An emerging Bitcoin protocol should be evaluated by asking what it changes, who enforces it, what evidence exists, and what happens when its assumptions fail. The name of a project, the presence of transactions on Bitcoin, or the publication of a BIP does not answer those questions.
“Built on Bitcoin” can describe many different systems: a consensus proposal, a node-policy change, an application protocol using ordinary transactions, an indexer-derived ledger, a bridge, a sidechain, a wallet convention, an experimental proof system, or software that merely anchors data to Bitcoin. Bitcoin enforces different, often narrow parts of these systems. Their remaining security, custody, availability, governance, and operational properties come from other components rather than being inherited automatically from Bitcoin.
A useful evaluation therefore begins by separating layers before comparing features.
Start with the exact artifact and date
Record what is being evaluated: a paper, BIP, specification commit, software release, pull request, testnet deployment, mainnet application, hosted service, or marketing page. Record the date, version, commit, and network.
This prevents “the protocol” from becoming a moving target. A paper can describe a design not yet implemented. A repository's default branch can differ from its latest release. A public demo can use signet parameters that do not exist on mainnet. A website can summarize capabilities more broadly than the code supports.
Primary evidence should be preferred. For consensus proposals, use the current BIP and implementation discussion. For software behavior, inspect release notes, source, tests, and configuration. For a deployed application, inspect its actual contracts, transactions, binaries, operator documentation, audits, and incident record.
Date every maturity or adoption statement. “Currently,” “supported,” and “live” become unreliable without a review date and a defined environment.
Classify the layer
The first classification is what kind of rule or system is involved.
A Bitcoin consensus rule is enforced by validating nodes when they accept transactions and blocks. Changing it requires a network rule change, not merely an application release.
Bitcoin Core behavior can include consensus implementation, wallet behavior, mempool policy, relay defaults, mining interfaces, and RPCs. Not every Bitcoin Core default is a Bitcoin consensus rule. Other compatible implementations may make different policy or interface choices while enforcing the same active consensus rules.
A BIP is a proposal or standard document. BIP 3 states that BIPs do not define Bitcoin or represent community consensus. Its workflow distinguishes Draft, Complete, Deployed, and Closed. A Complete consensus proposal can remain undeployed indefinitely.
An application protocol uses active Bitcoin rules without changing them. DLCs are one example: Bitcoin validates funding and closing transactions, while DLC software interprets oracle announcements, adaptor signatures, contract messages, and payout mappings.
An application-derived system reconstructs state from Bitcoin data according to additional rules. Ordinals, Runes, and BRC-20 indexers are examples of the broader category. Bitcoin consensus validates the underlying transactions but does not maintain those application balances or identifiers.
A bridge or sidechain adds another system and a custody or verification boundary. The bridge's Bitcoin transactions may be valid even if the external state machine, operator accounting, or wrapped asset fails.
An experimental project can have papers, code, and public transactions while remaining unsuitable for production. Classification should describe what exists, not what the roadmap intends.
Identify the enforcement point
For every important rule, ask who rejects a violation.
If every fully validating Bitcoin node rejects it, it is an active consensus rule. If ordinary nodes accept the transaction but one application ignores it, the rule is application-derived. If a federation refuses a withdrawal, it is federation policy. If a wallet refuses to construct a transaction, it is wallet behavior. If a hosted API filters results, it is service behavior.
This exercise often exposes ambiguous claims. “Bitcoin verifies the proof” may mean a Tapscript spend checks a verifier script. It does not necessarily mean Bitcoin nodes understand the external program, bridge ledger, or destination chain.
Create an enforcement table listing each claim, the enforcing component, the data it reads, the failure response, and whether another implementation can disagree while remaining Bitcoin-consensus compatible.
Then test disagreement. What happens when two indexers compute different balances, two wallets use different policy, or a bridge operator and challenger follow different external-chain tips? The protocol needs a resolution rule beyond saying that data is “on Bitcoin.”
Separate active features from proposals
Consensus proposals deserve especially careful language. A BIP number, reference implementation, test vectors, or Complete status is evidence of specification maturity. It is not activation.
BIP 347 illustrates the distinction. As of July 24, 2026, it is a Complete soft-fork proposal for OP_CAT in Tapscript. Current mainnet Tapscript still treats the target byte as OP_SUCCESS126, and current legacy or SegWit v0 execution keeps OP_CAT disabled. A guide should not describe OP_CAT as an available mainnet opcode unless deployment evidence changes.
The same method applies to covenant proposals, new signature hashes, peer-to-peer features, or policy changes. State the proposal identifier, exact status, implementation branch, activation design if one exists, and observed network state.
Avoid predicting inevitability. Bitcoin has no central approval body that turns a BIP into consensus. Deployment requires implementation and coordinated adoption appropriate to the proposal.
Map custody and control
For any system involving bitcoin, identify which keys or scripts control the actual UTXOs.
In self-custody, the user may hold keys satisfying the output's spending conditions. In a federation, threshold signers may control a shared output. In a bridge, operators may advance liquidity while another transaction system governs reimbursement. In a hosted account, the user may hold only a contractual claim against a custodian.
Terms such as “trustless,” “non-custodial,” and “trust-minimized” should be replaced or supplemented with a concrete key and failure map. List who can move funds, freeze exits, delay transactions, upgrade rules, censor requests, or recover from lost keys.
Also identify setup assumptions. Some systems depend on pre-signed transactions, key deletion, a ceremony, a common reference string, hardware security modules, or an honest threshold at initialization. A design can reduce ongoing trust while retaining significant setup trust.
Control can change over time. Emergency keys, upgrade keys, rotating federations, and recovery paths must be included, not treated as operational footnotes.
Define the state and data source
Ask what state the protocol maintains and where that state comes from.
Bitcoin-native state includes the accepted block chain and UTXO set under active consensus. An application may derive additional balances, names, inscriptions, contract records, proof commitments, or bridge liabilities. A side system may maintain accounts or smart-contract storage not visible to Bitcoin nodes.
Document the canonical data source and ordering rules. Does the protocol follow Bitcoin block order, transaction order, output order, an external sequencer, oracle timestamps, or a hosted database? How are reorganizations rolled back? How are unconfirmed replacements handled?
If state depends on an indexer, specify the parser version, database schema, rollback logic, and rebuild process. If state depends on an oracle, define the event encoding, signing key, nonce handling, measurement method, and correction policy.
“On-chain” is too broad to answer these questions. Data can be included in a Bitcoin transaction while its meaning remains entirely application-defined.
Evaluate data availability
A participant must be able to obtain the data needed to verify state, challenge a claim, or exit.
A proof may demonstrate that some hidden witness exists without supplying the transaction history a user needs. A bridge may publish commitments to Bitcoin while keeping batch data elsewhere. An indexer may require old block data that a pruned node no longer serves. A rollup-like system may depend on a sequencer or data-availability network.
List the minimum data required for each safety action. Identify who publishes it, where it is retained, how long it remains accessible, and whether users can reconstruct it independently.
Then test withholding. If an operator stops publishing data, can users exit with locally retained information? Can a challenger prove fraud? Can a new node synchronize? Does the protocol become safe but unavailable, or can funds be lost?
Availability claims should distinguish Bitcoin block inclusion, archival retention, indexer access, hosted APIs, and user backups.
Examine the exit and failure paths
The normal path is rarely the security-critical path. Trace failure scenarios.
What happens if counterparties disappear? If an oracle never attests? If a bridge operator refuses a withdrawal? If a challenger is offline? If a sequencer withholds a batch? If an external chain reorganizes? If a transaction misses its timelock window? If fees rise sharply?
A credible design supplies unilateral or threshold exit procedures with concrete transactions, data, deadlines, and fee assumptions. It also states where no unilateral exit exists.
Time-sensitive paths should be evaluated under realistic confirmation uncertainty. Consensus-valid transactions can still face relay-policy rejection, pinning, low fee rates, miner policy, or congestion. Pre-signed transactions may have limited fee-bumping options.
Recovery procedures need tests. A diagram showing a refund or emergency path is weaker evidence than an implementation test that constructs, signs, broadcasts, and confirms it under the current network rules.
List cryptographic and economic assumptions
Bitcoin's proof of work and signature rules do not replace every assumption in a higher-layer protocol.
Using Bitcoin for settlement, timestamps, commitments, deposits, or data publication does not make an external state machine, bridge, indexer, sequencer, oracle, proof system, or operator set share Bitcoin's consensus security. State exactly which Bitcoin transaction or script rule is enforced and which failures remain outside that boundary.
A project may rely on collision resistance, discrete-log hardness, a proof system's soundness, a trusted setup, adaptor-signature security, threshold-signature protocols, secure enclaves, or assumptions about an external virtual machine. Name each assumption and its implementation.
Economic security adds another layer. An optimistic system may assume a challenger will monitor and can profitably respond. A bridge may require operator collateral or liquidity. A channel system may require watchtower availability. Penalties must exceed plausible gains after fees and capital costs.
Model who pays to remain honest and who profits from failure. Include fee spikes, locked capital, challenge rewards, liquidity shortages, and griefing attacks that impose costs without directly stealing funds.
“Cryptographically verified” and “economically secured” are not complete descriptions unless the verified statement and incentive model are explicit.
Inspect code, tests, and release discipline
A repository is evidence of implementation effort, not security.
Check whether the code corresponds to the current paper or specification. Look for tagged releases, reproducible builds, dependency pinning, test vectors, integration tests, fuzzing, static analysis, continuous integration, and documented upgrade procedures.
Search for explicit warnings. The official BitVM implementation repository, for example, warns not to use it in production as of the review date. That warning outweighs promotional interpretations of a public demo.
Audits should be scoped precisely. Record the commit, components, assumptions, findings, remediation status, and whether the deployed binary matches the audited code. An audit of a cryptographic library is not an audit of bridge economics or operational key management.
Also review issue trackers, pull requests, and incident reports. Mature software can still be risky, but visible handling of failures is more informative than an unqualified “battle-tested” label.
Test interoperability and version boundaries
Protocols with multiple implementations need shared test vectors and cross-implementation testing.
Two projects can use the same name while disagreeing on serialization, rounding, transaction ordering, fee handling, oracle formats, proof inputs, or reorganization behavior. A “compatible” claim should name the versions tested and the cases passed.
Version negotiation matters for long-lived contracts. A DLC oracle may announce an event far in advance. A bridge deposit may remain open across software upgrades. An indexer may need to reproduce historical rules after a parser change.
Ask whether upgrades are backward-compatible, opt-in, centrally imposed, or coordinated by a federation. Determine what happens to existing funds and contracts when one participant upgrades first.
Application-derived systems should preserve historical interpretation rules or document migrations. Silent reinterpretation of old transactions can change displayed balances even though Bitcoin history is unchanged.
Examine governance and upgrade authority
Every evolving system has a change process, even when it avoids the word governance.
For Bitcoin consensus, no single maintainer or repository controls activation. For an application, maintainers may release new code, but users, operators, indexers, or signers decide what to run. A hosted service can change behavior unilaterally for its customers.
Identify who can change contracts, keys, fee parameters, oracle sets, sequencers, challenge periods, parsers, or supported assets. Check whether changes require user migration or apply automatically.
Emergency authority deserves special attention. An emergency pause can reduce losses during an incident but creates censorship and custody power. An upgrade key can fix bugs but can also change rules or redirect funds.
Governance claims should be based on actual control paths and deployment procedures, not token voting pages, organizational labels, or informal community language.
Verify adoption and performance claims
Adoption is not one number. A project can count addresses, transactions, deposits, wallets, nodes, or API requests, each with different meaning.
Prefer reproducible on-chain or published operational data with a date and method. Separate testnet from mainnet, unique users from addresses, gross deposits from current liabilities, and peak throughput from sustained finalized throughput.
Performance claims need workload definitions. Transactions per second can exclude data publication, settlement, bridge exits, proof generation, or Bitcoin confirmation time. Low fees may be subsidized or depend on centralized batching.
Do not infer safety from total value, transaction count, investors, partners, or longevity. Those can show use, not correctness. Conversely, low adoption does not disprove a design; it limits the operational evidence available.
When evidence cannot be independently reproduced, label the claim as project-reported.
Use a claim-evidence matrix
A practical review can be organized into a matrix with five columns:
- the exact claim;
- the layer or component;
- the primary evidence;
- the review date and version; and
- the remaining uncertainty.
For “OP_CAT is available,” the active-rule evidence contradicts the claim: BIP 347 is Complete but not Deployed. For “BitVM runs arbitrary programs on Bitcoin,” the more precise evidence says computation occurs off-chain and Bitcoin handles defined dispute verification; the implementation remains a developer preview. For “DLCs are Bitcoin smart contracts,” the matrix should explain that Bitcoin validates ordinary transactions while DLC software and oracles supply the contract semantics.
This format prevents a source from being stretched beyond what it supports. A paper can support the intended security model. A repository can support implementation status. A block explorer can support that transactions occurred. None alone proves the complete production claim.
Uncertainty is an output, not a failure. A good review identifies which questions remain open and what evidence would resolve them.
A repeatable evaluation sequence
Begin with classification: name the artifact, network, version, layer, and enforcement point.
Continue with control: map keys, custody, setup, upgrades, and emergency authority.
Then map state and information: identify the canonical history, parser, oracle, sequencer, data-availability path, and reorganization behavior.
Trace every exit: cooperative, unilateral, timeout, refund, challenge, recovery, and failure. Include fees and confirmation timing.
Review security evidence: cryptographic assumptions, economic incentives, code quality, tests, audits, incidents, and cross-implementation results.
Finally rewrite the project's main claims in precise language. Replace “secured by Bitcoin” with the exact rules Bitcoin enforces. Replace “decentralized” with the operator and key distribution. Replace “live” with the network, release, and date. Replace “trustless bridge” with its custody, challenger, setup, and data assumptions.
This process does not decide whether innovation is good or bad. It makes the system legible enough for readers to understand what is currently true, what is proposed, and what remains uncertain.