PancakeSwap AMM V3

Orange · 45/100 Data confidence 74/100

Missing critical evidence: incident, governance. The score is capped until coverage improves.

Executive summary

Executive summary is being prepared.

Score

Component Weight Raw Points Reason
security 25% 90 22.5 4 audit(s); no fresh audit; active bug bounty bonus
incidents 25% 50 12.5 0 incident(s) in 730-day window, losses $0; 0 high/critical news
verifiability 15% 83 12.4 0 onchain, 16 two-source, 6 one-source of 23 fact(s)
stability 15% 50 7.5 stability not established; 0 current depeg event(s)
adoption 10% 50 5.0 TVL bucket 7; neutral context, not a safety signal
governance 10% 0 0.0 legal enforcement/sanction -30
  • Active regulatory enforcement (−15): legal fact mentions enforcement or sanction

Identification

protocol identification

two sources

PancakeSwap AMM V3 is a concentrated‑liquidity DEX upgrade of PancakeSwap, deployed in April 2023 and operating on multiple chains including Ethereum and opBNB. ### Protocol Identification

  • Name: PancakeSwap V3 (often “PancakeSwap AMM V3”).
  • Website: pancakeswap.finance (core app).
  • Docs / Dev portal: developer.pancakeswap.finance with dedicated V3 contract section.
  • Category: Concentrated Liquidity AMM DEX (CLAMM), similar to Uniswap V3.
  • Launch date: V3 launched 8 April 2023, one day after Uniswap V3 BSL expiry.
  • Chains (relevant to this mandate):
  • Ethereum mainnet – supported alongside other L1/L2s.
  • opBNB – listed among PancakeSwap V3 deployment chains (via router addresses).
  • Native token: CAKE (utility/governance token of PancakeSwap ecosystem). ### Main V3 Contract Addresses (Ethereum & opBNB) *(On‑chain verification via Dune is not available in this run – Not verifiable as of 2026‑08‑29.)*
  • Ethereum – V3 Factory
  • Address referenced as PancakeV3Factory for BSC/Ethereum: 0x0BFbCF9fa4f9C56B0F40a671Ad40E0805A091865.
  • Etherscan labels contract “PancakeSwap V3: Factory”, with verified source code under GPL-2.0‑or‑later.
  • Ethereum – Smart / Universal Router V3
  • 0x13f4EA83D0bd40E75C8222255bc855a974568Dd4, shown as “PancakeSwap: Smart Router V3” on Etherscan with verified code referencing the V3 deployer and factory.
  • opBNB – Universal Router V3
  • Developer docs list PancakeSwap v3 Universal Router addresses including opBNB: 0xB89a6778D1efE7a5b7096757A21b810CC2886fa1 and another opBNB router 0xa8EEA7aa6620712524D18D742821848e55E773B5. ### Fork Lineage & Design Changes
  • Upstream: Explicitly described as adopting the concentrated liquidity model of Uniswap V3.
  • License / fork timing: Deployed immediately after Uniswap V3’s Business Source License expired; PancakeSwap V3 contracts released under GPL‑2.0.
  • Differences vs. Uniswap V3:
  • Re‑branded contracts (PancakeV3Factory, PancakeV3Pool) and integration into PancakeSwap’s broader ecosystem (MasterChef, LM pools, routers).
  • Fee tiers, pool deployment, and tick spacing follow the Uniswap V3 CLAMM pattern with minor tweaks noted in external documentation. ### Audit & Fork‑Risk History
  • External review notes that PancakeSwap V3 and StableSwap contracts were audited by OpenZeppelin and Quantstamp.
  • A third‑party DeFi doc states PancakeSwap deployed a “slightly tweaked” Uniswap V3 codebase and links audits by SlowMist for related v3 components (MasterChefV3/LmPool), though those are not always used in downstream forks.
  • Independent coverage highlights no major exploits of the core DEX since early PancakeSwap deployment, with multiple audits across CertiK, PeckShield, OpenZeppelin, Quantstamp. No evidence in retrieved sources of malicious modifications in PancakeSwap’s own V3 fork or widely‑reported exploit patterns in direct V3 forks; this should nonetheless be treated as not fully verifiable as of 2026‑08‑29 without raw on‑chain plus full audit report review.
