Lattice Perps

A safety-first WebMCP trading cockpit for Hyperliquid: agents propose bounded paper trades, humans control authority, and every action is policy-checked with transparent receipts.

Comment

Inspiration

Web agents can operate a web page, but actions that change state still need to be understandable, inspectable, and safe.

We wanted to explore what an agent-native trading interface could feel like without asking anyone to connect a wallet, approve a signer, or risk real funds. Lattice Perps is our answer: a browser-local paper-trading experience where a human and a browser agent can use the same interface, the same account, and the same visible evidence.

The project is inspired by Hyperliquid perpetual markets, but this public showcase intentionally stops at deterministic local simulation.

What it does

Lattice Perps is a paper trading flight recorder for WebMCP.

The app starts with one browser-local paper account containing $100,000 of simulated USD and four fixed markets:

  • BTC
  • ETH
  • SOL
  • HYPE

A human can place market or limit orders from the visible interface. Market orders fill at the displayed simulated mark price. Limit orders rest locally and can be cancelled by their local order ID.

A browser agent can perform the same paper-trading actions through six WebMCP tools:

  • paper_get_markets
  • paper_get_portfolio
  • paper_get_open_orders
  • paper_get_activity
  • paper_place_order
  • paper_cancel_order

Every human action, system event, and WebMCP call is written to the visible Agent Tape. The portfolio panel updates from the same underlying account state, showing equity, available balance, margin used, realised PnL, unrealised PnL, positions, open orders, and fills.

The key idea is simple:

One local account. One shared state. Two ways to interact.

You can trade from the page or ask your browser agent:

Buy 0.05 BTC at market, then show my paper portfolio.

The result is visible in the Agent Tape and reflected in the portfolio immediately.

How we built it

The app is built with React, TypeScript, and Vite.

The human interface and WebMCP tools share one LocalTradingStore. This prevents the UI and agent surface from developing separate balances, positions, orders, or activity histories.

The store provides:

  • deterministic simulated markets and mark prices
  • market and limit order handling
  • position netting and PnL calculations
  • simulated fees and margin checks
  • local order cancellation
  • browser persistence through localStorage when available
  • an in-memory fallback when browser storage is unavailable
  • a visible activity history for human and WebMCP actions

WebMCP registration is feature-detected through the browser's document.modelContext surface. If WebMCP is unavailable, the human trading interface still works. Tool inputs use explicit schemas and reject unexpected fields so the agent surface remains narrow and predictable.

The project also includes automated tests for the local trading store, WebMCP tool definitions, and the rendered paper-trading interface.

Safety by design

This showcase deliberately has:

  • no wallet connection
  • no exchange connection
  • no network order submission
  • no real funds
  • no private keys
  • no deposits or withdrawals
  • no production trading capability

WebMCP is treated as an invocation layer, not an authentication or authorization mechanism. The public demo is designed to make the interaction model visible without pretending that a browser tool registration is equivalent to trading authority.

Challenges

The hardest part was making the human and agent paths genuinely share state. A separate “agent balance” or fake tool response would have made the demo look convincing while hiding the real interaction model. Instead, both paths call the same store and produce the same portfolio projections and activity records.

Another challenge was making the demo useful even when the browser does not support WebMCP. The interface therefore remains complete on its own, while WebMCP enhances it when the browser exposes the API.

Finally, we had to make the boundaries clear. A trading demo can easily imply that a real exchange, wallet, or signer is involved. The local simulation, explicit labels, and Agent Tape are designed to keep the demo honest.

What we learned

We learned that agent-native interfaces benefit from visible evidence, not just successful tool calls. A tool invocation is much easier to understand when the user can see its source, timestamp, status, and effect on the shared account.

We also learned that deterministic simulation is valuable for WebMCP development. It makes the experience reproducible, easy to reset, and safe to demonstrate while the browser API and authority model are still evolving.

What's next

A future version could connect this interaction model to a separately approved testnet account behind explicit human authority, policy checks, and post-action reconciliation.

For this submission, we intentionally keep the public experience local, deterministic, and risk-free.

Built With

Share this project:

Updates

Submission history