Bounded authority for
autonomous trading.

Abstract

Two problems in retail trading have the same shape. Individuals execute their own plans badly under pressure, and the empirical record on this is unambiguous[1][2]. And language models, which do not execute badly under pressure, cannot safely be given the authority required to trade, because the standard way to grant that authority — hand the model an API key — grants everything at once and leaves no layer between the model's output and the exchange that can refuse.

OPPEN separates three things that are normally fused: cognition, authority, and custody. The agent reasons. A deterministic Rust core decides what is permitted. Keys never leave the operator's machine, and the key used to sign the agent's orders has no withdrawal authority at the venue[6][7]. Guardrails — symbol allowlist, notional caps, order rate, maximum slippage, loss circuit breaker — are evaluated in the instruction immediately preceding signature, in code the model cannot reach, read around, or persuade. Every decision, execution, and refusal is written to an append-only ledger surfaced in an operator console with a single kill switch.

v1 targets Hyperliquid. That choice is not incidental to the architecture: on-chain perpetual venues are the first execution venues in which bounded delegation to software is a protocol primitive rather than a vendor policy, and they are the fastest-growing segment of the derivatives market[8]. Section 3 makes that argument in full.

The design assumption is adversarial. Assume the agent will at some point be wrong, jailbroken, or injected. The system's job is to make the worst outcome of that a bounded, attributable, fully logged loss rather than an open-ended one.

The human execution problem

Before the delegation problem, there is the problem delegation is meant to solve.

The retail trader's difficulty is rarely that he cannot read a market. It is that the distance between the decision made in calm conditions and the action taken under pressure is large, variable, and unmeasured. Barber and Odean, examining 66,465 households at a discount broker between 1991 and 1996, found that the most active traders earned 11.4% annually against a market return of 17.9%, with turnover averaging 75% of the portfolio per year; their conclusion was that overconfidence drives excessive trading and that active trading imposes a severe performance penalty[1].

The result is worse at higher frequency. Chague, De-Losso and Giovannetti tracked every individual who began day trading Brazilian mini-Ibovespa futures between 2013 and 2015. Of the 1,551 who persisted beyond 300 trading days, 97% lost money net of fees. Only 1.1% earned more than the Brazilian minimum wage, and only 0.5% more than a bank teller's starting salary — both with severe risk. The authors found no evidence of learning[2].

These are not analysis failures. They are execution failures with a behavioural cause, and they are structural rather than personal. Under a live drawdown the trader is operating with degraded working memory and a strong loss-aversion asymmetry. The professional does not out-feel the amateur; he is simply not permitted to act on feeling at the moment of execution, because his limits are enforced by systems and by a risk function that can flatten him without asking. That is the actual asymmetry between institutional and retail participation — architecture, not information.

A language model does not hold a position in its own ego. It does not size up after a loss, hold a loser to avoid realizing it, or move a stop at 03:00 because the drawdown is uncomfortable. This is not a claim that the model is a better analyst; most days it is not. It is a claim about variance. Net return is a function of the average execution, not the best one, and the model's execution distribution is narrow.

So the plan can now carry itself out. The remaining question is what else it carries out along the way.

The delegation problem

An operator who wants an agent to trade today chooses between two unsatisfying architectures.

Give the agent the keys. The model, or the harness around it, holds an exchange credential. This works, and it is what most people do. It also means the authority granted to the agent is exactly the authority of the account: every symbol, every size, every leverage setting, unlimited order rate, and in many configurations, withdrawal. There is no enforcement boundary because there is no boundary at all.

Use a hosted agent-trading service. The operator transfers custody or delegated authority to a third party in exchange for a UI and some risk controls. This substitutes a well-understood problem for a worse one: counterparty risk, opaque execution, no verifiable claim about what the limits actually do, and a service that can be compelled, breached, or discontinued. CoinGecko counted more than $2.4 billion in losses from exchange hacks and exploits in a thirteen-month window ending January 2026[8].

Both share a deeper defect. They treat risk limits either as configuration the model can see or as policy enforced by a party the operator does not control. Neither produces the property the operator actually wants:

Whatever the agent does, the loss is bounded by numbers I set, the funds cannot leave, and I can reconstruct exactly what happened.

2.1Why the usual mitigations do not suffice

