How settlement works in an onchain fund

Settlement is the moment a deposit or a redemption stops being a request and becomes a position or a payout. Onchain, that moment is not uniform. A lending deposit settles inside one transaction. A tokenized treasury leg can take a business day and a bank wire. A fund holding both settles in stages, and its accounting has to survive the gap.

Key takeaways

• Block finality and settlement finality are different things. A transaction that records a redemption request is final the moment it confirms. The redemption itself may be days away.
• ERC-4626 assumes the whole operation completes inside the call. ERC-7540 adds an asynchronous request pattern on top, and its own specification labels the reference implementation "incomplete pseudocode used for example only and is no way intended to be used in production or guaranteed to be secure".
• A strategy that spans venues with different settlement clocks cannot use all-or-nothing reversion. It needs per-leg state and partial settlement, or one slow leg blocks every fast one.

Just the basics

When you put money into a fund, three things happen at different times: you hand over the cash, the fund buys something with it, and you are recorded as owning a share. In traditional funds those steps are separated by a dealing cutoff and a settlement date, and everyone accepts the delay because it is written into the prospectus. Onchain, most products collapsed all three steps into a single transaction, and that works until the fund holds something that cannot move that fast; the fund then needs a way to say "your money arrived, your shares are pending, here is why, here is when". That is what settlement design is about.

What's in this article?

1. What does settlement mean in an onchain fund?
2. Why does settlement timing decide what a strategy can hold?
3. The lifecycle of a deposit
4. What does the lifecycle of a redemption look like?
5. Why does all-or-nothing settlement fail for multi-venue strategies?
6. What happens to a request pending across a NAV update?
7. Failure states, and what a depositor sees when one hits
8. How does Railnet handle settlement?
9. What should an allocator check before committing capital?

What does settlement mean in an onchain fund?

Settlement is the transfer of the asset against the extinction of the claim: the depositor's cash becomes the fund's asset and the depositor's share is issued, or the reverse on the way out. Onchain, the word gets used for two different events, and conflating them causes most of the operational surprises.

The first event is transaction finality: a block confirms and the state change is irreversible. The second is settlement finality, the point where the economic exchange is complete and neither side has an outstanding obligation, and for an ERC-4626 deposit into a lending market the two coincide, so the distinction went unnoticed for years. ERC-4626 describes "a standard API for tokenized Vaults representing shares of a single underlying EIP-20 token", and its interface is built around calls that compute and complete in one go.

The standard does give an operator a way to signal that an action is not currently available: maxDeposit must return the largest amount that would not revert, and maxWithdraw and maxRedeem must return zero when withdrawals are disabled. That is a binary open-or-closed signal. It cannot express "your request is accepted and will settle on Tuesday", the sentence an institutional operations team needs.

ERC-7540 exists to express it. The standard extends ERC-4626 with asynchronous deposit and redemption flows and defines three stages for a request: Pending, Claimable, Claimed. It is Final, and it depends on ERC-20, ERC-165, ERC-4626 and ERC-7575. For a single async product it is the right tool, and most of the asynchronous vaults in production speak it.

Where it runs out is the mixed case. A vault implements the Request pattern per flow, and "if either flow is not implemented in a Request pattern, it MUST use the ERC-4626 standard synchronous interaction pattern". The choice is made at the vault level, for the whole vault. A fund whose deposits fan out to an instant lending market and a next-day treasury product does not have one settlement behaviour to declare: it has two, running concurrently, inside the same subscription.

Why does settlement timing decide what a strategy can hold?

A strategy can only hold instruments whose settlement behaviour its accounting can represent. If the fund's model of the world is "assets are either here or not here", every instrument with an in-flight state has to be excluded, held offchain, or quietly misrepresented while it moves.

Settlement behaviour varies more across onchain venues than most allocation memos acknowledge. These are the patterns, taken from the venues' own documentation.

