DAML's Canton network doesn’t tokenize securities—it syndicated-loan-izes them
The Nature of Smart Contracts and Data Oracles (Part 4): Canton’s model introduces economic and operational friction that banks might not fully appreciate until they try to scale beyond pilots.
{
"article_info": {
"title": "DAML's Canton network doesn’t tokenize securities—it syndicated-loan-izes them",
"author": "Swen Werner",
"date": "March 19, 2025",
"series": "The Nature of Smart Contracts and Data Oracles (Part 4)"
},
"technical_absurdities": [
{
"issue": "Blockchain Theater",
"description": "The protocol uses blockchain terminology as a 'fancy wrapper' for traditional bookkeeping without adopting decentralization or independent settlement.",
"evidence": "Broadridge's DLR settlement still relies on conventional payment rails and central securities depositories (CSDs) while claiming tokenization."
},
{
"issue": "Architectural Layering Mismatch",
"description": "DAML contracts are stored on a separate blockchain (VMware/Broadcom) but cannot be executed by it directly.",
"impact": "Requires a separate DAML runtime to interpret logic, creating a layered architecture where the blockchain is merely a passive data store with no direct interoperability between chaincode and contract logic."
},
{
"issue": "The IT Coordination Bottleneck",
"description": "Canton requires every counterparty to run and sync specific code for a transaction to occur, turning a commercial trade into a multi-party software deployment problem.",
"absurdity": "If one counterparty's node is offline, misconfigured, or under an 'IT moratorium,' the entire market transaction stalls. It introduces co-dependencies that are more complex than the traditional systems they replace."
},
{
"issue": "Absence of a Global State",
"description": "Unlike public blockchains (e.g., Ethereum) where the network verifies a universal state, Canton allows participants to selectively hide or reveal asset existence.",
"consequence": "Asset visibility depends entirely on the issuer’s discretion. There is no immutable, shared registry that the network can independently verify without trusting the issuer as an authority."
},
{
"issue": "Negotiability Paradox",
"description": "True securities lose issuer control once sold. Canton assets require the issuer's permission for disclosure and subsequent transfers.",
"legal_operational_flaw": "By maintaining issuer control over transferability, the assets behave like syndicated loans (cumbersome/inefficient) rather than truly negotiable market securities."
},
{
"issue": "Synchronization Domain Complexity",
"description": "Moving assets across different 'domains' requires coordination between sequencers andStakeholders to re-host contracts.",
"impact": "Creates operational friction that scales poorly once firms move beyond controlled pilots into real-world market scenarios."
}
],
"historical_parallel": {
"metaphor": "Franconian Knights' Cantons (1806)",
"meaning": "Like the independent but fragile knightly states swallowed by Bavaria, Werner predicts Canton’s decentralized IT model will eventually collapse into centralized control by CSDs as the 'friction' becomes unbearable."
},
"conclusion": "Canton introduces characteristic characteristics of loan markets—fragmented visibility and manual management—making it the most cumbersome digital asset class in existence."
}I had previously covered various issues concerning the nature of smart contracts and data oracles (in three parts), and this article follows on from that. My comments are entirely based on my interpretation of publicly available information, which means I could be missing important aspects that are only available to insiders. If that’s the case, DAML might want to take this as a prompt for their marketing team to do better.
After all, if someone like me can’t draw the right conclusions from their information, then—at the risk of sounding arrogant—I’d say the problem is unlikely to be on my end.
The Canton blockchain protocol is touted as a:
“A scalable, privacy-enabled enterprise blockchain protocol.”
Did they recently refresh their branding, similar to what DTC did last year? It now features a green-yellowish color. I think it’s close to Light Chartreuse, named after a French herbal liqueur made by Carthusian monks near Grenoble. Sometimes it’s called Electric Lime Wash (a more vibrant version of chartreuse). Cheers to that!
Canton, as part of the DAML universe, is often seen in the context of Broadridge’s Repo solutions using distributed ledger technology. I mentioned it before, but this is not blockchain in the conventional sense.
According to Broadridge, DLR uses the Daml smart contract language on the VMware blockchain. VMware was acquired in 2022 by Broadcom, a US semiconductor company, and their blockchain is described as:
“An EVM-compatible platform that will provide high-throughput performance, unique ZKP-based programmable privacy capabilities, enterprise-grade operations, and governance features.”
So high throughput performance means no decentralized consensus but something more centralized, and the ZKP-based privacy indicates the inability to independently verify all blockchain records.
Broadridge states that:
“Settlement is made by triggering a payment on conventional payment rails.”
and that:
“DLR uses smart contracts to mutualize the workflow,” which is “built on top of its existing connectivity with central securities depositories (CSDs) and custodian banks.”
But they also say:
“The underlying collateral securities are locked and tokenized, enabling ownership to be transferred using smart contracts.”
Does this all fit together? No—not at least in the conventional sense of what tokenization means.
Why not?
If you store DAML contracts on another blockchain, you need the DAML runtime to interpret and process those contracts.
This means:
VMware blockchain only stores the data.
The Daml platform handles execution, logic, and permissions.
There’s no direct interoperability between Daml contracts and the chaincode.
So while the blockchain provides storage—and in this case, Broadridge controls the consensus to book updates—all business logic and contract execution must run through DAML. This makes it a layered architecture rather than a fully integrated solution between its blockchain and smart contract components, which remain layered on top of the existing securities and cash infrastructure.
It’s classic marketing doublespeak—they want the benefits of blockchain terminology without actually adopting its principles. It’s blockchain theater—a fancy wrapper around traditional finance, pretending to be something new while doing everything the old way. The benefit comes from workflow orchestration not from the chosen technology:
No real decentralization—just centrally controlled nodes.
No real tokenization—just internal bookkeeping with a new label.
No independent settlement—still relying on traditional rails.
So what about Canton?
The term “canton” was historically used in France and some parts of Germany, but it largely fell out of favor due to political and administrative centralization. Today, the term only survives in Switzerland and parts of Belgium but is no longer used in Germany or France in any meaningful administrative sense.
Bavaria, for instance, had six Franconian Knights' Cantons aligned with the Holy Roman Empire, which ceased to exist in 1806 as a result of Napoleon’s reordering of German states into the Confederation of the Rhine (Rheinbund or États confédérés du Rhin). This meant that the Imperial Knights (Reichsritter) and their territories were absorbed by larger sovereign states like Bavaria, Württemberg, and Baden.
The German equivalent of a canton in a territorial sense was often “Mark” (border region). A Mark was a borderland or frontier territory, governed by a Markgraf (Margrave). For example, the Ostmark (Eastern March) was a military buffer zone that later became Austria.
Engraving depicting two eagle wings holding an orb and sword, inspired by a 1736 frontispiece of the Six Franconian Knightly Cantons.
The Knights' Cantons Were a “State Within a State”
The Reichsritter operated under imperial jurisdiction, not local Bavarian laws.
They had their own tax system, judicial courts, and governance through the Ritterkantone (knightly cantons).
They were independent, answering only to the Emperor, governing their own lands, and maintaining exclusive contracts—but they were also fragile.
Their survival depended on an invisible system of laws that bound them together but left them defenseless when the empire collapsed.
So in 1806, Bavaria (with Napoleon’s approval) forcibly annexed all remaining knightly lands—while the Emperor no longer provided protection and left them powerless to resist.
And DAML’s Canton? Kind of the Same.
Canton’s architecture is designed so that each business “party” runs a participant node that stores and processes only the data relevant to that party’s contracts, rather than sharing a global state with all nodes. Participants connect via synchronization domains, which provide ordering (via a sequencer) and coordination services. This creates a “virtual global ledger” composed of many private ledgers that can interoperate securely.
In essence, each set of stakeholders maintains its own private blockchain segment and exchanges cryptographic proofs with others, enabling atomic cross-organization transactions without exposing confidential data.
The IT Bottleneck Issue
By design, Canton’s distributed model introduces interdependencies among counterparties’ systems. Since contracts are shared (privately) between the parties involved, those parties’ nodes must all be online and in sync to execute transactions or update contract states. If one participant node is slow, unreachable, or misconfigured, it can hold up the joint transaction.
If a contract spans multiple domains, the initiating party must coordinate with other stakeholders to first transfer those contracts to one domain before the atomic transaction can occur.
In other words, a bank can’t unilaterally move assets in a multi-ledger workflow; it needs counterparties to cooperate operationally (by approving transfers or domain changes) to complete a transaction. This introduces a new kind of IT coordination between firms, baked into the platform’s architecture.
Canton’s Own Documentation Admits the Problem
Canton’s documentation itself highlights some of the consequences of these interdependencies. For instance, if one participant in a shared contract goes offline, it can block certain ledger maintenance tasks for others:
“An offline participant can prevent the pruning of contracts by its counter-participants.”
In practice, this means if Bank A and Bank B share a contract on Canton, Bank A cannot fully garbage-collect or archive that contract’s data while Bank B’s node is down or unresponsive.
Canton is working on features to mitigate these issues—such as “attestators”, trusted third parties that can be appointed to help progress workflows if a counterparty’s node is unresponsive. But how a bank could delegate control to a third party in this way without legal or operational risks remains unclear.
The International Securities Services Association (ISSA) has noted, although not in the specific context of Canton, that multi-firm DLT projects often require close coordination, and that:
“Co-dependencies tend to be less well understood and potentially more complex” due to the novel nature of the technology.
So let me spell out what that practically means.
The IT Bottleneck Issue
In a traditional financial system, onboarding a new counterparty or setting up a trade does not require deploying new software in every participant's infrastructure. The legal agreements and settlement instructions are process-driven rather than code-driven, meaning they can be modified by middle-office and operations teams without requiring IT intervention.
With Canton, however, every new counterparty relationship requires:
A DAML contract explicitly modeling the terms of that relationship (A-B pairing).
Deployment of this smart contract across the IT environments of all involved parties.
Coordination between each party’s IT teams, who must support, upgrade, and maintain these contracts without breaking existing infrastructure.
Now, let’s say:
A retail bank’s IT team is overwhelmed with a separate compliance upgrade or digital banking initiative.
There’s an IT moratorium in December (as most banks impose to avoid year-end risks).
A new trading counterparty needs to be onboarded for a repo transaction.
Under Canton, if one party’s IT is unavailable, the whole transaction is delayed or impossible because the smart contract must be actively deployed and updated on all participant nodes.
This is radically different from today’s financial markets.
Radically different, but not radically better.
The Multi-Domain Complication
Let’s say you are lending a security to Counterparty B, but you are waiting for Counterparty A to deliver it, so you can lend it to Counterparty B.
The A → You arrangement encoded in a smart contract does not provide atomicity for the A → You → B chain.
To achieve atomicity, you would need an A → You → B smart contract, and your local IT team must integrate this into your environment before the transaction can even occur.
Now, if you trade across multiple Canton domains (say, you and A are in Domain X, but B is in Domain Y), the workflow requires coordination between domains, and at some point:
The contracts need to be re-hosted on a common domain, or
There must be an inter-domain atomic swap involving sequencing, validation, and approvals across multiple parties’ ledgers.
The more domains involved, the more complex the IT dependencies become.
Suddenly, the simple act of lending a bond turns into a multi-party software deployment problem.
And if one firm’s IT department is slow (or under an upgrade freeze), entire market transactions can stall.
Scaling Canton Requires a Radical Change in Market Behavior
For a Canton-based market to truly scale, participants would need a radically different governance model, where all counterparties agree to run Canton nodes as a priority service.
But that’s a huge cultural, risk, and operational shift for banks, where IT resources are already stretched thin.
If a CSD launched a new digital repo system, it could centrally coordinate transactions without requiring Canton’s smart contract dependencies.
But then it raises the biggest question of all:
Why DAML versus any other software?
If (When?) Canton Collapses, What’s Left?
My point is: Canton’s model introduces economic and operational friction that banks might not fully appreciate until they try to scale beyond pilots.
While it works well for pre-arranged test cases, the moment firms face real-world IT constraints, its weaknesses will become apparent.
Once the industry wakes up to this problem, banks could either: Create a Canton workaround (e.g., a managed IT layer where firms don’t need to directly deploy smart contracts).
Return to centralized models that eliminate these IT co-dependencies.
And history tells us what happens next.
When external forces—regulatory pressure, market realities, and operational inefficiencies—demand an answer, systems like Canton collapse into centralized control.
Just like Bavaria swept in and absorbed the knightly lands in 1806, so too will CSDs and centralized infrastructures eventually absorb Canton’s use cases.
When Canton collapses into centralized governance, its core value proposition disappears, and its software is no longer the best choice.
So the only real question is: When and how will CSDs take over? But there’s more that makes this approach problematic.
Canton is Different from a Public Blockchain Like Ethereum
There Is No Universally Shared Ledger
In Ethereum, when you mint a token, the entire network sees it and can verify its existence.
In Canton, a participating institution chooses what the network knows—there is no single, transparent asset registry.
Privacy Means You Must Trust Counterparties
Ethereum uses a single, universal state where all transactions update the same ledger.
Canton allows counterparties to share only the information necessary for a contract, meaning the system doesn’t even have full visibility of its own assets.
In Ethereum, ownership is enforced by cryptographic consensus—nobody can hide or selectively reveal asset details.
In Canton, a party decides what information is available, meaning the system doesn’t function without trusting that party as an authority.
What Is The Consequence?
Canton isn’t a decentralized asset system—it’s a distributed contract execution system with selective disclosure.
If Goldman Sachs (GS) tokenizes an asset on Canton, that token is just a data entry—it has no independent market presence.
Unlike a real tokenized bond on Ethereum, a Canton-based bond cannot be independently verified unless GS allows it.
An asset’s visibility and existence depend entirely on the issuer’s discretion, not on an immutable shared ledger.
And since every participant can assume this role, it creates an interesting problem.
A Canton-Based Asset Cannot Be a Marketable Security
The principal benefit of a security is that once the issuer sells it, they no longer control its transferability.
The entire point of a security is that it can be freely traded, without needing the original issuer’s permission for every subsequent transfer.
In Canton, the issuer can choose what information is shared and what trades are allowed, meaning the asset is not truly negotiable.
This is my personal opinion—I am not a lawyer and do not mean to provide legal advice.
What This Means for Canton’s Future
The only way this model could succeed is if banks and financial institutions decide that workflow orchestration itself is valuable enough to justify using Canton-style semi-tokenization, despite its fundamental contradictions.
But for that to work, securities settlement would have to function more like syndicated loan platforms, where each trade is manually managed.
No free transfers
Fragmented visibility
These are characteristics of loan markets—which are also the most cumbersome and inefficient asset class in existence.
So, we will see.
{
"article_info": {
"title": "DAML's Canton network doesn’t tokenize securities—it syndicated-loan-izes them",
"author": "Swen Werner",
"platform": "LinkedIn / Substack",
"core_thesis": "Canton is 'Blockchain Theater'—a layered architecture that creates a digital version of inefficient loan markets rather than a negotiable securities market."
},
"technical_absurdities": [
{
"issue": "Architectural Layering Mismatch",
"absurdity": "The protocol requires a separate DAML runtime to interpret contracts stored on a passive blockchain (like VMware).",
"impact": "There is no direct interoperability between the chaincode and the contract logic. The blockchain acts as a simple 'shunting yard' (Verschiebebahnhof) for data while execution remains siloed."
},
{
"issue": "The IT Coordination Bottleneck",
"absurdity": "Transactions require all involved counterparty nodes to be online, synchronized, and running matching code simultaneously.",
"impact": "If one bank’s IT team is under an 'upgrade freeze' or a node is misconfigured, the entire market transaction stalls. It turns a commercial trade into a multi-firm software deployment dependency."
},
{
"issue": "The Absence of Global State",
"absurdity": "Unlike public ledgers (Ethereum) where assets are universally verifiable, Canton participants choose what the network 'knows'.",
"impact": "An asset's existence depends entirely on the issuer's discretion. This creates fragmented visibility where the system cannot verify its own assets without trusting the original authority."
},
{
"issue": "The Negotiability Paradox",
"absurdity": "Canton-based assets are not truly negotiable because the original issuer retains control over disclosure and subsequent transferability permissions.",
"impact": "This removes the primary benefit of a security (free tradability) and replaces it with the manual management characteristics of a syndicated loan platform."
},
{
"issue": "The Multi-Domain Complication",
"absurdity": "Moving assets between different 'synchronization domains' requires complex coordination to re-host contracts on a common sequencer.",
"impact": "It introduces a massive IT overhead that scales poorly, essentially forcing users back into centralized workarounds to avoid protocol friction."
}
],
"historical_parallel": {
"metaphor": "The Franconian Knights' Cantons (1806)",
"meaning": "Canton nodes are 'states within a state'—independent and exclusive until the lack of a protective central authority (or the friction of their own isolation) leads to their absorption by centralized entities (CSDs)."
},
"verdict": "Canton is a distributed contract execution system with selective disclosure, creating the most cumbersome digital asset class in existence."
}
Hi, short answer: this cannot be possible. The validators see a stream of transaction hashes only and ID. That leaves correlation risk but I am not familiar with the details on that specific set up to say more than that.
#BSV the genuine Bitcoin is the only Blockchain that can truly scale (Teranode).