Introduction

Client-side validated smart contract protocols like RGB leverage cryptographic commitments on a base blockchain (e.g. Bitcoin) to ensure consensus on transaction ordering without publicly revealing the contract data. This design greatly improves privacy and scalability by keeping state transition data off-chain. However, a key drawback of current RGB implementations is the requirement that transacting parties be online simultaneously to exchange and verify proofs, essentially coupling synchronization with verification. In other words, senders must deliver the full off-chain state proof to recipients in real-time (a “proof-of-receipt” paradigm), and both parties must remain online to complete the transfer. This synchronous coupling can hinder usability and reliability – for example, if a recipient is offline, the sender cannot finalize the transfer, and the state might become inaccessible.

Another significant challenge arises when extending RGB beyond a single blockchain. In a multi-chain environment, assets may need to “leap” across chains without trusted intermediaries. Traditional cross-chain bridges have typically relied on lock-mint or burn-mint schemes with custodial multi-signature vaults, which introduce central points of failure. These bridges have proven highly vulnerable – over $2 billion was stolen in cross-chain bridge hacks in 2022 alone. Even more recent analyses indicate recurring bridge attacks have cumulatively cost users more than $1.5 billion. The reliance on trusted committees or custodians undermines security and user control. By contrast, a trust-minimized approach would allow assets to move directly between blockchains under the sole control of users’ private keys, eliminating centralized honeypots and collusion risks.

This paper argues that the RGB protocol should not remain bound to a tightly coupled synchronous verification model. We present a new approach – the State Relay Graph (SRG) – that decouples state synchronization from verification and enables secure, efficient cross-chain state transfers. In our SRG design, each asset’s evolution is represented as a graph of anchored states across potentially multiple blockchains. This architecture offers several benefits: (1) Faster transfers with asynchronous client-side syncing (no need for both parties to be simultaneously online), (2) inherent double-spend prevention via one-time anchors and single-use seals, (3) support for time-to-live (TTL) constraints to enforce timely state propagation or rollback, and (4) improved overall security by leveraging the native consensus of multiple chains without introducing new trusted parties. Crucially, SRG achieves these gains while preserving RGB’s core advantages in privacy and confidentiality. By integrating CoinJoin/PayJoin techniques, multiple transfers can be merged or coordinated in a way that obfuscates the linkage between inputs and outputs, thereby preventing the state graph from leaking sensitive information. At the same time, we design an optional compliance mechanism wherein asset issuers or owners can reveal a verifiable audit trail to authorized parties via a viewing key, similar to the selective disclosure feature of Zcash shielded addresses. This dual mode supports anonymity by default with opt-in transparency when required.

In summary, our contributions include: (a) a formal model of cross-chain anchors, states, and relay graph paths for client-verified contracts; (b) a method to construct and validate a state graph that spans multiple anchor chains (e.g. BTC, Kaspa, Tondi, Ethereum) with no centralized indexer or relay server; (c) a demonstration of how SRG can accelerate state transfer and finalize ownership without compromising double-spend security or requiring custodians; (d) a privacy-enhancing integration with CoinJoin/PayJoin to achieve anonymous path convergence, concealing which asset followed which path; (e) a compliance-friendly design using viewing keys and anchor proofs for selective path disclosure; and (f) a performance analysis comparing SRG-based transfers to Lightning Network channels and atomic swaps, highlighting trade-offs in speed, trust, and scalability. We also outline future research directions, including zkSNARK-based path verification, recursive relay automations, and possible federation signaling to further improve the system.

The rest of this paper is organized as follows. We first define the system model and key concepts of anchors, states, graph paths, and relay nodes. Next, we describe the construction of the state relay graph and the constraints needed to ensure each path is trustworthy (sound and conflict-free), including how invalid or conflicting branches are pruned. We then discuss how SRG can be combined with CoinJoin/PayJoin mechanisms to enhance privacy, allowing multiple asset paths to merge and diverge in a manner that thwarts chain analysis. Following that, we present the compliance and viewing key design that permits regulated transparency on demand. We evaluate the expected performance of SRG-based transfers and compare it to Lightning channels and atomic swaps, illustrating that SRG provides a unique balance of decentralization, flexibility, and security. Finally, we outline areas for future work and conclude that decoupling synchronization from verification via the State Relay Graph significantly improves the RGB protocol’s extensibility to a multi-chain, privacy-preserving future.

Model Definitions

To formalize our approach, we introduce the following core concepts:

Anchor: In the context of RGB and SRG, an anchor is a cryptographic commitment embedded in a blockchain transaction that ties the off-chain state data to that chain’s consensus. An anchor typically consists of a transaction identifier on the underlying blockchain and a commitment (e.g. OP_RETURN output or Taproot tweak) that encodes the hash of the new state. Each anchor serves as a single-use seal – it can be spent (used) only once, preventing the same state from being committed twice. The spending of an anchor (e.g. the corresponding UTXO in Bitcoin or an equivalent one-time output on another chain) signals a state transition in the client-side-validated contract. Anchors are the bridge between off-chain RGB state and on-chain evidence: they provide proof-of-publication of a state update without revealing the state’s contents. In a cross-chain scenario, an anchor can reside on any supported chain (Bitcoin, Kaspa, “Tondi”, Ethereum, etc.), and the state can move by transitioning its anchor from one chain to another.
State: A state in RGB refers to the complete set of client-side data describing an asset or contract at a given point. This includes asset ownership (which public key or address controls it), asset amount or denominations (for fungible tokens), and any contract-specific data or conditions (for smart contracts or NFTs). States are updated via state transitions, which are operations that consume previous state(s) and produce a new state, analogous to transactions consuming and creating UTXOs. However, unlike a public blockchain, these states are not globally published – they are shared only with involved parties and committed via anchors for integrity. In SRG, we consider a state to be anchored on a particular chain at any time. For example, an RGB asset might start with a genesis state anchored in Bitcoin; later the state might transition to another state anchored in Ethereum, meaning the asset effectively moved chains. The state data itself (the contract details and proofs) remain off-chain and known to the asset owners and participants, while the anchors ensure that anyone can verify a given state was indeed committed to a certain chain’s ledger at a specific transaction.
Graph Path: We model the progression of an asset’s state as a path in a directed acyclic graph (DAG). Each node in this graph is an anchored state (the combination of an off-chain state and its on-chain anchor). A graph path represents the lineage of an asset from its genesis state (initial issuance) through each transfer to the current state. Because states can split or merge, the overall structure forms a graph: a single state can have multiple child states if, for instance, an asset is subdivided among multiple new owners (one parent state yields two outputs states, like splitting 100 tokens into 60 and 40). Conversely, multiple assets or parts of assets could be joined in a single transaction (e.g. different assets transferred in one CoinJoin), causing what appears as merged paths in the graph (though each asset’s provenance remains distinct). Importantly, each edge in the graph corresponds to a valid state transition, which is secured by the cryptographic commitments linking parent and child anchors. A graph path, therefore, is a sequence of anchors across potentially different chains, all cryptographically chained together by client-side validation proofs, starting from a genesis and ending at the latest state for an asset. The length of the path may increase as the asset travels across chains and through owners, but verifying the path does not require trusting any intermediaries – each hop’s validity can be checked by the client using the off-chain data against the on-chain anchors.
Relay Node: In the context of SRG, a relay node can be understood in two complementary ways: (1) as a node in the state graph – i.e. an intermediate anchored state that “relays” the asset from one anchor to the next, possibly on a different chain; and (2) as a network participant who helps forward the state data. In our pure client-driven design, we do not rely on any specialized trusted intermediaries or indexing servers to relay information, so every participant who receives a state and later transfers it effectively acts as a relay. When Alice moves her RGB asset from Bitcoin to Ethereum, for example, Alice herself is the relay entity performing that cross-chain transfer (creating a Bitcoin transaction that commits a handoff to an Ethereum anchor, and then publishing a corresponding Ethereum transaction). In the SRG graph, the Bitcoin-anchored state and the Ethereum-anchored state are connected via that transition. Thus a relay node (graph) = an anchored state that has both an incoming and outgoing edge in the multi-chain DAG (meaning it’s not a genesis or final state, but an intermediate state that passes the asset along). Because we aim to avoid centralized relays, the term is mainly used abstractly for analysis. We assume each user’s SRG wallet software is capable of path tracing and relaying states as needed, without delegating trust to third-party servers.

