DeFiPunk'd

Base Bridge

Canonical Bridge

TVL $2.7B
Type Canonical Bridge
Chain Ethereum
View on DeFiLlama ↗
Control criteria
Upgradeability Upgradeable Bug bounty hackerone.com Governance forum base.mirror.xyz Docs docs.base.org
About

Base Bridge is the canonical OP Stack bridge for ETH and ERC-20 transfers between Ethereum L1 and Base L2. Deposits lock assets in L1StandardBridge escrow and mint bridged tokens on L2; exits burn on L2StandardBridge (permissionless) then anyone proves and finalizes on OptimismPortal2 after the fixed ~7-day challenge period to unlock on L1. All steps are directly on-chain with no admin signature or project frontend required for claims.

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 59 addresses on file · 2 runs Submit run ↗
  • Verifiability ✓ 4/4 models agree AI-only weak red — weak consensus margin Submit run ↗
  • Control ✓ 3/3 models agree AI-only weak orange — weak consensus margin; total support weight 1.15 below confidence floor (1.5) Submit run ↗
  • Ability to exit ✓ 3/3 models agree AI-only weak red — weak consensus margin Submit run ↗
  • Autonomy ✓ 3/3 models agree AI-only 3/3 with chat share link Submit run ↗
  • Open Access ✓ 4/4 models agree AI-only weak green — total support weight 1.22 below confidence floor (1.5) Submit run ↗
  • Audit all 5 dimensions · one prompt Submit run ↗
  1. Verifiability tentative 4/4 models agree AI-only 4/4 with chat share link
    Core bridge contracts are explorer-verified, but no audit evidence was pinned or found on explorer audit sections
    Verdict

    Choosing red because source verification is good, but the audit side of the verifiability rubric fails: protocol.audit_links was empty for this run, no audit scope/date/commit could be inspected, and every checked explorer contract page reported no submitted contract security audit.

    Steelman argument
    Steelman argument Red is justified because the slice requires recognized audit coverage for green/orange-quality verifiability, protocol.audit_links was empty, and explorer audit sections for checked contracts show no submitted contract audit.
    Evidence (5)
    V1
    The assessed canonical Ethereum-Base bridge entrypoints were discovered from Base's official contract-address page: L1StandardBridge at 0x3154Cf16ccdb4C6d922629664174b904d80F2C35 on Ethereum, L2StandardBridge at 0x4200000000000000000000000000000000000010 on Base, and OptimismPortal at 0x49048044D57e1C92A77f79988d21Fa8fAF74E97e on Ethereum. Their explorer pages report verified source for the proxy contracts and disclose current implementation addresses.
    V1
    The current implementations checked for the assessed proxies are separately verified: L1StandardBridge implementation 0x61525EaaCDdB97D9184aFc205827E6A4fd0Bf62A is an Etherscan exact match, L2StandardBridge implementation 0xC0d3c0d3c0D3c0d3C0D3c0D3C0d3C0D3C0D30010 is a BaseScan genesis bytecode match, and OptimismPortal implementation 0x97cEbbf8959e2A5476fbe9B98A21806Ec234609B is an Etherscan exact match.
    V2
    The public ethereum-optimism/optimism repository contains corresponding L1StandardBridge and L2StandardBridge source files with matching contract names and standard-bridge semantics, but this run did not pin a deployment commit or perform bytecode equivalence.
    V3
    No audit report URL was pinned in protocol.audit_links for this run, and the explorer pages checked for the assessed proxy/implementation contracts show 'No Contract Security Audit Submitted' in their contract audit sections.
    V6
    The assessed bridge contracts are upgradeable proxies, but the current implementation contracts identified by the explorers were checked separately and are verified.
    Why is this consensus tentative?
    • weak consensus margin

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

    Run your own prompt Submit run ↗
    Sources claude-sonnet-4-6 url ↗ gpt-5.5-thinking url ↗ GPT-5.5 Pro url ↗ grok-4 url ↗ View raw submissions ↗
  2. Control tentative 3/3 models agree AI-only 3/3 with chat share link
    Security Council 9/12 Safe owns the ProxyAdmin with no on-chain timelock; T1 upgrades executable immediately after multisig quorum
    Verdict

    Choosing orange because T1 (upgrade of fund-holding bridge contracts via ProxyAdmin.upgrade()) is reachable on the uncontested fast path with zero on-chain delay — the Security Council Safe 9/12 can execute immediately once quorum is reached. This fails the green condition requiring ≥7-day uncontested delay combined with a Security Council. Additionally, the Security Council fails the 'every signer publicly announced' criterion (Yele Bademosi's signer address and Coinbase's individual signer key are not disclosed), placing it further into orange under 'a multisig failing one or more Security Council criteria sits on a T1/T2 path.' The green steel-man is real but cannot override the absence of a timelock exit window.

    Steelman argument
    Steelman argument A 9/12 Security Council Safe with broadly independent membership (11/12 non-Coinbase) sits on a T1 upgrade path with no on-chain timelock delay, meaning there is no exit window for users after an upgrade is signed, and two of twelve signer addresses are not publicly disclosed.
    Evidence (7)
    C1
    ProxyAdmin (0x0475cBCAebd9CE8AfA5025828d5b98DFb67E059E) on Ethereum is owned by a Gnosis Safe 1.3.0 at 0x7bB41C3008B3f03FE483B28b8DB90e19Cf07595c, which the official Base docs label 'Proxy Admin Owner (L1)'. This Safe corresponds to the Security Council established April 2025, comprising Coinbase plus 11 independent entities/individuals with a 9/12 (75%) threshold per published documentation. SystemConfig (0x73a79Fab69143498Ed3712e519A88a918e1f4072) is owned by a separate Gnosis Safe at 0x14536667Cd30e52C0b458BaACcB9faDA7046E056. Guardian role is held by 0x09f7150D8c019BeF34450d6920f6B3608ceFdAf2 ('Optimism: Guardian Multisig' per Etherscan label).
    C2
    The ProxyAdmin contract (OZ-style, v0.8.15 compiled) exposes upgrade() and upgradeAndCall() callable by its owner (the Security Council Safe). No Timelock contract appears in the official L1 contract list at docs.base.org/base-chain/network-information/base-contracts; no timelock address was discovered transitively from the ProxyAdmin or Proxy Admin Owner Safe. All key L1 OP Stack contracts (L1StandardBridge, OptimismPortal, L1CrossDomainMessenger, L1ERC721Bridge, DisputeGameFactoryProxy, etc.) are behind this ProxyAdmin and therefore upgradeable by the Security Council Safe directly. The ProxyAdmin itself is not a proxy.
    C3
    Uncontested fast path: Security Council Safe (9/12 threshold) calls execTransaction → ProxyAdmin.upgrade(proxy, newImpl) → proxy implementation replaced. No queuing step, no timelock delay, no veto window — delay = 0 seconds. The ProxyAdmin's most recent on-chain transaction was block 24816510 (April 5, 2026), confirming active use. This fast path reaches T1 targets (L1StandardBridge holds user-deposited ETH and ERC-20s; OptimismPortal is the withdrawal finalization entry point).
    C4
    Three privileged multisigs identified. (1) Security Council Safe 0x7bB41C3008B3f03FE483B28b8DB90e19Cf07595c (Gnosis Safe 1.3.0): upgrade authority over all L1 bridge/portal contracts via ProxyAdmin — 12 members per docs (Aerodrome, Moonwell, Blackbird, ChainSafe, Talent Protocol, Moshicam, Seneca, Juan Suarez, Toady Hawk, Roberto Bayardo, Yele Bademosi + Coinbase), required threshold 9/12 per docs; 10 of 11 external-member signer addresses published; Yele Bademosi's address and Coinbase's individual signer address are not published. (2) SystemConfig Owner Safe 0x14536667Cd30e52C0b458BaACcB9faDA7046E056 (Gnosis Safe 1.3.0): controls gas limit, resource config, sequencer address, fee recipient on SystemConfig — T2 economic parameters; threshold and owners not fully read on-chain this run. (3) Guardian Safe 0x09f7150D8c019BeF34450d6920f6B3608ceFdAf2 (Gnosis Safe 1.3.0, labeled 'Optimism: Guardian Multisig'): can pause withdrawal logic on OptimismPortal — T1 emergency power; threshold and owners not fully read on-chain this run.
    C5
    No on-chain governor or token-weighted voting contract identified for Base Bridge. Governance is entirely multisig-based.
    C6
    The Guardian Safe (0x09f7150D8c019BeF34450d6920f6B3608ceFdAf2, labeled 'Optimism: Guardian Multisig') holds emergency pause power over OptimismPortal withdrawals. Per Etherscan's label description, it 'can be used to pause several system contracts on OP Stack chains … particularly of withdrawal logic, in the event of a security concern.' This is a T1-capable emergency path (pausing withdrawals prevents user exit). The Guardian Safe is shared across OP Stack chains and held by Optimism, not the Base Security Council specifically; it has 2 on-chain transactions showing exercised activity.
    C7
    Highest tier on the uncontested fast path: T1. (a) ProxyAdmin.upgrade(L1StandardBridgeProxy, newImpl) — replaces implementation of a contract holding user funds; callable by Security Council Safe 9/12 with 0 on-chain delay. (b) ProxyAdmin.upgrade(OptimismPortalProxy, newImpl) — same tier, same path. (c) Guardian.pause() on OptimismPortal — T1, blocks all user withdrawals; separate actor. SystemConfig owner can change gas config / sequencer address — T2 at most (no direct access to user funds). No on-chain upper bound was found for SystemConfig fee parameters.
    Why is this consensus tentative?
    • weak consensus margin
    • total support weight 1.15 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 url ↗ grok-4 url ↗ gpt-5.5-pro url ↗ View raw submissions ↗
  3. Ability to exit tentative 3/3 models agree AI-only 3/3 with chat share link
    Guardian multisig (apparently 1-of-N) can pause withdrawal claims on OptimismPortal indefinitely with no time cap
    Verdict

    Choosing red because the Guardian (apparently a 1-of-N Gnosis Safe based on single-signature execTransaction evidence) can pause finalizeWithdrawalTransaction — the function that delivers finalized funds to users — indefinitely with no on-chain time cap, directly satisfying the red criterion 'ANY actor can pause CLAIMS of finalized exits indefinitely.' The orange steel-man (multisig, not EOA; Security Council could upgrade away) does not overcome the fact that the pause is currently uncapped and reachable by a small, fast actor without a governance vote.

    Steelman argument
    Steelman argument The Guardian, which appears to be a 1-of-N Safe, can pause both proveWithdrawalTransaction and finalizeWithdrawalTransaction on OptimismPortal indefinitely with no time cap; a single compromised or malicious key holder could freeze all withdrawals forever, satisfying the red criterion that any actor can pause claims of finalized exits indefinitely.
    Evidence (7)
    E1
    Three user-facing exit functions exist on OptimismPortal2 (0x49048044D57e1C92A77f79988d21Fa8fAF74E97e, impl 0x97cEbbf8): proveWithdrawalTransaction (step 1), finalizeWithdrawalTransaction (step 2, claims funds), and finalizeWithdrawalTransactionExternalProof (step 2 variant). On the L2 side, L2ToL1MessagePasser (0x4200...0016) is called first to initiate the withdrawal. ERC-20 withdrawals route through L1StandardBridge (0x3154Cf16...4D80F2C35) which wraps the portal.
    E2
    The ABI of OptimismPortal2 (impl 0x97cEbbf8) contains the custom error OptimismPortal_CallPaused. Analysis of the bytecode shows finalizeWithdrawalTransaction begins with a _checkPaused call that reads superchainConfig.paused(); if true the call reverts with OptimismPortal_CallPaused. The same check applies to proveWithdrawalTransaction. Both the new-request placement (prove) and the claim-of-finalized-funds (finalize) are fully pause-gated.
    E3
    The Guardian address 0x09f7150D8c019BeF34450d6920f6B3608ceFdAf2 (labeled 'Optimism: Guardian Multisig' on Etherscan) holds the pause role via SuperchainConfig. It is a GnosisSafe proxy (Singleton 1.3.0). Both executed transactions on this Safe contain exactly 65 bytes (one signature) in the signatures field — the Gnosis Safe standard packs one 65-byte entry per required signer — strongly indicating threshold = 1. The single signer in those transactions was 0xc2819dc788505aac350142a7a707bf9d03e3bd03 using the 'approved hash' (v=1) mechanism. No maximum pause duration is encoded in OptimismPortal2 or the standard OP Stack SuperchainConfig. The pause has no automatic expiry.
    E4
    No two-tier pause mechanism (emergency-capped vs governance-indefinite) is documented or apparent in the Base contracts. There is a single SuperchainConfig pause path callable by the Guardian. No auto-expiry timer was found. The Security Council (9-of-12 multisig) controls contract upgrades but does NOT hold the pause key; the Guardian holds it unilaterally.
    E5
    The 7-day proof maturity delay is encoded as an immutable in OptimismPortal2: proofMaturityDelaySeconds = 0x93a80 = 604800 seconds = 7 days exactly. No separate daily withdrawal cap or pausable queue mechanism was found beyond the portal-level pause. disputeGameFinalityDelaySeconds (read from ABI constant 0x93a80) is the same 7-day figure.
    E6
    No permissionless escape-hatch or forced-exit mechanism exists. Users cannot withdraw without the OptimismPortal's proveWithdrawalTransaction / finalizeWithdrawalTransaction flow. Under an adversarial-admin scenario where the Guardian pauses indefinitely, there is no on-chain fallback that bypasses the pause.
    E7
    All exit functions (proveWithdrawalTransaction, finalizeWithdrawalTransaction) are permissionless and callable directly on Etherscan's Write-as-Proxy tab for 0x49048044D57e1C92A77f79988d21Fa8fAF74E97e. No project frontend is required for on-chain exit — any wallet or raw calldata tool can invoke them. This is a partial mitigant since the ability to call them is irrelevant when the contract is paused.
    Why is this consensus tentative?
    • weak consensus margin

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

    Run your own prompt Submit run ↗
    Sources claude-sonnet-4-6 url ↗ gpt-5.5-thinking url ↗ grok-xai-4 url ↗ View raw submissions ↗
  4. Autonomy orange 3/3 models agree AI-only 3/3 with chat share link
    No external DeFi dependencies, but instant-upgrade governance power (no timelock) can silently introduce new dependencies for ~100% of ~$2B TVS; Guardian pause is bounded to 3 months
    Verdict

    Choosing orange because the dominant unmitigated risk is the instant-upgrade governance path (A9): Base Governance Multisig can upgrade the OptimismPortal or DisputeGameFactory without any timelock, potentially introducing malicious external dependencies affecting ~100% of TVS (~$2B+ ETH held in OptimismPortal 0x49048044D57e1C92A77f79988d21Fa8fAF74E97e). The green steel-man's observation that there are no autonomous external dependencies is correct — the bridge has no oracle feeds or AMM pool calls that can fail on their own — but this does not eliminate the governance-mutation path. The red steel-man overstates the risk: collusion requires both the 9/12 Security Council (11 independent entities) and the Base Coordinator to act maliciously simultaneously, making spontaneous principal loss very unlikely. Orange fits: governance can materially change expected behavior or introduce new deps without user exit window (Stage 1 characteristic), but the trust model meaningfully bounds the practical blast radius relative to a red single-actor-controlled system. Module: single canonical bridge holds ~100% of protocol TVS; grade orange.

    Steelman argument
    Steelman argument While instant upgrades are possible, they require 9/12 Security Council (independent, geographically diverse entities) plus the Base Coordinator Multisig to both sign; Guardian pauses auto-expire in 3 months; there are no external oracle or AMM dependencies that can fail autonomously; and permissionless fault proofs ensure any valid withdrawal can be finalized by any honest participant.
    Evidence (9)
    A1
    The OptimismPortal (0x49048044D57e1C92A77f79988d21Fa8fAF74E97e) calls only internal OP Stack contracts: DisputeGameFactoryProxy (0x43edB88C4B80fDD2AdFF2412A7BebF9dD42cB40e) to verify withdrawal dispute games, MIPS (0x6463dEE3828677F6270d83d45408044fc5eDB908) as the fault-proof execution engine, and PreimageOracle (0x1fb8cdFc6831fc866Ed9C51aF8817Da5c287aDD3) used by MIPS. There are no external price oracles (no Chainlink, Pyth, Redstone), no AMM pool reads, and no third-party yield wrappers. The L1StandardBridge (0x3154Cf16ccdb4C6d922629664174b904d80F2C35) is a simple ERC-20 escrow with no external integrations. Bridging correctness depends solely on the Ethereum L1 state and OP Stack's own dispute-game logic.
    A2
    Three off-chain actor roles exist. (1) Batch Sender (Sequencer): EOA 0x5050f69a9786f081509234f1a7f4684b5e5b76c9 managed by Coinbase Technologies — sole permissioned actor for ordering and submitting L2 transaction batches to Ethereum. A sequencer failure causes a liveness issue: users can force transactions via L1, but with up to a 12-hour delay. This cannot cause principal loss. (2) Output Proposer: EOA 0x642229f238fb9de03374be34b0ed8d9de80752c5 managed by Coinbase. Since permissionless fault proofs activated on Base mainnet on October 30, 2024, anyone can propose state roots via DisputeGameFactory — the Coinbase proposer is now a convenience, not a trust requirement. (3) Challenger: EOA 0x8Ca1E12404d16373Aef756179B185F27b2994F3a managed by Coinbase; Base operates a challenger continuously, but challenges are also fully permissionless. The permissionless proof system means a single honest challenger guarantees safety regardless of Coinbase's behavior.
    A3
    The Base Bridge IS the canonical L1↔L2 bridge. Deposits are native ETH/ERC-20 locking on L1; withdrawals are verified via the on-chain FaultDisputeGame + 7-day challenge window. No non-canonical bridge (LayerZero, Wormhole, Axelar, custom multisig) carries material TVL in the core bridge flow. The Base-Solana bridge (0x3eff766C76a1be2Ce1aCF2B69c78bCae257D5188) is documented but is a separate, opt-in product entirely outside the canonical Ethereum↔Base bridge scope assessed here.
    A4
    Not applicable. The canonical bridge holds native ETH and ERC-20 tokens directly in escrow on L1; there is no nested collateral, restaking chain, or receipt-of-receipt design.
    A5
    Base is built on Optimism's open-source OP Stack. Contracts are substantially derived from the OP Stack codebase.
    A6
    Three LIVE fallback mechanisms are active: (i) Guardian role (0x09f7150D8c019BeF34450d6920f6B3608ceFdAf2, Gnosis Safe — 'Base Multisig 1' per L2Beat) can pause withdrawals globally via SuperchainConfig; each pause auto-expires after 3 months if not extended or unpaused by the Base Governance Multisig. This covers catastrophic bugs. (ii) Guardian can blacklist individual FaultDisputeGame contracts whose resolution is detected as incorrect, requiring affected users to re-prove against a valid game. (iii) Guardian can change RESPECTED_GAME_TYPE back to PermissionedDisputeGame as an emergency fallback if the FaultDisputeGame implementation has a critical class-wide bug. All three mechanisms are live and enforcing on-chain today. The 3-month auto-expiry on pauses prevents indefinite censorship via Guardian. The DisputeGameFactory's 7-day dispute window itself is a live fallback against invalid withdrawal proposals.
    A7
    Base runs a single centralized sequencer (Coinbase EOA 0x5050f69a9786f081509234f1a7f4684b5e5b76c9). Sequencer failure halts normal L2 throughput, but users can bypass it by submitting forced transactions directly to the L1 inbox, with up to a 12-hour inclusion delay. All batch data is published to Ethereum L1 as blobs/calldata, enabling full permissionless state reconstruction. This is a liveness dependency but not a safety dependency. The sequencer cannot steal funds or prevent eventual withdrawals.
    A8
    Since October 2024, output proposals and challenge participation are fully permissionless via DisputeGameFactory. Any party can run op-proposer or op-challenger. Base operates its own challenger to ensure at least one honest challenger is always running. If ALL parties stopped proposing, new withdrawals could not finalize until a new proposal is made — a liveness issue, not a principal-loss issue, since existing proven withdrawals would still finalize through the timelock expiry.
    A9
    The ProxyAdmin Owner on L1 is 0x7bB41C3008B3f03FE483B28b8DB90e19Cf07595c (Gnosis Safe), which per L2Beat is a 2/2 multisig composed of the Base Coordinator Multisig and the Base Security Council (9/12 of independent entities, activated April 2025). L2Beat explicitly states: 'There is no delay on upgrades.' This means governance can: (a) upgrade OptimismPortal to a new implementation that calls a malicious or different external DisputeGameFactory, (b) change the MIPS fault-proof program to an altered version, (c) add or replace any core component — all without a timelock or exit window for users. As of analysis date, Base is Stage 1 (not Stage 2), precisely because this instant upgrade power exists. The Security Council's 9/12 composition from independent entities (Aerodrome, Moonwell, ChainSafe, Talent Protocol, individuals in diverse jurisdictions) reduces but does not eliminate this trust assumption.
    Sources claude-sonnet-4-6 url ↗ GPT-5.5 Thinking url ↗ grok-built-by-xai url ↗ View raw submissions ↗
  5. Open Access tentative 4/4 models agree AI-only 3/4 with chat share link
    Canonical bridge contracts expose permissionless user paths, while Base’s documented frontend restrictions are passive ToS/policy rather than verified runtime admission gates
    Verdict

    Choosing green because the contract-level evidence supports permissionless admission for the relevant bridge function classes: the onlyEOA modifiers apply to convenience self-recipient calls while public recipient-explicit alternatives remain available, finalization gates authenticate cross-domain messages rather than users, and no fetched evidence shows KYC, onchain blocklists, active frontend geoblocking, or wallet-screening enforcement.

    Steelman argument
    Steelman argument The strongest green argument is that the canonical bridge contracts expose public, non-allowlisted deposit, withdrawal, and message-finalization paths, documented direct-contract/CLI alternatives exist, and the fetched frontend/legal restrictions are passive policy language rather than verified active admission enforcement.
    Evidence (7)
    A1
    The inspected L1/L2 StandardBridge user paths do not show whitelist, KYC, allowlist, accredited-investor, or role-based admission modifiers. Some convenience functions are marked onlyEOA, but equivalent recipient-explicit paths such as depositETHTo, depositERC20To, bridgeETHTo, bridgeERC20To, and withdrawTo are public/external without onlyEOA, so contract wallets are not categorically excluded from the bridge function class.
    A2
    No fetched evidence shows a discretionary keeper, privileged relayer, oracle poster, or committee whose approval is required to admit deposits, withdrawals, or finalized claims. Finalization functions are gated by onlyOtherBridge, which verifies canonical cross-domain message authenticity rather than user identity or operator approval.
    A3-passive
    Base’s Terms include sanctions, eligibility, and wallet-address prohibition language, including that users must not be on the SDN list or located/organized in sanctioned jurisdictions and that Coinbase may prohibit certain wallet addresses from using or engaging in transactions via the Coinbase Sequencer or Services. The fetched material does not show a runtime block banner, KYC wall, wallet-screening provider integration, or HTTP 451-style active restriction.
    A3b-ii
    Base documents independent access paths beyond an official frontend: the bridge docs link programmatic bridging resources, and the Base native bridge examples provide Hardhat command-line flows for ETH/ERC20 deposits, withdrawal initiation, proving, and finalization.
    A4
    The inspected bridge entrypoints do not show an onchain OFAC/blocklist check controlled by Base. The source notes that tokens with their own blocklists may not interoperate properly, which is different from the bridge enforcing a protocol-level address blocklist.
    A5
    Read access is public through docs, explorers, and verified source. Write access for bridge function classes is public at the contract level, with message-finalization restricted to canonical bridge messages rather than identity, KYC, or allowlist status.
    A6
    The fetched Base Terms state that users may use the Services only if legally capable, not barred, not on the SDN list, and not located or organized in a sanctioned jurisdiction; they also reserve Coinbase’s discretion to prohibit certain wallet addresses from using or engaging in transactions via the Coinbase Sequencer or Services.
    Why is this consensus tentative?
    • total support weight 1.22 below confidence floor (1.5)

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

    Run your own prompt Submit run ↗
    Sources gpt-5.5-thinking url ↗ deepseek-reasoner url ↗ grok-built-by-xai url ↗ gemini-3-flash 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.