System prompts and instructions. Instructions are inputs to a probabilistic process. They bias behaviour; they do not constrain it. Prompt injection has held the top position in the OWASP Top 10 for LLM Applications across both editions, and OWASP states plainly that because of the stochastic nature of these models it is unclear whether fool-proof prevention is possible at all[3]. The mechanism is structural: models process instructions and data through the same channel, with no reliable separation between them.

This matters more for a trading agent than for most applications, because a trading agent consumes adversarial input by construction. Greshake et al. demonstrated indirect prompt injection — payloads embedded in retrieved content rather than typed by a user — against real LLM-integrated applications, showing that an attacker with no direct interface to the system can nonetheless steer it[4]. An agent reading order books, funding data, news, social feeds, or token metadata is reading content that counterparties can author.

Tool-level validation in the agent harness. Better, but it usually lives in the same process and language runtime as the agent loop, written by the same person under the same assumptions. If the harness can be induced to construct a different call, the validation is bypassed rather than triggered. OWASP treats this as its own category — LLM06, Excessive Agency: the risk that an agent performs actions beyond its intended scope because its granted permissions exceed its actual need[3].

Exchange-side risk limits. Worth using, but coarse. Venues offer leverage caps and margin rules, not "this agent may trade three symbols, at most 40,000 notional, at most six orders per minute, and must stop for the day after a 2% drawdown."

A human approving every order. This works and eliminates the point of Section 1. Approval mode is a supported OPPEN mode, not the design centre.

Why on-chain perpetuals

OPPEN targets a perpetual DEX first, and this is a thesis rather than a convenience. The argument has four parts: the shift is real and measurable; on-chain venues have properties that make bounded delegation to software actually enforceable; the asset universe on these venues is no longer confined to crypto; and the markets never close, which makes human supervision structurally impossible rather than merely inconvenient.

3.1The shift is measurable

CoinGecko's 2026 CEX & DEX Trading Activity Report, covering January 2025 through January 2026, found that DEX share of perpetuals volume expanded roughly fivefold in two years, from about 2% in January 2024 to approximately 10% in January 2026, while total perpetuals volume across both venue types grew 75% to around $7.24 trillion. Spot DEX share nearly doubled over the same period, from 6.9% to 13.6%. Three DEXs — PancakeSwap, Uniswap and Hyperliquid — now rank among the top ten venues by spot and perpetuals volume[8].

A caution on figures. Third-party trackers report perpetual DEX share anywhere from 10% to 26% depending on whether they measure notional or adjusted volume, which venues they include, and how they treat incentive-driven and wash volume. This document uses CoinGecko's numbers as the anchor because the methodology is published, and readers should treat the higher figures circulating in market commentary with corresponding scepticism. The direction of travel is not in dispute; the exact level is.

What matters for this document is not the market-share race. It is that on-chain venues have crossed the threshold of liquidity and execution quality at which running a serious strategy there is a reasonable decision rather than an ideological one.

3.2Bounded delegation is a protocol primitive, not a vendor policy

This is the load-bearing argument, and it is the reason OPPEN exists on a DEX rather than a CEX.

On a centralized exchange, an API key's permissions are a row in the venue's database. What that key may do is defined by the venue's software, described in the venue's documentation, revocable at the venue's discretion, and unverifiable from outside. Delegation is a promise.

On Hyperliquid, the equivalent is a signed authorization with protocol-enforced properties. A master account approves an API wallet (also called an agent wallet) that can sign trading actions on behalf of the master account or its sub-accounts. The agent wallet holds no funds and cannot initiate withdrawals — this is enforced by the protocol, not by an application's good behaviour. Authorizations can carry an explicit expiry of up to 180 days. An account may hold one unnamed and up to three named API wallets, with two additional named agents per sub-account. Nonces are tracked per signer, so separate agents get separate nonce spaces, and the documentation recommends a separate API wallet per trading process and advises against reusing agent addresses[6][7].

Read that list as a security specification rather than an API reference. It describes, at the venue level: bounded capability, mandatory expiry, per-agent isolation, and independent replay protection per signer. These are exactly the primitives a supervision architecture needs, and on a CEX none of them exist as guarantees — only as features.

The same pattern governs economics. A builder fee is not a rate the application sets; it is a maximum rate the master wallet signs an approval for, after which the application cannot exceed it without a new signature[7]. Fee authority is bounded by the same mechanism as trading authority.

