There are numerous areas of the transaction format that are extendable / upgradeable. Without proper handling, any new types added onto the spec could cause total failure for SDK users on older versions.

Nonexhaustive list of additive changes that could break existing SDK versions:

• New transactional variants (i.e. ScriptV2, CreateV2)
• New input or output types (i.e CoinInputV2)
• New opcodes w/ brand new gas price in the consensus params

Without handling for these new and unknown types in the SDKs, a purely additive network change could instantly break apps like:

• Explorers
• Third party indexers (i.e. envio)
• Wallets (i.e. account history)

On the Rust side, this likely requires something along the lines of a default unknown enum variant such as:

pub enum Transactions {
    Script(...)
    Create(...)
    Mint(...)
    Upload(...)
    Upgrade(...)
    Blob(...)
    #[serde(untagged)]
    Unknown // untagged variants are used to capture variants missing from the current enum definition during deserialization
}

TODO:

• Rust SDK doesn't throw unexpected errors when new types are added to the node API
• TS SDK doesn't throw unexpected errors when new types are added to the node API