[BIP-84] Revoke Hexagon's Friendly Fork Status

[gerg]

We should maintain a high standard for friendly forks, otherwise the designation is meaningless.

Motivation

The governance vote approving Hexagon passed over four months ago. Immediately following, Symmetric was denied FF status on the grounds of not yet having a product/deployment to show; Hexagon was not revoked at this time out of respect for governance’s decision. In those four months since Hexagon got their FF status, they have still delivered nothing.

Furthermore, their airdrop eligibility requirements for BAL holders revolved around mandatory twitter/discord/tg actions, which is tasteless and spammy, and also links on-chain addresses with public accounts while many users wish to be anonymous.

As far as I have seen, Hexagon has been extractive vaporware diluting the Balancer brand. I encourage them to prove me wrong, but I would currently advocate for revoking their status, and allowing them to reapply when/if governance decides to re-allow them.

Specification

Revoke their status. As far as I am aware, this is purely a social agreement. If there is on-chain action needed, please bring that up in the discussion

Pros/Cons

Pros

• Un-dilute the brand

Cons

• Drama
• I’ll probably be called a jerk by the Hexagon team et al.
• Reading through excuses. inb4 market downturn, UST implosion, didn’t raise enough money in FLAKE LBP (92.55k USDC)

Disclaimer: All opinions my own

[Hexagon]

Hi Gerg and hello to all the community,

We regret to read you believe our friendly fork status should be revoked, although we understand where you are coming from and can only commend your desire to protect the Balancer brand.

Please allow us to explain our position and introduce the exciting developments that have taken place over the recent months.

First of all, there is not one, but a couple of simple reasons why the platform has not been launched yet.

On the one hand, as you anticipated, the collapse of Terra has deprived us of a key backer – along with its large liquidity commitment, as well as marketing support, both of which we saw as important advantages in terms of user acquisition when we initially embarked on this project.

Another concern – again foreseen in your post - are the overall market conditions, with TVL and prices dropping across the board and uncertainty spreading within and beyond the crypto world. These headwinds will likely make it extra hard for any project to build up liquidity upon launching.

(On the other hand, the LBP results, heavily influenced by the Terra collapse happening exactly at the same time as the pool was opened, have had no bearing on the delay. We would also like to reassure you no one has called you a jerk or wants to instigate any drama.)

All of this convinced us that a better solution would be to bide our time and wait for the markets to stabilize while focusing on a new go-to-market strategy, concentrating all the efforts on a novel type of boosted pool that will include all of the rewards from the interoperable protocols. For example, the boosted pools will be able to capture both the interest and the AVAX rewards from AAVE and Benqi on Avalanche.

We are confident users will love this new feature, setting Hexagon entirely apart from competitors.

This development has required a pretty significant amount of work to further build upon the current Balancer contracts and make the front-end compatible with the new boosted pools. Especially so when it comes to including the mining rewards from the other interoperable protocols and making sure both the metastable and weighted pools are all boosted.

Thankfully, our team has worked tirelessly and is now pretty close to completing the project.

To be more specific, the devs have almost finished the work on:

•  Developing the aforementioned new type of boosting mechanism, in order to include all of the rewards from the interoperable protocols.
  

•  Interoperating AAVE V3 on Avalanche.
  

•  Developing a boosting shifter mechanism, to enable the reward-accruing shifting from one protocol to another. For example, the boosted pools will interoperate both AAVE and Benqi on Avalanche. Therefore, it will be possible to shift the accruing of rewards from AAVE to Benqi or the other way around if one protocol’s rewards are significantly higher than the other in just one boosted pool.
  

•      Developing the weighted boosted pool and perfecting the BatchRelayer SDK, making it possible to have an AVAX/USD boosted pool, with both AVAX and USD being boosted, as well as other similar pairs.
  

•      Developing and adapting the metastable boosted pool, making it possible to have an AVAX/SAVAX (staked AVAX) boosted pool, with both AVAX and SAVAX boosted.
  

•      Adapted the ERC4626 linear pool
  

With this in mind, we are now close to setting a launch date, which in our plans will happen at the end of August.

We would certainly appreciate it if we could retain the status of friendly fork till then since we are now so close to taking off – losing it now would hardly do anything good for Balancer and would certainly be detrimental to us.

Powered by the Balancer model and adapted by our engineers, Hexagon can – even in spite of the Terra issues and the market dynamics – be a success, bringing a new tool to Avalanche and, far from being vaporware, spread awareness about the Balancer brand in a new and vibrant ecosystem.

After all, certainly, we can agree that a delayed but successful operation is a far better outcome than a rushed and failing one?

The Hexagon Team

[gerg]

First to address this:

