Steve Haigh

UTXO, Privacy and Why Financial Markets Need a Different Blockchain Model

Steve Haigh — Tue, 03 Feb 2026 00:00:00 +0000

Why account-based chains solve one problem, while UTXO is often better suited to provenance, confidentiality and market infrastructure.

People still talk about blockchain as though it is one thing. It isn’t. Different blockchain systems make different trade-offs about how assets move, how state is represented, what gets shared, and how easy it is to prove what actually happened. In financial markets, those choices matter far more than the broad “blockchain” label suggests.

For me, one of the most important distinctions is between account-based systems and UTXO-based systems, and I think UTXO is the better fit for markets. Account-based systems tend to model the world as a current state: who owns what now, what the balance is now, what the contract says now. UTXO systems work differently. They are built around consuming existing outputs and creating new ones, which makes state transition much more explicit.

That may sound like an implementation detail, but it really is not. Financial markets are driven by events. Cash moves. Title moves. Collateral is allocated and released. Positions are adjusted. Obligations are settled. In that sort of world, it is not enough to know the current state. You also need to know how you got there. That is where UTXO starts to look very strong, because it gives you a cleaner story for lineage and provenance. One thing is consumed, another is created, and you can trace the path from one state to the next in a way that feels much closer to how financial events actually work.

Account-based systems are often better suited to building applications. They are flexible, expressive and familiar to developers. But financial market infrastructure is not just an app problem. It is an evidential problem. You need to show ownership, transfer, entitlement and finality in a way that stands up when somebody asks difficult questions, whether that is an auditor, a regulator, an operator or a counterparty. UTXO is naturally good at that because it treats transitions as first-class things rather than side effects of updating a shared balance.

There is then the separate question of public and private, permissionless and permissioned. People often muddle those up. A public chain is broadly visible, while a private one is not. A permissionless chain allows open participation under the rules of the network, while a permissioned one restricts participation to approved parties. Those are governance choices. UTXO is a transaction model. The two things are related, but they are not the same.

That matters because people too often assume that using a public permissionless UTXO blockchain means putting business data out in the open. It does not have to. In fact, I think one of the more interesting models for financial markets is to build a privacy layer over a public permissionless UTXO blockchain. In that model, the public chain becomes a neutral truth layer for ordering, timestamping and evidencing state transitions, without carrying the underlying business data in the clear. You do not need to put trade economics, client identities, settlement instructions or sensitive counterparty information on-chain. You put commitments on-chain, not the raw facts.

That is where Merkle trees, cryptography and derived keys come in. A Merkle tree allows you to commit to a structured set of data with a single root, and later prove that a particular item was included without revealing everything else. In markets, that is exactly the sort of thing you want. Selective disclosure, not full disclosure. Cryptography allows the underlying records to remain protected off-chain while still letting you prove integrity and linkage on-chain. Derived keys matter because they reduce linkability. If you derive fresh keys for different assets, transactions or workflows, you make it much harder to map activity across the entire system. In wholesale markets, that is not an optional extra. It is basic hygiene.

And privacy in financial markets is not a nice-to-have. Firms cannot expose positions, counterparties, collateral movements and settlement activity to the wider world and hope for the best. That would be commercially reckless. At the same time, regulators and authorised parties may still need controlled visibility. So the design goal is not secrecy, and it is not radical transparency either. It is controlled disclosure with strong evidence.

That, to me, is where UTXO starts to look more serious than the industry often gives it credit for. It gives you a disciplined way to model transitions, a strong evidential trail, and a better base for building privacy-preserving infrastructure on top of public permissionless rails. I am not saying every financial market workflow should sit directly on a public chain. That would be daft. Markets still need identity, governance, legal frameworks and operational controls. But I do think a public permissionless UTXO blockchain, with a proper privacy layer above it, is a far more interesting model than people often assume.

The industry has spent years treating UTXO as yesterday’s design and account-based chains as the more sophisticated answer. I am not convinced. If your main concern is building rich on-chain applications, account-based systems are often easier. If your concern is market infrastructure, where provenance, privacy, finality and evidential integrity really matter, UTXO has a lot going for it. Possibly more than most people realise.

Smart Contracts on Blockchain? That's Not the Same as a Contract

Steve Haigh — Sat, 17 Jan 2026 00:00:00 +0000

There is a habit in this industry of taking a perfectly good term, squeezing it through a narrow technical lens, and then pretending nothing got lost in the process.

That is more or less what has happened with smart contracts.

These days, if someone says “smart contract”, what they usually mean is on-chain code, generally in the Ethereum mould. Code is deployed to a blockchain, it executes deterministically, state changes, and that is taken to be the contract.

I think that gets the wrong end of the stick.

