Operations
LRC20 exposes the essential functionalities of a token protocol that enable a seamless and flexible experience across the breadth of use-cases.
Unlike L1 Bitcoin transactions, where UTXOs (Unspent Transaction Outputs) represent BTC tokens and are bound by spending conditions defined in a ‘Script’, Spark Token Transactions use LTTXOs (Token Transaction Output), where each Leaf represents a single broadcastable transaction on Bitcoin L1. In this way, you could think of a Spark Token Transaction as a ‘Meta-Transaction’.
Mint
The initial operation to create funds on spark is a ‘Mint Transaction’. For this operation, an Issuer creates a Spark Token Transaction and signs it using their Issuer Private Key. They then Broadcast this transaction to a Spark Operator group (AKA Spark Entity), which validates the legitimacy of the signatures, signs the transaction, and publishes the transaction to the LRC-20 Node Gossip Network (more on this below).
A real-world analogy to a Mint on Spark is a ‘Cashier’s Check’. A bank sets aside funds and issues a signed check that can be cashed at any time risk-free. Similarly, a Spark Issuer signs and issues a pre-signed transaction input, which can be redeemed on Bitcoin L1 at any time without risk that these funds will not be available at the time of exit.
Transfer
After issuance, these newly created partially signed transactions can now be split up, joined, and sent to other users in a way similar to how L1 Bitcoin outputs are spent.
Just like on Bitcoin, a Spark Token Transaction can have one or more inputs and one or more outputs. The fundamental requirement, of course, is that the aggregated value of tokens in the inputs matches the value of tokens in the outputs.
Unilteral Exit
When a receiver wants to withdraw their funds to L1 they must create a Bitcoin transaction with leaves they want to withdraw in outputs and L1 UTXO they own in inputs with minimum withdrawalBond satoshis (to cover the fees and minimal output amount for leaves). Transaction metadata should contain Spark’s transaction hashes and the output number of leaves from outputs. All output addresses must be P2TR with following conditions:
- Can be spent instantly either by using revocation key (as key-spend path) or
- With receiver signature after timelockForSpendingOfWithdrawedFunds timelock (as script-spend path).
What prevents a Wallet from Broadcasting a Transaction with a Different Revocation Commitment, Script, or Bond?
This is a valid concern. Any LTTXO Owner could broadcast an L1 transaction with unexpected parameters that the Bitcoin Network would consider valid and include in a block.
However, this is where the LRC20 Node network comes into play. While this document doesn’t go deep into the LRC20 network, LRC20 nodes are essential for providing final confirmation of the current state of token holdings on both the Spark Network and on Bitcoin L1.
If a modified / unexpected transaction were to be broadcast (with different withdrawal bond, revocation public key, script, etc), it would still be confirmed on-chain but the LRC20 nodes would recognize that the transaction does not meet the required criteria and would mark this transaction as ‘invalid’ and not consider the funds moved.
Any LRC20-enabled L1 wallet can communicate with a trusted LRC20 node in order to distinguish valid LRC20 exit transactions from invalid transactions.
Freeze
Issuers uniquely have the ability to freeze and unfreeze leaves in response to requests from regulatory bodies. In order to issue this request, the Issuer wallet signs a payload containing the owner’s public key it wishes to freeze and communicates that to each SO by calling FreezeTokens().
Each SO will respond with validation that the Leafs were frozen and will internally keep a list of frozen public keys. If a frozen leaf owner attempts to transfer these funds, the SO will return an exception and refuse to proceed during the SignTokenTransaction() step.
Consolidate
While it may be desired for a wallet to hold multiple individual LTTXOs under different keys for privacy reasons, wallets not concerned about this can at any time choose to consolidate all of their leaves for a given token into a single leaf. This does not require a separate flow and is a simple ‘self transfer’ where all currently owned token leaves are added as inputs with a single output.
Wallets not concerned about keeping its leaves unassociated are advised to execute this operation immediately upon receiving funds to ensure that unilateral exit costs remain low.
Burn
Tokens representing Stablecoins will oftentimes be burned to signal to the network that those tokens were redeemed off-chain. For the protocol we have defined a standardized burn public key “02….” (repeating) to enable an issuer to demonstrate that these tokens were irreversibly burned.