# Boardwalk — Full Product Documentation _Single-file dump of the entire Boardwalk docs site._ _Generated on 2026-05-21T14:56:54.524Z — for use as LLM context._ _Live docs: https://www.useboardwalk.com/docs_ # Welcome to Boardwalk *Docs are subject to change. Last updated: May 20, 2026.* Boardwalk is a community-centered fee-protection protocol for launching, discovering and participating in transparent token economies. It is open, permissionless, non-custodial, transparent, fair, auditable, and built to level the playing field for all. Users can discover and participate in token economies, provide liquidity and earn, in addition to directing designated fees through the BMX staking module. On Boardwalk, token launches are fair. All issuer, token and economy details are presented transparently on auction and token profile pages, with initial liquidity upon graduation seeded and permanently locked without human intervention or control. Tokens launched through Boardwalk utilize the Boardwalk standardization embedded into every token where it matters most, while having a degree of freedom to customize fringe settings to create their own economy. Boardwalk establishes the framework for security and transparency, while Issuers retain autonomy and flexibility. **Growth Team, Public Good, Referrers** are launch-specific fee and vesting recipients configured by the issuer. These can include an entity treasury, a public-good address, a growth team, and a referrer when the launch uses one. Boardwalk enables *anyone* to earn from nurturing token economies. **Issuers** define the characteristics of their token economy prior to launching. They choose a launch path, set the auction structure, configure fee routing, upload a description and video, and engage their community through Café Boardwalk. For Advanced launches, issuers configure initial liquidity and vesting splits. **Contributors** join auctions during the live window by depositing the raise token. Earlier contributors receive more weight through a 10% early participation bonus that decays to 0% by the end of the auction. ``` Effective weight = deposit × (1 + 0.10 × time remaining ÷ auction duration) ``` After a successful launch, they claim their token allocation once the 7-day claim cliff ends. If the launch does not reach its graduation threshold, they claim a full refund. Contributors can also trade, research, and evaluate live tokens through each token's profile page. **Liquidity Provider (LP) Participants** provide liquidity for live tokens launched through Boardwalk and are incentivized in multiple ways, including for staking for longer periods of time. Participants earn normal swap fees that compound in the pool. Participants earn a dedicated fee-stream from all token swaps and transfers (between 0.23% and 0.25% depending on the chain). If applicable, Participants also receive 20% of the vesting pool if vesting was configured into the launch. Participants earn Participation Points for staking longer over time. ``` Participation Points + LP size = Net Incentive allocation per LP ``` TL;DR — Participants who stake longer earn proportionally more incentives relative to short term stakers. DeFi summer anyone? **BMX Stakers** Each epoch, eligible stakers vote on where designated protocol fees should be routed. BMX stakers also accrue Voter Points, which increase at an 100% annual accrual rate, giving stakers who stake longer, a larger voting weight. ``` Voter Points + Total BMX staked = Total Voting Power ``` --- # Define and Launch a Token Economy ## Choose the launch path **Advanced** is the flexible path. It uses a 7-day auction, supports a presale allocation between 25% and 50% (in 5% steps), allows one to four issuer fee recipients, can include a referrer, and supports vesting. When the presale allocation is below 50%, vesting is enabled, as the remaining supply gets split between LP incentives (20% of remaining) and an issuer vesting allocation (80% of remaining). **Express** is the shorter path. It uses a 24-hour auction, splits the supply 50/50 between presale and liquidity, supports one issuer fee recipient, has no referrer, and includes no vesting. ## Set the launch details The issuer fills in the details users will see before they contribute: chain, name, ticker, logo, description, website, video, and social links. ## Set the auction structure The auction window and graduation threshold are static for all launches, as part of the Boardwalk standardization. Express uses a 24-hour auction. Advanced uses a 7-day auction and 24-hour start delay. The graduation threshold is currently 10 ETH or the chain-specific raise token equivalent (e.g. frxUSD on Fraxtal). The issuer can set a goal for the raise — an optional target intended to communicate the amount of contributions sought from contributors. The Raise Goal does not cap the auction and does not replace the graduation threshold. Auctions have no raise limits. ## How the supply is split For an Express launch (50% auction): 50% goes to auction contributors, 50% pairs with the raised asset to seed liquidity. There is no LP incentive pool and no issuer vesting. For an Advanced launch (auction set between 25% and 50%): the auction percentage goes to auction contributors, an equal amount pairs with the raised asset to seed liquidity, and the remainder becomes the vesting pool. 20% of the vesting pool funds LP incentives. The other 80% goes to issuer-directed vesting. An Advanced launch with a 30% for auction would split: 30% auction, 30% liquidity, 8% LP incentives, 32% issuer-directed vesting. For example, an Advanced launch sets 35% for auction which results in 35% for pairing into permanent liquidity. The 30% remaining; 6% is directed to LP vesting (20% of the remaining), leaving the issuer with 24% to direct to chosen recipients. ![Express vs Advanced supply split](/images/docs/express_vs_advanced_supply_split.png) ## Configure fee recipients The issuer defines issuer-directed fee destinations and sets the address and percentage for each allocation. **Issuer** is the person or team launching the token economy. **Entity** is usually a treasury or working-funds address, often protected by a team multisig. **Referrer** is typically someone who helped the issuer discover Boardwalk or get the auction set up. This is optional, and only Advanced supports it. The referrer portion comes from the Boardwalk portion, not from the Issuer. **Public good** is an optional destination for a cause or charitable organization. **Growth Team** can be an individual, team, or entity helping grow the project and community through marketing, content creation, community management, business development, or other targeted initiatives. Once the token is live, the core fee percentages are immutable for that launch. Addresses can rotate later through a timelocked address-change flow (see [Technical Appendix](/docs/technical)), but the fee split itself does not change. ## Configure token vesting Vesting is Advanced-only. When the presale allocation is below 50%, vesting is required. Advanced launches can support up to five vesting recipients, including a referrer. Once initialized, the vesting schedule is fixed. Issuer-directed vesting starts after a 7-day cliff and then vests linearly over 3 years. Only destination addresses can change via a 7-day timelock process. When an address is updated, vested but unclaimed tokens for the old address are claimed before the new address takes over. Vesting to LP Participants becomes active 24 hours after liquidity seed. ## BMX burn to launch Currently it requires burning 100 BMX to launch an economy on Boardwalk. This is seamlessly integrated in the launch process. --- # Joining an Auction *Disclaimer: Boardwalk is permissionless. A token appearing in the product is not approval or endorsement from the team.* ## What contributors deposit The deposit is the raise token for that chain, not the new token being launched. Think wETH or frxUSD on Fraxtal for example. An auction can accept unlimited deposits during the auction window. ## Early participation bonus Earlier contributions get more weight inside the auction. The bonus starts at 10% at the beginning of the auction and decays to 0% by the end. For example, a contributor who deposits 1 wETH at the halfway point of a 7-day auction receives a ~5% bonus, so their weighted contribution is ~1.05 wETH for allocation purposes. A contributor who deposits the same 1 wETH in the final minutes receives no bonus. Both deposits count equally toward the graduation threshold. ## What happens when the auction ends The auction window runs for 24 hours on Express launches and 7 days on Advanced launches by default. After the window closes, a 1-hour delay opens before the seeding step becomes available. Once that delay passes, any address can trigger seeding — the process requires no team action or approval. If the auction reached its graduation threshold, seeding mints the launch's full token supply and distributes it across the buckets defined by the launch path (see [How the supply is split](/docs/launching#how-the-supply-is-split)). The seeding call pairs the raised asset with the liquidity allocation in a v2-style pool with a 0.1% swap fee, then burns the LP tokens to the dead address. No address controls the seeded position, and no address can withdraw it. Seeding also initializes LP staking and vesting. The anti-sniper window activates at the moment of seed (see [Post-Launch](/docs/post-launch#the-anti-sniper-window)). If the auction did not reach its graduation threshold, the same call refunds rather than seeds. Contributors withdraw their full deposit from the contributing address. ## When tokens become claimable After liquidity is seeded and the 7-day claim cliff ends, contributors can claim their allocation of the auction supply. ## How allocation is decided Every Boardwalk launch has a fixed total supply of 10 billion tokens. The auction percentage determines how many of those tokens go to contributors as a group. Each contributor's allocation equals their weighted contribution (raw deposit times the live bonus multiplier — 1.10 at auction open, decaying to 1.00 at auction close) divided by total weighted contributions in that auction, multiplied by the total contributor token allocation. For example, an Advanced launch with a 30% auction allocation directs 3 billion tokens to contributors. A contributor whose weighted contribution equals 5% of the auction's total weighted contributions claims 150 million tokens. ``` Contributor Allocation = (Individual Weighted Contribution / Total Weighted Contributions) × Total Contributor Token Allocation ``` ``` 150,000,000 tokens = (5 wETH / 100 wETH) × 3,000,000,000 tokens ``` --- # After an Economy Launches Once liquidity is seeded, the token goes live as a token economy with permanently locked liquidity and built-in fee logic. The fee is built into the token itself. It functions similarly to a swap fee and lives in the token itself, not in any one pool. This protects the token economy from sophisticated strategies that would otherwise capture trading fees meant for the economy's participants. The total token fee amounts to 1.15%, combined with the 0.10% swap fee at the DEX level, making the total net cost to traders 1.25% across all chains. The fee routes value to different destinations depending on how the launch was set up and which chain it launched on: LP incentives, Boardwalk, issuer recipients, and depending on the chain, a referrer or an integrator allocation. ## Locked liquidity Locked liquidity means the seeded position cannot be withdrawn. It does not mean price stability, guaranteed exits, or protection from market risk. Trading risk after launch is normal market risk. ## Where liquidity lives When users add or remove liquidity through Boardwalk, the token's built-in fee does not apply. This liquidity lives in v2-style pools paired with the chain's raise token, with a swap fee of 0.1% set at the DEX factory level. The fee exemption only applies to liquidity added through Boardwalk's standard pools. The built-in fee makes sophisticated strategies attempting to capture trading fees outside of these pools uneconomical. In practice, liquidity for Boardwalk-launched tokens tends to live in standard pools as a result. ![Auction flow](/images/docs/auction_flow.png) ## Fee schedules by chain ### Base and Katana Advanced: 0.30% issuer and issuer-designated, 0.05% referrer, 0.30% Boardwalk, 0.23% issued-token LP incentives, 0.27% integrators, 0.10% swap fee. Express: 0.30% issuer and issuer-designated, 0.35% Boardwalk, 0.23% issued-token LP incentives, 0.27% integrators, 0.10% swap fee. ### Fraxtal Advanced: 0.30% issuer and issuer-designated, 0.05% referrer, 0.30% Boardwalk, 0.25% issued-token LP incentives, 0.25% integrators, 0.10% swap fee. Express: 0.30% issuer and issuer-designated, 0.35% Boardwalk, 0.25% issued-token LP incentives, 0.25% integrators, 0.10% swap fee. ### Ethereum Mainnet Advanced: 0.35% issuer and issuer-designated, 0.05% referrer, 0.30% Boardwalk, 0.25% issued-token LP incentives, 0.20% integrators, 0.10% swap fee. Express: 0.35% issuer and issuer-designated, 0.35% Boardwalk, 0.25% issued-token LP incentives, 0.20% integrators, 0.10% swap fee. *Disclaimer: future chains may have different fee schedules.* Note: the total net swap-fee equivalent for traders is 1.25%. For Advanced token launches, if a referrer is not set, that portion defaults to Boardwalk. ## The anti-sniper window Right after liquidity is seeded, the anti-sniper window kicks in. The fee starts at 40% and decays down to the token's base fee over the first 90 minutes after launch. After that, the base fee applies permanently. ## Fee routing The token sends its fee amount into a fee distributor, which splits that amount according to the launch setup. The system is built so token transfers do not fail if one downstream forward has a problem — failed allocations accumulate in pending balances and can be retried permissionlessly. Fees allocated to LP Participants are collected on a weekly epoch basis after liquidity seed and stream to stakers over the following epoch, so there is always a one-epoch lag between when fees accrue and when they reach stakers. ## How issuer fee claims are paced Each issuer fee recipient can claim up to 10% of their unclaimed balance once every 24 hours. The claim converts into the raise token at the time of the call, with the recipient supplying their own slippage protection and deadline. On an Advanced launch with multiple issuer recipients, each recipient's 24-hour clock runs independently. If a recipient's unclaimed balance is small enough that 10% would round to zero, the full unclaimed amount becomes claimable in one call. Integrator claims follow a separate pacing rule: each integrator can claim up to 25% of their unclaimed balance per token every 24 hours, with a similar small-balance escape. Integrators can also claim across multiple tokens in a single call. ## Fee-exempt actions Some system actions do not trigger the built-in fee: token claims after the auction cliff, vesting claims, LP staking fee flows, and adding or removing liquidity through Boardwalk. --- # Providing Liquidity After a token economy goes live, users can provide liquidity and stake their LP position to earn from multiple streams. LP Participants earn normal swap fees, which compound directly in the pool. LP Participants also earn a dedicated fee-stream from all token swaps and transfers (between 0.23% and 0.25% depending on the chain). If vesting was configured into the launch, LP Participants also receive an allocation from the vesting pool (20% of the vesting allocation, streaming linearly over 3 years). There is a 24-hour cliff from liquidity seed before the dedicated fee-stream and vesting distributions begin. ``` Participation Points + LP size = Net Incentive allocation per LP ``` Participants who stake longer earn proportionally more incentives relative to short-term stakers. ## Participation Points Participation Points build at a 100% annual accrual rate while an LP remains staked. They determine that LP's proportional allocation of fee distributions and, where applicable, vesting distributions. They are non-transferable and have no monetary value. On unstake, Participation Points burn proportionally. A full exit burns the related points with it. A partial withdrawal reduces points in proportion to what was removed. ## Claiming while staked The staking flow supports staking, withdrawing, and claiming as separate actions. An LP participant can claim pending accrued fees without leaving the pool. ![LP rewards](/images/docs/lp_rewards.png) --- # BMX, Staking, and Voting BMX is Boardwalk's protocol token. BMX also functions as a consumption token, burned by users across all chains to launch a token economy and influence project discovery through Upvoting and Downvoting. ## Voting Power A staker's weight to vote-direct designated fees is called Voting Power. It equals staked BMX plus Voter Points. ``` Voting Power = Staked BMX + Voter Points ``` **Staked BMX** is the base of voting weight. **Voter Points** build at a 100% annual accrual rate while BMX stays staked. They are non-transferable and have no monetary value. On unstake, Voter Points burn proportionally — a full exit burns the related points, and a partial withdrawal reduces points in proportion to what was removed. ``` 12,000 BMX staked + 2,820 Voter Points = 14,820 Voting Power ``` ## How voting works Voting happens in weekly epochs. During each epoch, BMX stakers vote on where the designated portion of Boardwalk's fees should be directed next. Votes cast in one epoch direct the designated fees collected in the following epoch. *Disclaimer: The amount that actually flows depends on protocol activity and may be low or zero.* The vote is winner-take-all. The option with the most support gets the routing for that epoch. The designated fees directed each epoch are held onchain by the protocol, not in a team-controlled wallet. When a vote resolves, the contract executes the winning outcome automatically onchain. ## The four vote options **BMX Buy & Burn** — The fee budget buys BMX from the market and sends it to the burn address. Once burned, that BMX cannot be recovered. **Route to Operations Reserve** — The fee budget transfers to the protocol Operations Reserve in the raise token. **Perma-Lock BMX/WETH** — The fee budget is split in half. One half is swapped into BMX. The two halves are paired into a BMX/WETH liquidity position that is permanently locked. Trading fees from that position flow to the Operations Reserve over time. **Route to BMX Stakers** — The fee budget buys BMX, then streams it over 7 days to stakers who voted in the prior epoch. ## Eligibility: the 1.5% Voter Points ratio To vote in a given epoch, a staker needs Voter Points equal to at least 1.5% of their staked BMX. A staker with 1,000 BMX staked needs at least 15 Voter Points. ## Quorum Boardwalk uses a 51% quorum — total Voting Power cast must reach at least 51% of the snapshotted total. If quorum is not reached, the designated fees revert to the Operations Reserve for that epoch. ## The consecutive-win cap An option that wins three epochs in a row is ineligible the next epoch. After sitting out one epoch, it returns to the ballot. ![Voting flow](/images/docs/voting.png) ## BMX Tokenomics BMX is Boardwalk's protocol token. It functions as both a utility token and a consumption token across all chain deployments. **Supply.** As of May 11, 2026, total BMX supply is 2,712,002. The token contract is renounced and the minter is burned, which means no one — including the Boardwalk team — can create new BMX. Supply can only decrease over time through burns. **Deflationary by design.** Several protocol actions permanently remove BMX from supply by sending it to the burn address (`0x000000000000000000000000000000000000dEaD`). Tokens sent to this address cannot be recovered or re-issued. BMX burns when users perform specific onchain actions. Launching a token economy on Boardwalk burns a protocol-defined amount of BMX from the issuer. Using Upvote or Downvote to signal on a token or auction burns BMX as a one-way cost — each address can use one Upvote and one Downvote per token or auction every 30 days. Additionally, one of the four vote direction options (BMX Buy & Burn) uses designated fees to purchase BMX and send it to the burn address. Because these burns depend on actual protocol activity, the rate of supply reduction varies and may be low or zero in any given period. **Holding vs. staking.** Holding BMX and staking BMX are different roles. Holders keep BMX in a wallet and can use it for community signaling or launch creation. Staking creates eligibility to vote-direct designated fees in weekly epochs. For how Voting Power works and how vote direction operates, see the sections above. Staking and voting actions currently operate on Base. *Note: BMX stakers direct a designated portion of Boardwalk's fees through onchain rules — this does not imply broad control over every part of the protocol. Stakers do not control the Operations Reserve and do not receive ownership, equity, or claims on protocol fees through staking or vote direction.* ## Primary BMX Liquidity Primary BMX liquidity is on Base and easily accessed via DEX meta-aggregators like [LlamaSwap](https://swap.defillama.com/?chain=base&from=0x0000000000000000000000000000000000000000&tab=swap&to=0x548f93779fbc992010c07467cbaf329dd5f059b7). ## Community Signals and Discovery Boardwalk includes community signals that affect how tokens and auctions appear in the default discovery view. An **Upvote** moves a token or auction higher in the default discovery ranking. A **Downvote** moves it lower. Both burn BMX as a one-way cost. Each address can use one Upvote and one Downvote per token or auction every 30 days. The visibility score is total Upvotes minus total Downvotes. All Upvote and Downvote activity resets every 30 days. *Disclaimer: Community signaling can influence what users see first, but it does not change a token's launch rules, fee setup, vesting schedule, or liquidity design. These are onchain signals from users, not team ratings, safety reviews, or recommendations.* --- # Community & Dashboard Boardwalk pairs an open community forum with an account-level dashboard so contributors, issuers, and LPs can stay in sync on every launch. ## Café Boardwalk Café Boardwalk is the community space tied to launches on Boardwalk. It is a public web forum where contributors, issuers, and other participants can discuss a token, ask questions, and share updates. It sits on the open web, not inside a separate chat app, increasing discoverability for economy communities. Every launch is automatically added when it is created. Issuers can use their launch's space to post project updates, answer questions, and publish context that did not fit on the launch page. Third parties who want to support a token — through liquidity support, growth and community help, security review, treasury management, or public-good contributions — can also connect with the issuer and community here. *Disclaimer: Café Boardwalk is a discussion and coordination surface, not an onchain mechanism. Conversations there do not mint or move tokens, change fee splits, adjust vesting, or cast votes.* ## The Dashboard The dashboard tracks where launches are in their lifecycle and what the next available action is for each one. ### Overview The top of the dashboard shows a summary of activity across all of a user's launches and positions: auctions joined, tokens launched, total contributed, total claimable, and high-level totals. ### Your Tokens Lists tokens a user currently holds from launches they have joined or claimed. Each row shows the token, current balance, recent price activity, and quick links to act on it. ### BMX Staking Shows current staked BMX, pending BMX claims, and active staking actions. Staking-related actions like claiming and adjusting a stake start here. ### Your Liquidity Positions Lists active LP positions across launched tokens. Each card shows position size, accrued Participation Points, and pending distributions. ### Your Visibility Influence Tracks how a user has used Upvotes and Downvotes during the current 30-day window, showing what has been used and what is still available. ### Fee & Vesting Allocations Visualizes where fee and vesting flows are coming from across launches. The donut chart breaks down current allocations by source, and the table shows specific recipient relationships and vesting schedules. ### Auction Track Record Summarizes a user's history with auctions: contributions made, launches participated in, and success rate of those launches reaching threshold. ### Launch Summary For issuers, tracks launches the user has created — total raised, current status, and key milestones. ### Token Profile Page Each launched token has a single-page view bringing together market information (price, chart, market cap, volume), liquidity profile and earned fees, project details and intro video, fee and vesting allocations with pending changes and change history, auction results, and the link to the token's Café Boardwalk thread. --- # FAQ ## Launches and auctions **Did Boardwalk approve this launch?** No. Launches through Boardwalk are permissionless. A token launching through Boardwalk is not an endorsement, recommendation, or approval from the team. **What is the graduation threshold?** Currently 10 ETH or the chain-specific raise token equivalent. A launch must reach this amount during its auction window to graduate and seed liquidity. If it does not, contributors can claim a full refund. **What happens if a launch does not reach its threshold?** Contributors can claim a full refund of the raise token they deposited from the launch page after the auction window closes. **Can a launch be canceled while it is live?** No. The auction window and graduation threshold are set at launch. If the threshold is not met by the deadline, the auction does not graduate and refunds become claimable. **What is the difference between Express and Advanced?** Express: no start delay, 24-hour auction, 50/50 auction-to-liquidity split, one issuer fee recipient, no referrer, no vesting. Advanced: 24-hour start delay, 7-day auction by default, 25–50% auction allocation (in 5% steps), one to four issuer fee recipients, optional referrer, vesting support. **Can a launch take unlimited deposits?** Yes. A Raise Goal may be shown, but it does not cap the raise and it does not change the graduation threshold. **Does contributing earlier change my allocation?** Yes. The bonus starts at 10% and decays to 0% by the end of the auction. That changes how the allocation is split among contributors but does not change whether the launch meets threshold. **What is the raise token?** The asset contributors deposit into the auction. If the launch succeeds, it later pairs with token supply for liquidity. The raise token depends on the chain. **Does every launch include vesting?** No. Express launches do not include vesting. Advanced launches can include vesting, and Advanced launches with an auction below 50% require it. ## Between auction and claim **What happens if I lose access to my wallet between the auction and the claim?** Auction allocations and refunds are tied to the contributing address. If the user no longer controls that address, they cannot claim. Boardwalk cannot redirect a claim to a different address. **Can I sell or transfer my auction allocation before the claim cliff ends?** No. Auction allocations are claimable only after the 7-day cliff ends, and only by the contributing address. **What happens during the gap between a successful auction and liquidity being seeded?** There is a short transition step with a visible countdown. Liquidity seeding is permissionless after a 1-hour delay. Once liquidity is seeded, the 7-day claim cliff begins. ## After launch **What does locked liquidity mean?** The raised asset is paired with token supply, the LP tokens are burned to the dead address, and the seeded position cannot be withdrawn. **Can launch settings be changed after a token goes live?** The core fee percentages are fixed. Some recipient addresses can change through a timelocked flow (see [Technical Appendix](/docs/technical)), but the percentages and vesting schedule do not. **Why does the token have a higher fee right after launch?** That is the anti-sniper window. The fee starts at 40% right after liquidity is seeded and decays to the base fee over the first 90 minutes. **Where does the liquidity for Boardwalk-launched tokens live?** In v2-style pools paired with the chain's raise token, with a 0.1% swap fee. Adding or removing liquidity through Boardwalk does not trigger the built-in fee. Sophisticated strategies operating outside of these pools do trigger it, so in practice liquidity tends to live in standard pools. **Why can't I claim my full issuer fee balance at once?** Each issuer fee recipient can claim up to 10% of their unclaimed balance every 24 hours. If the unclaimed balance is small enough that 10% rounds to zero, the full amount becomes claimable in one call. On Advanced launches with multiple issuer recipients, each has its own 24-hour clock. ## Liquidity and participation **What are Participation Points?** Points that build over time while an LP participant stays staked. They affect that participant's allocation of fee distributions and, where applicable, vesting distributions. Non-transferable, no monetary value. **What happens to my Participation Points if I unstake?** Points burn proportionally. Full exit burns all related points. Partial withdrawal reduces them proportionally. **If no one is staked, what happens?** Those accrued token fees are lost rather than carried forward. (Regular swap fees from the pool itself accrue as normal.) ## BMX and Vote Direction of Designated Fees **What are Voter Points?** Points that build over time while BMX stays staked. Added on top of staked BMX to form total Voting Power. Non-transferable, no monetary value. **What is the difference between holding BMX and staking BMX?** Holding means holding the token. Staking creates voting eligibility. **Can I vote as soon as I stake?** Not necessarily. Voting requires Voter Points equal to at least 1.5% of staked BMX. That ratio builds over time. **What are the four vote options?** BMX Buy & Burn, Route to Operations Reserve, Perma-Lock BMX/WETH, and Route to BMX Stakers. The winning option directs designated fees for the next epoch. **Can the same option keep winning?** Up to three epochs in a row. After that it sits out one epoch, then returns. **What happens if not enough people vote?** Boardwalk uses a 51% quorum. If not reached, designated fees revert to the Operations Reserve for that epoch. **Do BMX holders control everything in Boardwalk?** No. Stakers direct a designated portion of Boardwalk's fees through onchain rules. It does not imply broad control over every part of the protocol. **Why does using Upvote or Downvote burn BMX?** Upvote and Downvote use BMX as a one-way cost. Once burned, it does not come back. **Do Participation Points or Voter Points have monetary value?** No. Both are non-transferable and tracked inside the system only. ## Discovery **Are Upvotes and Downvotes recommendations?** No. They are community signals that affect default visibility, not team ratings or safety reviews. **How often can I use Upvote or Downvote?** Each address can use one Upvote and one Downvote per token or auction every 30 days. ## Fee recipients and referrers **What kinds of fee recipients can a launch include?** An issuer recipient and, depending on the setup, other issuer-directed routing (entity, public good, growth team). The fee schedule also includes chain-specific recipients such as an integrator allocation, with the exact configuration depending on the chain. **What does a referrer mean on Boardwalk?** Someone who helped the issuer discover Boardwalk or get the auction set up. When included, the referrer address can be part of fee routing and, in some launch types, vesting. **Is every recipient optional?** Every launch has issuer-side routing. Express supports one issuer recipient and no referrer. Advanced supports one to four issuer recipients and can include a referrer. ## Post-launch address changes **Which addresses can change after launch?** Issuer fee recipient addresses (changed by the current recipient for that position), the referrer address (changed by the current referrer), and vesting recipient addresses (changed by the launch issuer). These use a 7-day timelocked flow: signal, wait 7 days, execute within a 7-day window. Integrator addresses can also change, but with a 14-day delay — only the current integrator for that position can signal the change, and the replacement address cannot already be held by another integrator. Stale signals expire automatically. **What happens when a vesting recipient address is changed?** Vested but unclaimed tokens for the outgoing recipient are automatically claimed before the new address takes over. **Can the ability to change a vesting recipient be turned off permanently?** Yes. The issuer can permanently burn that ability for a specific vesting recipient. **Do the fee percentages or vesting schedule change?** No. Only addresses can change. The economic split and vesting schedule are fixed at launch. --- # Glossary ### Annual Accrual Rate The fixed rate at which Participation Points or Voter Points build over time while a position remains staked. A 100% annual accrual rate means points build at a 1:1 yearly rate relative to the amount staked. It describes point growth only. ### Anti-Sniper Window A short higher-fee window right after liquidity is seeded. The fee starts at 40% and decays to the token's base fee over the first 90 minutes after launch. ### Auction The launch window where contributors deposit the raise token. If the launch reaches its graduation threshold, the token moves forward into liquidity seeding. If it does not, contributors can claim a full refund. ### Auction Claim Cliff The waiting period after liquidity is seeded before auction contributors can claim their token allocation. On current launch settings, that cliff is 7 days. ### Boardwalk The protocol itself. Boardwalk is where launches begin, contributors join auctions, liquidity participation continues after launch, and stakers vote to direct designated fees. ### Burn A one-way action that sends BMX to the burn address, permanently removing it from supply. Some Boardwalk actions burn BMX, including community signaling (Upvote and Downvote) and certain launch-creation costs. ### Burn Address The onchain address used for permanent burns: `0x000000000000000000000000000000000000dEaD`. Tokens sent there cannot be recovered. ### BMX Buy & Burn A vote option. The fee budget is used to buy BMX from the market and send it to the burn address. ### Café Boardwalk The community web forum tied to launches on Boardwalk. Every launch is automatically added, giving contributors, issuers, and third-party supporters a built-in place for Q&A, updates, and discussion. Participation in Café Boardwalk is separate from onchain rules and does not change launch mechanics, fee routing, vesting, or Voting Power. ### Claim The action of receiving tokens that have become available through the launch, vesting, or staking flow. Claiming happens only when the relevant rules and timing conditions have been met. ### Consecutive-Win Cap A rule for designated fee direction. An option that wins three epochs in a row is ineligible the next epoch. After sitting out one epoch, it returns to the ballot. ### Contributor A user who deposits the raise token during an auction. If the launch succeeds, the contributor can later claim tokens. If the launch does not succeed, the contributor can claim a full refund. ### Downvote A community signal that moves a token or auction lower in the default discovery ranking. Using Downvote burns BMX as a one-way cost. Each address can use one Downvote per token or auction every 30 days. ### Epoch A seven-day cycle used for voting, quorum, and fee direction. ### Express The shorter launch path. It uses a 24-hour auction, a 50/50 split between auction and liquidity, one issuer fee recipient, no referrer, and no vesting. ### Fee Routing The way a launched token's built-in fee is split and sent to the destinations chosen in that launch. Depending on the chain and launch type, that can include LP incentives, Boardwalk, issuer recipients, a referrer, or an integrator allocation. ### Raise Goal An optional target shown during a launch. It helps communicate what the launch is aiming for, but it does not cap the raise and it does not change the graduation threshold. ### Graduation Threshold The minimum amount the auction must raise for the token to launch and seed liquidity. This is the number that decides whether the launch moves forward. Currently 10 ETH or the chain-specific raise token equivalent. ### Growth Team Anyone or party who helps nurture growing economies. This can include but not limited to content creators, key opinion leaders (KOLs), liquidity partners, public relations, community leads and moderation, security partners, business development, ambassadors, developer relations, events or education. ### Holder Someone who has BMX in a wallet but has not staked it. Staking enables eligibility to vote direct designated fees. ### Integrator A fee recipient included in every chain's fee schedule. A portion of the built-in fee routes to integrators as part of the standard fee split. ### Issuer The person or team launching a token through Boardwalk. The issuer chooses the launch setup up front, including launch path, fee routing, and vesting where supported. ### Issuer Claim Rate Limit The pacing rule on issuer fee claims. Each issuer fee recipient can claim up to 10% of their unclaimed balance once every 24 hours, with the claim converting into the raise token. A small-balance escape allows the full unclaimed amount to be claimed in one call when 10% would round to zero. The limit applies per recipient — recipients on the same launch each have their own 24-hour clock. ### Launch Paths The two main launch formats on Boardwalk: Express and Advanced. Express is shorter and simpler. Advanced is longer and more flexible. ### Liquidity Seed The step where the raised asset is paired with token supply after a successful auction to open the economy. ### Locked Liquidity Liquidity that is locked by the launch design after a successful auction. The seeded position cannot be withdrawn. It does not mean stable prices or guaranteed exits. ### LP Incentive Cliff The waiting period before LP incentives begin after liquidity is seeded. On current launch settings, that cliff is 24 hours. ### LP Participant A user who stakes into a launched token's liquidity pool after the token is live. LP participants can take part in fee-based and, where applicable, vesting-based flows tied to that pool. ### Operations Reserve A team-controlled multisig used for Boardwalk operations and other protocol-related purposes. Only the portion of Boardwalk's fee designated for the Operations Reserve routes there automatically; the designated portion sits in the `GovernanceVoter` contract until an epoch's vote resolves. ### Participation Allocation (Route to BMX Stakers) A vote option. The fee budget is used to buy BMX, then streamed over 7 days to stakers who voted in the prior epoch. ### Participation Points Points that build over time while an LP participant stays staked. They affect that participant's allocation of fee distributions and, where applicable, vesting distributions. They are non-transferable and have no monetary value. ### Perma-Lock BMX/WETH A vote option. The fee budget is split in half and used to mint a BMX/WETH liquidity position that is permanently locked. Trading fees from that position flow to the Operations Reserve over time. ### Permissionless Open to use without team approval or curation. Launches through Boardwalk are permissionless, which means a token appearing on the platform is not a team endorsement. ### Quorum The minimum level of voting participation needed for a vote direction result to count. Boardwalk uses a 51% quorum. If quorum is not reached, the designated reserves revert to the Operations Reserve for that epoch instead of being designated. ### Raise Token The asset contributors deposit into the auction. If the launch succeeds, it later pairs with token supply for liquidity. The raise token depends on the chain. ### Refund What contributors can claim if a launch does not reach its graduation threshold by the deadline. The refund returns the raise token deposited during the auction. ### Referrer A launch-specific destination that can be included in fee routing and, in some launch types, vesting as well. In practice, a referrer is often someone who helped the issuer discover Boardwalk or get the auction set up. ### Route to Operations Reserve A vote option. The fee budget transfers to the protocol Operations Reserve in the raise token. ### Signaling Window The 30-day window used for Upvotes and Downvotes. Each address can use one Upvote and one Downvote per token or auction during that window. When a new window begins, those actions reset. ### Sophisticated Strategies A set of approaches used by advanced actors to capture trading fees from a token economy at the expense of other participants. On most trading platforms, these strategies are possible because fee logic lives at the pool or venue level rather than in the token itself. The most well-documented form is Just-in-Time (JIT) liquidity. A bot watches for a large pending trade, drops a tightly targeted liquidity position into the pool right before the trade executes, collects the bulk of the trading fee from this single trade, and removes the position immediately after. Other liquidity providers in the same pool earn close to nothing on this trade. Researchers at Imperial College London identified 36,671 JIT attacks across roughly 20 months of activity on Uniswap v3, with one bot capturing 92% of the total profit and existing liquidity providers experiencing an average fee dilution of 85% per event (Xiong et al., 2023, "Demystifying Just-in-Time (JIT) Liquidity Attacks on Uniswap V3," IEEE S&P Workshop / IACR ePrint 2023/973). Uniswap's own research found JIT accounted for less than 1% of total v3 liquidity, but this small share was concentrated on specific pools and specific trades where the extraction per event was significant (Uniswap Labs, "Just-In-Time Liquidity on the Uniswap Protocol," 2022). A related approach uses range orders. These are tightly placed liquidity positions that function similarly to limit orders. When the token's price crosses through the range, the position converts, effectively executing a trade that does not appear on a typical price chart. These positions can absorb volume and influence price movement without being visible to most traders. Boardwalk's built-in fee lives in the token, not in any one pool. Every position adjustment and every interaction with the token triggers the fee, removing the cost advantage that makes these strategies profitable elsewhere. ### Staker A BMX holder who has staked. Stakers can vote during each epoch on where the designated portion of Boardwalk's fee should go, provided they meet the 1.5% Voter Points ratio. ### Start Delay The 24-hour window between when an Advanced launch is created and when its auction opens for contributions. Express launches have no start delay. ### Time-Weighted Bonus The early participation bonus inside an auction. It starts at 10% at the beginning of the auction and decays to 0% by the end. It affects how the auction allocation is split among contributors. ### Token Profile Page A single-page view for a launched token. It brings together market information (price, chart, market cap, volume), liquidity profile and earned fees, project details and intro video, fee and vesting allocations with pending changes and change history, auction results, and the link to the token's Café Boardwalk thread. ### Upvote A community signal that moves a token or auction higher in the default discovery ranking. Using Upvote burns BMX as a one-way cost. Each address can use one Upvote per token or auction every 30 days. ### V2-Style Pool A standard liquidity pool where the liquidity is spread evenly across the price curve, rather than concentrated into narrow ranges. Boardwalk-launched tokens trade in this kind of pool, with a swap fee of 0.1% set at the DEX factory level. ### Vesting A schedule that makes tokens claimable over time instead of all at once. Some launches include vesting for specific recipients as part of the launch setup. ### Vesting Cliff The waiting period before a vesting stream begins releasing tokens. On current launch settings for issuer-directed vesting, that cliff is 7 days from liquidity seed. ### Visibility Score The score that shapes default discovery ranking inside Boardwalk. It is total Upvotes minus total Downvotes. Because Upvotes and Downvotes reset every 30 days, the visibility score resets every 30 days as well. ### Voter Points Points that build over time while BMX stays staked. They are added on top of staked BMX to form total Voting Power. They are non-transferable and have no monetary value. Points burn proportionally on unstake. ### Voter Points Ratio (1.5%) The eligibility requirement to vote in a given epoch. A staker needs Voter Points equal to at least 1.5% of their staked BMX. ### Voting Power A staker's total weight for vote direction of designated fees, equal to staked BMX plus Voter Points. It is what the protocol counts when tallying votes. ### Winner-Take-All The rule used in the vote direction of designated fees. The option with the most support gets the routing for that epoch. There is no split across second or third place. --- # Technical Appendix The technical appendix covers the onchain structure behind Boardwalk: which contracts do the work, which parts are shared across launches, and which settings can still change after deployment. ## How the system is structured Boardwalk Launchpad is built as a permissionless launch system with auctions, liquidity seeding, built-in fee routing, LP staking, and vesting. The launch system uses minimal proxy clones so new launches can be created from shared implementations rather than redeploying full logic each time. Each launch gets its own token and launch-specific contracts, while the broader protocol relies on a smaller set of shared singleton contracts. ## Per-launch contracts Each launch is built from a set of launch-specific contracts. **`BoardwalkToken`** is the launched token contract. It holds the built-in transfer-fee logic, tracks the liquidity seed time, and points to the launch's fee distributor and presale manager. It does not have a normal owner-controlled admin surface after initialization. **`FeeDistributor`** routes the launched token's built-in fee according to the launch setup. It can split fee flow across LP staking, Boardwalk, issuer recipients, and depending on the chain, a referrer or an integrator allocation. It also supports retries if a downstream forward fails, so token transfers do not depend on every later step succeeding in the same transaction. Issuer fee recipients claim their allocation through the fee distributor's claim function, which converts the claim into the raise token. Each recipient is rate-limited to 10% of their unclaimed balance per 24 hours, with a small-balance escape so dust does not get stranded. **`PresaleManager`** runs the auction. It accepts contributions, tracks weighted contributions, handles refunds if threshold is not met, and seeds liquidity after success. It also manages claim timing for auction contributors after the claim cliff. **`LPStaking`** handles post-launch liquidity participation. It combines fee-based distributions with a longer-running vesting stream for LP incentives, and it tracks the point-based weight used inside that system. After initialization, it has no ongoing admin controls. **`VestingStream`** exists on launches that include vesting. It holds the vesting allocations, enforces the cliff and vesting schedule, and allows only the vesting recipient address to change through a timelocked path. The vesting amounts, schedule, and labels do not change after setup. ## Shared protocol contracts Some contracts are shared across all launches rather than recreated per launch. **`LaunchFactory`** is the deployment entry point. It validates configuration, burns BMX when required, deploys the per-launch clones, initializes them in the right order, and stores launch records. It also controls a set of future-launch admin defaults through timelocked actions. **`BoardwalkLPManager`** is the shared liquidity helper. It provides the fee-exempt path for adding and removing liquidity without triggering the launched token's built-in fee, but only for supported raise-token pairs. The swap fee on these pools is 0.1%, set at the DEX factory level. It has no admin controls after deployment. **`BoardwalkFeeCollector`** collects the Boardwalk allocation of fee flow from live launches. It can batch process those balances and route them onward through the protocol's fee flow. It also controls its own treasury, keeper, voting vault, and collector migration path through timelocked actions. **`GovernanceVoter`** runs weekly epochs, collects votes, finalizes results against quorum, and executes the winning option. It also enforces the consecutive-win cap and the 14-day deadlock fallback, which routes the unexecuted budget to a separate fallback treasury address. **`LPLocker`** holds the permanently locked BMX/WETH liquidity positions created by the Perma-Lock vote option. Trading fees from those positions can be claimed to the treasury over time. **`ParticipationDistributor`** creates the 7-day BMX streams that fund the Route to BMX Stakers vote option for eligible voters from the prior epoch. **`BoostBurn`** handles the BMX burns triggered by community signaling and other one-way protocol actions. **`IntegratorFeeCollector`** receives the integrator allocation of fee flow from live launches and splits it across integrator positions by fixed per-position percentages. Each integrator independently claims their accrued balance, which converts into the raise token. Position addresses can change through a 14-day timelocked path controlled by the current holder. These contracts sit at the protocol layer and support system-wide voting and discovery behavior. ## Architecture summary Per-launch clones (one set per launch): `BoardwalkToken`, `FeeDistributor`, `PresaleManager`, `LPStaking`, and `VestingStream` (only on launches that use vesting). Shared singletons (one instance protocol-wide): `LaunchFactory`, `BoardwalkLPManager`, `BoardwalkFeeCollector`, `IntegratorFeeCollector`, `BoostBurn`, `GovernanceVoter`, `LPLocker`, `ParticipationDistributor`, and the shared DEX factory and router contracts. ## Launch flow at the contract level At deployment time, `LaunchFactory` creates the per-launch contracts first and then initializes them in order. After a successful auction, `PresaleManager` seeds liquidity, mints the needed token allocations, burns the LP tokens from the seeded position, initializes LP staking and vesting where applicable, and then activates the launched token's live fee behavior by setting the liquidity seed time. Once the token is live, transfers that are not exempt route the built-in fee into `FeeDistributor`. From there, the system can forward the LP portion to `LPStaking`, the Boardwalk portion to the fee collector, and accrue the issuer, referrer, or integrator portions according to the chain's fee schedule. ## What is immutable after a launch goes live The core fee percentages for a live launch are immutable at deployment for that launch. Factory-level defaults can still be changed for future launches, but those later factory changes do not rewrite a launch that is already live. On the vesting side, the amounts, schedule, and labels are immutable once the vesting stream is initialized. Only the destination address for a vesting allocation can change later, and even that follows a timelocked path controlled by the launch issuer. The fee schedule that applies to a launch is immutable at creation based on the chain's active schedule. Factory-level defaults can change for future launches, but a live launch's fee setup stays as it was at creation. ## What can still change after launch Some addresses can change even though the economic split itself does not. Within `FeeDistributor`, issuer fee recipient addresses can be changed by the current recipient for that slot, and the referrer address can be changed by the current referrer. Those changes follow the typed address-change flow rather than a general owner-only admin path. Within `IntegratorFeeCollector`, each integrator address can be changed by the current holder of that position through a 14-day timelocked path. The change rejects a zero address and any address already held by another integrator. Within `VestingStream`, the launch issuer can change a vesting recipient address, but not the vesting amounts or schedule. When that change executes, any vested but unclaimed tokens for the outgoing address are automatically claimed before the new address takes over. The issuer can also permanently burn the ability to change a specific recipient. At the protocol layer, `LaunchFactory` can change future-launch defaults such as the BMX burn amount, launch thresholds, durations, fee defaults, presale range, anti-whale parameters, and fee collector through timelocked actions. The integrator BPS is immutable at the factory level; changing it requires a new factory deployment. These are future-launch controls, not live-launch rewrites. ## Timelock model The core timelock pattern uses a 7-day delay and a 7-day expiry window by default. The normal flow is: signal the change, wait through the delay, then execute it during the valid window. If the change is not executed in time, it expires instead of staying open forever. For `LaunchFactory`, only the owner can signal or cancel these admin changes, and anyone can execute them after the delay. The same general pattern applies to `BoardwalkFeeCollector` for its treasury, keeper, voting vault, and collector migration actions. For `FeeDistributor`, the model is narrower. The current recipient controls the signal and cancel step for issuer-recipient changes, and the current referrer controls the signal and cancel step for referrer changes. Anyone can execute the change after the delay. For `VestingStream`, the launch issuer controls recipient-address changes. That same contract also supports burning a specific address-change ability permanently, again through its timelocked path. For `IntegratorFeeCollector`, each position address change uses a 14-day delay. Only the current holder of that position can signal or cancel the change, and anyone can execute after the delay. For `GovernanceVoter`, voting-sensitive actions use a longer 21-day delay rather than the standard 7-day delay. ## Admin function inventory Every admin action in the Boardwalk protocol goes through a timelocked path. The owner signals a change, the protocol enforces a mandatory delay, and then anyone can execute the change during a limited execution window. If the change is not executed before that window closes, it expires. The owner can cancel any signaled action before it executes. The table below is the complete set of admin functions across all Boardwalk contracts. No admin action exists outside this list. | Contract | Action | Delay | Constraints | | :--- | :--- | :--- | :--- | | LaunchFactory | SET_BMX_BURN | 7 d | ≤ 200 BMX; burnable | | LaunchFactory | SET_GRADUATION_EXPRESS / _ADVANCED | 7 d | > 0 | | LaunchFactory | SET_EXPRESS_DURATION | 7 d | > 0 | | LaunchFactory | SET_ADVANCED_DURATION | 7 d | 2–14 days | | LaunchFactory | SET_FEE_DEFAULTS | 7 d | Issuer 10–80, Boardwalk 10–50, Incentive ≤ 50, Referrer ≤ 10 and ≤ boardwalk; tunes the four mutable buckets only (integrator BPS is immutable); new total must equal issuer + boardwalk + incentive + integrator BPS; future launches only | | LaunchFactory | SET_PRESALE_RANGE | 7 d | 500–5000 BPS, divisible by 500 | | LaunchFactory | SET_ANTI_WHALE | 7 d | Tax 500–4000 BPS, duration 5–90 min; future launches only | | LaunchFactory | SET_FEE_COLLECTOR | 7 d | Non-zero address, distinct from integrator collector and BoardwalkLPManager; future launches only | | LaunchFactory | SET_NFT_COLLECTION | 7 d | address(0) disables membership discounts | | LaunchFactory | SET_MEMBER_LAUNCH_DISCOUNT | 7 d | ≤ 10000 BPS | | BoardwalkFeeCollector | SET_TREASURY / SET_KEEPER | 7 d | Non-zero address | | BoardwalkFeeCollector | SET_GOVERNANCE_VAULT | 7 d | May be zero (disables voting split) | | BoardwalkFeeCollector | MIGRATE_COLLECTOR | 7 d | Non-zero new collector; both new collector and distributor list committed in signal hash | | BoostBurn | SET_BMX_COST | 7 d | 0–1 BMX | | BoostBurn | SET_NFT_COLLECTION / SET_MEMBER_BOOST_DISCOUNT | 7 d | Same constraints as LaunchFactory equivalents | | FeeDistributor | CHANGE_ISSUER(idx) / CHANGE_REFERRER | 7 d | Self-signal by current recipient; non-zero address at execute; not burnable | | IntegratorFeeCollector | CHANGE_ADDRESS(slotIdx) | 14 d | Self-signal by current slot holder; non-zero address at execute; rejects addresses already held by another slot; not burnable | | VestingStream | CHANGE_RECIPIENT(idx) | 7 d | Issuer-signal; non-zero; auto-claims for outgoing recipient; per-allocation burnable | | GovernanceVoter | SET_TREASURY / SET_KEEPER | 7 d | Non-zero address | | GovernanceVoter | SET_GOVERNANCE_BURN | 21 d | 0–1 BMX | | GovernanceVoter | SET_FALLBACK_TREASURY | 21 d | Non-zero address; setter itself is burnable | | GovernanceVoter | SET_FEE_COLLECTOR | 7 d | Non-zero address; paired with BoardwalkFeeCollector MIGRATE_COLLECTOR | ### Permanent burn pattern Any owner-controlled action in the table above can be permanently disabled through the burn-action flow. The owner signals a burn for a specific action, waits through the same delay that action normally requires, and then executes the burn. Once burned, that action can never be signaled, executed, or unburned. This is a one-way, irreversible lockdown of a specific admin capability. The burn pattern means the protocol's admin surface can only shrink over time, never grow. A chain evaluating Boardwalk can verify onchain which actions have already been burned for a given deployment. ## Contracts with no admin surface The following contracts have zero admin functions after initialization. There is no owner, no timelocked path, and no way to change their behavior once they are live. | Contract | Notes | | :--- | :--- | | BoardwalkToken | No owner. Only mutation after init is fee-collector swap during migration, callable only by FeeDistributor. | | LPStaking | Fully immutable after initialization. Zero admin functions. | | PresaleManager | No ongoing admin. One-time vesting config set by factory during creation. | | BoardwalkLPManager | Immutable after deployment. Raise-token restriction is hardcoded. | | LPLocker | No admin functions. Holds LP NFTs permanently. | | ParticipationDistributor | No admin functions. Pull-based claims only. | ## Maximum impact of a compromised owner key This section describes the worst-case scenario if the owner key for the protocol's singleton contracts (`LaunchFactory`, `BoardwalkFeeCollector`, `BoostBurn`, `GovernanceVoter`) were compromised. Because all admin actions are timelocked and publicly observable onchain, the window between signal and execution gives the community time to detect and respond to a malicious change. ### What a compromised key could do **Change future-launch defaults (7-day delay).** An attacker could signal new fee splits, graduation thresholds, presale ranges, or durations for launches that have not yet been created. These changes would not affect any launch already live. The 7-day delay means the signal is visible onchain before it can execute. **Redirect treasury or keeper addresses (7-day delay).** On `BoardwalkFeeCollector` and `GovernanceVoter`, the attacker could signal a new treasury or keeper address. Again, the 7-day public delay applies. **Migrate the fee collector (7-day delay).** The attacker could signal a collector migration. However, the signal hash commits both the new collector address and the full list of `FeeDistributor`s that will be updated, preventing partial or mismatched execution. **Change voting parameters (21-day delay).** On `GovernanceVoter`, voting-sensitive actions such as the per-vote BMX burn amount and the fallback treasury address require a 21-day delay, providing a longer detection window. ### What a compromised key cannot do **Rewrite a live launch's economics.** Fee splits, fee rates, vesting schedules, and token allocations are frozen at the per-launch contract level when a launch is created. Factory-level defaults only affect future launches. **Mint tokens.** Only `PresaleManager` can call the token's mint function, and total supply is enforced inside the mint. There is no open mint path for any admin. **Recover locked liquidity.** LP tokens are burned to the dead address at seed time. There is no recovery path. **Bypass the transfer fee.** The fee-exempt address set is fixed at token initialization. The only post-init change is the fee-collector swap during a migration, which itself is timelocked. **Drain user funds from staking or vesting.** `LPStaking`, `VestingStream`, `PresaleManager`, `LPLocker`, and `ParticipationDistributor` have no admin functions. User funds in these contracts are governed entirely by their fixed logic. **Execute any change without public onchain notice.** Every admin action emits an event at signal time. There is no path to execute an admin change in a single transaction. ## Token supply and mint authority Every token launched through Boardwalk has a fixed total supply of 10,000,000,000 (10 billion) tokens. The only contract with mint authority is the launch's `PresaleManager`, and the mint function enforces the total supply cap internally. After the initial mint at liquidity-seeding time, no further tokens can ever be created for that launch. There is no admin-controlled mint, no inflation schedule, and no way to increase supply after deployment. ## Upgradeability Boardwalk does not use an upgradeable proxy pattern. Per-launch contracts are EIP-1167 minimal proxy clones that delegate to shared implementation contracts. The implementation addresses are set at `LaunchFactory` deployment and are immutable. There is no mechanism to point a deployed clone at a new implementation. The only structural migration path in the system is the fee-collector rotation on `BoardwalkFeeCollector`. This allows the protocol to swap to a new fee collector contract, but the migration is timelocked (7-day delay) and the signal hash commits both the new collector address and the full list of `FeeDistributor`s that will be updated. This prevents partial execution or a mismatch between what was signaled and what runs. Singleton contracts (`LaunchFactory`, `BoardwalkLPManager`, `BoardwalkFeeCollector`, `BoostBurn`, `GovernanceVoter`, `LPLocker`, `ParticipationDistributor`) are standard deployed contracts, not proxies. Replacing a singleton requires deploying a new instance and, where applicable, using the timelocked admin paths to point existing references at the new address. ## External dependencies Boardwalk relies on a small number of external contracts. All external addresses are set at deployment and are either immutable or changeable only through timelocked admin actions. | Dependency | Used by | Mutability | | :--- | :--- | :--- | | Uniswap v2 factory + router (or v4 on Base) | LaunchFactory, BoardwalkLPManager, FeeDistributor, BoardwalkFeeCollector | Immutable at deploy (set in constructor) | | Raise token (WETH, frxUSD, etc.) | PresaleManager, FeeDistributor, BoardwalkFeeCollector | Immutable per chain (set at factory deploy) | | sbfBMX / Morphex staking contracts | GovernanceVoter (Base only) | Read-only; addresses set at deploy | | Burn address (`0x…dEaD`) | Token burns, LP lock | Hardcoded constant | **No price oracle.** Boardwalk does not use a price oracle at any point. The graduation threshold for auctions is denominated in raise-token units, not USD. This removes oracle risk entirely but means the USD-equivalent threshold moves with the raise token's market price. ## Fee-exempt trust boundary Each launched token has a base set of six fee-exempt addresses (up to seven on chains with an integrator recipient), set at initialization. These addresses are immediate counterparties in the fee-routing flow and bypass the transfer fee for tokens moving through them. The exempt set cannot be expanded after initialization. The only post-init change is the fee-collector address swap during a collector migration, which replaces one exempt address with another through the timelocked migration path. The full exempt set for each launch is: | Exempt contract | Reason for exemption | | :--- | :--- | | FeeDistributor | Receives the transfer fee; exemption prevents recursive fee on the callback path | | PresaleManager | Mints initial supply; presale claims after cliff are fee-free | | VestingStream | Vesting claims are fee-free | | LPStaking | Reward distribution and fee inflows are fee-free | | BoardwalkLPManager | Fee-exempt LP add/remove wrapper | | BoardwalkFeeCollector | Keeper batch-swaps to raise token are fee-free | | IntegratorFeeCollector | Receives integrator allocation; exemption prevents fee on the push path (present only on chains with a non-zero integrator BPS) | A compromise of any exempt contract would allow an attacker to route tokens through it without paying the transfer fee. The structural defense against using exempt contracts as general-purpose transfer tunnels is the `BoardwalkLPManager`'s raise-token restriction, which limits its add/remove liquidity functions to pairs that include the chain's raise token. ## Keeper and liveness fallbacks Several Boardwalk operations depend on an external caller (a keeper or the owner) to trigger them on schedule. In every case, the protocol includes a fallback path so that no user funds are permanently stuck if the expected caller stops operating. | Scenario | What happens | Fallback | | :--- | :--- | :--- | | Keeper stops calling fee swaps | Tokens accumulate in BoardwalkFeeCollector; no loss of funds | Any keeper-role address can resume; keeper address changeable via timelock | | Nobody seeds liquidity after auction | `seedLiquidity()` is permissionless after the 1-hour delay | Any address can call it | | Voting epoch not finalized or executed | Funds sit in GovernanceVoter vault | `forceMarkExecuted()` callable by anyone after 14 days; routes to fallback treasury | | FeeDistributor downstream forward fails | Failed allocation accumulates in pending balances; transfers are never reverted | `retryPendingFees()` is permissionless | | Issuer never claims fee allocation | Unclaimed balance accrues in FeeDistributor | No protocol-side impact; issuer's loss only | The general design principle is that keeper unavailability causes delays, not fund loss. In most cases, the relevant function is either permissionless from the start or becomes permissionless after a grace period. ## Audit status Boardwalk is currently in audit with Sherlock.