10. KEVM — Ethereum Virtual Machine

Kortana's EVM integration provides unmodified support for standard Ethereum tooling.

10.1 EVM Revision: Cancun

Kortana runs the Cancun (EVMC_CANCUN) revision of the EVM.

10.2 `evmone` Integration

The KEVM is powered by evmone via the standard EVMC API, ensuring exact byte-for-byte behavioral parity with Ethereum mainnet execution.

10.3 Precompiles

Standard Ethereum precompiles are natively implemented in C++ for maximum performance:

0x01 ecrecover
0x02 sha256
0x03 ripemd160
0x04 identity
0x05 modexp (EIP-198)
0x06 ecadd (alt_bn128 addition)
0x07 ecmul (alt_bn128 scalar multiplication)
0x08 ecpairing (alt_bn128 pairing check)
0x09 blake2f (EIP-152)

10.4 System Contracts (Read-Only)

Kortana exposes its native chain data to EVM contracts through read-only system contracts:

0x...0100: Chain Information
0x...0101: Staking State
0x...0102: Governance State

[!TIP] These are deliberately read-only. Modifying staking state via the EVM could lead to situations where a transaction reverts but consensus state changes remain committed.

10.5 Reserved Address Range

Addresses below 0x0200 are reserved. Any value sent to a precompile or reserved address is not credited to an account—the call reverts immediately.

10.6 EVM Deployment

EVM deployment follows standard Ethereum semantics: the transaction contains init code, which executes once and returns the runtime code to be stored at the address.

10.7 Known EVM Limitations

PREVRANDAO Returns Zero: Kortana derives randomness from dPOH, not a beacon chain. PREVRANDAO deterministically returns zero. Do not use it for randomness.
Blob Opcodes: BLOBHASH and BLOBBASEFEE return zero. There are no EIP-4844 blob transactions on Kortana.
No Filter API: eth_newFilter is not implemented. Use eth_getLogs or WebSockets.