[BIP-XXX] - bleu proposal for ve8020 Launchpad

Governance General Proposal
1

Description

Balancer’s 8020 Initiative revamps traditional governance models by enhancing liquidity and minimizing token volatility and slippage. This model works differently: instead of locking tokens into the Voting Escrow, user lock BPTs from a pool associated to the governance model.

As part of our commitment to the Balancer ecosystem, we’re eager to build a platform that makes it easier for any project to create a ve8020 system. To achieve this, we’re proposing to work on a ve system factory contract, an intuitive user interface for ve system admins, and an SDK to simplify integrations for protocols that prefer a custom-built frontend to interact with these features.

While creating this proposal, we’ve also developed a proof of concept (github, demo video here). This PoC includes test scripts to create a new ve8020 system, relying on ERC-5202’s proposed blueprint versions for the Voting Escrow and Reward Distributor (an adapted version of Balancer’s own FeeDistributor). We’ve also deployed this to Sepolia (tx and verified contract) for on-chain testing (although we haven’t dug our feet there yet!). This groundwork ensures we can hit the ground running post-approval and, we hope, gives the community confidence in our ability to deliver on this proposal.

Value Add

We aim to make it easier and less costly to implement a ve8020 governance model by providing ready-to-deploy contracts and a user-friendly UI. This could increase adoption of the 8020 initiative and thereby boost liquidity in Balancer Pools. During our proposal development, we’ve identified a list of potential users that might benefit from this solution, particularly those who already have liquidity locked in Balancer and are currently using single-side staking.

Milestones

  1. Smart Contracts
    1. Description: Each ve8020 system will be composed of two main contracts (Voting Escrow and Reward Distributor). We’ll build a factory to launch those contracts exposing some parameter customization.
    2. Requirements:
      1. Factory contract to deploy the Voting Escrow, Reward Distributor, and SmartWalletChecker contracts based on their blueprints.
      2. Customization of the round duration and deadline, and minimum and maximum lock time.
      3. Approval from the Balancer Smart Contract team for the developed contracts. An external audit may be required based on their recommendation (Balancer x Certora Accelerator with a cost of 10k USD).
      4. Technical documentation on how the system launches each ve8020 token and how to deploy the system.
  2. Integrations development
    1. Description: Development of SDK, Subgraph, and frontend integrations to simplify the launch of new ve8020 systems.
    2. Requirements:
      1. Create SDK functions for interacting with ve8020 systems (lock ve token, deposit rewards, claim rewards, ve allowlist management). Potentially integrate this to Balancer SDK if it makes sense.
      2. Create Subgraph for querying ve8020 system creations and usage, including BPT locks and reward deposits/claims.
      3. Provide a minimal frontend demo integrating with this SDK;
  3. Launchpad UI
    1. Description: Build a user-friendly and no-code UI to interact with the factories, making it as easy as possible for to anyone launch a veSystem based on any Balancer pool.
    2. Requirements:
      1. Initial page educating users about the tool and the ve system. Link to the ref docs created in the first milestone.
      2. Ability to create a ve8020 from any existing BPT. We’d link to Balancer’s Frontend for pool creation.
      3. Display data from subgraph to about ve8020 systems launched using the factory and total locked tokens.
      4. Allow token deposits into a system’s RewardDistributor contract.
  4. Deployment
    1. Description: As we did in other Balancer grants, deployment of the system and the contracts for each chain is not a problem. At this milestone, we would also address Balancer feedback, and write the project documentation.
    2. Requirements:
      1. Deploy and integrate contracts with UI and other integrations on specified chains.
      2. General documentation about how to use the Launchpad system.

Milestones are to be delivered in the space of 2 months and we’d need another two weeks for deployment to all chains. All USD values are to be converted to BAL at the time of payment. Our milestone schedule signals our commitment to delivering the project in full, as proposed by Burns in his post.

Edited to make payment schedule clearer:

