# Introducing Open Cost Ledger - Optimization of Vote Purchases

in #steem6 years ago (edited)

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.

## Assumptions

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.

## Vote Purchase

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.

# Our solution

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.

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

As seen on smartsteem.com/balance

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.

# In Conclusion

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.

Team Smartsteem

Sort:

Am I reading this right... you are back charging for votes you say were fractionally over voted? Not just a new thing you are doing, but back charging for votes already done, gone and buried that you say were under paid for?

6 years ago (edited)

Been with Smartsteem since march and there was never a problem (that was'nt solved in no time!).
Best thing for me that with @therealwolf i can ask questions in german what helpt a lot since my technical english is horrible^^

Good to see you're improving your system!
I may have to try this one day.

You may have to do that some time ;)

Smartsupport

Interesting, and slightly worrying discovery for those who use % to decimal places.

However, have you checked whether the issue resolves itself upon payout?

I mean, as in your examples, a 1% and 1.3% upvote would generate different rshares that on payout are converted to SP, STEEM and SBD. Are those payouts different, even if the US\$ pending rewards figure is wrong?

Thanks.

Hey @accelerator,

we tested the theory out in practice and while we didn't check the payout, the rewards where the same regardless of 1% or 1.3%

Smartsupport

Could you explain how 0.005 became 3.816 ????

Cleared Open Costs: 0.551 + 3.265 = 3.816

Could you explain where the funds go from each transaction ?

6 years ago (edited)

the `3.816 SBD` Open Costs that got cleared, as seen in your screenshot, were accumulated over the last months.

We just recently added transactions-entries, which you're now seeing for `0.002 +0.001+0.001`.

Also, please keep in mind that you profited from more votes than you paid for (as the rest cost were paid by us) for months, as we weren't aware of the occurrences at that time.

We are doing our best to offer you a transparent & effective service and are always looking to improve (i.e. the open-cost entries in your history).

All the best,
Smartsupport

6 years ago (edited)

The law does not have retroactive effect, doesn't it? Why customers must pay for your mistakes? From where I know that what exactly is this amount, maybe the amount was not 3.816 SBD but 0.005 or -53.008???? And did you return all Cleared Costs to vote-sellers?

And you did not answer for second question. So i am waiting for that

6 years ago (edited)

we can understand that this post might be a bit overwhelming. And we also see the point you're making about the retroactive effect.

However, we didn't make any mistake per-se. For months, you and other vote-buyers have been receiving part of your votes for free. The open costs have been paid by us - as votesellers of course were credited for the whole voted amount. (as explained in the post above)

And few months ago, after we realised about the occurrences, they were added after every vote-purchase to your open costs ledger.

We do understand that missing histories is a reason for scepticism, but please be reminded that we guaranteed, in your case, over 380 unique vote-purchases with our positive ROI (at the time of purchase).

Last but not least, we've worked hard on creating a post which should answer all questions. If there are still questions open from your side, then please read the post again.

All the best,
Smartsupport

nice

smart steemit become more smarter with such pretty tools ! keep doing the same

I love smartsteem they always make sure they deliver good service in their market strategy.

I have used the tool and it is pretty good

STEEM 0.23
TRX 0.12
JST 0.029
BTC 66649.32
ETH 3562.88
USDT 1.00
SBD 3.12