> ## 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.

# Two-party composition

> Identity is split across an operator and a credential issuer. Neither alone can name a trader. The issuer holds PII; Dagon holds none of it.

> **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.

<Info>
  **Pre-alpha vs production.** Pages that describe "the operator holds the session-to-ephemeral-key mapping" describe today's single-operator implementation. Production Dagon will distribute this custody across an [Ika 2PC-MPC dWallet network](https://ika.xyz) — no single "operator" entity will hold the mapping, and no unilateral disclosure (lawful or otherwise) will be possible without the network agreeing. The two-party composition described here is strengthened, not weakened, by the migration. See [Design Philosophy](/inkwell/design-philosophy) for the full decentralization roadmap.
</Info>

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+](https://identity.foundation/bbs-signature/)** — 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](https://arxiv.org/abs/1802.07344)** — 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?](/dagon/faq/is-this-a-mixer) for the positive
rebuttal.

## Further reading

* [Selective disclosure by design](/dagon/concepts/selective-disclosure)
* [Confidential matching](/dagon/concepts/confidential-matching)
* [What happens under subpoena?](/dagon/faq/what-happens-under-subpoena)