The consequence is quantifiable rather than rhetorical. The worst case of a fully compromised agent — key extracted, model jailbroken, harness rewritten — is trading loss within the guardrail envelope on the capital allocated to that sub-account. Not withdrawal. Not the master account. That property does not depend on OPPEN being correct; it depends on the protocol being correct, which is a considerably better place to put trust.

3.3Verifiable state

For an autonomous system, wrong state is more dangerous than a wrong opinion. An agent that believes it is flat when it is long will act on that belief without hesitation.

Public venues make state auditable. Order books, fills, funding payments, liquidations and open interest are observable rather than reported. Reconciliation can be checked against a public record instead of a private one, and an operator investigating a discrepancy is not dependent on a support ticket. Section 9 describes how OPPEN uses this.

3.4The asset universe is no longer crypto

The strongest argument that this is a market-structure shift rather than a crypto cycle is what these venues have started listing.

Hyperliquid's HIP-3 framework, live on mainnet since October 2025, permits builders meeting a staking requirement to deploy their own perpetual markets that settle on the shared infrastructure, with their own margining, order books, collateral choice and market parameters — moving listing from a curated process to a permissionless one[11]. In practice, deployers have used it to launch perpetuals on equities, indices, commodities and FX, alongside crypto[12].

Follow the implication. A perpetual contract requires an oracle and a settlement mechanism, not a listing committee, a clearing member, or a session calendar. Any asset with a reliable price feed can have one. The instrument is becoming a general wrapper for exposure to anything, on infrastructure that is programmable end to end.

That is the sense in which this is the next chapter rather than a niche. An architecture built for supervising autonomous agents on a permissionless, programmable, cryptographically-scoped venue is not a crypto architecture that happens to work. It is a template for how software will be permitted to act in markets generally, prototyped in the only venue class where the primitives currently exist.

3.5Markets that never close

Perpetual venues run continuously. There is no close, no settlement window, no session in which a human can reasonably be expected to be absent.

This is usually presented as a convenience. It is better understood as a constraint. A market that trades 24/7/365 cannot be supervised by a human at the point of execution, because humans sleep, and the failure mode of a leveraged position held through an unsupervised eight-hour window is not theoretical. Continuous markets do not merely permit autonomous execution — they select for it. The alternative is not careful manual trading; it is manual trading with gaps, which is worse than either extreme.

Note that this cuts against pure automation too. If the agent is unsupervised for eight hours, the enforcement layer has to hold without an operator present. That is the reasoning behind fail-closed evaluation and the dead-man switch in Section 7.

3.6What this does not fix

A whitepaper that only lists advantages is marketing. The on-chain venue class carries real risks, and OPPEN mitigates none of them.

Transparency is exploitable. Public positions, order sizes and liquidation levels are visible to counterparties as well as to the operator. This enables liquidation hunting and order anticipation strategies that are harder to run against opaque venues.

Oracle and collateral coupling. On 10 October 2025, roughly $19 billion in leveraged crypto positions were liquidated within 24 hours across venues, affecting more than 1.6 million traders — the largest deleveraging on record. Perpetual open interest contracted 43% to $123 billion, with a 57% drop on Hyperliquid specifically, and the stablecoin USDe depegged to $0.65 on one venue, triggering secondary liquidations[9]. Shared-collateral designs and venue-specific oracles acted as accelerants, and auto-deleveraging closed positions belonging to traders who were correctly positioned. An agent operating inside its guardrails can still be liquidated by a cascade it did not cause and could not have avoided.

Protocol and deployer risk. Permissionless market creation transfers parameter selection — oracle design, leverage limits, settlement behaviour — to deployers of varying quality. HIP-3 markets operate under isolated margin, which bounds the contagion, but diligence on the venue and the specific market remains the operator's responsibility.

Regulatory uncertainty. Perpetuals on equities, commodities and FX raise jurisdictional questions that are unsettled and moving. Nothing in this document is legal advice, and operators should assume the position of their jurisdiction may change.

The honest framing: on-chain venues offer better delegation primitives and worse tail behaviour than mature centralized venues. OPPEN is built for the first property and does not claim to solve the second. What it can do is ensure that when the tail arrives, the position size was one the operator chose and the record of what happened is complete.