Putting code on-chain is not the same thing as representing a contract. In most cases, it is not even close. What it usually gives you is a mechanism for execution and state transition. Useful, certainly. Clever, sometimes. But that is not the same as capturing the legal, operational and economic reality of an agreement between parties.

That distinction is not academic. It matters a great deal if you work in financial services, where contracts are not just chunks of logic waiting to be run, but living arrangements made up of rights, obligations, timing, events, exceptions, notices, calculations, disputes and recourse.

Some of that can be automated very well.

Some of it cannot.

And some of it absolutely should not be confused with whatever happened to execute on a blockchain.

That, for me, is where much of the modern smart contract conversation goes off the rails.

The industry has mistaken execution for meaning

The prevailing blockchain view of smart contracts tends to collapse everything into execution.

If the code ran, then the contract has done its job.

If the ledger updated, then the event has happened.

If the network reached consensus, then the matter is settled.

That might be fine for a narrow category of digital asset transfer. It is nowhere near enough for most serious contracts, and it is certainly not enough for many financial contracts.

A repo is not just code. A derivative is not just code. A settlement obligation is not just code.

These things sit inside a legal framework, an operating model and a market context. They depend on data, process, timing, fallback provisions and, from time to time, plain old human judgement. There are notices to issue, calculations to validate, events to interpret and disagreements to resolve. Anyone who has spent time around real post-trade operations knows the world is rarely as neat as the on-chain story likes to suggest.

So when people say a blockchain smart contract is the contract, I think that is giving the technology too much credit and not nearly enough scrutiny.

More often than not, it is a piece of automation attached to a contract-shaped problem.

That is not the same thing.

Ethereum made this way of thinking feel normal

Ethereum deserves credit for making programmable blockchain infrastructure mainstream. It gave developers a general-purpose platform for writing code that manages assets and shared state directly on-chain.

Technically, that was a big step forward.

But it also hard-wired a particular mental model into the market. In an account-based system, the natural pattern is to build a long-lived application that owns mutable state. The contract becomes a software object. Assets are balances or records within that object. Behaviour is expressed through functions that update shared state over time.

That is powerful, but it is also where the conceptual slippage begins.

Because once you start thinking that way, it becomes very easy to assume that the application state is the contract, or at least the definitive expression of it.

In practice, that is often not true.

What you have is a system that records and executes some operational aspects of an arrangement. You may have captured transfer logic, calculation rules, entitlement conditions or settlement steps. Fine. But you have not necessarily captured the actual meaning of the agreement in the round. You have not captured the legal framework. You have not captured every exception. You have not captured the fact that commercial life has rough edges and strange corners and occasionally refuses to sit nicely inside deterministic code.

There is a tendency in blockchain circles to brush past that point. I think that is a mistake.

In financial services, provenance matters just as much as state

This is where the comparison between account-based and UTXO-based models becomes more interesting than people sometimes allow.

At first glance, it can seem like a technical distinction. One model updates balances in accounts. The other consumes and creates discrete outputs. But the difference runs deeper than that, because it changes the shape of the system and the way you reason about what has happened.

Account-based systems are naturally geared towards maintaining current state. Who owns what, what the balance is, what the contract storage says right now.

UTXO-based systems are naturally geared towards transition and lineage. What existed before, what was consumed, what was created, and how one state gave rise to another.

That matters in finance.

A great deal of financial processing is event-driven. Cash is paid. Title transfers. Collateral is allocated. Positions are reset. Assets are encumbered, released, novated or settled. In those scenarios, the important question is often not just “what is the current state?” but “how did we get here, through which chain of rights, obligations and events?”

That is one reason UTXO-based models can feel closer to the underlying commercial problem. They force a discipline around provenance. They encourage explicit state transitions. They produce a more natural evidential trail.

I would not push that too far. UTXO systems can be awkward for certain types of general application logic, and account-based systems are often more straightforward for developers building rich applications. Fair enough.

But if you are dealing with contracts, especially where auditability, traceability and event lineage matter, the UTXO model has a habit of asking the right questions.

Not just what the state is now, but how it came to be.

That is often the more important thing.

The phrase “code is law” was always a bit glib

One of the more enduring slogans to come out of blockchain was “code is law”.

It is catchy. It also papers over quite a lot.

Code is not law. Code is code. It does what it has been written to do, no more and no less. That can be useful. It can be rigorous. It can be highly effective where the rules are clear and bounded. But it does not interpret intent, weigh ambiguity, handle unforeseen commercial circumstances, or step outside its own model of the world.

Law, by contrast, exists precisely because the world does not fit neatly into machine branches.

So I have always thought “code is law” confused enforcement with meaning. It mistakes the ability to execute something automatically for the ability to capture the full substance of what has been agreed.

In the real world, and particularly in financial services, a contract is broader than its implementation. It is not exhausted by the code.

