Onchain asset management is the practice of running an investment mandate where the portfolio, the accounting and the investor register live on a blockchain. A manager raises capital into a smart contract, allocates it across venues, prices the book continuously, and processes subscriptions and redemptions in code rather than through a fund administrator.
Key takeaways
- The hard part is post-issuance: tokenizing a fund is a one-time engineering job, running it is a daily operational one, and the two need different systems.
- The market has separated into three layers: yield sources that produce return, strategies that allocate across them, and branded front-ends that hold the depositor relationship. Managers work in the middle layer.
- What fails first is rarely the contract code. The usual causes are settlement timing, valuation authority, and positions sitting across venues that each publish their state in a different shape.
Just the basics
Picture a fund that holds short-dated government debt and lends cash overnight. The traditional version has an administrator keeping the register of who owns what, a custodian holding the assets, and someone striking a valuation once a day; onchain, the register is a token balance, the custody is a smart contract, and the valuation can be recalculated every block. Investors send stablecoins to an address and receive shares, and when they want out they hand back shares and receive stablecoins, subject to whatever notice period the fund requires. The investment decisions are the ones a portfolio manager has always made. The plumbing is different, and the plumbing is where the work is.
What's in this article?
- What is onchain asset management?
- What does an onchain asset manager actually do?
- How is the market structured?
- What differs operationally from traditional asset management?
- How does a subscription and redemption cycle run?
- Risks and failure modes
- Why is the operating layer separating from the venues?
- Where Railnet fits
- What should you do next?
What is onchain asset management?
Onchain asset management is the operation of a pooled investment mandate whose positions, share register and valuation are recorded on a public ledger, with subscriptions and redemptions executed by contract rather than by instruction. The definition matters because most published material on the subject stops at issuance, and issuance is the part that is already solved.
The container is standardised. ERC-4626 was created in December 2021 and is now a Final standard, and it fixed how a depositor's assets convert into shares and back again. Any competent team can deploy a compliant vault, and what the standard does not describe is how a manager decides where the money goes, how a position is valued when part of it cannot be sold today, who may change the risk limits, or what the auditor receives in March.
Those are asset management questions, not tokenization questions. They arrive on day two and they never stop arriving.
What does an onchain asset manager actually do?
The job is allocation, valuation, liquidity management, mandate enforcement and reporting, in roughly that order of frequency. A fixed income PM would recognise the job description. The venues are what differ.
Allocation is the visible part: how much sits in overnight lending, how much in tokenized treasuries, how much in a funding-rate position, and how the weights move as rates and utilisation change, with each move a transaction carrying a cost, so a rebalance that looks correct in a spreadsheet may not clear its own gas and slippage.
Valuation decides whether the fund is trustworthy. Some positions have a price the chain can read, and others do not: a redemption queued at a treasury issuer is worth whatever a settlement that has not happened yet turns out to be worth. Somebody has to state what the book is worth, and that authority has to be constrained, because whoever sets net asset value sets the clearing price for every subscription and redemption.
Behind that sits liquidity management, reconciling two clocks. Depositors want out on their schedule and positions release on theirs, so a manager holding an instrument with a multi-day exit cycle while offering same-day redemptions has written an option and not priced it.
Mandate enforcement is the constraint layer: these assets, at these caps, on these venues, and nothing else. In a traditional fund the mandate lives in a document and compliance checks it afterwards, whereas onchain it can be checked before execution, a real improvement and also a design burden, because a limit encoded wrongly blocks a trade the manager needed to make.
Nobody writes about reporting. An investment committee wants exposure by counterparty, by asset and by settlement horizon, with attribution for the period, and the chain holds all of that data and none of it in that shape.
How is the market structured?
Onchain asset management has settled into three layers: yield sources, strategies and distribution. Different parties operate each one, and that separation is what makes the middle layer a business.
Yield sources produce the return: lending markets, tokenized treasury issuers, staking systems, funding-rate strategies and private credit. Each has its own risk parameters, governance and settlement behaviour. A lending market settles inside one transaction, while a tokenized treasury settles on the underlying instrument's calendar, with a redemption cutoff and a KYC gate inherited from it.
Strategies are the allocation logic and the manager's product: a mandate, a set of permitted sources, weights, guardrails, a rebalancing policy. A strategy generates no yield of its own; it decides which venues to use, and absorbs the operational cost of every venue it touches.
At the front, distribution is the depositor-facing entry point, an exchange, a wallet, a fintech or a private bank, carrying the brand, the fee schedule, the onboarding and the obligation to its own users. Several distributors can sit on one strategy with different access rules, without splitting the underlying pool.
| Layer | Who operates it | What it decides | What it does not control |
|---|---|---|---|
| Yield sources | Protocol teams, token issuers | Interest rate models, collateral factors, redemption windows | Who allocates to them |
| Strategies | Asset managers, curators | Weights, caps, permitted venues, rebalancing | The terms of the underlying venues |
| Distribution | Exchanges, wallets, fintechs, banks | Access, fees, onboarding, user reporting | The investment decisions |
Operational responsibility does not follow the money in a straight line. A distributor answers to its users for a loss it had no hand in causing. A manager answers for a parameter change made by a protocol's governance overnight.
What differs operationally from traditional asset management?
Four things change: settlement is heterogeneous rather than uniform, the accounting record is public and continuous rather than periodic and private, mandate checks can run before execution rather than after, and the manager absorbs duties a fund administrator used to carry.
Settlement is the largest difference and the least discussed. A traditional multi-asset fund settles on a small number of known cycles, whereas an onchain portfolio can hold one position that settles atomically and another that sits pending for days on an offchain process, both in the same fund, priced into the same share and redeemed by the same investor. How settlement works in an onchain fund covers it in full.
The accounting record inverts. Instead of a monthly statement assembled from custodian files, the position data is already on the chain and the problem is interpretation. Anyone can read the balances, and very few can state the fund's exposure to a single counterparty across seven venues, or produce a period attribution an auditor will accept. Public data is not a reportable record.
Mandate enforcement moves earlier. A cap encoded in the contract is not a policy the manager could breach and later explain, and it also removes discretion in a crisis, sometimes the wrong property, so most designs pair hard limits with a role that can reduce risk immediately.
The administrator's work does not vanish. Somebody still strikes a valuation, applies fees, maintains the register and answers the auditor, and onchain those tasks run as contract logic configured by the manager, so the work moves rather than disappears. What is onchain fund administration covers the function.
| Function | Traditional fund | Onchain fund |
|---|---|---|
| Investor register | Transfer agent maintains it | Token balances, updated on transfer |
| Valuation | Struck periodically by the administrator | Read from onchain state, proposed for positions the chain cannot price |
| Settlement | A small set of standard cycles | Per-venue, from one transaction to multi-day |
| Mandate | Document, checked after execution | Encoded limits, checked before execution |
| Custody | Custodian holds assets | Contract holds assets, roles hold the keys |
| Reporting | Administrator statement pack | Continuous state, plus whatever turns it into a report |
| Audit trail | Reconstructed from records | Present by default, unstructured by default |
How does a subscription and redemption cycle run?
A subscription enters, is priced against a valuation, mints shares, and the capital is allocated; a redemption reverses the sequence, and the reversal is where timing risk concentrates. The cycle below is the shape it takes when a fund holds positions that settle at different speeds.
- The depositor submits a request. Under ERC-7540, an asynchronous vault takes the assets into escrow and records a Pending request. The standard requires an explicit claim step: "Requests MUST NOT skip or otherwise short-circuit the Claim state." Capital is committed, shares do not exist yet.
- A valuation is proposed. The role holding valuation authority publishes what the book is worth, snapshotting the pending requests and closing the period for pricing. Railnet's implementation splits this in two: a valuation manager proposes the new total assets, and the strategy separately confirms it before anything settles.
- Requests settle at the confirmed price. Shares are minted. Until this point the depositor does not know their exact share count, a property of the standard rather than a defect of an implementation.
- The depositor claims. A second transaction moves the shares to the receiver.
- Capital is allocated. Instant venues fill in the same block. Slower venues open a position that will not confirm for hours or days.
- The fund runs. Positions accrue, parameters at the underlying venues change without asking, and the valuation refreshes on whatever cycle the fund committed to.
- A redemption request arrives. Shares move into escrow, and the manager has to source liquidity by the settlement date from cash, from an instant venue, or by queuing an exit at a slow one.
- Redemption settles, or it does not. Railnet's 7540 vault settles redemptions all-or-nothing per cycle: if the strategy cannot cover every pending redemption at the confirmed price, none settle that cycle. Designs differ, and every design answers this somehow. Partial fills, pro-rata allocation and queue ordering are the three usual answers, and the choice belongs in the dealing policy rather than in the contract review.
Steps 2, 3 and 8 are where operational failure concentrates. None of them is a contract bug.
Risks and failure modes
The recurring failures are valuation authority, liquidity mismatch, parameter drift at the venues, and dependency contagion between positions that look independent.
Valuation authority is the largest unhedged exposure in most funds, larger than any position, and if the role that proposes NAV is a single key with no bounds check it sets the price for everyone entering and exiting. Sound designs put a band around the proposal and require a second party to confirm it. Note that such guardrails commonly exempt the first update after initialisation, because there is no prior value to bound against.
A solvent fund becomes a gated one through liquidity mismatch, and offering weekly redemptions against an instrument with a longer exit cycle is a mismatch no amount of contract auditing addresses.
Parameter drift is the one managers underrate. You do not set the loan-to-value ratios, oracle configurations or supply caps at the venues you allocate into, and those change through each venue's governance on its own timetable, so a portfolio built on assumptions that held at allocation can be sitting on different assumptions a month later with no transaction having occurred.
Hardest to see is dependency contagion. Two positions on two venues can share a collateral asset, an oracle or a bridge, and correlate perfectly at the worst moment while appearing diversified in the position report.
Contract code gets audited. The operational keys and the roles that can move assets or change limits often do not get the same scrutiny, and they are a smaller target.
If you are building the evaluation framework rather than reading about it, talk to the Railnet team about what a cross-venue position record can and cannot surface.
Why is the operating layer separating from the venues?
The number of venues a credible mandate has to touch grew faster than any manager's ability to integrate them, and integration is not where a manager's edge is. The arithmetic is visible in any adapter registry. Railnet's documentation lists native integrations for Aave V3, Compound V3, Morpho Blue, Ethena and Syrup, a generic ERC-4626 adapter, and a further set of protocols that need custom adapters specifically because they settle asynchronously, including Lido, Rocket Pool, EigenLayer, Symbiotic, Karak and Pendle. Each is a different accounting shape, a different settlement clock, and another set of governance parameters to watch.
A manager who integrates ten venues directly maintains ten codebases they did not write, ten monitoring surfaces and ten reconciliation paths into one accounting record. The marginal venue makes the strategy better and the operation worse, and eventually the operation constrains the strategy. That is the point where the operating layer separates out and becomes something a manager buys rather than builds. The same thing happened in traditional asset management, for the same reason.
Where Railnet fits
Railnet is the operating layer for onchain asset management. It is vault infrastructure, the layer that holds a strategy with its state, settlement and governance, and it standardises how capital moves, how the book is priced, and what the manager can report.
The architecture follows the three layers above. Yield sources connect through adapters, one written per protocol. Strategies combine those sources into a managed allocation with guardrails and sector-based accounting. Branded entry points sit at the front, each with its own share token, fee configuration and access rules, and several can sit on one strategy without fragmenting the underlying liquidity.
Underneath is STEAM, the State Transition Engine for Asset Management. Every deposit or redemption is a Query with a unique identity, and every Query runs one state machine: EMPTY, PROCESSING, PAUSED, UNLOCKING, RECOVERING, REJECTED, SETTLED, with REJECTED and SETTLED terminal and transitions between the success and error paths forbidden. A synchronous allocation into a lending market runs EMPTY to UNLOCKING to SETTLED inside one transaction. An asynchronous one into a tokenized instrument passes through PROCESSING and possibly PAUSED, on its own clock. Both are the same standard, so one deposit can fan across several sources and settle in parts rather than reverting as a whole.
That is a mechanism rather than a product. What it gives the manager is one accounting record across venues that settle at different speeds, and a position report that nobody has to assemble by hand.
That middle layer divides further into three roles. Vault infrastructure is one, and it is where Railnet sits, alongside Lagoon, Veda and Morpho Vaults V2. Curators parameterise risk inside a vault. Asset managers originate the strategy across venues and carry the mandate. None of the three is a yield source, and that is why Aave, Morpho, Compound and Ondo plug in rather than compete, and why the depositor relationship stays with whoever distributes.
What should you do next?
Decide which of the three layers you operate in, because the questions that matter differ sharply between them.
A manager building a strategy works in this order: mandate, venues, settlement policy, reporting. An allocator evaluating someone else's strategy should read a risk framework for onchain allocation, then establish who is on the other side of the position and what that party owes them.
For a distributor the open questions are access control, fee configuration and what to show its own users after a bad week.
If you are the engineer sent to check, the implementation detail is in the Railnet developer documentation and the supported protocols reference.
See all questions on onchain asset management
Foundations
Related pillars
- What is vault curation?
- How settlement works in an onchain fund
- Fund administration for onchain strategies
- What an orchestration layer does
FAQ
What is onchain asset management?
Running an investment mandate where the portfolio, the share register and the valuation live on a blockchain, with capital entering a smart contract, a manager allocating it across yield venues, and subscriptions and redemptions executing in code. The investment decisions are conventional, while the operational layer underneath them is not.
How is it different from tokenizing a fund?
Tokenization is the issuance step: creating a token that records ownership of a fund interest. Onchain asset management is everything after that, and it recurs daily: valuation, allocation, mandate enforcement, liquidity management and reporting. A fund can be fully tokenized and still have no operating layer behind it.
Who values an onchain fund?
A role with authority to propose net asset value, usually constrained by a second role that confirms it and by bounds on how far the price per share may move in one cycle. Positions the chain can price are read from state. Positions awaiting offchain settlement have to be proposed, and that is why the authority is split.
Do onchain funds still need a fund administrator?
The function is unavoidable. Somebody strikes a valuation, applies fees, maintains the register and answers the auditor, and in an onchain fund those tasks run as contract logic configured by the manager, so the work moves rather than disappears. Firms differ on whether they keep a traditional administrator alongside it.
What is the main operational risk?
Settlement timing. A fund holding positions that release on different clocks, while offering depositors one redemption schedule, has taken a mismatch that contract auditing does not address. Second is valuation authority, because whoever sets NAV sets the entry and exit price for everyone.
Does onchain asset management mean fully permissionless?
No. Access can be gated at the entry point, so one underlying strategy can serve a permissionless pool and a KYC-gated institutional channel through separate front-ends with different rules. The investment logic is shared, while the access rules are not. See how compliance is enforced onchain.
How many venues does a strategy need?
Enough to avoid a single-factor return, and that usually means more than one category rather than more than one protocol. Ten lending markets share the same supply and demand dynamics and diversify nothing. Adding a tokenized treasury leg changes the return driver, and also changes the settlement profile of the whole fund.
Talk to the team
If you are building or operating an onchain strategy and want to compare notes on settlement, valuation authority or reporting, talk to the Railnet team. There is no form to fill in first.