Bitcoin Production Readiness: What Every Engineering Team Should Validate Before Launch

Why production is a different problem

A Bitcoin product can pass every staging test and still be unsafe to operate. Development hides the conditions that matter once real users, real funds, and real uptime are involved: fee spikes, node restarts, indexer lag, partial outages, operator error, and recovery under time pressure.

Bitcoin makes those conditions less forgiving than a typical web system. Transactions are irreversible. Keys are not an implementation detail — they are the asset. Nodes, backends, and indexers are coupled; if one of them lies, stalls, or is exposed, the product inherits that failure.

This note is the framework Greybound uses when assessing production readiness. It is written for engineering leads who need a clear picture of what to validate before launch — not a certificate, and not a generic security checklist.

What “ready” actually means

A Bitcoin system is production-ready when the team can answer four questions in writing:

• Operate — Can we run the node, backend, indexer, and signing path as a single system, with named owners and known failure modes?
• Observe — Will we notice a stalled tip, a signing failure, a backup that stopped, or a payment that confirmed on-chain but not in our database?
• Recover — If a host dies, a key is suspected compromised, or a deploy goes wrong, do we have a rehearsed path back — including restoring funds access?
• Fail without surprise loss — If a dependency is wrong or slow, does the product halt safely, or can it sign, pay, or display the wrong thing?

If any of those answers is “we think so” rather than “we have done this,” that is a launch risk. Unknown is not the same as fine.

What to validate before launch

The areas below are where production incidents concentrate. Under each one: why it matters, what typically breaks, and what to check before users depend on the system.

1. Scope and trust boundaries

Most launch risk is not a missing control. It is an unspoken assumption: which process is allowed to sign, which service is trusted for chain data, which environment holds keys, and what happens when those assumptions are wrong.

If the boundary is unclear, reviews and incident response both stall. You cannot harden a system you have not named.

Check

• Components in production: wallet/signing, node, indexer, backend, admin tools.
• What each component is trusted to decide (balances, confirmation, destination, fees).
• Which keys exist, where they live, and who can use them.
• What is explicitly out of scope for this launch.

2. Wallet architecture and key management

Weak key handling is the fastest way to lose customer funds. In production this is rarely a dramatic “hack.” It is more often a seed in a backup disk, a hot key that grew in responsibility, a recovery path that only one person understands, or a signing flow that can be asked to sign a different transaction than the user approved.

Multisig and PSBT do not make a wallet ready. They change the failure modes. If recovery, key ceremony, and spending policy are not written down and tested, the wallet is not ready.

Check

• Key generation, storage, and access — including backups and who can restore.
• Signing policy: what can be signed, by whom, with what review.
• Multisig / script design, change control, and recovery if a cosigner is lost.
• Whether logs, metrics, support tools, or CI can ever see seed material or raw keys.
• A restore test that has actually been run, not only documented.

3. Transaction and signing flows

Users judge a Bitcoin product by whether amounts, destinations, and confirmation states match what was signed. Production traffic adds fee spikes, replace-by-fee, stuck transactions, partial broadcasts, and retries. If the application retries blindly, it can double-pay. If it displays a destination from one source and signs another, it can send funds to the wrong place.

Lightning, swaps, and batching add more state machines. Each extra path needs an explicit failure and reconciliation story.

Check

• The exact bytes being signed match what the user (or policy) approved.
• Fee handling under congestion, including RBF/CPFP where you claim to support them.
• Idempotency: a retry cannot create a second payment.
• How stuck, dropped, or replaced transactions are detected and resolved.
• Reconciliation between wallet, node/indexer, and your ledger or database.

4. Node, RPC, and the data path

The product is only as correct as the chain view it consumes. A node that is stalled, pruned past what you need, or reachable from the public internet will not fail politely. RPC without tight authentication is still one of the most common production exposures we see.

Indexers and “API providers” sit on the same trust boundary. If the UI treats indexer data as confirmed truth, indexer lag becomes a payment bug.

Check

• Node configuration: network exposure, RPC bind, authentication, peers, pruning.
• Who can call RPC, from where, and whether that path is logged.
• Tip monitoring, reorg handling, and what the app does if the node is behind.
• Storage, backups, and a restore of chain state — not only of application data.
• Dependencies between node, backend, and indexer when one of them is wrong or down.

5. Backend, API, and indexing

Backend failures become production incidents because they sit between users and signing or settlement. Missing authentication on an internal proxy, secrets in environment files, unbounded RPC methods, and “confirmed” balances from a lagging indexer are typical.

Rate limits, audit logs, and input validation matter here for a concrete reason: they are often the only thing between the public internet and a wallet or node.

Check

• Authentication and authorization on every endpoint that can move funds or change policy.
• Secrets management: rotation, access, and whether secrets appear in logs or images.
• What the API will do if the indexer or node returns stale or contradictory data.
• Idempotency, pagination, and replay on payment and withdrawal endpoints.
• Logging that is useful in an incident without recording sensitive material.

6. Operations, recovery, and launch conditions

Operational mistakes cause as many incidents as software defects. Access that was temporary and never revoked. A deploy with no rollback. A backup that has never been restored. A paging path that goes to a chat no one watches on weekends.

Production readiness includes the human system: who is allowed to spend, who is paged, and what the first hour of an incident looks like when keys or funds might be involved.

Check

• Access control and least privilege across hosts, cloud, CI, and admin tools.
• Patching and dependency process for node software and anything that touches keys.
• Backup and restore drills, including wallet recovery and application state.
• Rollback plan for the last deploy that could affect signing or payments.
• Incident path: detect, contain, communicate, recover — written, not improvised.

How to use the checklist

Score the system honestly. For each item use one of three states: Done, Needs work, or Unknown. Unknown should be treated as needs work. A control you have not verified is not a control.

Then apply a simple launch rule:

• Anything that can lose funds, leak keys, or prevent recovery is a launch blocker until it is resolved or explicitly accepted in writing.
• Anything that can stall payments, hide a stalled node, or make an incident unworkable should be fixed before you take real volume — even if a limited beta is already live.
• Everything else becomes a sequenced list: what you will do before launch, what you will do in the first weeks after, and what you will not do yet.

Do not average the checklist into a percentage and call that “ready.” A single untested recovery path outweighs twenty completed items.

Patterns that show up before launch

These are not theoretical. They are the gaps that most often appear when a Bitcoin product is about to take real funds.

• Recovery exists on paper only. The procedure was written during setup and has never been executed against a current backup.
• The node is treated as plumbing. RPC is reachable more widely than intended, or nobody is paged when the tip stalls.
• Payments have no source of truth. Wallet, indexer, and database can disagree, and there is no reconciliation job that the team trusts.
• Secrets outlived the people who created them. CI variables, disk images, and old hosts still hold material that should have been rotated.
• There is no rollback for the signing path. Application deploys can be reverted; key and script changes cannot, unless that was designed in advance.
• Observability stops at HTTP 200. The API is up while broadcasts fail, fees are stuck, or confirmations are read from a lagging indexer.

When to get a Review

The checklist is for the team that owns the system. It will not replace an independent look at architecture, operations, and the places where a local workaround became a production path.

A Review is the right next step when the problem is not fully specified: you need findings, prioritized recommendations, and a clear picture of what is actually blocking launch. Implementation stays separate. If you already know the work — fix a signing flow, harden RPC, add monitoring, restore a broken recovery path — that is Remediation or Upgrades, scoped and approved on its own.

See Review, Remediation, and Upgrades →