Champion introduction for a Daml disclosure proposal
grants-discuss0 messages
- Hi,
I'm looking for a champion for a Development Fund proposal, and I'd
rather ask than guess.
I built the tool before writing the proposal:
https://github.com/soloking1412/dpm-disclose
It works out which parties can see a Daml contract, and fails the build
when an upgrade widens that set. Adding a single observer line can pull
a new party into the transaction tree, and in review it just looks like
a field addition.
I checked it against what's already funded. Certora's analyzer looks at
authority between packages, OpenZeppelin's daml-lint at conservation and
arithmetic faults. Neither computes an informee set.
The proposal is drafted and scoped to six months. I haven't opened it as
a PR yet because I don't want to name a champion who hasn't agreed. I
have opened one to join the Daml Language and Developer Tooling SIG:
https://github.com/canton-foundation/canton-dev-fund/pull/624
Is there someone you'd suggest I talk to?
Thanks,
Maheswaran Velmurugan - Adding the funding and milestones I left out, plus some numbers I didn't
have when I posted.
I've also cut the scope since then. I originally had a fourth milestone
covering workflow level analysis and divulgence. Dropping it takes the
request from 1,150,000 to 700,000 CC over five months. That work is a
different problem on a different timeframe and belongs in its own
proposal if the first part lands.
M1 month 2 300,000 CC Daml-LF analysis
M2 month 4 250,000 CC disclosure.yaml and the upgrade gate
M3 month 5 150,000 CC dpm component, docs, handover
On M1 I'd rather commit to numbers than adjectives. I ran the tool over
415 templates in six public packages including Daml Finance and Splice,
and published the baseline with the packages pinned to commits and the
script included:
https://github.com/soloking1412/dpm-disclose/blob/main/docs/2026-08-public-package-sweep.md
It resolves 84% of nodes from source today. M1 gets that to 95%, and
daml-finance specifically from 45% to 95%. You can re-run the script and
check the before number yourself.
Two things from that run I didn't expect.
Three quarters of what the tool can't resolve comes down to a single
function, Disclosure.flattenObservers. So the remaining work is narrower
than 84% makes it sound.
And three templates in Splice resolve to no party at all. Subscription
in splice-wallet-payments is the clearest. The signatory clause calls a
helper, and that helper sits two lines below in the same file returning
[sender, receiver, provider]. Anyone reading the file gets it straight
away. The tool doesn't, because it doesn't follow functions yet.
The sweep also turned up three bugs in my own parser, now fixed with
tests taken from the code that broke them. They only showed up because
the tool prints what it can't attribute instead of quietly dropping it.
If you'd want this to exist, or you think the informee rule I'm applying
is wrong, I'd like to hear either. It's analyse() in
src/disclose/ledger.py, about twenty lines.
Maheswaran Velmurugan - This is a useful shape for the problem, and the rollback asymmetry
framing matches what I've run into.
One gap worth considering for the plan output. The planner covers
whether an upgrade is mechanically safe to apply: upload order, vetting,
what can be rolled back via topology serials. It doesn't cover whether
the new DAR changes who can see the contracts it applies to. Under SCU
the new version takes effect for existing contracts, so a change to a
signatory, observer or choice observer clause silently alters the
informee set on contracts that already exist. Nothing in the current
plan output would surface that, and it isn't rollback-safe in the way a
vetting change is, because the disclosure already happened.
Concretely: adding one observer to a template widens the create node and
every consuming choice on it, since a consuming exercise informs the
contract's observers. In a diff it reads as a field addition.
I've been working on the disclosure side of this and have a tool that
computes the informee set per node and diffs it between two versions:
https://github.com/soloking1412/dpm-disclose
It emits JSON, so if you wanted a "disclosure changes" section in the
migration plan it should be straightforward to feed in rather than
building it yourself. Happy to shape the output to whatever your plan
format needs.
One data point that might be relevant to your M1 scope: I ran it over
415 templates in Daml Finance and Splice, and three quarters of what
source-level analysis can't resolve comes down to a single helper
function. The measurements are here if useful:
https://github.com/soloking1412/dpm-disclose/blob/main/docs/2026-08-public-package-sweep.md