II. Layer 2: RGB on Tondi

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 that fundamentally limit its potential for mass adoption and enterprise deployment.

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. This introduces a critical vulnerability: the very infrastructure meant to enable trustless validation becomes itself a trust dependency.

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, premised on users or watchtowers timely detecting and submitting evidence). Meanwhile, Lightning's payment paths and success rates 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 is not publicly auditable, LN payment paths are 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.

The asymmetric trust structure manifests in daily operations:

Users cannot independently verify all asset states without relying on indexers
Payment success depends on intermediaries whose behavior cannot be fully validated
Watchtowers become necessary trust dependencies for offline security
The promise of "trustless" operation exists only in theory, not in practice

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

The fundamental limitation: 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 inelegant, error-prone, and introduces centralization vectors.

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 means all complex interactions either fallback to LN channels or rely on centralized servers.

Real-world implications:

Multi-party state coordination requires centralized coordinators
Price discovery mechanisms cannot operate efficiently
Atomic swaps across multiple assets become prohibitively complex
Smart contract composability remains theoretical rather than practical

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 lockup. The 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.

The economic forces driving centralization:

Larger nodes achieve better routing efficiency and capture more fees
Users rationally choose to open channels with well-connected hubs
Network effects create winner-take-all dynamics
Smaller nodes become economically unviable, further accelerating concentration

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:

Channel Management Complexity: Opening and maintaining LN channels require certain technical knowledge (adjusting channel capacity, fees, node connections, etc.), with complex operations. Novice users find it hard to run a Lightning node directly to participate in the network.
RGB State Reception Issues: RGB asset reception requires waiting for the sender to provide the state proofs; if missed or indexer service abnormal, manual retry may be needed.
Balance Fragmentation: Simultaneously managing on-chain BTC balances and in-channel BTC balances, sometimes handling on-chain settlements (closing channels), operations cumbersome and confusing.
Security Burden: Multi-signature, backup, offline storage, and other wallet security matters add significant 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.

The critical vulnerability: When the process happens, the protocol itself has no global consensus to arbitrate which transaction 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, there is no consensus process to "converge" to a correct state.

Summary of Structural Challenges

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, organizations may encounter:

Weakened decentralization due to infrastructure dependencies
Poor user experience preventing mass adoption
Hard-to-detect security issues that manifest only at scale
Economic centralization that undermines the core value proposition

II. Avato Labs' Solution: Tondi + RGBX + Atlas 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: Tondi + RGBX + Atlas.

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
📡 Atlas State Relay Graph: A brand-new off-chain state broadcasting network, replacing Lightning's point-to-point channel model, providing low-latency, high-privacy, and verifiable state transmission

The three components each perform their duties yet closely cooperate, forming a complete high-performance blockchain stack. Below, we elaborate their key features 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.

Core Performance Innovations

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. The protocol maintains security by ordering parallel blocks through a sophisticated DAG topology that preserves Nakamoto consensus properties while enabling unprecedented throughput.

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). This design choice dramatically reduces the attack surface while improving validation performance.

Native Protocol Features

Client-Side Validation as First-Class Citizen

Tondi natively supports the existence of state commitments in block structures and consensus rules. 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. 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
Miners include the result's hash commitment in blocks
Once committed on-chain, 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
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
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.

Enhanced 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 dock 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.

Design Philosophy Summary

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 Atlas State Relay Graph: Reshaping Off-Chain Networks