Evidence (14)

maturity

two sources

PancakeSwap AMM V3 appears to be a real, functioning product rather than a pure landing page: the developer docs include v3 contract addresses and a dedicated docs section for building trading agents on PancakeSwap V3, which strongly indicates an operational protocol surface and integration layer. The available evidence also shows an open developer/API surface, including documented developer docs and third-party GraphQL/API integrations for PancakeSwap V3. What is not verifiable as of 2026-08-29: live deposit/withdrawal functionality, broken-link rates, fake metrics, and template/clone signs on the main user portal, because those require direct site inspection and/or on-chain validation that is not available in this run. The protocol site itself should therefore be treated as partially verified for maturity, but those UX and live-flow details remain unconfirmed. Overall assessment: likely a mature, live protocol with public developer documentation and API access, but the specific state of the retail UI and live user flows is not fully verifiable here.

Evidence (3)

Security

audit

one source

PancakeSwap v3 Exchange V3 security audit; covers the Exchange V3 codebase. The public audit index lists this report, but the available result snippet does not expose critical/high/medium counts, fix status, or a bytecode-to-deployment coverage statement.

Auditor
PeckShield
Report Date
2023-03
Scope
Exchange V3
Evidence (2)

audit

one source

PancakeSwap MasterChef V3 security audit; relevant to the v3 ecosystem’s incentive contracts. The search results confirm the audit exists, but the accessible snippets do not provide critical/high/medium findings, fix status, or explicit deployed-bytecode coverage.

Auditor
PeckShield
Report Date
2023-04
Scope
MasterChef V3
Evidence (2)

audit

one source

PancakeSwap v3 Exchange V3 security audit; covers the Exchange V3 codebase for PancakeSwap’s v3 AMM deployment. The public audit index lists this report as part of the EVM audit set, but the audit page excerpt does not provide the detailed findings breakdown.

Auditor
SlowMist
Report Date
2023-03
Scope
Exchange V3
Evidence (2)

audit

one source

PancakeSwap MasterChef V3 security audit; this is relevant to reward distribution / farming contracts associated with v3, not the AMM pool swap logic itself. The public audit index confirms the report exists, but the snippet does not expose issue counts or remediation status.

Auditor
SlowMist
Report Date
2023-03
Scope
MasterChef V3
Evidence (2)

bug bounty

two sources

PancakeSwap has an active bug bounty program hosted on Immunefi. The program was live since 28 March 2021 and was last updated on 29 April 2026. For smart contracts and blockchain, the published payouts are Critical up to $1,000,000, High $40,000, Medium $5,000, and Low $1,000; for websites and apps, the payouts are Critical $7,500, High $4,000, and Medium $1,500. The rules require a proof of concept for eligibility, and payouts are denominated in USD but paid in CAKE or BUSD.

Evidence (3)

counterparty risks

two sources

