[Proposal] New grant to incentivise SOR integrations ( eg aggregators, wallets)

Governance General Proposal
1

Summary:

Proposal is to provide a consistent framework to incentivise third-party providers (eg. wallets, aggregators) in onboarding Balancer V2 SOR.

Background/ Painpoint:

We know its true. Every dev team worth its salt has work sprints packed to the brim. Typically, teams prioritise workflows based on whether the end result can bring the biggest impacts to their dapp or, simply (you know), choosing the low lying fruit. This means dapp integrations which fall in the “good to have” range are often neglected.

Especially recently, free flowing grants and liquidity mining dangled by foundations have aggressively competed for dev time. We see this where multiple or complex cross-chain deployments are increasingly common and faster. Naturally, the implications are SOR integration like ours tend to lose out.

For context, Aggregator integration (eg. Paraswap, 1inch) and wallets/dashboards have been slow or work in progress.

TL:DR: Balancer V2 integration is an uphill task and grants will help even the playing field.

~~
We believe any relationships originating from this program to be synergistic and recurring with the market trend toward multichain deployments. Balancer will have closer partners that are more willing to prioritise us in future deployments. Native projects in future chains are incentivised to reach out to integrate, thus saving us time and effort.

The vesting terms are to ensure that the integration is completed with good quality and includes a decent duration of “after-sales support”.

The proposed grant amounts and terms are benchmarked against 3 points: (1) integration effort needed (2) current grant structure, (3) our Ballers remuneration structure

~~

Key Areas:

Third party integration could be in the form of DEX aggregators, wallets or other SOR (smart order routing) use cases.

Timeline:

Engagement starts when both teams are agreeable. Could be backdated, but of course terms will be adjusted accordingly.

Terms:

One off 3-5k BAL grant vested 2 years with a 1 year cliff.

~

As usual open for discussions :slight_smile:

1 Like
2

just to be clear, this proposal authorizes an unlimited number of grants under the terms of “3-5k BAL vested 2y with 1y cliff” correct? So no limit on how much BAL can be spent on this program + no expiration of the mandate here.

Other question is who’s in charge of authorizing these grants? Blabs, you, grants committee, or?

3

Would it perhaps make sense to have a total amount of BAL set aside for this, managed by the grants committee? So the grants committee manages say e.g. 20k more BAL for this purpose, issued as vested rather than liquid.

Would be too much BAL to take away from the existing grants budget, but that might be a good way to approach it.

Edit: to be clear I support the proposal, just details about who manages it / how it’s budgeted for/constrained missing I think.

1 Like
4

Agree with @DavisRamsey and @bakamoto20 to put in some ownership and limits.

On amount: 30k BAL seems like a good number to start as it onboards us 6-10 quality integrations ( that should help us cover ~70% of the entire ecosystem IMO).

On ownerships: My first instincts are to delegate this grant ownership to the grants community. Everyone in the community can pitch to them to unlock these funds. Ideally, we can also approach L1/L2 foundations that we are currently integrated (eg polygon) to highlight this grant and ask them for recommendations.

1 Like
5

My initial thoughts is we don’t want to be biasing specific partners over others. I can’t imagine why the committee would ever vote against third party providers. If anything we would be welcoming them!

Given this, I would say the only concern would be if we ran out of budget and had to decide which projects to choose - if this is the case then let’s simply agree to increase the amount of BAL the grants committee has access to when we hit this limit. I think it’s too early for us to be super structured in how we will distribute the grants and we will soon find limits in this methodology (similar to our LM constraints)

1 Like
6

I understand this proposal the following way:

  • protocols can apply for a grant to integrate SOR into their Dapp. If their proposal is accepted they receive BAL tokens in return (vesting terms apply)
  • This would effectively increase the “business value” of an aggregators epic called “Balancer integration”

Let’s say the vision of an aggregator would loosely be “Offer best prices for our users across highest used chains”

Does the SOR integration help the aggregator work more more towards his vision? I think so: The aggregator can either offer a wider range of assets or a more competitive price. So to me this proposal is generally beneficial for aggregators and the Balancer protocol.

Say the deliverable is a working integration of the SOR into an aggregator dApp. If this is achieved within 3-6 months, how do we achieve the maintenance of the integration and “after-sales support”?

Limiting these grants to a fixed amount of BAL (aggregated) also caps our risk. I support this as a good initiative.

1 Like
7

Only thing I’d add is I don’t think any relevant aggregator/wallet is going to approach us asking for a grant. These projects are all giga rich, and a smol grant they don’t have access to for 3 years doesn’t strike me as much motivation for them.

