Which vault standard does a strategy need?

Most onchain strategies need a combination rather than a single standard. ERC-4626 defines the vault interface, ERC-7540 adds request-based deposits and redemptions for positions that cannot settle instantly, ERC-7575 separates the share token from the vault so one share can have several entry points, and ERC-3643 restricts who is permitted to hold the token at all.

Key takeaways

• The choice is driven by settlement behaviour and by investor eligibility, not by asset class. A fund's slowest leg and its holder restrictions decide the standard, and both are known before any code is written.
• ERC-7540 declares asynchrony per direction at the vault level, through ERC-165, not per request. A vault can take synchronous deposits and asynchronous redemptions. It cannot settle one redemption instantly and the next one on a T+1 clock.
• A transfer-restricted ERC-3643 token cannot simply be deposited into a permissionless pool. Every transfer checks that the receiver is a verified identity, and a pool contract is a receiver.

Just the basics

A token standard is an agreement about function names and behaviour, so that software written by one team can read a contract written by another. Four matter here. ERC-4626 describes a pot you put money into and get shares out of immediately, and ERC-7540 covers the case where the money cannot come back out immediately, so the withdrawal becomes a request that gets filled later. ERC-7575 lets several pots issue the same share token. ERC-3643 is about eligibility: it checks the identity of anyone receiving the token and blocks the transfer if they are not approved. A regulated fund usually needs the last one and one or two of the others.

What's in this article?

1. What does ERC-4626 solve, and where does it stop?
2. What does ERC-7540 add?
3. What problem does ERC-7575 solve?
4. Why ERC-3643 is not a vault standard
5. How do the four standards compare?
6. Which standard does your strategy need?
7. Two places these standards fail to compose
8. Where Railnet fits
9. What should you do next?

What does ERC-4626 solve, and where does it stop?

ERC-4626 standardises the interface for a tokenized vault: one underlying asset in, fungible shares out, with a fixed set of conversion, preview and limit functions so that any integrator can read a vault it has never seen. It was created in December 2021 and is Final. The specification's own framing of the problem is blunt: "Tokenized Vaults have a lack of standardization leading to diverse implementation details."

Before it, every lending market and yield aggregator invented its own deposit function, so an integrator wrote one adapter per venue and then maintained all of them; after it, a wallet, an accounting system or another protocol integrates once and reads many.

Three limits are worth knowing before choosing it.

It assumes atomic settlement. Deposit, mint, withdraw and redeem complete inside the calling transaction. A vault holding anything that cannot be unwound in one block has to either hold a buffer, revert, or return a limit of zero.

Its price functions are not oracles, and the specification says so: preview functions are "manipulable by altering the on-chain conditions and are not always safe to be used as price oracles," while the convertTo functions are "rough estimates that do not account for operation specific details like withdrawal fees." Integrators that treat share price as a trusted feed inherit whatever the vault's state can be pushed to.

Conformance is not correctness. The specification warns that "fully permissionless use cases could fall prey to malicious implementations which only conform to the interface but not the specification." Reading the interface flag tells you the function names exist. It tells you nothing about rounding, fees or what the vault does with the assets. Rounding is normative and directional: round down when computing shares issued or assets sent to a user, round up when computing what a user must supply. The failure cases live in those details rather than in the interface.

What does ERC-7540 add?

ERC-7540 replaces the immediate call with a request that moves through Pending, then Claimable, then Claimed, so a vault can hold positions that take hours or days to settle. It extends ERC-4626 and requires ERC-20, ERC-165 and ERC-7575. It is Final. The motivation names the cases directly: real-world asset protocols, undercollateralized lending, cross-chain lending, liquid staking tokens and insurance safety modules. All of them share one property. The vault cannot know at request time what the exchange rate will be at settlement.

Four properties of the design matter operationally.

The claim step is mandatory. "Requests MUST NOT skip or otherwise short-circuit the Claim state." Even a request the vault could fill instantly costs the user two transactions.

