ERC-4626 is a standard vault interface: deposit an asset, get shares, standard assets-to-shares accounting. For private credit it standardizes NAV and subscriptions, but it is an interface, not compliance. You still gate holders and control redemptions.
A 4626 vault is a clean container for a credit pool. The hard parts sit outside the standard.
Why
EIP-4626 defines one interface for tokenized vaults: you deposit an underlying asset, the vault mints shares, and everyone reads the same functions for deposit, mint, withdraw, redeem, and the convertToShares / convertToAssets accounting.
For tokenized private credit, that maps well. The vault holds a pool of loans or receivables. Shares represent a pro-rata claim on the pool. Subscription is a deposit; redemption is a redeem. The accounting layer prices shares against the pool’s value in one agreed way.
The real gain is composability and tooling. Wallets, custodians, and dashboards that already speak 4626 can integrate a credit vault without bespoke work. Subscription and redemption UX becomes standard instead of a one-off. That is a genuine operational saving, and it is why 4626 is worth using as the container.
The edge cases
Three things the standard does not solve.
First, 4626 is an interface, not a permission system. Vault shares are transferable ERC-20s by default. A security-token credit vault must gate who can hold shares. That means composing 4626 with a transfer-restriction layer, ERC-3643 or ERC-7943, so eligibility is enforced on every transfer, not just at deposit. Without that, a compliant subscription can be resold to an ineligible holder minutes later.
Second, private credit is illiquid. The standard’s shape implies you can withdraw any time. You cannot. The underlying loans have fixed terms. You need gated or epoch-based redemptions, a redemption queue, and clear rules for when the gate opens. Treating redeem as always-available is the fastest way to break the vault.
Third, shares need a price, and losses need a home. convertToAssets is only as honest as the NAV feeding it. Illiquid loans do not have a live market price, so you need a defined NAV or oracle process and a schedule. And when a borrower defaults, the standard says nothing: you must decide, in advance, how a loss is written down across shares. Silent on this, and the accounting lies.
What this means for your structure
Use 4626 as the container, not the compliance layer. Wrap it in transfer restrictions so only eligible holders touch the shares. Compliance is enforced at the token transfer layer, which is where Stobox puts it.
Then write the mechanics down explicitly: redemption epochs, the NAV process, and default handling. These are structuring decisions, not code you inherit from the standard.
Stobox is a non-custodial technology provider, not a broker-dealer or law firm. We issue security tokens primarily on Base, and also on Arbitrum, Canton, and other EVM chains, and back ERC-7943 while working with ERC-3643. Flat fees, never a percentage of the raise.
Gene Deyev’s take
A standard interface is not a compliance framework, and 4626 is the clearest example. It gives you clean accounting and tooling everyone already speaks, but the shares are still plain transferable tokens the moment you deploy them. Gate eligibility at the transfer layer with something like ERC-7943, or a compliant subscription gets resold to an ineligible holder minutes later. And be honest about liquidity: illiquid credit cannot promise instant redemption, so write the epochs, the NAV process, and default handling down before anyone deposits.
— Gene Deyev, CEO & Co-Founder, Stobox. Co-author of the Stobox Tokenization Framework and the STV3 protocol; ERC-7943 backer; SEC Crypto Task Force roundtable participant (2025).
Related questions
- ERC-3643 vs ERC-7943
- SPV tokenization
- Security token liquidity
- How to choose a tokenization platform
Last updated: 2026-07-12.