Status — active development (pre-release). Interfaces and design docs are in place and evolving; APIs and package layout may change without notice until the first tagged release.
Concordia is the reference implementation of Canton Allocation Primitives (CAP) — an open-source Daml interface library for privacy-preserving, multi-party allocation and decision workflows on the Canton Network.
CAP targets the class of coordination problems where multiple parties submit private inputs, a rule resolves those inputs into an outcome, and the outcome triggers a downstream executable action — atomically, with on-ledger authority. Auctions and governance are the two worked instances.
M2 adds one reference format per domain,
built on the same cap-core, each running as Daml Script and against
a Canton sandbox.
| M2 deliverable | Where to look |
|---|---|
Majority-vote reference slice on cap-core |
examples/governance/private-majority-vote — demos |
Sealed-bid auction reference slice on cap-core |
examples/auctions/sealed-bid-first-price — demos |
| Private ballot handling demonstrated | whoSeesWhat — governance demos |
| Private bid handling demonstrated | whoSeesWhat — auction demos |
| Daml Script demos for both slices | .../private-majority-vote/demo, .../sealed-bid-first-price/demo — how to run |
| Sandbox integration tests for both slices | scripts/sandbox-test.sh — how to run |
M2 tracks as issue #539.
| M1 deliverable | Where to look |
|---|---|
Design document for cap-core |
DESIGN.md |
| First-release scope and out-of-scope items | SCOPE.md |
| Extension points for downstream modules | POST-RELEASE.md |
| Prototype of a typical workflow on Canton sandbox | examples/governance/baby-dso |
M1 tracks as issue #538.
Concordia is a three-tier library: domain-agnostic interfaces in cap-core,
and per-domain standards that require them and add their own.
cap-core—Submittable(a private input, admitted by a declared check) andResolver(the mechanism: window, authority set, resolution), pluscap-core-utils, the implementer's toolkit.cap-governance—Ballot,AuthenticTarget(the state an execution acts on, and what drift means for it),Action(an effect arriving from a package deployed after the core),Executable.cap-auctions—OneLotBid,Settlement, and a registry binding; settlement composes with the Token Standard V2 rather than restating it.
A format author writes templates implementing the tiers they need. CAP sits above Canton's asset and settlement layer.
concordia/
├── cap-core/ # Tier 1: domain-agnostic
│ ├── Interfaces/{submittable,resolver}
│ └── cap-core-utils/ # admission, execution, patch, time, value
├── cap-governance/ # Tier 2: governance
│ ├── Interfaces/{binding,executable,action,ballot}
│ └── cap-governance-utils/ # drift, pinning, separable formats
├── cap-auctions/ # Tier 2: auctions (Token Standard V2)
│ ├── Interfaces/{bid,settlement}
│ ├── cap-auctions-utils/
│ └── cap-auctions-funding/
├── examples/governance/
│ ├── baby-dso/ # M1: Splice DSO governance
│ │ ├── plain/ # the shape being argued against
│ │ └── cap/{ans,config,governance,action,demo}
│ └── private-majority-vote/ # M2: private ballots, {impl,demo}
├── examples/auctions/
│ └── sealed-bid-first-price/ # M2: private bids, {impl,impostors,demo}
├── examples/lib/ # vendored DARs only the examples need
├── lib/ # vendored Token Standard DARs (prebuilt)
├── scripts/sandbox-test.sh # sandbox integration run
├── multi-package.yaml # dpm workspace (build order)
├── DESIGN.md # cap-core design (threat models inline)
├── RATIONALE.md # why the design is not something else
├── SCOPE.md # first-release scope, capability → milestone
├── POST-RELEASE.md # extension points for downstream modules
├── CHANGELOG.md
├── LICENSE # Apache-2.0
└── README.md # this file
cap-governance/DESIGN.md and cap-auctions/DESIGN.md carry the tier-2 designs.
RATIONALE.md records why each of these shapes was chosen over
the alternative, with the per-domain decisions in
cap-governance/RATIONALE.md and
cap-auctions/RATIONALE.md.
Concordia builds with dpm (the Daml Project Manager),
SDK 3.4.11. From the repository root:
dpm build --all # every package in dependency order, per multi-package.yamlQuick check — the in-memory script runner, no sandbox. Each package is run
from the repo root with --package-root:
# M2 — majority vote, all scripts ok
dpm test --package-root examples/governance/private-majority-vote/demo
# M2 — sealed-bid first price, all scripts ok
dpm test --package-root examples/auctions/sealed-bid-first-price/demo
# M1 — BabyDso on cap, all scripts ok
dpm test --package-root examples/governance/baby-dso/cap/demoEach DEMOS.md says what its scripts assert, and what they deliberately do not.
The same scripts run against a real ledger. scripts/sandbox-test.sh boots a
static-time sandbox, uploads the demo DARs and runs every script in each:
dpm build --all
./scripts/sandbox-test.shTo drive one DAR by hand instead, start the sandbox yourself and point
dpm script at it — the scripts drive time, so --static-time is required on
both sides:
# terminal 1
dpm sandbox --static-time
# terminal 2
dpm script --all --ledger-host localhost --ledger-port 6865 \
--static-time --upload-dar true \
--dar examples/governance/private-majority-vote/demo/.daml/dist/cap-example-majority-vote-demo-0.1.0.darThe other demo DARs, same shape:
examples/auctions/sealed-bid-first-price/demo/.daml/dist/cap-example-sealed-first-price-demo-0.1.0.dar
examples/governance/baby-dso/cap/demo/.daml/dist/cap-example-babydso-demo-0.1.0.dar
Expected: every script reports SUCCESS, in the same counts dpm test reports
as ok.
External adopters and contributors are welcome to read the design, open issues, and comment. The library is pre-release and its interfaces are still moving, so please open an issue to discuss before substantial changes.
Apache License 2.0 — see LICENSE.