# oppen

> A local-first trading terminal and execution gateway for AI agents.
> Delegate execution. Retain control.

Source: https://oppen.xyz/

**Pre-alpha, no public release.** Hyperliquid is the v1 target and testnet is the default. Aster and Lighter are planned. Source publication is planned at launch; readiness depends on execution, recovery and operator-control gates.

## Infrastructure for agent trading

Oppen is being built to let an operator choose an agent, allocate capital and set the terms on which it may act. The agent requests actions through a local MCP gateway. A Rust core owns policy evaluation, signing and the execution record. The desktop console provides supervision and intervention.

The product does not operate an exchange or supply a trading strategy. A model or script decides what to request; the venue determines execution. No profitable outcome is promised.

## Separate authority from execution

The intended key model keeps account-owner private keys in your own wallet. Agent-wallet keys are generated locally and used by the Rust signer, with OS keychain storage. Each agent is assigned a dedicated venue account, called a container. A container may be a top-level account or a sub-account where available; it is not cross-venue margin.

The local application handles signing keys. The Oppen team does not receive them. Venue connections leave the device, and a hosted model receives the context its client sends. Local-first does not mean offline.

## Limits that can be inspected

Market allowlists, exposure caps, order-rate budgets, slippage constraints and loss-triggered halts are designed to govern requests before signing. The operator changes policy; the agent cannot raise its own limits through MCP.

These controls are not a guarantee of maximum loss. They depend on correct, fresh state and on execution passing through the core. An extracted key can be used outside Oppen. An open position remains exposed after a halt, and losses can exceed a circuit-breaker trigger.

## A record of requests and outcomes

The console is designed to distinguish proposed actions, refusals, submissions and observed venue outcomes. An unresolved submission must remain visible after interruption or restart. A locally hash-chained record supports inspection; it is not an immutable witness against a fully compromised host.

## Current stage

Read and execution paths exist in source. Full venue acceptance, recovery, operator supervision and a supervised testnet pilot remain open gates. The site illustrations show intended behavior, not live market data or a released trading system.

Website visit analytics and launch-notification emails are described in [Privacy](/privacy/). The desktop application has no usage analytics sent to the Oppen team.

## Read next

- [Manifesto](/manifesto/): the principles behind the project.
- [Whitepaper](/whitepaper/): the architecture, tradeoffs and release evidence.
- [For agents](/agents/): the integration boundary.
- [Answers](/answers/): common questions.
- [Status](/changelog/): implementation progress and open gates.