Giacomo Zucco on RGBTC: Why RGB’s Late Arrival Became Its Advantage
This Giacomo Zucco RGB community call recap is based on the call held on August 12, 2026, featuring Giacomo Zucco, Bitcoin educator, and one of the earliest people to sketch out the idea behind RGB.
To have more context on RGBTC, check Giacomo’s interview in Riga in 2025. For the full backstory of RGB Protocol on Bitcoin, see the History of RGB article, which the call also referenced at the start.
In Brief
- RGB began as a Peter Todd paper on client-side validation — he proposed it for Bitcoin itself, not for tokens.
- RGBTC (RGB-native Bitcoin, trustless peg-out) was never abandoned. It’s still unsolved, but closer thanks to BitVM and shielded CSV.
- Arriving late let RGB skip a standards war: it can sit on top of Taproot Assets, Confidential Assets, Arkade, Spark, and Cashu as a meta asset protocol.
- USDT on RGB isn’t unconfiscatable, but with no address to freeze, a government order gets much harder to execute.
- Zucco’s dream wallet auto-routes funds across security tiers
How RGB Was Born
Zucco set the record straight on how RGB actually started. While serving on the program committee of Scaling Bitcoin, he received a paper from Peter Todd proposing client-side validation: a model where miners and nodes only need to know whether a Bitcoin output has been spent, not what it represents. The details of a transfer could move directly from payer to payee, improving censorship resistance, privacy, and scalability along the way.
The paper had nothing to do with token standards. Zucco placed it in “Breaking the Chain,” a track that gathered the wildest ideas at Scaling Bitcoin, alongside DAG-based designs that eventually became IOTA and a wave of related projects, and an early Bitcoin NG proposal.
Right after the conference, a conversation with Andrew Poelstra surfaced the catch: client-side validation trades away Bitcoin’s best UX property, the ability to receive without being online and without keeping a backup of every single payment. Years later, discussing Lightning, Zucco realized the same tradeoff applied there too, in a worse form: a Lightning user has to stay online, or run a watchtower, to broadcast a punishment transaction, and restoring from an out-of-sync backup can accidentally trigger one.
The intuition that started RGB, in his account, was neither about assets nor tokens: it was the idea of pairing Peter Todd’s client-side validation with Lightning, since solving Lightning’s UX challenges would, by construction, also solve client-side validation’s.
However, a path onto Bitcoin didn’t exist yet for that combination and eventually, what turned the theoretical research idea into something practical was interest from early clients evaluating token protocols: Omni, Counterparty, and various shitcoin-based token schemes. RGB became a token protocol at that point, and NFTs briefly rode along (a direction Zucco says never impressed him, despite early attempts on Liquid). A talk at the Berlin Lightning Conference made the case that RGB would not just avoid harming Bitcoin, but actively help it: Lightning channels routing RGB assets alongside sats increase Bitcoin’s own liquidity and anonymity set.
USDT eventually became the dominant use case. Zucco described himself as a long-term skeptic of Tether specifically, someone who considers Bitcoin the real long-term store of value and USDT a useful, shorter-term bridge. The original goal of putting Bitcoin itself onto RGB never disappeared. It moved into the shade of two more immediately practical use cases, NFTs first and then USDT.
RGBTC: The Piece Nobody Ever Abandoned
Still, the idea of representing Bitcoin natively on RGB (RGBTC, for short) survived alongside the token use case, and Zucco called his own original design “abstract and not really thought out.”
Locking Bitcoin into an RGB token is trivial. An assignment simply requires proof that a Bitcoin output has been locked, and an RGB token can be generated from it. Unlocking that Bitcoin, the peg-out, has never had a good answer. Proving that an RGB token has been burned, along with its full chain of assignments and single-use seals, in order to release the underlying Bitcoin, remains an open problem.
Zucco pointed to two directions closing the gap:
- BitVM, which lets a complex program be compressed into a single zero-knowledge proof, broken down into a series of NAND gates, and spent through via Taproot if the proof is solved.
- Shielded CSV, an academic research line combining client-side validation with two-way pegging, which Zucco expects to converge with a working RGBTC design rather than diverge from it.
He credits RGB’s slow path to mainnet, technical, human, and organizational, with an unusual advantage: a very low time preference. Instead of rushing, RGB has had room to absorb and outlast competing ideas.
Could a Federation Get RGBTC Live Tomorrow?
The conversation turned to how a trust-minimized consensus layer for RGBTC could actually work. Zucco admitted that a federation model could launch immediately: as an example, if the Liquid federation reused its existing HSMs, fiduciaries could check the RGB chain of consignments and the on-chain single-use seals before signing off on a peg-out, alongside their existing Liquid sidechain duties.
He is not pushing for it, and explained why. A federation is composable (Spark already pairs a statechain with a federation model; Fedimint pairs eCash with one) and safe from outright theft, since the odds of enough geographically distributed HSM operators colluding are extremely low.
However, censorship resistance is a different matter. Zucco estimated 15 to 20 entities currently run Liquid’s HSMs worldwide, and argued that a government pressuring even one into shutting down could plausibly trigger a shutdown across the rest, since there’s no reward for the remaining fiduciaries to keep signing once one gets ordered to stop.
He contrasted the federation model with Bitcoin mining, which he considers structurally more resilient: when a government arrests a miner or forces one operator offline, the hashrate doesn’t stay orphaned, since anonymous operators elsewhere can absorb the abandoned machines under a different flag. A liquid federation, in his view, doesn’t recover the same way. He is fine with someone building the federated version of RGBTC as an experiment, as long as nobody oversells its security as equivalent to Bitcoin’s.
The alternative he prefers, a BitVM-style design requiring only a single prover and a challenger with no federation at all, is still further away. It depends on soft-fork-level tooling that doesn’t yet exist.
If he were to champion (not enforce) a soft fork today, he said he wouldn’t pick a Bitcoin-native ZK verifier, since the field is still evolving too quickly to commit to one design. He’d pair cross-input signature aggregation (CISA) (now formalized in BIP 458 and BIP 459) with a MuSig-family signature scheme descended from Taproot and Graftroot. Combining the two wouldn’t solve RGBTC’s trustless design on its own, but it would make the design simpler and more efficient to build: hard, but still theoretically possible.
The Advantage of Arriving Late: RGB as a Meta Protocol
The conversation turned to a concept Federico Tenga presented at the Lightning Summit in Viareggio in May: RGB isn’t just another way to tokenize Bitcoin, since plenty of other tokenization schemes already exist. What makes it distinctive is flexibility across every Bitcoin security layer.
RGB started as a protocol for two layers: on-chain and Lightning. RGB’s real potential shows up in the latter, since Lightning already solves the flying, receiving, and backup challenges that client-side validation introduces on its own.
From there, competing asset protocols multiplied across every new Bitcoin security layer:
| Protocol | Security layer | Zucco’s Comments |
|---|---|---|
| Taproot Assets | Lightning (Taproot-based channels) | Lightning Labs built it |
| Liquid Confidential Assets | Liquid sidechain | Improves on colored coins, keeps Bitcoin’s own chain and anonymity set untouched |
| Arkade assets | Ark | A colored coin on Ark (in Zucco’s words) better than one on the main chain, but still basic |
| Spark assets | Statechain | Blitz Wallet already uses it for dollar-denominated credit |
| Cashu assets | eCash | Works offline; Aleikos Filini has used it to issue conference tickets |
Had RGB launched five years earlier, Zucco argued, the field would have split into a straightforward fight between five or six incompatible standards. Instead, RGB’s design is general enough to be reimplemented on top of essentially any UTXO-based system: Liquid, Taproot Assets infrastructure, Ark, Spark, and, with more effort, Cashu. That reimplementability is what lets RGB act as a meta asset standard, natively translating between the other protocols and letting an asset issued on one security layer swap atomically with an asset on another.
“We are late, but now we don’t need to compete with the other six protocols — we can just become the lingua franca across these protocols.”
Two reasons drive his enthusiasm.
- The philosophical one: he dislikes incompatible standard proliferation. RGB’s answer isn’t to out-compete every other protocol, but to stay flexible enough that each one keeps doing its own thing while remaining “swappable” through RGB, including on-chain, where RGB is the only standard that survives, since any asset scheme that didn’t rely on client-side-validation on chain was a mistake from the start.
- The practical one is more personal: having helped create RGB, Zucco wants to see it succeed, and the years lost to a late launch turn into an advantage once RGB has the flexibility and the timing to become the connective layer across a field that has already fragmented into six protocols.
Merging RGBTC With the Meta-Protocol Vision
The conversation turned to whether RGBTC and RGB-as-meta-protocol were converging into the same concept. Zucco confirmed the goal, while flagging that unifying them cleanly is still unsolved work: representing assets through RGBTC and representing RGBTC across every layer that already represents assets are two different research directions, currently running in parallel rather than merged.
If the unification succeeds, the result is elegant: wherever satoshis exist and wherever assets exist, RGB becomes the shared language, and RGBTC becomes the underlying security model, comparable to BitVM.
In terms of trust spectrum, Zucco ranked it between Ark and a statechain: RGBTC would need to publish neither an Ark-style timeout tree nor a single statechain transaction, only a BitVM-style zero-knowledge proof, at a cost depending on the efficiency of that proof. On top of that trust profile, an RGBTC asset layer would already integrate with the asset standard, instead of arriving later as a separate piece.
USDT on RGB: What Actually Changes
The technical half of the call closed with a direct question: what does USDT on Bitcoin through RGB unlock that previous attempts didn’t?
Zucco framed USDT as a regulatory arbitrage. A direct PayPal competitor needs banking and localization licenses everywhere it operates, which shuts out the unbanked and underbanked by design. USDT gets around that problem by issuing on a blockchain regulators see as decentralized, even when the chain’s real validator set is actually far more centralized than it appears.
The primary market, where credit is issued and redeemed, runs through KYC/AML like a bank account. The secondary market, where that credit circulates once issued, doesn’t, and Tether can’t unilaterally stop a transfer there.
Governments can still reach USDT indirectly, by pressuring Tether to blacklist an address before it redeems back to fiat, whether the justification is sanctions, politically inconvenient recipients, or simple compliance with a foreign government. Zucco walked through why RGB changes the mechanics of that pressure: an RGB asset has no address. Only the sender and the immediate recipient of a transfer know where the asset sits; nobody upstream or downstream in the chain of transfers can see it. A government can’t hand Tether an address to freeze, because no address exists to hand over.
“An RGB asset is nowhere — there is no address where an RGB asset is, by definition, being client-side. Only the recipient of an RGB transaction can tell that they have the asset — well, of course the sender as well — but everybody before and after, they don’t know.”
Still, Tether could refuse a specific redemption if a submitted consignment reveals a blacklisted public key, so the privacy gain isn’t a complete defense, and a government could instead try to ban Tether from using RGB altogether on privacy grounds.
Zucco pointed to the defense that already worked for confidential assets on Liquid: best market practice. Tether abandoned Omni years ago specifically because Tether was the only company using it; ordering a shutdown carried no political cost. Ordering Tron or an ERC-20 rail to shut down would mean shutting down an entire ecosystem of unrelated projects, which is a much harder case to justify politically. RGB’s adoption curve mattered for the same reason: it needed credible, broad market adoption before USDT could safely move onto it, not just the technical capability. In Zucco’s words, that milestone is no longer an “if.”
Once live, RGB’s history is not impossible to trace, but orders of magnitude harder to trace than an ERC-20 balance. It is good for users, since the entire value proposition of a stablecoin is money that moves without the bureaucratic friction of PayPal or other payment apps.
The obvious counterargument came next: if USDT is just dollars, and a payment app already holds dollars, what’s actually new? Zucco named two things:
- The one that benefits users is a secondary market largely free of the account restrictions imposed on payment apps like PayPal, since a wallet app replaces a bank account.
- The one that benefits Tether is capturing Treasury interest on the collateral instead of passing it through a bank: a model Zucco expects to weaken over time as rates normalize and governments grow less tolerant of a private company holding that yield indefinitely.
RGB doesn’t change the second novelty much. However, it changes the first one significantly: USDT itself stays freezable, since Tether remains a centralized company, but RGB makes confiscation significantly harder to execute and separates USDT’s counterparty risk from the Bitcoin side of any trade, which becomes zero-counterparty.
One more point followed: privacy on RGB doesn’t only defend against government confiscation. A fully transparent ERC-20 balance also exposes users to kidnapping, phishing, and blackmail, since anyone who can see a wallet’s balance and history, not just a government, can act on it. Most Bitcoin-versus-USDT trades today (swaps, collateralized loans, bets) actually settle as USDT against a wrapped Bitcoin token, since no chain hosting USDT actually has real Bitcoin on it. RGB removes that middle step, allowing a native swap between real Bitcoin and USDT with zero counterparty risk on the Bitcoin side.
Privacy and Trust Never Reach 100%
The last technical question probed further: does RGB point toward a future of full privacy and full trustlessness, or does trust in some federation stick around permanently once assets scale up?
Zucco separated the two concepts. Privacy never reaches 100%, for reasons outside any protocol’s control: a webcam, a keylogger, or mandated spyware on a phone bypasses whatever encryption a wallet uses. What RGB can do is push the achievable ceiling significantly higher than today. Bitcoin’s base layer has a real privacy problem; Lightning improves on it, but liquidity bottlenecks force tradeoffs, since an LSP like Phoenix’s needs visibility into channel activity to manage liquidity for its users. RGB, even without RGBTC, already improves liquidity through BTC/USDT swaps without giving up privacy in the process.
Trust never reaches zero percent either. Even a fully trustless protocol requires trusting that the hardware running it isn’t backdoored; if every chip shipped with a hidden keylogger phoning a state actor, privacy and trust would collapse together, because a compromised key holder still has to trust whoever holds the compromising information not to act on it. Zucco expects both privacy and trust to climb meaningfully with RGB and RGBTC, without either one ever completing the climb.
Zucco drew a comparison to how people actually protect physical valuables: a fortune sits behind drones and armed guards, a hotel safe only needs the hotel manager’s honesty, a wallet risks pickpocketing, and a handful of loose coins in a car barely need protecting at all. Security spend should scale with what’s at stake, and he’d like Bitcoin wallets to work the same way: Cashu for a few dollars, Spark for tens of dollars, Ark for hundreds, a Poon-Dryja Lightning channel for thousands, a single key on-chain beyond that, and full multisig for life savings, with the wallet moving funds between tiers automatically as a balance crosses a threshold.
Q&A
After the RGB-focused part of the call, the conversation opened up to Q&A from the audience and the hosts, moving beyond RGB into broader Bitcoin topics.
Scam Resistance
Q: Do RGB’s privacy properties make it resistant to scams?
A: Zucco pointed to RGB’s lack of a visible public order book, which removes front-running, and contrasted it with two earlier failed narratives: NFTs promised exclusive ownership but delivered a transferable claim on a freely-circulating image, something RGB’s private, client-side transfers get genuinely closer to; on the other side, memecoins, unlike prior shitcoin cycles, at least carry no false technical claim, as they can be seen as gambling from the start.
Irrational gambling on RGB assets is still possible, he added, but the missing order book closes off a real fraud vector.
Bitcoin Security in 2026: Nihilism or the Orange Pill
Q: What’s behind the recent wave of Bitcoin security incidents (Liquid, Coldcard, Boltz, BTCPay Server, Trezor)?
A: Zucco tied the pattern to LLMs lowering the cost of auditing code: a double-edged sword that helps both defenders and low-skill attackers. His preferred response isn’t nihilism (retreating to exchanges, which have lost far more money than self-custody ever has), but the orange pill path: rebuilding stronger, as Boltz and Ark have. The same logic applies to hardware wallets. We shouldn’t bet on one vendor, but spreading trust across several (a Ledger, a Jade, an old laptop running Bitcoin Core).
Circular Economy, or Fiat-Skipping Economy?
Q: What does grassroots Bitcoin adoption and a “circular economy” look like in practice?
A: Zucco pushed back on “circular economy” as an environmentalist framing he doesn’t buy into, pointing instead to early examples like Bitcoin Valley in Rovereto, Italy, and El Salvador’s farmers’ market.
“I prefer to call it a fiat-skipping economy — in the sense that if you pay somebody in Bitcoin, it’s better if they just keep the Bitcoin and spend Bitcoin their way, because you minimize the amount of fiat you have to involve with every step, which makes everything more private and more efficient.”
Online, he sees concrete reasons to use Bitcoin already (private VPNs, bypassing bank accounts). For everyday retail payments he’s more skeptical. Bitcoin isn’t optimized for that yet, though he’s fine with a marketing framing as long as organizers stay honest about it.
Zucco’s Take on BIP-110
Q: Was BIP-110 a failure, and where does the Bitcoin community go from here?
A: Offered as a personal, informal read, Zucco called BIP-110 a spectacular but entirely predictable failure, with one genuine surprise: OCEAN kept mining on the losing minority chain for two days after a reorg became mathematically impossible. He grouped the reactions he’s watched since into three camps: doubling down out of sunk-cost and ego (his read on Luke Dashjr), partial reconsideration, and quiet denial from the majority.
Further Reading
- The History of RGB Protocol on Bitcoin
- Inside Utexo’s RGB Stack: SDKs, the Bridge, and a Live Wallet Demo
- USDT on the Lightning Network: Why It’s Good for Lightning Itself
