Parallel finance grant proposal

[yubo-ruan]

Grant Application Checklist

• The application-template.md has been copied, renamed ( "project_name.md") and updated.
• A BTC or Ethereum (DAI) address for the payment of the milestones is provided inside the application.
• The software of the project will be released under the Apache license version 2.0 as specified in the terms and conditions.
• The total funding amount of the project is below USD $30k for initial grant applications and $100k for follow-up grants.
• The initial PR contains only one commit (squash if needed before submitting your PR).
• The grant will only be announced once we've successfully delivered the first milestone.

[CLAassistant]

All committers have signed the CLA.

[mmagician]

@yubo-ruan Thanks for the application. I see that you haven't checked all the boxes in the PR template - is there a reason for this? In particular:

• the box for announcing the grant hasn't been ticked - this is important to us, as it shows that you agree to the delivery & announcement rules
• please squash your commits (cosmetic request)

Please notice that we don't support payment in ETH, could you please update to DAI?

Also, you're missing an Overview section for the Development Roadmap, with total costs etc.

Please note that we won't review your application until the above points have been addressed.

Finally, thanks for sharing your previous hackathon code. Could you outline whether this is the same scope as the hackathon, or perhaps you're developing extra features, building on top of what you've delivered for the hackathon?

[yubo-ruan]

@yubo-ruan Thanks for the application. I see that you haven't checked all the boxes in the PR template - is there a reason for this? In particular:

• the box for announcing the grant hasn't been ticked - this is important to us, as it shows that you agree to the delivery & announcement rules
• please squash your commits (cosmetic request)

Please notice that we don't support payment in ETH, could you please update to DAI?

Also, you're missing an Overview section for the Development Roadmap, with total costs etc.

Please note that we won't review your application until the above points have been addressed.

Finally, thanks for sharing your previous hackathon code. Could you outline whether this is the same scope as the hackathon, or perhaps you're developing extra features, building on top of what you've delivered for the hackathon?

Hi @mmagician, we added the overview session and fixed a few issues that you brought up. Let me know if you have any other questions. Thanks!

[yubo-ruan]

@mmagician Regarding the next steps, we plan to develop extra features on top of the hackathon project. We will develop the cross-chain staking and transfer module to support native token DOT and KSM. All of our team is working full time to commercialize this idea and we plan to raise additional funds and participate in para-chain auction.

[mmagician]

@yubo-ruan Aren't DOTs and xDOTs supposed to be worth the same? I'm a bit lost as to the following point:

We will implement a the process for issuing and trading DOT for xDOT with the users based on our exchange rate

---

When staking tokens, does the user get to choose which validator they want to nominate? If not, what's your mechanism for selecting whom to stake with?

---

Why do you need an oracle at all? I guess this ties in to the first point. Also, since your focus is not on building an oracle solution, we would prefer not to support this development as part of the grant, but we'd rather encourage you to use existing solutions.

We will need to create a on-chain price aggregation pallet for the oracle prices from multiple source that is queried by off-chain workers.

---

We will integrate our existing front end to the finalized substrate backend

I haven't looked in depth at your dApp, but could you perhaps outline how much integration work is already done and how much more would you need?

---

We will conduct user testing to improve our product's UX and UI, to ensure that the staking functionalities are intuitive

That's great and I would personally love to see more such deliverables - provided that you can deliver quantitative results, as well as providing us access to raw collected data from such tests. Please specify your concrete testing plans (numbers, methods, desired outcomes etc.)

---

In general I like the idea behind your protocol and I think it would be a good addition to the ecosystem. Please let me know if you can address the above comments before proceeding further.

[mmagician]

@yubo-ruan I have some further feedback. In general, our grants focus on the development of new software, such as new substrate modules. I feel like your application is going in the direction of directly preparing to launch a parachain and putting all the pieces in place - though correct me if I'm wrong.

---

We will create a Substrate module that will utilize XCMP protocol to enable cross-chain transfer of DOT and KSM through Relay chain

I believe you could leverage the xtokens module from the ORML library to achieve this functionality.

---

We will implement a 28 days locking period for the unstaking process of DOT tokens from validators

At the end of the day, the (DOT/KSM) tokens that users locked in your Parallel app must end up on the relay chain in order to actually participate in staking. Therefore, you must be playing by the rules of the relay chain, which already has a lock-up period built-in. Therefore I don't understand the purpose of this deliverable.

---

Staking tokens does have inherent risks of being slashed. We will implement our model that will change the exchange rate in case of slashing scenarios

This is tricky. My initial thought was that when the stake is subject to a slash, then there will be less DOTs available to re-claim. But this will leave a user with more xDOTs than DOTs -> and they could then exchange xDOTs 1:1 for DOTs and behave as if the slash didn't exist. Scenario:

• I stake 100 DOTs, get 100 xDOTs in return
• the validator is slashed 10%, so there's now only 90 DOTs staked.
• I wish to claim my DOTs back, so I burn 90 xDOTs for 90 DOTs.
• I then exchange my remaining xDOTs for DOTs on some DEX

That's a clear problem. I am starting to see why you wanted to introduce an oracle and why it might not be the case that the value of xDOT is pegged to DOT. Now my previous question on how validators are selected becomes all the more relevant - and I believe it requires all users' funds to be staked with the same validator(s). Otherwise, we're entering the realm of fungibility - what happens if validator A got slashed, but validator B didn't?

Would you mind elaborating on your idea of model that will change the exchange rate in case of slashing scenarios and provide full details of your solution please?