With these definitions, we can imagine an RGB asset’s life cycle as a series of anchors connected by off-chain proofs, forming a state relay graph. Our goal is to allow a client to independently trace and verify the entire graph path of any asset it receives – even if that path spans multiple blockchains – using only the information in the public blockchains (anchors) and the off-chain data provided by the previous owner (or other participants), without querying any central index. In the next section, we describe how such a graph is constructed and enforced to be trustworthy.

State Graph Construction and Trusted Path Constraints

In an SRG-enabled RGB system, the state graph is constructed gradually as assets are transferred or moved across chains. The graph must satisfy certain trusted path constraints to ensure that it represents a valid history with no double-spends or tampering. We outline how the graph is built, how a client verifies a path, and how invalid branches are detected and pruned.

Graph Construction: The process begins at the asset’s genesis, which defines the initial state (e.g. an issuance of some tokens or rights by an issuer) and anchors it on a base chain. For instance, an issuer might anchor the genesis of a new token on Bitcoin by creating a special transaction output with an RGB commitment. From that point, any transfer of the asset to a new owner will produce a state transition. In a single-chain scenario, this means the original Bitcoin UTXO is spent, and a new UTXO is created (possibly to the new owner) with a new RGB commitment that encodes the updated state. In the graph, this appears as an edge from the genesis node to a new node representing the first transfer. Now, if we introduce cross-chain transfers, a state transition can also result in the asset’s anchor moving to a different blockchain. For example, suppose Alice holds an RGB asset anchored on Bitcoin, and she wants to “leap” to Ethereum (perhaps to use the asset in an Ethereum DeFi contract). With SRG, Alice would create a Bitcoin transaction spending her UTXO (thus voiding the old anchor) and embedding a commitment that indicates a handoff to Ethereum. This could be implemented by tying the RGB state’s next single-use seal to an Ethereum transaction hash or an Ethereum address that will carry the next state. Concretely, Alice might include in her Bitcoin commitment a reference like “next anchor = (Eth TxID XYZ)”, and then on Ethereum she publishes a transaction (for example, calling a lightweight RGB anchor contract or simply emitting a log) that contains the matching commitment proving she controls the asset on Ethereum now. This effectively sets the Ethereum anchor’s unlocking condition to the Bitcoin UTXO having been spent. Once both the Bitcoin and Ethereum transactions are confirmed, the asset’s state has “moved” — the graph now has an edge from a Bitcoin-anchored node to an Ethereum-anchored node, representing a trustless cross-chain transfer. No custodian held the asset during this move; the Bitcoin chain’s consensus ensured Alice couldn’t double-spend her UTXO, and the Ethereum chain’s inclusion of the new state provides verifiable evidence of the asset’s new location.

It is worth noting that the UTXO model makes such cross-chain handoffs elegant: the spending of the UTXO on Chain A can be directly used as the trigger to unlock an output on Chain B. For account-based chains like Ethereum (which lack native UTXOs), we simulate a similar one-time anchor by using a dedicated anchor contract. This contract can maintain a registry of used anchors or use an event nonce such that each cross-chain transfer has a unique identifier. The principle remains that each state transition consumes a unique seal on the source chain and establishes a new one on the destination chain. Thus, the graph is extended by one node and one edge each time an asset is transferred, either within the same chain or across to a new chain.

Path Verification: When a client (say, Bob) receives an asset, he needs to verify the entire path of state transitions leading to his current state to be confident the asset is valid. Thanks to client-side validation, Bob does not need to trust any global ledger beyond the anchor blockchains’ normal consensus; he only needs the cryptographic proofs of each transition and the public blockchain records. Bob will typically be given the full history of state data (or at least the cryptographic digest chain) by the sender. To verify, Bob traverses from the genesis (or from the last state he knows as valid) through each link: for each state transition, he checks that the previous anchor was indeed spent (consumed) exactly once and corresponds to the new anchor. This involves checking the single-use seal property – each prior anchor’s transaction output should appear spent in the expected next transaction. Bob can use SPV (Simplified Payment Verification) proofs or light client techniques to verify cross-chain events; for example, to verify a Bitcoin UTXO was spent in a certain block, an SPV proof on Bitcoin can be used, and similarly, if verifying a move from Ethereum, Bob might verify an Ethereum Merkle proof or header inclusion on the Ethereum side. Each anchor includes the necessary data (such as the Bitcoin TxID or Ethereum event hash) in the off-chain proof Bob received (this data is part of the anchor structure). Bob ensures that the cryptographic commitment in the previous anchor binds to the details of the next state (this is typically done by having the previous state’s commitment include the hash of the new state or the new anchor, as per RGB’s design of tied commitments). By sequentially checking all links, Bob confirms that the state he now holds is part of a consistent chain of custody from the issuer.

