Introducing Brink Intents: Brink is building the most advanced intents protocol for Web3

Comparative Architecture
1

Introducing Brink Intents
Brink is building the most advanced intents protocol for Web3.

We see a future where intents are much more powerful than they are today. With Brink Intents, users sign their desired outcomes instead of sending transactions directly to a blockchain. A single signature can delegate multi-action workflows to solvers on any network. Signatures are composed with any number of conditional state checks and single or cross-chain actions such as market swaps, limit swaps, and transfers. DApps and wallets that build on Brink Intents offer massive UX benefits to their users by abstracting away transaction submission and gas payments, and by simplifying many time consuming steps into one signature. It is a completely new paradigm for interacting with Web3, and it’s powered by account abstraction.

Intents built with our protocol have three core properties. They are:

  • Composable: Actions such as swap, transfer, and bridge can be composed together into a single signed message**,** allowing for infinite combinations of intended outcomes.
  • Conditional: Intents can be enabled or disabled by state conditions, such as market spot prices and deltas, wallet balance changes, governance voting results, or off-chain analytics brought on-chain via oracles.
  • Continuous: A single intent signature can permit continuous outcome solving over a period of time, such as the intent to swap 1 ETH for DAI at market price once every 50,000 blocks or at a specified time interval.

Our protocol lets users delegate any workflow to solvers within a single signature: from simple limit order routing to extremely complex multi-swap, state-conditional actions across different networks.

Composable Intents

Web3 users often have complex workflows that require many transactions to achieve their desired outcomes. Definition of these outcomes can be broken down into Outcome Primitives. These primitives define a user’s desired state, and solvers are incentivized to find the most optimal way to fulfill that state. Brink Intents supports outcome primitives such as:
‍

  • Swap: “My desired outcome is to have Asset A, I’m willing to pay with Asset B”
  • Transfer: “My desired outcome is to move assets from one address to another”
  • Bridge: “My desired outcome is to move assets from the same address on one chain to another chain”
    ‍

For all of these state-changing outcome primitives, the user signs what they want to happen, but it’s up to solvers to deal with the complexity of where to swap, how to transfer, or what bridge to use.

Brink Intents also supports Conditional Primitives. These primitives are used to determine which outcomes are currently allowed by a user. All conditional primitives can be represented as boolean state. Logic around questions like “has my swap been completed?” and “is the ETH/DAI price less than 1,800?” can be represented with conditional primitives, since these ultimately resolve to either true or false.

Conditional and outcome primitives can be composed together into signatures that delegate user workflows to solvers. Consider a simple workflow where a user wants to swap from DAI to ETH at a low market price and then swap from ETH back to DAI at a slightly higher market price. A user can compose this intent with two limit swap outcome primitives and a conditional primitive to check whether the first limit swap outcome has been solved. Solvers that understand how these composable primitives work can monitor and solve them independently.
‍

‍

In this workflow, the user only signs once, but solvers will have to “solve” this workflow with two transactions that would likely happen many hours apart from each other. A solver may have never seen this particular composition of primitives before, but the solver only needs to understand how to interpret and solve each primitive individually. Using the composable primitives that Brink Intents provides, an infinite set of workflows can be composed, signed, and delegated for solving.

State Conditions

Brink Intents can support conditional primitives for any on-chain state. State can represent anything from price thresholds to complex off-chain analytics data (provided this data is brought on-chain with an oracle). Conditional primitives check state and always resolve to either true or false.

Using a price condition as an example, a conditional primitive could check if the current TWAP (Time Weighted Average Price) on a Uniswap pool is less than the user’s signed price. The conditional primitive forces solvers to prove that the condition is true by reading the TWAP value and comparing it to the user’s signed price threshold.

The potential set of state is infinite. Brink Intents supports a subset of conditional primitives for state such as:

  • Market prices and deltas
  • Blocks mined / not mined
  • Blocks / time elapsed
  • Gas prices
  • Address balances
  • Intent outcomes, such as swap fill state

More complex state conditions can be integrated to support more powerful cases. For example:

  • Account actions, such as swaps and transfers
  • DAO proposal voting results
  • DeFi data, such as liquidity or yield
  • Any off-chain data brought on-chain

Our core protocol is un-opinionated about what state actually represents, so conditional primitives can be built around any state check that resolves to a boolean value. Ideally, conditional primitives will be built around state that is not easily manipulated by a centralized entity, but ultimately this trade-off is left up to users of the protocol.

Continuous Delegation

Intent-based protocols in Web3 today only support signed limit orders, which delegate a single action. Brink Intents enables Continuous Delegation: a single signature can delegate a workflow with any number of outcomes over any period of time.

One example of continuous delegation is the intent to make a recurring purchase or sale, which is sometimes referred to as DCA (Dollar Cost Averaging). In the context of Web3, a user might want to swap 3 ETH for DAI. Instead of doing this all at once, they want to average the swap over 150k blocks. They’re willing to pay a 1% fee for each swap. This can composed with standard Brink Intents primitives into a single signature. Solvers can use the same signature to solve the user’s desired outcome multiple times.

‍

This particular intent to swap will end after about 3 weeks (assuming 12s block times), but intents can also be cyclical and continue indefinitely.Consider a market maker who has the intent to buy and sell on the ETH/DAI market at a range between 1,800 DAI and 2,000 DAI. Their intent workflow might look something like this:

‍

This intent would only have to be signed once. It could be valid until canceled, or have an explicit expiry block, but otherwise it will be executed continuously by solvers in a loop for as long as market conditions allow, using the same initial signature.