Base Bridge 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.

  • 58addresses
  • 2verified source
  • 2proxies

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

Basebridge (solana)0x3eff…5188discoverybridge
Basebridge_validator0xaf24…794bdiscovery
Basefactory (erc20)0xdd56…7df2discoveryfactory
Basefactory (L2 OptimismMintableERC20Factory)0xf101…b83bdiscoveryfactory
Basefactory (L2 OptimismMintableERC721Factory)0x4200…0017discoveryfactory
Baseoracle (GasPriceOracle predeploy)0x4200…000fdiscoveryoracle
Baseoracle (L1Block predeploy)0x4200…0015discoveryoracle
Baseother (BaseFeeVault predeploy)0x4200…0019discovery
Baseother (EAS predeploy)0x4200…0021discovery
Baseother (EASSchemaRegistry predeploy)0x4200…0020discovery
Baseother (L1FeeVault predeploy)0x4200…001adiscovery
Baseother (L2CrossDomainMessenger predeploy)0x4200…0007discovery
Baseother (L2ERC721Bridge predeploy)0x4200…0014discovery
Baseother (L2StandardBridge predeploy)0x4200…0010discovery
Baseother (L2ToL1MessagePasser predeploy)0x4200…0016discovery
Baseother (SequencerFeeVault predeploy)0x4200…0011discovery
Baseproxy_admin (L2 ProxyAdmin predeploy — owns L2 predeploy proxies)0x4200…0018discovery
Baserelayer_orchestrator0x8cfa…4741discovery
Basetoken (SOL)0x3119…cf82discoverytoken
Basetoken (WETH9 predeploy)0x4200…0006discoverytoken
ethereumL1ChugSplashProxy0x3154…2c35TVL + discproxybridge
ethereumProxy0x4904…e97eTVL + discproxy
EthereumAddressManager0x8efb…bae2discovery
Ethereumbatch_sender0x5050…76c9discovery
Ethereumchallenger0x8ca1…4f3adiscovery
Ethereumfactory (DisputeGameFactoryProxy — creates FaultDisputeGame instances; corrected from typo in pinned address_book)0x43ed…b40ediscoveryfactory
Ethereumfactory (OptimismMintableERC20Factory L1)0x05cc…1d84discoveryfactory
Ethereumguardian0x09f7…daf2discoverymultisig
EthereumL1CrossDomainMessenger0x866e…0afadiscovery
EthereumL1ERC721Bridge0x608d…1e53discovery
Ethereumother (AnchorStateRegistryProxy — anchors L2 state proposals)0x909f…4e72discovery
Ethereumother (Batch Inbox — EOA with no known private key; 0xff…+chainId 8453)0xff00…8453discovery
Ethereumother (DelayedWETHProxy — FDG bond escrow)0x2453…c8ecdiscovery
Ethereumother (DelayedWETHProxy — PDG bond escrow)0x64ae…fd4ddiscovery
Ethereumother (FaultDisputeGame implementation)0x6ddb…7499discovery
Ethereumother (MIPS — fault-proof VM)0x6463…b908discovery
Ethereumother (PermissionedDisputeGame implementation)0x58bf…266adiscovery
Ethereumother (PreimageOracle — preimage oracle for fault proofs)0x1fb8…add3discoveryoracle
Ethereumother (Security Council signer — Aerodrome)0xa595…cb73discovery
Ethereumother (Security Council signer — Blackbird)0xa565…cdfediscovery
Ethereumother (Security Council signer — ChainSafe)0x1c56…2e2bdiscovery
Ethereumother (Security Council signer — Juan Suarez)0x99db…71d2discovery
Ethereumother (Security Council signer — Moonwell)0x21c7…851fdiscovery
Ethereumother (Security Council signer — Moshicam)0xa8ee…fb06discovery
Ethereumother (Security Council signer — Roberto Bayardo)0x18e9…1b3ediscovery
Ethereumother (Security Council signer — Seneca)0x82c8…e766discovery
Ethereumother (Security Council signer — Talent Protocol)0x5ff5…acc6discovery
Ethereumother (Security Council signer — Toady Hawk)0x0e8a…252fdiscovery
Ethereumother (sole owner of Guardian Safe)0xc281…bd03discoverymultisig
Ethereumother (sub-owner of Proxy Admin Owner Safe)0x20ac…a4dddiscoverymultisig
Ethereumother (sub-owner of Proxy Admin Owner Safe)0x9855…46a1discoverymultisig
Ethereumother (SystemConfig — chain configuration parameters)0x73a7…4072discovery
Ethereumother (SystemDictator — historical deployment helper)0x1fe3…e557discovery
Ethereumoutput_proposer0x6422…52c5discovery
Ethereumproxy_admin0x0475…059ediscovery
Ethereumproxy_admin (owner)0x7bb4…595cdiscoverymultisig
EthereumSurfacer for the address as pinned in address_book reports 'No verified ABI found … etherscan + sourcify both failed' — confirming the pinned address (with dD) does NOT correspond to a verified contract on Ethereum mainnet, supporting the conclusion that it is a 1-character typo of the actual DisputeGameFactoryProxy address.0x43ed…b40ediscovery
Ethereumsystemconfig_owner0x1453…e056discoverymultisig

Protocol Info

Security

[:] Source: DEFI@home quorum
Audits
3 audits
Security contact
https://docs.base.org/base-chain/security/report-vulnerability

Technical

[:] Source: DEFI@home quorum
Upgradeability
Upgradeable

Provenance

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