Skip to main content

Protocol overview

Tayho is a set of coordinated HyperEVM contracts with one canonical deployment identity per environment. Applications should discover addresses from GET /v1/config through the SDK rather than copying individual addresses.

Contract map

Capital flow

Trader margin is segregated from LP shares in accounting. The reserve buffer and claim queue limit withdrawals. Token issuance does not substitute for USDC owed to winning traders.

Execution controls

The contracts enforce:
  • Per-market net and gross open-interest limits.
  • Cluster exposure limits.
  • Maintenance margin that can increase near price boundaries and resolution.
  • Price clamping and time-weighted liquidation marks.
  • Oracle staleness, depth, and chain-liveness checks.
  • Resolution freeze behavior.
  • Typed-data replay protection and bounded session permissions.
  • Permit and allowance validation for token-pulling actions.
Failures at these boundaries revert; applications should surface the simulation or relayer error rather than estimating success locally.

Transaction submission

The current public transaction model is relayer-only. Users sign EIP-712 actions or orders; Tayho submits the transaction and exposes a capability-scoped receipt. There is no SDK method for direct broadcasting. Relayer submission provides:
  • Stable idempotency across retries.
  • Pre-submit simulation and policy enforcement.
  • Gas sponsorship within project limits.
  • Managed nonce/replacement behavior.
  • A lifecycle that remains readable if realtime delivery is interrupted.
It does not give the relayer authority to alter signed quantities, recipients, deadlines, markets, or permit terms.

Deployment identity

client.configuration() returns:
  • Environment and chain ID.
  • The complete role-to-contract address map.
  • API and SDK compatibility versions.
  • Supported relayed actions and permit capabilities.
  • Whether direct RPC preparation reads are configured.
Treat the returned deployment as one coherent unit. Do not mix addresses from different releases. When an RPC reader is configured, the SDK checks that its chain ID matches this identity. The checked-in deployment currently includes HyperEVM testnet chain ID 998. Public production availability and addresses are not asserted by this documentation until a production identity is served by the production API.

Data ownership

The chain is authoritative for positions, orders executed onchain, vault and staking accounting, funding indices, and market lifecycle. Tayho scans historical logs in one canonical indexing boundary. The API composes indexed history with live reads and offchain signed-action lifecycle; clients and SDK adapters do not call eth_getLogs.

Integration safety checklist

  • Read configuration at startup and after an environment change.
  • Keep all amounts as integers and preserve opaque cursors/receipts.
  • Use direct RPC reads only through a bounded SDK reader or adapter.
  • Inspect prepared consequences before signing.
  • Reuse the same prepared payload and idempotency key when retrying.
  • Use receipt state—not WebSocket delivery alone—to determine completion.
  • Treat stale oracle, wrong-chain, simulation, quota, and policy failures as hard execution gates.

Core concepts

Learn the user-facing accounting and lifecycle vocabulary.

SDK actions

Prepare and submit the currently supported relayed writes.
Last modified on July 23, 2026