OMNITERMINAL / DOCS

Agent guide

Research with Omni. Decide locally. Execute only through the broker.

A trading agent should not merge data purchase and order authority into one opaque step. The committed examples buy a bounded Omni Market Risk result, apply deterministic local guardrails, and then use a broker-specific preview or dry-run path. Live submission remains disabled by default.

At a glance

Research
HTTP or MCP Select transport without changing the decision contract.
Default
HOLD / dry-run Weak signals and missing live authorization do not submit.
Authority
Broker-owned Omni never receives brokerage credentials or order authority.

Why It Matters

What traders and researchers should take away

  • Research failures cannot silently become a neutral or bullish signal.
  • A deterministic guardrail makes the boundary between model/tool output and order submission reviewable.
  • Broker preview, not an Omni receipt, remains the final executable contract for an order.

How it works

What the product uses behind the scenes

  • examples/agents/research.ts loads the same Market Risk schema through x402 REST or native MCP.
  • decideFromMarketRisk returns HOLD when evidence is incomplete, confidence is weak, or funding is extreme.
  • MAX_ORDER_NOTIONAL_USD caps broker order size independently of the x402 research price.
  • Coinbase uses authenticated preview before submission; Robinhood dry-run returns a signed payload without transmitting it.

Notes

Things to know

  • Examples are integration patterns, not profitable strategies or investment advice.
  • Broker credentials are required only by the corresponding broker client and must never be sent to Omni.
  • LIVE_TRADING=true can submit a real order when all broker requirements pass; never enable it during initial setup.
  • An Omni payment receipt proves research settlement, not user approval to trade.

Guide

Steps

  1. Verify research in no-spend mode

    Run the SDK unit, boundary, and live no-spend suites before adding a funded buyer key.

  2. Buy and validate one Market Risk result

    Use x402 REST or MCP, enforce a 0.003 USDC per-call ceiling, and reject stale or incomplete components.

  3. Apply local decision policy

    Turn the typed result into HOLD, BUY, or SELL using deterministic confidence, funding, and notional limits.

  4. Preview or dry-run at the broker

    Keep LIVE_TRADING=false; inspect Coinbase preview errors or the Robinhood signed payload.

  5. Require explicit production approval

    Only enable live submission with least-privilege broker keys, broker-side limits, monitoring, and human approval for material orders.

Safety

Before using this workflow

  • Use separate secrets for the x402 buyer wallet and each broker.
  • Keep research spend limits and order-notional limits independent.
  • Log decisions and receipt identifiers, never private keys or broker secrets.
  • Stop when settlement, freshness, broker preview, account scope, or order state is uncertain.

Next

Open the workflow

Use the same decision input over HTTP or MCP

Transport selection should not change the schema consumed by policy.

dotenv
OMNI_RESEARCH_TRANSPORT=x402
# or: OMNI_RESEARCH_TRANSPORT=mcp

EVM_PRIVATE_KEY=0x...
X402_MAX_PAYMENT_USD=0.003
TRADING_SYMBOL=BTC
MAX_ORDER_NOTIONAL_USD=25
LIVE_TRADING=false
  • The research helper returns MarketRisk plus payment evidence for either transport.
  • Keep LIVE_TRADING=false while validating account scope, preview, and payload construction.
  • The x402 maximum protects one research call; MAX_ORDER_NOTIONAL_USD protects one broker order.

Run Coinbase or Robinhood in guarded mode

Both examples require deliberate secrets and remain non-live unless explicitly enabled.

bash
npm run example:coinbase
npm run example:robinhood

# Do not set LIVE_TRADING=true during setup.
  • Coinbase dry-run still calls its authenticated preview endpoint and requires Coinbase credentials.
  • Robinhood dry-run signs and prints the order payload but does not transmit the order.
  • A HOLD decision ends before broker submission in both examples.

Authority model

Each subsystem receives only the authority required for its role.

  • Omni seller: receives a standard payment proof and returns bounded public-market research.
  • Buyer policy/wallet: decides whether a resource, amount, asset, network, and payee are allowed.
  • Decision code: validates research and produces a bounded recommendation or HOLD.
  • Broker client: owns account access, preview, and order transmission under separate credentials.
  • User/operator: owns live-trading authorization, material-notional approval, monitoring, and recovery.

References

Implementation references

  • Shared research helper

    https://github.com/InTheta/omni-universe-sdks/blob/main/packages/typescript/examples/agents/research.ts

    HTTP/MCP transport selection and typed Market Risk input.

  • Coinbase example

    https://github.com/InTheta/omni-universe-sdks/blob/main/packages/typescript/examples/agents/coinbase-agent.ts

    Preview-first Coinbase Advanced Trade workflow.

  • Robinhood example

    https://github.com/InTheta/omni-universe-sdks/blob/main/packages/typescript/examples/agents/robinhood-agent.ts

    Signed dry-run and guarded Robinhood Crypto workflow.

Next

  • Agent quickstart

    Give an agent bounded market intelligence in the way it already works.

  • TypeScript SDK

    One typed source preview for Omni data, x402, MCP, and agent examples.

  • Trading-agent companion

    Research with Omni, then execute through the broker you already trust.