This proposal is about to go up for official voting, but the questions
raised have not been answered yet in written form. I am in favor of this proposal, but also appreciate the questions 0xean asked and think they should be addressed so the community can make an informed decision.
What are the success metrics of this proposal? Here are some metrics I think we could expect/aim for from this partnership:
Acquire at least 300 new users/mo from staking rewards for the next year (3600 users, <$10/user)
Increase ATOM staked to ShapeShift DAO validator by 5% monthly for the next year (80% increase; over the past 6 months, the Cosmos validator has generated over $150k revenues for the DAO; estimated $240k annual increase in revenues)
pointed out. These are just some example goals; ideally the growth workstream will give feedback on and commit to these or similar goals.
What can this expenditure not come from the Marketing and Growth budget?
This is a fair question, and I am not a growth WS leader so can only speculate. A couple reasons that I think it makes sense for this to be its own proposal:
a. this expenditure was neither negotiated nor anticipated when the workstream was proposed
b. the payment is split into 2 tranches, and just because the Growth workstream has budget available now, there’s no guarantee that they will have budget available for the second installment
I don’t have strong feelings around whether this is its own proposal or comes from the growth ws budget, I think both can work, and if there is a large unexpected expense for a WS it is justifiable to make a new proposal. Regardless, this is a valid proposal from StakingRewards and the community is welcome to vote yay or nay.
I know you’re v busy today and planning to respond to 0xean’s q’s later; looking forward to seeing your answers!
I know you’re also v busy, but realizing that we still don’t have engineering’s confirmation that this is doable and can be resourced (either internally or with bounties). I am hopeful that is right and this is very low lift (if we can display the APRs in our UI, should be very easy to give StakingRewards what they need to display the APRs in their UI, right?), but really want to confirm that we can provide the required data before we transfer precious stables.
@1screampleease - we currently run a very minimal backend, for one specific purpose - to provide indexed chain data related to accounts and transaction history. We don’t have a monolithic backend, and endeavor to avoid adding backend infrastructure at all costs, as it moves us away from decentralization.
From a cursory glance of the proposal, I believe all the data that Staking Rewards requires, we obtain from on-chain sources, typically via Infura.
Are you able to provide more technical reference materials outlining exactly what is required for this API on our side to require?
Gut feel is that it’s likely that everything we display is publicly available, and that we could provide code snippets for how we obtain or calculate specific metrics that could be integrated on the staking rewards side, but I am not in support of adding a staking rewards API service if it can be avoided.
It’s hard to add complete success metrics but we have some ideas of which metrics would make us happy around acquisition cost. Also there could be new goals and KPIs coming down the pipeline so these should be readjusted at that time:
Acquire at least (number will be decided upon after the first 30 days) at an acquisition cost of $2-$2.50 per user
Increase FOXy holders by end of year with a 15% MoM target
More Goals and KPIs will be reestablished within 7 days of going live on Staking Rewards if approved.
The reason that this is not coming from Marketing & Growth budget is due to recent budget cuts for the market conditions. Further budget restrictions are happening on the M&G workstream and would make funding this purely out of our budget possible but over time not in the 2 payments required by Staking Rewards. When the budget was first approved by the community we were not at a point of working with Staking Rewards and cost of $35,000 was not on the table at the time, so it was not included in the budget. As willy pointed out there would be concern of this being funded into tranches and having budget for that second payment. While we built the budget to have bounty and wiggle room larger media buys that would offer massive benefits such as Staking Rewards should be considered by the DAO instead of just waiting for the next marketing turn.
Thanks for posting this information. It still seems that we are unsure if this integration is aligned with our distributed architecture at this point and think it would be wrong to vote yes on this without further technical diligence.
Does Stakingrewards have any flexibility on their end with respect to the integration pattern outlined in the documentation?
we’ve been discussing in DMs and should have clarification by tomorrow on whether we can integrate. good lesson going forward to finish technical diligence before a proposal goes live. can you plz post a response in here as soon as you hear back from the research team?
There is no need to panic. I can reassure the API is not going to be an issue if you have at least 1 person decently knowledgeable in Javascript within the DAO.
Our Research team and Engineering team are glad to help you - please let us know 2 slots for a quick meeting at your convenience.
Invites for today’s meeting at 10:00 EET have been sent. Please feel free to add somebody from your side.
thanks for setting up the meeting this morning 1f64f
and I met with and their head of research and tentatively confirmed that there shouldn’t be any issues providing the necessary data without a self-hosted backend. StakingRewards is double checking with their devs to be sure; will post here once we have confirmation.
Knowing that Javascript or just placing a script within an application can be a serious security concern, I would caution this as being a simple and easy solution. I am not placing dispersion on this as a service, but with the current state of our capacity for a valid security code review process I will voice my concern. I am pinging for your attention knowing that you have other obligations and concerns in the near term. I know that this topic has garnered lots of attention, I just have concern that due diligence for the security of the platform, isn’t sacrificed for the sake of ease of integration.
I’m not fully up to speed on this, but it looks like they just want to be able to hit a server to get some info; if I’m reading this right, there’s no need to add any code to the app, we’d just spin up some code somewhere to pull public blockchain data (i.e. interactions with our router contracts, etc) and reformat it into the data structure they need, and that’s not a security issue (wouldn’t even need any special perms or anything, probably just an Infura key).
I could be missing something; LMK if that sounds about right !
Fair points, I just get concerned when I see no problem just need some javascript or someone who knows how to add a script. I am aware that it wasn’t directly stated that we need to add anything I just would rather get ahead of the possibility and be proactive vs reactive as to the possibilities of solutions. Thank you for the reply
To clarify here - no external code/libraries is required. Staking Rewards just needs data we already obtain from chains to be massaged into their shape.
Understood, so in relaying that information the access granted is contained or siloed to just the needed data, without the ability to interact in any fashion with other data on the platform. Thank you.