Inside Utexo’s RGB Stack: SDKs, the Bridge, and a Live Wallet Demo

This article is based on the RGB community call held on July 30, 2026, a developer-focused session with Renat Skitsan, CTO of Utexo, hosted by Birk from RGB Protocol Association. Renat walked through the Utexo SDK suite and gave a live demo of the bridge and a browser-based RGB Lightning wallet.

In Brief

• RGB Protocol on Bitcoin already covers stablecoins’ core use cases (private payments, atomic trading, lending); broader programmability is a smaller, separate track.
• Utexo’s SDKs span Node.js, browser JS/TS, React Native, and soon Flutter, plus an unannounced integration built into Tether’s own Wallet Development Kit (WDK).
• The bridge mints USDT on RGB using a trusted execution environment (TEE), not federation trust; a live demo showed the full round trip, from an EVM chain into a browser-based RGB Lightning wallet.
• A realistic, not committed, launch window for USDT on Bitcoin: end of summer to mid-September 2026.

https://t.co/3FzYs5kLRT

— RGB Hub (@RGB_Hub) July 30, 2026

What Is RGB Protocol on Bitcoin, and Why Does It Matter for USDT?

Renat opened with a primer for newcomers to the call. RGB Protocol on Bitcoin is a client-side validation protocol: a way to layer an accounting system, and ultimately a full smart contract system, on top of Bitcoin’s UTXO model, without pushing that logic onto the base chain itself.

Bitcoin’s blockchain is used only for preventing double-spending. Everything else (the actual state transitions, the contract logic) happens on the client side. RGB is scalable precisely because any number of state transitions can be batched into a single UTXO and finalized in one Bitcoin transaction, instead of hitting a one-transaction-per-payment limit. Renat described moving everything but double-spend prevention off the base chain as a genuinely unique design choice, the reason RGB can scale so far beyond what a typical protocol manages.

He traced the lineage back to Omni Layer (the original “Master Coin” project that first tried alternative accounting on top of Bitcoin), which pushed early stablecoin issuance toward Ethereum because Bitcoin didn’t yet have an expressive enough system for it. RGB is presented as the system the Bitcoin community eventually built to close that gap, with the same censorship resistance and decentralization properties as Bitcoin itself, plus the ability to carry additional logic on top of a UTXO.

The immediate target for that logic: USDT on Bitcoin, with the added benefit that RGB transfers aren’t publicly visible on a block explorer the way today’s USDT transactions are.

From Programmability to a Meta Asset Standard: Why the Narrative Shifted

RGB’s client-side-validation model is narrower than general-purpose EVM programmability by design, but it already covers the use cases that actually generate value:

• Payments and stable value transfer: fully covered, and can run on Bitcoin Layer 1, Lightning, or other Layer 2 technologies like Ark and Spark.
• Trading: Bitcoin’s HTLC primitive already supports atomic swaps, so this use case is covered as well.
• Lending and borrowing against USDT and Bitcoin: projects are already actively building these products.

Renat estimated that these three use cases cover roughly 90% of what generates real value in crypto today, calling out that a lot of what general programmability enabled elsewhere over the last year will eventually disappear. The remaining 10% (staking, leveraged positions, more exotic instruments) is a smaller, ongoing research direction, and matters more for lower-liquidity tokens than for an asset like USDT.

Where more programmability is needed, Renat pointed to RGB working as a meta-protocol: since it works on top of any UTXO, assets can move into layer 2 systems that offer more expressive programmability (like the work KaleidoSwap has published on combining RGB with Simplicity on Liquid), while keeping the asset itself denominated in RGB. In Renat’s view, framing RGB as a meta-protocol is the best way to describe what it actually is: a design that avoids polluting the Bitcoin chain, preserves privacy, and puts Bitcoin to work for exactly what it was built to do.

Utexo’s Product Suite: SDKs, Bridge, Swap, Settlement, Cloud

Renat then gave an overview of Utexo’s product lineup before moving into the demo:

1. API & SDK: Non-custodial, confidential USDT settlement on Bitcoin via Lightning and RGB.
2. Cloud: Fully managed RGB-Lightning infrastructure for operators who don’t want to run nodes.
3. Mint: Lock-and-mint hub for issuing USDT on Bitcoin from any source chain.
4. Swaps: Intent-based routing for non-custodial BTC ↔ USDT conversion.

Multi-Platform Coverage and the Tether WDK Integration

Wallets that already have USDT users (on Tron, Ethereum, and other networks) need an SDK that can run inside their existing codebase rather than a standalone node. Utexo’s answer is a set of SDKs covering:

