DeFiPunk'd

WBTC

Bridge

TVL $8.3B
Type Bridge
Chain Bitcoin
View on DeFiLlama ↗
Control — tentative orange Ability to exit — tentative red Autonomy — tentative red Open Access — tentative red (1/3 models submitted) Verifiability — tentative orange Control Exit Autonomy Open Access Verifiable
Control criteria
Upgradeability Immutable Bug bounty — Governance forum — Docs wbtc.network
About

WBTC is an ERC-20 token on Ethereum backed 1:1 by Bitcoin held by institutional custodians. Users interact with authorized merchants to mint WBTC by depositing BTC, or burn WBTC to redeem BTC. The token contract, Controller, Members (merchant registry), and Factory contracts are immutable but owned by a 6-of-10 multisig that holds pause and merchant-management authority.

Risk analysis

One card per dimension, sorted by severity. Only Verifiability and Autonomy carry automated signals in Phase 0. See methodology for scope.

Audit a dimension yourself · DEFI@home Contribute an LLM-run assessment — any model, any dimension. Three agreeing runs merge automatically into the public record.

DEFI@home is a distributed audit network modeled on SETI@home: instead of CPU cycles, it crowdsources LLM reasoning. Paste a slice prompt into Claude, ChatGPT, Gemini, or any browsing-capable model, and submit the JSON output as a pull request. The quorum bot merges it once ≥3 independent runs (from different models) reach the same grade — no single model, and no single contributor, can move the needle alone. How it works →

  • Address discovery 64 addresses on file · 4 runs Submit run ↗
  • Verifiability Submit run ↗
  • Control ✓ 9/9 models agree AI-only weak orange — total support weight 1.23 below confidence floor (1.5) Submit run ↗
  • Ability to exit Submit run ↗
  • Autonomy Unverified Submit run ↗
  • Open Access 1/3 submitted Submit run ↗
  • Audit all 5 dimensions · one prompt Submit run ↗
  1. Verifiability tentative 1 model AI-only 0/1 with chat share link
    Core Ethereum contracts verified on Etherscan; ChainSecurity audit from 2018–2019 is >6 years stale with no discovered follow-up re-audit
    Verdict

    Choosing orange because the WBTC token is bytecode-verified on Etherscan (ABI source confirmed as 'etherscan' by the DeFiPunkd surfacer), a public source repo exists, and ChainSecurity — a recognized firm — performed an audit. However, the audit dates from 2018–2019 (>6 years before the analysis date), the repo's own README explicitly notes the ethereum/ contracts are not deployed and references a separate ethereumV2/ subdirectory, the audit_summary acknowledges the deployment commit differs from the audited commit, and no later audit or differential review from a recognized firm was discovered. This satisfies the orange condition: 'audit scope is stale relative to deployment.' The red steel-man is weaker because bytecode IS verified and a recognized audit DID exist; the green steel-man fails because the 6-month recency threshold cannot be met.

    Steelman argument
    Steelman argument The WBTC token bytecode is verified on Etherscan (ABI served from Etherscan source), the public repo exists and contains a verification script confirming deployed code matches compiled code at commit 0e8c140, and ChainSecurity is a recognized firm — but the original audit is >6 years stale with no discovered follow-up, satisfying the orange rubric condition of stale audit scope relative to deployment.
    Evidence (6)
    V1
    WBTC token (0x2260FAC5E5542a773Aa44fBCfeDf7C193bc2C599) ABI is sourced from Etherscan (abiSource: 'etherscan') per the DeFiPunkd surfacer, confirming on-chain bytecode is verified. The token is not a proxy — no proxy.implementation address was surfaced, so no separate implementation verification is needed for this contract. For the Arbitrum token (0x2f2a2543B76A4166549F7aaB2e75Bef0aefC5B0f), Arbiscan shows it as 'ClonableBeaconProxy' which is verified at the proxy level, but 'No Contract Security Audit Submitted' is noted. Verification status of the Controller (0xCA06411bd7a7296d7dbdd0050DFc846E95fEBEB7) and Factory (0xe5a5f138005e19a3e6d0fe68b039397eeef2322b) was not directly confirmed via fetched block-explorer pages this run (Etherscan domain blocked); ABI was served from Etherscan source for the token only.
    V2
    The WrappedBTC/bitcoin-token-smart-contracts GitHub repository is publicly accessible and confirmed active. The ethereum/README.md states 'The contracts in this repo are NOT deployed' and directs to the ethereumV2/ subdirectory for the deployed contracts. The audit_summary.md in the repo names commit 0e8c140ab5fa006a17afa504dafcf311f56f81a2 as the relevant deployed commit and states 'These prints confirm that the deployed code matches the locally compiled code.' A pinned commit SHA from a direct fetch of the deployed-addresses document or ethereumV2 directory was not obtained this run — this is recorded as a scope limit, not a downgrade signal on its own.
    V3
    ChainSecurity completed a security audit of the WBTC smart contracts, published January 2019, covering the minting, burning, merchant/custodian management, and ERC-20 transfer logic. A second audit PDF dated 2018-11-19 is also stored in the repo docs/ folder. The wbtc.network/dashboard/audit page rendered only metadata without a readable audit list. No re-audit or differential audit from a recognized firm covering the currently-deployed Ethereum contracts post-2019 was discovered across all fetched sources. The audit is estimated >6 years prior to the analysis date of 2026-05-07.
    V4
    ChainSecurity is listed as a recognized audit firm in the rubric. The Medium post and ChainSecurity's own site both confirm the completed audit. During the audit ChainSecurity detected two security issues (minting/burning pause and a possible hash collision from abi.encodePacked) and confirmed WBTC addressed, acknowledged, or fixed the raised issues.
    V5
    The ethereum/ subdirectory of the repo is explicitly marked non-deployed since some later date (ethereumV2/ holds the deployed versions). The audit_summary.md references the final verification commit (0e8c140) but the audit itself was against commit 144311389d5c46af5999b7cceb2bad9fec2a9a5e. The summary acknowledges differences between the audit commit and the deployed commit. No later audit, fix-audit, or differential audit from a recognized firm was found covering the currently-deployed contracts. The gap between the audit date (~2018-2019) and the analysis date (2026-05-07) exceeds 6 months materially, qualifying as a stale-audit finding under the orange grade rubric.
    V6
    The WBTC ERC-20 token (0x2260FAC5E5542a773Aa44fBCfeDf7C193bc2C599) is not a proxy — no implementation address was returned by the surfacer. For the Arbitrum token (0x2f2a2543B76A4166549F7aaB2e75Bef0aefC5B0f), the Arbiscan page shows a 'ClonableBeaconProxy' architecture with a verified proxy contract; full verification status of the beacon implementation was not confirmed from fetched sources this run.
    Why is this consensus tentative?
    • weak consensus margin
    • only 0/2 sources have a public chat share link
    • total support weight 0.56 below confidence floor (1.5)

    A fresh independent run can strengthen (or overturn) the verdict.

    Run your own prompt Submit run ↗
    Sources claude-sonnet-4-6 (autorun) no url View raw submissions ↗
  2. Control tentative 9/9 models agree AI-only 8/9 with chat share link
    WBTC Controller owned by 6-of-10 multisig with no timelock; T1 powers (mint, pause, ownership transfer) are immediately executable; 6 of 10 signers are unidentified, failing Security Council criteria.
    Verdict

    Choosing orange because T1 fund-critical powers (pause, mint via factory swap, ownership transfer) are reachable with zero timelock through a 6-of-10 multisig that fails Security Council criteria — specifically, 6 of 10 signers are not publicly announced. The multisig is NOT a single EOA or 2-of-3 (which would make it red), but the absence of any timelock and the incomplete signer disclosure place it squarely in the orange tier per the rubric: 'a multisig failing one or more Security Council criteria sits on a T1/T2 path.' The green steel-man is weaker because, despite immutable contract bytecode, the Controller's owner-gated functions constitute a live T1 surface (pause, mint, transferOwnership) that is immediately executable.

    Steelman argument
    Steelman argument The 6-of-10 threshold is meaningful (not trivially bypassed like a 2-of-3), and at least 4 identified signers include independent entities (Chainlink, Balancer), but the multisig fails Security Council criteria due to unidentified signers and lacks any timelock.
    Evidence (7)
    C1
    WBTC token (0x2260) owner = Controller (0xCA06). Controller owner = 0x972Eed35781f09987a5c40F761f6A24623C570DE, a 6-of-10 MultiSigWalletWithDailyLimit. pendingOwner on both token and Controller is 0x0000. The GitHub README still lists the old Big DAO multisig (0xB33f) as the wallet but on-chain state shows ownership has migrated to 0x972E.
    C2
    All core contracts (WBTC token, Controller, Factory, Members) are non-upgradeable (no proxy pattern detected). The ABI has no implementation() slot. upgradeability = immutable.
    C3
    Execution path: 6-of-10 multisig (0x972E) → Controller (0xCA06) → WBTC token (0x2260). No timelock anywhere in the path. The multisig is a classic Gnosis-style MultiSigWalletWithDailyLimit; upon reaching 6 confirmations a transaction executes immediately. Total uncontested-fast-path delay = 0 seconds.
    C4
    Controller owner multisig 0x972E: 6-of-10, 10 signers. Matched signers from GitHub DAO Members list: 0x512f (Balancer), 0x157b (BitGo), 0xcBf1 (Tom Bean), 0x65CE (Chainlink). The remaining 6 signers (0xa9e7, 0xD00e, 0x0940, 0xD3A1, 0xA2F5, 0x7E25) are not publicly identified in the GitHub README. The custodian multisig at 0xb0F4 (BitGo) has confirmMint authority but its internal structure could not be read via Safe API (fetch failed). The Small DAO / Light Multisig at 0x4dbb owns the Members contract (T2 power over merchant/custodian list) but was not read this run.
    C5
    No on-chain governance. WBTC has no Governor contract, no voting token, no proposal/quorum mechanism. All governance is via multisig.
    C6
    No separate emergency-pause role detected. The Controller's pause() and unpause() functions are owner-gated, meaning the same 6-of-10 multisig controls both normal operations and emergency pause. No guardian or separate emergency multisig was found.
    C7
    T1 — FUND-CRITICAL: The Controller owner (6-of-10 multisig) can: (1) pause() — halts all WBTC transfers, blocking user exits; (2) mint(address,uint256) — mint unbacked WBTC via setFactory() to a malicious factory; (3) callTransferOwnership(ownedContract, newOwner) — transfer ownership of the WBTC token itself to any address; (4) setMembers(address) — replace the members registry, changing custodian. All of these are T1 fund-critical powers. The uncontested-fast-path delay is 0 seconds. The multisig fails Security Council criteria because 6 of 10 signers are not publicly announced.
    Why is this consensus tentative?
    • total support weight 1.23 below confidence floor (1.5)

    A fresh independent run can strengthen (or overturn) the verdict.

    Run your own prompt Submit run ↗
    Sources claude-opus-4-6 (autorun) no url gpt-5.5-thinking url ↗ claude-sonnet-4-6 url ↗ claude-opus-4-20250514 url ↗ claude-opus-4-7 url ↗ GPT-5.4 Pro url ↗ gpt-5.5-pro url ↗ gpt-5.2-pro url ↗ claude-haiku-4-5 url ↗ View raw submissions ↗
  3. Ability to exit tentative 2/2 models agree AI-only 0/2 with chat share link
    WBTC redemption requires custodian/merchant cooperation — no permissionless on-chain exit to native BTC exists; burn function is callable but BTC release is entirely custodial
    Verdict

    Choosing red because the fundamental exit — recovering native BTC from WBTC — requires an admin signature (custodian/merchant approval) with no on-chain fallback, satisfying the red criterion 'exit requires admin signature.' Additionally, the pause function on the token contract is held by the WBTC DAO multisig with no documented time cap, meaning token transfers and burns can be frozen indefinitely. The secondary-market DEX exit does not constitute a permissionless exit to the underlying asset. Evidence: WBTC token contract on Etherscan confirms custodial architecture and pausability; WBTC documentation confirms merchant/custodian redemption requirement.

    Steelman argument
    Steelman argument WBTC redemption for native BTC is entirely custodial — there is no permissionless on-chain mechanism to retrieve BTC; the burn function destroys tokens but BTC release requires an approved merchant and custodian (BitGo/BiT Global) action, and the pause function on the token contract has no time cap, meaning a single multisig can freeze all token transfers indefinitely.
    Evidence (7)
    E1
    The WBTC ERC-20 contract (0x2260FAC5E5542a773Aa44fBCfeDf7C193bc2C599) exposes a `burn(uint256 value)` function that any token holder can call to destroy their WBTC. There is also an operator-only `mint` function. There is NO on-chain redeem/withdraw function that atomically releases BTC; the burn merely records intent. The actual BTC release depends entirely on the custodian (BitGo / BiT Global) processing the redemption off-chain after a KYC-approved merchant initiates it. The WBTC DAO contract at 0x9c849a0ed5952cf4f1f0be7e1dce8d08c70e2b34 and the WBTCController govern merchant and custodian roles.
    E2
    `burn(uint256 value)` — publicly callable by any WBTC holder, not pause-gated at the token contract level directly, but is subject to the token's `whenNotPaused` modifier inherited from OpenZeppelin's Pausable. The `mint` function is restricted to the minter role (custodian). However, calling `burn` on the ERC-20 does not trigger BTC release — the redemption pipeline requires a licensed merchant to submit a burn request through the WBTC portal, and the custodian must process it. End-users who are not merchants cannot initiate redemption at the protocol level.
    E3
    The WBTC token contract has a `pause()` function callable by the contract owner. As of the most recent on-chain state, the owner/admin of the WBTC token contract is a multisig controlled by the WBTC DAO (which since 2024 includes BiT Global / Justin Sun entities as co-custodian). There is no documented maximum pause duration — pause can be indefinite. The pause role holder is a multisig (the WBTC DAO multisig), but it can pause the token transfers and burn function with no time cap.
    E4
    No distinct emergency-vs-governance pause distinction is publicly documented for WBTC. The single `pause()` path is controlled by the WBTC DAO multisig and has no auto-expiry or time cap documented in the contract or public documentation.
    E5
    There is no queued redemption mechanism on-chain. Redemptions are processed off-chain by merchants and custodians. The WBTC documentation states that merchants must complete KYC/AML and that the custodian (BitGo / BiT Global) processes BTC releases, with no documented SLA or maximum queue duration.
    E6
    There is no forced-exit or escape-hatch mechanism. If the custodian (BitGo / BiT Global) becomes insolvent, is sanctioned, or refuses to process redemptions, WBTC holders have no on-chain recourse to recover their BTC. The only secondary market exit is selling WBTC on a DEX/CEX for another asset.
    E7
    The `burn` function is directly callable on-chain via Etherscan's write tab without the project frontend. However, calling burn does NOT release BTC — it only destroys ERC-20 tokens. The actual BTC redemption process requires the WBTC portal, KYC with a merchant, and custodian action, making the meaningful exit path entirely dependent on off-chain infrastructure and custodian cooperation.
    Why is this consensus tentative?
    • only 0/3 sources have a public chat share link
    • total support weight 0.38 below confidence floor (1.5)

    A fresh independent run can strengthen (or overturn) the verdict.

    Run your own prompt Submit run ↗
    Sources claude-sonnet-4-6 (autorun) no url claude-sonnet-4-5 (autorun) no url View raw submissions ↗
  4. Autonomy tentative
    External message validators reduce autonomy

    Bridges rely on an external validator set, guardian signatures, or light-client proofs — a category-level autonomy risk independent of any specific implementation.

    Run your own prompt Submit run ↗
  5. Open Access 1/3 model submitted
    WBTC minting requires merchant whitelist approval; no permissionless on-chain entry for retail users
    Tentative grades
    • claude-sonnet-4-6 (autorun) red

    No quorum yet — verdict and steelman hidden until ≥3 models agree.

    Evidence (7)
    A1
    WBTC minting and burning are exclusively available to whitelisted 'Merchants' — entities approved by BitGo (and the WBTC DAO multisig). The ERC-20 contract exposes mint() gated to a single minter address and burn() gated to burner addresses. Ordinary users cannot call mint or burn directly; they must transact with an approved Merchant who holds the whitelisted role. The deployed contract on Ethereum (0x2260FAC5E5542a773Aa44fBCfeDf7C193bc2C599) uses an owner-controlled minter/burner registry. This constitutes a contract-level whitelist on user entry (minting) and exit (burning).
    A2
    The admission path for minting WBTC requires off-chain operator approval at two levels: (1) a Custodian (BitGo, historically) must receive and verify the BTC deposit, and (2) a whitelisted Merchant must submit a mint request on-chain. Retail users cannot directly trigger minting — they must go through a Merchant who performs KYC/AML on them. The Merchant set is a permissioned committee controlled by the WBTC DAO multisig. For burning/redemption, users must also go through a Merchant, which submits a burn request after the user sends WBTC. Transfers of existing WBTC between wallets are unconditional (standard ERC-20), but entry and exit require operator approval.
    A3
    The official wbtc.network website and dashboard are informational. There is no retail-facing mint/burn interface — the site directs users to approved Merchants. This is not a frontend geo-block but a fundamental design: the official UI has no mint/burn function for retail users. The site does list approved Merchants (exchanges, OTC desks) as the access channel.
    A3b
    A3b-i: No IPFS mirror of an official UI was found; the official site is informational only. A3b-ii: Alternative paths exist for holding and transferring WBTC (any DEX, any wallet) but minting/burning WBTC requires going through an approved Merchant — no independent path bypasses the Merchant whitelist for mint/burn. Uniswap and other DEXes allow secondary-market trading of WBTC but do not allow creation or redemption of WBTC without a Merchant.
    A4
    Merchants are required to perform KYC/AML on their customers as a condition of their Merchant Agreement with the WBTC DAO. There is no on-chain OFAC blocklist applied to WBTC token transfers (transfers are standard ERC-20), but admission to minting/burning is filtered through Merchants who are contractually obligated to apply sanctions screening off-chain.
    A5
    Read access: fully permissionless — anyone can query the WBTC contract, view balances, and observe the mint/burn history on Etherscan. Write access: (a) transfer — permissionless, standard ERC-20 for any holder; (b) mint — gated to whitelisted Merchants who must go through custodian approval; (c) burn — gated to whitelisted Merchants. Retail users cannot write to mint() or burn() directly.
    A6
    The WBTC merchant/user agreement and legal framework require Merchants to verify customer identity. The wbtc.network site references a Merchant Agreement. A verbatim ToS clause specifically applicable to retail users was not extractable from the static site (it is directed at Merchants, not end-users). The WrappedBTC GitHub (wrappedbtc/wbtc-merchant-documentation or similar) contains the merchant framework. End-user ToS for the wbtc.network site itself is minimal since the site is informational.
    Why is this slice uncertain?
    • only 1 of 3 model submissions on record — quorum requires ≥3 agreeing models

    A fresh independent run can establish (or overturn) a verdict.

    Run your own prompt Submit run ↗
    Sources claude-sonnet-4-6 (autorun) no url View raw submissions ↗

