CIP-0086: Native ERC‑20 Middleware for Canton Network
Please see CIP below open for discussion. Feel free to reach out if you have questionsExecutive Summary
This project aims to provide Canton Network operators, token issuers, and ecosystem participants with a robust and extensible ERC‑20-compatible middleware and distributed indexer infrastructure that complies with Canton’s privacy-preserving ledger model while aligning with Ethereum’s dominant token interface standard.
This Statement of Work (SOW) outlines the development of an ERC‑20 interface middleware and distributed indexer for the Canton Network. The goal is to enable Ethereum-like token interactions (e.g., stablecoins, tokenized assets) to operate natively on Canton’s distributed ledger using a familiar API surface while maintaining strict privacy, security, and performance guarantees. The middleware will abstract Canton’s UTXO-style smart contract architecture and participant specific data access into standard ERC‑20 API semantics.
The work is structured in three progressive phases:
● Phase 1 – ERC‑20 Middleware for a Concrete Canton-Compatible Token (CIP-0056): Implement a concrete ERC‑20Token Daml template that conforms to the Canton token standard (CIP-0056). Develop the middleware and indexer against this implementation to expose ERC‑20-compatible API endpoints. This phase focuses on ensuring compatibility with Canton Coin as the initial supported token.
● Phase 2 – Multi-Token Generalization via Interface Abstraction: Refactor the Phase 1 token and middleware to adopt Daml interfaces that formally define ERC‑20 compatibility (e.g., an ERC20Compatible interface). Tokens implementing both the Canton token standard and this ERC‑20 interface will be supported by the same middleware and indexer infrastructure. The middleware becomes token-agnostic and reusable.
● Phase 3 – Canton Improvement Proposal (CIP): Collaborate with Canton governance (e.g., the Global Synchronizer Foundation) to propose a formal ERC‑20 compatibility interface as a CIP. The objective is to enable Canton Coin and other tokens to adopt this interface, allowing Super Validators (who validate all Canton Coin transactions) to run the ERC‑20 middleware as public infrastructure.
Middleware deployment is designed for two operational modes:
● Full Visibility Mode: For tokens like Canton Coin, where Super Validators have full ledger visibility, the middleware can be operated by validator nodes to provide globally accurate ERC‑20 API responses.
● Scoped Visibility Mode: For other tokens (e.g., stablecoins or tokenized RWAs), the middleware must be operated by entities with global visibility into the token (e.g., issuers), or by end users for personal visibility. In this mode, functions like balanceOf will only work for addresses the operator is authorized to see, ensuring compliance with
Canton’s privacy model.
ChainSafe shall provide the Client with monthly invoices that contain all applicable Fees (as defined below) and expenses incurred during the term of this Statement of Work.
Delivery - Phase 1
The source code deliverables of this engagement will be delivered to the Client in the form of a GitHub repository containing the source code and associated documentation.
The project will deliver the following components and capabilities:
Architecture & Design Documentation
● System architecture diagram describing interactions between:
○ On-ledger Daml contracts
○ Off-ledger middleware services issuing commands to the ledger,
○ Distributed indexer responsible for aggregating token state.
● API interface schemas for the ERC‑20-compatible middleware.
● Security and privacy model, including:
○ Middleware operation under Canton’s visibility constraints (global vs partial observability),
○ Access control patterns for issuer-hosted and user-hosted middleware deployments.
Daml-Based ERC20Token Contracts (Canton Coin Standard Compliant)
● Development of a concrete Daml token template (e.g., ERC20Token) that: ○ Implements the Canton token standard for fungible assets,
○ Encodes token metadata (name, symbol, decimals, issuer),
○ Supports UTXO-based transfers through controlled archival and issuance, ○ Defines AllowanceContract logic to implement approve() and transferFrom() semantics.
● Governance-enforced minting and burning restricted to authorized signatories. ● On-ledger logic for validating authorization, transfer conditions, and state invariants. ● Unit tests and integration of the contract templates on a devnet deployment of Canton Coin.
ERC‑20 Middleware API Layer
● Stateless ERC‑20-Compatible API Server implementing standard endpoints: transfer, transferFrom, approve, balanceOf, allowance, and totalSupply. ● Transaction Orchestration Engine to construct and submit Canton Ledger API commands mapped from ERC‑20 operations.
● Identity & Session Management for resolving Canton parties and handling authentication.
● Contract State Resolver to resolve token and allowance contract states, including logic to support transfer composition under UTXO constraints.
● Visibility-Aware Execution Logic, which allows middleware to operate in “full visibility” (issuer/operator) and “partial visibility” (end-user) modes, returning appropriate errors for unauthorized queries.
● Deployment infrastructure (Docker, Kubernetes, IaC) and observability components for both operational modes.
Distributed Indexer
● Indexer Core Service that subscribes to Canton Ledger API or Canton Sync Service for all relevant token-related events (contract creations/archivals).
● Database Schema & Storage Engine (PostgreSQL or equivalent), optimized for real-time token state queries and immutable audit trails.
● Deterministic Indexing Logic to maintain consistent balance and allowance views from distributed UTXO contract state.
● Query API Layer for exposing token state to middleware and clients in a format analogous to standard ERC‑20 calls.
● Validator Coordination & Distribution Infrastructure for use in the Canton Coin context, where Super Validators have visibility into all transfers.
Deliverables
Phase 1 – ERC‑20 Middleware & Indexer for Canton Coin
The objective is to implement and deliver an end-to-end ERC‑20 interface middleware for a concrete Canton Coin Standard compliant token on Canton, tested in a controlled environment. This includes an ERC‑20-compatible middleware API, a supporting distributed indexer, and a concrete Canton-compatible token template.
The work in Phase 1 will be divided into the following key deliverables:
Deliverable 1 - Architecture & Design document
● Scope:
○ System architecture diagram describing interactions between Daml contracts, middleware, and indexer.
○ Data flow specifications outlining how token state changes propagate across layers (ledger → indexer → API).
○ Interface definitions and API schemas (OpenAPI spec or gRPC IDL) for ERC‑20 middleware endpoints.
○ Security and privacy model detailing identity mapping, authorization flow, and data access restrictions.
● Estimated resources:
○ Engineering: 4 Weeks
○ Project Management: 1 week
● Estimated duration: 2 weeks
Deliverable 2 - Daml ERC‑20-Compatible Token (Canton Coin)
● Scope:
○ Implementation of a concrete ERC20Token Daml template compliant with Canton Token Standard.
■ Implements ERC‑20 behavior via templates such as TokenHolding,
Allowance, and issuer-governed TokenManager.
○ Smart contract logic for transfer, approve, transferFrom, mint, and burn mapped to Canton privacy-preserving workflows.
○ Unit testing
○ Integration with Canton devnet
● Estimated resources:
○ Engineering: 4 Weeks
○ Project Management: 1 week
● Estimated duration: 2 weeks
Deliverable 3 - Middleware Service (API and library)
● Scope:
○ ERC‑20-Compatible API Server: a stateless, externally accessible API server (REST or gRPC) implementing ERC‑20-like endpoints.
○ Transaction Orchestration Engine: Logic to construct and submit appropriate Daml commands using the Canton Ledger API.
○ Identity & Session Management: Identity resolution and Canton party mapping for API callers.
○ Contract State Resolver: Middleware module that resolves current token and allowance state for transaction construction. Optimization logic for
combining/splitting UTXO contracts during transfer flows.
○ Indexer Integration Adapter: Pulls balance/allowance data from indexer backend.
○ Infrastructure as Code (IaC): Scripts and configs for deployment,
containerization, and observability.
● Estimated resources:
○ Engineering: 8 Weeks
○ DevOps: 1 week
○ Project Management: 2 weeks
● Estimated duration: 4 weeks
Deliverable 4 - Indexer Backend Service
● Scope:
○ Indexer Core Service written in Rust, subscribing to Canton’s Ledger API and processing ERC20Token contract lifecycle events.
○ Database and Storage Engine: Postgres or equivalent SQL backend to track balances and allowances.
○ Deterministic update logic: Aggregates UTXOs deterministically for total supply and account balances.
○ Query API Layer: REST/gRPC server exposing balanceOf, allowance, totalSupply, etc.
○ Validator Coordination & Distribution: Infrastructure to deploy the indexer in a distributed fashion across multiple nodes.
○ Infrastructure as Code (IaC): Deployment and observability scripts.
● Estimated resources:
○ Engineering: 6 weeks
○ DevOps: 1 week
○ Project Management: 1.5 weeks
● Estimated duration: 3 weeks
Deliverable 5 - Integration Testing & Demo
● Scope:
○ End-to-End Functional Test Suite: Comprehensive automated tests validating all ERC‑20 operations.
○ Scenario-Based Daml Simulations: Integration of test scripts that simulate realistic user flows.
○ Mock Frontend / CLI Demo Application: A lightweight web UI or command-line interface that showcases ERC‑20 usage.
● Estimated resources:
○ Engineering: 2 weeks
○ Project Management: 0.5 weeks
● Estimated duration: 2 weeks
Deliverable 6 - Documentation & User Guide
● Scope:
○ Developer Integration Guide: for third-party developers on how to interact with the middleware, including API endpoints, authentication flows, example payloads, and token operations.
○ API Specs: documentation of all ERC‑20-compatible endpoints, suitable for inclusion in SDKs or third-party tooling.
● Estimated resources:
○ Engineering: 1 Week
○ Project Management: 0.5 weeks
● Estimated duration: 1 week
Phase 2 – ERC-20 Interface Abstraction and Multi-Token Enablement
The objective of Phase 2 is to generalize the ERC-20 middleware implementation and establish a reusable token-agnostic interface standard for ERC-20 compatibility on the Canton Network. This includes the formalization of a Daml interface (or interface suite) that defines the canonical set of ERC-20-compatible operations (e.g., balanceOf, transfer, approve, totalSupply) and standard interaction semantics. The Phase 1 ERC20Token implementation and middleware service will be refactored to interact exclusively through this interface abstraction, ensuring modularity and reuse.
This phase will enable future token templates to integrate with the middleware by simply implementing the standardized interface alongside the Canton Token Standard (CIP-0056). The indexer and API layers will also be updated to support runtime configurability for multi-token
handling, providing the operational foundation for a universal ERC-20 compatibility layer on Canton.
This phase will be scoped and budgeted separately based on technical insights, constraints, and architectural refinements resulting from Phase 1.
Phase 3 – Canton Improvement Proposal (CIP) & Validator-Grade Deployment
The objective of Phase 3 is to propose a formal Canton Improvement Proposal (CIP) to elevate the ERC-20 compatibility interface (defined in Phase 2) to a network-wide standard. The CIP will recommend that Canton Coin (the native token) implement the interface, thereby enabling Super Validators to natively run the ERC-20 middleware service in a standardized and trusted manner for Canton Coin.
It will include collaboration with the Global Synchronizer Foundation and Canton governance stakeholders to ensure the proposed standard aligns with the broader network roadmap, security model, and privacy guarantees.
Phase 3 will be proposed as a standalone engagement, contingent upon community alignment and successful validation of the technical interface in earlier phases.
Acceptance of the Deliverables
The Client shall have a period of ten (10) days after delivery to review and accept any Deliverables completed during the term of this Statement of Work. Within this period of time, the Client shall either accept the Deliverables or deliver to ChainSafe a detailed written statement of deficiencies to be corrected prior to the Client’s acceptance of the Deliverables. Within a commercially reasonable amount of time after receipt of such a statement of deficiencies (if
any), ChainSafe will deliver the corrected Deliverables. If the Client does not deliver a statement of deficiencies within the allotted time, the Deliverables shall be deemed immediately accepted by the Client.
Super Validator Application
The following deliverables will be drafted as a CIP as part of ChainSafe’s SV application. The application will include the following acceptance criteria.
Deliverables for Full SV Rewards
Add ChainSafe as an SV of weight 5.
Deliverables for full SV Reward:
Deliverable
Acceptance Criteria
Deadline
Weight
Earned
ERC-20
Middleware
MVP
Complete and Available on
MainNet
First EVM compatible
token launched on
Canton main network
using ChainSafe’s
ERC-20 middleware
+ 180 Days from CIP
Approval
1
Acceleration
Bonus
+0 Bonus if delivered +180 Days from SV CIP Approval
+2 Bonus if delivered +60 Days from SV CIP Approval
Linear sliding scale between +60 and +180 days
Example: If delivered in +120 days, Chainsafe is awarded +1 SV Weight
* At least one asset must be live, having completed a transaction on MainNet
+ 180 Days from CIP
Approval
Max 2
Adoption
Bonus
* Driving TVL of assets on Canton
+ 180 Days from
Middleware going to
MainNet
+ 0.5 per
asset with > $10m of
TVL issued on MainNet
Max +2
Prepared for:
Canton Network
Prepared by:
ChainSafe Systems
Date of SOW: 11 September, 2025
Version: 2.2
Statement of Work
ChainSafe Systems Inc.
Pursuant to Section 2.1 of the ChainSafe Master Service Agreement (the “Agreement”) dated ________________, 20____between ChainSafe Systems Inc. (“ChainSafe”) and <FULL_CLIENT_NAME> (the “Client”, collectively with ChainSafe the “Parties”, each a “Party”),
the Services and Deliverables are set out in this statement of work (this “Statement of Work”). This Statement of Work is effective as of the last signature date below (“Effective Date”).
This Statement of Work adopts and incorporates by reference the terms and conditions of the Agreement. ChainSafe and the Client may enter into additional Statement of Works for Services unrelated to the Services described hereunder.
I support moving forward with this ERC-20 compatibility proposal. It lowers adoption friction, aligns Canton with the dominant token standard, and provides a clear path to scaling TVL and ecosystem integrations.
We are ready to endorse it but have some points to raise which we think are very important:-
Privacy vs. ERC-20 Assumptions: ERC-20 expects global visibility. Canton doesn’t. Scoped visibility must be handled cleanly, with a standard error/response model, or we risk confusing developers.
-
Differentiation: This should be positioned as a compatibility layer, not a step toward Canton becoming “just another EVM.” Messaging matters.
-
Governance & Incentives: ChainSafe’s dual role (builder + SV candidate) is fine if structured correctly. SV weight should be tied not just to delivery but also to uptime, reliability, and adoption.
-
Spec vs. Implementation: The ERC-20 interface should become a Canton-wide open standard (via CIP), implemented and maintained openly, not controlled by a single vendor. All validators should be able to adopt it if they choose.
-
IP Ownership: Deliverables must remain open source, ensuring that no one party owns the IP and that the ecosystem can evolve collectively.
If we execute with those safeguards, this can be a powerful accelerator for the network.-
- I got feedback that this didn't sound like an endorsement.
We actually do endorse this. Just wanted to point out some stuff. - As discussed please find a link to a video demo of our middleware api.
