TTN source support alone does not establish that published packages or deployed
images support TTN. Verify exact released artifacts and deployment evidence;
merging source does not authorize a package release, image build, or deployment.
- Publish the reviewed TTN package candidates through the OIDC release
workflow, beginning with
@bsv/sdk and then its affected dependents.
- Reconcile every infrastructure package manifest and lockfile to verified
TTN-capable versions, including overlay, wallet, Message Box, WAB, ChainTracks,
and UHRP. A source workspace dependency does not prove image contents.
- Rebuild Linux/amd64 images in CI, retain their immutable digests and
attestations, and run the container smoke and vulnerability gates.
- Provision a dedicated TTN Message Box endpoint. TTN clients intentionally
require an explicit
host until this exists; the existing staging Message
Box is testnet and must not be reused as a TTN default.
- Provision and validate a TTN overlay discovery root before advertising
production-like services. Do not use a testnet overlay host as a TTN root.
- Deploy the staging environment with
ttn/teratestnet selected explicitly,
then validate health responses, reported chain identity, transaction
broadcast, proof acquisition, SHIP/SLAP isolation, Message Box delivery, and
wallet storage before promoting any workload.
- TTN broadcasting uses Arcade's EF
/tx contract. The incompatible legacy
ARC BEEF /v1/tx provider is not registered as a TTN fallback.
- BRC-100 wallets still report
testnet for test-family chains, so every
overlay-facing TTN component must receive teratestnet explicitly.
- Mainnet, testnet, and TTN deployments use separate configuration, storage,
discovery roots, credentials, DNS, certificates, databases, and image
promotion records.
- Rollback restores the previous immutable image digests and configuration; it
never redirects TTN traffic into testnet or mainnet infrastructure.
Until all gates above have exact-main evidence, keep TTN workloads undeployed.