5. Contracts, state & operations

RGB contracts are bearer agreements which are being maintained independently of each other.

Each user has a partial view on the contract state.

Contract state forms: owned and global

Types of contract state. Data type system. Formal verifiability.

Definition of a contract. Interfaces, Schemata, Genesis.

State transitions.

State extensions (“decentralized genesis”). The way they work.

RGB smart contract defines state, owners of that state, and operations, which participants of the contract (owners and sometimes more broad public) can execute to update the state.

Operations include genesis operation (issuance of the contract), state transitions updating the existing state (or adding to the state data) and state extension, which represent a mechanism how anybody (public) can participate in the contract operations.

State of the contract consists of state atoms of different data types. Data types are defined in the same terms as variable types in any structural language (C, Rust, Haskell, etc).

RGB contract always have a well-defined parties of the contract, which hold ownership rights over atoms of state. The state owned by a contract party is called owned state.

Let's start with writing a simple contract managing decentralized identity backed by a PGP key. The "smartness" of the contract (comparing to normal PGP/GPG and Web of Trust) comes from the fact that when a revocation operation is executed, everybody in the world will know about it (since they can see that the UTXO, associated with the key -- the owned state -- was spent), and it can be proven whether at any given moment of time the identity was valid -- or it was already revoked.

5.5. Availability of the global state