What an orchestration layer does

A yield orchestration layer is the operating layer between yield venues and the products that distribute them. It standardizes execution across venues, tracks every capital movement in one settlement state model, maintains the position record, enforces the mandate before execution, and produces reporting. It is not a venue, not an aggregator, and not a custodian.

Key takeaways

• Venues, operations and distribution are separating into three layers because they have different economics and different failure modes, not because anyone designed the split.
• The work an orchestration layer does is unavoidable. It is either a system or it is people, and at four or five venues it stops being affordable as people.
• Building in-house is the right answer more often than a vendor will tell you. Two stable venues, a team that already carries the cost, or an edge in execution rather than allocation are all cases where you should not buy.

Just the basics

Onchain yield comes from venues: lending markets, tokenized funds, liquidity pools. Investors reach those venues through products: a vault, an app, an exchange's earn tab, a fund. Between the two there is a set of jobs nobody sees. Somebody has to send the money to the right places in the right order, know what state each movement is in when one settles instantly and another takes three days, keep an accurate record of what is held and what it is worth, check that each move is allowed under the rules the fund was sold on, and turn all of it into a report. That middle set of jobs is what an orchestration layer is, and in traditional finance it is unremarkable, an operational function that has existed for decades. Onchain it is mostly done by hand.

What's in this article?

1. What is a yield orchestration layer?
2. Why is the stack separating into three layers?
3. What is an orchestration layer responsible for?
4. What it is not
5. What breaks without one?
6. Should you build it or buy it?
7. When building in-house is the right answer
8. How does Railnet fit?
9. What should you do next?

What is a yield orchestration layer?

The layer that turns an allocation decision into executed, accounted, reportable positions across more than one venue. The decision belongs to the manager, and the venue produces the return. Everything between the two is orchestration.

The name is newer than the function. Any asset manager running money across multiple execution venues has always needed an operational layer of order management, position keeping, settlement tracking, compliance checks and reporting, and onchain that layer was skipped because the first generation of products ran on one venue where the vault contract could hold both the strategy and the accounting. ERC-4626 fits that world precisely, defining an API "for tokenized Vaults representing shares of a single underlying EIP-20 token." One asset, one venue, synchronous settlement, and the vault is the whole system.

The function reappears the moment a strategy touches a second venue with different settlement behaviour, and at that point the vault contract is no longer the system. It is one component in a system that also has to know where else the money is, what state each movement is in, and how to produce one valuation across positions that do not settle on the same clock.

That larger system is what an orchestration layer names. It sits above the vault and below the distributor, and it exists because neither of those two wants the reconciliation work.

Why is the stack separating into three layers?

The three layers have different economics, different regulatory exposure and different rates of change, and bundling them makes all three worse.

Venues are already specialised and already publish their mechanics: Aave documents a two-slope interest rate model with an optimal usage ratio as the inflection point, deriving the supply rate from the variable borrow rate net of the reserve factor. Morpho documents a vault role system where the curator configures adapters, caps and fees under timelock, the allocator moves assets between enabled adapters, and a sentinel can deallocate or revoke pending actions. Ondo documents OUSG's instant and non-instant redemption paths, their minimums, and its restriction to accredited investors who are qualified purchasers.

Those three descriptions have almost nothing in common. Different rate mechanics, different permission models, different settlement, different eligibility. A product that connects to all three has to reconcile them, and that reconciliation is a distinct piece of engineering with a distinct maintenance burden. It does not belong inside a venue, because a venue integrating its competitors is a conflict, and it does not belong inside a distribution product either, because every distributor would then rebuild the same thing for itself.

Distribution is separating for a different reason. The party with the depositor relationship, the licences and the brand is frequently not the party with the strategy expertise, and neither wants to be in the other's business.

What is an orchestration layer responsible for?

Five jobs sit here, and each exists whether or not a system does it.

Standardised execution across venues

One instruction produces the correct calls at each venue, with each venue's own approval pattern, adapter, slippage handling and revert behaviour, so the manager writes an allocation and the layer produces the transactions that carry it out. Without this, an allocation across four venues is four integrations, each with its own failure semantics, and adding a fifth venue is a new project rather than a configuration change.

One settlement state model

Every capital movement is tracked through the same lifecycle regardless of how long it takes, and this is the part with no equivalent in the standards. ERC-4626 provides no mechanism for queuing, delayed processing or time-delayed claims. ERC-7540 adds asynchronous flows with three request states, Pending, Claimable and Claimed, and requires that where a shared request id becomes partially claimable, all requests under that id become claimable at the same pro rata rate.

ERC-7540 handles the common case well and is the right tool for a fund that is asynchronous throughout. Two things sit outside it. Cancellation is out of scope by the authors' own statement: cancelling a request "may not be straightforward or even technically feasible" and "a separate EIP should be developed to standardize the behavior." And a fund holding an instantly settling lending position alongside a tokenized fund with a redemption cutoff is running two clocks against one share price, and no single vault standard arbitrates that. That combination describes most institutional strategies, and it is the reason the state model belongs in a layer above the vault rather than inside it. See what the vault standards do and do not cover.