Asynchrony is declared per direction. "ERC-7540 Vaults MUST implement one or both of asynchronous deposit and redemption Request flows," and the spec's worked example is a liquid staking token where "the unstaking period necessitates support for asynchronous withdrawals, however, deposits can be fully synchronous." The declaration is made through ERC-165: 0xce3bbe50 for asynchronous deposit vaults, 0x620ee8e4 for asynchronous redemption vaults, 0xe3bc4e65 for the operator methods every ERC-7540 vault implements.

Requests can be batched by ID. Requests sharing the same non-zero request ID must move from Pending to Claimable together and receive the same exchange rate. That is the mechanism behind epoch or cycle-based funds.

Cancellation is not in the standard. The spec leaves it out deliberately and says a separate EIP should be developed for it, and it does not require pending claims to be fungible. The security considerations acknowledge the consequence: pending requests can become stuck unless a vault adds fungibility or a cancellation path of its own.

One more detail worth knowing before an engineer copies from the spec. The reference implementation carries its own warning: "This code snippet is incomplete pseudocode used for example only and is no way intended to be used in production or guaranteed to be secure." The standard is Final. A production-grade reference is not part of it.

What problem does ERC-7575 solve?

ERC-7575 detaches the share token from the vault contract, so several vaults can issue the same share and a vault no longer has to be an ERC-20 itself. It is Final, and its abstract states the purpose plainly: "The following standard adapts ERC-4626 to support multiple assets or entry points for the same share token."

What it fixes is structural rather than cosmetic. ERC-4626 requires the vault to be an ERC-20, so the arithmetic is fixed at one vault, one share, one asset, and anything with several entry points, an LP token for example, is "generally unwieldy or non-compliant due to the requirement of ERC-4626 to itself be an ERC-20."

The mechanism is one function and one relaxation. Vaults expose share(), returning the address of the share token; the call may return the vault itself and must not revert. And: "All ERC-7575 Vaults MUST implement ERC-4626 excluding the ERC-20 methods and events." The share token in turn should expose vault(asset) so an integrator can look up the entry point for a given asset. Discovery runs through ERC-165: 0x2f0a18c5 on the vault, 0xf815c03d on the share.

Splitting the share from the vault carries a cost, and the standard names it. When the share lives in a different contract from the vault, ordinary ERC-20 approvals do not carry across for redemptions where the owner is not the caller, and the specification's suggested remedy is to configure the vault as a trusted forwarder of the share token using ERC-2771. Multi-asset funds inherit that plumbing whether or not they wanted it.

It also defines Pipes: converters between a single asset and a share, both external ERC-20 tokens, and a Pipe may be one-directional.

Why ERC-3643 is not a vault standard

ERC-3643 is a permissioned token standard rather than a vault standard: it checks the identity of the receiver on every transfer and blocks the transfer if the receiver is not verified. It is Final, and it is the reference pattern for regulated security tokens. The architecture is a set of registries around the token: an ONCHAINID identity per investor holding signed claims, an Identity Registry mapping addresses to identities and country codes, an Identity Registry Storage that several registries can share, a Trusted Issuers Registry naming who may sign claims, a Claim Topics Registry defining the claims that are required, and a Compliance contract holding offering-level rules such as holder caps or permitted jurisdictions.

Two checks run on every transfer: isVerified confirms that the receiver holds the required claims from authorised issuers, and canTransfer evaluates the offering-level rules that have nothing to do with the individual, such as a maximum number of holders. Both must pass, neither party's wallet may be frozen, the token must not be paused, and the specification is explicit that "the receiver MUST be whitelisted on the Identity Registry and verified."

The standard also gives an agent role powers with no analogue in a permissionless token: forced transfers, partial or total freezing of balances, minting and burning, pausing, and recovery of tokens for a lost private key. Those exist because a transfer agent in a regulated fund has always had them, and they make an ERC-3643 token a different counterparty proposition from an ERC-20. The diligence question is who holds the agent role.

How do the four standards compare?

They answer four different questions: what the interface is, when settlement happens, where the share lives, and who may hold it. Only the second and fourth are usually contested.

Which standard does your strategy need?

