Honeyswap roadmap planning call Nov. 23rd

[eenti]

Hey everyone

So, as some of you may remember I posted some ideas on the use of Honeyswap as a tool for Gardens almost a month ago Honeyswap alignment with Gardens and I’ve been pushing to try and get Honeyswap rolling again, and we finally had a conversation about the future of Honeyswap and some other settings at 1Hive.

There are a lot of things to define still but here’s a brief summary of what we talked about:

• We are looking at tweaking the interface a bit to bring it closer to 1Hive’s visual line.
• While trying to algin the efforts of all 1Hive, taking Gardens as a critical piece of our future, we’re looking to include Honeyswap as a tool for communities to incentivize and achieve deep liquidity with 1Hive as a strategic partner to help them along the way.
• We consider that the strategy of focusing Honeyswap on Gardens means that communities build TVL and their users generate volume.
• We explored the possibility of reforming or eliminating COMB altogether and using HNY in a controlled and intelligent way.
• The protocol fee that was normally destined for the common pool will now be sent to Tulip’s multisig to cover maintenance and other expenses.

Here are some diagrams taken from the presentation that illustrate some of the proposals

We also talked a bit about the motivation and how we would go about it, it’s important to remember that we can be very ambitious and think about a lot of things to do, but due to the lack of human and economic resources and the little interest in DeFi per se from the community, I wanted to focus the call on getting the most out of Honeyswap with as little effort as possible and making sure it aligns better with our high-level direction so it stays relevant over time. At least for now, I’m taking care of coordinating the work to the best of my extent with Hernando and Striker who are willing to put some work into this. We’ll see how to and if we can bring some more people in.

Here the slide and recording of the call: Honeyswap Roadmap Call Nov 24 - Google Drive

But not everything was about Honeyswap, within the framework of this call it was inevitable to talk about other problems that have been surrounding us.

We talked about how we operate, we like to experiment a lot but most of the time we don’t have plans to maintain what we’ve invested into, we really need to be more responsible about what we do. This is the reason I suggested that Tulip Swarms receives Honeyswap’s protocol fee directly to use it for maintenance.

The other big point on the call was Pollen and how it has been a tremendous expense over time that perhaps isn’t giving the expected results, for now we agreed to reduce de distributions to 5HNY a week and there are discussions to keep improving the policy and ensure that the distribution truly translates into more contributions and engagement.

We talked for a long time and I’m sure I forgot something, any questions or comments please let me know and I’ll gladly answer.

P.S. This is just a small recap of the meeting, we will post a concrete plan as soon as we know what exactly we’ll do and what we would need.

[metaverde]

Calls to use Honeyswap income to maintain Tulip is what caused the schism to begin with.

[Ariez]

I’d like to see model #1 been tested out or implemented.

[eenti]

I think the issue itself was that the community overall did not want Tulip to have such a competing or complex compensation scheme, not with the fact that it would use protocol income to do so.

Anyways I think we can sort of agree that it’s super relevant that we ensure we can mantain protocols overtime and with Honeyswap generating income I think it’s only fair.

[freiheit]

I would suggest to have an informal agreement among community and swarm that a certain percentage of the fees going to the Common Pool will be reinvested in Tulip Swarm, with a cap of (just a rough figure) 15k usd per “full time” Tulip Swarm member per month.

Incentive to the Tulip Swarm should still pass as a proposal having Celeste arbitration.

Such an agreement would help the DAO and the swarms to stay as permissionless and open as possible.

Most web3 project nowadays are organized with infrastructures that replicates corporations. At some stage the builders working at those project will realize that they are being exploited by the “founders” and venture capitals that funded those projects. (see Uni or Aave token distribution, just to make an example)

When this will be realized (and that will happen) a project like 1Hive will be recognized by the broader web3 community like a best practice in horizontal organization, and we need a mechanism design that can incentivize new builders to join.

[cryptoclip]

Maintaining honeyswap isn’t really a full time job though, for bug fixes right? $15k USD per month seems like a huge amount for maintaining a product that is already built. Should be lower for bug fixes, and then new feature development paid by bounty/upfront agreed fee that is paid when the task is completed and verified.

[freiheit]

The rough figure I proposed was for a full time equivalent.

Having that incentive model would allow Tulip swarm members (or new members coming) to have an incentive if they want to work at improving Honeyswap and 1Hive DeFi tools.

One of the question we should ask ourselves as a community is:

• Which kind of incentives could 1Hive have to encourage talented builders working for corporation-like crypto projects to leave the projects they are working on to experiment the thrill of working for a real decentralized organization ?

Our asset (that to me looks insanely undervalued, and thats why I like to buy honey in the market these days) is being one of the few projects that are really decentralized and permissionless.

[eenti]

Well I don’t think that’s particularly the best way to go about it as we probably wouldn’t be able to do that for every single swarm/product that may come up. IMO we should find a solution at the 1Hive DAO level like maybe hiring a full time team that should be able to help and maintain whatever we do.

As far as Tulip goes, I’m thinking the best way is to keep the revenue from Honeyswap and ask for funds from the common pool as investment until we break even and make enough to at least support maintenance and all that, at the end it would be an independent project that happens to use HNY as their preferred currency and of course part of the broader 1Hive ecosystem.

[freiheit]

One problem with the full time team is that Quality Assurance is a pretty complex matter. For sure we are heading in a direction that will allow to have a lot of decentralized tools to assess quality of work, b ut the the moment having incentive models linked to KPIs (fees in the case of honeyswap) could make easier to align incentives, when the deliverable is not something otherwise easily measurable.

I use Honeyswap, for sure the is some detail to be improved, but prolly to increase the volume is not something just related to tweaking the UI, but with a more broad product strategy, that Tulip Team for my understanding proposed to lead.

It’s also true that the whole 1Hive DAO brings value to Honeyswap, so it’s not easy at all to determine a fair split (especially now that the Gardens project will have the change to bring more liquidity).