Skip to main content
A vault holds the source-chain reward for one intent. In the EVM implementation, the Portal derives its address deterministically and deploys the vault when needed. The reward is held separately from other intents’ rewards.

​
Funding

You can fund a vault with an ERC-20 transfer to its computed address. The Portal also provides functions that publish and fund an intent together. Use the vault address returned by the API or the Portal’s intentVaultAddress helper; the address depends on the complete intent and deployment. Funding does not establish who receives a refund. The contract’s default refund recipient is reward.creator, which can differ from the account that sent the tokens.

​
Releasing funds

The Portal controls the vault’s operations:
  • Withdrawal: the configured prover supplies a claimant and destination, and the Portal checks the reward state before releasing funds.
  • Refund: the Portal checks refund eligibility and transfers the listed reward tokens to the refund recipient.
  • Recovery: tokens outside the reward can be recovered through the Portal to the creator.
Expiry makes an eligible reward refundable; it does not send a transaction. Check the refund transaction and asset balances before treating funds as returned.

​
Resource locks

A resource lock reserves assets for a particular operation. Routes vaults implement this pattern with one escrow address per intent. They still depend on shared Portal and vault code, the selected prover, and the token contracts.

​
Next steps

Read Vault architecture for funding checks and refund behavior, or Integrate the Routes API for the application flow.