Milestone 1: Completion of Smart Contracts. Payment: USD 4k.
Milestone 2: Completion of Integrations. Payment: USD 6k.
Milestone 3: Completion of Launchpad UI. Payment: USD 9k.
Milestone 4: Successful Deployment to the chains that Balancer is in. Payment: USD 10k.

Team description

bleu collaborates with companies and DAOs as a web3 technology and user experience partner. We’re passionate about enhancing the interaction between blockchain and web3 users.

In this project we would have mostly three people involved: José Ribeiro (co-founder at bleu with Fabio @ BLabs), Luiza Kataoka, and Pedro Yves. This is the team behind most of the grants delivered to Balancer to date (more on track record below), as well as continuously maintaining the tools we’ve built.

Track record with Balancer

Since 2023Q2, we’ve immersed ourselves in Balancer by developing multiple grants on Wave 8:

  • Vault Internal Balances Manager: an application to manage tokens in the Vault’s internal balance which is accessible here.
  • Stable Swap Simulator: a Dashboard to simulate Balancer Stable Pools Simulation in order to facilitate pool parameters optimization.
  • Twitter/Discord bots: Our bot delivering real-time metrics, including veBAL, about Balancer’s pools is live on Twitter and in Balancer’s Discord in the #metrics channel.
  • Pool Metadata: This tool allows easy and on-chain management of pool data to be integrated directly into Balancer’s frontend.
  • Balpy Vault feature completeness: We’ve also contributed to the Balancer Python package (balpy) by integrating the Vault functions that had not been accessible before.

We’re thrilled to continue our collaboration with Balancer. As we extend our work on the Stable Swap Simulator, we’re planning to integrate both Gyro Concentrated Liquidity and FX pools.

Should our ve8020 Launchpad proposal be selected, our plan is to prioritize this over other work as we see its potential to truly enhance the ecosystem. In this case, we’ll touch base with the grants committee about slowing down the pace on the Simulator if need be (since we don’t have exact dates about when the greenlight here would happen). We want to ensure we’re delivering our best on both fronts without stretching ourselves too thin.

The last months have been of great learnings and growth for us, and we want to give much of that back. We are committed to driving growth within Balancer, and the ve8020 launchpad project is a key part of our strategy. The groundwork is already laid with our proof of concept, so we’re ready to roll as soon as we get approval. We hope to have signaled with this proposal how much we’re invested in Balancer, as well as our capability to deliver this grant.

We’re keen to hear what the community thinks and are genuinely interested in receiving any constructive feedback or questions. Thanks for your patience, kindness, and active participation. That’s really what makes Balancer stand out. We’re ready for the journey ahead and can’t wait to further contribute to Balancer!

6 Likes
2

Solid proposal. I believe this hits all the requirements right on and is well-priced.

I’ve been working with a team from PrimeDAO on our VeFactory proposal - but we think that for the first version, this proposal is the right way to go for BalancerDAO. For now, we’ll abstain from submitting a proposal.

However, we’ve done early user research and have ideas for follow-up developments on a VeFactory. Happy to connect with the Blue team and share our learnings and ideas.

3 Likes
3

Thank you for the supportive words, Luuk. I think it makes sense to collaborate here. Would love to connect and learn more about your ideas on how to collaborate. Followed up on a DM to set up a Telegram chat!

4

Thanks for the well thought out proposal. Can you please clear up the following:

  1. Please detail the full scope of customization options being offered. Eg. Will the duration of lock be linear or stepped and what min/max ranges would be allowed? Token split?

  2. Confirm milestones and their payments are deliverables based, not time. And for absolute clarity, indicate payment to be sent at each milestone and a total for the project.

  3. With the work done to date with Balancer’s architecture, are there any aspects of this project that are known or potential unknown areas of difficulty/complexity that need to be overcome?

5

Hey @burns, thank you for your feedback. Let me address each of your points:

  1. Please detail the full scope of customization options being offered. Eg. Will the duration of lock be linear or stepped and what min/max ranges would be allowed? Token split?

Projects will have the freedom to set lock durations ranging from one week to four years, offering a wide variety of options to suit their specific needs. The reduction in voting power continues to follow the linear decay model, same as Curve’s and Balancer’s, where it decreases linearly over time. As for changing the voting power rule, it does represent an exciting future possibility. However, we believe it falls outside this proposal’s scope.

In terms of pool token weights or ‘token split’, we envisage this aspect being handled directly through Balancer’s own UI. Our role is to facilitate the launch of veTokens, while the Balancer UI is already optimized to help projects create their own Pools, which includes weight adjustments.

  1. Confirm milestones and their payments are deliverables based, not time. And for absolute clarity, indicate payment to be sent at each milestone and a total for the project.

We agree with tying payments to milestones. However, we designed our initial payment schedule to enhance the incentive for project completion and to cover operational costs during the project. Each payment does not directly correspond to the perceived value of each milestone. The total budget remains USD 29k, payable in BAL upon completion of each milestone.

Here’s a deliverable-based breakdown (also edited in the main post):

Milestone 1: Completion of Smart Contracts. Payment: USD 4k.
Milestone 2: Completion of Integrations. Payment: USD 6k.
Milestone 3: Completion of Launchpad UI. Payment: USD 9k.
Milestone 4: Successful Deployment to the chains that Balancer is in. Payment: USD 10k.

  1. With the work done to date with Balancer’s architecture, are there any aspects of this project that are known or potential unknown areas of difficulty/complexity that need to be overcome?

We see the main challenges arising from the project’s inherent complexity, not specifically from Balancer’s architecture. The two main challenges standing out for us are making sure both of our team are happy with the smart contracts themselves. Which is also why we developed a PoC initially – so that we can map out any roadblocks and gather early feedback. For example, verifying the blueprint contracts in Etherscan wasn’t as seamless as we’d hoped due to the ERC-5202 format. We’re actively exploring solutions to these and welcome inputs — we’re happy to altering our technical strategy and if a quick and efficient solution doesn’t present itself.

Beyond deployment, we see the challenge will be ensuring effective usage and management of the tool. This is going to be uncharted territory for us, so there’s a lot to be learned here and we definitely welcome any feedback and contributions. After ensuring that, in the ideal scenario, we foresee a growing backlog of feature requests from users post-launch. In fact, this second challenge is what excites us most – it’s an opportunity to get to know a lot of other projects and to continually refine the system.

Do all these make sense? I hope this addresses your concerns — happy to answer any other questions!

7

@bleu Puppet is looking to launch on Balancer, we have been working on a very similar ve8020 foundation, i would love to provide you some feedback if were to switch to your implementation and this proposal goes forward

would you mind if we create a focused group? itburnzz(telegram)

1 Like
8

Sounds great, interested to hear your thoughts! Just created a group chat with us on TG.

9

Thanks for addressing all these, we are going through and completing a final summary to share now the we have all proposals up. Can you please clear up a couple more things:

  1. What is the plan to cover FE maintenance (resources and cost) and is there a planned hosting duration? Will factories be available in the event that Bleu discontinues hosting?
  2. Are there any ongoing costs perceived that need to be covered outside of this grant or are any fees taken by the FE?
  3. Does this include the feeDistributor contract / is this what the “RewardsDistributor” contract is referring to? Are changes to this required? If so, an intermediary contract is needed to deposit.
10

Hey @burns, here’s a rundown:

Frontend Maintenance & Hosting: We’re committed to taking care of this as long as we can. Should circumstances change, the open-source code on GitHub ensures anyone can step in. We see covering deployment and ongoing frontend costs as part of our commitment to the ecosystem.

Ongoing Costs: No fees are to be taken by the frontend, and we don’t see any ongoing costs to be covered by Balancer outside of this grant.

Contracts: “RewardsDistributor” is indeed our “FeeDistributor”. The PoC shows that it’s the point for depositing tokens, ruling out the need for new intermediary contracts. We do see an authorization system as necessary to manage deposits effectively. Did you have anything else in mind?

Hope this makes things clearer. Happy to delve into any more areas you’re curious about!