Daimo Pay

Important notes for hackers:

Assume a smart relayer

As in all intent-based protocols, the relayer must validate intents before solving. "If you fast-finish a malformed intent, you might not get paid back" is not a bug but as-designed.

Our intents are designed such that bridgeTokenOutOptions are meant to be interchangeable alternatives, such as (100 USDC, 100 USDT). Meanwhile, finalTokenOut should also be a roughly equal value, say (100 DAI). They are primarily built to be used with stablecoins.

If an attacker creates an intent address with finalTokenOut of $100, but (at least one of) bridgeTokenOutOptions is worth less than that, then no solver will fast-finish such an intent, because they are not guaranteed full repayment. This is by design.

For the DaimoPay.sol/PayIntent.sol system, another known limitation: relayers cannot claim expired intents. Relayers do not fast-finish intents that are close to expiry, to ensure that the underlying bridge can complete before the intent expires.

Assume valid usage

The intent protocol ensures, first and foremost, that a user who creates an Intent Address and sends funds to it will either A. see their intent completed, or B. received a full refund. It cannot guarantee that misuse will not result in loss of funds.

In particular, overpaying an intent can result in loss. If Alice makes an intent address to send $100 to Bob on Base, but then she sends $150 to it on Arbitrum, a solver can complete the intent and keep the extra $50. This is analagous to setting a too-high slippage tolerance in Uniswap, or a too-high tip in other intent protocols. It is known behavior, not a bug.

--

The newer DepositAddress/DepositAddressManager system has no concept of over- or underpayment. (Non-dust) funds are transmitted regardless of amount. Known limitation: if a user sends a very large amount exceeding liquidity of underlying bridge, it may not be possible to run daStart(); in this instance, the user will get a refund once the DepositAddress expires.

Focus on loss of funds

The scenarios we're particularly interested in are ones where:

• A user uses the system as intended, but loses funds. These are Critical, see Rewards.
• A well-implemented relayer does everything right, but still loses funds. These are High, see Rewards.
• A malicious relayer can temporarily freeze or otherwise grief users, or vice versa.