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

# Technical objections

> MEV surface, metadata leakage, FHE pragmatism, timing attacks, committee liveness. What's strong, what's weak, what's open.

> **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>
  **"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.
</Info>

## "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](/dagon/concepts/batch-clearing) for the mechanism.

## Further reading

* [Batch clearing](/dagon/concepts/batch-clearing)
* [Confidential matching](/dagon/concepts/confidential-matching)