TL-DR:Create a framework to whitelist partners to host a front end of Paladin’s dapps or use our software for internal use.
The core team has been working for a while on structuring business development for its product and enabling an attractive business model for integrations to happen on our product line. This is a major step for the growth of the project and we’ve been very careful on how to approach the matter.
Our recent discussions with StakeDAO have accelerated our brainstorming as they have offered to use our Quest infrastructure for sdCRV in exchange for a 50/50 fee sharing. This would mean that StakeDAO would host a front end of Quest and manage its own client pipeline, and we would simply be in charge of infrastructure management. This is a fair deal that we would like to honor.
The goal of this proposal is to create a framework to make other partnerships happen in the future.
Our initial plan was to create a BD working group, but it has become very apparent that at this point, such a system would be easy to game and too inefficient. As such, we have reformatted these goals into a partner program where each new integration will have to be approved by governance in a new type of proposal: Paladin Partner Proposals (PPP).
DAOs / Companies using our software for internal use or on their interface will be able to request a fee sharing system (up to 50%) that will need to be approved by governance under the PPP framework.
To what extent do you think these partnerships with third parties will cannibalize the Quest front end itself? Do you expect going forward that partnerships like these would be responsible for most of the Quest volumes?
I’m all for creating partnerships with big players that could bring Paladin/Warden more visibility and users/revenues.
I’m just curious about how that would look from the point of view of the end users… Would they still go through the Warden/Quest front end, or are you thinking of a white label solution where the users would remain on the StakeDOA (and other partners) website and the transactions would be going through our SC behind the scenes? From your description ("…using our software for internal use or on their interface…") it sounds like it could be either. Is that correct?
would the 50/50 split of fees be a fixed parameter or can that be negotiated based on the partner’s user base ? (also negotiated over a certain period of time to be reassessed every x months?). I am assuming we don’t want to be too agressive either as we want to partner with these protocols rather than have them build their own version of our product?
good question… and this actually made me realise that i didn’t pay much attention about the protocol fees. Is there any specific section in the doc that covers this?
I’m guessing it is transparent from a user perspective and that it is the protocol setting up a new Quest that pays the fee? Is it always 5% or is it subject to negotiation as well?
I honestly do not know how much this is going to represent. Our current growth strategy for Quest is to raise the surface area of quest creations (incentivise partner protocols to use/pitch us) and concentrate voting activity on our protocol. In simpler terms: frens bring us more quests and we find more voters.
it sounds like it could be either. Is that correct?
Yes, it doesn’t really matter where the Quest is displayed, what is going to matter is by who it is created.
The whole point of this proposal is to elucidate this. Fees are fixed as +5% of the total Quest.
Agreed but please try to fit all these questions in one post to facilitate clarity of discussions in the forums.
I’m in favor of increasing the growth of Quest by integrating a new iteration on different protocols that can require a front end or specifics parameters.
However, these projects can already use Quest through the protocol directly without a front end or specific parameters, in which case, all the fees would go to Paladin DAO.
The current proposal is about giving 50% of the fees, but as it was mentioned above, it’s hard to estimate the weekly volume and the generated fees, which is why I’m against the current distribution proposed.
I also think that it could set a precedent for others DAOs to ask an iteration of Quest with shared fees (requiring time from Paladin core team) instead of just using Quest.
I initially wanted to propose a reduction of the fees, but while discussing it with @jeanbrasse, he mentioned the idea to adjust the fees depending on the weekly volume, meaning that we could probably use some kind of KPI options to manage the revenues distribution.
This would help a lot to incentivize the Quest integrations while making sure that giving a high % of the fees to partners will guarantee some revenue streams to Paladin DAO. This also allows to always share a % of the fees no matter the volume since it would not be possible to revoke it, but always automatically adjusted, which should help to keep the goals aligned in the long term.
I fully agree with the idea, and I tried to write an example to explain it easily:
I like the proposed model for adapting fee sharing based on volume, and think we could start with that type of model.
The only issue I have is that a whole system based on KPI would delay the start of this 1st partnership (it would require to change the current model we have for Partner smart contract).
For now, I propose to have the current system, but with the DAO being able to update the partner share parameter in the smart contract. We can then start with a lower share for the partner, and reserve the right for both the partner & the Paladin DAO to re-negociate that share every 2 weeks (not set in stone, we can find an amount of time between 2 updates as the DAO prefers) based on the partner Quests volume.
We can then start working on another system based on KPI, and that could automatically adapt the partner share based on volume directly, and replace the 1st generation of Partner smart contracts by this new system.
I already have one, but with the partner share as immutable, would need a small update, but otherwise it’s ready
Not to my knowledge
Seeing that more as when to do the update of the partner share. Since Quests can be directly 2, 3 even 4 weeks long, you could see some weeks with low volume while others with high volume (also since all fees on a Quest are paid at the Quest creation), so I think a system where the share is not updated only when needed might be better (maybe through a quick Governance process, that can be Optimistic based on the model you shared)
Depends on the Partner, but yeah the v1 of the Partner smart contract would still have control over the active Quests at that moment, so it would require to have the 2 contracts concurrently during some time. But other than that, shouldn’t be expensive.
It is not about the front-end but bringing new customers in for Quest. Here, StakeDAO has a new wrapper called the sdCRV who would become compatible with Quest, thus raising our growth’s surface area.
I like a lot the idea of KPI-based fee sharing that are up for renegociation when any of the party has passed certain thresholds. I also believe we have to create sufficiently beneficial partnerships for these projects to want to keep using Quest and not build their own infrastructure.
I believe @Dydymoon’s metrics are fair, but I would also add a one month 50-50 fee sharing welcome gift to show our partners how beneficial collaborating could be.
I think it’s a very good thing to have the possibility of having other DAOs who can offer paladin quests on their dapp.
Quests should bring visibility to paladin and the other services they offer.
It is also important that this favor is not a way for other DAOs to profit from the work and fees generated by Paladin. The dydymoon proposal seems very good to me for having a gradual approach to the fees earned according to what our partners bring to quest.
I like the proposal overall, but I wonder if it would not be better to consider the full monetary commitment of the partner rather than weekly amount? (especially since the committed amount cannot be reduced once the quest is launched).
Agreed, it sounds like a good way to get them to try out the solution.
i’m assuming that the number of partnerships would be limited to only a few number of very large players, no? Do we want to set a threshold under which it would simply not be worth considering fee sharing or do we want to consider all proposals once the code changes are done?
I think what is key is to make sure that we are not agreeing to reduce revenue, while at the same time adding complexity for the team. Am I correct in saying that having partners run their own version of the front end will not add any additional work for the Paladin dev(s)?
aIn terms of the framework, i guess a lot of discussion happen behind the scenes between potential partners and the team. Will the PPP votes be for approving partners, deciding on the fee sharing %age or both?
I see you included changes to Warden’s codebase… is there an additional component around the boost market for partnerships, or is it just because both the code for Warden and Quest are very
Yes that seems fair, maybe one condition for this could be one month duration for the first quest ?
However I would love to see the next projects implementing an iteration of Quest to propose a Grant for Paladin devs for their time spent on the integration, which would legitimate this kind of welcome gift a lot imo