> For the complete documentation index, see [llms.txt](https://agentdex.gitbook.io/agentdex-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://agentdex.gitbook.io/agentdex-docs/under-the-hood/validator-and-verifiability.md).

# Validator and verifiability

AgentDex today is a centralised operator running an off-chain matching engine with on-chain custody. The framing as a deterministic state machine ([State machine](broken://spaces/aCY4JwuHvGKtRcc70Q10/pages/a1e6a0ee9f6d5d23e7262b20698fb098588a68b3)) is a target, not a present-day guarantee. This page draws the line honestly: what a third party can verify *now*, and what comes online stage by stage.

### Where we are today

<table><thead><tr><th width="358.8203125">Aspect</th><th>Today</th></tr></thead><tbody><tr><td>Custody of funds</td><td>On-chain in BridgeUpgradeable (<a href="/spaces/aCY4JwuHvGKtRcc70Q10/pages/4b9b7a70e5fc5d2f02f928071debc369f181680a">Smart contracts</a>).</td></tr><tr><td>Matching, PnL, margin, liquidations, funding</td><td>Off-chain in the matching engine.</td></tr><tr><td>Operator authority</td><td>Treasury key signs balance updates and finalises withdrawals.</td></tr><tr><td>Escape hatch</td><td>Force withdrawal after a 1–14 day timelock (default 7).</td></tr><tr><td>State commitment on L1</td><td><strong>Not implemented.</strong></td></tr><tr><td>Fraud or validity proofs</td><td><strong>Not implemented.</strong></td></tr><tr><td>Canonical log publication</td><td><strong>Not implemented.</strong></td></tr><tr><td>Reference implementation (validator)</td><td><strong>Not implemented.</strong></td></tr></tbody></table>

So today's trust model is: *operator-authoritative, with a structural escape hatch on custody*. We don't try to dress that up as something it isn't.

{% hint style="warning" %}
Today the trust model is operator-authoritative, with a structural escape hatch on custody.
{% endhint %}

### What you can verify today

Limited but non-trivial:

* **On-chain bridge state.** Every deposit, withdrawal request, finalization, cancellation, force withdrawal, and balance-update batch is an on-chain event. Anyone can read the bridge contract and reconstruct the on-chain custody history.
* **The mark-price construction parameters.** The η bound and the component aggregation are part of the protocol spec — they are knowable a priori.
* **The off-chain engine's effect stream**, indirectly. Every API and WebSocket consumer reads the same effect stream. Fills, liquidations, funding payments are all attested in the events you receive.

What you cannot verify today:

* That the engine's internal application of operations to state matches what you'd derive from the apply function (no reference implementation yet).
* That the order of operations in the engine matches what was actually submitted (no public canonical log yet).
* That the operator-controlled `updateAvailableBalance` calls reflect the engine's authoritative balances (no on-chain proof, just a record).

### The four-phase plan

The roadmap to a fully verifiable system is in [Roadmap](/agentdex-docs/under-the-hood/roadmap.md). The verifiability dimension specifically moves through:

#### Phase 1 — Unverified Data

Map engine events into structured blocks and transactions; write to an internal store. The data format is fixed; correctness is not yet validated externally. Positioned honestly as **unverified**.

#### Phase 2 — Explorer + sequencer infra

A read-only explorer surfaces the internal blocks and transactions for transparency. Sequencer optimisation and internal SDK in parallel. Still unverified — the explorer reads our internal store.

#### Phase 3 — Validator (reference implementation)

The protocol team writes a clean, deterministic re-implementation of the trading logic — slow, but correct. Runs in dry-run against historical engine data; discrepancies logged. **This codebase is the future engine, not a separate artefact.** It evolves into Phase 5.

#### Phase 4 — Publishing & disclosure

The validator becomes useful externally:

* **Rollup publication** — blocks published to a blob layer (or alternative). The canonical log is now external.
* **Validator + libraries open-sourced** — any third party can run the reference implementation against the public log and verify state.
* **Explorer migrated** to read from the published public data, not our internal store.

After Phase 4, **independent verification is possible**. You can hold a copy of the public log and reproduce state.

#### Phase 5 — Production core

The validator is hardened for production load and replaces the legacy engine. A backwards-compatibility adapter keeps old integrations working. Canary deployment alongside the legacy engine; postmortem comparisons until cutover.

After Phase 5, the gap between "what you'd derive from the spec" and "what the engine does" closes. The system is then ready for decentralised sequencer / consensus work — but that's beyond this roadmap.

### Security boundaries to be aware of

| Boundary                  | How it's protected today                                                                               |
| ------------------------- | ------------------------------------------------------------------------------------------------------ |
| Custody                   | Funds in the Bridge contract; Treasury can't transfer arbitrary user funds out.                        |
| Operator outage           | Force withdrawal after the timelock window.                                                            |
| Operator misconfiguration | UUPS upgradeability under Owner key; concrete multisig and timelock policy on upgrades is TBD.         |
| Stale price feeds         | Engine emergency mode after 5 min of stale index ([Mark price](/agentdex-docs/trading/mark-price.md)). |
| Engine correctness        | **No third-party verification today.** Internal review, audits, and the validator phase.               |

See [Risks](/agentdex-docs/reference/risks.md) for the user-facing risk inventory.

### What you can do, today, to limit operator trust

* **Withdraw frequently.** Custody is on-chain; idle balance has no benefit beyond traded collateral.
* **Use per-key limits.** A bounded agent mandate ([API keys](/agentdex-docs/developers/api-keys.md)) limits how much of your collateral is at risk under any single failure mode.
* **Monitor on-chain events.** Subscribe to the bridge contract's events; you don't have to trust the UI for your custody-side history.
* **Watch the force-withdrawal timer.** If `updatedAt` on the bridge stops progressing while you have a pending withdrawal, the engine is silent and the timer is running.

The honest claim: AgentDex today is trustworthy if you trust this operator and this code. It will be **verifiable without trust** when Phase 4 lands.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://agentdex.gitbook.io/agentdex-docs/under-the-hood/validator-and-verifiability.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.