Work from the slowest leg and the holder restriction. Everything else follows. Run these in order.

1. Can every position be exited in a single transaction, at the largest size the fund will accept? The test is not a normal day but the day everyone asks at once. If yes, ERC-4626 alone is sufficient and adding anything else is cost without benefit.
2. If not, is the constraint on deposits or on redemptions? Deposits usually settle fine; redemptions usually do not. ERC-7540 lets you declare asynchrony on one direction only, the liquid staking pattern in the specification. Declaring both when only one is needed makes every deposit a two-transaction flow for nothing.
3. Does the fund need more than one entry asset, or a share that exists independently of the vault? Multi-currency share classes, an LP-style share, or a share token that must be a specific contract for compliance reasons all point at ERC-7575. It is already a requirement of ERC-7540, so an async vault gets it either way.
4. Is holding restricted by investor eligibility? If the answer involves accredited investors, jurisdiction limits or a holder cap, the restriction belongs on the share token, and ERC-3643 is the reference pattern. Bolting eligibility onto the deposit function does not restrict the share once it exists, because the share is transferable and the deposit check has already passed.
5. Do you need cancellation of a pending request? ERC-7540 does not provide it. Build it, or make the notice period short enough that nobody asks.
6. Do you need settlement speed to vary per request? No standard on this list covers that.
7. Confirm what a counterparty will see. Publish the ERC-165 interface IDs and check they match the behaviour, because an integrator reads the flag and writes against it.

Order matters. Teams start at step 4 because compliance is the loudest requirement, then discover at step 1 that the redemption profile forces a different vault shape and the compliance work has to be redone against it.

If you are working through this for a live mandate, talk to the Railnet team.

Two places these standards fail to compose

Both are structural rather than implementation defects, so careful engineering does not remove them.

The first is that a transfer-restricted token cannot enter a permissionless pool. ERC-3643 checks the receiver on every transfer, and a pool contract is a receiver like any other. If the pool's address is not registered as a verified identity the deposit reverts, and if it is registered the pool then holds the restricted asset while issuing its own unrestricted share against it, so the eligibility rule has been satisfied at the boundary and abandoned immediately behind it. Neither outcome is what the issuer intended. Permissioned assets therefore end up in permissioned pools sharing the same registry rather than in general-purpose ones, and the distribution surface narrows accordingly.

There is a composition that works, and it is worth stating because neither specification spells it out. ERC-7575 allows the share token to be a separate contract and removes the requirement that the vault be an ERC-20 itself. An ERC-3643 token is ERC-20 compatible. So a permissioned fund can use an ERC-3643 token as the ERC-7575 share while the entry points stay conventional vault contracts, putting the eligibility check on the instrument that circulates rather than on the door. The catch is operational: minting and burning in ERC-3643 are agent functions, so the vault contract has to hold the agent role, and whoever controls that role controls issuance. That is a governance decision rather than a coding one.

The second is that ERC-7540 cannot mix settlement speeds inside one direction. The standard is asymmetric between deposit and redemption, and that asymmetry is genuinely useful: a vault can take synchronous deposits and asynchronous redemptions, and the specification's own example does exactly that. What it cannot do is vary within a direction. The flag is set per vault, through ERC-165, and it is read by integrators as a static property. A fund holding an overnight lending position that settles in one block alongside a tokenized treasury leg that settles on the underlying instrument's calendar has three options and no fourth: run every redemption on the slower clock, hold a liquidity buffer large enough to serve fast exits from cash and accept the drag, or drop the slow leg. Institutional mandates tend to want both legs, so the constraint binds in practice rather than in theory. See how settlement works in an onchain fund.

A related consequence of the mandatory claim step: a request that could have been filled immediately still costs two transactions, and the depositor does not know their exact share count until settlement.

Where Railnet fits

Railnet treats the standards as interfaces to be spoken correctly rather than as the accounting model. The interface a counterparty integrates against and the state machine the fund runs internally are different problems, and conflating them is what forces the trade-offs above into the product.

