EVM

The EVM on Tenzro Network 1 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.xyz \
  -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.xyz") });
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 Network 1 must; see RPC access.

tenzro_caip2 returns the chain's CAIP-2 identifier together with the EVM chain id, for wallets that track chains by CAIP.

Deploy a contract

Deploy with your usual tool, or with the CLI:

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

tenzro contract encode and tenzro contract decode ABI-encode calls and decode return data when you are scripting without a library.

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.

Account abstraction

Network 1 supports ERC-4337 v0.8: an EntryPoint, packed user operations with split gas fields, EIP-712 hashing, a deterministic CREATE2 account factory and paymaster sponsorship. Submit user operations with eth_sendUserOperation and estimate them with eth_estimateUserOperationGas.

Smart accounts install ERC-7579 validator modules. The installed modules are combined, so every one of them must approve an operation, and they are enforced on every path that signs or submits a transaction. See Smart account policies and Paymaster.

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.

# Build the signing hash for an authorisation
tenzro eip7702 signing-hash \
  --chain-id <CHAIN_ID> --delegate-address 0xDELEGATE --nonce 0 \
  --rpc https://rpc.tenzro.xyz

# Inspect an account's active delegation
curl -s https://rpc.tenzro.xyz -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tenzro_get7702Delegation","params":[{"authority":"0xYOUR_ADDRESS"}]}'

tenzro_install7702Delegation takes the authority, chain id, delegate address, nonce and signature, and rejects a wrong chain id, a stale nonce or a signature that does not recover to the authority. It is an owner method: only the account's own signature can install a delegation. Helpers tenzro_eip7702SigningHash, tenzro_eip7702BuildDesignator and tenzro_eip7702ParseDesignator are open. 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. Network 1 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 domain-separator | digest | nonce-used | verify-and-consume.

Related

• Multi-VM runtime
• SVM
• Smart account policies
• Bridges