> For the complete documentation index, see [llms.txt](https://docs.qms.finance/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.qms.finance/for-developers/evm-compatibility.md).

# EVM Compatibility

This page lists what differs from Ethereum on QMS Testnet, including what is not yet available. Anything not listed here behaves as it does on Ethereum.

QMS runs a standard Ethereum execution client, a fork of Reth, with the standard Ethereum JSON-RPC API. Existing contracts, wallets, and developer tools work without modification. The differences below come from what the current release of QMS does not yet include, and from the design of the chain itself.

## Transaction types

QMS does not accept type-3 (`0x3`, "blob") transactions, the type introduced by EIP-4844 for rollups to post data to Ethereum. `eth_sendRawTransaction` and `eth_sendRawTransactionSync` reject them with the error `-32003 transaction type not supported`. Legacy (type 0), access-list (type 1), EIP-1559 (type 2), and EIP-7702 (type 4) transactions are supported.

Because no blob transaction is ever included, excess blob gas never accrues: `BLOBBASEFEE` returns the minimum of 1 wei and `BLOBHASH` returns zero for every index.

## Finality

The current release runs without the finality layer. Any request for the `safe` or `finalized` block tag returns the genesis block, on every endpoint that accepts a block tag. This is temporary and changes when the finality layer is enabled. Until then, rely on block confirmations, and check any tooling that waits for a `finalized` block before proceeding: it will either wait indefinitely or act on the genesis state.

## Fees

Gas is paid in QMS, the native token, not in ETH. The fee structure is Ethereum's EIP-1559: each transaction pays a base fee, which is burned, and an optional priority fee, which goes to the miner that includes the transaction. Tools that estimate fees with `eth_feeHistory` and `eth_maxPriorityFeePerGas` work unchanged. Some wallets instead derive the fee from `eth_gasPrice` alone and leave little or no margin above the current base fee. When the network is busy, the base fee rises from block to block, and such transactions wait until it falls back. An application can avoid this by setting `maxFeePerGas` and `maxPriorityFeePerGas` in the transaction request instead of leaving them to the wallet, for example twice the next block's base fee plus the priority fee.

## Block production

Blocks are produced by proof-of-useful-work, a proof-of-work protocol: the right to produce a block is awarded by a lottery over miners' solver runs. As on Bitcoin, block times are probabilistic rather than slot-based. The target block time on QMS Testnet is 10 seconds. Contracts that use `block.timestamp` or `block.number` as a clock should allow for that variance. `PREVRANDAO` (`block.prevrandao`, or `block.difficulty` in older code) returns zero on this release. Do not use it as a source of randomness.

## Hard fork level

The execution layer runs the Osaka hard fork from genesis, so every earlier fork, including Prague, is active. Compile for `prague`, the default in current solc and Foundry, or for `osaka`; contracts compiled for `cancun` run as well. The setting is `evm_version` in `foundry.toml` for Foundry and `evmVersion` in the Solidity settings for Hardhat.

## Accounts

Accounts use standard Ethereum signatures. The post-quantum account options described in [Why QMS](/overview/why-qms.md) are not part of the current release; there is no way to upgrade an account to post-quantum signatures on QMS Testnet.