ERC-7621 Token Standard Explained: The Technical Deep Dive

We spent over a year trying to make basket tokens work with existing Ethereum standards before accepting that we needed to write a new one. ERC-20 could not represent a token that holds other tokens inside it. ERC-1155 got closer but forced every basket into the same contract, killing composability. Wrapping everything in a custom vault contract worked technically but meant no wallet, marketplace, or lending protocol would know what to do with it.

ERC-7621 is the result of that process. It extends ERC-721 (the NFT standard) with a set of functions for managing a weighted portfolio of ERC-20 assets entirely onchain. If you already know what basket tokens are, this is where we break down how they actually work at the contract level, including the tradeoffs we made and why.

Why Not Use an Existing Standard?

We tried. Here is what we ran into:

ERC-20 is a single-asset token. There is no concept of "this token contains other tokens." You could deploy a vault contract and issue ERC-20 receipt tokens, but the receipt token has no standard way to describe its composition. Wallets cannot show what is inside it. Protocols cannot programmatically inspect the underlying assets. You end up building everything custom.

ERC-1155 supports multiple token types in one contract, but it was designed for batch operations across distinct token IDs, not for a single token that wraps a weighted portfolio. It also forces all baskets into one contract, which creates shared-state risks and kills the modularity we needed.

Custom vault contracts work but produce fragmented ecosystems. Every team reinvents asset registration, weight management, proportional minting, proportional burning, and fee accrual. Every implementation is different. No common interface means no generic tooling.

ERC-7621 fills that gap. It defines a common set of functions that all basket tokens share, so any wallet, DEX, or protocol that supports the standard can work with every BSKT built on it.

Core Architecture

An ERC-7621 token is, first and foremost, a valid ERC-721 token. Each BSKT is a non-fungible token with a unique token ID. It supports transfers and approvals just like any NFT. You can send it to any Ethereum address, trade it on any NFT marketplace, or use it in any protocol that supports ERC-721 tokens. Nothing about the basket functionality breaks standard ERC-721 compatibility.

On top of that ERC-721 foundation, ERC-7621 adds several distinct layers:

• Asset registry. The contract maintains an ordered list of underlying ERC-20 token addresses and their corresponding weights. This registry defines what the basket contains and in what proportions.
• Minting mechanism. Users deposit the underlying tokens in the correct proportions to mint new BSKT tokens. The contract enforces that deposits match the basket's weight configuration exactly.
• Burning mechanism. Holders burn their BSKT tokens to withdraw the underlying assets proportionally. This guarantees that BSKTs are always fully redeemable.
• Rebalancing. The basket creator or designated manager can adjust the target weights of underlying assets, changing the basket's composition over time.
• Fee collection. Management fees are encoded at the contract level at creation time and accrue continuously to the basket creator.

Each of these layers has its own set of interface functions, events, and invariants. The sections below walk through them one by one.

Design Tradeoffs We Made

Every standard is a set of tradeoffs. Here are the ones we chose deliberately:

NFT-based, not fungible. We built on ERC-721 instead of ERC-20. This means each basket is a unique, non-fungible token. The upside is that each basket can have its own composition, manager, and fee structure without needing a factory pattern that deploys new ERC-20 contracts per basket. The downside is that BSKTs do not plug directly into AMMs or lending protocols that expect fungible tokens. We think the uniqueness is worth it because basket tokens are inherently unique (different compositions, different managers), but this is a real constraint that affects DeFi integrations today.

Strict proportional minting. The contract requires exact proportional deposits. We considered allowing partial mints (deposit Token A now, Token B later) but rejected it because partial state creates under-collateralization windows. Strict minting is a worse UX for the minter but a hard safety guarantee for every holder.

Immutable fees. The management fee is locked at deployment. We debated making it adjustable with a timelock, but immutability is simpler and removes an entire class of governance attacks. If a manager wants different fees, they deploy a new basket. This is more expensive but more honest.

The Minting Process

Minting is how new BSKT tokens come into existence. When a user wants to mint, they specify how many BSKT tokens they want to receive. The contract then calculates exactly how much of each underlying token needs to be deposited, based on the basket's current weight configuration.

Here is what happens step by step:

1. The user approves the BSKT contract to spend the required amounts of each underlying ERC-20 token.
2. The user calls the mint function, specifying the desired quantity of BSKT tokens.
3. The contract calculates the required deposit for each underlying token based on the basket weights and the requested mint amount.
4. The contract transfers the underlying tokens from the user into the basket contract using transferFrom calls.
5. The contract mints the corresponding BSKT tokens to the user's address.

