Introducing Open Cost Ledger - Optimization of Vote Purchases
Since the inception of Smartsteem, our main focus has been to offer the best promotion tool available for the Steem ecosystem. It's with this in mind, that we are constantly revising and refining our tools and services through careful development.
A few months ago, we were alerted of a small occurrence, where some vote buyers through @smartmarket would get more votes than they actually paid for. This particular issue came about simply due to the very nature of voting power percentages.
The intention of this point is to explain the issue and to clarify the steps we are taking to correct the unbalanced calculations.
Detailed Explanation & Example
The following breakdown is intended as the simplest explanation possible. The specific values of upvotes can of course vary, as the valuation of STEEM fluctuates constantly.
Let’s assume we have a vote selling account that holds 1 million STEEM Power. Let’s refer to this account from now on as @vote-seller. Let’s also assume a VP that does not deplete, simply for the sake of simplification.
Also for our example, the only account available to vote at the moment of the transaction is @vote-seller. In other words, his vote would not be added to a trail or compounded with any other voting account.
ROI: 1 SBD vote purchase => $1.5 STU Result
The Roundup problem
- Votes at 1% with today’s valuation would be exactly: $0.84 STU
- Votes at 2% with today’s valuation would be exactly: $1.68 STU
- Votes at 1.3% with today’s valuation would be exactly: $0.84 STU
As you can clearly see, the blockchain rounds the 1.3% and makes the voting result exactly the same as a vote that has 1% of weight behind it.
Now imagine an account that sends to @smartmarket 1 SBD to purchase votes. As we discussed before, at the moment of this transaction, the only seller available is @vote-seller. Since, the roundups cause a problem a refund is calculated and sent back.
The process would work like this:
- Voting at 1% = $0.86
- Target of $1.5 not hit
- The difference is calculated
- 0.42 SBD is sent back to buyer
As you can see, this does not seem like an optimal way to operate. In other words, the buyer is unable to access the potential vote he/she wants due to the roundup issue.
We believe we can find a better way that can work for everyone.
In simple terms: Let’s round the numbers up.
So when a vote buyer purchases his vote from @vote-seller he would get the next exact percentage up, instead of down. For our specific example it would work like this.
What about the difference?
Of course this operation has to be a win for absolutely everyone involved. We could not simply expect the vote seller to give away a part of his vote, represented in our example by the $0.18 cent difference. In truth, up until now we have been covering that difference at our expense, but we know this is not a sustainable way of operating. Simply said, the costs pile up.
Our solution to this second problem…
Open Cost Ledger
The simplest way you can think of this ledger is as a promotion fund. Every time you send transfers to it, it would operate in your best interest. Meaning, that it would add the cost of your promotion to your particular ledger, while at the same time allowing you to purchase the bigger vote.
The ledger will self-balance in the next transactions, whenever we would partially-refund transfers due to not enough available voters. Thus keeping your account up to date and giving priority to your promotion requests before re-balancing the Open Cost Ledger.
Now, it’s important to mention that the main goal of this change is designed to optimize vote availability. The balancing of the Open Cost Ledger only happens when it becomes viable, when the transactions allows it. The balancing of the ledger is automated.
We trust that this changes will allow our customers to take better advantage of our service. Allowing more optimal windows for purchasing without relying on optimal vote availability, which should allow a more fluent system at any time of the day.