From 74bb62c38b08a7a28b8076d1cbeb8ed92a5ae7f6 Mon Sep 17 00:00:00 2001 From: step Date: Wed, 11 Mar 2026 17:56:24 +0100 Subject: [PATCH 1/4] align docs to dropped support for replace transitions --- .../schema/supported-schemas.md | 12 ++---------- 1 file changed, 2 insertions(+), 10 deletions(-) diff --git a/rgb-contract-implementation/schema/supported-schemas.md b/rgb-contract-implementation/schema/supported-schemas.md index a86f86c..6c3ad36 100644 --- a/rgb-contract-implementation/schema/supported-schemas.md +++ b/rgb-contract-implementation/schema/supported-schemas.md @@ -58,7 +58,7 @@ The following operations are supported for the asset: ## IFA (Inflatable Fungible Asset) -This schema defines a non-inflatable fungible asset, involving the following data: +This schema defines an inflatable fungible asset, involving the following data: - AssetSpec: groups basic asset information, namely: - Ticker: short identifier of the asset, to be displayed on wallets and exchanges (e.g.: BTC, USDT, ...). Note that there is no guarantee of uniqueness @@ -80,13 +80,9 @@ This schema defines a non-inflatable fungible asset, involving the following dat Additionally to the owned state representing the asset's allocation, an IFA asset can -optionally define two rights: +optionally define rights: - Inflation: represents the right to inflate the asset by a certain amount, using this right will reduce the remaining inflation amount -- Replace: represents the right to "stamp" an allocation, so that wallets trusting the - replace right owners can avoid validating the history from this operation back to - genesis. It's always possible, provided that the CSV data is available, to perform - full trustless validation The following operations are supported for the asset: - Transfer: send some amount of assets to a number of destinations (optionally including @@ -95,10 +91,6 @@ The following operations are supported for the asset: - Inflate: use an inflation right to issue a certain amount of assets in circulation, which can be optionally split into more than one allocation. The remaining inflation right (if any) can also optionally be split into more than one allocation -- Replace: use a replace right to certify that the history of a set of allocations back - to genesis is valid. This "stamp" can be used by wallets to skip part of the - consignment validation, provided that they trust the issuer (or their delegates for - replace operations) - Burn: burn a number of (asset or right) allocations by adding them as input to a transition with no outputs. It allows to prove to a third party that those allocations no longer exist, e.g. as part of a protocol with wider scope From e756eb1a78bf02f18ed9c86dd241b006eee9b201 Mon Sep 17 00:00:00 2001 From: step Date: Wed, 11 Mar 2026 18:11:24 +0100 Subject: [PATCH 2/4] clarify requirements checked during validation --- rgb-state-and-operations/state-transitions.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/rgb-state-and-operations/state-transitions.md b/rgb-state-and-operations/state-transitions.md index 94237e5..61fb7ba 100644 --- a/rgb-state-and-operations/state-transitions.md +++ b/rgb-state-and-operations/state-transitions.md @@ -20,8 +20,8 @@ This time the explanation **contains an important difference**: Bob is not simpl 4. After that, Alice, using some [PSBT](../annexes/glossary.md#partially-signed-bitcoin-transaction-psbt) wallet tool, prepares a transaction that spends the UTXO that was indicated by the previous seal definition (the very same one that granted her ownership of some elements of the contracts). In this transaction, which is a [witness transaction](../annexes/glossary.md#witness-transaction), Alice embeds in one output a commitment to the new state data that uses [Opret](../commitment-layer/deterministic-bitcoin-commitments-dbc/opret.md) or [Tapret](../commitment-layer/deterministic-bitcoin-commitments-dbc/tapret.md) rules depending on the chosen method. As explained earlier, Opret or Tapret commitments are derived from an [MPC](../annexes/glossary.md#multi-protocol-commitment-mpc) tree which may collect more than one contract's state transition. 5. Before transmitting the transaction thus prepared, Alice passes to Bob a data packet called [Consignment](state-transitions.md) which contains the organized stash of client-side data already in possession of Alice in addition to the new state. Bob, at this point, using RGB consensus rules: - * **Validates every RGB state transition** in the Consignment, including the one creating some New State assigned to his own UTXO. - * **Verifies** that every RGB state transition **is committed to in a valid [witness transaction](../annexes/glossary.md#witness-transaction)**, ensuring **legitimacy** and **uniqueness** of the whole history from Genesis to the new state. + * **Validates every RGB state transition** in the Consignment, including the one creating some New State assigned to his own UTXO, proving the **legitimacy** of the allocations' history. + * **Verifies** that every RGB state transition **is committed to in a valid [witness transaction](../annexes/glossary.md#witness-transaction)**, ensuring that the corresponding seals are properly closed. This implies the **completeness** of the history from Genesis to the new state, since spending an allocation requires closing the corresponding seal, which is defined by the parent transition and must be present in **revealed** form in the consignment for the validation to pass. 6. After checking the correctness of the Consignment, Bob may optionally give Alice a "go-ahead" signal (e.g., by GPG signing the [consignment](../annexes/glossary.md#consignment)). Alice, even without Bob's clearance, can now broadcast this last witness transaction, containing the New State. Once confirmed, such a witness transaction represents the conclusion of the [State Transition](../annexes/glossary.md#state-transition) from Alice to Bob. For the detailed process of a contract transfer with the RGB stack, see the [related section](../annexes/contract-transfers.md). From e3448fc30d6cd49c799535bfdacb0399a1fc9734 Mon Sep 17 00:00:00 2001 From: Stefano Pellegrini <33753050+St333p@users.noreply.github.com> Date: Mon, 16 Mar 2026 11:19:57 +0100 Subject: [PATCH 3/4] Update rgb-contract-implementation/schema/supported-schemas.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Zoe Faltibà <7492268+zoedberg@users.noreply.github.com> --- rgb-contract-implementation/schema/supported-schemas.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rgb-contract-implementation/schema/supported-schemas.md b/rgb-contract-implementation/schema/supported-schemas.md index 6c3ad36..743be0d 100644 --- a/rgb-contract-implementation/schema/supported-schemas.md +++ b/rgb-contract-implementation/schema/supported-schemas.md @@ -82,7 +82,7 @@ This schema defines an inflatable fungible asset, involving the following data: Additionally to the owned state representing the asset's allocation, an IFA asset can optionally define rights: - Inflation: represents the right to inflate the asset by a certain amount, using this - right will reduce the remaining inflation amount + right will reduce the remaining inflatable amount The following operations are supported for the asset: - Transfer: send some amount of assets to a number of destinations (optionally including From 19ebb71729e1c50dbb679b01da166b03d5e9e6fd Mon Sep 17 00:00:00 2001 From: step Date: Mon, 16 Mar 2026 11:53:02 +0100 Subject: [PATCH 4/4] add contract linking to IFA --- .../schema/supported-schemas.md | 18 ++++++++++++++---- 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/rgb-contract-implementation/schema/supported-schemas.md b/rgb-contract-implementation/schema/supported-schemas.md index 743be0d..e478d2e 100644 --- a/rgb-contract-implementation/schema/supported-schemas.md +++ b/rgb-contract-implementation/schema/supported-schemas.md @@ -77,12 +77,19 @@ This schema defines an inflatable fungible asset, involving the following data: - RejectListUrl: an optional URL where the issuer can provide a list of operations that should be considered invalid. This cannot be enforced by the issuer due to the nature of client side validation, and wallets are free to ignore it - +- LinkedFromContract, LinkedToContract: optional `ContractId`s that should be considered + equivalent economic objects as the current asset, may be used by the issuer to update + an asset to a different schema or a different version of the IFA schema. The contract link + from `A` to `B` should only be considered valid if `A.LinkedToContract` is `B` + AND `B.LinkedFromContract` is `A`; this guarantees that the issuers of both assets + are willing to consider them the same economic structure Additionally to the owned state representing the asset's allocation, an IFA asset can optionally define rights: -- Inflation: represents the right to inflate the asset by a certain amount, using this - right will reduce the remaining inflatable amount +- Inflation: allows its owner to inflate the asset by a certain amount, using this right + will reduce the remaining inflatable amount +- Link: allows its owner to link the current asset to another one, by setting a value to + the `LinkedToContract` global state The following operations are supported for the asset: - Transfer: send some amount of assets to a number of destinations (optionally including @@ -94,11 +101,14 @@ The following operations are supported for the asset: - Burn: burn a number of (asset or right) allocations by adding them as input to a transition with no outputs. It allows to prove to a third party that those allocations no longer exist, e.g. as part of a protocol with wider scope +- Link: Link this asset to another linkable one. This operation can be done at most once + in the life of a contract, hence the corresponding right is lost after this operation + is performed ## PFA (Permissioned Fungible Asset) This schema defines a permissioned, non-inflatable fungible asset, in which the issuer -needs to explicitly authrize every transfer; e.g. it may be used to represent company shares, +needs to explicitly authorize every transfer; e.g. it may be used to represent company shares, for which there are legal constraints on the potential owners. It involves the following data: - AssetSpec: groups basic asset information, namely: - Ticker: short identifier of the asset, to be displayed on wallets and exchanges.