fwiw i’m in favor of advancing the proposal as is, tho couple q’s
there’s an enormous amount of precedent in funding integrations so i’m not at all averse to encouraging more composability within the system. wanted to know, though – what’s the process of integration look like, and how’s the dev burden distributed between you and the partner protocol? has there been friction in getting new yield sources onboarded?
i’d also comment that better UX in a world with generally bush-league interfaces is for my money a better source of user onboarding than any small incentive. paired with user incentives (which have been uniquely effective in PoolTogether’s hands – the analysis last week showed that, broadly speaking, their efficacy has been mixed at best), I’d say that’s good, broad coverage for growth.
That said, though, hoping to get a brief sense of finances and why a grant at this stage would catalyze better UX – are you unable to move this forward otherwise?
wanted to know, though – what’s the process of integration look like, and how’s the dev burden distributed between you and the partner protocol? has there been friction in getting new yield sources onboarded?
Good question! Over the years we’ve tried many different approaches, we’ve done them internally, we’ve bountied them and then yield source teams have done them. Our best outcomes have been working directly with yield source teams to get them done. We also always audit them. So generally we’ve tried to either get the yield source team to do them for free and we pay for the audit or provide some sort of grant to the yield source team… that would be the idea here.
That said, though, hoping to get a brief sense of finances and why a grant at this stage would catalyze better UX – are you unable to move this forward otherwise?
The PoolTogether Inc team is a total 5 people (was 4 people until yesterday when we added Ncookie). We have zero designers on our team and we only have one front-end. So internally, we are highly limited in terms of what we can do UI wise.
I’ve always felt like there is a big need for a UI that connects to the protocol but focuses specifically on people who have never used a dapp before (have a Cex account but never used DeFi). So that’s something specifically I’d love to see. We’ve also had a lot of good work done on instrumentation, things like prize notification bots, prize odds calculators, things along those lines.
Overall, these integrations and UIs are things that will move a lot slower but I thought having some allocation for them would be good as a longer term play rather than incentive focused stuff.
I love this proposal and PoolTogether is highly trusted in the space. But we asked every other proposal to either state exactly how teams/projects reserves will be distributed or to take it out of the proposal I feel I have to ask the same here.
Don’t get me wrong I know 100% you will use this for new PoolTogether UIs. But if you can specify how that 20% distribution will be that would be perfect.
The same goes for the 10%.
I rather have to approve a second proposal asking for UIs core features individually than leave this 30% to the team will.
Again, I trust the PoolTogether team 100% but I want to keep the same conditions for all teams even if they earned my trust. thank you!
we asked every other proposal to either state exactly how teams/projects reserves will be distributed
What level of detail do you need beyond what is already shared? Do you need to know exactly who would be getting the grants?
I rather have to approve a second proposal asking for UIs core features individually than leave this 30% to the team will.
My understanding (via @Netrim) is at this stage, we can’t change the proposal. Is that correct? If it is possible to adjust the current proposal before voting I would do so.
You can change the proposal. Tag your approvers to reafirm their position.
“Well if you say 10k Op will go to this team for this UIs” that would be awesome. But if you have the UIs features in mind and you don’t have the teams at least specify those features and approximate distributions.
“Feature 1 does this and we will allocate approx 10k OP”
Sounds logical or is it too much work? I’m trying to figure out how to approve this I’m very fond of developer grants.
It sounds logical and it’s not too much work but given the time constraints I’m not sure it’s possible.
Let me just re-iterate the key points here as I have added more information in the comments.
550,000 OP total grant request
380,000 allocated to depositor rewards
110,000 OP allocated to alternative interfaces
55,000 OP allocated to alternative yield source integrations
For the 110,000 we think there is a big opportunity to further leverage “PoolTogether as the front door to DeFi” by making a dedicated interface targeted to people who own crypto on centralized exchanges but have never used an app. Think of it like if the Optimism Get Started page and app.pooltogether.com had a baby. That’s the primary a goal, a secondary goal would be more experimental ideas that might get submitted once we put out a request, I used the web3 savings cards as an example. That specific example is already funded so doesn’t need a grant but I think there is a lot of room to build easier to onboard interfaces for the protocol. As I mentioned in another comment, the PoolTogether Inc team has zero designers and only 1 front-end dev so having some grants to do work on front-ends would be helpful.
The second part, 55,000 OP for yield source integration is more straight forward. Right now the protocol is only intergated with Aave on Optimism, this is pretty limiting. It would be great to integrate with other yield sources, we have looked into integrating with Velodrome so that is possible but I also assume in the coming months more yield sources will be coming online. These OP tokens would be used as incentives to get those teams to integrate with the PoolTogether protocol. This is something we’ve done before on Ethereum mainnet.
I’m not sure if that adds clarity? I am happy to try and adjust the original proposal as several people have asked questions about it but I also don’t want to mess up the voting process! So looking for some input on best suggested path forward.
It seems like people are generally in favor… however, I will default to our original sponsors, @jackanorak and @mastermojo if you would like me to lower or remove the OP allocated towards yield source integrations and interfaces, let me know and I will do so.
@OPUser asked a further question via Discord and I wanted to answer it here for visibility.
What you want to built is clear from your last comment, but could you break this cost estimate, how did you reach to this number ? are you calculating Dev hours * hours rate, if so then how much.
There isn’t an Apples to Apples comparison since the OP tokens won’t be sold and generally shouldn’t be viewed as money. However, I do have some stats on past expenses of related activities.
I know Pool Grants paid $25,000 for phase 1 development of the Web3 Savings card interface. This specific project was one developer working on a part-time basis. Ideally, what we would like to achieve on Optimism is much bigger… A direct to Optimism on-ramp with fiat conversion making it simple to use PoolTogether for someone who owns crypto but has never used a dapp. We anticipate this being a multi-person project because it would include front-end, web designer, and also back-end / smart contract integration work. So we are targeting having enough resources for a single large grant that can motivate a talented team. If the total amount requested (110,000 OP) wasn’t needed then I would anticipate any remainder could be used for some OP on-boarding incentives specifically for that interface. I believe that would be very effective.
In terms of yield source’s integration our ideal path here would be working closely with a team to get them done. We’ve generally paid $15,000 per yield source integration. Yield sources always need a good audit which generally will cost about $30,000. I don’t expect an auditor would accept OP tokens as payment so likely that will be paid for by PoolTogether Inc and then OP tokens will incentive the actual integration work + the launch of the new pool. When new pools with new yield sources are created, they need to bootstrap deposit growth, so any tokens not needed for the actual growth can be used towards that.
Hopefully this helps create some clarity! Let me know if it does!
This proposal and the team’s answers are clearly from people with a lot of time in crypto and they know what they are doing. Thank you for all your answers I’ll vote Yes on this proposal
It took some time to study the proposal; nonetheless, direct fiat on-ramp is a welcome addition to the protocol and to the L2 chain, and development effort is not the best use of OP funds.
Clear and simple plan for usage of 70% of the OP requested for user rewards, with sufficient detail of the reason for the additional segments for UX and integrations. The proposers have responded to queries and shown willingness to expanded on sections that delegates have queried.
Value-Add
Pooltogether offers slightly better APRs than Aave and can attract significant TVL and users - similar as with their first grant proposal. TVL should stay & improve on Optimism and potentially more users should be attracted
Traction
Pooltogether has been a top project on Ethereum moved most of its liquidity ($35M) from Eth l1 to Optimism. They are used by thousands of addresses on Optimism daily.
Amount
550K OP is a reasonable amount for the size of Pooltogether, further incentivizing liquidity & phasing out rewards. 385K OP (70%) will be spent on liquidity incentives over 19 weeks at a rate of 20K Op/week. The rest will be used for builder incentives, incl. 110K OP (20%) for new UIs and better onboarding of users & 55K OP (10%) for integrations on Optimism.
Co-incentives
The variable co-incentives are based on Pool Governance and likely amount to 500$ - 2000$ USDC per day which would in AVG result in 170K USD over 19 weeks. This is slightly low for the requested OP liquidity but Pooltogether is also open to fund additional grants for teams building on Pooltogether/Optimism.
Allignment
Great, moved their project & liquidity to Optimism and plan to further build there
I’m abstaining from this proposal. I feel like much of the bootstrapping has already been done by the Partner’s Fund. At the same time, you have made an effort to mix things up by somewhat reducing incentives and allocating funds towards improving user experience. Still, it’s not enough - I want repeat proposals to be bolder, or at least come after a brief period to assess the effects without incentives. As an example, I would like to see much more focus on user acquisition through better user experiences and marketing, rather than liquidity mining.
As a point of general feedback on the process. It’s quite difficult as different voters clearly have different priorities. All the pushback we’ve gotten thus far is that we’ve allocated too much to building better user experiences… to the extent we almost completely cut out all the request for OP allocated towards it.
One thing that would be helpful is if people put their voting weight in their names on discourse… that way feedback could be weighted appropriately based on voting power.
I can provide some input here, initially token allocated to builders was not clear. What you want to build, how did you reach to that specific number and how it will add value. Once you provided information to those, it was easy to support your proposal.
(dune.com)