EVM

The EVM on Tenzro Network runs Solidity and Vyper contracts with the standard Ethereum JSON-RPC, so existing wallets and tools (Foundry, Hardhat, viem, ethers and EIP-1193 browser wallets) work unchanged. It is one of three runtimes on the same ledger; see Multi-VM runtime. Gas is paid in TNZO under an EIP-1559-style fee market, and every account's TNZO appears to contracts as the wTNZO ERC-20.

Connect

Point any Ethereum tool at the public endpoint and read the chain id from the node rather than hard-coding it:

curl -s https://rpc.tenzro.com \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'

import { createPublicClient, http } from "viem";

const client = createPublicClient({ transport: http("https://rpc.tenzro.com") });
const chainId = await client.getChainId();
const block = await client.getBlockNumber();

Supported methods include eth_chainId, eth_blockNumber, eth_getBalance, eth_getCode, eth_getStorageAt, eth_call, eth_estimateGas, eth_gasPrice, eth_feeHistory, eth_getLogs, eth_getTransactionReceipt and eth_sendRawTransaction. Reads are open. eth_sendRawTransaction carries its own signature from the paying account, as every state-changing call on Tenzro Network must; see RPC access.

Read the chain id from eth_chainId; the CAIP-2 identifier is eip155:<chain id> for EVM tooling and tenzro:<reference> in the chain-agnostic namespace.

Deploy a contract

Deploy with your usual tool, or with the CLI:

forge build
BYTECODE=$(jq -r .bytecode.object out/Meter.sol/Meter.json)
tenzro contract deploy \
  --vm evm \
  --bytecode "$BYTECODE" \
  --deployer 0xYOUR_ADDRESS \
  --rpc https://rpc.tenzro.com

tenzro contract call sends a call to a deployed contract, and tenzro contract card <ADDRESS> shows its code hash, upgrade policy and build attestations.

Execution guarantees

• Deterministic block time. block.number and block.timestamp come from the finalised block, never from a validator's clock, so every node computes the same result. Deadlines, rental epochs and permit expiries behave identically everywhere.
• Parallel execution. Blocks run under Block-STM. Results are identical to sequential execution in block order; contracts need no changes.
• One balance. wTNZO is a pointer to the account's native TNZO. A wTNZO transfer moves the native balance, and the SVM and DAML views update in the same block.
• Standard precompiles. ecRecover, SHA-256, RIPEMD-160, identity, ModExp, the BN254 add, multiply and pairing precompiles, BLAKE2f, the EIP-2537 pairing-curve precompiles, and EIP-7951 P256VERIFY at 0x100. P256VERIFY lets a contract check a passkey or Secure Enclave signature directly, which is how hardware-rooted keys authorise smart-account actions.

Tenzro precompiles

Tenzro precompiles are native functions at fixed addresses that contracts call like any other contract. They run inside ordinary EVM transactions, their results are part of the block, and they are metered in gas. They let a contract act on evidence produced elsewhere on the network without trusting an off-chain oracle.

A contract calls a precompile with staticcall and reads a single result word (1 for valid, 0 for invalid):

// TEE_VERIFY is the precompile's fixed address.
// Pay a provider only if its attestation verifies.
(bool ok, bytes memory out) = TEE_VERIFY.staticcall(attestationReport);
require(ok && abi.decode(out, (uint256)) == 1, "attestation invalid");

The same checks are available off-chain over RPC for clients that only need an answer: tenzro_verifyTeeAttestation, tenzro_verifyZkProof and tenzro_verifyVrfProof (all open). See TEE, ZK proofs and VRF.

Passkey accounts

A passkey account sends native transactions signed by a passkey its keystore links; consensus checks the passkey against the account's keystore. Value and authority change only in consensus, so there is no separate user-operation path. See Device linking and recovery.

Wallet interfaces

A site talks to a Tenzro wallet through the standard browser interfaces, so viem, wagmi and other wallet libraries work unchanged:

• Discovery and requests. The wallet announces itself with EIP-6963 and answers EIP-1193 request calls. eth_requestAccounts connects the account in the wallet window, where the passkey approves.
• Call batches (ERC-5792). wallet_sendCalls sends up to 16 calls as one transaction from the account, approved once by the passkey; every call applies or none does. wallet_getCapabilities reports atomic: { status: "supported" }, and wallet_getCallsStatus reports the batch from its transaction receipt (the batch id is the transaction hash).
• Permissions (ERC-7715). wallet_requestExecutionPermissions with the native-token-periodic type gives one of the user's agents a spend limit per hour or per day, with an optional expiry rule. The limit is written into the agent's Terms in consensus, and every validator checks each of the agent's actions against it. The agent acts through its serving nodes rather than a delegation contract, so the answer's delegationManager is the zero address and its context names the agent. wallet_revokeExecutionPermission sets the agent's spend limits to zero.
• Sponsored fees. A sponsor can send an account's keystore changes and agent Terms with the passkey's approval inside and pay their fee. A call batch is paid by the account that sends it, so paymasterService is reported as unsupported for batches.

Contracts written for Ethereum account abstraction run as they do on Ethereum. ERC-4337 accounts and EntryPoint v0.9 hash and pack user operations exactly as on Ethereum (including the v0.9 paymaster signature and the EIP-7702 init code), ERC-7579 accounts and modules use the standard selectors and execution encoding, and P256VERIFY at 0x100 follows EIP-7951. The network itself runs no user-operation mempool or bundler: a passkey account's transactions are native and verified in consensus.

EIP-7702 delegation

EIP-7702 lets an ordinary account run smart-account code at its existing address. The account signs an authorisation over (chain_id, delegate_address, nonce); once installed, the account's code becomes the 23-byte designator 0xef0100 || delegate_address and calls into the account execute the delegate's code in the account's own storage. Delegating to the zero address revokes.

Install a delegation with a standard EIP-7702 transaction (type 4) signed by the account and sent through eth_sendRawTransaction; any wallet library that supports EIP-7702 can build it. Read the active delegation back:

tenzro identity delegation7702 --authority 0xYOUR_ADDRESS --rpc https://rpc.tenzro.com

The JSON-RPC method is tenzro_get7702Delegation, which returns { "delegated": false } when no delegation is active. Delegations persist in chain state.

Permit2

Permit2 lets an account sign one expiring, bounded authorisation that a named spender uses to pull tokens, so an agent can pay for a service without a separate approval transaction. Tenzro Network implements SignatureTransfer with EIP-712 typed data:

TokenPermissions          { token, amount }
PermitTransferFrom        { permitted, spender, nonce, deadline }
PermitWitnessTransferFrom { permitted, spender, nonce, deadline, witness, witness_type_name, witness_type_string }

Nonces use the unordered bitmap layout (high 248 bits select the word, low 8 bits the bit), so an account can sign many permits in parallel. The witness variant binds extra data into the same signature; a cross-chain order's id is the usual witness, so one signature authorises both the token pull and the ERC-7683 order.

The CLI mirrors these as tenzro permit2 nonce-used and tenzro permit2 verify-and-consume. Build the EIP-712 digest with any Permit2 library.

Related

• Multi-VM runtime
• SVM
• Device linking and recovery
• Bridges