You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 9, 2023. It is now read-only.
Currently, RGB Node nodes not provide an API to access metadata of the contract nodes. The rationale was that it is impossible to detect whether metadata in a node are invalid/replaced with a new metadata of a node descendant: each node may have zero to many descendants and it is impossible to define a rules for state invalidation without the use of single-use-seals (which are not used for the metadata).
It was intended that all state should be defined with single-use-seal-based owned state mechanism. However, certain scenarios make this definition impossible: for instance, when the state is updated by the state transition which does not allow further state modification and, thus, does not defines new single-use-seals.
To cover such cases (which include a case of asset naming and renomination for RGB20 and RGB21 schemata) it is advised to expose an API which will return a metadata for a given contract node ID. This will allow client libraries to do a custom state conflict resolution and apply schema-specific logic to access particular metadata (such as asset name).
The text was updated successfully, but these errors were encountered:
Currently, RGB Node nodes not provide an API to access metadata of the contract nodes. The rationale was that it is impossible to detect whether metadata in a node are invalid/replaced with a new metadata of a node descendant: each node may have zero to many descendants and it is impossible to define a rules for state invalidation without the use of single-use-seals (which are not used for the metadata).
It was intended that all state should be defined with single-use-seal-based owned state mechanism. However, certain scenarios make this definition impossible: for instance, when the state is updated by the state transition which does not allow further state modification and, thus, does not defines new single-use-seals.
To cover such cases (which include a case of asset naming and renomination for RGB20 and RGB21 schemata) it is advised to expose an API which will return a metadata for a given contract node ID. This will allow client libraries to do a custom state conflict resolution and apply schema-specific logic to access particular metadata (such as asset name).
The text was updated successfully, but these errors were encountered: