The Superform Protocol draws its power from the ERC-4626 Tokenized Vault Standard. You’ve probably been hearing all the buzz about “over $2.4B TVL in ERC-4626.” But what exactly is it? And how does it enable Superform to provide the best experience for earning yield on your crypto?

ERC-4626 is a standardized interface for tokenized vaults. For reference, ERC-20 and ERC-721 are standardized interfaces for fungible tokens and NFTs, respectively.

“ERC-4626 drastically simplifies the process of building cool and useful applications by decreasing the complexity of integration while improving UX and security.” - 4626 Alliance (ERC4626.info)

At the highest level, a vault is a smart contract that accepts token deposits to perform a service that provides a return (aka ‘yield’) to the depositor. Common services that earn yield include staking, providing liquidity, and lending/borrowing, among many other DeFi activities.

Many separate individuals and entities will deposit into the same vault, pooling their assets. Depositors typically receive “vault shares”: tokens that represent their ownership stake in the underlying assets of the vault and act as a receipt of funds deposited. These tokens—or the assets they represent—typically increase in value over time as the vault generates yield. (Note: Vaults can decrease in value due to defaults, bad trades, impermanent loss, hacks, or other circumstances.) Vault shares are burned when funds are withdrawn from the vault.

Aggregators, also known as yield optimizers, pool capital from multiple investors and put that capital to work within the DeFi ecosystem. Examples include Yearn and Beefy. Investors can deposit their tokens into various vaults that employ strategies and use deposits to stake, farm, provide liquidity, etc., to earn a return. Depositors receive a vault share token representing their share of the vault’s assets. Auto-compounding and socialized gas costs allow these aggregators to earn a greater yield than an individual investor could.

On-chain lending markets such as Aave also utilize vaults. When users deposit assets into an Aave market, they mint aTokens—a tokenized representation of the lender position. The deposited assets are available for borrowers who pay interest on the loan. This interest is distributed as yield to aToken holders. aTokens are burned when withdrawing from Aave.

What about double-sided liquidity pools like we see on Uniswap? If we go back to our high-level definition, then a Uniswap pool would also be considered a vault. Liquidity pools accept token deposits and use those tokens to facilitate DEX swaps. Liquidity providers receive LP tokens as a receipt of their deposit and earn yield from a small fee that the pool takes on every swap.

And what about native asset staking contracts like Lido? These can also qualify as vaults. Lido accepts token deposits in the form of ETH, issues stETH to depositors, uses the deposited ETH to contribute to the security of Ethereum, and earns native staking rewards passed along to stETH holders.

As you can see, vaults come in many forms. Going by our high-level vault definition—a smart contract that accepts token deposits and does something with those tokens to provide rewards to the depositor—the universe of possible vaults is limited only by our imagination. Not all vaults are created the same, however.

Building With Vaults Before ERC-4626:

• Lack of standardization

• Limited composability

• Wasted development resources

• Error-prone = security risk

A lack of standardization limits composability. Suppose someone wants to build an application that aggregates multiple vaults. In that case, they need to build a custom integration for each vault or type of vault because they don’t have the same functionality and won’t necessarily behave in the same way. This wastes development resources and is ultimately an error-prone process, creating additional security risks. Developers are forced to write thousands of lines of unnecessary code, increasing the chance of a security vulnerability and loss of funds.

Benefits of ERC-4626:

• Saves development time, allowing for rapid innovation

• Reduces integration effort, simplifying the process of building cool apps

• Increases security and auditability of smart contracts

• Provides safety and assurance for users

Rather than building custom adapters for each vault implementation, applications can easily build on top of any vault that conforms to the ERC-4626 standard.

To fully appreciate ERC-4626, you must first understand token standards and why they exist.

ERC stands for Ethereum Request for Comments. ERCs are standards that define the behavior and implementation of tokens and smart contracts on the Ethereum blockchain. These standards help ensure that smart contracts remain composable. Examples of popular ERCs include ERC-20 and ERC-721. We will first explore these token standards and use them to help understand ERC-4626.

ERC-20 is a standard for fungible tokens. Some of the main functionalities include:

• Transfer tokens between accounts

• Get the token balance of an account

• Get the token’s total supply

• Approve a third party to spend tokens on your behalf

Diving deeper, we can look at the specific functions that are standard across all ERC-20 contracts. A smart contract is considered ERC-20-compliant if it implements the following functions:

function name() public view returns (string)
function symbol() public view returns (string)
function decimals() public view returns (uint8)
function totalSupply() public view returns (uint256)
function balanceOf(address _owner) public view returns (uint256 balance)
function transfer(address _to, uint256 _value) public returns (bool success)
function transferFrom(address _from, address _to, uint256 _value) public returns (bool success)
function approve(address _spender, uint256 _value) public returns (bool success)
function allowance(address _owner, address _spender) public view returns (uint256 remaining)