The proportions are strict. If a basket is configured as 50% Token A and 50% Token B, the user must deposit exactly the right amount of both tokens. The contract will revert if the proportions do not match. There is no partial minting or rounding that could leave the basket under-collateralized.

After minting, the underlying tokens sit inside the basket contract. They are not lent out, staked elsewhere, or used for anything else. They back the BSKT tokens directly and can be reclaimed at any time through burning.

The Burning Process

Burning is the reverse of minting. Any BSKT holder can burn their tokens at any time and receive the underlying assets back in proportion to their share of the total supply.

The process works like this:

1. The holder calls the burn function, specifying how many BSKT tokens to burn.
2. The contract calculates the holder's proportional claim on each underlying asset. If you hold 1% of the total BSKT supply and burn all of it, you receive 1% of every underlying token held by the contract.
3. The contract burns the BSKT tokens, reducing the total supply.
4. The contract transfers the proportional share of underlying tokens to the burner's address.

This mechanism ensures that BSKTs are always fully backed. There is no scenario where a BSKT exists without the underlying tokens to support it. The contract cannot mint tokens out of thin air, and it cannot prevent redemptions. This is enforced at the smart contract level, not by policy or governance decisions.

The guaranteed burn-and-redeem function is also what keeps BSKT market prices anchored to their net asset value. If a BSKT trades below the value of its underlying tokens on an NFT marketplace, arbitrageurs can buy the BSKT cheaply and burn it for the more valuable underlying assets, pocketing the difference and pushing the price back up.

Rebalancing

A basket's composition does not have to be static. The basket creator (or a designated manager address) can trigger a rebalance to adjust the target weights of the underlying assets. This is how active portfolio management works onchain.

When a rebalance is triggered, the contract updates its internal weight configuration. This changes the proportions required for future mints and the proportions returned on future burns. The assets already held inside the contract don't get swapped or moved during a weight change. Instead, the new weights take effect for all subsequent minting and burning interactions.

For example, suppose a basket starts with a 60/40 split between Token A and Token B. The manager decides conditions warrant a shift to 50/50. After the rebalance call, any new minting will require equal amounts of both tokens. The actual token holdings in the contract will gradually align with the new weights as new mints and burns occur over time.

Rebalancing is permissioned. Only the address designated as the basket manager can call the rebalance function. This prevents random addresses from altering a basket's strategy. The manager address is set at basket creation and is visible onchain, so holders always know who controls the composition. This creates accountability: if a manager makes poor rebalancing decisions, holders can simply burn their BSKTs and exit.

Fee Mechanics

Management fees are one of the most important features of ERC-7621, because they create an economic incentive for skilled managers to build and maintain quality baskets.

The fee percentage is set when the basket is created and encoded directly in the smart contract. It cannot be changed after deployment. This gives holders certainty about what they are paying. There are no surprise fee increases, hidden charges, or manual invoicing.

Fees accrue continuously over time based on the assets held in the basket. The accrual happens automatically through the contract's internal accounting. When fees are collected, the basket creator receives their share without any off-chain payment processing or dispute resolution. Everything runs through the smart contract code.

In practice, the contract tracks when fees were last collected and the current total supply. When a collection is triggered (which can happen during mints, burns, or explicit collection calls), the contract calculates how much time has passed and mints new BSKT tokens to the manager's address. This means the fee is paid through dilution rather than direct deductions from the underlying assets. Economically, it's equivalent to charging a percentage fee on assets under management.

The model is straightforward: the more assets a basket attracts, the more fees the creator earns. This aligns incentives cleanly. Creators are motivated to build baskets that people actually want to hold, which means choosing good assets, setting sensible weights, and rebalancing when market conditions call for it.

Composability with DeFi

This is where the design of ERC-7621 pays off the most. Because every BSKT is a fully compliant ERC-721 token, it works with any protocol that supports NFTs. No special integration is required. The basket functionality is invisible to external contracts that only care about the ERC-721 interface, while the underlying ERC-20 tokens inside the BSKT remain fully accessible through the standard's dedicated functions.

Here are concrete examples of what this enables:

Trading on NFT marketplaces and DEXs. BSKTs can be listed and traded on any NFT marketplace or platform that supports ERC-721 tokens. This gives baskets liquidity and allows anyone to buy exposure to a basket's strategy without minting directly. Because BSKTs are always fully backed by their underlying ERC-20 tokens, buyers can verify onchain exactly what they are getting.

