Who’s building onchain trigger addresses?

I’ve been stressed by a crypto UX inconvenience that I deal with often, so I’m making it everybody’s problem.

The Problem

I use Accrue and Yara for sending money with stablecoins to and from my Revolut account. To send Naira into Revolut, I:

Buy USDC with my Naira on Accrue > Send USDC from Accrue to Revolut > Swap USDC for USD on Revolut.

This works well when both Accrue and Revolut support the same sets of chains, a coincidence of acceptance as I define it here. Both of them support at least one identical token-chain pair. If they don’t, I have to send the funds from Accrue to a non-custodial wallet first, bridge + swap on a platform like Matcha, and then send to Revolut.

As you can imagine, not only is this expensive, the UX is horrendous.

Apps that custody crypto on behalf of their users have to be efficient about the chains and tokens they support. Every additional chain and token they support increases their operational overhead and costs, so they have to make trade-offs on what to support.

My proposed solution — using onchain liquidity

Decentralised Exchange (DEX) aggregators don’t have these same limitations as they don’t hold liquidity for tokens. They source the liquidity in real-time and, as such, can support many chains and tokens easily.

In the ideal case, apps like Accrue and Revolut would integrate providers like 0x and LiFi to increase their coverage. Users would just provide the destination details, and the aggregator would figure out routing on their behalf. But getting applications to adopt these aggregators might take a while.

In the absence of a formal integration, this is what more savvy users like me already do. We take a few additional steps to source the liquidity. However, smart contract addresses are a path to offer this more seamlessly to mainstream users immediately.

Smart Contract Addresses

A smart contract address is an entry point for interacting with a deployed contract on a blockchain. Sending a transaction to the address triggers predefined functions in the contract’s code, which will execute specific actions on the blockchain.

It’s the same as exposing functionality to users through a button or an API; the only difference is that they can access it by sending a transaction to it. Having wallets as an open interface that can trigger actions is such a cool feature that allows developers to distribute products to end-users directly.

In this case, someone could build a tool that leverages a DEX and Bridge aggregator to offer this service to end users. Take an example of a user who wants to send 200 USDC to Revolut but is stuck with Accrue only supporting Base, and Revolut only supporting USDT on Optimism. The experience would look like:

• User selects their source chain as Base and token as USDC
• They select their destination chain as Optimism and the token as USDT
• They provide the destination address to receive the funds.
• The platform generates a smart contract address for them that contains the functions required to trigger bridging, swapping, and sending the tokens to the right address.
• They can then use this withdrawal address on Accrue, and when they send their 200 USDC on Base, it’ll land in Revolut as USDT on Optimism.

On the backend, this might require a system that:

• Listens for deposits of the token onchain
• Fetches a quote from a bridge + swap aggregator, with the recipient set to the Revolut address
• Submits the transaction while covering the gas on behalf of the user. They might choose to wrap the gas in the quote as a fee.

Payment use cases are fundamentally chain & token-agnostic, and solutions should be as well. In reality, I consider this specific application a stop-gap as I expect that centralising factors will solve this problem further away from the user’s line of sight. However, trigger addresses are an interesting way to distribute onchain products and give user more capabilities from their custodial wallets.

Addresses as ‘hooks’ that extend app functionality

Similarly to how Zapier enables you to access the APIs of Web2 services through a simple workflow interface, I would like to see a workflow builder where users can set up predefined onchain actions and expose them through a contract address that they can send funds to.

In some sense, we built a version of the trigger address concept as Sendcash in 2020. We used it to trigger fiat withdrawals for cross-border payments. A user would provide us with a Naira bank account, and we would generate a wallet address linked to it. Whenever they sent Bitcoin into that address, we’d convert it to Naira and then forward it to the bank account on their behalf.

A cool onchain implementation of this that we often recommended to customers at 0x who wanted to split their trading revenue with other parties at the source was 0xsplits. Say a customer had a referral program and wanted to split fees at source with the referrer, they could go on the tool, set up the configuration of addresses and how the fee should be split, and generate a contract address for it. They would then pass that address as their fee collection address when requesting a quote from the 0x API. On submission, any fees accruing from the transaction would be sent to that address and automatically split and disbursed as programmed. While the API didn’t natively offer splitting revenue across multiple addresses, this single contract address acted as a hook that extended the functionality of the service.

I can see this being used for various consumer and business applications such as savings automations, yield deposits, payments disbursement, and so on.