The Ledger That Remembers Why

Finance is moving from digitising records to digitising execution. That changes what the infrastructure beneath it has to prove.

For decades, financial technology has become progressively faster. Trading became electronic. Payments became real-time. Risk moved closer to the front office. Settlement cycles compressed. Algorithms replaced manual execution. Now AI agents are beginning to make decisions and initiate transactions on behalf of people and institutions.

Yet an important part of the architecture has barely changed.

A financial transaction is still more than a movement of value. It is an exercise of authority under a set of rules.

Someone, or increasingly something, must have been permitted to initiate it. The asset must have been eligible to move. Limits may have applied. Both sides of an exchange may have needed to settle together. And afterwards, an institution, counterparty or regulator may need to establish exactly what happened and why.

Historically, much of that trust has existed around the transaction. People supplied it. Institutions attested to it. Policies described it. Messages transported parts of it. Compliance systems checked it. Reconciliation reconstructed it.

Automation changes the equation. As the human disappears from the workflow, the judgement that human once absorbed does not disappear with them. It has to become machine-readable.

The limiting question is no longer only how quickly a system can change financial state. It is whether the basis for that state change can be verified without reconstructing trust afterwards.

Call that verifiable finance.

And if finance is going to operate increasingly at machine speed, the objective becomes verifiable finance at scale.

Tokenisation is becoming execution

This is no longer primarily a crypto-native argument.

The official sector is arriving at much the same architecture from another direction.

The Bank for International Settlements describes tokenisation as more than putting an asset onto a digital ledger. A token combines the record of the underlying asset with the rules and logic governing how it can be transferred. The consequence is important: payment instructions, asset movements, reconciliation and settlement can begin to collapse into a single programmable operation.1

That is a much bigger idea than replacing a security identifier with a token.

It turns financial claims into executable objects.

Delivery-versus-payment is a useful example. Instead of one system moving cash, another moving securities and operational processes reconciling whether the two happened correctly, each leg can become conditional on the other.

The same principle extends much further: collateral eligibility, issuance controls, settlement conditions, authority limits, compliance checks and eventually machine mandates can all begin to participate directly in execution.

That transition is the real opportunity behind tokenisation.

AI makes the requirement impossible to ignore

Agentic finance sharpens the same problem.

An AI agent can reason probabilistically. It can interpret an objective, evaluate alternatives and decide what action it believes is appropriate.

Money cannot settle probabilistically.

The IMF makes precisely this distinction in its 2026 work on agentic payments. Its architecture separates probabilistic intent and orchestration from a strictly rules-based authorisation boundary and deterministic settlement beneath it.2

Intelligence may be probabilistic. Financial authority should not be.

An AI agent may decide to buy an asset. The financial infrastructure still needs to establish whether that agent had authority to buy it, for whom it was acting, what limits applied, whether the asset was eligible and whether settlement was final.

The same requirement already exists when the actor is a trader, an algorithm, a treasury application or an automated collateral process.

Agentic finance therefore does not require an entirely different financial substrate. It exposes what a highly automated institutional substrate needs to look like.

Institutions and autonomous agents converge at the execution boundary.

Seven substrate principles for verifiable finance

These ideas are emerging from several directions. BIS and CPMI-IOSCO work addresses programmable settlement and finality; the IMF separates probabilistic agent reasoning from deterministic authorisation; Project Mandala explores privacy-preserving compliance; and Tom Zschach’s recent writing on scalable trust highlights portability, machine-verifiability, confidentiality, auditability and provenance.910

Taken together, they point to a deeper architectural question: what must the execution substrate itself guarantee?

I propose seven principles. They are deliberately technology-neutral and should be applicable to Radix, Canton, a future central-bank platform or a system that has not yet been invented.

The important point is not the number seven. It is the shift in emphasis.

A blockchain should not be judged only by what it can execute.

For finance, it should increasingly be judged by what it can establish about that execution.

Why Radix is interesting

This is where Radix enters the argument, not before.

