On-Chain Finance Needs A Control Plane

Digital Asset Summit 2026 was all about investment products on-chain. Franklin Templeton partnered with Ondo Finance to tokenize ETFs, Invesco are managing $900M of a Superstate T-Bill fund on-chain, NYSE and Securitize are working together for on-chain securities. The phrase "on-chain finance" is becoming shorthand for a structural shift in how capital markets infrastructure gets built, and it is accelerating. However "on-chain" is doing a lot of heavy lifting in these announcements. Focussing on blockchain settlement rails. What we need is an on-chain control plane for these products.

What the public chain actually gives you

Tokenization offerings sit on public blockchain infrastructure and enables ETF positions to be held in crypto wallets, traded around the clock, and settled without the friction of traditional market hours or brokerage intermediaries. That is a real improvement.

The public blockchain underneath gives you:

1. A transaction hash - immutable, timestamped, permanent

2. A public record of who sent what, to whom, in what amount

3. Composability - the ability for other protocols and systems to read and build on that state

This is the what layer. It answers: what happened?

This is a meaningful improvement over the fragmented, intermediary-heavy infrastructure that traditional finance still runs on. The public blockchain is the right place for the final record. It is the single source of truth for what settled, and that is exactly where that responsibility belongs.

However for a regulated financial product, "what happened" is the easy question.

The question the public chain cannot answer

External stakeholders and actors in the value chain such as the fund administrator, a depositary, a regulator not only want to know that a transaction occurred. They want to know why it was permitted.

1. Was the investor KYC-verified and AML-screened at the point of execution?

2. Was the price used for that redemption tied to a current NAV, or a stale one that gave the investor an information advantage over other unitholders?

3. Had the daily or per-investor redemption limit already been reached before this request came in?

4. Was every investor treated equally, or did some receive better pricing or faster access than others?

5. Were all pre-trade controls applied before the transaction hit the chain, or only as a post-trade overlay after the fact?

The public blockchain record is structurally silent on every one of these questions. It records the outcome. It has no knowledge of the conditions that governed whether that outcome was permissible.

This is not a criticism of public blockchains. It is a description of what they are: settlement and state layers.

Some of this can be partially addressed at the token level. Permissioned token standards such as ERC-3643 on Ethereum enforce KYC whitelisting at the point of transfer — they can determine who is permitted to hold a token. Solana has developed equivalent functionality through its Token-2022 extensions program, which supports transfer hooks and permanent delegate controls for similar permissioning. Any new chain that wants to host regulated products will build its own version of this. That is a meaningful set of controls.

However it is not the control plane. It does not validate whether the NAV used for pricing was current at the moment of execution. It cannot enforce redemption caps dynamically across a population of investors in real time. It cannot produce a per-transaction conformity record that reconstructs the precise conditions under which a specific trade was permitted. Furthermore, since each chain develops its own permissioning standard, each deployment is separately coded, separately audited, and separately maintained. As chains compete and multiply, the fragmentation problem compounds. A control plane built on token-level standards is a control plane that has to be rebuilt for every chain. Token-level controls answer part of the "who" question. The control plane answers the "why, when, at what price, under what conditions, and with what record" once, and across all chains.

The gap is not in what the blockchain does. The gap is in what needs to happen before it does it.

The trade lifecycle is a sequential process, not just a final moment

Here is the part that most "on-chain finance" discussions under appreciate: a financial transaction is not a moment. It is a journey.

Consider a simple redemption request. An investor wanting to exit a tokenised fund position during the standard dealing window. The on-chain transfer that eventually settles that redemption is the last step in a sequence that looks something like this:

1. Intent: the investor signals they want to redeem a given amount

2. Pre-trade controls: the system checks: is this investor KYC'd and sanctions-screened? Is the current NAV fresh enough to price against? Have per-investor or aggregate daily redemption limits been reached? Does the destination address pass AML hygiene checks?

3. Pricing: the redemption amount is calculated against the validated NAV reference

4. Execution: the Fund token is redeemed and a pre-approved stablecoin type for settlement is sent to the investor

5. Confirmation: the on-chain transfer is verified and confirmed.

