Wallets & Identity

Wallet architecture can move forward faster than the funds held under older wallet conventions.

That creates a practical problem.

A user may still have a valid recovery phrase from a wallet used years ago, while newer BSV Blockchain applications are increasingly being built around BRC-100 wallets and different approaches to transaction management, proofs and application connectivity.

BSV Passage is a new public project from Peer-to-peer Privacy Systems Research designed specifically around that transition.

Rather than attempting to become another general-purpose wallet, Passage acts as a guarded migration tool.

It takes supported historical wallet backups, identifies standard P2PKH outputs belonging to those backups, verifies the information needed to spend them and then hands the migration into a separate connected BRC-100 wallet.

The objective is simple:

bring old keys safely forward without making the recovery tool the user’s new wallet.

Several historical wallet conventions are recognized

Bitcoin wallets have not always derived keys in exactly the same way.

Different applications adopted different BIP-39 paths, seed formats, change conventions and wallet-specific variations over time.

Passage currently provides automatic profiles for several of those historical environments:

• Centbee
• RockWallet
• ElectrumSV and ElectrumSVP
• Exodus
• Coinomi
• Atomic Wallet
• Simply Cash

Those names do not all imply the same recovery method.

ElectrumSV, for example, may involve native Electrum v2 seeds or imported BIP-39 seeds. Coinomi used more than one relevant derivation path around the BCH/BSV chain history. Centbee’s supported recovery path also incorporates the original PIN.

The software encodes those known conventions so the user does not have to manually guess derivation paths until an address containing funds happens to appear.

But the catalogue also defines its limits.

BRC-42 wallets, current HandCash accounts, custodial services, multisig setups, hardware-specific policies, early non-standard Bitcore derivations and undocumented backups are not treated as ordinary automatic recovery cases.

That restraint is part of the design.

Passage is not attempting to recover anything that might plausibly contain keys.

It handles a constrained set of wallet formats for which the software can establish the conditions it expects before signing.

Recovery happens locally in the browser

The recovery phrase and any associated passphrase are processed inside the user’s browser.

Passage does not intentionally transmit or persist those secrets.

Once the seed has been validated, the visible phrase and passphrase fields are cleared and the software derives the relevant receiving and change addresses locally.

Public addresses do have to leave the browser for discovery.

Passage sends them to two independent services—WhatsOnChain and Bitails—to determine which outputs are currently spendable.

That leads to one of the project’s central safety rules:

the two providers have to agree.

If WhatsOnChain and Bitails return different outpoints or different values for the same wallet scan, Passage does not decide which provider is probably correct; it stops.

Two indexers must independently agree

Using two services is not intended to make either one authoritative.

The threat model explicitly treats both indexers as individually untrusted.

For every spendable output, they must independently return the same outpoint and satoshi value set before Passage will continue.

Even that agreement is not treated as sufficient by itself.

Passage then obtains the source transactions as BEEF evidence and checks the actual transaction information again.

The software re-derives the expected keys, reconstructs the P2PKH locking script and verifies that the script, value and outpoint correspond exactly to what was discovered during the scan.

Only then can the source output proceed toward signing.

The design therefore uses the indexers for discovery while attempting to verify the source transaction independently before spending it.

Some outputs are deliberately refused

Passage also imposes hard boundaries on what it will automatically sign.

An output must be confirmed.

It must use a standard P2PKH source script.

The transaction structure must contain exactly the inputs Passage expects, without missing, duplicated or unexplained additions.

Fee rates must remain within a defined range, and one reviewed action cannot contain more than 100 source inputs.

The project also refuses automatic migration of outputs created at or before BSV Blockchain’s split from BCH at block height 556,767.

That restriction is intended to avoid treating potentially replayable pre-split outputs like ordinary later funds.

Those cases require a separate reviewed chain-splitting process rather than a one-click migration.

The result is deliberately conservative.

Passage would rather refuse a recovery it cannot fit inside its safety assumptions than broaden its compatibility by silently weakening those assumptions.

The destination belongs to the BRC-100 wallet

Passage does not create a second permanent wallet around the recovered seed.

Instead, the connected BRC-100 wallet creates the destination output.

The historical inputs are presented as externally proven inputs, while the receiving output and any wallet-controlled change belong to the target wallet environment.

That produces a clear migration direction:

historical key convention → verified source outputs → current BRC-100 wallet

