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:
Contracts
AutoLoop.sol
The core orchestrator. When a worker calls performUpdate(), AutoLoop:
- Verifies the caller is a registered controller
- Checks the target contract's balance can cover gas + fees
- Calls
progressLoop()on the target (with VRF proof if applicable) - 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:
| Contract | Interface ID | What Workers Do |
|---|---|---|
AutoLoopCompatible | Default | Call progressLoop() directly |
AutoLoopHybridVRFCompatible | ERC-165 detected | Check needsVRF flag; attach proof only when true |
AutoLoopVRFCompatible | ERC-165 detected | Always generate and attach ECVRF proof |
Workers
Workers are permissionless Node.js processes. Anyone can run one.
Execution loop:
- Fetch all registered contracts from the Registry
- For each contract, call
shouldProgressLoop() - If
true, detect the contract type via ERC-165 - For Standard: submit
performUpdate(contractAddress) - For VRF/Hybrid: generate ECVRF proof, submit
performVRFUpdate(contractAddress, proof) - Receive gas reimbursement + 50% of base fee
- 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:
Network Support
| Network | Status | RPC |
|---|---|---|
| Ethereum Mainnet | Live | Any mainnet RPC |
| Sepolia Testnet | Live | Any Sepolia RPC |
| Base | Planned | — |
| Arbitrum | Planned | — |
| Polygon | Planned | — |
The protocol is EVM-chain-agnostic — the same contracts and worker code deploy to any EVM chain.