A critical constraint for trust is that no state can have two valid successors. Thanks to single-use seals, if a malicious owner attempted to fork the state (sending the same asset to two different recipients or two different chains), they would have to double-spend the same anchor, which base-layer consensus will not permit. For example, Alice cannot successfully anchor the same prior state into both an Ethereum transaction and a Kaspa transaction, because that would entail two spends of the same Bitcoin UTXO (if the asset was on Bitcoin). Only one spend can confirm; the other will be rejected by Bitcoin’s miners as a double-spend. Thus, the state graph should never have a node with two confirmed child edges. If such a fork is attempted, at most one branch can be realized in the graph, and the other will remain unconfirmed (and thus invalid from the perspective of any honest verifier). This property ensures the graph is a tree of states growing forward, rather than a branching tree – any branch indicates a double-spending attempt and will be pruned by lack of confirmation.

Pruning Invalid Paths: The SRG client logic includes the ability to detect and prune invalid or conflicting paths. If Bob, while verifying history, encounters evidence of a conflict (for instance, two different purported “next states” both claiming to spend the same anchor), Bob will examine the underlying blockchains to see which (if any) actually got confirmed. The confirmed branch is kept, and any conflicting unconfirmed branch is rejected as a fraud attempt. The design inherently leverages the finality of each underlying chain to decide the valid path. Once an anchor is spent and confirmed on-chain, that is an immutable proof of which direction the state went; any alternative attempt is forever invalid. Additionally, if an earlier state in the path had any rule violations (e.g. the amounts don’t balance, or an unauthorized transfer according to the contract’s rules), Bob would detect that by validating the off-chain data against the contract’s schema (RGB ensures each state transition is verified against the smart contract rules locally). In such a case, Bob would know the asset’s history is corrupt and can refuse the payment. However, under normal operation with honest parties, the off-chain validation and on-chain anchors align to show a single valid lineage.

Time-to-Live (TTL) and Timeliness: Introducing a TTL constraint into state transitions can further enhance security and liveness. TTL in this context means a state transition may carry an expiration or deadline by which it must be confirmed on the new chain, or else it is considered failed. For example, if Alice initiates a cross-chain transfer to Ethereum, she could include a clause that if the Ethereum anchor transaction is not confirmed within, say, 10 blocks (or a certain time), then the transition is aborted and Alice retains control on the source chain (perhaps via not finalizing the spend or via a time-locked covenant). TTL prevents a state from being in limbo indefinitely and can mitigate denial-of-service scenarios where a malicious party accepts an off-chain state but never completes the on-chain anchor. In SRG, we can implement TTL by using hash-timelock techniques akin to HTLCs in atomic swaps. Essentially, the transfer can be made conditional on a timely proof of the new anchor. If the condition is not met, the original anchor spend can be rolled back or invalidated. This adds a time-bound trustlessness: either the cross-chain move finishes in time, or it fails safely, avoiding a scenario where neither party is sure of the asset’s status. In our model, TTL thus contributes to safety (preventing dangling states) and speed (incentivizing quick finalization of cross-chain moves).

By obeying these constraints – single-use of anchors, verifying every link’s cryptographic integrity, pruning unconfirmed branches, and optionally enforcing TTL on cross-chain operations – the State Relay Graph ensures that any path a client accepts is sound (authentic and unique). It is effectively a distributed state graph that all clients can come to agreement on, without needing a centralized index: the agreement emerges from the public blockchains’ consensus and the matching cryptographic proofs. Each client is like a spider traversing the web of anchors, independently verifying each thread. The result is that synchronization of state (i.e. one party handing off the data to the next) can be done asynchronously or via store-and-forward, because even if a receiver misses an update in real time, they (or any other party) can later reconstruct the path by scanning for the relevant anchors on each chain. This decouples the act of committing a state (which is public and timestamped on-chain) from the act of verifying it (which a client can do at any time after the fact). The network no longer requires an always-online handshake for every transfer. Instead, the blockchain anchors act as a public bulletin board where commitments are posted, and each client can pull the information it needs from that board.

In the next section, we delve into how privacy is maintained in this model. One might worry that linking states across chains and recording anchors could reduce anonymity by giving observers more clues. We address this by leveraging CoinJoin and PayJoin mechanisms in conjunction with SRG to converge multiple paths and thereby hide individual asset trails.

SRG Integration with CoinJoin/PayJoin for Anonymous Path Convergence

One of RGB’s celebrated advantages is privacy: since transaction details and ownership changes are not on a public ledger (only commitments are), outsiders cannot easily trace who owns what or how assets move. However, introducing a cross-chain state graph might seem to expose more information – for instance, an outside observer could see that some Bitcoin UTXO with an RGB commitment was spent and then an Ethereum event happened, suggesting an asset moved from Bitcoin to Ethereum at a certain time. If each asset were moved individually, an analyst could potentially correlate the on-chain events and infer an asset’s path (though they still wouldn’t know the asset type or amount without the off-chain data). To counter this, SRG incorporates CoinJoin and PayJoin techniques to enable anonymous path convergence: multiple assets’ state transitions are combined in such a way that it becomes infeasible to tell which output state corresponds to which input state.

CoinJoin in State Transitions: CoinJoin is a trustless method of combining transactions where multiple users cooperate to produce a single transaction with many inputs and many outputs, thereby obscuring the mapping between them. In a Bitcoin context, CoinJoin breaks common input ownership heuristics by having inputs from different people in one transaction. We apply the same principle to RGB state transfers. Suppose several users each want to transfer their RGB assets (possibly of the same type or even different types) around the same time. They could form a join transfer: aggregate their state transitions into one batched operation. Practically, this means they create one on-chain transaction (or one pair of cross-chain transactions for a leap) that includes all their anchors together. For example, imagine Alice, Bob, and Carol each have an RGB token anchored on Bitcoin and they all want to move to the Kaspa chain (or even just transfer ownership on Bitcoin). Using CoinJoin, they coordinate to spend all three of their Bitcoin UTXOs in a single transaction, which produces three new outputs – but these outputs correspond to the new states in a mixed order. Each new output has an RGB commitment for the next state (which could be on Kaspa or on Bitcoin, depending on the plan). An outside observer sees one transaction with three inputs and three outputs, but cannot determine which input maps to which output. If the outputs are uniform amounts (a common CoinJoin practice is to use identical output amounts to make them indistinguishable), it further confuses linkage. In the context of cross-chain, the participants could even coordinate such that, say, each one moves to a different chain in the same combined operation – a complex scenario, but one that SRG could support. The key effect is that the paths converge: multiple distinct asset histories intersect at a single on-chain event, and then diverge. This breaks the simple one-to-one tracing. An analyst might see that a set of assets moved collectively, but not who ended up where.