Internally, every deposit and redemption is a Query with its own identity running one state machine: EMPTY, PROCESSING, PAUSED, UNLOCKING, RECOVERING, REJECTED, SETTLED, with REJECTED and SETTLED terminal and no transition permitted between the success and error paths. Partial settlement is an explicit cycle in that machine. A synchronous allocation runs EMPTY to UNLOCKING to SETTLED in one transaction. An asynchronous one passes through PROCESSING and possibly PAUSED on its own clock. Because state is tracked per Query rather than per vault, one deposit can fan across several sources at different speeds and settle in parts rather than reverting as a whole.

At the boundary, Railnet's advanced strategies present an ERC-7540 vault. Deposits are synchronous while the current valuation sits inside its validity window and switch to request-based once it expires, and redemption settlement is all-or-nothing per cycle. The constraint in the previous section does not disappear, and Railnet does not claim it does. What moves is where it binds: on the depositor-facing interface once, rather than on every position inside the fund.

The supported protocols reference records where an adapter already exists and where a custom one is needed because the source settles asynchronously, and Railnet and other standards sets out the relationship to ERC-4626 and ERC-7540 in implementation terms.

What should you do next?

Write down the fund's slowest exit and its holder restriction before choosing anything. Those two facts determine the answer, and both are known at mandate design time rather than at build time. If the choice is between the two vault standards, the deciding question is whether every position can be unwound inside one block. If you are integrating a vault someone else deployed, check its rounding direction, its fee treatment and what its limit functions return. The interface flag reports none of that. If the compliance requirement is the binding one, start with how compliance is enforced onchain.

See all questions on vault standards

Foundations

• What is ERC-4626?
• What is ERC-7540?
• What is settlement, onchain and off?

Related pillars

• How settlement works in an onchain fund
• How compliance is enforced onchain
• What is onchain asset management?

FAQ

Which vault standard should a new strategy use?

Start from the slowest position the fund will hold and from whether holders are restricted. If everything exits atomically and anyone may hold the share, ERC-4626 is enough. If redemptions cannot settle in one transaction, add ERC-7540 on that direction. If eligibility is restricted, put ERC-3643 on the share token.

Is ERC-7540 a replacement for ERC-4626?

No. It extends it. An ERC-7540 vault still exposes the ERC-4626 interface, and the standard also requires ERC-20, ERC-165 and ERC-7575. What changes is that the deposit or redemption call becomes a request that must pass through an explicit claimable state before the user receives anything.

Can a vault be synchronous for deposits and asynchronous for redemptions?

Yes, and the specification uses exactly that example: a liquid staking token whose unstaking period forces asynchronous withdrawals while deposits stay synchronous. The vault declares which directions are asynchronous through ERC-165 interface IDs, so integrators can detect the behaviour before interacting.

Can one vault settle some redemptions instantly and others on a delay?

Not within ERC-7540. Asynchrony is a per-direction property of the vault, declared statically and read by integrators as such, rather than a per-request one. A fund holding both instant and multi-day positions has to run every redemption on the slower clock, hold a buffer, or drop the slow leg.

Can an ERC-3643 token be deposited into a normal DeFi pool?

Not without breaking one of the two intentions. The transfer reverts unless the pool contract is itself registered as a verified identity, and if it is registered, the pool issues an unrestricted share against a restricted asset. Permissioned assets generally have to sit in pools that share the same identity registry.

What is ERC-7575 for if a fund only has one asset?

Nothing, on its own. It matters when a fund has several entry assets, when the share token must be a separate contract, or when the vault cannot be an ERC-20 itself. It is also a requirement of ERC-7540, so any asynchronous vault implements it whether or not the multi-asset case applies.

Does the ERC-7540 specification ship production code?

No. The reference implementation in the specification carries an explicit warning that it is incomplete pseudocode, for example only, not intended for production and not guaranteed to be secure. The standard being Final refers to the interface, not to a reference implementation anyone should deploy.

Talk to the team

If you are choosing a standard combination for a live mandate and the settlement profile and the compliance requirement are pulling in different directions, talk to the Railnet team. There is no form to fill in first.