Two-party composition

Documentation Index

Fetch the complete documentation index at: https://docs.inkwell.finance/llms.txt

Use this file to discover all available pages before exploring further.

CONFIDENTIAL & PROPRIETARY © 2026 Inkwell Finance, Inc. All Rights Reserved. This document is for informational purposes only and does not constitute legal, tax, or investment advice, nor an offer to sell or a solicitation to buy any security or other financial instrument. Any examples, structures, or flows described here are design intent only and may change.

Every valid Dagon participant is identified by two halves, held by two independent parties. Naming a participant requires both halves. Neither party alone can do it, because neither party holds both.

​

The halves

​

Operator-held: session_id → ephemeral_public_key

When a user starts a session, their client generates a fresh ephemeral keypair locally. The operator records the minimum-necessary mapping between the session id and the ephemeral public key — plus any IP telemetry required for OFAC / geofencing compliance under applicable retention law. The operator does not record, and never sees:

• The user’s real-world identity, document, or name.
• The user’s wallet address outside this session.
• The user’s credential (credentials are presented in zero-knowledge — see below).
• Any order contents, curves, or fill details during matching (the FHE circuit is operator-blind).

​

Issuer-held: credential → PII

Every counterparty holds a KYC-backed credential issued off-chain by a credential issuer. Two credential primitives are supported, both of which let the user prove eligibility without revealing their identity:

• BBS+ — a pairing-based signature that supports selective disclosure and blind issuance. The user can prove “this credential exists and is valid” without revealing the underlying signature.
• Coconut — a threshold blind-signature credential with similar selective-disclosure properties; additionally supports multi-issuer issuance.

Both are forms of zero-knowledge credentials — zkKYC in the common idiom. The issuer KYC’d the user once, at credential issuance, and holds the mapping between the issued credential and the user’s document-verified identity. The issuer operates under its own jurisdiction’s data-protection regime (GDPR in the EU, state privacy laws in the US). The issuer does not see, and never knows:

• Which Dagon sessions the user opened.
• Any order activity, clearing prices, fills, or contents.
• Anything Dagon does. Dagon does not tell the issuer.

​

What Dagon retains

Dagon (the operator) retains only what the compelled-process path requires:

• Session ↔ ephemeral-key mapping, for the retention window required by applicable law.
• IP telemetry, for the window required by OFAC / geofencing obligations.

Dagon retains no PII. Ever. If a design proposed to import user PII into operator systems, we would reject it regardless of convenience. The PII lives with the issuer, under the issuer’s own legal posture.

​

Why the split is load-bearing

If the operator alone is asked “who is this user?”:

• It has the session id and the ephemeral public key for that session.
• It does not have the credential that unlocked the session (credentials are presented in zero-knowledge; the operator verifies validity but does not see the credential itself).
• It cannot produce a name.

If the issuer alone is asked “what did this user do?”:

• It has the credential-to-PII mapping.
• It does not have session ids, ephemeral keys, or any venue activity.
• It cannot produce a trade history.

Under compelled process served on both parties:

• Operator produces session_id → ephemeral_public_key for the named user’s sessions (scoped to the compelled period).
• Issuer produces credential_used → PII for the named user.
• Joining them via the credential verifier proof reveals which sessions belong to the named user.
• The named user’s trade history is the union of their sessions’ submissions.

​

How the user deposits and withdraws

Depositing and withdrawing are user-controlled. Dagon is non-custodial: the user’s funds never leave their own signing authority. The operator cannot move user funds; the issuer cannot move user funds. Users pick their own on-chain rails (wallet of choice, bridge of choice), and the matching engine operates only on already-deposited balances. Matching never decrypts. Decryption happens only on user-controlled withdrawal and on the user’s client-side balance view.

​

Ephemeral credentials and multi-schedule submission

For market makers submitting multiple schedules per batch, a naive design would leak the multiplicity: one credential per submitter per batch means k schedules expose k lanes to an observer. This breaks the 1/N lane-anonymity bound that makes the batch private. The production design introduces a credential-mint role that issues batch-unlinkable ephemeral credentials. The holder presents a single long-lived BBS+ credential once to the mint; the mint blind-signs an ephemeral credential per schedule. Each ephemeral is unlinkable to the long-lived credential and to other ephemerals from the same holder. Submissions carry the ephemeral, not the long-lived credential. The mint is a separate trust boundary (TB-CRED-MINT). It can be run by the same entity as the credential issuer under the same regulatory posture, or by a separate party.

​

Failure modes

​

Operator compromise

An attacker steals the operator’s database. They get session ids and ephemeral public keys. They do not get names. The venue’s users cannot be doxed from that data alone.

​

Issuer compromise

An attacker steals the issuer’s KYC database. They get names and credential identifiers. They do not get venue activity. The breach is equivalent to a standard KYC-database breach — bad, but unconnected to trades.

​

Both compromised simultaneously

This is the weakest point of the design. If both parties are simultaneously breached, the composition collapses and identity is resolvable. Mitigation:

• Jurisdictional dispersion between operator and issuer.
• Different infrastructure stacks.
• Different personnel and supply chains.
• Independent security audits.
• (Production) the operator role itself decentralizes across an Ika 2PC-MPC dWallet network — see the note above.

​

Adversarial credential issuer

A malicious issuer could attempt to link a credential to the wrong PII. This is detectable at credential issuance (the user signs their own enrollment), and the issuer’s attestation is verifiable. A rogue issuer can refuse to onboard users, but cannot frame an existing user.

​

Relationship to “compliance”

The two-party composition is not a clever dodge of compliance — it is a stronger implementation of it. Under a single-party model, a subpoena pulls the whole record; an insider query pulls the whole record; a breach leaks the whole record. Under two-party composition, a subpoena pulls one named user’s record; an insider query at one party pulls half of nothing; a breach at one party leaks half of nothing. The disclosure surface area shrinks. The legitimate disclosure path remains open. That is the trade — and it is a trade that lets Dagon clear MiCA / Reg ATS / MiFID II posture that a mixer cannot. See Is this a mixer? for the positive rebuttal.

​

Further reading

• Selective disclosure by design
• Confidential matching
• What happens under subpoena?