v2 wishlist

[paOol]

Dividends

Allow for all holders of a token to receive future rewards / dividends / airdrops.
And/or a method for sending to all holders of said token.

Grouping / Unique assets

somewhat NFT-related. Be able to create ITEM token, and an additional token can be attached/grouped accordingly. for example ITEM.sword , ITEM.shield, etc.
anyone who looks up sword/shield would see they're a part of ITEM. and ITEM.sword.asdf might be the only sword of that type in existence.

Messaging

Some form of protocol or compatibility with an existing broadcast system. The token would have a 'feed' or a channel to send messages/news updates transmitted based on the token_id. Every on chain transaction can be a hash of the actual message/update for time-stamping and censorship-resistance.

Voting

built in voting protocol for anyone who creates a token to easily use w/o any programming knowledge required.

Update-able Metadata

native support for updating website, email, etc.
TICKER and maybe name should be static.

Licensing

A spec/protocol to follow so services can query an address to quickly verify the authenticity of a token representing a license. Some licenses might expire after 1 year, some may be considered invalid if they are moved more than once, etc.

Private assets

An issuer broadcasts that NEW token can only be held by person A,B,C and D. Their identities are encrypted (or maybe CDS is used) but only the issuer knows who A,B,C,D are.

Freeze / Unfreeze

ability to 'banlist' or freeze certain bad actors' addresses.

[christroutner]

Addition to Freeze

An additional use case for Freeze functionality would be memento tokens. Think of buying a t-shirt at a concert to prove you were there. That kind of use case. Proof that someone acknowledge you by sending you a token, but which should have no monetary value and should not be transferable.

The token should

• show up in the wallet
• not be transferable

[markblundeberg]

Fraud proofs

If SLP included a mandatory field that said which inputs were to be used for tokens, and there was a rule that all such declared inputs must be valid, then it would make it much simpler to have proofs of invalid SLP transactions.

[markblundeberg]

Multi-sends

It could be nice to add support for sending multiple token types in one transaction. This was considered during SLPv1 design but dropped due to the technical complications.

• If one token type input is invalid, is the entire SLP invalid? This makes SLP transaction validity relationship DAG overlap between different token types! Alternative: SLP has distinct validity judgement for each token type, for no overlap.
• More token types need to be declared, increasing the OP_RETURN message size. Unlikely that more than 4 tokens could be practically sent at once.
• This would allow fast token-token atomic swaps in one transaction; currently token-token swaps would require using the slow four-transaction HLTC atomic swap method (as if done between chains).

[jcramer]

Updating token document URI/Hash

At least 2 users have requested the ability to update the token document's URI and hash details. Here is a link to our previous discussions on how this could be accomplished in PR #11

[imaginaryusername]

Tree NFT

Continuation of the NFT extension type 1 here https://github.com/simpleledger/slp-specifications/blob/master/NFT.md, allow a "Type 3" where the descendant "NFT" are also their own groups of "fungible tokens" that can generate descendants. An example will be an origin "items" groups of tokens that can be burned to generate "sword", "bow", "hammer"... tokens, which can then themselves generate NFTs, and so on, e.g. item.sword.flame.fiery_sword_of_doom

While it's relatively easy to extend existing protocol in a strictly hierarchical way (item tokens can genesis sword tokens exactly once), a desirable feature might include making descendants that can increase in supplies by burning more parent tokens. It's unclear exactly how to do that right now and may require some exploration.

[tulasacra]

Dividends for BCH holders
Allow for all BCH holders to receive future rewards / dividends / airdrops of a certain token.
And/or a method for sending to all BCH holders this token.
Declaratively, without the need to actually send a transaction to everyone. For instance we could have a token BCH_clone_at_X which in its genesis transaction has a script that says a minting transaction is valid, if it mints Y amount to an address which held Y BCH at block X. Then anyone could broadcast such a valid minting transaction. Ideally the minting scripting language is the same as the BCH script.

[christroutner]

I'm unclear on the scope of this issue:

• Are we discussing a second version of the SLP protocol?

