#75 OpenSquare's treasury proposal for dotreasury M2
As you may know, we proposed dotreasury and finished our work for M1. Check post 352 for the proposal discussions and here for our M1 report. We hope you like our work and now we are proposing the dotreasury M2.
Work in M2
1. Account system
- Account registry
- Login & logout
- Binding with web3 addresses
It will be similar with account system of polkassembly.
2. Funded projects list and detail page
It's common that one project have support from several proposals. So it's not enough to just comment on one proposal or tip. We should get to know the funded projects and comment them from a higher view.
In the detail page, there will be descriptions about:
- summary of the project
- what this project have done with the treasury fund
- how many proposals/tips and in total how many KSMs this project has spent
- related links
- remarks to this project
Some consultant work maybe involved for this. I may ask questions to some beneficiaries and councilors.
3. Remarks support
Mainly in the expense detail pages and project detail pages. Remarks may come from:
- logined users. If the user has bind address, we will show the address or identity.
- anonymous remark. User don't have to login to leave this kind of remarks, but we need to think deeply about it. Maybe we will open it to user after the logined user remarks has been supported.
4. Burnt records
Only burnt records list, no need to show the detail.
5. Treasury income distribution
We will show it like 20% from gas, 30% from slash, etc. Maybe a doughnut chart will be shown.
6. Previous work polish
Mainly solve problems we mentioned in our M1 report.
- We may parse more special extrinsic that wrap tip action.
- Add more docs and test cases.
- Add settings for switch nodes.
Time and cost
Cost for M1 can be checked here, and the time is a little tight for us.
Considering our experience of M1 and the upcoming China spring festival, we want to decide the time to be 1.25 months. 3 developers, 1 designer and 1 operation intern will work on this M2, but we will not request cost for the operation intern.
So the cost list will be:
- 3 developers and 1 designer: ($6500 * 3 + $4000) * 1.25 = $29375
- Server fee for 2021.01 and 2021.02: (8vCPU + 16GiB + 500GiB SSD + 10Mbps) * 2 = $800
- We use MongoDB, but now it's deployed as single instance in our server, it's really unstable. We want a cloud MongoDB for more stable deployment to support upcoming remarks feature, but only from 2021.02. It is $500.
Take KSM price as $70, so the KSM expense: ($29375 + $800 + $500) / $70 = 438KSM
Output:
- New features supported in dotreasury.com
- Code repo.
FAQs
-
What's your next plans?
You can see our rough milestones here. Though there maybe small changes, our final target is to introduce retrospect mechanism to current treasury workflow. In the future, we aim to build a reputation system for treasury participators. Of course, we will do it cautiously. -
What's your plan to integrate polkadot?
Our plan is after M2.
Some other possible questions can still be seen here.
We are OpenSquare team, dedicated to facilitate the collaboration between projects and developers.
Show More
Thanks, @chevdor . We took the price close to that calculated by last 2 proposals by #73 proposal and #74 proposal detail. Sure it's advantageous for us, and hope there will be a formal way to define the price in the future to avoid dispute.
No worries, I just added it to have it at hand. I agree that we should define a standard way. It would make it easier for everyone. If you have the price information in dotreasury, that would actually be a nice addition: provide a calculator following the (not yet defined :)) standard.
I have been chatting with Raul and IMO, we could use something like:
- 30d average
- taken at the time of the proposal block (or very close to it)
Many teams already did that but I am assuming this is quite some extra work to pull the data, etc... That's why a little calculator would be useful. Subscan already provided the version I linked above but it does not include the 30d average (that was not in the specs at the time).
With the recent big movements, big variations are to be expected.
If you have suggestions/wish on how it could be done, please shoot :)
If you have the price information in dotreasury, that would actually be a nice addition: provide a calculator following the (not yet defined :)) standard.
Very good suggestion. And it's better for community to know the fiat currency cost for each funded project. Yongfeng once be the leader of qkl123.com project, and we think it's not a big problem for us to develop it.
Thanks, we will put it in future plan.
If you have suggestions/wish on how it could be done, please shoot :)
Hi, @chevdor, cc @rrtti-5220 .
Sorry I(Yongfeng) didn't reply this immediately, but I had a deep thinking about this today.
IMO, neither the 30d average nor the price at proposed block is a perfect solution, while a composition maybe better. Followings are my ideas.
Terminologies
Avg30 = last 30d average price
nowPrice = any price an hour before the proposed block
Final price we can take
finalPrice = Min(Avg30, nowPrice * 0.85)
Avg30 is good for beneficiaries when the KSM price is rising, but bad when it's dropping. nowPrice is also not good because the price may change a lot, especially when the beneficiaries want to hold the KSM for a long time.
So the possible proposal steps:
- Proposer start a discussion with the cost only calculated in fiat currencies
- If they decide propose onchain, calculate the price with the fomula metioned above
- What if the price rise a lot in the voting process?
Just let it go, the beneficiaries are lucky.
- What if the price drop a lot(over 15%) in the voting process?
Raise a tip for the beneficiaries to cover part of the loss. Why covering the loss? We should make sure the final fund can cover the cost at the awarded time IMO, or the beneficiary may be discouraged.
This is a just idea from a beneficiary, beneficial to the beneficiary role. We believe the coucilors can make the best decision.
Some other thinkings
We don't have to calculate the average price very formally, while it will involve every deal price and the corresponding volume. Just record the price at the end of each day, then do a arithmetic mean.
Indeed, such calculation could make sense.
Please check our report for this proposal here.
Discover similar proposals