It’s going to be on blabs or the grants team to seek these ppl out and offer the grant. And again, do these ppl care about ~100k they can’t access for 3 years when their treasuries are in the 8 or 9 figure range.

Certainly doesn’t hurt to try of course.

1 Like
8

Great points everyone!

I agree with @tongnk and would simplify things by sticking to a fixed amount of BAL.

Also agree with @DavisRamsey that these are all super successful projects (we are talking about wallets like Argent, aggregators like 1inch/Paraswap/Matcha). We should probably do our homework and go after the ones we believe are a must have for Balancer. I think there are 6-10 of them but that could be a longer debate.

My suggestion would be, why don’t we increase the amount so that it’s substantial even for these teams, and that has the nice effect of making them staked in Balancer so that they will always have a tendency of considering us a special partner if future integration work is required for some reason (Balancer will keep shipping and innovating faster and faster). I would propose 10k BAL for each of them, but instead of a 2 years vest with a 1 year cliff (which would mean 5k liquid overnight a year from now), I would do a vesting that only starts in 1 year and ends in 2 years (so they have 5k liquid in 1.5 years).

This new vesting schedule would ensure there is less of a risk of dumping as the BAL will be made liquid continuously. But really, the expectation IMO we should convey to these partners is that we would like them to hold long term and ideally let their communities vote on what to do with these BAL when they become liquid (as opposed to a centralized decision). For all integrators that don’t have a DAO (did not launch a token yet) the expectation is that once this happens the BAL is transferred from the company to the DAO.

We still have over 4.75M BAL in the ecosystem fund as of now, I think spending 60-100k of that with alignment of incentives across the most crucial partners for Balancer is a no-brainer. We need these partners to get more volume, which will make us more relevant and intensify the network effects that IMO will make Balancer extremely successful (see my vision for Balancer).

In terms of process, to simplify maybe we could discuss who these partners are and make a list, then vote specifically to approve the grant for this list. This way we would not take away bandwidth or BAL from the grants committee which has been doing an amazing job at hashing out grants and giving them away. Maybe we would need a group of people to clarify what are the requirements/expectations for each of the partners to receive the grant (it will be different from case to case). That could be a temporary “Integrations committee” or something like that composed of a few technical members that know Balancer well.

Thoughts?

4 Likes
9

100% agreed on all of it

2 Likes
10

Agreed with @Fernando. Though question is do we have existing relationships already? If so I’d suggest potentially we just vote to increase grants committee allocation and we spin out a subcommittee from that for this integrations piece. Might help with coordination potentially?

2 Likes
11

That can work @tongnk , ideally we want to approach the integrations dapps with a “plan in hand” rather than going back and forth with grants application and approval.

12

I’m a bit late to this discussion, but I do not think it’s a good idea to pay for integrations with aggregators. Frankly, it comes off as weak and/or desperate. Aggregators whole purpose is to get the best price across various dexes and they are usually pretty aggressive at adding meaningful liquidity sources. I’m not aware of any other DEX that has had to pay to get integrated in an aggregator.

We know the major aggregators, such as Matcha and 1inch, have previously integrated directly with individual Balancer pools. Those pools were both much smaller at the time and in theory implied more manual work and ongoing maintenance than integration of the SOR. If integrating something that is supposed to be easier, require less maintenance, and provide better pricing isn’t attractive to aggregators already, then I suspect there are other issues at play that a grant won’t help. For example, do we have robust documentation of the SOR? Does it provide high enough reliability and low enough latency for the needs of the aggregators? I would spend some time talking to the integration engineers at the top aggregators to understand their requirements before jumping to offering grants. LMK if any intros there would be helpful.

3 Likes
13

Thanks Dan, all very good points.

My suggestion then will be the following: BLabs will be closely working in the next couple of months with the aggregators to better understand their needs and make sure we can offer all they require to seamlessly integrate all new pools that will be added to Balancer V2 as new partner projects launch.

If we feel that it’s inevitable that they will have to spend some time integrating with new Balancer pool types, then I can come back here and lay down the case for giving them grants (which I do think can be a good option, especially if it’s vested long term as suggested, making them aligned with us for the long run).

2 Likes
14

Adding to what @delitzer mentioned already, is there any hard data to back up these assumptions? We recently completed a project that instruments the performance of Uniswap V2 router and publishes the results when it does well and when we found a better route: https://playground.valve.finance/dashboard, and a tweet thread that breaks it down further: https://twitter.com/getsimpleid/status/1435227689468715015?s=20

If there’s interest from the Balancer community, we can extend this tool to support Balancer SOR. It would not only help improve SOR performance but also make a clear case as to why it should be integrated by partners.

2 Likes