Proposal: Zeko ZK Rollup Settlement for Canton

[zekoxyz]

Development Fund Proposal Submission

Proposal file: /proposals/2026-06-Zeko-zk-rollup-on-Canton.md

Zeko: https://zeko.io
Zeko GitHub: https://github.com/zeko-labs
Zeko Docs: https://docs.zeko.io

---

Summary

Canton gets a full-stack sovereign ZK rollup framework for private, end-to-end verifiable enterprise applications and workflows, all settling natively to Canton. Private ZK applications, custom sovereign enterprise rollups, AI-agent workflows, private markets, and institutional RWA logic can execute on Zeko, prove their state transitions, and settle verified receipts onto Canton without exposing private computation or forcing Canton validators to run ZK application logic. Canton Coin (CC) is the default utility and gas/payment token for Canton-integrated Zeko rollup lanes.

This grant produces public, open-source Canton ecosystem infrastructure. The Daml packages, verifier interface, adapter, CLI, Docker deployment path, schemas, test fixtures, and reference scenarios will be reusable by Canton builders, institutions, application teams, and additional ZK integrations, with ecosystem growth support to help kickstart new app deployments and adoption.

Zeko is a fully audited, mainnet-live ZK rollup protocol. This proposal funds a focused 3-6 month effort to make Canton the first-class institutional settlement layer for Zeko's proof-settlement pipeline: turning Zeko's SP1/Groth16 proof path into Canton-governed settlement receipts for institutional assets and workflows.

The grant brings Canton a deployable Zeko settlement kit: institutional-ready, verifier-attested Groth16 settlement; Daml receipt packages; verifier registry and quorum rules; canonical public-input schemas; hash-domain test vectors; Ledger API adapter and CLI; 1-click Docker deployment; reference scenarios for Canton assets and workflows; and a first approved mainnet settlement lane path subject to proposal review, security acceptance, configured verifier operators, and committee-approved timing. Every accepted receipt is strongly bound across proof hash, public inputs, prior and next state roots, verifier keys, canonical receipt digests, and Daml settlement state. Groth16 verification runs in a deterministic verifier layer; Daml governs registered verifier attestations, root progression, asset custody, settlement claims, stakeholder visibility, and auditability.

Zeko's existing settlement work already advances the proof path from Zeko rollup proof material through SP1 into a compact Groth16 artifact. Zeko has already begun building and proving this external-settlement path in zeko-labs/ethereum-settlement. That repository is prior implementation work showing the reusable SP1/Groth16 mechanics. The Zeko Ethereum settlement litepaper is prior technical roadmap context: Ethereum is the initial proof point for the external settlement path, and with this proposal Canton becomes the actual target deployment.

The Canton path uses versioned canonical byte encoding plus Daml-visible SHA-256 digest fields to bind Zeko/Poseidon proof commitments to Canton receipts. The deliverables include test vectors and negative tests showing that the Groth16 public values, Poseidon commitments, Canton-visible digest, and Daml certificate fields are derived from the same canonical batch object.

The core Canton pipeline is:

1. Zeko executes private, high-throughput, or proof-heavy application activity in a sovereign rollup lane.
2. Zeko proves the resulting state transition with its recursive proof stack.
3. SP1 verifies the Zeko rollup proof material and wraps the result as a Groth16 proof.
4. A deterministic Zeko-Canton verifier service verifies the Groth16 proof and signs a Canton-readable attestation over the exact public inputs.
5. Canton records the proof hash, public-input digest, verifier attestations, prior root, next root, nullifier root, asset root, DA commitment, and settlement instruction root in Daml.
6. Daml enforces root progression, verifier authorization, asset custody, one-time settlement claims, stakeholder visibility, and auditability.

An accepted batch becomes a Canton-native settlement receipt for a verified Zeko rollup transition: Canton records the proof hash, public inputs, verifier attestations, and state-root update, then Daml uses that receipt to release or update Canton assets and advance the relevant Canton workflow.

This opens a general ZK application layer for Canton: TypeScript/o1js zk contracts, recursive proof composition, private inputs, proof-carrying appchains, custom sovereign rollups, and modular privacy at the infrastructure/application/user levels. The work directly supports existing AI-agent native coordination and payment protocols, private order book/RFQ settlement, private prediction market, and institutional RWA flows.

Funding request: 6,000,000 CC for the base 3-month Canton final-mile delivery, with a committee-approved extension of up to 4,000,000 CC for the full 6-month hardening, reference scenarios, ecosystem growth support, and first approved mainnet settlement lane path. Maximum request: 10,000,000 CC. Delivery begins after proposal acceptance, with a Q3/Q4 2026 target based on review timing and committee-approved scope.

---

Checklist

• Proposal file added under /proposals/
• Champion/contact identified
• 3-6 month scope and funding request defined
• Canton-specific architecture defined
• Acceptance criteria included
• Alignment with Canton priorities described

---

Notes For Reviewers

Champion organization: Digital Asset.
Champion contact: Sina Nader.
SIG label: canton-protocol-multi-synchronizer.

This proposal advances Canton's multi-runtime strategy through a distinct proof-native settlement lane for custom sovereign enterprise rollups, private rollup execution, recursive proof aggregation, Groth16 proof verification, and Canton-native Daml settlement receipts.

[github-actions]

Champion identified Canton Foundation

The committee will verify this champion during review.

[github-actions]

SIG labels auto-detected and applied: canton-protocol-multi-synchronizer

If this is incorrect, you can ask the reviewers to update the labels.

[zekoxyz]

Champion organization has been updated in the proposal to Digital Asset.

[waynecollier-da]

Your champion needs to be an individual person, either a member of the Tech & Ops committee, or a member of one of the Special Interest Groups. They need to confirm that they are willing to act as champion.