Skip to content

Add bid wall optionality to launchpad v7#440

Open
pileks wants to merge 3 commits intodevelopfrom
pileks/met-292-add-bid-wall-optionality-to-launchpad-v7
Open

Add bid wall optionality to launchpad v7#440
pileks wants to merge 3 commits intodevelopfrom
pileks/met-292-add-bid-wall-optionality-to-launchpad-v7

Conversation

@pileks
Copy link
Contributor

@pileks pileks commented Mar 16, 2026

Make bid wall optional for launchpad v7 launches

Previously, every launch that raised more than 1.25x the minimum raise amount would automatically initialize a bid wall with the excess USDC. This PR makes the bid wall opt-in by adding a has_bid_wall flag to the Launch account, allowing launch creators to choose whether surplus funds go to the bid wall or the DAO treasury.

Changes

  • New has_bid_wall field on Launch state -- set at initialization via InitializeLaunchArgs. When false, all post-LP USDC goes directly to the DAO treasury. When true, the existing bid wall allocation logic applies (excess above minimum_raise_amount funds the bid wall).
  • **complete_launch conditional logic** -- the USDC split between treasury and bid wall now branches on has_bid_wall. With the flag off, usdc_to_bid_wall is always 0.
  • Migration via resize_launch -- existing launches get has_bid_wall: false by default when resized, preserving backward compatibility. The OldLaunch struct is updated to include the accumulator_activation_delay_seconds field that was added in the prior release, and the resize handler now correctly preserves that value instead of zeroing it.
  • SDK and event updates -- LaunchpadClient.initializeLaunchIx accepts hasBidWall, and LaunchInitializedEvent includes the new field.

SDK

New SDK version released under alpha tag (clients won't automatically pick it up):
https://www.npmjs.com/package/@metadaoproject/futarchy/v/0.7.2-alpha.0

Testing

Four new test cases in completeLaunch.test.ts cover the key scenarios:

  1. hasBidWall: false with excess funding -- all post-LP USDC goes to treasury, no bid wall created
  2. hasBidWall: true with funding above 1.25x minimum -- bid wall is initialized with the surplus
  3. hasBidWall: true with funding at exactly the minimum -- no bid wall (insufficient surplus), same as before
  4. hasBidWall: true with funding at exactly 1.25x minimum -- boundary case, no bid wall (LP allocation consumes the surplus)

All existing tests updated to pass hasBidWall (defaulting to false).

@pileks pileks self-assigned this Mar 16, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant