I. Reflections on the BTC + RGB + LN Model: Limitations and Challenges

The original vision of the RGB protocol was to achieve high scalability for smart assets within the Bitcoin main chain + Lightning Network framework. However, through community practice, Avato Labs has cautiously reflected on the popular "BTC main chain + RGB + Lightning Network (LN)" model, identifying some structural bottlenecks:

1.1 Asymmetric Trust Structure:

In theory, both RGB and Lightning Network claim point-to-point trust minimization, but in practice, users end up needing to trust entities at two levels:

First, state indexing services in RGB protocol. Since RGB asset states propagate off-chain, users often rely on third-party indexers (stash/indexer) to obtain proofs of asset transfers sent to them. If indexers are unreliable, users may miss latest states or even face double-spending.
Second, channels and routing nodes in LN. LN payments require each node in the path to relay funds and stay online; users must trust relay nodes in the path not to maliciously intercept or misbehave (though with punishment mechanisms, but premised on users or watchtowers timely detecting and submitting evidence). Meanwhile, Lightning's payment paths and success are opaque to users, who can only hope for good connections and honesty from large nodes in the network.

As a result, under the BTC + RGB + LN model, user transactions are actually in a black box: RGB state propagation not publicly auditable, LN payment paths not externally verifiable. This deviates from the original intent of "client-side validation"—users must additionally trust some services or nodes rather than fully self-verify.

1.2 Limited State Flow Mechanism:

RGB currently mainly supports token-type asset transfers, lacking effective state broadcasting and synchronization for more complex contracts (e.g., governance voting, on-chain identity, AMM trading states). Each RGB contract state change can only be exchanged point-to-point, lacking global scheduling. For example, a decentralized exchange (DEX) or lending protocol on RGB cannot easily broadcast price updates or liquidation signals to all relevant participants because RGB has no event notification bus or on-chain contracts for scheduling. This leads to complex business logic relying on additional application-layer means for notification or processing, which is very inelegant and error-prone.

In simple terms, RGB implements point-like asset transfers on the BTC chain, but attempting cross-asset interactions or complex logic makes the existing design inadequate. This is not an issue with RGB's philosophy but a limitation of Bitcoin's single-chain environment: no built-in broadcasting mechanism, all complex interactions either fallback to LN channels or rely on centralized servers.

1.3 Lightning Network's Centralization Trend:

LN is hoped to be Bitcoin's high-throughput payment layer, but in reality, its topology is gradually showing a "super node" concentration trend. Studies show that Lightning's majority channels and capacity are concentrating toward a few large routing nodes. Situations where 10% of nodes control most network capacity have emerged. This means decentralization is declining, with high network dependence on these hubs. Once a few large nodes fail, it could cause systemic congestion or even fund stuck. BitMEX research team pointed out as early as 2018: "The network will concentrate around a few large hubs because it's the most efficient model. This centralization increases the risk of systemic channel failures." LN's centralization trend undoubtedly weakens its censorship resistance and reliability, contrary to the original intent of building a global open payment network.

1.4 User Experience Falls Short:

The user threshold under the BTC + RGB + LN model is extremely high. Users need to simultaneously handle: managing UTXOs and anchoring transactions on Bitcoin chain, maintaining LN channel balances and worrying about channel capacity, managing stash and signature proofs with RGB wallet... For ordinary users, this is multiple layers of complexity stacked.

Specific manifestations include:

Opening and maintaining LN channels require certain technical knowledge (adjusting channel capacity, fees, node connections, etc.), complex operations. Novice users find it hard to run a Lightning node directly to participate in the network.
RGB asset reception requires waiting for the sender to provide the state proofs; if missed or indexer service abnormal, manual retry may be needed.
Simultaneously managing on-chain BTC balances and in-channel BTC balances, sometimes handling on-chain settlements (closing channels), operations cumbersome and confusing.
Multi-signature, backup, offline storage, and other wallet security matters also add difficulty.

As a result, most ordinary users cannot directly use pure self-custodial LN + RGB services, either giving up or falling back to custodial wallets or centralized services. Many Lightning network users actually use services like Strike, Wallet of Satoshi, sacrificing decentralization for usability. This indicates that achieving Web2-like smooth user experience under the existing model is very difficult, still quite a distance from mass ordinary user adoption.

1.5 Lack of Security Rollback Mechanism:

