SLP token migration strategies upon introduction of a miner validated token schemes

[freetrader]

As discussion about future token schemes grows, I’d like us to consider what the options are in terms of migration for users of SLP.

Since SLP is permissionless and not part of the consensus rules by design, the introduction of a new miner-validated token scheme does not imply the end of life of SLP.

Some of the tradeoffs made by SLP will drive adoption of new token schemes.
At least two such schemes are already in discussion [1, 2], and there is also the third option of adding SLP validation to consensus rules (which would probably not require migration since invalid SLP transactions would simply not be accepted by BCH nodes).

But for the other schemes, let’s consider what we can offer to issuers generally in terms of migration from SLP to a new scheme.

There is no reason at this time why BCH would need to remove any functionality relied upon by SLPv1. Those who wish to maintain their own SLPv1 token infrastructure ought not be impeded at all.

A token issuer could run some tokens on the old (SLPv1) scheme, and run only newer tokens on a non-SLP scheme, and abstract that difference away in their own application. In order to incentivize their users to switch over, such sites could offer to redeem the old tokens for new ones, burning the old SLP tokens which are redeemed.

Alternatively, issuers could announce to their users that they are migrating their existing tokens to a new scheme via airdropping “replacement” tokens to their holders as part of a coordinated switchover with services supporting that token. I believe this could be problematic for heavily traded tokens where it is difficult to get everyone to halt trading, then airdrop and resume on the new scheme. Failing that would result in double spends of the token.

What other migration strategies can we suggest?

[1] Group Tokenization (Google doc)
[2] CashToken

[bitjson]

For tokens which need to support contract-based validation (e.g. allowing them to be traded using decentralized exchange covenants), one trustless option might be:

Trustless Snapshot Migrations

The community around a token settles on a date to migrate the token. At migration time/block height, a snapshot of all token holders and balances is taken, and future transactions are no longer considered valid. The snapshot is embedded as a merkle tree in a covenant like this contract. The covenant is easy to verify, and many industry actors can validate that the correct merkle tree has been included.

After someone funds the covenant with dust, any token holder can withdraw their “upgraded” tokens from the covenant by proving they hold an output from the merkle tree (and zeroing out that leaf + paying the TX fee). One recommendation for implementors: it might be wise to allow proof by either 1) showing the token holder can move a particular UTXO from the snapshot, or 2) if the output is P2PKH, the token holder can simply sign using the correct key. The proof for (2) may make upgrading easier for wallets which don’t have good support for UTXO selection/management.

It would also be wise to specify a migration time window: e.g. all migrations must be completed within one year. (The specifics can be decided by each token community, but 1 year seems like a good default.) After the year ends, the “snaphot migration” covenant can prune itself, snipping off the migration code path to reduce top-level covenant transaction sizes.

For migrations like this, all token holders are advised to either 1) hold their tokens themselves in a supporting wallet (recommended), or 2) hold the tokens on some exchange which has committed to supporting the migration.

And to clarify, this strategy is mostly intended for trustless tokens. For tokens issued by a central entity, the process can be much simpler – both token types can circulate simultaneously, and “SLPv1” can even continue to be supported indefinitely. “Upgraded tokens” would only be necessary for decentralized exchanges and covenant use cases (or if infrastructure providers wanted to stop supporting the older SLP infrastructure).

[bitcoincashautist]

@freetrader

SLP validation to consensus rules (which would probably not require migration since invalid SLP transactions would simply not be accepted by BCH nodes)

Right now there’s no restriction on the content of OP_RETURN and whomever used it for purposes other than SLP could suffer from this, right?

Re. transition, just to add a perspective: SLP right now competes with token solutions on other blockchains. I imagine those using SLP now are using it because of their love for BCH, and not because there aren’t better solutions out there. Maybe there will be no need to nudge them into anything, just giving them a competing solution on BCH should be enough of incentive to think about migration. How did USDT move from Omni to Ethereum? BNB from Ethereum to Binance Chain? With miner validated tokens, the move will be from Bitcoin Cash to Bitcoin Cash, and hopefully we’ll see moves from blockchain X to Bitcoin Cash because it will be the better solution, and in the process find love for BCH

[freetrader]

Right now there’s no restriction on the content of OP_RETURN and whomever used it for purposes other than SLP could suffer from this, right?

I would envisage this being restricted to SLP transactions with certain prefixes, e.g. the Lokad ID’s described in slp-specifications/slp-token-type-1.md at master · simpleledger/slp-specifications · GitHub .

So I don’t really see how other OP_RETURN messages would necessarily suffer in any way.

I imagine those using SLP now are using it because of their love for BCH, and not because there aren’t better solutions out there.

Various token schemes have their own strengths and weaknesses, and I would not presume people generally to just use SLP because of emotional reasons.

Various stronger reasons are laid out in the SLP spec, but to those listed there (permissionlessness, simplicity, etc) I would add “affordable”. We have precisely seen issuers of tokens like USDt hope from one system to the next when fees on their current platforms became excessive for token operation. SLP tokens remain very affordable to operate because on BCH. Is that a reason to love them? I would say yes.

[bitjson]

Since SLP tokens are specified in a separate OP_RETURN output and can be applied to any output, it’s possible to use both systems in the same transaction. (Thanks to @joshmg for raising this point in a private chat.)

Writing here to think it through:

Dual-Validated Tokens

Existing SLP tokens can be gradually converted to any contract-validated/native token scheme by using both schemes in every token transaction. Supporting wallets can start sending SLP outputs to the new token scheme, and existing SLP infrastructure can be slowly upgraded to support both.

We could roll out an SLP v1.1 as a sort of “SLP soft fork” – if the SLP transaction somehow commits to being v1.1, it must 1) conform with the existing SLP standard, and 2) lock tokens properly in a contract-validated or native token system.

This would allow existing SLP infrastructure to be able to compute balances and validate network activity properly. It may also make upgrading wallets slightly easier – wallets would still need to be able to construct the new locking/unlocking bytecode to receive/send any “upgraded tokens”, but they can otherwise continue to use their existing SLP code/APIs/infrastructure for v1 tokens.

Of course, token upgrading is one-way, since upgraded tokens must use the correct locking bytecode for whichever token scheme they use. (And a transaction to “send tokens back” to a non-token output will be rejected by the network.) Eventually, almost all tokens would be “dual-validated”, and we could sunset the SLP OP_RETURNs.

URI scheme: we’d probably want to increment the Address Type bit for simpleledger: addresses. All existing SLP wallets and infrastructure can continue operating normally, and over time, chunks of the ecosystem would move to this SLPv1.1, adding support for the upgraded Address Type. (Related: discussion with @im_uname, @Licho, and @tom about moving to a bch: prefix – we could also do that.)

I’m still wrestling with whether this would be worth the effort, but it at least offers one solution for existing ecosystems to continue using SLP while chunks of the community upgrade over time.