Fund administration for onchain strategies

Onchain fund administration is the set of operational functions that sit between a strategy and its investors: the accounting record, net asset value, subscriptions and redemptions, share classes, and investor and regulatory reporting. Onchain, no third party performs them by default. They are distributed across smart contracts, the manager, and whoever holds an admin key.

Key takeaways

• The functions do not disappear when a fund goes onchain. They get reassigned, usually without anyone writing down who now holds each one, and that is the finding an auditor arrives at first.
• ERC-4626 covers a single-asset synchronous vault and nothing beyond it. ERC-7540 adds asynchronous requests with Pending, Claimable and Claimed states, and its own specification calls its reference implementation "incomplete pseudocode ... in no way intended to be used in production."
• A share price computed by a contract is a calculation, not a valuation. Sign-off is a governance question, and it is the one an audit committee asks about first.

Just the basics

A fund needs somebody to count. Somebody has to record what the fund owns, work out what a share is worth, process money coming in and going out, keep the investor register accurate, and produce statements that investors and auditors accept. In a traditional fund a third-party administrator does most of this, and the fact that they are independent of the manager is the point: the person calculating the value is not the person whose fee depends on it. Onchain, a smart contract can compute a share price continuously and every transaction is publicly visible, solving parts of the problem and quietly removing others. Independence is the part that goes missing, along with the ability to value anything the contract cannot see.

What's in this article?

1. What does fund administration actually consist of?
2. What changes onchain, function by function
3. Who does each job when there is no administrator?
4. How is NAV calculated and signed off?
5. How do subscriptions and redemptions work with mixed settlement?
6. How do share classes work onchain?
7. Reporting a position to an auditor
8. How does Railnet fit?
9. What should you do next?

What does fund administration actually consist of?

Five functions, each needing an owner by name: the accounting record, valuation and NAV, subscription and redemption processing, the investor register and share classes, and reporting.

• The accounting record. A complete, dated ledger of every position, cash movement, fee accrual and corporate action, reconciled to independent evidence. This is the substrate everything else is computed from.
• Valuation and NAV. The value of the fund's assets less its liabilities, at a stated time, computed by a documented method and signed off by someone accountable for it.
• Subscriptions and redemptions. Accepting money in and paying money out at the correct price, in the correct order, with the correct treatment when the fund cannot pay everyone at once.
• Investor register and share classes. Who owns what, in what class, on what fee terms and under what eligibility restrictions.
• Reporting. Investor statements, manager reporting, regulatory filings and the audit pack.

The reason a traditional fund pays a third party for this is independence rather than capability: a manager can compute a NAV, and an administrator computing it means the number was produced by a party whose compensation does not move with it. Every design decision in onchain fund operations should be checked against that question: who computed this, and what do they gain if it is wrong.

For the plain definition, see what is onchain fund administration.

What changes onchain, function by function

One function gets materially better, two get harder, one simply changes shape, and one disappears unless somebody rebuilds it deliberately.

The valuation row is where most of the difficulty concentrates. ERC-4626 defines totalAssets as the total amount of the underlying asset managed by the vault, and specifies that it must be inclusive of any fees charged against assets. That works cleanly when every position is a contract balance the vault can query in the same transaction. It does not extend to a tokenized fund holding that settles on its own schedule, a position whose value depends on an offchain event, or an asset that is temporarily untradeable. A vault that cannot read a position cannot price it, and a NAV that silently omits an unpriceable position is wrong in a direction that always favours the fund.

Independence is the row that ends up in an audit finding, because it is the one the chain does not supply on its own.

Who does each job when there is no administrator?

The jobs are already assigned, to smart contract logic, to admin keys and to the manager, usually without a document saying so. Morpho's vault role model is a useful published example of how these permissions get split in practice. The owner controls top-level permissions and can appoint the curator and sentinels, with no direct control over assets or risk parameters, while the curator configures adapters, caps, fees and interest rate limits, with most actions timelocked and cap decreases permitted immediately. The allocator moves assets between enabled adapters. The sentinel can deallocate, decrease caps, or revoke pending timelocked actions. Performance fees are capped at 50% and management fees at 5%.

Map that onto the five administrative functions and the assignment becomes visible:

1. The accounting record is held by the chain, and is complete for anything onchain. Nobody owns the reconciliation to an offchain general ledger. This is a job, and it is usually unassigned.
2. Valuation is performed by contract logic for readable positions. For anything else, someone submits a value. Whoever holds that permission is the fund's pricing committee, whether or not they have been told.
3. Subscription and redemption processing is contract logic for the synchronous path. For the asynchronous path, someone decides when a request becomes claimable and at what rate. That is a dealing decision with economic consequences for the investors on both sides of it.
4. The register is the token contract. Eligibility and transfer restrictions are enforced by whatever gate sits in front of it, and by nothing if no gate exists.
5. Reporting has no default owner at all. Data being public is not reporting.

The practical instruction is a permissions inventory: every address with a privileged role, what it can change, whether the change is timelocked, and who at the manager controls the signer. Write it as a table and give it to the audit committee before they ask. The role model in how vault curation works shows what those privileges typically look like.

How is NAV calculated and signed off?

Calculation is a contract reading positions. Sign-off is a documented human process for the positions the contract cannot read, and for the exceptions. Funds that skip the second half discover the gap at the first month-end where something is untradeable.

A workable process has six steps.

1. Define the valuation point. Onchain systems compute continuously, convenient but not a valuation point. Pick a block height or a timestamp, state it in the fund documents, and value against it. Registered funds are required to compute NAV at least once daily, Monday through Friday, at times the board sets. A daily point is the convention auditors expect even where it is not required.
2. Enumerate positions from the chain, not from a spreadsheet. Every adapter, every underlying market, every token balance, at the chosen block. The enumeration should be reproducible by a third party from public data.
3. Apply a written pricing hierarchy. Contract-readable balances come first, then observable market prices with the source named, then a model with the inputs named, then a fair value determination by a named committee. The hierarchy is the document an auditor reads before looking at any number.
4. Handle unpriceable positions explicitly. A position that cannot be valued gets flagged, not omitted or carried at cost by default. The treatment should be stated in advance: side-pocket it, hold it at the last observable price with a disclosed haircut, or suspend dealing. Deciding this after a position becomes unpriceable is deciding it under pressure and in the fund's favour.
5. Accrue fees on the same schedule. Management fees, performance fees and any high-water mark calculation are applied at the valuation point rather than at interaction time, so two investors dealing on the same day get the same treatment.
6. Sign off, and record who signed. One named person or committee, with the exceptions listed and the fair value determinations attached. The artefact, rather than the number, is what makes the NAV auditable.

Two mechanical warnings. ERC-4626 instructs implementations to round down when issuing shares and round up when calculating what a user must supply, so rounding favours the vault. That is a sensible anti-manipulation default and it means share price is not exactly symmetric between entry and exit, a fact that needs disclosing. Separately, the standard states that its preview methods "are manipulable by altering the on-chain conditions and are not always safe to be used as price oracles." A NAV derived from those methods inherits that property, and so does anything downstream that consumes the NAV.

If you are designing the sign-off process for a live fund, talk to the Railnet team.

How do subscriptions and redemptions work with mixed settlement?

Synchronous and asynchronous dealing are two different operating models, and an institutional strategy nearly always contains both, a combination that is the hardest problem in onchain fund operations and is not solved by any single standard.

ERC-4626 is synchronous. A deposit mints shares in the same transaction and a redemption returns assets in the same transaction. The specification provides no mechanism for queuing, delayed processing or time-delayed claims. That is correct for a vault whose entire book is instantly liquid, and it stops being correct the moment the fund holds anything that settles on its own clock.

ERC-7540 extends ERC-4626 with asynchronous deposit and redemption flows, using three sequential request states. Pending means "a Request has been made but is not yet Claimable." Claimable means "a Request is processed by the Vault enabling the user to claim corresponding shares (for async deposit) or assets (for async redeem)." Claimed means the user has received the output token. Where a flow is not implemented as a request, it must use the ERC-4626 synchronous pattern, and where a request with a shared requestId becomes partially claimable, all requests with that id must become claimable at the same pro rata rate.