Design principles

Local-first, no backend. OPPEN is a desktop application. There is no OPPEN server, no account, and no telemetry path carrying positions or keys. This is a security property before it is a philosophy: a system with no hosted component has no hosted component to breach, subpoena, or discontinue.

Capabilities, not credentials. The agent receives the ability to request actions, never the material required to perform them. The signing key is not reachable from the agent's context, not passed through the MCP transport, and not present in any tool result.

Enforcement below cognition. Guardrail evaluation is the last thing that happens before an order is signed, in the Rust core, over a fully constructed order object. The model cannot widen its own envelope and cannot construct an order that reaches the signer without passing the check.

Refusal is a normal outcome. A guardrail rejection is a structured return value with a machine-readable reason, an explanation the agent can reason about, and a ledger entry the operator can read. Systems that treat denial as an exception get denial handling that is untested; systems that treat it as a return type get agents that adapt.

Observability is the primary surface. The console's hero element is the activity stream — what the agent asked for, what was permitted, what was refused and why, what filled. Not an order ticket.

Isolation with attribution. One sub-account per agent, using the venue's own isolation primitives[6]. Each agent's positions, margin and PnL are separable at the venue, not just in OPPEN's bookkeeping.

Architecture

┌──────────────────────────────────────────────────────────────┐
│  Agent (Claude Code, or any MCP client)   — UNTRUSTED        │
│  Reasons, plans, requests. Holds no keys.                    │
└───────────────────────────┬──────────────────────────────────┘
                            │  MCP over local transport
┌───────────────────────────▼──────────────────────────────────┐
│  MCP Gateway              — SEMI-TRUSTED                     │
│  Capability surface, schema validation, session identity,    │
│  per-agent scoping. Translates intent → typed order object.  │
└───────────────────────────┬──────────────────────────────────┘
                            │  in-process, typed
┌───────────────────────────▼──────────────────────────────────┐
│  Rust core                — TRUSTED                          │
│                                                              │
│  ┌────────────┐  ┌─────────────┐  ┌───────────────────────┐  │
│  │ Guardrail  │→ │   Signer    │  │  Event ledger         │  │
│  │  engine    │  │ (keychain)  │  │  append-only          │  │
│  └────────────┘  └─────────────┘  └───────────────────────┘  │
│  ┌────────────┐  ┌─────────────┐  ┌───────────────────────┐  │
│  │ WS pool +  │  │ Quant       │  │  Kill switch /        │  │
│  │ reconcile  │  │ features    │  │  dead-man             │  │
│  └────────────┘  └─────────────┘  └───────────────────────┘  │
└───────────────────────────┬──────────────────────────────────┘
                            │
        ┌───────────────────┴──────────────────┐
        │                                      │
┌───────▼────────┐                    ┌────────▼────────┐
│  Hyperliquid   │                    │ Operator console│
│  (v1 venue)    │                    │ (Tauri desktop) │
└────────────────┘                    └─────────────────┘

The trust gradient is the architecture. Everything above the gateway is assumed compromisable. Everything in the Rust core is the trusted computing base, and it is deliberately small: order construction, guardrail evaluation, signing, state reconciliation, ledger writes. The console reads from the core and can command the kill switch; it cannot relax a limit without an explicit operator action recorded in the ledger.

Rust is chosen for the core because the components that must not fail — signing, guardrails, reconciliation — benefit from a language with no garbage-collection pauses in the order path and a type system that makes invalid order states unrepresentable. Tauri 2 provides the desktop shell; bun the frontend toolchain.

The key model

The master wallet never enters OPPEN. It is not imported, not pasted, not stored, not held in memory. OPPEN has no code path that accepts a master private key or seed phrase. The master wallet interacts with OPPEN once per setup, over WalletConnect, to sign a small set of bounded approvals.

Agent wallets are generated in-app. Each agent gets its own wallet, generated locally, with the private key stored in the OS keychain (Keychain on macOS, Credential Manager on Windows, Secret Service on Linux). The key is used by the signer inside the Rust core and is never exposed to the gateway, the frontend, the MCP transport, or any log line. Following venue guidance, agent addresses are not reused across agents or rotations[6].

Agent wallets cannot withdraw[6][7]. See Section 3.2 for why this is the property everything else rests on.