RGB protocol currently relies mainly on local prevention and post-punishment for anti-double-spending. For example, if Alice attempts to transfer the same asset to Bob and Charlie twice (double-spend), only one will be first accepted by the counterparty and anchored on-chain successfully; the other will be invalid due to UTXO spent. But when the process happens, the protocol itself has no global consensus to arbitrate which one stands—entirely depending on whether Alice broadcasts the commitment correctly, and whether Bob/Charlie prudently validate. In this case, once parallel conflicts occur (especially with multiple recipients, across multiple channels), RGB protocol has no consistency algorithm like blockchain to rollback invalid states; each wallet handles independently, and subsequent transactions discover issues when rejecting. In complex application scenarios, this lack of centralized mediation mechanism may lead to user confusion or asset loss risks. In other words, RGB currently lacks a final arbitration layer like blockchain: when state conflicts or protocol attacks occur, no consensus process to "converge" to a correct state.

Based on the above observations, we believe: the current BTC + RGB + LN architecture is more like a combination of experimental technologies, workable in small-scale, point-to-point scenarios, but bearing global commercial deployment still has many uncertainties and limitations. If forced to build large-scale Web3 services with it, may encounter weakened decentralization, poor user experience, or even hard-to-detect security issues timely.

II. Avato Labs' Solution: Tondi + RGBX + SRG Technology Stack

To address the above bottlenecks, Avato Labs proposes a self-developed three-layer architecture, corresponding to the main chain layer, contract layer, and state propagation layer, namely Tondi + RGBX + SRG. This technology stack aims to reshape the mode of on-chain settlement and off-chain contract execution from the bottom up, achieving unity of high performance, high privacy, and strong availability:

🌀 Tondi Main Chain: High-performance GhostDAG + PoW main chain, focusing on security neutrality and concurrent throughput, positioned as the "new generation currency layer".
🔁 RGBX Contract Layer: Engineering-level reconstruction of the RGB protocol, achieving off-chain state snapshots, concurrent execution, and multi-chain anchoring, providing a universal client-side contract platform.
📡 SRG State Relay Graph: A brand-new off-chain state broadcasting network, replacing Lightning's point-to-point channel, providing low-latency, high-privacy, and verifiable state transmission.

The three each perform their duties yet closely cooperate, forming a complete high-performance blockchain stack. Below, their key points are elaborated respectively.

2.1 Tondi Chain: Returning to Satoshi's Paradigm, Elevating Performance Boundaries

Tondi main chain's design philosophy is: letting "digital gold" have modern usability. It returns to Satoshi's original UTXO + PoW model to ensure security and decentralization, while significantly enhancing speed and functionality through technological innovation:

