> For the complete documentation index, see [llms.txt](https://sodex.com/documentation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://sodex.com/documentation/for-developers/developers/valuechain-evm/differences-from-ethereum.md).

# Differences from Ethereum

ValueChain runs an EVM for contract execution. Wallets, RPCs, and Solidity toolchains work as they do on other EVM chains. Fees, chain identity, and SoDEX product settlement do not.

## Execution environment

The execution layer matches the Pectra revision. Cancun blob transactions (EIP-4844, type-3) are not accepted. Do not send blob-carrying transactions or assume blob data is available. Legacy, access-list, and EIP-1559 transactions (types 0–2) are accepted.

Point the wallet or client at the [ValueChain network endpoints](/documentation/for-developers/developers/valuechain-evm.md#network-configuration). A contract address on Ethereum is not the ValueChain deployment of that contract. Identify tokens and protocol contracts by the address on this chain; see [Contracts](/documentation/for-developers/developers/valuechain-evm/contracts.md).

## System chain and application chains

ValueChain is a host chain with one EVM and several application chains. The EVM holds shared system state and the account layer other appchains use. Each appchain keeps that application's own transactions and state. Spot and perpetual trading run on their appchains, not as ordinary EVM contract calls.

An EVM receipt means the EVM call ran. It does not mean a trade, transfer, or vault request has finished. Use the [Trading API](/documentation/for-developers/api-reference/trading-api.md) for orders, [History & Status](/documentation/for-developers/api-reference/mirror-api/history-and-status.md) for Mirror transfers, and the [Wealth vault lifecycle](/documentation/for-developers/developers/wealth/vault-lifecycle.md) for vault requests.

## Consensus finality

Ethereum uses a 12-second slot and finalizes a block after two epochs (Gasper). ValueChain uses a **2-second slot** and **single slot finality**: a block is finalized in the slot it is proposed. After a transaction is included, consensus will not revert it. You do not need extra confirmation depth.

JSON-RPC block tags do not match Ethereum's justified / finalized lag. `eth_blockNumber` returns `latest`.

| Tag         | ValueChain                                                                                             | Ethereum                                            |
| ----------- | ------------------------------------------------------------------------------------------------------ | --------------------------------------------------- |
| `latest`    | Current head. Inclusion in this block is irreversible. Typically one slot (\~2s) ahead of `finalized`. | Current head; can reorg.                            |
| `safe`      | Same block as `finalized`.                                                                             | Approximately the justified checkpoint (\~1 epoch). |
| `finalized` | Last block exposed as the finalized checkpoint. Typically one slot behind `latest`.                    | Two-epoch finalized checkpoint.                     |
| `pending`   | Proposed next block. `hash` is `null`.                                                                 | Same idea.                                          |
| `earliest`  | Genesis.                                                                                               | Same idea.                                          |

`safe` and `finalized` are interchangeable here. The `finalized` tag is a checkpoint that lags `latest` by about one slot; it is not an extra safety wait. Libraries that wait on `finalized` therefore see about 2 seconds of lag, not Ethereum's two-epoch delay. Do not apply multi-block or multi-epoch confirmation thresholds.

That finality applies to the EVM block only. See [Transaction Finality](/documentation/for-developers/developers/valuechain-evm/transaction-finality.md).

## Gas token and fee distribution

Gas is native SOSO (18 decimals), not ETH. Native SOSO has no ERC-20 address. WSOSO and other ERC-20 balances do not pay gas.

EIP-1559 fee fields work, but the base fee is not burned: the base fee and the priority fee both go to the block builder.

A native SOSO balance is required to submit a transaction yourself. For sponsored submission, see [Relayer](/documentation/for-developers/developers/valuechain-evm/relayer.md). See [Gas & Fees](/documentation/for-developers/developers/valuechain-evm/gas-and-fees.md).

## Network identity

These chain IDs are not Ethereum's. Add ValueChain as a custom network: mainnet `286623`, testnet `138565`. Use the same chain ID in the wallet, the RPC URL, the signed transaction, and any EIP-712 domain that includes `chainId`.

```bash
curl -sS https://mainnet.valuechain.xyz \
  -H 'Content-Type: application/json' \
  --data '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'
```

The result is hex: `0x45f9f` (mainnet) or `0x21d45` (testnet).

## Transaction completion

On Ethereum, a successful receipt is often the end of the operation (the token already moved). On ValueChain, a successful EVM call may only create an asynchronous request. Track the product's own status APIs before treating the operation as complete. See [Transaction Finality](/documentation/for-developers/developers/valuechain-evm/transaction-finality.md).