User Experience Benefits

Brink Intents protocol lets users put complex on-chain workflows into motion with very little effort, instead of having to deal with direct blockchain transactions that require deep protocol knowledge, MEV awareness, gas, transaction risk, and lot of time. We believe that the composable intents layer is key to onboarding future users by removing a big part of the current learning curve, and reducing complexity for those already using Web3 applications. Brink Intents can benefit both existing and future users.

‍

Users who primarily use EOA’s can delegate any of their existing transaction-based workflows to solvers.

‍

Multi-Sig / AA Wallet Holders can sign and approve continuous actions that execute over time, rather than having to define every individual transaction and coordinate signing when an action is needed.

‍

DAOs can create proposals that result in intent-based delegation instead of transaction based actions to ultimately reduce the number of proposals they need to approve.

‍

Whether these users interact with Brink Intents directly using our builder tools, or indirectly through a Web3 application that has integrated Brink Intents, these benefits are the same.

Solver Incentives

In all intents-based systems, solvers need incentives to cover their operational cost and earn profit. To capture incentives, solvers need to compete with other solvers as well as generalized MEV bots running front-running strategies like sandwich attacks. The solvers themselves are part of the MEV ecosystem since they are attempting to extract the maximum value from every intent they solve. The most optimal solver incentive designs work by aligning solver incentives with optimal user outcomes, so that more MEV for solvers actually results in faster and better execution for users.

‍

Brink Intents is designed to accommodate any solver incentive design. Our primitives use two common incentive structures: implicit and explicit. In both cases, fees are taken from the tokens involved in the intent and the user does not have to hold ETH or pay directly for gas.

‍

Implicit Incentives are used in our limit swap primitives. For a limit swap where the user is willing to pay 1 ETH and requires receipt of 2,000 DAI, a solver attempts to find a route that will return more than 2,000 DAI. For example, if the solver finds a route from 1 ETH to 2,050 DAI, they can take the additional 50 DAI to cover the transaction gas cost and earn profit. Solvers compete to be the first to find the most optimal route that covers their costs. The user specifies a desired input and output, but does not need to sign an explicit fee.

‍

Explicit Incentives are used for our market swap and transfer primitives. For these, the user needs to sign an explicit fee that they are willing to pay to the solver. The fee can be a fixed amount, or can include some dynamic computation based on state, such as current gas cost plus a fee percentage. Using a recurring transfer as an example, a user who wants to transfer 7,000 USDC to another account once every 100,000 blocks might sign an explicit fee of gas cost + 2% paid to the solver in USDC at ETH/USDC market rate.

Protocol Architecture

Brink Intents Protocol’s on-chain and off-chain components work across EVM networks to securely execute desired outcomes defined by users.

‍

  • Brink Intent API: A hosted service for building, signing, storing, and reading intents

  • Brink Intent Pool: An off-chain intents data store

  • Brink Smart Contracts: A smart contract layer that solvers must interact with. Enforces security of intent execution and verification

  • Brink Solvers: A network of bots that resolve intent outcomes on EVM-compatible chains

  • Brink UI: An app built on the Brink Intents infrastructure for end-users to create intents

‍

1643Ă—1872 307 KB

Intent API

The primary interaction layer for front-end DApp developers and solvers to use the Brink Intents protocol. Front-ends use the API to build the intents data that their users need to sign, and to submit user signed intents to the Intent Pool. Solvers use the API to query the Intent Pool in order to discover intents to solve. The API also provides endpoints for interacting with Brink smart contracts and building transactions that solve signed intents.

Intent Pool

A data store for signed intents. This is a permissioned intent pool specifically designed for the Brink Intents protocol. All signed intents are public by default. Since intents are public, our intent pool treats them as immutable and does not allow them to be modified or removed by users. While the intent pool is permissioned, signing and solving in Brink Intents protocol is permissionless. Users and DApps using Brink Intents can choose to broadcast intents to other intentpools. The protocol is designed to accommodate decentralized intentpools and we hope these will be available in the near future.

Brink Smart Contracts

A smart contract layer that all solvers must call when executing intent solving transactions. The Brink smart contracts validate intent signatures, verify signed intent conditions, control execution of conditional and outcome primitives, and check that solver transaction outcomes meet the expected outcomes signed by users. These smart contracts ensure that solvers can only take actions that users authorize.

Solvers

A network of bots that solve user intents. They are incentivized by MEV. Solvers are not permissioned at the smart contract layer, but users can choose to limit solving of their intents to a specific solver or group of solvers.

Brink UI

A DApp to help users create and sign intents for common use-cases, such as stop-loss orders and recurring swaps (Dollar Cost Averaging), and to build custom intents without having to write code or interact with an API. The Brink UI is a web application that works with Metamask and other standard Web3 wallets.

Account Abstraction

Brink Intents supports both EOA’s and smart contracts as signers, allowing intents to be signed with either EIP-712 or EIP-1271. Brink Intents also supports creation of intents as an EIP-4337 UserOperation. Part of the Brink smart contract layer is an extremely light abstracted proxy account that EOA’s and smart contract wallets can either deposit to or approve to.

Multi-Chain Support

Brink Intents works on any EVM-compatible chain. The Intents API and Intent Pool allow intents to be signed for any chainId. Users can also create intents that involve multiple chains.

Next Steps

Brink Intents is currently only available to early access users. Please reach out on Discord or Twitter @brinktrade if you’re interested in building.

2 Likes
2

Hey welcome to the Anoma research forums. Its great to have you here :smiley:! 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?

3

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