Zeko ZK Rollup Settlement for Canton
Authors: Zeko Labs
Zeko: https://zeko.io
Zeko GitHub: https://github.com/zeko-labs
Zeko Docs: https://docs.zeko.io
Status: Draft for Canton Development Fund submission
Created: 2026-06-11
Champion: LayerZeko
Champion contact: Jack Charlesworth
Label: financial-workflows-composability
Primary SIG: Financial Workflows & Composability
RFP category: Financial Markets, Standards & Verification — 11. Public verifiability
Abstract
Canton gets a full-stack sovereign ZK rollup framework for private, end-to-end verifiable enterprise applications and workflows, all settling natively to Canton. It also gains a reusable path for privacy-preserving public verification: issuers, applications, and market operators can prove standardized aggregate metrics such as supply, reserves, collateral sufficiency, transaction volume, settlement activity, and market or workflow outcomes without publishing the underlying private transactions or source data. 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 aggregate outputs, 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.
The first adoption path is private financial workflow infrastructure with verifiable market outputs: RWA lifecycle and supply metrics, payment and netting aggregates, proof-backed reserve, collateral, credit and risk metrics, private market settlement, compliance packages, and enterprise financial-agent authorization. Zeko lets institutions map authorized off-chain data and computation into proof-backed Canton receipts, including authenticated web or API evidence supplied through zkTLS-based workflows. Institutions can prove the integrity of the result and publish or selectively disclose standardized verification packages without exposing source data, private order flow, positions, agent prompts, policy logic, or internal decision records.
The work is cross-functional by design: it supports financial workflow adoption while binding Zeko settlement receipts to Canton asset and workflow flows.
This proposal responds to Financial Markets, Standards & Verification — RFP 11: Public verifiability. The RFP reference implementation will prove an aggregate metric from data supplied by an entitled issuer or application, or from private workflow data already executed in a Zeko lane; bind it to the corresponding source commitment, Zeko state, and Canton receipt; and produce a versioned public verification package containing the metric, scope, time period, proof and verifier metadata, and receipt digest. The proof artifact and public inputs remain independently reproducible, while a decentralized verifier quorum provides an operational attestation path for Canton.
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.
Zeko is a fully audited, mainnet-live ZK rollup protocol. Zeko requests a focused 3-6 month Development Fund grant to make Canton the first-class institutional settlement home for Zeko's proof-settlement pipeline: turning Zeko's SP1/Groth16 proof path into Canton-governed settlement receipts for institutional assets and workflows.
Zeko's existing settlement work already advances the proof path from Zeko rollup proof material through SP1 into a compact Groth16 artifact. This grant brings that path to Canton as a deployable 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; streamlined Docker deployment; reference scenarios for Canton assets and workflows; and a first approved mainnet settlement lane path. 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.
The core Canton pipeline is:
- Zeko executes private, high-throughput, or proof-heavy application activity in a sovereign rollup lane.
- Zeko proves the resulting state transition using its recursive proof stack.
- The Zeko proof is verified inside SP1 and wrapped as a Groth16 proof.
- A deterministic Zeko-Canton verifier service verifies the Groth16 proof and emits a signed verification certificate over the exact public inputs.
- Canton records the proof hash, public-input digest, verifier certificate, prior root, next root, nullifier root, asset root, data-availability commitment, and settlement instruction root in Daml.
- Daml contracts enforce root progression, verifier authorization, asset custody, one-time settlement receipts, and stakeholder approval.
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 contracts, recursive proof composition, private inputs, proof-carrying appchains, custom sovereign rollups, and modular privacy at the infrastructure, application, and user levels. Canton remains the regulated asset, identity, workflow, and settlement layer. Zeko compresses private application computation into verified receipts for workloads that are too high-volume, too privacy-sensitive, or too computationally specialized to run directly inside ordinary Canton application workflows.
Specification
1. Scope
The funded 3-6 month scope is the Canton settlement pipeline.
In scope:
- Canton Daml packages for Zeko rollup registration, asset escrow, batch receipt registration, verifier governance, disclosure policy, and settlement claims.
- Canonical public-input schema for Zeko-to-Canton settlement certificates.
- Versioned public-verifiability schema and reference implementation for proving aggregate financial metrics from private workflow data without disclosing the underlying records or transactions.
- Deterministic verifier service that verifies Groth16 proofs produced from the Zeko/SP1 pipeline and signs Canton-readable verification certificates.
- Canton Ledger API adapter and CLI for submitting verified Zeko batch receipts onto Canton.
- Public verification package export and inspection tooling for independently checking the disclosed metric, scope, source commitment, proof metadata, verifier quorum, and Canton receipt binding.
- Streamlined Docker deployment path for a local Zeko rollup lane, verifier service, Canton adapter, and demo settlement workflow.
- Local, testnet, and mainnet-ready demos for root advancement, asset escrow/release, proof-backed compliance receipts, AI-agent native coordination and payment protocols, private market receipts, and RWA/TAP settlement receipts.
- First Canton mainnet settlement lane deployment, subject to proposal review, security acceptance, configured verifier operators, and committee-approved timing.
- Public open-source reference infrastructure that other Canton ecosystem teams can inspect, fork, operate, extend, and adapt for future proof-carrying applications.
- Threat model, failure-mode tests, replay tests, root mismatch tests, verifier-key rotation tests, and operator runbooks.
Out of scope for this grant:
- Rebuilding the Zeko base protocol.
The design has a clear boundary: Daml enforces Canton state, Canton parties authorize Daml choices and asset or workflow updates, and Zeko proofs attest to off-ledger rollup computation.
2. Why Canton
Canton is the right settlement layer for this work because financial workflows require privacy, authorization, auditability, and composability across regulated parties. Those requirements become even more important as institutions adopt enterprise agents for payments, reconciliation, market operations, compliance checks, and workflow automation.
Canton is also the right technical layer because its architecture already separates privacy, stakeholder validation, and synchronization:
- Canton transaction privacy is based on entitled views: only the relevant parties and validators receive the transaction data they are entitled to see.
- Synchronizers order and mediate encrypted transaction views without seeing transaction contents.
- Validators process transactions for their hosted parties through the Ledger API and store only the contract data relevant to those parties.
- Canton uses an extended UTXO model where contracts are created, archived, and composed atomically.
- Canton supports multiple synchronizers, including private synchronizers for regulated or high-throughput workflows, while still allowing interaction with the Global Synchronizer.
Zeko extends those strengths. Canton controls regulated asset state and institutional workflow state. Zeko compresses private computation into proof receipts. Together, they give Canton verifiable private computation, batch compression, and proof-backed application settlement without expanding Canton validators into ZK application runtimes.
Why The Ecosystem Needs This
Canton's privacy model protects institutional transactions, but private markets still need credible signals about supply, reserves, collateral, volume, settlement activity, demand, and risk. Publishing raw transaction data defeats confidentiality, while publishing an issuer-calculated number without verifiable provenance asks the market to trust the publisher.
Zeko closes that gap by proving that a disclosed aggregate was computed under a published circuit and schema from data committed to a specific private workflow state. Asset issuers and application operators gain a privacy-preserving disclosure tool; investors, liquidity providers, counterparties, auditors, regulators, analytics providers, and external applications gain stronger evidence about the disclosed metric; and Canton builders gain reusable open-source schemas, proof tooling, Daml receipts, and verifier-quorum infrastructure.
This drives adoption by making private Canton activity more useful beyond the originating workflow. Verified metrics can support asset discovery, market confidence, liquidity formation, collateral and reserve monitoring, risk management, reporting, and integration with analytics or oracle consumers without requiring institutions to surrender transaction privacy. The same infrastructure supports multiple issuers, assets, applications, and verifier operators rather than a single proprietary deployment.
It also gives enterprise financial agents a trustworthy data boundary. Agents can consume proof-backed market or off-chain evidence, operate under mission-bounded authorization, and produce verifiable activity and settlement receipts without receiving every underlying private record.
3. What Zeko Represents To Canton
Zeko is a ZK rollup and proof-carrying execution domain for Canton. It is not a replacement synchronizer, not a competing ledger for Canton assets, and not a general-purpose off-chain oracle.
Zeko gives Canton:
- Settlement receipt layer: Zeko produces state roots, nullifier roots, asset roots, policy roots, data-availability commitments, and settlement instruction roots that Canton can record and govern.
- Public verification layer: Zeko proves standardized aggregates over private workflow data and binds each disclosed metric to its source-state commitment, proof, verifier quorum, disclosure policy, and Canton receipt.
- Private financial workflow execution: Zeko handles private actions, payment/netting events, order flow, compliance events, RWA lifecycle events, and financial-agent receipts while exposing only the public inputs Canton needs.
- Sovereign rollup infrastructure: Zeko provides a streamlined Docker deployment path for private, permissioned rollup lanes with controlled operators, scoped data availability, modular privacy, verifier services, Canton adapters, demo settlement workflows, and Canton settlement.
- Enterprise agent infrastructure: Zeko supports agent-native coordination, payments, approvals, budgets, mission-bounded authorization, lifecycle receipts, and activity proofs for enterprise financial workflows without exposing private prompts, outputs, policy checks, or internal decision data.
- CC-native rollup economy: Canton Coin is the default utility and gas/payment token for Canton-integrated Zeko lanes.
- Developer expansion layer: Builders can use TypeScript/o1js for private ZK application logic while settling institutional assets and workflows on Canton.
- ZK coprocessor for long-running workflows: Zeko connects heavy off-chain computation to Canton settlement by proving AI model work, agent workflows, compliance checks, analytics, private market logic, and multi-step processes that are too heavy for ordinary blockchain execution. Canton receives a verified receipt instead of running or revealing the full process, giving Canton applications access to capabilities most on-chain environments cannot support directly.
4. Architecture
The architecture has four layers.
Layer A: Canton Settlement Layer
Canton holds the regulated asset contracts, institutional parties, approval workflows, and final settlement state.
The Daml package set will define:
ZekoRollupRegistry: registers each Zeko lane, operator set, verifier set, verifier quorum, SP1 program verification key identifier, Zeko verification-key hash, circuit hash, disclosure policy, and supported asset scopes.ZekoRollupState: records the current accepted Zeko state root, action state, asset root, nullifier root, policy root, latest batch number, and data-availability policy for a registered lane.ZekoAssetEscrow: locks or binds Canton assets for use inside a Zeko lane. Signatories, observers, and choice controllers are assigned according to the Canton asset workflow.ZekoBatchCertificate: records a verified Zeko batch receipt, including proof hash, public-input digest, prior root, next root, action state, asset root, nullifier root, settlement instruction root, DA commitment, circuit hash, verifier key identifiers, and verifier attestations.ZekoPublicMetricCertificate: records a verified disclosed aggregate, including metric identifier and version, asset or workflow scope, measurement period, disclosed value, source-state commitment, proof and public-input digests, verifier quorum, disclosure policy, and linked batch or settlement receipt.ZekoVerifierAttestation: represents a verifier-party assertion, and optionally an attached signature payload, that a specific Groth16 proof was verified against a specific registered SP1 program key identifier and public-input schema.ZekoSettlementClaim: releases, updates, or composes Canton-side state after the batch certificate has been accepted and the claim has not already been used.ZekoDisclosurePolicy: records the auditor visibility, retention requirements, jurisdictional constraints, and selective-disclosure commitments attached to a lane or batch.
The active ZekoRollupState contract is consumed and recreated through a Daml choice on every accepted batch. This matches Canton's eUTXO model and gives Daml a clear state-transition boundary: the prior root must equal the current accepted root, and the next root becomes the new accepted root only after verifier attestations and Daml authorization checks pass.
Layer B: Zeko Execution Layer
Zeko executes the private application logic.
Relevant Zeko primitives:
- zkApp account state.
- Account updates with preconditions, permissions, and authorization.
- Action state as an ordered Poseidon commitment to emitted actions.
- Recursive Kimchi/Pickles proof composition.
- Sequencer batching.
- Archive and data-availability paths for replay and audit.
- Client-side or server-side proving depending on the application privacy and UX requirements.
For Canton, Zeko lanes support:
- AI-agent native coordination, payment receipts, and budget state.
- Private order books and RFQ state.
- Private prediction-market or oracle-linked state.
- Tokenized Asset Protocol policy state.
- RWA issuance, eligibility, transfer-control, reserve, and lifecycle state.
- Sovereign institutional rollups with scoped operators and data availability.
Layer C: SP1/Groth16 Proof Layer
Zeko's existing settlement engineering verifies Zeko rollup proof material inside SP1 and emits a Groth16 proof. 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. This proposal brings the proof-wrapping pipeline to Canton as the first-class institutional settlement endpoint.
That prior implementation work demonstrates the key mechanics:
- SP1 reads Zeko rollup proof material, Zeko verification-key material, zkApp command data, and verifier index data.
- The program checks that the zkApp command and statement bind to the same account update.
- The program reconstructs verifier-index commitments and computes the Zeko verification-key hash.
- The program verifies the Kimchi proof.
- The program commits public settlement values such as
proofValid, vkHash, stateBefore, stateAfter, and actionStateBefore.
- The settlement contract checks proof validity, verifier key hash, action state, current root, and root update semantics before advancing state.
For Canton, the same proof core becomes a versioned ZekoBatchCertificate schema. The current proof core already emits proof validity, Zeko verification-key hash, pre/post zkApp state, and prior action state. The Canton work binds those proof-emitted values to Canton settlement metadata and lane-specific commitments:
- Registry and versioning:
rollupId, batchNumber, sp1ProgramVKeyId, circuitHash, publicInputSchemaHash
- Proof-bound rollup transition:
zekoVkHash, priorStateRoot, nextStateRoot, priorActionState
- Canton lane commitments:
nextActionState, priorAssetRoot, nextAssetRoot, priorNullifierRoot, nextNullifierRoot, settlementInstructionRoot, daCommitment, policyRoot
Hash-domain binding is part of the Canton design. The Ethereum proof point reconciles Zeko's Poseidon commitments with Ethereum's Keccak/SHA/KZG settlement surface. The Canton path uses versioned canonical byte encoding for each batch and settlement instruction, SHA-256 digests over those canonical bytes for Daml-visible identifiers, and the Zeko Poseidon commitments used inside the proof. The verifier service checks that the Groth16 public values, Poseidon commitments, Canton-visible digests, and ZekoBatchCertificate fields are all derived from the same canonical batch object. Daml records and compares the digest fields and enforces the state transition.
The Groth16 proof is the cryptographic proof artifact. The Canton Daml transaction records the proof hash, public inputs, and verifier certificate showing that the artifact verified under the registered verifier keys and schema.
Layer D: Zeko-Canton Verifier And Adapter Layer
The Canton integration keeps Groth16 arithmetic in the verifier layer and keeps Canton settlement logic in Daml.
The Zeko-Canton verifier service does four deterministic jobs:
- Load the registered SP1 program verification key, Zeko verification-key hash, circuit hash, public-input schema, and current Canton root state.
- Verify the Groth16 proof and decode the committed public values.
- Check root continuity, verifier-key binding, action-state binding, hash-domain binding, DA commitment binding, settlement-instruction-root binding, and application-specific invariants.
- Emit a signed
ZekoVerifierAttestation for the exact proof hash and public-input digest.
Canton then enforces the settlement rules:
- Validate Daml authorization.
- Confirm that verifier parties are registered and meet the quorum policy.
- Ensure the batch number and prior root match the active
ZekoRollupState.
- Consume and recreate the rollup state contract with the next accepted root.
- Enforce asset escrow, settlement claim, and nullifier/receipt rules.
- Expose the right receipt views to signatories, observers, auditors, and regulators.
This is a proof-verified, reproducible settlement path. Institutions can run their own verifier service or require verifier attestations from a configured operator set. The proof artifact, public inputs, verifier version, canonical receipt digest, and Daml receipt remain available for audit and replay. The design is institutional-ready today through verifier attestations, quorum policy, strong receipt binding, and Canton-governed settlement state.
5. Settlement Flow
Deposit Or Asset Binding
- A Canton party exercises a choice on
ZekoAssetEscrow to lock, bind, or authorize a Canton asset for use in a Zeko lane.
- The escrow event produces a canonical deposit or scope commitment.
- The adapter submits the commitment as a Zeko action.
- Zeko includes the action in the lane's action state.
- The next Zeko batch proof binds the action-state transition to the batch's state transition.
Batch Acceptance
- Zeko sequencer batches private actions and generates the Zeko proof.
- SP1 verifies the Zeko proof material and produces a Groth16 proof with Canton-bound public inputs.
- The Zeko-Canton verifier service verifies the Groth16 proof and signs a verifier attestation.
- The adapter submits a Canton command exercising
AcceptBatch on the active ZekoRollupState.
- Daml checks verifier authorization, quorum, batch sequence, prior root, circuit hash, public-input digest, DA commitment, and settlement instruction root.
- Daml archives the old
ZekoRollupState, creates the new state contract, and creates a ZekoBatchCertificate.
Settlement Claim
- A claimant submits a
ZekoSettlementClaim linked to an accepted batch certificate and settlement instruction.
- The adapter supplies the claim digest, nullifier or receipt id, and required verifier/issuer/custodian authorization.
- Daml rejects duplicate claims by consuming and recreating the relevant settlement state and recording the spent receipt/nullifier commitment.
- Canton releases or updates the Canton-side asset state according to the Daml template rules.
Audit And Replay
- Canton stores the batch receipt, roots, proof hash, public-input digest, verifier attestations, and accepted asset or workflow updates.
- Zeko archive/DA stores the private or encrypted rollup data required for entitled replay.
- Auditors receive only the Daml views and Zeko disclosure packages they are entitled to under
ZekoDisclosurePolicy.
- Any authorized verifier can reproduce proof verification from the proof artifact and public inputs.
6. Core Invariants
The implementation must enforce these invariants.
Proof Invariants
- A Canton batch certificate is accepted only if a registered verifier quorum attests to the exact Groth16 proof hash and public-input digest.
- The public-input schema is versioned and hash-bound.
zekoVkHash, sp1ProgramVKeyId, and circuitHash must match the active registry entry.priorStateRoot must equal the active Canton ZekoRollupState.nextStateRoot becomes the active root only after Daml acceptance.
Bridge And Asset Invariants
- Canton assets are represented in a Zeko lane only after Canton escrow, binding, or explicit authorization.
- Canton assets are released, updated, or composed only after a verified Zeko transition includes the corresponding settlement instruction.
- Each settlement claim has a one-time receipt or nullifier binding.
- Batch order is monotonic for each
rollupId.
- Asset conservation is proven in the Zeko circuit and reflected in the Canton settlement instruction root.
DA And Audit Invariants
- Every accepted batch binds to a DA commitment.
- The DA commitment identifies the encrypted or scoped data needed for replay, audit, and recovery.
- Private witnesses, order contents, prompts, model outputs, raw customer records, and compliance evidence are not posted to Canton unless an explicit disclosure policy requires it.
- Auditor access is represented as Daml observer visibility, separately disclosed Zeko audit packages, or both.
Operational Invariants
- Verifier key rotation is explicit and versioned.
- Circuit upgrades cannot silently apply to existing rollup state.
- Emergency disablement pauses new batch acceptance without breaking already-accepted receipts.
- Recovery can proceed from the last accepted Canton root and DA commitments.
7. Canton Alignment
Privacy
Canton provides sub-transaction privacy: parties see the views they are entitled to, validators process only the relevant views, and synchronizers see encrypted messages. Zeko adds proof privacy: Canton can accept a fact about private computation without receiving the computation's private inputs.
Together:
- Canton hides workflow data from uninvolved parties.
- Zeko hides private computation and batch internals from Canton.
- Daml controls who sees settlement receipts, asset updates, and audit disclosures.
eUTXO Settlement
Canton contracts are immutable active contracts that are created and archived. The Zeko settlement design maps cleanly to that model: each accepted Zeko batch consumes the prior ZekoRollupState and creates the next one. Asset escrow and settlement claims are also represented as explicit Daml state transitions.
Multi-Synchronizer And Institutional Deployment
Canton supports multiple synchronizers for isolation, performance, regulatory constraints, governance, and cost. Zeko's sovereign rollup lanes pair naturally with this model. A bank, market operator, or consortium can run a private Zeko lane for confidential execution and settle selected roots and receipts onto Canton using a private synchronizer, the Global Synchronizer, or a cross-synchronizer workflow depending on the asset and policy requirements.
External Parties And Institutional Keys
Canton supports external parties that retain their own signing keys. That matters for verifier operators, custodians, issuers, agent operators, auditors, and regulated market participants. The Zeko-Canton integration can use Canton party authorization rather than bespoke off-ledger authorization for settlement acceptance and claim approval.
8. Reference Use Cases
Tokenized Asset Protocol And RWA
Zeko's tokenized asset protocol work is directly relevant to Canton. It supports private, permissioned asset workflows with policy-linked proofs, settlement-time policy guards, source-system adapters, issuer workflows, and sovereign-rollup deployment patterns.
On Canton, tokenized asset flows can bind issuance approvals, investor or counterparty eligibility, transfer restrictions, reserve or collateral facts, custody/fund-administrator evidence, and lifecycle events such as mint, transfer, corporate action, redemption, burn, and audit.
This positions Zeko and Canton as research and implementation partners for private, permissioned, institutional RWA systems.
Private Order Book And RFQ
Zeko private order book infrastructure supports wallet-signed order authorization, private notes/intents, off-chain matching, and proof-backed settlement anchoring. On Canton, this becomes a private RFQ/order-book lane where strategy and order flow remain private while Canton settles the asset transfers and audit receipts.
Proof-Backed Compliance Packages
An institution can generate a scoped compliance package off-ledger, prove that it satisfies policy, and register a Canton receipt for entitled auditors. The raw evidence remains in scoped storage or Zeko DA. Canton records the receipt, disclosure rights, and resulting asset or workflow update.
Publicly Verifiable Market Metrics
An entitled asset issuer, market operator, or application supplies the private records or commitments required by an approved metric circuit, uses authenticated off-chain evidence from a zkTLS-based workflow, or uses private workflow data already executed in its Zeko lane. Zeko can then prove a standardized aggregate such as circulating supply, reserve coverage, collateral sufficiency, transaction or settlement volume, redemption activity, or another approved market metric over a defined period. The public package discloses the metric and its scope, source-state commitment, proof and verifier metadata, schema version, and Canton receipt digest, while the underlying positions, counterparties, transactions, and source records remain private. Independent parties can reproduce proof verification, and Canton records the governed receipt and disclosure policy. The integration does not depend on scraping or exposing private Canton transaction data.
AI-Agent Native Coordination And Payment Protocols
Zeko's agent infrastructure models paid work, budgets, approvals, mission-bounded authorization, lifecycle receipts, output commitments, capability registration, worker leases, activity proofs, and settlement modes. On Canton, these become proof-backed work receipts, budget-bound agent actions, private prompt/output handling, and Daml approval workflows for institutional agents that touch real assets.
Private Prediction Markets And Oracle-Linked Risk
Zeko private prediction-market work already uses private bet intent, wallet-signed orders, oracle/zkTLS-style event data, and rolling settlement. On Canton, this maps to private forecasting, event-linked risk transfer, internal market signals, and proof-backed structured-product workflows.
9. Deliverables
This is a 3-6 month funded effort with monthly updates and an end-of-phase report. Delivery begins after proposal acceptance, with a Q3/Q4 2026 target based on review timing and committee-approved scope.
Phase 1: Settlement Specification And Local Proof Fixture
Focus: Lock the Canton settlement design and prove the proof-to-receipt path locally.
Deliverables:
- Versioned Canton settlement schema for Zeko batch certificates, including canonical public inputs, hash-domain binding, and verifier attestation format.
- Versioned public-verifiability schema covering metric identity, asset or workflow scope, measurement period, source-state commitment, disclosed value, proof metadata, verifier quorum, disclosure policy, and Canton receipt binding.
- Daml package prototypes for rollup registration, state progression, verifier governance, batch receipts, asset escrow/claims, and disclosure policy.
- Deterministic verifier service prototype that verifies SP1/Groth16 proof artifacts and emits Canton-readable attestations.
- Canton-first local fixture and test vectors derived from the existing Zeko/SP1 proof-wrapping implementation.
- Streamlined local Docker workflow that runs a Zeko rollup lane, verifier service, Canton adapter, and demo settlement path.
- End-to-end local demo for proof-backed root advancement and a representative Canton asset or workflow settlement claim.
- End-to-end local demo that derives and verifies an aggregate financial metric from private workflow data without disclosing the underlying records.
- Phase 1 threat model and failure-mode test plan covering verifier authorization, replay, stale roots, duplicate claims, DA binding, and circuit/key upgrades.
Phase 2: Testnet/Mainnet Adapter And Reference Scenarios
Focus: Move from local fixture to testnet/mainnet-ready infrastructure, reference scenarios, and the first approved Canton mainnet settlement lane path.
Deliverables:
- Canton Ledger API adapter and CLI for lane registration, receipt submission, receipt inspection, and settlement claims.
- Testnet/mainnet-ready deployment package for the Zeko-Canton verifier service and rollup lane, including configuration, verifier-operator setup, key-material handling, runbooks, pause/rollback procedure, and acceptance checklist.
- Negative-test suite for the core settlement invariants: proof validity, verifier/key authorization, schema binding, root progression, DA binding, canonical digest consistency, replay resistance, and one-time settlement claims.
- Reference scenarios covering private payment/netting or asset escrow, proof-backed compliance/RWA, and AI-agent or private-market receipts, with at least one runnable end-to-end lane and additional implementation blueprints.
- A runnable RFP reference scenario that publishes a standardized aggregate metric and an independently checkable public verification package bound to the corresponding Canton receipt.
- First approved Canton mainnet settlement lane path, subject to proposal review, security acceptance, configured verifier operators, and committee-approved timing.
- Documentation for Canton builders, Daml developers, verifier operators, and institutional reviewers.
Follow-On Phase: Hardening And Production Readiness
The initial proposal is intentionally 3-6 months. A separate follow-on proposal would cover:
- External audit of Daml packages, verifier service, and adapter.
- Production verifier-operator governance.
- Managed explorer/indexer for Zeko-Canton receipts.
- Broader enterprise pilots.
- Additional mainnet deployments beyond the first approved settlement lane.
- Additional use-case circuits and disclosure-policy packages.
10. Acceptance Criteria
Protocol And Architecture
- Public-input schema and Daml package API are published and versioned.
- Verifier attestation format is deterministic and reproducible.
- Proof hash, public-input digest, verifier key, circuit hash, DA commitment, and root transition are all bound in the accepted Canton receipt.
- Canonical encoding and hash-domain test vectors show that Poseidon commitments, Groth16 public values, Canton-visible SHA-256 digests, and Daml certificate fields are derived from the same canonical batch object.
- Groth16 verification is handled in the verifier layer; Daml validates the accepted receipt, registered verifier attestations, and Canton state transition.
- The public-verifiability schema is published and versioned, and binds each disclosed aggregate to its metric definition, scope, measurement period, source-state commitment, proof metadata, verifier quorum, disclosure policy, and Canton receipt digest.
Functional Correctness
- End-to-end local flow accepts a valid Groth16 proof and advances a Canton
ZekoRollupState.
- Invalid proofs, mismatched verifier keys, mismatched schemas, stale roots, or inconsistent canonical digests cannot produce an accepted Canton receipt.
- Duplicate settlement receipts, replayed batches, and already-used settlement claims are rejected.
- Unauthorized verifier party cannot satisfy the registry quorum.
- Asset release cannot occur without an accepted batch certificate and valid settlement claim.
- A reference aggregate computed from private workflow data produces a valid public verification package, while altered metrics, scopes, periods, source commitments, proofs, attestations, or receipt digests fail verification.
Security
- Zeko protocol mainnet/audit status is documented for reviewers.
- New security scope is limited to Canton Daml packages, verifier service, public-input schema, adapter, fixtures, and operational controls.
- Threat model is published in Phase 1 and covers verifier operators, DA, replay, root mismatch, stale roots, duplicate claims, unauthorized verifiers, key/circuit upgrades, and emergency pause.
- Key rotation, circuit upgrade, verifier removal, and emergency pause flows are documented.
Developer And Operator Experience
- CLI can register a rollup, submit a batch certificate, inspect a receipt, and submit a settlement claim.
- Streamlined Docker deployment can launch the local Zeko-Canton rollup stack, verifier service, adapter, and demo settlement workflow.
- Mainnet deployment package includes verifier-operator configuration, key material handling, pause/rollback procedure, and acceptance checklist for the first approved Canton mainnet settlement lane.
- Documentation explains the full proof path from Zeko proof to SP1/Groth16 proof to Canton Daml receipt.
- Reference scenarios are documented, with at least one runnable end-to-end lane and additional scenarios as implementation blueprints.
- Canton developers can run the local demo without needing to understand Zeko internals.
Adoption-Driven Delivery
In addition to technical acceptance criteria, Phase 2 will include usage-based acceptance criteria demonstrating that the Zeko-Canton settlement path can be operated and evaluated by Canton ecosystem participants.
Phase 2 adoption targets include:
- At least 25 verified Zeko batch receipts settled on a Canton testnet or approved demo environment.
- At least 2 registered Zeko-Canton lanes, including one Zeko-operated reference lane and one externally configured, externally operated, or externally participated lane.
- At least 1 external institution, app team, or Canton ecosystem participant running the Docker stack, submitting receipts, or participating in a reference lane.
- At least 1 financial workflow scenario demonstrated end to end, such as asset escrow/release, private payment or netting, RWA lifecycle receipt, private-market receipt, proof-backed compliance receipt, or enterprise-agent authorization receipt.
- At least 1 public-verifiability scenario demonstrated end to end, with a standardized aggregate metric derived from private workflow data, bound to a Canton receipt, and checked by an external participant without access to the underlying private records.
- Public documentation showing how a Canton developer can register a lane, submit a verified batch receipt, inspect the receipt, and verify the proof/attestation path.
- An end-of-phase report covering settled batch count, registered lane count, external operator or app-team participation, integration issues discovered, and recommended next steps.
If the committee approves the full-term extension, additional adoption targets will include 100+ settled batch receipts, 3+ registered lanes, 2+ external participants, and at least 2 financial-workflow reference scenarios.
Zeko is working with multiple partners on Zeko-based applications and settlement workflows and will select the first reference-lane partner as the Canton review and implementation path becomes more specific. If public disclosure is not available before review, Zeko can disclose the participant privately to the champion or committee where appropriate.
11. Post-Grant Sustainability And Verifier Operations
Zeko Labs will maintain the public reference stack after the grant, including the Daml packages, verifier interface, adapter, CLI, Docker templates, schemas, test fixtures, and documentation.
Zeko will operate the initial verifier service for the reference lane and first approved production/reference lanes. A portion of the grant and extension budget is allocated to verifier operations, monitoring, runbooks, operator onboarding, and support for additional verifier operators, so the funded work remains usable beyond code delivery.
The verifier model is quorum-based. For the initial lane, Zeko will serve as one verifier operator and will work with the champion, participating institutions, and Canton ecosystem operators to define the registered verifier set, quorum threshold, key rotation process, and emergency removal process through the Daml-governed registry.
Longer term, verifier sustainability can be supported by lane-level economics. Production Zeko-Canton lanes can include CC-denominated verifier service fees for accepted batches, settlement receipts, or managed lane operation. These fees should be set to cover verifier operating costs plus a reasonable operator margin, so registered verifier operators have an economic reason to provide reliable service without relying on continued Development Fund support.
12. Funding
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 if the scope proceeds through the full 6-month hardening, reference scenarios, ecosystem growth support, and first approved mainnet settlement lane path. Maximum request: 10,000,000 CC.
Term: Initial 3 months for specification, local fixture, Daml packages, verifier service, and adapter. Extension to 6 months covers broader hardening, reference scenarios, ecosystem growth support for new Canton app deployments and adoption, testnet/mainnet-ready documentation, and the first approved Canton mainnet settlement lane path, subject to committee-approved scope and timing.
Payment schedule: Milestone-based disbursements:
- 1,500,000 CC on proposal acceptance and Phase 1 start.
- 1,500,000 CC on Phase 1 acceptance.
- 3,000,000 CC on Phase 2 acceptance, including the testnet/mainnet-ready deployment path, reference-scenario materials, and initial ecosystem adoption package for new app deployments.
- Up to 4,000,000 CC for committee-approved full-term extension, hardening, additional reference scenarios, ecosystem growth support, first approved mainnet settlement lane path, and production readiness.
Budget rationale: This is shared ecosystem infrastructure. The work spans ZK engineering, Daml engineering, public-input/circuit binding, verifier service implementation, test fixtures, negative tests, documentation, institutional use-case design, and ecosystem adoption support.
Indicative allocation:
- 45% proof, verifier, and public-input engineering.
- 25% Daml packages and Canton Ledger API adapter.
- 10% security modeling, negative tests, and reliability.
- 10% documentation, CLI, and developer tooling.
- 10% reference scenarios, ecosystem growth, and adoption support.
Open-source commitment: Daml packages, verifier reference implementation, adapter, CLI, Docker deployment templates, schemas, test harnesses, documentation, and reference examples will be open-sourced under Apache-2.0 or another permissive license approved in the proposal repository. The result is reusable public infrastructure for the Canton ecosystem. Private keys, partner configurations, and security-sensitive deployment secrets are excluded.
13. Co-Marketing And Research Partnership
Zeko will work with the Canton ecosystem on:
- Technical writeups on Groth16 proof settlement onto Canton.
- Developer workshops for Daml, TypeScript, o1js, verifier operators, and institutional builders.
- Reference demos for AI-agent native coordination and payment protocols, private markets, proof-backed compliance, and RWA settlement.
- Ecosystem growth support for Canton teams building new Zeko-backed app deployments, including technical onboarding, reference integrations, and adoption materials.
- Research with Canton stakeholders on sovereign rollups, modular privacy, verifier governance, and proof-backed enterprise workflows.
Zeko will be an active research partner for Canton on enterprise-grade private and permissioned systems.
14. Motivation
Canton already solves a hard problem: institutional privacy with composable multi-party workflows. It does this through entitled transaction views, stakeholder validation, encrypted synchronization, and Daml authorization.
Zeko targets workloads that benefit from private proof-carrying execution before Canton settlement:
- High-frequency private matching and netting.
- Agent receipts and budget updates.
- RWA compliance and eligibility computation.
- Private forecasting and oracle-linked event logic.
- Large policy checks over private evidence.
- Proof-backed analytics over tokenized assets.
These workloads need computation, privacy, and compression before they reach Canton. Zeko supplies that layer. Canton remains the system of record.
The result is a new institutional architecture:
- Zeko performs private proof-carrying execution.
- SP1/Groth16 makes the proof artifact compact and externally verifiable.
- Canton records the verified settlement receipt and executes the regulated asset or workflow update.
15. Risks And Mitigations
Risk: Verifier Operators Become Too Trusted
Mitigation: Verification is deterministic, proof artifacts are retained, public inputs are hash-bound, verifier keys are registered in Daml, and institutions can run their own verifier service or require a quorum of registered verifiers.
Risk: Public-Input Encoding Is Ambiguous
Mitigation: The schema is versioned, hash-bound, test-vectored, and included in every accepted ZekoBatchCertificate.
Risk: DA Is Missing Or Insufficient For Audit
Mitigation: Every batch binds to a DA commitment and disclosure policy. Batches without required DA metadata are rejected by the adapter and verifier policy.
Risk: Replay Or Duplicate Claims
Mitigation: Batch numbers, prior roots, receipt ids, nullifier roots, and Daml state transitions make settlement claims one-time-use.
Risk: Scope Expands Into Too Many Apps
Mitigation: The funded work is the settlement layer plus bounded reference scenarios, with at least one runnable end-to-end lane. Additional app-specific circuits and enterprise pilots belong in follow-on work.
16. Notes For Reviewers
This proposal advances Canton financial workflow adoption by making verified Zeko state transitions first-class Canton receipts for private asset, market, payment, compliance, and institutional workflow use cases, including enterprise-agent authorization, mission-bounded execution, and activity receipts.
RFP mapping: Financial Markets, Standards & Verification — 11. Public verifiability. The proposal directly implements the RFP's ZK path: proofs of aggregate financial data, supported by a decentralized verifier quorum, with public verification packages that preserve the confidentiality of the underlying Canton workflow.
Ecosystem benefit: Issuers and applications can publish more credible metrics without exposing private transactions; investors, liquidity providers, counterparties, auditors, regulators, analytics providers, and external applications can verify the disclosed result; and Canton builders receive reusable open-source infrastructure that supports multiple assets, issuers, applications, and operators.
Zeko remains the external proof execution domain; Canton remains the institutional settlement layer. The proposal makes verified Zeko state transitions first-class Canton receipts.
Canton settlement uses Daml state and registered verifier attestations over Groth16 proof artifacts. Daml records and governs the accepted receipt; the verifier layer checks the proof. Canton enforces authorization, stakeholder visibility, contract lifecycle, asset custody, settlement finality, and auditability.
Zeko brings audited mainnet protocol infrastructure, recursive ZK execution, sovereign rollup deployment, o1js developer tooling, modular privacy, and a working SP1/Groth16 proof-wrapping pipeline. Canton becomes the institutional final-mile settlement layer for those proofs.
References