PancakeSwap AMM V3 is a non-custodial DEX, but users are still exposed to several external dependencies and counterparties, especially across Ethereum and opBNB. Not verifiable on-chain as of 2026-08-29. 1. External protocol dependencies

  • BNB Chain / opBNB and Ethereum infrastructure: Users depend on the liveness and integrity of each L1/L2 (consensus, sequencer for opBNB, RPC infra). A chain halt, reorg, sequencer failure, or censorship could trap liquidity or enable MEV/exploit scenarios around swaps and liquidity positions.
  • Router and staking integrations: PancakeSwap integrates with yield and staking products (e.g., for CAKE, BNB) via smart contracts; failures in those external protocols can impair LP strategies or cause mispricing, though AMM pools remain technically non-custodial. 2. Oracles & price manipulation risk
  • Core AMM pricing is on-chain, pool-based, but PancakeSwap V3 relies on concentrated liquidity and TWAP-like mechanisms for price feeds used by other protocols.
  • Risk vectors:
  • Low-liquidity pairs on Ethereum or opBNB are vulnerable to flash-loan price manipulation, impacting protocols that consume PancakeSwap prices as oracles.
  • If any external lending/derivatives protocol treats PancakeSwap V3 as a primary oracle without robust TWAP and liquidity thresholds, that protocol can suffer bad-debt or liquidation failures. 3. Bridges & cross-chain exposure
  • PancakeSwap’s ecosystem relies heavily on bridged assets between BNB Chain/opBNB and Ethereum (e.g., bridged stablecoins, wrapped BNB).
  • A bridge exploit (custodial multisig compromise or light-client failure) could lead to:
  • Massive devaluation of bridged tokens on one side.
  • “Toxic” liquidity in V3 pools and severe LP/ trader losses when the bridged asset deviates from its canonical chain value. 4. Stablecoin & LST/restaking exposure
  • V3 pools typically include major stablecoins (USDT, USDC, BUSD/FDUSD, etc.) and LSTs (e.g., wstETH, ankrETH, staked BNB variants) on relevant chains.
  • Failure scenarios:
  • Stablecoin depeg or issuer insolvency: LPs in affected pools incur concentrated losses; prices on PancakeSwap can diverge from broader markets, impacting any protocol using these pools as price references.
  • LST/restaking slashing or oracle failure: Loss of backing for staked assets causes large repricing; concentrated positions amplify impermanent loss and can trigger cascading liquidations in integrated DeFi. 5. CEX/MM & RWA exposure
  • Major stablecoins and LSTs introduce indirect CEX, MM, and RWA issuer risk (reserve mismanagement, regulatory action, or trading outages), which can suddenly alter on-chain prices and liquidity conditions.
  • PancakeSwap itself does not custody RWA, but relies on these tokens’ integrity; failures transmit instantly to LPs and traders through AMM pricing.
Evidence (3)

crypto custody

two sources

PancakeSwap AMM V3 is best described as non-custodial: users connect their own wallets, approve tokens, and sign swaps or liquidity actions, while the protocol’s smart contracts handle execution through AMM pools rather than a centralized exchange balance. For Ethereum and opBNB, that means custody is organized at the user-wallet level for normal trading, and at the smart-contract level for liquidity positions, which in V3 are represented as non-fungible positions (NFT-like positions) rather than pooled account balances. This setup means PancakeSwap itself does not hold user funds in an omnibus custody account; instead, assets remain controlled by the user’s wallet until they are intentionally moved into a pool/position contract. The main custody risk is therefore not exchange insolvency, but wallet key loss, malicious approvals, or smart-contract risk. Not verifiable as of 2026-08-29 for chain-specific custody implementation differences between Ethereum and opBNB beyond the general V3 model.

Evidence (3)

key management

one source

PancakeSwap AMM V3 uses a per-pool, contract-based key model: each v3 pool is a separate contract, and positions are managed through the NonfungiblePositionManager as ERC-721 NFTs rather than fungible LP tokens. On Ethereum and opBNB, the relevant v3 deployment addresses are published in PancakeSwap’s contract registry, including the v3 factory, pool deployer, and NFPM, which are the main operational contracts for pool and position management. The v3 position itself is the key management unit: it stores the tick range, liquidity, and fees, and is referenced by tokenId. For the newer Infinity architecture, PancakeSwap describes a singleton PoolManager design with a shared Vault plus modular Hooks; hooks are bound into each pool’s PoolKey, and hook permissions are fixed after deployment. CertiK’s review of Infinity confirms that the vault holds token balances, PoolManagers execute AMM logic, and hooks add customizable behavior under immutable permissions. For the user-specified AMM V3 scope, the important point is that key management is not centralized in a single admin key in the documentation provided; instead, operational control is organized around deployed core contracts, pool-specific contracts, and NFT-based position records. Not verifiable as of 2026-08-29: whether any privileged admin/multisig, emergency pause, or upgrade keys control the Ethereum and opBNB v3 deployments, because the provided sources do not disclose governance or ownership details for those contracts.

Evidence (4)

Live security feed

No verified protocol news in the last 12 months.

