Hello everyone ! Today I want to write a bit of explanation on one of the core smt operations:
This operation is used, as it's name hints, to setup emission/inflation for an smt. In order to use it you must have previously called the smt_create operation to create an smt object in the chain to send this operation on.
Now let's look at the operation and it's parameters :
account_name_type control_account;
asset_symbol_type symbol;
time_point_sec schedule_time;
smt_emissions_unit emissions_unit;
uint32_t interval_seconds = 0;
uint32_t interval_count = 0;
time_point_sec lep_time;
time_point_sec rep_time;
share_type lep_abs_amount;
share_type rep_abs_amount;
uint32_t lep_rel_amount_numerator = 0;
uint32_t rep_rel_amount_numerator = 0;
uint8_t rel_amount_denom_bits = 0;
bool remove = false;
bool floor_emissions = false;
extensions_type extensions;
You can find this in : https://github.com/steemit/steem/blob/master/libraries/protocol/include/steem/protocol/smt_operations.hpp
the basics
So first of all, you need to give the operation the information about which smt you want to add emission to :
(note that the code examples will be in js from now on)
this is where you set
control_account
with, for example : "howo"symbol
it's anasset_symbol_typewhich is a struct with a nai and a precision, so it would be akin to something like
{'nai': @@280090049, 'precision': 13}
- schedule_time
This is where you state when the emission starts, there is no end date for the emissions unless you set it in another emission call (we'll get to that later on)
Emission units
This is where we start to dive into the interesting parts, emission units define where the inflation actually goes, the structure looks like this :
[
['howo', 50],
['steempress', 50],
]
And that's it ! Here I state that every time there is an emission, 50 tokens will go to me and 50 will go to steempress, you can put steem accounts and there are also three special strings that you can use :
$market_maker : inflation will go to the decentralized market in order to provide liquidity early on
$rewards: Fund the reward pool for your smt, if you don't set this, your token won't have proof of brain rewards via inflation (you could fund that account via other means like the ico)
$vesting: Fund the vesting rewards
Since the parameter is an array you can set several inflation destination at the same time.
Interval_second and interval_count
Okay so we emit x tokens to those emission sources, but how how often ?
interval_seconds sets how often emissions will be triggered, note that the minimum is 21600, aka 6 hours.
interval_count sets a limit on how many times you want to emit.
if you set it to 10 you will only emit 10 times. It's a good way to set a limit to your inflation, or to get all the tokens at once in everyone's hands.
Variable emissions, because otherwise it would be too easy
This is where things get tricky, and I am not 100% sure myself but here's the gist of it, you can refer to the official smt documentation as well if I'm not making enough sense : https://github.com/steemit/smt-whitepaper/blob/master/smt-manual/manual.md#adding-time-modulation
you can set curves for your inflation, in order to have, let's say a decreasing inflation.
for that you have lep_time and rep_time to set both ends of the curve, lep stands for left end point, rep right end.
values are like this : 1970-01-01T00:00:00
Side note :
- For times before the left endpoint time, the amount at the left endpoint time is used.
- For times after the right endpoint time, the amount at the right endpoint time is used.
Then you have 4 parameters :
lep_abs_amount and rep_abs_amount which are the values taken at lep and rep from which we'll get a curve (100 and 0 for instance to make inflation go to 0 over time).
Abs use integer values aka 10, 20, 30
lep_rel_amount_numerator and rep_rel_amount_numeratorwhich are the same except that they use a different calculation to take advantage of decimals. Hence why they also have the rel_amount_denom_bitsto bitwise righ shift the value by the number defined.
So do we need to have both defined and what happens if we only want to set the abs and leave the rel alone ? This is where the floor_emissions parameter comes in handly. this is basically what it does :
if ( emission.floor_emissions )
new_token_supply = std::min( abs_amount, rel_amount );
else
new_token_supply = std::max( abs_amount, rel_amount );
If floor emission is set to true, it will take the minimum value between the calculated absolute value and the calculated relative value otherwise it will take the biggest of the two. So if you want to use only abs emission, set lep_rel_amount_numerator and rep_rel_amount_numerator to 0 and floor_emissions to false.
Adding multiple emissions
phew almost done ! Now here's an interesting thing about emissions, you don't have to have a single emission model, you can have several ones ! So you can reward early adopters with a high reward pool inflation and then switch to a model where it's more normal but inflation to vesting is now favored.
You can have as many inflation as you want but they need to be 6 hours apart from each others.
Deleting an emission
Finally there is one last parameter : delete if set to true, it will delete the emission model that you previously submitted. Quite useful if you found out that there is a parameter that isn't right huh ?
conclusion
You can find a complete example for this on my hard fork 23 tests here : https://github.com/drov0/hf23-testing/blob/master/bulk_full_setup.js
The reason I'm able to do this work and allocate time to it is thanks to the funds from the sps, please consider voting on it or unvoting the return proposal : https://steemproposals.com/proposal/50 every bit counts !
And finally I am also doing this as part of the witness @steempress if you like what I'm doing please consider voting on it as well. Every bit counts ! It will take you but a few minutes but will greatly help me test the network and the more we test the more steemit and the witnesses will feel confident enough to launch on the main net
Thanks for doing all this.
Are you going to compile all the documentation you're creating in some more formal way? Like @intertia's documentation website?
Mmmh I was thinking of actually putting it on the devportal (aka inertia's website, although it's a steemit funded initiative at first), but most of the data is already formatted here : https://github.com/steemit/smt-whitepaper/blob/master/smt-manual/manual.md#adding-time-modulation
And for now my time is better spent actually testing than documenting, as writing stuff like this takes quite some time.
Great work @howo looks impressive explanation. I am non technical and followed your commentary pretty well.
Posted using Partiko iOS
Thanks ! Glad to hear that you could follow, it was mostly aimed at technical people so it's a great sign :)
Congratulations @howo!
Your post was mentioned in the Steem Hit Parade in the following category:
Congratulations @howo! You have completed the following achievement on the Steem blockchain and have been rewarded with new badge(s) :
You can view your badges on your Steem Board and compare to others on the Steem Ranking
If you no longer want to receive notifications, reply to this comment with the word
STOPVote for @Steemitboard as a witness to get one more award and increased upvotes!
Thanks for the post.
Great work, I am sure community developers will find these tests and infos useful
Amazing piece of work @howo
I'm far from capable to understand all technicalities, however I can roughly see how useful this content can be for many.
Upvote on the way. And will vote on your sps proposal in a minute.
Would you mind telling me if blockchain is your passion or is your work somehow related to this topic as well? Just curious :)
Yours, Piotr