Docs/Architecture

Architecture

How AutoLoop's contracts, workers, registry, and dashboard fit together.


System Overview

AutoLoop has four main components that work together to provide decentralized smart contract automation:

Loading diagram…

Contracts

AutoLoop.sol

The core orchestrator. When a worker calls performUpdate(), AutoLoop:

  1. Verifies the caller is a registered controller
  2. Checks the target contract's balance can cover gas + fees
  3. Calls progressLoop() on the target (with VRF proof if applicable)
  4. Calculates and distributes fees (gas reimbursement to worker, base fee split between protocol and worker)

AutoLoopRegistrar.sol

The entry point for new contracts. Validates that a contract implements the correct interface (via ERC-165) before allowing registration. Also handles initial ETH deposits.

AutoLoopRegistry.sol

State storage. Tracks:

  • Which contracts are registered and active
  • ETH balances for each contract
  • Max gas limits per contract
  • Controller registrations and permissions

VRFVerifier.sol

A gas-efficient on-chain ECVRF (Elliptic Curve Verifiable Random Function) verifier. Validates proofs submitted by workers using their registered public key coordinates (pkX, pkY). Based on the secp256k1 curve.

Base Contracts

Your game inherits one of these:

ContractInterface IDWhat Workers Do
AutoLoopCompatibleDefaultCall progressLoop() directly
AutoLoopHybridVRFCompatibleERC-165 detectedCheck needsVRF flag; attach proof only when true
AutoLoopVRFCompatibleERC-165 detectedAlways generate and attach ECVRF proof

Workers

Workers are permissionless Node.js processes. Anyone can run one.

Execution loop:

  1. Fetch all registered contracts from the Registry
  2. For each contract, call shouldProgressLoop()
  3. If true, detect the contract type via ERC-165
  4. For Standard: submit performUpdate(contractAddress)
  5. For VRF/Hybrid: generate ECVRF proof, submit performVRFUpdate(contractAddress, proof)
  6. Receive gas reimbursement + 50% of base fee
  7. Sleep, repeat

VRF proof generation happens off-chain using the worker's private key. The corresponding public key (pkX, pkY coordinates) must be registered on-chain before the contract will accept proofs.

Workers expose a /health endpoint for monitoring (uptime, block number, contracts monitored).

Dashboard

The dashboard (dashboard.tryautoloop.com) provides a web UI for:

  • Connecting a wallet (RainbowKit + wagmi)
  • Registering new contracts
  • Depositing and withdrawing ETH
  • Viewing loop status and execution history
  • Monitoring contract balances

Built with Next.js 16, wagmi v2, and RainbowKit.

MCP Server

The AutoLoop MCP server lets AI agents interact with the protocol programmatically:

  • Free tools — read-only queries (deployments, loop status, contract type detection)
  • Paid tools — operational actions via x402 micropayments (registration TX generation, cost estimation, audit analysis)

See MCP Server for details.

Data Flow: A Complete Tick

Here's what happens when a worker executes one tick on a Hybrid VRF contract:

Loading diagram…

Network Support

NetworkStatusRPC
Ethereum MainnetLiveAny mainnet RPC
Sepolia TestnetLiveAny Sepolia RPC
BasePlanned
ArbitrumPlanned
PolygonPlanned

The protocol is EVM-chain-agnostic — the same contracts and worker code deploy to any EVM chain.