Who’s building trigger addresses II?

Yesterday, I wrote about enabling users to use addresses to trigger a chain of actions onchain. Specifically, I discussed using it to offer onchain liquidity in CEXes to give users more flexibility. However, there are clear product risks to resolve to implement something like that seamlessly, especially for less crypto-savvy users.

Handling address UX

The most obvious UX challenge users will encounter is the ugliness of wallet addresses. They’re not easily parsable by humans, making it easy for users to accidentally paste or use the wrong address. Blockchain transactions are practically irreversible, so such an error can lead to the loss of user funds.

While there are human-readable options like ENS for Ethereum, not all apps support them. As such, the best bet is to reinforce context clues for the correct address — e.g., highlighting the last five digits for easy reference — and urging users to verify addresses properly before sending funds.

Managing errors gracefully

A chain of multiple transactions could fail at any point — the swap transaction, bridge, or send transaction. A good product should handle failed transactions gracefully by providing a refund mechanism to the end user’s source address if anything goes wrong downstream.

Handling onchain uncertainty: Slippage & MEV

When people are trying to send money, they expect that what they see is what they will get. However, this can be complicated to achieve with DEX trades due to a variety of factors, most commonly slippage and MEV.

1. Slippage: Due to normal market movements, the price of the assets at submission might ‘slip’ and be more or less than what the user was quoted. Most users would be happy with receiving more money than quoted, but the reverse is pretty common.
2. MEV: Beyond normal market movements, blockchain validators or bots can impact the price at which the transactions settle by reordering transactions in a block. The effect is often the same as ‘natural’ negative slippage: the user receives less money than expected.

To handle this, the developer can:

• Define a slippage tolerance for the trade — how much the price can move downward before it reverts. Only the minimum amount based on that tolerance should be displayed to the user. If the price slips below what is expected, the transaction reverts entirely, and the user is refunded.
• Use liquidity sources like onchain private market makers (e.g., 0x RFQ) that don’t slip.
• Submit the transaction using a private mempool to prevent MEV.

Insurance

A well-designed product will have to factor in some form of insurance and risk scoring to smooth out these uncertainties for users. This insurance might be funded by:

• Adding a small premium on all users to spread the risk/
• Allowing users to opt into insurance and pay for guaranteed results. The premium might depend on the transaction size, tokens involved, etc.
• Taking any positive slippage/trade surplus generated on all transactions.

This gives them the flexibility to design a more robust product with a seamless experience. In the case I described in the previous article, using it for USD stablecoin payments, some of these issues are less common, as slippage and price swings are not as severe.