GhostDAG Parallel Consensus: Tondi adopts the proven feasible GhostDAG protocol, achieving high parallel block production and fast finality. Compared to traditional longest chain consensus, GhostDAG can safely accept parallel blocks, thereby significantly increasing throughput without losing security. This means Tondi's blocks per second far exceed Bitcoin's, while each block can be relatively small, making transaction confirmations as fast as swiping a card.
Full-Chain BLAKE3 Hashing: The on-chain hash algorithm uniformly adopts high-performance BLAKE3, rather than Bitcoin's SHA-256. This enhances hash computation speed and efficiency under the premise of security, more suitable for high-TPS scenarios (BLAKE3 is one of the fastest and collision-resistant algorithms among modern hashes).
- Note! : An exception is made for Schnorr signatures, which continue to use SHA-256 to align with Bitcoin's implementation. This ensures seamless liquidity interoperability between the two ecosystems, as Tondi and Bitcoin do not exist in a competitive relationship but rather complement each other for broader adoption and cross-chain functionality.
Taproot-Only + Simplified Scripts: Tondi only supports Taproot outputs and TapScript, eliminating old ScriptSig script complexity. This "slimming" ensures all transaction validation logic is simple and unified, easier to optimize for hardware acceleration. Tondi also removes some unnecessary script operators, making script execution more efficient and secure (while retaining necessary verification operations like OP_CHECKSIG).
Client-Side Validation as First-Class Citizen: Tondi natively supports the existence of state commitments in block structures and consensus rules. That is, blocks can include special fields or accommodate batch commitment data from RGB and other protocols according to specific rules, ensuring these commitments do not affect UTXO consensus but can be validated. This is like directly incorporating RGB's needs into chain design, avoiding the expedient of "stuffing data into Bitcoin OP_RETURN," instead providing formal support. Thus, when users submit RGB commitments, miners process as usual, but full nodes perform format checks on commitment fields, ensuring no malicious data disrupts chain consistency.
Verifiable Governance Upgrades: Tondi adopts an "off-chain voting + on-chain commitment" parameter governance mechanism. Specifically, any protocol upgrade proposal first generates results through off-chain signed voting by coin holders, then miners include the result's hash commitment in blocks. Once committed on-chain, it means the community has passed this upgrade, and nodes execute changes accordingly. The entire process is publicly verifiable and cannot be unilaterally tampered with, avoiding possible centralized intervention or closed-door decisions in traditional on-chain governance. More importantly, no hot code upgrades—all protocol changes are publicized through verifiable programs before application, any user can audit upgrade content and signed voting results. This ensures Tondi's rule evolution is transparent and credible.
Separated Issuance and Fee Models: Tondi isolates the issuance of base token TND from the fee mechanism. TND's currency issuance follows a fixed cap or progressive deflation strategy (specific model detailed in whitepaper), ensuring long-term scarcity and anti-inflation. Transaction fees use another internal pricing unit, dynamically adjusted based on network load. But these fees do not directly mint TND or pay miners, instead entering a protocol fee pool, exchanged/destroyed periodically through governance decisions. This decouples "monetary policy" and "fee economy": base currency supply does not fluctuate wildly with TPS changes, fees won't directly increase inflation pressure. At the same time, the protocol layer can offset block rewards by destroying part of fees, forming sustained intrinsic value support.
Compliance Hooks and Audit Interfaces: Considering real-world regulatory needs, Tondi designs pluggable compliance interfaces without compromising privacy. For example, transactions can optionally include an encrypted "travel rule tag" (recording hashed regulated IDs of sender/receiver), readable only by regulatory bodies with specific decryption keys, for meeting cross-border transfer reporting requirements. Similarly, institutions issuing stablecoins and other regulated assets can use Tondi's templates to add zero-knowledge proofs in anchoring transactions, proving compliance with KYC/AML without exposing user identities. All these compliance fields are hidden by default to ordinary nodes (e.g., treated as random bytes), used only when needed and authorized. Through this mechanism, Tondi achieves on-chain transactions remaining private for ordinary people, but auditable for those with proper permissions.

User Experience : Tondi strives to shed the stereotypical impression of traditional PoW chains being "slow and hard to use," providing experiences close to internet applications through various means:

Lightning-Fast Sync: Due to no global state, light clients can verify on-chain transactions with just block headers and minimal Merkle proofs. Combined with Tondi's fast block production, users can complete wallet sync in seconds, no long waits. We also implement verifiable snapshots: trusted multi-parties periodically provide compressed UTXO set snapshots of the chain; users download and validate with a few blocks, speeding up by orders of magnitude compared to calculating from genesis.
Standardized APIs: Tondi provides REST/GraphQL interfaces for enterprises and developers, along with validation-supporting SDK components, facilitating quick integration of on-chain transfers and commitment submissions. No need for deep understanding of blockchain underlying to develop business applications. Additionally, gateways docking traditional databases/message queues for real-time acquisition of on-chain state changes, embracing Web3 in the most familiar way.
Developer Extension Friendly: Through Lex Schema (Tondi's custom contract schema language) and embedded AluVM (lightweight computational virtual machine, compatible with RGB's AluVM), developers can define custom validation rules or constraints, expanding functionality without violating the client-side validation paradigm. This flexibility allows Tondi to serve not only preset RGB protocols but also adapt to future other innovative protocol needs.

In summary, Tondi pursues high performance while always upholding security neutrality and user sovereignty. It does not sacrifice decentralization or introduce trusted third parties for speed but achieves the best of both worlds through technological innovation. For Asia and even global clearing and payment infrastructure, Tondi provides a new choice not relying on traditional strong centers yet integrable into compliance frameworks. This is not just performance enhancement but a persistence in reclaiming cryptographic origins for financial autonomy and institutional neutrality.

2.2 SRG State Relay Graph: Reshaping Off-Chain Networks

SRG (State Relay Graph) is Avato Labs' new design for off-chain state transmission, aiming to replace Lightning Network's point-to-point channel model, providing a full-network broadcasting + verifiable state update network. Its emergence stems from this insight: if we don't pre-lock channel funds but let all off-chain transactions broadcast and record signatures on a shared network, we can simultaneously avoid channel capacity limits and routing instability issues.

SRG's key idea is to treat each off-chain state change as a snapshot, containing the hash of state update content, sequence number, and related signature set. All snapshots are broadcast network-wide, received by several relay nodes, then signed to confirm receipt (equivalent to witnessing). Then snapshots form reference relationships: later snapshots reference previous snapshot hashes, thus each state thread is linked, while converging through references to form a directed graph. This structure is similar to blockchain but doesn't rely on proof-of-work, instead guaranteed by signature witnessing for order and validity.

To prevent double-spending or conflicts, SRG sets a monotonically increasing sequence number for each state (e.g., an asset, a balance). Each update increments the sequence by 1 and includes the previous snapshot hash. If someone attempts to publish two different updates in parallel (same sequence but different content), network observers (Auditor/Challenger roles) can easily detect: because two conflicting snapshots will appear, referencing the same previous. In this case, observers can construct a fraud proof, submitting conflicting snapshot information to Tondi main chain for arbitration. Contracts on Tondi chain (or predefined validation rules) will verify the conflict and declare one update invalid or both invalid (depending on rules). Thus, through the main chain's final ruling, erroneous states on SRG network can be revoked or marked invalid, ensuring eventual consistency. This is equivalent to introducing a "timely detection - on-chain arbitration" mechanism off-chain, remedying LN's lack of centralized rollback defect.

SRG components include:

Emitter/Executor (Emitter): The party initiating state changes (e.g., payment sender, contract caller). They execute actual state updates and generate corresponding snapshots.
Relayer/Watcher (Relayer): Nodes forwarding snapshots in the network, optionally storing snapshots as data availability layer. Upon receiving snapshots, Relayers sign to prove they've seen and agree to forward (unless format invalid or obviously bad). These signatures can be collected by subsequent validators to prove "enough nodes witnessed this snapshot."
Auditor/Challenger (Auditor): Specially monitor snapshot legitimacy on the network. Upon detecting double-spend conflicts or illegal updates (e.g., abnormal sequence jumps), immediately construct fraud proofs and submit relevant evidence to the main chain. Auditors can also be played by recipients to protect their interests.
Anchor Service: Periodically submit SRG network snapshot summaries to on-chain. Similar to Rollup batch submission—e.g., every N minutes, pack Merkle roots of recent N snapshots into a Tondi transaction. Thus, even without conflicts needing arbitration, on-chain saves latest state roots for offline or new joining nodes to verify history later.

SRG's data structure can be summarized as: maintain a signed snapshot chain for each asset/state, while all chains form a state directed graph through references, with the graph's global hash (root) anchored on-chain. When Alice pays Bob, Alice as Emitter creates a new snapshot recording "pay X to Bob, balance decrease," referencing her previous snapshot hash, sequence +1, then signs and broadcasts. Network Relayers receive and sign to forward; Bob receives and validates the snapshot, considering himself paid, and Bob can act as Relayer to continue forwarding or at least retain for reference. If Alice attempts to pay Charlie the same (double-spend), she generates another snapshot referencing the same previous but different recipient. The network will eventually anchor the existence of two conflicting snapshots; Auditor detects and submits fraud proof on-chain, chain rules may rule the first arriving valid, later invalid. Charlie can't get valid signature sets because some nodes refuse to forward conflicting snapshots. After a period, the on-chain anchored state root can only include Alice->Bob's.

SRG's advantages:

No Need for Pairwise Channel Opening: Any parties in the network can pay each other via broadcasting, no pre-locking funds to establish channels, no unfindable route situations, because the whole network is the channel. This lowers participation threshold, also eliminates channel capacity limits.
Low Latency and High Success Rate: Since no layer-by-layer routing probing like LN, as long as network connectivity is normal, broadcasting quickly reaches the counterparty, and unless double-spend, almost no "failure." Each payment only undergoes network propagation delay, nearly achieving second-level or sub-second arrival.
Stronger Privacy: SRG's broadcasting is point-to-multipoint encrypted. Although relay nodes witness snapshots, snapshots only contain hashes and signature sets, no specific transaction content (specific payment amounts, asset IDs, etc., can be processed via encryption or one-way hashing). Externals only see Alice published an update, content invisible. Differs from LN onion routing in privacy focus—LN hides amounts transferred by intermediate nodes, SRG hides transaction details themselves. Each has pros and cons, but SRG at least avoids LN's partial transaction inference via graph analysis due to few paths.
Controllable Double-Spending: LN double-spending relies on watchtower monitoring, and once channel closed, no punishment chance. SRG, upon conflict discovery, immediately handles on-chain, no missing time window issue. Moreover, being a broadcast network, conflicts are easier to detect (because both conflicting snapshots diffuse and get compared). Additionally, since broadcast, conflicts are harder to conceal.
Global Consistency View: Through periodic anchoring, SRG makes the entire network state quickly acquirable by new joining nodes via on-chain info, no need to trust counterparties' provided channel snapshots like LN. Somewhat similar to blockchain's friendliness to new nodes: no need to ask others for balances one by one, just look at blocks.

It should be noted that SRG is not a purely cost-free solution—it needs some infrastructure support, like enough Relayer nodes and on-chain anchoring fees. But considering SRG batch anchoring with adjustable frequency, this cost is much lower than LN's per open/close on-chain. Relayers don't need massive storage, just cache snapshots for a certain time for signing; even offline doesn't affect fund security (only reduces signature witness count).

SRG can be seen as an upgraded version of Lightning Network: elevating from "multi-person multi-channel mesh network" to "multi-person integrated broadcast network." It borrows some blockchain consensus ideas (like directed acyclic graph and conflict arbitration) yet retains off-chain transaction efficiency and privacy. In the future, SRG can be used not only for payments but also for more general off-chain state synchronization (e.g., cross-chain bridge state transmission, NFT offline exchanges), a universal Layer 2 communication backbone. SRG has currently completed proof-of-concept internally at Avato Labs, implementing basic snapshot broadcasting, signature aggregation, and fraud proof on-chain validation. Next, it will further integrate and test with Tondi and RGBX.

2.3 RGBX: Reconstruction and Upgrade of RGB Protocol

RGBX is a "modern reconstruction" of the RGB protocol in software implementation and architecture. It does not change RGB protocol's core logic and commitment structures but significantly improves performance and functionality of existing implementations (like rgb-node) at the engineering level to adapt to Tondi main chain and SRG network needs.

Original RGB has some issues: strict encoding format low efficiency, single-thread processing limiting performance, state storage relying on external indexing services, non-unified development interfaces, etc. RGBX addresses these with the following improvements:

Parallel Parsing and Validation: RGBX abandons serial traversal in strict encoding, adopting zero-copy parsing and multi-thread validation pipelines. That is, upon receiving a set of RGB state change data, decode each part in parallel and validate multiple rules simultaneously. One bottleneck of client-side validation is needing to validate full history, but through parallelization, RGBX speeds up single-asset full history validation by 10-30 times (per internal tests). This means even if an asset has thousands of transfers, a phone can complete full history validity check in seconds.
Verifiable State Snapshots: RGBX introduces state snapshot concept, recording aggregated state hash at a certain moment, stored via Merkle-DAG cache. Somewhat like blockchain state roots but maintained locally by users. When needing fast sync, users just get latest snapshot and incremental changes since last sync, much faster than fully replaying all history. Each snapshot has verifiable proofs, ensuring evolved from a series of valid states, no fear of malicious nodes providing fake states.
Embedded Index Storage: RGBX sinks the stash/indexer functions originally needing nodes or servers to local. Wallets build in lightweight embedded databases (like SQLite or RocksDB), directly storing UTXOs and states of assets users care about. Thus, users master their asset changes without trusting third-party indexing services. At the same time, through decentralized index discovery protocols (similar to DHT), users can get missed state updates from other peer-to-peer nodes upon going online, reducing risks of relying on central servers.
Unified Build-Sign Flow: In traditional RGB implementations, generating commitment PSBT, signing it, and publishing on-chain often require multiple tools, cumbersome process. RGBX provides integrated WASM SDK encapsulation, unifying build, sign, validate flows. Wallet developers just call a high-level API (e.g., create_and_sign_transfer(dest, asset, amount)), SDK internally completes RGB state update, associates anchoring UTXO, generates PSBT and calls signing key, returns signed final transaction. This greatly lowers RGB integration threshold, also avoids signing inconveniences due to wallet and RGB node separation.
Unified Descriptor/Seal/Anchor Abstraction: RGBX highly abstracts commitment generation, single-use seal outputs, and anchoring transactions, making them transparent to developers. This means whether issuing stablecoins (token type), creating DAO voting (smart contract type), or deploying decentralized identities (certificate type), the calling interfaces differ little for developers. All these different uses are treated internally as "state transfers" in RGBX, uniformly processed through create-sign-broadcast three stages. Thus, once a team familiarizes with RGBX API, they can quickly build multiple types of applications on it without delving into each contract's details.
Multi-Chain Anchoring Support: RGBX's most breakthrough feature is anchoring a set of contract states to multiple underlying chains. Through Anchor Adapter module, RGBX flexibly encapsulates commitment data based on different target chains. For example:
- On Bitcoin chain, commitments written as Taproot internal keys or OP_RETURN forms in transaction outputs;
- On Tondi chain, commitments can be directly recorded using its special fields (since Tondi natively supports commitment fields, higher efficiency);
- On Kaspa chain, since no scripts, put commitments in transaction metadata;
- On Ethereum and other account chains, accommodate commitments via calldata or special precompiled contracts.