• Node.js, for embedding a node server-side into an existing backend.
• Browser JavaScript/TypeScript, the one used in the live demo, described as the easiest way to show the capabilities.
• React Native, for iOS and Android.
• Flutter, coming shortly, expected to cover roughly 90% of Web3 wallets combined with React Native.
• Native Swift/Kotlin, already supported, for the remaining 10% of wallets built natively.

Renat then shared what he called “a small spoiler,” not yet formally announced: an RGB Lightning module built into Tether’s own Wallet Development Kit (WDK): the modular framework Tether provides for building self-custodial wallets that embed the chains where USDT is represented. Utexo’s integration runs fully on Node.js and Bare, and is compatible with Tether’s peer-to-peer product suite, including Keet and Hypercore. Renat called WDK the easiest and most convenient path for developers building a new wallet, since a large existing developer base already works within the framework, with support available from both Tether’s team and Utexo’s.

Alongside the SDKs, Utexo is preparing a fully open-source reference implementation wallet, built on WDK and the web SDK, shipping as both a browser extension and mobile apps for iOS and Android, to be published on the Apple and Google app stores. Wallet backups use a VSS server, the backup system originally designed by the Lightning Development Kit (LDK) team, extended to also cover RGB asset backups.

The Wallet Ecosystem Building on RGB

Renat listed several wallets already integrating Utexo’s SDK, at different stages:

• Tribe Wallet: open source.
• Kaleidoswap: currently in beta.
• Iris Wallet: with further updates expected.
• Layer Z Wallet: successor to the well-known Blue Wallet, in the final stage of RGB integration.
• Xverse Wallet: previously known as an ordinals/runes wallet, now adding RGB.
• Unisat: another wallet known for ordinals and runes, integration complete and currently in testing, expected to be a launch partner.

Renat also noted interest from stablecoin-oriented and general Web3 wallets beyond the Bitcoin-native ones named above.

Inside the Bridge: How Security Actually Works

The bridge uses a lock-and-mint design. On the EVM side, an audited, open-source smart contract (compatible with USDT0 and LayerZero, so USDT can be brought in from multiple chains) locks the funds and emits an event. That event is picked up and processed by the RGB smart contract, which mints the corresponding asset on the RGB side. Because RGB is client-side validated, every recipient independently checks the mint history back to that lock event, so minting can’t be triggered by anything other than a real, verifiable lock transaction.

The part designed to be genuinely novel, in Renat’s framing, is where trust actually sits. The bridge runs inside trusted execution environments (TEEs): enclaves that generate signing keys which, by design, can never leave the hardware boundary. A federation of parties runs these TEEs, but the federation isn’t what the security rests on: Renat was explicit that the bridge’s security assumption comes from cryptographic logic and smart contracts, not from trusting the federation, to the point that even a compromised federation majority would still need a genuinely valid Bitcoin transaction to unlock any funds.

The federation’s actual job is providing liveness and censorship resistance (ensuring the bridge stays available), not acting as a trust anchor. To unlock funds on the way back, the TEE validates the RGB burn event, checks the RGB consignment file, and verifies Bitcoin proof-of-work, additionally cross-checked on the EVM side through a smart contract called BTC Relay, which only needs one honest participant anywhere in the world submitting the correct longest chain to prevent a fraudulent unlock.

Both the lock contract and the TEE code are fully open source, with an internal and external audit already completed on the bridge and its TEE codebase. Renat mentioned the plan to publish the final audit report soon, along with tooling that lets anyone independently verify that a given federation signer is running the exact audited code, by compiling it locally and matching the resulting public key hash against what’s published on GitHub. Longer-term hardening includes spreading the TEE workload across multiple providers (AWS, Google Cloud, Azure) instead of depending on a single one.

Live Demo: Sending USDT From an EVM Chain Into a Browser RGB Lightning Wallet

Renat then switched to a live walkthrough, worth watching in full in the recording of the call rather than just reading about it, since a lot of the value is in seeing the actual interface. A short summary of what he showed:

The bridge front end: connecting a wallet, choosing a source chain (currently around 68 chains are supported, with USDT concentrated mostly on Ethereum and Tron, plus Plasma and Polygon live and Solana coming next), and choosing Bitcoin/RGB as the destination. Renat ran the live transfer on Arbitrum specifically, since as an Ethereum L2 it shares the same finalization assumptions Utexo relies on for mainnet Ethereum. After generating an invoice from the RGB wallet side and entering it into the bridge, a small transfer (around $2) was submitted and confirmed on the EVM side. Finalization took about 18 minutes in the demo, a mainnet security assumption tied to confirmation depth on the EVM chain rather than to Bitcoin or RGB; Renat expects finalization to be much faster in a dedicated dev environment.

