Talking with Andrew the other day had me realize that one use of subgroup was to easily evolve token state. Parent authority redeems the old token and issues the new one. Proof of ancestry is in the first 32 bytes of the ID.
If we update the spec to include the full prevout of the genesis TX in the genData that gets hashed for newly created tokenID, then such tokenID (still only 32 bytes) itself becomes a compressed proof of ancestry with the caveat that anyone wanting to prove ancestry down the line must present the genData to whatever contract requiring such proof.
Re. group covenant, don’t they make moving such tokens awkward? When the Script is locked so that it always must be equal across the TX, with some freedom to choose among contracts one owns, it means we can’t have P2PKH outputs because covenant would lock them so that you could only send it back to the same address. With Group covenant you can’t have non-covenanted and covenanted outputs share the same tokenID. Group templates were intended to work around this limitation by providing slots that could be changed without breaking the covenant. With that we could have a typical covenant contract that would allow changing the address, some pay-to-address-template.
It allows you to carry a proof of ancestry compressed into the detached witness hash, allowing descendant transactions to “introspect” entire so witnessed history. If we had a backed token, the witness should carry proof that whatever ratio calculation was respected for all minting and melting in the past.
With a backed token, you need to have 2 pools: the backing asset (1:1 fencedBCH), and the backed token (normal group token, supply somehow tied to the supply of fencedBCH), right? Who needs to hold the backing asset i.e. the fencedBCH? If it’s only supposed to sit in issuer’s vault, then for what would he need to move fencedBCH around inside the vault? He can, but doesn’t need to. Because, to free them from the fence/vault you need to put them in the same TX with the fencedBCH authority which opens the vault. So isn’t it more practical to just keep all the fencedBCH “inside” the authority and have the whole BCH pool exist in a single such UTXO?
I think ‘fence’ feature enables one function that could be the selling point: it prohibits people from paying into this super-contract. With TX introspection support, a Script contract could be written that locks BCH and pays them out only if some token X was burned in the TX but a Script can never prohibit anyone to lock his BCH with the exact same bytecode.
PS even the current proposal supports a special case of locking some BCH, a single UTXO “fence”: the BCH amount stored in the authority/baton UTXO. Nobody can pay BCH into it or out of it without spending the previous instance of the baton. So I think even the “base” enables backed tokens (depending on introspection support). The baton becomes the backing asset vault, and the tokens it fans out are the backed tokens.