Corresponding Proof Translator module normalizes light client proofs from different chains. E.g., BTC needs SPV proofs (block headers + Merkle paths), Ethereum needs log proofs, Kaspa needs DAG inclusion proofs, etc. Proof Translator converts them to unified interfaces, so RGBX validating an anchor doesn't care which chain it's from, just calls validation interface. In other words, RGBX supports BTC, Tondi, Kaspa with one code set, even ETH in future, greatly expanding RGB's applicability.

Seamless SRG Integration: RGBX tightly integrates with the aforementioned SRG network. Whenever RGBX client executes a state change (e.g., Alice transfers some asset to Bob), besides generating on-chain commitment transaction, automatically generates corresponding SRG snapshot and broadcasts. In SRG network, this snapshot carries asset ID, transfer amount, etc. (encrypted or hashed for privacy), Bob's wallet if online receives and validates the snapshot. Even if Bob offline then, can later get this snapshot from SRG storage nodes. After snapshot witnessed by Relayers, its hash also included in next anchoring submission's graph root. Thus the whole chain forms: RGBX state update → SRG broadcast snapshot → Tondi anchor commitment. Anyone wanting to validate an RGB asset transfer can not only check Tondi chain's commitment transaction but also require counterparty to provide corresponding SRG path proof (including snapshot and Relayer signatures). This confirms: the commitment's off-chain state indeed fulfilled some asset transfer from Alice to Bob, and SRG network recorded no conflicts.

Through the above integration, RGBX achieves previously unimaginable features: one off-chain contract protocol, any on-chain settlement, any off-chain broadcasting, truly cross-chain, cross-layer flexible deployment. For example, a DAO governance token can mainly anchor on Tondi for high performance, while anchoring a copy to BTC chain for important decisions to ensure long-term secure records; user mobile wallets default to tracking only Tondi chain commitments for speed, while backend services or audit nodes periodically check BTC chain for consistency confirmation. All this is seamless to RGB users, but provides higher freedom and security redundancy for professional institutions.

RGBX has shown impressive results in experimental environments: single-asset validation speed improved by an order of magnitude over RGB core, mobile first sync shortened from past minutes to seconds. At the same time, RGBX maintains backward compatibility in design—for users still using old RGB protocol, RGBX can provide data import and compatibility modes; in case new mechanisms have issues, users can choose to fallback to BTC chain anchoring for security. These measures make the upgrade process stable and controllable.

2.4 User Experience as Core

Avato Labs firmly believes: blockchain technology without good user experience has no vitality. Thus, Tondi + RGBX + SRG's ultimate goal is to make ordinary users hardly feel blockchain's existence yet enjoy the trust and autonomy blockchain brings. This manifests as:

