Skip to main content

Local development

Prerequisites

  • Node.js 22.23.1 from the repository .node-version
  • Bun 1.3.13 from packageManager
  • Foundry with Solidity 0.8.28 support
  • Git with submodules initialized for contract dependencies
  • PostgreSQL and Redis when exercising durable coordination, API credentials, or multi-replica behavior
The repository is a Bun workspace orchestrated by Turborepo. Root build, test, typecheck, and lint tasks delegate to packages and apps; package-local commands are faster while iterating.

Workspace map

Use the checked-in .env.example and apps/keeper/env/*.env.example files as schemas. Copy into a gitignored local file and replace placeholders; never edit a template with a real credential.

Contracts: no-IR is mandatory

The default Foundry profile does not enable via_ir. This is a product constraint, not a local optimization:
Do not fix a stack-depth regression by enabling IR. Reduce function scope, use typed structs, or split logic while retaining ABI and invariant coverage. Generated protocol ABIs come from the current contract build:
Commit generated ABI changes with the Solidity change that caused them.

Local infrastructure modes

Unit mode

Most tests use memory adapters and deterministic fake RPC/fetch implementations. They require no network, database, Redis, signer, or Railway access.

Integration mode

Use local PostgreSQL and Redis for Drizzle migrations, queue/outbox behavior, API credential storage, transaction reconciliation, and multi-replica tests. Apply migrations explicitly before starting runtime processes:
Ponder uses local PGlite when DATABASE_URL is absent. Set its start block to the earliest deployed Tayho contract block; using a convenient later block creates an invalid projection.

Chain mode

Contract and runtime qualification can use a local Anvil/fork or the development HyperEVM deployment. Live signing tests use dedicated development wallets only. Never point local tests at production signers or production coordination stores.

Running services

Start only the roles needed for the flow. A typical read/API loop is indexer, API, and frontend. A relayed-action loop adds PostgreSQL, Redis, engine, and relayer.
Other keeper entrypoints are automation, oracle, attester, guardian, revenue, and auditor. Each process must use its matching environment template. Do not combine roles into one process or key pool.

Test layers

Run the narrow suite first, then the owning workspace suite, then root gates proportional to the change. Schema, deployment, signing, and public API changes require their focused integration suites.

Documentation preview

The first command previews anonymous content. The second includes engineering pages. Repository classification checks are necessary but do not replace the deployed partial-authentication acceptance gate.
Last modified on July 23, 2026