Atlas (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.

The Core Insight

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.

Architectural Design

Atlas's key idea is to treat each off-chain state change as a snapshot, containing:

The hash of state update content
Sequence number
Related signature set

All snapshots are broadcast network-wide, received by several relay nodes, then signed to confirm receipt (equivalent to witnessing). 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.

Conflict Resolution Mechanism

To prevent double-spending or conflicts, Atlas 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
Two conflicting snapshots will appear, referencing the same previous
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 Atlas 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.

Network Components

Emitter/Executor

The party initiating state changes (e.g., payment sender, contract caller). They execute actual state updates and generate corresponding snapshots.

Relayer/Watcher

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

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

Transaction Flow Example

When Alice pays Bob:

Alice as Emitter creates a new snapshot recording "pay X to Bob, balance decrease"
References her previous snapshot hash, sequence +1
Signs and broadcasts to the network
Network Relayers receive and sign to forward
Bob receives and validates the snapshot, considering himself paid
Bob can act as Relayer to continue forwarding or at least retain for reference

If Alice attempts to pay Charlie the same amount (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 transaction

Atlas'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

Atlas'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, Atlas hides transaction details themselves. Each has pros and cons, but Atlas 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. Atlas, 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, Atlas 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.

Infrastructure Considerations

It should be noted that Atlas is not a purely cost-free solution—it needs some infrastructure support, like enough Relayer nodes and on-chain anchoring fees. But considering Atlas 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).

Future Extensibility

Atlas 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, Atlas can be used not only for payments but also for more general off-chain state synchronization:

Cross-chain bridge state transmission
NFT offline exchanges
Complex multi-party contract coordination
Real-time oracle data distribution

A universal Layer 2 communication backbone.

Current Status: Atlas 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 Atlas network needs.

Addressing Original RGB Limitations

Original RGB has several issues:

Strict encoding format with low efficiency
Single-thread processing limiting performance
State storage relying on external indexing services
Non-unified development interfaces
Limited to Bitcoin chain anchoring

RGBX addresses these with the following improvements:

Performance Enhancements

Parallel Parsing and Validation

RGBX abandons serial traversal in strict encoding, adopting zero-copy parsing and multi-thread validation pipelines. Upon receiving a set of RGB state change data:

Decode each part in parallel
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
Ensures evolved from a series of valid states
No fear of malicious nodes providing fake states

Decentralization Improvements

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.

Benefits:

Users master their asset changes without trusting third-party indexing services
Through decentralized index discovery protocols (similar to DHT), users can get missed state updates from other peer-to-peer nodes upon going online
Reduces risks of relying on central servers

Developer Experience

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:

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.

Unified interface for diverse use cases:

Issuing stablecoins (token type)
Creating DAO voting (smart contract type)
Deploying decentralized identities (certificate type)

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.

Chain-Specific Implementations

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

Unified Proof Translation

Corresponding Proof Translator module normalizes light client proofs from different chains:

BTC needs SPV proofs (block headers + Merkle paths)
Ethereum needs log proofs
Kaspa needs DAG inclusion proofs

Proof Translator converts them to unified interfaces, so RGBX validating an anchor doesn't care which chain it's from, just calls validation interface.

Result: RGBX supports BTC, Tondi, Kaspa with one code set, even ETH in future, greatly expanding RGB's applicability.

Seamless Atlas Integration

RGBX tightly integrates with the aforementioned Atlas network. Whenever RGBX client executes a state change:

Besides generating on-chain commitment transaction, automatically generates corresponding Atlas snapshot and broadcasts
In Atlas 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 Atlas storage nodes
After snapshot witnessed by Relayers, its hash also included in next anchoring submission's graph root

Complete chain of trust:

RGBX state update → Atlas broadcast snapshot → Tondi anchor commitment

Anyone wanting to validate an RGB asset transfer can:

Check Tondi chain's commitment transaction
Require counterparty to provide corresponding Atlas path proof (including snapshot and Relayer signatures)
Confirm: the commitment's off-chain state indeed fulfilled some asset transfer from Alice to Bob
Verify: Atlas network recorded no conflicts

Cross-Chain Deployment Flexibility

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.

Example use case:

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

Performance Results

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 + Atlas's ultimate goal is to make ordinary users hardly feel blockchain's existence yet enjoy the trust and autonomy blockchain brings.

Design Principles

Hiding Complexity

At the frontend, users see familiar Web2-style operations:

Transfer: Input counterparty account (readable alias or scan code), input amount, click send, complete payment
Voting: Click option to confirm
Asset management: Visual portfolio with instant balance updates

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

Examples:

Users can view a certain asset transfer's on-chain anchoring transaction hash when needed
Export a zero-knowledge proof for some asset holding to prove authenticity to third parties
Access full validation history for audit purposes
View network graph topology for routing analysis

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.

Example scenario:

A stablecoin supports both BTC and Tondi chains
Wallet automatically chooses optimal path:
- Large amounts via BTC for maximum 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
Using 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 Atlas 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 + Atlas stack:

Lowers self-custody threshold
Obtains 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:

Enterprise wallet example:

Can choose to enable regulatory view keys
Transactions generate encrypted records for regulators
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
Actual enabling is decided by upper-layer applications
Fully respecting users and business choices

The Vision

In short, under Tondi + RGBX + Atlas 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 Layer 2 architecture choices, Avato Labs chooses a path of independent autonomy and open collaboration.

Our Position

Independence from Existing Organizations

We will not join RGB Protocol Association or RGB Open Alliance, nor accept their current governance and technical route path dependencies.

Rationale: 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.

Global Collaboration

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
Mainstream institutions' participation to drive large-scale application landing

Core Principles

Our principles are very clear:

🌐 Open Ecosystem

Tondi + RGBX + Atlas technology stack will be open-sourced
Welcoming global developers to co-build
Transparent development process with community involvement

🔗 Cross-Chain Fusion

Support multi-chain anchoring
Not tied to any public chain ideology
Pursuing optimal technical solutions regardless of ecosystem politics

👤 People-Oriented

User experience and actual needs oriented
No conceptual hype castles in the air
Solving real existing problems

Technical Philosophy

We reject the false dichotomy often presented in blockchain discourse:

Not "Bitcoin vs. Everything Else"
Not "Privacy vs. Compliance"
Not "Decentralization vs. Usability"

Instead, through careful engineering and thoughtful design, we demonstrate that:

High performance and strong decentralization can coexist
Privacy and regulatory compliance can be reconciled
Advanced technology and intuitive UX can be unified

The Path Forward

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
Innovation and stability

Bringing blockchain into the convergence of mainstream finance and society.

Call to Action

We sincerely invite visionary partners to join us:

Researchers interested in pushing the boundaries of Layer 2 design
Developers seeking to build on a principled, high-performance stack
Enterprises requiring compliant yet private blockchain infrastructure
Users demanding Web2 usability with Web3 sovereignty

Together, let's advance this future-oriented base chain to the world.

Conclusion

The journey from recognizing the limitations of BTC + RGB + LN to architecting Tondi + RGBX + Atlas represents more than technical evolution—it represents a fundamental rethinking of what blockchain infrastructure should be.

We don't accept trade-offs between:

Security and performance
Privacy and auditability
Decentralization and user experience

Instead, through careful layering, novel cryptographic primitives, and relentless focus on real-world usability, we build systems that excel across all dimensions.

The future of blockchain is not about choosing between competing visions, but about synthesizing the best ideas from all approaches into coherent, production-ready systems that can truly serve billions of users.

Tondi + RGBX + Atlas is our contribution to that future.