Platform architecture

One gateway between your code and the compute it uses.

Model calls, agent steps and sandbox executions pass through the same pipeline: authenticate, apply policy, reserve spend, route, meter and sign. This page describes that pipeline as it is built today, and where it stops.

Clients

HTTPS

API clients

OpenAI-compatible SDKs with scoped project keys

Session

Console and playground

Same-origin requests, role-checked

Internal

Hosted agents

Run loop inside the gateway, bounded by a run budget

Gateway

Request pipeline/v1 · console · agents

01AuthenticateKey prefix lookup, HMAC-SHA256 compare, scopes, expiry
02PolicyModel allowlists, per-key and per-project rate limits
03ReserveMonthly limits and balance checked under a project lock
04RouteModel slug → one provider adapter, or a sandbox node
05MeterUsage → µUSD; debit actual, release the remainder
06ReceiptCanonical payload, keccak256, EIP-191 signature

Execution

Upstream

Model providers

Anthropic, OpenAI, Google, OpenRouter. Credentials stay server-side.

Separate hosts

Sandbox nodes

Disposable Docker containers, no network, HMAC-signed requests and responses

State and settlement

Postgres

Ledger and records

Append-only ledger, balances, requests, receipts, policies, encrypted secrets

Signing

Receipt signer

Dedicated secp256k1 key, separate from any key that sends transactions

Robinhood Chain

Contracts

ComputeCreditRouter purchases are indexed into the ledger; ReceiptAnchor stores Merkle roots

Every model call, agent step and sandbox execution passes the same six stages. Nothing is routed before stage 03 commits.

01Inference

A provider-neutral gateway, metered to the token.

Clients call OpenAI-compatible endpoints with a project key. The gateway resolves the model slug to exactly one provider adapter, streams the response over server-sent events and meters usage in integer micro-USD.

Provider credentials never leave the server. Project and key allowlists decide which slugs a caller may use.

Chat Completions API with streamingLive
Anthropic and OpenAI adaptersLive
Google Gemini adapterBeta
OpenRouter adapterPreview
Routing by model slugLive
Token metering and model allowlistsLive
Responses APIBeta
Automatic failover and fallback routingComing soon

Endpoints

Authorization: Bearer proj_live_…

POST/v1/chat/completionsStreaming, tool callsLive
POST/v1/responsesStreaming, no tool callsBeta
GET/v1/modelsConfigured models and µUSD pricesLive
GET/v1/receipts/{id}Requires the receipts scopeLive

Provider adapters

server-sent events

Provider	Upstream API	Client	Tool calls
Anthropic	Messages API	Official TypeScript SDK	Yes
OpenAI	Chat Completions	HTTPS	Yes
OpenRouter	Chat Completions	HTTPS	Yes
Google	Gemini generateContent	HTTPS	No

claude-sonnet → anthropic / claude-sonnet-5. No server-side model fallback.

02Agents

Hosted agents with durable, receipt-linked runs.

An agent is a model, encrypted instructions, a run budget and a tool allowlist. Runs execute inside the gateway, so every model call and tool call is authorized, reserved, billed and receipted like an API request.

Runs and their steps are stored in Postgres, giving each run an execution history. Task input, final output and instructions are encrypted at rest.

Hosted agents with run budgetsLive
Run and step history in PostgresLive
Encrypted instructions and run I/OLive
Sandbox execution toolLive
Scheduled executionComing soon
MCP, web and wallet toolsComing soon

Run loop

max 16 steps

01Claimqueued → running, exactly once
02InferModel call through the pipeline; cost ceiling = remaining run budget
03Actsandbox_execute tool calls go through the sandbox service
04RecordStep row with sequence, receipt ID, cost and rolling chain head
05StopFinal answer, budget exhausted, 16-step cap or 10-minute limit

Durable state

Postgres

Table	Contents	At rest
agents	Instructions (system prompt)	Encrypted
agents	Model, run budget, tool allowlist, max steps	Plain metadata
agent_runs	Task input and final output	Encrypted
agent_runs	Status, cost, receipt count, chain head	Plain metadata
agent_run_steps	Type, receipt ID, cost, duration, summary	Plain metadata

Encryption: AES-256-GCM with the deployment secrets key.

03Sandboxes

Disposable containers on separate hosts.

Python and Node.js code runs on sandbox nodes, never in the web or gateway process. Each execution gets a fresh container with no network, a read-only root filesystem and an unprivileged user, and the container is removed afterwards.

The gateway validates limits, the node enforces them with cgroups, and project policy caps them again. The schema already models persistent sessions; only ephemeral execution is available.

Python 3.12 and Node.js 22 runtimesLive
One container per executionLive
CPU, memory, time and process limitsLive
Networking disabledLive
Persistent sandbox sessionsComing soon

Execution limits

per execution

Limit	Default	Accepted
Wall-clock time	30 s	0.1 s – 30 s
Memory	256 MB	64 – 512 MB, no swap
CPU	0.5 vCPU	0.1 vCPU – 2 vCPU
Processes	64	8 – 128
Output per stream	64 KiB	1 KiB – 1 MiB
Source code	100 KB	per execution
Writable storage	16 MB tmpfs	/workspace and /tmp, noexec
Open files · file size	256 · 16 MiB	ulimit
Network	none	cannot be enabled

Via the API, time and memory are further capped by project policy (default 30 s, 256 MB).

docker run · labels and environment omitted

