Why Intents?

Today trading on-chain is anything but fun.

Users need to think about slippage, front and back running, and their gas price settings. We give users bandaid solutions, like private RPCs, slippage controls and RFQs. Those solutions are bandaids at best.

We're solving problems we created in the first place, blaming user ignorance rather than our lack of design skills.

Why can't users trade with $1M worth of tokens if they have no ETH? Why should they get only 40% back of the backrun they themselves created from poor execution? Why if you have a $1M worth of assets, you can't transact if you don't hold any ETH?

There is no fundamental reason why any of those should be true. Intents re-architect those systems by having a professional take care of execution. There's no free lunch, so the expert, which we will call fulfiller from now on, has to handle all the complexity. The key is that they're an expert! Any professional will want to lift to endure the pain for users, as long as they're compensated for it.

In the intent model, users pay fees and everything is take care of for them, they give up control to get what they want.

Today, the fastest growing DeFi apps are all intent based.

For example:

• Across: A bridge where fulfillers give front money to users on any given chain for a small fee. Across is one the fastest and the cheapest bridge on major routes.

• Unibot: A bot for users to trade and snipe token launches from Telegram. Unibot goes as far as taking control of user private keys! Despite this, users love Unibot for the convenience and functionality it provides. The Unibot team itself is the fulfiller in this case. Unibot is one of the fastest growing DeFi apps today.

• Flood: Allows you to trade with optimal execution with just one signature. From yours truly.

Intents are what teams will build

Better UX is nice, but not why people will build intent based apps. People will build intent based apps for the network effects and economic benefits. First, let's review a basic intent based architecture, we'll dive much deeper in a future post, but for now:

Users signal an action they want performed. For example: "Swap 100 A for B." This is in practice done through sending a signature to a database. An on-chain smart contract takes care of settlement, verification, and whitelisting Fulfillers. A Fulfiller see the intent, fulfills it and calls the smart contract for settlement.

This on-chain logic is simple, so I expect primitives like Permit2 will ossify as standards to handle settlement. The business logic is off-chain so apps are harder to fork and have regular release cycles. Now, nothing stops Fulfillers from batching some intents execution in one transaction. Batch execution costs less than the sum of individual executions as many of share the same state. Fulfillers can then either pocket the difference or use it to incentive more usage. More usage means bigger batches, which means smaller average execution cost, which means more usage...

The smartest fulfillers will re-order their batches to find the cheapest execution order, effectively building Mini-Sequencers.

As the batch value grows, fulfillers become worthy bidders for blockspace, making them well poised to also capture MEV opportunities. New PVP scenarios open up where apps fight for block-space and censor each others to achieve best execution. All leads to higher fulfiller profits, which you guessed it, leads to higher usage and growth.

The dark side of intents

As fulfillers take full control over user execution, several problems arise:

• Fulfillers can be censors, by not fulfilling user intents.

• Fulfillers can be malicious, putting users funds at risk

• Fulfillers can be bad at execution, leaving users with bad outcomes.

We can ease those problems by following a few key design principles:

First, fulfilling should be open and users should have the option publicly to broadcast their intents. An example is an event in a smart contract. This can be a secondary communication channel, but should always exist.

Second, funds should move only in the transaction that fulfills the intent. Signatures and settlement standards like Permit2 solve this. When atomic settlement is impossible, fulfillers should get paid last. Across is a good example where fulfillers get paid after confirming successful execution.

Finally, the intent should be verifiable. This means you can look at the execution of an intent and assess wether you've got a good solution or got ripped off. Today developers hand pick fulfillers, which in turn post a bond, and punish them if they misbehave.

This is not great, as developers and fulfillers can still collude (or be the same entity) to give bad execution. The hard, one way to fix this is to tie the intent to an easy to verify problem (which can be really hard to solve!). Fulfillers must provide a proof to the protocol when executing a batch. If the proof is valid, they can fill the intent. This process is similar to a ZK rollup sequencer, which posts proofs of execution to L1.

Conclusion

Intents are a powerful design pattern and all incentives will lead to teams building intent-based apps. Intents are a winner take all game, with apps competing for blockspace and even taking over MEV. It's crucial that we build apps that are open, verifiable and safe.

If those challenges excite you, and want to tackle them with a small and extremely talented team, reach out on twitter or email us at talent@flood.bid .