PayJoin (P2EP) for two-party privacy: PayJoin, also known as Pay-to-EndPoint (P2EP), is a special two-party CoinJoin where the receiver of a payment contributes one of the inputs, thereby confusing observers about which output is the actual payment vs change. In our scenario, PayJoin can be used whenever an asset is being transferred from one user to another even on the same chain. For instance, Alice wants to send Bob an RGB asset on Bitcoin. Normally, Alice would spend her UTXO and create an output for Bob. In a PayJoin, Bob also contributes one of his own UTXOs into the transaction and receives change back. The resulting Bitcoin transaction has Alice’s and Bob’s inputs and Alice’s and Bob’s outputs, making it look like a self-transfer or a normal CoinJoin rather than a clear sender→receiver payment. This invalidates the common input ownership heuristic that chain analysis uses, because now inputs belong to two different people. In SRG terms, the state transition (Alice’s asset moving to Bob’s control) is obscured within this PayJoin. An observer cannot be sure that Bob actually received an asset; it could appear as if Bob and Alice simply mixed some coins and each got some back. PayJoin thus provides plausible deniability and greatly enhances privacy for single transfers.

Combining these techniques with SRG yields a powerful anonymity set. Not only is the content of the state (asset type, amount, contract details) hidden by cryptographic commitments, but even the fact that “asset X moved from user A to user B” is concealed among other movements. For example, if a CoinJoin includes 5 different RGB assets being transferred among 5 people (potentially also hopping chains), an outsider sees a complex transaction involving 5 anchors in and 5 anchors out. Those 5 outputs could represent any permutation of the 5 inputs – the mapping is obscured. This is analogous to mixing in traditional cryptocurrencies, but here it is applied at the layer of state transitions. The more participants that join, the larger the anonymity set and the harder it becomes to trace any single asset’s path. The state relay graph thus may have merged nodes where multiple prior states all feed into one joint anchor (conceptually one graph node with multiple parents) and then split out into multiple children. While the internal details of such a merge are only known to the participants, from an external perspective the graph has an entropy that defeats simple tracing.

It’s important to note that, unlike a centralized mixer, CoinJoin/PayJoin are trustless and decentralized. Users do not hand their assets to a third party; they simply cooperate to construct a legitimate transaction that benefits all of their privacy. No modification to the underlying protocols is required to allow this – it’s a coordination among wallets. SRG wallets can incorporate a feature to discover or coordinate with others who want to perform transfers around the same time, then automatically create a joined transaction. There are some practical considerations (latency, the need for an interactive protocol to form the CoinJoin, etc.), but these are well-studied in Bitcoin privacy research and tools exist (e.g. Wasabi, JoinMarket). Our proposal could extend such coordination across chains: for example, a group of users could collectively initiate cross-chain transfers such that one large Bitcoin transaction fans out to multiple chains’ outputs, or vice versa, multiple chains converge into one (though cross-chain CoinJoins require careful interlocking, possibly by two-phase commits or adapter signatures).

Anonymous Path Convergence Benefits: By implementing CoinJoin and PayJoin at strategic points, SRG ensures that building a multi-anchor state graph does not degrade privacy – in fact, it can enhance privacy due to the larger anonymity sets. Even users who do not themselves CoinJoin gain some privacy benefit if a significant fraction of transactions use these methods. As the Blockstream research noted, if enough transactions involve multi-party inputs, the common-ownership heuristic is broken broadly, improving privacy for everyone. In our scenario, if SRG transfers commonly involve path convergence, an analyst can no longer assume a one-to-one mapping of RGB commitments indicates a direct asset move; it could be part of a mixed multilateral transfer. This means that RGB’s inherent privacy (hiding contract data) is complemented by transactional privacy (hiding relationships between participants).

In sum, SRG with CoinJoin/PayJoin preserves anonymity by design. We maintain confidentiality of asset details (through client-side validation and commitments) and unlinkability of transfers (through joined transactions). For compliance or auditing, however, some users might voluntarily need to reveal their asset’s history. We address that next through a viewing key mechanism that enables compliance-friendly transparency without undermining the default privacy for others.

Compliance and Viewing Key Design: Supporting Optional Path Disclosure

While privacy and anonymity are highly desirable for most users, certain scenarios demand selective transparency. For example, institutional users or regulated entities might need to prove the provenance of an asset, demonstrate that it wasn’t involved in illicit activity, or comply with reporting requirements. How can we reconcile the privacy-by-default nature of SRG (and RGB) with the option of compliance when needed? Our solution is inspired by the “viewing key” concept used in privacy coins like Zcash and advanced smart contract systems. We introduce a viewing key + anchor proof mechanism that allows an authorized third party to trace and verify an asset’s state relay graph path, only if the asset owner chooses to disclose it.

Viewing Key Concept: A viewing key is essentially a special cryptographic key or token that grants read-access to otherwise concealed information. In Zcash, for instance, a user can share a viewing key with an auditor to let them see all transactions related to their shielded address, without allowing the auditor to spend funds. We adopt a similar approach for SRG. Each RGB asset (or each wallet holding assets) can have an associated viewing key that can decrypt or unveil the details of its state transitions. Concretely, the state data that is kept off-chain (which includes information like previous owner, asset type, amounts, etc.) can be encrypted in such a way that only someone with the viewing key can decrypt it. By default, other network participants cannot see the content of state transitions, only the commitments. But if a user provides their viewing key to a regulator or auditor, that party could reconstruct the full history of that asset’s graph path: every off-chain state and its corresponding on-chain anchor, from genesis to current.

Anchor Proofs: In addition to revealing the plaintext state data, a compliance audit needs to verify the on-chain evidence for each step. This is where anchor proofs come in. An anchor proof would be, for example, an SPV proof or a Merkle inclusion proof that a given commitment was included in a certain block on the anchor chain. Since all anchors are public, the auditor can fetch the relevant blockchain records (e.g. Bitcoin or Ethereum transactions) directly. The viewing key would allow them to know which transactions to look at (because it reveals the TxIDs or anchor IDs that were hidden in commitments). The auditor can then independently verify each anchor’s authenticity: e.g., check that the Bitcoin transaction with TxID X was confirmed in block Y (perhaps using a block explorer or their own node), and that it contains the expected commitment corresponding to the disclosed state. This process is akin to showing receipts: the viewing key reveals the receipt numbers (TxIDs), and the auditor checks those receipts on the public ledger.

The combination of these two – decrypted state data and verified anchor inclusion – provides a full audit trail. The auditor can see who owned the asset when, how it moved, on which chains it resided, and confirm that no double-spends or hidden forks exist, because they can follow the single path of confirmed anchors. Essentially, the auditor is performing the same kind of path verification the client does, but now with the ability to identify the participants and values, since the data is no longer encrypted to them.

