This document contains the technical specification for the proposed “RGB” protocol for the issuance, the storage and the transfer of blockchain-based digital assets. The protocol aims to provide a standard to perform the aforementioned goal in a way that overcomes the major shortcomings of previous attempts. The protocol is based on Bitcoin, and it’s aimed to provide an acceptable level of scalability, confidentiality, and standardness.
There is a continuous and growing interest for digital assets somehow representing a proxy for securities (shares, bonds, deposits, royalties, voting rights, IOUs for physical goods, etc.), utilities (vouchers, coupons, fidelity points, casino tokens, discount rights, pre-sell receipts, payment alternatives, etc.) or collectibles. Traditional ways to issue and transfer assets are usually slow, expensive, inefficient, and present a lot of friction, both from a technological and from a regulatory point of view. Nowadays an increasing number of businesses, startups, financial institutions or even individuals are willing to issue digital assets across multiple use-cases.
While centralized and trust-based models for digital asset management are still, in many cases, the most rational option, there is a growing interest for the application to this problem of the same kind of “blockchain” technology that powers Bitcoin (a purely peer-to-peer, decentralized, trustless, permissionless protocol born to manage the homonym digital commodity). Much of this interest is driven by marketing reasons in the context of the current hype cycle, as blockchain-based strategies often result useless (in many digital asset schemes there is already unavoidable need for a central counterparty) and even harmful (a blockchain-based design is usually more expensive, slow, inefficient, and privacy-lacking if compared with existent centralized alternatives, its implementation is usually more complex, challenged by new and not well understood security issues and it requires skills not yet common in the market, while providing “features” that are often undesirable for business and/or regulatory reasons, like pseudo-anonymity, censorship-resistance, complete openness, etc.). There could be, anyway, some legit reasons to use such a design.
A first class of reasons could be related to use-cases in which the market value (or the use value) of the asset is completely independent from the centralized issuer right after the issuance moment. The most obvious instance of this scenario is that of digital collectibles: once the original issuance process of a collectible is recognizable as unrepeatible, it's value is usually independent of any specific action (or lack of action) by the initial issuing party. Another, less obvious instance could concern the possible future development of decentralized mechanisms enabling autonomous, trustless, and censorship-resistant mechanisms to enforce rights/benefits connected to the assets, in order to extend some of the features of the bitcoin commodity to more generic/complex types of digital ownership. While the "digital collectible" proposition is absolutely realistic but arguably less interesting, the "self-enforced-right" proposition is more interesting but still not realistic: applications of this kind are still far from any actual implementation, even if there are many theoretical niches (“smart-property”, “DAOs”, etc.) that seem to bear some potential.
While a full-fledged decentralized, trustless, and permissionless setting is still difficult to imagine for systems beyond Bitcoin itself, some of its interesting features could be somehow possible to approximate in settings where the central issuer of a digital assets is made, to a certain degree, “blind” to the exact history of that asset in the moment they step in to perform their redeeming/enforcing actions. This decoupling between the transaction history and the issuing/redeeming/enforcing phase could lead to interesting changes in the legal accountability of the central issuer: for example, a central party could comply with restrictive and privacy-harmful regulations such as KYC/AML during the issuance phase and during the redeeming/enforcing phase, while not being technically involved in any way int the possible secondary market exchanges between the two. While such a setting would be possible already using only well established, centralized setups (ie: blind signatures in e-Cash), the central party would be actively involved in clearing the exchanges, resulting somehow more accountable. Bitcoin-based assets could enhance this kind of decoupling. Digital IOUs representing fiat money (i.e., US dollars) issued on Bitcoin-based protocols like Omni, could be already considered first attempts at this particular use-case, potentially useful for the development of decentralized exchanges where the “fiat representation” function can be legally separated from the actual trading/exchanging system.
Even in the case of a trusted, non-blind, and centralized party, some advantages could still come in the form of enhanced auditability around the actions of the issuer/redeemer/enforcer. While a traditional architecture would technically allow him to modify the state of the system in every possible way (by inflating the asset supply, changing the distribution, blacklisting specific amounts and users, editing the transaction history, denying legit redeem claims or forging false ones) without leaving traces, blockchain-related methods could be used to provide solid proofs of fair (or unfair) behaviour. It is still unclear to what extent these auditability properties could represent a strong value proposition toward final users (at least in the case of a regulated business, where social, reputational, and legal guarantees are usually better received than technological ones), but they could be interesting for the regulators, possibly relaxing some of the existing, quite expensive, accounting/auditing requirements. Many current speculations about "blockchain-based regulated securities" could be ascribed to this fundamental use case.
While centralized, closed and proprietary solutions could already provide some mitigation for many of the problems above (sometimes with less technological friction than Bitcoin-based alternatives), they are usually difficult to adopt in a wide, consistent, and durable fashion. Open standards, on the other end, can be leveraged to lower the friction to adoption and to overcome many coordination problems. This is especially true in the case of Bitcoin-based protocols, where the need for a single, global, consistent, and immutable “source of truth” in the base protocol could reduce the degrees of freedom, boosting coordination. In a scenario in which Bitcoin (and related technologies) reached mainstream adoption for their inner value proposition, then also other, more general types of digital assets could easily leverage some of the same infrastructure (standards, libraries, APIs, marketplace liquidity, custodian services, wallets, block explorers, regulatory frameworks, secure hardware, user habits, best practices, etc.). The fewer the customizations necessary, the more frictionless the process would be. This advantages typically come at the costs of higher difficulty to profit, to grant investment returns, to lock-in and retain users, to monetize research and development, but many examples seem to suggest a strong market case for such strategies. Right now, the most used framework for the management of digital tokens is the Ethereum-based ERC20 protocol: notwithstanding the several and very serious shortcomings of this asset protocol and of its underlying system (which we cannot cover here but are well documented and severely affect sustainability, security, censorship-resistance, confidentiality, and scalability) this has so far become is the de-facto standard for many token schemes and “Initial Coin Offerings”, a controversial but financially and socially relevant use-case. While not sustainable in their current form, these examples prove the market need for a well designed, open, reasonably secure, auditable, censorship-resistant, private and scalable digital asset protocol. The fact itself that many market niches are now adopting broken models as de-facto standards for digital asset management, could represent a compelling argument for the development of better alternatives.
If the dominant Ethereum-ERC20 model for blockchain-based assets raises several serious concerns, existent alternatives still fail to address many of them. Asset-specific independent blockchains are not sustainable, while proper asset-enabled side-chains are still just a promising field of research (relying on very strong social and legal assumptions as for bootstrap and adoption). Most “meta-protocols” developed on top of Bitcoin (digital asset protocols that rely on independent validation rules, leveraging Bitcoin’s blockchain just as “proof of publication”, in order to prevent double-spending and audit issuances and reserves), while providing a potential interesting solution, completely miss the standardness/interoperability point, while showing important scalability shortcomings. The “colored coin” idea (a particular subset of Bitcoin “meta-protocol”, where most of the features of the underlying platform, such as addresses, scripts and amounts, are leveraged to maximize interoperability) has been considered promising by many, but existing implementations still show important limitations. In particular, they inherit and further exacerbate the confidentiality/fungibility shortcomings, as well as the scalability shortcomings, of the “on-chain” Bitcoin layer. As for confidentiality/fungibility, existent “colored coin” schemes heavily rely on the present serious lack of these features on Bitcoin itself: specific bitcoin amounts (often already not fungible enough in the current setting) are made even less fungible, “coloring” them in ways that greatly facilitate forensic analysis, clustering and “tainting” techniques, often invalidating external confidentiality/fungibility enhancing practices (i.e., coinjoin or other techniques where “order-based coloring” and “value-based coloring” would break) and relegating them to (pseudo)anonymity sets that will necessarily be small-to-irrelevant, for all but major asset-types. As for scalability, they inherit the typical limitations of “on-chain” Bitcoin transaction, making them worse because of the risk of perverse incentives for blockchain bloating, because of the "dust problem" and because of the lack of a trivial support for light-nodes in the form of “SPV”-like solutions (whose effectiveness is anyway seriously questioned for Bitcoin itself). Also, many of the existing implementations require a huge number of “ad hoc” deviation from the standard Bitcoin infrastructure, making their adoption difficult and full of friction and reducing the potential standardness/interoperability/leverage points of strength of the model. It is also possible that many of these first implementations just had their timing wrong (the market was not showing the current strong demand for a digital asset management standard, back when they have been conceived and implemented), and that a new, reviewed proposals could now gather more interest and momentum.
A new, better proposal for a blockchain-based asset management standard should satisfy as much as possible all the rational market requirements (standardness, auditability, blindness, possible even independence), as well as overcome many of the shortcomings of the existing alternatives. The “RGB” protocol is mostly aimed to “layer 2” scalability/fungibility strategies, but it relies for its bootstrap on a “layer 1” core, which borrows extensively from existent “colored coin” concepts, maximizing standardness properties, leveraging as much as possible the current Bitcoin infrastructure and interoperating seamlessly with it with minor, modular add-ons. This part will introduce some new modifications in respect with traditional “colored coin” implementations, aimed to reach “on-chain” levels of confidentiality/fungibility and scalability which could be considered at least close to the ones of Bitcoin itself: the adoption of the "Client Side Validation" model, a set of responsible best practices to limit and disincentivize blockchain-bloating (pay-to-contract instead of op_return), a broad (pseudo-)anonymity set for asset users, a complete independence from output ordering. Other modifications of the “layer 1” are introduced as a mean to make this protocol fully compatible with the main “layer 2”/”off-chain” standards, with a particular focus on Lightning Network, in order to seamlessly inherit all their game-changing scalability and confidentiality/fungibility features. Furthermore, the protocol proposal will contain an additional, specific and native “layer 2” solution based on the "Proofmarshal" idea.
In order to be able to compose and verify asset transactions related to a specific contract, RGB-enabled wallets must include a software module capable to analyze contracts and transactions in order to deterministically verify the compliance with the constraints specified by the kind of contract being used.
Different contract "blueprints" are defined in this specification, allowing RGB to support in a highly modular way multiple different kinds of contracts with different, predefined, behaviors.
Together with some very specific, "popular", contract blueprints (which should cover most of the use-cases), there's one more general purpose blueprint that embeds a meta-script executor, which allows very complex contract to be created.
Since any assumption of additional protocols for off-band communication weakens the standardness of the proposal, in order to implement the protocol within a Client Side Validation paradigm we leverage the only type of off-band communication already assumed as existing in most Bitcoin on-chain transactions to implement: the address passing. When a payee generates an address to give to the payer, he also transmit the coordinates of the selected Publisher Server (or collection of Publisher Servers), and he finally generates a number, hereby called “dark-tag”, passing it to the payer along with the address and the Publishing information. This feature can be developed extending the BOLT Invoice Protocol.
The scheme requires additional agreed-upon (at the transaction level) third parties which store the chain of encrypted proofs and accept related queries, possibly in a "Bloom filter" way to increase privacy (false positive can be added randomly in order to maintained even more privacy). In the context of an issued asset, these "publisher" servers could be maintained by the issuer itself. More generally, they can be maintained individually by the receivers, or by one or many independent third parties selected by the sender from a set defined by the receivers. The storage and the transmission of the proofs could be in theory achieved via decentralized systems (BitTorrent, IPFS, Siacoin, ecc.), but the censorship-resistance gains do not compensate for the increased complexity. Moreover, the Proofmarshal Integration (see below) requires a centralized third party anyway, which could be effectively leveraged for the Lightning Network Integration (see below) as well.
Being the protocol UTXO-based, it will be possible to link one or more assets to a Lightning Network channel, which becomes colored, exchanging state updates which are compliant to the asset scheme, with strong guarantees that asset distribution will be preserved also in case of non-consensual closures. In this way, it will be possible to leverage the scalability and privacy features of the Lightning Network, as well as LN-enabled atomic swaps and LN-based path discovery for decentralized asset exchange.
The protocol will also include another L2 strategy for scalability/fungibility, an asset-specific implementation of the “Proofmarshal” concept, based on “Single-Use-Seals” and “Proof-of-Publication-Ledgers”. In this integration, a Publisher Server might also act as “sealer”, with the ability to censor transactions but not to manipulate/forge/falsify them by committing multiple proofs from different anonymous users to a single UTXO. This could decouple the anti-double-spending function of the Bitcoin blockchain from the specific asset transactions, making possible to "seal" a huge number of them spending a single Bitcoin UTXO.