ERC-20 Middleware and Distributed Indexer for Canton Network

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-56). 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:

SV Reward Mechanics:

• An extraBeneficiary PartyID associated with the ‘escrowed’ Super Validator will be setup by the Foundation, or another SV node operator approved to provide SV rewards escrow services, with an SV Weight at the maximum earnable weight.

  • The Applicant is responsible for coordinating the process of setting up the escrowed weights with the GSF and the operator of the SV node.
  • The Applicant is responsible for all costs associated with the operation of the escrow SV
  • The escrow SV will NOT mint rewards on a block by block basis
  • All escrow SV rewards will go to the Unclaimed Rewards pool

• ⅔ of the Super Validator Operators will update their configurations to allow the escrowing SV node to host the full weight to be earned by the given Super Validator

• Applicant is required to present proof of successful completed milestones to the Tokenomics Working Group

  • Applicant is required to present a calculation for number of Canton Coin it should earn for meeting the requirements of the milestone

• If the Tokenomics Working Group agrees the milestone has been met and agrees with the calculation, an announcement will be sent via the Tokenomics-Announce mailing List

  • The GSF will update the extraBeneficiary to an active PartyID controlled by that Super Validator.
  • ⅔ of Super Validator Operators will then assign a portion of the Unclaimed Rewards to be minted by the Applicant’s Validator, based on the calculation approved by the Tokenomics working group.

• If any milestones and associated rewards are not achieved by the deadline

  • Applicant will be notified they have not met a deliverable by the GSF
  • Remaining SV Weight assigned to the extraBeneficiary SV will be removed from the GSF node configuration, and the total SV weight of the GSF SV node will be reduced by the same amount by a vote of the Super Validators.
  • The Tokenomics Working Group will make a recommendation to the SVs on what to do with the Unclaimed Rewards

• Applicant is subject to CIP-0045 : SV Operating Requirements

  • If, at any time, the Applicant has been rewarded SV Weight > 2.5, they are required to operate their SV within 6 months of crossing that Weight. This SV node will join the network with an SV weight of zero (0) and may add weights as the SV completes the milestones listed in this CIP.

Copyright

• This CIP is licensed under CC0-1.0: Creative Commons CC0 1.0 Universal.

Changelog

• 2025-10-14: Initial draft of the proposal.
• 2025-1015: CIP Approved.