DeCCP: decentralized central counterparty

"Central" describes the logical role: obligations are accepted, netted, guaranteed and resolved through one authoritative clearing state. "Decentralized" describes control: material changes require a threshold of independent authorities, and settlement is verified against DeFMI rather than trusted to one operator. The crates do not custody assets and are not, by themselves, a licensed clearing house.

source: deccp/README.md, defmi/DEFMI.md §4.2 · crate deccp-core (the only workspace member); the Aethel adapter is aethel-deccp in the aethel repository

Clearing flow

flowchart LR
    G["Threshold authorities"] --> B["Create and govern ClearingBook"]
    K["DeKYX
qualification proof"] --> M["Admit clearing member"]
    D1["DeFMI
capital, fund, collateral locks"] --> M
    M --> O["Accept verified obligations"]
    Z["zkPI verifier"] --> O
    O --> N["Compute net positions"]
    N --> C{"All risk and conservation
checks pass?"}
    C -->|no| R["Reject without state change"]
    C -->|yes| S["Settlement proposal"]
    S --> D2["DeFMI
settle exact proposal"]
    D2 --> E["Record settlement receipt"]
    M --> X["Default declaration"]
    X --> W["Apply loss waterfall"]
    W --> D2

DeCCP advances a final clearing or default state only when a DeFMI receipt is bound to the exact proposal or waterfall context. A partial or mismatched receipt cannot finalise anything.

Admission and margin

Member admission requires threshold approval, a verified DeKYX eligibility result, and a live DeFMI default-fund lock. DeCCP records a scoped subject line, not a legal name. Capital, default-fund and collateral lock identifiers must be unique, so one external lock cannot back multiple risk positions. Margin changes and material cycle controls are threshold-approved; every net risk debit must fit inside the participant's encumbered margin or the close is rejected.

Three netting modes

For every asset, the sum of net positions must remain zero. The resulting proposal has a canonical digest so the settlement receipt cannot be moved to a different cycle or set of legs. The cryptographic cost of each mode on committed balances is on the DeFMI page; the finding that matters is that novation is free arithmetically (two multiplications, no proof) and that a cleared cycle's cost stops growing with the number of trades, at 0.53 µs per trade for the novation itself.

Guarantee facilities

The public-value path tracks facility capacity, reserved, consumed and individual holds, with compare-and-swap sequence checks so two concurrent requests cannot spend the same remaining capacity. The confidential path stores a coverage commitment and a DeFMI state digest rather than a plaintext amount; reserve, release and claim name the prior sequence and digest, and the DeFMI adapter must verify the hidden amount relation, capacity bound, transition proof and final receipt before DeCCP advances. Aethel's aethel-deccp adapter maps Aethel guarantee lifecycle events onto these transitions; the mapping lives in the aethel repository and imports deccp-core, so DeCCP never imports an Aethel crate.

Default waterfall

A default case records the triggering evidence, the defaulter's available resources, mutualised layers, the CCP's own contribution and the resulting draws. Resolution requires threshold approval and a DeFMI receipt for the exact waterfall context. On the settlement side the tranche ordering is enforced with a committed product pinned to the identity (draw_k × remaining_{k−1} = 0), at about 11 ms per tranche to build and 1.4 ms to verify, once per default. The CCP's capital sits between the defaulting member's fund contribution and the mutualised pool, where CPMI-IOSCO and EMIR put it.

Invariants checked on every accepted path

• threshold approvals are bound to a canonical operation digest
• member subject lines, external locks, obligations, facilities and holds are unique in their scope
• incoming obligations must pass InstructionPort; a non-zero digest alone is not a valid zkPI
• net positions conserve each asset exactly
• margin and guarantee reservations cannot exceed available capacity
• expired, released or consumed holds cannot be claimed again
• settlement and default receipts must name the exact proposal context
• invalid operations fail without partially updating state

Persistence and recovery

ClearingBook is not directly deserialisable, because unchecked restoration would bypass quorum, qualification and settlement validation. Two recovery models: replay verified operations into a new book, or restore a ClearingSnapshot after validating its canonical digest, authority set, approval and structural invariants. restore_authenticated may be used only when the host storage already commits to the exact snapshot bytes, such as consensus state under a state root; it skips a second snapshot signature, not the structural validation.

Ports

flowchart TB
    DK["DeKYX"] -->|verified eligibility| EP["EligibilityPort"]
    Z["zkPI"] -->|verified instruction| IP["InstructionPort"]
    DF["DeFMI"] -->|locks and receipts| DP["DeFmiPort"]
    EP --> CORE["deccp-core"]
    IP --> CORE
    DP --> CORE
    A["aethel-deccp (aethel repo)
optional guarantee adapter"] --> CORE

deccp-core has no dependency on Aethel, DeKYX, zkPI or DeFMI crates. A deployment can replace the credential scheme or the settlement network without weakening DeCCP's internal invariants.

What DeCCP does not do

• Cross-margining across providers: a position at one clearing provider is not offset against a position at another.
• Cross-instrument novation: obligation graphs are per asset and a mixed novation is refused rather than netted.
• Legal novation: arithmetic validity says nothing about validity under the register's rulebook. "A CCP is no longer needed" is on the may-not-claim list.
• Detecting omission: a house can leave a trade out, though it can no longer invent one. A graph missing an edge is a consistent graph; the tranche is what makes that expensive.