Technical Appendix

The technical appendix covers the onchain structure behind Boardwalk: which contracts do the work, which parts are shared across launches, and which settings can still change after deployment.

How the system is structured

Boardwalk Launchpad is built as a permissionless launch system with auctions, liquidity seeding, built-in fee routing, LP staking, and vesting. The launch system uses minimal proxy clones so new launches can be created from shared implementations rather than redeploying full logic each time. Each launch gets its own token and launch-specific contracts, while the broader protocol relies on a smaller set of shared singleton contracts.

Per-launch contracts

Each launch is built from a set of launch-specific contracts.

BoardwalkToken is the launched token contract. It holds the built-in transfer-fee logic, tracks the liquidity seed time, and points to the launch’s fee distributor and presale manager. It does not have a normal owner-controlled admin surface after initialization.

FeeDistributor routes the launched token’s built-in fee according to the launch setup. It can split fee flow across LP staking, Boardwalk, issuer recipients, and depending on the chain, a referrer or an integrator allocation. It also supports retries if a downstream forward fails, so token transfers do not depend on every later step succeeding in the same transaction. Issuer fee recipients claim their allocation through the fee distributor’s claim function, which converts the claim into the raise token. Each recipient is rate-limited to 10% of their unclaimed balance per 24 hours, with a small-balance escape so dust does not get stranded.

PresaleManager runs the auction. It accepts contributions, tracks weighted contributions, handles refunds if threshold is not met, and seeds liquidity after success. It also manages claim timing for auction contributors after the claim cliff.

LPStaking handles post-launch liquidity participation. It combines fee-based distributions with a longer-running vesting stream for LP incentives, and it tracks the point-based weight used inside that system. After initialization, it has no ongoing admin controls.

VestingStream exists on launches that include vesting. It holds the vesting allocations, enforces the cliff and vesting schedule, and allows only the vesting recipient address to change through a timelocked path. The vesting amounts, schedule, and labels do not change after setup.

Shared protocol contracts

Some contracts are shared across all launches rather than recreated per launch.

LaunchFactory is the deployment entry point. It validates configuration, burns BMX when required, deploys the per-launch clones, initializes them in the right order, and stores launch records. It also controls a set of future-launch admin defaults through timelocked actions.

BoardwalkLPManager is the shared liquidity helper. It provides the fee-exempt path for adding and removing liquidity without triggering the launched token’s built-in fee, but only for supported raise-token pairs. The swap fee on these pools is 0.1%, set at the DEX factory level. It has no admin controls after deployment.

BoardwalkFeeCollector collects the Boardwalk allocation of fee flow from live launches. It can batch process those balances and route them onward through the protocol’s fee flow. It also controls its own treasury, keeper, voting vault, and collector migration path through timelocked actions.

GovernanceVoter runs weekly epochs, collects votes, finalizes results against quorum, and executes the winning option. It also enforces the consecutive-win cap and the 14-day deadlock fallback, which routes the unexecuted budget to a separate fallback treasury address.

LPLocker holds the permanently locked BMX/WETH liquidity positions created by the Perma-Lock vote option. Trading fees from those positions can be claimed to the treasury over time.

ParticipationDistributor creates the 7-day BMX streams that fund the Route to BMX Stakers vote option for eligible voters from the prior epoch.

BoostBurn handles the BMX burns triggered by community signaling and other one-way protocol actions.

IntegratorFeeCollector receives the integrator allocation of fee flow from live launches and splits it across integrator positions by fixed per-position percentages. Each integrator independently claims their accrued balance, which converts into the raise token. Position addresses can change through a 14-day timelocked path controlled by the current holder.

These contracts sit at the protocol layer and support system-wide voting and discovery behavior.

Architecture summary

Per-launch clones (one set per launch):

BoardwalkToken, FeeDistributor, PresaleManager, LPStaking, and VestingStream (only on launches that use vesting).

Shared singletons (one instance protocol-wide):

LaunchFactory, BoardwalkLPManager, BoardwalkFeeCollector, IntegratorFeeCollector, BoostBurn, GovernanceVoter, LPLocker, ParticipationDistributor, and the shared DEX factory and router contracts.

Launch flow at the contract level

At deployment time, LaunchFactory creates the per-launch contracts first and then initializes them in order. After a successful auction, PresaleManager seeds liquidity, mints the needed token allocations, burns the LP tokens from the seeded position, initializes LP staking and vesting where applicable, and then activates the launched token’s live fee behavior by setting the liquidity seed time.

Once the token is live, transfers that are not exempt route the built-in fee into FeeDistributor. From there, the system can forward the LP portion to LPStaking, the Boardwalk portion to the fee collector, and accrue the issuer, referrer, or integrator portions according to the chain’s fee schedule.

What is immutable after a launch goes live

The core fee percentages for a live launch are immutable at deployment for that launch. Factory-level defaults can still be changed for future launches, but those later factory changes do not rewrite a launch that is already live.

