> ## Documentation Index > Fetch the complete documentation index at: https://docs.tayho.io/llms.txt > Use this file to discover all available pages before exploring further. # Security model > Tayho trust boundaries, privileged roles, key classes, datastore controls, review evidence, and compromise ownership. # 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`](https://github.com/Tay-Ho/app/blob/develop/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](/operations/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](/operations/security-review-scope) and [launch checklist](/operations/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.