EVM Compatibility

Orbinum runs a standard EVM through Frontier. Solidity contracts deploy and execute unmodified, and the usual Ethereum tooling connects without a custom adapter.

What works

EVM bytecode — deploy Solidity contracts as-is
Ethereum JSON-RPC — MetaMask, Hardhat, Foundry, Remix, ethers.js, viem
Transaction types — Legacy, EIP-2930, EIP-1559, EIP-7702
EIP-1559 fee market — dynamic base fee with priority tips
Transient storage — EIP-1153
Precompiles 0x01–0x05 — ecRecover, SHA-256, RIPEMD-160, identity, modexp

The one gap: precompiles `0x06`–`0x09`

The BN128 precompiles (0x06 add, 0x07 mul, 0x08 pairing) and BLAKE2F (0x09) are not currently registered.

This affects contracts that verify ZK proofs on-chain — a snarkjs-generated Groth16Verifier.sol, Semaphore, Tornado-style mixers, or any BLS/pairing-based scheme. All of them call 0x08.

Failure mode is silent

A call to an unregistered precompile address does not revert. The EVM treats it as a call to an empty account: the call succeeds and returns empty data. A verifier contract that decodes that result as false will reject every valid proof without any error to trace.

If your contract depends on pairing operations, test it on testnet before building on top of it.

Orbinum's own privacy layer does not go through these precompiles — proofs are verified natively by pallet-zk-verifier in the runtime, which is both cheaper and faster than an in-EVM pairing check. For on-chain ZK verification, see the ShieldedPool precompile.

Network Parameters

Testnet

Field	Value
Network Name	Orbinum Testnet
Chain ID	`2700`
Native Currency	ORB (18 decimals)
RPC URL	`https://testnet-rpc.orbinum.io`
Explorer	`https://testnet-explorer.orbinum.network`

Local development

A node started with --dev uses Chain ID 42.

Mainnet is not deployed

Chain ID 270 is reserved for mainnet in the runtime genesis presets, but the network is not live. Do not configure wallets or contracts against it yet.

Custom Precompiles

Orbinum's custom precompiles are live, not planned. They expose runtime pallets directly to Solidity:

Address	Precompile	What it does
`0x…0801`	ShieldedPool	Shield, private transfer, unshield, fee claim
`0x…0802`	Balances	Pay any `AccountId32`, including Sr25519/Ed25519 accounts

Curve25519 point addition and scalar multiplication are also available at 0x…0402 and 0x…0403.

Example: paying a Substrate-native account from Solidity

This is something a plain EVM chain cannot do. The Balances precompile lets a contract send native tokens to an AccountId32 that has no EVM address at all:

// SPDX-License-Identifier: MIT
pragma solidity >=0.8.0;

interface IBalances {
    function transfer(bytes32 dest, uint256 value) external;
    function transferKeepAlive(bytes32 dest, uint256 value) external;
}

contract Payouts {
    IBalances constant balances =
        IBalances(0x0000000000000000000000000000000000000802);

    /// @param recipient AccountId32 of a Substrate-native account
    function payout(bytes32 recipient, uint256 amount) external {
        balances.transferKeepAlive(recipient, amount);
    }
}

Standard Solidity, standard tooling — the only difference is the precompile address.