Once the migration has completed, the old recovery format does not need to become the basis for the user’s continuing application environment.

This is what distinguishes Passage from a conventional multi-format wallet restore.

The purpose is not primarily to make an old wallet usable again.

It is to move recoverable value out of the old convention and into infrastructure designed around the current wallet interface.

Preparation and broadcast are intentionally separate

Financial recovery software has another difficult problem: knowing what happened after the user presses the final button.

A transaction broadcast can succeed even if the software does not receive a clean success response.

If the user assumes that the transaction failed and immediately tries again, recovery software can create a confusing or conflicting second action while the first transaction may already be propagating.

Passage treats that ambiguity seriously.

Preparation and broadcast are separate actions.

Before broadcast, the user is shown the source value, destination value, fee, fee rate, number of inputs and outputs, and the expected transaction ID.

The user then separately authorizes the BRC-100 wallet to broadcast.

Passage does not send the transaction through the discovery indexers or through an additional broadcaster.

More importantly, submission is not treated as completion.

Another overlapping recovery remains blocked until the BRC-100 wallet marks the earlier Passage action as completed.

If broadcast throws an error or returns an unexpected or missing TXID, the documented instruction is not to try again automatically.

The user is instead expected to reconcile the precomputed TXID, source outputs and wallet action history until the network state is clear.

That is another example of the project’s fail-closed philosophy:

uncertainty does not become permission to try something potentially irreversible again.

The safety model still has limits

The repository is unusually direct about what its controls cannot guarantee.

Two indexers could agree because they share the same faulty upstream information or because both are compromised.

Public-address discovery necessarily reveals those addresses to the providers.

A compromised target wallet could construct a malicious destination.

Browser extensions, host malware or a compromised JavaScript runtime can still threaten secrets being handled locally.

A remote copy of an old wallet could also attempt to spend the same outputs.

The repository therefore labels Passage as financial recovery software and states that its defense-in-depth controls cannot guarantee against loss.

Its own guidance recommends beginning with the smallest verified output, independently confirming the result and using a reviewed local build before attempting migration of a meaningful balance.

That caution should remain part of how the project is understood.

Complementary to multi-path recovery wallets

BSV TIMES recently covered Kallubi BSV Wallet’s expanded support for historical wallet conventions.

The two projects address the same historical fragmentation from different directions.

Kallubi can restore several earlier derivation paths into its own desktop wallet environment.

Passage is designed around migration rather than continuing custody.

It identifies compatible historical outputs, proves and signs them under strict constraints and moves the result into another BRC-100 wallet selected by the user.

Both approaches reflect the same underlying reality.

The BSV Blockchain wallet ecosystem has existed long enough to accumulate several generations of key derivation and wallet architecture.

Moving toward common interfaces does not remove that history.

Migration and recovery tooling becomes part of the infrastructure needed to carry users from one generation into another.

Source-available, with a specific license boundary

The BSV Passage repository publishes its source under Open BSV License version 4.

The project explicitly notes that this is a BSV-use-restricted source license and should not be described as OSI-approved open source.

That distinction is worth preserving.

The availability of the source allows developers and technically capable users to inspect the recovery logic, tests, threat model and transaction-state handling.

But source visibility and an OSI-defined open-source license are not the same claim.

A bridge between wallet generations

The interesting part of BSV Passage is therefore larger than the list of historical wallets it recognizes.

BRC-100 is increasingly becoming a common application-to-wallet boundary across newer BSV Blockchain development.

Older wallet funds, however, may still sit behind seed formats and derivation conventions created years before that interface existed.

Those two worlds need a transition path.

Passage attempts to make that path narrow, inspectable and deliberately difficult to cross when the available evidence does not agree.

The old wallet provides the authority to spend.

Independent discovery sources identify candidate outputs.

BEEF supplies transaction evidence.

The migration engine checks the assumptions it knows how to verify.

And the destination is created by a separate BRC-100 wallet that can continue serving the user after Passage has finished its job.

That is a quiet but increasingly relevant form of wallet infrastructure:

not another place to keep funds, but a guarded route for moving them from yesterday’s wallet conventions into today’s application architecture.

Source: BSV Passage — GitHub

BSV TIMES — Under the Surface

Under the Surface looks at projects, standards, experiments, and community activity that may not rise to the level of a headline but are still worth noticing. Some are new, some are continuing work, and some are quieter developments that help show what is taking shape across the BSV community.

Update — September 30, 2026