6. Settlement: the public chain ledger as shareholder registrar is updated.

The public blockchain is present at steps 5 and 6. The other four steps happen somewhere else. Ideally these are programmatic rules that are enforced and not some manual or off-chain process in legacy systems with warts and all.

What makes this harder is that the failure paths are as important as the happy path. What happens when the NAV feed is stale and the redemption cannot be fairly priced without creating an information asymmetry? What happens when a non-whitelisted wallet attempts a redemption? What happens when the counterparty claims a request but does not deliver within the required window?

Each of these is an event that needs to be handled deterministically, recorded completely, and resolved without creating a burden of manual intervention. The investor whose redemption was correctly rejected because the NAV was four hours old needs to know that and so does the fund's governance function, depositary, and regulator. A missing transaction on the public chain tells no one anything.

The control plane: where the journey lives

A natural question at this point is whether the control plane is simply a description of what transfer agents and fund administration systems already do. In traditional fund processing, the answer is largely yes — the transfer agent manages the dealing window, validates investor eligibility, applies redemption limits, and maintains the shareholder register. The control plane is not a new concept.

The more sophisticated tokenised fund implementations have begun bridging this gap in different ways, and it is worth understanding what they do and where they stop.

Franklin Templeton's tokenised money market fund uses what is sometimes called a digital twin model: the blockchain holds a secondary representation of ownership, while the primary shareholder register lives in a traditional transfer agent system. The legacy infrastructure does the control plane work: KYC, eligibility, NAV validation, redemption processing and the on-chain record is updated as a mirror afterwards. It is operationally conservative and legible to the regulator. However it captures few of the benefits of genuine on-chain execution. The control plane is still batch, still dependent on scheduled processing windows, and the blockchain is functioning more as a distributed ledger for transparency than as settlement infrastructure.

Securitize, acting as SEC-registered transfer agent and tokenisation platform for products including BlackRock's BUIDL fund, goes a bit further. Their platform handles KYC/AML onboarding and investor management, while smart contracts enforce token-level transfer restrictions on-chain. This hybrid model is more capable. Compliance and controls are more systematically applied than in the digital twin approach. However the control plane function is Securitize's own centralised infrastructure: clients depend on a single intermediary for the availability, integrity, and ongoing development of the control layer. We're back in the "trust us" game, and their implementation is Ethereum-specific, which returns us to the chain fragmentation problem.

These are steps in the right direction. Yet the gap that remains is a control plane that is: designed for 24/7 execution rather than batch processing, capable of real-time exception handling rather than next-day reconciliation, not dependent on a single intermediary to run infrastructure, and chain-agnostic by design rather than chain-specific by necessity.

The gap is that legacy systems were built for batch processing within defined dealing windows. They were not designed for continuous, automated, 24/7 on-chain execution and risk management. They were not built to validate a reference price in real time, hold a redemption request in a defined intermediate state pending a fresh NAV, handle a non-whitelisted wallet attempting an on-chain transfer at 3am, or produce a per-transaction conformity record in a format consumable by a blockchain-native fund administrator and depositary. The function is familiar. The implementation required for on-chain finance is not.

This is the role of what we think of as the control plane, the layer that sits between the investor's interaction with an investment product and the on-chain settlement event.

The control plane manages the full lifecycle of a financial transaction as a state machine. Every request enters a defined sequence of states. Every transition is governed by explicit policy. Every outcome (whether the redemption settled, was rejected, timed out, or failed) is recorded with the full context of why.

That context is the conformity record for each transaction: which pre-trade controls ran and what they returned, what NAV reference was used for pricing, what the limit status was at the moment of the request, which counterparty was assigned, how conduct obligations around best execution were satisfied. It is not a second ledger competing with the blockchain. The blockchain remains the single source of truth for what settled. The control plane produces the provenance of permission — the record of what had to be true, and was verified to be true, before that settlement was allowed to occur.

Think of it this way: the blockchain record answers "this transfer happened." The control plane record answers "here is the complete history of how we got there — every check, every decision, every path that was correctly evaluated before the permitted one proceeded."

