9. Execution Router

The Execution Router is the central architectural switchboard that sits between the consensus layer and the smart contract virtual machines. When a block is finalized, the consensus engine passes the ordered transactions to the Execution Router. The router examines each transaction and dynamically dispatches execution to either the KEVM or the KVM on a per-call basis.

9.1 How the Engine is Chosen

The Execution Router determines the execution target by inspecting the bytecode stored at the destination account address:

When an account is called, the router reads the first 4 bytes of its stored code. If the code begins with the exact 4-byte magic prefix:

4B 56 4D 00  (ASCII: "KVM\0")

The router instantiates a KVM execution context and dispatches the call to the KVM register interpreter. If the code does not begin with this prefix (or if the target account has no code, indicating a native value transfer to an EOA), the router defaults execution to the KEVM Cancun engine.

Because 0x4B is an undefined opcode in the Ethereum Virtual Machine specification (and will cause an immediate EVM instruction trap if executed), no valid Solidity contract will ever begin with the KVM\0 prefix. This enables 100% collision-free routing.

9.2 Cross-VM Calls

Kortana provides seamless, bidirectional Cross-VM Interoperability. Smart contracts deployed in Solidity on the KEVM can call Quorlin contracts on the KVM, and Quorlin contracts on the KVM can invoke Solidity contracts on the KEVM.

Because the Execution Router sits above both virtual machines, a cross-VM call is handled identically to an intra-VM call. When a Solidity contract makes a standard STATICCALL or CALL to an address holding KVM bytecode, the EVM host environment pauses, delegates execution to the router, the router executes the KVM module, and the return data or revert reason is passed seamlessly back into the EVM memory space.

9.3 Shared State Trie & Gas Meter

Both the KEVM and the KVM operate directly against the same underlying Merkle-Patricia State Trie and consume gas from the same unified gas meter.

A transaction begins execution with a fixed gas budget defined by its gas_limit. If a transaction begins in Solidity on the KEVM, calls a Quorlin token contract on the KVM, and then calls back into another Solidity contract on the KEVM, every instruction across both engines deducts gas from the single transaction gas meter. Furthermore, all balance transfers, storage slot mutations, and account creations write directly to the single shared state trie, guaranteeing full ACID transactional atomicity.

9.4 Why Alternatives Were Rejected

During protocol architecture design, three alternative routing mechanisms were evaluated and rejected:

1. Address Prefix Routing (Rejected): Partitioning addresses by prefix (e.g., 0x01... for EVM and 0x02... for KVM) was rejected because Ethereum's CREATE2 opcode allows deployers to grind salt values to generate addresses with arbitrary leading bytes, creating dangerous address collision and spoofing vulnerabilities.
2. Account State Trie Field (Rejected): Adding a dedicated vm_type enumeration field to the AccountState struct was rejected because changing the account serialization schema would alter the RLP hash of every account, breaking full Ethereum Yellow Paper compatibility and forcing a complex state migration for data already present in the bytecode prefix.
3. On-Chain Registry Contract (Rejected): Using a central registry contract to track VM types was rejected because querying an external contract on every call introduces massive latency, gas overhead, and introduces the risk of registry desynchronization.

---