The name function is a view function that returns the token’s name (e.g., Wrapped Bitcoin). Similarly, the symbol function returns the token’s symbol (e.g., wBTC). The balanceOf function takes an address as input and returns the ERC-20 token balance of that address. The transfer and approve functions handle the logic for transferring tokens between accounts.

Without the ERC-20 standard, something like Uniswap could not exist! Developers would need to build a custom integration for every token or every set of tokens they wanted to list, and users could not permissionlessly list tokens like they can today. Any ERC-20 token can trade on Uniswap only because it knows that all of these contracts will behave in the same way. If you call a function on one ERC-20 contract, you can expect similar behavior if you call that function on another ERC-20 contract.

ERC-721 is a standard for NFTs. Some of the main functionalities include:

• Transfer tokens between accounts

• Get the token balance of an account

• Get the owner of a specific token

• Approve a third party to spend tokens on your behalf

Without ERC-721, OpenSea could not exist. The vast majority of popular NFT collections are ERC-721s like Bored Apes, Azukis, Pudgy Penguins, and many more. Developers would need to build a custom integration for every collection they want to list, and users could not permissionlessly list NFTs. Lack of standardization is why older NFT collections like CryptoPunks had their own marketplace. It was infeasible to build a permissionless NFT marketplace prior to ERC-721!

ERC-4626 is a standard for tokenized vaults. Some of the main functionalities include:

• Deposit underlying asset

• Withdraw underlying asset

• Mint shares

• Redeem shares

ERC-4626 standardizes the basic functionality for depositing and withdrawing assets, minting and redeeming share tokens, and, most importantly, the accounting that the vault uses to convert between shares and the underlying asset. ERC-4626 inherits from ERC-20, so all of the methods in ERC-20 are present here as well.

function asset() public view returns (address)
function totalAssets() public view returns (uint256)
function convertToShares(uint256 assets) public view returns (uint256 shares)
function convertToAssets(uint256 shares) public view returns (uint256 assets)
function maxDeposit(address receiver) public view returns (uint256)
function previewDeposit(uint256 assets) public view returns (uint256)
function deposit(uint256 assets, address receiver) public returns (uint256 shares)
function maxMint(address receiver) public view returns (uint256)
function previewMint(uint256 shares) public view returns (uint256)
function mint(uint256 shares, address receiver) public returns (uint256 assets)
function maxWithdraw(address owner) public view returns (uint256)
function previewWithdraw(uint256 assets) public view returns (uint256)
function withdraw(uint256 assets, address receiver, address owner) public returns (uint256 shares)
function maxRedeem(address owner) public view returns (uint256)
function previewRedeem(uint256 shares) public view returns (uint256)
function redeem(uint256 shares, address receiver, address owner) public returns (uint256 assets)
function totalSupply() public view returns (uint256)
function balanceOf(address owner) public view returns (uint256)

Here is a brief explanation of these functions, broken down by category:

Vault Details:

• asset → get the address of the underlying asset

• totalAssets → TVL of the vault

Inherited from ERC-20:

• totalSupply, balanceOf, name, symbol, decimals, etc.

How to Deposit into the Vault:

• deposit → market order deposit the underlying asset

• previewDeposit → real-time estimation of the shares that would be received by calling deposit

• mint → limit order deposit the underlying asset

• previewMint → real-time estimation of assets needed to get some amount of shares

How to Withdraw from the Vault:

• redeem → market order withdraw shares

• previewRedeem → real-time estimation of the assets that would be received by calling redeem

• withdraw → limit order withdraw shares

• previewWithdraw → real-time estimation of the shares needed to get some amount of the underlying asset

Pricing Functions:

• convertToShares → price of shares:price of asset

• convertToAssets → price of asset:price of shares

At the time of writing, many vaults are not ERC-4626 compliant. The standard described above cannot yet support every vault implementation. But ERC-4626 has been growing in popularity, and it will eventually support all common yield types, including double-sided LP and native asset staking.

Enter Superform: The Universal Yield Marketplace. The ERC-4626 standard allows for the Superform Protocol to list any vault, similar to how Uniswap can list any fungible token and OpenSea can list any NFT. Investors can view and deposit into any ERC-4626 vault on any EVM chain, and developers can permissionlessly deploy their vaults (as long as the vault is ERC-4626 compliant).

Without ERC-4626, Superform could not exist. If it weren’t for this standard, the Superform Protocol would require many unique integrations to list various vault implementations. This is inconvenient—but not impossible—when we are talking about hundreds of vaults. But what about the not-so-distant future, when the Superform App has tens of thousands of vaults? Building a custom integration for each one would be inconceivable without some form of standardization.

The future of yield is composable, easy to use, and multi-chain: Get ready to experience it through Superform.

Check out the 4626 Alliance website: https://erc4626.info/

In future posts, we will dive into extensions to the ERC-4626 standard, like EIP-7540 and EIP-7535.