Expand description
Data structures and APIs related to RGB data storage and data exchange tasks.
There are two main APIs which may be used to access RGB contract data (both
client-side-validated and data containers): Stash API and [GraphAPI].
They differ in the fact that Stash manages long-term persistance of
large-volume data, while [GraphAPI] is used by the data structures fitting
into the computer memory (Consignments and Disclosures).
These data structures are not part of the client-side-validation
commitments (like [ConsensusCommit] and [CommitEncode]), however, some
of them MAY participate client-side-validation process (see
[Consignments]) or MAY have a restricted forms of validation (see
Disclosure), while others are constantly maintained in valid state by
the data management procedures (Stash).
Structs
Unique state transition bundle identifier equivalent to the bundle commitment hash
Iterator over transitions and corresponding witness transaction ids which
can be created out of consignment data. Transitions of this type must be
organized into a chain connecting 1-to-1 via the provided connected_by
during iterator creation.
Consignment represents contract-specific data, always starting with genesis, which must be valid under client-side-validation rules (i.e. internally consistent and properly committed into the commitment layer, like bitcoin blockchain or current state of the lightning channel).
Disclosure purpose is to expose a set of stash data related to number of RGB contracts to some external entity – or store them outside of the stash to be merged lately upon a certain event (for instance, withness transaction being mined or receiving a signature for the updated channel state from an LN channel counterparty).
Enums
Errors accessing graph data via GraphApi.
Constants
Traits
Trait defining common data access API for all storage-related RGB structures
Top-level structure used by client wallets to manage all known RGB smart contracts and related data.