Help us fix a DLease Bug - 200 BUILDTEAM + 200 STEEM Bounty

As you all probably know by now, DLease is an excellent way for those with a lot of STEEM POWER to grow their investments, and those who want more STEEM POWER for a limited time to find what they need.

Especially now after HF21 with the curation rewards being 50% of the post payout instead of 25%, having a lot of STEEM POWER is beneficial.

With more and more people using DLease, we're also occasionally running into unexpected bugs that we are not always able to fix ourselves.

The latest bug is that DLease doesn't report the correct available STEEM POWER available for delegation when the user is powering down. Currently, it overstates the available SP.

This info is displayed on your dashboard under Idle STEEM POWER.

If you want to help us solve this, there is a 200 BUILDTEAM Token + 200 STEEM bounty for the first good solution to this problem.

Please contact @thecryptodrive (thecryptodrive#8144) on Discord with your fix or your suggestion for a fix!

The current code to calculate idle STEEM POWER is:

let free = this.powerOwned - this.powerDelegated - this.poweringDown;
let effective = free + this.powerReceived;
let available = effective * this.votingPower;
if (available > free) {
     available = free;}
     return ((available * this.steemPerVest ).toFixed(3))

Thank you for your support!

Visit our website for more!
Subsribe to our YouTube Channel
Check out @Minnowbooster
Don't miss out on @Steemvoter
Set @buildteam as your Steem witness proxy
Set it up today and contribute to building a better tomorrow!
( Want an easier way? Use our SteemConnect proxy link! )
Join our Discord Chat
Get support and connect with us and other BuildTeam fans!

Disclaimer: This is a @steemvoter subscription payment post. Thank you to Steemvoter customers for allowing us to use your Steem accounts to upvote this post by virtue of your free subscription to the curation automation service. @steemvoter is proudly a @buildteam subsidiary and sister project to @dlease, @tokenbb, @ginabot, @steemsports. @steemsports-es and @minnowbooster.

Beneficiary Declaration: 10% @null burnpost + 10% @steem.dao

Remember to vote for your favourite Steem proposal at!

Comments 17

Downvoting because I think with #NewSteem it is even more clear than ever that using the reward pool to pay for Steemvoter subscriptions is not really appropriate (it was always controversial).

10.09.2019 05:11

Being that the case we may have to start shutting down free or unprofitable services such as GINAbot, QuickSteem, TokenBB etc. We have always done our best to be honourable and run our own nodes etc when our competitors didn't, at great cost to us, we have even taken steps to make our posts have a corporate social responsibility aspect as seen in our foot above with 10% to @null and 10% to @steem.dao.

Our strategy outlined in yesterday's post

In that same post we also laid out a challenge to Steemit inc, which is the biggest elephant in the room and the target that will make the most impact if the community can apply pressure for them to include a tax burn with their programmatic selling.

In that post we highlight that all our services bring in a holistic income that help to keep the lights on during times of low Steem price performance, we are literally on the bones of our bum and now we have to contend with stakeholders downvoting without taking into consideration the holistic picture of our business.

I also urge you to read this post regarding user sentiment towards downvoting and my reply therein:

10.09.2019 05:25

help to keep the lights on during times of low Steem price performance, we are literally on the bones of our bum

We all are, but it also makes the challenges of trying to do something systemically good with the reward pool being directed by proof-of-brain and not milked by self-voting and vote selling all the greater. Every bit of payout is precious at this–some may be close enough to a public service/public good they would be good candidates for SPS or upvoting of posts about them–but steeemvoter specificifically, I see v offers 90% or more of its value tocustomers and itsfact do disagree, o

10.09.2019 05:32

A business especially is more vulnerable because it has fixed costs in USD for infra, if a user is on the bones of their bum on Steem and not earning what they used to is different to a business which can go into the negative profit due to infra cost obligations. Atm our team is dissillusioned that we are being targetted and it is serving to re-inforce that Steem is not friendly for business, we are not in the business of milking the rewards pool for frivolity, we provide value, employ developers, many well known names on Steem started out with the support of BuildTeam.

I also don't believe downvoting bodes well for user retention, if my first encounter with you was a downvote, instead of encouragement and support. I likely would not still be here on Steem today.

Also, I cannot take stakeholders' objections seriously unless they take action against the greater problem, which is Steemit inc's systematic selling. Targetting smaller users and businesses is the easy way out to not have to tackle the real problem head on.

10.09.2019 05:41

With HF20, the part of the Steempower that would be powered down is subtracted from the effective Steempower.

I've added that logic to dsteem after the HF:

You can either write it yourself for effective vests:

import {Asset} from 'dsteem'
const vests = Asset.from(account.vesting_shares)
const vests_delegated = Asset.from(account.delegated_vesting_shares)
const vests_received = Asset.from(account.received_vesting_shares)
const withdraw_rate = Asset.from(account.vesting_withdraw_rate)
const already_withdrawn = (Number(account.to_withdraw) - Number(account.withdrawn)) / 1000000
const withdraw_vests = Math.min(withdraw_rate.amount, already_withdrawn)
vests = vests.subtract(withdraw_vests)
vests = vests.subtract(vests_delegated)
vests = vests.add(vests_received)
return vests.amount

Or use the already in-built function for that in dsteem:

const client = new dsteem.Client('')
const account = await client.database.getAccounts(['therealwolf'])
const vests = dsteem.getVests(account)

10.09.2019 08:19

Why is already_withdrawn = to_withdraw - withdrawn?
That should be the quantity which is not withdrawn yet and which is missing yet.
(That's the number we use at the moment).
If I do a math.min on that with the withdraw_rate the available quantity doubles and we're already displaying too much.

A bit more detail of our calc:

        store.powerOwned = parseInt( result[ 0 ].vesting_shares.split( " " )[ 0 ] );
        store.powerDelegated = parseInt( result[ 0 ].delegated_vesting_shares.split( " " )[ 0 ] );
        store.powerReceived = parseInt( result[ 0 ].received_vesting_shares.split( " " )[ 0 ] );
        store.poweringDown = parseInt( (result[ 0 ].to_withdraw - result[ 0 ].withdrawn) / 1000000 )
        store.votingPower = result[ 0 ].voting_power / 10000;
10.09.2019 13:00

Not sure why you're making it so complicated. The code I linked above (dsteem version) is exactly what I'm using and it spits out the same numbers you'll find on The code you shared seems fine, so I can't tell based on that where the problem might lie, besides that Math.min(withdraw_rate.amount, already_withdrawn) is missing.

10.09.2019 20:37

It's because we need a different number than the one on steemd, we need to find out how much of the steempower on the account can be used to delegate.

10.09.2019 20:38

Have you checked whether it's voting mana related? If you have 90% voting mana, you can only delegate 90% of your base Steempower

12.09.2019 18:11

It's even more that just that. If you have received delegated vests, then you can't delegate more than the % you will drop bellow the amount of vests that belong to the received delegation.

I have come up with a function at home... that I am still reviewing, once I find the right sauce, I will post here.

12.09.2019 21:43

Thanks so much for enaging with us to help solve the problem.

11.09.2019 00:32

I was starting to have an idea last night about was intended. I will see if I can get back to it again today. I understand what it's the objective here, but I need to extrapolate more of the maths involved here to understand if it makes sense.

11.09.2019 05:09

Ok... this is my entry =)

I Welcome some feedback @therealwolf

Forgive me the standards and code "beauty" as I am not a dev guy and besides some advanced troubleshooting skills, I can only try to learn from many in terms of programming skills. Either way... this is my contribution.

By the way... @steemchiller, you might want to look at this... as delegating with your tool, under some of these situations, will throw some "warnings" that I have "potentially" covered with this code. =)

