ERC-4626 and ERC-7540, the Vault Standards Behind SukukFi

SukukFi uses two Ethereum token standards for its vaults: ERC-4626 and ERC-7540. Both are published Ethereum Improvement Proposals. Both were designed to make vaults interoperable. Understanding what each one does helps depositors know exactly what they hold and how withdrawals work.

ERC-4626: The Tokenised Vault Standard

ERC-4626 is the base vault standard. It defines a single interface for any contract that takes deposits and issues shares in return.

Before ERC-4626 existed, every yield protocol invented its own interface. Aave had aTokens. Compound had cTokens. Yearn had yTokens. Each one deposited differently, withdrew differently, and calculated share value differently. Aggregators, wallets, and portfolio trackers had to write custom integrations for every protocol.

ERC-4626 standardised the interface. A compliant vault exposes:

• deposit(assets, receiver): deposit a given amount of the underlying asset and receive shares
• withdraw(assets, receiver, owner): withdraw a given amount of the underlying asset by burning shares
• redeem(shares, receiver, owner): burn a given number of shares and receive the underlying asset
• convertToShares(assets) and convertToAssets(shares): show the current exchange rate

The key design: share value rises over time as the vault earns yield. A depositor who puts in 1,000 USDC and receives 1,000 shares might later redeem those 1,000 shares for 1,080 USDC. The yield accrues in the share price, not in the share count.

Neither SukukFi vault uses the plain ERC-4626 interface directly. Both trUST and duPRT require the async extension described below, because operator approval is required for every deposit and redemption on both. Understanding the base standard is still useful — ERC-4626 defines the interface vocabulary that ERC-7540 builds on, and most tooling references it.

ERC-7540: Async Deposits and Redemptions

ERC-4626 assumes that deposits and redemptions happen in the same transaction. You call deposit, the vault accepts your assets, and you receive shares immediately. You call redeem, the vault burns your shares, and you receive assets immediately.

For vaults backed by illiquid assets, that assumption breaks. SukukFi cannot instantly liquidate a telecom invoice to pay a redemption. The Phase 1 vault runs on 15net15 terms, with settlements arriving twice monthly. Instant redemption would require holding idle liquidity as a buffer, which drags yield.

ERC-7540 extends ERC-4626 to handle this case. It introduces a two-step flow:

For deposits:

1. requestDeposit(assets, controller, owner): submit a deposit request and transfer assets to the vault
2. The vault processes the request asynchronously, typically when the next deployment window opens
3. deposit(assets, receiver): once processed, complete the deposit and receive shares

For redemptions:

1. requestRedeem(shares, controller, owner): submit a redemption request and lock shares
2. The vault processes the request as settlement payments arrive
3. redeem(shares, receiver, owner): once assets are available, complete the redemption

Between steps 1 and 3, the vault tracks your request in a pending state. When settlement payments arrive, the vault moves your pending redemption to a claimable state. You then call to claim it.

duPRT uses ERC-7540. When you request redemption, you submit a request and your shares are locked. The SukukFi operator processes pending redemption requests as settlement funds arrive from each invoice cycle.

The Difference in Practice

Both trUST and duPRT use ERC-7540. The operator approval requirement applies to both, in both directions. The difference is in timing and why the async step exists.

trUST's async step exists for access control: the operator reviews every mint and every redemption to confirm the counterparty is a verified CommTrade participant. Once approved, settlement is fast because the backing pool maintains a liquid float. The gating is commercial, not structural.

duPRT's async step exists because the underlying capital is deployed into invoice tranches. Redemptions cannot be paid until those invoices settle. The pending state tracks that obligation honestly: your shares are locked, your claim is recorded, and the operator fulfils it as settlement funds arrive.

Why Standards Matter for Depositors

Depositors benefit from standards even if they never read the EIP. The standardised interface means:

• Any ERC-7540-aware interface can display your duPRT position, including pending deposit, claimable deposit, pending redemption, and claimable redemption states
• The contracts behave predictably. The interface is the same across every compliant vault. Auditors, integrators, and depositors all read from the same specification.
• Composability: other protocols can build on top of SukukFi's vaults using the standard interface, without needing to understand the internal accounting

ERC-7575: One Share Token, Multiple Deposit Assets

ERC-7575 extends ERC-7540 to handle a situation that arises naturally with stablecoins: depositors have preferences. Stablecoin preference works like choosing an ice cream flavour. USDC.e, USDT0, and HONEY are all dollar-equivalent, but you might hold one and not another, prefer the one with the lowest slippage for your position, or simply not want to swap before depositing. Forcing everyone into a single deposit asset is friction.

ERC-7575 solves this by separating the share token from the vault. Under ERC-4626 and early ERC-7540, the vault itself is the token. Under ERC-7575, the share token (duPRT) is its own contract, and multiple vault entry points can issue it: one accepting USDC.e, one accepting USDT0, one accepting HONEY. Each entry point is a distinct EVM contract, but all three issue the same duPRT share token.

The result: depositors can deposit their preferred stablecoin directly. No intermediate swap, no extra transaction. On the other side, the vault tracks all positions in a single share accounting layer. A depositor who entered via USDC.e and one who entered via HONEY hold the same duPRT token and earn from the same pool.

This matters for integrators too. Wallets, portfolio trackers, and aggregators see one share token (duPRT) and one balance, regardless of which entry point the depositor used. The standard keeps the interface clean while allowing flexibility underneath.

SukukFi's contracts implement ERC-7575 alongside ERC-7540. The core accounting logic is separated from the interface layer, so the multi-asset entry points do not require changes to the vault's internal settlement and share price calculations.

For a worked example of how duPRT's async redemption queue functions in practice, read the duPRT redemptions explainer. For the full technical architecture, start with the documentation.