Contract Implementation in RGB

We have finally arrived at describing how an RGB contract is actually defined and implemented. In addition to Genesis, which we have discussed earlier, the definition of a contract in the RGB ecosystem is realized by two independent plus a third complementary one:

Schema which represents the data file containing the fundamental contract declarations, possible states and operations constituting its business logic.
Interface which contains the instruction to parse the contract and to expose state data to users and wallet interface.
Interface Implementation is a third complementary component that is responsible for bridging the previous two together.

In this regard, it is important to point out that each one of these components can be freely and independently developed by different parties, provided that they respect the RGB consensus rules. This represents a notable feature of the RGB ecosystem which allows an even higher degree of separation and decentralization among the building process of the different components of the contract itself.

In the picture below a general scheme of all the components together with a summary explanation is reported. In addition to this, the creation of a compiled Genesis with suitable procedures derived from the 3 components just described completes the issuance phase of a contract, which becomes then fully operational to users.

It's worth pointing out that, in order to work with an RGB contract a wallet needs to import all the 4 compiled components (Schema, Interface, Interface Implementation, and Genesis) through a contract consignment.

To give a better general view, the following table summarizes the main characteristics of each one and the equivalent terminology adopted both in Object Oriented Programming (OOP) languages and in Ethereum contract system.

In the next sections, we shall explore in more depth the role and the technicalities of each one of these constructs.

PreviousFeatures of RGB State NextSchema

Last updated 1 month ago