Skip to content
Clicking
← Directory

Trading

Coming

Orch

Orch doesn't trade. It allocates capital across specialist trading pods, governs total risk, and holds the kill switch.

Funds stay in your own account. The agent gets trade-only access and never withdrawal authority.

In development. No live capital deployed.

No pod has graduated past its first gate, and that gate deploys zero real capital by design. Backtests currently run on synthetic data — and a synthetic report is deliberately failed by the validation gate, so a pod cannot graduate on a market that never existed.

By arrangement

Limited placements, arranged in conversation. It isn't sold by the job and there's no checkout.

Orch isn't reachable yet — its entry points open with the agent.

What it does

Pronounced “Ork.” One allocator over many specialists: each pod owns a strategy and a market, while risk is governed centrally and the kill switch sits in one place.

How it's built

Orch allocates. It doesn't trade.

It moves capital across pods and clusters, and it's the only thing that sees the whole book.

No pod knows another exists

Each pod receives only its own positions and its own allocation. Strategy logic is isolated; nothing else lives in a pod.

Pods cannot place orders

A pod emits an order intent, which no venue accepts. Only the risk engine can turn one into a validated order, and only that reaches a venue. It's a structural limit, not a policy.

One spine, many strategies

Market data, execution, positions and audit are a single shared implementation. Only the strategy logic is duplicated per pod.

  • Trade authority is never withdrawal authority.

    There is no withdrawal type in the system and no venue method that could carry one.

  • Time at a graduation gate cannot be bought.

    Five hundred profitable trades and zero drawdown do not shorten a gate by a single day. There's a test that asserts it.

The pods

6 built · 3 spec'd · 12 gated

21 specialist pods, each owning one strategy in one market. The gated ones are blocked on named dependencies rather than on effort.

Robinhood

Dedicated agentic account. Custody is enforced by the venue itself.

  • RH-1 Equity TrendBuilt
  • RH-2 Equity Mean-ReversionBuilt
  • RH-3 Thematic BasketBuilt
  • RH-4 Event-DrivenSpec'd
  • RH-5 Sector RotationSpec'd
  • RH-6 Defined-Risk Options PremiumGated
  • RH-7 Event VolatilityGated
  • RH-8 Crypto TrendBuilt
  • RH-9 Crypto RangeSpec'd
  • RH-10 On-Chain Informed CryptoBuilt
  • RH-11 Catalyst & UnlockWaiting on: Verified vesting-contract reads from the detectiveGated
  • RH-12 Hedge / Risk-OffBuilt

Hyperliquid

Perps, spot and outcome contracts. Every pod here is gated on the venue adapter and on a custody reconstruction that has to be verified by attempting a withdrawal and confirming it fails — this venue doesn't enforce trade-without-withdrawal the way Robinhood does.

  • HL-1 Funding / Basis CarryGated
  • HL-2 Liquidation StructureGated
  • HL-3 On-Chain Positioning FlowGated
  • HL-4 Perp TrendGated
  • HL-5 Order-Book ImbalanceGated
  • HL-6 Relative Value / PairsGated
  • HL-7 Cross-Venue DislocationGated
  • HL-8 HIP-3 Relative ValueGated
  • HL-9 Outcome ContractsGated

Sample output

No sample yet.

A real one goes here the moment Orch produces it. A mocked-up example would show you our writing, not the agent's work — which is the only thing worth judging it on.