Summary
NFT_TOKENOP_HEIGHT must stay dormant (u64::MAX) until the apply/storage layer ships. The wire format and fork gates are in, but no handler turns a parsed NFT TokenOp into state. Activating the fork now would halt the chain.
Verified state (not assumed — checked against code)
Shipped:
- Wire format:
TokenOp::{DeployNft, MintNft, TransferNft, BurnNft, ApproveNft, SetApprovalForAll} + SRC-1155 variants in crates/sentrix-primitives/src/transaction.rs. Nodes can parse these txs.
- Three gate sites, all reject pre-fork:
crates/sentrix-core/src/block_executor/validate.rs:247 (Pass-1 validate)
crates/sentrix-core/src/block_executor.rs:531 (Pass-1 dispatch)
crates/sentrix-core/src/block_executor.rs:909 (Pass-2 apply) — also rejects post-fork with "NFT TokenOp dispatch handlers not yet wired (Phase B follow-up PR)".
NOT shipped (the gap):
ContractRegistry / SRC20Contract in crates/sentrix-core/src/vm.rs is purely fungible: amount: u64, balance_of, mint/burn/transfer/approve. No token_id, no owner_of, no per-token owner map, no token_type.
- No NFT storage tables in
sentrix-storage.
- No apply handler functions anywhere.
Why activating now halts the chain
Post-fork the two passes disagree:
Pass-1 (validate): gate opens → NFT tx accepted as VALID
Pass-2 (apply): still returns Err("handlers not yet wired")
⇒ a valid-looking NFT tx enters the mempool, a proposer includes it in a block,
every validator then fails to apply that block → block cannot finalize
→ chain STUCK at that height
Note: the validator process does not panic/abort (Audit L3 replaced the old unreachable!() with a graceful InvalidTransaction). The halt is via an unappliable block, not a crash — same operational outcome (chain stops), subtler mechanism.
What "wire the apply path" requires
Activation discipline
Same as every consensus fork on Sentrix: implement → testnet bake → mainnet halt-all + simultaneous-start with NFT_TOKENOP_HEIGHT=<height> on all validators. Do not flip the gate before the apply path is merged and baked.
Summary
NFT_TOKENOP_HEIGHTmust stay dormant (u64::MAX) until the apply/storage layer ships. The wire format and fork gates are in, but no handler turns a parsed NFTTokenOpinto state. Activating the fork now would halt the chain.Verified state (not assumed — checked against code)
Shipped:
TokenOp::{DeployNft, MintNft, TransferNft, BurnNft, ApproveNft, SetApprovalForAll}+ SRC-1155 variants incrates/sentrix-primitives/src/transaction.rs. Nodes can parse these txs.crates/sentrix-core/src/block_executor/validate.rs:247(Pass-1 validate)crates/sentrix-core/src/block_executor.rs:531(Pass-1 dispatch)crates/sentrix-core/src/block_executor.rs:909(Pass-2 apply) — also rejects post-fork with"NFT TokenOp dispatch handlers not yet wired (Phase B follow-up PR)".NOT shipped (the gap):
ContractRegistry/SRC20Contractincrates/sentrix-core/src/vm.rsis purely fungible:amount: u64,balance_of, mint/burn/transfer/approve. Notoken_id, noowner_of, no per-token owner map, notoken_type.sentrix-storage.Why activating now halts the chain
Post-fork the two passes disagree:
Note: the validator process does not panic/abort (Audit L3 replaced the old
unreachable!()with a gracefulInvalidTransaction). The halt is via an unappliable block, not a crash — same operational outcome (chain stops), subtler mechanism.What "wire the apply path" requires
ContractRegistry(currently SRC-20-only).DeployNft / MintNft / TransferNft / BurnNft / ApproveNft / SetApprovalForAlland the SRC-1155 batch ops."handlers not yet wired"reject atblock_executor.rs:909once handlers land.NFT_TOKENOP_HEIGHTis pinned.Activation discipline
Same as every consensus fork on Sentrix: implement → testnet bake → mainnet halt-all + simultaneous-start with
NFT_TOKENOP_HEIGHT=<height>on all validators. Do not flip the gate before the apply path is merged and baked.