On-chain vs traditional funds: what actually changes (and what doesn’t)

What’s changing now isn’t the idea of a fund. It’s the operating rails: how ownership is registered, how investors enter and exit from the fund, and how its lifecycle events (NAV updates, fee settlement) are recorded.

Traditional funds are already digital.

They run on elaborate back-office systems: onboarding portals with e-signatures, transfer agent workflows when distributing shares, custody and settlement rails, and cap table/register management software.

The friction in fund management, like most assets today, comes from fragmentation and isolation — too many systems, too many handoffs, and too much reconciliation for what should be a predictable lifecycle.

Moving fund on-chain isn’t binary. Most implementations sit on a spectrum, mixing traditional asset management on-chain registers and workflows.

Bringing a fund on-chain involves 3 layers

1) Ownership layer

This is the official record of who owns fund units and the conditions under which ownership can change.

• Traditional: the register lives in a transfer agent/administrator system, with reconciliations across distributors, custodians, and internal ledgers.
• On-chain: fund units are recorded on a shared ledger, so ownership updates become explicit events and can be aligned more tightly with transfer rules.

2) Operating layer

This is the fund’s operating flow: onboarding outcomes feeding subscriptions, subscriptions and redemptions tying into NAV events, and fees being calculated and recorded in a way the back office can audit reliably.

• Traditional: these steps are executed across multiple systems and parties, which makes the process more manual, slower to coordinate, and more exception-prone.
• On-chain: workflows can be coordinated end-to-end, with structured requests, pre-trade checks, and lifecycle events recorded consistently alongside ownership.

3) Portfolio layer

This is what the fund actually holds and where/how those assets are custodied.

• Traditional: the portfolio is held through existing custody/broker rails, and the fund’s view of holdings is assembled from statements and data feeds.
• On-chain: the portfolio is represented by on-chain instruments, which means the fund’s assets can be recorded on a blockchain at any time, with positions easier to observe and reconcile.

In practice, a fund can bring units and operations on-chain while keeping portfolio custody traditional — or move all three layers. Most real-world designs sit somewhere on that spectrum.

How the fund lifecycle compares between traditional and on-chain

Issuance

Issuance is the creation of fund units and the definition of how they behave (share classes, rights, restrictions, transferability).

• Traditional: units are issued and recorded in the administrator/transfer agent system, while restrictions are enforced through processes and counterparties.
• On-chain: units can be issued as digital instruments with holding and transfer rules enforceable as part of how those units work.

Onboarding

Onboarding is collecting investor information, running checks, and approving eligibility to subscribe, hold, and potentially transfer.

• Traditional: onboarding is handled through portals and document workflows, and eligibility is enforced through administrator rules, distributor checks, and manual approvals.
• On-chain: onboarding still exists, but the outcome can become a reusable eligibility state that is applied consistently across subscriptions, redemptions, and transfers.

Subscription

Subscription is when an investor commits capital and receives units in return.

• Traditional: an investor receives payment instructions, sends funds, and the payment is reconciled before the administrator updates the register and issues units according to cutoffs and dealing cycles.
• On-chain: the investor submits a structured subscription request that commits capital, eligibility is confirmed upfront, and units can be issued against confirmed payment to improve delivery-versus-payment (DvP).

NAV

NAV is calculating the fund’s value per unit and communicating it to the parties that rely on it.

• Traditional: NAV is calculated on a schedule using portfolio data collected from custodians/brokers/venues, then distributed through reports, portals, and operational messages.
• On-chain: NAV calculation can still happen off-chain, but the fund can notify the NAV on-chain for a dealing cycle so subscription and redemption requests automatically use that NAV as the reference price for issuing and burning fund units.

Redemption

Redemption is when an investor returns units and receives capital back (cash or in-kind, depending on structure).

• Traditional: redemption requests are collected and processed at the next dealing cycle, register updates are coordinated with the administrator, and payouts are executed and reported through manual operating steps.
• On-chain: redemption intent can be expressed as a structured request, redemption amounts can be computed and recorded as explicit liabilities linked to NAV events, and payouts can be coordinated with the burn/settlement of units more systematically.