For a fund administrator or depositary reconstructing why fifty redemptions were processed in a particular order on a given day, the blockchain alone is not enough. The control plane conformity record is what makes that reconstruction possible and what makes it defensible to a supervisor.

What a properly designed control plane needs to do:

Pre-trade controls applied at the point of execution. Controls that run pre-trade are a governance mechanism. Controls that run post-trade are a reporting mechanism. They are not equivalent. When an interested party asks why a transaction that should have been blocked was permitted to settle, "we identified it in the post-trade review" is not an acceptable answer. The distinction between pre-trade and post-trade is not procedural, it is the difference between a control and an observation.

Conduct obligations enforced systematically. Best execution is not a compliance checkbox it is a conduct obligation that requires the institution to demonstrate it took all sufficient steps to obtain the best possible result for the investor. For on-chain financial products trading around the clock, that means the reference price used must be validated as current before each execution, and the record of that validation must be retained. A system that cannot demonstrate this systematically cannot demonstrate best execution at all.

Deterministic exception handling. Every failure mode (stale reference price, failed KYC, limit breach, counterparty timeout) needs a defined resolution path that the system executes automatically and records completely. Exceptions handled by manual intervention outside the system are exceptions with no conformity trail, which doesn't scale (we're talking about 24/7 markets now) and is a weaker method of governance.

Chain-agnostic operation. A fund that issues on Ethereum today may need to support investors on Solana next year, or a new L2 the year after. Smart contracts are chain-specific so each deployment is a separate codebase with separate audit surface. A properly designed control plane runs the same pre-trade controls and governance rules across all chains. The settlement rail is pluggable; the policy is not.

Configurable human oversight. Fully automated processing is operationally efficient. But regulated institutions also need the ability to insert governance gates at specific points in the lifecycle, to require authorisation or perhaps swing pricing above a certain redemption size, or to suspend the facility during a market stress event. All without architectural changes.

Layers to on-chain finance

To help visualise this we can think of On-chain finance as spanning three distinct domains.

Domain 1: The Regulated Financial Product. Fund prospectus, formation documents, regulatory authorisation, NAV calculation methodology, depositary oversight, transfer agency, fund accounting. The domain that defines what the product legally is and how it must behave. Tokenisation does not replace this. It connects to it and must conform to it at every step.

Domain 2: The Control Plane. Pre-trade controls, conduct obligations, fund governance rules, lifecycle management, conformity records. The domain that governs what happens before and in the lead up to a settlement event. This is where investor intent becomes a verified, priced, policy-governed instruction. This is the domain that makes the final domain defensible.

Domain 3: The Settlement Rail. The public blockchain such as Ethereum, Solana, or whichever network the product issues on. Settlement, state, composability. The single source of truth for what settled. The domain that every announcement talks about launching products on.

Most announcements in the news cycle lead with Domain 3. It is the most visible layer and the one that most clearly demonstrates the tokenisation concept. Some implementations have begun to address Domain 2, and that is encouraging. However it remains the least cultivated layer: less visible than the settlement rail, less obvious than the fund structure, and considerably harder to build correctly than either. Firms like Cordial Systems who are going deep on it are finding that it is where almost all of the hard problems live.

The Franklin Templeton and Ondo announcement, like those before it, proves the concept at Domain 3: a fund position can exist as a token on a public blockchain, it can trade 24/7, it can be held in a self-custody wallet.

The next step is about making these products work as regulated financial infrastructure at scale, across chains, in a way that satisfies the full institutional stack from investor through to supervisory authority. That is a fundamentally different engineering problem, and it lives in Domain 2.

The ones who treat the settlement rail as the finish line will hit the same wall: the first time a trade executes against a stale reference price, or a large redemption causes the fund to bear disproportionate liquidity costs, or a supervisor asks them to reconstruct the precise conditions, and the conformity record to support them, under which a specific transaction was permitted at 2am on a Sunday.

That wall is Domain 2. And the time to build it is before you need it.

Sebastian Higgs is co-founder of Cordial Systems - providing institutional MPC wallet infrastructure and capital market solutions for regulated finance products on-chain.