Subscriptions, Redemptions and NAV: Running a Tokenised Fund Day to Day

The interesting engineering in a tokenised fund is not the issuance. It is Tuesday: an order arrives at 11:40, the valuation point is noon, the cash lands on Thursday, and the investor has been told that tokenisation makes settlement instant. Reconciling that promise with how funds actually price is where these programmes succeed or quietly stall.

The dealing cycle, and why it resists compression

An open-ended fund typically deals on forward pricing: orders received before a cut-off are executed at the next valuation point, at a price not yet known. This is not an artefact of legacy systems. It exists so that an investor cannot subscribe or redeem at a price they already know to be stale — which would let them extract value from the investors who stay.

That single rule constrains everything downstream:

Subscriptions

You cannot mint units before you know the price, and you should not mint them before you have the money. That leaves three workable patterns:

• Pre-funded. Cash arrives before the cut-off and sits in a subscription account; units are minted at the struck price. Clean, and it moves the delay to the investor, who dislikes it.
• Escrowed tokenised cash. The investor locks a stablecoin or tokenised deposit into an escrow at order time; at pricing, the escrow releases to the fund and units mint in the same transaction. This is the design that genuinely compresses the cycle, and it requires the cash leg to be tokenised on a ledger you can settle against.
• Deferred settlement. Units mint at pricing, cash follows on the normal rail. Fast for the investor and it creates a receivable — the fund carries counterparty exposure until the money arrives, which the prospectus and your risk framework must permit.

Redemptions

Redemptions carry the harder problems, because they interact with liquidity. Notice periods, gates, swing pricing and in-kind redemption exist to protect remaining investors when many holders leave at once — and none of them disappear because units are tokens.

They do become enforceable in code, which is an improvement worth having. A gate that is a clause in a prospectus depends on someone applying it under pressure; a gate implemented as a compliance rule applies itself. Build the ability to burn on redemption, to apply a gate mid-cycle, and to settle in kind by transferring underlying positions — and test all three before you need them.

NAV on-chain: information or trigger?

Publishing NAV to a feed is straightforward. Deciding what depends on it is not.

As information, an on-chain NAV lets holders and integrators read the current price without a data agreement. Useful, low-stakes: if it is briefly stale, nothing breaks.

As a settlement trigger — minting units, releasing escrow, marking collateral — the feed becomes part of the transaction, and its assurance requirements jump. Who computes it, from what valuations, signed by whom, with what tolerance for staleness, and what halts if it is late? A fund administrator's NAV carries a chain of accountability built over decades; an oracle publishing a number does not inherit that chain automatically. Make the administrator the source and the feed a transport, not the other way round.

If a number moves money automatically, it needs the assurance of a valuation, not the convenience of a data feed.

Distributions and the snapshot problem

Paying a distribution requires knowing who held what at a moment. Off-chain, the register provides that at a record date. On-chain, balances change every block, so you need an explicit snapshot — a block height or timestamp at which entitlement is fixed, published in advance and honoured even as transfers continue.

Three details cause most of the pain:

• Transfers around the snapshot. A holder who sells just after the record moment still receives the distribution. That is correct and it surprises people, so document it.
• Where the payment goes. To the address holding at the snapshot, or to a payment instruction on file? For an investor who has since recovered to a new wallet, these differ.
• Withholding. Tax treatment varies by holder, so a pro-rata payment to every address is rarely correct. Entitlement is on-chain; the net payment is a function of off-chain facts.

Cut-offs do not survive a global holder base

A dealing cut-off is a wall-clock time in one place. Tokenisation removes the geographic limits on who can hold, which means an investor in another timezone now experiences your cut-off as arbitrary — an order placed during their business day misses a deadline that passed while they slept, and settles a day later than they expected.

There is no clever fix, only an explicit choice: publish the cut-off in a way that is unambiguous across timezones, state clearly which valuation point an order will reach, and confirm it back at the point of submission rather than in a document nobody reads. Most investor complaints in the first year of a tokenised product are not about technology; they are about an order landing in the next cycle, which is a communication failure wearing an operational costume.

Fees, and why they fight the token

Management fees accrue daily and are reflected in the NAV per unit. That works because, in a traditional fund, the unit is a claim on a pool whose value moves. It still works when the unit is a token — the token count stays constant and the price per unit absorbs the accrual — and that is the design to keep.

The temptation to avoid is expressing fees by adjusting balances: burning a fraction of every holder's tokens periodically, or minting units to the manager pro rata. Both look elegant and both create problems. A balance that changes without a transfer confuses every downstream system that treats a token balance as a settled position — custodians, collateral systems, accounting feeds — and it generates taxable events in some jurisdictions where an NAV accrual would not. It also breaks any secondary trade priced on the assumption that units do not evaporate overnight.

Performance fees add a second wrinkle: they are frequently calculated per investor, against that investor's own high-water mark, which is an off-chain fact about a holder rather than a property of the token. If a holder's units can move to another wallet, the high-water mark has to follow the investor, not the address — which is one more reason entitlement should be keyed to an identity rather than to a key.

The rule of thumb: let value live in the price and let the token count mean units held. Every design that violates that ends up reconciling against systems that assume it.

The shadow book you will run anyway

For at least the first year, the administrator will run the traditional book alongside the on-chain one and compare them. This is not a failure of ambition; it is how a regulated operation adopts a new system of record, and the parallel period is where you find the discrepancies you did not design for.

Budget it explicitly. Parallel running is the single most underestimated line in tokenisation business cases — it is two operating models at once, with reconciliation between them, for as long as your risk function requires before it will stand behind the new one alone.

Mapping a tokenised dealing cycle? SUPERBLOCK builds both legs — SBX Prime for issuance and the register, AURA for the payment side — which is the only way the cycle actually compresses. To walk through a timetable for a live fund, see what we build for asset managers — dealing, NAV and the cash leg — or request a demo.