Configuration ownership
Checked-in environment examples are schemas, not deployable values. Railway sealed variables own runtime values; deployment identity JSON owns chain/address configuration; service profiles own commands, health checks, and replica policy.Sensitivity classes
Shared identity and telemetry
The deployment identity artifact supersedes individually supplied chain/address values in qualified
environments. Every service must receive the exact same artifact for a release.
API
Source schema:apps/api/.env.example and apps/api/src/config.ts.
Indexer
Source schema:apps/indexer/.env.example and apps/indexer/src/config.ts.
Only indexer/Ponder may use the log-range configuration.
Keeper roles
Each role’s authoritative schema is the matching file inapps/keeper/env.
Startup rejects
SIGNER_KEYS for engine and auditor. Never reuse a keyring, signer pool, source token,
or metrics token across roles or environments.
Market data and frontend
Market-data configuration is owned byapps/market-data/.env.example: source mode/origin and cache,
circuit, notional, depth-band, freshness, four distinct route tokens, metrics token, and telemetry.
Route and metrics tokens are secret; numeric normalization policy is public. Production uses
independently governed sources rather than treating replicas as source diversity.
Frontend runtime configuration is generated from the public testnet API origin
https://api.testnet.tayho.io and WalletConnect metadata.
It receives no private service origin, database/Redis value, internal engine token, receipt secret,
or worker signer.
Change procedure
- Change the parser/type and its tests.
- Update the owning
.env.examplewithout a resolved value. - Update the Railway JSON profile or release wiring when shape changes.
- Update this registry and the affected architecture/runbook.
- Roll development, prove readiness and failure behavior, then qualify production.