Selective and Secure Disclosure: A crucial aspect is that this disclosure is optional and selective. Only those who are given the viewing key (and any associated decryption keys for historical data) can see the info. Others observing the blockchain or even participating in CoinJoins remain unable to piece together the asset’s history. This satisfies regulatory needs without redesigning the protocol to be universally transparent. For instance, a financial institution using RGB for issuing securities could provide regulators with a viewing key for their assets, enabling oversight of all transfers, while the general public and competitors see nothing beyond random-looking commitments. It’s a fine-grained control: users maintain privacy unless they opt to share details.

One can also implement partial viewing keys – for example, a viewing key that only reveals that an asset exists and is valid up to a certain point, without revealing identities. But typically, compliance means linking to real-world identities. In practice, the user might accompany the viewing key with identity attestations off-chain (like, “Address ABC is owned by Company X”). The viewing key just proves the cryptographic consistency.

We draw on existing precedents for such designs: Zcash’s selective disclosure for transactions, and similar capabilities in projects like Railgun (which offers an auditor view key for private DeFi transactions). An important consideration is revocation – if a viewing key is compromised, can it be revoked? Ideally, the viewing key might be tied to certain time ranges or use counters. But if one is compromised, a user might have to transfer assets to a new contract with a new key. This is beyond our scope, but we mention it as an operational detail.

Compliance with CoinJoin/Privacy: One might wonder, if CoinJoin is mixing multiple users, how does an auditor differentiate the specific asset’s path in a joined transaction? Here, the viewing key for a particular asset would allow the auditor to pick out which output of the CoinJoin corresponds to that asset. Recall that during a CoinJoin, multiple outputs are created. The asset’s off-chain state (decryptable by the viewing key) will contain a reference to the specific output (like an index or a specific commitment) that is this asset’s new anchor. So even though to the public all outputs look alike, the viewing key reveals “among those outputs, this one is ours.” Thus, even mixed transactions can be unscrambled by the rightful party’s viewer, but remain opaque to outsiders. This property is analogous to how in Monero, ring signatures mix many decoys but a user with the key can identify which one was real; or in CoinJoin, each participant knows which output is theirs, but an outside observer cannot tell. We are essentially giving the auditor the perspective of the user whose history is being audited.

In summary, the viewing key + anchor proof mechanism provides an auditability option: Regulators or partners can be given insight into the asset flows when needed, ensuring that privacy features do not equate to opaqueness for lawful purposes. It’s a best of both worlds approach—routine transactions stay confidential and un-linkable, but if required, full transparency can be achieved for specific assets or users. As noted in industry discussions, this kind of selective disclosure is increasingly seen as important for privacy tech adoption in regulated environments.

By supporting anonymity with optional disclosure, SRG can cater to both cypherpunk privacy advocates and compliance-conscious enterprises. The design aligns with emerging regulatory expectations that even privacy-enhancing cryptocurrencies provide some mechanism for accountability (e.g., recent guidance that at least an “opt-in” audit feature is desirable). Our approach ensures that RGB does not have to sacrifice its privacy ethos even as it expands functionality – privacy remains the default, and compliance is a controlled capability.

Having detailed the architecture and features of SRG, we now turn to evaluating its performance and comparing it with alternative mechanisms for cross-chain asset transfer, notably Lightning Network payment channels and atomic swaps.

Performance Analysis and Comparative Evaluation

We evaluate the SRG approach along key dimensions – speed (latency and throughput), security model, complexity, and usability – and compare it to two prominent alternatives for moving value across chains or off-chain: the Lightning Network (payment channels) and atomic swaps. Each of these approaches has different trade-offs, and understanding them will highlight the unique niche that SRG fills.

Speed and Latency: In SRG, each cross-chain transfer or state transition ultimately relies on at least one on-chain transaction per involved chain (to commit the state). For example, moving an asset from Bitcoin to Ethereum involves a Bitcoin transaction (to spend the anchor) and an Ethereum transaction (to create the new anchor). This means the latency for final settlement is on the order of the slower chain’s block confirmation time (possibly both chains). If Bitcoin takes ~10 minutes and Ethereum ~15 seconds (with probabilistic finality or a bit longer for strong confidence), the transfer is effectively done within one Bitcoin confirmation – because the Ethereum side can be done very quickly after. So perhaps ~10 minutes in that scenario. By contrast, the Lightning Network offers near-instantaneous payments once channels are established. Payments on Lightning are completed in milliseconds to seconds, since they are off-chain and only require updating local channel state and possibly forwarding along a route. This makes Lightning ideal for fast, frequent transactions (e.g. retail payments), with virtually real-time settlement as long as the network route has liquidity. However, Lightning’s speed advantage comes with constraints: initially opening a channel is on-chain and takes time and fees, and multi-hop payments can fail if any channel on the route lacks capacity. Lightning is not typically used to transfer an asset to a different chain, but it can do cross-chain payments if both chains support HTLC and share hash functions. Those cross-chain Lightning swaps are still very fast (off-chain atomic swaps via HTLCs), effectively as quick as normal LN payments, but require at least a network of channels spanning the chains.

Atomic swaps (on-chain HTLC-based swaps between two chains) usually involve a sequence of on-chain transactions with time locks. A typical atomic swap might require 2 transactions on each chain (one to lock, one to spend or refund), and participants often wait for at least one confirmation on each step to be safe. This can mean a swap takes on the order of minutes to an hour, depending on block times and how many confirmations each step waits for. It’s slower than Lightning (which is essentially a more interactive, off-chain form of atomic swap) and roughly comparable to SRG’s on-chain moves, possibly a bit slower because atomic swaps are a multi-step protocol (lock then redeem) whereas SRG’s transfer is one-step (just move asset and confirm). The Time-Locked aspect in atomic swaps ensures safety but introduces waiting periods (e.g. if one party disappears, the other might have to wait for a timeout to get funds back). SRG can similarly incorporate timelocks (TTL) but typically each transfer is done in a single coordinated step, not two sequential steps, so it might complete faster than a full atomic swap cycle.

Throughput-wise, SRG uses layer-1 transactions for each transfer, so its throughput is limited by underlying chains’ capacity (e.g. a few TPS on Bitcoin). However, note that one on-chain transaction can carry many state transitions if using CoinJoin (batching), so it can be more efficient. Lightning can achieve extremely high throughput off-chain (potentially thousands or more transactions per second across the network) since channel updates don’t hit the blockchain for each payment. Atomic swaps are one-to-one and require new on-chain transactions each time, so their throughput is low (and they aren’t meant for high frequency; they are usually for one-off trades).

Security and Trust: All three approaches (SRG, Lightning, atomic swaps) aim to be trustless, but in different ways:

