All committers have signed the CLA.

@prastut Thanks very much for the follow-up grant. Your current portal is very intuitive and I would like to support further funding of the project. I also wrote an RFP for something similar recently, although using an on-chain approach with smart contracts.
I've got a couple of doubts regarding the current proposal:

1. How does the proposed ledger integration differ from what's currently possible with Ledger?
2. We don't pay for the design phase via the Grant Program anymore, this should form part of the proposal.
3. The main (?) deliverable: "Implementation to detect account type (stash/controller) in the background and accordingly allow the user to stake through YieldScan." sounds fairly expensive for what it proposes. Could you outline what exactly needs to be done in order to accomplish this?

Lastly, regarding your future plans:

In the near short term, we plan to start charging a small fee for helping user stake simply to sustainably fund development to reduce or diminish the reliance on taking grants.

On the one hand I appreciate the tremendous work that's gone into the design and the implementation already, as I said your portal looks great and I personally think it's extremely useful for getting widespread adoption. That should be rewarded. On the other hand, the fee might discourage some users, especially if they can just run the service themselves locally (which shouldn't be the default!)
Ideally, this is something that would be funded by the treasury, although given the somewhat controversial nature of the proposal (also see the discussion in the earlier mentioned PR), I'm not sure whether this would get the necessary approval - but it's certainly worth a try, as this would be the ideal use case for "Infrastructure deployment and continued operation." I guess this can be explored in parallel to the grant.

Hi @mmagician thank you for investing your valuable time and going through our proposal in detail.

Replying inline:

Responding to your RFP

I also wrote an RFP for something similar recently, although using an on-chain approach with smart contracts.

I went through the RFP and I am quite excited by both ends of the debate.

• While I understand where Jeff is coming from, I also have faced the pain myself as a user to stake.
  • And to be an active participant of the overall staking process is asking a lot from a busy user.
• Having built multiple products in the past 5 years, I believe that users easily tradeoff convenience over security.
  • A big example that is playing right in front of our eyes is BSC transaction volume going to cross Ethereum transaction volume.
• Therefore YieldScan mission is to help user with the tools required to not make that tradeoff.
• Related to your idea of making this entire process on-chain, our long term ambition with base infrastructure is to build a trustless accounting system - a set of smart contracts designed for precise DeFi portfolio accounting as and when projects like Acala and XCMP go live into production.
  • The problem most interface designers face at the moment is reliance on centralized services (including us) to provide actionable insights to the user, and we believe an on-chain approach will help mitigate these issues.
  • This will also help standardize interface design.
    • This problem is big enough in the Ethereum ecosystem, where interfaces can't keep up with so many projects (eg) and users are left with either bad interfaces or trusty old Google Sheets with CoinGecko API.

Though in the near term, we believe we can increase value for our existing userbase and this is what the proposal is about.

Responding to your doubts regarding the proposal:

1. How does the proposed ledger integration differ from what's currently possible with Ledger?

I have used the Ledger Live experience and contrasted them with YieldScan experience. You can also contrast them here:

• Ledger Live Staking Experience
• YieldScan Staking Experience

The principal argument that I believe is that the former is just a feature in the entire Ledger Suite while the latter is a cohesive product experience tailored to fit the needs of the staker.

In other words, YieldScan speaks in the average user's language while Ledger assumes the user to be sophisticated enough that they can make their own choices.

These questions aren't answered by the Ledger Flow:

• "What's in it for me to invest my valuable time here?". YieldScan uses that as the starting metric.

• "Okay I have X assets, but my risk-taking appetite is Y, can you tell me what is recommended personally for my case?" Designed with user preferences in mind.

  • On YieldScan, the user tells us what risk they want to take, how much time they want to stake for.
  • 

• "Which validators do I choose out of 770?"

  • On YieldScan, basis user preferences and risk scores outputted by our recommendation algorithm that analyzes all validators basis various on-chain metrics, we help them with best possible choices.
  • Contrast this with the staking experience provided by Ledger Live in this video where the user just selected 100% commission validators for they don't know any better.
  • In YieldScan case, basis live on-chain metrics these validators are never suggested to the user for the user's intent was to earn rewards but they aren't getting anything in return which might create a sour taste in user's mouth.

The other supporting arguments that I think makes YieldScan envisioned experience much better than Ledger Live is:

• We have thought through the "after-sales" experience as well.

  • Given nominators don't start earning rewards instantly, we help user with insights as to when they can expect to get returns.
  • On YieldScan dashboard page, user can also take insights from their inactive and active nominations.
    • For eg: if the user's active validator get's slashed, the risk score will become super high and user can go and restake again using YieldScan.

• We support both Polkadot & Kusama.

• And going forward, we are going to nudge user's to take the right approach.

  • For eg: user's has > $1k worth of DOT but their private key is inside their Polkadot.js extension.
  • We will alert user's as to why this is a big problem from a security lense, and what they can do about it.

We don't pay for the design phase via the Grant Program anymore, this should form part of the proposal.

Got it. I can make that a part of the proposal.

(Though I highly think the committee could reconsider this stance.

I love what Parity has built with so many lego blocks and customization available to developers, though it's time the ecosystem shifts gears to getting more users using the stuff the ecosystem has built.)

3. The main (?) deliverable: "Implementation to detect account type (stash/controller) in the background and accordingly allow the user to stake through YieldScan." sounds fairly expensive for what it proposes. Could you outline what exactly needs to be done in order to accomplish this?

The main goal/deliverable that we are building in this grant is onboarding stakers to best practises. All deliverables mentioned here aim to achieve that.

I agree that implementation of stash/controller might be expensive, but to make a cohesive experience around it requires a lot of iterations when the product is getting built.

For example, this is the sort of experience we envision developing for Ledger:

^ And this is the same kind of experience we want to create for the end-users with respect to stash and controller accounts.

Just to give you a sense of that how users are not onboarded that well to these best practises, we calculated the following stats from on-chain data. The script we used to calculate the numbers is here

TL;DR ~80% of nominators on Polkadot and ~66% of nominators on Kusama don't understand the difference.
We would like to help reduce these numbers.

Responding to your views on our future plans:

In the near short term, we plan to start charging a small fee for helping user stake simply to sustainably fund development to reduce or diminish the reliance on taking grants.

On the one hand I appreciate the tremendous work that's gone into the design and the implementation already, as I said your portal looks great and I personally think it's extremely useful for getting widespread adoption. That should be rewarded. On the other hand, the fee might discourage some users, especially if they can just run the service themselves locally (which shouldn't be the default!)

The intention with our fee is multifold:

• It should be low that it doesn't pinch the user.
• The user makes it up within 1-5 days of staking, which otherwise they might be losing out on returns.
  • We have users that tell us their validators increased their commission to 100% and they didn't know what to do next.
  • For some users, they don't even know that this change has happened.
• We also may direct some of the fees to the Polkadot.js community to experiment with positive-sum open-source funding models. We have pinged Jaco in that regards.

On the other hand, the fee might discourage some users,

Actually, some of our users have suggested to charge fees 😅

especially if they can just run the service themselves locally (which shouldn't be the default!)

• There are many organizations in the web2.0 world where the user can self host the application, though the company charges for hosting the application on user-behalf.
• Even in web3.0 world, an example that is widely used is Metamask - which is charging 0.875% (!) service fees through their swap functionality to fund sustainable development going forward.
  • Source
  • I could theoretically fork the extension repo and point the extension to my instance of swap contracts on-chain here which have turned off the fees.
  • But data tells otherwise and MetaMask seems to be generating ~$300k per day in revenue from these swaps.

Goes without saying, we will be experimenting with different funding models including getting our community view's.

Thank you for reading this very long reply and hope I was able to address all your concerns. Happy to address follow-up questions.

Best,
Prastut

Hey Prastut. Many thanks for the detailed reply. I have to say I agree with your opinion pretty much on all fronts and I'm also impressed by your work with YieldScan. Though I certainly understand why there should be some resistance from our side to support anything that automates nominations (but not from Grants I'd say).

I also agree with the fact that charging a fee is totally acceptable for the benefit this provides, at least I wouldn't flinch. And the fact that you're thinking of directing some of the funds to wherever else it's needed in the community is just brilliant. You have my support.

While it is true that we can't fund design work, I also agree with your stance to some extent and have started an internal discussion. The low fidelity designs are certainly enough for the application, so for now I would advise you to just remove that deliverable while leaving the price unchanged, unless you want to wait for the outcome of the discussion. The designs look great, though I think you'd be better off getting feedback from the community than from us if you want any before you start. The only thing I could add would be to make sure to provide access to an explanation on what stash and controller accounts are, and any other term that might be unfamiliar to the user, whenever these come up.

Something else we may want to agree on as a compromise would be to add warnings and links to nudge users... well, away from YieldScan and towards taking a more active approach to nominating. I.e. learning about nominators, joining the channels, etc. Or at least a warning about the risks, both to the users and to the network. What would you think of that?

And the fact that you're thinking of directing some of the funds to wherever else it's needed in the community is just brilliant. You have my support.

Since YieldScan stands on the shoulders of giants (Parity, Web3F Foundation, Polkadot.js team), our team wants to give back to the value we have gotten so far.

• We started from the lense that whether we can return the capital + interest provided by Web3F back.
• And in this line of thought sustainability of the project became paramount for we can't give when we are in need.
• Ideas to play positive-sum games are documented below:
  • With the chains we are helping simplifying staking:
    • Moving the capital from CEX's to on-chain transactions sends a portion of transaction fees to on-chain treasuries.
      • The amount may be trivial at the moment, but it is something and a function of how we get more adoption.
    • With Polkadot.js:
      • Simply directing a % of fees to the team's treasury, this could be web3.0 version of API metering.
      • To accelerate feature requests on-chain bounties signed of by Polkadot.js team, incentivized by YieldScan treasury and devs make PR's to Polkadot.js

While it is true that we can't fund design work, I also agree with your stance to some extent and have started an internal discussion. The low fidelity designs are certainly enough for the application, so for now I would advise you to just remove that deliverable while leaving the price unchanged, unless you want to wait for the outcome of the discussion. The designs look great, though I think you'd be better off getting feedback from the community than from us if you want any before you start.

Sounds good. I have removed the deliverable.

The only thing I could add would be to make sure to provide access to an explanation on what stash and controller accounts are, and any other term that might be unfamiliar to the user, whenever these come up.

Yup, we plan to heed Einstein's advice on “everything should be made as simple as possible, but no simpler"

While the first phase of YieldScan was completely abstracting away all new technological aspects that will overload a user, this time we are planning to make sure a curious user has all that they need to answer their why, what questions. It is the how part where YieldScan will mostly help.

Something else we may want to agree on as a compromise would be to add warnings and links to nudge users... well, away from YieldScan and towards taking a more active approach to nominating. I.e. learning about nominators, joining the channels, etc. Or at least a warning about the risks, both to the users and to the network. What would you think of that?

I understand where you are coming from.

The problem to solve here is to convert passive participation of nominators to active.

• If that means nudging user's away from YieldScan is higher yield on time AND it solves the problem, we are all for it.
• Though I don't think it as a comprise on YieldScan part, rather I feel it's as an open opportunity for YieldScan team as well as for any community member interested to help solve this problem who can use YieldScan platform and distribution to their advantage.
• For example:
  • We understand that YieldScan's current recommendation algorithm is baked with our team's current opinions of how we would want to nominate.
    • While it may have it's pro's and cons's, we generally agree that blanket recommendation for all our users --> creates centralization of opinion.
    • This is the same problem Twitter feed faces so there are no good/bad answers here IMO.
  • An idea that was discussed in our community was user-generated recommendation system algorithm, where a knowledgeable user can come onto YieldScan platform, tweak variables around various metrics of how they would want to tailor the recommendation system and upload it to the platform.
    • Then users coming to the platform can choose between various recommendation algorithms basis risk/reward.
    • This could incentizive diversity of opinion and making the more platform more accepting and inclusive in nature.

Your stance may also stem from YieldScan's current narrative of "don't make me think" perspective to staking where instead the network would want users to think while nominating to increase security through wisdom of crowds.

Going forward we are going to change that narrative through:

• Staying true to our initial vision of providing information symmetry and transparency so that the cognitive friction to become an active nominator reduces over time.

• Improving discoverability and accessibility of our current half-baked features (😅).

  • For example:

    • We want to help small validators market themselves by using their YieldScan profile which has 1 click staking CTA attached to it.

      • Currently, our validator profile looks like this.
      • We need to get it to a mark where validators can use them as marketing collateral on social media channels.

    • We want to help nominators understand what the network want's to incentivize through discovery and comparison (over reading economic whitepaper)

      • Currently we have a explore nominators page.
        • Disclaimer: it takes some time to load.
        • Now what this page doesn't help a nominator answer these following questions:
          • "Who are the nominators earning more than me?"
            • "Why is that the case?"
            • "What can I do to make returns comparable?"
            • "How can I better my returns?"
          • A smart nominator may figure out that championing a small validator might be high yield to get returns.
            • Currently there is no easy way to do this.

• Change the overall narrative from "maximizing returns, minimizing cogntive load" to a community centric narrative of inclusive participation to bolster network security.

Loads to be done, and this capital would also help us increase our development velocity to ship by onboarding new talent.

Thank you again for reading this very long reply.
Happy to address followup questions.

Sounds good. Thanks for getting into the details again.

The problem to solve here is to convert passive participation of nominators to active.

That's it exactly. Glad to see you'd like to contribute to finding a solution to the underlying problem. See also the ongoing discussion on the RFP suggestion in case you haven't subscribed.

I've given the warnings thing a bit more thought and to be honest it doesn't seem fair to me to impose it as a requirement, considering CEXs have no obligation to include such a warning and are even worse for the network from a security perspective. Besides, it doesn't solve the real problem, which is that nominating "the hard way" simply doesn't make sense for an economically rational user. I think it's fair to say that on average one will achieve larger returns for a minimal fraction of the time invested using YieldScan or some other automatic nominations solution (or average returns with most CEXs), as opposed to conducting due diligence on one's validators.

I think there's nothing you can do to make the problem disappear, but I agree, those strategies could be used to educate users and mitigate the problem. Validator profiles are good but imo likely to be ignored by most everyone unless they have to make a choice at any point. Nudging and educating would probably help, not sure to what extent. User-generated recommendations along with variables that can be tweaked to output a personalised validator set would be likely to mitigate the decision centralisation the most, and I'd argue it'd even be a pretty good approach all things considered. Perhaps add some randomisation, and I think you're very close to all you can do. Lastly if we care about this you may indeed want to make changing the overall narrative a priority. I assume all of the following people (and many others, if anyone wants to involve someone else, please do) have given this more thought than I have, so I'll let them add their thoughts to the discussion if they want: @wpank @AlistairStewart @burdges @jonasW3F @laboon @gavofyork.

Feel free to add some efforts in this direction to the current application, depending on where this goes.

The validator profile doesn't load for me, by the way.

Thank you for your comment @alxs 🤝

The problem to solve here is to convert passive participation of nominators to active.

That's it exactly. Glad to see you'd like to contribute to finding a solution to the underlying problem. See also the ongoing discussion on the RFP suggestion in case you haven't subscribed.

I have been reading the RFP discussions since Marcin mentioned it to me.

I have gone through both sides of the conversation and I prefer to take the stand that building tools like YieldScan is a net positive to the ecosystem than NOT building them.

For you will end up with cases like nominator staking on 100% commission validators -> not getting rewards -> and going back to CEX for convenience ultimately reducing the overall network decentralization. Caveat: I am overly simplifying things here.

Empowering them with a soft landing and progressive onboarding is what I think is the best bet.

Besides, it doesn't solve the real problem, which is that nominating "the hard way" simply doesn't make sense for an economically rational user.

Agreed.

Also when staking derivatives launch, I suspect that most economically rational users would want to increase capital efficiency of their holdings by not worrying about staking activity that much, further reducing the incentive to participate actively.

I am still going through this paper "Why stake when you can borrow" to understand the full implications of staking derivates and what are the parameters under which network security improves under them.

I have a hunch that tools like YieldScan would become more crucial to the ecosystem when convenience starts to trade off security.

I think it's fair to say that on average one will achieve larger returns for a minimal fraction of the time invested using YieldScan or some other automatic nominations solution (or average returns with most CEXs), as opposed to conducting due diligence on one's validators.

I'd also add the non-custodial nature of YieldScan (and any other solution) is getting more and more valueable to the retail user who is waking up to the systemic risk exchanges are posing and adopting custody of their assets.

As you can see from this data, this trend is on the rise.

Combined with the higher returns aspect (eg: a feature request by a community member is an auto rebalancer built into YieldScan that maintains yield), it becomes a no-brainer to move away from CEX's.

Feel free to add some efforts in this direction to the current application, depending on where this goes.

• Our team has thought about this at length and to do it right we believe it's a scope that is best taken after the current scope of the grant has been shipped.
  • Our last grant was feature-heavy as we promised the world (😅), but I'd say we were capital inefficient in the sense that we built a ton of features though ended up with 1 core dominant flow that we really perfected which is where the traction is coming from.
• At the moment, I feel the current set of users is a very small sample set to justify testing different recommendation algorithms feature.
• Hence a conscious decision was taken on our part to keep the minimal scope that leads us to scale adoption.

The validator profile doesn't load for me, by the way.

My apologies for providing an incorrect link, we are adding network specific URL routes soon:

1. This link should work as Kusama network is the default network on YieldScan for a new user.
2. This link should work if in case you shifted to Polkadot network.

keep the minimal scope that leads us to scale adoption.

Sounds very reasonable. I do try to understand both perspectives: that of empowering the user; as well that of providing best UX via "guiding" the user and having the least friction. I believe there is space for both approaches in the ecosystem, but I like your stance on firmly choosing one and deciding that your product focuses on the latter (there might be another team building a more choice-friendly version some day).

I see you're committed and definitely you know what you're talking about. Nevertheless, is there any room for reducing the cost just a little bit? Despite having a history of working with us and delivering a great product, I still feel the price is high for the two deliverables proposed. This is just my personal view of course, other Grant Team members might still be fine with proceeding in the current state. Let me know and good luck either way!

Sounds very reasonable. I do try to understand both perspectives: that of empowering the user; as well that of providing best UX via "guiding" the user and having the least friction.

I believe there is space for both approaches in the ecosystem, but I like your stance on firmly choosing one and deciding that your product focuses on the latter (there might be another team building a more choice-friendly version some day).

🙏

Our mandate is clear from day 1 that we start from the customer experience first and then work backwards to the technology.

Even though I draw inspiration from Jobs/Apple (from the link above), I hated their walled garden strategy and our team is more than open to provide dedicated bandwidth in bugfixing/merging if any team wish to merge their custom logic inside the smooth buttery UX YieldScan provides.

This way the other team doesn't need to bother about thinking about UX or how do go about acquiring users and we get better recommendations choice inbuilt. Win-win.

Despite having a history of working with us and delivering a great product, I still feel the price is high for the two deliverables proposed.

I understand.

• I am slightly reluctant to reduce the price since it's very hard to develop quality UX without running lot of feedback loops at the product level, especially in a space like ours where you are constantly balancing a tight rope between abstraction and user know-how of these new systems.

  • The extra capital helps us with extra time to run more feedback loops. (Eg: we already are on the third draft of the low fidelity designs that we have attached in this grant.)
  • Given how reasonably big the problem is and going to get bigger as Polkadot goes more mainstream, I believe we have requested a fair price in exchange for the probability of creating asymmetrical wealth from an adoption standpoint.

• Though on the other hand I'd be happy to reduce the price since I understand the grant commitee's current mandate of not funding design work.

  • I really like working in the ecosystem and I have often expressed my admiration of how well the grant program is run so all in all a little price reduction won't hurt in the sense of playing long term games with long term people and letting compounding do it's magic.

Let me know accordingly and I will do the needful 🤝

As an aside, I've not read https://arxiv.org/abs/2006.11156 closely, but at a cursory glance it does not discuss security beyond paying lip service. Aside from security, it's plausible their slashing risk model fits validator operator mistakes under our current slashing conditions, ignoring correlational slashing. We'll mostly avoid those with paritytech/substrate#7398 (comment) however, likely making staking derivatives more boring. Appears their model cannot cover the 100% soundness slashes required by parachains, which conversely makes staking derivatives nutty. I've not looked specifically at YieldScan or this proposal, but since that paper came up I figure worth some remarks.

Btw, I also noticed that your application says payment in BTC, but since recently we can only pay grantees in DAI, I hope that's fine with you. Could you please update the <application>.md accordingly?

Well, I really hope they turn out to be of top quality!

🤝🥺

but since recently we can only pay grantees in DAI, I hope that's fine with you. Could you please update the .md accordingly?

No worries, updated!

Congratulations! As part of the Open Grants Program, we want to help winning teams acknowledge their grants publicly. To that end, we’ve created a badge for projects that successfully delivered their first milestone. Please observe the foundation’s guidelines when making any announcements; in particular, don’t announce the grant publicly before you've completed at least the first milestone of the project.

At that point, we will be happy to collaborate on an announcement about the work you’re doing. Please get in touch with us at grantspr@web3.foundation in case you're interested (at least two weeks notice is preferred).

As an aside, I've not read https://arxiv.org/abs/2006.11156 closely, but at a cursory glance it does not discuss security beyond paying lip service. Aside from security, it's plausible their slashing risk model fits validator operator mistakes under our current slashing conditions, ignoring correlational slashing. We'll mostly avoid those with paritytech/substrate#7398 (comment) however, likely making staking derivatives more boring. Appears their model cannot cover the 100% soundness slashes required by parachains, which conversely makes staking derivatives nutty. I've not looked specifically at YieldScan or this proposal, but since that paper came up I figure worth some remarks.

Thank you @burdges for this comment and giving me more leads on rabbit holes. I will get back to you when I have specific questions that could merit your time investment.

Thank you @mmagician, @alxs for investing your valuable time in going through the proposal and your vote of confidence and to @Noc2 who has been supporting us since the start of our journey in YieldScan. 🤝

Back to building 🏗

Hey @prastut, I hope everything is going well. Have you got any updates regarding the second phase yet?

Hi @mmagician

After running into several roadblocks, we are just stuck at the last roadblock - which we are problem-solving currently.
We are almost done, apologies for the insane delay.

Pre-context about the last roadblock:

• Given that UX is a pillar for YieldScan, we wanted to build a great experience for ledger users.
• Our staking experience makes use of batch for simplifying a bunch of user actions in one go.
• Since:
  • Ledger didn't have batch support at the time of our grant approval and
  • polkadot.js doesn't provide info of what wallet user is using,
  • we had devised our UX in a way that the user informs us about what device are they using to connect to YieldScan (ledger/polkadot.js or any other wallet) .
• In between shipping the grant, we came across the info that batch utility is now supported in both polkdot and kusama ledger apps
  • More details here: Status of batch transactions on Kusama Ledger app Zondax/ledger-kusama#83 (comment))
  • We tested this with info with simple transactions in batch utility and were delighted that ledger got batch support.
  • We then went back to the drawing board and did an iteration of UX again which hugely simplified the experience given now irrespective of what wallet user uses, we have parity in the features of the wallet we are using.

The roadblock we are facing:

• After implementing the revised UX, we started beta testing inside the whole experience and there is where we discovered that batchAll is somewhat supported inside ledger.
• You can read more about the issue:
  • we have opened here Getting 'Not Supported' error with batch/batchAll for specific module Zondax/ledger-polkadot#98
  • other users running into same problems here Status of batch transactions on Kusama Ledger app Zondax/ledger-kusama#83 (comment)

How are we fixing the roadblock

We decided to install a temporary patch for ledger users - that in the meantime ledger properly supports batchAll - users can still make use of YieldScan.

Btw you can play around with the updated UX on this link:
https://dev-yieldscan-pr-59.onrender.com/setup-wallet

Our major deliverables were around:

• Supporting ledger wallet (this is the part we are stuck and problem solving)
• Supporting + simplifying stash + controller account support. (this is done)

You can currently test the UX if you have an account on Polkadot.js extension where the account can fall into the following PnC's:

• You have never staked before.
• You have staked before but don't use controller setup (i.e stash account == controller account)
• You have staked before and use a controller (i.e distinct stash and controller keys)

Attached some images from here https://dev-yieldscan-pr-59.onrender.com/setup-wallet

• This is how the new setup wallet flow looks like.

  • 

• After setting up wallet and user is happy with their staking calculations, they are now given a way to select between express and secure method.

  • 

• If the user selects secure, we walk them through why, what and how about setting up controller account:

  • 

Okay thanks for the update! @alxs also mentioned that you've been in touch over a private channel. All good, looking forward to the final delivery 👍🏼

hi @prastut we transferred the payment for M1.

Hey @RouvenP, thank you very much for moving so swiftly and processing the transfer.

I apologise for the delayed response, our team was caught up in making fixes and additions to the platform for the upcoming transition from free to paid 😅

We look forward to keep building for the community.