In late January 2026 the Canton Network team ran a developer experience and tooling survey. Forty-one active developers responded between January 20 and February 4. Eighty percent had joined the ecosystem within the previous twelve months. Seventy-one percent came from Ethereum. The line the writeup foregrounds is that developers reported being forced to act as “Infrastructure Engineers before Product Builders.” Forty-one percent named environment setup and node operations as the longest task to master before they could ship anything.
Forty-one respondents is a small sample, and the survey writeup says so. It is roughly the size of a single founding cohort at one of the larger Canton apps. The directional findings line up with everything else in the public record (third-party blog posts, the forum’s thread history, the explicit releases Digital Asset has shipped since), and the demographic mix is what makes the survey useful. The people building on Canton today are, in their large majority, EVM-trained developers in their first year of touching Daml and a node operator’s toolchain at the same time.
This piece is a practitioner read on what that population is running into, what shipped in the six months before and after the survey, and where the EVM-to-Canton shift remains hard no matter how good the tooling gets. It is also a snapshot. The DevEx story moves fast enough that anything written today carries a velocity caveat: what is missing this quarter may land in a release the next.
For background on the network and its token model, see the earlier Canton Coin tokenomics and CIP-0114 DAT program pieces.
The four shifts that actually trip people up
The translation tables in the official Canton-for-Ethereum-Developers module make the migration look like a vocabulary lesson. Address becomes Party, function becomes Choice, gas becomes Traffic, ERC-20 becomes CIP-0056, and so on. That table is real and useful, but it understates the work. The reason Solidity developers stall on Canton is not that the keywords are different. It is that four pieces of the mental model invert.
1. Global mutable state becomes party-scoped immutable contracts
In Solidity, a contract is a long-lived object with mutable fields. You change a balance by writing balances[to] += amount;. The state is in the contract; the contract stays put; the EVM keeps a global trie that every full node maintains. Anyone can eth_call it.
In Daml, a contract is an immutable record on a sub-ledger. A state change archives the old contract and creates a new one. There is no global trie. The participant nodes that host the parties involved in a contract see it; nobody else does. Querying “what is Alice’s balance” is not a function call against a global state. It is a query against the Active Contract Set of Alice’s hosting participant, scoped to what your party is authorized to see.
The first surprise for an EVM developer is that there is no equivalent of getReserves() you can call from another contract to read state you do not have privileges to. The privacy model is enforced at the data layer, not the application layer. A second surprise is that “update a value” is a misframing. You always create a new contract that supersedes the old one. Workflows look more like event sourcing than like field assignment.
2. Address becomes Party — and Party is not a key pair
In EVM, an address is the public-key hash of an externally-owned account (EOA), or the deterministic address of a deployed contract. Anyone can send a transaction signed by the right key. Identity is permissionless and global.
In Daml, a Party is an allocated entity on a specific participant node. Parties are not derived from a key pair. They are explicitly created (allocateParty) and managed. In the institutional path, parties are often tied to traditional Web2 identity via JWT-authenticated API access to the Ledger API. There is no tx.origin, no “anyone can send a transaction.” A transaction is submitted by a user (in the Ledger API sense) acting as one or more parties hosted by a participant.
The deeper point is that Canton’s identity model is closer to a permissioned messaging system with cryptographic settlement than to a permissionless blockchain. That is by design and it is exactly what makes the model attractive to institutional users. For an EVM developer it means a chunk of the muscle memory around address validation, signature recovery, and msg.sender checks does not transfer.
3. require(msg.sender == owner) becomes a compile-time signatory declaration
This is the inversion that bites hardest in day-to-day code.
In Solidity, authorization is a runtime check. You write require(msg.sender == owner, "not owner"); and the EVM evaluates it on each call. You can express patterns like “anyone can call this function, but the behavior depends on who called it” trivially.
In Daml, authorization is a compile-time property of the template. You declare which parties are signatory to a contract (meaning their authorization is required for the contract to exist) and which parties can exercise each choice. The protocol enforces this at submission time. You do not write require. The compiler and the protocol together refuse to commit a transaction that lacks the required authorizations.
The translation table that maps msg.sender to “Controller” is technically correct, but the asymmetry matters. msg.sender is a runtime per-call property. A Daml choice’s controller is a compile-time per-choice declaration. Patterns like “anyone may call this; we will check who you are and branch internally” exist in Solidity and do not have a direct Daml equivalent. You restructure: separate templates per role, or a generic template with role-specific choices, each declaring its controller. Some Solidity authorization patterns become impossible. Others become much harder to misconfigure.
Here is what a minimal token transfer looks like in each.
Solidity:
mapping(address => uint256) public balances;
function transfer(address to, uint256 amount) public {
require(balances[msg.sender] >= amount, "insufficient");
balances[msg.sender] -= amount;
balances[to] += amount;
}Daml (sketch — propose-accept):
template Holding
with
issuer : Party
owner : Party
amount : Decimal
where
signatory issuer, owner
choice Propose_Transfer : ContractId TransferProposal
with newOwner : Party; transferAmount : Decimal
controller owner
do
assertMsg "insufficient" (transferAmount <= amount)
create TransferProposal with
issuer; sender = owner; newOwner; transferAmount
template TransferProposal
with
issuer : Party
sender : Party
newOwner : Party
transferAmount : Decimal
where
signatory issuer, sender
observer newOwner
-- the recipient's authorization is collected here.
choice Accept_Transfer : ContractId Holding
controller newOwner
do
create Holding with
issuer; owner = newOwner; amount = transferAmountThe shape difference is the point. In Solidity, the sender executes transfer and the recipient’s address is just a key in a mapping; no consent from the recipient is required at the protocol layer. In Daml, transferring ownership across parties requires the recipient’s authorization, so the canonical idiom is two-step: the sender exercises Propose_Transfer (carrying the sender’s authorization), and the recipient exercises Accept_Transfer (carrying theirs). The Holding is signed by both issuer and owner; the choice on the proposal is controlled by the new owner specifically because their authorization is what’s still missing.
The sketch elides partial transfers (the remainder back to the sender) and revocation (the sender’s ability to withdraw the proposal). A production token uses a richer set of choices on top of the same propose-accept skeleton — the CIP-0056 token standard formalizes the full flow. What matters for the paradigm comparison is the choreography: Solidity’s atomic state mutation versus Daml’s protocol-enforced multi-party authorization.
4. emit Event becomes subscribed transaction trees
Solidity contracts emit events that get indexed in receipt logs. Off-chain consumers run eth_getLogs or subscribe to filtered topics. The Graph protocol made an entire ecosystem of indexing tooling around this pattern.
Canton contracts do not emit custom events. State changes are observable as transaction trees through the Ledger API: subscribe to the Transaction Service for your parties, read the Active Contract Set, and react. There is no equivalent of indexed log topics. As the ioBuilders deep dive put it, “off-chain applications must subscribe to ledger services to listen for and interpret transaction results.” Off-chain plumbing that an EVM team has reflexively built with The Graph for the last five years needs a different shape on Canton.
Honest framing: none of these four shifts are fixed by better tooling. A unified CLI does not make sub-transaction privacy intuitive to an account-model thinker. A Tenderly-equivalent debugger does not turn require(msg.sender == owner) into a signatory declaration in someone’s head. The paradigm shift is real and it lives in the developer’s head, not on disk. Better tooling can make the second hour better. The first eight hours are conceptual work that has to happen regardless.
The tooling state, by the numbers the survey gave us
With the conceptual shift acknowledged, the survey’s findings about practical tooling are the actionable part. The numbers from the Q1 2026 survey writeup:
| Finding | Number |
|---|---|
| Active developers surveyed | 41 |
| Joined ecosystem in last 12 months | 80% |
| Coming from EVM background | 71% |
| Working on TradFi / hybrid projects | 83% |
| Cited environment setup & node ops as longest task | 41% |
| Times “unified CLI” was mentioned in free-text feedback | 11+ |
The specific tools developers named as missing were Hardhat, Foundry, and Anchor as local development frameworks, and Tenderly as the missing standard for transaction simulation and error decoding. Visual debugging and observability dashboards were the most-requested category after local frameworks. The survey writeup quotes a recurring ask for dashboards that “verify node handshakes (Sequencer/Mediator) without relying on complex terminal commands.”
The lived-experience details are sharper than the percentages. Developers reported “parsing cryptic log files” for debugging, “cobbling together scripts” because no unified toolchain existed, manually extracting hash strings from compiled .dar files and hardcoding them into frontends, and deploying “blindly,” only discovering transaction size limits or cost issues after testnet failures. Package ID discovery for the JSON API was described as “opaque” enough that teams built their own discovery mechanisms and caching layers.
The documentation complaint is the one most visible to anyone who has tried to onboard recently: the materials were fragmented across the Daml language docs, the Canton protocol docs, and the various driver and Splice docs. Holding a coherent mental model required jumping between three separately-versioned doc sites with overlapping vocabulary.
Reading the sample honestly: forty-one respondents cannot tell you the exact percentage of Canton developers who have ever hardcoded a .dar hash. They can tell you the practice is common enough that it surfaced unprompted across a meaningful share of the population that bothered to respond. The directional finding is that the common on-ramp friction is more about tooling and node operations than about Daml syntax. The exact percentages are less useful than the pattern.
For scale context: the Solidity Developer Survey 2025, fielded in February-March 2026, drew thousands of respondents. Canton’s active builder population, by any reasonable measure of the Q1 2026 survey’s denominator, is at least two orders of magnitude smaller than that. The exact ratio is not the point; the order-of-magnitude mismatch is the underlying problem the DevEx investment is trying to address.
What shipped in the six months around the survey
Canton’s response cycle has been faster than the survey-thread tone suggests, and the chronology is worth getting right. Several of the most useful pieces predate the survey; others post-date it. The arc looks like this:
| Date | Release | What it addresses |
|---|---|---|
| July 2, 2025 | Major architectural change to cn-quickstart | Local environment, infrastructure scaffolding |
| Nov 4, 2025 | CIP-0091 approved (Zenith as SV) | Approves third-party EVM bypass on Canton |
| Nov 11, 2025 | Canton 3.4 / Splice 0.5.0 ships | Introduces dpm as preferred unified CLI; JSON Ledger API v2 |
| Jan 20 – Feb 4, 2026 | Q1 DevEx & Tooling Survey runs | The signal |
| Mar 5, 2026 | Zenith launches on Canton | EVM execution layer, Hardhat/MetaMask compatible |
| May 18, 2026 | New unified Canton developer docs site goes live | Consolidates Daml, Canton, driver docs |
The Canton Network Quickstart (cn-quickstart on GitHub) is the most concrete answer to the “Infrastructure Engineers before Product Builders” complaint. It scaffolds a complete local environment via Docker Compose: Java/Spring Boot backend, TypeScript/Vite frontend, Daml smart contracts, PostgreSQL, optional Keycloak OAuth2, and a Grafana/Prometheus/Loki observability stack. The Thetanuts Finance developer testimonial, quoted on Canton’s developer resources page, frames the value crisply: “we could ‘skip’ a lot of the learning curve and we had a full Canton dev environment running in hours and we went from zero to running custom contracts with a custom UI in one day instead of multiple weeks/months.” That quote is published Canton-side rather than independently sourced, so treat it as the vendor-cited testimonial it is. The underlying claim is structurally plausible. The repo does what it says.
dpm (Digital Asset Package Manager) shipped with Canton 3.4 in November 2025 and is the explicit response to the “unified CLI mentioned 11+ times” complaint. The Canton 3.4 release notes describe dpm as the preferred CLI for local dev “from version 3.4.x onwards.” It consolidates project management, build, Java and TypeScript codegen from Daml types, sandbox testing, and integration with PQS and the daml shell into one surface. The deprecation of the older daml assistant is on the same release schedule.
Caveat on dpm: the unification holds on the Canton 3.x track. Daml SDK 2.x (the 2.10.x line in particular) is still in active production, and a meaningful tail of projects has not migrated. The “unified CLI” win is real on the new track but does not retroactively clean up the older one. Teams will be on a mix of daml and dpm for a while.
JSON Ledger API v2 (Splice 0.4 / Daml 3.3 forward) replaced the deprecated v1 with simplified configuration, self-administration endpoints that let users query their own party details and rights, and standardized error responses. The error-response standardization specifically targets the “parsing cryptic log files” complaint.
The new unified developer docs went live May 18, 2026 at docs.canton.network. The structural change is that the previously separate Daml language docs, Canton protocol docs, and driver/Splice docs now sit behind one navigation, with a dedicated “Canton for Ethereum Developers” learning track (Modules 1 through 7) that includes the concept translation tables and a privacy-model deep dive. There is also an llms.txt index for AI-assisted navigation. The launch announcement does not explicitly credit the survey as the trigger, but the structure of the new site directly mirrors the survey’s documentation-fragmentation complaint.
The chronology matters because it sets the right expectation about velocity. Quickstart was already maturing before the survey landed. The dpm CLI shipped a month before the survey ran. The new docs site arrived three months after the survey closed. The cadence is roughly one major DevEx release per quarter.
Honest framing on velocity: “one major release per quarter” is fast against the L1 ecosystem comparison and slow against a Solidity developer’s expectations. A team migrating from a stack where Hardhat releases a new minor version every few weeks is going to experience Canton’s release cycle as glacial regardless of how it benchmarks against other L1s. Both framings are accurate; which one matters depends on whose patience is being measured.
Zenith and the language-only escape hatch
The biggest DevEx event of the past six months did not come from Digital Asset. It came from Zenith, an EVM execution layer for Canton built by ZkCloud (a spinout of Equilibrium Labs) and approved as a Super Validator on the network via CIP-0091, which passed on November 4, 2025. Zenith launched March 5, 2026; the CIP-0091 milestone schedule puts MVP at +4 months from approval (Mar 2026, achieved), demonstrated composability +4 months from MVP (Jul 2026), and growth-and-adoption targets within twelve months.
What Zenith ships is bytecode-compatible Solidity on Canton. Hardhat, Foundry, and MetaMask work. The Zenith launch announcement quotes its CEO directly on the design intent: “Until now, developers building on Ethereum could not easily access Canton’s institutional infrastructure without learning Daml, the network’s proprietary programming language. Zenith removes that barrier.” Every EVM transaction routes natively through the Canton protocol, encapsulated as a Canton transaction; atomic composability with Canton-native (Daml) applications goes through an external_call() primitive.
The framing on crypto-Twitter has been straightforward: Canton finally got EVM compatibility, Solidity devs can ship there now, the language barrier is solved. That framing is half right.
For one class of app, Zenith really is the right answer. A perpetuals DEX, an AMM, or a lending market that does not need sub-transaction privacy and does not need party-based identity, but does want Canton settlement guarantees and access to institutional liquidity, can deploy on Zenith with its existing Hardhat-based toolchain and never touch Daml. For those apps, Zenith is a legitimate endpoint, not a layover.
For the other class, the framing breaks. The institutional features that make Canton interesting (sub-transaction privacy, party-scoped composition, signatory-based authorization, explicit observer disclosure) live in the Daml layer. A Zenith-only app does not get them. An app that wants to compose atomically with Canton-native (Daml) applications still has to reason about parties, signatories, and what is and is not visible across the EVM-to-Daml boundary. Zenith removes the language barrier completely; it removes the paradigm barrier only for apps that did not need the paradigm in the first place.
There is a stronger signal embedded in CIP-0091 itself. Whatever the internal reasoning, the public artifact is that the ecosystem approved an external EVM bypass through governance and assigned its operator Super Validator weight rather than folding EVM compatibility into Canton’s native stack. The decision to formalize a Solidity entry point at the governance layer is a tacit admission that the language barrier was high enough to be worth solving through a partner. That is not a Daml indictment; Daml does things Solidity cannot do for this domain. But it is an acknowledgment that asking every prospective Canton developer to learn Daml as a prerequisite was not a winnable bet on its own.
Status caveat: Zenith mainnet is not live as of this writing. The CIP-0091 milestone math puts MVP done (Mar 2026) and demonstrated composability scheduled around July 2026. Production mainnet timing follows that. EVM apps planning to deploy on Zenith should treat the next two quarters as the build-and-test window, not the production window.
The annotated translation table
The official concept translation tables are accurate. They are also a starting point. Here is the same mapping with the gotchas the docs gloss over.
| Ethereum | Canton | What changes in practice |
|---|---|---|
| Address (EOA) | Party | Not derived from a key. Allocated. Often Web2-tied via JWT auth at the Ledger API. |
msg.sender | Controller (per-choice) | Compile-time declaration, not runtime property. “Anyone-may-call” patterns must be restructured. |
| Smart contract | Template | Defines the shape; instances are individual contracts. |
| Contract instance | Contract (immutable record) | Every state change archives the old and creates a new one. No mutation. |
| Storage variable | Contract field | Lives in a specific contract instance on a specific sub-ledger. |
require() | Signatory / Controller declaration | Protocol-enforced at submission. There is no runtime require. |
emit Event | Subscribe to Transaction Service / ACS | No event topics. Off-chain integration is shaped differently. The Graph pattern does not transfer. |
| Gas (per-op) | Traffic (per-MB, prepaid in CC) | Pricing is by data size, not opcode count. See CIP-0078 on per-transfer fee zeroing. |
| ERC-20 | CIP-0056 Token Standard | Different shape; not a drop-in. |
| ERC-721 / 1155 | CIP-0103 dApp standard | Different model; treat as new design rather than as ERC port. |
| Proxy upgrade pattern | Smart Contract Upgrade (SCU) | Built into the protocol, not a userland pattern. |
| Factory pattern | Template instantiation | Not a workaround; it is how things are. |
| Reentrancy guard | Not needed | Execution model forbids arbitrary external calls inside a transaction. |
| Public mempool / MEV | Not present | Encrypted sequencer payloads; no front-running surface. |
| Flash loan primitive | Not present | No equivalent. |
eth_getLogs | GetTransactionTrees against your parties | You only see what your party is authorized to see. |
| Etherscan / Tenderly | Cantonscan, Lighthouse, CCView (lighter on debugging) | The Tenderly-equivalent gap is the single most-named missing tool. |
| ENS | Canton Name Service (CNS) |
The audit-category inversion. The class of bugs you hunt for changes. As the Credshields security perspective notes, reentrancy is gone (no arbitrary external calls inside a transaction), MEV and front-running are gone (no public mempool, encrypted sequencer payloads), flash-loan amplification is gone (no flash-loan primitive). What replaces them: authorization logic errors (signatory or controller misdeclared in ways that are syntactically valid but commercially wrong), disclosure boundary failures (observer set leaks data the business model did not intend to leak), workflow logic errors (the multi-party flow technically completes but does not match the intended business sequence), interface misuse across composed applications, and choice-controller misconfiguration. The bugs are different. Audit shops good at Solidity are not automatically good at Daml.
Should you learn Daml or wait for Zenith?
This is the question every Solidity developer evaluating Canton will ask. There are three coherent answers, and which one applies depends on what your app actually needs from Canton.
Daml, if you need sub-transaction privacy or party-based identity. If the application needs different parties in the same workflow to see different subsets of the same transaction (the canonical institutional use case: counterparty A and counterparty B settle a trade; A’s prime broker sees A’s leg, B’s prime broker sees B’s leg, the clearinghouse sees both), Daml is the only answer today. The same applies if you need signatories drawn from named institutional parties rather than addresses, or if you want atomic composition with existing Daml apps (the Canton Network Utilities collateral / trading / settlement modules, for example). Zenith’s external_call() lets EVM code reach into Daml apps, but the data structures and authorization on the Daml side are still party-and-signatory shaped. There is no way to opt out of understanding them at the boundary.
Zenith, if you are building shapes that don’t use those features. Pure on-chain DeFi shapes — a perpetuals DEX, an AMM, a lending market — that want Canton’s institutional liquidity rails without needing sub-transaction privacy do not benefit enough from Daml to justify the learning investment. Ship Solidity on Zenith with the EVM tooling you already know, and compose with other Zenith apps as your design needs. The trade is real: you get Canton’s settlement layer and access to its institutional party set; you give up the privacy and authorization machinery you were not going to use anyway.
Zenith now, with Daml on the reading list, if you might want to compose across the boundary later. This is the middle case and the most common one. A team that does not need Daml-side features for the first release but expects to compose with Canton-native apps in a later one should ship on Zenith and still budget time to read Daml. The composability story across Zenith and Daml apps will get more interesting through 2026. Being unable to read either side of an external_call() is an institutional knowledge gap that turns into a roadmap blocker faster than most teams expect.
A realistic onboarding path
For a Solidity developer who has decided to build on Daml (not Zenith), the realistic path looks roughly like this. The numbered units are the actual gates, not days on a calendar.
- Read Module 2 (“Canton for Ethereum Developers”) in the new docs end-to-end. This is the smallest investment that makes the four conceptual shifts above stick. Read it before writing code.
- Clone
cn-quickstart, runmake setupandmake start. This is the difference between days and weeks. The Quickstart resolves the Docker Compose, OAuth2, observability, and onboarding scaffolding that the survey identified as the longest task. A running local environment is a single-session install rather than a multi-week project. The gate here is Docker resources and disk, not credentials. - Modify a template in the Quickstart’s Daml code and watch it propagate. Add a field, add a choice, regenerate Java/TypeScript bindings via
dpm, see it appear in the frontend. This is where the immutability and authorization patterns become muscle memory. - Build a small custom application end-to-end on LocalNet. Pick a workflow with at least two parties (a buyer and a seller, an issuer and a holder). The two-party constraint is where the signatory and observer model becomes load-bearing rather than incidental.
- Request DevNet access through a sponsoring validator. This is the gate that turns days into weeks. The 2-7 day sponsor lead time is governance, not engineering. Use this window to write tests with Daml Script and to harden the off-chain glue.
- Deploy to DevNet. Request TestNet access. TestNet adds another 1-2 weeks of approval cycle. DevNet runs on a scheduled reset cadence; check current Splice documentation for the reset schedule and plan deployment timing accordingly.
- For MainNet, expect Featured App approval if you want builder rewards. The Tokenomics Committee gate is real and is documented as a multi-week process. If you do not need builder rewards, MainNet deployment itself is not gated by the Committee.
The pattern: LocalNet is days. DevNet is weeks because of the sponsor gate. TestNet is more weeks. MainNet at scale plus builder economics is its own approval process. Code is the smaller share of total elapsed time after Quickstart. Governance is the larger share.
What is still missing
The fast response cycle has not closed every gap the survey named. As of mid-May 2026, these are the meaningful remaining items.
A Tenderly-equivalent for Canton. The most-cited missing tool in the survey, by a clear margin. None of transaction simulation, pre-flight cost and resource profiling, visual debugging, or error decoding has a polished native equivalent yet. Cantonscan and Lighthouse give you transaction inspection; the active debugging surface is thin. This is the gap most likely to materially slow a Solidity team’s transition.
True Hardhat/Foundry feature parity. dpm is a serious step toward unified tooling, but the published surface is not yet a one-to-one replacement for Foundry’s testing primitives, fuzz testing, gas profiling, and mainnet-fork testing. The local sandbox plus Daml Script covers the unit-test case well. Property-based testing and fork-style testing against shared infrastructure are areas where the documented equivalents are thinner; teams that rely on those workflows should expect to bridge the gap themselves for now.
Permissionless TestNet. Until TestNet drops the sponsor requirement, the lead time from “I have an app” to “it runs against shared infrastructure” is governance-bound. This is one of the most visible reasons new teams stall.
Full dpm rollout to existing 2.x projects. The unification is in 3.x. The existing 2.10.x install base needs to migrate, and that migration is not free. Teams should plan it.
Featured App approval friction. Builder economics through the Featured App program (post-CIP-0078, unfeatured apps earn zero rewards) require Tokenomics Committee approval. The motivation is fraud prevention; the side effect is that builder rewards are gated by a committee process rather than open eligibility.
Independent third-party reviews. The Thetanuts testimonial is the cleanest positive DevEx data point, and it is Canton-cited. The ioBuilders Medium deep dive is the closest thing to an independent practitioner account in long form. The literature here is thin compared to any EVM chain of similar age. More independent writeups would do more for the ecosystem than another tutorial.
What it means
For Solidity developers evaluating Canton: budget the first chunk of effort for the conceptual shift, not the syntax. Read Module 2 before writing code. Use Quickstart. If your app does not need sub-transaction privacy or party-based composition, build on Zenith and skip Daml. If it does, accept that you are learning a different mental model, not just a different keyword set. Plan around governance-gated environments rather than around code velocity.
For Canton itself: the survey and the response cycle around it are the clearest DevEx data point the network has produced. The cadence of releases (Quickstart, dpm, JSON Ledger API v2, unified docs, Zenith approval) looks right. The remaining items (Tenderly-equivalent, permissionless TestNet, Featured App friction) are now identified, named, and either funded or in the Canton Development Fund pipeline. The network should treat the size of its active builder population as the highest-priority metric to move, and structure quarterly releases around the obstacles that population names.
For the EVM ecosystem: Zenith is a real bridge but it is not annexation. The institutional features that distinguish Canton from any other L1 are in the Daml layer. Apps that deploy on Zenith get Canton settlement and Canton’s institutional party set; they do not get the privacy and authorization model that is the reason most institutional users pick Canton in the first place. The interesting wave through 2026 will be the apps that span both — Solidity for the public-facing parts, Daml at the institutional boundary — and the developer experience for that shape is barely sketched out yet.
The twelve-month bet is that Canton’s active builder population at least doubles by mid-2027 under the combined weight of Quickstart, dpm, unified docs, Zenith mainnet, and the hackathon pipeline, and that the next Q1 2027 DevEx survey shows the “Infrastructure Engineer before Product Builder” line shrinking from forty-one percent to something below twenty. The bet is wrong if Zenith mainnet slips meaningfully past Q3 2026, if the Tenderly-equivalent gap stays open through year-end, or if the Featured App approval queue becomes the new bottleneck once code-and-tooling friction comes down. The paradigm shift will still be the hardest part. It just will not be the first hard part anymore.
This is a point-in-time analysis as of May 18, 2026. The Canton developer experience is moving fast enough that specific gaps named here may close within a release cycle. For the most current state, consult docs.canton.network and the Canton Network forum.
