How it works
Daimo Pay offers a fast, high-converting way to pay or deposit stablecoins. This page explains how our smart contracts accomplish this.
Motivation
Seamless cross-chain, multi-asset payments have been a long-standing technical challenge. Existing automated bridging and swapping solutions are plagued with issues, such as lost funds, clunky UX, and big trust assumptions.
We've built what we believe is the gold standard for cross-chain payments: fast, delightful, non-custodial, and trust-minimized.
Design goals
- Any asset, any network. If Alice has enough money anywhere, she should be able to use your app in one click. Swapping assets and moving funds across networks shouldn't create friction that loses users.
- One click. Just send money to an address, from any payment app or exchange. The swapping and bridging happens automatically without the typical two-step approval process.
- Max speed. Payments should feel immediate. As soon as Alice’s payment lands, a liquidity provider completes the transaction on the destination chain in typically two seconds or less.
- Trustless. The simplest way to achieve the above would be for Alice to send funds to a trusted custodian. Daimo is trustless and non-custodial: even if we disappear, you will still be able to recover your funds.
Intent Addresses
To fulfill all our design goals, we developed intent addresses.
An intent address is a smart contract that serves as a receiving address: it accomplishes a specific goal just by sending assets to it. Using Ethereum’s CREATE2
, we can make one address that works on all EVM chains. Daimo Pay encodes all the parameters of the action, including amount, destination chain, and contract calls, into the intent address.

This accomplishes our goals above. Alice performs a single transfer and the LP triggers the action immediately. The intent address guarantees Alice's intended action triggers, and the LP takes minimal settlement risk to instantly yet trustlessly complete the action in exchange for a fee specified in the intent.
Bridging
Daimo aggregates over multiple bridging protocols to abstract away the complexity of bridges and ensure end users get the best experience.
CCTP: Daimo Pay bridges using USDC via CCTP for all CCTP-supported chains. CCTP has no additional counterparty risk since it is operated directly by Circle, the issuer of USDC.
For non-CCTP chains, Daimo uses either Across or Axelar to bridge funds.
Neither Daimo nor liquidity providers ever control user funds. The contract only allows the exact flow illustrated above: from the moment Alice sends funds to the intent address, those funds are guaranteed to end up with Bob. The LP takes some reorg and bridge settlement risk by finishing the transfer immediately in exchange for a fee specified in the intent, but if no LP shows up, Alice or Bob can complete the intent permissionlessly themselves. In short, liquidity providers only provide speed and convenience, not trust.
Swapping
Similarly, the intent commits to the exact amount to bridge, and the exact amount of the destination transfer. This protects the payer, vendor, and the liquidity provider. By swapping to a non-volatile token such as USDC (on the source chain) and completing immediately (on the destination chain), the liquidity provider avoids price risk during the time it takes to bridge.
This lets Daimo Pay offers a convenient interface for apps and vendors. You generate a checkout link for X token on Y chain. Your users can pay with any token on any chain.
Bounced Payments
Intents can specify a contract call on the destination chain that is executed on
behalf of the user. If a contract call on the destination chain fails or
reverts, the payment is considered "bounced." In this case, Daimo Pay
automatically refunds the payment to the refundAddress
specified in the intent.
In most cases, the refund is sent directly to the user's wallet, in the intended token on the destination chain. If a direct refund is not possible (for example, if the customer paid from an exchange), we will notify you so you can handle the refund manually.
Refunds
Refunds are automatically sent to the refundAddress
specified in the intent in
the following situations:
- Intent expiration: If an intent is not processed within its expiration time (typically 24 hours after creation), any remaining funds will be refunded. This can happen if the user underpaid the intent address.
- Overpayment or duplicate payment: If the user overpays or pays the same intent multiple times, any excess funds in the intent address are refunded.
- Bounced payments: If a payment bounces due to a failed contract call, the funds are automatically refunded.
These refund mechanisms ensure that users can always recover their funds in cases of error, overpayment, or failed transactions.