0:00
blogs

The next step for FTFs on Canton: upgrading the register

Matthew Longhurst
September 17, 2026
4 min

Matthew Longhurst explains how TreasurySpring is laying the foundations for Fixed-Term Fund share ownership records to be maintained natively on Canton, while preserving the familiar experience and safeguards that clients rely on today.

At a glance

  • TreasurySpring has been approved to become a Super Validator on Canton Network. A Super Validator is an approved institution that helps operate the network’s core infrastructure and participates in its governance. The role reflects our long-term commitment to Canton’s privacy-enabled institutional infrastructure and our intention to bring sustained Fixed-Term Fund (FTF) issuance activity onto the network. 
  • The first step is to upgrade the ownership register behind FTFs, not to change the product. We are developing the legal, operational, and technical foundations for the ownership records of a growing proportion of FTFs to be maintained natively on Canton. This is intended to establish a production model that can support ongoing FTF issuance, rather than serve as a one-off proof of concept. 
  • For most clients, the immediate effect should feel deliberately uneventful. Clients will continue to access, subscribe for, settle, and hold FTFs in the usual way, without needing to build a key-management system, appoint a digital-asset custodian, or operate their own wallet. The Transfer Agent, which maintains the legal register of ownership, will continue in that role, preserving operational continuity and the controls that apply today. 
  • Over time, this could make FTFs more useful as financial assets. Clients that choose to use approved wallet infrastructure could eventually transfer FTFs between approved entities, use them to access short-term liquidity, or post them as collateral. These capabilities will be optional and introduced at the pace appropriate for each client.

Laying the foundations

In February, we set out why TreasurySpring is working with Canton Network to explore how Fixed-Term Fund Shares (FTFs) could become more useful as financial assets. Our focus was on practical institutional use cases: moving FTFs between entities, using them to access short-term liquidity and posting them as collateral, all within a properly governed and privacy-enabled environment.

Those use cases remain our direction of travel. But before any asset can move efficiently through digital financial infrastructure, there needs to be a robust digital record of who owns it.

As part of this next phase, TreasurySpring has been approved to become a Super Validator on Canton Network. Our decision to pursue this role reflects our long-term commitment to Canton and to the privacy-enabled institutional infrastructure it provides. It also reflects our intention to use Canton to maintain ownership records for a meaningful volume of FTFs and thereby contribute to sustained ledger activity on the network. In doing so, we aim to demonstrate how shared-ledger technology can improve the administration, visibility and utility of established financial products.

That commitment is already being translated into practical work. We have been developing the legal, operational and technical foundations required for a growing proportion of FTF ownership records to be maintained natively on Canton. This is an important step, but its immediate effect should feel deliberately uneventful for most clients. The first stage is best understood as a back-end technology upgrade: improving the infrastructure beneath the FTF platform without changing the investment proposition or requiring clients to adopt unfamiliar technology.

Upgrading the register, not changing the product

Every FTF has a legal register of ownership maintained by the Transfer Agent. That register records which investor owns each FTF and is the authoritative record used throughout its life, from issuance through to maturity.

Today, the register is maintained through conventional transfer agency processes. This model works, but the information is held within systems operated by the relevant service providers and is not designed to support assets that may eventually need to move between different financial applications or counterparties.

The model we are developing allows an FTF's ownership record to be created and maintained directly on Canton. In other words, Canton would not simply hold a digital copy or representation of a separate register. For FTFs brought into the model, the shared ledger record is intended to form part of the authoritative register itself, subject to the same legal and operational controls that apply today.

This creates a common, privacy-enabled source of truth for TreasurySpring, the Transfer Agent and the relevant investor. It can provide the parties entitled to see the record with clearer and more direct visibility over ownership, without making that information public or exposing one client's holdings to another.

What changes for clients at the outset?

For clients who are comfortable with the existing model, very little should change.

Clients will continue to access TreasurySpring in the usual way. They will continue to subscribe for FTFs through the TreasurySpring platform, settle using established payment processes and hold their investments until maturity. The Transfer Agent will continue to maintain the register and perform its existing responsibilities.

Crucially, clients will not need to build a key-management system, appoint a digital-asset custodian or operate their own wallet simply because an FTF ownership record is maintained on Canton. In the first stage, the relevant ledger identities and supporting infrastructure can be controlled through TreasurySpring's existing node environment and administered as part of the register-maintenance process.

The Transfer Agent will also continue to operate its established register systems in parallel, maintaining a synchronised record alongside the Canton register. Together with TreasurySpring's own Canton node infrastructure, this preserves operational continuity and ensures that TreasurySpring and the Transfer Agent retain direct control of the ownership record without becoming dependent on any single external technology provider.

That allows us to introduce the underlying technology without transferring new operational responsibilities to investors. It also means that clients do not need to make an immediate decision about wallet infrastructure before they can benefit from a more modern ownership record.

This staged approach is intentional. We believe infrastructure should be introduced where it provides a clear benefit, not where it creates new work or risk for clients.

Why the back end comes first

There is a tendency in digital finance to begin with the most visible feature: a wallet, a token or a new trading interface. We think the more important starting point is the less visible one.

