pBTC: a trust-minimized Bitcoin → PulseChain bridge

Giving Bitcoin holders permissionless access to PulseChain DeFi — verified by math, not by a custodian.

01 The problem

Bitcoin is the deepest, most secure pool of value in crypto, yet it is largely idle. For many holders one question remains: how do I move my assets across chains to make them more useful while keeping Bitcoin's core values? The dominant answer today is the custodial wrapper — you send BTC to an intermediary, and it mints an IOU token on another chain. That model reintroduces exactly what Bitcoin was designed to remove: a trusted third party that can be censored, coerced, hacked, or simply choose to freeze your funds. It threatens Bitcoin's promise of secure, permissionless decentralization.

The history of cross-chain bridges makes the stakes concrete. Bridges have been among the most exploited components in the entire industry, with roughly $1.5–2 billion lost in 2022 alone. A fact-checked reading of the research literature shows the losses cluster around a few causes: custody-key compromise (Ronin, Multichain, Harmony), faulty initialization and upgrade logic (Nomad), and weak proof validation. Any credible bridge design has to confront these failure modes directly rather than paper over them with marketing.

02 What pBTC is

pBTC is the PulseChain-branded user experience for a decentralized Bitcoin bridge. It is a fork of Threshold Network's tBTC v2 — a mature, audited, production Bitcoin bridge protocol — retargeted to PulseChain (mainnet chain 369, testnet chain 943). We use tBTC v2 because reinventing a Bitcoin bridge from scratch would discard years of adversarial hardening; instead pBTC inherits its cryptography and adapts the deployment and off-chain services to PulseChain.

We are deliberately transparent about that lineage. Where an on-chain contract, token symbol, or explorer entry uses tBTC naming, pBTC surfaces that exact value so users can reconcile what the UI claims with what is actually deployed. The brand is pBTC; the infrastructure is powered by tBTC v2, and we never imply the contracts are something other than what is on-chain.

03 Design overview

pBTC follows tBTC v2's core mechanism. A Random Beacon and an on-chain weighted Sortition Pool select governable-sized threshold-ECDSA Bitcoin wallets — starting at 51-of-100 — and rotate them on a governable schedule (starting weekly). The youngest wallet accepts new deposits; the oldest serves redemptions. Because the signing set is a rotating, randomly selected majority rather than a fixed multisig, no single operator — and no static group — can unilaterally move deposited Bitcoin. Users rely on math and a distributed operator set, not on hardware or the goodwill of any one company.

The lifecycle in three steps:

1. Deposit. A user sends BTC to a deposit address controlled by the current threshold-signing wallet.
2. Prove. The deposit is proven to the PulseChain contracts with an on-chain SPV proof (see §04). Verification is done by a light client, not by an operator vote.
3. Mint / redeem. A proven deposit grants a transferable bank balance, which mints a supply-pegged ERC-20-style token, pBTC, on PulseChain. Redemption burns pBTC and instructs the wallet to release the underlying BTC to a Bitcoin address.

Crucially, the design keeps the two hard security jobs — verifying that a deposit happened and holding the keys that move the Bitcoin — separate, and assigns each to the mechanism best suited to it. Conflating them is precisely how many bridges have failed.

04 SPV proofs: verification by math

The strongest component pBTC inherits is on-chain SPV (Simplified Payment Verification). Rather than asking a committee to attest that a Bitcoin deposit occurred, pBTC embeds a Bitcoin light client — LightRelay.sol — directly in the PulseChain contracts. This is "native" verification, the most trust-minimized category on the security spectrum.

How it works:

• Header validation. LightRelay validates Bitcoin block headers on-chain — checking double-SHA256 proof-of-work against the encoded bits target and handling the 2016-block difficulty retarget. It is self-contained in pBTC with no external dependency.
• Inclusion proof. The bridge verifies that a deposit transaction is included in a validated block via a Merkle inclusion proof against the stored epoch difficulty.
• Careful genesis. The relay is initialized (genesis()) from a recent, deeply confirmed BTC header with the correct epoch difficulty. Initialization correctness is a Nomad-class risk and is tested against Bitcoin testnet headers first.
• Relay maintenance. An off-chain maintainer bot feeds new headers and calls retarget() each ~2016-block (~two-week) epoch, gas-refunded from a reimbursement pool. This bot does not yet exist in the repository and is being built.
• Conservative confirmations. minConfirmationsCount is set to at least six Bitcoin confirmations at launch, to be tuned against PulseChain's reorg and finality characteristics.

At launch, minting requires a full SPV proof and the optimistic-minting shortcut (TBTCOptimisticMinting) is disabled — it trades safety for speed and would add a minter/guardian trust assumption pBTC does not need on day one. The proof path is specifically audited against two classes of attack: problematic minting (minting more than the proven deposit — mitigated by exact-amount checks) and proof replay (reusing a valid proof to drain repeatedly — mitigated by nullifier / used-proof tracking).

05 Trust model: honest by construction

No bridge is trustless. Zamyatin et al. (Financial Cryptography 2021) prove that correct cross-chain communication is impossible without some trust assumption. Every Bitcoin bridge — tBTC and pBTC included — is trust-minimized, never trustless, and we will say so plainly rather than market otherwise. The useful question is not "is it trustless?" but "exactly what are you trusting, and how much?"

pBTC answers that by splitting security into two jobs:

