Tokenized Vault (AIP-4626)
Relevant source files
The following files were used as context for generating this wiki page:
The Tokenized Vault implementation within the Aztec Standards library provides a privacy-preserving adaptation of the ERC-4626 standard, referred to as AIP-4626. It allows users to deposit an underlying asset into a vault in exchange for yield-bearing shares. Both the underlying asset and the vault shares are AIP-20 compliant tokens, supporting the full range of Aztec's private and public transaction capabilities.
The vault is specifically configured using the constructor_with_asset() initializer, which links the vault to an existing AIP-20 token contract. This architecture enables decentralized finance (DeFi) primitives on Aztec, such as lending markets or yield aggregators, while maintaining confidentiality for depositor balances and transaction history.
Sources: README.md:27-32, src/ts/test/utils.ts:168-185
Architecture and Configuration
The Tokenized Vault is an extension of the standard Token Contract. Rather than being a separate contract class, the Token contract is configured at deployment to act as a vault by pointing to an underlying asset.
Deployment Logic
To initialize a vault, the constructor_with_asset method is invoked. This setup requires:
- Asset Address: The address of the AIP-20 compliant underlying token.
- Asset-to-Share Ratio: Initial conversion parameters.
- Minter/Admin: Optional administrative addresses.
Sources: README.md:27-32, src/ts/test/utils.ts:168-185
Inflation Attack Protection
The implementation includes mechanisms to prevent "inflation attacks," where an early depositor manipulates the share price by donating assets to the vault. This is mitigated by depositing an initial amount of assets during deployment, which creates "locked shares" that dilute manipulation attempts. Tests demonstrate that a vault with zero initial deposit is vulnerable, while even a 5-wei initial deposit provides protection.
Sources: src/ts/test/tokenized_vault.test.ts:468-592, src/ts/test/utils.ts:192-214
Core Functionality
The vault supports four primary actions: Deposit, Issue, Withdraw, and Redeem. Each action is implemented in multiple variants to support Aztec's dual state (Private and Public).
Transaction Variants
Each core operation supports combinations of public and private balances for both the asset and the share:
| Operation Category | Methods Supported | Description |
|---|---|---|
| Deposit | deposit_public_to_public, deposit_public_to_private, deposit_private_to_private, deposit_private_to_public | User provides a specific amount of assets to receive shares. |
| Issue | issue_public_to_public, issue_public_to_private, issue_private_to_private_exact, issue_private_to_public_exact | User specifies a exact number of shares to receive, providing the necessary assets. |
| Withdraw | withdraw_public_to_public, withdraw_public_to_private, withdraw_private_to_private, withdraw_private_to_public_exact | User retrieves a specific amount of assets by burning shares. |
| Redeem | redeem_public_to_public, redeem_private_to_public, redeem_private_to_private_exact, redeem_public_to_private_exact | User burns a specific amount of shares to retrieve the underlying assets. |
Sources: src/ts/test/tokenized_vault.test.ts:88-344, benchmarks/tokenized_vault_contract.benchmark.ts:110-188
State Interaction Flow
Interactions with the vault often involve AuthWitnesses (Authorization Witnesses) because the vault contract must be authorized to spend the user's underlying assets.
Key Logic Components
Asset-Share Conversion
The vault maintains the relationship between assets and shares based on the total assets held by the vault contract address and the total supply of shares minted. Yield is simulated in tests by minting assets directly to the vault address, which increases the value of each existing share.
Sources: src/ts/test/tokenized_vault.test.ts:108-112, benchmarks/tokenized_vault_contract.benchmark.ts:50-53
Exact Methods
"Exact" methods (e.g., deposit_private_to_private_exact) are used when the user needs to ensure they receive a specific number of shares or spend a specific number of assets, often involving complex rounding logic to ensure the vault remains solvent and fair to all participants.
Sources: src/ts/test/tokenized_vault.test.ts:346-410, benchmarks/tokenized_vault_contract.benchmark.ts:125-132
Authorization and Security
Because the vault frequently moves funds on behalf of the user, it relies heavily on the SetPublicAuthwit and createAuthWit patterns.
- Public AuthWitness: Used for
transfer_public_to_publiccalls from the user to the vault. - Private AuthWitness: Used for
transfer_private_to_publiccalls, requiring the user to provide a witness that the vault can use within its private execution context.
Sources: src/ts/test/tokenized_vault.test.ts:412-466, src/ts/test/utils.ts:219-245
Conclusion
The AIP-4626 Tokenized Vault standard in Aztec provides a critical bridge for yield-bearing assets in a private environment. By leveraging the flexibility of the AIP-20 Token contract and implementing robust protection against common vault vulnerabilities like inflation attacks, it offers a secure and confidential foundation for decentralized finance on the Aztec Network.
Sources: README.md:27-32, src/ts/test/tokenized_vault.test.ts:590-592