🪣 Protocol: Launchpad Default Parameters and Distribution.

[dillchen]

Description

This ticket addresses the onchain work necessary to update the distribution of the Launchpad ERC20 token as follows:

Launchpad Distribution:

• 70% of tokens are sold via a bonding curve.
• 12.5% of tokens are allocated to liquidity on the launchpad (if the cap is reached).
• 15% of tokens are held by the treasury.
• 7.5% of tokens are deposited into an autogenerated contest.

Beyond initial liquidity, the Launchpad ERC20 tokens will by default 1) launch a contest 2) reserve a portion for community treasury. This is in addition to the current distribution launchpad and liquidity reserve.

Of the 7.5% deposited into the contest, 0.5% will be distributed per week. The distribution will be weighted via community-driven weighted reactions (e.g., upvotes or other forms of engagement) within the contest. Voting power will be based on tokens held, allowing communities to have weighted voting power.

Project Owner

@dillchen

Bucket ID

No response

User Stories / Acceptance Criteria

1. Initialize Governance Contract (Contract 2)

   • Use OpenZeppelin’s Governor and ERC20Votes to for the launched token, and implement governance for 20% of the total token supply.
   • Setup quorum, voting delay, and voting period using the follow parameters: • Quorum: 15% of token supply • Voting Delay: 0.5 days • Voting Period: 2 days • Tokens will be held by a governance contract with a default quorum for decision-making.

2. Integrate with Launchpad Contract

   • Update the Launchpad contract to adjust token destination splits based on the new allocation percentages.

3. Governance Voting and Proposal Execution

   • Implement voting and proposal execution to manage Contract 2 (Governance).
   • Ensure proper handling of ERC20Votes for snapshot-based governance.

4. Integration with Existing Contest Infrastructure

   • Ensure the contest infrastructure is able to handle the 7.5% allocation for contests.
   • Implement the weighted reaction (of existing upvotes) to distribute 0.5% of tokens weekly based on community engagement.
   • By default launch the contract in a batched transaction

5. Testing and Validation

   • Verify the correct token allocation across all contracts.
   • Test governance proposals and ensure they meet the set quorum and voting period requirements.

Design Devlink

No response

Design Screenshot

No response

Additional Context

• OpenZeppelin Governance Documentation

Out of scope

• UI work for governance proposals - this will be done after work is done after this
• Documentation and training for Growth Team.

Future

• In the future, based on user feedback, the distribution model may be updated. For instance, the new configuration could allocate 60% for sale via bonding curve, 12.5% for liquidity, 15% to the treasury, and the remaining tokens could be used for other types of airdrops.
• Tap-style game that releases tokens at regular intervals (e.g., weekly) until all funds are distributed.

Tasks

• [ ] #9355
• [x] #9356
• [x] #9357

[ianrowan]

As requested I'll add a granular breakdown of the more specific dev tasks/contracts here:

1. Build a Launchpad launch hook to create a treasury/OZ gov contract for each launch

2. Architect and implement the automatic contest creation action

   • I cant point directly to the implementation plan directly here as it will involve some thought and rewiring of some things potentially
   • Initially we can plan to either route funds to a feeManager of the community or create a destination of the 7.5% in contract form that can spin up the relevant contest. As mentioned this all still requires some off-chain manual/programatic intermediate steps we will need to figure out
     3. Final task of this would be to wire up the default values and method calls detailed here and in the ticket on the app side to deploy tokens in this format

   CC @jnaviask

[dillchen]

Can hop on call to discuss 2 and 3 if needed

[ianrowan]

After some detailed analysis of the way the curve works I wanted to suggest some initial values/defaults for the curve etc.

First, the totals in the ticket description add up to 105% so I would suggest subtracting the 5% from the total liquidity provision to bring the original 70+12.5=82.5 to 77.5(more on this later)

Some values I found while messing with the math that work well imo are.

totalSupply = 1B min initial liquidity = 0.00000000001 ETH (1E8 wei) actual initial liquidity(would be hardcoded in UI) = 4.167E8 wei (creates the first sale at a $1000 mkt cap) connector weight(shape of the curve) = 830,000

these initial parameters create the following outcome of mkt cap/uni liquidity

Of the 77.5% Liquidity provision 43%(430MM tokens) sold via curve 34.5%(345MM tokens) added as liquidity

this implies the following final conditions of the bonding curve final price = $0.00007 final mkt cap = $70k raised liquidity = $25k

initial Uni price = $0.000072

Just suggestions but these values feel clean imo.