This post was flagged by the community and is temporarily hidden.
2 Likes
Hey welcome to the Anoma research forums. Its great to have you here 
! Thanks for contributing some thoughtful topics already.
Enjoyed the post. I have a few questions to start the conversation.
Is this like Permit2 ?
Is there any way for the solver to abuse this privilege?
- Are these immutable?
- Are any funds escrowed in this contract from a user or solver?
- Is this similar to Uniswap X reactor contracts?
Do you have an opinion on what is the best way to integrate with Dapps or Wallets; E.g., Is it better to target specific applications?
Thinking about this question in general a bit recently. Uniswap’s advantage is that their front-end provides a decent amount of order flow. Filler’s aren’t really a new role, they are just MEV agents incentivized to behave in a particular way. I wonder how you could create this incentive more generally for Brink Intents.
One idea is integrating with a neutral block builders. These builders do not do their own searching like integrated searcher-builders. They compete on bundle inclusion and extra services (more so in the future as we will see pre-confirmations, gas futures, cancellations, or conditional actions ) to get orderflow.
Is there a whitelisted group of solvers or can anyone permissionlessly solve brink intents? Are there any privacy or accountability (reputation system) affordances provided to users?
Thanks for reading! These are really good questions.
Permit2 is specific to token approval and allows users to issue approvals with gas-free EIP-712 signatures without having to submit an approve transaction for every separate contract they’re approving. We love Permit2 and are considering adding support for it so Brink EOA signers don’t have to pay gas for approvals. Brink’s Continuous Delegation concept let’s users sign a single intent that allows more than one solver issued transaction. Simple example would be a swap that is allowed to be executed once every 1000 blocks. Similar to Permit2 in that it also uses EIP-712 signatures, but different because it’s not just for token approvals.
A signed intent in Brink is composed of a set of functions that solvers have to run. We call these Primitive Functions. If one of these primitive functions reverts, the solver won’t get their MEV and they have to pay for the reverted transaction. Brink intents can include anti-replay rules as primitive functions. In the case of an intent that allows a swap every 1000 blocks, the intent composer/signer would include a primitive function that will revert if 1000 blocks have not passed since the last run. As long as this function behaves as intended, there’s no way for a solver to run a solution more than once every 1000 blocks. In short, solvers can’t do anything that isn’t allowed by the primitive functions within the signed intent.
The primitive functions in smart contracts that we have deployed are immutable. More can be added. But we don’t have any restrictions at smart contract level on what the user can or cannot sign.
All primitive functions we’ve designed use approval/transferFrom, as opposed to escrow where users would deposit funds into a contract. With our primitive functions, solvers can move funds via transferFrom as the user has allowed, as long as the user’s desired state outcomes are met. Brink protocol isn’t opinionated about what primitive functions are used, so an escrow based function could be added in the future.
Yes, our limitSwap and marketSwap primitives are very similar to Uniswap X’s reactor contracts. The main difference is that ours are designed to fit into a system of composability for intents, so users aren’t restricted to just signing a single limit order intent for example.
We think any wallet or app that wants to include intents-based features (recurring swaps for example) would be a good candidate for integration.
A standard for solver solution transactions could help immensely. Solvers have to balance the amount of effort it takes to integrate new intents protocols with the potential MEV opportunity of the integration. A standard interface would make it much easier for them to integrate new intents protocols.
So far we haven’t included anything opinionated in our architecture around how solver tx’s get included in blocks. I don’t necessarily think MEV incentives for block builders is bad, as long as it aligns with the user’s goals. Interesting to think about conditional order flow at scale and how it relates to this. For example, if we have multiple orders that will be solvable at the same time once a specific price threshold is exceeded, how is the execution order determined i.e. who gets the most favorable price? Would love to dig into this one more.
In Brink protocol, solvers will not be whitelisted at smart contract level, but signers can choose to sign their intent with their own set of approved solvers.
There’s no formalized reputation system, we believe solver reputation will evolve organically. More generally, with proper protocol design there should be no risk in allowing a “bad” solver to participate in an intents protocol (outside of exploitable smart contract code risk, which can be mitigated). Incentives should align such that when solvers compete, users get better outcomes.
For privacy, everything solvers execute in Brink is ultimately public if it’s getting mined on a public chain. I think this is an area where we could benefit from the research Heliax is doing around zk and trusted execution. Privacy for intents is one of the most common asks we’ve had.
1 Like