Team & Reputation

founders

two sources

PancakeSwap is a major DEX originally launched on BNB Chain; AMM V3 on Ethereum and opBNB is an extension of that protocol, not a separate project. The same founding and team structure applies across chains. 1. Founders & team identity

  • PancakeSwap was launched in September 2020 by a small group of largely anonymous DeFi developers; no formal “founder” list is disclosed on the official site or docs.
  • Public-facing figures exist (e.g., business development, community leads), but these are not presented as doxxed founders with full biographies in official materials.
  • Binance has repeatedly clarified that PancakeSwap is not a Binance product, but an independent project that initially received ecosystem support. Reality check: The founding team is effectively pseudonymous, with no comprehensive, verified founder bios; this limits traditional KYC-style due diligence. Not verifiable as of 2026-08-29. 2. Prior projects / outcomes / hacks
  • There is no widely documented pre-PancakeSwap project track record for the anonymous founders in credible sources; claims on forums or social media cannot be reliably tied to specific real-world identities. Not verifiable as of 2026-08-29.
  • PancakeSwap itself has operated since 2020 with no major protocol-level exploit of the core AMM reported by leading analytics or security trackers; risk events have primarily involved individual tokens or external integrations. 3. Public vs anon; credibility signals
  • Credibility is based on:
  • Long operational history and high TVL/volume across BNB Chain, Ethereum, and opBNB.
  • Multiple independent smart contract audits (e.g., CertiK, PeckShield) for core contracts and upgrades.
  • Ongoing bug bounty programs hosted on platforms like Immunefi.
  • These are technical/operational credibility signals, not personal-identify credibility. 4. Office, jurisdiction, business reality
  • PancakeSwap presents itself as a decentralized, global project; no clear registered corporate entity, office address, or jurisdiction is disclosed in docs or core web properties.
  • No reliable regulator filings, company registries, or court records can be tied unequivocally to PancakeSwap’s core team. Not verifiable as of 2026-08-29. Reality check:
  • Founders: pseudonymous; real-world identities and prior projects not verifiable.
  • Business form: appears as a web-native, offshore-style DAO/project with no confirmed onshore corporate wrapper.
  • Risk implication: governance, accountability, and legal recourse rely on protocol design and community processes rather than identifiable management.
Evidence (8)

general reputation

two sources

PancakeSwap AMM V3 has generally positive market reputation as a long-running DEX with multiple external audits and no clear publicly documented scandal in the sources gathered. PancakeSwap’s own audit page lists Exchange V3 security audits by PeckShield and SlowMist in March 2023, and the same documentation indicates additional PancakeSwap audit coverage beyond V3 . An external review also states that PancakeSwap has been audited by CertiK, PeckShield, and SlowMist and that no publicly known hacks or exploits have been reported since inception, though that claim is secondary and not independently verified here . The protocol is widely associated with an anonymous founding team launched in 2020; however, specific founder/investor claims in the search results are inconsistent and should be treated cautiously. One source says the team was anonymous at launch and lists investors including a16z and Platinum Software Development Company, while other directory-style pages list different names and should not be relied on as authoritative . I did not find credible evidence in the gathered sources of fraud, rug-pull, insolvency, or sanctions allegations specifically tied to PancakeSwap AMM V3. I also did not find authoritative legal or regulatory enforcement actions in the results reviewed. Not verifiable as of 2026-08-29 for any unresolved allegations beyond generic DeFi smart-contract risk. Main unresolved concerns are standard DeFi ones: smart-contract risk, audit coverage limits, governance/key-management risk, and dependence on third-party integrations. Audit coverage reduces risk but does not eliminate it .

Evidence (4)

Economy

TVL: $48.9M

model

two sources

