Instead of publishing all contract data globally, participants pass the required history off-chain, verify the rules themselves, and check cryptographic commitments and closed single-use seals on Bitcoin.
Each recipient applies the particular protocol's rules to only the part of history that leads to the state being received. This is partial replication: other participants need not know or retain the contract's entire private graph. [4]
The required data travel outside Bitcoin as a package of history and proofs. A recipient must not accept only a current balance; they must verify the sequence of state transitions back to a trusted origin and bind every step to its corresponding on-chain commitment. [4]
A single-use seal is an abstract commitment that can be validly closed over a chosen message only once. A Bitcoin UTXO can serve as such a seal: spending it is a public, consensus-ordered proof of closure, while Bitcoin does not evaluate the meaning of the private data. [3]
Proof-of-Publication anchors a compact commitment in the public transaction order and makes an attempt to use the same seal for incompatible transitions detectable. Miners and full nodes still verify Bitcoin's rules, not the business logic hidden behind the hash. [2]
Client-Side Validation is a general design model, not a synonym for RGB. The LNP/BP registry lists LNPBP-9 as an informational draft, and related libraries expose interfaces for commitments, serialization, and single-use seals; concrete protocols define their own state and rules on top. [5]
Privacy and scaling move the duty to preserve data onto its owners. If a sender withholds the complete history or the recipient loses one required part, the public blockchain cannot reconstruct it from the commitment and local validation may end without a provable state. [4]
The public usually sees only a Bitcoin transaction and a short commitment, not the whole contract. This reduces the global data footprint but does not guarantee anonymity: timing, counterparties, data delivery, and a recognizable anchor structure can create metadata. [1]
Verification requires the exact protocol, a trusted genesis or schema, the seal definition, commitment scheme, complete linked history, Bitcoin transaction status, and software version. A hash on-chain by itself proves neither validity, value, nor ownership of an asset. [5]
For the clearest picture, read this entry together with UTXO, Double-spend, Hash, Taproot, Sidechain, Consensus Rules. The reverse links also lead from RGB Protocol, Taproot Assets.
01Do Bitcoin full nodes perform Client-Side Validation?+
No. Full nodes verify the Bitcoin transaction and its consensus rules; the recipient uses the appropriate client to verify private data and the rules over it locally.