Anatomy of an intent
An intent has two parts:| Part | Holds | Lives where |
|---|---|---|
| Route | What to execute on the destination chain (token transfer, contract call, deadline) | Read by the solver on the destination |
| Reward | What the solver gets paid on the source chain when execution is proven | Locked in a Vault on the source |
keccak256(destination, routeHash, rewardHash) — a deterministic identifier that both chains agree on without ever transmitting the full intent.
The intent lifecycle
- Publish and fund. The user (or a relayer) publishes the intent and transfers the reward tokens to a deterministic vault address. Funding can happen before publishing — the vault address is CREATE2-derived from the intent hash.
- Fulfill. A solver executes the route on the destination chain, recording the fulfillment in the destination Portal.
- Prove. A prover (chosen by the user) carries proof of fulfillment back to the source chain.
- Settle. The source-chain Portal verifies the proof and releases the reward from the vault to the solver.
- Refund (if no fulfillment by deadline). A permissionless refund service returns the reward to the user.
Why intents (vs. transactions)
Transactions specify a path. Intents specify an outcome. The difference matters when the optimal path is unknown at signing time, or when the path crosses chains that don’t share execution.| Property | Transaction | Intent |
|---|---|---|
| Specifies | Exact contract calls | Desired outcome |
| Best path chosen | At signing time | At fulfillment time, by competing solvers |
| Cross-chain | Manual coordination required | Atomic with cryptographic proof |
| Failure mode | Partial state, manual recovery | Atomic refund, no partial states |
Read next
Solvers
Who fulfills intents and how they get paid.
Provers
How settlement proof crosses chains.
Vaults & resource locks
How funds stay non-custodial.
Settlement vs Orchestration
The dual-mode execution model.