On the vesting side, the amounts, schedule, and labels are immutable once the vesting stream is initialized. Only the destination address for a vesting allocation can change later, and even that follows a timelocked path controlled by the launch issuer.

The fee schedule that applies to a launch is immutable at creation based on the chain’s active schedule. Factory-level defaults can change for future launches, but a live launch’s fee setup stays as it was at creation.

What can still change after launch

Some addresses can change even though the economic split itself does not.

Within FeeDistributor, issuer fee recipient addresses can be changed by the current recipient for that slot, and the referrer address can be changed by the current referrer. Those changes follow the typed address-change flow rather than a general owner-only admin path.

Within IntegratorFeeCollector, each integrator address can be changed by the current holder of that position through a 14-day timelocked path. The change rejects a zero address and any address already held by another integrator.

Within VestingStream, the launch issuer can change a vesting recipient address, but not the vesting amounts or schedule. When that change executes, any vested but unclaimed tokens for the outgoing address are automatically claimed before the new address takes over. The issuer can also permanently burn the ability to change a specific recipient.

At the protocol layer, LaunchFactory can change future-launch defaults such as the BMX burn amount, launch thresholds, durations, fee defaults, presale range, anti-whale parameters, and fee collector through timelocked actions. The integrator BPS is immutable at the factory level; changing it requires a new factory deployment. These are future-launch controls, not live-launch rewrites.

Timelock model

The core timelock pattern uses a 7-day delay and a 7-day expiry window by default. The normal flow is: signal the change, wait through the delay, then execute it during the valid window. If the change is not executed in time, it expires instead of staying open forever.

For LaunchFactory, only the owner can signal or cancel these admin changes, and anyone can execute them after the delay. The same general pattern applies to BoardwalkFeeCollector for its treasury, keeper, voting vault, and collector migration actions.

For FeeDistributor, the model is narrower. The current recipient controls the signal and cancel step for issuer-recipient changes, and the current referrer controls the signal and cancel step for referrer changes. Anyone can execute the change after the delay.

For VestingStream, the launch issuer controls recipient-address changes. That same contract also supports burning a specific address-change ability permanently, again through its timelocked path.

For IntegratorFeeCollector, each position address change uses a 14-day delay. Only the current holder of that position can signal or cancel the change, and anyone can execute after the delay.

For GovernanceVoter, voting-sensitive actions use a longer 21-day delay rather than the standard 7-day delay.

Admin function inventory

Every admin action in the Boardwalk protocol goes through a timelocked path. The owner signals a change, the protocol enforces a mandatory delay, and then anyone can execute the change during a limited execution window. If the change is not executed before that window closes, it expires. The owner can cancel any signaled action before it executes.

The table below is the complete set of admin functions across all Boardwalk contracts. No admin action exists outside this list.

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.

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 FeeDistributors that will be updated, preventing partial or mismatched execution.

Change voting parameters (21-day delay). On GovernanceVoter, voting-sensitive actions such as the per-vote BMX burn amount and the fallback treasury address require a 21-day delay, providing a longer detection window.

What a compromised key cannot do

Rewrite a live launch’s economics. Fee splits, fee rates, vesting schedules, and token allocations are frozen at the per-launch contract level when a launch is created. Factory-level defaults only affect future launches.

Mint tokens. Only PresaleManager can call the token’s mint function, and total supply is enforced inside the mint. There is no open mint path for any admin.

Recover locked liquidity. LP tokens are burned to the dead address at seed time. There is no recovery path.

Bypass the transfer fee. The fee-exempt address set is fixed at token initialization. The only post-init change is the fee-collector swap during a migration, which itself is timelocked.

Drain user funds from staking or vesting. LPStaking, VestingStream, PresaleManager, LPLocker, and ParticipationDistributor have no admin functions. User funds in these contracts are governed entirely by their fixed logic.

Execute any change without public onchain notice. Every admin action emits an event at signal time. There is no path to execute an admin change in a single transaction.

Token supply and mint authority

Every token launched through Boardwalk has a fixed total supply of 10,000,000,000 (10 billion) tokens. The only contract with mint authority is the launch’s PresaleManager, and the mint function enforces the total supply cap internally. After the initial mint at liquidity-seeding time, no further tokens can ever be created for that launch. There is no admin-controlled mint, no inflation schedule, and no way to increase supply after deployment.

Upgradeability

Boardwalk does not use an upgradeable proxy pattern. Per-launch contracts are EIP-1167 minimal proxy clones that delegate to shared implementation contracts. The implementation addresses are set at LaunchFactory deployment and are immutable. There is no mechanism to point a deployed clone at a new implementation.

The only structural migration path in the system is the fee-collector rotation on BoardwalkFeeCollector. This allows the protocol to swap to a new fee collector contract, but the migration is timelocked (7-day delay) and the signal hash commits both the new collector address and the full list of FeeDistributors 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.

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:

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.

The general design principle is that keeper unavailability causes delays, not fund loss. In most cases, the relevant function is either permissionless from the start or becomes permissionless after a grace period.

Audit status

Boardwalk is currently in audit with Sherlock.