Executive Summary
JIL Sovereign's AMM v5 governance module splits control over live trading parameters into three cryptographically distinct authority types, each with a permission set matched to how fast and how consequentially it needs to act. Autonomous rule-based authorities react instantly to pre-audited on-ledger conditions; a risk-engine authority issues signed, time-to-live-bound actions that can adjust spreads, batch caps, and entity throttles but cannot halt the market or touch keys; and human governance, requiring multiple independently verified signatures, is the only tier that can enter or exit a full market halt, rotate risk-engine keys, or change the hard parameter bounds themselves.
No tier can silently exceed hard-coded limits: every parameter change from any tier is checked against a shared ParameterBounds structure, and only a full governance multisig action can move those bounds. Risk-engine actions additionally expire automatically - every action carries its own TTL and is rejected outright if submitted without one.
Problem Statement
An AMM that concentrates spread-adjustment, throttling, and emergency-halt power in a single administrative key faces an unavoidable tradeoff: either the key requires human sign-off for every routine adjustment, which is too slow to matter during a fast-moving stress event, or it is automated end-to-end, which means a single compromised or malfunctioning signer can also halt the market or drain risk controls.
Why a Single-Key Model Falls Short
- Fully manual control: Cannot react at the speed a live stress event requires; every parameter tweak waits on human multisig latency.
- Fully automated control: Grants a single compromised key the power to halt trading or grant itself unlimited authority - no separation between "adaptive" and "existential" actions.
- Unbounded automated actions: Even a well-intentioned automated system without hard parameter bounds can misconfigure itself into an economically absurd state.
Technical Architecture
Authority Permission Matrix
| Permission | Autonomous | Risk Engine | Governance |
|---|---|---|---|
| Adjust spreads | Yes | Yes | No |
| Adjust batch caps | Yes | Yes | No |
| Throttle entities/clusters | No | Yes | No |
| Change pair mode | Yes | Yes | No |
| Halt market | Yes (rule-based) | No | Yes |
| Resume from halt | No | No | Yes |
| Rotate keys / update bounds | No | No | Yes |
Hard Parameter Bounds (No Tier May Exceed)
| Parameter | Bound |
|---|---|
| Spread | 1 - 500 basis points |
| Batch cap | $100 - $10,000,000 |
| Throttle TTL | Up to 7 days |
| RFQ bond | $0 - $100,000 |
| Withdrawal cap | 1% - 100% of vault assets per epoch |
Cryptographic Enforcement
Risk-engine actions are structured records carrying an engine ID, engine and model version, a signature, a creation time, and an explicit expiry; submission is rejected if the issuing authority is unknown, revoked, or of the wrong type, if the TTL exceeds the governed maximum, or if any requested parameter falls outside its hard bound. Governance actions require a threshold number of independently verified Ed25519 signatures over the specific action ID before they can execute, and even an approved action executes only the specific, named change it was signed for - there is no generic "admin override" path.
Prior Art Differentiation
| Approach | Tiers | Self-Expiring Actions? | Hard Bounds? |
|---|---|---|---|
| Single admin key / EOA | 1 | No | No |
| Timelock-only governance | 1 (delayed) | No | Not inherent |
| Multisig-only for all actions | 1 | No | Not inherent |
| JIL Sovereign | 3, permission-scoped | Yes - risk-engine tier | Yes - all tiers |