The seven principles should not be considered valid because Radix happens to satisfy some of them. The stronger test works the other way around:

Radix becomes strategically interesting to the extent that its architecture satisfies the requirements of verifiable finance.

There is something distinctive here worth examining.

Radix starts from an architectural decision that remains unusual: assets are native resources understood by the execution environment.

A resource is not simply a convention encoded inside a token smart contract. The Radix stack understands resources as first-class objects with system-enforced behaviour. Wallets and other applications can therefore reason about important properties of an asset without first interpreting arbitrary token contract code.3

That decision propagates through the architecture.

Resources live in native containers. Proofs of resources can participate in authorisation. Roles and access rules govern privileged actions. Transaction manifests explicitly orchestrate interactions between resources and components.

If an authorisation rule is not satisfied, execution aborts.4

Pre-authorisations and subintents add another significant primitive: one actor can authorise a constrained piece of a transaction for later inclusion by another actor inside a larger atomic transaction.5

Consider what that could mean for finance.

An institution does not necessarily need to give an agent unrestricted control of an account. It could instead authorise a bounded action: a particular resource, under defined conditions, within a validity period, as one part of a wider transaction.

The institutional semantics still need to be built around that primitive. But the primitive itself is important.

The unresolved question is who attests that authority. One existing institutional model is the GLEIF vLEI ecosystem. A Qualified vLEI Issuer can issue a credential to a legal entity and, under a governed credential chain, issue credentials for official organisational roles. That gives a financial substrate something more meaningful than a signature alone: a cryptographically verifiable assertion that a person or role is acting for a recognised legal entity under a governed trust framework.12

The substrate does not need to become the identity authority. It needs to be able to verify such attestations and allow a credentialled role to delegate a narrower, expiring mandate to a machine or agent.

This is the deeper Radix proposition. It is not a list of blockchain features. It is the coherence of a model in which assets, authority and transaction intent participate in the same execution environment.

The gap that matters most: privacy with proof

There is also a reason Radix is not yet a complete institutional answer: privacy.

Financial markets cannot operate on the assumption that every position, counterparty relationship, client identity, trading strategy and commercial term can be published globally.

But complete opacity is not the answer either.

A counterparty may need to establish that a holder is eligible. A regulator may require information the public should not see. An institution may need to prove that a transaction remained inside a limit without revealing the limit itself. A machine may need to establish that another machine possesses a valid mandate without learning everything contained in its underlying identity record.

Financial institutions need confidentiality. Counterparties, operators and supervisors need verifiability.

A fully transparent system sacrifices the first. A fully opaque system sacrifices the second.

The requirement is therefore not privacy alone. It is confidentiality without surrendering verifiability.

This is already becoming a real financial architecture pattern. BIS Project Mandala, for example, explored cryptographic compliance proofs and privacy-enhancing techniques so that compliance assertions can accompany transactions without necessarily exposing the information used to derive them.6

For Radix, this is not simply a missing privacy feature. It is the hinge of the institutional proposition.

If Radix can combine its open, asset-oriented execution model with confidential but verifiable participation, it materially strengthens the case for institutional finance on an open substrate. If it cannot, the institutional ceiling remains.

A credible solution should eventually answer questions such as: can an investor prove eligibility without revealing its identity publicly? Can an institution prove a limit was respected without exposing the limit? Can a supervisor receive greater visibility than an ordinary network participant? And can those properties coexist with atomic composition between financial applications?

Radix does not provide a general institutional solution to those questions today.

That should be said plainly.

It is not a reason to weaken the vision. It defines the most important part of the work ahead.

Canton shows why the privacy problem is real

Canton is useful here because it provides a concrete example of the requirements financial institutions already consider important.

It has been designed around privacy, controlled visibility, independent applications and atomic coordination between participants.

Canton's Global Synchronizer allows transactions across independent applications while its privacy model means only relevant stakeholders see and record the parts of a transaction they are entitled to see.7

That is a serious architectural result. It also means the useful debate is no longer simply public versus permissioned; that distinction is becoming too crude.