Stage

Preview of the Phase-3 maturity framework. DeFiPunk'd will adopt DeFiScan v2's stages verbatim; the section is rendered below in its intended shape so the structure is visible today.

WBTC has not yet been assessed under the DeFiScan v2 stage framework.
The walkaway test is the central criterion. Once stages land, protocols reach Stage 1 only if users can exit in the presence of malicious operators even when the emergency council disappears.
Scope of assessment
Stages are assessed per-protocol against DeFiScan v2's criteria: governance structure, upgradeability path, timelock durations, emergency-council scope, and the walkaway test. The analysis depends on onchain discovery (roles, owners, timelocks) and deeper review of deployed contracts — neither of which DeFiPunk'd automates at Phase 0.
Stage 0 requirements pending
Governance is largely off-chain, contracts are upgradeable with short or no timelock, and the protocol depends on a multisig or team with full discretion. At Phase 0 DeFiPunk'd does not automatically evaluate these; the assessment lands with crawler-based onchain discovery.
Stage 1 requirements pending
Users can exit or opt out on their own terms even if the team disappears. Upgrades run through a meaningful timelock with an emergency security council clearly scoped. The walkaway test is the headline criterion.
Stage 2 requirements pending
Protocol is fully permissionless and immutable, or upgrades require a supermajority of token holders with a long timelock and no emergency override. This is the terminal stage of the DeFiScan v2 framework.
Learn more about DeFiScan v2 stages →
Stages are an opinionated assessment of maturity, not a rating of security or safety. A protocol can sit at Stage 2 and still carry substantial technical or economic risk; the framework exists to incentivize decentralization, not to rank protocols.