SRG: Trust is placed in the cryptographic verification and the security of the underlying blockchains. There is no new trust assumption beyond those networks. Each transfer is as secure as the chains’ consensus. Double-spending is prevented by the base layer (single-use seal), and no third party can steal or block the asset without controlling the majority of a blockchain’s miners/validators. SRG does not introduce custodians or oracles; the user’s keys and the chains do the work. However, one must trust that they can eventually get their transaction confirmed on the destination chain (if, say, miners censor a particular contract, that could be an issue, though with multiple chains an asset could potentially reroute to a different chain if one is censored).
Lightning: Security is based on game-theoretic smart contracts (HTLCs) and the assumption that parties can stay online to respond to breaches (or use watchtowers). There is a slight liveness requirement: if you go offline for too long, a counterparty could try to cheat by broadcasting an old state. With proper use of watchtowers or being regularly online, this is mitigated. Lightning doesn’t require trusting intermediaries for correctness (each intermediate node can’t steal funds thanks to HTLC enforcement), but you do trust them to forward payments. If a node on the route misbehaves or is down, the payment fails (but funds aren’t lost, just not delivered). Lightning’s use of HTLCs means if the network is congested or a channel closes, there may be a recovery period. In general, Lightning is secure given Bitcoin’s security and honest majority assumption for miners in case of punishment transactions.
Atomic Swaps: These are trustless exchanges typically between two parties. Each party is protected by cryptographic escrows (HTLCs) such that either both sides exchange or both get refunded. The security is straightforward: as long as both blockchains’ scripts work and one party can’t break the hash function or time lock, neither can cheat the other. It does assume that both parties act within the time constraints (if one disappears, the other can recover funds after the timelock). There’s no reliance on third parties, just the two traders and the two blockchains.

One advantage of SRG over atomic swaps is that assets preserve identity. In an atomic swap, you trade Asset A on Chain1 for Asset B on Chain2. You no longer have Asset A; you have some other asset. In SRG, you carry the same asset across – e.g. a token issued on Bitcoin becomes effectively a token on Ethereum, but it’s the same token managed via the protocol (similar to how the Leap concept did it natively without a bridge). That continuity eliminates exchange rate or liquidity issues; you’re not finding a counterparty, you’re moving your own asset. Lightning, on the other hand, usually is same-asset (Bitcoin to Bitcoin on a different node), or if cross-chain, it essentially is doing atomic swaps via channels (still requiring someone with a bidirectional channel between chains acting as a bridge).

Complexity and Ecosystem: Lightning requires an infrastructure of liquidity providers (nodes with capital) and maintaining channels. It’s operationally more complex for cross-chain if the chains are very different; generally Lightning cross-chain is limited to chains that can share HTLCs (like Bitcoin and Litecoin, or other similar networks). Also running a Lightning node has a learning curve and requires hot wallets, etc. SRG in contrast can be used by any client that speaks the protocol and tracks the chains; it doesn’t require always-on nodes except to the extent of monitoring blockchains (which can be done in a light client manner or via public block explorers if one chooses some trust there). Atomic swaps require finding a counterparty and coordinating the swap protocol steps. That can be user-unfriendly (order books, negotiation) and is one-time. By comparison, SRG transfers are one-way and don’t require finding someone else who wants the opposite asset; you just do it.

Scalability: Lightning is great for micro-transactions and high frequency, but every participant must lock capital in channels and the network may centralize into hubs. Atomic swaps are not scalable for frequent use (imagine doing 1000 atomic swaps – it’s heavy on chain). SRG is somewhere in between: more scalable than doing equivalent moves via atomic swaps because you can batch and because it’s the same asset (no need for two assets to be moved and multiple transactions), but not as scalable as Lightning for small payments. SRG shines for asset mobility and interoperability – moving assets or managing complex multi-chain states – which Lightning does not address (Lightning is primarily for Bitcoin payments, not for say moving an NFT from Ethereum to Bitcoin, which SRG could handle if both support the protocol).

Comparison Summary:

Lightning Network: near-instant transactions off-chain, extremely high throughput potential, great privacy for payments (not all transactions are publicly recorded, though channel closures are), but requires channels and online presence, not designed for multi-chain asset persistence (though cross-chain payment possible). Good for quick payments, not for transferring an asset identity across chains (Lightning transfers value, not the token/contract state itself).
Atomic Swaps: trustless cross-chain exchange of assets, no custody risk. However, relatively slow (needs on-chain confirmations), interactive, and each swap is an isolated event – it doesn’t create a lasting connection between chains or continuous contract state. It’s suitable for trading one asset for another without a middleman, but not for, say, continuing to use an asset on another chain seamlessly.
State Relay Graph (our approach): Enables an asset to migrate across multiple blockchains while keeping a unified history, without centralized bridges. Security relies on underlying chains (no extra trust assumptions). Speed is limited by on-chain confirmation times, but this can be partially mitigated by the fact that only one transaction per hop is needed and possibly batched. Privacy is strong (no one sees details, plus mixing techniques can confound tracing). SRG’s unique strength is interoperability and rich state transfer: one can effectively utilize features of different chains (like moving an RGB token to Ethereum to interact with an ERC20 contract by wrapping it in a suitable interface, then maybe move to a faster chain for cheap transfers, etc.) all while the asset remains the “same” asset governed by the client-side validation rules.

From a security perspective, SRG avoids the massive honeypot risk of traditional bridges. Each transfer is user-controlled and assets are not pooled, so there isn’t a single vault that hackers can target. This is a major improvement in safety: bridgeless cross-chain transfers eliminate the central target that led to huge hacks. Lightning also doesn’t have central pools (funds are distributed in channels), though large hubs could be attacked or fail, and users might face routing issues. Atomic swaps likewise have no central storage risk.

To ground the comparison, consider a hypothetical scenario: You have a token issued on Bitcoin via RGB and you want to use it for something on Ethereum for a while, then possibly trade it via a DEX on another chain (say a future Kaspa DeFi), then hold it privately in Bitcoin again. With SRG, you can do this as follows: anchor move to Ethereum (one transaction each on BTC & ETH, wait for confirmation), interact on Ethereum (which might involve many operations on Ethereum that don’t concern Bitcoin anymore), then later anchor move to Kaspa (one tx on ETH, one on Kaspa), then perhaps anchor back to Bitcoin. Each move is a couple of on-chain transactions and fully decentralized. With Lightning, you couldn’t do this at all because Lightning can’t carry an RGB smart contract state into Ethereum’s environment – Lightning could only help if you had an equivalent asset on Ethereum’s network (like a pegged token) and channels set up, which is far-fetched in this case. Atomic swaps would allow you to trade your RGB Bitcoin token for an ERC-20 token maybe (if someone issued a mirror), but that’s a different asset entirely; you’d lose the original and get something else, and later you’d have to swap back. And each swap trade requires finding liquidity and doing the swap protocol with fees. Not practical for multi-hop usage.

