# Boardwalk — Full Product Documentation _Single-file dump of the entire Boardwalk docs site._ _Generated on 2026-08-17T19:13:44.250Z — for use as LLM context._ _Live docs: https://www.useboardwalk.com/docs_ # Welcome to Boardwalk *Docs are subject to change. Last updated: July 17, 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 BWLK 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 Standard 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 (0.40%). 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? **BWLK Stakers** — Each epoch, eligible stakers vote on where designated protocol fees should be routed. BWLK stakers also accrue Voter Points, which increase at a 100% annual accrual rate, giving stakers who stake longer a larger voting weight. ``` Voter Points + Total BWLK staked = Total Fee-Direction Weight ``` --- # Define and Launch a Token Economy ## Choose the launch path **Standard** is the flexible path. It uses a 2-day auction, supports an auction allocation between 25% and 50% (in 5% steps), allows one to four issuer fee recipients, can include a referrer, and supports vesting. When the auction 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 auction 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. Standard uses a 2-day auction and 24-hour start delay. The graduation threshold is currently 2.5 ETH or the chain-specific raise token approximate equivalent (e.g. WETH on Base). 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 a Standard 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. A Standard launch with a 30% for auction would split: 30% auction, 30% liquidity, 8% LP incentives, 32% issuer-directed vesting. For example, a Standard launch sets 35% for auction which results in 35% for pairing into permanent liquidity. The 30% remaining; 6% is directed to LP incentives (20% of the remaining), leaving the issuer with 24% to direct to chosen recipients. ![Express vs Standard 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 Standard 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 Standard-only. When the auction allocation is below 50%, vesting is required. Standard 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. ## Who Can Change an Address After a Launch A launch locks its economics when the issuer creates it. Fee percentages, vesting amounts, and vesting schedules stay fixed for the life of the token. Addresses are the one exception. Each address has exactly one owner who can move it, and every move runs on a timer. | Address | Who can change it | Waiting period | Can be made permanent | | ------- | ----------------- | ------------- | --------------------- | | Fee recipient (each address on the Fee-Direction step) | The person or team at that address. Each holder controls only their own address. | 7 days | No | | Referrer | The referrer | 7 days | No | | Vesting recipient | The issuer | 7 days | Yes, one allocation at a time | | Integrator | The integrator at that address | 14 days | No | ### How a change works Every address change runs the same three steps. The owner signals the change. The waiting period runs. Anyone can then execute the change during the seven days that follow. If nobody executes it in that window, the change expires and the address stays as it is. The owner can cancel a signaled change any time before it executes. ### What happens when a change executes **Fee recipients.** Fees keep flowing to the old address until the change executes. **Vesting recipients.** The change claims any vested tokens the outgoing address has not taken yet, then hands the allocation to the new address. **Integrators.** The new address cannot be empty, and it cannot be an address another integrator already holds. ### What the issuer cannot do The issuer sets every fee address and every split when they create the launch. After the launch goes live, the issuer cannot change a fee address. Only the person or team at that address can change it. This matters when an issuer sends fees to a partner, a public good, or a growth team on the Fee-Direction step. That routing becomes a commitment the issuer cannot reverse later. One case looks like an exception and is not. An issuer who lists their own wallet can change that address, because they hold the address, not because they launched the token. Vesting is the one place where the issuer keeps address control. ## BWLK burn to launch Currently it requires burning 100 BWLK 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. See the [Disclosures](/docs/disclosures) for the full disclosures.* ## What contributors deposit The deposit is the raise token for that chain, not the new token being launched. Think wETH on Ethereum, 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 2-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 2 days on Standard 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 Uniswap v2 pool, 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, a Standard 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 weighted wETH / 100 weighted 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. Boardwalk-launched tokens trade in Uniswap v2 pools, and a trader pays 1.25% all-in. Boardwalk applies this same canonical structure across Ethereum, Base, Arbitrum, and Robinhood Chain. The fee routes value to the destinations in the schedule below: issuer recipients, Boardwalk, LP participants, the security and research recipients, and, on Standard launches, a referrer. ## 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 (see the [Disclosures](/docs/disclosures) for the full risk disclosure). ## Where liquidity lives When users add or remove liquidity through Boardwalk, the token's built-in fee does not apply. This liquidity lives in Uniswap v2 pools paired with the chain's raise token. The fee exemption only applies to liquidity added or removed 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 Boardwalk applies one canonical fee schedule across Ethereum, Base, Arbitrum, and Robinhood Chain. Every launch uses the same percentages. Express and Standard differ only in the referrer allocation and the matching Boardwalk share. ![Boardwalk fee schedule](/images/docs/fee_schedule.png) | Recipient | Fee | Claimed in | Who controls recipient-address changes | | :--- | :--- | :--- | :--- | | Issuer-designated | 0.35% | WETH | Each fee recipient through a 7-day timelock | | Referrer | Express: 0% / Standard: 0.05% | Issued token | Referrer through a 7-day timelock | | Boardwalk | Express: 0.35% / Standard: 0.30% | WETH | Boardwalk through a 7-day timelock | | LP participants | 0.40% | Issued-token LP token | Immutable; cannot be modified | | Uniswap Protocol | 0.05% | LP tokens | Controlled by Uniswap governance | | Sherlock | 0.02% | WETH | Sherlock through a 14-day timelock | | DefiLlama Research | 0.02% | WETH | DefiLlama Research through a 14-day timelock | | 0x | 0.02% | WETH | 0x through a 14-day timelock | | Security Alliance (SEAL)\* | 0.02% | WETH | SEAL through a 14-day timelock | | DeFi Llama\* | 0.02% | WETH | DeFi Llama through a 14-day timelock | | Total trading fee | 1.25% | | | \*Donation to public goods. Listed integrators have confirmed designated fee-recipient addresses; inclusion does not constitute an endorsement of Boardwalk, any issuer, or any token. Express launches carry no referrer allocation. On Standard launches, if a referrer is not set, the 0.05% referrer share defaults to Boardwalk. The percentages above are fixed at launch and hold for the life of each token. Only the eligible destination addresses can change, and only under the timelocked rules described in the [Technical Appendix](/docs/technical). *Disclaimer: future chains may carry different fee schedules.* ## 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 a Standard 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 (0.40%). 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) --- # BWLK, Staking, and Voting BWLK is Boardwalk's protocol token. BWLK 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. ## Fee-Direction Weight A staker's weight to vote-direct designated fees is called Fee-Direction Weight. It equals staked BWLK plus Voter Points. ``` Fee-Direction Weight = Staked BWLK + Voter Points ``` **Staked BWLK** is the base of voting weight. **Voter Points** build at a 100% annual accrual rate while BWLK 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 BWLK staked + 2,820 Voter Points = 14,820 Fee-Direction Weight ``` ## How voting works Voting happens in weekly epochs. During each epoch, BWLK 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 **Route to Operations Reserve** — The fee budget transfers to the protocol Operations Reserve in the raise token. **BWLK Buy & Burn** — The fee budget buys BWLK from the market and sends it to the burn address. Once burned, that BWLK cannot be recovered. **Perma-Lock BWLK/ETH** — The fee budget is split in half. One half is swapped into BWLK. The two halves are paired into a BWLK/ETH liquidity position that is permanently locked. Trading fees from that position flow to the Operations Reserve over time. **Route to BWLK Stakers** — The fee budget buys BWLK, 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 BWLK. A staker with 1,000 BWLK staked needs at least 15 Voter Points. ## Quorum Boardwalk uses a 51% quorum — total Fee-Direction Weight 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) ## BWLK Tokenomics BWLK is Boardwalk's protocol token. It functions as both a utility token and a consumption token across all chain deployments. **Supply.** BWLK was deployed with an initial supply of 3,150,000 BWLK. The BWLK token contract has no minter and no post-deployment supply-increase function, which means no one — including the Boardwalk team — can create new BWLK. Supply can only decrease over time through burns. Reference the [Migration Announcement](https://x.com/useboardwalk/status/2077232979882221707) for the BWLK supply allocation. **Deflationary by design.** Several protocol actions permanently remove BWLK from supply by sending it to the burn address (`0x000000000000000000000000000000000000dEaD`). Tokens sent to this address cannot be recovered or re-issued. BWLK burns when users perform specific onchain actions. Launching a token economy on Boardwalk burns a protocol-defined amount of BWLK from the issuer. Using Upvote or Downvote to signal on a token or auction burns BWLK 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 (BWLK Buy & Burn) uses designated fees to purchase BWLK 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 BWLK and staking BWLK are different roles. Holders keep BWLK 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 Fee-Direction Weight works and how vote direction operates, see the sections above. BWLK staking, Voter Points, and Fee Direction operate on Ethereum. BWLK is bridgeable to other supported Boardwalk deployments through official Chainlink CCIP routes but must be on Ethereum to stake, accrue Voter Points, and vote-direct designated fees. _Note: BWLK stakers direct a designated portion of Boardwalk's fees through onchain rules — this does not imply broad control over every part of the protocol. See the [Disclosures](/docs/disclosures) for the full statement of BWLK rights, fee-direction limits, and the Operations Reserve._ ## Primary BWLK Liquidity Primary BWLK liquidity is on Ethereum. Reference the [Migration Announcement](https://x.com/useboardwalk/status/2077232979882221707) for the verified BWLK contract address and liquidity details. ## 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 BWLK 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. ### BWLK Staking Shows current staked BWLK, pending BWLK 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. --- # Launch Visibility Playbook A practical checklist for communication, discovery platforms, listings, and post-graduation tasks. ## Visibility starts with consistency Repetition is key. Ensure you have a source of truth for information about your launch. | Item | Guidance | | :---- | :---- | | **Project name and ticker** | Use the exact spelling and capitalization everywhere. | | **Slogan or tagline** | One sentence about the token or project. | | **Full description** | Approximately 250-500 words describing what you're working on. | | **Token logo** | A high-quality square PNG with a transparent background. | | **Your website** | Display the official contract, social accounts, and project description. | | **Contract address** | Copy directly from the Boardwalk profile or chain explorer. | | **Social links** | X, Telegram, Discord, Café Boardwalk, GitHub, and docs where applicable. | | **Supply information** | Total supply, circulating methodology, vesting allocations, and supporting links. | ## As soon as your launch is created 1. Pin official information about your launch to all your social channels. 2. Mobilize your community to help your token graduate. Spread the word! 3. Be available to answer community questions. 4. Monitor your chats for impersonators and fraudulent actors. Scammers are rampant on social media, especially Telegram. ## Communicate during the auction **Give people a reason to care.** Explain why the token exists. **Get people to understand.** The auction schedule and current progress. **Share what comes next.** What happens after the auction ends, such as the [claim cliff](/docs/auction#when-tokens-become-claimable) and LP incentives. ## Immediately after graduation (live trading) Begin submitting information to platforms where people are looking for new launches. ### Update token information on GeckoTerminal GeckoTerminal automatically lists your token once its liquidity pool is seeded on Uniswap. However, the token's information, such as the description and logo, must be updated manually. - [Follow the official GeckoTerminal token-information guidance](https://support.coingecko.com/hc/en-us/articles/22612245806745-How-do-I-update-token-information-on-GeckoTerminal) ### Verify the token on DEX Screener DEX Screener also indexes your token automatically once its liquidity pool is seeded on Uniswap and the first trade lands. Basic listing is free and needs no application. Like GeckoTerminal, the token's displayed information must be updated manually. On DEX Screener this goes through "Enhanced Token Info", an optional paid service. - [Follow the DEX Screener token-listing guidance](https://docs.dexscreener.com/token-listing) DEX Screener also offers optional Boosts. These may increase visibility temporarily, but they do not guarantee that a token will trend. - [DEX Screener Boosts guidance](https://docs.dexscreener.com/boosting) ### List your token on CoinGecko Seeding a pool gets it tracked on GeckoTerminal, but it does not create a CoinGecko listing. A standard listing requires submitting a request and active trading on a tracked exchange. - [CoinGecko listing guidance](https://support.coingecko.com/hc/en-us/articles/33084534107289-Guide-to-the-CoinGecko-Self-Serve-Request-Form) - [CoinGecko listing request form](https://partner.coingecko.com/request-form/new) The public verification process involves: 1. Publish a verification post from an official social account linked by the project website. 2. State that the project is submitting a CoinGecko request. 3. Include the GeckoTerminal link where applicable. 4. Submit the listing form on CoinGecko with a link to your verification post on X. 5. You'll receive a request ID from CoinGecko. Reply to your original X post with that ID as a comment. Submitting a request is free, but it may be rejected if trading volume is below CoinGecko's requirements. For faster turnaround, CoinGecko offers Fast Pass, a paid expedited review that does not guarantee approval. - [CoinGecko Fast Pass](https://support.coingecko.com/hc/en-us/articles/37529551769497-How-to-Purchase-CoinGecko-Fast-Pass) ## First-week operating checklist ### First 24 hours of trading - Publish an official trading announcement and pin it to your socials - Explain the [90-minute anti-sniper window](/docs/post-launch#the-anti-sniper-window) - Update GeckoTerminal - Update the DEX Screener page - Ensure your launch contributors know when their [claim cliff](/docs/auction#when-tokens-become-claimable) ends - Continue answering questions ### Days 2-6 of trading - Submit active CoinGecko and CoinMarketCap applications - Share development, community, or product updates - Prepare contributor claim instructions - Monitor fake accounts, pools, and contract addresses ### Day 7 of trading - Once the 7-day claim cliff ends (exactly seven days after liquidity was seeded), publish an announcement that contributors may begin claiming their tokens on Boardwalk - Remind contributors to use the wallet that joined the auction - If applicable, confirm vesting recipients can view their schedules ## Launching is only the start The strongest token economies continue communicating after the auction, keep their information consistent, answer questions publicly, and give users reliable places to verify every important link. Third-party listing and promotional services are optional, independently operated, and subject to their own review standards. Paying for an expedited review or profile product does not guarantee listing approval, trading activity, visibility, or any particular market outcome. Always beware of scammers, and do not immediately trust anyone claiming to provide services on social media. --- # 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 2.5 ETH or the chain-specific raise token approximate equivalent (for example, WETH on Base). 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 Standard?** Express: no start delay, 24-hour auction, 50/50 auction-to-liquidity split, one issuer fee recipient, no referrer, no vesting. Standard: 24-hour start delay, 2-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. Standard launches can include vesting, and Standard launches with an auction below 50% require it. **Do I need BWLK on the chain I am launching on?** Yes. BWLK can be bridged to supported Boardwalk chains through official Chainlink CCIP routes. Reference the [Migration Announcement](https://x.com/useboardwalk/status/2077232979882221707) for bridge details. ## 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 Uniswap v2 pools paired with the chain's raise token. 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 Standard 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.) ## BWLK and Vote Direction of Designated Fees **What are Voter Points?** Points that build over time while BWLK stays staked. Added on top of staked BWLK to form total Fee-Direction Weight. Non-transferable, no monetary value. **What is the difference between holding BWLK and staking BWLK?** 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 BWLK. That ratio builds over time. **What are the four vote options?** Route to Operations Reserve, BWLK Buy & Burn, Perma-Lock BWLK/ETH, and Route to BWLK 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 BWLK 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 BWLK?** Upvote and Downvote use BWLK 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. **Can anyone mint more BWLK?** No. The BWLK token contract has no minter and no supply-increase function, so no one — including Boardwalk — can create new BWLK. Supply only goes down over time as BWLK is burned. See the [Disclosures](/docs/disclosures) for BWLK token properties. **What is the contract address of BWLK on each chain?** The BWLK token contract is deployed on Ethereum, with bridged deployments on supported Boardwalk chains. Reference the [Migration Announcement](https://x.com/useboardwalk/status/2077232979882221707) for verified BWLK contract addresses. ## 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 rest of the schedule is set by the protocol and is the same on every supported chain: Boardwalk, LP participants, the Uniswap protocol, and the security and research recipients. Standard launches can also include a referrer. **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. Standard 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 BWLK to the burn address, permanently removing it from supply. Some Boardwalk actions burn BWLK, 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. ### BWLK Buy & Burn A vote option. The fee budget is used to buy BWLK 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 Fee-Direction Weight. ### 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. ### Designated Fees 90% of the protocol fees Boardwalk collects. The other 10% goes to the Operations Reserve. This 90/10 split applies to Boardwalk's own fee allocation, not to the 1.25% total a trader pays. ### Downvote A community signal that moves a token or auction lower in the default discovery ranking. Using Downvote burns BWLK 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-Direction Weight Fee-Direction Weight is a protocol-calculated metric used only within Boardwalk's designated fee-direction system. It determines how a staker's vote is weighted and, if the "Route to BWLK Stakers" option wins, may affect that eligible staker's pro rata share of the BWLK stream for that epoch. Fee-Direction Weight does not provide governance over Boardwalk, ownership, equity, debt, revenue share, guaranteed yield, redemption rights, or any claim on Boardwalk, the Operations Reserve, or protocol fees. ### Fee Routing The way a launched token's built-in fee is split and sent to the destinations chosen in that launch. That includes issuer recipients, Boardwalk, LP participants, the security and research recipients, and, on Standard launches, a referrer. ### 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 2.5 ETH or the chain-specific raise token approximate 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 BWLK in a wallet but has not staked it. Staking enables eligibility to vote to direct designated fees. ### Integrator A party that integrates Boardwalk and holds a designated address on a launch. An integrator address can be changed by the integrator that holds it, through a 14-day timelock. Integrator claims are paced separately from issuer claims. ### 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 Standard. Express is shorter and simpler. Standard 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 BWLK Stakers) A vote option. The fee budget is used to buy BWLK, 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 BWLK/ETH A vote option. The fee budget is split in half and used to mint a BWLK/ETH 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 non-exempt interaction with the token triggers the fee, so the repeated position adjustments these strategies depend on cost the operator each time, removing the cost advantage that makes them profitable elsewhere. The exemption covers adding and removing liquidity through Boardwalk's standard pools, along with auction claims, vesting claims, and LP staking flows; the exempt set is fixed at initialization (see the [Technical Appendix](/docs/technical)). ### Staker A BWLK 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 a Standard 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 BWLK 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 Uniswap v2 pools of this kind. The fee a trader pays on those swaps is set by the launch fee schedule — see [Post-Launch: Fees & Liquidity](/docs/post-launch). ### 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 BWLK stays staked. They are added on top of staked BWLK to form total Fee-Direction Weight. 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 BWLK. ### 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 BWLK 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. 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 BWLK/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 BWLK streams that fund the Route to BWLK Stakers vote option for eligible voters from the prior epoch. **`BoostBurn`** handles the BWLK 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 BWLK 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: a change is signaled, the protocol enforces a mandatory delay, and then anyone can execute it during a limited execution window. If the change is not executed before that window closes, it expires. Owner-controlled actions are signaled and cancelled by the owner. The address-change actions lower in the table are signaled and cancelled by the current recipient, slot holder, or issuer instead, as noted in their constraints. 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_BWLK_BURN | 7 d | ≤ 200 BWLK; 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); a non-zero vault must report the chain's raise token as its WETH | | BoardwalkFeeCollector | MIGRATE_COLLECTOR | 7 d | Non-zero new collector; both new collector and distributor list committed in signal hash | | BoostBurn | SET_BWLK_COST | 7 d | 0–1 BWLK | | 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 BWLK | | 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 BWLK 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 Ethereum) | LaunchFactory, BoardwalkLPManager, FeeDistributor, BoardwalkFeeCollector | Immutable at deploy (set in constructor) | | Raise token (WETH, etc.) | PresaleManager, FeeDistributor, BoardwalkFeeCollector | Immutable per chain (set at factory deploy) | | sbfBWLK / bnBWLK staking trackers | GovernanceVoter (Ethereum 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. ## Audits Boardwalk is audited with Sherlock. See the [Audits](/docs/audits) page for the reports. --- # Audits Boardwalk's smart contracts are audited with Sherlock. Reports are linked below as published. - **Sherlock** — Core Protocol — May 2026: [report PDF](https://www.useboardwalk.com/audits/Boardwalk-Sherlock-Audit-May-2026.pdf) - **Sherlock** — BWLK migration and CCA — July 2026: [report PDF](https://sherlock-files.ams3.digitaloceanspaces.com/reports/2026.07.09%20-%20Final%20-%20Boardwalk%20Collaborative%20Audit%20Report%201783557446.pdf) --- # Agent Skill, SDK & CLI Boardwalk ships an executable layer alongside these docs. The Boardwalk agent skill, the `@useboardwalk/sdk` package, and its `boardwalk` CLI let a model — or any app — launch a token, contribute to an auction, claim, stake, and vote. The rest of the docs explain what these actions mean; this page covers how to run them. The SDK and CLI are non-custodial: they never ask for, store, or accept a private key. They produce **unsigned** transaction calldata (and, for launch metadata, an EIP-712 payload to sign). Your own wallet signs and submits — the same trust boundary as the rest of Boardwalk. ## Install `@useboardwalk/sdk` is a framework-agnostic TypeScript package. Use it as a library, install the CLI globally, or run the CLI with no install: ```bash npm install @useboardwalk/sdk # use as a library npm install -g @useboardwalk/sdk # install the boardwalk CLI npx -p @useboardwalk/sdk boardwalk # run the CLI, no install ``` Requires Node 18 or newer. Run `boardwalk --help`, or `boardwalk --help`, for the flags on any command. ## The CLI The `boardwalk` CLI turns a request into calldata without writing code. Every transaction command prints an ordered `calls` array; when an ERC-20 approval is needed it comes first, so the whole batch submits in one approval. Read commands print plain JSON. The commands, grouped by what they do: - **Launch** — `launch`, `launch-metadata`, `submit-metadata`, and `launch-link` (a prefilled URL for surfaces with no terminal) - **Auction** — `contribute`, `claim`, `refund`, `seed-liquidity` - **BWLK staking** — `stake-bwlk`, `unstake-bwlk`, `handle-rewards` - **Fees & vesting** — `claim-issuer-fees`, `claim-referrer-fees`, `claim-integrator-fees`, `claim-vested`, `claim-participation` - **Liquidity & trading** — `add-liquidity`, `remove-liquidity`, `stake-lp`, `unstake-lp`, `claim-lp-rewards`, `swap` - **Vote direction & visibility** — `vote`, `cast-visibility` - **Reads** — `status`, `launch-cost` `launch`, `contribute`, and `claim` run on Ethereum, Base, Arbitrum, and Robinhood Chain. Ethereum is the governance, staking, and revenue home, so BWLK staking, reward handling, participation claims, and voting are Ethereum-only; revenue collected on the other chains is bridged there weekly. Transactions built on Base carry Boardwalk's [ERC-8021](https://docs.base.org/base-chain/builder-codes) builder code in their calldata, so onchain volume is attributed even when an agent submits it. ## The SDK Under the CLI is the same set of builders, exported for direct use. Each builder takes a viem client, reads what it needs onchain (allowances, burn cost, launch state), and returns ready-to-submit `{ to, data, value, chainId }` calldata for your wallet to sign. The full command reference, code examples, and exported functions live in the repo: - GitHub — [useboardwalk/boardwalk-sdk](https://github.com/useboardwalk/boardwalk-sdk) - npm — [@useboardwalk/sdk](https://www.npmjs.com/package/@useboardwalk/sdk) ## Agent skill The package also ships a Boardwalk agent skill that tells an agent when and how to drive the CLI: which command to use, what to check before calling it, and how to submit the calldata safely. For Cursor, Codex, Gemini CLI, or anything that supports the [Agent Skills](https://agentskills.io) format, install it with one command: ```bash npx skills add useboardwalk/boardwalk-sdk ``` In Claude Code, install it as a plugin instead: ```bash /plugin marketplace add useboardwalk/boardwalk-sdk /plugin install boardwalk@boardwalk-sdk ``` The skill calls the CLI through `npx`, so there's nothing else to install. --- # Disclosures *Last updated: July 16, 2026.* These disclosures are provided for transparency. They are not legal, tax, financial, or investment advice. Users should review the Boardwalk smart contracts, documentation, and applicable laws before participating. ## BWLK Token Design BWLK is Boardwalk's protocol token. It is designed as a fixed-supply consumption and utility token used for launch creation, community signaling, staking eligibility, and limited participation in Boardwalk's designated fee-direction system. The BWLK token contract is immutable from deployment: it has no owner, no administrator, no minter, no post-deployment supply-increase function, and no upgrade path. No person or entity — including Boardwalk, any Boardwalk team member, the Operations Reserve, BWLK stakers, or any administrator — can mint additional BWLK. BWLK supply can only decrease over time through permanent burns. BWLK is burned when used for certain protocol actions, including token-economy launches, Upvotes, Downvotes, and any vote-directed BWLK Buy & Burn activity. Fee-Direction Weight is a protocol-calculated metric used only within Boardwalk's designated fee-direction system. Fee-Direction Weight does not represent ownership, general governance power, equity, debt, revenue share, guaranteed yield, or any entitlement to receive protocol fees. BWLK may have no value. BWLK markets may be illiquid or volatile. Boardwalk does not guarantee BWLK price, liquidity, trading volume, protocol usage, staking outcomes, fee amounts, fee-direction outcomes, burns, or any other economic result. ## Current Team Member BMX Ownership prior to Migration **Supply ownership:** As of June 15, 2026, 74.92% of BMX supply is held outside current Boardwalk team beneficial ownership. Current Boardwalk team members beneficially own 25.08% of total BMX supply, including 10.47% from team allocations and 14.61% acquired independently. **Staked BMX:** Non-team participants control 65.0% of staked BMX. Current Boardwalk team members control 35.0% of staked BMX. **Fee-Direction Weight:** Non-team participants control 56.33% of Fee-Direction Weight. Current Boardwalk team members control 43.67% of Fee-Direction Weight. **Token immutability:** BMX has no emissions. Contract ownership is renounced. Owner/admin functions, including transfer functions, are permanently disabled and cannot be restored. No additional BMX can be minted, and supply can only decrease through burns. **Fee-direction limits:** Fee-Direction Weight is limited to Boardwalk's designated fee-direction system. BMX is not equity, debt, revenue share, guaranteed yield, or a claim on Boardwalk or the Operations Reserve. For the purposes of this disclosure, "current Boardwalk team members" means individuals currently providing material services to Boardwalk in a co-founder, core contributor, or similar active operating role. "Beneficial ownership" includes BMX held directly, through wallets, accounts, or entities controlled by a current Boardwalk team member, or BMX over which a current Boardwalk team member has voting or dispositive control. Personally acquired BMX is included in the aggregate figures above. BMX held by the Operations Reserve is excluded. Percentages are approximate and based on team self-certifications and onchain protocol data as of the snapshot date. The figures in this section are provided as of the stated date only. They may change over time due to transfers, burns, staking, unstaking, secondary-market purchases or sales, changes in Voter Points, changes in Fee-Direction Weight, and other onchain activity. Unless expressly stated otherwise, these figures are unaudited and are based on good-faith review of known wallets, disclosed team-controlled wallets, and available onchain information. Boardwalk may update this disclosure periodically, but does not guarantee that the figures shown are current at all times. Users should review onchain data and should not rely on this disclosure as a real-time statement of BMX ownership, staking participation, liquidity, or Fee-Direction Weight. Nothing here is legal, financial, tax, or investment advice, and nothing here is a recommendation to buy, sell, stake, or hold any token. ## BWLK Rights, Entitlements, and Fee-Direction Limits **Fee-Direction Weight is limited in scope.** Fee-Direction Weight is a protocol-calculated metric used only within Boardwalk's designated fee-direction system. It may determine how an eligible staker's vote is weighted and, if the Route to BWLK Stakers option wins for an applicable epoch, may affect that eligible staker's pro rata share of the BWLK stream for that epoch. BWLK holders and stakers may vote only to direct a designated portion of Boardwalk protocol fees made available to the fee-direction system by the applicable onchain contracts. Fee-Direction Weight does not provide general governance over Boardwalk. BWLK holders and stakers do not own Boardwalk, do not control the Operations Reserve, do not hold equity or debt in any Boardwalk-related entity, and do not have any claim on Boardwalk assets, Operations Reserve assets, protocol treasury assets, or liquidation proceeds. BWLK does not provide holders with any right to dividends, profit distributions, revenue shares, guaranteed yield, guaranteed rewards, redemption rights, repurchase rights, or any entitlement to receive protocol fees. Any BWLK or other value received through staking, fee-direction participation, burns, fee routing, or other protocol activity may be low, zero, intermittent, or dependent on protocol usage, market conditions, fee-direction outcomes, contract execution, eligibility, and other risks. BWLK holders and stakers cannot use Fee-Direction Weight to upgrade Boardwalk contracts, mint BWLK, mint tokens launched through Boardwalk, recover locked liquidity, change live token-economy fee percentages, change live token-economy vesting schedules, control issuer fee recipients, control the Operations Reserve, or direct the assets of any Boardwalk-related entity. No person or entity has any obligation to repurchase BWLK, support a BWLK market, maintain BWLK liquidity, stabilize BWLK price, or make any market in BWLK. ## Operations Reserve The Operations Reserve is separate from BWLK holders and BWLK stakers. BWLK holders and stakers do not own, control, or have any entitlement to the Operations Reserve. Fees routed to the Operations Reserve are compensation to the applicable builder, operator, or service provider entity for building, supporting, maintaining, or otherwise contributing to Boardwalk. The Operations Reserve may be used for operations, development, audits, infrastructure, legal, security, grants, integrations, ecosystem support, or other Boardwalk-related purposes, in each case as determined by the applicable controlling entity and not by BWLK holders. BWLK staking and Fee-Direction Weight do not create any claim on the Operations Reserve. ## BWLK Token Immutability The BWLK token contract is immutable from deployment. It has no owner, no administrator, no minter, no post-deployment supply-increase function, and no upgrade path. No person or entity — including Boardwalk, any Boardwalk team member, the Operations Reserve, or any administrator — can mint additional BWLK or alter its token-level permissions. BWLK supply can only decrease through permanent burns. BWLK begins with a purpose-built token contract that removes inherited legacy token surface area. It does not carry a legacy handler branch or other privileged token controls found in older token-code patterns. BWLK is a separate protocol-token transition from the legacy BMX token. Reference the [Migration Announcement](https://x.com/useboardwalk/status/2077232979882221707) for the legacy BMX contract's onchain history, including its renunciation of ownership, minter burn, and handler-role status. ## Boardwalk Is Permissionless and Does Not Endorse Launched Tokens Boardwalk is a permissionless protocol. Tokens launched through Boardwalk are created by independent issuers or users, not approved, sponsored, underwritten, verified, recommended, endorsed, or guaranteed by Boardwalk or any Boardwalk team member solely because they appear on, launch through, or are displayed by Boardwalk. Any issuer-provided descriptions, videos, links, social posts, fee-recipient labels, vesting information, growth-team information, public-good information, or other launch materials are provided by or on behalf of the applicable issuer, not by Boardwalk, unless expressly stated otherwise. Boardwalk does not guarantee the accuracy, completeness, legality, quality, safety, value, liquidity, market performance, graduation, continued operation, issuer conduct, or regulatory status of any token launched through Boardwalk. A token appearing on Boardwalk is not a Boardwalk rating, recommendation, approval, certification, diligence review, underwriting decision, solicitation, or investment opinion. Users are responsible for conducting their own review before participating in any launch, trading any token, providing liquidity, staking, or otherwise interacting with a token economy. ## Onchain Protocol and Hosted Interface Boardwalk's core protocol runs through permissionless smart contracts. Key protocol actions, including launch creation, auction participation, liquidity seeding, refunds, claims, staking, and fee-related flows, are governed by onchain rules and may be available without use of Boardwalk's hosted interface. The hosted Boardwalk interface, documentation, dashboards, token profile pages, discovery features, and Café Boardwalk are supplementary access, information, and community surfaces. They do not change the rules of deployed smart contracts unless expressly stated. Boardwalk's hosted interface or related services may restrict access, remove content, moderate user-generated materials, or take other interface-level actions where Boardwalk believes it is necessary or appropriate for legal, security, abuse-prevention, intellectual-property, sanctions, or user-protection reasons. These interface-level actions do not imply control over deployed smart contracts unless expressly stated. ## Issuer Responsibility Issuers are solely responsible for the tokens they launch through Boardwalk and for the accuracy, completeness, legality, and regulatory treatment of their launch materials. Issuers are responsible for determining whether their token, launch, auction, fee routing, vesting, disclosures, marketing, use of proceeds, or other activities comply with applicable law. Issuers are also responsible for disclosing material information, including token purpose, issuer identity or pseudonymity, use of raised assets, fee recipients, vesting recipients, related-party relationships, conflicts of interest, market-support plans, and any other information necessary for users to evaluate the launch. Boardwalk does not provide legal, tax, financial, investment, underwriting, broker, dealer, exchange, or compliance advice to issuers or users. ## Risk Disclosure Participation in Boardwalk, BWLK, or tokens launched through Boardwalk involves substantial risk. Risks include, but are not limited to: - total loss of value - failed launches - smart-contract bugs or exploits - volatile or illiquid markets - thin liquidity - slippage - MEV - failed transactions - issuer abandonment - inaccurate or misleading issuer disclosures - social or community manipulation - wash trading - Sybil activity - Upvote or Downvote manipulation - regulatory uncertainty - tax consequences - bridge, wallet, DEX, router, or third-party integration failures - chain congestion, reorgs, outages, or forks - inability to recover lost wallets or private keys Locked liquidity does not mean price stability, guaranteed liquidity, guaranteed exits, or protection from market risk. Staking does not guarantee rewards. Fee-direction participation does not guarantee any economic outcome. ## Market Integrity and Prohibited Conduct Boardwalk does not permit or endorse fraud, wash trading, spoofing, pump-and-dump activity, market manipulation, sanctions evasion, money laundering, terrorist financing, impersonation, misleading issuer disclosures, intellectual-property infringement, scam launches, or other unlawful or abusive activity involving Boardwalk, BWLK, or tokens launched through Boardwalk. Users may report suspected fraud, impersonation, market manipulation, sanctions issues, IP violations, security issues, or misleading launch materials to: [contact@bmx.trade](mailto:contact@bmx.trade). ## Sanctions and Restricted Activity Users are responsible for complying with sanctions laws, export controls, anti-money-laundering laws, counter-terrorist-financing laws, and other laws that apply to them. Boardwalk's hosted interface may restrict access or take other interface-level actions where required or appropriate for legal, sanctions, abuse-prevention, or security reasons. Users may not use Boardwalk's hosted interface to engage in unlawful activity, evade sanctions, conceal illicit proceeds, or facilitate prohibited transactions. ## Third-Party Services Boardwalk may link to or interoperate with third-party wallets, decentralized exchanges, aggregators, bridges, analytics tools, forums, infrastructure providers, or other services. These services are not controlled by Boardwalk unless expressly stated. Boardwalk is not responsible for third-party services, liquidity venues, bridge failures, wallet failures, routing errors, slippage, MEV, failed transactions, smart-contract bugs in third-party systems, inaccurate third-party data, or other risks arising outside Boardwalk-controlled systems. ## Legal and Regulatory Status Nothing in these disclosures is a representation that BWLK, Boardwalk, or any token launched through Boardwalk has any particular status under securities, commodities, banking, money-transmission, tax, consumer-protection, sanctions, or other laws. Legal and regulatory treatment may vary by jurisdiction and may change over time. Users and issuers are responsible for complying with laws that apply to them. ## Tax Disclaimer Using Boardwalk, acquiring BWLK, burning BWLK, staking BWLK, voting, receiving BWLK, participating in auctions, claiming tokens, receiving refunds, providing liquidity, claiming fees, receiving vesting distributions, swapping tokens, or transferring tokens may have tax consequences. Boardwalk does not provide tax advice. Users and issuers should consult their own tax advisors. ## Forward-Looking Statements Any statements about future features, integrations, chains, protocol activity, usage, fees, burns, fee-direction outcomes, ecosystem development, or other future matters are forward-looking and subject to change. Boardwalk does not promise that any roadmap item, integration, feature, chain deployment, protocol activity, fee amount, burn amount, fee-direction outcome, or other future outcome will occur. ## Updates Boardwalk may update these disclosures from time to time. Updated disclosures apply as of the date posted unless stated otherwise. Historical versions may be made available for transparency where feasible. --- # Terms of Service _Last Updated: May 27th, 2026_ ## Important Notice PLEASE READ THESE TERMS OF SERVICE CAREFULLY. BY ACCESSING OR USING THE BOARDWALK INTERFACE, YOU AGREE TO BE BOUND BY THESE TERMS. IF YOU DO NOT AGREE TO ALL OF THESE TERMS, DO NOT ACCESS OR USE THE INTERFACE. THESE TERMS INCLUDE A BINDING ARBITRATION CLAUSE AND A CLASS ACTION WAIVER IN SECTION 20, WHICH AFFECT YOUR LEGAL RIGHTS. PLEASE READ THEM CAREFULLY. ## Risk Warning The Boardwalk Interface provides access to permissionless smart contract protocols deployed on public blockchains. Digital assets, including tokens launched through Boardwalk, are highly volatile and speculative. You may lose some or all of the value of any digital assets you interact with through the Interface. Boardwalk does not provide financial, legal, tax, or investment advice. We do not recommend that any digital asset be acquired, held, or disposed of by any person under any circumstances. You are solely responsible for evaluating whether any interaction with the Interface is appropriate for you based on your own circumstances, financial or otherwise. ## 1. Definitions **“Applicable Law”** means all applicable statutes, regulations, rules, orders, directives, and guidance of any governmental authority, including sanctions laws and regulations administered by the U.S. Department of the Treasury’s Office of Foreign Assets Control (OFAC), the U.K. Office of Financial Sanctions Implementation, the European Union, and the United Nations Security Council. **“Boardwalk”** (also referred to as “we,” “our,” or “us”) means the entity or entities that develop, maintain, and provide access to the Interface. Boardwalk does not control trade execution, governance outcomes, fee routing, or liquidity seeding on the Protocol, and does not operate, control, or administer the tokens launched through the Protocol. **“BWLK”** means the digital asset used for protocol actions and active governance under the current design of the Protocol. **“Digital Asset”** means any digital token, cryptocurrency, or other digital representation of value recorded on a blockchain, including BWLK and tokens launched through the Protocol. **“Interface”** means the web-based application provided by Boardwalk that enables users to interact with the Protocol. The Interface is one means of accessing the Protocol but is not the only means. **“Issuer”** means any person or entity that configures and launches a token through the Protocol. **“Protocol”** means the permissionless, open-source smart contracts deployed on supported public blockchains that comprise the Boardwalk Launchpad system, including all per-launch contracts and shared singleton contracts. The Protocol operates autonomously once deployed and is not operated or controlled by Boardwalk. **“Restricted Jurisdiction”** means any jurisdiction subject to comprehensive sanctions or embargoes, including Cuba, Iran, North Korea, Syria, and the Crimea, Donetsk, and Luhansk regions of Ukraine, and any jurisdiction subsequently designated by applicable sanctions authorities or Boardwalk policy. **“Restricted Person”** means any individual or entity (a) on any sanctions list maintained by OFAC (including the Specially Designated Nationals and Blocked Persons List), the U.K., the EU, or the UN; (b) owned 50% or more by one or more persons described in (a); (c) located in, organized in, resident of, or a citizen of a Restricted Jurisdiction; or (d) acting on behalf of any of the foregoing. **“User,” “you,” or “your”** means any individual or entity that accesses or uses the Interface. **“Wallet”** means a non-custodial blockchain wallet that you connect to the Interface to interact with the Protocol. ## 2. Acceptance of Terms 2.1. These Terms of Service (the “Terms”) constitute a legally binding agreement between you and Boardwalk governing your access to and use of the Interface. By accessing or using the Interface in any way, you acknowledge that you have read, understood, and agree to be bound by these Terms and all documents incorporated by reference. 2.2. If you are accessing or using the Interface on behalf of a legal entity, you represent and warrant that you have the authority to bind that entity to these Terms, and all references to “you” include that entity. 2.3. We may update or amend these Terms at any time by posting revised Terms on the Interface and updating the “Last Updated” date. Your continued use of the Interface after any such revision constitutes your acceptance of the revised Terms. You are responsible for reviewing these Terms periodically. ## 3. The Interface and the Protocol 3.1. The Interface is a user-facing application that allows you to interact with the Protocol. The Interface is distinct from the Protocol. The Protocol comprises self-executing smart contracts deployed on public blockchains. Once deployed, the Protocol operates autonomously according to the logic encoded in those contracts. 3.2. Boardwalk does not control trade execution, token launches, governance votes, fee routing, liquidity seeding, or any other onchain activity that occurs through the Protocol. Boardwalk does not hold custody of, or exercise control over, any Digital Assets at any time. 3.3. The Interface is one, but not the exclusive, means of accessing the Protocol. Users may interact with the Protocol’s smart contracts directly or through third-party interfaces. Boardwalk is not responsible for interactions with the Protocol that occur outside the Interface. 3.4. Boardwalk may, at its sole discretion, modify, suspend, or discontinue the Interface or any portion of it at any time, with or without notice, and without liability to you. ## 4. Eligibility 4.1. To access and use the Interface, you must be at least the age of majority in your jurisdiction and have the legal capacity to enter into a binding agreement. 4.2. By accessing the Interface, you represent and warrant that you are not a Restricted Person and are not located in, organized in, resident of, or accessing the Interface from a Restricted Jurisdiction. 4.3. You represent and warrant that your use of the Interface does not violate any Applicable Law in your jurisdiction, including but not limited to sanctions laws, anti-money laundering laws, and counter-terrorism financing regulations. 4.4. You represent and warrant that you are not acting on behalf of, for the benefit of, or at the direction of a Restricted Person. 4.5. We reserve the right to modify our eligibility criteria at any time and to restrict, suspend, or terminate your access to the Interface at our sole discretion, with or without notice and with or without reason. ## 5. Restricted Jurisdictions and Sanctions Compliance 5.1. The Interface is not available to Restricted Persons or users located in, organized in, resident of, or accessing the Interface from Restricted Jurisdictions. 5.2. Restricted Jurisdictions include, without limitation: Cuba, Iran, North Korea (the Democratic People’s Republic of Korea), Syria, the Crimea region of Ukraine, the Donetsk region of Ukraine, the Luhansk region of Ukraine, and any other jurisdiction designated by OFAC, the U.K., EU, UN, or Boardwalk policy as subject to comprehensive sanctions or embargoes. 5.3. Boardwalk may maintain an expanded risk-based block list that includes additional jurisdictions beyond the minimum set described above. This list is configurable and may be updated without prior notice. 5.4. You may not use a virtual private network (VPN), proxy server, Tor network, geolocation spoofing, burner identities, linked accounts, or any other technical means to circumvent jurisdictional, sanctions, fraud, or platform-integrity controls implemented by the Interface. 5.5. Boardwalk may employ IP geolocation checks and such other technical measures, screening mechanisms, and risk controls as Boardwalk may, in its discretion, implement from time to time to enforce access restrictions. Boardwalk may block, restrict, suspend, or refuse Interface access or transaction preparation where required by Applicable Law, sanctions rules, risk controls, or platform policy. ## 6. Non-Custodial Nature; Wallet Responsibility 6.1. The Interface is non-custodial. Boardwalk does not have custody of, access to, or control over your Wallet, private keys, seed phrases, or Digital Assets at any time. You are solely responsible for securing your Wallet credentials and for all activity that occurs through your connected Wallet. 6.2. If you lose access to your Wallet or your private keys are compromised, Boardwalk cannot recover your Digital Assets or reverse any transactions. You acknowledge that blockchain transactions are irreversible once confirmed. 6.3. You are responsible for ensuring that all instructions you submit through the Interface are complete and accurate. Boardwalk is not required to verify the accuracy, authenticity, or validity of any instruction. ## 7. Description of Services 7.1. The Interface provides access to the following Protocol features, among others: **(a) Token Launches.** The Protocol enables issuers to configure and launch tokens through a permissionless auction system. Tokens launched through the Protocol are user-generated. A token appearing in the Interface is not an approval, endorsement, vetting, or recommendation by Boardwalk. **(b) Auction Participation.** Users may contribute the raise token for a given chain (such as wETH) to active auctions. Contributions are subject to the rules encoded in the Protocol’s smart contracts, as further described in the publicly available product documentation. **(c) Trading.** After a token launches and liquidity is seeded, the token may be available for trading on decentralized exchange pools. Boardwalk does not operate or control these pools. **(d) Liquidity Provision.** Users may stake liquidity into launched token pools. LP participation may involve Participation Points, which are non-transferable and have no monetary value. **(e) BWLK Staking and Vote Direction of Designated Fees.** Users may stake BWLK to participate in periodic vote direction of a designated portion of Protocol fees, as further described in the publicly available product documentation. Staking BWLK produces a non-transferable governance position used for voting. Stakers may accrue additional non-transferable governance points over time, which combine with staked BWLK to form total voting power. Voting eligibility, quorum, voting options, voting periods, cooldown rules, and the handling of votes that do not meet quorum are determined by the rules encoded in the Protocol’s smart contracts and may change from time to time. Vote direction does not confer ownership, equity, or any claim on Protocol fees, reserves, or any other assets. Any allocation directed through vote direction is contingent on Protocol rules, quorum, votes, and future Protocol activity, and may be zero. **(f) Community Signals.** Users may Upvote or Downvote tokens launched through the Protocol. These are community signals, not team ratings, safety reviews, or endorsements. **(g) Café Boardwalk.** A community discussion forum made available in connection with the Interface. User posts on Café Boardwalk are user-generated content and are not reviewed, endorsed, or moderated by Boardwalk except as Boardwalk may elect from time to time. 7.2. Boardwalk may offer additional products, services, or features from time to time. Such additions are governed by these Terms unless separate terms are provided. ## 8. Permissionless Launches; No Endorsement 8.1. The Protocol is permissionless. Any person may configure and launch a token through the Protocol without approval, vetting, selection, or endorsement by Boardwalk. 8.2. Boardwalk does not verify issuer identities, conduct due diligence on token projects, audit smart contracts for launched tokens, review token economics, or monitor for fraudulent activity by issuers. You acknowledge that permissionless systems carry inherent risks, including the risk of encountering tokens created with deceptive or fraudulent intent. 8.3. A token appearing in the Interface, having a positive visibility score, or being discussed in Café Boardwalk does not constitute endorsement, approval, due diligence, or a recommendation by Boardwalk. 8.4. You are solely responsible for conducting your own evaluation of any token, issuer, or auction before interacting with it through the Interface. ## 9. Fees 9.1. The Protocol applies built-in transfer fees to tokens launched through it. These fees are encoded in the token’s smart contract at launch. Fee parameters vary by chain and launch configuration, and are further described in the publicly available product documentation. 9.2. The fee is built into the token itself and applies to onchain movement wherever the token trades, not only within the Interface. Combined with the swap fee at the DEX level, the total net cost to traders is determined by the applicable fee schedule. 9.3. Boardwalk does not guarantee any specific fee amount, fee allocation, or fee revenue to any party. All fee-related amounts depend on actual protocol activity, volume, and onchain conditions, and may be zero. 9.4. You are solely responsible for determining and fulfilling any tax obligations related to your use of the Interface, including any digital asset transactions, fee claims, staking, vote direction participation, or other activities. Boardwalk does not provide tax advice. 9.5. The Protocol may require BWLK to be burned for certain actions, including launching a token and community signaling. Burned BWLK is destroyed permanently and cannot be recovered. ## 10. User Content and Conduct 10.1. You must not use the Interface to post, upload, or transmit any content that is abusive, defamatory, dishonest, obscene, infringing, or intended to manipulate a market or spread false or misleading information. 10.2. You must not use the Interface or the Protocol to launch, promote, or distribute tokens in connection with any activity that violates Applicable Law, including but not limited to securities laws, anti-money laundering laws, and counter-terrorism financing regulations. 10.3. Issuers are solely responsible for the tokens they launch through the Protocol, including all legal, regulatory, and compliance obligations. Boardwalk does not provide legal advice to issuers. 10.4. Issuers and users may submit content through the Interface in connection with launches and community features, including token names, symbols, logos, descriptions, social links, and forum posts. You represent and warrant that any such content does not infringe third-party rights and complies with these Terms. ## 11. Prohibited Uses You agree not to use the Interface to: **(a)** Violate any Applicable Law, including sanctions laws, anti-money laundering regulations, or securities regulations. **(b)** Engage in, facilitate, or promote money laundering, terrorist financing, fraud, market manipulation, or other illegal activity. **(c)** Circumvent or attempt to circumvent any access restrictions, sanctions controls, fraud controls, or platform-integrity measures implemented by the Interface, including through VPNs, proxies, Tor, geolocation spoofing, burner identities, or linked accounts. **(d)** Access the Interface from a Restricted Jurisdiction or on behalf of a Restricted Person. **(e)** Interfere with, disrupt, or attempt to compromise the integrity, security, or proper functioning of the Interface, the Protocol, or any associated system, network, server, or infrastructure. **(f)** Use any automated means (including bots, spiders, scrapers, or crawlers) to access the Interface in a manner that impairs its availability or functionality, or to extract data not purposely made available. **(g)** Attempt to obtain private keys, passwords, wallet credentials, or other security information from any other user. **(h)** Decompile, reverse-engineer, or attempt to obtain the source code of the Interface, except where such restriction is prohibited by Applicable Law. **(i)** Provide false, inaccurate, or misleading information in connection with your use of the Interface. **(j)** Impersonate any person or entity, or falsely state or otherwise misrepresent your affiliation with a person or entity. **(k)** Infringe on the intellectual property rights of Boardwalk or any third party. ## 12. Intellectual Property 12.1. The Interface and its contents, including text, graphics, logos, icons, images, software, and design, are the property of Boardwalk or its licensors and are protected by applicable intellectual property laws. Subject to these Terms, Boardwalk grants you a limited, revocable, non-exclusive, non-sublicensable, non-transferable license to access and use the Interface for your personal, non-commercial use in accordance with these Terms. 12.2. You may not reproduce, distribute, modify, create derivative works of, publicly display, publicly perform, or otherwise exploit the Interface or its contents without Boardwalk’s prior written consent, except as expressly permitted by these Terms or Applicable Law. 12.3. The Boardwalk name, logo, and all related names, logos, product and service names, designs, and slogans are trademarks of Boardwalk or its affiliates. You may not use these marks without Boardwalk’s prior written consent. ## 13. Third-Party Services 13.1. The Interface may integrate with, link to, or provide access to third-party services, including wallet providers, blockchain networks, decentralized exchange protocols, data providers, oracles, and other infrastructure (each a “Third-Party Service”). 13.2. Your use of any Third-Party Service is governed by that provider’s terms of service and privacy policy. Boardwalk does not control, endorse, or assume responsibility for Third-Party Services, including their availability, accuracy, security, or legality. 13.3. You acknowledge that Boardwalk is not responsible for any loss or damage arising from your use of or reliance on any Third-Party Service. ## 14. Risk Disclosures You acknowledge and accept each of the following risks in connection with your use of the Interface and the Protocol: **(a) Smart Contract Risk.** The Protocol is based on smart contracts that may contain bugs, vulnerabilities, or design flaws. Smart contracts are generally irreversible and may not function as intended. Audits reduce but do not eliminate risk. **(b) Digital Asset Volatility.** Digital assets are highly volatile. Their value can fluctuate significantly in short periods. You may lose some or all of the value of any Digital Assets you interact with. **(c) Permissionless Launch Risk.** Tokens launched through the Protocol are user-generated and permissionless. There is no guarantee of quality, legitimacy, or value. Issuers may abandon projects, drain liquidity through mechanisms outside the Protocol’s control, or act with deceptive intent. These risks can result in total loss of contributed funds. **(d) Locked Liquidity.** Locked liquidity means the seeded liquidity 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. **(e) Governance Risk.** Vote direction outcomes are determined by onchain voting and may not align with your preferences. Participation in vote direction does not confer ownership, equity, or entitlement to Operations Reserve assets or protocol fees. **(f) Regulatory Risk.** The regulatory framework governing blockchain technologies, digital assets, and token launches is uncertain and evolving. New regulations or enforcement actions may materially affect the Protocol, the Interface, or your ability to use them. **(g) Blockchain and Network Risk.** Blockchain networks may experience congestion, forks, attacks, outages, or changes to consensus rules that affect the availability or functionality of the Protocol. **(h) Anti-Sniper Window.** After a token’s liquidity is seeded, the Protocol applies an elevated fee that decays over an initial period following liquidity seeding. This mechanism reduces but does not eliminate front-running or sniping risk. **(i) Paced Claims.** Issuer fee recipients are subject to a paced-claim mechanism that limits the rate at which accrued balances may be withdrawn. This pacing is a Protocol mechanic; it does not guarantee that claimed amounts will have any particular value at the time of claim. **(j) Vesting Risk.** Vesting schedules are fixed onchain after initialization. The value of vested tokens at the time they become claimable is not guaranteed and may be zero. **(k) Participation Points and Voter Points.** Participation Points and Voter Points are non-transferable and have no monetary value. They serve onchain functions within the Protocol and should not be treated as financial assets or entitlements. **(l) Fee Dependency.** All fee amounts, allocations, and distributions directed through vote direction depend on actual protocol usage, volume, and onchain conditions. They may be zero. ## 15. Disclaimers 15.1. THE INTERFACE AND ALL CONTENT, FEATURES, AND SERVICES MADE AVAILABLE THROUGH THE INTERFACE ARE PROVIDED ON AN “AS IS” AND “AS AVAILABLE” BASIS, WITHOUT WARRANTIES OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE, AND NON-INFRINGEMENT. 15.2. BOARDWALK DOES NOT WARRANT THAT THE INTERFACE WILL BE UNINTERRUPTED, ERROR-FREE, SECURE, OR FREE OF VIRUSES OR OTHER HARMFUL COMPONENTS. BOARDWALK DOES NOT WARRANT THE ACCURACY, COMPLETENESS, OR TIMELINESS OF ANY INFORMATION DISPLAYED THROUGH THE INTERFACE, INCLUDING PRICE DATA, TOKEN VALUES, FEE CALCULATIONS, OR TRANSACTION DETAILS. 15.3. BOARDWALK IS NOT A BROKER, DEALER, EXCHANGE, INVESTMENT ADVISER, CUSTODIAN, TRANSFER AGENT, OR FINANCIAL SERVICE PROVIDER OF ANY KIND. BOARDWALK DOES NOT HAVE A FIDUCIARY RELATIONSHIP WITH, OR OBLIGATION TO, YOU. 15.4. BOARDWALK DOES NOT ENDORSE, APPROVE, VET, SELECT, RATE, OR RECOMMEND ANY TOKEN, ISSUER, AUCTION, OR DIGITAL ASSET ACCESSIBLE THROUGH THE INTERFACE. WE DO NOT RECOMMEND THAT ANY DIGITAL ASSET BE ACQUIRED, HELD, STAKED, OR DISPOSED OF BY ANY PERSON UNDER ANY CIRCUMSTANCES. ## 16. Limitation of Liability 16.1. TO THE FULLEST EXTENT PERMITTED BY APPLICABLE LAW, IN NO EVENT SHALL BOARDWALK, ITS AFFILIATES, OR THEIR RESPECTIVE OFFICERS, DIRECTORS, EMPLOYEES, CONTRACTORS, AGENTS, OR LICENSORS (COLLECTIVELY, THE “BOARDWALK PARTIES”) BE LIABLE FOR ANY INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, EXEMPLARY, OR PUNITIVE DAMAGES, INCLUDING BUT NOT LIMITED TO LOSS OF PROFITS, LOSS OF DIGITAL ASSETS, LOSS OF DATA, LOSS OF BUSINESS OPPORTUNITIES, OR LOSS OF GOODWILL, WHETHER ARISING OUT OF OR IN CONNECTION WITH THESE TERMS, THE INTERFACE, THE PROTOCOL, OR ANY DIGITAL ASSET, AND REGARDLESS OF THE THEORY OF LIABILITY (CONTRACT, TORT, STRICT LIABILITY, OR OTHERWISE), EVEN IF THE BOARDWALK PARTIES HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. 16.2. TO THE FULLEST EXTENT PERMITTED BY APPLICABLE LAW, THE AGGREGATE LIABILITY OF THE BOARDWALK PARTIES FOR ALL CLAIMS ARISING OUT OF OR RELATING TO THESE TERMS, THE INTERFACE, OR THE PROTOCOL SHALL NOT EXCEED ONE HUNDRED U.S. DOLLARS (USD \$100.00). 16.3. THE LIMITATIONS IN THIS SECTION APPLY REGARDLESS OF WHETHER THE ALLEGED LIABILITY IS BASED ON CONTRACT, TORT, NEGLIGENCE, STRICT LIABILITY, OR ANY OTHER BASIS, AND EVEN IF A REMEDY SET FORTH HEREIN IS FOUND TO HAVE FAILED OF ITS ESSENTIAL PURPOSE. 16.4. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OR LIMITATION OF CERTAIN DAMAGES. IN SUCH JURISDICTIONS, THE LIMITATIONS AND EXCLUSIONS IN THIS SECTION SHALL APPLY TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW. ## 17. Indemnification You agree to indemnify, defend, and hold harmless the Boardwalk Parties from and against any and all claims, damages, losses, liabilities, costs, and expenses (including reasonable attorneys’ fees) arising out of or related to: (a) your access to or use of the Interface or the Protocol; (b) your violation of these Terms; (c) your violation of any Applicable Law; (d) your violation of the rights of any third party, including intellectual property rights; (e) any Digital Assets you launch, create, or interact with through the Protocol; or (f) any content you post or transmit through the Interface or Café Boardwalk. ## 18. Privacy and Data 18.1. Boardwalk may collect, use, store, and disclose information relating to your access to and use of the Interface for purposes including providing and improving the Interface, maintaining platform security, preventing fraud and sanctions evasion, complying with Applicable Law, enforcing these Terms, and resolving disputes. 18.2. Information collected may include IP addresses, geolocation data, wallet addresses, transaction data, device information, browser information, and timestamps. 18.3. Boardwalk may log and retain records relating to access attempts that are restricted or refused, and other information reasonably necessary to enforce these Terms or comply with Applicable Law. 18.4. By using the Interface, you consent to the collection, use, and disclosure of your information as described in this Section. ## 19. Modifications and Termination 19.1. Boardwalk may modify, suspend, or discontinue the Interface or any part of it, temporarily or permanently, at any time and without prior notice or liability. You agree that Boardwalk shall not be liable to you or any third party for any modification, suspension, or discontinuance of the Interface. 19.2. Boardwalk may restrict, suspend, or terminate your access to the Interface at any time, with or without cause and with or without notice, including if Boardwalk reasonably believes that you have violated these Terms or any Applicable Law, or that your continued access poses a risk to Boardwalk, other users, or third parties. 19.3. Sections that by their nature should survive termination shall survive, including Sections 14 through 21. ## 20. Dispute Resolution; Arbitration; Class Action Waiver **20.1. Informal Resolution.** Before filing any claim, you agree to attempt to resolve the dispute informally by contacting Boardwalk. If the dispute is not resolved within thirty (30) days, either party may proceed as set forth below. **20.2. Binding Arbitration.** Any dispute, controversy, or claim arising out of or relating to these Terms, the Interface, or the Protocol, including the formation, interpretation, breach, or termination thereof, shall be finally settled by binding arbitration. The arbitration shall be conducted on an individual basis, not as a class, consolidated, or representative action. The arbitrator’s award shall be final and binding, and judgment on the award may be entered in any court of competent jurisdiction. 20.3. CLASS ACTION WAIVER. YOU AND BOARDWALK AGREE THAT EACH PARTY MAY BRING CLAIMS AGAINST THE OTHER ONLY IN YOUR OR ITS INDIVIDUAL CAPACITY AND NOT AS A PLAINTIFF OR CLASS MEMBER IN ANY PURPORTED CLASS, CONSOLIDATED, OR REPRESENTATIVE PROCEEDING. UNLESS BOTH YOU AND BOARDWALK AGREE OTHERWISE, THE ARBITRATOR MAY NOT CONSOLIDATE MORE THAN ONE PERSON’S CLAIMS AND MAY NOT OTHERWISE PRESIDE OVER ANY FORM OF A REPRESENTATIVE OR CLASS PROCEEDING. **20.4. Exceptions.** Notwithstanding the foregoing, either party may seek injunctive or other equitable relief in any court of competent jurisdiction to prevent the actual or threatened infringement, misappropriation, or violation of intellectual property rights or confidentiality obligations. ## 21. Miscellaneous **21.1. Entire Agreement.** These Terms, together with any other documents incorporated by reference, constitute the entire agreement between you and Boardwalk with respect to the Interface and supersede all prior or contemporaneous communications. **21.2. Severability.** If any provision of these Terms is found to be invalid, illegal, or unenforceable, the remaining provisions shall continue in full force and effect. The invalid provision shall be modified to the minimum extent necessary to make it valid and enforceable. **21.3. Waiver.** The failure of Boardwalk to enforce any right or provision of these Terms shall not constitute a waiver of that right or provision. **21.4. Assignment.** You may not assign or transfer these Terms or your rights or obligations hereunder without Boardwalk’s prior written consent. Boardwalk may assign these Terms without restriction. **21.5. Force Majeure.** Boardwalk shall not be liable for any failure or delay in performance resulting from circumstances beyond its reasonable control, including acts of God, war, terrorism, pandemic, power failure, internet disruption, blockchain congestion or failure, government action, or regulatory change. **21.6. No Third-Party Beneficiaries.** These Terms do not create any third-party beneficiary rights in any person or entity. **21.7. Headings.** Section headings are for convenience only and do not affect the interpretation of these Terms. **21.8. Contact.** Questions about these Terms may be directed to contact@bmx.trade. _Not financial or legal advice. Participation in protocol features is subject to risk, smart-contract constraints, and jurisdiction-specific considerations._