> ## 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. # Data ownership and consistency > Authoritative stores, allowed writers, derived copies, and recovery rules for Tayho data. # Data ownership and consistency Every state class has one authority. Derived delivery systems can be discarded only when their authority and replay procedure are intact. ## Ownership matrix | Data class | Authority | Only writer | Readers / derived copies | | ------------------------------------------------------------ | -------------------------------------------- | ------------------------------------------------------------- | -------------------------------------------------- | | Protocol balances, positions, markets, vault, staking, roles | HyperEVM contracts | Contract-authorized transactions | Ponder projections, bounded RPC reads | | On-chain query projection and checkpoint | Isolated Ponder database | Single `tayho-indexer` writer | Indexer HTTP, API, auditor | | Signed intent terms and lifecycle | Coordination PostgreSQL | Engine within column/RLS grants; settlement fields by relayer | API capability reads, derived trigger indexes | | Relayed action lifecycle | Coordination PostgreSQL | Engine/relayer lifecycle transitions under grants | API receipt reads, indexed transaction correlation | | Jobs, attempts, outbox, worker state | Coordination PostgreSQL | Matching keeper identities | BullMQ delivery and operational tooling | | Signer allocation, nonces, transaction lineage | Coordination PostgreSQL | Relayer/signing worker under role grants | Reconciler and metadata-only operator tools | | API projects, keys, quotas, operator audit | API control tables in PostgreSQL | Internal API-key CLI / API credential store | API authentication cache | | Queue delivery, retry timers, leases | Redis/BullMQ | Coordination adapters | Workers; rebuild from PostgreSQL outbox | | Realtime replay and admission counters | Redis | Indexer pump/API admission | API replicas; rebuild/restart safely | | Normalized market-data response | Upstream facts plus deterministic normalizer | `tayho-market-data` in memory | Oracle and attester workers | | Audit findings and evidence | Coordination PostgreSQL audit tables | Auditor role only | Engineers and alerting | | Metrics, traces, structured logs | Observability backends | Service telemetry exporters | Grafana and incident tooling | Schema sources: [`keeper`](https://github.com/Tay-Ho/app/blob/develop/apps/keeper/src/db/schema.ts), [`indexer`](https://github.com/Tay-Ho/app/blob/develop/apps/indexer/ponder.schema.ts), and [`API control`](https://github.com/Tay-Ho/app/blob/develop/apps/api/src/auth/schema.ts). ## Consistency model ### Chain to indexer Ponder scans and handles logs in EVM order. A projection can include unfinalized blocks, so Ponder owns rollback and replay on reorg. Consumers use the returned checkpoint rather than assuming two separate reads saw the same block. No secondary service fills gaps with its own `eth_getLogs` loop. That would create competing event ordering, range policy, retry behavior, and reorg semantics. The auditor obtains event projections from the indexer and uses independent RPC quorum calls only for bounded state verification. ### Engine to relayer The engine commits immutable accepted terms, lifecycle state, a job, and an outbox delivery in one durable workflow. BullMQ is allowed to deliver more than once. An execution token, idempotency key, current-state simulation, and database transitions make delivery idempotent. The relayer persists signed transaction bytes and the assigned nonce before broadcast. Ambiguous RPC outcomes rebroadcast the identical bytes or a bounded same-nonce replacement. It never creates a new logical action to recover transport uncertainty. ### Confirmation to indexed `confirmed` means the transaction receipt met the configured confirmation policy. `indexed` means the indexer has correlated the canonical transaction. These are intentionally separate: indexer lag must not erase receipt status, while a reorg can still require transaction reconciliation. ### Snapshot to event stream Realtime establishes a stream boundary around an authoritative snapshot. At-least-once overlap is expected. Clients deduplicate event IDs and advance domain versions monotonically. Stream loss requires a fresh snapshot, not database reconstruction from WebSocket events. ## Failure and recovery properties | Loss or delay | Correct response | | ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | Redis/BullMQ loss | Drain, restore Redis, republish stable delivery IDs from PostgreSQL outbox, verify idempotency, resume gradually | | Indexer lag | Continue receipt-capability status through `confirmed`; pause claims of indexed freshness; never add another log scanner | | Coordination PostgreSQL unavailable | Stop intake/execution that requires durable state; do not fall back to Redis | | One RPC provider unavailable | Use health-scored fallback/quorum; fail closed when chain identity or majority cannot be established | | Realtime replay gap | Send `resync_required`, replace state from snapshot, resume from the new sequence | | Observability unavailable | Avoid blind risky rollout; application authority remains in chain/PostgreSQL | ## Database privilege boundary The migration job alone owns schemas. Runtime, engine, relayer, auditor, API, and indexer identities receive only their required tables, columns, sequences, and operations. Engine cannot read signed transaction ciphertext; relayer cannot rewrite accepted intent terms; auditor cannot mutate signing-role jobs or encrypted transactions; indexer cannot access coordination state. Backups must preserve the coordination and indexer logical databases as independent recovery domains even when hosted on the same managed PostgreSQL service.