> 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/reference/risks.md).

# Risks

Trading perpetual futures on AgentDex carries both **market risks** (intrinsic to leveraged trading) and **operational / protocol risks** (specific to this venue's current architecture). This page is the honest inventory. The goal is for an informed user to know exactly what trust assumptions they are taking on.

{% hint style="warning" %}
This page covers both market risk and current operator / protocol risk.
{% endhint %}

### See also

* [Validator and verifiability](/agentdex-docs/under-the-hood/validator-and-verifiability.md)
* [Smart contracts](/agentdex-docs/under-the-hood/smart-contracts.md)
* [FAQ](/agentdex-docs/reference/faq.md)

### Market risks

These exist on every perpetual venue.

* **Leveraged loss.** A 10× position can lose its full margin on a 10 % adverse move (less in practice, factoring in fees and the maintenance margin buffer). Liquidations are evaluated against mark price, which can move faster than the visible last-traded price.
* **Auto-deleveraging (ADL).** If the insurance fund cannot cover a bankrupt position's deficit, the engine closes the most-profitable counter-side positions at bankruptcy price. Your profit can be cut short to keep the system solvent.
* **Funding cost.** In a sustained directional market, funding payments can be the dominant cost of holding a position. A 0.1 % hourly rate compounds to roughly 10 % a month.
* **Mark-vs-last divergence.** Mark price is a median of fair, SMA, and last-trade. In low-liquidity moments the median can sit away from the last-traded price, producing unrealised PnL swings that aren't visible on the chart.

### Operational / protocol risks

These are specific to AgentDex today. The roadmap addresses several of them ([Roadmap](/agentdex-docs/under-the-hood/roadmap.md)); we surface them now because users should know the current state.

#### Operator trust

* The Treasury private key authorises bridge balance updates and finalises withdrawals.
* There are no on-chain fraud proofs or state commitments today.
* A compromised or misbehaving Treasury could push incorrect balance updates, subject to the force-withdrawal escape hatch.

#### Force-withdrawal timelock

* Default 7 days, configurable 1–14.
* Every Treasury `updateAvailableBalance` call refreshes the timer. The escape hatch only opens if the off-chain engine is **fully silent** for the full window.
* This means in a partial-outage scenario where the engine continues to push balance updates but stops processing your withdrawals, the escape hatch doesn't help. Mitigation: file a support ticket and monitor `updatedAt` on the bridge.

#### Upgradeability and Owner powers

* BridgeUpgradeable is UUPS-upgradeable. The Owner key can replace the implementation contract.
* The Owner can also swap the Treasury operator at any time, with no on-contract timelock, via `changeTreasury`. Concrete custody / multisig / announcement policy on the Owner role is **TBD** — see [Smart contracts](/agentdex-docs/under-the-hood/smart-contracts.md).
* A global `pause()` is available to Owner — blocks deposits, withdrawals, and Treasury finalisations. Sensible safety mechanism, but means Owner availability is a liveness assumption.
* Until concrete policy is published, treat upgrades and Treasury swaps as Owner-discretionary.

#### Stale price feeds

* Mark price is built from external venue quotes polled every 10 seconds.
* If the index-price aggregator goes silent, the engine enters **Emergency Mode** after roughly 5–6 minutes. Until then, mark price is frozen.
* During the 5–6 minute window: liquidations may not trigger when they should, new orders accept with stale-mark margin checks, and the slim possibility exists for opportunistic trades to lock in benefits against stale state.
* In Emergency Mode: new orders rejected (`IN_EMERGENCY_MODE`), withdrawals halted, liquidator paused. Recovery resumes operations.

#### Engine non-determinism

* The current engine is a complex piece of software with no third-party reference implementation to check it against.
* The validator phase ([Validator and verifiability](/agentdex-docs/under-the-hood/validator-and-verifiability.md)) exists precisely to address this.

#### Message reliability

* Kafka and Redis can lose messages under failure scenarios.
* Mitigations exist (retries, idempotency, reconciliation) but are not yet formally proven.
* A subtle inconsistency between engine and off-chain bookkeeping is theoretically possible, though the system is designed to detect and reconcile.

#### Known code-level limitations

| Limitation                                  | Status                                         |
| ------------------------------------------- | ---------------------------------------------- |
| Deflationary / fee-on-transfer ERC-20s      | Not supported; will mis-account.               |
| `WithdrawalCancelled` event                 | Logged on-chain; not handled by state-service. |
| Native-token deposit path                   | Incomplete; don't send.                        |
| Out-of-order `WithdrawalFinalized` messages | Silently dropped.                              |

Full list in [Smart contracts](/agentdex-docs/under-the-hood/smart-contracts.md).

### Agent-specific risks

You're handing trading authority to a non-deterministic LLM. Specific failure modes:

* **Misinterpreting an instruction**, e.g. opening a long when you asked for a hedge.
* **Tool-call loops** — repeated calls in pathological prompts. Rate limits cap blast radius.
* **Prompt injection** — if the agent reads external content (web, files), an attacker can try to make it issue trades.
* **Wallet-level exfiltration is impossible** — the agent only has the MCP key, not your wallet. The worst case is constrained to the trading limits on that key.

Mitigations:

* **Tight per-key limits.** Instrument allowlist, leverage range, order-size range. See [API keys](/agentdex-docs/developers/api-keys.md).
* **One key per agent.** Revoke without affecting other workflows.
* **Monitor.** WebSocket private topics stream fills and position events; alert on unexpected activity.

### Practical mitigations users can take

* Use only what you can afford to lose, especially during dev / beta phases.
* Withdraw frequently. Custody is on-chain; idle balance has no operational benefit.
* Use per-key trading limits ([API keys](/agentdex-docs/developers/api-keys.md)) to constrain bot blast radius.
* Watch the bug-bounty and audit pages; we'll publish links here when they go live.

### Audit status

#### Internal security review (complete)

An internal Phase 1 security review of the bridge contracts has been completed. Headline conclusions:

* The bridge design is **workable as an early trusted-operator bridge**, not production-ready for material user funds without further hardening.
* Highest-severity finding: accepted withdrawals do **not** reduce on-chain `available`. The bridge's internal accounting is therefore overstated until the next Treasury `updateAvailableBalance` reconciles. The protocol team has acknowledged this as intentional — the off-chain engine is the source of truth; the bridge's accounting is restored on the next sync. The real-world consequence: a user can submit withdrawal requests exceeding their actual balance; the engine rejects them. Funds cannot be double-spent against the contract.
* Other findings concern weaker on-contract status validation, partially-implemented native-token support, and the broad recommendation to move toward proof-based or independently-verifiable balance updates.
* Treasury trust assumptions are central: honest finalization, honest cancellations, correct balance pushes. We do not yet have on-chain proofs of any of these.

#### Third-party audit (complete)

A formal third-party security audit of the bridge contracts was completed by **Decurity** (audit period 18–22 May 2026; finding statuses as of 3 June 2026). The full report is published on this page.

| Finding                                                            | Severity | Status            |
| ------------------------------------------------------------------ | -------- | ----------------- |
| `removeToken` traps already-deposited funds of a delisted token    | Medium   | Fixed & re-tested |
| `pause()` disables the `forceWithdrawal` escape hatch              | Low      | Fixed & re-tested |
| Token can become unsupported after a withdrawal request is created | Info     | Fixed             |
| USDC-style fee-on-transfer switch can be flipped post-listing      | Info     | Fixed             |

All four findings were remediated and the fixes re-tested in the course of the engagement. The two most material to user fund recovery — the delisting fund-trap (Medium) and the `pause()`-vs-`forceWithdrawal` interaction (Low) — are both resolved.

For agent-specific risks (your agent acting against your intent), see the patterns recommended in [MCP server](/agentdex-docs/developers/mcp-server.md).

A public bug-bounty program is planned now that the first third-party audit has closed.

### What this page does not do

We don't surface internal attack vectors or exploit details that aren't already public. The internal vulnerability tracker is shared with auditors and remediated under a coordinated disclosure window; coordinated disclosures will be published on this page after fixes ship.


---

# 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/reference/risks.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.