The position record

A continuous, reconcilable account of what is held, where, at what value, and how it got there: not a dashboard but a record that can be exported at a stated block, tied to accounting entries, and reproduced by a third party. This is the artefact that determines whether an audit is a report or a three-week reconstruction. See fund administration for onchain strategies.

Mandate enforcement before execution

The rules the fund was sold on, checked before a transaction is signed rather than reported after it settles: concentration limits, eligible venues, maximum exposure to a single underlying, permitted counterparties. Post-trade monitoring tells you that a breach occurred; pre-execution enforcement means it did not.

Reporting

Investor statements, manager reporting, and the audit pack, produced from the record rather than assembled from it. The standards auditors are calibrated on are exacting: registered funds compute NAV at least daily on business days and price dealing at the next computed NAV, and advised accounts get at least quarterly custodian statements plus an annual surprise examination by an independent public accountant. Most onchain structures are bound by neither, and are asked for the equivalent of both.

What it is not

It is regularly confused with three other things, and the distinction matters because each of them implies a different set of obligations.

• Not a venue. It does not generate return, set an interest rate, hold collateral or liquidate anyone. It routes to the parties that do, and a layer that also ran a lending market would be selecting between itself and its competitors on a client's behalf.
• Not an aggregator. An aggregator's job is to find the best available rate and move capital toward it, on behalf of a depositor who has delegated that judgment, while an orchestration layer executes and accounts for a mandate somebody else wrote and has its correctness measured against that mandate rather than against a rate. The two get conflated because both touch several venues. They optimise for different things, and a mandate-bound institution generally cannot use the first.
• Not a custodian. It does not hold keys or take title to assets, so custody arrangements are unchanged by its presence, and a layer of this kind cannot repair a weak custody arrangement either.

The third point matters in practice. A large share of onchain loss is control failure rather than contract failure, and a layer that reports positions accurately does nothing about a signer set that still contains someone who left the company.

What breaks without one?

The work does not disappear. It becomes manual, and manual work has a specific failure signature. Integrating one venue properly is not a weekend. It is an adapter, a model of that venue's rate or pricing mechanics, its settlement semantics, its revert and partial-failure behaviour, a mapping into your accounting, monitoring for parameter and governance changes, and an ongoing commitment to track upgrades. Do that seven times and the seventh integration is not the hard part. Keeping the first six current is.

What goes wrong, in roughly the order it happens:

1. Reporting lags the positions. The month-end pack is assembled from exports and a spreadsheet, so it is accurate as of a date nobody can reproduce.
2. Settlement state lives in someone's head. A redemption request submitted on Thursday is claimable on Monday, and the only record of that is a message thread.
3. Mandate breaches are found after the fact. A rebalance takes a position over a concentration limit and it surfaces at the quarterly review.
4. Attribution collapses into one number. Returns from four payers are reported as one portfolio APY, so a change in composition is invisible. See where onchain yield actually comes from.
5. Venue changes are missed. A parameter change or a governance vote alters the risk of a live position and nobody was watching that venue's forum.
6. Adding a venue stops being possible. The marginal integration cost exceeds the marginal return, so the strategy freezes at whatever it already supports. This is the one that quietly caps the business.

None of these is a catastrophe on its own, and that is exactly why they accumulate.

Should you build it or buy it?

Start from the number of venues, how fast that number changes, and whether your edge is in the execution or in the allocation. Those three answers decide it, and the honest version of the analysis does not always end in buying.

Smart contract code is open. Anyone can read an adapter, and no orchestration layer's advantage lies in the contracts being hard to write: the cost is in maintenance across venues that change independently, in the settlement modelling for anything that is not instant, and in producing reporting an auditor will accept. Those are ongoing costs rather than a build, and they scale with venue count rather than with assets. A team of good engineers can build the first version, and the question is whether maintaining it is the best use of them for the next five years.

The middle row is the one people get wrong in both directions. A manager whose edge is picking the right lending market and sizing it correctly gains nothing from owning the adapter code, while a manager competing on basis points of slippage should not outsource the thing they compete on.

The honest test is whether the venue list is expected to grow. If it is worth a conversation against your own, talk to the Railnet team.

When building in-house is the right answer

Four situations make an external operating layer the wrong choice.

• A small, stable venue set. Two venues that you chose deliberately and do not intend to expand: the integration is finite, the maintenance is a known quantity, and a dependency buys you very little.
• Execution is the product. If the strategy's return comes from how it trades rather than where it allocates, the execution path is the intellectual property and it should not sit in someone else's system.
• A mandate or jurisdiction that forbids the dependency. Some structures cannot accept an external party in the execution path without source access, escrow, or an operational due diligence process that costs more than the build, and that is a legitimate constraint to check at the start rather than discover in month four.
• The capability already exists. A firm running a venue, a custodian, or a large trading operation frequently already carries most of the cost for another reason, and adding orchestration to an existing platform team is cheaper than it looks from outside.