[yubo-ruan]

Hi @mmagician thanks for asking questions and here are the answers to them:

1. DOT and xDOT are not supposed to worth the same. exchangeRate = (initialStake + totalReward - totalSlash) / totalSupply. Notice the exchangeRate is the future value and we need to discount back 28 days to find the present value. We are still in discussion of what to use as the risk free rate but initially we plan to choose a number that is close to the average annualized staking rewards. For more information see here: https://docs.parallel.fi/technology/staking-workflow

2. Users don't need to select a validator and our platform will choose for them as it will be easier to use. We can optimize the algorithm to find the best risk-adjusted return. We will consider a few dimensions when choosing the validators: the reputation of node operator, uptime, historical slash records, own stake, commission ratio, and etc.

3. Correct, our focus is not to build an oracle solution, and thus we will try to use existing solutions. We plan to join the Acala Oracle as one of the first data providers and we also consider utilizing chainlink oracle once it is launched.

4. We are currently integrating with Polkadot and Kusama relay chain. We are currently developing and testing the Cumulus framework and XCMP protocol

5. Blockchain applications inherently have UX challenges compared to traditional applications and require more guidance and feedback loops for each user action. Initially, we will conduct qualitative user testing by observing 10-15 users use the v1 platform:
   -Interaction with the platform
   -Ability to find the major call to actions
   -Ability to navigate through the overall flow intuitively
   -Deliverable: summary of the findings and improvements made based on insights

We will implement more quantitative user testing with A/B tests, web analytics, and heatmap once we have more adoption (>100-200 DAU) in order to get more significant insights (not part of v1 deliverables).

6. Regarding the cross-chain transfer, we can utilize some of the existing modules and we will examine the xtokens module.

7. We don't need to implement the 28-day lock-up since it is the rules of the relay chain. However, we do need to implement a cross-chain function call to initiate the cross-chain staking and unstaking securely as well as monitoring the stash account balance in order to update the exchange rate.

8. All the DOTs will be staked into one pool of validators that were chosen by our system. One of our deliverables is to design this algorithm to select validators and try to optimize the return for our users. We consider running the algorithm in multiple decentralized nodes, which is also under careful design and development.

9. Since all funds are staked with the same validator(s), the exchange rate will depend on the total rewards and total slashed over time. Please refer to the solution here: https://docs.parallel.fi/technology/staking-workflow. Notice, this is still under development and we will update the exchange rate formula as part of the deliverables.

[mmagician]

@yubo-ruan Thanks for your detailed responses. I would like to follow-up on a few of these:

2, 8 & 9: There are of course no guarantees that the currently chosen validator will stay in the active validator set in the next session. In order to maximise the users' returns, you will need to monitor the active set and adjust accordingly in time.
5: Please add the testing details to your milestones in the .md file

I would be happy to support your project, but in my opinion the current price tag is too high. As I mentioned, lots of your deliverables (XCMP, staking & slashing) are centered on integrating as a parachain, which is not the focus of the Grants Program.

[yubo-ruan]

@mmagician Thanks for the feedback again. I'm glad to hear that you are willing to support us and we are committed to contributing to our ecosystem as much as we can. As the project and team grow, I believe we will develop more unique modules and contribute. Finally, let us know how do you foresee the next steps. We are flexible on the price tag if you want to suggest another idea.

[yubo-ruan]

@mmagician also updated the testing plans in our parallel.md file

[mmagician]

@yubo-ruan Thanks for updating the test deliverable.
As per my comment, there are only a few deliverables that pertain to the development of new code, rather than parachain integration. Perhaps 5000 DAI / milestone would be more appropriate.
This is only my personal suggestion. If you decide to choose a different cost, I will still share your application with other Grant Committee members - but of course the lower the cost the higher the chance for receiving 3 approvals.

[mmagician]

@yubo-ruan Thanks for the flexibility. Is this ready on your side now?

[yubo-ruan]

@mmagician Yes, it is good on my said as we change the amount. Now, everything is ready.

[mmagician]

Looks good to me

[BenWhiteJam]

Looking forward to it!

[github-actions]

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 [email protected] in case you're interested (at least two weeks notice is preferred).

[alxs]

Hey @yubo-ruan, care to share a quick status update on milestone 2, along with an ETA if possible? Taking the date your last delivery was accepted as reference, it is delayed by a bit over a month now. As long as you're actively working on the project, delays aren't a big problem, but please keep us in the loop.

Note that if we don't hear from you within the next two weeks, we'll assume you're no longer interested and terminate the grant.

[yubo-ruan]

@alxs we are finishing up milestone 2. Let me add my colleague CJ and Zhouyang to follow up you

[yz89]

Hey @alxs, milestone2 is always on the way. We iterated on the design a lot.

v1: https://github.com/parallel-finance/parallel/tree/db11d8b929abd5cc122a6492dd4a71771ea1562a/pallets/liquid-staking/src
v2: https://github.com/parallel-finance/parallel/tree/641260fc8ad83f0766289c4b83fb26e0cdd68858/pallets/liquid-staking-v2/src
v3: https://github.com/parallel-finance/parallel/tree/master/pallets/liquid-staking/src

stake client v1: https://github.com/parallel-finance/stake-client-rs
stake client v2: https://github.com/parallel-finance/stake-client

testnet: https://testnet.parallel.fi/#/staking

At present, the function development is almost completed. Delivery is expected by October 22.