The standard handles the common case well. Three limits matter for a fund with mixed settlement. Cancellation is out of scope: the specification notes that cancelling a request "may not be straightforward or even technically feasible" and that "a separate EIP should be developed to standardize the behavior of cancelling a pending Request." The reference implementation is explicitly not usable as written; the spec says the code "is incomplete pseudocode used for example only and is no way intended to be used in production or guaranteed to be secure." And a fund whose book contains an instantly liquid lending position alongside a tokenized fund holding with its own subscription minimums and settlement window is running two settlement clocks against one share price, and the standard does not arbitrate between them.

That last case is not hypothetical. Ondo publishes OUSG with an instant mint and redemption path from a $5,000 minimum and a separate non-instant path with $100,000 investment and $50,000 redemption minimums, restricted to accredited investors who are qualified purchasers. A fund holding that alongside an onchain lending position has one leg that can be exited this block and one that cannot, and it has to decide who among the redeeming investors bears the difference.

The operational answers are dealing policy rather than code: a stated dealing deadline, forward pricing against the next computed NAV, a documented ordering rule for partial fills, and a gate that suspends dealing rather than paying out at a price nobody can defend. See how settlement works in an onchain fund.

How do share classes work onchain?

A vault share is one fungible token, so share classes have to be constructed rather than configured. There are three routes and each has a real cost.

ERC-4626 assumes one vault, one underlying asset and one share token: the standard describes an API "for tokenized Vaults representing shares of a single underlying EIP-20 token." Different fee terms, different currencies or different eligibility for different investor groups all break that assumption.

• Separate vaults per class. This is the simplest and most common route. Each class is its own contract with its own fee configuration. The cost is that the strategy has to be replicated or the vaults have to feed a shared allocation layer, and NAV then has to be consistent across contracts that deal independently.
• One share token, multiple entry points. ERC-7575 adapts ERC-4626 "to support multiple assets or entry points for the same share token," externalising the ERC-20 dependency through a separate share method so several vault contracts can issue and redeem the same share. That addresses multi-asset entry directly. It does not by itself give you differentiated fee terms per class.
• A permissioned token with transfer restrictions. Eligibility, jurisdiction and lockup enforced at the token level. This is where ERC-3643 and comparable permissioned standards apply, and the cost is that restricted shares cannot circulate through venues that have no way to satisfy the check, a cost set out in how compliance is enforced onchain.

Whichever route, fee differentiation between classes has to be accrued at the valuation point rather than netted at redemption, or one class subsidises another through the share price.

Reporting a position to an auditor

Three artefacts are the core of it: a dated valuation with its method, a complete transaction record for the period, and an independent verification of the holding. Auditors are calibrated on the offchain equivalents and will ask for those three whether or not your structure is regulated.

The calibration is worth knowing precisely, because it explains the questions. Under the custody rule for registered advisers, a qualified custodian holds client assets in a separate account under the client's name or in accounts containing only client assets, sends an account statement at least quarterly identifying the amount of each security and all transactions in the period, and the assets are verified by actual examination at least once each calendar year by an independent public accountant at a time chosen by the accountant without prior notice. Registered funds additionally price dealing at the NAV next computed after receipt of the order, with NAV computed at least daily on business days.

The full onchain audit pack expands those three into six items:

1. A position statement at the period-end block. Every holding, its quantity, its price, the price source, and the resulting value. The block height is stated so the statement is reproducible.
2. A full transaction record for the period, with hashes, mapped to accounting entries. This is not a block explorer export but a mapping from each transaction to the ledger line it produced.
3. The permissions inventory. Every privileged address, what it can change, and the timelock on each. Auditors treat an unrestricted admin key as a control deficiency.
4. The pricing hierarchy and the exceptions log. A note of the level each position was priced at, and every fair value determination with its rationale and signatory.
5. An independent verification. Address ownership attested by the custodian or key holder, and balances confirmed from public data by someone who is not the manager. The chain provides the data. Independence still has to be arranged.
6. A reconciliation to the general ledger, with breaks aged and explained.

The chain makes items one, two and five cheaper than their offchain equivalents. It does nothing for items three, four and six, and those are where onchain funds fail their first audit.

How does Railnet fit?