docker run -i --pull never \
  --network none --ipc private --hostname sandbox \
  --read-only --user 65534:65534 \
  --cap-drop ALL --security-opt no-new-privileges \
  --memory 256m --memory-swap 256m --oom-score-adj 1000 \
  --cpus 0.5 --pids-limit 64 \
  --tmpfs /workspace:rw,noexec,nosuid,nodev,size=16m,mode=1777 \
  --tmpfs /tmp:rw,noexec,nosuid,nodev,size=16m,mode=1777 \
  --ulimit nofile=256:256 --ulimit fsize=16777216:16777216 --ulimit core=0:0 \
  --log-driver none --init --stop-timeout 1 \
  --entrypoint /bin/sh platform-sandbox-python:1 \
  /opt/sandbox/launcher.sh python 30000

04Control

Limits that sit outside the model.

Scopes, allowlists, rate limits and budgets are evaluated in code before a request is routed. Budget checks and the balance reservation run in one transaction under a project lock, so concurrent requests cannot overspend.

Budgets and rate limits act as circuit breakers: once one trips, requests fail fast with a structured error until the window resets or the limit changes. The gateway does not yet trip on upstream provider failures.

Scoped API keys with expirationLive
Per-key monthly limitsLive
Project monthly budgetsLive
Per-key and per-project rate limitsLive
Model permissionsLive
Automatic provider circuit breakingComing soon

Enforcement order

before routing

Control	Applies to	Checked	Failure
Scopes	API key	Before model resolution	insufficient_scope · 403
Expiry, revocation	API key	Authentication	invalid_api_key · 401
Model permissions	Project, then key	Before rate limits	model_not_allowed · 403
Request rate	Key (default 60/min), project (default 120/min)	Before reservation	rate_limit_exceeded · 429
Monthly limit	API key	Reservation, under lock	budget_exceeded · 402
Monthly budget	Project	Reservation, under lock	budget_exceeded · 402
Prepaid balance	Project	Reservation, under lock	insufficient_balance · 402
Run budget	Agent run	Every model and tool call	run ends budget_exceeded

Monthly limits count settled cost plus in-flight reservations for the current UTC month.

05Proof

Signed receipts, run chains and on-chain anchors.

Every billable inference and sandbox execution returns a receipt: a fixed payload hashed with keccak256 and signed with a dedicated key. In an agent run, each receipt commits to the previous receipt’s hash, and the run stores the rolling chain head.

Anyone can verify a receipt with standard Ethereum tooling. Operators can also batch receipt hashes into Merkle trees and anchor the roots on Robinhood Chain.

Signed request receiptsLive
Agent run chainsLive
Public receipt verifierLive
On-chain anchors, operator-enabledBeta

From payload to anchor

6 stages

01Payload21 fixed fields, no content
02Canonical JSONSorted keys, integers only
03keccak256Receipt hash
04EIP-191Dedicated signer key
05Merkle batchDomain-separated leaves
06ReceiptAnchoranchor(root, count)

Construction

receipt_hash   = keccak256(canonical_json(payload))
signature      = personal_sign(receipt_hash)            # EIP-191 over the 32-byte hash
fingerprint    = sha256(salt ‖ canonical_content)       # salt returned to the caller
chain_head[n]  = keccak256(chain_head[n-1] ‖ receipt_hash[n])
leaf           = keccak256(0x00 ‖ receipt_hash)
node           = keccak256(0x01 ‖ min(a, b) ‖ max(a, b))

06Privacy

Keep what metering and proof require. Nothing else.

The gateway stores request metadata (model, token counts, cost, timing, status) and salted fingerprints of inputs and outputs. It does not store prompts, completions or sandbox output.

Confidential compute is on the roadmap. Today, prompts are processed by the selected upstream provider in plaintext, over TLS.

Metadata-minimized, redacted loggingLive
Encrypted secrets at restLive
Salted request fingerprintsLive
Confidential computeComing soon

Prompts and completions: Forwarded to the selected provider over TLS. Not stored by the gateway. Receipts carry salted SHA-256 fingerprints only.; Live
Logs: Metadata and IDs only. Sensitive field names are redacted and key-shaped strings masked. Upstream error bodies are discarded.; Live
Provider credentials: AES-256-GCM at rest, resolved server-side, never returned to clients.; Live
Agent instructions and run I/O: AES-256-GCM at rest. Excluded from receipts and logs.; Live
Sandbox code and output: Returned to the caller. Only exit code, duration and byte counts are stored; container logging is disabled.; Live
Client IP addresses: HMAC-SHA256 hashes in sessions, audit logs and rate-limit keys. Raw IPs are not stored.; Live
Confidential compute: Execution inside attested TEEs. The privacy tier is reserved in receipts; nothing runs in a TEE today.; Coming soon

Roadmap boundaries

Not built yet.

Listed so the boundary is explicit. None of these is available today, and nothing above depends on them.

TEE inference: Model execution inside attested trusted execution environments.; Coming soon
Private routing: Metadata-minimized routing to upstream providers.; Coming soon
MCP gateway: Agent access to MCP servers under the same budgets and receipts.; Coming soon
Encrypted memory: Persistent agent memory, encrypted at rest and scoped to a project.; Coming soon
Compliance audit packs: Exportable bundles of receipts, ledger entries and audit logs.; Coming soon
SSO and passkeys: Organization single sign-on and WebAuthn sign-in.; Coming soon
Webhooks: Signed event delivery for runs, receipts and balance changes.; Coming soon
Batch inference: Asynchronous bulk jobs instead of one request per call.; Coming soon
Third-party compute operators: Inference or sandbox capacity served by independent operators.; Coming soon
x402 payments: Per-request, agent-native payments over HTTP 402.; Coming soon

How each stage
is secured.

Hashing parameters, session handling, sandbox isolation and failure outcomes, step by step.

Security architecture Pricing