Collateral in NFT-compatible lending. A BSKT token can be used as collateral on NFT lending protocols. Because the basket is always fully backed by its underlying ERC-20 tokens, it has intrinsic and verifiable value that makes it suitable as collateral. A lender can verify onchain exactly what backs the BSKT and price the collateral accordingly.

Yield strategies. BSKTs can hold yield-bearing ERC-20 tokens like stETH, rETH, and sDAI inside them, creating a diversified yield portfolio in a single NFT. The underlying tokens continue to accrue value while held inside the basket, giving the BSKT holder broad yield exposure through one position.

Baskets of baskets. Since BSKTs can contain any ERC-20 tokens, and since wrapper mechanisms can bridge between token standards, layered portfolio structures are possible. A higher-level basket could gain exposure to other basket strategies as components. This allows for sophisticated portfolio architectures, all managed through the same standard interface.

This composability is not a theoretical benefit. It works today with existing infrastructure because ERC-7621 was designed as a strict extension of ERC-721, not a replacement for it. Any platform that supports NFTs can work with BSKTs, while the underlying ERC-20 tokens inside each basket remain accessible through the standard's minting and burning mechanics.

Security Considerations

The security model of ERC-7621 is built on a few key invariants that the contract enforces at all times.

Full backing. The contract cannot mint BSKT tokens without receiving the corresponding underlying assets. There is no credit, no fractional reserve, no unbacked issuance. Every BSKT in circulation is matched by real tokens sitting in the contract.

Guaranteed redemption. Any holder can burn their BSKTs and receive underlying tokens at any time. The contract cannot block redemptions or freeze assets. This is a hard guarantee enforced by the code itself.

Transparent composition. The asset registry and weights are readable onchain by anyone. There are no hidden assets, off-chain reserves, or opaque accounting. Anyone can verify exactly what backs a BSKT at any block height.

The smart contracts are open source and verifiable. As with any smart contract system, users should review audit reports and understand the specific implementation they are interacting with before committing capital. The contract code is the final source of truth for how a basket behaves.

What Implementers Should Watch Out For

If you are building on ERC-7621 or integrating with baskets, these are the things that have tripped up other teams:

• Token approval sequencing. Minting requires approvals on every underlying ERC-20 before the mint call. If your frontend batches these transactions, make sure all approvals confirm before submitting the mint. A reverted mint after partial approvals wastes gas and confuses users.
• Rebasing tokens. ERC-7621 tracks fixed balances. If you include a rebasing token (like stETH) as an underlying asset, the basket's internal accounting will not reflect the rebasing. Use the wrapped, non-rebasing version (wstETH) instead.
• Fee-on-transfer tokens. Some ERC-20 tokens deduct a fee on every transfer. The basket contract expects to receive the exact amount it requested via transferFrom. If a token skims 1% on transfer, the proportions will be off and the mint may revert or create accounting mismatches.
• Low-liquidity underlying tokens. The standard does not check liquidity. A basket can include a token with $10K daily volume. That basket will technically work, but minting and burning will hit severe slippage. Check the liquidity of every token before deploying.
• Manager key security. The manager address controls rebalancing. If this is a single EOA and it gets compromised, the attacker can rebalance the basket into worthless tokens. Consider using a multisig for the manager address on any basket with meaningful TVL.

Future Development

ERC-7621 establishes the core standard, but there is a clear path for extending what basket tokens can do.

Cross-chain BSKTs. Today, baskets operate on a single chain. Future implementations could allow baskets that hold assets across multiple networks, using bridge infrastructure to maintain the backing guarantees. A basket holding tokens on Ethereum, Arbitrum, and Base simultaneously would give users cross-chain diversification through a single token.

Automated rebalancing triggers. Currently, rebalancing is a manual action taken by the basket manager. Future versions could integrate with onchain automation services (like Chainlink Automation) to trigger rebalances based on predefined conditions. For instance, a rebalance could fire automatically when an asset's actual weight drifts more than 5% from its target.

Oracle integration for market-cap weighting. Many traditional index funds weight their holdings by market capitalization. By integrating price oracles, baskets could automatically adjust their weights to track market-cap-weighted allocations without manual intervention. The basket would stay current with market conditions on its own.

These are natural extensions of the existing architecture and are actively being explored by the Alvara team and the broader community building on ERC-7621.