• Verification — proving a deposit really happened. Handled by on-chain SPV (§04). This is math, and it is pBTC's strongest inherited component.
• Custody — holding the BTC keys and signing to move funds. This is the honeypot and the genuinely hard problem. Roughly half of all bridge losses are custody-key compromise — Ronin (a 5-of-9 set, ~$625M), Multichain (all validators on one person's cloud account, ~$231M), Harmony (2-of-5, ~$100M). No quantity of verifiers fixes weak custody.

The target architecture assigns three layers accordingly:

Custody is the one place pBTC is not trust-minimized, and the roadmap is explicit about it. If the full keep-core operator network (Random Beacon + sortition + threshold-ECDSA + staking economics) is not ready at launch, interim custody must be a high-threshold, independently hosted (never one person or one cloud — that was Multichain), HSM/MPC-backed set with tiny caps, disclosed publicly as the trust assumption. Custody then migrates toward the full threshold network over time, with deposit caps gated on that decentralization. A further honest caveat from the research: operator rotation raises the bar against collusion but is not a collusion guarantee — it must be paired with slashing.

06 Liveness vs. mint security — a distinction that matters

The testnet and the transparency dashboard surface a "guardian liveness" gate. It is essential to be precise about what that signal is and is not, because conflating them is a subtle but dangerous error.

This is also why the guardian layer is designed as a veto + pause + header-relay layer rather than a verifier layer. If minting already requires a cryptographic SPV proof, then a thousand guardians re-attesting the same deposit would add only a social layer on top of a mathematical one — not real security. But as a layer that independently submits BTC headers (removing the relay's single-maintainer liveness risk), re-checks every mint and custody action against the Bitcoin chain, and can veto fraud and trigger a pause, breadth genuinely strengthens the system. That is exactly where a large guardian count belongs. Guardians are bonded to validator stake for Sybil resistance and are rewarded from bridge fees and slashed for attesting to (or failing to veto) fraud — because pure-altruism guardian sets decay.

The critical caveat: Layer 3 strongly secures the minting direction (no pBTC without real BTC), but it does not by itself stop custody theft. "A thousand guardians" must never create a false sense that custody is solved — that remains Layer 2's job.

07 Roadmap to mainnet

A tBTC fork is emphatically not "just deploy the contracts." The contracts are only half the system; a real deployment needs an off-chain layer — Bitcoin nodes, a relay-maintainer bot, guardian sidecars, and eventually the full keep-core operator network for non-stubbed custody. pBTC currently ships contracts plus a mock API. The path forward is phased and gate-driven:

• Phase 0 — Decisions. Trust model, custody phasing, and incentive mechanism (the security roadmap).
• Phase 1 — De-mock + real SPV on testnet. Genesis LightRelay, build the maintainer bot, require full-proof minting, and add automated deterministic end-to-end tests in CI (regtest BTC + hardhat + relay + test signer running deposit → SPV proof → mint → redeem → payout in one command).
• Phase 2 — Guardian sidecar. Validator-run watchtower with veto, pause, and header submission; incentives and slashing; registration bonded to validator stake.
• Phase 3 — Safety rails + custody hardening. Pause, caps, upgrade timelock, and either HSM/MPC multi-host interim custody or the start of keep-core migration.
• Phase 4 — Audits + bug bounty + long public testnet. Non-negotiable.
• Phase 5 — Guarded mainnet. Tiny caps, gradual ramp, real-time monitoring, one-button pause.
• Phase 6 — Decentralize custody. Migrate toward the keep-core threshold network, raising caps as decentralization increases.

Before any mainnet mint, all of the following gates must be true (none optional):

• Full on-chain SPV proof required to mint; optimistic path disabled.
• Custody is distributed and slashable, on no single host or cloud, HSM/MPC-backed, with deposit and TVL caps that start tiny.
• The guardian/watchtower set is at quorum with real veto teeth and slashing.
• Pausability, an upgrade timelock plus governance multisig, redemption guarantees, and rate limits are in place.
• At least two independent audits of the fork's diff — the stub-to-real registry change, deploy/init logic, the mint/burn and SPV path, and the API — plus an economic review of custody.
• A public bug bounty is live and a long public testnet has run with no criticals.
• The trust model is publicly disclosed: what is trust-minimized versus trusted.

The testnet phase is the point, and it is designed to be run exhaustively: automated e2e on every change, plus deliberate fraud-injection and chaos drills — try to mint without a real deposit (guardians must veto), submit a forged or replayed SPV proof (must be rejected), stall a relay maintainer (headers must keep flowing from other validators), stall redemptions (watchtower must alarm and pause), and compromise a single testnet signer key (the threshold must hold). Bank, mint, and burn accounting are covered by invariant and fuzz testing.

08 Risks

Honesty about risk is a core design value, not a footnote.

• Mainnet is not live. No funds can be bridged today. The testnet is a mock demonstration — no real Bitcoin, no on-chain minting, no custody.
• Cross-chain bridges are high-risk. They are historically among the most-exploited components in crypto. The dominant real-world loss is custody-key compromise, which no amount of verification fixes.
• A fork's upstream audit does not cover its diff. pBTC's own changes — the stubbed WalletRegistry, modified deploy/init logic, and the bridge API — are unaudited and are exactly where bugs hide. Initialization and upgrade logic is as dangerous as key management: the Nomad exploit (~$190M) came from an upgrade that set trusted roots to a value that meant "everything is valid."
• Custody is a trusted assumption at interim scale. Until custody is fully decentralized onto a keep-core threshold network, the interim signing set is a trust assumption, disclosed as such and constrained by tiny caps.
• No trustless claims, no guarantees, no warranties. pBTC is trust-minimized, not trustless. The software is experimental and provided "as is." Nothing in this paper is financial, investment, legal, or tax advice, or a solicitation to buy or sell any asset.