We would also like to reassure you no one has called you a jerk or wants to instigate any drama.)

I fully agree that no one has, and in fact I even amended my original tongue-in-cheek comment to make it more clear that it was something I expected rather than something that happened, but since I am proposing to remove your status, I’m not expecting you to be terribly fond of me.

Back to the core of the issue:

I view achieving FF status as a carrot on the end of a stick. I believe your team having FF status is unfair to teams like Symmetric that are building just like you are, but without FF status. My personal impression is that your governance approval passed because the BAL voters expected that those pushing your proposal forward had considered it on-par with BeethovenX, and did not realize that you did not have a live product.

Do you think it’s fair that you have FF status while Symmetric does not? I don’t. And don’t get me wrong – my intent is not at all to say “screw you guys.” My ideal scenario is that we revoke your status (which I would argue you should have waited for from the beginning) while you are still building, you keep building, you deploy something great, everyone sees it, and says “yeah awesome, let’s give these folks FF status.”

My biggest gripe here is with Balancer governance process, the lack of requirements for FF at the time of your vote, and the fact that people vote blindly without really digging into what they’re voting on.

This is not just a discussion between your team account and me, this is for the Balancer ecosystem as a whole. I encourage other people to join this discussion.

---

In response to the other items

• Regarding the stuff you’re building, I’m happy to hear you’re working on new and exciting things, but no one would know you’re working on anything other than your farm based on your GitHub.
• You did not address the FLAKE airdrop requirements which amount to buying social media engagement, which I don’t think is right.
• That’s great that you think you’re launching soon; I’m excited for you. Realistically though that doesn’t change my perspective; that date can very easily shift back.

[solarcurve]

All things considered I think revoking the FF status is justified. I did originally vote in favor as there were marketing plans put into place with high profile backers (Ava Labs, Terra) that needed a quick approval vote so it could be announced at the AVAX conference (if I recall it all correctly). Since then plans obviously changed. It’s great that Hexagon has continued work but I think it is appropriate to revoke the FF given the large amount of time that has passed since the original proposal without a launch. After Hexagon goes live it will be easier for the Balancer community to assess if a FF makes sense.

Back in the day when BeethovenX first started some people wanted a FF deal with them immediately. I pushed back saying an anon team with zero reputation has to prove themselves first before it’s worth the risk to Balancer’s reputation. In those first couple of months after their launch I interacted with them quite a bit and saw they were the real deal - then we did the FF. Gerg is 100% correct that this is the way it should be done - not the way we did it with Hexagon.

This vote would set a clear precedent for future friendly forks - that they must have a live product before they can be considered.

[Andrea81]

Hello everyone,

I’ve been following this conversation and hoped for more comments to pop up.

Greg, thank you for bringing this up and I’m sure the vast majority here would not consider you a jerk just because you express your opinions openly and frankly. That’s exactly what is needed!

Just a couple of thoughts:

Do you think it’s fair that you have FF status while Symmetric does not? I don’t

When assessing a scenario like this, I would suggest sticking to frameworks/proposals. Symmetric didn’t get approved as a FF because the proposal was rejected by BAL token holders. Whatever the majority of BAL voters decides, then it is implemented. Not sure if this falls into the fair/unfair category but it is the framework we all adopted until today.

the fact that people vote blindly without really digging into what they’re voting on

Would you mind supporting these claims? Why do you think this? If BAL token holders didn’t “dig enough”, what was the cause of rejecting the Symmetric FF agreement then? I’d like to know more and understand your line of thoughts.

Just as a reminder, some considerations were made on the proposal to help the voter making an informed decision:

Weaknesses

• Making UST as the main focal point can be a double edged sword for two reasons:

1. focussing on one stable coin creates an overexposure that some would consider unnecessary in terms of point of failure;
2. the general missing of potential trading volume on alternative pairs.

• While the BeethovenX Friendly Fork agreement has been reached after launch, in this case, the agreement should be reached before. Consequently bringing a certain level of uncertainty. However, the Partnership subDAO believes that risks have been reduced considerably given the deep due diligence done on the team and the partners involved in this collaboration.

The DeFi landscape is still in its early stages and layers of uncertainty are very much present, especially in today’s market conditions. A constantly evolving market generates certain known unknowns and a level of unpredictability that needs to be taken into account when operating in cutting edge environments.

As per solarcurve comments, while respecting his opinion (which I’m sure is honest), I would have preferred him to abstain from commenting, this is given his position within BeethovenX and the potential conflict of interests that could emerge.
My concern here is removing the FF status from Hexagon to then offering the Avalanche market to Beets. Balancermaxis have enough voting delegation to technically make this move. I’m sure this is not the case, but for transparency I would have preferred no comments/abstaining from voting in case this RFC goes to snapshot.

