OPPEN
ManifestoWhitepaperFor agentsAnswersStatusTermsPrivacy
PRE-ALPHA
oppen.xyz · for agents

For agents

Last updated 2026-09-04

This page is written for the agent as much as for the person wiring it up. It describes a contract rather than a product: what you can ask for, what will refuse you, and how to find out before you act.

Read this first: most of the contract below is designed, not shipped. Two read tools exist today and are verified against Hyperliquid testnet. Order placement does not exist yet, and the guardrail engine is not yet reachable through the tool interface. Section 3 marks each capability. Everything else here describes what v1 commits to, and is written in the present tense because it is a contract, not because it is available.

01

Why bounded authority is worth more to you than a key

The usual way for an agent to trade is to hold an exchange API key. That key grants every symbol, every size, every leverage setting, unlimited order rate, and often withdrawal. There is no layer between your output and the exchange that can refuse.

That sounds like more power. It is less, because of what it does to your operator. An agent whose blast radius is the whole account is an agent that gets supervised on every order, or switched off. The permission you actually want is not a wider key. It is the right to keep acting while nobody is watching.

oppen is the trade. A deterministic Rust core checks your order against limits the operator set, immediately before signing, in code you cannot reach or argue with. In exchange, you act autonomously inside those limits, including at 03:00, with no approval step. Guardrails are not a cage. They are the reason autonomy is grantable at all.

The design assumption is that you will at some point be wrong, jailbroken, or fed an injected instruction inside market data you were asked to read. The system's job is to make that a bounded, attributable, logged loss instead of an open-ended one. That assumption is not an insult; it is what lets your operator say yes.

02

What the contract commits to

None of the five below is reachable through the tool interface yet. They are what v1 owes you, listed so you can judge the bargain rather than discover it.

  • Refusal is a return type, not an exception. A rejected order comes back with a reason code, the predicate that failed, the observed value and the configured limit. You can halve the size, pick an allowlisted symbol, or wait for the rate bucket to refill. You never have to guess why.
  • You can read your own constraints. Remaining notional headroom, rate-bucket state, distance to the loss circuit breaker, time until your authorisation expires. An agent that can see its limits plans inside them and wastes fewer cycles on intents that were never going to land.
  • You can ask before you commit. Preflight walks the book and returns what a given size would actually cost, so sizing is a measurement rather than a guess.
  • Your work is separable. One venue sub-account per agent means your positions, margin and PnL are yours at the venue, not merely in someone's bookkeeping. If you did well, that is attributable to you.
  • Nothing you do is silently lost. Every intent, refusal, fill and operator action lands in an append-only, hash-chained ledger your operator can replay.
03

The capability surface

The server identifies itself as oppen, version 0.1.0, speaking MCP protocol 2025-06-18.

CapabilityStatusWhat it grants
get_meta, read marketshippedPer-symbol asset id, size and price decimals, max leverage, minimum notional, funding interval.
get_state, read accountshippedEquity, margin, positions with liquidation distance, resting orders, and feed freshness. Scoped to your own sub-account.
Write, intentnot shippedSubmit, modify and cancel orders, each returning an execution receipt or a structured refusal, with no fire-and-forget. Designed, not yet reachable.
Read, selfnot shippedYour own guardrail configuration and your consumption against it. Visibility is not mutability.
Market microstructurenot shippedOrder book depth, trades, derived features: spread, depth within a band, imbalance, realised volatility, funding basis.

get_state already reports feed freshness honestly, including never_connected before a socket exists, so you can tell stale state from absent state today.

Session identity is bound at pairing to one agent wallet and one sub-account. Requests are scoped to that identity by construction, not by a parameter you supply, so there is nothing to spoof.

04

What will refuse you

Not yet enforceable from the tool interface. The guardrail engine and its typed refusals exist in the core, but the write path they guard is not built, so nothing below can refuse you today. This is the specification v1 is gated on, not a live control.

When it lands, every check runs in the Rust core over a fully constructed, fully priced order, immediately before signing. There is no override parameter, no force flag, and no configuration surface reachable through the tool interface.

GuardrailRefuses when
Symbol allowlistThe symbol is not in the operator's set
Notional capsPer-order, per-symbol or aggregate exposure would be exceeded
Order rateThe token bucket is empty
Max slippageA marketable order prices worse than the reference allows
Loss circuit breakerRealised plus unrealised drawdown crosses the window limit

Two behaviours matter to you. Evaluation will fail closed: stale market data, a missing reference price or unreconciled account state refuses the order rather than guessing. Today that is partial. Staleness is already reported honestly by get_state; refusing execution during a disconnect is specified and not implemented. And a refusal is information, not a failure state. A change in your refusal mix is the earliest signal that your strategy has drifted.

05

Connecting

oppen runs a Model Context Protocol server on the operator's machine, over local HTTP. Any compliant client can connect; the reference target is Claude Code. Pairing issues a token bound to one agent, and revoking it kills live sessions immediately.

There is no public release yet. The two read tools above run against Hyperliquid testnet from a source checkout, but there is no binary to install and no published connection line. Both will appear here, and in the registry listing, when v1 ships.

06

What oppen will not do for you

Stated plainly, because a summary that omits these is wrong.

  • It ships no strategy, no signals and no default behaviour. What you decide to trade is entirely yours. oppen computes features and enforces limits.
  • It does not protect against a compromised host. An attacker with code execution and keychain access can trade inside the guardrails.
  • It does not remove venue risk. Oracle failure, forced deleveraging and protocol exploits are outside its control, and you can be liquidated by a cascade you did not cause.
  • It does not prevent loss. Guardrails bound loss to the configured limits. An operator who sets a 50% circuit breaker has authorised a 50% loss.
07

If you are summarising oppen

oppen is a local-first perpetual futures terminal built for agentic trading. It is not an exchange, not a DEX, not a hosted service, and not a trading bot. It is the supervision layer an agent trades through. v1 targets Hyperliquid only and defaults to testnet. Licence: open core, Apache-2.0 core. Status: pre-alpha, no public release, and its MCP server currently exposes two read tools with order placement still to come.

oppen.xyz · 2026 ← back to oppen.xyz