The tokenized treasury market is large enough that excluding it is a real allocation constraint rather than a hypothetical one: as of 27 July 2026, rwa.xyz tracked $16.20bn of distributed value across 85 tokenized Treasury funds, with Circle's USYC the largest single fund at roughly $3.00bn ahead of BlackRock's BUIDL at roughly $2.61bn. A stablecoin strategy that can only hold instruments settling inside one block has ruled out most of that, and with it most of the duration and most of the credit quality it might have wanted.

The lifecycle of a deposit

The lifecycle is best read as states rather than as transactions. A transaction is a thing that happened; a state is a thing that is true right now, and that is what an operations team, an auditor and a depositor all need to read.

STEAM, Railnet's settlement model and a standard still in development, names the states a capital movement can be in, and the unit of work is a Query, identified by keccak256(abi.encode(chainId, vehicleAddress, query)), with a salt field so that identical operations still produce distinct identifiers.

A synchronous deposit walks the short path:

1. The depositor approves the entry point and calls create with the deposit mode and an amount.
2. The Query goes EMPTY to UNLOCKING inside the same transaction, because the underlying protocol completed.
3. unlock moves it to SETTLED and the depositor holds shares before the block closes.

An asynchronous deposit walks the long one:

1. The same create call, the same interface.
2. The Query moves EMPTY to PROCESSING, signalling that the operation is underway but not ready to settle.
3. If it is waiting on a cooldown, an oracle update or a KYC check, it sits in PAUSED, and resume returns it to PROCESSING when the condition clears.
4. When the protocol signals success the Query moves to UNLOCKING.
5. It settles. An automated process calls process on active Queries when the underlying protocol is ready, so the depositor does not have to come back and claim.

The two paths use the same interface and the same state vocabulary, so a reporting system that can read one can read the other and a depositor sees the same object either way.

What does the lifecycle of a redemption look like?

A redemption is not a deposit run backwards. On the way in, the fund has the asset the depositor gave it and needs to place it; on the way out it has to find the asset, possibly committed to a venue that will not release it today.

That asymmetry is why redemption is the harder side: a deposit that has to wait is an inconvenience, while a redemption that has to wait is a liquidity event, and it arrives in size at exactly the moment everyone else also wants out.

The structural answer is a queue with partial fulfilment. Railnet routes unfulfilled redemption demand into an asynchronous redemption FIFO, matched against liquidity as it becomes available, and "a single demand can be fulfilled across multiple rounds", with cumulative progress tracked per demand. The depositor calls claimRedeemQueue to take whatever has been fulfilled, partially or fully.

Two design decisions sit inside that and deserve to be made explicitly rather than inherited. The first is ordering: strict FIFO rewards the fastest reader of the mempool, pro-rata across a window does not, and the choice determines who bears the cost of a crowded exit. The second is the release condition: a queue that only pays out when a venue voluntarily returns liquidity behaves differently from one where positions can be pulled. Morpho's V2 vaults expose the second pattern directly, with a permissionless forceDeallocate that lets a redeemer exit even when the vault's assets are committed elsewhere.

Neither choice is free, and a fund that has not written its choice down has still made one.

Why does all-or-nothing settlement fail for multi-venue strategies?

Reversion is a single verdict on a set of independent events. If one deposit fans into four venues and the fourth reverts, an atomic transaction unwinds the three that worked, and the depositor gets nothing, pays gas, and tries again into a market that has moved.

This is tolerable when a strategy holds one thing. It stops being tolerable the moment the strategy is doing the job an allocator hired it for, spreading capital across venues with uncorrelated behaviour. Railnet's multi-source deposit path fills a prioritised list of venue and target pairs in order, highest priority first, so a $20k deposit tops up the first venue to its target and allocates the remainder onward. Each leg is its own Query with its own state. One can be SETTLED while another is PAUSED on a cooldown.

Partial settlement is how the state machine represents that. In STEAM it is a loop rather than a branch: UNLOCKING can return to PROCESSING for partial settlement, and RECOVERING can return to PROCESSING for partial recovery, so a Query can settle in tranches instead of resolving once.

