#680Declined Pull Request3.5M CC requested

Add Gaming SDK for Canton proposal

alituzun26-08-2026Last activity 10d ago

dapp-integrationneeds-champion

Development Fund Proposal Submission

Proposal file:
proposals/2026-08-arCCade-gaming-sdk-for-canton.md — rendered on the PR branch. Also readable under Files changed.

Applicant

Organization:
arCCade

Author / Primary Contact:
Melkor, arCCade — melkor@arccade.io — @alituzun

Champion:
Needs Champion

Proposal Classification

Proposal Type:

RFP-aligned proposal
Individual initiative

RFP / Roadmap Area:
N/A — individual initiative. Two areas under Developer Experience, Tooling & Education are adjacent and neither is a clean fit: RFP 14 concerns the wallet as an interface, while this sits one layer inward and defines what a game venue and a player's wallet agree to on the ledger; RFP 17 concerns ledger client libraries held to the ledger client standard, which this is not — its clients speak to the package, not to the ledger API. Claiming either would invite review against a brief the work is not trying to meet. The roadmap areas it does advance are named in the proposal under Roadmap alignment.

Suggested SIG: dApp Integration

Label:
dapp-integration

Funding & Timeline

Total Funding Request:
3,500,000 CC

Project Duration:
3.5 months (14 calendar weeks)

Maximum Amount:
N/A

Maximum Duration:
N/A

Summary

Canton has custody, privacy and deterministic finality, but no reusable primitive for game economies, so every studio rebuilds custody, atomic commitment, settlement ordering and player recovery for itself.

This proposal turns arCCade's working, TestNet-vetted implementation into the Apache-2.0 Gaming SDK for Canton: a two-write settlement cycle with cryptographic entry and outcome commitments, clients at parity in JavaScript, Python and Java, two open-source reference games, Merkle audit anchoring, an independent security audit, and a MainNet path.

The result is a primitive a Canton game studio can adopt rather than rebuild — and 52.9% of the funding is released only once external studios have actually adopted it.

Verifiable before review

The reference package is already public, and the central claim in this proposal can be checked in a few minutes without taking anything on trust:

git clone https://github.com/arCCade/arccade-game-sdk
cd arccade-game-sdk && daml build

A clone at any path — with no arCCade infrastructure and no Splice installation — produces main package id

edb0af194381326861eb20da2e87d9698e9825172eb5ed3b4d381272dd811c3a

which is byte-identical to the DAR vetted on Canton TestNet. 378 tests run from that same clone: 90 Daml scripts, 117 JavaScript, 115 Java and 56 Python, plus a conformance manifest of 72 catalogued capabilities driven by three runners.

Updated since first submission

This PR was opened on 26 August against package 1.3.0. Work it had scheduled inside funded Milestones 1–3 has since shipped unfunded, and the proposal has been revised rather than left to describe a state that no longer holds.

Unchanged: 3,500,000 CC total, milestone payments 450k / 600k / 600k / 1,850k, 14 calendar weeks, 42 engineer-weeks, 2 developers + 1 analyst, Needs Champion.

Originally scheduled	Delivered
M2 — contract-level concurrency enforcement	`PlayerRoster` and on-chain `concurrencyLimit`, v1.4.0, vetted 27 Aug
M2 — Merkle audit anchoring	`Audit.daml`, cycle rows, period anchors, v1.5.0, vetted 27 Aug
M3 — three clients at feature parity	JavaScript 1.5.3, Python 1.5.1, Java 1.5.1
M3 — shared conformance suite	72 capabilities, three runners, one manifest
M1 — public repository, npm, documentation	GitHub, `@arccade/game-sdk`, sdk.arccade.io
not previously scheduled	`AllocationV2` — a committed allocation can hold a stake, v1.6.0

The same funding now buys the work that remains: registry distribution (the Python and Java clients are not on PyPI or Maven Central, so two of three can only be used by vendoring source), an independent verification tool, arCCade's own backend migrated onto the public package, two open-source reference games, and the unchanged Milestone 4 — audit, MainNet, external adoption, CIP draft.

Adoption is now measured in every milestone rather than only in M4, in response to the review guidance that adoption should be the primary indicator of success.

The disclosure made in the first submission has been kept, not removed. That submission stated that the venue's concurrency limit was validated but not enforced by the contract. It is enforced as of v1.4.0. The risk is retained in the proposal, struck through, with what became of it — and a new one replaces it: arCCade's own backend does not yet run on the public SDK. An SDK whose author has not adopted it has not been proven at the boundary that matters, which is why that integration now sits inside Milestone 2.

Submission Checklist

← Back to Proposals