PancakeSwap AMM V3 is a market-neutral liquidity provision protocol: users deposit token pairs into concentrated-liquidity pools and earn swap fees from traders; the main asset flow is tokens in as LP collateral and tokens plus fees out when positions are withdrawn. Yield is primarily organic (trading activity), not a lender-style subsidy, and there is no built-in leverage, looping, or restaking mechanism in the AMM V3 design. Liquidity positions are not locked by protocol design; LPs can typically withdraw their position and accrued fees subject to normal AMM mechanics and any pool-specific fee tier constraints. PancakeSwap’s own docs say V3 pools use multiple fee tiers and that LPs earn trading fees, while a protocol share of fees goes to the treasury/burn, which is consistent with a fee-driven model rather than emissions-only incentives. The protocol’s fee mechanics are the main economic engine: traders pay a swap fee, LPs receive the majority of that fee flow, and PancakeSwap allocates a protocol cut to treasury and CAKE burn. That means protocol revenue is fee-based, while LP APY depends on realized trading volume, fee tier, price range utilization, and impermanent loss; APY is therefore inherently volatile and not sustainably fixed. Because Dune on-chain verification is unavailable in this run, chain-level TVL, product-level TVL, and Dune-vs-DeFiLlama reconciliation are Not verifiable as of 2026-08-29. DeFiLlama’s latest surfaced entries indicate PancakeSwap AMM V3 has material TVL on Ethereum and opBNB, but the exact as-of breakdown is not independently on-chain verified here. In risk terms, the main exposures are market risk (impermanent loss and concentrated-range risk), smart-contract risk, and flow dependence on external trading volume. The protocol is not a directional yield strategy, and LPs are effectively underwriting order-flow and price-range occupancy rather than taking long/short leverage. Historical APY levels and volatility are Not verifiable as of 2026-08-29 without on-chain pool fee and liquidity data.

Evidence (4)

reserves

unverified

Not verifiable as of 2026-08-29. I could confirm only the canonical PancakeSwap v3 pool-router address page, which lists a v3-related contract deployment on Ethereum and opBNB but does not state treasury/reserve holdings, custody structure, reserve policy, or attestations. The web results available here are analytics/marketing pages focused on TVL rather than protocol treasury balances, and they do not provide on-chain reserve balances or controller addresses for a treasury. Because Dune/on-chain verification is unavailable in this run, the size, composition, custody, and control of any reserves or treasury for PancakeSwap AMM V3 are not verifiable from the provided sources.

Evidence (4)

tokenomics

two sources

PancakeSwap AMM V3 uses the CAKE token as its native / governance / utility token (shared across all PancakeSwap products). There is no separate “v3-only” token. 1) Token identity & addresses

  • Name / ticker: PancakeSwap Token / CAKE.
  • Primary chain: BNB Chain (BEP‑20). Contract: 0x0e09fabb73bd3ade0a17ecc321fd13a19e81ce82.
  • Ethereum and opBNB use the same economic token via bridged CAKE; contracts are bridge-wrapped (not new native tokens). 2) Supply, market cap, FDV
  • CAKE’s original hard cap (~750M) was replaced by a new “ultra sound” model targeting ~450M maximum supply, with emissions reduction over time.
  • Current total and circulating supply, market cap, and FDV for CAKE on multi-chain aggregators (e.g., CoinGecko/CMC) are Not verifiable as of 2026‑08‑29 under this workflow constraint. 3) Token utility & governance
  • Utility:
  • Liquidity mining / farm rewards for AMM LPs.
  • Staking in Syrup Pools for yield.
  • Fee discounts / rewards in some products (e.g., trading incentives).
  • Governance: CAKE holders vote on PancakeSwap proposals (e.g., farm listings, emissions changes), using on-chain or Snapshot-based voting. 4) Revenue share, burns, staking rewards
  • Protocol uses trading fees from AMM (including v3) and other products to:
  • Fund CAKE buybacks & burns under an “ultra sound” model (ongoing emissions cuts + burns).
  • Support staking rewards and ecosystem incentives.
  • Exact current fee split and numerical burn rates are Not verifiable as of 2026‑08‑29 within this setup. 5) Emissions & unlocks
  • Emissions schedule has been repeatedly revised downward, with explicit governance decisions to reduce CAKE output and target ~450M max supply.
  • Specific unlock schedules, cliff/vesting details, and verification that announced unlocks occurred on-chain are Not verifiable as of 2026‑08‑29. 6) Allocations & holder concentration
  • Public marketing/early docs mention allocations to team, treasury, and community incentives, but precise shares and current balances are Not verifiable as of 2026‑08‑29.
  • Top-holder concentration, insider wallets, and current treasury holdings are Not verifiable as of 2026‑08‑29. 7) Contract controls & risk-relevant functions
  • CAKE is a mintable BEP‑20 token; historical docs show minting controlled by the PancakeSwap team / governance.
  • Detailed status of blacklist, fee-switch, and admin keys, and which multisig/DAO controls them on each chain, is Not verifiable as of 2026‑08‑29. 8) DEX liquidity & listings
  • CAKE’s primary liquidity is on PancakeSwap on BNB Chain, with additional liquidity on Ethereum and other chains via bridges.
  • Depth by pair/chain (e.g., CAKE/BNB, CAKE/BUSD, CAKE/WETH) and order-book CEX listings are Not verifiable as of 2026‑08‑29.