There is a counterweight. What compounds in an operating layer is coverage and the accumulated correctness of the settlement modelling rather than the code, and a team building for itself gets the venues it needs and stops. That is the right outcome if the venue list is genuinely fixed, and it is the assumption most worth interrogating before committing, because strategies expand and the integration backlog is what stops that expansion.

How does Railnet fit?

Railnet is an operating layer for onchain asset management of exactly this kind, vault infrastructure that holds a strategy with its state, settlement and governance, sitting between the venues it allocates into and the products that distribute it to depositors. Aave, Morpho, Compound, Ondo and tokenized treasury issuers are yield sources that connect to it, not competitors.

The architecture is yield sources into strategies into branded entry points. Strategies are the allocation logic a manager builds, and the entry points carry their own fee terms, compliance rules and access control, so one strategy reaches several distributors without being rebuilt for each.

The settlement model is the part that distinguishes it from a set of adapters, because every capital movement is a Query running one state machine: EMPTY, PROCESSING, PAUSED, UNLOCKING, RECOVERING, REJECTED and SETTLED, the last two terminal. The same machine covers both timings. A lending market deposit goes EMPTY to UNLOCKING to SETTLED in a single transaction, while a tokenized treasury leg enters PROCESSING and can sit in PAUSED behind a KYC gate or a cooldown for days. Each source is wrapped by its own contract, so one subscription can fan into several Queries across sources, spread a single deposit across several of them, and settle partially rather than reverting as a whole.

The market this sits in separates into five layers. Protocols produce the yield. Vault infrastructure holds the strategy with its state, settlement and governance, and that is the layer Railnet operates at alongside Lagoon, Veda and Morpho Vaults V2. Above it, curators parameterise risk inside a vault, asset managers originate strategies across venues, and distributors hold the end-user relationship. An orchestration layer does not produce the returns and does not own the client relationship. It is what makes both work at scale.

There are things Railnet does not do. It does not hold keys and is not a custodian. It does not set the mandate, choose the venues, or sign a NAV, and it is a dependency in your execution path, a real thing to accept and a fair question to put through operational due diligence. And if your venue list is two and fixed, the build case is the better one and will stay the better one.

Integration surfaces, supported sources and the settlement states are documented at docs.railnet.org.

What should you do next?

• If you are deciding whether the category applies to you, count your venues and re-read should you build it or buy it; below three venues, probably not yet.
• If the settlement mix is the problem, read how settlement works in an onchain fund.
• If reporting is the problem, read fund administration for onchain strategies.
• If you are pricing the build, count the adapter, the accounting mapping and the upgrade tracking for every venue, not the first integration alone.
• Technical documentation is at docs.railnet.org.

FAQ

What is a yield orchestration layer?

The operating layer between yield venues and the products that distribute them. It standardizes execution across venues, tracks every capital movement in one settlement state model, maintains the position record, enforces the mandate before execution, and produces reporting. It generates no return of its own and holds no keys. The venues produce the yield; the distributor owns the depositor.

How is it different from a yield aggregator?

An aggregator seeks the best available rate and moves capital toward it, exercising judgment the depositor delegated, while an orchestration layer executes and accounts for a mandate someone else wrote and is measured against that mandate rather than against a rate. Institutions with a written mandate generally cannot delegate the allocation decision, so the aggregator model is unavailable to them.

Is an orchestration layer a custodian?

No. It does not hold keys or take title to assets, so custody arrangements are unchanged by its presence, and that cuts both ways: it also cannot compensate for weak key management. Given how much onchain loss traces to signer and admin control rather than contract code, the custody question should be answered separately and first.

Why can't a vault standard do this?

ERC-4626 is synchronous and single-asset, with no queuing or delayed claims. ERC-7540 adds asynchronous requests and pro rata partial claimability but leaves cancellation to a future EIP. A fund holding both instantly settling and multi-day positions runs two clocks against one share price, and no vault standard arbitrates that.

At how many venues does this become necessary?

There is no threshold that holds for everyone, but the cost curve bends where maintenance overtakes integration, usually somewhere around the fourth or fifth venue. The better signal is whether adding a venue is a configuration change or a project, and once it is a project the strategy is constrained by the backlog rather than by the opportunity.

Should we just build it ourselves?

Sometimes yes. The contracts are open and a good team can build the first version; the recurring cost is maintaining adapters across venues that change independently, modelling settlement for anything not instant, and producing audit-grade reporting. If your venue list is small and stable, or execution is your edge, build. If it grows, the maintenance is what you are buying.

Does an orchestration layer compete with lending protocols?

No, and a layer that did would have a conflict, because it would be selecting between itself and other venues on a client's behalf. Venues compete on depth, rates and risk parameters. The operating layer competes on coverage, correctness and whether its reporting survives an audit. They are different businesses with different customers.

Talk to the team

If you are working out whether this layer belongs in your stack, or comparing a build against an integration, talk to the Railnet team, and note that there is no form to fill in first and that "you should build this yourself" is a genuine possible answer.