RGB FAQ
  • Welcome to RGB!
  • 💡What is RGB?
  • 📚RGB Resources
  • ⚙️RGB design principles
  • 🎓RGB paradigms
    • Single-use seals
    • Cryptographic commitments
    • Client-side validation
    • Strict encoding
  • 🔖RGB Smart contracts
    • What is a smart contract?
    • What is contract schema?
    • How does one program RGB smart contracts?
    • Do you define the validity of a state transition with Schema?
  • ☣️RGB & ₿itcoin
    • Will RGB require a fork of Bitcoin or Lightning?
    • RGB testnet & mainnet
    • Taproot, Schnorr signatures and RGB
    • Does anything need to happen in Lightning or Bitcoin to enable Lightning on RGB?
    • Is there a plan to work on channel factories?
  • 🎨RGB NFT
    • RGB NFT vs other NFT
    • What's the difference between RGB design of NFTs and common NFT approach?
  • ❓FAQ
    • What is RGB?
    • What does 'RGB' stand for?
    • Is RGB a new blockchain?
    • What can I do with RGB?
    • Is it possible to create a DAO with RGB?
    • RGB vs alternatives
    • Is RGB Turing-complete?
    • Does RGB require Taproot?
    • What RGB is compatible with?
    • Will Simplicity be used in RGB?
    • Why there is no RGB MVP with updates rolling out after?
    • How is confidentiality reached in RGB?
    • How is safety reached in RGB?
    • What is client-side validation?
    • How scalable is RGB?
    • Is there an RGB "Hello World" guide?
  • 📖Glossary
    • Contracts
      • ContractId
      • NodeId
      • Node
      • State
      • State assignment
      • State transition
      • Assignment
      • Assignment variant
      • State data
      • State type
      • Metadata fields
      • Metadata
      • Data type
      • Genesis
    • AluVM
    • Bifrost
    • Client-side validation
    • Contractum
    • Deterministic Bitcoin commitments
      • Container construction/deconstruction
      • Container
      • Commitment
      • Commitment embedding
      • LockScript
      • Proof
      • Protocol-specific entropy
      • Supplement
    • Right
    • Schema & Scripts
      • Schema
      • Field type
      • Assignment type
      • Bit dimensions
      • ABI
      • Script library
      • Occurence boundaries
      • Script extensibility
      • Transition type
    • Single-use seals
      • Witness
      • Seal definition
      • Seal blinding
      • Multimessage commitments
      • Seal closing over message
    • Stash
      • Stash
      • Consignment
      • Disclosure
      • Anchor
      • Forget procedure
      • Merge procedure
      • Validate procedure
      • Conceal procedure
      • Consign procedure
    • Encodings
      • Merklization commitment encoding
      • Storage encoding
      • Strict encoding
      • Pedersen commitments
      • Blinding factors
      • Buletproofs
      • Conceal
      • Commitment encoding
  • 🙋Community
    • Developer calls
    • Presentation slides
    • YouTube
    • Getting familiar with RGB
    • Articles & interviews on RGB
Powered by GitBook
On this page
  • What does Schema define and describe?
  • From technical perspective, RGB Schema defines the following:

Was this helpful?

  1. Glossary
  2. Schema & Scripts

Schema

RGB Schema is a “blueprint”/standard for constructing RGB smart contracts. The way ERC defines token standards used for integration of Ethereum contract that issues some tokens into wallets and exchanges, Schema defines a standard for RGB assets (fungible assets, collectibles, digital identities etc.).

When an issuer defines some issuance contract, in order to be supported by wallets/exchanges it must stick to (“validate against”) particular Schema.

When wallets and exchanges get information (data and contract) about some asset, they need to validate it against a specific Schema, that needed to be used for creating the asset. Only if the validation against that Schema is passed, they can accept the request and start working with the asset.

Wallets or exchanges will always use Schema-based libraries (for example “RGB fungible assets”, “RGB collectibles”) instead of complex & universal core RGB library. From technical standpoint, Schema describes actual requirements for the state transition validation outside of the level of Bitcoin script commitments. It allows simple updates without software modifications, so that wallets, explorers, LN nodes etc could accept new types of assets without any code changes.

What does Schema define and describe?

  1. Types of metadata and their value restrictions (maximum length for strings, maximum value for integers etc).

  2. Types of rights (i.e. state) and their value restrictions.

  3. How rights transfers (state transitions) can be organized:

    • which metadata they should provide

    • which rights can be (or must be) transferred jointly

    • history validation rules for each of the rights, defined using Simplicity (such as 'the sum of outputs must be equal to the sum of inputs).

  4. How these rules can be further limited (or extended) at the level of genesis and individual state transitions.

From technical perspective, RGB Schema defines the following:

  • Types of state transitions

  • Types of seals transitions

  • Semantics for state

  • Semantics for metadata

  • Referenced Simplicity script modules

  • Additional constraints on each type of state transition:

    • Which seals may be defined by the state transition

    • Which state may be associated with each seals

    • Which metadata is required, optional and prohibited

    • Which additional scripts and with which constraints may be defined

PreviousSchema & ScriptsNextField type

Last updated 3 years ago

Was this helpful?

📖