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.

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.

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.

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.

​Persistent data model

​API control domain

​Keeper coordination domain

​On-chain projection domain

​Migration ownership

​Retention and reconstruction