Skip to main content

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

​
”MEV isn’t closed. Epoch boundaries are observable.”

Correct. Uniform clearing eliminates MEV inside a batch — no arrival order, no last-look, no sandwich. But batch boundaries are observable:
  • The crank transaction is public on Solana.
  • Vector sizes (participant counts) are plaintext.
  • The act of submitting to a batch is visible to validators.
Possible MEV vectors that remain:
  • Epoch-boundary sniping: submit very late in the window to react to earlier submissions. Mitigation: any late submission is itself subject to the same uniform clearing, so the edge is bounded by the sub-epoch time between a submission landing and the close.
  • Composition inference: observing that N ciphertexts entered a batch reveals aggregate activity. Individual curves remain private, but demand intensity is not a secret.
  • Cross-venue arbitrage: hedging a Dagon fill on a public CEX makes the hedge visible. Your downstream route is your choice; we don’t encrypt it.
concern-23 (randomized batch length) and concern-24 (timing-hardened submission) are tracked in our product repo as open items.

​
”FHE is slow and pre-alpha.”

Correct and acknowledged. Today’s devnet runs a mock Encrypt executor with plaintext fallback for integration testing. Production mainnet is gated on the Encrypt REFHE network shipping production FHE. Expected production latency (per Encrypt’s internal targets, subject to change): batch close to clearing-price emergence ~3–8s for a 32-lane vector. This is slow for HFT (obviously) and acceptable for block execution where impact > latency. If Encrypt REFHE slips past end-of-2026, Dagon’s stack pivots — likely to gMPC substrate. This is a live kill criterion.

​
”Metadata leaks even if orders are encrypted.”

Real concern. Possible leakage vectors we track:
  • Submission timing: when a user submits reveals something about their strategy. Mitigation: VRF-jittered batch close (planned, not shipped).
  • Vector size changes between batches: reveals demand intensity trends. Accepted by design; not considered a load-bearing privacy failure because it reveals aggregates, not individuals.
  • Vault deltas: post-settlement, per-lane vault changes are public. An observer with enough context can correlate a lane’s delta pattern with an external-chain hedge. Mitigation: lane-to-user binding is session-scoped and ephemeral; cross-session correlation requires operator-held session map, which is only disclosable via compelled process to both parties.
An ML model trained on enough metadata (lane delta patterns + public Pyth prices + external hedge patterns) could achieve partial de-anonymization with non-trivial confidence. We do not claim that the vault-delta tape is perfectly unlinkable. We claim that the identity-resolving key (credential → PII) is held by a separate party and requires compelled process to produce.

​
”Operator liveness is a single point of failure.”

Correct. If the operator stops cranking batches, submitted schedules sit in escrow and cannot settle. Users’ capital is never at risk (it’s still in their own vault), but their orders don’t clear until the operator recovers or a replacement operator is appointed. This is an availability concern, not an integrity one. The operator cannot drain user funds (non-custodial). The operator can only stall. Planned mitigations:
  • Permissionless crank fallback after a timeout (operator serves first; anyone can crank after N slots).
  • Multi-operator rotation (requires more design work).

​
”FHE committees / key holders are a new trust surface.”

Dagon’s cryptographic invariant depends on the Encrypt REFHE network’s threshold decryption committee. If a threshold of the committee colludes or is compromised, they can decrypt ciphertexts they are not supposed to. The threshold assumption is public. The committee membership is public. The slashing conditions are public. Whether the committee is honest in practice is a trust-the-network question — analogous to trusting Ethereum’s validator set at its current decentralization level.

​
”Vault accounting leaks order-flow density.”

Correct. The per-batch notional settled is observable (sum of vault deltas = sum of matched notional). An attacker watching batch-by-batch notional can infer whether demand is rising or falling. This is aggregate-level leakage, not user-level. We accept it by design; eliminating it would require hiding settlement, which would hide the property that makes the system non-custodial and auditable.

​
”Walrasian is the wrong term. You’re running bisection tâtonnement.”

Fair. “Symmetric Walrasian clearing” is the outcome (one clearing price, both sides, uniform); “bisection tâtonnement” is the algorithm that finds it. Marketing uses the outcome name because it is more interpretable; technical docs use the algorithm name because it is more precise. We try to use both where appropriate. See batch clearing for the mechanism.

​
Further reading