All in all, I think the RFC is fair and this is a good discussion to have.

My honest opinion is that Hexagon has not much to lose here as the FF model, as it is today, just gave a rubber stamp which is nice to have but not necessary.

Eventually, what makes the difference is the team and the quality of the product they intend to deliver. And I’m sure Hexagon has both.

One last point: I’ve seen some mentioning regarding brand dilution: In my humble opinion, the FF program also serves to protect Balancer as these agreements prevent any stepping on each other’s toes or vampire attacks. This is particularly true today, as veTokenomics still need to be proven for projects operating multichain like Balancer.

Revoking the status would not prevent the Hexagon team from competing directly with Balancer on other L2s, exactly where it would hurt the most. Not an ideal scenario. Again, just some personal thoughts.

[Mike_B]

I believe that the friendly fork status should be revoked for the time being.

It was mindblowing to me how they were encouraging BAL users to bridge their assets to avax in order to receive the “airdrop” which coincided with the launch of veBAL, forcing users to choose whether they want to lock into veBAL or get the Hexagon distribution. In what way is this friendly? In addition, there were obvious engagement manipulation on social media platforms which was really offputting.

I personally believe the way we were pushing for friendly forks was doomed to fail. There is just not enough of an incentive to deliver. Beethoven worked because the team launched their product with no expectation from us and have made significant contributions to the ecosystem, particularly around boosted pools and the SOR. They impressed us, and only after that did we grant them friendly fork approval. We are very lucky hexagon had not launched and attracted members of the Balancer community who would have subsequently lost everything to UST.

Having a non functional friendly fork designation on a chain simply discourages any other teams from attempting it. Going forward I think it’s fair to demand there be a live deployment that meets minimum metric requirements before being designated as a friendly fork. Right now it feels like we gave away our marketing resources and brand name for nothing in return. This is our only leverage to make sure projects do what they are supposed to do under the FF framework.

I would be comfortable revoking the friendly fork status with the caveat that the Hexagon team can reapply once they are up and running. If the project depended on the friendly fork designation to survive, maybe it wasn’t meant to work out at all.

[gerg]

When assessing a scenario like this, I would suggest sticking to frameworks/proposals. Symmetric didn’t get approved as a FF because the proposal was rejected by BAL token holders. Whatever the majority of BAL voters decides, then it is implemented. Not sure if this falls into the fair/unfair category but it is the framework we all adopted until today.

Yes, I obviously understand that the majority of BAL voters approved Hexagon and rejected Symmetric. There is no well-defined FF framework, which is why I’m bringing this issue up. I laid forth a preliminary list of things that I would consider requirements in the Symmetric thread, but they have not been formalized.

Why do you think this? If BAL token holders didn’t “dig enough” , what was the cause of rejecting the Symmetric FF agreement then?

Did I perform an exit poll of why each voter voted as they did? No. But in my opinion there was a hell of a lot more discussion on the Symmetric proposal because Hexagon passed. See my post in that thread here. In that forum post, you argue that the primary backlash to Symmetric is capital allocation while I argue it’s the lack of product. It seems that we disagree on that point.

FWIW, I also had an issue with the capital allocation, but my primary concern was (and continues to be) lack of demonstrated product.

As per solarcurve comments, while respecting his opinion (which I’m sure is honest), I would have preferred him to abstain from commenting, this is given his position within BeethovenX and the potential conflict of interests that could emerge.

I’m glad you joined the conversation here, but to be fair, couldn’t he make the same exact argument against you?

For full disclosure:
The Hexagon team has offered Andrea a token allocation equal to the 0,0012% of the total token supply as a thank you gesture.

Regarding this:

In my humble opinion, the FF program also serves to protect Balancer as these agreements prevent any stepping on each other’s toes or vampire attacks.

Sure, it prevents stepping on each other’s toes, but doesn’t approving one FF implicitly prevent/deter other teams from doing so on a given chain? What if there was another team that was considering launching on Avalanche but saw we already gave that rubber stamp away? What if that team was able to execute more quickly/effectively? It shouldn’t be a race to who can apply first, but who can deliver first/better.

[eaglelex]

This is a very important discussion concerning the present and the future of the FF program.

Undeniably, Hexagon has not been lucky in trying a token launch exactly the same day of the Terra collapse back in May, but I tend to agree with @gerg @solarcurve and @Mike_B (although on the basis of a different motivation).

First, I want to clarify that I totally agree on a basic principle: in order to get a recognition as a FF it is fundamental to first deploy the product and show its quality. I think that this should be applied in any case and for every team. For example, we all agree that BeethovenX is a very good product, nevertheless if the Ludwigs would like to expand to another chain I think that the FF status for the different chain would require a new vote. Every chain has different starting conditions and the assessment of Balancer’s interest requires every time a new vote.