That does not reduce the value of automation. Far from it. Good automation is essential. Deterministic execution is valuable. Verifiable state transitions are valuable. Shared records are valuable. But they remain parts of a larger picture.

That is the point.

A better way to think about smart contracts

For my money, a smart contract should not be defined by whether it runs on-chain.

It should be defined by whether it faithfully expresses and automates the operationally deterministic parts of an agreement.

That may involve blockchain. It may not.

It may involve workflow engines, event processors, state models, shared ledgers, rule engines, API integrations and legal documentation, all working together.

That is much closer to how serious systems in financial markets actually have to be built.

The real design question is not, “Can we put this contract on-chain?”

It is, “Which parts of this arrangement are precise enough to automate, which parts need evidence and traceability, and which parts remain anchored in legal text and operational process?”

That is a far better question. It is also a more grown-up one.

Because once you frame it properly, it becomes obvious that putting code on a blockchain is only one implementation choice among many. Sometimes it is the right one. Sometimes it is not. Often it is only part of the answer.

So what is the point being missed?

The point being missed is that contracts are about meaning before they are about execution.

Execution matters, of course it does. But meaning comes first. Rights and obligations come first. The legal relationship comes first. The operating model comes first. Evidence, process and governance all come first.

The machine should serve that reality, not pretend to replace it.

That is why I think so many blockchain smart contracts miss the point. They start from the implementation and work backwards. They assume that because a thing can execute deterministically on-chain, it has somehow captured the contract in full.

Usually, it has not.

Usually, it has captured one slice of behaviour and wrapped it in more certainty than it deserves.

And in financial services, that is not a small distinction. It is the whole game.

London Blockchain Conference Recap: Tokenisation of RWAs, Cash and Atomic Settlement

Steve Haigh — Wed, 29 Oct 2025 00:00:00 +0000

Last week at London Blockchain Conference, I presented a tech talk on the innovation stage: “Tokenisation of RWAs, Cash and Atomic Settlement.”

The core message was simple: moving from pilots to production in capital markets requires more than tokenising assets in isolation. You need a practical workflow that connects tokenised real-world assets, tokenised cash, and deterministic post-trade execution.

Watch the tech talk from London Blockchain Conference.

What I covered

I focused on how Tokenovate’s enterprise wallet and workflow orchestration can help financial institutions industrialise post-trade operations.

The demonstration covered:

Standardised workflows for post-trade events, aligned to institutional operating models.
Atomic settlement of asset and cash legs to reduce principal and counterparty risk.
Faster settlement cycles by eliminating avoidable handoffs and reconciliation delays.
A shared truth layer of trade data that supports a durable, auditable golden record.

Why this matters now

Market infrastructure is at an inflection point. The technology is no longer the biggest blocker; operational integration, risk controls, and production-grade workflows are.

Tokenisation only creates real value when it is connected to settlement finality, robust process design, and evidential data integrity. That is where enterprise adoption is won or lost.

Looking ahead

Thanks to everyone who joined the session and shared thoughtful questions afterwards. The level of engagement around practical implementation, interoperability, and governance was especially encouraging.

If you’d like to continue the discussion, feel free to connect with me.

Smart Contracts Before Blockchain

Steve Haigh — Wed, 01 Oct 2025 00:00:00 +0000

If you listen to enough conversations in digital assets, you’d be forgiven for thinking smart contracts are something that live on blockchains.

They’re not.

Or at least, they didn’t start that way. And in my view, they don’t need to.

The term itself goes back to the 1990s, when Nick Szabo was writing about whether agreements could be expressed in software and enforced by the system itself. This was well before Bitcoin, long before Ethereum, and long before we started attaching tokens to everything that moves.

His idea was fairly grounded. If you can define the rules of an agreement clearly enough, you can build a system that enforces those rules without needing people in the middle.

The example he used was a vending machine. You put money in, press a button, and if everything lines up, out comes your drink. No reconciliation, no follow-up, no debate about what was meant to happen. It just does what it’s supposed to do.

That’s a smart contract in the original sense.

And importantly, there’s no blockchain anywhere in sight.

Somewhere along the way, the meaning shifted

The association between smart contracts and blockchains really took off with Ethereum. When Ethereum launched in 2015, it explicitly positioned itself as a platform for running “smart contracts”, and that framing stuck.

Since then, the term has been more or less absorbed into blockchain vocabulary. In most conversations today, a smart contract is assumed to be code deployed on a blockchain, typically running inside something like the Ethereum Virtual Machine.

That’s understandable, but it’s also a bit of a category mistake.

Because what Szabo was describing wasn’t tied to any particular infrastructure. It was a property of a system. If a system encodes the rules of an agreement and enforces them automatically, then by that definition, it’s a smart contract. It doesn’t matter whether it runs on a blockchain, a server, or a fairly old bit of embedded hardware.

