CIP-56/ERC-20 Middleware #453 - Milestone 1: Architecture & Daml / Bridge Contracts

Milestone 1: Architecture & Daml / Bridge Contracts

Acceptance criteria, verbatim from #453:

• Architecture and design documents (deployment topology, data-flow, API schemas, security/privacy model) published to the public repository and available for committee review.
• cip56-token and bridge-core packages build and pass their unit + integration test suites against Canton mainnet, reproducibly from the repo.

Criterion	Evidence
Documents published	Ten documents under docs/, one owning each named area: topology and four end-to-end data flows in ARCHITECTURE.md, schemas in docs/openapi/ (three OpenAPI 3.1 documents, 41 paths, authentication class stated per route), the security and privacy model in SECURITY_AND_PRIVACY_MODEL.md, the threat model and custody evaluation in SIGNER_ARCHITECTURE.md. The OpenAPI README names the nine Go files where routes are registered and gives a lint command, so the specs can be diffed against the code.
Packages build and pass	Nine Daml packages build on SDK 3.4.8. 18 Daml Script tests across four test packages. Package IDs are content hashes of the built DAR, so a reviewer with the source and that SDK can rebuild and compare identifiers. Those packages run on the MainNet participant: DEMO, a CIP-56 token issued from them, returns totalSupply 1000e18 in production.

Stated plainly: the second criterion says "against Canton mainnet, reproducibly from the repo". The packages are deployed on MainNet and the suites pass on the local harness and in CI, but we have not yet run the package suites pointed at a MainNet participant. We are claiming deployment plus a green harness run, and we would rather say so than let the wording pass unexamined.

Two points raised publicly on #453 by @Noosphere-314 on 22 September, answered here.

Which CantonBridge.sol is canonical for MainNet. canton-wayfinder/src/CantonBridge.sol at 054801f is the deployed contract and the one the relayer calls. The contract under canton-erc20/ethereum/ is an earlier exploration and is not deployed.

approve and transferFrom. No standalone allowance template ships, which matches the proposal's own wording that ERC-20 semantics are "mapped to TransferFactory / signed-instruction flows rather than via a standalone allowance template". CIP-56 defines no template granting a third party spending rights over another holder's holding, so there is nothing for approve to write or allowance to read. We return JSON-RPC -32601 rather than a success the ledger would never honour, and allowance returns zero. We ask the committee to confirm this treatment.

Lock and unlock on Ethereum, mint and burn on Canton. The proposal describes bridge-core as a lock/unlock/mint/burn state machine. As built, Ethereum escrows and releases while Canton mints and burns. The asset stays on its home chain, which is the standard lock-and-mint design, and issuance authority never crosses the boundary, so locked balance against minted supply stays auditable from either side.

Funding, Milestone 1

Milestone	Trigger	Gross (CC)
M1: Architecture & Daml / Bridge Contracts	Committee acceptance; accrued SV credit applies	1,500,000

Originally posted by @pedrodneves in #887