Skip to main content
TEE-backed Executors connect the Robinhood Chain control plane to integrated execution venues. They translate authorized intents into venue-specific operations and return the results and state needed by the onchain risk engine. Executors are an execution boundary, not a second source of portfolio authority. The Credit Account determines what may happen; the venue determines how the action executes locally; the Executor connects the two.

​
Responsibilities

Executors perform five protocol functions:
  1. Bind accounts: Provision or associate a Venue Account and finalize its relationship to the Credit Account.
  2. Process actions: Submit authorized orders, cancellations, deposits, withdrawals, and position closures.
  3. Observe results: Determine whether the requested venue operation succeeded, failed, or exceeded its deadline.
  4. Relay state: Normalize venue balances, positions, PnL, margin, and freshness inputs for the Robinhood Chain risk engine.
  5. Coordinate unwinds: Close or reduce venue exposure when the Credit Account enters a risk-driven unwind.
Drivers isolate venue-specific APIs and signing rules. The rest of Mobius consumes the same binding, action, state, and request-status model for every venue.

​
Authority Boundary

An Executor may process only an intent already authorized through the Credit Account. The authorization specifies the action and its permitted bounds. An Executor cannot:
  • originate a discretionary trade;
  • withdraw assets without an authorized request;
  • add an unsupported venue or asset;
  • change the Credit Account’s debt or risk configuration; or
  • treat an unconfirmed venue outcome as completed onchain state.
Sensitive venue credentials and signing operations remain inside hardware-isolated execution. This reduces exposure of the keys needed to operate Venue Accounts without granting those keys broader portfolio authority.

​
Request Processing

Each request has a stable identifier and deadline. Stable identifiers make retries idempotent: an interrupted process can resume without intentionally submitting the economic action twice.

​
Fail-Closed Behavior

Executor or venue failures restrict the portfolio instead of creating additional borrowing power:
  • stale venue state receives reduced risk value;
  • pending actions remain pending until their outcomes are established;
  • failed and expired actions are not credited as successful transitions;
  • risk-increasing requests are rejected while an account is being unwound; and
  • unsupported or malformed state is rejected rather than interpreted through a fallback.
The onchain authorization and request records remain the canonical history even when a venue or Executor is unavailable.

​
Execution Topology

The protocol’s safety model depends on hardware-isolated execution, bounded authority, authenticated results, explicit request states, and fail-closed risk treatment. It does not depend on the documentation prescribing how many Executor operators exist or how they coordinate. That separation allows the execution topology to evolve without changing the Credit Account’s authority or the risk engine’s invariants.