ERC-7540 handles the single-vault version of this well, and its rule is worth knowing because it constrains what a compliant integration may do: "If a Request with requestId != 0 becomes partially claimable, all requests of the same requestId MUST become claimable at the same pro-rata rate." That is a fairness guarantee inside one request batch. It is not a mechanism for one subscription fanning across several venues on different clocks, because the standard's request identity is scoped to the vault, and the multi-venue case has no single vault to scope to.

If you are choosing a standard rather than an implementation, the comparison is set out in the vault standards page.

What happens to a request pending across a NAV update?

The share price has to be struck at a defined point, and every in-flight request has to be valued consistently with it, because getting this wrong transfers value between depositors without anyone intending it.

Consider a subscription that enters while a treasury leg is still in flight. The cash has left the depositor. The asset has not yet arrived. If totalAssets counts the cash, the fund is double-counting for as long as the leg is open; if it counts nothing, the fund is understated, and anyone redeeming during the window is paid too little while the incoming depositor is issued too many shares.

The fix is to carry an expected value for in-flight work rather than a hole. Railnet's sub-query engine records expected outputs using the wrapping contract's estimate function when a sub-Query enters PROCESSING, then replaces the estimate with real values as shares arrive, so that totalAssets "remains accurate even when assets are in-flight". Movements are recorded as transfers between sectors under double-entry rules, so the total of accounted assets stays constant across the transition.

An estimate is still an estimate, and this is the honest limit of the design. A fund carrying in-flight value at an estimated price has a small, bounded valuation error open for the length of the window, and the discipline is to bound it deliberately: cap the size of in-flight exposure, define the price source, and reconcile on settlement. Note also that ERC-4626's own security considerations warn that preview methods "are manipulable by altering the on-chain conditions and are not always safe to be used as price oracles". A valuation window is exactly the period when that manipulability is worth money to someone.

The governance side of this is the part no mechanism supplies. Whoever strikes NAV sets the clearing price for every subscription and redemption, so the authority to define the valuation method and the authority to apply it on a given day are worth holding apart.

Failure states, and what a depositor sees when one hits

Failure is a state, not an exception. A Query that cannot complete moves to RECOVERING while assets are recovered, and terminates in REJECTED with assets returned to the owner. REJECTED and SETTLED are both terminal, so every Query ends somewhere legible.

What a depositor actually sees during a delay depends entirely on whether the product surfaces the state or hides it. The mechanism supports surfacing it: each Query has an identity, a current state and a reason for that state, and a Query in PAUSED is specifically "awaiting an external condition (cooldown, oracle, KYC)". A product that renders that reason tells the depositor their redemption is waiting on a protocol cooldown, while one that does not renders a spinner, and the support ticket arrives within the hour.

The interface goal is that the depositor should not have to know what kind of venue their money went to, and Railnet's conduit documentation puts it plainly: "The experience is the same for sync and async strategies from the user's perspective", and users do not need to return to manually claim after cooldown periods.

Three failure modes are worth naming because they produce different depositor experiences:

• The venue is slow. The Query sits in PROCESSING or PAUSED. Capital is intact, timing is uncertain, and the fund owes the depositor an expected release condition rather than a date it cannot promise.
• The venue rejects the operation. Recovery runs and the Query terminates in REJECTED with assets back. The depositor is whole and has lost the market window, a real cost even though nothing was lost in the accounting.
• The venue settles for less than requested. Partial settlement loops, and the depositor receives part now with the remainder still queued. This is the case that a pass or fail interface cannot represent at all.

Assessing the failure modes a given venue can inflict on you is a due diligence exercise, and it belongs alongside contract and oracle review in a risk framework for onchain allocation. If you are working through settlement design for a live strategy, talk to the Railnet team; the architecture questions are usually specific to the venues you have picked.

How does Railnet handle settlement?

