I kept it previously, but it was quite annoying in the tests and usually just useless data if there's no unintentional burn. But I'm open to adding it back in.

There's already a function has_unintentional_burns, is_normal calls it but also checks if there's any failed colorings (which not necessarily generate any burns). "normal" implies there's nothing extraordinary going on.

It's not straightforward to find good names for it, maybe we can get some third opinions.

That's true, there can be tokens moved in the tx and token_is_invalid could be true at the same time.

I originally called it token_is_normal implying no failed parsings and all token entries have is_normal, but this would've changed every test that tests a Tx (since normal XEC tx would have token_is_normal true).

Maybe it's best to set this to an enum, token_status: NON_TOKEN, NORMAL, UNINTENTIONAL_BURNS. That way the default (NON_TOKEN) implies no token stuff whatsoever (neither any burns nor any failed parsing/coloring).

I'm not quite sure I understand, but let me try to explain:

We're using a oneof which is a tagged union (kind of like an enum in Rust), so we know whether it's SLP or ALP.

Both SLP and ALP have a concept of token type, which is just an integer (in both cases just a single byte), and we use a proto enum (~a named integer) to expose the integer to the user.

It's for the specific case of a "bare burn", where input tokens are burned but there's no corresponding OP_RETURN.

I've added a test for it, you can search for bare_burn in chronik_token_burn.py (note how the tx_type is unspecified i.e. NONE).

Good find, should I move it to D15369? This diff is already quite big

There's also a typo in endiannnes

It's kind of the union of all options, and if they can't be specified (like hash in ALP, or mint_vault_scripthash in everything except V2 Mint Vault) they're simply left blank.

The token_type definitively establishes which field is "the empty bytestring" vs "not specified", so IMO that's fine.

I wouldn't mind that!

I found in practice it's much easier to work with to have one unified type.

The original design actually had different types for everything and it was very annoying to always have to match on the different cases.

Think about implementing the explorer; you have to have big match blocks with branches that all basically do the same.