Action-Based vs State-Based Systems: A Clear Path for Tokenised Securities
Tokenisation frameworks often fail to account for the core principles of blockchain technology. This article covers the critical differences between token- and account-based systems.
In my last article as part of the collaboration with The Securities Services Advisory Group (TSSAG), I covered account structures and related aspects that create challenges for tokenised securities on blockchain.
There is a raft of other issues, but one aspect I want to highlight in this article is the impact of the fact that blockchain operates on the principle of action-based proof, not on state—i.e., holdings.
This issue is mostly ignored, leading to impractical solutions that will fail to deliver benefits to the market. My comments are based on the design of public blockchains such as Bitcoin or Ethereum. Private chains can deviate because they could disable existing functionality or add additional features. Whether that reimagined solution still offers the benefits of a distributed, decentralised, and deterministic system that creates a shared ledger with verifiable records would depend on the actual implementation, but these benefits stem from the present design of blockchain. The only limit to redesign is a practical one: why use blockchain if users want functionality that blockchain doesn’t have or that would be incompatible with it?
The UK Jurisdiction Taskforce (UKJT) of LawtechUK published a legal statement on the issuance and transfer of digital securities under English private law in 2023 and found that the
“existing framework of English law supports the transfer and issue of securities using blockchain or distributed ledger technology. It highlights the benefits of the inherent flexibility of English law [..]”
Really? I don’t think we can be sure of that.
What the document describes is a model that involves blockchain but eliminates the very reason for using it in the first place, because it would require off-chain functionality to implement what they describe to such an extent that the blockchain records serve no other purpose than making the process unnecessarily convoluted and risky. The tension between blockchain's fundamental mechanics and the assumptions of the legal framework demonstrates a lack of understanding of how blockchain-based systems truly work.
If English law can support what is required to use blockchain effectively is another question that remains unanswered since their report doesn't actually cover this question. I want to use this article to describe why that is and what scenarios would be needed to use blockchain effectively. Would the UKJT be able to confidently confirm their previous assessment under the scenario I will describe? I have a hunch this is not going to be so easy in all scenarios, but maybe I underestimate the inherent flexibility of English law.
A draft Property (Digital Assets etc) Bill was introduced in the House of Lords in September 2024 to give effect to recommendations of the Law Commission for England and Wales, in particular confirming that property rights can be established for crypto-assets such as Bitcoin. The Law Commission stated:
“Legal rights (as opposed to things such as a crypto-token [note: calling crypto-assets a crypto-token is very problematic and makes the analysis difficult because a token has a specific technical meaning in blockchain and would not be used for Bitcoin]) that are created within blockchain or DLT-based systems or multilateral contractual frameworks will be treated as things in action by the law. Those things in action will therefore be different from, and will attract different legal treatment to, third-category things.”
Thus, crypto will be treated differently from securities, which will continue to be treated as things in action under English law.
UKJT starts with this scenario for a bond issue:
“Isabel PLC wishes to raise £10,000,000 through the issue of digital bonds. It creates one million tokens on a public, decentralised blockchain and offers them for sale at £10 each, promising to redeem its tokens by paying holders £11 each in one year’s time. Each token is transferable in accordance with the protocol of the blockchain and can be redeemed by transferring it back to Isabel PLC.”
This seems to suggest that Isabel PLC creates one million tokens upfront and then offers them for sale. The tokens are pre-minted and stored on the blockchain in Isabel's control until they are transferred to buyers.
In most public blockchain implementations (e.g., Ethereum-based systems). tokens are not pre-created; they are minted dynamically at the point of purchase. This ensures that each token issued corresponds directly to a received payment (e.g., USDC sent to a smart contract) eliminating discrepancies in supply or coverage. There can’t be a token that has not been paid for.
In traditional markets, an issuer account or some form of identifier at a CSD acts as a placeholder for bonds not yet sold. Once a sale occurs, bonds are transferred to the buyer's account. The CSD maintains a record linking bonds to buyer identities. Wallet addresses lack intrinsic identifiers (names, identities), so the blockchain cannot distinguish between tokens Alice holds as issuer and those held by purchasers. To use pre-created tokens, an offline system would be needed to track which wallets are designated as “issuer wallets” by Alice. Suggesting that this distinction may be noted simply in an offering document undermines the ability to interpret blockchain records, because a token could suddenly signify an issued security or a security not yet issued.
In this way, we cannot distinguish between Alice holding her own securities and Alice intending to sell securities in the future. The same record signifies both a past event and a future intent. This could be addressed by building transparency into an offline reconciliation process, but this point alone is sufficient to question why blockchain would be useful to support such an issuance, as it renders the token non-fungible. Other participants could not rely on the token unless they fully understand the issuer's specific setup, which would become very costly and complex to verify for each security.
Blockchain systems are action-based, not state-based:
A token only proves an asset if it results from an action (e.g., a purchase).
Pre-minting ignores this principle and assumes a static state of “ownership” that cannot be independently validated on-chain.
This approach is commercially unviable because it renders the ledger record dysfunctional.
Regarding redemption, they state:
“Bob demonstrates his practical control of a token by transferring it to Isabel on redemption, using the private key, just as the holder of a bearer bond demonstrates its possession by physically presenting the instrument to the issuer.”
This misses an important nuance. Bob cannot demonstrate control in this way solely through blockchain methods. When the token is associated with Bob’s wallet, there is no way of knowing if Bob can create a valid instruction to transfer it. Blockchain systems cannot confirm the current ability to act based on the token’s association with a wallet.
Once Bob makes the instruction to transfer the token, he no longer possesses the token that represents his claim. While a hypothetical process could involve a pre-prepared instruction that Bob signs using his private key, and a third party validates the transaction off-chain without propagating it to the blockchain, this introduces several issues:
Bob must trust the third party to delete the test transaction and not misuse it.
This only proves Bob's control at the time of testing, not ongoing control. For instance, Bob could lose his private key minutes later.
If we assume such a scenario is unlikely and proceed under the assumption that control will persist, we miss a critical point: blockchain is intended to be the record system. If there is any uncertainty about Bob’s ability to create a valid transaction in the future, the blockchain record becomes unreliable. The ledger cannot accurately reflect entitlement if issues around future control persist.
Furthermore, if Bob transfers his token (representing entitlement) to Alice, then the token ceases to function as evidence of Bob’s claim. At this point, if we rely on the fact that a transaction shows the token was sent from Bob’s wallet and is now associated with Alice’s wallet address, we essentially convert blockchain into an account-based ledger system. This fundamentally alters the nature of blockchain as a token-based system and negates its efficiency under such expectations.
Blockchain’s Core Limitation
Blockchain lacks a mechanism to identify real-world individuals and link them to specific wallet addresses. While external applications could map Bob or Alice to their wallet addresses, this introduces significant challenges:
Inefficiency: Such a model would require issuer-specific solutions, making it cumbersome and highly inefficient.
Data Privacy Concerns: Mapping individuals to wallet addresses risks exposing sensitive data and undermines the pseudonymity that blockchain systems are designed to preserve.
Interoperability Issues: Without a universal and standardised solution, each issuer would have to implement its own system, creating fragmentation and raising costs.
The UKJT’s redemption model imposes assumptions on blockchain that it cannot fulfil without compromising its fundamental principles. Introducing off-chain validation mechanisms or even worse, treating blockchain like an account-based system undermines its efficiency and reliability.
If blockchain is to serve as a viable record system for digital securities, we must use its action-based mechanics. Redemption models requiring off-chain validation or external identity linking defeat the very purpose of using blockchain.
So how does crypto deal with this problem?
How DeFi Demonstrates Effective Blockchain Design
Decentralised finance (DeFi) offers a clear and efficient model for solving the challenges associated with blockchain-based securities issuance and redemption. DeFi protocols like Aave exemplify how blockchain systems can effectively manage action-based proofs of entitlement while avoiding the pitfalls of state-based assumptions.
Dynamic Minting and Burning of Tokens
In DeFi, tokens are minted dynamically at the time of a deposit or interaction with the smart contract. For example:
Deposit: If Alice wants to submit USDC for liquidity staking, she sends 100 USDC to a specified wallet address controlled by the Aave smart contract.
Minting: The smart contract mints 100 aUSDC tokens and transfers them to Alice’s wallet. These are often called “wrapped tokens,” but it is more precise to think of them as a tokenised representation of Alice's USDC deposit.
USDC (itself issued by a different smart contract) is now represented as aUSDC, reflecting its new function in the staking pool.
Interest Accrual: The aUSDC tokens represent Alice’s claim on her deposit and accrue interest over time.
Redemption: When Alice wants to retrieve her deposit, she sends the aUSDC back to the Aave smart contract. The contract burns the aUSDC tokens and releases the corresponding USDC, plus any accrued interest.
This model is action-based:
Tokens only exist when tied to an action (deposit or redemption). This eliminates ambiguity about whether a token is "active" or "inactive."
The lifecycle of tokens directly corresponds to underlying transactions, ensuring clarity, accuracy, and efficiency.
Action-Based Issuance for Securities
An issuance model using blockchain effectively must adopt similar principles:
The purchaser initiates the action. For blockchain, this means the bond issuance process begins with Bob, not Alice.
How it Works:
Bob sends a cash token (e.g., USDC) to Alice’s smart contract.
Alice’s smart contract dynamically mints bond tokens representing the securities and transfers them to Bob.
The process is handled atomically, ensuring the receipt of the cash token and the issuance of the bond token are linked and happen as a single, indivisible operation.
Alice can configure the acceptable payment amount for each participant by interacting with the smart contract through an off-chain front-end or API. These configurations can then be stored on-chain for enforcement during transactions.
Example Workflow:
Rule Setup:
Alice uses a web interface or API connected to the smart contract to set rules for Bob.
Example rules:
Minimum payment: 100 tokens.
Maximum payment: 200 tokens.
Partial payment handling: Allow or reject.
These rules are recorded on-chain as part of the smart contract's state.
Alice can manage participant-specific configurations through an API that interacts with the smart contract. The API allows to manage many participants efficiently without directly interacting with the blockchain for every configuration.
There are some edge cases to consider, for instance, what if Alice changes Bob’s rules after he has initiated a transaction but before it’s processed (but they are not insurmountable).,
A stablecoin like USDC is not created through such a DeFi model but follows a traditional approach. For example, cash is wired through off-chain systems, and the issuer then instructs the smart contract to issue the required stablecoin. This activity is limited to designated organisations (conceptually like primary dealers in traditional markets), and investors purchase the stablecoin through them, ensuring that the token has been paid for.
If the asset is purchased using another token, the DeFi model is far superior to the on-ramp and off-ramp model for dealing with assets not recorded on the blockchain. If Alice were to accept off-chain payments and issue the bonds after payment is received, then Alice is not only issuing bonds but also providing an on-ramp/off-ramp solution. Alice must maintain an off-chain infrastructure to verify payments, reconcile accounts, and manually instruct the smart contract to issue bond tokens. This is ineffective and costly for Alice and also high-risk for Bob.
The cash token received by Alice can be spent by Alice before redemption. This requires functionality to ensure that there is a cash token available for the smart contract to send to Bob.
At maturity, Bob sends his bond token (e.g., aBondToken) to the smart contract to redeem it for USDC. The contract performs the following steps:
Validation: The contract checks:
Is the bond token valid for redemption (e.g., has the maturity date passed)?
Does Bob’s wallet hold enough bond tokens to match the redemption request?
Redemption Process: If validation passes, the contract attempts to:
Burn Bob’s bond token (to prevent double redemption).
Transfer the equivalent amount of USDC to Bob’s wallet.
If the contract lacks sufficient USDC, the entire transaction will revert, meaning:
Bob’s bond token will not be burned.
No partial USDC transfer will occur.
Smart contracts on Ethereum and similar blockchains execute atomically, meaning all steps in the transaction must succeed for it to be finalised. If any step fails (e.g., insufficient USDC in the contract), the entire transaction is rolled back.
If USDC is unavailable at the moment Bob sends his bond token, the contract can enqueue his redemption request rather than failing outright. Once USDC is replenished, queued redemptions are processed.
The UKJT describes six models in total, and this one was the simplest, as the requirements for equity make the process even more complex. Nevertheless, this short summary hopefully explains why a precise definition is important: what information in our ledger is evidencing what.
The underlying issue with the UKJT report is its failure to apply the necessary clarity due to an insufficient understanding of what it means to operate a token-based system, as opposed to an account-based system. I don’t blame them—this is far from easy, and I didn’t pick up on this aspect when I read their report last year. However, this represents a fundamental barrier to making tokenisation work. The banking industry, and the lawyers supporting it, lack the practical experience of operating with a token-based system and doing so more efficiently than current methods.
The UKJT’s approach treats tokens both as holding but also like messages—static indicators of intent or status—rather than as true tokens that embody ownership and action. This misunderstanding undermines the core advantages of blockchain, which is fundamentally designed for action-based proof. To fully realise the potential of tokenisation, it’s essential to treat tokens not as messages but as active ‘participants’ in processes like issuance, transfer, and redemption, ensuring clear and deterministic outcomes.
Token-based systems cannot function like account-based systems without undermining blockchain’s design principles. Tokens are not static representations of ownership but action-driven instruments. To use blockchain effectively, we must understand that tokens associated with a wallet address cannot be interpreted the same way as a bank statement showing funds in an account. Blockchain proves what has happened, not what can or will happen.