> ## 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. # Persistent data model > API control, keeper coordination, intent/action lifecycle, Ponder projections, migrations, and retention. # Persistent data model Tayho has three persistent domains: API control, keeper coordination, and on-chain projection. Redis is not a fourth authority. ## API control domain Owner: API Drizzle schema and internal API-key CLI. | Table group | Tables | Purpose | | -------------- | --------------------------------- | --------------------------------------------------------------------------------------------- | | Projects | `tayho_api_projects` | Named environment-bound customer/project lifecycle | | Quotas | `tayho_api_project_quotas` | Read/live/realtime/submission and sponsored-gas policy | | Keys | `tayho_api_keys` | Lookup ID, display prefix, one-way secret hash, scopes, restrictions, status, expiry/rotation | | Operator audit | `tayho_api_operator_audit_events` | Immutable project/key administrative actions and reasons | Key plaintext is returned once at creation and is not stored. The API uses a short positive cache; revocation and suspension remain database-authoritative. Source: [`apps/api/src/auth/schema.ts`](https://github.com/Tay-Ho/app/blob/develop/apps/api/src/auth/schema.ts). ## Keeper coordination domain Owner: keeper Drizzle schema; migrations and database grants define sub-ownership. | Table group | Representative tables | Purpose | | ----------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- | | Schema/runtime identity | `schema_metadata`, `worker_instances`, `worker_instance_signers`, `worker_signer_history` | Migration version, active processes, drains, build/signer evidence | | Signer admission | `signer_lanes`, `signer_pool_cursors`, `signer_nonces` | Durable drains, fair pool selection, serialized nonces | | Work | `jobs`, `job_attempts`, `outbox` | Idempotent logical work, fenced attempts, transactional queue delivery | | Transactions | `transactions` | Encrypted signed bytes, deterministic hashes, fees, receipts, replacement/reorg lineage | | Audit operations | `audit_events`, `protocol_audit_runs`, `protocol_audit_findings`, `protocol_audit_evidence` | Operator/runtime audit trail and invariant findings | | Audit projection | `audit_projection_checkpoints`, `audit_chain_events`, `audit_projection_subjects` | Auditor-owned materialization consumed from the indexer projection | | Intents | `intents`, `intent_events`, `intent_account_snapshots`, `intent_reservations`, `intent_cancellations`, `intent_index_outbox`, `intent_validation_snapshots` | Immutable signed terms, private lifecycle, trigger/reservation/account evidence | | Relayed actions | `relayed_actions`, `relayed_action_payloads`, `relayed_action_events` | Immediate action identity, encrypted/signed payload, lifecycle history | | Engine controls | `engine_market_controls`, `engine_checkpoints` | Intake/market policy and durable progress | Relationships: * one logical job has many immutable attempts and zero or more same-nonce transaction lineage rows; * one outbox row delivers one stable logical delivery into BullMQ; * one intent/action has append-only events plus a current lifecycle row; * an intent can hold reservations/cancellation state and emit reference-only relayer jobs; * a signer lane and nonce row serialize all replicas using that address. Source: [`apps/keeper/src/db/schema.ts`](https://github.com/Tay-Ho/app/blob/develop/apps/keeper/src/db/schema.ts). ## On-chain projection domain Owner: one Ponder writer per deployment schema. The schema currently contains these groups: | Group | Projection purpose | | ----------------------------------- | ---------------------------------------------------------------------------- | | Markets/events | Listing, risk bounds, status, pause, resolution, TWAP | | Positions/events/settlements | Current position plus exact ordered partial/full settlement history | | Funding markets/updates/settlements | Published intervals, cumulative indices, reserves, settlement legs | | Sessions/events | Active session bounds, spend, generation, authorization/revocation | | Orders/events/OCO | Canonical on-chain execution, cancellation, and OCO consumption | | Protocol configuration | Worker signers, risk/fee/emission settings, caps, roles, addresses, changes | | Vault/claims | Vault accounting, events, senior FIFO claim queue | | Staking | Global state, accounts, rewards, stake/unstake/claim events | | Oracle | Assets, funding attestations, configuration, funding attesters, asset events | | Token | TAYHO balances and transfers | | Maintenance | Per-item batch execution outcomes | Every history row carries chain/block/transaction/log identity. Current tables retain the block and transaction that last updated them. Ponder owns rollback and replay. Source: [`apps/indexer/ponder.schema.ts`](https://github.com/Tay-Ho/app/blob/develop/apps/indexer/ponder.schema.ts). ## Migration ownership * Generate API migrations with `apps/api db:generate`; check and apply them with the API Drizzle config. * Generate keeper migrations with `apps/keeper db:generate`; the one-shot migration service applies them under advisory lock and verifies least-privilege grants. * Ponder manages deployment-isolated schemas and stable views; do not hand-author application migrations against an active Ponder schema. * Runtime services never receive schema-owner credentials or run migrations at startup. Schema changes must be forward-deployable with the current release workflow. Because Tayho is pre-launch, remove obsolete fields and update all callers atomically rather than retaining shadow columns or compatibility reads. ## Retention and reconstruction Keep immutable intent/action events, transaction lineage, operator/audit evidence, and signer history for their configured compliance/incident window. Do not delete active ciphertext while a nonterminal job, receipt, replacement lineage, reorg lookback, or key-retirement proof depends on it. BullMQ jobs, Redis indexes, admission counters, leases, and realtime events are reconstructable. After Redis loss, the PostgreSQL outbox republishes stable delivery IDs; authoritative snapshots reseed realtime. PostgreSQL and Ponder require PITR, backups, and restore drills as separate logical recovery domains.