Three one-time approvals, signed by the master wallet in the operator's own wallet software:

1. 01Agent wallet authorization — grants the generated agent wallet permission to sign trading actions, with an explicit expiry.
2. 02Sub-account provisioning — creates the isolated sub-account the agent trades in, making capital allocation explicit and containing exposure.
3. 03Builder fee approval — sets the maximum builder fee rate OPPEN may attach to orders (Section 11). A cap the operator signs, not a rate OPPEN can raise.

None can be initiated by an agent.

Expiry as a feature. Because authorizations expire, an agent's authority decays by default rather than persisting indefinitely. OPPEN surfaces time-to-expiry in the console and treats renewal as a deliberate operator decision. An abandoned deployment stops being able to trade on its own.

Threat boundary. OPPEN defends against a compromised or misbehaving agent. It does not defend against a compromised host: an attacker with code execution and keychain access can extract agent keys and trade within the guardrails. The mitigation is the same one that applies to the withdrawal restriction — bounded loss, no custody. docs/threat-model.md is the authoritative treatment and should be read before trading real funds.

Guardrails

Guardrails are deterministic predicates evaluated in the Rust core against a fully constructed, fully priced order, immediately before signing. If any predicate fails, the order is not signed. There is no override path exposed to the agent, no "force" parameter, and no configuration surface reachable through MCP. In OWASP's terms, this is the control for LLM06 (Excessive Agency): the agent's granted authority is narrowed to its actual need, and narrowed outside its own reach[3].

Two behaviours make this a control rather than a suggestion.

Fail-closed. If the guardrail engine cannot evaluate — stale market data, missing reference price, unreconciled account state, ledger write failure — the order is refused. Uncertainty about whether a limit is breached is treated as a breach. The cost of a false refusal is a missed trade; the cost of a false permit is unbounded.

Structured refusal. A refusal returns a reason code, the failed predicate, the observed value, and the configured limit. The agent can read it and adapt — halve the size, pick an allowlisted symbol, wait for the rate bucket to refill. The operator sees the same record. Refusals are among the most informative telemetry the system produces: a change in refusal composition is a leading indicator that an agent's behaviour has shifted.

Kill switch. One operator action halts new order entry across all agents and, subject to configuration, cancels resting orders. It is a core-level state flag checked in the same path as the guardrails.

Dead-man switch. If the core loses its heartbeat with the console, or the venue connection degrades past a threshold, the system moves to a defensive state rather than continuing to trade blind. Default is halt-and-alert; flatten-on-timeout is available. Absence of supervision is not permission to continue — which matters more on a venue that never closes (Section 3.5).

Invariant, stated for the record: there is no code path that reaches the signer without a guardrail evaluation. This is enforced in the type system — the signer accepts only a value constructible exclusively by the guardrail engine's success branch — and is the subject of the P3 acceptance gate.

The agent interface

OPPEN exposes an MCP server on the local machine. MCP is an open standard for connecting AI systems to external tools and data sources, introduced by Anthropic in November 2024[5]; any compliant client can connect, and the reference target is Claude Code, paired with a single claude mcp add.

The capability surface, grouped by what it grants:

Read — market. Order book state, trades, funding, mark and index prices, and derived quant features (Section 10). Unprivileged, but logged.

Read — account. Positions, margin, open orders, fills and realized PnL, scoped to the calling agent's sub-account. An agent cannot see or reason about another agent's book.

Write — intent. Submit, modify and cancel orders. Every write returns either an execution receipt (venue order id, status, ledger sequence number) or a structured refusal. There is no fire-and-forget.

Read — self. The agent can query its own guardrail configuration and its consumption against it: remaining notional headroom, rate-bucket state, distance to the circuit breaker, time to authorization expiry. This is intentional. An agent that can see its constraints plans within them and wastes fewer cycles on rejected intents. Visibility is not mutability.

Session identity is established at pairing and bound to a specific agent wallet and sub-account. Requests are scoped to that identity by construction, not by a parameter the agent supplies.

State integrity

Event ledger. Every intent, decision, refusal, signature, submission, acknowledgement, fill and operator action is appended to a local, ordered, immutable log with a monotonic sequence number. The ledger is the system of record; UI state and in-memory caches are projections of it. For any position, the operator can replay the sequence of events that produced it, including the agent's stated intent at each step.

