DeFiPunk'd

LayerZero

2 deployments · $7.5B aggregate TVL · Bridge

Deployments

Each deployment is rated independently. Pick one to see its rating, risk analysis, and stage.

TVL $7.5B
Type Bridge
Chains Ethereum, Arbitrum, Base, Avalanche, Polygon +55
View on DeFiLlama ↗
Control criteria
Upgradeability Immutable Bug bounty immunefi.com Governance forum Docs docs.layerzero.network
About

LayerZero V2 is an omnichain messaging protocol. Applications send cross-chain messages through EndpointV2, with send and receive message libraries, DVNs, and executors used for verification and delivery. The distinctive mechanism is configurable cross-chain messaging rather than a single canonical liquidity bridge.

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 102 addresses on file · 1 run Submit run ↗
  • Verifiability Unverified Submit run ↗
  • Control ✓ 3/3 models agree AI-only weak orange — only 0/3 sources have a public chat share link; total support weight 0.46 below confidence floor (1.5) Submit run ↗
  • Ability to exit ✓ 3/3 models agree AI-only weak green — weak consensus margin; only 0/3 sources have a public chat share link; total support weight 0.37 below confidence floor (1.5) Submit run ↗
  • Autonomy ✓ 3/3 models agree AI-only weak orange — weak consensus margin; only 0/3 sources have a public chat share link; total support weight 0.42 below confidence floor (1.5) Submit run ↗
  • Open Access ✓ 3/3 models agree AI-only weak green — only 0/3 sources have a public chat share link; total support weight 0.45 below confidence floor (1.5) Submit run ↗
  • Audit all 5 dimensions · one prompt Submit run ↗
  1. Verifiability tentative
    Open source + 8 audits

    Protocol publishes a GitHub repository and has at least one audit on record. This is a coarse Phase-0 signal only: auditor reputation, scope, and post-audit review coverage are not yet weighted.

    Run your own prompt Submit run ↗
  2. Control tentative 3/3 models agree AI-only 0/3 with chat share link
    All EndpointV2 and MessageLib contracts are immutable; owner on each chain is a 3-of-5 custom OneSig multisig (no timelock) with T1-reachable power to change default message libraries for all OApps relying on protocol defaults
    Verdict

    Choosing orange because the highest-tier action reachable by the OneSig 3-of-5 is T1 (setDefaultSendLibrary / setDefaultReceiveLibrary on EndpointV2, setDefaultUlnConfigs on SendUln302) with a 0-second uncontested fast path, and the 3-of-5 OneSig fails the Security Council standard on multiple dimensions (fewer than 7 signers, signers not publicly identified, non-standard contract type). The green argument — that OApps can self-custody their library — is valid for well-configured OApps but not for the large fraction of OApps relying on protocol defaults.

    Steelman argument
    Steelman argument A 3-of-5 custom multisig without a timelock sits on a T1 path (setDefaultSendLibrary/setDefaultReceiveLibrary), and signer identities are not publicly documented; this fails every Security Council criterion, so red would require only 2-of-3 or an EOA — the higher signer count keeps this in orange.
    Evidence (7)
    C1
    Ethereum EndpointV2 (0x1a44076050125825900e736c501f859c50fE728c) owner() returns 0xBe010A7e3686FdF65E93344ab664D065A0B02478, a contract named 'OneSig'. Arbitrum EndpointV2 (same address) owner() returns 0x9A3cE220D17a92dd4DF9766ceE48fDd0c448bA4f (also a OneSig). Optimism/Unichain endpoints share owner 0x32b323EFC09D5812510B6510b242647C603947Ab (also a OneSig). All OneSig contracts have identical signer sets: 0x0cb72C1F6a36c225A7E2B21712E8853A4A1acc47, 0x5bC6AA6ad117A8B50ABf9E1658971f5DA1968c5c, 0x73E9c017Ad37e2113e709D8070Cc9E1b28180e1e, 0x771dcAcB96024d1e55Fd21Fe8a8187AA7EC9e77e, 0xe67DB04d7eFF4e9ec282eD929632D4FF058112d7; threshold=3, executorRequired=true with 1 executor (0x39f86ECef62c5bcE23428d6b7c7050D9Ecb0e346). SendUln302 and ReceiveUln302 on Ethereum have the same owner.
    C2
    All core contracts are immutable (not proxied): defipunkd ABI endpoint returns proxy=null for EndpointV2 (0x1a44076050125825900e736c501f859c50fE728c, Ethereum) and SendUln302 (0xbB2Ea70C9E858123480642Cf96acbcCE1372dCe1, Ethereum). The LayerZero V2 docs and GitHub repo explicitly describe 'immutable core contracts' and 'append-only MessageLib registry'. Once registered, message libraries cannot be removed.
    C3
    No timelock contract was found. The execution path is: 3-of-5 OneSig signers sign a Merkle-tree transaction bundle, the single executor (0x39f8...) submits it, and it executes immediately. There is no queuing delay. Total uncontested-fast-path delay: 0 seconds.
    C4
    The OneSig on Ethereum (0xBe010A7e3686FdF65E93344ab664D065A0B02478) has 5 signers and threshold=3. The same 5 EOA signers appear on all chain-specific OneSig contracts across Ethereum, Arbitrum, Optimism, Unichain, and Linea. Signer identities are not publicly documented. The single executor is also unidentified. No separate emergency multisig or guardian role was found. The OneSig is NOT a standard Gnosis Safe — it is a custom contract with Merkle-tree-based batch transaction support.
    C5
    No on-chain governor, GovernorBravo, or OZ Governor was found. No voting token or governance forum was identified this run. Ownership is held directly by the per-chain OneSig multisigs.
    C6
    No separate emergency-pause guardian or role distinct from the OneSig owner was found on the EndpointV2 or MessageLib contracts. The only special mechanism is the hardcoded 'blockedLibrary' (0x1ccBf0db9C192d969de57E25B3fF09A25bb1D862) which is a permanent sentinel in the registry — it cannot be reassigned by the owner.
    C7
    Highest tier: T1. The OneSig owner can call (a) registerLibrary(address) to add a new MessageLib to the append-only registry, then (b) setDefaultSendLibrary(uint32 dstEid, address lib) and setDefaultReceiveLibrary(uint32 srcEid, address lib, uint256 expiry) on EndpointV2 to redirect default message verification for all OApps that have not pinned their own library. A malicious library substituted as the default could forge verified messages and drain OFT escrows on destination chains. Additionally, the SendUln302 owner can call setDefaultUlnConfigs and setDefaultExecutorConfigs to change default DVN and executor assignments for all OApps using defaults. No on-chain bound limits these changes. Severity: T1 on the uncontested path with no timelock.
    Why is this consensus tentative?
    • only 0/3 sources have a public chat share link
    • total support weight 0.46 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 no url gpt-5.5-thinking no url grok-xai no url View raw submissions ↗
  3. Ability to exit tentative 3/3 models agree AI-only 0/3 with chat share link
    Message execution on EndpointV2 is fully permissionless with no pause mechanism; the protocol holds no user funds directly, and lzReceive is callable by any address without admin approval
    Verdict

    Choosing green because the EndpointV2 itself has zero pause functionality, message execution is fully permissionless, and no admin action can block the delivery of already-verified messages. The orange argument about DVN liveness is real but belongs in the Autonomy slice (A2), not here — the EndpointV2's access control gates on message delivery are absent. The red argument about the default library redirect requires the additional step of changing OApp library config, and only prevents new sends, not claims of already-verified messages.

    Steelman argument
    Steelman argument The EndpointV2 has no pause mechanism, no admin-required exit function, no queued withdrawal with indefinite delay, and lzReceive is callable by any address — once a message is verified by DVNs, no admin action can prevent its execution.
    Evidence (7)
    E1
    LayerZero V2 is a messaging protocol, not a fund vault. The EndpointV2 does not hold user tokens. The relevant exit functions are: (a) lzReceive((uint32,bytes32,uint64),address,bytes32,bytes,bytes) — deliver a verified message to the destination OApp; (b) clear(address,(uint32,bytes32,uint64),bytes32) — OApp owner or delegate can clear a verified payload; (c) nilify(address,uint32,bytes32,uint64,bytes32) — OApp owner or delegate can mark a nonce as nil (cancel a message); (d) skip(address,uint32,bytes32,uint64) — OApp owner or delegate can advance the lazy inbound nonce past a nonce. These functions are enumerated from the ABI returned by the defipunkd ABI endpoint for EndpointV2.
    E2
    The lzReceive function is callable by any address (permissionless). The only check is that the caller passes a valid (already-verified) packet — verified meaning the payload hash has been committed to the ReceiveUln302 by the configured DVNs. The clear/nilify/skip functions are restricted to the OApp address or its delegate via _assertAuthorized, which is enforced by EndpointV2. Neither lzReceive nor any other core execution path has a whenNotPaused guard or any admin-triggered gate.
    E3
    No pause role, PAUSE_ROLE, guardian, or isPaused state variable was found in the EndpointV2 ABI (verified via defipunkd ABI endpoint, proxy=null). The defipunkd surfacer for EndpointV2 (Ethereum) lists 10 zero-arg view methods (EMPTY_PAYLOAD_HASH, NIL_PAYLOAD_HASH, blockedLibrary, eid, getRegisteredLibraries, getSendContext, isSendingMessage, lzToken, nativeToken, owner) — none of which are a 'paused' state. No PAUSE_INFINITELY or time-capped pause was found.
    E4
    No emergency pause path was found. The same OneSig 3-of-5 that controls protocol configuration has no dedicated pause function on the EndpointV2. The blockedLibrary (0x1ccBf0db9C192d969de57E25B3fF09A25bb1D862) is a reserved sentinel — it is permanently registered as the first library and cannot be set as the effective library for active OApps without each OApp's own delegate calling setSendLibrary/setReceiveLibrary.
    E5
    There is no withdrawal queue in the core EndpointV2. Message delivery is event-driven: once a DVN commits a verified payload hash, any executor (or the user directly) can call lzReceive. There is no daily cap or max queue duration at the EndpointV2 level. Individual OApp contracts (e.g., OFT implementations) may have their own queuing or rate-limiting, but those are not in scope for this assessment of the core protocol.
    E6
    If a DVN fails to verify a message, the message is frozen (not delivered). The protocol's escape hatch for such cases is: (a) the OApp operator can switch to a different DVN by calling setReceiveLibrary or setConfig on the EndpointV2 delegate, reconfiguring the security stack; (b) the nilify function allows the OApp operator to cancel a pending nonce with a valid guardian signature; (c) execution of already-verified messages is permissionless. There is no forced-exit mechanism for end users at the EndpointV2 level when DVN liveness fails — this is acknowledged as a DVN-liveness risk in the Autonomy slice.
    E7
    All core functions (lzReceive, send, etc.) are directly callable via any standard Ethereum interaction tool (Etherscan write tab, Foundry, ethers.js). No LayerZero frontend or off-chain infrastructure is required to submit a transaction. The LayerZero Scan tool at layerzeroscan.com provides monitoring but is not required for execution.
    Why is this consensus tentative?
    • weak consensus margin
    • only 0/3 sources have a public chat share link
    • total support weight 0.37 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 no url gpt-5.5-thinking no url grok-xai no url View raw submissions ↗
  4. Autonomy tentative 3/3 models agree AI-only 0/3 with chat share link
    LayerZero V2 depends on DVN committees for message verification; the default LayerZero DVN is centralized, so DVN liveness failure can freeze cross-chain message delivery without causing direct loss of principal in the core protocol, but in-flight OFT assets may be temporarily stranded
    Verdict

    Choosing orange because DVN liveness failure (specifically for OApps using the default LayerZero-operated DVN) constitutes a material dependency that can freeze message delivery and strand OFT assets, materially changing expected performance. This qualifies as orange under the rubric (committee-based oracles, fallback paths incomplete for users who cannot self-configure). The impacted TVS under a single-DVN failure is unclear but non-trivial given the large share of OApps using default configurations. However, the failure mode is delayed delivery rather than permanent principal loss, and the permissionless execution model prevents total protocol seizure. Impacted TVS from DVN liveness failure: ~50% of OFT value-in-transit for OApps using default LayerZero DVN (estimate; exact figure not determinable this run).

    Steelman argument
    Steelman argument DVN liveness failure can freeze cross-chain messages and strand OFT assets on source chains indefinitely, but OApp operators retain the ability to reconfigure their DVN stack, and permanently locked principal is prevented by the permissionless execution model — losses are at worst temporary impairment of expected performance.
    Evidence (8)
    A1
    The EndpointV2 itself calls no external price oracles, Chainlink feeds, or AMM pools. Its primary external interactions are: (a) the configured MessageLib (SendUln302 or ReceiveUln302) called during send/receive flows; (b) DVN contracts (implementing ILayerZeroDVN) — DVNs are called via event emission on-chain but must submit their verification off-chain by calling ReceiveUln302.verify(); (c) Executor contracts called via assignJob() in SendUln302. None of these are price oracles. The core protocol does not call any external DeFi protocol.
    A2
    DVNs (Decentralized Verifier Networks) are the primary off-chain actor committees for LayerZero V2. Each DVN listens to source-chain events, validates the message, and calls ReceiveUln302.verify() on the destination chain with a payload hash. The default DVN is operated by LayerZero Labs. If LayerZero's default DVN ceases to operate, all OApps using the default DVN configuration cannot have messages verified. However: (a) OApp operators can reconfigure their DVN set via the EndpointV2; (b) third-party DVNs exist (confirmed from docs and DVN ecosystem page); (c) DVN liveness failure does NOT cause loss of principal — locked OFT tokens remain on source chains and can be unlocked by OApp operators through alternative DVN configurations or manual recovery. DVN failure size: unmitigated for default-DVN users; mitigated for OApps with custom DVN stacks.
    A3
    LayerZero V2 IS the cross-chain messaging protocol — it has no external bridge dependency. OFTs and OApps built on LayerZero V2 trust LayerZero as their cross-chain layer. The core protocol trusts the configured DVN set for each route. The DVN trust model for each OApp is application-configurable; there is no shared mandatory bridge validator set.
    A4
    The LayerZero V2 core protocol has no nested collateral chains. OFTs built on top of LayerZero may have nested asset risk (e.g., OFT wrapping wstETH), but those are per-OApp risks, not core-protocol dependencies.
    A6
    Fallback mechanisms: (a) Execution liveness: Execution is permissionless — if the default Executor stops running, users or OApp operators can call lzReceive directly or use any third-party executor. Status: LIVE and enforcing on-chain. (b) DVN fallback: OApp operators can switch DVNs at any time by calling setConfig/setReceiveLibrary via the EndpointV2. No time lock on this switch. Status: LIVE. (c) No protocol-level oracle sanity check exists — DVNs are trusted to report correct payload hashes. (d) OApps can configure multiple DVNs (M-of-N required + optional threshold) to increase resilience. Per the whitepaper search result: DVN failure by a required DVN freezes the channel for that OApp. No automatic failover at the protocol level.
    A7
    LayerZero V2 is deployed on third-party L1/L2 chains (Ethereum, Arbitrum, Base, etc.) as a permissionless application. The sequencers/validators of those chains are substrate, not protocol-level dependencies. LayerZero V2 is not an appchain or rollup. Not applicable.
    A8
    Executor liveness: Executors are off-chain services that pay gas to deliver verified messages. If no executor runs, users must call lzReceive directly (permissionless). Message delivery is never permanently lost — only delayed until an executor (or the user) calls lzReceive. Executor role is fully permissionless and openly competitive: any actor willing to pay destination gas can deliver a packet. No graceful degradation issues from executor failure beyond user needing to self-deliver.
    A9
    Governance-mutable dependency surface: The OneSig owner can call setDefaultSendLibrary(uint32,address) and setDefaultReceiveLibrary(uint32,address,uint256) to change which MessageLib is used as the default for each route. This means the owner can silently change the external verification dependency (the MessageLib contract and the DVNs it enforces) for all OApps that have not pinned their own library configuration. No timelock protects this switch. This is both a Control-slice T1 finding and an A9 finding: the governance-mutable dependency is the default DVN configuration embedded in each MessageLib's default ULN configs.
    Why is this consensus tentative?
    • weak consensus margin
    • only 0/3 sources have a public chat share link
    • total support weight 0.42 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 no url gpt-5.5-thinking no url grok-xai no url View raw submissions ↗
  5. Open Access tentative 3/3 models agree AI-only 0/3 with chat share link
    EndpointV2 and MessageLib contracts are fully permissionless with no whitelist or KYC; the official website has OFAC self-certification ToS but multiple independent access paths exist including direct contract interaction and third-party integrations
    Verdict

    Choosing green because the EndpointV2 and MessageLib contracts are fully permissionless at the admission layer: send() and lzReceive() carry no whitelist, KYC, or operator-approval gate, and at least three independent access paths (SDK, Etherscan direct-call, third-party integrations like Stargate) exist that do not require LayerZero Labs' official frontend cooperation. Frontend ToS sanctions self-certification is reported as context (A3-passive) and does not affect the grade. The orange argument about DVN operational capture is a liveness concern, not an admission concern, and belongs in the Autonomy slice.

    Steelman argument
    Steelman argument The EndpointV2 has no admission gates, no runtime whitelist, no contract-level sanctions enforcement, and multiple fully independent access paths (SDK, direct contract calls, third-party frontends and integrations) exist.
    Evidence (7)
    A1
    No onlyWhitelisted, onlyRole (for user-facing functions), allowlist, isAccredited, or isKYCed modifier was found in the EndpointV2 ABI (verified via defipunkd API). The send() function takes a Packet struct and fee payment — no caller whitelist. The lzReceive() function takes an Origin struct and executes the message — no caller whitelist. Owner-only functions (registerLibrary, setDefaultSendLibrary, etc.) are admin functions, not user-facing entry points.
    A2
    DVNs (verification committees) are required for message verification but not for message submission. A user's send() call does not require DVN approval to be admitted — the transaction is processed unconditionally on the source chain. DVN approval is required for the downstream verification step (permitting execution on the destination chain). This is a liveness dependency, not an admission gate. Separately, Executors deliver messages permissionlessly — any address can pay destination gas to call lzReceive. No single privileged operator controls admission to the messaging system.
    A3
    Frontend restrictions (context only): The official layerzero.network Terms of Use require users to self-certify they are not subject to OFAC sanctions or citizens/residents of comprehensively sanctioned jurisdictions. Verbatim from the terms: 'You further represent that you are not (a) the subject of economic or trade sanctions administered or enforced by any governmental authority or otherwise designated on any list of prohibited or restricted parties (including but not limited to the list maintained by the Office of Foreign Assets Control of the U.S. Department of the Treasury) or (b) a citizen, resident, or organized in a jurisdiction or territory that is the subject of comprehensive country-wide, territory-wide, or regional economic sanctions by the United States.' This is an A3-passive self-certification clause, not runtime enforcement. No evidence of IP-based geo-blocking or wallet-screening oracle on the official site was found this run.
    A3b
    Independent access paths confirmed: (a) Published SDK/devtools at https://github.com/LayerZero-Labs/LayerZero-v2 — OApp developers and end users can interact directly with EndpointV2 using standard Solidity tooling; (b) Direct contract interaction via Etherscan/block-explorer write tabs (EndpointV2 is verified on all supported chains); (c) Third-party DeFi integrations: Stargate Finance (stargate.finance), OFT-based token bridges across major chains, aggregators such as LayerZero Scan routing through the contracts; (d) The LayerZero Whitepaper documents the protocol as 'permissionless infrastructure' with open sender/receiver semantics. These paths are operated independently of LayerZero Labs' official interface.
    A4
    No on-chain blocklist or address screening was found in the EndpointV2 or MessageLib ABIs. OFAC compliance is a self-certification in the website ToS only. No Chainalysis, TRM, or Elliptic oracle integration was observed in the core contracts.
    A5
    Read access: The EndpointV2 exposes all state via public view methods (owner, eid, getRegisteredLibraries, getConfig, etc.) accessible to any caller without restriction. Write access: send(), lzReceive(), and setConfig() (when called by the OApp itself) are permissionless. Admin write methods (registerLibrary, setDefaultSendLibrary) are restricted to the OneSig owner — these are admin functions, not user entry/exit functions.
    A6
    ToS verbatim sanctions clause from https://layerzero.network/terms (fetched this run): 'you are not (a) the subject of economic or trade sanctions...or (b) a citizen, resident, or organized in a jurisdiction or territory that is the subject of comprehensive country-wide, territory-wide, or regional economic sanctions by the United States.' This is a self-certification attestation; no runtime enforcement in the LayerZero V2 contracts.
    Why is this consensus tentative?
    • only 0/3 sources have a public chat share link
    • total support weight 0.45 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 no url gpt-5.5-thinking no url grok-xai 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.

