Provide a concise narrative that clearly states each of (a)–(e) below.
PancakeSwap presents itself as a decentralized exchange and DeFi platform intended to let users trade directly from a wallet, earn through liquidity and farming products, and access additional onchain products such as prediction, lottery, bridging, and early-token-access events without a registration flow. (Source: PancakeSwap Product Overview, PancakeSwap Business Partnerships)
Ongoing protocol operations are tied to directing CAKE emissions toward selected products and pools, using buy-back-and-burn mechanics to target long-run deflation, maintaining publicly visible code and contracts, and routing material governance changes through the PancakeSwap voting process. (Source: PancakeSwap CAKE Tokenomics, PancakeSwap Product Overview, PancakeSwap Governance)
PancakeSwap publicly describes its product surface around trade, earn, and win flows, including spot swaps, liquidity pools, yield farming, CAKE staking, CAKE.PAD events, perpetual trading, bridging, prediction, and lottery features across multiple supported chains. (Source: PancakeSwap Product Overview, PancakeSwap Business Partnerships)
Public sources describe CAKE as the token used for direct governance voting, yield-farming rewards, Syrup Pool staking, and participation in CAKE.PAD events, while fee burns and buy-back-and-burn mechanics are used as part of the token’s supply-management design. (Source: PancakeSwap Governance, PancakeSwap Product Overview, PancakeSwap CAKE.PAD, PancakeSwap CAKE Tokenomics)
The public control surface combines direct CAKE-holder voting with a retained core-team role. All CAKE holders have direct voting rights, voting power is based on wallet balances at snapshot, community proposals are non-binding, and core proposals can only be proposed by the PancakeSwap Core Team. Public security materials also state that the chefs use multisig for contracts and that contracts are subject to time-locks. (Source: PancakeSwap Governance, PancakeSwap Product Overview, PancakeSwap General FAQ)
For each existing entity: Labs/DevCo (e.g., Founder, CEO, CTO, COO), Foundation (e.g., President, Executive Director, CFO, COO), and DAO / onchain governance leadership (if applicable) list the: (a) full names, (b) official titles, (c) and prior experience of key team members. For any non-existent entity, explicitly mention it does not exist. External links may be included but they will not factor into the score.
Full Name | Entity | Official Title | Prior Experience |
|---|---|---|---|
Chef Kids (public pseudonym) (The Kitchen Team) | Labs/DevCo | Head Chef (The Kitchen Team) | Not publicly disclosed. |
Chef Miso (public pseudonym) (The Kitchen Team) | Labs/DevCo | Product (The Kitchen Team) | Not publicly disclosed. |
Chef Jackson (public pseudonym) (The Kitchen Team) | Labs/DevCo | Dev Lead (The Kitchen Team) | Not publicly disclosed. |
Chef Taco (public pseudonym) (The Kitchen Team) | Labs/DevCo | Backend Dev Lead (The Kitchen Team) | Not publicly disclosed. |
Chef Snoopy (public pseudonym) (The Kitchen Team) | Labs/DevCo | Smart Contract Dev Lead (The Kitchen Team) | Not publicly disclosed. |
Chef Rei (public pseudonym) (The Kitchen Team) | Labs/DevCo | Security (The Kitchen Team) | Not publicly disclosed. |
Chef Cocoa (public pseudonym) (The Kitchen Team) | Labs/DevCo | Marketing Lead (The Kitchen Team) | Not publicly disclosed. |
The public team page also lists broader engineering, QA, design, community, BD, and operations roles under additional chef pseudonyms. The Kitchen Team | Labs/DevCo | Not publicly disclosed. | Not publicly disclosed. |
PancakeSwap has not publicly disclosed a separate foundation entity or named foundation leadership. The Kitchen Team | Foundation | Not applicable. | Not applicable. |
PancakeSwap has not published a roster of named DAO or onchain governance leadership. Governance is exercised through CAKE-holder voting, with a distinct PancakeSwap Core Team role in proposing core proposals. PancakeSwap Governance | DAO/Onchain Governance | Not publicly disclosed. | Not publicly disclosed. |
Provide a structured description of the DAO's governance, powers, and economic rights. If a DAO does not exist, state so. Address the lettered items below. Even if there is no DAO, there must be an answer to (d).
Public sources do not identify DAO ownership of PancakeSwap IP through a named legal wrapper or onchain resolution. The bounded public IP-control surface instead consists of the project-controlled frontend and smart-contract repositories plus copyrighted PancakeSwap and CAKE brand assets that are not distributed under the same licenses as PancakeSwap's open-source technology. (Source: PancakeSwap Codebase Overview, PancakeSwap Trading Interface V1 Repository, GitHub - pancakeswap/pancake-smart-contracts: PancakeSwap Smart Contracts · GitHub, Brand & Logos)
All CAKE holders have direct voting rights, that voting power equals wallet-held CAKE at snapshot, that there is no minimum quorum, and that core proposals can only be proposed by the PancakeSwap Core Team while community proposals are non-binding suggestions. Public security materials also state that the chefs use multisig for contracts and that contracts are subject to time-locks. (Source: PancakeSwap Governance, PancakeSwap Product Overview, PancakeSwap General FAQ)
Public sources do not describe a current locking mechanism that grants additional governance rights beyond wallet-held CAKE after Tokenomics 3.0. The governance page states that delegation is not allowed and that CAKE staked in Syrup Pools does not count toward voting power because it is not in the wallet balance at snapshot. Public revenue-sharing materials describe a locked-CAKE economic mechanism, not additional governance rights. (Source: PancakeSwap Governance, Revenue Sharing FAQ)
Public sources describe a bounded value-accrual mechanism for locked CAKE through the revenue-sharing system. RCAKE shares are recalculated at each weekly distribution from locked CAKE amount and remaining lock duration, and that revenues from blockchains other than BNB Chain are processed monthly and injected with a one-month delay using weekly averaging. PancakeSwap has not disclosed any mechanism giving CAKE holders direct treasury-direction rights beyond the governance processes already described above. (Source: Revenue Sharing FAQ, PancakeSwap Governance)
PancakeSwap has published no dissolution or wind-up authority over the PancakeSwap DAO. The published governance process is a snapshot vote in which voting power equals wallet-held CAKE, there is no minimum quorum, core proposals can be raised only by the PancakeSwap Core Team, and community proposals are non-binding; that process names no body, vote threshold or procedure capable of dissolving the DAO. PancakeSwap has also identified no legal wrapper for the DAO, such as a foundation or association, in whose constitutional documents a dissolution authority would ordinarily sit, so no such authority appears on the public record. (Source: PancakeSwap Governance, PancakeSwap General FAQ)
For the Primary Foundation do the following independently. If an entity does not exist, state that explicitly. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn't exist. Definitions: The primary Foundation and DevCo can be explained as those entities which are directly involved in the issuance of the native token at launch.
PancakeSwap has no primary foundation entity. No foundation is named anywhere in its product and protocol documentation, its governance materials, its team pages or its brand materials, and no foundation entity form or jurisdiction of incorporation appears in any of them. The only operating surfaces PancakeSwap identifies are the PancakeSwap Core Team, which alone may originate core governance proposals, and the Kitchen Team, whose members are listed under pseudonyms; contract control is described as sitting with chef-operated multisigs and timelocks rather than with any foundation. (Source: The Kitchen Team, PancakeSwap Product Overview)
No foundation-held intellectual property is publicly disclosed for PancakeSwap, because PancakeSwap has no primary foundation entity. PancakeSwap's brand page states that PancakeSwap and CAKE brand assets are copyrighted and not distributed under the same licenses as its open-source technology, but it does not attribute that copyright to a foundation. (Source: Brand & Logos, PancakeSwap Codebase Overview)
No foundation powers over a DAO, treasury, protocol-controlled resources, or token administration are publicly disclosed for PancakeSwap, because PancakeSwap has no primary foundation entity. The governance documentation describes core-proposal origination and voting, but assigns no authority to a foundation. (Source: PancakeSwap Governance, PancakeSwap Product Overview)
No foundation powers over a DevCo are publicly disclosed for PancakeSwap, because PancakeSwap has no primary foundation entity, and PancakeSwap has likewise not named an incorporated developer company over which such powers could be exercised. (Source: The Kitchen Team, PancakeSwap Governance)
No foundation contract or administrative powers are publicly disclosed for PancakeSwap, because PancakeSwap has no primary foundation entity. Public materials describe multisig-controlled and time-lock-protected contracts, but do not attribute any of those keys or roles to a foundation. (Source: PancakeSwap Product Overview, PancakeSwap General FAQ)
No foundation economic arrangements or distribution policies are publicly disclosed for PancakeSwap, because PancakeSwap has no primary foundation entity. Public sources describe no foundation CAKE allocation, vesting, fee entitlement, or distribution policy. (Source: PancakeSwap Product Overview, PancakeSwap Governance)
For the Primary DevCo do the following independently. If an entity does not exist, state that explicitly. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn't exist. Definitions: The primary Foundation and DevCo can be explained as those entities which are directly involved in the issuance of the native token at launch.
PancakeSwap's operating team surface consists of the PancakeSwap Core Team and the Kitchen Team. PancakeSwap has not publicly disclosed a named incorporated developer company, entity type, or jurisdiction of incorporation for either, so there is no registered DevCo entity to identify. (Source: The Kitchen Team, PancakeSwap Governance)
PancakeSwap controls its frontend and smart-contract repositories, and PancakeSwap and CAKE brand assets are copyrighted and not distributed under the same licenses as PancakeSwap's open-source technology. That brand-asset carve-out is the clearest publicly disclosed IP-control surface. PancakeSwap has not publicly disclosed which legal entity holds those copyrights or trademarks, or the terms of any licence between that holder and the team. (Source: PancakeSwap Codebase Overview, PancakeSwap Trading Interface V1 Repository, GitHub - pancakeswap/pancake-smart-contracts: PancakeSwap Smart Contracts, Brand & Logos)
PancakeSwap retains an operational role through core-proposal origination, which means the team originates governance proposals rather than only executing tokenholder-initiated ones. PancakeSwap has not publicly disclosed entity-level treasury access, token-administration authority, or the division of authority between the team and CAKE voters over protocol-controlled resources. (Source: PancakeSwap Governance, PancakeSwap Product Overview)
PancakeSwap has no primary foundation entity, so there are no powers over a foundation to describe. No foundation is named in its product and protocol documentation, its governance materials, its team pages or its brand materials, and the only operating surfaces PancakeSwap identifies are the PancakeSwap Core Team and the Kitchen Team. (Source: The Kitchen Team, PancakeSwap Governance)
PancakeSwap's public materials describe multisig-controlled contracts and time-lock-protected contracts as the administrative surface over the protocol. PancakeSwap has not publicly disclosed which entity or individuals hold those multisig keys, the signing thresholds, the timelock durations, or which contracts fall under each protection. (Source: PancakeSwap Product Overview, PancakeSwap General FAQ, GitHub - pancakeswap/pancake-smart-contracts: PancakeSwap Smart Contracts)
A protocol-level treasury fee entitlement is disclosed, but its holder is not. The published V3 trading-fee breakdown allocates each swap fee across three components by fee tier: liquidity providers receive 67% at the 0.01% tier, 66% at 0.05% and 68% at the 0.25% and 1% tiers; the CAKE burn receives 15%, 15%, 23% and 23%; and the Treasury receives the remaining 18%, 19%, 9% and 9%. On the emissions side, CAKE emissions are directed to multichain farms, the lottery and Ecosystem Growth, and PancakeSwap's stated target is an annual deflation rate of at least roughly 4% with a hard cap of 400,000,000 CAKE set by a proposal passed on January 16, 2026. PancakeSwap has not publicly disclosed which legal entity holds that Treasury share, whether any part of it funds the Core Team or Kitchen Team, or any team CAKE allocation, vesting schedule, salary, grant funding source or policy governing sale or transfer of CAKE held by team members. (Source: PancakeSwap Pools — Trading Fees, CAKE Tokenomics) (Source: PancakeSwap Governance, PancakeSwap Product Overview)
Disclose launch and initial supply details in a single initial allocation schedule covering the token's launch.
CAKE had no launch supply. There was no premine and no genesis allocation: the total number of CAKE issued at launch was zero, so the number locked at launch and the number unlocked at launch were both zero as well. The entire supply accrued after launch through MasterChef block emissions, which archived tokenomics materials record as starting at 40 CAKE per block on Binance Smart Chain, and the first emissions reduction lowered that rate to 14.5 CAKE per block. PancakeSwap has published no issuance event, treasury mint or investor allocation preceding or accompanying the MasterChef deployment. (Source: CAKE Tokenomics v1, Controlling CAKE supply v1)
There were no launch-date recipient buckets, because nothing was allocated at launch. The recipient categories that CAKE does have are emission destinations that begin accruing block by block after the MasterChef contract is live, and archived public tokenomics materials set them out as follows. No team, investor, advisor, treasury or foundation bucket appears among them, and PancakeSwap has published no allocation to any such party at or before launch.
No fixed price was set, and no price-discovery mechanism was run. CAKE was not sold at launch in any form: there was no public sale, private sale, auction, liquidity bootstrapping pool or other offering, so PancakeSwap set no offering price and received no proceeds. The token entered circulation only through MasterChef emissions paid to liquidity providers and stakers, and its price was set from the outset by open-market trading on PancakeSwap's own pools. (Source: CAKE Tokenomics v1, Controlling CAKE supply v1)
The ticker and market symbol is CAKE. (Source: PancakeSwap CAKE Tokenomics, PancakeSwap CAKE.PAD)
The supply regime has changed materially over time and is now capped and deflationary. PancakeSwap launched as an MVP with MasterChef emitting 40 CAKE per block, and early public materials described CAKE as uncapped and inflationary; the first emissions reduction lowered circulation from 40 CAKE per block to 14.5 CAKE per block. A May 2022 Tokenomics 2.0 litepaper proposed a 750,000,000 CAKE max-supply cap together with additional locked-CAKE utility such as boosted IFO benefits and boosted farm yields. CAKE now has a hard cap of 400,000,000 and targets at least approximately 4% annual deflation and approximately 20% total supply reduction by 2030 through buy-back-and-burn and fee-burn mechanisms. CAKE.PAD burns 100% of participation fees in CAKE. (Source: CAKE Tokenomics v1, Controlling CAKE supply v1, PancakeSwap V2 Litepaper, PancakeSwap CAKE Tokenomics, PancakeSwap CAKE.PAD)
No vesting or release schedule applied, because there was nothing to release. CAKE entered circulation through per-block emissions paid directly to farmers and stakers as they earned them, rather than through allocations to identified parties held back for later distribution, so no cliff, linear vest, lockup or unlock cadence attached to any category or recipient at launch. The nearest equivalent to a release schedule is the emissions rate itself, which was 40 CAKE per block at launch and has been reduced by governance since, and the harvest lockup applied at the pool level, which delays when a farmer may claim already-earned rewards rather than vesting an allocation. (Source: CAKE Tokenomics v1, Controlling CAKE supply v1)
Address each of the following sub-items based on the project's airdrop status. If a sub-item does not apply to the project's situation, state that explicitly.
Planned but not yet executed airdrop
Not applicable. PancakeSwap has no planned airdrop, so there is no future recipient wallet list to commit to publishing and no prospective target segment or allocation method to describe. No airdrop program appears anywhere in PancakeSwap's current or archived tokenomics documentation, its product documentation or its governance materials, and no claim contract, eligibility checker or claim window has ever been announced for CAKE. (Source: PancakeSwap CAKE Tokenomics, CAKE Tokenomics v1)
Executed airdrop
Not applicable. PancakeSwap has never executed an airdrop, so there is no per-address source to point to and no executed recipient set to characterise. CAKE had no premine and no genesis allocation: the total supply issued at launch was zero, and the entire supply entered circulation through MasterChef per-block emissions paid to liquidity providers and stakers as they earned them, with 4.25 CAKE per block, or approximately 122,400 CAKE per day, directed to farms and the lottery and 10 CAKE per block, or approximately 288,000 CAKE per day, directed to the Syrup Pools, each allocated pro rata to the share of the relevant pool a participant supplied. That is a continuous earned-rewards mechanism rather than a distribution against a snapshot. No CSV, TSV or JSON allocation file, Dune table, Merkle dump, GitHub repository file embedding per-address allocations, or RPC endpoint exposing claim or amount data has been published for an airdrop, because none took place; every CAKE ever issued is instead traceable through the MasterChef contract's own emission and harvest events onchain. (Source: CAKE Tokenomics v1, Controlling CAKE supply v1)
No airdrop planned or conducted
This is the applicable branch. PancakeSwap has never conducted a CAKE airdrop to date and does not plan to execute one. (Source: PancakeSwap CAKE Tokenomics, CAKE Tokenomics v1)
Projects must disclose all material terms of market-making arrangements that affect token liquidity. If the project has no agreements or deals with market makers, state that explicitly; doing so earns full credit. For each market maker, include in a table:
If the project has no agreements or deals with market makers, state that explicitly; doing so earns full credit. If no native tokens were loaned or allocated to market makers, state that explicitly; cash/fiat retainers or fees are not required for this item.
Public sources do not disclose the names of PancakeSwap's market makers, any native-token allocation or loan amount, term duration, or agreement structure. Public sources show that PancakeSwap integrates with designated whitelisted market makers on Ethereum and BNB Smart Chain, routes orders to them only when they quote better prices than the AMM, and screens and works with market makers on an individual basis. A newer routing page also states that the Smart Router can use AMM and market-maker liquidity on BNB Chain and Ethereum and that trades executed by market makers do not pass through AMM liquidity pools. Public sources also state that PancakeSwap receives commissions from market makers and uses those commissions to fund CAKE buyback and burn, but they still do not provide the market-maker identities or the contract-level deal terms requested here. (Source: Market Maker Integration, Fees and Routes)
Projects must disclose all material terms of centralized or decentralized exchange listings that affect token liquidity. For each listing, include in a table:
If the project has no agreements or deals with CEX or DEX, state that explicitly; doing so earns full credit; cash/fiat fee amounts are not required for this item.
Public sources describe PancakeSwap's listing surface as largely permissionless rather than contract-disclosed listing agreements. PancakeSwap's partnership FAQ states that anybody can list any ERC-20 or BEP-20 token by adding liquidity to a liquidity pool, that projects hosting Farms are usually added to the Extended token list, and that PancakeSwap does not take applications for the default list. The same FAQ also states that Info-page indexing depends on pairing with common tokens and meeting chain-specific liquidity thresholds, such as 10 BNB on BNB Chain, 5 ETH on Ethereum, 1 ETH on Base, 1 BNB on opBNB, and no current threshold on Arbitrum. Separately, PancakeSwap's IFO and CAKE.PAD materials show a more curated launchpad surface in which projects apply, pass due diligence, receive tokenomics and GTM input from PancakeSwap, and are launched through time-limited sale events where users can commit any amount of CAKE, overflow allocations determine final fills, and unused CAKE is refunded. The CAKE.PAD overflow-tax guide further states that oversubscription taxes are charged only on excess committed funds, the partner project receives 100% of its targeted raise amount, and 100% of collected CAKE taxes are burned. PancakeSwap has not publicly disclosed listing-specific native-token allocations as a percentage of CAKE supply. (Source: Commonly Asked Business Partnerships Questions, Initial Farm Offerings - IFOs, How to Participate - CAKE.PAD, How CAKE.PAD Taxes Work in Overflow Sales – With Example)
Disclose all prior token sales by the Project — including fundraising rounds, any material OTC sales to investors, and any discounted market-maker sales. For each sale, provide:
If no prior sales occurred, state that explicitly (e.g., "No prior fundraising, OTC, or discounted MM sales have occurred.").
PancakeSwap's published record establishes that CAKE has no genesis allocation that could have been sold. PancakeSwap's own tokenomics archive states that the protocol "launched as an MVP (minimum viable product) with the MasterChef contract emitting 40 CAKE per block", and every distribution figure PancakeSwap publishes is an emission figure paid per block to farms, Syrup Pools and the lottery rather than a pre-allocated balance. There is accordingly no founder, investor, treasury or reserve tranche in the published supply from which a fundraising round, over-the-counter sale or discounted market-maker sale could have been made. Against that record, PancakeSwap has published no prior token sale, no fundraising round, no over-the-counter sale to investors and no discounted market-maker sale, and no PancakeSwap document names an investment vehicle, a sale date, a number of tokens sold or a vesting schedule for any such transaction. What the published record does not establish is a signed negative: PancakeSwap has never issued an affirmative statement in the form "no prior fundraising, OTC, or discounted MM sales have occurred", so this filing reports the absence of any sale in the record rather than a project attestation that none exists. The team is pseudonymous and operates no investor-relations disclosure channel, so no counterparty-level record is available to check against. (Source: CAKE Tokenomics v1, The Kitchen Team)
If any, list prior exploits or incidents that directly affected the token, token supply, tokenholder balances, token contract, minting controls, burn mechanics, or custody of token supply. This question is not asking about general protocol, application, or smart contract exploits unless the incident directly affected the native token itself. If no prior incidents, state this explicitly (e.g., "No exploits affecting tokenholders or protocol funds as of YYYY-MM-DD").
No exploit of the CAKE token contract or of PancakeSwap protocol treasury funds has been publicly reported as of 2026-09-28. Public secondary security analyses identify three 2026 exploits involving third-party token mechanisms in PancakeSwap V2 pools on BNB Chain, recorded below. PancakeSwap has not published protocol-issued post-mortems, compensation statements, or final remediation status for any of them.
Incident 1 of 3. PGNLZ burn-mechanism drain, 2026-01-27
2026-01-27; the PancakeSwap V2 USDT-PGNLZ liquidity pool on BNB Smart Chain. The affected component was the third-party PGNLZ token's burn mechanism interacting with a PancakeSwap V2 pair, not PancakeSwap's own contracts. (Source: Weekly Web3 Security Incident Roundup, Jan 25 – Feb 1, 2026)
Incident 2 of 3. XPL burn-mechanism drain, 2026-01-28
2026-01-28; the PancakeSwap V2 XPL-USDT liquidity pool on BNB Smart Chain. The affected component was the third-party XPL token's burn mechanism interacting with a PancakeSwap V2 pair. (Source: Weekly Web3 Security Incident Roundup, Jan 25 – Feb 1, 2026)
Incident 3 of 3. BCE burn-mechanism drain, 2026-03-23
2026-03-23; the PancakeSwap BCE-USDT liquidity pool on BNB Chain. The affected component was the third-party BCE token's burn mechanism interacting with the PancakeSwap pair address. (Source: Weekly Web3 Security Incident Roundup, Mar 23 – Mar 29, 2026)
Incident 1 of 3. PGNLZ burn-mechanism drain, 2026-01-27
BlockSec states that a flawed PGNLZ burn mechanism allowed PGNLZ to be burned directly from the pool balance, which distorted pool reserves and price and let the attacker drain USDT from the pool. (Source: Weekly Web3 Security Incident Roundup, Jan 25 – Feb 1, 2026)
Incident 2 of 3. XPL burn-mechanism drain, 2026-01-28
BlockSec states that a flawed XPL burn mechanism allowed XPL to be burned directly from the liquidity pair, which manipulated pool reserves and price and let the attacker siphon USDT from the pool. (Source: Weekly Web3 Security Incident Roundup, Jan 25 – Feb 1, 2026)
Incident 3 of 3. BCE burn-mechanism drain, 2026-03-23
BlockSec states that a flawed BCE burn mechanism used a user-influenced scheduledDestruction value to burn tokens directly from the PancakeSwap pair address, which compressed LP reserves, distorted price, and let the attacker drain USDT. (Source: Weekly Web3 Security Incident Roundup, Mar 23 – Mar 29, 2026)
Incident 1 of 3. PGNLZ burn-mechanism drain, 2026-01-27
BlockSec estimates approximately $100,000 in losses and states the attacker ultimately made 100,901e18 USDT in profit. The loss fell on the liquidity in that single pool; no CAKE and no PancakeSwap treasury funds were affected. (Source: Weekly Web3 Security Incident Roundup, Jan 25 – Feb 1, 2026)
Incident 2 of 3. XPL burn-mechanism drain, 2026-01-28
BlockSec estimates approximately $717,000 in losses and states the attacker made 718,844e18 USDT in profit. The loss fell on the liquidity in that single pool; no CAKE and no PancakeSwap treasury funds were affected. (Source: Weekly Web3 Security Incident Roundup, Jan 25 – Feb 1, 2026)
Incident 3 of 3. BCE burn-mechanism drain, 2026-03-23
BlockSec estimates approximately $679,000 in losses and states the attacker netted approximately $679,000 in profit after borrowing 123,500,000 USDT via flash loans and a lending pool. The loss fell on the liquidity in that single pool; no CAKE and no PancakeSwap treasury funds were affected. (Source: Weekly Web3 Security Incident Roundup, Mar 23 – Mar 29, 2026)
Incident 1 of 3. PGNLZ burn-mechanism drain, 2026-01-27
PancakeSwap has not publicly disclosed protocol-issued remediation, compensation, or governance action. BlockSec instead recommends proper access controls and comprehensive testing of the burn mechanism, which is a recommendation directed at the third-party token issuer. (Source: Weekly Web3 Security Incident Roundup, Jan 25 – Feb 1, 2026)
Incident 2 of 3. XPL burn-mechanism drain, 2026-01-28
PancakeSwap has not publicly disclosed protocol-issued remediation, compensation, or governance action for this incident. (Source: Weekly Web3 Security Incident Roundup, Jan 25 – Feb 1, 2026)
Incident 3 of 3. BCE burn-mechanism drain, 2026-03-23
PancakeSwap has not publicly disclosed protocol-issued remediation, compensation, or governance action for this incident. (Source: Weekly Web3 Security Incident Roundup, Mar 23 – Mar 29, 2026)
Incident 1 of 3. PGNLZ burn-mechanism drain, 2026-01-27
PancakeSwap has not publicly disclosed a final resolution status beyond the third-party incident analysis. The incident is not recorded as in litigation, under investigation by the project, or refunded. (Source: Weekly Web3 Security Incident Roundup, Jan 25 – Feb 1, 2026)
Incident 2 of 3. XPL burn-mechanism drain, 2026-01-28
PancakeSwap has not publicly disclosed a final resolution status beyond the third-party incident analysis. The incident is not recorded as in litigation, under investigation by the project, or refunded. (Source: Weekly Web3 Security Incident Roundup, Jan 25 – Feb 1, 2026)
Incident 3 of 3. BCE burn-mechanism drain, 2026-03-23
PancakeSwap has not publicly disclosed a final resolution status beyond the third-party incident analysis. The incident is not recorded as in litigation, under investigation by the project, or refunded. (Source: Weekly Web3 Security Incident Roundup, Mar 23 – Mar 29, 2026)
Incident 1 of 3. PGNLZ burn-mechanism drain, 2026-01-27
The only public reference is the third-party security analysis linked below. PancakeSwap has published no post-mortem or advisory for this incident. (Source: Weekly Web3 Security Incident Roundup, Jan 25 – Feb 1, 2026)
Incident 2 of 3. XPL burn-mechanism drain, 2026-01-28
The only public reference is the third-party security analysis linked below. PancakeSwap has published no post-mortem or advisory for this incident. (Source: Weekly Web3 Security Incident Roundup, Jan 25 – Feb 1, 2026)
Incident 3 of 3. BCE burn-mechanism drain, 2026-03-23
The only public reference is the third-party security analysis linked below. PancakeSwap has published no post-mortem or advisory for this incident. (Source: Weekly Web3 Security Incident Roundup, Mar 23 – Mar 29, 2026)
Describe material risk factors across the three categories below. Each category includes prompts to address at a minimum.
(a) Regulatory, Legal & Tax Risks — Describe how evolving laws and regulations could affect the project by answering, at a minimum, questions like:
Impact of Regulatory Change on TGE and Listings: (If applicable) How could evolving or conflicting laws and regulations affect your ability to complete the TGE, deliver tokens to purchasers, and list or maintain the token on trading venues in key jurisdictions?
Entity-Level Regulatory Impact: (If applicable) How could regulatory or legal changes impact your core entities (Foundation, DevCo, DAO, affiliated service providers), including enforcement actions, licensing requirements, or forced changes to structure or operations?
Tokenholder Tax Treatment: (If applicable) What uncertainties exist around how tokenholders may be taxed, and make clear that tokenholders are responsible for understanding their own tax obligations?
Jurisdictional & User Access Restrictions: (If applicable) If the project restricts access for certain jurisdictions or user types (e.g., U.S. persons, sanctioned countries, retail vs. professional), what are those restrictions and what risks do they create for users and for the project?
(b) Protocol, Technology & Security Risks — Describe risks to network and contract reliability, correctness, and safety by answering, at a minimum, questions like:
Bugs and Design Flaws: (If applicable) What bugs, design flaws, or implementation errors could exist in your core protocol code, smart contracts, and any bridges, rollups, or oracles that you depend on, and how could these lead to loss of funds or disruption of the protocol?
Security Measures & Their Limitations: (If applicable) What security measures have you taken (audits, formal verification, bug bounties), and what types of failures might these measures still fail to detect or prevent?
(c) Token Economics, Unlocks & Incentive Risks — Describe how the token's economic design and supply schedule could affect holders by answering, at a minimum, questions like:
Critical Economic Assumptions: (If applicable) Which economic assumptions (e.g., staking yields, fee revenue, liquidity incentives, MEV capture, demand for blockspace) are critical for protocol security, utility, and governance, and what happens if those assumptions fail?
Governance Control over Monetary Policy & Rewards: (If applicable) To what extent can governance change monetary policy, fee parameters, or reward allocations (e.g., inflation rate, treasury flows, incentive programs), and how could such changes adversely affect tokenholders?
Impact of regulatory change on TGE and listings
Public sources do not disclose a TGE-specific legal or listing-compliance plan. CAKE had no token sale — it entered circulation through per-block emissions — so there is no TGE process exposed to regulatory change; the live exposure is to venue availability and to the continued operation of PancakeSwap's own products. PancakeSwap has not published an assessment of how regulatory change in any jurisdiction would affect CAKE listings or the availability of its trading interfaces. (Source: CAKE Tokenomics v1, PancakeSwap Product Overview)
Entity-level regulatory impact
PancakeSwap has not identified a named incorporated foundation or devco entity, which limits public visibility into entity-level legal exposure: there is no disclosed jurisdiction in which enforcement, licensing requirements, or forced structural change would land, and no disclosed entity to bear them. Archived affiliate-program terms state that PancakeSwap reserved discretion to change, vary, or discontinue services for referrals under that program and may change trading-fee arrangements, which shows that program terms and fee arrangements were allowed to change over time at the operator's discretion. PancakeSwap has not published a contingency plan for regulatory change affecting its operating structure. (Source: Terms & Conditions, Commission Structure and Payment, The Kitchen Team, PancakeSwap Governance)
Tokenholder tax treatment
PancakeSwap has not published tax guidance. Tokenholders are responsible for understanding and complying with their own tax obligations in their respective jurisdictions, and changes in tax rates or law could create additional liabilities. No project-specific statement exists on how farming rewards, staking rewards, revenue-sharing distributions, or disposals are treated in any jurisdiction. (Source: Terms & Conditions, Revenue Sharing FAQ)
Jurisdictional and user access restrictions
Archived affiliate-program materials state that perpetuals are prohibited from certain jurisdictions, which is a bounded public user-access restriction. PancakeSwap has not published a comprehensive jurisdiction matrix for all its products, so users cannot determine from public sources which products are available to them in which jurisdictions, and further regulatory change could extend restrictions to additional products or territories. (Source: Terms & Conditions, Commission Structure and Payment)
Bugs and design flaws
Public sources show several categories of protocol and integration risk. PancakeSwap's routing docs state that Smart Router uses V3, V2, StableSwap, and market-maker liquidity by default and that turning off multihops or split routing can worsen execution, increase slippage, or even lead to fund loss. The limit-order materials add that a separate order-flow path relies on off-chain takers competing to fill orders, that winning taker fees are removed from output tokens, that small orders can become uneconomic because of gas, that fee-on-transfer tokens should not be used with limit orders, and that open orders expire after 90 days if not canceled. The swap and troubleshooting FAQs also state that fee-on-transfer and rebase tokens are unsupported on Exchange V3, that some tokens can block most or all transfers or allow only certain addresses to sell, that scam tokens may be unsellable, and that PancakeSwap cannot block such tokens or return funds. Third-party security analyses identify three 2026 PancakeSwap-pool exploits tied to flawed burn mechanisms in the PGNLZ, XPL, and BCE tokens, with reported losses of approximately $100,000, $717,000, and $679,000 respectively — demonstrating that composability with third-party token contracts is a live fund-loss surface for liquidity providers. (Source: Fees and Routes, How to use Limit Orders (Legacy), Limit Orders and TWAP FAQ, PancakeSwap Swap FAQ, PancakeSwap Troubleshooting Errors, Weekly Web3 Security Incident Roundup, Jan 25 – Feb 1, 2026, Weekly Web3 Security Incident Roundup, Mar 23 – Mar 29, 2026)
Security measures and their limitations
Official materials describe open-source and verified contracts, multisig and timelock protections, an audit inventory, a live bug-bounty surface on Immunefi, and MEV Guard private-relay routing intended to reduce sandwich attacks, slippage, price manipulation, and lost value. The disclosed limits of those measures are visible in the 2026 pool exploits: audits and bug bounties cover PancakeSwap's own contracts and do not extend to the third-party token contracts that pair against them, and PancakeSwap's own FAQ states that it cannot block malicious tokens or return funds. MEV Guard is opt-in routing rather than a protocol-level guarantee, and timelocks delay but do not prevent a privileged change. PancakeSwap has not published formal verification coverage or the signing thresholds and key-holder identities behind its multisig protections. (Source: PancakeSwap Product Overview, PancakeSwap General FAQ, PancakeSwap Audits, PancakeSwap Bug Bounties, MEV Guard FAQ, PancakeSwap Troubleshooting Errors)
Critical economic assumptions
The public economic model depends on continued product usage, trading-fee generation, fee conversion, governance decisions about where emissions are directed, and sustained demand for CAKE-bearing launch or locking utility. PancakeSwap began with 40 CAKE per block of MasterChef emissions, later reduced effective emissions through burn and diversion mechanisms, and historically operated without a hard cap while routing recurring emissions to Farms and Lottery plus Syrup Pools. Later public tokenomics materials moved to the current 400,000,000 hard cap and a target of at least approximately 4% annual deflation and approximately 20% total supply reduction by 2030 through buy-back-and-burn mechanics, spot-trading fee burns, CAKE.PAD fee burns, and actively managed emissions. That deflation target is therefore contingent on trading volume: if fee generation falls, the burn rate falls and the deflation target is not met while emissions continue. Fixed-term locked CAKE earns weekly rCAKE-based revenue-sharing distributions whose processing can depend on fee conversion, lock duration, and delayed treatment of non-BNB-chain revenues, so distribution amounts are not guaranteed. CAKE.PAD sale mechanics show that overflow taxes are charged only on excess commitments, the partner project receives 100% of its target raise, and the collected CAKE taxes are fully burned — making that burn source contingent on launchpad demand. PancakeSwap has disclosed the mechanics behind the deflation target, emissions management, and fee-processing constraints, but has not quantified the risk if those assumptions fail. (Source: CAKE Tokenomics v1, Controlling CAKE supply v1, PancakeSwap CAKE Tokenomics, PancakeSwap CAKE.PAD, Revenue Sharing FAQ, How CAKE.PAD Taxes Work in Overflow Sales – With Example)
Governance control over monetary policy and rewards
Governance control over CAKE's monetary policy is extensive and has already been exercised to reshape the token repeatedly. The supply regime moved from uncapped and inflationary, to a proposed 750,000,000 cap in the May 2022 Tokenomics 2.0 litepaper, to the current 400,000,000 hard cap — each change altering the dilution profile for existing holders. Emissions are actively managed and directed to selected products such as multichain farms, Lottery, and Ecosystem Growth, so the allocation of new supply is a discretionary decision rather than a fixed schedule. Lock terms have also been changed: the veCAKE sunset redemption page states that, after Tokenomics 3.0, all locked CAKE was scheduled to unlock on April 23, 2025 at 9:00 UTC, which released previously committed supply. Because PancakeSwap retains core-proposal origination, the team sets the agenda for these changes, and holders vote on proposals rather than initiating them. (Source: PancakeSwap V2 Litepaper, PancakeSwap CAKE Tokenomics, Staked Cake Redemption, PancakeSwap Governance, Controlling CAKE supply v1)
This Token Transparency Filing is provided for general informational purposes only and does not verify or warrant the accuracy of individual answers.
