Scotbot parameter manual

As you my know may know, I'm the developer of the scotbot backend. The bot is written in python and uses my beem library. In order to add your token to scotbot, the active key of the token issuer account itself or any other account that have sufficient token in their wallet is needed. The bot uses the key to send out token when a user has a sufficient amount of pending token and is willing to claim them.

You can read more about it here.

Let me explain all parameter that can be set at https://sto.steem-engine.com/#/launch/scotbot:

json_metadata_keyand json_metadata_value

This parameter is important, it defines which parameter in the json metadata of a post is checked. One possible choice is "tags". Only posts that have a json_metadata_key parameter in the json metadata field are included and can collect rewards. The value of the json_metadata_key must include or be equal to json_metadata_value.

When json_metadata_key="tags" and json_metadata_value="scottest", then only posts that have a "scottest" tag can have pending tokens. Pending tokens will be generated when token holder upvote this post.

json_metadata_key can also be a new parameter, as for example scot_token. In this case, a new frontend is needed that broadcasts posts that have this parameter in its json metadata field.
When json_metadata_key="scot_token" and json_metadata_value="MYTOKEN", posts that have:

json_metadata": {
"scot_token": [ "MYTOKEN"]
}

can have receive token from the MYTOKEN reward pool.

At the moment it is advised to use the tags parameter and define a tag that every post must use for receiving token from the reward pool

rewards_token and rewards_token_every_n_block

These two parameters define the size of the reward pool. Every rewards_token_every_n_block steem blocks, the reward pool is increased by rewards_token .

When for example rewards_token_every_n_block=3 and rewards_token=8, 8 token are added to the reward pool every 9s (3 blocks). Every hour, 3200 token are added to the pool and every day 76800 token.

The reward pool is distributed entirely to authors and voters.

reduction_every_n_block and reduction_percentage

Every reduction_every_n_block blocks, the amount of token that are added to the pool is reduced by reduction_percentage.
When reduction_every_n_block = 10512000 and reduction_percentage = 0.5, the reward is reduced by 0.5% every year. For example, when the old reward was 8 token, it is reduced after the first year to

8 / (1.005) = 7.96

cashout_window_days

This parameter defines when voting on a post is closed and the amount of pending token can be claimed. For example for steem, cashout_window_days is 7.

issue_token

When this parameter is true, claimed token are send out with the issue command. This is only be possible when the token account is also the token creator. When issue_token is false, token are send out with the transfer command. In this case, the token account just needs to have sufficient token in its wallet.

author_reward_percentage

Defines the split between post creator and upvoter. When it is set to author_reward_percentage = 50, 50% of the pending tokens goes to the author and the remaining 50% to the voters.

author_curve_exponent

This parameter can be a number between 1 and 2. author_curve_exponent = 1 is equivalent to linear and author_curve_exponent > 1 means super linear.

The pending token for a post are calculated as follow:

y = token_config[token]["author_curve_exponent"]
weight_rshares = int_pow(sum_rshares, y)
pending_token = int(weight_rshares / pending_rshares * reward_pool)

When author_curve_exponent > 1, it means that posts with more votes will receive an increased share from the reward pool.

Example

When author_curve_exponent = 1, and we have two posts, one with 100 rshares and one with 1000 rshares and the reward_pool has 1 token:

pending_token = 100 / 1100 * 1 = 0.09

and

pending_token = 1000 / 1100 * 1 = 0.91

When author_curve_exponent = 2, the pending_rshares is 100 * 100 + 1000*1000 = 1010000

pending_token = 100 * 100 / 1010000 * 1 = 0.009

and

pending_token = 1000 * 1000 / 1010000 * 1 = 0.991

curation_curve_exponent

This parameter defines the curation rewards. It can be a number between 0.5 and 2.

The curation reward which can be given to the voters is

curation_reward = pending_token - author_reward

For each vote, a weight is calculated. When curation_curve_exponent = 1, the weight is linear the vote rshares.

y = token_config[token]["curation_curve_exponent"]
vote_weight = (int_pow(sum_rshares + vote['rshares'], y) - int_pow(sum_rshares, y))
sum_rshares += vote["rshares"]

The vote_weight of all voters is summed up in total_vote_weight.
The curation reward is then

pending_curation_token  = int(curation_reward * vote_weight / total_vote_weight)

Example

curation_curve_exponent = 0.5, curation_reward = 1 , one vote with 100 rshares and a later vote with 1000 rshares.

sum_rshares = 0
vote_weight_1 = sqrt(100) = 10
sum_rshares = 100
vote_weight_2 = sqrt(100 + 1000) - sqrt(100) = 23.166
total_vote_weight = 33.166

The first voter receives:

1 * 10 / 33.166 = 0.302

and the second voter receives:

1 * 23.166 / 33.166 = 0.698

vote_regeneration_seconds and vote_power_consumption

These two parameter defines how often it is possible to vote. These parameters are integer in the steem percentage notation 100 means 1 %.

vote_power_consumption defines how the vote power is reduced with a 100% vote. When it is set to 200 (2%), the vote power is reduced to 98% when voting at full vote power and a weight of 100%.

vote_regeneration_seconds defines in which time duration an empty vote power is regenerating to 100%.

downvote_regeneration_seconds and downvote_power_consumption

These two parameter defines how often it is possible to downvote. When downvote_regeneration_seconds is set to a positve integer, a second downvote pool is activated.

When a downvote pool is active, downvoting does not reduce the vote power.

downvote_power_consumption defines how the downvote power is reduced with a 100% downvote. When it is set to 200 (2%), the downvote power is reduced to 98% when downvoting at a full downvote power and a weight of 100%.

downvote_regeneration_seconds defines in which time duration an empty downvote power is regenerating to 100%. When this parameter is negative, the downvote pool is deactivated and downvoting will reduce the vote power.