Can open financial infrastructure combine broad composability with institutional confidentiality, explicit authority and verifiable execution?

Canton approaches that problem from privacy and controlled visibility. Radix approaches it from shared, asset-oriented execution. Other architectures will approach it differently again.

These systems may coexist. They may also converge toward similar requirements from different architectural starting points.

For Radix, Canton should therefore be treated as evidence of what institutions already require, particularly privacy, selective visibility and coordinated settlement, and as a benchmark against which an open, asset-oriented execution model should be tested.

The more interesting question is not whether one architecture replaces the other. It is whether Radix can preserve the openness and composability of its execution model while adding the confidentiality and institutional control that serious financial markets require.

Hyperscale has changed: the vision should change with it

Scaling is the second half of the argument, and it is important to be precise about what Hyperscale now means.

The earlier Foundation-led programme should be treated as historical research rather than as the forward-looking architecture. The active effort is now the community-led hyperscalers/hyperscale-rs implementation. That work is no longer only an informal community project: the April 2026 Xi’an RFC proposes a concrete path from the current prototype toward a production-ready, linearly scalable Radix implementation, with milestone-based delivery and a mainnet-ready target. The proposal is concrete; the implementation remains work in progress.13

The implementation will necessarily evolve as Radix moves toward a horizontally scalable architecture. But that should not obscure the objective.

Hyperscale should be about scaling the Radix Engine, not scaling a benchmark.

The Radix proposition is not simply that transactions can be processed quickly. It is an asset-oriented execution model in which resources, authority and transaction intent participate in the same environment, with predictable and atomic outcomes.

The discipline should therefore be to add capacity inside that execution model, not around it.

Hyperscale should allow the Radix Engine to operate horizontally across increasing numbers of shards while preserving the properties that make it valuable: asset integrity, explicit authority, predictable transaction outcomes, atomic composition, deterministic execution, auditability and, ultimately, confidential verification.

That does not mean freezing today's implementation. The Engine itself can evolve. Its internal architecture, data structures and execution mechanics may need to change substantially as Xi’an and the community-led Hyperscale work develops.

But those changes should serve one purpose: to make the Radix Engine scale without giving back the properties that distinguish it.

This changes how success should be measured.

A headline TPS figure can demonstrate raw capacity. It cannot demonstrate that the Radix Engine itself has scaled.

The stronger test is whether components can call components, resources can move between vaults and accounts, authorisation rules can be evaluated and multi-party transactions can remain atomic across the scaled architecture under real workloads and at meaningful volume.

The question is not simply: how many transactions can Hyperscale process? It is: does the Radix Engine scale?

If scaling sacrifices the properties that make the Radix Engine valuable, a higher throughput number is the wrong trade.

Throughput is an output of the test. It is not the purpose of it.

That is the connection back to the wider vision: the Radix Engine provides the execution model for verifiable finance; Hyperscale should allow that same model to operate at market scale.

There are two ceilings

This creates two different constraints.

The first is verifiability.

Participants need enough evidence to rely on the transaction: the asset was valid, authority existed, controls were satisfied, execution was atomic and the result is final. The objective is not to manufacture trust, but to reduce the amount of trust participants must reconstruct outside the execution itself.

The second is capacity.

Once the first property exists, the system must be capable of carrying real markets.

These two goals cannot be traded casually against each other.

Verification without capacity produces an elegant system that cannot host meaningful economic activity.

Capacity without verification produces fast state changes and pushes the difficult trust problem back onto institutions surrounding the network.

The opportunity is to solve both:

Verifiable finance at scale.

That should be the north star for the architecture.

Build the proof in public

The practical consequence is straightforward. Radix should stop asking institutions and its own community to imagine what this architecture could mean for finance.

Build it.

Not an entire bank or another generic DeFi ecosystem, but a stylised financial-market reference system.

Issue tokenised commercial-bank money and exchange two currencies atomically.

Issue a digital bond. Define who can hold it. Settle it delivery-versus-payment. Pay a coupon. Redeem it.

Represent collateral eligibility and haircuts. Execute repo. Perform a collateral substitution.

Give a machine a tightly scoped mandate. Let it execute only within that mandate. Revoke the authority and show that the next action fails.

Introduce a compliance-gated asset.

Then attempt the harder demonstration: prove eligibility without disclosing the holder's underlying information.

Where the architecture works, show it. Where it does not, expose the missing primitive.

The same workloads can become the tests for hyperscale-rs.

Instead of asking how many synthetic transactions the network can process, ask how many concurrent DvP settlements, collateral movements, multi-party authorisations and lifecycle events it can execute while preserving the required invariants across shards.

That is a benchmark financial institutions can understand. And because the work is public, they do not have to accept the claims on trust; they can inspect them.

A different way to go to market

That points to a different strategy for Radix.

Do not begin by claiming to be the institutional blockchain.

Begin by publishing a view of what institutional-grade digital finance actually requires.

Make the seven principles open to criticism. Build implementations against them. Invite Radix developers and community members first, then market practitioners, institutions and competing ecosystems, to challenge the assumptions.

Where another architecture does something better, acknowledge it. Where Radix lacks a capability, make the gap explicit. Then build.

That approach may sound less like traditional crypto marketing. That is precisely why it could work.

The market Radix ultimately wants to address is professionally sceptical. Banks, market infrastructures and regulated financial institutions do not need another claim that a blockchain is fast, secure, revolutionary or institution-ready.

They need to understand the architecture, the assumptions and where the boundaries are.

Credibility will come from showing them.

What should the Radix community commit to?

This is not a proposal for a centrally owned roadmap. It is a proposal for a set of invariants against which different roadmaps, implementations and community initiatives can be judged.

Not a feature list.

Not a TPS target.

Not a prediction that one competing network will disappear.

A set of architectural outcomes.

Assets whose fundamental behaviour the platform understands.

Execution that can enforce deterministic controls atomically.

Authority that can be bounded, delegated and ultimately connected to real institutional identity.

A record that allows entitled parties to understand what happened and under whose authority.

Confidentiality that does not require surrendering verifiability.

Interoperability that preserves relevant trust rather than simply moving representations between networks.

And a community-led scaling architecture capable of carrying all of that at market volume.

Those outcomes are harder to communicate than a headline performance number.

They are also far more valuable.

The ledger that remembers why

Finance does not lack databases.

It does not lack messaging systems.

And increasingly, it does not lack computational speed.

What it still lacks is a universal execution environment in which the asset, the authority to act on it, the deterministic rules governing the action and the evidence produced by execution can participate in one coherent model.

That is what makes the next stage interesting.

A financial transaction is not merely:

For serious finance, the system increasingly needs to be able to establish something closer to:

And where confidentiality requires it, the system should be able to establish those facts without revealing information the observer has no right to see.

That is a much higher standard than moving tokens quickly.

Radix already provides meaningful pieces of that model through asset-oriented execution, explicit authorisation primitives and atomic transaction construction. But the institutional thesis remains incomplete: privacy-with-proof is the most important gap, institutional attestation needs to mature, trust-preserving interoperability remains open, and community-led Hyperscale still has to show that verifiability survives horizontal scaling.

Those are not footnotes. They are the roadmap this vision asks the community to adopt.

Verifiable finance at scale: financial infrastructure in which assets, authority and execution rules are machine-verifiable, confidentiality coexists with verification, and the resulting system can scale without giving those properties back.

If that architecture can be built, institutional tokenisation and agentic finance start to look less like separate futures and more like different actors operating on the same foundation. Humans decide, institutions govern, agents reason, machines execute. The substrate provides the deterministic boundary beneath them.

A ledger that remembers what moved is a database. The financial substrate we are heading toward needs to establish more: why the movement was permitted, who had authority, which rules applied and what finally happened, at the speed of the machine and the scale of the market.

That is the ledger that remembers why.