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.

​
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.

​
FAQ

​
Is the Spark LRC-20 fork interoperable with the Original LRC-20 Implementation?

We’ve extended the original L1-only LRC-20 implementation to support Spark consensus natively. Currently, Spark LRC-20 is only compatible with other Spark LRC-20 nodes, though future updates may support direct gossip between Spark and L1-only nodes.

​
How many LRC-20 node peers will your Node gossip with by default?

Nodes specify a ‘boot-node’ at startup to seed their peer list. By default, your node will receive data from up to 125 peers and push data to up to 7 peers, though these settings are configurable.

​
What is the incentive for LRC-20 Nodes to openly share data?

Not sharing transaction receipts reduces both the availability of transaction confirmations and others’ ability to independently verify your transactions, degrading overall transaction quality.

​
How will the LRC-20 node scale with growing transaction history?

As transaction volume increases, we’ll implement archiving/pruning of older transaction history, allowing nodes to operate without ever-increasing storage requirements.

​
How can I ensure my transaction receipts are stored securely?

Run your own node to maintain direct control of your receipts. Alternatively, verify your receipt data is stored with multiple independent LRC-20 nodes (such as those owned by Spark Operators) to prevent data loss in case one node goes offline.

​
How do I protect against corrupted or fake receipts from malicious nodes?

Run your own LRC-20 node to validate directly against Bitcoin and Spark consensus mechanisms. Your node will automatically reduce communication with nodes sending invalid messages and eventually disconnect from persistent offenders. Alternatively, use a trusted service provider’s node.

​
How do LRC-20 node operators keep their software updated?

We follow standard versioning practices distinguishing between major and minor updates. Update instructions are posted to all public channels. While we prioritize backward compatibility, any necessary major updates will be communicated well in advance.

​
What validation occurs in the Spark Operator vs. the LRC-20 Node?

Both perform similar transaction validation before recording or signing transactions. However, LRC-20 nodes conduct additional validation against L1 history, such as verifying L1 token announcements before minting tokens.