Evidence (3)

Stress scenarios

stress scenario - bitcoin price falls below $10000

two sources

A Bitcoin drop below $10,000 would most directly stress PancakeSwap AMM V3 through LP range breakouts, fee collapse in affected pools, and higher slippage as concentrated liquidity is pulled out of range. PancakeSwap’s own docs say V3 positions can convert fully into one asset when price moves outside the chosen range, and out-of-range positions earn no trading fee rewards. For this protocol, the practical risk is not protocol insolvency from BTC itself; it is the market-structure effect on pools that include BTC or BTC-linked assets, and second-order stress on correlated crypto pairs if the broader market sells off. In a sharp BTC drawdown, LPs with narrow ranges would likely suffer the largest impermanent loss and may withdraw liquidity, which can leave the pool with thinner active depth and worse execution. A separate risk channel is pricing and liquidation stress in downstream integrations that rely on PancakeSwap V3 liquidity or price discovery. Hindenrank’s analysis notes that concentrated-liquidity mechanics can amplify impermanent loss and that prior manipulation incidents in V3 pools show the attack surface is active, not theoretical. What can be stated with confidence is limited by the current evidence: there is no on-chain verification available in this run for PancakeSwap AMM V3’s live Ethereum and opBNB exposure, pool composition, or chain-by-chain TVL, so those figures are Not verifiable as of 2026-08-29. The protocol docs also indicate V3 routing can still fall back to legacy v2 and stable-swap liquidity, which may soften—but not eliminate—execution stress in a BTC crash.

Evidence (3)

stress scenario - largest collateral depegs 20%,

two sources

PancakeSwap AMM V3 is an AMM, so a 20% depeg of the largest collateral asset would primarily hit LPs through impermanent loss and range-exit effects rather than create protocol insolvency. In concentrated-liquidity AMMs, LPs can be fully converted into the depreciating asset when price moves through their active ranges, which sharply reduces available depth and can make the pair much more slippage-prone. For a stress scenario, the main impact path is:

  • LP value loss: positions concentrated around the pre-depeg price absorb the full move and may end up holding mostly the depegged asset, especially if ranges are narrow.
  • Liquidity withdrawal / vacuum: as LPs react to the depeg, active liquidity can fall quickly, worsening execution quality and amplifying price impact for any further selling.
  • Downstream spillovers: if other protocols use PancakeSwap V3 as a pricing venue, a 20% depeg can create stale or distorted prices and complicate liquidations, though that is a second-order effect outside the AMM itself. What is not verifiable as of 2026-08-29 from the available sources:
  • The actual Ethereum vs. opBNB exposure of PancakeSwap AMM V3
  • The largest collateral asset by TVL on each chain
  • A quantified loss estimate for a 20% depeg without live pool composition and concentration data So the best defensible answer is: expect severe LP losses and temporary liquidity impairment, but not a direct protocol-balance-sheet loss; the severity depends on how concentrated the active ranges are and how much of the affected asset is actually in-range at the time of the depeg.
Evidence (5)

stress scenario - committed fraud by the DAO or owners

two sources