Transfer & secondary

Transfers are ownership changes outside subscription/redemption, including secondary movement where permitted.

• Traditional: transfers are often possible in principle but operationally heavy, and restrictions rely on multiple intermediaries enforcing the same rules.
• On-chain: transferability is available by design, but not automatically “open.” Token mechanics and compliance rules can restrict who can receive units, when transfers are allowed, and under which conditions secondary movement can occur.

Fees

Fees are how the fund manager and service providers get paid (entry/exit fees, management/performance fees, administration fees).

• Traditional: fees are calculated in back-office processes and executed via manual transfers, with reporting back to administrators to keep the register, liabilities, and NAV consistent.
• On-chain: entry and exit fees can be automated as part of subscription and redemption workflows. Management, performance, and administration fees may still be calculated off-chain, but can be recorded as explicit liabilities tied to NAV events and settled through the same operating rails. If the portfolio is also on-chain, fee calculation and accrual can become more automated because positions and cashflows are easier to source programmatically.

Improvements when a fund goes on-chain

Single execution lowers operational friction

At a dealing point (daily/weekly/monthly), multiple subscriptions, multiple redemptions, fee accruals, NAV notification, register updates, and payouts can be coordinated as a single execution. This reduces handoffs, reconciliation loops, and the operational burden of handling many investors at once.

Clear auditability

Lifecycle events (issuance, eligibility changes, subscriptions, NAV references, fees, redemptions, transfers) can be recorded consistently, making it easier to show what happened, when it happened, and which rules or approvals applied.

Consistent and verifiable rule enforcement

Eligibility and transfer restrictions can be enforced consistently across issuance, subscriptions, redemptions, and transfers — reducing the risk of “policy drift” where different parties apply the same rule differently.

Example flow: a typical on-chain fund lifecycle (portfolio off-chain, operations on-chain)

This example describes a common setup today: the fund’s portfolio remains off-chain with traditional custody, while fund units and fund operations run on-chain.

1. Issuance of a share class token
2. The fund issues an ERC-20 that represents a share class. Holding and transfer rules are gated by compliance requirements associated with that share class.
3. Onboarding of an investor via automated KYB/KYC
4. The investor completes required checks and documentation. Once approved, the investor receives an eligibility status that can be used across fund actions.
5. Subscription request
6. The investor submits a structured subscription request that commits capital. Entry fees, if applicable, are applied automatically as part of the workflow.
7. Fund approval and NAV notification
8. The fund approves the subscription request and notifies the NAV for the dealing cycle. That NAV is used as the reference price so the number of fund units to be issued is calculated automatically.
9. Distribution of the fund shares to the investor
10. Fund units are issued and delivered to the investor in alignment with confirmed payment (improving DvP), and the register update is reflected as an explicit lifecycle event.
11. Redemption request
12. The investor submits a redemption request. Exit fees, if applicable, are applied automatically as part of the workflow.
13. NAV re-notification and redemption settlement
14. At the next dealing point, the fund notifies the new NAV to calculate the redemption price. Units are burned/returned, redemption liabilities are cleared, and proceeds are paid out with a clear, auditable event trail.
15. Management, performance, and administration fees
16. In this setup (portfolio off-chain), these fees are typically computed off-chain and recorded on-chain as liabilities tied to NAV events, rather than being manually transferred on-chain as ad hoc transactions.

Conclusion

Traditional funds rely on coordination across siloed systems to keep ownership, eligibility, NAV, fees, and payouts consistent. Bringing a fund on-chain modernizes those operating rails so the lifecycle becomes easier to execute, easier to audit, and easier to integrate into modern distribution channels.

Evergon leverages this technology to help teams bring funds on-chain across issuance, lifecycle workflows, and rule enforcement — enabling compliant distribution and streamlined fund operations without requiring teams to rebuild their entire stack from scratch.

‍