Interoperability is a key element for ensuring smooth experiences within blockchain and cryptocurrency ecosystems. However, a significant gap exists in the integration between many current wallet Software Development Kits (SDKs) and RGB, a protocol designed for issuing assets and executing smart contracts on the Bitcoin network. Utexo, a participant in the CTDG Dev Hub, has taken a step to bridge this gap by introducing RGB support for Tether's Wallet Development Kit (WDK) through the Utexo SDK. This support aims to reconcile fundamentally different perspectives on asset state.
Most wallet SDKs are built around specific functions: managing keys, monitoring balances, creating transactions, and interacting with the underlying blockchain. These SDKs generally operate on the assumption that asset state is globally visible, derived from the blockchain, and updated in a consistent, sequential manner. This model aligns well with Bitcoin's Unspent Transaction Output (UTXO) model or account-based systems like Ethereum.
However, RGB deviates from these assumptions. RGB does not publish asset state on the blockchain; instead, it relies on client-side validation and off-chain transfers. Bitcoin transactions serve only as anchors in this system. This creates a structural challenge, particularly in the areas of balance tracking, transaction lifecycle, and state persistence and recovery.
In RGB, because validity depends on locally stored proofs and consignments, there isn't an on-chain source of truth for balances. The transaction lifecycle requires coordination between a Bitcoin transaction and an RGB state transition; neither fully represents the transfer on its own. Moreover, simply replaying the blockchain is insufficient for wallet recovery; local RGB state must be preserved and validated.
While RGB maintains Bitcoin's security and scalability, it places extra responsibilities on wallet SDKs. These include managing RGB state, handling validation data and persistence, and coordinating these elements with Bitcoin transaction flows.
Client-side validation in distributed systems ensures the validity and chronological order of states, verifying the correctness of protocol rules during state transitions. In Bitcoin, this process verifies changes in the UTXO set through transactions in ordered blocks, with each block representing a state update. The drawback of Layer 1 validation is that each node validates every transaction and stores the data after block inclusion. This leads to scalability and privacy issues. Public blockchains require everyone to validate all information, causing privacy and scalability concerns. However, a recipient primarily needs the last state transition (the transaction to them) and the sequence of transactions leading to it, forming a Directed Acyclic Graph of state transitions from genesis to the last state.
Client-side validation offers scalability, where the commitment of the verified state has a small footprint. It also provides privacy, using one-way cryptographic hash functions to keep the original data private.
Tether's WDK is a modular, multi-chain SDK with core wallet functions similar to other SDKs. Client-side validation protocols, such as RGB, allow a Bitcoin transaction to commit to data whose validity is determined separately from Bitcoin's consensus rules. These protocols can leverage consensus rules, like preventing double-spending, and impose additional rules known only to validators. A simple protocol might assign an off-chain state, like tokens, to a UTXO, requiring only validators to know the assignment. When the UTXO is spent, the user updates the state and uses spending transactions to assign the new state to a new UTXO, a mechanism known as single-use seals that leverages Bitcoin's anti-double-spending property.
For instance, if Alice controls the UTXO associated with a token and Bob wants to buy it, Alice provides evidence of the original assignment. Bob then verifies the history of every transfer using his validated copy of the blockchain and client-side validation. He also verifies that Alice's transaction is correctly formatted to assign the token to a UTXO that Bob controls. RGB uses taproot-embedded OP_RETURN commitments to allow transactions to commit to smart contract state.