For the stress scenario of committed fraud by the DAO or owners, I found no verifiable evidence that PancakeSwap AMM V3’s DAO or core owners committed fraud on Ethereum or opBNB. The strongest directly relevant material is that PancakeSwap documents governance/ownership-style controls and whitelisting/routing features, but the provided sources do not prove fraudulent conduct by the DAO or owners. What *is* supported by the results is a broader risk profile: third parties have reported security incidents and manipulation vectors affecting PancakeSwap-related activity, including a social-media account compromise used to promote a fraudulent token, and token/pool-level exploits that exploited token logic or reserve-accounting issues rather than proving DAO theft. A forum post also contains an allegation that PancakeSwap “scammed” users, but this is an unverified community claim, not evidence of committed fraud. Assessment:

  • Fraud by DAO/owners: Not verifiable as of 2026-08-29.
  • Adjacent risks: governance/operational compromise, market manipulation, and token-level exploits can still create user losses without indicating DAO fraud. If you need a higher-confidence determination, the next step would normally be on-chain governance and admin-role verification, but that is Not verifiable as of 2026-08-29 in this run.
Evidence (6)

stress scenario - primary yield source negative 30d,

two sources

For PancakeSwap AMM V3 on Ethereum and opBNB, the primary yield source is LP fees from concentrated liquidity positions; only LPs earn APR from AMM trading activity, and v3 liquidity positions are explicitly exposed as yield-bearing positions. In a stress scenario where the 30-day primary yield is negative, the most likely driver is impermanent loss (IL) plus fees earned failing to offset adverse price movement, especially for narrow ranges where concentrated liquidity can increase IL magnitude. This means the protocol-level issue is not a loss of fee accrual mechanics; it is that net LP return can turn negative after accounting for price divergence, out-of-range behavior, and transaction/rebalancing costs. In volatile markets, LPs may be forced to rebalance or withdraw as prices move toward or beyond their range, which can reduce realized yield further. Chain-specific exposure:

  • Ethereum: Not verifiable as of 2026-08-29.
  • opBNB: Not verifiable as of 2026-08-29. I could not verify the 30-day yield split by chain from the available sources, so the negative 30-day primary yield condition is Not verifiable as of 2026-08-29 for each chain independently. The only supported conclusion is that, under stress, PancakeSwap V3 LP yield can become negative when IL and active-management friction overwhelm fee income.
Evidence (4)

Governance & Legal

legal & regulatory

two sources

PancakeSwap AMM V3 is a non‑custodial DeFi AMM originating from Binance Smart Chain (BNB Chain); for this run you ask specifically about Ethereum and opBNB deployments and their legal/regulatory profile. On‑chain verification is not possible: Not verifiable as of 2026‑08‑29. 1. Legal entity / jurisdiction

  • PancakeSwap is presented as a decentralized protocol; the website and docs do not clearly identify a traditional corporate entity or registered jurisdiction, and governance is partly via the CAKE token and a DAO‑style process.
  • Absence of a clearly disclosed legal entity increases counterparty and enforcement uncertainty: regulators may instead target core developers, front‑end operators, or major token holders. 2. Terms of Service & user restrictions
  • The main PancakeSwap website publishes Terms of Service including: no use by persons in certain sanctioned jurisdictions (e.g. OFAC‑sanctioned countries), age restrictions (usually 18+), and disclaimers that users are responsible for tax and compliance.
  • These ToS are off‑chain contract terms attached to the web front‑end, not the Ethereum/opBNB smart contracts themselves; users interacting directly with contracts may bypass them, creating a gap between legal structure and technical reality. 3. KYC/AML practices
  • As a permissionless AMM, PancakeSwap AMM V3 on Ethereum/opBNB does not implement KYC at smart‑contract level.
  • The front‑end does not generally require identity verification for swapping or providing liquidity, relying instead on user self‑responsibility and ToS‑based prohibitions.
  • This exposes users (especially institutions) to AML risk: counterparties and flows are not screened at protocol level; institutions must overlay their own transaction‑monitoring and wallet‑screening tools. 4. Regulatory classification / risks
  • AMMs like PancakeSwap are widely discussed by regulators as potential unregistered securities/derivatives venues or illicit‑finance facilitators, but there is no public, protocol‑specific classification decision for PancakeSwap AMM V3 on Ethereum/opBNB.
  • CAKE and LP tokens may be viewed as:
  • investment instruments (yield‑bearing positions),
  • or purely functional protocol tokens, depending on jurisdiction. This is not definitively resolved in case law. 5. Warnings, enforcement, sanctions, court cases
  • No direct enforcement actions, court cases, or sanctions specific to PancakeSwap AMM V3 on Ethereum or opBNB were identifiable: Not verifiable as of 2026‑08‑29.
  • General regulatory reports on DeFi and AMMs (e.g., from IOSCO, FATF) highlight risks around market integrity, consumer protection, and AML for similar protocols, which are applicable by analogy. 6. Data protection / privacy
  • PancakeSwap front‑end collects some user data via web technologies (cookies, analytics) per its Privacy Policy; blockchain interactions themselves are public and pseudonymous.
  • There is no strong privacy layer (e.g., mixers) embedded in AMM V3, so primary compliance concern is transparency plus lack of identity binding, not data‑protection failures. For institutional use, treat PancakeSwap AMM V3 as an unregulated, non‑KYC, global venue with front‑end ToS but limited enforceability against direct contract interactions, and layer your own sanctions/AML screening and legal opinions per jurisdiction.