LayerZero V2 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.

  • 97addresses
  • 0verified source
  • 0proxies

Abstractother (EndpointV2, eid 30324)0x5c6c…4ae7discovery
Arbitrumother (EndpointV2, eid 30110)0x1a44…728cdiscovery
Arbitrumother (LZ Dead DVN, eid 30110)0x758c…8ec1discovery
Arbitrumother (LZ Executor, eid 30110)0x31ca…660ddiscovery
Arbitrumother (ReadLib1002, eid 30110)0xbcd4…beffdiscovery
Arbitrumother (ReceiveUln302, eid 30110)0x7b9e…05e6discovery
Arbitrumother (SendUln302, eid 30110)0x975b…493adiscovery
Astarother (EndpointV2, eid 30210)0x1a44…728cdiscovery
Avalancheother (EndpointV2, eid 30106)0x1a44…728cdiscovery
Avalancheother (LZ Executor, eid 30106)0x90e5…bd9cdiscovery
Avalancheother (ReceiveUln302, eid 30106)0xbf35…2c61discovery
Avalancheother (SendUln302, eid 30106)0x197d…558adiscovery
Baseother (EndpointV2, eid 30184)0x1a44…728cdiscovery
Baseother (LZ Dead DVN, eid 30184)0x6498…9703discovery
Baseother (LZ Executor, eid 30184)0x2cca…bae4discovery
Baseother (ReceiveUln302, eid 30184)0xc70a…4bafdiscovery
Baseother (SendUln302, eid 30184)0xb532…dda2discovery
Berachainother (EndpointV2, eid 30362)0x6f47…dd5bdiscovery
Binanceother (EndpointV2, eid 30102)0x1a44…728cdiscovery
Binanceother (LZ Executor, eid 30102)0x3ebd…4859discovery
Binanceother (ReceiveUln302, eid 30102)0xb217…cec1discovery
Binanceother (SendUln302, eid 30102)0x9f8c…23dediscovery
Blastother (EndpointV2, eid 30243)0x1a44…728cdiscovery
Blastother (LZ Executor, eid 30243)0x4208…0a0bdiscovery
Blastother (ReceiveUln302, eid 30243)0x3775…b5b6discovery
Blastother (SendUln302, eid 30243)0xc1b6…9821discovery
BOBother (EndpointV2, eid 30279)0x1a44…728cdiscovery
Cantoother (EndpointV2, eid 30159)0x1a44…728cdiscovery
Celoother (EndpointV2, eid 30125)0x1a44…728cdiscovery
Citreaother (EndpointV2, eid 30403)0x6f47…dd5bdiscovery
Confluxother (EndpointV2, eid 30212)0x1a44…728cdiscovery
Ethereumother (BlockedMessageLib, eid 30101)0x1ccb…d862discovery
Ethereumother (EndpointV2, eid 30101)0x1a44…728cdiscovery
Ethereumother (LZ Dead DVN, eid 30101)0x747c…f6acdiscovery
Ethereumother (LZ Executor, eid 30101)0x1732…3059discovery
Ethereumother (ReadLib1002, eid 30101)0x74f5…db9ddiscovery
Ethereumother (ReceiveUln302, eid 30101)0xc02a…24c2discovery
Ethereumother (SendUln302, eid 30101)0xbb2e…dce1discovery
Fantomother (EndpointV2, eid 30112)0x1a44…728cdiscovery
Flareother (EndpointV2, eid 30295)0x1a44…728cdiscovery
Flowother (EndpointV2, eid 30336)0xcb56…aaaadiscovery
Fraxtalother (EndpointV2, eid 30255)0x1a44…728cdiscovery
Goatother (EndpointV2, eid 30361)0x6f47…dd5bdiscovery
Harmonyother (EndpointV2, eid 30116)0x1a44…728cdiscovery
Hederaother (EndpointV2, eid 30316)0x3a73…9aa9discovery
Hemiother (EndpointV2, eid 30329)0x6f47…dd5bdiscovery
Hyperliquid L1other (EndpointV2, eid 30367)0x3a73…9aa9discovery
Inkother (EndpointV2, eid 30339)0xca29…e958discovery
Katanaother (EndpointV2, eid 30375)0x6f47…dd5bdiscovery
Kavaother (EndpointV2, eid 30177)0x1a44…728cdiscovery
Klaytnother (EndpointV2, eid 30150)0x1a44…728cdiscovery
Lineaother (EndpointV2, eid 30183)0x1a44…728cdiscovery
Lineaother (LZ Executor, eid 30183)0x0408…a7c7discovery
Lineaother (ReceiveUln302, eid 30183)0xe22e…b205discovery
Lineaother (SendUln302, eid 30183)0x3204…ea06discovery
Liskother (EndpointV2, eid 30321)0x6f47…dd5bdiscovery
Mantaother (EndpointV2, eid 30217)0x1a44…728cdiscovery
Mantleother (EndpointV2, eid 30181)0x1a44…728cdiscovery
MegaETHother (EndpointV2, eid 30398)0x6f47…dd5bdiscovery
Metisother (EndpointV2, eid 30151)0x1a44…728cdiscovery
Modeother (EndpointV2, eid 30260)0x1a44…728cdiscovery
Monadother (EndpointV2, eid 30390)0x6f47…dd5bdiscovery
Moonriverother (EndpointV2, eid 30167)0x1a44…728cdiscovery
Morphother (EndpointV2, eid 30322)0x6f47…dd5bdiscovery
Nibiruother (EndpointV2, eid 30369)0x2a5e…aefddiscovery
Op_Bnbother (EndpointV2, eid 30202)0x1a44…728cdiscovery
Optimismother (EndpointV2, eid 30111)0x1a44…728cdiscovery
Optimismother (LZ Executor, eid 30111)0x2d2e…666ediscovery
Optimismother (ReceiveUln302, eid 30111)0x3c49…2063discovery
Optimismother (SendUln302, eid 30111)0x1322…6e95discovery
Peaqother (EndpointV2, eid 30302)0x6f47…dd5bdiscovery
Plasmaother (EndpointV2, eid 30383)0x6f47…dd5bdiscovery
Plume Mainnetother (EndpointV2, eid 30370 plumephoenix)0xc1b1…cb36discovery
Polygonother (EndpointV2, eid 30109)0x1a44…728cdiscovery
Polygonother (LZ Executor, eid 30109)0xcd3f…885bdiscovery
Polygonother (ReceiveUln302, eid 30109)0x1322…6e95discovery
Polygonother (SendUln302, eid 30109)0x6c26…9da3discovery
RSKother (EndpointV2, eid 30333)0xcb56…aaaadiscovery
Scrollother (EndpointV2, eid 30214)0x1a44…728cdiscovery
Scrollother (ReceiveUln302, eid 30214)0x8363…9808discovery
Scrollother (SendUln302, eid 30214)0x9bbe…a03bdiscovery
Seiother (EndpointV2, eid 30280)0x1a44…728cdiscovery
Soneiumother (EndpointV2, eid 30340)0x4bcb…3a19discovery
Sonicother (EndpointV2, eid 30332)0x6f47…dd5bdiscovery
Stableother (EndpointV2, eid 30396)0x6f47…dd5bdiscovery
Swellchainother (EndpointV2, eid 30335)0xcb56…aaaadiscovery
TACother (EndpointV2, eid 30377)0x6f47…dd5bdiscovery
Taikoother (EndpointV2, eid 30290)0x1a44…728cdiscovery
Tempoother (EndpointV2, eid 30410)0x20bb…cc9cdiscovery
Unichainother (EndpointV2, eid 30320)0x6f47…dd5bdiscovery
World Chainother (EndpointV2, eid 30319)0x6f47…dd5bdiscovery
X Layerother (EndpointV2, eid 30274)0x1a44…728cdiscovery
XDCother (EndpointV2, eid 30365)0xcb56…aaaadiscovery
zkSync Eraother (EndpointV2, eid 30165)0xd07c…ddbfdiscovery
zkSync Eraother (LZ Executor, eid 30165)0x664e…d8a6discovery
zkSync Eraother (ReceiveUln302, eid 30165)0x0483…59e1discovery
zkSync Eraother (SendUln302, eid 30165)0x07fd…e12cdiscovery

Protocol Info

Links

[defillama] Source: DeFiLlama [:] Source: DEFI@home quorum
Twitter
@LayerZero_Core

Security

[:] Source: DEFI@home quorum
Audits
9 audits
Security contact
https://docs.layerzero.network/community/bug-bounty-support

Technical

[:] Source: DEFI@home quorum
Upgradeability
Immutable

Provenance

[defillama] Source: DeFiLlama [:] Source: DEFI@home quorum
Review status
listed
Updated
2026-06-23 16:47 UTC