Proposal: cantonsim
Development Fund Proposal Submission
Proposal file:
rfps/developer-experience-tooling-education/2026-09-PixelPlex-cantonsim.md
Applicant
Organization: PixelPlex
Author / Primary Contact: Alexei Dulub, alexei.dulub@pixelplex.io
Champion:
Needs Champion
Proposal Classification
Proposal Type:
- RFP-aligned proposal
- Individual initiative
RFP / Roadmap Area: RFP 20, Indexers — Developer Experience, Tooling & Education. Responds to the transaction simulation / dry-run and debugging need recorded in the roadmap's Q1 and Q2 DevRel survey note. Secondary alignment: RFP 19 DPM Components, RFP 18 Integration into SDLCs, RFP 26 Key Management and Signing Controls.
Label:
daml-tooling
Funding & Timeline
Total Funding Request: 2,400,000 CC
Project Duration: 6 months (24 weeks)
Maximum Amount:
N/A — RFP 20 specifies no maximum amount.
Maximum Duration:
N/A — RFP 20 specifies no maximum duration.
Summary
Canton developers, application operators and wallets cannot find out what a
command will do before submitting it: who will receive which part of the
transaction, what it will cost, and why it is being refused. The participant
computes most of this during submission and returns almost none of it —
routing rejections arrive as one unstructured string, and a
CreateAndExerciseCommand passes preparation only to be refused at execute,
after it has been signed.
cantonsim is an open-source transaction analysis tool that runs the Ledger API
prepare flow against the caller's own participant and answers the questions
prepare leaves open: the participant-level view and recipient projection,
structured attribution for routing refusals, execute-compatibility, the signing
authority required, and a binding between what a wallet displayed and what it
signs. It ships as a DPM component (dpm sim), an embeddable TypeScript
library, a CI mode and a local web UI, with a scenario sandbox for multi-step
flows. Everything is Apache-2.0.
The value to the ecosystem is that every team submitting transactions — and every wallet asking a user to sign one — gets a checkable answer instead of a guess, computed on infrastructure they already control, with no contract state leaving their environment.
Submission Checklist
- Full proposal file is included in this PR
- Organization and primary contact identified
- Champion identified or
Needs Championselected - RFP / roadmap alignment identified, if applicable
- Total funding request provided
- Project duration provided
- Proposal is within any RFP maximum amount
- Proposal is within any RFP maximum duration
- Milestones and milestone funding are defined in the proposal
- Acceptance criteria are based on ecosystem value
- Architectural alignment is addressed
Notes for Reviewers
The proposal states its boundary against the adjacent work on the board in
§3a, including PR #481 (Tenderly Simulation for Daml on Canton), which is the
closest in ambition and is labelled Core/ready for vote. The short version:
#481 hosts a forked Virtual Participant and hydrates it from an uploaded ACS;
cantonsim asks the caller's real participant, which is what lets it answer
execute-compatibility, live routing attribution, the actual traffic cost and
the signing-hash binding. Should both be funded, we will consume its
simulation API rather than stand up a competing hosted service.
A companion implementation draft accompanies this proposal, with the real interface shapes, the data sources per analysis, the feasibility gates and an appendix reproducing the contract-id recomputation self-check. We are happy to walk a reviewer through either document.
This proposal is submitted with Needs Champion. The most likely reviewer
paths are the Daml Language & Developer Tooling SIG, which owns the
daml-tooling label this proposal carries, and the Canton APIs SIG, since the
work sits on the interactive submission service. We would welcome the
Foundation or either SIG routing it to a Tech & Ops Committee member willing
to champion it.