On July 15, DTCC, the plumbing under nearly every share and Treasury in America, ran real production trades with tokenized assets. More than thirty firms took part. BlackRock. JPMorgan. Goldman Sachs. Vanguard. The trades settled on two networks: DTCC's own private chain, and exactly one public one, Canton.
Crypto read the headline as adoption. Fair enough. But the more useful question is the one almost nobody asked: how does a list like that get made? Why does the public slot go to a network most retail investors had never traded, instead of any of the chains they had?
The answer is a process. Institutions don't discover technology the way markets do, by momentum. They select it, through a review most outsiders never see. I've spent my career inside that review on the data side of large enterprises, and once you've seen how it works, lists like DTCC's stop looking like surprises and start looking like verdicts. This piece walks you through the review, so the next time a chain claims institutional adoption, you can judge the claim like the institutions would.
The reframe
Ask a crypto investor how to judge a blockchain and you'll get a familiar list. How decentralized is it. How fast. What does the token do, how does the supply work, what's it settling that nothing else can. Which apps are being built, and how much attention are they pulling. These are real questions, and on an established chain they're most of how a retail investor decides where to put money.
Now walk into a bank and ask how they'd judge the same chain. You won't hear any of that. Not at first, maybe not at all.
The conversation starts somewhere else entirely: with strategy. What is the organization actually trying to achieve, and how does that intent travel down from the boardroom to the teams doing the daily work. Any system that wants in has to serve that line. And the moment you're talking about a system that will hold or move the institution's information, one word decides everything that follows. Whether the data is fit for purpose.
That phrase does a lot of work, so here's what it means on the ground. Data is fit for purpose when it can be trusted to do the job you're about to ask of it. It's complete, so nothing critical is missing. It's on time, so you're not deciding on last week's picture. It's consistent, so the same question gives the same answer no matter who asks or where they look, at the raw database level and at the conceptual level a human actually reasons about. When those things hold, everything built on top inherits the trust: the analytics produce insight the organization can act on, because the ground they stand on is solid. When they don't, the institution is making confident decisions on quiet nonsense, and won't know until it hurts.
Getting data to that state is a discipline, not an accident. It runs on a stack of capabilities with names most investors never encounter: data quality, data governance, lineage, training and awareness, change management. Every one of them exists to serve that single aim. Fit for purpose. And braided through all of it is compliance, the internal and external guardrails that say not just is this data good, but are I allowed to use it this way. That's the next layer, and it's where the institution's world gets genuinely hard.
The checklist, and the humans behind it
So what does that hard layer actually consist of. Strip away the jargon and enterprise data compliance comes down to a handful of capabilities, each one a different angle on the same fit-for-purpose promise. A few are worth knowing by name, because they're where a chain either passes or fails long before anyone looks at its throughput.
The first is data quality, which I've already met. It's the machinery that keeps information complete, consistent, unique, and on time, good enough to build real decisions on. Necessary, but on its own not enough, because quality doesn't maintain itself. Someone has to be on the hook for it.
That someone is the point of the second capability: data governance. And here's what most technical descriptions miss: governance is not about data. It's about people. You cannot manage information effectively by writing a policy and hoping. The only thing that actually works is ownership: for every piece of data that matters, a specific human being is accountable for whether it's fit for purpose. Not a department, not a system. A person, by name, who answers for that number.
Ownership changes the whole character of the thing. Once a real person is accountable for a dataset, they start to care about it the way you care about anything that carries your name. And accountable people don't stay isolated, they organize. That's where governance bodies come from: standing groups that convene to settle the questions no single owner can resolve alone. What happens when two departments define "active customer" three different ways and the numbers won't reconcile. What happens when someone's using data in a way it was never cleared for. What happens when a use runs up against a regulation. Those conflicts land on the governance body's table, and someone has to rule. That's not bureaucracy for its own sake, it's the mechanism by which an organization keeps its data honest at scale.
And underneath both sits a quieter capability that makes the rest possible: training and awareness. None of this works if the people handling the data don't know how. An organization has to actively teach its own people to treat information with the care the rules demand, or the ownership and the governance bodies are just structure with nothing holding it up.
Put those together and the shape of internal compliance comes clear. It isn't a rulebook. It's ownership, the bodies that ownership creates, and the knowledge that lets people carry it, all pointed at keeping the data fit for purpose. Which is exactly why the systems an institution lets near that data get judged so hard. The system doesn't just have to be good. It has to fit inside a structure built entirely around trust and accountability, and prove it belongs there.
How the decision actually gets made
Here's the honest part nobody selling software leads with: no single tool meets a hundred percent of what an institution needs. That's not a failure of the tools. It's the nature of the problem, because by the time an organization sits down to choose, the list of what it needs has grown enormous.
Look back at everything I've walked through, because the institution has to hold all of it at once. The strategy filtering down through tactical and operational levels. The data foundations underneath. The capabilities that keep data fit for purpose. The ownership and the governance bodies. The analytics use cases riding on top. The internal and external guardrails. Every one of those is a source of need, and together they distill into something concrete: a requirements list. This is the thing the institution is actually shopping with. Not a wish for "a blockchain," but a specific catalog of what its data world demands, drawn from the real pain its people live with.
That list is the entry ticket, and it's how you should read any enterprise technology decision. The buyer isn't browsing. They're holding a document that says here is what I need, and asking the market to answer it.
Then the gauntlet begins. The requirements go out to multiple vendors, and each one comes back to show how their tool meets them. Often that's not a slide deck but a sandbox: the vendor stands up a working environment, and the stakeholders closest to the problem, the people who'd actually live with this thing, get to test it against reality. Through that testing period the organization scores what it sees against a checklist built from its own needs. The tool that meets the requirements to a significant degree is the one that advances. The ones that fall short don't.
And meeting the checklist isn't even the whole of it. Other dimensions weigh in, the quality of support the vendor can provide, how they'll behave when something breaks at two in the morning, whether they'll still be standing in five years. An institution isn't buying a tool for a quarter. It's choosing something it intends to build on, so it's judging the vendor as much as the software.
Once the dimensions are weighed and a vendor is chosen, a contract gets signed, and implementation begins. And this is where the weight becomes real, because implementation is not installation. Every part of this, again, is about the people. A new tool means adapting the processes around it, and training, and retraining, the human beings who'll use it. Change management is a discipline of its own, and it eats resources: an adoption phase, an implementation phase, training, a feedback loop, adjustment, step after step until the people and the organization are genuinely comfortable with the thing. That doesn't take weeks. It can take years.
Which is why large institutions correct course slowly, by their very nature. Tool selection at this level is close to a lifetime marriage. Reversing it once you've paid for the change management, reshaped the processes, and bent the whole organization to make room for the new system, that costs more than the original decision did. So the discipline all points one way: get it right at the jump, because the price of getting it wrong compounds for years.
And that single fact is the one an investor should hold onto, because it's about to change what the DTCC list actually means.
Why most chains fail the review
Now run an ordinary public blockchain through that gauntlet, not as an investor, but as the institution holding the requirements list. It goes badly, and it goes badly early.
Start with the first requirement any data organization writes: control over who sees what. A conventional public chain is radically transparent by design. Every balance, every transaction, every counterparty relationship, published to the world, forever. For crypto, that transparency is the point. For a bank, it's the immediate end of the conversation, because the bank is not permitted to broadcast client positions, and no compliance officer alive signs off on "everyone can see everything, but the addresses are pseudonyms." Pseudonymous is not private. Ask anyone who's watched a wallet get de-anonymized.
The usual answer is to bolt privacy on top, mixers, encryption layers, off-chain workarounds. But recall what the review is actually testing: whether the guarantee lives in the system or in a promise. Bolted-on privacy is an application making a promise. The institution needs the rail itself to enforce it, the way access rights inside its own data estate are enforced, not requested.
Access control fails next. Enterprise data access is granular by role, by purpose, by jurisdiction. Most chains offer two settings: everyone, or no one. Then compliance: KYC, data residency, the regulator's right to look. On a chain where data lives everywhere and belongs to no one, those questions don't have clean answers, so the chain's answer becomes "that's the application's problem." The requirements list disagrees. It was written by people whose names go against the number, and they are not signing for a rail that shrugs.
None of this makes those chains bad technology. It makes them the wrong shape for this buyer. The review isn't hostile to crypto. It's indifferent to it, which is worse.
Canton against the requirements
So what does a chain that survives the review look like? Walk Canton down the same list, and label the evidence as I go, because that discipline is the point of this publication.
Privacy first, the requirement that kills most candidates at the door. Canton's answer is confirmed, documented protocol behavior, not marketing: privacy operates at the sub-transaction level as a property of the rail itself. A transaction is decomposed into views, and each party receives only the slice it's entitled to see. In a settlement between two banks, each sees its own leg. The network as a whole never holds a public copy of the deal, because there is no single global ledger for it to sit on; only the parties to a transaction store its data. For the compliance officer reading along: this is the difference between masking data and never distributing it in the first place.
Access control, same verdict, confirmed. The rules for who sees what are written into the smart contracts themselves, in Daml, Canton's contract language, and enforced by the protocol at every step. Permissioning isn't a policy sitting beside the system. It is the system, which is precisely the shape the governance review is looking for, because it's the shape the institution's own data controls take internally.
Atomic settlement, confirmed, and worth a sentence of plain English. Delivery-versus-payment means both legs of a trade complete together or not at all, no window where one side has paid and the other hasn't delivered. Canton executes that atomically even while keeping each party's view partial. Settlement risk, the thing a treasurer actually loses sleep over, is engineered out at the rail.
Now the honest labels. On regulatory data rights, the right to be forgotten under GDPR, for instance, Canton's data minimization design is built with that alignment in mind, but that's announced intent, vendor-stated, not yet a proven compliance record. And there is a genuine open challenge worth naming rather than hiding: precisely because data is partitioned and no validator holds the whole picture, coordinating consistent end-to-end audit trails across parties is harder than on a transparent chain. The audit view the regulator wants has to be assembled, not simply read. Anyone who tells you a privacy-first architecture has no trade-offs is selling something. This is the trade-off, and the institutions buying in are doing so with eyes open.
Which brings me back to July 15. DTCC's tokenization service runs a deliberately multi-chain strategy, its own private network alongside one public one. Canton didn't beat a field of public chains in a bake-off I can see; what's confirmed is narrower and, I'd argue, more telling: when the most conservative market infrastructure in America composed its settlement menu under a full institutional review, exactly one public network was fit to appear on it. The review is why the menu is that short.
The verdict, and the lens you keep
Pull the threads together and the investor lesson is compact. An institution choosing a chain is not making a bet. It's concluding a review, one that started in its own data pains, hardened into a requirements list, survived vendor gauntlets and sandboxes and board scrutiny, and ends in something close to a lifetime marriage, because unwinding it costs more than choosing it did. That's why institutional adoption is slow. It's also why it's sticky, and why it means more than any metric crypto natively produces.
So here's the lens, yours to keep. When the next chain announces institutional adoption, ask the review's questions. Is privacy a protocol property or an application promise? Is access control enforced by the rail or requested of it? Would a compliance officer put their name against this? And is the evidence confirmed, announced, or just hoped?
By that lens, what happened on July 15 was not a headline. It was a verdict from the most demanding reviewers in finance, delivered after the longest gauntlet in the industry, with October set as the date the marriage papers get signed. Announced claims score zero around here. This one is confirmed.
One question worth sitting with: which requirement on the institutional list do you think the next wave of public chains will fail first, privacy, access control, or auditability?
Disclosure: I hold Canton Coin ($CC). This is analysis, not financial advice. Always do your own research.
References and further reading
- DTCC press release, 15 July 2026: U.S. trades successfully processed using DTC-tokenized assets (businesswire.com)
- Canton Network protocol documentation: sub-transaction privacy and Daml permissioning (canton.network)
- Halborn, need-to-know privacy analysis of Canton (2026); Messari, Canton Network overview (2026)
- Blockdaemon on the regulatory challenges of partitioned-validator architectures (2026)
- DAMA-DMBOK: the formal reference for the data management capability model discussed in Parts 1 and 2
- GDPR (EU 2016/679), for the data rights discussed