{"version":"https://jsonfeed.org/version/1","title":"Steve Haigh","home_page_url":"https://stevehaigh.net/","feed_url":"https://stevehaigh.net/feed.json","description":"CTO and engineering leader writing about post-trade automation, digital assets, financial infrastructure, and technology leadership.","favicon":"https://stevehaigh.net//assets/favicon.ico","expired":false,"author":{"name":"Steve Haigh","url":"https://stevehaigh.net/"},"items":[{"id":"e09e00a184f99134ddb22fcb2b650c9883fbabc5","title":"UTXO, Privacy and Why Financial Markets Need a Different Blockchain Model","summary":"","content_text":"Why account-based chains solve one problem, while UTXO is often better suited to provenance, confidentiality and market infrastructure.\nPeople still talk about blockchain as though it is one thing. It isn\u0026rsquo;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 \u0026ldquo;blockchain\u0026rdquo; label suggests.\nFor 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.\nThat 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.\nAccount-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.\nThere 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.\nThat 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.\nThat 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.\nAnd 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.\nThat, 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.\nThe industry has spent years treating UTXO as yesterday\u0026rsquo;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.\n","content_html":"\u003cp\u003e\u003cem\u003eWhy account-based chains solve one problem, while UTXO is often better suited to provenance, confidentiality and market infrastructure.\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003ePeople still talk about blockchain as though it is one thing. It isn\u0026rsquo;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 \u0026ldquo;blockchain\u0026rdquo; label suggests.\u003c/p\u003e\n\u003cp\u003eFor 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.\u003c/p\u003e\n\u003cp\u003eThat 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.\u003c/p\u003e\n\u003cp\u003eAccount-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.\u003c/p\u003e\n\u003cp\u003eThere 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.\u003c/p\u003e\n\u003cp\u003eThat 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.\u003c/p\u003e\n\u003cp\u003eThat 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.\u003c/p\u003e\n\u003cp\u003eAnd 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.\u003c/p\u003e\n\u003cp\u003eThat, 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.\u003c/p\u003e\n\u003cp\u003eThe industry has spent years treating UTXO as yesterday\u0026rsquo;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.\u003c/p\u003e\n","url":"https://stevehaigh.net/posts/utxo-privacy-and-why-financial-markets-need-a-different-blockchain-model/","date_published":"3026-03-09T20:33:00+00:00","date_modified":"3026-03-09T20:33:00+00:00","author":{"name":"Steve Haigh","url":"https://stevehaigh.net/"}},{"id":"91e4287d00a1e924cf40ef1c6fca42203cc5fad6","title":"Smart Contracts on Blockchain? That's Not the Same as a Contract","summary":"","content_text":"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.\nThat is more or less what has happened with smart contracts.\nThese days, if someone says \u0026ldquo;smart contract\u0026rdquo;, 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.\nI think that gets the wrong end of the stick.\nPutting 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.\nThat 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.\nSome of that can be automated very well.\nSome of it cannot.\nAnd some of it absolutely should not be confused with whatever happened to execute on a blockchain.\nThat, for me, is where much of the modern smart contract conversation goes off the rails.\nThe industry has mistaken execution for meaning The prevailing blockchain view of smart contracts tends to collapse everything into execution.\nIf the code ran, then the contract has done its job.\nIf the ledger updated, then the event has happened.\nIf the network reached consensus, then the matter is settled.\nThat 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.\nA repo is not just code. A derivative is not just code. A settlement obligation is not just code.\nThese 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.\nSo 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.\nMore often than not, it is a piece of automation attached to a contract-shaped problem.\nThat is not the same thing.\nEthereum 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.\nTechnically, that was a big step forward.\nBut 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.\nThat is powerful, but it is also where the conceptual slippage begins.\nBecause 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.\nIn practice, that is often not true.\nWhat 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.\nThere is a tendency in blockchain circles to brush past that point. I think that is a mistake.\nIn 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.\nAt 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.\nAccount-based systems are naturally geared towards maintaining current state. Who owns what, what the balance is, what the contract storage says right now.\nUTXO-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.\nThat matters in finance.\nA 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 \u0026ldquo;what is the current state?\u0026rdquo; but \u0026ldquo;how did we get here, through which chain of rights, obligations and events?\u0026rdquo;\nThat 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.\nI 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.\nBut 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.\nNot just what the state is now, but how it came to be.\nThat is often the more important thing.\nThe phrase \u0026ldquo;code is law\u0026rdquo; was always a bit glib One of the more enduring slogans to come out of blockchain was \u0026ldquo;code is law\u0026rdquo;.\nIt is catchy. It also papers over quite a lot.\nCode 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.\nLaw, by contrast, exists precisely because the world does not fit neatly into machine branches.\nSo I have always thought \u0026ldquo;code is law\u0026rdquo; 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.\nIn the real world, and particularly in financial services, a contract is broader than its implementation. It is not exhausted by the code.\nThat 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.\nThat is the point.\nA better way to think about smart contracts For my money, a smart contract should not be defined by whether it runs on-chain.\nIt should be defined by whether it faithfully expresses and automates the operationally deterministic parts of an agreement.\nThat may involve blockchain. It may not.\nIt may involve workflow engines, event processors, state models, shared ledgers, rule engines, API integrations and legal documentation, all working together.\nThat is much closer to how serious systems in financial markets actually have to be built.\nThe real design question is not, \u0026ldquo;Can we put this contract on-chain?\u0026rdquo;\nIt is, \u0026ldquo;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?\u0026rdquo;\nThat is a far better question. It is also a more grown-up one.\nBecause 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.\nSo what is the point being missed? The point being missed is that contracts are about meaning before they are about execution.\nExecution 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.\nThe machine should serve that reality, not pretend to replace it.\nThat 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.\nUsually, it has not.\nUsually, it has captured one slice of behaviour and wrapped it in more certainty than it deserves.\nAnd in financial services, that is not a small distinction. It is the whole game.\n","content_html":"\u003cp\u003eThere 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.\u003c/p\u003e\n\u003cp\u003eThat is more or less what has happened with smart contracts.\u003c/p\u003e\n\u003cp\u003eThese days, if someone says \u0026ldquo;smart contract\u0026rdquo;, 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.\u003c/p\u003e\n\u003cp\u003eI think that gets the wrong end of the stick.\u003c/p\u003e\n\u003cp\u003ePutting 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.\u003c/p\u003e\n\u003cp\u003eThat 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.\u003c/p\u003e\n\u003cp\u003eSome of that can be automated very well.\u003c/p\u003e\n\u003cp\u003eSome of it cannot.\u003c/p\u003e\n\u003cp\u003eAnd some of it absolutely should not be confused with whatever happened to execute on a blockchain.\u003c/p\u003e\n\u003cp\u003eThat, for me, is where much of the modern smart contract conversation goes off the rails.\u003c/p\u003e\n\u003ch2 id=\"the-industry-has-mistaken-execution-for-meaning\"\u003eThe industry has mistaken execution for meaning\u003c/h2\u003e\n\u003cp\u003eThe prevailing blockchain view of smart contracts tends to collapse everything into execution.\u003c/p\u003e\n\u003cp\u003eIf the code ran, then the contract has done its job.\u003c/p\u003e\n\u003cp\u003eIf the ledger updated, then the event has happened.\u003c/p\u003e\n\u003cp\u003eIf the network reached consensus, then the matter is settled.\u003c/p\u003e\n\u003cp\u003eThat 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.\u003c/p\u003e\n\u003cp\u003eA repo is not just code.\nA derivative is not just code.\nA settlement obligation is not just code.\u003c/p\u003e\n\u003cp\u003eThese 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.\u003c/p\u003e\n\u003cp\u003eSo 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.\u003c/p\u003e\n\u003cp\u003eMore often than not, it is a piece of automation attached to a contract-shaped problem.\u003c/p\u003e\n\u003cp\u003eThat is not the same thing.\u003c/p\u003e\n\u003ch2 id=\"ethereum-made-this-way-of-thinking-feel-normal\"\u003eEthereum made this way of thinking feel normal\u003c/h2\u003e\n\u003cp\u003eEthereum 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.\u003c/p\u003e\n\u003cp\u003eTechnically, that was a big step forward.\u003c/p\u003e\n\u003cp\u003eBut 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.\u003c/p\u003e\n\u003cp\u003eThat is powerful, but it is also where the conceptual slippage begins.\u003c/p\u003e\n\u003cp\u003eBecause 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.\u003c/p\u003e\n\u003cp\u003eIn practice, that is often not true.\u003c/p\u003e\n\u003cp\u003eWhat 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.\u003c/p\u003e\n\u003cp\u003eThere is a tendency in blockchain circles to brush past that point. I think that is a mistake.\u003c/p\u003e\n\u003ch2 id=\"in-financial-services-provenance-matters-just-as-much-as-state\"\u003eIn financial services, provenance matters just as much as state\u003c/h2\u003e\n\u003cp\u003eThis is where the comparison between account-based and UTXO-based models becomes more interesting than people sometimes allow.\u003c/p\u003e\n\u003cp\u003eAt 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.\u003c/p\u003e\n\u003cp\u003eAccount-based systems are naturally geared towards maintaining current state. Who owns what, what the balance is, what the contract storage says right now.\u003c/p\u003e\n\u003cp\u003eUTXO-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.\u003c/p\u003e\n\u003cp\u003eThat matters in finance.\u003c/p\u003e\n\u003cp\u003eA 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 \u0026ldquo;what is the current state?\u0026rdquo; but \u0026ldquo;how did we get here, through which chain of rights, obligations and events?\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eThat 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.\u003c/p\u003e\n\u003cp\u003eI 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.\u003c/p\u003e\n\u003cp\u003eBut 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.\u003c/p\u003e\n\u003cp\u003eNot just what the state is now, but how it came to be.\u003c/p\u003e\n\u003cp\u003eThat is often the more important thing.\u003c/p\u003e\n\u003ch2 id=\"the-phrase-code-is-law-was-always-a-bit-glib\"\u003eThe phrase \u0026ldquo;code is law\u0026rdquo; was always a bit glib\u003c/h2\u003e\n\u003cp\u003eOne of the more enduring slogans to come out of blockchain was \u0026ldquo;code is law\u0026rdquo;.\u003c/p\u003e\n\u003cp\u003eIt is catchy. It also papers over quite a lot.\u003c/p\u003e\n\u003cp\u003eCode 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.\u003c/p\u003e\n\u003cp\u003eLaw, by contrast, exists precisely because the world does not fit neatly into machine branches.\u003c/p\u003e\n\u003cp\u003eSo I have always thought \u0026ldquo;code is law\u0026rdquo; 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.\u003c/p\u003e\n\u003cp\u003eIn the real world, and particularly in financial services, a contract is broader than its implementation. It is not exhausted by the code.\u003c/p\u003e\n\u003cp\u003eThat 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.\u003c/p\u003e\n\u003cp\u003eThat is the point.\u003c/p\u003e\n\u003ch2 id=\"a-better-way-to-think-about-smart-contracts\"\u003eA better way to think about smart contracts\u003c/h2\u003e\n\u003cp\u003eFor my money, a smart contract should not be defined by whether it runs on-chain.\u003c/p\u003e\n\u003cp\u003eIt should be defined by whether it faithfully expresses and automates the operationally deterministic parts of an agreement.\u003c/p\u003e\n\u003cp\u003eThat may involve blockchain.\nIt may not.\u003c/p\u003e\n\u003cp\u003eIt may involve workflow engines, event processors, state models, shared ledgers, rule engines, API integrations and legal documentation, all working together.\u003c/p\u003e\n\u003cp\u003eThat is much closer to how serious systems in financial markets actually have to be built.\u003c/p\u003e\n\u003cp\u003eThe real design question is not, \u0026ldquo;Can we put this contract on-chain?\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eIt is, \u0026ldquo;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?\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eThat is a far better question. It is also a more grown-up one.\u003c/p\u003e\n\u003cp\u003eBecause 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.\u003c/p\u003e\n\u003ch2 id=\"so-what-is-the-point-being-missed\"\u003eSo what is the point being missed?\u003c/h2\u003e\n\u003cp\u003eThe point being missed is that contracts are about meaning before they are about execution.\u003c/p\u003e\n\u003cp\u003eExecution 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.\u003c/p\u003e\n\u003cp\u003eThe machine should serve that reality, not pretend to replace it.\u003c/p\u003e\n\u003cp\u003eThat 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.\u003c/p\u003e\n\u003cp\u003eUsually, it has not.\u003c/p\u003e\n\u003cp\u003eUsually, it has captured one slice of behaviour and wrapped it in more certainty than it deserves.\u003c/p\u003e\n\u003cp\u003eAnd in financial services, that is not a small distinction. It is the whole game.\u003c/p\u003e\n","url":"https://stevehaigh.net/posts/smart-contracts-on-blockchain-thats-not-the-same-as-a-contract/","date_published":"17016-17-09T10:1717:00+00:00","date_modified":"17016-17-09T10:1717:00+00:00","author":{"name":"Steve Haigh","url":"https://stevehaigh.net/"}},{"id":"b704628d5135b914b0b2207ad4591e2d27d7c183","title":"London Blockchain Conference Recap: Tokenisation of RWAs, Cash and Atomic Settlement","summary":"","content_text":"Last week at London Blockchain Conference, I presented a tech talk on the innovation stage: \u0026ldquo;Tokenisation of RWAs, Cash and Atomic Settlement.\u0026rdquo;\nThe 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.\nPlay Watch the tech talk from London Blockchain Conference. What I covered I focused on how Tokenovate\u0026rsquo;s enterprise wallet and workflow orchestration can help financial institutions industrialise post-trade operations.\nThe demonstration covered:\nStandardised 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.\nTokenisation 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.\nLooking 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.\nIf you\u0026rsquo;d like to continue the discussion, feel free to connect with me.\n","content_html":"\u003cp\u003eLast week at London Blockchain Conference, I presented a tech talk on the innovation stage: \u003cstrong\u003e\u0026ldquo;Tokenisation of RWAs, Cash and Atomic Settlement.\u0026rdquo;\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eThe 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.\u003c/p\u003e\n\n\n\n\n  \n  \n\u003cfigure class=\"post-video youtube-embed\"\u003e\n  \u003cbutton class=\"youtube-cover\" type=\"button\" data-youtube-id=\"UmfwE93BN6E\" data-youtube-title=\"Tokenisation of RWAs, Cash and Atomic Settlement\" aria-label=\"Play Tokenisation of RWAs, Cash and Atomic Settlement\"\u003e\n    \u003cimg src=\"https://i.ytimg.com/vi/UmfwE93BN6E/hqdefault.jpg\" alt=\"Tokenisation of RWAs, Cash and Atomic Settlement cover image\" loading=\"lazy\" decoding=\"async\"\u003e\n    \u003cspan class=\"youtube-cover-play\" aria-hidden=\"true\"\u003ePlay\u003c/span\u003e\n  \u003c/button\u003e\n  \n  \u003cfigcaption\u003eWatch the tech talk from London Blockchain Conference.\u003c/figcaption\u003e\n  \n\u003c/figure\u003e\n\n\n\u003ch2 id=\"what-i-covered\"\u003eWhat I covered\u003c/h2\u003e\n\u003cp\u003eI focused on how Tokenovate\u0026rsquo;s enterprise wallet and workflow orchestration can help financial institutions industrialise post-trade operations.\u003c/p\u003e\n\u003cp\u003eThe demonstration covered:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eStandardised workflows for post-trade events, aligned to institutional operating models.\u003c/li\u003e\n\u003cli\u003eAtomic settlement of asset and cash legs to reduce principal and counterparty risk.\u003c/li\u003e\n\u003cli\u003eFaster settlement cycles by eliminating avoidable handoffs and reconciliation delays.\u003c/li\u003e\n\u003cli\u003eA shared truth layer of trade data that supports a durable, auditable golden record.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"why-this-matters-now\"\u003eWhy this matters now\u003c/h2\u003e\n\u003cp\u003eMarket infrastructure is at an inflection point. The technology is no longer the biggest blocker; operational integration, risk controls, and production-grade workflows are.\u003c/p\u003e\n\u003cp\u003eTokenisation 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.\u003c/p\u003e\n\u003ch2 id=\"looking-ahead\"\u003eLooking ahead\u003c/h2\u003e\n\u003cp\u003eThanks to everyone who joined the session and shared thoughtful questions afterwards. The level of engagement around practical implementation, interoperability, and governance was especially encouraging.\u003c/p\u003e\n\u003cp\u003eIf you\u0026rsquo;d like to continue the discussion, feel free to \u003ca href=\"https://www.linkedin.com/in/stevehaigh/\"\u003econnect with me\u003c/a\u003e.\u003c/p\u003e\n","url":"https://stevehaigh.net/posts/london-blockchain-conference-tokenisation-of-rwas-cash-and-atomic-settlement/","date_published":"29106-29-09T100:2929:00+00:00","date_modified":"29106-29-09T100:2929:00+00:00","author":{"name":"Steve Haigh","url":"https://stevehaigh.net/"}},{"id":"a07edc794aa2d25bbbb4840950f2e99a11176341","title":"Smart Contracts Before Blockchain","summary":"","content_text":"If you listen to enough conversations in digital assets, you’d be forgiven for thinking smart contracts are something that live on blockchains.\nThey’re not.\nOr at least, they didn’t start that way. And in my view, they don’t need to.\nThe 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.\nHis 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.\nThe 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.\nThat’s a smart contract in the original sense.\nAnd importantly, there’s no blockchain anywhere in sight.\nSomewhere along the way, the meaning shifted\nThe 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.\nSince 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.\nThat’s understandable, but it’s also a bit of a category mistake.\nBecause 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.\nA vending machine qualifies.\nSo does any piece of software that deterministically enforces an agreement between parties.\nWhich means the idea is much broader, and much more useful, than the current shorthand suggests.\nThe real problem: contracts aren’t simple\nAll of that works nicely for simple systems.\nIf 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.\nBut most real contracts, particularly in financial markets, don’t look like that.\nThey’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.\nIt’s worked out through interpretation.\nThat’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.\nAnd when things do go wrong, as they inevitably do, you don’t turn to the code and say “that’s final”.\nYou go back to the contract.\nAnd very often, to the lawyers.\nCode is not law\nThere’s a phrase that crops up from time to time: code is law.\nI’ve never found that particularly convincing in the context of capital markets.\nCode 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.\nLaw 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.\nTrying to collapse one into the other doesn’t really work.\nYou 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.\nAt that point, the “smart” contract isn’t particularly smart. It’s just rigid.\nThis isn’t about blockchain\nIt’s also worth being clear that none of this is an argument against blockchain.\nBlockchains 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.\nBut they’re not what makes something a smart contract.\nThe 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.\nBlockchain is one way of doing that.\nNot the only way.\nWhere this shows up in practice\nFrom where I sit, working in post-trade and digital assets, this distinction matters quite a lot.\nA 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.\nIn many ways, that is exactly what Szabo was getting at.\nYou 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.\nBy any reasonable definition, that’s a smart contract.\nAnd it doesn’t need to sit on a blockchain to be one.\nBut it still isn’t the whole contract\nEven then, it’s not complete.\nYou 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.\nBut you can’t capture everything.\nThere 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.\nAt that point, you fall back to the legal contract.\nAnd, usually, to the lawyers.\nSo what are smart contracts, really?\nIf you strip away the hype, smart contracts are best understood as:\nsystems that automate the well-defined parts of an agreement.\nThat’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.\nIn simple systems, smart contracts work well.\nIn complex financial instruments, they’re only part of the picture.\nClosing thought\nThe original idea behind smart contracts still stands up. If you can define the rules clearly enough, you can get the system to enforce them.\nThat’s worth pursuing.\nBut it only takes you so far.\nYou can automate the predictable bits. You can make execution cleaner. You can reduce the need for trust in process.\nBut 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.\nSo yes, smart contracts are useful.\nBut they’re not quite as smart as we sometimes make them out to be. Oh, and they don\u0026rsquo;t have to live on a blockchain.\n","content_html":"\u003cp\u003eIf you listen to enough conversations in digital assets, you’d be forgiven for thinking smart contracts are something that live on blockchains.\u003c/p\u003e\n\u003cp\u003eThey’re not.\u003c/p\u003e\n\u003cp\u003eOr at least, they didn’t start that way. And in my view, they don’t need to.\u003c/p\u003e\n\u003cp\u003eThe 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.\u003c/p\u003e\n\u003cp\u003eHis 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.\u003c/p\u003e\n\u003cp\u003eThe 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.\u003c/p\u003e\n\u003cp\u003eThat’s a smart contract in the original sense.\u003c/p\u003e\n\u003cp\u003eAnd importantly, there’s no blockchain anywhere in sight.\u003c/p\u003e\n\u003cp\u003eSomewhere along the way, the meaning shifted\u003c/p\u003e\n\u003cp\u003eThe 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.\u003c/p\u003e\n\u003cp\u003eSince 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.\u003c/p\u003e\n\u003cp\u003eThat’s understandable, but it’s also a bit of a category mistake.\u003c/p\u003e\n\u003cp\u003eBecause 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.\u003c/p\u003e\n\u003cp\u003eA vending machine qualifies.\u003c/p\u003e\n\u003cp\u003eSo does any piece of software that deterministically enforces an agreement between parties.\u003c/p\u003e\n\u003cp\u003eWhich means the idea is much broader, and much more useful, than the current shorthand suggests.\u003c/p\u003e\n\u003cp\u003eThe real problem: contracts aren’t simple\u003c/p\u003e\n\u003cp\u003eAll of that works nicely for simple systems.\u003c/p\u003e\n\u003cp\u003eIf 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.\u003c/p\u003e\n\u003cp\u003eBut most real contracts, particularly in financial markets, don’t look like that.\u003c/p\u003e\n\u003cp\u003eThey’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.\u003c/p\u003e\n\u003cp\u003eIt’s worked out through interpretation.\u003c/p\u003e\n\u003cp\u003eThat’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.\u003c/p\u003e\n\u003cp\u003eAnd when things do go wrong, as they inevitably do, you don’t turn to the code and say “that’s final”.\u003c/p\u003e\n\u003cp\u003eYou go back to the contract.\u003c/p\u003e\n\u003cp\u003eAnd very often, to the lawyers.\u003c/p\u003e\n\u003cp\u003eCode is not law\u003c/p\u003e\n\u003cp\u003eThere’s a phrase that crops up from time to time: code is law.\u003c/p\u003e\n\u003cp\u003eI’ve never found that particularly convincing in the context of capital markets.\u003c/p\u003e\n\u003cp\u003eCode 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.\u003c/p\u003e\n\u003cp\u003eLaw 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.\u003c/p\u003e\n\u003cp\u003eTrying to collapse one into the other doesn’t really work.\u003c/p\u003e\n\u003cp\u003eYou 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.\u003c/p\u003e\n\u003cp\u003eAt that point, the “smart” contract isn’t particularly smart. It’s just rigid.\u003c/p\u003e\n\u003cp\u003eThis isn’t about blockchain\u003c/p\u003e\n\u003cp\u003eIt’s also worth being clear that none of this is an argument against blockchain.\u003c/p\u003e\n\u003cp\u003eBlockchains 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.\u003c/p\u003e\n\u003cp\u003eBut they’re not what makes something a smart contract.\u003c/p\u003e\n\u003cp\u003eThe 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.\u003c/p\u003e\n\u003cp\u003eBlockchain is one way of doing that.\u003c/p\u003e\n\u003cp\u003eNot the only way.\u003c/p\u003e\n\u003cp\u003eWhere this shows up in practice\u003c/p\u003e\n\u003cp\u003eFrom where I sit, working in post-trade and digital assets, this distinction matters quite a lot.\u003c/p\u003e\n\u003cp\u003eA big part of what we’re doing at \u003ca href=\"https://tokenovate.com\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eTokenovate\u003c/a\u003e is building systems that codify the lifecycle of financial products. In particular, using the \u003ca href=\"https://cdm.finos.org\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eFINOS Common Domain Model (CDM)\u003c/a\u003e to represent the rules of derivatives and securities financing transactions, based on things like ISDA and GMRA agreements.\u003c/p\u003e\n\u003cp\u003eIn many ways, that is exactly what Szabo was getting at.\u003c/p\u003e\n\u003cp\u003eYou 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.\u003c/p\u003e\n\u003cp\u003eBy any reasonable definition, that’s a smart contract.\u003c/p\u003e\n\u003cp\u003eAnd it doesn’t need to sit on a blockchain to be one.\u003c/p\u003e\n\u003cp\u003eBut it still isn’t the whole contract\u003c/p\u003e\n\u003cp\u003eEven then, it’s not complete.\u003c/p\u003e\n\u003cp\u003eYou 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.\u003c/p\u003e\n\u003cp\u003eBut you can’t capture everything.\u003c/p\u003e\n\u003cp\u003eThere 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.\u003c/p\u003e\n\u003cp\u003eAt that point, you fall back to the legal contract.\u003c/p\u003e\n\u003cp\u003eAnd, usually, to the lawyers.\u003c/p\u003e\n\u003cp\u003eSo what are smart contracts, really?\u003c/p\u003e\n\u003cp\u003eIf you strip away the hype, smart contracts are best understood as:\u003c/p\u003e\n\u003cp\u003esystems that automate the well-defined parts of an agreement.\u003c/p\u003e\n\u003cp\u003eThat’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.\u003c/p\u003e\n\u003cp\u003eIn simple systems, smart contracts work well.\u003c/p\u003e\n\u003cp\u003eIn complex financial instruments, they’re only part of the picture.\u003c/p\u003e\n\u003cp\u003eClosing thought\u003c/p\u003e\n\u003cp\u003eThe original idea behind smart contracts still stands up. If you can define the rules clearly enough, you can get the system to enforce them.\u003c/p\u003e\n\u003cp\u003eThat’s worth pursuing.\u003c/p\u003e\n\u003cp\u003eBut it only takes you so far.\u003c/p\u003e\n\u003cp\u003eYou can automate the predictable bits. You can make execution cleaner. You can reduce the need for trust in process.\u003c/p\u003e\n\u003cp\u003eBut 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.\u003c/p\u003e\n\u003cp\u003eSo yes, smart contracts are useful.\u003c/p\u003e\n\u003cp\u003eBut they’re not quite as smart as we sometimes make them out to be. Oh, and they don\u0026rsquo;t have to live on a blockchain.\u003c/p\u003e\n","url":"https://stevehaigh.net/posts/smart-contracts-before-blockchain/","date_published":"1106-01-09T100:11:00+00:00","date_modified":"1106-01-09T100:11:00+00:00","author":{"name":"Steve Haigh","url":"https://stevehaigh.net/"}}]}