Connection pool. Multiple WebSocket connections with independent lifecycles, so a single socket failure degrades rather than blinds.

Reconciliation. On reconnect, OPPEN re-queries authoritative account state, diffs it against the ledger's projection, and applies missing events idempotently, keyed on venue-assigned fill and order identifiers. Because the venue's state is publicly observable (Section 3.3), this diff can be independently audited. The P2 acceptance gate is explicit: zero fills lost across a 30-second disconnect.

Staleness is visible and enforced. When market data or account state is stale beyond threshold, the console renders a stale overlay and the guardrail engine's fail-closed behaviour engages. The system never silently trades on old information.

Quant features

OPPEN computes microstructure and risk features locally and exposes them through the read surface: book imbalance, depth-weighted prices, realized volatility over configurable windows, funding basis, position-level risk decomposition. The intent is to remove from the agent the work that is well-specified and error-prone — rolling statistics, correct handling of funding accrual, consistent notional accounting — so its context is spent on decisions rather than arithmetic.

Two constraints govern this surface. Features are descriptive, never prescriptive: OPPEN computes, the agent decides. And every feature is validated against an independently hand-computed reference before release (the P6 gate). A silently wrong volatility estimate is worse than none, because it will be trusted.

Market quality, and the honest counterargument

There is a broader claim implicit in this project: that rule-bound automated execution, distributed widely, improves markets rather than merely improving individual outcomes.

The supporting evidence is real. Hendershott, Jones and Menkveld used the NYSE's 2003 automation of quote dissemination as an exogenous instrument and found that increased algorithmic trading narrowed spreads, reduced adverse selection and reduced trade-related price discovery, concluding that it improves liquidity and enhances the informativeness of quotes[10]. Predictable emotional flow — capitulation, revenge sizing, forced liquidation — is not neutral noise; it is a transfer, and it is already systematically harvested by parties with software built to collect it. Replacing hand-trading with bounded, rule-following execution shrinks that transfer.

The counterargument is equally real and belongs in the same paragraph. Kirilenko, Kyle, Samadi and Tuzun's study of the May 2010 Flash Crash found that the most active automated intermediaries did not change their trading pattern as prices collapsed — automation was not a stabilizer during the event[13]. A population of poorly specified agents can correlate, crowd the same signals and amplify a cascade rather than damp it. October 2025 demonstrated what that looks like in crypto specifically[9].

OPPEN does not resolve this. What it contributes is narrower and still worth having: per-agent notional caps and circuit breakers bound each participant's contribution to a cascade, and an open, inspectable enforcement layer is a better substrate for studying the question than an opaque one. Anyone claiming that widespread agentic retail trading is unambiguously stabilizing is ahead of the evidence.

Economics and licensing

Builder fee. Official OPPEN builds attach a builder code to every order. The fee is small, disclosed in docs/spec.md, and bounded by the maximum-rate approval the operator signs at setup[7]. OPPEN cannot exceed the signed cap without a new signature from the master wallet. The rate is visible in the console and recorded per order in the ledger. This is the project's revenue mechanism, stated in the README rather than buried: a system whose value proposition is bounded authority cannot have an unbounded fee.

License. Apache-2.0, with a CLA required for contributions. The source is auditable in full, which is the only basis on which any claim in this document can be believed rather than trusted.

Trademark. "OPPEN" is a trademark. The code may be forked and modified freely; forks may not ship under the OPPEN name. The safety claims here are claims about a particular build with particular invariants. A fork that removes the guardrail check and keeps the name would be a security problem for users, not merely a branding one.

Non-goals

Not a hosted service. No component runs anywhere but the operator's machine.

Not a human trading terminal. The activity stream is the hero surface. The order ticket exists for intervention, not discretionary trading.

Not a strategy. OPPEN ships no alpha, no signals, and no default agent behaviour. Profitability is entirely a function of the operator's agent.

Not a defence against a compromised host. See Section 6.

Not a defence against venue risk. Oracle failure, forced deleveraging, protocol exploit and chain-level failure are outside the system's control. See Section 3.6.

