www.DCRStake.com Next generation Decred staking
A collaborative platform where people share voting authority as well as ticket reward on a per-second basis
Decred staking problem Decred staking has two major problems: - Very high ticket price which prevents most people from participating in POS as well as voting in agendas - Ticket lock time where money can't be spent which is usually more than 28 days
Solution An efficient ticket, vote, and reward sharing platform where users collaborate to participate in POS, help shape the future of Decred, and share tickets' rewards without the usual limitations of Decred POS.
How does it work? Users deposit some Decred through the service website, that money are used to buy tickets and whenever a ticket votes, the reward is distributed among all participants who had balances during ticket life time, in the meanwhile when a user requests to withdraw all/some of his money, the withdrawal request is recorded in a "pending" state and gets processed once there are enough funds and he gets rewards based on the time span he participated for all tickets that were live during any point of time where he had balance at.
How about votes? Agendas votes are handled using a similar approach where each user has a voting authority proportional to his balance and how much time he had this balance.
----------------------------------------------------------------------------
Detailed ExplanationThe service consists of 6 layers:
- Private layer
- Voting layer
- Shared layer
- Workers layer
- Database layer
- Interface layerPrivate layer consists of:
Private encrypted wallet.
Deposit addresses generator that prevents address pool from running out of deposit addresses.
Transaction handler which handles wallet transactions each with required action.
Deposit handler which credits accounts with deposited funds.
Withdraw handler which uses a priority based algorithm to handle withdraw requests.
Ticket buyer which buys tickets with spendable funds only (spendable funds here means spendable wallet funds minus sum withdraw requests which ticket buy operations will happen if and only if no pending withdraw requests exists).
Voting layer consists of many geographically distributed nodes with each node consists of the following:
Voting only wallet to handle ticket votes.
Vote maintainer which keep the wallet synchronized with currently winning vote for each agenda.
Ticket revoker to revoke missed tickets if exists to avoid a missed opportunity if a missed ticket is not revoked immediately after missed.
Shared layer consists of the following:
Random Decred wallet.
Message verifier which verifies signed message to fulfill login requests.
Ticket watcher to determine if a ticket life ended and take the appropriate action and deliver that ticket to the next worker.
Ended ticket handler that receives ended ticket from the previous worker and takes the appropriate action.
Stable date maintainer which maintains the system "Stable Date" a term used to determine the last date that any transaction prior to that point is "Stable" which is usually varies from 30 minutes to 24 hours before current date (deposit and withdraw transactions are not affected by this term but it exists because of the fact that ticket votes takes 256 blocks to be available)
Workers layer consists of multiple workers to handle the following tasks:
Calculate, distribute , and credit balances with rewards based on their contribution of every ticket.
Calculate, decide, and store the currently-winning vote choice for every active agenda.
Collect the service fee for every voted ticket (5%) as well as pay the same percentage from the system for missed/expired tickets.
Database layer A database that allows authenticated and encrypted connections from other layers only.
Interface layer contains the website and internal applications to manage workers.
We ran a beta testing to test all possible scenarios over testnet and ensured no loss is possible, the worst-case scenario is with missed/expired ticket because split tx fee + ticket tx fee is deducted from all balances each with his share which may cause negative balances with very small amounts if the user withdrawed his balance before the distribution and that's not a problem at all because with 2+ live tickets at any given point of time any negative balance from one missed/expired ticket will be covered from vote reward from the other ticket and even if only one ticket existed negative balances will be covered from the system fees (the 5 % fees).
How it works (In Detail)Deposits is clear enough, users deposit Decred through the deposit address
Ticket buying whenever there's enough spendable balance available to purchase a ticket, a ticket will be purchased and as I illustrated before "Spendable Balance" here means spendable wallet balance minus sum pending withdrawal requests which means no tickets shall be purchased if there exists any pending withdrawal requests and in the future we plan to keep a small percentage as a reserve to increase the liquidity.
Withdrawals whenever a user wants to withdraw part/all his money, he submits a withdrawal request, the request is recorded in a "Pending" state and remains in the "Pending" state until there are funds available to fulfill that request (during the "Pending" state user is still participating in voting and getting rewards for his balance but the withdrawal amount is locked)
Ticket voting explained better through a simple example.
ExampleAssumptions just for easy illustrating:
Ticket price is fixed to 100 DCR.
Ticket reward is exactly 10 DCR.
A ticket takes exactly 10 Days to vote.
Scenario
User A deposits 50 DCR at 01-01-2018.
No enough DCR available to purchase a ticket.
User B deposits 60 DCR at 02-01-2018.
Total balances is 110 DCR.
Ticket Buyer Purchases a ticket at 100 DCR.
Remaining Balance is 10 DCR.
Nothing happens through 02-01-2018 to 12-01-2018
Ticket votes gives the reward of 10 DCR
As all users had their balances from the start to the end of the ticket life time The reward is distributed as follows:
The system takes 5% which is 0.5 DCR (10 * 0.05)
User A takes approximately 4.32 DCR (9.5 * 50/110)
User B Takes approximately 5.18 DCR (9.5 * 60/110)
If there was another user who deposited money in the middle of that ticket life time he will get rewards also but for his contributed time only and that is calculate on a per-second basis
For the voting part lets assume there exists one agenda, user A chooses Choice 1 and user B chooses Choice 2
All the time there's a worker that decides which vote is the winning vote on a per-second basis just like the reward for easy illustration let's assume it's based on a per-day basis
User A has voting authority of 50 DCR for 11 days
User B has voting authority of 60 DCR for 10 days
At the time of the vote the voting authority for all users is as follows:
Choice 1: 550 points.
Choice 2: 600 points.
So the ticket will vote for Choice 2
After the ticket successfully votes the required voting authority which is calculated based on the ticket life time and the ticket price is deducted from the system which keeps the remaining voting authority as follows:
** Required voting authority** equals 100 * 10 = 1000
Choice 1: 550 points.
Choice 2: -400 points.
The next ticket if bought will vote after 10 days and by then the global voting authority if the balances remains without changes will be
Choice 1: 550 + 54.32 * 10 = 1093.2 points
Choice 2: -400 + 65.18 * 10 = 251.8 points
So the next ticket will vote for choice 1 and the remaining voting authority is as follows:
** Required voting authority** equals 100 * 10 = 1000
Choice 1: 93.2
Choice 2: 251.8
And so on
Needless to say that this example is very simplified but it illustrates the concept clearly and the difference is only pure complicated calculations
