Security model

Tayho assumes application, infrastructure, RPC, provider, and worker failures can occur independently. Correctness rests on narrow on-chain authorization, session-signed user intent, durable idempotent coordination, isolated signer roles, reorg-aware projection, and fail-closed readiness. This page indexes the operational model. The detailed contract analysis remains in packages/contracts/SECURITY.md.

Assets and authorities

Asset	Authority	Security objective	Response owner
User collateral, positions, vault, staking	Contracts	Only valid protocol transitions; solvency/reserve invariants	Protocol/security
Signed user intents/actions	User/session EIP-712 signature plus contracts	No term mutation, replay, or unauthorized execution	Engine/relayer
Worker transaction authority	Role-specific signer and contract allowlist	No cross-role or owner-equivalent call	Service owner/security
Intent/action lifecycle	Coordination PostgreSQL	Immutable accepted identity and legal fenced transitions	Engine/data
Transaction nonce/lineage	Coordination PostgreSQL plus RPC quorum	No nonce reuse or unrelated replacement	Relayer
On-chain projection	Chain plus Ponder database	Ordered, complete, reorg-correct history	Indexer/data
API credentials and quotas	API control database	One-way secret storage, least scope, immediate revocation	API/security
Replay/queue delivery	Redis	Availability without becoming authority	Keeper/API
Telemetry/evidence	Observability/evidence stores	Useful correlation without sensitive payload leakage	On-call/security

Public boundary

Only the frontend and tayho-api accept public application traffic. API controls enforce exact body/path/query schemas, bounded JSON, CORS, trusted-proxy policy, API-key environment/status/expiry, scope, origin/CIDR restrictions, and project/key/IP quotas. API keys authorize access to Tayho services; wallets authorize economic actions. A publishable API key never replaces a wallet signature. Receipt capabilities separately protect intent/action status and protected realtime snapshots. The API is signerless. It can compose indexed state, engine lifecycle, and live unsigned RPC reads, but cannot broadcast or mutate accepted terms. It authenticates to the engine with a private service credential and never exposes the engine publicly.

Signer roles

Role	Transaction authority	Compromise action
Relayer	Execute validated session-signed orders/actions and hard cancellation	Pause intake/drain lanes, remove affected signer, reconcile every nonce/lineage
Automation	Permissionless bounded maintenance calls	Drain affected pool; protocol permission is not broadened
Funding oracle	Funding attestation only	Guardian-pause markets, revoke both funding attesters, rotate keys and source
Depth/resolution attester	Depth and resolution attestation only	Guardian-pause, revoke affected attesters, requalify independent facts
Guardian	Pause/unpause unsafe markets	Remove guardian and maintain pause through unaffected approved authority
Revenue	Vault `skim` only	Remove distributor; delayed distribution is preferable to broadened authority

Engine and auditor reject signer configuration. API, indexer, and market-data are also signerless. Owner and treasury remain distinct from every operational address. Each active signing role uses exactly the reviewed role key pool across replicas. Runtime function allowlists reject cross-role calls before simulation/broadcast, while contracts enforce final authorization. PostgreSQL serializes signer selection, nonces, and same-nonce replacement lineage.

Key and credential classes

Class	Mounted into	Rotation invariant
Worker private signers	One matching signing role	Drain lane, update on-chain set, prove replica agreement and nonce reconciliation
Transaction journal keyring	Signing role	Add new active key first; retain old keys until retirement proof covers all ciphertext/lineage/reorg windows
Intent keyring and receipt secret	Engine/relayer only as required	Preserve decryptability and receipt tracking through rotation
API key pepper	API credential process	Coordinate rehash/reissue design; never log or expose
API project keys	Integrator and API hash store	Revoke/rotate one key with reason; suspend project only when intended
Internal bearer tokens	Exact producer/consumer pair	Rotate both ends; never reuse as metrics or source credentials
Database/Redis credentials	Matching restricted service	Rotate role independently and re-prove grants/readiness
Observability credentials	Exporter/scraper/backend	Preserve telemetry while preventing public scrape/export

Resolved values, wallet lists, signed bytes, ciphertext, database URLs, private hostnames, and raw audit payloads do not belong in Mintlify content or release evidence.

Datastore boundaries

PostgreSQL is the durable authority for coordination. Separate runtime, engine, relayer, auditor, API, indexer, and migration identities have table/column/RLS/default-grant boundaries. Only the migration job has schema-owner credentials. Redis/BullMQ can redeliver, lose locks, or be rebuilt. Stable outbox IDs, execution tokens, idempotency keys, current-state simulation, and legal database transitions make at-least-once delivery safe. Operators never repair correctness by deleting queue/database rows or resetting nonces. The indexer is the sole eth_getLogs owner. Its Ponder state handles ordering and reorg rollback. The auditor consumes the private indexer projection for ordered evidence and independently checks bounded current state through RPC quorum. API, engine, relayer, auditor, SDK, and all other workers must not add log-range scanners.

RPC and provider assumptions

Wrong-chain, unavailable, stale, or disagreeing RPC origins fail readiness or the current decision. Signing roles use one preferred write endpoint and independent safety voters. The development single-origin exception is restricted to HyperEVM testnet chain 998 and never changes production majority requirements. Market-data replicas improve process availability but do not create source independence. Production funding and resolution require separately governed facts. Price-domain clamps, reserve backing, one-shot intervals, guardian pause, and auditor recomputation bound damage but cannot make a dishonest source truthful.

Contract emergency paths

Guardians pause/unpause only within their narrow authority.
Owner/governance manages markets, bounded parameters, roles, and emergency configuration; it is deliberately not an operational worker.
Exits remain available when stale funding blocks new exposure.
OCO, nonce bitmaps, session limits, deadlines, Permit2 bounds, and receipt/cancellation races are enforced at contract and signed-message boundaries.
Queue, API, or relayer pause must preserve status reads, transaction reconciliation, and recovery evidence.

Follow Incident response for RPC, database, nonce, oracle, liquidation, funding, deployment, queue, transaction, signer, audit, intent, reorg, indexer, API, realtime, market-data, and compromise procedures.

Review and launch evidence

Production launch requires:

exact reviewed commit and immutable image/provenance/SBOM identity;
contract static, fuzz, invariant, symbolic, and independent review evidence;
operational independent review of actual deployed grants/topology;
24-hour injected-failure qualification and datastore restore/rebuild drills;
signer, intent-key, journal-key, API-key, and database credential rotation evidence;
RPC partition, reorg, queue/idempotency, and unauthorized-write probes; and
named operations, security, protocol, and incident-owner approval.

Open Critical or High findings block launch. Accepted Medium findings require a named owner, rationale, compensating controls, and deadline. See the review scope and launch checklist.

Reporting a vulnerability

Do not open a public issue containing an unpatched vulnerability, credential, exploit payload, or sensitive infrastructure detail. Report through the organization’s approved private security contact and include the affected commit/deployment, impact, reproduction with secrets removed, and a safe response channel. If the contact is unavailable, escalate privately to the security owner and incident commander. Preserve evidence, minimize access, and avoid testing against production funds or identities without explicit authorization. Disclosure timing is coordinated by the security owner after containment, fix verification, and affected-party review.

​Security model

​Assets and authorities

​Public boundary

​Signer roles

​Key and credential classes

​Datastore boundaries

​RPC and provider assumptions

​Contract emergency paths

​Review and launch evidence

​Reporting a vulnerability