Invoices
Last updated
Last updated
This section explores how invoices are structured and operate within a particular . 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 and assets, ensuring a standardized method of identification throughout the system.
Each element within the system, be it a contract, schema or asset, is assigned a unique identifier. These identifiers are prefixed with a descriptor (in the form of a URL or URN) indicating their type, such as rgb:, which clarifies their nature.
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:
2whK8s5O-b1LG4rR-OhXpDq1-SjyHvKx-OhTEFjQ-aba0V_o
which, as we said, is a string divided into different chunks to make it easier to read.
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:2whK8s5O-b1LG4rR-OhXpDq1-SjyHvKx-OhTEFjQ-aba0V_o/RWhwUfTMpuP2Zfx1~j4nswCANGeJrYOqDcKelaMV4zU/cR/bc:utxob:x8H6O_~H-7RyndJZ-CAUUAcF-RJfWg7H-9hew6Zo-pacK97w-gaGhQ
Where
rgb: defines the application identifier of the URL.
The ContractId is the same as in the previous example.
RWhwUfTMpuP2Zfx1~j4nswCANGeJrYOqDcKelaMV4zU defines the schema which the contract should implement.
The string cR represents the amount of the requested tokens encoded in a Base32 alphabet with no digits.
The string bc:utxob:x8H6O_~H... is the of the that prevents Alice from knowing the UTXO actually held by Bob. The part following the bc:utxob: identifier is encoded in Baid64.
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:2whK8s5O-b1LG4rR-OhXpDq1-SjyHvKx-OhTEFjQ-aba0V_o/RWhwUfTMpuP2Zfx1~j4nswCANGeJrYOqDcKelaMV4zU/cR/bc:utxob:x8H6O_~H-7RyndJZ-CAUUAcF-RJfWg7H-9hew6Zo-pacK97w-gaGhQ?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:jgOr8JoA-BSmFO9S-Z0_hGE~-pV6VQf8-d0phP06-obTe8Go/~6rjymf3GTE840lb5JoXm2aFwE8eWCk3mCjOf_mUztE/1@0/bc:utxob:x8H6O_~H-7RyndJZ-CAUUAcF-RJfWg7H-9hew6Zo-pacK97w-gaGhQ
Where, in addition to the already described parts, the 1@0 part shows that a receiver can explicitly ask to for the fraction 1 of an UDA token with index 0.