You are viewing a single comment's thread from:
RE: DSTORS(디스토어스): 비즈니스 모델이 가능한 것인가?
One more question: is it fixed to 1 unit = 1 stor? Or will increase to say 1 unit = 10 stor, as more SP delegated?
One more question: is it fixed to 1 unit = 1 stor? Or will increase to say 1 unit = 10 stor, as more SP delegated?
okay, now this is even more confusing.
For simplicity, let's assume that the price of steem remains constant, and ignore the STOR creation from the transactions, and focus on tokens generated from the SP delegation part.
The number of STOR token airdropped is linearly increasing in the number of SP delegated. Then, how are you going to decrease the number of STORs awarded per day? this is a simple, but critical question.
In addition, if transaction volume grows, so STOR token distribution to buyers and sellers. Or at least, there should be a fixed amount of STOR token distributed per day from transactions. In any case, decreasing number of STOR as transaction volume goes up does not make sense.
And for a numerical example, let's say you reach your goal of 4.5m SP delegated. Even under the conservative assumption that all SP delegated are round C and gets only 1 token per 1 SP, it will result in about daily 25,000 STOR airdrop from the SP delegation alone. But from my understanding, per each day you will only decrease 1,000 STOR (10 full votes) by selling votes. Where would the rest of tokens go or get used?
Per day, there will be 1,000 units of 1% upvotes available. Daily, the amount of upvote that can be garnered per STORS token will be set (maybe weekly). So, if the limit of upvotes per day is 1,000 units of 1% upvotes, then dStors will set 1 STORS = 1%. If price of STEEM increases to $2; then 1 STORS = 0.1 of 1%. Not ALL STORS submissions will be serviced for upvotes for that day. Just like the bidbots, daily upvotes that can be captured will be limited to 1,000 units of 1%. NOW, two scenarios are potential:
I hope this answers your question.
Also, no airdrops will happen, to make it clear.
Inflation of STORS is purely dependent on completed transactions that are awarded.
Delegators who received STORS will have to spend stors for the upvotes. The amount they get will depend on the purchase power of STORS for that 1% unit of upvote.
Can all stors be serviced in totality from an upvote request? Yes, but it'll take a while. This is why, we'll setup a potential for bidding. Votes will go to the highest bidder using STORS.
So, just like the bidbots, 10 votes per day. That's the load and per day, it won't service all STORS tokens rewarded. That is not the point. In other words, not everyone can cash out STORS for upvotes all at once.
I think that's good because it'll "force" many to hold the STORS.
Initially, upvotes will be first come first serve. Then, upvotes will likely have to be bid for using stors.
Again, there is no way to service all STORS for upvotes right away.
It's like imagine if every Korean Air air-mile holder wanted to cash in on their free tickets all at once......the airline won't allow it. However, steady flow is manageable for them as it will be for dStors.
Just like how airlines have certain number of seats at certain times available for purchase using air-miles; dStors has 10 votes per day limit.
However, unlike air-miles which can't be bought or sold on an exchange, STORS tokens will be available to sell and buy on the exchanges.
The project is in-development and we reserve the right to change and improve our reward mechanism and the experience for our users as appropriate.
p.s. Whitepaper now states:
Thank you.
Thank you for your detailed reply. This reply answers lots of questions I had. Now I think I got the main concept, but it seems that 'the devil is in the detail' like in many cases.
But it is certainly assuring to have founders who are responsible and energetic. Again, thank you for your time and effort answering my questions and promptly fixing the whitepaper.
If you are in the process of updating whitepaper, you may want to update the formula in the page 11 (7.4). First is typo: it says summartion from k=0 to n, but it seems that you meant i=0 to n. Second, this part is not certain, but to me T_i is a bit confusing, as "i" denotes for each transaction so T_i does not really make sense - to my understanding, it should be "T", which is a total number of transactions in a certain day.
Hello yet again @glory7
The formula has been adjusted to reflect your suggestion:
I will update the WP as well. Thank you again!
Thank you for letting me know. Glad to see that suggestions are reflected immediately!
Thank you @glory7! You certainly helped greatly. And yes, the devil is in the detail and you have a great eye for it. I will edit the formula as well and post an update to this thread here 👍