SECTION I: BACKGROUND
Introduction
Philosophy
Use Cases
MINT Vault vs. MINT Baton
MINT Vault Advantages
Why Not Multiple Mint Batons?
Multiple MINT Outputs
SECTION II: TYPE 2 PROTOCOL DESCRIPTION
Protocol Overview
Reserved Token Types
Transaction Detail
GENESIS - Token Genesis Transaction
MINT - Extended Minting Transaction
SEND - Spend Transaction
COMMIT - Checksum Commitment Transaction
SImple Ledger Token Type 1 has proven to be a versatile and powerful token protocol that, for the most part, is able to leverage the benefits of Bitcoin’s UTXO (“coin”) transaction model. Type 1 is able to accommodate the needs of many simple applications that require tokens. In the 5 years since the Token Type 1 specification was first published, more advanced SLP Token use cases have emerged. In some of those use cases, the limitations of the Type 1 specification create serious bottlenecks, preventing even modest scaling. We propose a new version of the Simple Ledger Token, Type 2, that removes the most immediate limitations of Type 1.
The stated design philosophy of SLP Token Type 1 was focused around simplicity and consensus. The SLP Token Type 2 specification seeks to adhere to the same design philosophy and, as a result, has altered the Type 1 specification as little as possible to fully address issues with the Type 1 specification that are being experienced, at the present time, by applications in production and deployed on mainnet networks.
The introduction of the OP_CHECKDATASIG opcode in the November 2018 Bitcoin Cash network upgrade introduced the capability, through covenants, for advanced applications using Bitcoin script. The SLP Token Type 1 specification was published in August 2018, months before the upgrade that included OP_CHECKDATASIG. Novel Script contracts specifically designed for SLP tokens have been deployed on the Bitcoin Cash and eCash networks. In the case of advanced contracts such as MIST mineable SLP tokens and the Self Mint Protocol, the MINT transaction type is the core component. It is the MINT transaction design in SLP Token Type 1 that limits the scaling of these advanced Script contracts. This document, the SLP Token Type 2 specification, removes the scaling limitations of Type 1 MINT transactions.
SLP Token Type 1 uses the “MINT Baton” concept as the means for generating new coins after the GENESIS transaction has already been added to the blockchain. According to the Type 1 specification, there can only ever be a single UTXO that is considered to be the MINT Baton for a given token. The MINT Baton, if used as an input in a MINT transaction, allows that transaction to generate new coins and a new MINT Baton output that can be used to generate more coins in the future.
The MINT Baton model necessarily places a rate limit on MINT transactions. In order to perform a MINT, a wallet must first query the UTXO set for the current location (transaction hash and output index) of the MINT Baton for a given token. It must then create a valid MINT transaction and broadcast the transaction to the network. If two or more wallets are simultaneously attempting to MINT new tokens, using the same MINT Baton UTXO as an input, only the transaction that is first seen by the network will be considered valid. Any other transactions attempting to spend the now-spent MINT Baton UTXO will be rejected by the network. It is easy to see how this race condition limits advanced Script contracts, focused on MINT transactions, to hobby-level scale.
SLP Token Type 2 replaces the MINT Baton model with the “MINT Vault” concept. Instead of only one UTXO being able to be used to generate new coins in a MINT transaction, any UTXO held in the MINT Vault address can be used. So long as at least one input in an otherwise valid MINT transaction originates from the P2SH address specified in that token’s GENESIS transaction, the MINT transaction is considered valid according to this specification.
The move from a MINT Baton model to a MINT Vault model not only removes pressing limitations, it also offers some advantages for future use cases. Some immediate examples:
-
Tokens of Type 1 can be more easily migrated/upgraded to Type 2 (potentially even programmatically via Script) by burning the Type 1 token to a UTXO located in the MINT Vault and using that UTXO to then MINT new Type 2 tokens of the corresponding value.
-
Multiple different tokens can share the same MINT Vault. Any UTXO in the vault can be used as a MINT input for any of the tokens sharing the vault. A given UTXO is not limited to use with a single token
-
The GENESIS transaction itself can be used as PUSH data in the unlock script of a MINT Vault input to validate both the input itself and the SLP OP_RETURN output of a MINT transaction
The use of multiple MINT Batons was a possible choice for addressing the limitations of the single MINT Baton in the SLP Token Type 1 specification. While this choice would mitigate the previously described race condition, at scale this option is still significantly more complex than the MINT Vault solution because assignment of baton privileges to a given UTXO must, necessarily, still be done via an SLP-specific transaction, and all MINT Batons must be separately indexed. These additional steps and the associated resource usage is eliminated by using the MINT Vault model.
SLP Token Type 1 only allows a single output where new tokens are created in a MINT transaction. This means that if an application requires the minting of new tokens and immediate distribution to multiple outputs, that application must first do a MINT transaction and then an immediate SEND transaction in order to accomplish the task. Additionally, the restriction to a single MINT output prevents valuable use cases such as “fee outputs” where the administrator of a token can take a non-custodial payment as a fee on every MINT.
SLP Token Type 2 allows multiple outputs on a MINT transaction using the same model as is already used in SLP SEND transactions.
SLP Token Type 2 primarily makes substantive changes to the GENESIS and MINT transaction type specifications. The SEND and COMMIT transaction type specifications are unchanged except that the token_type field’s value is now 2. For simplicity, and because there is no change beyond the changing of the token_type field value, full specifications for SEND and COMMIT transaction types are not included in this document.
Tokens of different types cannot be mixed. In order to be valid, all transactions of a token of Type 2 must use 2 as the value in their token_type field.
The SLP Token Type 1 specification reserves token_type 2, used for this specification, for security tokens. In the 5 years between the Type 1 specification and this specification, there has been no security token specification published. Furthermore, security tokens have been shown to be possible using SLP Token Type 1. For these reasons the reservation is not being observed.
The SLP Token Type 2 GENESIS transaction is similar to the GENESIS format for Type 1, with the following changes.
token_type: the value of this field is 2
mint_vault_scripthash: this field replaces mint_baton_vout from Type 1. The value is the 20-byte hash portion of the pay-to-script-hash (P2SH) address that will serve as the MINT Vault. Note: Unlike in Type 1, the value of this field cannot be 0. If the GENESIS transaction is “dead-ended” (no further MINT’s possible), then the specification is identical to Type 1 and, thus, Type 1 should be used instead.
Transaction inputs: Any number of inputs or content of inputs, in any order.
Transaction outputs:
| vout | ScriptPubKey ("Address") | BCH amount |
Implied token amount (base units) |
| 0 |
OP_RETURN <lokad_id: 'SLP\x00'> (4 bytes, ascii)1 <token_type: 2> (1 byte integer) <transaction_type: 'GENESIS'> (7 bytes, ascii) <token_ticker> (0 to ∞ bytes, suggested utf-8) <token_name> (0 to ∞ bytes, suggested utf-8) <token_document_url> (0 to ∞ bytes, suggested ascii) <token_document_hash> (0 bytes or 32 bytes) <decimals> (1 byte in range 0x00-0x09) <mint_vault_scripthash> (20 bytes) <initial_token_mint_quantity> (8 byte integer) |
any2 | 0 |
| 1 | Initial mint receiver | any2 | initial_token_mint_quantity |
| ... | Any | any2 | 0 |
1. The Lokad identifier is registered as the number 0x504c53 (which, when encoded in the 4-byte little-endian format expected for Lokad IDs, gives the ascii string 'SLP\x00'). Inquiries and additional information about the Lokad system of OP_RETURN protocol identifiers can be found at https://github.com/Lokad/Terab maintained by Joannes Vermorel.
2. SLP does not impose any restrictions on BCH output amounts. Typically however the OP_RETURN output would have 0 BCH (as any BCH sent would be burned), and outputs receiving tokens / mint batons would be sent only the minimal 'dust' amount of 0.00000546 BCH.
The SLP Token Type 2 MINT transaction is similar to the MINT format for Type 1, with the following changes.
token_type: the value of this field is 2
additional_token_quantity (multiple): these fields replace the mint_baton_vout and additional_token_quantity fields from Type 1. The implementation of these fields is exactly the same as the token_output_quantity fields in the SEND transaction type.
Transaction inputs: Any number of inputs or content of inputs, in any order, but with required presence of at least one input originating from the P2SH address identified by the mint_vault_scripthash in the GENESIS transaction.
Transaction outputs:
| vout | ScriptPubKey ("Address") | BCH amount |
Implied token amount (base units) |
| 0 | OP_RETURN <lokad_id: 'SLP\x00'> (4 bytes, ascii) <token_type: 2> (1 byte integer) <transaction_type: 'MINT'> (4 bytes, ascii) <token_id> (32 bytes) <additional_token_quantity1> (required, 8 byte integer) <additional_token_quantity2> (optional, 8 byte integer) ... <additional_token_quantity19> (optional, 8 byte integer) |
any | 0 |
| 1 | Receiver 1 | any | additional_token_quantity1 |
| ... | ... | any | ... |
| N | Receiver N (N = number of additional_token_quantities provided) |
any | additional_token_quantityN |
| ... | Any | any | 0 |
The SLP Token Type 2 SEND transaction is exactly the same as the SEND format for Type 1, with the following change.
token_type: the value of this field is 2
Transaction inputs: Any number of inputs or content of inputs, in any order, but must include sufficient tokens coming from valid token transactions of matching token_id, token_type (see Consensus Rules).
The SLP Token Type 2 COMMIT transaction is exactly the same as the COMMIT format for Type 1, with the following change.
token_type: the value of this field is 2
The SLP Token Type 2 BURN transaction is exactly the same as the BURN format for Type 1, with the following change.
token_type: the value of this field is 2
This protocol specification is published under the terms of the MIT license.