Not a guarantee against loss. Guardrails bound loss to configured limits under normal venue operation. The system will lose money when the strategy is wrong; it will lose it at the rate configured, until the circuit breaker halts it. That is the design goal, not a shortfall. A bounded, attributable loss preserves the ability to determine whether an edge existed. An operator who sets a 50% circuit breaker has authorized a 50% loss.

Status and roadmap

Status: pre-alpha. v1 targets Hyperliquid only. Testnet by default.

Each phase is gated on a falsifiable test rather than a feature list. P3 establishes the core invariant; P7 establishes that the security model survives contact with a real operator on a real machine.

Beyond v1: additional venues behind the same protocol abstraction, portfolio-level guardrails spanning sub-accounts, and signed-build attestation so operators can verify that the binary they run corresponds to the audited source. None committed.

Summary

The interesting question in agentic trading is not whether a model can find an edge. It is what happens on the day the model is wrong in an unusual way — a loop that does not terminate, a feed that lies, an injected instruction inside a data field, a strategy that has quietly stopped working.

Systems that answer that question with "the model was instructed not to do that" have not answered it. OPPEN answers it structurally: funds cannot be withdrawn because the signing key lacks the authority at the protocol level; the loss is bounded because a deterministic predicate the model cannot reach refuses the order; the event is attributable because each agent trades its own sub-account; and the operator knows, because every intent and every refusal sits in an append-only ledger with a kill switch above it.

Cognition stays flexible. Authority stays bounded. Custody never moves.

References

1. [1]Barber, B. M., and Odean, T. (2000). Trading Is Hazardous to Your Wealth: The Common Stock Investment Performance of Individual Investors. The Journal of Finance, 55(2), 773–806. https://onlinelibrary.wiley.com/doi/abs/10.1111/0022-1082.00226
2. [2]Chague, F., De-Losso, R., and Giovannetti, B. (2020). Day Trading for a Living? SSRN Working Paper 3423101; FGV EESP Texto para Discussão 525. https://ssrn.com/abstract=3423101
3. [3]OWASP GenAI Security Project (2024). OWASP Top 10 for Large Language Model Applications, 2025 edition (LLM01 Prompt Injection; LLM06 Excessive Agency). https://owasp.org/www-project-top-10-for-large-language-model-applications/assets/PDF/OWASP-Top-10-for-LLMs-v2025.pdf
4. [4]Greshake, K., Abdelnabi, S., Mishra, S., Endres, C., Holz, T., and Fritz, M. (2023). Not What You've Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection. Proceedings of the 16th ACM Workshop on Artificial Intelligence and Security (AISec '23), 79–90. arXiv:2302.12173. https://arxiv.org/abs/2302.12173
5. [5]Anthropic (2024). Introducing the Model Context Protocol. https://www.anthropic.com/news/model-context-protocol
6. [6]Hyperliquid Docs. Nonces and API wallets. https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/nonces-and-api-wallets
7. [7]Hyperliquid Docs. Exchange endpoint (approveAgent, approveBuilderFee). https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/exchange-endpoint
8. [8]CoinGecko (2026). CEX & DEX Trading Activity Report 2026. https://www.coingecko.com/research/publications/cex-dex-trading-activity-report-2026
9. [9]CoinDesk Research (2025). Market Spotlight: Inside Crypto's $19 Billion Liquidation Event. https://www.coindesk.com/research/market-spotlight-the-19-billion-liquidation-that-shook-crypto
10. [10]Hendershott, T., Jones, C. M., and Menkveld, A. J. (2011). Does Algorithmic Trading Improve Liquidity? The Journal of Finance, 66(1), 1–33. https://onlinelibrary.wiley.com/doi/abs/10.1111/j.1540-6261.2010.01624.x
11. [11]Hyperliquid Docs. HIP-3: Builder-deployed perpetuals. https://hyperliquid.gitbook.io/hyperliquid-docs/hyperliquid-improvement-proposals-hips/hip-3-builder-deployed-perpetuals
12. [12]Nansen (2026). What Is HIP-3? Hyperliquid's Permissionless Markets. https://nansen.ai/post/what-is-hip-3-hyperliquid
13. [13]Kirilenko, A., Kyle, A. S., Samadi, M., and Tuzun, T. (2017). The Flash Crash: High-Frequency Trading in an Electronic Market. The Journal of Finance, 72(3), 967–998. https://onlinelibrary.wiley.com/doi/abs/10.1111/jofi.12498