smt-whitepaper
smt-whitepaper copied to clipboard
Post-launch redirection of emissions
So the idea I'm going to discuss in this ticket is this: We may in the future want to implement new emissions destinations for SMT's. How can SMT's which launched before a new destination became available take advantage of the new destination? According to the present spec, it is not possible.
The idea here is twofold:
- Have an object representing an emission destination.
- Allow the object's contents to be replaced, provided that affected user accounts consent to the replacement and the total emission is not increased.
- Replacements are deferred and cancellable, so a compromised and (timely) recovered control account can cancel any changes before they take effect.
So for example, if a token emits 70% to rewards pool and 30% to a founder Alice's account, Alice can sign a transaction to adjust the emission to go 70% to the rewards pool, 20% to a newly implemented destination, and 10% to Alice.
I would have thought it would be better to just have the community fork its SMT to a new one ¯_(ツ)_/¯ as we wouldn’t need to make this a requirement. But if it’s simple to develop, then this is OK
Sent from my iPhone. Please excuse any grammatical mistakes or errors.
On Mar 2, 2018, at 6:28 AM, theoreticalbts [email protected] wrote:
So the idea I'm going to discuss in this ticket is this: We may in the future want to implement new emissions destinations for SMT's. How can SMT's which launched before a new destination became available take advantage of the new destination? According to the present spec, it is not possible.
The idea here is twofold:
Have an object representing an emission destination. Allow the object's contents to be replaced, provided that affected user accounts consent to the replacement and the total emission is not increased. Replacements are deferred and cancellable, so a compromised and (timely) recovered control account can cancel any changes before they take effect. So for example, if a token emits 70% to rewards pool and 30% to a founder Alice's account, Alice can sign a transaction to adjust the emission to go 70% to the rewards pool, 20% to a newly implemented destination, and 10% to Alice.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.
This is interesting thought. I am wondering whether SMT_Power stakeholders can decide hardfork through vote. For instance, users vote for a spacial Oracle account that contains SMT parameters, such as inflation rate and reward distribution curve.
As far as I understand, this destination object can be included as a parameter in an atomic transaction on the blockchain. Shouldn't this be part of the consensus? Shape shifting destinations without consensus can adversely affect trust.
Also, remotely related to this ticket: is there really a consensus in an SMT ecosystem? Since blocks are produced by Steem witnesses, what are the prerogative of a consensus layer in an SMT ecosystem?
Related question: Should vested SMT affect user's power in witness voting?
@Kiwonik No, vested SMT won't have any effect on witness voting power.