Community Pool / Governance Pool

I would like to tackle two problems:

  • Lack of incentives to vote.
  • Lack of community-governed development fund.

Taking inspiration from YFI I would suggest the following solution:

Set up a community pool that would incentivize users to behave in a certain way

  • % of rewards would go towards participants in the voting process.
  • You can stake vBNT but you do not get rewards unless you have voted for the last proposal (same as Kyber).
  • % of rewards would be distributed via voting to developers and other relevant network participants that would be responsible for the curation of the Bancor Network.

Fees collected:

There are two ways of fees collection:

  • 0.5% of the exit fee - applied to the liquidity provided when leaving the pool. With 0.5% exit fee, most of the pools should breakeven after a week or two.
  • 2% annual management fee - 2% of all the fees collected on the network annually would be gathered to the community pool and governed by the community in voting.

Exit fees will be applied to liquidity providers when leaving the pool by confiscating Pool Tokens he/she provides in order to withdraw their position on the Bancor Network.

For the sake of development simplification, the management fee will be applied the users in a similar way. When the liquidity provider is leaving the pool 2% of fees will be confiscated in form of Pool Tokens.

Pool Tokens will be liquidated, TKNs will be converted to BNT and send to the Community Pool and Governance Pool

Firstly, I would suggest voting on the 0.5% exit fee that would collect 50% to the Governance Pool to speed up the decision making process. Another 50% would be collected to the Community Pool. The % distribution can be change anytime based on the protocol’s current needs.

Secondly, after discovering the protocol needs, management fees.

Overall two BIPs.

1 Like

My feedback is include a financial incentive for LPs to accept a proposal of introducing an LP exit fee by allocating part of it to the LPs which have not yet exited.

Then the question will be how much allocation for long term LP stakers and how much to serve the network, in your example for governance incentives and development.

The first baby step is for LPs to accept an exit fee for prioritising long term stakers, over shorter term stakers. A much bigger step is to ask LPs to give up some of their rewards to the betterment of the network. Maybe LPs will be ready to give away 100% of their exit fees, or maybe 50%, or 30%?

I agree that the voting needs to be addressed.

I am on board with the sort of policies you are proposing. There are two additional points that might be worth considering if the next BIP is addressing voting:
i) Signature voting (requires nearly zero gas, and will be used by Aave governance)
ii) Vote delegation

Everything being discussed here will require additional changes to the protocol and the contract. We will also need to model how paying voting rewards will bleed value from the pools. It could be that rewarding voting is a massive liability. It needs to be investigated either way.

While the existence of a community-governed development fund seems imperative, I’m not sure if at this point in the initial LP onboarding process it’s the wisest thing to add these semi-hidden exit and management fees. Already we have some skepticism around the IL insurance coverage and adding further mental barriers for LPs to take the plunge might hinder the initial adoption we desperately need. Once the protocol proves itself both in IL coverage and fees generated, I think it will be a much easier sell.

Could we perhaps use the co-invested profits from the BNT side and instead of burning them add them to some pot for use in different areas?

For example:

  • 25% to keep in some insurance fund as a show of confidence to all LPs that the protocol is capable to payout IL costs without falling into a potential negative inflation spiral in the case of a catastrophic event ( Binance’s SAFU fund and Bitmex’s insurance fund accomplish something similar). These can then be repurposed at a later date when trust in the overall system is established.

  • 25% to pay out to those participating in governance votes.

  • 25% to use for marketing and promotional uses that could be needed in future BIPs.

  • 25% for use for grants and other labor cost uses that could be needed in future BIPs.


I agree with this. A community-governed development fund is certainly something we should be talking about, but it may be premature to have those talks now.

It seems that we are still in the process of establishing a governance method. The proposed changes in BIP3 are seeking to address some key weaknesses, identified immediately after launch. The ideas in BIP3 have been well-received so far, and I imagine it will probably pass.

Addressing issues with voting could be a natural progression in the governance improvement narrative; BIPs regarding fees, community dev funds etc will need to be informed by activity on the platform and the V2.1 behavior, and should be carefully modelled. As the system is so fresh, any proposals that touch on these components are naive until we have more data.

Voting issues, on the other hand, we can confidently make decisions on - at least with regard to what we like, what we don’t like, and what we want to see done. Bare in mind, some changes might seem trivial, but could be a profund change in the way the contract is coded. Therefore, I think it might be time to filter our concerns down to something manageable, and ask for commentary from a Bancor dev.

I am glad that vote delegation is uncontroversial, so let’s put that item on the list. For reasons mentioned above, I think a discussion on voting rewards is premature, but maybe we can discuss other technical solutions to trivializing the cost of voting. Is there anything else you think is critical, and that we are in a position to make considered choices about in the immediate future?


Thank you for your relevant feedback.

Let’s push the discussion to the later stages.

In regards to modeling, after we agree on general design I will focus on analyzing relevant data and providing model and proves.

Management fee indeed has to be well thoughts, that is the reason I proposed it in later stages after heaving some more data about exit fee profitability.

Exit fee is proven working, it penalizes users for leaving earlier which decreases the churn rate. We can always start with the lower rate such as 0.2%.

However, since you feel like it has negative feedback as a penalty and would have an inverse effect on adoption, let’s focus on more relevant items and come back to the discussion later.

Maybe it is better for now to have less people involved in governance so it is easier to achieve consensus here.