The browser-based RGB Lightning wallet: created live on signet (for faster blocks than mainnet), with a seed phrase generated on the spot. Renat was explicit about what’s actually happening here: the Lightning node runs completely inside the browser, with no calls to an external server beyond encrypted backups. From there, he connected to an LSP (Lightning Service Provider), a remote RGB Lightning node that opens channels and provides inbound liquidity, so a new wallet doesn’t need to solve inbound liquidity itself before it can receive a payment.

Receiving and sending assets: using a Telegram bot built for the dev experience, Renat requested test assets by asset ID, generated an on-chain invoice, and had the bridge pay it, watching the balance update in the wallet once confirmations landed. The wallet interface separates transactions (on-chain fund movements) from transfers (the invoices generated and their statuses, such as “in progress” or “complete”), and updates the asset balance once enough confirmations land. He also demonstrated a peer-to-peer Lightning payment between two SDK instances, and briefly showed Lightning address payments, which let a recipient receive funds without pre-generating an invoice for each payment.

A freshly opened Lightning channel starts with inbound liquidity from the LSP but zero outbound liquidity; Renat noted that outbound liquidity comes from actually receiving funds first, whether through the bridge or through a submarine swap into the channel.

Everything shown is open source: the Telegram bot, the React Native SDK (with a sandbox mobile app), and the web SDK (with documentation covering the LSP and the underlying async payment protocol needed since a browser wallet isn’t always online to receive a payment in real time).

What Happens If Something Fails Mid-Swap?

What happens if a user’s device or connection drops mid-transaction. Renat’s answer: for the swap product specifically (as opposed to the bridge), there’s no partial-failure state by design: a swap either completes or it doesn’t, with no state in between where funds could be lost. The system is deliberately built without a liveness requirement on the user’s side for the transaction itself to remain valid: a broadcast transaction only finalizes if the backing transaction on the source chain actually exists.

As Renat summarized it, worrying that a dropped connection mid-transaction might mean burned funds is unfounded: nothing gets lost, because an atomic swap either completes in full or not at all, with no in-between state to fail out of.

The one thing that does need to stay available is the RGB consignment file, the same category of responsibility a user already has with a seed phrase according to Renat, not an additional trade-off introduced by RGB’s design.

RGB Lightning Node: From Feature-Complete to Security-Hardened

Asked for an update on the RGB Lightning Node itself, Renat described the last several months as focused on interoperability: building out the SDKs across mobile, browser, wallet extensions, and server/cloud, plus supporting features like the async payment protocol and backups. With that groundwork largely done, and validated through the wallets already integrating it, Utexo’s focus has shifted to security hardening of the RGB Lightning Node specifically, following the same process already completed for the bridge (internal review, then external audit).

External reviewers being brought in include known LDK and RGB Lightning developers. Renat expects this phase to move faster than the bridge one, since the team is no longer splitting focus across several projects at once, and results are already being shared inside the RGB Lightning Node development group, with more pull requests expected in the coming days.

Exchanges, PSPs, and the Road to Launch

On the business side, Renat described an active pipeline of exchange integrations, with engineering feedback from exchange teams already incorporated. Most exchanges are expected to launch with Lightning support specifically, since Lightning is already well-integrated across tier-one and tier-two exchanges and familiar to their engineering teams; RGB on top of it is a smaller incremental step than adopting an entirely new asset. Some exchanges running RGB on-chain only could theoretically launch slightly earlier, but the goal is to launch both together where possible.

On the payment services side, Renat named one completed integration: one of the biggest crypto casinos (Betfury) that finished RGB Lightning integration and has been helping test real-world use cases.

When Is USDT Launching on Bitcoin?

Renat laid out the remaining checklist rather than a single hard date:

• Security audits: done for the bridge and its TEE codebase; RGB Lightning Node hardening is in progress (see above).
• Compliance: a recently announced Crystal Intelligence integration checks this box; remaining legal work is described as in its final stage.
• Interoperability: extending support beyond an initial set of chains to the broader range of USDT and USDT0 chains by transaction volume.
• A new token standard, “Bridged Fungible Asset”: developed primarily by the RGB Protocol team, expected to ship as part of an upcoming RGB Lightning update within the coming weeks.

With those pieces closing out, Renat gave a realistic, explicitly not committed, window: end of summer to mid-September 2026 is realistic from a technical standpoint, as already announced, though he was careful to note it still depends on a lot of coordination within the RGB community.

A Final Note

Renat ended on the broader vision behind all the SDK and infrastructure work: abstracting away RGB, Lightning, and Bitcoin’s layered architecture so that, eventually, an ordinary user only needs to know they’re using USDT on Bitcoin, the same way most people use the internet today without thinking about TCP/IP. He encouraged developers to treat this as the ideal moment to get involved, build with the SDKs, and send feedback back to the team.

---