Boardwalk Is Migrating Its Protocol Token From BMX on Base to BWS on Arbitrum
1 BMX = 1 staked BWS. Boardwalk application infrastructure remains multichain.
Beginning July 17, 2026, eligible BMX holders may migrate 1 BMX for 1 BWS through the official migration process. Migrated BWS will be received as staked BWS.
BWS will be used for Boardwalk’s active protocol-token systems on Arbitrum, including:
- staking
- Voter Points
- Fee Direction and
- primary BWS liquidity.
Boardwalk application infrastructure remains multichain, including on Base. Boardwalk will relaunch across Ethereum, Base, Arbitrum, Ink, Katana, and Fraxtal.
BWS will be bridgeable between Arbitrum, Base, and other supported Boardwalk chain deployments through verified Chainlink CCIP routes. BWS must be on Arbitrum to participate in BWS staking, Voter Points, Fee Direction, and primary BWS liquidity.
A Note on Terminology
BMX was previously the name used for both the legacy protocol and its token.
Today:
- Boardwalk is the protocol and multichain application-infrastructure layer.
- BWS is Boardwalk’s protocol token.
- BMX refers to the legacy Base token being migrated.
At a Glance
| Topic | Design |
|---|---|
| Protocol-token transition | BMX on Base → BWS on Arbitrum |
| Migration ratio | 1 BMX = 1 BWS |
| BMX migration basis | 2,711,068 BMX as of June 29, 2026 |
| BWS initial deployment supply | 3,150,000 BWS |
| Migrated BMX | Received as staked BWS |
| Voter Point credit | 0.16 × (Migrated BMX + Migrated Voter Points) |
| Public CCA allocation | 219,466 BWS |
| CCA raise asset | ETH |
| CCA floor | 0.00025 ETH per BWS |
| Graduation Threshold | 54.87 ETH |
| CCA opens | July 6, 2026, 8:00 a.m. PDT / 15:00 UTC |
| CCA closes | July 10, 2026, 11:59 p.m. PDT / July 11, 2026, 06:59 UTC |
| CCA BWS | Received unstaked; may be staked after BWS staking becomes active |
| Contingent initial liquidity | 219,466 BWS paired with CCA ETH and permanently locked if the CCA graduates |
| Snapshot publication | By July 15, 2026, 12:00 p.m. PDT / 19:00 UTC |
| Migration opens | July 17, 2026, 12:00 p.m. PDT / 19:00 UTC |
| Migration closes | January 13, 2027, 19:00 UTC |
| Unclaimed migration BWS | Permanently burned |
| CCA non-graduation | ETH refunds available; migration continues; 438,932 BWS permanently burned |
| Separate team, private-sale, Operations Reserve, treasury, or discretionary BWS allocation | 0% |
| Estimated multichain relaunch | July 13–20, 2026, subject to integration completion |
What Is Changing
BMX is moving from Base to BWS on Arbitrum.
This is not a simple ticker replacement. BWS uses a new token contract and dedicated transition contracts built for the BMX-to-BWS migration.
For BMX holders, the core migration outcome is direct:
1 BMX = 1 staked BWS
Eligible snapshot Voter Points may migrate with the applicable position. Every BMX migrated also receives a one-time Voter Point credit:
Migration Voter Point Credit = 0.16 × (Migrated BMX + Migrated Voter Points)
BWS is not a token deployed through Boardwalk’s standard permissionless issuer contracts. It is a separate, one-time protocol-token transition for the existing BMX community.
Why Arbitrum
Boardwalk was built for more than creating tokens.
It was built for what happens after a token exists: how liquidity is structured, how fees move through a system, how staking works, how participation is recognized, how communities coordinate, and how market rules remain visible and programmable over time.
Arbitrum is the environment Boardwalk has selected for BWS protocol-token systems. It is building the architecture for a global, programmable economy rooted in true decentralization.
Arbitrum is one of crypto’s most active onchain ecosystems, with billions in stablecoins, DeFi liquidity, DEX volume, and perps activity across a deep base of builders, apps, games, communities, and native markets.
That is exactly where Boardwalk’s native token economy fits.
Mature ecosystems do not just need more tokens. They need clearer ways for projects and communities to form native markets with transparent rules, programmable fee routing, and legible launch mechanics.
This is a product and infrastructure decision.
Boardwalk remains multichain, including on Base. The Boardwalk application layer will continue across supported chains, and BWS will be bridgeable through official CCIP routes to Base and other supported Boardwalk deployments.
Bridgeability does not create a second BWS staking, Voter Point, or Fee-Direction venue. Those active BWS protocol-token systems operate on Arbitrum.
Why BMX Is Becoming BWS
BMX was created before Boardwalk became its own protocol, brand, and multichain application-infrastructure layer.
BWS aligns the protocol token with Boardwalk’s current identity and establishes a new token contract designed for the system going forward.
Like BMX, BWS is designed as a fixed-supply, non-emitting utility and coordination token used within Boardwalk’s protocol-token systems. BWS improves on BMX’s token architecture by removing inherited legacy token surface area and beginning with a purpose-built immutable token contract.
At deployment, the BWS token contract will have:
- no owner
- no administrator
- no minter
- no post-deployment supply-increase function and
- no upgrade path.
The BWS token contract is designed to be immutable from deployment.
Legacy token-code patterns can create warnings in token scanners, wallet interfaces, and third-party discovery tools. Those warnings may be generic, but they can still create confusion and friction for users, integrations, and marketplaces.
BWS begins with a simpler token architecture: no privileged token controls, no future token-supply function, and no upgrade authority.
Why BWS Is Not Being Issued Through Boardwalk
BWS is not a new token economy deployed through Boardwalk’s standard permissionless issuer infrastructure.
That is intentional.
Boardwalk’s existing core contracts were written to support a protocol token with BMX-like characteristics. Its staking, Voter Point, and Fee-Direction systems were designed around BMX because, when those contracts were written, there was no plan to replace or migrate the protocol token.
Boardwalk’s standard issuer path serves a different purpose. It is a neutral, permissionless path for independent token economies using Boardwalk’s standard launch, liquidity, vesting, fee, and participation infrastructure.
The BMX-to-BWS transition has requirements that do not exist in a standard Boardwalk-issued token flow, including:
- a BMX burn-and-claim migration;
- snapshot-based Voter Point assignment;
- pro-rata treatment of snapshot Voter Points;
- the one-time 16% Voter Point credit;
- one snapshot Voter Point match per source wallet;
- later BMX migrations that remain eligible for 1:1 BWS and the 16% credit;
- a one-time BWS receiving-address option for current stakers;
- a migration deadline and permanent burn of unclaimed supply; and
- a public CCA and contingent permanent-liquidity configuration.
Forcing those one-time migration mechanics into Boardwalk’s existing core codebase would require extensive changes to contracts that have already been reviewed for their current purpose.
That would broaden review scope, introduce avoidable implementation risk, require additional audit work, and materially delay Boardwalk’s multichain relaunch.
Instead, BWS uses dedicated contracts for the migration, snapshot treatment, CCA, contingent liquidity, and other one-time transition mechanics.
This preserves Boardwalk’s existing core architecture, avoids unnecessary delay, and keeps the standard issuer path consistent for future independent token economies.
BWS is therefore not a Boardwalk platform issuance.
It is a separate protocol-token transition from BMX.
Why Now
Boardwalk has only recently exited beta and launched live.
There are currently no live Boardwalk token economies to interrupt, no active issuer systems being asked to change direction midstream, and no active designated protocol-fee flows for BMX holders to vote-direct.
That makes this the cleanest point to establish BWS before Boardwalk’s live economies, issuer systems, fee flows, and cross-chain activity become more interconnected.
Waiting until those systems are active at scale would make the same transition more difficult, more disruptive, and less clear.
BWS Supply at Deployment
BWS will be deployed with an initial supply of 3,150,000 BWS.
The 2,711,068 BMX total supply recorded on June 29, 2026 forms the 1:1 migration pool. The remaining supply is split equally between the public CCA and a contingent BWS/ETH liquidity allocation.
| BWS Allocation | BWS | Share of Initial Supply |
|---|---|---|
| BMX community migration pool | 2,711,068 | 86.07% |
| Public Uniswap CCA | 219,466 | 6.97% |
| Contingent permanently locked BWS/ETH liquidity | 219,466 | 6.97% |
| Initial BWS supply | 3,150,000 | 100.00% |
There is no separate BWS allocation for:
- a team
- a private sale
- the Operations Reserve
- a treasury
- a discretionary reserve or
- any other category.
The canonical BWS token contract has no post-deployment supply-increase function.
BWS supply may decrease through permanent burns, including:
- BWS unclaimed after the migration deadline
- unsold or unallocated CCA BWS and
- CCA and contingent-liquidity BWS required to burn if the CCA does not graduate.
Burned BWS cannot be reissued.
BWS bridged through official CCIP routes is subject to the published cross-chain accounting and contract configuration for each supported deployment. Cross-chain movement does not create a new discretionary BWS allocation or increase the aggregate BWS supply described in this announcement.
The token-level properties described here apply to the canonical BWS token contract. The migration module, CCA, LP vault, CCIP routes, Operations Reserve, and hosted interface are separate systems with their own disclosed addresses, configurations, and permissions.
Current BMX Staking Context
As of June 29, 2026, 1,791,536 BMX is staked, representing approximately 66.08% of the 2,711,068 BMX migration basis.
The remaining 919,532 BMX, or approximately 33.92%, is unstaked.
This is a current network-state reference only. It does not predict how much BMX will migrate, remain staked after migration, be unstaked, be bridged, or trade.
Every BMX successfully migrated through the official process is received as staked BWS.
There is no mandatory lock. Holders may later unstake BWS, but Voter Points burn proportionally when BWS is unstaked.
The BWS Continuous Clearing Auction on Uniswap
From July 6, 2026 at 8:00 a.m. PDT through July 10, 2026 at 11:59 p.m. PDT, 219,466 BWS will be offered through a Uniswap Continuous Clearing Auction, or CCA.
CCA opens: July 6, 2026, 15:00 UTC
CCA closes: July 11, 2026, 06:59 UTC
The CCA raise asset is ETH.
The fixed CCA floor is: 0.00025 ETH per BWS
This is a fixed ETH-denominated auction parameter. It is not USD-linked, does not adjust with ETH price, and is not a statement about BWS value, liquidity, or any future market outcome.
The CCA is subject to its published onchain terms, applicable law, and any applicable participant-eligibility or hosted-interface access restrictions.
Before bidding opens, the official CCA page will publish:
- verified BWS contract address;
- the fixed ETH-denominated floor configuration;
- bid, settlement, withdrawal, and refund mechanics;
- BWS claim instructions;
If the CCA Graduates
If the CCA meets its graduation threshold of 54.87 ETH:
After settlement, contributors may claim allocated BWS and any unspent ETH under the published terms.
CCA-acquired BWS is received unstaked.
CCA BWS does not receive:
- Migrated Voter Points; or
- the 16% Voter Point credit.
CCA BWS may be staked on or after July 17, once the BWS staking system is active.
A separate 219,466 BWS allocation will be paired with CCA ETH and deposited into a permanently locked BWS/ETH LP vault.
Any CCA BWS not allocated through settlement will be permanently burned through the preconfigured burn path.
If the CCA Does Not Graduate
If the CCA does not meet its graduation threshold:
- CCA contributors will have ETH refunds available under the published CCA terms;
- the BMX-to-BWS migration will continue on July 17 as planned;
- no BWS/ETH LP will be initialized through the CCA path; and
- all 438,932 BWS allocated to the CCA and contingent LP path will be permanently burned.
No CCA- or LP-path BWS may be redirected to (except in the event of an LP-initialization error per Uniswap Contracts):
- a team
- a private purchaser
- the Operations Reserve
- a treasury or
- any other recipient.
After the migration closes in this outcome, final BWS supply will equal the amount of BMX successfully migrated, capped at 2,711,068 BWS. Any unclaimed migration BWS will also burn.
Permanently Locked Initial Liquidity
If the CCA graduates, the LP principal cannot be withdrawn, transferred, or unwound by the Operations Reserve, a team member, or any discretionary party.
The Operations Reserve may claim trading fees generated by the permanently locked LP position in both BWS and ETH. It cannot claim, withdraw, transfer, or unwind LP principal.
The LP address, permanent-lock configuration, recipient configuration, and onchain proof path will be published before use.
Locked liquidity does not mean price stability, guaranteed liquidity, guaranteed exits, or protection from market risk. It does not guarantee trading volume, liquidity depth, or any other market outcome.
Migration Timeline
| Date | Event |
|---|---|
| July 6, 2026 | CCA opens |
| July 10, 2026 | CCA closes |
| By July 15, 2026, 19:00 UTC | Snapshot record published for review |
| July 17, 2026, 19:00 UTC | BMX → BWS migration opens and BWS staking becomes active |
| January 13, 2027, 19:00 UTC | Migration closes; unclaimed migration BWS permanently burns |
Boardwalk’s multichain application-infrastructure relaunch is currently estimated for July 13–20, 2026, subject to integration completion.
Any statements about future integrations, chain deployments, routes, timing, protocol activity, fees, burns, or other future matters are forward-looking and subject to change.
What BMX Holders Need to Do
- Remain staked through July 15th’s snapshot publication if you want existing Base Voter Points represented.
- Review the published wallet-level snapshot information.
- Withdraw BMX from LP positions before migration, where applicable.
- Choose a BWS receiving address carefully if using the one-time destination-address option available to current stakers.
- Maintain sufficient network gas for Base and Arbitrum transactions.
- Unstake BMX on Base after July 15th’s snapshot publication.
- Bridge BMX to Arbitrum only through the verified Chainlink CCIP route.
- Complete the burn-and-claim migration through the official Boardwalk interface.
- Confirm received staked BWS, Migrated Voter Points where applicable, and the 16% Voter Point credit.
Use official sources only.
Use only Boardwalk’s official website banner and official channels. Do not rely on direct messages, search advertisements, or unverified links.
The BMX to BWS Migration
Eligible BMX migrates at a 1:1 ratio: 1 BMX = 1 BWS
The migration opens on: July 17, 2026, 12:00 p.m. PDT / 19:00 UTC
The migration remains available for 180 days and closes at: January 13, 2027, 19:00 UTC
Any BWS remaining unclaimed at that time will be permanently burned.
The expected migration sequence is:
- Review the published snapshot information for the source wallet.
- Confirm the source wallet’s snapshot data is accurate.
- Select a BWS receiving address where applicable.
- Unstake BMX on Base where applicable.
- Bridge BMX to Arbitrum through the verified Chainlink CCIP route.
- Complete the burn-and-claim migration.
- Receive staked BWS, Migrated Voter Points where applicable, and the Voter Point credit.
Note: Steps 6 and 7 will occur behind a migration tool on
.
Only BMX held directly in a wallet and bridged to Arbitrum can migrate.
BMX held in an LP position must be withdrawn before migration. There is no separate LP migration route or special LP Voter Point treatment.
BMX held through an exchange, custodian, or third-party contract can only migrate where the holder can withdraw it to a compatible wallet and complete the required steps.
All BMX follows the same 1:1 migration economics, subject to applicable law, published migration terms, and hosted-interface eligibility restrictions.
Snapshot Timing and Voter Points on Base
The Voter Point snapshot will be taken at an unannounced time before the July 15 snapshot publication.
On July 15, 2026, at or before 12:00 p.m. PDT / 19:00 UTC, Boardwalk will publish:
- the snapshot date and timestamp;
- the reference block;
- wallet-level review information; and
- a process for reporting technical discrepancies.
The published snapshot record determines the maximum amount of snapshot-derived Voter Points that may migrate with each eligible wallet.
Because the precise snapshot time is not announced in advance, holders who want to migrate their existing Voter Points from Base should remain staked through the July 15 publication.
Unstaking before the snapshot occurs may result in loss of Voter Point representation. No discretionary exceptions will be made.
Voter Points on Base Earned After the Snapshot
BMX that remains staked after the July 15th snapshot announcement may continue accruing Voter Points on Base until it is unstaked. These do not transfer.
Those post-snapshot Voter Points on Base do not increase:
- Migrated Voter Points;
- the 16% Voter Point credit; or
- BWS Fee-Direction Weight.
The BWS migration uses the published snapshot record only. Post-snapshot Voter Points on Base remain on Base and burn under the Base contract’s normal mechanics when the related BMX is unstaked.
One Snapshot Voter Point Match; Later BMX Migrations
Each source wallet has one snapshot record. That record may be used one time to assign snapshot-derived Voter Points.
At the time of the snapshot-match migration, the source wallet must migrate its full BMX balance held at that time. A holder cannot split that balance across multiple snapshot-match claims to multiply snapshot-derived Voter Point assignments.
This restriction is a per-wallet restriction, meaning one wallet may use the migration module one time.
BMX acquired after the snapshot-match migration may be migrated using a wallet that has not yet utilized the migration module. BMX migrated receives:
- 1 BWS for each BMX migrated; and
- the 16% Voter Point credit calculated from the later migrated BMX amount.
Later BMX migrations do not receive additional Migrated Voter Points from the original snapshot record.
Migrated Voter Points and Fee-Direction Weight
Fee-Direction Weight, previously referred to as voting power, is:
Fee-Direction Weight = Staked BWS + Voter Points
Voter Points are non-transferable, have no monetary value, and are soulbound to the applicable staked position.
BWS Voter Point accrual begins on July 17, 2026 for BWS staked when the migration module opens.
Voter Points accrue at a 100% annual rate based only on the amount of BWS staked. They do not compound based on previously accumulated Voter Points.
When BWS is unstaked, Voter Points burn proportionally. A full unstake burns the Voter Points associated with that position.
There is no mandatory lock. Voter Points increase Fee-Direction Weight while BWS remains staked, while preserving a holder’s ability to exit the staking position.
The 16% Voter Point Credit
The 16% Voter Point credit is designed to help offset the difference between BMX supply and BWS’s larger initial deployment supply for purposes of starting Fee-Direction Weight.
It is a fee-direction weight adjustment only.
The credit does not:
- create additional BWS;
- increase a wallet’s 1:1 BWS claim;
- increase total BWS supply; or
- create a right to payment, protocol revenue, or any other entitlement.
Migration Voter Point Credit = 0.16 × (Migrated BMX + Migrated Voter Points)
“Migrated Voter Points” means the wallet’s eligible snapshot-derived Voter Points assigned under the pro-rata formula below.
The credit applies to every BMX migrated, regardless of when that BMX was acquired.
CCA-acquired BWS does not receive the 16% Voter Point credit.
Pro-Rata Formula for Migrated Voter Points
For a wallet with staked BMX and Voter Points in the snapshot:
Migrated Voter Points = min(Snapshot Voter Points, Migrated BMX × Snapshot Voter Points ÷ Snapshot Staked BMX)
Migrated Voter Points are capped at the wallet’s recorded snapshot Voter Point amount.
A wallet that migrates less BMX than it had staked at snapshot receives the proportional amount of its snapshot Voter Points.
A wallet that migrates more BMX than it had at snapshot, including BMX acquired later, receives its recorded snapshot Voter Point amount plus the 16% voter point credit applied to the migrated BMX amount in excess of the snapshot amount.
Examples
Example 1: Bob’s snapshot position and migration are the same.
Bob had 100 staked BMX and 100 snapshot Voter Points. He migrates 100 BMX through his snapshot-match migration.
- Bob receives 100 staked BWS.
- Bob receives 100 Migrated Voter Points.
- Bob receives a 32 Voter Point credit: 0.16 × (100 Migrated BMX + 100 Migrated Voter Points).
- Bob begins with 132 Voter Points.
- Bob begins with 232 Fee-Direction Weight: 100 staked BWS + 132 Voter Points.
Example 2: Bob then later acquires BMX.
After completing the snapshot-match migration above, Bob later acquires and migrates 50 additional BMX using a separate wallet considering the migration contract only allows one migration per wallet. Bob inputs his original address as the destination address on the migration module:
- Bob receives 50 additional staked BWS.
- Bob receives 0 additional Migrated Voter Points.
- Bob receives an 8 Voter Point credit: 0.16 × (50 Migrated BMX + 0 Migrated Voter Points).
- Bob’s Voter Points increase from 132 to 140.
- Bob’s aggregate Fee-Direction Weight becomes 290: 150 staked BWS + 140 Voter Points.
Example 3: Sally is unstaked at snapshot.
Sally migrates 100 BMX and had 0 snapshot Voter Points.
- Sally receives 100 staked BWS.
- Sally receives 0 Migrated Voter Points.
- Sally receives a 16 Voter Point credit: 0.16 × (100 Migrated BMX + 0 Migrated Voter Points).
- Sally begins with 16 Voter Points.
- Sally begins with 116 Fee-Direction Weight: 100 staked BWS + 16 Voter Points.
One-Time BWS Receiving-Address Option
Current BMX stakers may enter a different BWS receiving address during their snapshot-match migration.
This creates a one-time opportunity to change or consolidate wallet staking positions and select a destination for the migrated stake.
The source wallet’s snapshot record remains the basis for the migration. Selecting a different BWS receiving address does not create a transferable staking position after migration.
The receiving-address selection is irreversible. Users are responsible for confirming that the selected address is correct, controlled by them, and compatible with the migration process before signing.
Boardwalk cannot reverse, reroute, or recover a migration sent to an incorrect, inaccessible, or unsupported receiving address. Boardwalk is not responsible for user error.
BWS staking positions remain non-transferable once created.
Fee Direction on Arbitrum
BWS stakers may vote weekly on the routing of a limited, designated portion of Boardwalk protocol fees made available to the Fee-Direction system by applicable onchain contracts.
The available directions are:
1. Buy BWS and burn it.
2. Buy BWS and permanently lock liquidity.
3. Apply the designated fee budget to the contract-defined BWS stream for eligible stakers.
4. Route the designated fee budget to the Operations Reserve.
Votes are winner-take-all and cast one epoch before the applicable fee period. An option that wins three consecutive epochs must sit out for the following epoch.
Fee-Direction Weight applies only to this contract-defined system.
Fee Direction is limited.
Fee Direction is a limited contract-defined routing mechanism only. It does not obligate Boardwalk, the Operations Reserve, or any other person to generate fees, acquire BWS, lock liquidity, fund a stream, maintain liquidity, support a market, or take action intended to affect BWS value.
No financial outcome is promised, projected, or guaranteed by Boardwalk, BWS, staking, Fee Direction, burns, or locked liquidity. BWS does not create an entitlement to fees, revenues, assets, or action by Boardwalk.
Any amount made available through the limited Fee-Direction system depends on actual protocol activity, applicable onchain rules, eligibility, voting outcomes, and execution. It may be low, intermittent, or zero.
Fee Direction does not provide general governance over Boardwalk. It does not provide ownership, equity, debt, revenue share, guaranteed yield, redemption rights, repurchase rights, or a claim on Boardwalk assets, Operations Reserve assets, protocol treasury assets, or liquidation proceeds.
BWS holders and stakers may vote only to direct the designated fee budget made available under applicable onchain rules. They cannot use Fee-Direction Weight to:
- upgrade Boardwalk contracts;
- mint BWS;
- 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 an obligation to repurchase BWS, support a BWS market, maintain BWS liquidity, stabilize BWS price, or make any market in BWS.
There are currently no active Boardwalk token-economy deployments and therefore no active designated protocol fees for BMX holders to vote-direct.
Operations Reserve
The Operations Reserve is separate from BWS holders and BWS stakers.
It is controlled by a 2-of-3 team multisig and may receive designated protocol fees or trading-fee claims as compensation for building, supporting, maintaining, securing, and operating Boardwalk.
Operations Reserve resources may be used for:
- operations
- development
- audits
- infrastructure
- legal
- security
- grants
- integrations
- ecosystem support and
- other Boardwalk-related purposes.
BWS holders and stakers:
- do not own or control the Operations Reserve
- have no equity, debt, revenue-share, liquidation, or treasury claim on it
- cannot direct its assets
- have no entitlement to its assets or LP trading fees and
- cannot withdraw permanently locked LP principal.
The Operations Reserve’s right to claim BWS and ETH trading fees from the permanently locked LP does not create a BWS allocation or increase BWS supply.
The Operations Reserve address, signer configuration, and relevant onchain permissions will be published before use.
Existing BMX Holdings Disclosure
All BMX follows the same migration rules.
Boardwalk’s most recent BMX disclosure, dated June 15, 2026, states that:
- 74.92% of BMX supply was held outside current Boardwalk team beneficial ownership
- current Boardwalk team members beneficially owned 25.08% of BMX supply
- 10.47% reflected team allocations
- 14.61% reflected BMX acquired independently by current team members
- non-team participants controlled 65.0% of staked BMX and
- non-team participants controlled 56.33% of Fee-Direction Weight.
These figures exclude BMX held by the Operations Reserve. They are approximate, unaudited, time-specific, and may change through ordinary onchain activity.
There is no special BWS allocation or preferential migration route for any team, Operations Reserve, treasury, or related holder.
Existing BMX holdings remain eligible for the same migration mechanics, subject to applicable law, published terms, and hosted-interface eligibility restrictions.
Updated BWS-specific disclosures will be published before launch.
What Remains on Base After Migration
The BMX token contract and existing Base staking contract remain legacy contracts.
This transition does not alter the Base BMX token contract.
Until the January 13, 2027 migration deadline, eligible BMX may be bridged through the verified CCIP route and migrated through the official burn-and-claim process.
After the migration deadline:
- no additional BMX-to-BWS migration claims will be available
- any unclaimed migration BWS will have been permanently burned
- BMX on Base will no longer represent the active Boardwalk protocol-token system
- post-snapshot Base Voter Points will have no BWS migration, Voter Point credit, or BWS Fee-Direction effect and
- the Base contracts may continue to execute according to their immutable code, but they will not be part of Boardwalk or the active BWS staking and Fee-Direction system.
Boardwalk application infrastructure remains multichain, including on Base.
BWS will remain bridgeable to Base through supported CCIP routes. BWS on Base is supported through the multichain bridge architecture, while BWS staking, Voter Points, Fee Direction, and primary liquidity operate on Arbitrum.
