It's been a really busy week but I've finally finished what I think are a very nice set of new updates to the Post Promoter software that should benefit both bot owners and users alike! So find a comfortable seat, cancel your appointments, and let's get into it!
A number of bot owners using the software brought up the issue that if a new or updated delegation comes in right before a withdrawal then that delegator receives an oversized portion of the payout even though their SP did not contribute much to that round.
The code has now been updated so that new or updated delegations do not take effect until the next withdrawal period. If withdrawals are daily then they will not receive their payout until the following day, and if withdrawals are after each round then they will not receive their payout until the following round.
This was a relatively simple change code-wise. Now whenever a delegation transaction comes in the updated amount of vesting shares is saved in a "new_vesting_shares" property in the code's internal list of delegators, rather than updating the "vesting_shares" property which is used for calculating the payouts.
Then after a withdrawal is finished a new function is called which updates the "vesting_shares" property to be equal to the "new_vesting_shares" value for any delegators with new_vesting_shares > 0. Here's the code for that function:
function updateDelegations() {
// Find any delegators with a new or updated delegation amount.
var updates = delegators.filter(d => parseFloat(d.new_vesting_shares) > 0);
for (var i = 0; i < updates.length; i++) {
var delegator = updates[i];
// Copy the new_vesting_shares value to vesting_shares and set new_vesting_shares to 0
delegator.vesting_shares = delegator.new_vesting_shares;
delegator.new_vesting_shares = 0;
}
saveDelegators();
}
Another delegation-related change requested by a few bot owners is the ability to specify certain delegators whose payouts should be sent to a different beneficiary account. In certain cases a delegator may wish to decline a payout or donate their payout to another account, and now the software supports that using the "overrides" property within the "auto_withdrawal.accounts" list like so:
"auto_withdrawal": {
"active": true,
"accounts": [
{
"name": "$delegators",
"stake": 8000,
"overrides": [
{ "name": "delegator_account", "beneficiary": "beneficiary_account" }
]
},
...
In the example above 80% of the bot's earnings are set to be paid out to delegators based on their delegation amount. With the new "overrides" property you can now specify a beneficiary account where payouts should be sent for specific delegators. "overrides" is an array so you can add multiple delegator beneficiaries.
As you know there already exists a Maximum Post Age setting (max_post_age) to prevent users from buying upvotes for their posts at the last possible minute before payout to try to avoid downvotes, however there are also some spammers who grab profits from bid-based voting bots by posting right at the end of the bidding round and then buying a vote on their post right after it was published in order to take the 25% normally reserved for curators for themselves.
In order to prevent this there is now an option to specify a minimum age for posts that can be submitted to the bot:
"min_post_age": 20, // In minutes, minimum age of post that will be accepted
I suggest a minimum post age of 20 minutes, but each bot owner can choose an amount of time that they feel works best.
This setting, if enabled, offers a very big benefit to bot users in that it prevents a situation where a round gets seriously over-bid causing everyone to lose out. Every so often, for whatever reason, a round gets bids worth significantly more than the bot's vote value and everyone in the round takes a big loss. While this is good in the short term for the bot owner, in the long run it's a really bad experience for users and will undermine confidence in, and usage of, bid-based voting bots.
So now bot owners have the option of limiting the value of the bids that can be accepted in each round as a percentage of the bot's vote value (based on the current market prices of STEEM and SBD, and after factoring in 25% curation rewards) using the new "round_fill_limit" setting:
"round_fill_limit": 1.1 // Limit the round to 110% full to guarantee no worse than a -10% ROI
If it is set to 1 then it will limit the value of the bids in each round to at most the value of the bot's vote. If it is set to 0.9 then it will limit it to 90% of the bot's vote guaranteeing a minimum 10% ROI, and 1.1 will limit to 110% of the bot's vote limiting the ROI to no worse than -10%. Hopefully you get the idea at this point.
If any bids come in that will push the round over the set limit then they will be refunded to the sender. My suggestion is that bot owners set this to 1.1 and that's what 
Based on that I think that breaking even or getting a slightly negative direct return from the bot's vote is ideal, and also offers a good trade-off for bot owners. But each bot owner can decide whether or not they would like to use this feature and what value works best for them. I know a few smaller bots are using it already in addition to
So looks like it was another marathon post, but for those of you who made it all the way here - thank you! As always I want to also thank everyone who has helped and supported me in creating this software. Please stay tuned for more updates in the coming weeks!
Links to relevant commits: