I’m researching how RGB uses Taproot commitments (Tapret, LNPBP-12) and ran a transfer experiment on testnet: 64a14551…c20b6b.
The RGB client output shows the state anchored at tapret1st:64a14551...c20b6b:1 — a standard P2TR output on-chain.
My understanding is that Tapret inserts an unspendable 64-byte OP_RETURN leaf into the script tree at depth 1, shifting existing scripts one level deeper. This changes the Merkle root, which changes the output key (P2TR address) via the BIP-341 tweak formula.
Two questions:
-
If Script_A was originally at depth 1 (single-leaf, empty Merkle path in the control block), after Tapret insertion it moves to depth 2. Does the original control block become invalid? Does the spender need to reconstruct it with the Tapret leaf hash included in the Merkle path?
-
Since the Merkle root changes with every new Tapret commitment, does RGB always derive a fresh P2TR address for each state transition — even if the internal key P remains the same?
