What do you guys think about intents? Pros and Cons. Where should they be processed/matched, who should match them (MEV searchers, builders, solvers)?
Primer on this:
3 Likes
Really love this article on intents, also wondered - while reading it - where encrypted mempools like shutter fit in (then saw you already posted here^^). Can they be a solution against toxic MEV resulting from order flow being able to be acquired by blockbuilders?
2 Likes
Hey! Super interesting question, we’re currently working on a blog post on this!
Couple of thoughts on this:
At first glance, the concepts of intents and encrypted mempools might appear to be in contradiction. After all, the fundamental premise of intents is to reveal information to match the user’s needs, whereas encrypted mempools aim to conceal information. However, upon further examination, it becomes apparent that these concepts can not only co-exist but encrypted mempools could actually be the key to enabling the vision of an Intents-based transaction supply chain. especially under the assumption that censorship resistance and minimal trust are required.
Where exactly encrypted mempools like Shutter fit in depends on who wants to be protected against whom and when the intent/bundle/partial block/block is considered to be final. The essential question is then: when/at which point in the transaction supply chain do you encrypt?
2 high level examples:
-
You want to protect the user against front-running by solvers. Then the user needs to encrypt (a part of) their intent and then solvers have to match it while a certain part of the intent is still encrypted. Gets a little complex on what exactly to encrypt and how to match then.
-
Alternatively, you might also assume that the user is fine with getting front-run, but that then the solvers want to protect themselves against other solvers or the block proposer (simplifying a little bit here and assuming a non-PBS world). Then users would be sending plain text intents, those are matched by solvers. The solvers could encrypt those “bundles” and then pass them on to the block proposer.
There are a lot more variants like this and it gets little more complex with PBS.
Stay tuned for the blog post!
2 Likes
Hey Luis,
Looking forward to the blog post.
Regarding #1 - Assuming (for a hypothetical) that there was a global agreement on what to encrypt and how to then match, would there be any negative outcomes or costs to the network/txs from this approach?
If it’s covered in the blog I’ll wait. 
2 Likes
Sounds really interesting looking forward to the blog!
- You want to protect the user against front-running by solvers. Then the user needs to encrypt (a part of) their intent and then solvers have to match it while a certain part of the intent is still encrypted. Gets a little complex on what exactly to encrypt and how to match then.
→ So maybe the solvers can be shown there will be a trade of X asset to Y asset, but only when they take on the intent the assets themselves are revealed? So they do not have a view of all the intents/volume on the trading pair, which would be much more valuable to exploit.
2 Likes
Without having a concrete architecture/implementation proposal, it’s a little hard to say, generally I’d presume that the trade-offs will be similar to how they are for implementing Shutter e.g. into an L2, so on a high level:
- Same instant inclusion latency, but slightly higher (~10 seconds) execution latency due to the encryption/decryption process
- (we think instant execution latency is fundamentally not compatible with geographical decentralization and censorship resistance. More on that relationship: Decentralized crypto needs you: to be a geographical decentralization maxi - Research - The Flashbots Collective )
- Added costs to pay the keypers for their services (but we think those will be offset on average by what the users will save in terms of not getting front-run/less malicious MEV extracted).
2 Likes
Yes, I think that would be one good example of a partially encrypted intent!
1 Like
I think intent based is evil actually cause it could and will make our ecosys more centralized. If the user lose the right to choose the routine to process the asset. Basiclly I can use my own dex,lending protocal and give a higher fee. AA can exactly make “intent based transaction” happened by bundling the different transaction. SO bullishi on AA and bearish on intent-centric platform
2 Likes
Definitely I’m also seeing that danger and many intents focused efforts currently are short sighted and will result in a worse than status quo outcome. Vlad Zamfir says (paraphrasing): Intents are in your head, they shouldn’t be communicated, otherwise you’re at risk and even putting other people in the market place at risk.
However, intents can be an extremely powerful UX paradigm, and I think there’s a way to combine all of this and make this safe if:
- the trust requirements are transparent
- intents solving process is separated clearly from the transaction/execution process
- there’s always an option for users to not reveal information about their intents, if they don’t wish to do so)
1 Like
Yes， I totally agree with what u said. And I think mature AA wallet are excatly solve all of this, what do u think. Fundamentaly, user should have the right and power to make the decision on all steps.
1 Like
Auction based intents are good. Payment-for-order-flow intents are not good, because they will distort the markets (centralisation).
PFOF is banned for TradFi markets in
- EU
- UK
and has some restrictions now being applied in the USA as well.
1 Like
Here is a good post Illuminating Ethereum’s Order Flow Landscape related on the topic a bit.
1 Like