9. Execution Router

The Execution Router is the entry point for all smart contract calls. It dynamically dispatches calls to either the KEVM or the KVM on a per-call basis.

9.1 How the Engine is Chosen

The router inspects the code of the target address. If the first four bytes are the magic prefix 4B 56 4D 00 ("KVM\0"), the router dispatches the execution to the KVM. Otherwise, it defaults to the EVM.

Because 0x4B is not a defined EVM opcode, no valid EVM contract will accidentally begin with this prefix.

9.2 Cross-VM Calls

EVM contracts can call KVM contracts, and KVM contracts can call EVM contracts. Because the router sits above both engines, a cross-VM call is handled exactly like an intra-VM call. The callee's bytecode prefix determines how it runs.

9.3 Shared State Trie & Gas Meter

Both engines share exactly one Merkle-Patricia state trie and one gas meter. A transaction starts with a set gas limit; whether it bounces back and forth between KVM and EVM ten times during execution, it deducts from the same gas meter and writes to the same world state.

9.4 Why Alternatives Were Rejected

Address Prefix: Relying on address prefixes (e.g., 0x... vs a specific bytecode hash prefix) was rejected because CREATE2 allows deployers to grind salts to spoof prefixes.
State Trie Field: Adding a vm_type field to the account state was rejected because it would change every account's RLP hash, forcing a state-root migration for information the bytecode already carries.
Registry Contract: Using a registry was rejected as it introduces an extra lookup on every single call and risks disagreeing with the code it describes.