RWA Vault (RWAVault)¶

Overview¶

The RWA Vault is RAAC’s on-chain vault that issues an ERC‑20 index token (iRAAC) representing a pro‑rata claim on a diversified basket of real‑world–backed assets held by the vault. Users gain fractional exposure by depositing supported assets via adapters; the vault mints iRAAC shares against the vault’s Net Asset Value (NAV).

Hybrid vault with a unified accounting model
Index token (iRAAC) for simple exposure and composability
Adapter pattern for asset-specific integration
Randomized NFT redemption backed by Chainlink VRF

Purpose¶

Provide single‑token exposure (iRAAC) to a curated basket of on‑chain RWAs
Fractionalize illiquid assets (e.g., NFTs) into fungible shares
Maintain transparent, on‑chain NAV across heterogeneous assets
Enable protocol integrations (e.g., LendingPool collateral) using a single token

Index Token (iRAAC)¶

iRAAC is the vault’s ERC‑20 share token. It represents a claim on the vault’s NAV.
Shares are minted on deposit proportional to the contributed value, and burned on redemptions/administrative burns as applicable.
Price per share equals NAV / total supply and is surfaced via standard share/asset conversions.

Composability

iRAAC is ERC‑20 and can be integrated across DeFi, including being used as collateral within RAAC’s LendingPool and potentially other protocols.

Adapter Model¶

The vault integrates assets through adapters that implement a common interface for deposit, withdrawal, and valuation. This is conceptually similar to IAssetAdapter in the LendingPool, with one critical difference: in the vault, the asset ownership sits with the vault, not with end‑users.

Ownership Model Difference

In the LendingPool, collateral remains user‑scoped. In RWAVault, deposited assets are owned by the vault, and users hold iRAAC shares reflecting proportional ownership of the vault’s NAV.

The vault calls adapters to accept assets, hold custody, and report values.
Only the vault owns assets deposited via adapters; users hold iRAAC instead.
Adapters must be registered first, then may be whitelisted as:
Depositable: public can deposit this asset type through the adapter
Redeemable (ERC‑721 only): asset can be redeemed for iRAAC via the vault’s redemption flow
By default, poolDepositAsset can target any supported (registered) adapter and is used by the Stability Pool for liquidation workflows (see the Liquidations documentation for details).

Adapter Lifecycle & Lists¶

Register adapter: makes an adapter recognized by the vault
Add to Depositable list: enables public deposits through the adapter
Add to Redeemable list (ERC‑721 only): enables redemption of NFTs using iRAAC

Adapter Surface – Key Methods¶

Method	Who Calls	Purpose
`deposit(bytes data, address from)`	Vault	Pull/lock asset from depositor and return its vault‑accounted value
`withdraw(bytes data, address to)`	Vault	Transfer out underlying asset to recipient (vault‑owned asset)
`getAssetValue(bytes data)`	Vault/UI	Return current value for a specific asset key (e.g., an NFT tokenId)
`totalValue()`	Vault/UI	Total value held by the adapter for NAV aggregation
`getAssetType()`	Vault	Declares adapter type, e.g., `ERC721` for redeemables
`getDepositedTokensCount()` (ERC‑721)	Vault	Enumerate deposited NFTs for selection/redemption
`getDepositedTokenAtIndex(uint256 i)` (ERC‑721)	Vault	Fetch tokenId at index for selection/redemption

Deposits, Shares, and Fees¶

The vault follows an ERC‑4626‑like share model, extended to multiple asset types:

Public deposits use depositAsset(adapter, data, receiver, minSharesOut) and are only allowed when the adapter is on the Depositable list.
Stability Pool deposits use poolDepositAsset(...) and can deposit into any supported adapter (used during liquidations and protocol operations).
Shares minted are proportional to the contributed value versus current NAV and total supply (first depositor mints 1:1 when NAV/supply is zero).
A configurable minting fee may apply on public deposits (currently set to 0; consult the Parameters page for the latest value). Net shares after fees are transferred to the receiver.

Current Support

The vault currently supports RAAC NFT via its ERC‑721 adapter. Other assets (e.g., stablecoins) are not supported at this time.

Donation Warning

Any direct donation to the RWA Vault adapter will result in permanent loss of the asset.
The adapter is designed to only accept assets through the vault's controlled deposit mechanisms. Assets sent directly to the adapter address cannot be recovered.

Inflation Attack Prevention

Any attempt to inflate the vault's value by sending assets directly to an adapter is ineffective, because all accounting is handled internally by each adapter and only assets received via the official deposit flow are counted toward the vault's NAV. Directly sent assets are ignored in all calculations, so inflation attacks are prevented.

Withdrawals vs Redemptions¶

iRAAC is not a direct redemption token for arbitrary withdrawals of basket assets.
Redemptions are available only for ERC‑721 assets on the Redeemable list (currently: RAAC NFT). The vault burns shares equal to the NFT’s current value and withdraws that NFT to the redeemer.

Randomized NFT Redemption¶

The vault uses Chainlink VRF to secure an unpredictable random seed after each redemption.
A simple selection algorithm uses the seed to pick among available redeemable NFTs across adapters; uniform or weighted guarantees are not required.
Objective: ensure the next NFT to be redeemed cannot be predicted or influenced.

Why randomness?

We prioritize unpredictability over distributional guarantees. The goal is to ensure the next redeemable NFT cannot be known in advance.

Administrative Flows (Peg Maintenance)¶

Two primary administrative operations support active management without impacting NAV mid‑transaction:

adminDepositAsset(adapter, data, mint=false, ...) – deposit an asset into the vault; optionally skip minting shares (mint=false) if performing multi‑step rebalancing
adminWithdrawAsset(adapter, data, receiver, burn=false, ...) – withdraw an asset from the vault; optionally skip burning shares (burn=false) to pair with a subsequent deposit

Atomic maintenance

Compose admin deposit/withdraw into one transaction when performing reallocations so that temporary mint/burn deferrals do not create transient NAV discrepancies. This keeps NAV stable during peg‑maintenance operations.

Admin Setters & Controls¶

Method	Purpose
`setVRFConsumer(address vrfConsumer)`	Configure Chainlink VRF consumer and initialize the first randomness seed
`setStabilityPool(address stabilityPool)`	Set Stability Pool allowed to interact via pool flows
`setIndexTokenMintingFee(uint256 bps)`	Configure minting fee on public deposits (in basis points)
`setFeeCollector(address feeCollector)`	Route collected minting fees to this collector
`setVRFRequestDelay(uint256 seconds)`	Minimum delay between public VRF reseed requests
`setAllowVRFRequest(bool value)`	Enable/disable public VRF reseed requests
`addManager(address user)` / `removeManager(address user)`	Grant/revoke manager permissions for maintenance flows
`pause()` / `unpause()`	Operational pause controls for safety procedures

For all other public methods and deeper behavioral details, see the RWA Vault Functions page.