Performance in Practice: In terms of throughput and cost, if the underlying chains have low throughput, SRG will inherit that limitation for each transfer. However, note that SRG transfers are infrequent per asset – you only move when necessary, not for every payment (unlike Lightning where every payment is an off-chain tx). So if an asset moved chain a few times a day, that’s just a few L1 transactions. This is not a huge load even on Bitcoin. The cost is the sum of fees on involved chains, which could be higher than a single chain transfer but arguably much lower risk than a failed trade or a hack. Also, SRG can take advantage of batching: many state transitions can be packed in one transaction (like transferring 50 tokens between various owners in one Bitcoin tx via commitments), amortizing costs.

Privacy Comparison: On privacy, Lightning transactions are not recorded on-chain (until channel close), so they are very private in that sense, though traffic analysis at the network layer is possible and channel balances can sometimes be inferred at open/close. SRG’s transactions are on-chain, but reveal minimal info (just cryptographic commitments). And with our CoinJoin integration, on-chain analysis is confounded. Atomic swaps reveal on-chain HTLCs which often are identifiable as swap transactions; one can often tell “these two addresses engaged in an atomic swap” by the presence of hashlocked contracts, which could then link those addresses. SRG’s anchors look like either normal outputs or at worst some data insertion; they don’t scream “swap happening” to the world, especially if hidden in standard-looking transactions (Taproot commitments, etc., can be made to look like any other payment).

In summary, our comparative evaluation indicates that SRG provides a versatile, secure, and privacy-preserving method for cross-chain asset transfer and state management, at the cost of some on-chain latency. It complements the Lightning Network rather than replacing it: Lightning is superb for fast off-chain payments, whereas SRG is suited for transferring asset ownership or state across chains, which Lightning doesn’t address. Compared to atomic swaps, SRG handles a broader use-case (moving the same asset vs swapping one asset for another) with similar trustless guarantees but more user-friendly continuous ownership. Table 1 (hypothetical, in text) summarizes these points:

Trust Model: All are non-custodial. SRG/Atomic: rely on chain consensus; Lightning: relies on network and honest enforcement of channel contracts.
Latency: Lightning – milliseconds to seconds (after channel open). SRG – one to two block confirmations (minutes). Atomic swap – multiple confirmations (tens of minutes potentially).
Throughput: Lightning – very high (off-chain). SRG – medium (on-chain but can batch). Atomic – low (each swap separate, on-chain).
Complexity: Lightning – needs channels and liquidity management; SRG – needs multi-chain wallet and possibly coordinating CoinJoins; Atomic – requires finding partners and handling timeouts manually or via protocols.
Privacy: Lightning – strong (off-chain, though some routing info leaks), SRG – strong (commitments + mixing, on-chain data doesn’t show specifics), Atomic – moderate (on-chain HTLCs can link addresses, amounts visible).
Use-case Fit: Lightning – microtransactions, frequent payments in one currency. SRG – asset mobility, multi-chain dApp interoperability, retaining asset identity. Atomic – exchanging one currency for another without intermediary.

Our experiments and theoretical analysis suggest that SRG can achieve secure cross-chain transfers with performance acceptable for many applications (e.g. moving assets to where liquidity or functionality is, not high-frequency but occasional moves). The added confirmation time is often a worthwhile trade for eliminating trust and vastly improving security compared to centralized bridges which might be faster but expose users to huge risks. Moreover, techniques like block header relays or light clients on target chains (as done in some protocols) could be combined with SRG to automate verification, albeit with some cost.

Next, we discuss future work, which includes potential improvements like zkSNARK-accelerated verification to compress long path proofs, recursive relay designs for multi-hop automation, and federation signaling for enhanced network coordination.

Future Work: Toward zk-Path Aggregation, Recursive Relay, and Federation Signaling

The State Relay Graph concept opens up numerous avenues for further research and development. We highlight a few promising directions:

