> ## 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.
# Is Dagon decentralized?
> Partially. 'Decentralized' is a gradient, not a binary. Here's where Dagon sits on each axis.
> **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.
**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.
**"Operator" pre-alpha vs production.** Pages that describe a single "operator" cranking batches, holding liveness, or acting as a single point of failure describe today's pre-alpha implementation. In production, operator duties are performed by the **decentralized FHE cluster** (Encrypt REFHE threshold network) — any quorum can crank, no single entity can stall the venue, and liveness is shared across independent nodes. "Operator" survives as a conceptual role, not a single entity.
"Decentralized" is a gradient across at least five axes. Calling
anything "a DEX" or "not a DEX" flattens it in a way that usually
misleads. Here's where Dagon actually sits.
| Axis | Position (today) | Target end-state | Note |
| ---------------- | ------------------------------- | ----------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Custody | **Decentralized** | Same | Non-custodial. Users hold their own keys. No operator-held vault. |
| Settlement | **Decentralized** | Same | On-chain on Solana. Balance updates are public Solana transactions. |
| Matching | **Single operator (pre-alpha)** | **Decentralized FHE committee (threshold FHE)** | One operator runs the FHE executor today. The design is compatible with a multi-party threshold-FHE committee where no single party holds enough key material to decrypt. Gated on Encrypt REFHE shipping production threshold decryption. |
| Identity gate | **Named issuer** | **Federated issuers** | A credential issuer KYCs users and attests eligibility. Multiple jurisdictionally-separated issuers are on the roadmap; users choose which they trust for KYC. |
| Listing / access | **Permissioned** | Same | Credential required to submit. No fully anonymous deposits — load-bearing for the non-mixer legal posture. |
## Why this shape
Each axis solves a different problem:
* **Custody decentralized** → no honeypot for attackers; no trust assumption on the operator for funds.
* **Settlement decentralized** → auditable balance updates; no operator can silently rewrite history.
* **Matching blind today, committee-ready by design** → the matching circuit runs over ciphertexts that nobody executing it can decrypt. Today that's one operator (pre-alpha); the target is a threshold-FHE committee where a quorum of independent parties holds key shares and no single party alone can decrypt. Liveness depends on whoever is cranking — one operator today, the committee tomorrow.
* **Identity gate centralized (for now)** → someone has to do KYC for compliance. Separating this from the matching operator creates the two-party composition. A federation of issuers is the target so users in different jurisdictions can pick a credential issuer they trust.
* **Permissioned access** → necessary for the legal posture. A fully permissionless venue would be a mixer (see [Is this a mixer?](/dagon/faq/is-this-a-mixer)).
## Why call it a "decentralized exchange" at all
Because on two load-bearing axes (custody, settlement), it genuinely is.
Users keep their keys; balances live on-chain. The "decentralized"
label honors that. We describe Dagon as a **decentralized confidential
matching venue**, not a "dark pool." Dark pools imply CEX-operated
internalization; Dagon's matching runs on ciphertext inside an
operator-blind execution environment, with a committee-decentralized
end-state on the roadmap.
"Decentralized" alone imports AMM assumptions (permissionless listing,
no operator, MEV surface) that are false here. "Confidential matching
venue" names what it actually is: a credentialed, encrypted, batch-
clearing mechanism with non-custodial settlement.
## What this means for trust
You trust the operator to:
* Run the FHE circuit correctly.
* Crank batches in a timely manner.
* Not censor your submissions.
* Respond to compelled process honestly.
You do **not** trust the operator to:
* Keep your funds safe (they never hold them).
* Keep your orders secret from itself (it cannot decrypt them).
* Refrain from front-running you (it cannot see the order).
You trust the issuer to:
* KYC users faithfully.
* Respond to compelled process honestly.
* Not collude with the operator to de-anonymize users.
You do **not** trust the issuer to:
* Know anything about your trade activity (it doesn't).
## Further reading
* [What Dagon is not](/dagon/what-dagon-is-not)
* [Two-party composition](/dagon/concepts/two-party-composition)