Architecture

Repository layout

daml/      Daml model: participant profiles, bilateral trades, cycle proposal and
           participation, the atomic execute, and selective disclosure
app/       Off-ledger client: payload encryption, commitments, per-node verification,
           the matching stand-in, the Ledger API client, and typed model bindings
demo/      Demo application: party selection and the per-party views, each rendered
           from that party's own ledger projection
landing/   Landing site
docs/      This documentation site
deploy/    Local Canton sandbox script and topology notes

The Daml model (daml/)

The on-ledger contracts hold only commitments, ciphertext, topology, and boolean attestations — never cleartext economics.

• ParticipantProfile— signatory: the participant; optional observer: that participant's regulator, granted only through disclosure. Carries an encrypted sensitivity commitment.
• BilateralTrade— signatories: the two counterparties only. Carries the trade's economic terms as ciphertext plus a hash commitment. No operator party is ever a stakeholder. A NominateIntoCycle choice can mark a trade eligible for a cycle by reference without revealing terms — modeled, though the current live flow references the teardown trades directly by contract id.
• CompressionCycle— an accumulating contract. It starts signed only by the operator (carrying no economics); each invited participant exercises Commit, which recreates the cycle adding that participant to the signatory set along with its replacement-leg commitments and a withinTolerance boolean. Once every participant has committed, the operator exercises Execute: in one transaction it archives the nominated trades and creates the replacement legs, each signed only by its two counterparties. This composition is required because a Daml choice's authority does not accumulate across separate exercises — the accumulating contract is what lets one atomic transaction carry every participant's authority. Consent is bound to the exact plan: a participant exercises Commit on one specific cycle contract carrying that teardown list and topology, and Commit rebuilds the cycle with create this with, so neither field can drift as commits accumulate — and an already-committed set cannot be moved onto a different list, because committed is the signatory set and only Commit adds to it. What Commit does not check is whether a listed trade was ever one the participant agreed to include; binding that via NominateIntoCycle is roadmap.
• SelectiveAuditDisclosure— participant-initiated; adds that participant's regulator as an observer on that participant's own contracts and decryption scope only, with no transitive disclosure to any other participant's data.

The off-ledger client (app/)

Runs on each participant's own side.

• crypto/— per-leg authenticated encryption (libsodium crypto_secretbox under a fresh content key), key-wrapping to a leg's counterparties via sealed boxes, and a salted hash commitment over the canonical cleartext.
• verify/— the per-node residual-risk check: a real, deterministic computation over a participant's own decrypted positions, comparing the movement a proposed compression would cause against the participant's declared tolerance.
• cycle/ — composes crypto and verify into what a participant actually submits: open and verify each replacement leg, then emit the on-ledger participation only if the check passes.
• solver/— the matching stand-in (see Scope below): a small, deterministic algorithm that nets each party's risk across a set of nominated trades and rebuilds those net positions with a minimal set of replacement legs.
• ledger/— a per-party JSON Ledger API v2 client: submit commands, read a party's own active contracts and its CREATE/ARCHIVE activity feed, and manage parties. It holds no key that can decrypt a payload.
• model/ — typed bindings between the Daml model and the JSON the ledger client sends and reads.

The demo (demo/)

A party-selection entry followed by per-party views, each rendered from that party's own Ledger API projection: a Compression Console, a Ledger/X-ray activity feed with a contract-detail drawer, an animated privacy-matrix scoreboard computed from real projection reads, a "try to cheat" control that genuinely attempts to reveal a position as the operator, and a live counter. Shares a dealer-terminal design system with the landing site.

Scope

This is a hackathon build focused on the privacy architecture, not a production compression engine.

• The matching is a real, deterministic algorithm, not a production risk model. It nets sensitivities and rebuilds a minimal replacement topology; it does not implement SIMM, SA-CCR, or CRIF. It can also pair parties that had no trade with each other before, where production services typically only shrink existing obligations.
• Operator-blind matching via multi-party computation, topology hiding, a legal-enforceability wrapper, asset settlement, and MainNet deployment are roadmap items, not part of this build.
• Key handling is demo-grade. The code is unaudited and runs on DevNet/local sandbox only.
• Three participant nodes, with limits.A multilateral cycle has run across three participant nodes, with the operator on a node that hosts no firm, and the operator a stakeholder of no trade (it still receives the cycle's trades as ciphertext when it executes — see the privacy model); its net replacement leg is signed by parties on two different nodes. One node is a shared, colocated participant and two run on the same host, sealed legs are handed over in-process rather than over a real channel, and the hosted demo runs on a single participant.