# Intents on Suave: v0
> The following was completed during ETH NY 2023. Further research is underway and more posts will follow including an implementation spec.

Intents have recently gained a lot of attention in the crypto community. They are a way for users to express what they want, without having to worry about how to achieve it. This is a very powerful concept for users to be able to navigate the modular complexity of the crypto space. The main downside stems from the increased fragmentation of off-chain infrastructure (solvers) currently required to solve user intents. Additionally, existing intent systems have very limited expressivity, mainly focused on simple token swaps. Recently, [Essential](https://blog.essential.builders/) proposed [ERC-7521 ](https://github.com/essential-contributions/ERC-7521/tree/master)that makes important steps towards a unified intent standard on top of the ERC-4337 standard. There are still many open questions see our [discussion on ethereum magicians ](https://ethereum-magicians.org/t/erc-7521-generalized-intents-for-smart-contract-wallets/15840/5)and our aim is to investigate how Suave can be used to address some of these questions.

## Key Considerations for v0

### 1. Intent Privacy
How do we keep intents private? Can we make the `decryptionCondition` more expressive on when the user intent can be gossiped to solvers? Another option would be to enable multi-stage intents with expressive hints.
* For the decryption condition, if an intent is not yet ready to be acted on by solvers due to various external data dependencies like waiting for a specific EVM event to be emitted before the intent can be `activated` . The trusted suave node would need to keep these pending intents in their private mempool and be a trusted operator to resolve data dependencies. This would essentially result in suave itself being a specialized solver for certain intent types.
* A more flexible design would be multi-stage intents (called intent segments in ERC-7521), a user or dapp would compose a user intent in a specific ordering of segments that the user desires. For example, an external data dependency could be the first segment followed by a swap, and then another external data dependency with an expiry that leads to the final segment of a bridge of funds to a specific chain. This would only require a mechansim that stores intent `segments` in the confidential store and make them available to specialized solvers/searchers to compete on a solution for. This preserves intent privacy and a user can easily only make the specific portion of their intent that they want to be solved.

### 2. Intent Validation
We need a way to validate intent solutions. Currently, suave validates bundles by simulating them. For complex intents, suave would need to accept a wide variety of intent validation schemes. A user could elect their security preferences since some validation mechanisms might increase latency and cost for solvers (ie zk proof of data dependency). For this design we'll focus on simple to verification, like verifying expected token balances, since the interface can easily be used for more sophisticated verification schemes that people may come up with.

### 3. Solver Cooperation
Cooperation between different solvers. If a user submits an intent from multiple domains (swaps, bridging, NFT trade, data dependency etc), would one solver come in and fulfill this intent? Its more likely that you'd have specialized solvers capable of parially fulfilling these types of intents and the user would want to best possible combination of these solutions.

## Mechanism Design on Suave

### Scope for v0
1. Intent privacy -- users shouldn't have to reveal their full intentions
2. Transparent, cooperative and competitive solution market
3. Data dependencies limited to on-chain data
4. We re-use the proposed ERC7521 intent standard

### Long Term Goals
1. Multi chain settlement
2. Solution proofs
3. Anoma as a complimentary component
4. secure enclaves?
5. Convenient UX and integration with AA infrastructure
1. Lots of options here as AA infra is off-chain and can route to suave if needed

---

### Intent Format
The follow suave transaction model would be used (standard bid with possible expressive `decryptionCondition` and the encrypted data would be the intent data):

struct bid {
  BidId id
  bytes / uint64 decryptionCondition 
  address[] allowedPeekers
}

bytes[] intentConfidentialData

Following the ERC-7521 standard, we'll just define the `intentConfidentialData` as a sequence of intent segments. These segments can either be a "SWAP" or "DATA_TRIGGER". A `SWAP` intent would essentially define the `inputToken` , `outputToken` , and `inputAmount` . A `DATA_TRIGGER` would essentially define a storage slot, evm event, or token price with the associated conditional operator (`>`,`<` `==` , etc) and value (event params, price, etc). We assume that a "DSL" would allow be used to composed intents like so:

1. If the price of $BITCOIN goes above $1000, sell all my $BITCOIN balance for USDC,
2. or if whale.eth sells his $BITCOIN on any DEX, sell all my $BITCOIN for USDC

We point out that this would get "compiled" down to [`price > 1000 OR whale.eth swap event for token`, `market sell $BITCOIN for USDC`].

To validate the intent we'd create a standard contract that lets you fetch the confidential intent data:

function fetchIntentConfidentialData() public returns (bytes memory) {
  require(Suave.isConfidential());
		
  bytes memory confidentialInputs = Suave.confidentialInputs();
  return abi.decode(confidentialInputs, (bytes));
}

---

### Resolving Intent Segments
#### Option 1: More expressive decryptionCondition
We can modify the `MempoolBackend` to accept more types of decryption conditions other than `uint64`. For example, Suave maybe efficient at solving certain data depencies with its order flow and access to settlement chain data. Suave essentially becomes a solver for data dependencies in this case. In this scenario, the mempool would have a mempool engine that figures out which data dependencies are required for an intent in the mempool to be acted upon by solvers for on-chain routing. If the data dependencies are met, the intent will be decrypted and made available to external solvers. For the example we gave above, the decryption condition would be set to the data dependency (`price > 1000 OR whale.eth swap event for token`), the mempool rule engine would have to ingest data and check which transactions are ready for decryption.

Pros:

1. Keeps intent private while data dependencies are still being solved
2. No additional precompiles required

Cons:

1. Not very flexible
1. its more complex to create multi stage intents, the mempool would require a sophisticated engine to keep track of data dependencies and the current segment an intent is in
2. Relies on Suave client to solve data dependencies
3. Doesn't open up mechanism innovation to the broader builder solidity ecosystem (ie enshrines this intent mechanism)
4. Doesnt open up competition from external solvers that may have higher quality data

#### Option 2: Suave facilitates solver competition and cooperation on user intents
When an intent gets submitted, an event is emitted with the first segment of the intent that interested solvers listen to and begin solving for. If a solution is found they call the intent standard with their solution. The intent standard validates the solution and emits the next intent segment for that Intent. This process is repeated until the intent is considered fully fulfilled.

The node can store the current state of the intent in an `intent:v0:active` keyspace. The relevant data would be the current segment the intent is on and the actual intent data.

An intent solution, is itself an intent (see ERC 7521). It is also possible to host several rounds of solutions, since Suave block times will be quicker than mainnet.

Pros:

1. No additional pre compiles needed
2. Allow for more open competition on intent solutions
3. Preserves intent privacy by only making the minimal amount of the intent public
4. Allows for more innnovation on new intent standards and specialized solvers

Cons:

1. Possibly slower since you'd need to wait for consensus, however suave block times are much faster than mainnet and some L2s