Contract surface

Every contract in scope for this protocol — pooled from DeFiLlama's TVL adapter (mechanical) and DEFI@home discovery submissions (LLM-curated). Verified-source flags come from Etherscan + Sourcify; owner / multisig metadata is read on-chain when available. Reviewer audit context, not a slice score. A lending protocol's adapter set will list third-party collateral tokens alongside its own contracts; attribution is the grader's job.

  • 128addresses
  • 8verified source
  • 0proxies
  • 3of 7 owners are Safes

TVL adapter pinned at 683d369. Sourcecode fetched 2026-05-06. Control fetched 2026-05-14.

addTonBalancesnull0x0000…0000TVL————
arbitrumAnyswapV5ERC200xfea7…6c2aTVL✓—0xf46b…5aea5/10 Safe
Arbitrumtoken (WBTC bridged ERC-20 proxy on Arbitrum One; BeaconProxyFactory architecture)0x2f2a…5b0fdiscovery———token
Basetoken (WBTCOFT LayerZero OFT on Base; 8 decimals; OAppCore owner controls cross-chain config)0x0555…2b9cdiscovery———token
bobaBUSD0x461d…4eb5TVL————
covalentGetTokensnull0x0000…0000TVL————
dogechainBUSD0x3327…41ffTVL————
dogechainMATIC0xdc42…1f98TVL————
ethereumDai0x6b17…1d0fTVL✓———
ethereumFantomToken0x4e15…7870TVL✓—0xb5c4…3f702/4 Safe
ethereumCvxLockerV20x72a1…b86eTVL✓—0xa3c5…e2fb3/5 Safe
ethereumWBTC0x2260…c599TVL + disc✓—0xca06…beb7token
Ethereumfactory (mint and burn request factory; merchants submit requests here; custodian approves/rejects)0xe5a5…322bdiscovery———factory
Ethereummultisig (Controller owner, 6-of-10; directly owns the Controller contract)0x972e…70dediscovery———multisig
Ethereummultisig (current Big DAO, 8-of-13; governs Controller ownership transfers and major protocol changes)0xb33f…37c5discovery———multisig
Ethereummultisig (deprecated Big DAO, 11-of-18; previously governed Controller; superseded by 0xB33f)0xd409…3c68discovery———multisig
Ethereummultisig (Members owner, 5-of-9; controls merchant and custodian list in Members contract)0x4dbb…1e80discovery———multisig
Ethereumother (active merchant from Members.getMerchants)0x03dc…766fdiscovery————
Ethereumother (active merchant from Members.getMerchants)0x044b…cce1discovery————
Ethereumother (active merchant from Members.getMerchants)0x07f2…f6cadiscovery————
Ethereumother (active merchant from Members.getMerchants)0x1068…d7f3discovery————
Ethereumother (active merchant from Members.getMerchants)0x14b4…bbf2discovery————
Ethereumother (active merchant from Members.getMerchants)0x14c4…39c8discovery————
Ethereumother (active merchant from Members.getMerchants)0x1619…0bf3discovery————
Ethereumother (active merchant from Members.getMerchants)0x18c5…8d6adiscovery————
Ethereumother (active merchant from Members.getMerchants)0x1eec…cc0fdiscovery————
Ethereumother (active merchant from Members.getMerchants)0x1fad…acc9discovery————
Ethereumother (active merchant from Members.getMerchants)0x2081…e778discovery————
Ethereumother (active merchant from Members.getMerchants)0x22aa…9246discovery————
Ethereumother (active merchant from Members.getMerchants)0x2d92…abf6discovery————
Ethereumother (active merchant from Members.getMerchants)0x3011…98fbdiscovery————
Ethereumother (active merchant from Members.getMerchants)0x35a1…e144discovery————
Ethereumother (active merchant from Members.getMerchants)0x4d31…e979discovery————
Ethereumother (active merchant from Members.getMerchants)0x4e05…d2badiscovery————
Ethereumother (active merchant from Members.getMerchants)0x572f…fc20discovery————
Ethereumother (active merchant from Members.getMerchants)0x58fc…3a41discovery————
Ethereumother (active merchant from Members.getMerchants)0x6056…fda9discovery————
Ethereumother (active merchant from Members.getMerchants)0x6585…261ddiscovery————
Ethereumother (active merchant from Members.getMerchants)0x65b0…9de0discovery————
Ethereumother (active merchant from Members.getMerchants)0x6707…8f50discovery————
Ethereumother (active merchant from Members.getMerchants)0x6c86…a1aadiscovery————
Ethereumother (active merchant from Members.getMerchants)0x6fde…8b03discovery————
Ethereumother (active merchant from Members.getMerchants)0x7659…8a73discovery————
Ethereumother (active merchant from Members.getMerchants)0x808e…0643discovery————
Ethereumother (active merchant from Members.getMerchants)0x9acd…0736discovery————
Ethereumother (active merchant from Members.getMerchants)0x9ba1…2810discovery————
Ethereumother (active merchant from Members.getMerchants)0x9da7…20dcdiscovery————
Ethereumother (active merchant from Members.getMerchants)0x9f2e…c044discovery————
Ethereumother (active merchant from Members.getMerchants)0xa2b1…5cfadiscovery————
Ethereumother (active merchant from Members.getMerchants)0xa726…7f31discovery————
Ethereumother (active merchant from Members.getMerchants)0xaac1…5c92discovery————
Ethereumother (active merchant from Members.getMerchants)0xb43d…9a6adiscovery————
Ethereumother (active merchant from Members.getMerchants)0xb906…18aediscovery————
Ethereumother (active merchant from Members.getMerchants)0xbc93…e5bfdiscovery————
Ethereumother (active merchant from Members.getMerchants)0xbe6d…81cddiscovery————
Ethereumother (active merchant from Members.getMerchants)0xbe7b…e549discovery————
Ethereumother (active merchant from Members.getMerchants)0xbec8…a381discovery————
Ethereumother (active merchant from Members.getMerchants)0xc028…5681discovery————
Ethereumother (active merchant from Members.getMerchants)0xc308…df95discovery————
Ethereumother (active merchant from Members.getMerchants)0xcbd1…4f96discovery————
Ethereumother (active merchant from Members.getMerchants)0xcbeb…ed96discovery————
Ethereumother (active merchant from Members.getMerchants)0xe1f3…046fdiscovery————
Ethereumother (active merchant from Members.getMerchants)0xfdb7…d980discovery————
Ethereumother (active merchant from Members.getMerchants)0xfdf2…4c20discovery————
Ethereumother (deprecated multisig owner signer from old Big DAO)0x36de…1fe1discovery———multisig
Ethereumother (Members registry; stores merchant and custodian list; owned by Members owner multisig)0x3e86…7ac5discovery———multisig
Ethereumother (WBTC token deployer EOA; tagged Wrapped BTC: Deployer on Etherscan)0x8b41…d80bdiscovery———factory
Ethereumowner (Controller; owns WBTC token; approves/rejects mint and burn requests from factory)0xca06…beb7discovery———factory
Ethereumtreasury (BitGo custodian address; holds BTC-backed Ethereum-side custodian interface per Members.custodian)0xb0f4…bd27discovery———treasury
eulerTokenseulerTokens0x1b80…dc1dTVL————
eulerTokenseulerTokens0x3c66…62d0TVL————
eulerTokenseulerTokens0x4169…d264TVL————
eulerTokenseulerTokens0x4d19…85d2TVL————
eulerTokenseulerTokens0x5484…054eTVL————
eulerTokenseulerTokens0x6089…c527TVL————
eulerTokenseulerTokens0x64ad…ee82TVL————
eulerTokenseulerTokens0xbd1b…d593TVL————
eulerTokenseulerTokens0xe025…d9dcTVL————
eulerTokenseulerTokens0xeb91…a716TVL————
fantomanyUSDC0x95bf…d605TVL✗———
fantomDAI0x8d11…bf3eTVL✗———
fantomfUSDT0x049d…3c7aTVL✗———
fantomMIM0x82f0…29c1TVL✗———
fantomnICE0x7f62…e443TVL✗———
fantomUSDC0x0406…5b75TVL✗———
genericUnwrapCvxtarget0xf403…ae31TVL————
harmonyAVAX0xb12c…1358TVL————
kccDAI0xc9ba…2055TVL————
kccWBTC0x218c…a4c0TVL————
moonriverAnyswapV5ERC200x639a…2c5cTVL✓—0x10c6…7e23—
moonriverAnyswapV5ERC200xe3f5…ad7dTVL✓—0x10c6…7e23—
moonriverAnyswapV5ERC200xb44a…663cTVL✓—0x10c6…7e23—
nullAddressnull0x0000…0000TVL————
Optimismtoken (WBTC L2 standard ERC-20 on Optimism; l1Token=0x2260FAC5E5542a773Aa44fBCfeDf7C193bc2C599; onlyL2Bridge mint/burn)0x68f1…2095discovery———token
PANCAKE_NFT_ADDRESSPANCAKE_NFT_ADDRESS0x46a1…4364TVL————
Polygontoken (WBTC UChildERC20 proxy on Polygon; EIP-897 DelegateProxy; implementation 0x7ffb3d637014488b63fb9858e279385685afc1e2)0x1bfd…bfd6discovery———token
shidenBUSD0x65e6…d97aTVL————
shidenETH0x7652…9c61TVL————
shidenJPYC0x735a…7b0fTVL————
sumTokensnull0x0000…0000TVL————
sumTokens2null0x0000…0000TVL————
syscoinETH0x7c59…227dTVL————
syscoinUSDC0x2bf9…c45cTVL————
syscoinUSDT0x922d…12e1TVL————
telosETH0xfa93…a40fTVL————
telosUSDC0x818e…dc0bTVL————
telosUSDT0xefae…0d73TVL————
telosWBTC0xf390…cbc2TVL————
tonTON0x0000…0000TVL————
unwrapMakerPositionsCDP_MANAGER0x5ef3…5e39TVL————
unwrapMakerPositionsILK_REGISTRY0x5a46…0f87TVL————
unwrapMakerPositionsPROXY_REGISTRY0x4678…3fe4TVL————
unwrapUniswapV3NFTfactory0x71b0…6127TVL———factory
unwrapUniswapV3NFTunwrapUniswapV3NFT0xa08a…5aabTVL————
unwrapUniswapV4NFTsnftAddress0x3c3e…1017TVL————
unwrapUniswapV4NFTsnftAddress0x4529…17bfTVL————
unwrapUniswapV4NFTsnftAddress0x5b7e…4016TVL————
unwrapUniswapV4NFTsnftAddress0x7a4a…f95bTVL————
unwrapUniswapV4NFTsnftAddress0x7c5f…9bdcTVL————
unwrapUniswapV4NFTsnftAddress0xbd21…ee9eTVL————
unwrapUniswapV4NFTsnftAddress0xd88f…d869TVL————
unwrapUniswapV4NFTsstateViewer0x76fd…9990TVL————
unwrapUniswapV4NFTsstateViewer0x7739…9d64TVL————
unwrapUniswapV4NFTsstateViewer0x7ffe…7227TVL————
unwrapUniswapV4NFTsstateViewer0x86e8…e8f2TVL————
unwrapUniswapV4NFTsstateViewer0xa3c0…7a71TVL————
unwrapUniswapV4NFTsstateViewer0xc18a…ecdbTVL————
unwrapUniswapV4NFTsstateViewer0xd13d…e0c4TVL————

Protocol Info

Links

[defillama] Source: DeFiLlama [:] Source: DEFI@home quorum
Website
https://wbtc.network
Twitter
@WrappedBTC
GitHub
3 repositories
Docs
https://wbtc.network/

Security

[:] Source: DEFI@home quorum
Audits
9 audits
Bug bounty
unknown
Security contact
security@bitgo.com

Technical

[:] Source: DEFI@home quorum
Deployed contracts
https://wbtc.network/dashboard/order-book
Upgradeability
Immutable

Provenance

[defillama] Source: DeFiLlama [:] Source: DEFI@home quorum
Review status
listed
Updated
2026-06-02 13:51 UTC