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

# What happens under subpoena?

> A court compels both the operator and the credential issuer. Joined, they resolve one user's activity. Everything else in the batch stays private. Pre-alpha Dagon produces a narrower set of records than the production posture.

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

Dagon's architecture is designed to respond to lawful process through a
**two-party composition**: the venue operator and the credential issuer
must both be served, and neither alone can de-anonymize a user. This
page describes the production posture Dagon is building toward, and
separately what pre-alpha Dagon can actually surface today.

<Warning>
  **Pre-alpha caveat.** Dagon is not currently registered as an ATS,
  MTF, or MiCA CASP. Nothing on this page is a statement that Dagon is
  legally obligated to produce these records today. The regulatory
  targets listed (Reg ATS, FINRA 4552, MiCA Art. 78) are the bars Dagon
  plans to meet when it registers in the relevant jurisdictions. Today
  the venue operates in a pre-registration, devnet posture.
</Warning>

## In-scope legal process

In the production posture, Dagon's operator is designed to respond to:

* US federal grand jury subpoenas (Fed. R. Crim. P. 17).
* US administrative subpoenas within counsel-confirmed authority
  (OFAC / 50 U.S.C. § 1705, FinCEN, SEC / CFTC where applicable).
* Mutual Legal Assistance requests routed through DOJ OIA or direct
  treaty.
* EU national-authority production orders implementing the European
  Investigation Order (Directive 2014/41/EU) and national
  transpositions.
* Court orders in US, EU Member States, UK, Switzerland.

Civil discovery and informal law-enforcement requests without a court
order are **out of scope**.

## Two-party composition (architectural, today)

Whatever the compelled process produces, it passes through the same
privacy boundary: the operator holds `session ↔ ephemeral-key` and the
credential issuer holds `credential ↔ PII`. Neither alone resolves a
user. Joined, they resolve **one named user** — not the book, not the
tape, not other users in those batches.

This property is structural and is in force on devnet today. See
[Two-party composition](/dagon/concepts/two-party-composition) for the
full shape.

## What pre-alpha Dagon can produce today

Scope limited to what actually exists in the current devnet build. If
an operator today were presented with a valid instrument and chose to
respond (remembering: no registration, no legal obligation), it could
surface:

* **Session metadata.** Per-session establishment timestamp, source IP
  (raw and hashed), geofence verdict, OFAC-screen verdict, credential
  hash and issuer identifier, revocation status at session time.
* **Raw ciphertext material.** On-chain ciphertexts by session keypair
  commitment and timestamp range. Not useful without decryption — see
  the decryption note below.
* **Governance records.** Already public on Solana; curated export with
  block-height citations.
* **Decryption of specific ciphertexts (pre-alpha only).** Today a
  single operator holds the decryption key, so decrypting a named
  ciphertext is physically possible. In production this is replaced by
  a threshold-committee quorum (see below), and no single operator
  will hold unilateral decrypt authority.

## What the production posture adds

The production posture targets the Reg ATS / FINRA 4552 / MiCA Art. 78
bar. The items below are **design-hook-present but not shipped**;
they land across M8 before Dagon would register in any jurisdiction.

* **Attested execution receipts.** Signed `(graph_hash, input_hash,
  output_hash, batch_id, executor_pubkey, signature)` per match,
  chained back to the attestation root. No plaintext order content.
  *Status: open (ADR-008).*
* **Sequencer ordering proofs.** Per-batch ordering records,
  content-independent. *Status: committee stub (M8).*
* **Post-trade tape.** Post-LIS-delay records in FINRA 4552 / MiCA
  Art. 78 format: timestamp, venue MIC, asset pair, notional, side,
  settlement tx hash, counterparty LEI where applicable. *Status:
  NDJSON tape scaffolded; format sign-off + APA pipeline + LEI/MIC
  assignment pending.*
* **Threshold-committee decryption under warrant.** A quorum of the
  threshold-FHE committee authorizes decryption of specific
  ciphertexts the instrument names. The operator can no longer decrypt
  unilaterally. *Status: design in place; production primitive gated
  on Encrypt REFHE threshold network.*

None of these are legal requirements on pre-alpha Dagon. They are
acceptance criteria Dagon must clear to register.

## What the operator does not hold, in any state

Regardless of pre-alpha or production:

* The user's KYC/KYB PII. That's held by the credential issuer, under
  its own regulatory regime.
* Plaintext order content outside whatever the decrypt path surfaces.
  The operator sees ciphertext in, ciphertext out.
* Any information the user kept client-side (balances, fill detail
  client-decrypt) — matching never decrypts.

## The issuer side

Separately, the credential issuer is served. The issuer produces:

* The KYC/KYB package tied to the specific credential (named by hash).
* The credential ↔ PII mapping for the named user or credential.

The issuer holds **only** this data, under the issuer's own
jurisdictional data-protection regime (GDPR for EU-based issuers,
state privacy laws for US-based issuers). The issuer does not know
what the user did on Dagon — it was not told.

## Joining the two sides

An authorized recipient (court, prosecutor, counsel, or an independent
forensic process) joins:

* Operator's `session → ephemeral-key` + `credential hash` records.
* Issuer's `credential hash → PII` mapping.

Joined via the credential verifier proof, this resolves **one specific
user's activity**. This shape holds on pre-alpha devnet; production
strengthens it by removing unilateral decrypt authority from the
operator.

## Edge cases

### One party refuses

If the operator complies but the issuer refuses (or vice versa), the
composition collapses and no identity resolves. The process is only
effective when both parties comply.

### Operator is breached post-hoc

An attacker who later steals the operator's session-metadata database
gets hashed IPs and ephemeral public keys. They do not get names. A
second breach of the issuer is required to de-anonymize.

### Foreign court order

A foreign court must route through MLAT to compel US-incorporated
parties (or vice versa). This is slower and subject to the MLAT's own
probable-cause standards. Dagon does not block MLAT; Dagon does not
accelerate it either.

### Compelled decryption of a batch (production)

A court may compel the committee to decrypt a specific batch's
ciphertexts. The committee quorum can do so once the threshold-FHE
committee ships. The batch's *other* participants remain shielded in
the same response — the instrument must name the user(s) whose
decryption is authorized. Today, a single operator holds the
decryption key; this concentration is what production explicitly
removes.

### A user claims they aren't the one named

The credential ↔ PII binding is signed at issuance by the user.
Standard KYC-grade identity verification applies. This is identical to
the KYC surface at any regulated CASP; Dagon does not improve or
weaken it.

## Timing bounds (production target)

These are targets for the production operator org, not claims about
pre-alpha:

* Operator intake: 4 business hours.
* Operator production: 48 hours for the pillars above.
* Issuer production: depends on the issuer's own SLA.
* Two-party response overall: limited by the slower of the two.
* Committee decryption (production): adds a quorum round.

Pre-alpha Dagon has no CCO, no intake SLA, and no counsel pipeline.
Any response today is ad-hoc.

## How the user deposits and withdraws — and why that's relevant

Dagon is non-custodial. Users hold their own keys; deposits and
withdrawals are on-chain Solana transactions initiated by the user.
Matching never decrypts. Decryption happens only on user-controlled
withdrawal and on the user's client-side balance view.

Under compelled process, the operator cannot move user funds and has
no mechanism to compel a user to withdraw. The most a legal process
against the operator and issuer can surface is historical activity;
future user actions remain under the user's own signing authority.

## Further reading

* [Two-party composition](/dagon/concepts/two-party-composition)
* [Selective disclosure by design](/dagon/concepts/selective-disclosure)