Evidence (3)

Stability

stability

two sources

Not verifiable as of 2026-08-29. The provided sources do not identify which specific stablecoin PancakeSwap AMM V3 used on Ethereum or opBNB, nor do they provide historical peg data or a depeg count/last occurrence/% depeg for that stablecoin. The only related source is PancakeSwap’s StableSwap documentation, which discusses stable-pair trading and references a date, but it does not document any actual depeg event.

Evidence (2)

Risks & Strengths

risks

two sources

For PancakeSwap AMM V3 on Ethereum and opBNB, the top risks are liquidity-provider impermanent loss, range-mismanagement/zero-fee exposure, MEV sandwich/front-running, smart-contract or integration bugs, and cross-chain liquidity fragmentation. PancakeSwap V3 uses concentrated liquidity and requires LPs to choose fee tiers and price ranges; narrower ranges can raise fee capture but also increase impermanent loss and the chance that a position sits out of range and earns no fees.

  • Impermanent loss amplification: concentrated liquidity makes LP losses more sensitive to price moves than a broad-range AMM, especially in volatile pairs.
  • Active-management risk: if price leaves the chosen band, the position can become effectively one-sided and stop earning fees, so poor range selection can materially hurt returns.
  • MEV / execution risk: narrow ranges and volatile trading conditions can make sandwich attacks and front-running more profitable for bots, reducing LP and trader outcomes.
  • Smart-contract / hook risk: no audit removes all risk; undiscovered bugs, exploits, or risky third-party hook logic can still cause losses.
  • Cross-chain fragmentation: because liquidity is split across chains, depth on any single chain can be thinner, which can worsen slippage and complicate rebalancing/arbitrage.
Evidence (6)

strengths

one source

PancakeSwap AMM V3’s main strengths are its concentrated liquidity, which lets LPs allocate capital within specific price ranges for better capital efficiency and potentially higher fee earnings; multiple fee tiers, which give pools different risk/reward and cost profiles; lower slippage / deeper effective liquidity from concentrating liquidity near active prices; multi-chain deployment across Ethereum and opBNB, which broadens access and venue choice; and battle-tested V3-style mechanics, since it is a well-established concentrated-liquidity design forked from Uniswap V3-style architecture. These points are supported by PancakeSwap’s liquidity docs and independent reviews of the protocol’s V3 design.

Evidence (3)

Methodology & Limitations

  • On-chain metrics: not verifiable — Dune phase 2 is not enabled.
  • 4 of 24 fact categories not yet collected.
  • Fact verifiability: 16 two independent sources, 6 one source, 1 unverified.
  • Oldest fact verification date: 2026-08-29.