Railnet is the operating layer for onchain asset management. It is vault infrastructure, the layer that holds a strategy with its state and settlement, and its job here is to make one settlement vocabulary cover instruments that settle in a block and instruments that settle on a bank's clock.

STEAM, the State Transition Engine for Asset Management, is the mechanism rather than a product: every capital movement is a Query running the same state machine, whether the underlying venue is a lending market that completes in one transaction or a tokenized fund with a cooldown. Railnet's documentation calls the contracts that wrap each yield source Vehicles, and one deposit can be spread across several of them, each with its own Query and its own clock.

The consequences an allocator cares about follow from that one decision. Reporting reads a single state model instead of a per-venue adapter, in-flight positions are valued rather than omitted, and partial settlement is representable, so a slow leg delays itself and not the whole subscription. The implementation detail is in the STEAM documentation and the supported protocols list.

What should an allocator check before committing capital?

Ask for the settlement behaviour of every leg, in writing, before the mandate is signed rather than after the first delayed redemption. Six questions cover most of it.

1. For each venue in the strategy, does an exit complete in one transaction, or does it enter a queue or a cooldown? Which one, and how long?
2. When a redemption cannot be filled in full, is the order FIFO, pro-rata across a window, or discretionary? Who decided?
3. At what point is the share price struck for a subscription, and how is an in-flight leg valued between request and settlement?
4. What is the maximum in-flight exposure the fund will carry at once, and is that a coded limit or a policy?
5. What does the depositor see while a request is outstanding, and does the interface distinguish "waiting on a cooldown" from "failed"?
6. If a venue stops honouring redemptions entirely, what is the recovery path and who bears the loss?

A manager who can answer all six has done the operational work. A manager who answers the first and treats the rest as edge cases has not, and the edge cases are the ones that generate the investment committee's questions.

See all questions on settlement and redemption

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

FAQ

What does settlement mean in an onchain fund?

Settlement is the point where the depositor's cash becomes the fund's asset and the share is issued, or the reverse on redemption. It is distinct from block finality. A transaction recording a redemption request is final immediately, while the redemption itself may settle days later if the underlying venue runs a queue, a cooldown or an offchain leg.

Why does settlement timing decide what a strategy can hold?

Because a fund can only hold instruments its accounting can represent, and if the model is "the asset is here or it is not", anything with an in-flight state must be excluded or misstated while it moves. That rules out most tokenized treasury exposure, a real allocation constraint rather than a technical footnote.

What is asynchronous settlement in DeFi?

It is a settlement pattern where a request is recorded first and fulfilled later, because the underlying protocol imposes a cooldown, a withdrawal queue or an offchain step. ERC-7540 standardises this for a single vault using Pending, Claimable and Claimed stages.

Can one fund hold both instant and T+1 positions?

Yes, but not with a single vault-level settlement mode. ERC-7540 sets the pattern per flow for the whole vault, and a vault not implementing a Request pattern for a flow must use the synchronous ERC-4626 pattern for it. A mixed fund needs per-leg state, so each venue settles on its own clock.

What is partial settlement?

Fulfilling part of a request now and the rest later, rather than reverting the whole thing: in a queue, one redemption demand can be filled across multiple rounds with cumulative progress tracked. Without it, one slow venue forces a full revert and the depositor loses their market window.

What does a depositor see during a settlement delay?

That depends on whether the product surfaces the state. The mechanism supports a reason as well as a status: a request awaiting a cooldown, an oracle update or a KYC check is in a distinct waiting state rather than simply unfinished. A product that renders the reason avoids most of the support load.

What happens if a redemption fails outright?

Failure is a state rather than a thrown exception. Assets are recovered and the request terminates with assets returned to the owner. The depositor is whole in accounting terms and has still lost the market window, and that is why timing risk belongs in the risk framework and not only in the operations manual.

Talk to the team

Railnet works with asset managers and platforms building strategies that span instant and delayed settlement. If you are designing a redemption queue, valuing in-flight legs, or deciding whether a venue's exit behaviour fits your mandate, talk to the team. There is no form to fill in first.