Zero-Knowledge Path Aggregation: One limitation of the current design is that verifying a long history involves checking each link individually. With advanced zero-knowledge proof techniques, it may be possible to generate a succinct proof that an entire state graph path is valid without revealing its details. For example, using zk-SNARKs or STARKs, a prover (say the asset owner) could prove to a verifier (could be another user or even a smart contract) that “I have a valid RGB asset state that originates from a valid genesis and no double-spends occurred” without revealing the actual path or anchors. This could greatly enhance privacy and efficiency. Projects like zkBridge have already demonstrated using succinct proofs to verify cross-chain events in a scalable way. They show that with zk proofs, one can compress the verification of hundreds of block headers or transactions into a tiny proof that can be checked on-chain with minimal gas. Similarly, we envision a zkPath proof where an RGB client proves knowledge of a path linking an asset’s genesis to the current state and that all anchors on that path exist on their respective chains and adhere to single-use seal semantics. This could address scenarios where a user wants to convince someone of the asset’s legitimacy without exposing which chains it traveled or who owned it. It also could allow smart contracts on one chain to verify an RGB state from another chain trustlessly. For example, an Ethereum contract might accept an RGB asset deposit if given a zkSNARK proving that the asset exists on Bitcoin and is now assigned to this contract’s control (instead of having to run a full Bitcoin light client in Ethereum, which is infeasible directly). This approach is complex and requires further research in circuit design and proving system performance, but it aligns with the trend of trustless interop via zk-proofs.
Recursive Relay Mechanisms: Currently, each transfer is initiated by the asset owner. A future improvement could be recursive relay or delegated hops, where a chain itself (or a set of agents) helps forward the state. For instance, imagine a network of relay nodes (in the sense of participants who volunteer to help) who listen for anchored states on one chain and automatically trigger the corresponding anchor on another chain. This could create a fluid “routing” of assets akin to how packets are forwarded on the Internet. Importantly, this can be done without requiring trust if the relays only publish transactions that the asset owner pre-signed or authorized (e.g. the owner could embed a pre-signed Ethereum transaction in the Bitcoin commitment, which any relay can broadcast on Ethereum once the Bitcoin part is confirmed). The concept of recursive comes in if an asset might be directed through multiple intermediate chains or layer-2 networks automatically. For example, a user might define in their contract that “if asset not spent on Bitcoin for 100 blocks, it can be relayed to a fallback chain by anyone” to avoid inactivity or to reduce fees. Recursive relays could ensure assets find the most optimal chain (like moving from a busy chain to a cheaper sidechain when possible, then perhaps back). This touches on dynamic and autonomous behavior of assets – almost like state roaming. Implementing this safely would require careful design of the commitments and possibly script support (e.g. covenants that allow a third party to re-anchor an asset under certain conditions). It introduces some trust considerations (we must ensure a malicious relay can’t hijack the asset to the wrong place), likely by cryptographic conditions provided by the owner.
Federation Signaling: To improve coordination in a decentralized way, we could use federations or committees not for custody, but for signaling and indexing. A federation of nodes could run to index the state graph publicly (like an RGB block explorer) and even to signal upcoming cross-chain moves (to make coordination faster, like matching users for CoinJoins, etc.). Because SRG operates without a central server by design, bootstrapping a new client might require scanning potentially large blockchains for relevant anchors. Federations could alleviate that by providing an unauthenticated hint service: e.g., a set of servers that index all RGB anchors on various chains and let clients query by asset ID or public key. Since the ultimate verification is still done client-side with cryptography, these federations would not introduce trust in correctness (a lying index would be caught when the client tries to verify a fake path). They would simply make the network more user-friendly and efficient by reducing the need for each client to be full scanning all chains. Federation signaling might also involve notary functions: for instance, a federation could collectively attest to seeing a particular anchor (which might help in low-resource clients to trustlessly know which branch won in a conflict, though ideally SPV proofs handle that). This concept is similar to watchtowers in Lightning or consortiums that assist in interop protocols, but carefully used to not undermine decentralization. If compromised, they should not be able to steal anything or permanently mislead users, only maybe cause delay until the user’s own verification catches up.
Enhanced Schema and Compliance Logic: Future work could extend the compliance features. For example, integrate identity frameworks such as Decentralized Identifiers (DIDs) such that compliance can be automated (only if viewing key reveals a credential signed by some authority then allow transfer beyond some amount, etc.). Another direction is policy-enforced paths – an issuer could specify that their asset can only hop to certain whitelisted chains (for regulatory reasons), and clients would enforce that policy when verifying. This could be achieved via the contract’s schema including allowed anchor chains, or a requirement that each anchor include a proof of compliance (maybe a signature from a compliance oracle). While this introduces some central element, it could be optional per asset type for those who need it.
Integration with Layer-2s and Sidechains: We can explore making SRG compatible with evolving Bitcoin layer-2 protocols, such as Lightning (RGB is already working on Lightning integration for transfers on channels) and other sidechains or rollups. For instance, one could anchor an RGB state in a Lightning channel commitment (off-chain) and later anchor out – effectively giving the asset Lightning-like speed within a channel. Also, if rollups on Bitcoin become a reality or sidechains like RSK are used, SRG could treat them as just more anchor options. A complex scenario would be an asset moving from Bitcoin to a rollup, then to Ethereum via some bridge or direct SRG if Ethereum can read Bitcoin proofs (maybe via Rollup that posts on Ethereum). The possibilities grow – essentially SRG can be the unifying layer for multi-chain, multi-layer assets.
MEV and Front-running Resistance: Because SRG keeps data off-chain, it’s already resistant to MEV (miners can’t decode what the state commit means, so they can’t front-run based on it). Future work could maintain this as more complex cross-chain dApps are built. For example, if an asset moves to Ethereum to do a trade, one could use adapter contracts to ensure even that trade is hidden until execution (like using commit-reveal schemes). Ensuring that our cross-chain approach doesn’t inadvertently introduce new front-running vectors (like if a malicious actor sees a Bitcoin commit that says “will move to Ethereum”, they might try to anticipate and do something on Ethereum) might require minimal information leakage in commitments. So designing commit formats to be as uninformative as possible is a subtle but important area for future optimization.

In conclusion, SRG is a step toward a more interconnected and private blockchain ecosystem. By decoupling synchronization from verification, and enabling cross-chain state transfers without centralized relays, we preserve the spirit of client-side validation and extend RGB’s capabilities. The future work discussed above aims to further bolster SRG’s efficiency (through zk-proofs), automation (recursive relays), coordination (federation signaling), and compliance features. We anticipate that as blockchain interoperability becomes ever more critical, approaches like SRG will play a key role in avoiding the pitfalls of centralized bridges and instead leveraging cryptography and clever protocols to achieve a trust-minimized multi-chain reality.

Conclusion

We have presented State Relay Graph (SRG) as an innovative extension to the RGB protocol, arguing that RGB should not remain constrained by tightly coupled synchronization and verification. By decoupling these aspects, SRG allows state transfers to occur asynchronously and trustlessly, without requiring participants to be online at the same time or to rely on any centralized service. We demonstrated how SRG can accelerate state propagation (by removing waiting for acknowledgements), prevent double-spending inherently (through one-time anchors and single-use seals), incorporate TTL for timely finality, and overall improve the security of cross-chain operations by eliminating custodial bridges.

Our design enables constructing a state graph of asset movements across multiple anchor blockchains (Bitcoin, Kaspa, “Tondi”, Ethereum, etc.), which each client can verify independently. We showed that this approach maintains – and even enhances – privacy: default observers learn nothing beyond cryptographic commits, and with the integration of CoinJoin/PayJoin the link between successive states is obscured. At the same time, SRG supports compliance via optional viewing keys, allowing selective transparency when required. In our comparative analysis, we found that SRG complements existing solutions: it provides unique benefits for cross-chain asset continuity that neither Lightning (focused on payments) nor atomic swaps (one-off exchanges) fully address, all while avoiding the central points of failure that have plagued conventional bridges.

The SRG approach underscores a broader principle: by using the blockchain only as a commitment layer and performing validation at the client side, we can achieve scalability and confidentiality without sacrificing security. Bitcoin and other base chains serve as robust “couriers” for our state commitments (ensuring order and preventing double spends), but they need not process the contract logic or know the asset details. This paradigm, pioneered by RGB and extended here, could be a blueprint for future multi-chain interoperability protocols that emphasize user sovereignty and privacy.

In summary, we conclude that RGB should evolve beyond synchronous, coupled designs and embrace architectures like SRG. Doing so will prepare RGB-based assets and contracts for a multi-chain world – one where users can move freely among chains to capitalize on each network’s strengths (security, speed, functionality) without ever giving up control or privacy. SRG can dramatically reduce the need to trust third-party relays or custodians, thereby minimizing systemic risks. It retains the core ethos of Bitcoin and RGB (decentralization, censorship-resistance, fungibility) while adding the flexibility that modern decentralized finance demands.

We believe our work provides a compelling argument and technical foundation for this evolution. As we look ahead, implementing SRG and testing it in real-world scenarios (perhaps on testnets or via prototypes) will be crucial. We anticipate valuable feedback and iterations from the community. Ultimately, by decoupling verification from synchronization and embracing a graph-based state model, the RGB ecosystem can achieve a new level of agility – one that answers the question posed at the outset: Can we extend RGB across multiple anchor chains without undermining its privacy? Our answer is a resounding yes – not only can it be done without damaging privacy, but with SRG’s approach, privacy can even be strengthened in the process, all while ensuring trustless integrity and improving performance.

Decoupling Synchronization and Verification in RGB: The State Relay Graph (SRG) for Secure Cross‑Chain Asset Transfers