The register is the foundation on which every later use case depends. Establishing it natively on Canton means that FTFs can exist within the network as real financial assets with legally recognised ownership records, rather than as experimental digital replicas of assets administered elsewhere.

It also allows TreasurySpring to bring meaningful, recurring FTF issuance onto Canton before asking clients to change how they interact with those investments. FTFs are issued and mature continuously across multiple currencies and maturities. Recording that activity on Canton creates sustained institutional use of the network and lays the groundwork for additional functionality to be introduced when clients are ready for it.

This is why we see the register project as infrastructure rather than a proof of concept. The immediate objective is not to demonstrate that one isolated transaction can be completed. It is to establish a production model that can support a material and growing proportion of FTFs over time.

An optional path to wallet-held FTFs

Once FTF ownership is recorded natively on Canton, we can begin to make wallet functionality available to clients who want it.

Under this model, an eligible client could choose to hold an FTF through its own approved third-party wallet infrastructure. The wallet would give the client a more direct way to view and, where permitted, initiate activity involving its FTF holdings. For institutions already developing digital-asset or tokenised-finance capabilities, this could allow FTFs to sit alongside other financial assets within their chosen infrastructure.

This will be an option, not a requirement. Clients that prefer the existing model can continue to rely on the Transfer Agent-controlled infrastructure. Clients interested in wallet-based use cases can adopt them in a controlled way, following the necessary onboarding, technical integration and risk disclosures.

The important point is that the back-end register does not need to wait for every investor to become wallet-ready. We can modernise the common infrastructure first, then add client-facing capabilities at the pace appropriate for each client.

What wallet-enabled utility could look like

Holding an FTF through wallet infrastructure is not an end in itself. Its value comes from the transactions that a digital ownership record could support.

The first use cases we envisage are practical extensions of activities institutional treasury teams already undertake.

One is an intra-group transfer. A group may hold cash across several subsidiaries or investment vehicles and need to move an asset from one approved entity to another. Today, that process can require manual instructions and coordination between multiple parties. A wallet-initiated transfer could make the process more direct while preserving the Transfer Agent's approval and the integrity of the register.

A second is borrowing or repo against an FTF. An investor holding a term asset may occasionally need liquidity before the FTF matures. Rather than selling or disrupting the underlying investment, the investor could potentially use the FTF as security for short-term borrowing from an approved institutional counterparty. This could be particularly useful outside normal operating windows or where liquidity is needed for a defined period shorter than the remaining FTF term.

A third is collateral posting. FTFs provide exposure to high-quality short-dated assets, including government securities and secured reverse repo. Subject to a counterparty's eligibility and risk requirements, a wallet-held FTF could potentially be posted as collateral for derivatives, financing or other institutional transactions.

In each case, the objective is not to replace the governance around the transaction. It is to make the asset easier to identify, control and move once the relevant parties have approved its use.

Institutional controls remain central

The legal register cannot operate on the basis that possession of a private key overrides every other consideration. Funds and their service providers must be able to comply with court orders, correct errors and protect investors when access credentials are lost or compromised.

For that reason, the Transfer Agent will remain central to the model. Wallets eligible to hold FTFs will need to be approved and associated with fully onboarded parties. Wallet-initiated transactions will remain subject to the Transfer Agent's sign-off and the applicable legal, regulatory and contractual requirements.

The infrastructure will also preserve the ability to freeze an asset, correct the register or complete a controlled transfer where required or permitted by law. If an investor loses access to its wallet keys, there must be a governed route through which ownership can be verified and the asset recovered to replacement infrastructure. These are not exceptions to the system. They are essential features of an institutional ownership framework.

This is one of the reasons Canton is well suited to the project. Its privacy model allows transaction data to be shared only with the parties that need to see it, while its architecture supports the controls required of an authorised register. It provides many of the efficiency benefits associated with shared-ledger technology without treating financial assets as anonymous bearer instruments circulating on a public network.

A measured path to greater utility

Our direction has not changed since our first update. We want FTFs to become more useful to the institutions that hold them, particularly where those institutions need to mobilise liquidity or collateral without compromising the quality of their underlying cash investments.

What has changed is that the foundations are now becoming more concrete. The first step is to place the native ownership record for a growing proportion of FTFs onto Canton and establish sustained issuance on the network. The next is to offer approved wallet infrastructure to clients that want more direct control. From there, we can develop specific transfer, financing and collateral use cases with clients and institutional counterparties where there is genuine demand.

This is an evolution of TreasurySpring's infrastructure, not a change in what TreasurySpring does. We will continue to provide institutional clients with efficient access to high-quality cash investments. Canton gives us a way to improve the infrastructure beneath those investments and, over time, make them capable of doing more.

For clients who value the existing experience, that experience can remain familiar. For those ready to explore wallet-based ownership and new forms of utility, the path is beginning to open.

TreasurySpring's blogs and commentaries are provided for general information purposes only and do not constitute legal, investment or other advice.

Subscribe to Insights

Explore flexible, diversified funding, built around your requirements.

We may use your contact details to follow up on your enquiry and to share information about similar products or services that may be relevant to you. You can opt out at any time. For more information, please see our privacy policy.
Subscribe
Thank you!
Your submission has been received. We will get back to you as soon as possible.
Oops! Something went wrong while submitting the form. Please try again.