sRFC 40: Vault Standard Program

[LHFVII]

Summary

We aim to create a standard factory program that handles many of the same use cases as ERC 4626 and 7540. This is an important primitive that would make it easier and safer for others to develop on top of. By handling the subscription/redemption process within a standard implementation, we can promote more lindiness of critical Solana infrastructure, while still allowing innovation on top.

Background

RWA issuers build custom smart contracts and infrastructure to support their tokenization efforts on Solana. Every product is slightly different, but the high level requirements are all very similar. Tokens need KYC checks, products should have role based access control, and investors should be able to subscribe and redeem from the RWA. This led us to discussing what it would take to build core primitives for these components to make it easier and more secure to deploy on Solana.

Vaults are just one piece of the puzzle. [sRFC 37](https://forum.solana.com/t/srfc-37-efficient-block-allow-list-token-standard/4036), the Token Access Control List (ACL), standardizes a pattern for handling KYC of a Token without compromising composability (i.e. an improvement to Transfer Hooks). These initiatives together enable KYC’d tokens with subscription/redemption capabilities without the need to deploy custom smart contracts.

Institutions and enterprises that want to manage tokenized funds and other assets require functionality akin to vaults. Vaults handle deposits and redemptions into managed strategies, such as depositing stablecoins to receive shares in a fund. As it stands today, Solana has no standardization for vaults and every team has been left to develop their own implementation. This leads to more integration work for clients, more engineering work for those developing the product, and ultimately leads to less secure Solana programs as the surface area for vulnerabilities increases. This is why we are presenting this standardized vault program proposal.

After several working group sessions and incorporating feedback from the community, we've reached a clear consensus that asynchronous vaults provide significantly more value for immediate use cases (especially RWA, funds, and strategies involving off-chain or delayed settlement) compared to purely atomic ones. As a result, we've decided to prioritize building the Async Vault program first. The intention is for this to serve as a high-quality reference implementation rather than a canonical one-size-fits-all program. This approach allows us to ship faster and gather real usage feedback sooner than later.

Key Changes from the Original Proposal

• Separate Programs for Atomic and Async: Instead of a single program with an "Async Vault Extension" layered on top of an atomic base, we now recommend splitting them into distinct programs. They can (and should) share common code/libraries where it makes sense, but this separation reduces complexity in the hot paths and makes each easier to audit, deploy, and maintain.
• Async-First Design: The Async Vault architecture has been fully fleshed out, drawing inspiration from ERC-7540 while adapting it to Solana's native patterns.

Core Async Vault Architecture Highlights

• State:
  • AsyncVault account with new fields like pending_vault (shared escrow for unclaimed deposits/redemptions), nav, async_inflows/ async_outflows flags, total_asset_balance (virtual balance accounting for authority withdrawals), and TLV-based extensions.
  • Request accounts tracking RequestType (Deposit/Redeem), RequestState (Pending/Claimable/Rejected), amount, price (NAV snapshot when Vault Authority approves), owner, etc.
• Key Instructions:
  • CreateAsyncVault / InitializeExtension/ InitializeAsyncVault (finalizes config and locks further extensions).
  • RequestDeposit / RequestRedeem (assets move to a pending_vault) and wait for Vault Authority to approve
  • ApproveRequest / RejectRequest (authority-only; rejects return assets/shares to user).
  • Claim (called by user to finalize; mints shares for deposits or transfers assets for redemptions; supports partial claims).
  • Additional instructions: CancelRequest, WithdrawAssets (authority can pull assets for off-chain use), UpdateNav, authority transfer flow, etc.
• Extensions (modular via TLV data):
  • Order Queue - Enforces FIFO Deposit and Redemption requests
  • Instant Share Minting - Small deposits (set via authority) can be executed synchronously
  • Pausable Subscriptions/Redemptions - Manual pausing or resuming of either subscriptions or redemptions allowing authority to enact request windows
  • Subscription Lock-Up Period - Prevent users from claiming shares until time after approval has elapsed
  • Partial Subscriptions/Redemptions - Enables the authority to partially fill a User’s request as long as it meets the User’s minimum fill amount

This design supports many of the requirements for RWA issuers and other vault strategies.

Legacy Proposal (This was the original proposal which has been deprecated)

A new program that takes inspiration from [ERC4626](https://eips.ethereum.org/EIPS/eip-4626) and other vault standards as well as the lessons from Token2022, with the intent to be highly customizable by supporting the most common use cases available as extensions.

The creation of a Vault does not create a new Mint for the share token, but rather accepts a pre-configured mint as the share token. This decouples the Vault program from future Mint configuration combinations significantly reducing complexity during Vault creation as well as reducing the likelihood of required program upgrades with new Token Extensions in the future.

As a corollary, the program will not initialize token accounts nor enforce ATAs. The user/admin must initialize in an instruction prior to interacting with the vault program. This promotes maximum flexibility for those that want to use non ATAs.

The base functionality is the Atomic Vault. The logic and features are then configurable using extensions such as the following non-exhaustive list:

• Deposit Fees Extension:

Vault authority can configure percentage or fixed fees to be collected when a deposit is made.

• Withdraw Fees Extension:

Vault authority can configure percentage or fixed fees to be collected when a withdraw is made.

• Deposit Hook Extension:

It extends the deposit functionality allowing to interface the Vault Program with a custom hook program that provides custom logic with downstream protocols. For example, a vault that would like to deposit tokens atomically into a borrow/lend protocol. See the hook interface below for more.

• Withdraw Hook Extension:

It extends the withdraw functionality allowing to interface the Vault Program with a custom hook program that provides custom logic with downstream protocols. For example, a vault that would like to withdraw previously deposited tokens atomically from a borrow/lend protocol. See the hook interface below for more.

• Investor Subscription Limits Extension:

Limits the total amount a user can have deposited into a vault. Important for vaults that must adhere to strict regulatory requirements.

Composability

One of our goals with this program is to make it very easy to compose smart contracts so that it allows for greater granularity for the interested parties. A caveat regarding stack limit, this proposal is built for the network when the CPI call stack limit is greater than 4. We acknowledge that the nested hook pattern would very quickly reach the current CPI depth limit.

Specification

Note that this specification is only for the purpose of this discussion and is not final. It does not take into account optimizations that would be present in a production version of the program.

Accounts

/// The fee types:
/// FixedAmount: a fixed fee is applied (ex 0.1 asset)
/// Percentage: the fee is a % of the transfer amount
pub enum FeeType {
		NoFee,
		FixedAmount {
			amount: u64,
		},
		Percentage {
			bps: u16,
		},
}

pub enum VaultExtensions {
	pub Async(AsyncVault),
	pub DepositFees,
	pub WithdrawFees,
	pub DepositHook,
	pub WithdrawHook,
	// And more
}

/// Core state of the Vault account necessary for common
/// logic across configuration types.
/// PDA Seeds: ["vault", share_mint.key()]
#[account]
pub struct Vault {
		pub asset_mint_address: Pubkey,
    /// share mint address
    pub share_mint_address: Pubkey,
    /// vault_token_account
    pub vault_token_account: Pubkey,
    /// authority that can sign permissioned instructions
    pub authority: Pubkey,
    /// initial price
    pub initial_price: u64,
    /// paused
    pub paused: bool,
    /// max balance allowed in vault
    pub vault_asset_cap: u64,
    /// extensions for optional features
    pub extensions: Vec<VaultExtensions>
}

Instructions (Base case for atomic vault)

Create Vault:

• Creates the base vault account

Initialize [EXTENSION]:

• Initialization instruction for the given extension

Initialize Vault:

• Prevents further extensions to be initialized

Deposit:

• The user sends amount of assets to the vault and share tokens are minted to the user.

Mint:

• The user wants to mint amount shares, and transfers the required amount of assets

Withdraw:

• The user wants to withdraw amount assets, and burns the required amount of shares

Redeem:

• The user sends amount shares, and receives the computed amount of assets in return

Price Mechanism

Note: this price mechanism is for Atomic vaults only. The initial price is set during vault creation and cannot be updated.

If the share supply is 0 then this is how price is calculated:

$$ (initialPrice)*(assets)/(reserveBalance) $$

Otherwise:

$$ (shareSupply)*(assets)/(reserveBalance) $$

Deposit & Withdraw Custom Logic

A very common use case is adding custom logic after a deposit or withdraw instruction has been executed and the user's tokens have been transferred. This is necessary for integration with downstream protocols. In order to handle this use case we have decided to follow the ExtraAccountMeta and a “Hook” program pattern.

Hook Program Interface

/// Vault program CPIs to `execute_deposit` during Deposit/Mint instructions
/// after approving the Hook program's PDA as a Token Account delegate.
/// `execute_deposit` may then transfer to or from the Vault's Token
/// Account as necessary for the desired custom logic.
pub fn execute_deposit(_ctx: Context<Deposit>) -> Result<()>

/// Vault program CPIs to `execute_withdraw` during the Withdraw/Redeem
/// instructions.
/// `execute_withdraw` may then perform custom logic as necessary. 
pub fn execute_withdraw(_ctx: Context<Withdraw>) -> Result<()>

/// Reads required Account states and computes the NAV for the vault.
/// This instruction should not mutate any state.
/// Vault program CPIs to `get_nav` during all instructions where
/// the NAV (aka exchange rate) is required.
pub fn get_nav(_ctx: Context<GetNav>) -> Result<u64, i64>

Only the Vault Standard Program is able to interface with the hook program. When interfacing with downstream protocols the hook program will relay the vault as the user of that vault. For instance: When depositing in Protocol X, the vault authority will be the “user” who is depositing into it.

NAV Calculation:

NAV calculation logic and thus Update Authority is up to the developer of the Hook program.

One way to implement it would be:

The hook program will read downstream protocol values, perform calculations, and return NAV in the get_nav instruction. get_nav is a readonly instruction that is permissionless. The Vault program will use the returned NAV to calculate the amount of assets based on the given amount of shares or vice versa.

[stevewhyman-fulminata]

Really interesting initiative — this addresses a real gap. A few things that came to mind from the institutional side.

Legal Title. When assets pool inside a vault, the question of where legal title sits becomes non-trivial. Different jurisdictions treat this differently, and the answer affects everything from insolvency treatment to regulatory reporting. Something to think about as the standard matures.

Beneficial Ownership. FATF Recommendations 16 and 24 create obligations around identifying beneficial owners of financial arrangements. How that interacts with vault share tokens — particularly if they circulate on secondary markets — is an open question that will come up in institutional due diligence.

The Register. Regulated funds maintain a register of holders via a transfer agent. The relationship between on-chain vault state and that register is undefined. There's a design space here that's worth exploring.

NAV. For regulated funds, NAV carries legal weight — it's not just a price feed. The governance of who controls the oracle and under what methodology will matter.

Pending Redemptions. With async vaults, the status of a share token during a pending redemption request creates some ambiguity around claims and transferability.

Ownership Through Composability. The hook architecture is powerful. The question is whether ownership integrity can be maintained as vault shares move through downstream protocols — lending, collateral, derivatives.

None of these are blockers — the extension model gives room to address them. But they're areas where the institutional world will have strong views, and probably worth a deeper conversation. Happy to explore any of these further with anyone interested.

[alessandromaci]

The proposal looks solid overall. Here there are a few feedback from a vault integrator point of view:

• referral logic is missing. It creates a new revenue stream for the integrators and it will be great to see this option mentioned in the proposal from day-1

• the challenge with async vaults (some erc vaults split deposit and mint shares by couple of hours in between) is to track the status of the async request and safely trigger the second transaction. I wonder if there is a way for the protocol to help us handling these use-cases without only relying on our backend for monitoring.

• another common use-case we deal with is swap + deposit. To guarantee atomicity, we would like to deal with the two instructions in the same transaction. It would be great to have an extension swap + vault deposit that we know for sure will fit within the transaction limits.

[Taylor123]

@stevewhyman-fulminata thanks for the comments! These are very helpful as we're architecting the Asynchronous vaults, which will be primarily used for RWAs.

The Register. Regulated funds maintain a register of holders via a transfer agent. The relationship between on-chain vault state and that register is undefined. There's a design space here that's worth exploring.

This is an interesting point worth discussing. Would it suffice to store this information offchain? I imagine most, if not all, regulated issuers will need to maintain KYC/KYB records and associate them to a wallet address. With that information, they could index deposit events and shares held by the wallet to build an offchain registry. This could be reconstructed and verified by anyone.

Pending Redemptions. With async vaults, the status of a share token during a pending redemption request creates some ambiguity around claims and transferability.

When a User requests to redeem their shares for tokens, the shares are escrowed by the Vault. So they are unable to transfer the shares after making such a request unless they cancelled the requested claim. Let me know if that doesn't make it more clear.

Ownership Through Composability. The hook architecture is powerful. The question is whether ownership integrity can be maintained as vault shares move through downstream protocols — lending, collateral, derivatives.

I suspect it will break ownership integrity. Hooks will be used for synchronous vaults only and thus are unlikely to be used for regulated RWAs (note this is an assumption and we welcome feedback to disprove this).

[Taylor123]

@alessandromaci appreciate the feedback!

referral logic is missing. It creates a new revenue stream for the integrators and it will be great to see this option mentioned in the proposal from day-1

After discussion with the working group, we've decided referrals won't be a priority. Primarily for the reason that it's very contextual to the product and could be built on top of the Vaults. There are many offchain providers that have referral implementations that meet needs for many of the initial use cases. Implementing some of these referral methods onchain would be very difficult and increase the complexity of an already complex program. Some of the RWA design partners have indicated that referrals are preferred offchain as they may be private deals not available to all depositors.

To guarantee atomicity, we would like to deal with the two instructions in the same transaction. It would be great to have an extension swap + vault deposit that we know for sure will fit within the transaction limits.

This likely doesn't need to be a separate extension, but please correct me if I'm mistaken. Rather, the client constructing the transaction can include swap & deposit instructions in the same transaction. Or in the case the deposit needs to know the exact amount received, build a custom program that wraps both to get an accurate delta from the swap. Ultimately, swapping should sit outside of the Vault since it's not a core feature.

[kauenet]

Great initiative, over the past couple at of months @solanabr Superteam Brazil we converged on the same reasoning and built out a full implementation suite we're calling the Solana Vault Standard (SVS). What we have today:

• A couple different ERC-4626 equivalent tokenized vaults with virtual share offset for inflation attack
  protection, vault-favoring rounding, and configurable asset token support (SPL Token and Token-2022).
• Vaults with streaming yield, native SOL vault wrapper
• Allocator vaults — a meta-vault that deposits into child vaults via CPI
• ERC-7540 equivalent async vault with request/fulfill/claim lifecycle and granular operator
  permissions + credit markets vault with oracle NAV pricing + Tranched (structured) vault with waterfall yield distribution
• Composable, feature-gated modules that plug into any vault variant — fees (entry/exit/management/performance),
  deposit caps (global and per-user), share locks, access control (whitelist/blacklist via merkle roots), and
  rewards. Each vault opts in via Cargo features and wires hooks through remaining_accounts.
• TypeScript SDK with PDA helpers and typed interfaces for each vault variant
• CLI for all vault operations (creation & lifecycle)

The repo is at https://github.com/solanabr/solana-vault-standard. Happy to align on interface standardization as our implementations could serve as reference or starting points for whatever standard comes out of this discussion.

[kauenet]

Our implementation at @SuperteamBR isn’t really focused on defining a single, generalized standard. But after reviewing both approaches, a few points stood out that are worth bringing into this discussion.

Design tradeoffs to consider:

• CPI hooks vs. module hooks via remaining_accounts
  The CPI hook pattern is clean, but it hits stack depth limits pretty quickly, as noted in the proposal. We ended up going with feature-gated modules that operate through remaining_accounts. This avoids the CPI depth issue entirely while still enabling composable logic (fees, caps, locks, access control).

• Decoupled share mint vs. program-owned mint
  Allowing a pre-existing mint is flexible, but it also introduces risk, since an external party could retain mint authority and inflate supply outside the vault’s control. In our case, the vault PDA owns the mint from initialization. It’s less flexible, but safer by default. If the standard supports decoupled mints, it should at least require mint authority to be transferred to the vault PDA during initialization.

• Inflation attack protection
  The current pricing formula (shareSupply * assets / reserveBalance) is vulnerable to first-depositor manipulation, which is a known issue from ERC-4626. We mitigate this using a virtual offset approach:
  shares = assets * (total_shares + 10^offset) / (total_assets + 1)
  The standard should either mandate a mitigation like this or clearly flag it as a required consideration.

• Rounding direction
  The proposal doesn’t specify rounding behavior, which is a problem. Without a convention, implementations will diverge, and some may round in favor of the user in ways that are exploitable. A sensible default would be:

  • floor on deposit/redeem (user gets slightly less)
  • ceiling on mint/withdraw (user pays slightly more)

I believe It’s also worth asking whether async/NAV-based vaults (ERC-7540 style) should live in the same standard or be split into a separate SRFC. The request/fulfill/claim lifecycle, operator delegation, and oracle pricing are fundamentally different from atomic deposit/redeem flows.

Happy to share more details from our implementation if useful.

[LHFVII]

Hey @kauenet! Appreciate your feedback.

Decoupled share mint vs. program-owned mint
Yes once the vault is created the authority is transferred to the vault PDA.

Inflation attack protection
This was also a common finding in audits so we account for that in the our implementation of our deposit calculation formula

Rounding direction
We round in favor of the protocol/vault (rounding down shares in case of deposits, and rounding up shares in case of burning).

CPI hooks vs. module hooks via remaining_accounts
This is a very interesting point, our premise is that CPI stack depth will be increased but right now we are checking alternatives with remaining accounts as well.

Finally, we are still wondering whether we want a single Atomic Vault with Async Extensions or as you mentioned a separate sRFC for it.

[tiago18c]

Have there been any considerations to alternatives on ExtraAccountMeta account dependency declaration? This was one of the most criticized parts of Token-ACL, however it quite flexible in declaring the account dependencies if you get over the DX burden.

Even though CPIs can be expensive for read purposes, I would still recommend adding instructions that mimic the maxMint, maxDeposit, maxWithdraw, maxRedeem, at the very least they should help with parity against ERC4626.

The implementation not directly dealing with mint and token account creation is actually a great step in decreasing program maintenance. But this should come with libraries and UIs that aid in vault creation.

[Taylor123]

Other routes have been considered, but none have the benefit of allowing offchain clients to be able to construct the transaction without additional context. Without an onchain representation of the accounts needed for an unknown CPI, external clients (i.e. wallets) are unable to construct a proper TX. As you know, this is one of the more difficult aspects of defining an generic interface with dynamic account lists.

[LHFVII]

The scope of the proposal has been shifted to an async vault. Therefore, we have edited the original document to take into account that.

[BlocksOnAChain]

🚀 The reference implementation for the vaults program is now open source - go check it out: github.com/exo-tech-xyz/vault and use it to build cool stuff.