CERBERUSProtocol documentation.
An introduction to the design of Cerberus: execution and simulation infrastructure for automated trading systems, bots and autonomous agents.
Overview
Cerberus is designed to provide programmable trading infrastructure across Elysium and Hyperliquid. The intended first users are Cerberus trading bots, followed by third-party developers and autonomous trading applications.
The current app supports paper bots, policy checks, durable execution records and read-only network previews. Public live trading is disabled. The homepage playground uses illustrative estimates; it does not send real orders.
Protocol architecture
The pipeline separates trade preview, authorization and execution into three components. An intent should progress only when the preceding checks permit it.
Simulation produces a transaction preview. Guardian evaluates whether an action is permitted under the configured policies. Execution handles authorized actions and their lifecycle. The public app applies this flow to paper execution. Observed Hyperliquid accounts remain separate from paper balances and grant no signing authority.
Scroll to view all columns →
| Component | Responsibility | Intended output |
|---|---|---|
| Simulation | Preview costs, slippage and potential failures | Transaction preview |
| Guardian | Evaluate permissions and configured limits | Authorized or rejected action |
| Execution | Submit and monitor approved actions | Execution status and records |
Simulation
The Simulation component is intended to preview a proposed trade before submission, estimate its costs and slippage, and identify potential execution failures.
A preview is an estimate at a point in time. Market state can change before execution. Simulation is not a guarantee of execution price, successful settlement or trading performance.
In the interactive example
The approved scenario uses a fixed 0.12% slippage estimate against a 0.50% configured limit. The high-slippage scenario uses a fixed 1.20% estimate and stops before submission. These numbers are educational examples and do not come from an order book.
Guardian
Guardian is designed to apply transaction authorization rules: allowed assets, trading limits and permissions associated with an automated system.
- Check whether the requested asset is approved.
- Evaluate the action against configured trading limits.
- Allow only authorized operations to proceed to execution.
Enforceable controls require a constrained authorization path. A bot with unrestricted credentials could bypass an external policy check. The custody model, signing permissions and enforcement mechanism must be specified and tested before production use.
In the interactive example
The restricted-asset scenario passes the illustrative simulation but is rejected by Guardian because its asset is not on the approved list.
Execution
The current Execution component records authorized paper orders, tracks their outcomes and reconciles uncertain results. Live exchange submission is disabled in the public app.
Submission and confirmed completion are different states. Production execution must track that distinction, reconcile uncertain outcomes and prevent retries from unintentionally duplicating a trade. The public app does not provision signing authority or submit live exchange orders.
The homepage example stops at an illustrative submission event. It does not connect to a wallet, submit an order or demonstrate actual network latency.
Development direction
The current release provides paper execution and read-only network tools. The stages below describe the broader development direction. Public live trading has no announced release date.
01 / Internal systems
Build the execution pipeline, simulation and permission controls. Validate them with internal bots, tests and execution monitoring.
02 / Developer access
Prepare integration interfaces, implementation documentation and controlled testing with external applications.
03 / Public integrations
Extend access to third-party trading bots and autonomous applications as the protocol matures.
Network context
Cerberus targets Elysium and the Hyperliquid ecosystem. The app reads Hyperliquid account and market data and prepares EVM call previews. Its Elysium tools prepare unsigned registry transactions and verify supplied transaction hashes against network evidence. The app does not sign or broadcast these transactions. See the official Elysium documentation ↗ for network-specific information.
Cerberus token
The token’s utility, launch mechanics and verified contract address are not finalized in this overview. This documentation does not announce staking, governance, fee sharing or buybacks.
Confirmed token information will be added here and on the homepage.