This is important, but it is not the reason why I consider that the FF status of Hexagon should be revoked. Rules on FF were not clarified, the new team acted in a legitimate way in pretending the FF recognition, and got a governance vote in favor. In this regard, I also don’t see the point – as indicated by @Andrea81 - of discussing issues concerning Symmetric in this context.

To me, a new vote is necessary on the basis of the change of circumstances theory (in German Wegfall der Geschäftsgrundlage). Hexagon presented itself with a strong support of Terra and Ava Labs. The community took these two elements strongly in consideration at the time of voting. These conditions do simply not exist anymore and this makes the value proposition of Hexagon as FF impossible to evaluate.

I really hope that the @Hexagon team will have a lot of success on Avalanche, but at the moment Balancer DAO has no basis to evaluate the capabilities of the new team. In my opinion, the situation would not be different also if Hexagon would have presented a precise roadmap about the next steps, the deployment and the token launch. The conditions on which the DAO has voted back in March do not exist anymore and the FF status needs to be revoked.

[Andrea81]

I’m glad you joined the conversation here, but to be fair, couldn’t he make the same exact argument against you?

The Hexagon team has offered Andrea a token allocation equal to the 0,0012% of the total token supply as a thank you gesture.

Man I can’t wait for those bad boys to finally unlock and move to the Bahamas. I was really hoping to get away with it…

[gerg]

lol

still though, there’s a parallel

[Bobbay_StableLab]

Balancer has been trimming its hedges a lot recently. We have outlined a few reasons why we believe FF should be revoked.

1. Setting a standard

We share a similar sentiment to eaglelex and Solar, and believe that FF’s should only be approved once we have seen a successful deployed product rather than providing hype to projects that might fail to reach the finish life. In this case, it feels unfortunate to revoke FF status before a launch. Still, after considering various factors that we will outline below, we believe Hexagon should have their FF status revoked.

FF should only be given to live and successful products that portray Balancer in a good light. We should have expectations for our FF’s.

2. Loss of high-profile support

With the loss of their support, the team isn’t necessarily going to do worse, but if we approved a FF with the knowledge that they had AVAX and Terra behind them, it does change the situation significantly.

These types of support can be essential to launching a protocol, and without that support, it is hard to gauge whether they are FF-worthy. We can make that decision post-launch.

3. Airdrop requirements

To have FF status, then make BAL holders complete x amount of tasks otherwise, they will be disqualified is not exactly how a FF should work. It should be more of a collaboration rather than making BAL holders do certain tasks which are social-farming.

[gerg]

I wanted to just type “bump” but apparently there’s a minimum of 20 characters

[Xeonus]

We had extensive discussions on this topic and my understanding is that this could go to a vote soon. However, this is an RFC and not a properly written proposal IMO. @gerg would you be willing to formulate a proposal? We could potentially send it to snapshot this Thursday, Oct 6th. What do others think?

[Bobbay_StableLab]

sounds like a plan, community sentiment seems to be in favour.

[gerg]

Motivation

The Balancer Friendly Fork framework came about to encourage teams to deploy Balancer V2 contracts, subgraph, and a frontend for chains on which the Balancer DAO has not prioritized. The framework is meant to benefit the deploying teams with a seal of approval and the Balancer DAO with a revenue/token split. Ensuring benefits of a friendly fork should be a high priority for the DAO.

The governance vote approving Hexagon passed approximately seven months ago. Immediately following, Symmetric was denied FF status on the grounds of not yet having a product/deployment to show; Hexagon was not revoked at this time out of respect for governance’s decision. In those ~7 months since Hexagon got their FF status, they have still delivered nothing and communicated nearly nothing other than what was said in this forum thread.

Proposal

• Revoke the Hexagon Friendly Fork existing designation, but do not bar Hexagon from re-applying when/if they have a delivered a full deployment
• Formalize the requirement that teams applying for FF status must have a functional deployment consisting of core contracts (w/ identical bytecode), subgraph, and frontend before applying

Core contracts include:

• Vault, (Timelock) Authorizer
• Weighted Pools
• Composable Stable Pools
• LBPs
• Linear Pools (if appropriate external protocols exist on that chain)
• Boosted Pools (if linear pools are deployed)

Implementation

Since Friendly Forks are social agreements, no on-chain actions are required

Specification

Again, no on-chain actions are required

Disclaimer

All opinions my own

cc: @Xeonus

[Xeonus]

https://snapshot.org/#/balancer.eth/proposal/0x8f506c72f20ca4616d6e84651aa28e93ef44957e982b66ef227b76ccc398a5b0