or

• Are we discussing Token Type 2 withing the scope of the current SLP protocol

How do we prevent this Issue from growing forever? How do we reach resolution and close it?

[jcramer]

Each version/type of token is essentially a different token protocol. For example, NFT1 is not token type 1 because it has more rules than Token Type 1.

Version 2 would be a total rewrite of a token protocol. If the new token type is a minor ruleset extension, like NFT1, then the spec writing can be handled like NFT1 was.

[markblundeberg]

It's worth emphasizing though, it's not a complete rewrite as future SLP2 transactions are supposed to be detected by existing SLP wallets, which should flag all those transaction outputs as 'possibly tokens' and hence not spend them. So, it should be safe to send SLP2 tokens to any simpleledger: address with the knowledge that the recipient won't accidentally burn them, and hence, we don't need yet another simpleledger2: format and new derviations paths, etc. etc....

It would be a good idea to make sure all the wallet devs are aware of this, and specify carefully the rules that future SLP versions will absolutely follow, so that they know which transactions need to be flagged as do-not-spend.

For example one question I am wondering is whether SLP2 will still require the OP_RETURN to be on position 0. After all, the most elegant way to do multitoken is if standardness rules allow multiple OP_RETURNs, and each one can deal independently with a different token type. But that would mean that even if a transaction is valid SLP1, then it still might need to be flagged as do-not-spend because another output had an SLP2 OP_RETURN on it.

[jcramer]

Good clarification, the new v2 spec would have to keep SLP lokad id and version fields for general compatibility.

To your second point, it would be valuable to come up with a test plan for checking all of the existing wallet implementations to see how they handle SLPX type transactions.

Based on the current implementations we have it seems like SLP1 would never be able to safely support multi-token sends and this could only be supported with a new token specification. So, in this case, wouldn't the safest path forward to have the new token version's metadata starting on vout=0, since all existing wallets look there first and don't look anywhere else.

The new token version could have the possibility of having additional metadata on vout > 0, but keeping in mind none of the additional metadata could be a SLP1. It's definitely a good thing to bring up, and now I will be keeping in mind moving forward.

[christroutner]

wouldn't the safest path forward to have the new token version's metadata starting on vout=0, since all existing wallets look there first and don't look anywhere else.

Seems like the best path forward to me.

Food for thought:

I'm a huge fan of the memo.cash protocol. It's a damn shame it doesn't comply with the Lokad spec, but putting that aside, the structure of the protocol is extremely expressive. I think that structure could provide inspiration for incorporating some of the ideas on this wish list, and essentially passing commands to SLPDB or other token validation software.

https://memo.cash/protocol

[markblundeberg]

Based on the current implementations we have it seems like SLP1 would never be able to safely support multi-token sends and this could only be supported with a new token specification. So, in this case, wouldn't the safest path forward to have the new token version's metadata starting on vout=0, since all existing wallets look there first and don't look anywhere else.

Could be, but we can easily amend SLP design requirements for wallets that they need to scan all outputs. (This isn't a change to SLPv1 spec, which would still require its message to live on output 0) Given how far away SLP2 is from existing, if we did this now then it would give ample time for wallets to conform to this requirement.

Note that if SLP2 doesn't require its OP_RETURN to live on vout 0, then SLP1 indeed could participate in a multitoken send with an SLP2 token, just not with other SLP1 tokens. Also you could do SLP2-SLP2 multitoken transaction, SLP2-SLP3, or SLP2-wormhole multitoken, or whatever.

[jcramer]

Could be, but we can easily amend SLP design requirements for wallets that they need to scan all outputs. (This isn't a change to SLPv1 spec, which would still require its message to live on output 0) Given how far away SLP2 is from existing if we did this now then it would give ample time for wallets to conform to this requirement.

I was going to write a rebuttal type response, but then I realized that there is no way to enforce a wallet to respect multi-send on a consensus level regardless of the specification rules. Yes, I agree. we should add this v1 wallet implementation requirement to respect multiple OP_RETURNs.