A TokenTxEntry is for one type/kind of token in a tx (maybe a name change makes sense?), so two SLP inputs set to 0xffffffffffffffff would already overflow

Good point; "total burn" here implies that the rules have been broken and all input tokens are burned unconditionally.

What do you think about renaming it to is_invalid? That way it's clearer that the meaning is that the section doesn't contribute to the tx

Yes, I think setting the default template to zero-ish values and then overriding them would make it a bit more readable. I don't think any other field than actual_burn_amount should be set differently though, as the rest kind of forwards the fields from the coloring

Yes; a GENESIS can't ever have a token burn (because the token can't exist before it comes into existence), so using a 0 default accomplishes the same thing and is a bit more readable.

Maybe, but the flag's intention is to later remove all outputs and set them to None.

Yes, and here too the burn amount will always be 0 anyway as we can't calculate the amounts sent for unknown tokens.

Yes, absolutely, there can be XEC-only inputs, which will have None as the spent_tokens.

Yes, good point. Renaming is_total_burn might also help

does it make sense to organize SLP and ALP under the same GenesisInfo?

we might expect different token standards to diverge, use different names, different structs, etc.

i'm not familiar on what kind of duplications starting a distinct bitcoinsuite-alp would entail. Does though seem almost like a happy coincidence that both protocols have a GenesisInfo which is kinda sorta the same but not totally.

If it is best to have all the token parsing in one place -- e.g. we want to test various token txs and make sure they are not confused for one another -- mb it should be bitcoinsuite-tokens instead of bitcoinsuite-slp

I was thinking about doing an enum for the GenesisInfo, but then we'd have 3 different variants: one for SLP V1+NFT1, one for Mint Vault and one for ALP.

In the end, it's easier to just use one type where some fields are set and others are None.

Agree on the bitcoinsuite-token; the name was set a bunch of months ago before ALP even had its own name.

One thing that might be worth discussing (now that you bring it up) is how we store the GenesisInfo in the DB. Right now it's encoded using postcard, so we have to be extra careful when changing GenesisInfo, because adding a field could garble all existing GenesisInfo.

There's three ways we could do it IMO:

1. No change: Just store the GenesisInfo and hope we don't need to update, if we do, just add a few tests making sure we don't garble anything. Maybe add a test already to make sure that is possible (e.g. adding a new field at the end)
2. enum: Store an enum in the DB (either by chaning GenesisInfo to an enum or by simply adding a 1 variant DbGenesisInfo which we can later add a new variant to)
3. protobuf: Store the GenesisInfo in a protobuf encoded byte string, this way we can add and remove fields pretty freely since protobuf is optimized for this exact usecase. We'd have to add a new proto file and build it in chronik-db, similar to chronik-proto, or just add it to chronik-proto and export there.

This is probably more of a question for @Fabien

mb it should be bitcoinsuite-tokens instead of bitcoinsuite-slp

100%, though it should be another diff

Does though seem almost like a happy coincidence that both protocols have a GenesisInfo which is kinda sorta the same but not totally.

In general I would agree, but in this case it's not a happy coincidence. Both SLPv2 and ALP are SLP inheritants, so they are designed to be mostly similar and make the transition easier.
Looking at the structure the differences are very limited and imo using the same structure is the most simple and efficient solution for this special case.

we might expect different token standards to diverge, use different names, different structs, etc.

I'm expecting at least one out of the 3 standards to get deprecated before this happen to be problematic. Also I'd rather avoid adding more complicated code to fix a problem that doesn't exist (yet). Worst case the cost is a reindex.

So I prefer solution 1.