Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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_wallflag to theLaunchaccount, allowing launch creators to choose whether surplus funds go to the bid wall or the DAO treasury.Changes
has_bid_wallfield onLaunchstate -- set at initialization viaInitializeLaunchArgs. Whenfalse, all post-LP USDC goes directly to the DAO treasury. Whentrue, the existing bid wall allocation logic applies (excess aboveminimum_raise_amountfunds the bid wall).**complete_launchconditional logic** -- the USDC split between treasury and bid wall now branches onhas_bid_wall. With the flag off,usdc_to_bid_wallis always 0.resize_launch-- existing launches gethas_bid_wall: falseby default when resized, preserving backward compatibility. TheOldLaunchstruct is updated to include theaccumulator_activation_delay_secondsfield that was added in the prior release, and the resize handler now correctly preserves that value instead of zeroing it.LaunchpadClient.initializeLaunchIxacceptshasBidWall, andLaunchInitializedEventincludes the new field.SDK
New SDK version released under
alphatag (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.tscover the key scenarios:hasBidWall: falsewith excess funding -- all post-LP USDC goes to treasury, no bid wall createdhasBidWall: truewith funding above 1.25x minimum -- bid wall is initialized with the surplushasBidWall: truewith funding at exactly the minimum -- no bid wall (insufficient surplus), same as beforehasBidWall: truewith funding at exactly 1.25x minimum -- boundary case, no bid wall (LP allocation consumes the surplus)All existing tests updated to pass
hasBidWall(defaulting tofalse).