Solana Needs Something Like ERC4626 Vaults

TL;DR ⚡

• What you’ll learn: Why Solana needs a standardized vault interface (deposits, redemptions, shares), what ERC4626 solved on Ethereum, and how a Solana vault standard can power tokenized funds and RWAs (including NAV-based flows).

• Why it matters: Today, every team ships a custom vault, creating fragmented integrations, weaker composability, duplicated audits, and slower (riskier) institutional adoption.

• Exo Edge: The Solana Foundation asked us to help explore a canonical vault standard, designed to be plug-and-play for issuers and composable with institutional primitives like sRFC 37 (Token ACL), so teams can launch faster with fewer bespoke contracts.

The Problem

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 Exo Tech, along with other partners, is investing time into exploring a standardized vault program implementation.

What ERC4626 Is & Why It Works

Ethereum has a standard interface for vaults, known as . This interface defines the required methods, events, and state of a vault smart contract. Every EVM vault smart contract can then adhere to this standard so that users and clients easily know that they may call the deposit method to send assets to the vault and receive shares.

    function deposit(uint256 assets, address receiver) public virtual returns (uint256 shares) {
        // Check for rounding error since we round down in previewDeposit.
        require((shares = previewDeposit(assets)) != 0, "ZERO_SHARES");

        // Need to transfer before minting or ERC777s could reenter.
        asset.safeTransferFrom(msg.sender, address(this), assets);

        _mint(receiver, shares);

        emit Deposit(msg.sender, receiver, assets, shares);

        afterDeposit(assets, shares);
    }

While the above code shows an implementation of a deposit function adhering to the ERC4626 interface, it is important to note that ERC4626 does not implement or require specific logic. This will become an important distinction as we discuss the details about a vault standard on Solana. The interface alone is incredibly valuable as it makes it very easy to compose smart contracts. Many of the institutions we have worked with typically use ERC4626 for handling their fund subscription and redemption flows in order to make it easy to integrate with downstream protocols.

How Vaults Enable RWAs

RWAs are foreign to the blockchain and require interaction with external systems (e.g., banks, exchanges). This requires RWA issuers to collect capital onchain and then issue a tokenized representation of the offchain asset(s). Vaults are core to this as they contain the logic for capital formation (and redemption). The vault also contains the net asset value (NAV), which determines the exchange rate for shares and the assets (stablecoins) accepted. Every RWA issuer needs some form of a vault, whether it’s a standard or implemented in their own custom smart contract.

For example, let’s look at a tokenized money market fund (MMF). The fund manager wants to accept dollar-backed stablecoins (USDC) and issue MMF tokens to their investors to represent their ownership in the fund. The investor must deposit the stablecoin into the issuer’s smart contract. The manager may update the NAV so that the onchain value accurately matches the offchain before the investor can claim their MMF shares. All of this logic can be implemented at the vault level, as is the case with Ethereum and ERC4626 and ERC7540.

The above example looks like the following:

With a standard vault implementation, most of this would become plug-and-play for the fund manager. This significantly reduces the engineering effort required by issuers and drastically improves security as the vault implementation becomes battle-tested across multiple products.

Why We’re Building This

At Exo Tech, we’ve building 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 discuss what it would take to build core primitives for these components, making deployment on Solana easier and more secure.

Vaults are just one piece of the puzzle. , the Token Access Control List (ACL), standard that standardizes a pattern for handling KYC of a Token without compromising composability as much as Transfer Hooks. These initiatives together enable KYC’d tokens with subscription/redemption capabilities without the need to deploy custom smart contracts.

What’s Next?

We’re just getting started on this initiative and have some preliminary designs. A working group is being set up with RWA issuers, DeFi protocols, and others to integrate such a standard and increase the amount of feedback. There isn’t a firm timeline, but we would like to have all feedback in before the end of Q1 so that Q2 can be spent hardening the implementation and enabling integration testing.

If you would be a good fit for the working group, please reach out to the exo team at founders@exotechnologies.xyz so that your feedback can be included.