ChainEvidence

Evidence-first EVM transaction preflight for AI agents and developers.

ChainEvidence inspects an unsigned Base transaction before execution and returns deterministic, machine-readable evidence: decoded intent, basic simulation, contract verification, proxy/implementation facts, privilege signals, findings, coverage, and exact block provenance.

It deliberately does not label a transaction SAFE, SCAM, or MALICIOUS, and it does not emit a global risk score. The caller gets facts, confidence, and uncertainty so it can apply its own policy.

What ChainEvidence checks

• calldata intent and known function selectors;
• unlimited ERC-20-style approvals and setApprovalForAll;
• basic eth_call simulation and gas estimation;
• target bytecode and contract status;
• verified source metadata through Etherscan V2 when available;
• ERC-1967, ERC-1167, beacon, and legacy ZeppelinOS proxy evidence;
• implementation and admin addresses when deterministically recoverable;
• readable owner() evidence;
• deterministic CE-001..CE-012 findings;
• coverage limits and exact state/block provenance.

Supported networks in v0.1: Base Mainnet (8453) and Base Sepolia (84532).

Run on Apify

The Apify Actor accepts one unsigned transaction and returns one evidence report.

Example input:

{
  "chain": "base",
  "from": "0x0000000000000000000000000000000000000001",
  "to": "0x833589fcd6edb6e08f4c7c32d4f71b54bda02913",
  "data": "0x095ea7b3000000000000000000000000111111125421ca6dc452d289314280a0f8842a65ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff",
  "value": "0",
  "blockTag": "latest"
}

Example evidence excerpt:

{
  "schemaVersion": "chainevidence/0.1",
  "analysisVersion": "0.1.0-alpha.15",
  "intent": {
    "decoded": true,
    "signature": "approve(address,uint256)",
    "category": "TOKEN_APPROVAL"
  },
  "simulation": {
    "executed": true,
    "reverted": false
  },
  "target": {
    "sourceVerification": {
      "status": "VERIFIED",
      "provider": "etherscan",
      "contractName": "FiatTokenProxy"
    },
    "proxy": {
      "detected": true,
      "type": "ZEPPELINOS"
    }
  },
  "findings": [
    {
      "id": "CE-001",
      "kind": "MAX_UINT256_APPROVAL",
      "attention": "WARNING"
    }
  ],
  "coverage": {
    "calldataDecode": "FULL",
    "proxyDetection": "FULL",
    "sourceVerification": "FULL",
    "executionSimulation": "BASIC"
  },
  "provenance": {
    "chainId": 8453,
    "requestedBlockTag": "latest",
    "blockNumber": 0,
    "verificationSources": ["etherscan"]
  }
}

The example intentionally truncates fields. The dataset item contains the complete evidence report for that run.

Why evidence-first?

A transaction simulation is an observation against a specific blockchain state, not a guarantee of future execution. A verified contract can still have privileged or upgradeable behavior. A single score can hide those distinctions.

ChainEvidence therefore records what was observed, where it came from, how confident the engine is, and what it could not establish.

Report structure

Each report contains:

• request — normalized unsigned transaction request;
• intent — selector/signature/category and decoded arguments when supported;
• simulation — state-specific basic execution observation;
• target — bytecode, verification, proxy, implementation, and ownership evidence;
• findings — deterministic CE rules with evidence references;
• coverage — explicit FULL/PARTIAL/NOT_AVAILABLE analysis coverage;
• provenance — chain, effective state block, block hash, provider class, and ruleset version.

Unknown selectors remain unknown instead of being guessed.

Security and privacy boundary

ChainEvidence never asks for or accepts:

• private keys;
• seed phrases;
• wallet passwords;
• signed transactions;
• arbitrary user-supplied RPC URLs.

It does not sign or broadcast transactions. The engine performs read-only blockchain/RPC and verification lookups.

For pre-sign transaction analysis, ChainEvidence does not silently send private unsigned calldata to arbitrary public fallback RPC providers.

Current limitations

• selector coverage is intentionally small in v0.1;
• simulation is basic and state-specific;
• no internal call tree yet;
• no complete asset-change model yet;
• privilege analysis is partial;
• verified-source availability depends on explorer coverage;
• approve(address,uint256) is shared by ERC-20 and ERC-721, so calldata alone does not establish the token standard.

These limits are surfaced in coverage rather than hidden behind a verdict.

Local CLI

Requirements: Node.js 22+.

npm install
npm run build
npm test

Analyze a request file:

$npm run cli -- --input fixtures/requests/unlimited-approval.example.json

For live local use, configure your own RPC and optional Etherscan key:

export BASE_RPC_URL="https://your-provider.example"
export ETHERSCAN_API_KEY="..."

A historical mined-transaction probe is also available with --tx-hash. Historical mode anchors reads to the mined block; it is not an exact intra-block pre-transaction replay.

Deterministic design

The core v0.1 engine does not require an LLM. Findings are produced from decoded calldata, RPC observations, bytecode/storage patterns, verification metadata, and explicit rules.

This makes reports reproducible and suitable for AI agents, policy engines, developer tooling, and security automation that need evidence rather than a black-box verdict.