An end-to-end tokenized JGB collateral lifecycle across Canton and Zenith EVM
Zenith Network
Zenith participates in the Progmat-led Digital Asset Co-Creation Consortium’s Tokenized JGB / On-chain Repo Working Group, which explores tokenizing rights to Japanese Government Bonds (JGB) and using them as collateral in stablecoin-funded repo transactions. The initiative addresses a JGB repo market estimated at JPY 250–270 trillion (approximately US$1.6 trillion), where faster settlement and programmable collateral could improve efficiency, liquidity and access.
As part of our contribution to the consortium, we have prepared and validated an end-to-end pilot workflow that carries a tokenized JGB as an RWA asset through its full collateral lifecycle, including issuance, asset purchase via DvP, collateralization and borrowing, monitoring, and resolution by either repayment or liquidation, and spanning Canton Network and Zenith EVM.
Workflow requirements
Zenith’s role was to provide the EVM execution environment within Canton’s architecture and to design the integration patterns that connect Daml workflows with Solidity contracts atomically. The objective was to let regulated asset state on Canton use EVM-based payment and credit functionality while Canton remains the canonical coordination and settlement layer.
The target workflow had to coordinate two execution environments without weakening either: Canton/Daml as the privacy-preserving record for asset issuance, ownership, eligibility and encumbrance; and EVM smart contracts for the cash leg of a DvP and for lending.
Conventional bridges and cross-chain protocols create a window in which one leg has committed and the other has not, introducing execution risks and further complexity to revert a partially committed state if one leg of a transaction fails. In order to mitigate this, the pilot therefore focused on three main controls:
Cross-domain atomicity: a tokenized JGB purchase on Canton settled against a stablecoin payment leg on Zenith EVM as a single indivisible operation.
EVM finality handling: verifying EVM state and finality on Canton.
Reliable delivery of EVM state and events back into Daml: reading loan health on the EVM side so that Daml workflows can branch out to trigger any necessary action atomically.
Two paths ensure these controls:
The write path (Daml → EVM → Daml): Daml initiates an EVM operation, then feeds the EVM execution result into the actual Daml workflow it is part of.
The read path (Daml ← EVM): Daml reads EVM state mid-processing and branches on it, implemented trustlessly, by reading against a state root taken from an on-chain source and verifying the data, rather than trusting whoever reports it.
What we mean by atomicity
“Atomic swap” is often used for workflows built on hashed time-lock contracts or intent-based coordinated transactions across independent chains. Those mechanisms can give economic assurance that both sides eventually complete, but each leg is still finalized by distinct consensus mechanisms at different speeds. Any partial commitment needs to be reverted if one leg fails, and users often need to trust third parties.
Zenith’s architecture provides consensus-level atomicity: EVM execution and finality is entirely coordinated through Canton’s Global Synchronizer and consensus rather than by an independent validator set.
Every EVM block is created inside a Canton transaction:
An ordered list of EVM transactions is provided to Zenith’s block builder contract on Canton,
Canton validators running the above contract triggered EVM execution through external_call(),
These Canton validators re-execute the block with the same inputs and record results on Canton,
A quorum of 2/3 is needed for the new EVM block to finalize on Canton.
As a consequence:
A Daml transaction can contain an entire EVM block, and the Canton-side operations and the EVM events all commit or fail as one atomic transaction.
EVM transactions on Zenith inherit Canton’s deterministic finality in a few seconds, with no reorgs.
The end-to-end lifecycle validated
The pilot was designed to test more than simple asset issuance or cross-chain messaging. The goal was to validate an end-to-end RWA lifecycle in which an asset originating in Canton, can be settled against EVM-native cash, used as collateral in an EVM lending application, and ultimately released or transferred based on the resulting loan state.
The resulting flow covers three stages: issuance and settlement, collateralization and borrowing, and monitoring and resolution.
Asset issuance
The lifecycle begins with issuance of a TJGB-representative RWA as a Daml contract on Canton. The contract encodes the asset ownership model together with holder eligibility and transfer controls, allowing those restrictions to remain enforceable throughout the lifecycle rather than being delegated to the EVM application.
Cross-chain deliver-versus-payment (DvP)
The delivery-versus-payment transaction to purchase the RWA asset takes place atomically between the Canton-native RWA asset and an EVM-side stablecoin.
The buyer approves an EVM transaction authorizing the settlement contract to move and spend the required stablecoins. Once that prerequisite is in place, the Canton-side settle choice coordinates the exchange.
The atomic settlement flow finalizes the EVM block including the ERC-20 asset transfer as part of the same Canton transaction that transfers the RWA asset to the buyer.
Thus, the DvP executes atomically: the delivery leg and the payment leg commit together or not at all, delivering the bond to the buyer and USDC to the seller with deterministic finality. The buyer confirms the holding, unencumbered.
The pilot therefore validates a DvP model in which settlement across Canton and Zenith EVM behaves as one indivisible coordinated operation rather than as two loosely coupled legs requiring off-chain reconciliation.
Collateralize and borrow
The second phase of the workflow moves the RWA asset from a freely transferable asset into an encumbered position backing an EVM loan.
This part of the flow coordinates three operations:
Represent or register the locked Canton asset as collateral on Zenith EVM;
Execute a borrow from a Solidity lending contract, and
Verify the successful EVM borrow receipt before Canton records the RWA as encumbered.
From a single Canton authorization to move the RWA to Zenith, deposit it as collateral, and borrow a target amount to a target EVM address, the workflow locks the RWA asset on Canton so it cannot be used twice while it is on Zenith, and via external_call():
Mints an ERC-20 representation on Zenith,
Deposits that representation into the Solidity lending protocol, and
Borrows a stablecoin against it.
Canton validators validate and finalize the EVM block while the Gateway verifies the receipts in the same transaction and commit the Canton-side state, marking the RWA encumbered and storing the loan reference and EVM state roots on Canton. The borrowed liquidity is now usable on Zenith.
If the EVM leg is rejected, its receipt is absent and the whole step aborts, leaving no partially committed state on either side.
Monitoring the loan from Canton
Once the asset is encumbered, Canton needs to determine what should happen to the underlying RWA as the EVM loan state changes over time.
A Daml monitoring contract periodically reads live loan state (debt outstanding, collateral value and health factor) at exactly the Canton-recorded Zenith EVM block hash, and branches out on it: healthy loans continue to be monitored, a deteriorating loan raises a margin call, and a loan below threshold routes to repayment or liquidation.
The reads are performed trustlessly, with the loan health check being replicated across participants and an EIP-1186 proof also being verified against the Canton-pinned EVM block hash (Read more on this in the next section).
Resolve: repayment or liquidation
From the monitor, the lifecycle takes one of two mutually exclusive branches:
Repay and release: The borrower repays principal plus accrued interest on Zenith. Once the outstanding debt is zero, the collateral is withdrawn and the representation is burned; the Gateway matches the burn log against the stored loan reference, clears the encumbrance and unlocks the RWA on Canton.
Liquidation and transfer. If the health factor falls below threshold, a permissionless liquidation seizes the collateral on EVM. The Gateway reacts to the liquidation receipt, records the ownership change against the locked Canton contract, and Canton settles the final entitlement, subject to a holder-eligibility check on the receiving party.
Either way, the lifecycle closes with notifications to the holder, issuer and lending protocol, and an audit log that includes the EVM state roots recorded on Canton.
Failing closed
The pilot also verifies the negatives. Injected read divergence (one participant’s read deliberately corrupted by a byte), unauthorized readers, duplicate monitor references and replayed settlement attempts all fail closed.
A closer look: reading EVM state without trusting a witness
There are a few subtle details around the read path that deserve a bit deeper of an explanation. For effects a Canton transaction originates, let’s say, a borrow, there is nothing to trust: the choice finalizes the block carrying the borrow and reads that transaction's receipt inside the same Canton transaction, so its success is known at commit. But repayment and liquidation are originated by third parties. How does Daml learn what happened on the EVM without trusting whoever reports it?
The answer is to pin every such read to an EVM block hash Canton itself recorded, and to accept no caller-supplied block selector, target, or calldata, the block hash is derived on-ledger and the call is fixed by the read function. Two strengths of read run over the same wire:
The observation read initiates an eth_call via external_call() to an EVM node at the pinned block. All validating participants re-execute the call and any divergence aborts the transaction. This makes the read a replicated, deterministic observation which catches any participant that disagrees.
The trustless read removes any residual trust in the value, e.g. in case there was a single data source. Instead of taking the value on faith, it fetches a cryptographic proof along with it and checks that proof against the pinned block hash. The proof has to chain all the way from the block down to the exact balance being read, and it only matches if the value is genuine. A source that lies about the value can't fake a matching proof without breaking the hash function itself. A data source that lies about the value cannot forge one without a keccak256 collision; the only trust that remains is that the verifier code is correct, and every participant runs it independently.
The freshness of read EVM data comes from Canton keeping the fetched block active through commit, not from an Ethereum light client; and the block hash is trustworthy because on Zenith it's the Canton commit that makes an EVM block canonical. Together, that's what lets Daml branch, and trigger a margin call, release or transfer, on numbers it never had to trust anyone to report.
Where we are now: Zenith EVM Testnet
The pilot workflows shown here, such as an atomic cross-chain DvP, the collateral lifecycle, and the pinned read lane, were run against a fully local stack. Since that work was completed, Zenith has reached another milestone: the public Zenith EVM Testnet launched on September 28, 2026.
Developers can now deploy and interact with Solidity smart contracts using familiar Ethereum tools, with EVM blocks processed and finalized through Canton. The public testnet also supports registered token transfers between Canton and Zenith EVM through the Zenith Gateway.
Explore the Zenith EVM Testnet documentation to see what's available today.