# -------------------------------------------------------------------------
store.powerOwned = parseInt( result[ 0 ].vesting_shares.split( " " )[ 0 ] );
store.powerDelegated = parseInt( result[ 0 ].delegated_vesting_shares.split( " " )[ 0 ] );
store.powerReceived = parseInt( result[ 0 ].received_vesting_shares.split( " " )[ 0 ] );
store.poweringDown = parseInt( (result[ 0 ].to_withdraw - result[ 0 ].withdrawn) / 1000000 )
store.votingPower = result[ 0 ].voting_power / 10000;

let free = this.powerOwned - this.powerDelegated - this.poweringDown;
let effective = free + this.powerReceived;
let available = 0;

# locked = PowerReceivedLockedVestsRatio (1 - 0.00)
# This is the absolut ratio of vests that can't be delegated (aka, percentage of VP locked)
let locked = 0;
if (this.powerReceived > 0) {
    locked = (this.powerReceived / effective);}
if (this.votingPower <= locked) {
    available = 0;
    return ((available * this.steemPerVest ).toFixed(3));
    available = effective * (this.votingPower - locked);
    return ((available * this.steemPerVest ).toFixed(3))
# -------------------------------------------------------------------------
13.09.2019 12:01

Thanks for your entry, @raycoms will evaluate and let us know.

13.09.2019 22:57

I'm thinking of joining soon

28.09.2019 01:06

I confirm that @forykw has solved this bounty and will be receiving the rewards on our distribution day on the 30th.

28.09.2019 01:57

And I have learned a lot during the process. So thanks for that!

28.09.2019 03:55