Hiding Complexity: At the frontend, users see familiar Web2-style operations. For example, when transferring, input counterparty account (readable alias or scan code), input amount, click send, complete payment; when voting, click option to confirm. All backend happenings (select route, find channel, generate commitment, submit anchor, broadcast snapshot) are automatically completed by system. Users don't need to understand concepts like UTXO, hash, channel balance. Just like using payment Apps now, no need to understand TCP/IP protocols.
Progressive Information Disclosure: By default, wallets won't show technical details to users, but for advanced users, provide options like "view proof" or "on-chain details." E.g., users can view a certain asset transfer's on-chain anchoring transaction hash when needed, or export a zero-knowledge proof for some asset holding to prove authenticity to third parties. This progressive disclosure ensures ordinary people not overwhelmed by too much info, while pro users have channels to access details.
Seamless Chain Switching: With RGBX multi-chain anchoring capability, users can even cross-chain use assets without perception. For example, a stablecoin supports both BTC and Tondi chains, wallet automatically chooses optimal path (e.g., large amounts via BTC for security, small high-frequency via Tondi to save fees). All this is transparent to users, "on what chain" no longer a concern for users, just like using email without caring about routers.
Second-Level Sync and Recovery: New device installs wallet, imports mnemonic, leveraging Tondi's lightweight sync and RGBX snapshots, loads all asset balances and history in seconds, no waiting for lengthy on-chain scans or syncs. This solves the long-troubling "wallet cold start" experience issue for blockchain users.
Outstanding Reliability: Through SRG conflict arbitration and Tondi chain's robust design, users basically won't encounter asset loss or transaction stuck. Even if network instability or temporary conflicts, system auto-handles (e.g., delay submission or reselect path), ultimately guaranteed consistent by on-chain. For users, experience similar to using bank App transfers—either success or failure refund, but no "uncertain state."
Secure Autonomy with User Choice: Users still fully control their private keys and assets, no intermediate party can access funds unless actively authorized. This contrasts sharply with many current Lightning wallets being actually custodial. Tondi + RGBX + SRG stack lowers self-custody threshold, obtaining near-equivalent convenience without trusting service providers. This is where blockchain value truly shines.
Compliance-Friendly Mode: For scenarios needing compliance, users also have opt-in rights. For example, an enterprise wallet can choose to enable regulatory view keys, then its transactions generate encrypted records for regulators. But ordinary users default off, fully anonymous. Thus meeting requirements in different environments without forcing all to accept uniform scrutiny. Technically, Tondi provides interfaces for these functions, while actual enabling is decided by upper-layer applications, fully respecting users and business choices.

In short, under Tondi + RGBX + SRG combination, we are striving to create a Web2-level smooth, Web3-level trustworthy user experience paradigm. It hides blockchain's edges yet retains blockchain's core values. We believe this is the key step for ordinary masses to truly embrace Web3. After all, most users don't care how cool blockchain tech is; they care: what can I do with it, is it easy to use, is it safe. The entire Tondi stack is advancing in this direction.

III. Avato Labs' Stance and Outlook

Facing recent disputes in RGB community and L2 architecture choices, Avato Labs chooses a path of independent autonomy and open collaboration:

First, we will not join RGB Protocol Association or RGB Open Alliance, nor accept their current governance and technical route path dependencies. As mentioned earlier, we believe Bitcoin single-chain + LN mode has structural limitations, and RGB governance's closed tendencies contradict open-source spirit. Thus, we will persist in independent thinking and development, not coerced by any existing political or commercial forces.

At the same time, we will collaborate with globally influential academic and industrial forces. We believe a truly future-oriented blockchain infrastructure needs both grassroots open-source community vitality and mainstream institutions' participation to drive large-scale application landing.

Our principles are very clear: open ecosystem, cross-chain fusion, people-oriented. Tondi + RGBX + SRG technology stack will be open-sourced, welcoming global developers to co-build; support multi-chain anchoring, not tied to any public chain ideology, but pursuing optimal technical solutions; most critically, user experience and actual needs oriented, no conceptual hype castles in the air, but solving real existing problems.

Finally, concluding with our team's words: Tondi with DAG skeleton, Taproot skin, RGB soul, unlocks the future currency layer of performance and privacy. We believe, in an era of increasingly digitized value and identity, the technical path Tondi represents can truly balance decentralization and compliance, privacy and efficiency, bringing blockchain into the convergence of mainstream finance and social. We sincerely invite visionary partners to join us, jointly advancing this future-oriented base chain to the world.

Tondi + RGBX + SRG Technology Stack Analysis