Open jcramer opened 4 years ago
Would the proposed convenant script enforce token transfer as well? If not, it's possible to burn the token at transferring; while that's an edge case which nobody is incentivized to perform, it should probably be addressed explicitly, even if the convenant does enforce token transfer.
On the other hand a convenant that does not enforce token transfer can be generalized for "staking" BCH as well, which can be useful for governance among other things.
Should we specify that reward trail can only be issued by the token issuer, from the token-issuing address/pubkey?
I read both documents. Great work!
It would have been better to submit each document as its own PR, since they cover very different use cases. Food for thought on future PRs.
I love the Rewards spec. It makes a lot of sense and is easy to implement. The only concern I have is that the scope is too narrow. This method of dropping metadata onto the blockchain about other transactions could be applied to a wide range of use cases beyond air-drop rewards. I think it's worthy of a more general specification. I'd love for us to explore the intersection of the rewards specification and this media sharing specification.
I'm not sure how I feel about the Staking specification. This is one way to do it, and if a covenant can produce a formal process that can protect users from burning tokens, then it's worth exploring. But it seems way too complex to me.
In contrast, the Permissionless Software Foundation is going to implement a simple staking system based on UTXO age. This does not require any extra code, as people simply need to not move their tokens for a specified period of time. This does not protect against user error however. But it is extremely simple, and there is value in simplicity.
These two documents provide standardized recommendations for two common use cases. These standards will allow SLP users and block explorers to communicate more efficiently and provide an optimized user experience.
Proposed standards include:
Rewards: This is a very basic application protocol that can be followed to allow tracking of user rewards. It isn't complicated and would add immense value to the ecosystem. Wallet integration with an airdrop tool would be ideal, but it's optional as the protocol could be followed by manually entering details into NFT1 Group/Child GENESIS transactions with existing wallet tools.
Staking: This is a more complicated application protocol that would take a bit of time to implement and would require complex wallet integration.