Invoices

This section explores how invoices are structured and operate within a particular contract. The initial focus is on RGB identifiers, which are integral to the operation of the system and may be encountered by users in various forms. These identifiers are unique to each component of the system, including contracts, assets, and interfaces, ensuring a standardized method of identification throughout the system.

Identifiers and their encoding

Each element within the system, be it a contract, schema, interface, interface Implementation, or asset is assigned a unique identifier. These identifiers are not arbitrary strings but are carefully encoded using base58, a method chosen for its efficiency and readability. Furthermore, these identifiers are prefixed with a descriptor (in the form of a URL or URN) indicating their type, such as rgb: . This prefixing strategy ensures clarity regarding the nature of each identifier, preventing confusion with other URLs and misuse.

Enhancing Human Readability through Chunking

The concept of chunking has been introduced as a means to enhance the readability and verifiability of these identifiers. This technique, commonly used in phone and credit card numbers, breaks down long strings into smaller, more manageable segments. This feature not only aids in human parsing but also in verification processes, where checking the integrity of an identifier involves examining specific segments, such as the checksum at the end. Chunking, thereby, offers a balance between security and usability, with each chunk providing a certain level of security assurance. For example, having 256-bit strings divided into six blocks means that each chunk adds about 256/6 (~42) bits of security.

An identifier for an RGB contract could be represented, by the following ContractId encoded string:

2WBcas9-yjzEvGufY-9GEgnyMj7-beMNMWA8r-sPHtV1nPU-TMsGMQX

which, as we said, is a string in Base58 divided into different chunks to make it easier to read. The last group of characters is a checksum of the previous encoding. Finally, Base58 encoding was chosen in favor of Bech32 encoding which can have some limitations regarding readability and character size limits of the string.

Use of URLs for Invoices

A significant advantage of this identifier system is its compatibility with URLs, allowing for direct interaction with wallets through simple clicks. This contrasts sharply with the cumbersome process required by other systems, where multiple steps are needed to copy and paste identifiers into wallets.

An example of an Invoice URL for fungible tokens might be:

rgb:2WBcas9-yjzEvGufY-9GEgnyMj7-beMNMWA8r-sPHtV1nPU-TMsGMQX/RGB20/100+utxob:egXsFnw-5Eud7WKYn-7DVQvcPbc-rR69YmgmG-veacwmUFo-uMFKFb

Where

• rgb: defines the application identifier of the URL.

• The ContractId is the same as in the previous example.

• RGB20 defines the default interface which should be used to parse the contract.

• The number 100 is part of the assignment and represents the amount of requested tokens by invoice's issuer.

• The string egXsFnw-... which follows +utxob identifier is itself in the Base58 format divided into chunks, but it is neither a Bitcoin address nor a OpId. Indeed it is the concealed form of the seal definition that prevents Alice from knowing the UTXO actually held by Bob.

The URL format's simplicity and efficiency in opening wallets and facilitating transactions underscore its superiority over alternatives. Alternatives to the direct use of contract IDs, for example by using asset tickers, were considered but ultimately rejected due to security concerns and the potential for confusion. The chosen format prioritizes clarity and security, ensuring that users can easily understand and verify the details of their transactions.

The power of URLs is also expressed in the ease with which parameters such as an invoice signature can be introduced:

rgb:2WBcas9-yjzEvGufY-9GEgnyMj7-beMNMWA8r-sPHtV1nPU-TMsGMQX/RGB20/100+utxob:egXsFnw-5Eud7WKYn-7DVQvcPbc-rR69YmgmG-veacwmUFo-uMFKFb?sig=6kzbKKffP6xftkxn9UP8gWqiC41W16wYKE5CYaVhmEve

With this invoice URL format each software is to be able to interpret the part of the invoice which it is able to execute while the other parts (e.g. the ?sig part relate signature verification) can be safely discarded.

As for an extra example, in the box below an example of NFT transfer invoice is shown:

rgb:7BKsac8-beMNMWA8r-3GEprtFh7-bjzEvGufY-aNLuU4nSN-MRsLOIK/RGB21/DbwzvSu-4BZU81jEp-E9FVZ3xj-cyuTKWWy-2gmdnaxt-ACrS+utxob:egXsFnw-5Eud7WKYn-7DVQvcPbc-rR69YmgmG-veacwmUFo-uMFKFb

Where, in addition to the already described fields, the DbwzvSu-... field refers to the possibility to explicitly refer to the blob of the NFT data by the receiver.

Use of URL for Operations

As an additional example, RGB URLs can be used also for more complex operations, for instance, those related to the encoding of an issuance operation of an RGB20-interfaced contract which assigns an amount of 10000 new tokens to the issuer wallet:

rgb:2WBcas9-yjzEvGufY-9GEgnyMj7-beMNMWA8r-sPHtV1nPU-TMsGMQX/RGB20/issue/100000+utxob:egXsFnw-5Eud7WKYn-7DVQvcPbc-rR69YmgmG-veacwmUFo-uMFKFb

---