> ## Documentation Index
> Fetch the complete documentation index at: https://docs.eco.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Vault

> Per-intent reward storage, funding checks, withdrawals, refunds, and token recovery.

A **vault** holds an intent's source-chain reward. Its management functions accept calls only from the Portal. Applications and solvers use the Portal's methods to fund, withdraw, refund, or recover tokens.

This reference describes the [Routes 2.12.0 Vault](https://github.com/eco/eco-routes/blob/ea5111ba0cd644089d04f922e05a5253dbd21fb8/contracts/vault/Vault.sol) and [IntentSource](https://github.com/eco/eco-routes/blob/ea5111ba0cd644089d04f922e05a5253dbd21fb8/contracts/IntentSource.sol). Check your deployment's version before relying on version-specific behavior.

## Address and deployment

The EVM Portal derives a vault address from the intent hash and its configured vault implementation using deterministic deployment. A vault can receive ERC-20 tokens before it is deployed.

Use `Portal.intentVaultAddress` or the API's `execution.vault`. Do not reuse a vault address for an intent with different route or reward data.

## Funding

The vault can hold the reward's native amount and listed ERC-20 tokens. For token funding through the Portal, the vault pulls the remaining amount using the selected permit or the funder's ERC-20 allowance.

The Portal checks actual balances after funding. When `allowPartial` is false, insufficient funds revert the transaction. Partial funding does not guarantee that a solver will fulfill the intent.

A raw transfer can increase the vault's balance without changing its recorded reward status. `isIntentFunded` includes the balance check needed for this case.

## Withdrawal

The Portal reads fulfillment evidence from `reward.prover` and validates the reward state. It calls the vault with the proven claimant as the recipient.

For each reward asset, the vault transfers up to the smaller of the specified amount and its current balance. A reward record is therefore not a substitute for checking that the vault is funded before fulfillment.

## Refund

The Portal determines refund eligibility. The default recipient is `reward.creator`; an authorized `refundTo` call can choose another recipient. The vault attempts to return its balances of the listed reward tokens and native currency.

In the 2.12.0 implementation, a failed native-token transfer can leave native funds in the vault for a later refund attempt. Check asset balances as well as the refund event before recording a complete payout.

Refunds require a transaction and gas. Reaching the deadline alone does not return assets.

## Token recovery

`Portal.recoverToken` handles ERC-20 tokens that are not part of the reward. It sends recovered tokens to the reward creator. It does not replace the normal refund path for listed reward assets.

## Troubleshooting

* **Funding remains incomplete:** compare each reward amount with the actual vault balance, token allowance, and funder balance.
* **Withdrawal is unavailable:** check source-chain proof availability and whether the reward is already withdrawn or refunded.
* **Refund has not arrived:** verify eligibility, the submitted transaction, the configured recipient, and balances for each asset.
* **Unexpected tokens remain:** distinguish listed reward assets from unrelated tokens before choosing refund or recovery.

## Next steps

See [Portal](/routes/architecture/portal) for entry points and [Vaults and resource locks](/concepts/vaults) for the conceptual model.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.