A vending machine qualifies.

So does any piece of software that deterministically enforces an agreement between parties.

Which means the idea is much broader, and much more useful, than the current shorthand suggests.

The real problem: contracts aren’t simple

All of that works nicely for simple systems.

If the rules are clear, the inputs are known, and the outcomes are limited, then automating the agreement is entirely sensible. In those cases, code is exactly what you want. It removes ambiguity, enforces consistency, and gets rid of a lot of unnecessary operational overhead.

But most real contracts, particularly in financial markets, don’t look like that.

They’re long-lived, nuanced, and full of edge cases. Terms get amended. Events occur that no one quite anticipated. Different parts of the agreement interact in ways that only become clear over time. And when something doesn’t line up neatly, the answer isn’t sitting there waiting in a function call.

It’s worked out through interpretation.

That’s the bit the “smart contract” narrative tends to gloss over. Real contracts aren’t just about execution. They’re about meaning. They’re written in a way that leaves room for context, intent and, occasionally, disagreement. Not because lawyers enjoy ambiguity, but because the real world doesn’t fit neatly into predefined branches of logic.

And when things do go wrong, as they inevitably do, you don’t turn to the code and say “that’s final”.

You go back to the contract.

And very often, to the lawyers.

Code is not law

There’s a phrase that crops up from time to time: code is law.

I’ve never found that particularly convincing in the context of capital markets.

Code is precise. It does exactly what it’s told. That’s its strength. But it only deals with what has been explicitly modelled. It doesn’t cope well with ambiguity, conflicting interpretations, or situations that sit outside what anyone thought to encode at the outset.

Law is different. It exists precisely to deal with those situations. It handles intent, context, judgement, and the messy edge cases that don’t fit neatly into a predefined structure.

Trying to collapse one into the other doesn’t really work.

You can encode a lot of behaviour in code. You can make systems highly deterministic. But you can’t realistically capture every possible outcome of a complex financial agreement, and you certainly can’t remove the need for interpretation when something unexpected happens.

At that point, the “smart” contract isn’t particularly smart. It’s just rigid.

This isn’t about blockchain

It’s also worth being clear that none of this is an argument against blockchain.

Blockchains are useful. They give you shared state, tamper resistance, and a way for multiple parties to agree on outcomes without a central operator. That’s valuable.

But they’re not what makes something a smart contract.

The industry has slightly conflated the two ideas. Smart contracts became “things that run on blockchains”, when in reality they’re just systems that enforce agreements automatically.

Blockchain is one way of doing that.

Not the only way.

Where this shows up in practice

From where I sit, working in post-trade and digital assets, this distinction matters quite a lot.

A big part of what we’re doing at Tokenovate is building systems that codify the lifecycle of financial products. In particular, using the FINOS Common Domain Model (CDM) to represent the rules of derivatives and securities financing transactions, based on things like ISDA and GMRA agreements.

In many ways, that is exactly what Szabo was getting at.

You take the economic terms, the lifecycle events, the allowable state transitions, and you express them in a form that a system can apply deterministically. If an event is valid, it moves the contract from one state to another. If it isn’t, it doesn’t.

By any reasonable definition, that’s a smart contract.

And it doesn’t need to sit on a blockchain to be one.

But it still isn’t the whole contract

Even then, it’s not complete.

You can codify a great deal of the lifecycle. You can make behaviour far more deterministic than it is today. You can remove a lot of reconciliation and ambiguity from the operational layer.

But you can’t capture everything.

There will always be edge cases. There will always be scenarios that weren’t anticipated. There will always be moments where interpretation matters, where the wording of the legal agreement takes precedence, and where the system doesn’t have a definitive answer.

At that point, you fall back to the legal contract.

And, usually, to the lawyers.

So what are smart contracts, really?

If you strip away the hype, smart contracts are best understood as:

systems that automate the well-defined parts of an agreement.

That’s already useful. In fact, it’s quite powerful. But it’s not the same as replacing the agreement itself, and it’s not the same as eliminating ambiguity altogether.

In simple systems, smart contracts work well.

In complex financial instruments, they’re only part of the picture.

Closing thought

The original idea behind smart contracts still stands up. If you can define the rules clearly enough, you can get the system to enforce them.

That’s worth pursuing.

But it only takes you so far.

You can automate the predictable bits. You can make execution cleaner. You can reduce the need for trust in process.

But you can’t write code for every edge case. You can’t eliminate ambiguity entirely. And you can’t replace the role of legal interpretation when things get difficult.

So yes, smart contracts are useful.

But they’re not quite as smart as we sometimes make them out to be. Oh, and they don’t have to live on a blockchain.