Railnet is the operating layer for onchain asset management: standardized execution across venues, one settlement state model, continuous position reporting, and mandate enforcement. It is vault infrastructure, the layer that holds a strategy along with its state, settlement and governance, between the yield venues it allocates into and the channels that distribute it to depositors. In traditional asset management, BlackRock's Aladdin is the operational and risk layer that standardizes accounting, compliance and portfolio transparency at scale. Railnet is the onchain counterpart, and fund administration is one part of that job.

The settlement point is the one that matters most here. Every capital movement runs through STEAM as a Query on a single state machine: EMPTY, PROCESSING, PAUSED, UNLOCKING, RECOVERING, REJECTED and SETTLED, with the last two terminal. The same machine covers both timings. A lending market deposit goes EMPTY to UNLOCKING to SETTLED inside one transaction. A tokenized treasury leg enters PROCESSING and can sit in PAUSED behind a KYC gate or a cooldown until the condition clears, on its own clock. Both are tracked in one standard, so a single subscription can fan into several Queries across sources and settle partially rather than reverting entirely. That is the mixed-settlement problem from the section above, handled as a state model rather than as two systems reconciled by hand.

There are things Railnet does not do. It is not an administrator and it is not independent of the manager who operates it, so it does not supply the independence that a third-party administrator supplies. It does not sign a NAV. It does not hold keys and is not a custodian. It produces the record and the exceptions; a named human still has to review them and put their name on the number.

What should you do next?

• If you are standing up a fund, start with the permissions inventory in who does each job. It takes an afternoon and it is the document everything else references.
• If NAV sign-off is the open question, write down who strikes the number and who may change the method, and keep the two apart.
• When the fund holds anything that does not settle instantly, read how settlement works in an onchain fund before choosing a standard.
• With an audit scheduled, work through the six-item pack above and find out early which of the items nobody owns.
• Implementation details, including the settlement states and the reporting surface, are at docs.railnet.org.

See all questions on onchain fund operations

• What is onchain fund administration?
• What is settlement, onchain and off?

FAQ

What is onchain fund administration?

The operational layer between a strategy and its investors: maintaining the accounting record, computing and signing off NAV, processing subscriptions and redemptions, maintaining the register and share classes, and producing investor and audit reporting. Onchain, no third party performs these by default, so each function is distributed across contract logic, admin keys and the manager.

Does a smart contract replace a fund administrator?

It replaces the calculation, not the administrator. A contract can compute a share price from positions it can read, continuously and without error. It cannot value a position it cannot see, cannot exercise judgment on an exception, and is not independent of the manager who deployed it. Independence and judgment are what a third-party administrator supplies.

How often should an onchain fund compute NAV?

Pick a stated valuation point and hold to it. Continuous computation is not a valuation point, because two investors dealing at different times get different treatment with no documented basis. Registered funds must compute NAV at least once daily on business days at board-set times. Daily is the convention auditors expect.

Can ERC-4626 handle a fund with delayed redemptions?

No. The standard is synchronous and provides no queuing or delayed claim mechanism. ERC-7540 adds asynchronous requests with Pending, Claimable and Claimed states and pro rata partial claimability for shared request ids. Cancellation is explicitly left to a future EIP.

How do you run multiple share classes onchain?

Three routes: a separate vault per class, one share token with multiple entry points under ERC-7575, or a permissioned token enforcing eligibility at transfer. Whichever you pick, differentiated fees must accrue at the valuation point rather than at redemption, or one class subsidises another through the share price.

What do auditors ask for first?

The permissions inventory. Every privileged address, what it can change, and the timelock on each. Public transaction data answers completeness questions quickly, so the audit focus moves to control: who could have changed the fund's positions or its valuation, and what stopped them. An unrestricted admin key is treated as a control deficiency.

Who signs off the NAV?

Somebody named, in every structure that survives an audit. The contract computes; a person or committee accepts the computation, reviews the exceptions, and records the fair value determinations. If no such person exists, the honest answer is that the manager signed off on their own valuation, and that should be disclosed rather than left implicit.

Talk to the team

If you are building the operating model for an onchain fund, or working out who signs the NAV, talk to the Railnet team. There is no form to fill in first.