The backbone of the LRC-20 Protocol is a decentralized network of nodes which provides critical off-chain services to support the overall token ecosystem.

LRC-20 Nodes from the backbone of the LRC-20 Protocol by providing critical off-chain services to support the overall token ecosystem. Each node has two major functions:

​
As A Data Availability Layer

  • Stores Token Transaction data provided by L1 + Spark wallets when initiating transactions and consensus nodes (Bitcoind and Spark Operators) when confirmation transactions.
  • Shares (eg. gossips) data to other LRC-20 Nodes to give them a complete record of transaction history.
  • Provides data to anyone who asks (eg. Wallets who would like to fetch or validate the state of tokens on the network)

​
As a Validator

  • Indexes Bitcoin L1 and Spark to build a complete internal graph of token movement.
  • Verifies that new transactions don’t break the rules of the LRC-20 Protocol to guard against user mistakes and attempts at cheating. Examples of cheating could include:
    • Case 1: Someone tries to create tokens out of thin air
    • Case 2: Someone tries to re-announce the same token again with different rules
    • Case 3: An Issuer tries to exceed the max supply of a token
    • Case 4: An owner of a TTXO tries to withdraw without the required time lock.

By encoding these functions into a decentralized node network, we ensure that any individual who wants to have guaranteed validity of their transactions prior to moving funds can run software (either by running their own LRC-20-Node or by writing their own validation logic) that enforces the rules of the protocol. Upon starting up their node, other nodes will gossip additional context about transaction history.

​
What LRC-20 Nodes are *Not

  • LRC-20 Nodes are not a consensus mechanism.
    • There is no expectation of ‘honesty’, and any invalid or malicious gossip can be instantly validated directly with the network nodes actually involved in consensus (Bitcoind blockchain history and SO history)
  • LRC-20 Nodes are not intended to exist in a closed network
    • Although technically a node could choose to only communicate with certain other nodes, the nature of the network is inclusive rather than exclusive. LRC-20 nodes by default will discover nodes & gossip with the wider network.

​
Best Practices

We encourage you to run your node! Not only does this help improve availability and redundancy in the wider network, but it is also the best way to guarantee that your TTXOs are promptly recognized and that receipts are stored safely.

Note: Detailed instructions on how to run your own LRC-20 node are coming soon.

​
Technical Details

​
LRC-20 On L1

One core design principle in the LRC-20 protocol is the desire to enable On-Chain token transactions that do not take up more block space than a standard Bitcoin transaction. In order to enable this, standard UTXO addresses are tweaked deterministically according to the number and type of token stored in that UTXO. LRC-20 nodes then store the Transaction Receipts for each token UTXO which enables verification of the tokens embedded within a tweaked UTXO.

The stored receipt data for each LRC-20 UTXO includes the:

  • Token Public Key
  • Token Amount
  • Receiver Public Key

​
Full communication protocol

For a formal description of the LRC-20 protocol on L1, see the whitepaper.

​
LRC-20 On Spark

Unlike L1 Bitcoin transactions, where UTXOs (Unspent Transaction Outputs) embed token details and are burdened by spending conditions defined in the ‘Bitcoin Script’, Spark Token Transactions use TTXOs (Token Transaction Output) that are spent by providing a signature of the token transaction and the release of a revocation secret for each output.

​
Full communication protocol

All LRC-20 operations (with the exception of Token Announcement) can be conducted natively on Spark via TTXOs. However, the validation mechanisms and verification data changes significantly. There are two underlying changes:

​
Consensus

  • Rather than receiving transaction confirmation updates from Bitcoin nodes, updates are now received from Spark Operators.

​
Receipt Data

  • Rather than holding a Receipt which contains simply a txid, token amount, and token public key, LRC-20 nodes for spark transactions hold more data. It holds a transaction object which contains:
    • The entire Token Transaction for validating TTXO Withdrawals
    • Spark Operator signatures for validating created TTXOs
    • Revocation secrets for validating spent TTXOs

The expanded receipt data allows for the LRC-20 node to verify the validity of any withdrawal transactions that move the funds back to L1. If a user were to maliciously change these values to unexpected ones, the LRC-20 node can detect it and ignore that transaction.

​
Bringing L1 and Spark Together

Operations for a given LRC-20 token do not have to be isolated to one network, and can occur in parallel across both networks. The ‘link’ between these operations is the Gossip protocol. Any context across networks that may be missed by a given LRC-20 Node (for example, if the node is subscribed Spark-only) will be shared by the Gossip protocol. This enables a bridging of the two disparate consensus + finality mechanisms used on Bitcoin L1 vs in Spark.