Where it settles was the question of No. 03. This note answers the next one: how a Bitcoin-native dollar actually climbs out of rgb-lib and LDK, through a Rust FFI, into the app on your phone. The map below is drawn from the source of @utexo/wdk-rgb-lightning - the module that wires RGB-over-Lightning into Tether's Wallet Development Kit.
USDT was born on Bitcoin, left for faster chains, and is finding its way back - this time as an RGB asset settling over Lightning. The module in this note is the road home.
Tether launches on the Omni Layer - USDT's first home, anchored to Bitcoin.
Volume migrates to Ethereum and Tron. Cheaper, faster - and fully public.
Tether ends Omni support. The original Bitcoin rail goes quiet.
Native USDT returns to Bitcoin - client-side validated, Lightning-fast, settlement-anchored.
Tap a floor to read it. Or press trace a payment and watch an invoice fall through the whole building - from the wallet's one-line call down to the Rust node that signs against Bitcoin.
One package, two runtimes. exports in package.json picks the binding at module-load: Node resolves index-node.js, a bare worklet resolves bare.js. Same classes either way.
The README's usage example, annotated move by move. This is the whole journey from "npm install" to a paid Lightning invoice carrying an RGB asset - with the seed never leaving the host.
Three design decisions in the security model, as documented in the repo. They are the difference between "an SDK that moves money" and one a wallet team can actually ship.
The mnemonic is owned by the WDK secret manager. The binding derives a 32-byte BIP-32 entropy (seedHex), hands it once to NativeExternalSigner.create, and the node persists only public material - xpubs, node id, master fingerprint. Same mnemonic, same node identity, every restart.
All channel-state signing goes through vls-protocol-signer - the Validating Lightning Signer - whose lifecycle is tied to the binding and destroyed on manager.dispose(). No external signing daemon to misconfigure.
With vssUrl set, channel state and RGB wallet data mirror to a VSS endpoint encrypted client-side with XChaCha20-Poly1305, keyed via HKDF from the BIP-39 mnemonic (path m/535'/1'). The server stores ciphertext; recovery requires the original seed. Plain http:// is rejected by default.
A wallet integration has a shape you can count. Here's the one this module asks for - read straight off the repo at the version above.
USDT already moves over Lightning via Taproot Assets. This module bets on RGB instead. The difference is where asset data lives - and who can see it.
rgb-lib store. The chain sees commitments, not amounts.rgb-lightning-node (LDK + rgb-lib).The honest read: Taproot Assets has the head start. RGB's pitch is stronger client-side privacy and validation that never touches a shared ledger. This module is a bet that the second property is worth the younger toolchain - a bet worth its own field note.
What actually happens when one wallet pays another, end to end - the five beats this module orchestrates.
Things you only find by reading the repo, not the press release. Beta software is allowed rough edges - naming them is how it hardens.
At the time of writing the native bindings shipped only as GitHub-tagged prebuilds, installed via a github:#v<tag> spec. As of 0.1.0-beta.10 they are published: @utexo/rgb-lightning-node-nodejs@0.1.0-beta.9 and -bare@0.1.0-beta.13. The README install steps are now plain npm install.
When filed, the README pinned the bindings at beta.8 / beta.12 while package.json floored both at ^0.5.2-beta.1 - ranges that didn't overlap, so the documented install threw EBADPEER. Flagged it; 0.1.0-beta.10 realigned the floors to ^0.1.0-beta.9 / ^0.1.0-beta.13, on the same 0.1.0 base as the published prereleases. Maintainer confirmed the diagnosis.
The README says issueAssetNia / Ifa / Cfa / Uda and inflate aren't exposed here and points at wdk-wallet-rgb. The account class in src/wallet-account-rgb-lightning.js forwards all five straight to the node. Either the code should drop them or the README should own them.
Async payments (apayNew, plus a one-shot bootstrapLsp that replaced a manual three-call dance), hodl invoices, atomic swaps and a hardened LSP client with retry/backoff and structured errors - all present in beta. The surface is wider than the headline suggests.