BounceBit Wallet
Security model

Verify first. Sign second.

BounceBit Wallet keeps transaction context visible before authorization. Network, origin, method, recipient, permissions and expected effect are reviewed before a key is used.

Open verification guideVerify desktop releases
A white marble guardian holding a shield in front of a secure vault, representing BounceBit Wallet security.
Signing
Local only

Keys stay on your device

Networks
6001 · 6000

Mainnet and testnet

Release integrity
SHA-256 · PGP

Verified before install

Recovery requests
Never

No support exceptions

Principles

Eight decisions the wallet makes on your behalf.

Each principle is a real product surface. What the user sees, and what the wallet prevents, are listed for every entry.

  1. 01

    Key boundary

    Private keys are generated and stored on the device. No secret material is transmitted to servers operated by us or third parties, including for backup, analytics or telemetry.

    You see

    A local key indicator, encrypted vault status, and an option to export material only through explicit, user-initiated flows.

    Wallet prevents

    Remote exfiltration, cloud key escrow, silent seed transmission, and provider-side custody.

  2. 02

    Transaction clarity

    Every signing request is decoded into a human-readable preview: intent, method, target, permissions, amounts and expected effect are surfaced before the key is used.

    You see

    Origin, method, recipient, asset, amount, permission scope, estimated fee and risk flags on a single confirmation panel.

    Wallet prevents

    Blind signing, opaque calldata, hidden approval scope, and misrepresented actions.

  3. 03

    Network verification

    The active chain ID and RPC endpoint are persistent across every screen. Signing surfaces refuse to proceed when the requested network does not match the active one.

    You see

    Chain ID (6001 mainnet · 6000 testnet), RPC endpoint, and a network-mismatch warning when relevant.

    Wallet prevents

    Cross-chain confusion, spoofed testnet requests, and silent RPC substitution.

  4. 04

    Contract context

    Known contracts are labeled with verified metadata. Unknown contracts are marked as such — never assumed safe — and approval scope is translated into concrete terms.

    You see

    Contract label, verification state, requested method, and human-language approval scope (asset, spender, limit).

    Wallet prevents

    Impersonation of protocol contracts, unlimited approvals hidden behind branded UI, and misread method selectors.

  5. 05

    Application permissions

    Connected applications are reviewed and revoked from a single panel. Origin and requested scope are shown at connection time and re-shown on every signing request.

    You see

    Origin URL, connection time, active permissions, and a per-session revoke control.

    Wallet prevents

    Persistent silent access, forgotten sessions, and origin drift after the initial connection.

  6. 06

    Release verification

    Each published desktop release ships with a SHA-256 checksum and OpenPGP signature. Installers can be verified against the signing key fingerprint before running.

    You see

    Version, checksum, signature reference and fingerprint on the download and releases pages.

    Wallet prevents

    Tampered installers, mirror substitution, and impersonated download pages.

  7. 07

    Phishing protection

    Signing surfaces flag suspicious patterns: wrong network, unknown contract, unlimited approval, and unfamiliar origin. Warnings appear before the confirmation control is enabled.

    You see

    Explicit risk labels next to the affected field, with the underlying reason in plain language.

    Wallet prevents

    Silent unlimited approvals, wrong-chain signing, and deceptive origin prompts.

  8. 08

    Support boundaries

    Support follows a fixed policy. Diagnostic snapshots exclude private material. Recovery material is never requested, on any channel, under any circumstance.

    You see

    A published support contact path, and diagnostic exports that omit secrets by construction.

    Wallet prevents

    Support impersonation, seed-phrase requests over chat, and remote-access social engineering.

Threat model

What the wallet is designed to defend against.

A short, honest list. Every mitigation maps to a real signing surface, not a marketing claim.

RISK 01

Phishing sites

Attack surface
Fake origin or deceptive connection request
Wallet response
Origin displayed before signing; unknown-origin warning
Your action

Confirm the domain and the requested permission

RISK 02

Malicious contracts

Attack surface
Unverified contract requesting broad approval
Wallet response
Decoded method, recipient and approval scope surfaced pre-signing
Your action

Reject unknown contracts or reduce the approval amount

RISK 03

Fake installers

Attack surface
Substituted binary from mirror or lookalike site
Wallet response
SHA-256 checksum and OpenPGP signature published per release
Your action

Verify the checksum and signature before running the installer

RISK 04

Wrong network

Attack surface
Application requests signing on a chain other than the active one
Wallet response
Persistent chain ID indicator and network-mismatch refusal
Your action

Switch networks explicitly, or cancel the request

RISK 05

Unlimited approvals

Attack surface
Token approval with unbounded spending allowance
Wallet response
Approval scope translated to plain language with explicit flag
Your action

Set a bounded amount, or reject the request

RISK 06

Support impersonation

Attack surface
Third party posing as support requesting recovery material
Wallet response
Fixed support policy — recovery material is never requested
Your action

End the conversation and report the account

Support policy

We will never ask for your seed phrase or private key.

Any request for recovery material, passwords, remote access or session secrets must be treated as hostile. End the conversation and use a verified support path.

Verification guideContact supportPrivacy policy