Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Testnet execution (optional, opt-in)

Testnet is never part of ordinary CI (spec §30). It requires an explicitly configured public network, funded accounts, and deployed contracts, so it is always selected by an operator, never by default.

The adapter

crates/adapters/testnet provides the opt-in surface:

  • configuration — validated network settings with an explicit enabled/network gate; without configuration nothing attempts a connection,
  • polling — deterministic poll/backoff logic over a configurable interval, so scenario steps can wait on transaction status without blocking the runner,
  • execution — translation of the scenario’s operation vocabulary into the network’s submission surface (the transport itself is the operator’s wiring).

The adapter is hermetic and unit-tested (no network in tests), exactly like the other adapters.

Running it

# Build + unit-test the adapter, skip network execution (default path):
scripts/run-testnet.sh

# Provide explicit configuration to move past the skip:
export CRUCIBLE_TESTNET_CONFIG='{ "network": "futurenet", ... }'
scripts/run-testnet.sh

CI’s testnet.yml is workflow_dispatch-only: it builds the adapter, runs its hermetic tests, and skips (with a notice) unless a TESTNET_CONFIG secret is present. It can never fail the default PR path.

Scenario posture

Testnet scenarios are tagged testnet, target Environment::Testnet (which is isolated), require explicit capabilities, and are not required by any ordinary CI gate. A scenario that cannot run honestly in the current environment is skipped deliberately — never silently mis-executed.