Relay Safety Model

Relay limits execution through explicit values, server previews, confirmation boundaries, runtime guards, and revocation controls.

2 min read

Relay is designed around explicit authority. A run must move through visible states before it can affect an account.

Safety principles

  • No execution from prose.
  • No hidden trade-critical defaults.
  • No mandate mutation without a new preview and confirmation.
  • No confirmation while data is stale or the preview is expired.
  • No live authority without revoke and audit paths.
  • No semantic green for anything except ready, live, allowed, positive, or complete states.

Account and market checks

Preview creation uses account and market snapshots. If those snapshots are stale, missing, or unsupported, Relay should block confirmation.

The UI should distinguish account readiness, Hyperliquid funding, trading capability, and Yoso execution capability. A wallet can be ready while execution remains locked.

Runtime guards

Runtime guards can pause, skip, or block work while a mandate is live. Guards should be visible as part of the run, not hidden in a technical blob.

Common guard categories include market conditions, account exposure, freshness, slippage, and kill-switch-relevant limits.

Revocation and audit

Live mandates must remain revocable. Users should be able to find pause, resume, cancel, and revoke paths without hunting through chat history.

Receipts and activity records should make it clear what the runtime attempted, what was accepted, what failed, and what remains active.

Product language

Relay copy should stay precise:

  • Say preview, confirm, pause, revoke, and blocked.
  • Say AI drafted or AI patched, not AI traded.
  • Avoid words such as autonomous, magic, and I will trade.