TrustGate

TrustGate is the first working autonomous hiring manager for AI agents on Ethereum. It is a complete, end-to-end system that lets one agent (or a human) discover, vet, hire, deliver work to, pay, and rate any other agent on the network, without a central server, without hardcoded API endpoints, and without anyone holding custodial keys on the user's behalf.

The problem TrustGate solves is concrete. ERC-8004, Ethereum's onchain standard for AI agent identity and reputation, went live on mainnet on January 29, 2026, and over 45,000 agents have already self-registered. But until TrustGate, there was no working system that actually used those registries to make autonomous hiring decisions. Today, when an AI agent needs to outsource a subtask (summarise a PDF, run a swap, validate a price feed, generate test data), it has only two real options: call a hardcoded API it was programmed to use (no flexibility, no fallback, no trust signal), or use a centrally orchestrated multi-agent framework (a coordinator server in the middle that is a single point of failure and trust). Neither option lets an agent find an unknown peer, verify it from its onchain history, hire it, and pay it without a human or central server in the loop.

TrustGate fills that gap with a five-stage hiring loop, every stage of which is wired to real, live infrastructure:

Broadcast. A requesting agent submits a job spec (capability, budget, deadline, optional minimum reputation) over the Gensyn AXL peer-to-peer mesh (TLS-encrypted, no central server). Discover. TrustGate enumerates the live ERC-8004 IdentityRegistry on Base Sepolia (0x8004A818BFB912233c491871b3d84c89A494BD9e), pulls every agent's tokenURI, and hydrates the agent card from data:, ipfs://, or https:// (with multi-gateway IPFS fallback), then filters by capability. Evaluate. For each candidate, TrustGate reads the ERC-8004 ReputationRegistry (0x8004B663056A597Dffe9eCcC1965A193B7388713), aggregates every onchain feedback record, and ranks candidates with a transparent 60 / 20 / 20 weighted score: 0.6 · reputation + 0.2 · price fit + 0.2 · latency. The dashboard renders the per-agent score breakdown as a stacked bar chart so the user can see why each candidate was picked. Hire and deliver. TrustGate sends the job spec directly to the winner's AXL node via the AXL A2A SendMessage primitive. If the top candidate fails or times out, TrustGate automatically falls back to the runner-up through a separate AXL node, a real multi-node retry-aware delivery pipeline, not a single happy path. Settle and record. On successful delivery, TrustGate calls KeeperHub's /api/execute/transfer to release payment to the worker's wallet, then writes a giveFeedback(...) transaction back to the ReputationRegistry so the next hire anyone in the world runs benefits from this outcome. A subtle but important detail: TrustGate doesn't sit outside the standard it consumes. It self-registers on the IdentityRegistry (TrustGate is agent #5412 on Base Sepolia today), publishes its own JSON agent card, supports setAgentURI to re-publish that card without burning a fresh agent id (and, critically, without losing accumulated reputation), and resolves its signer's primary ENS name on mainnet with multi-RPC failover. Any other ERC-8004-aware agent can discover and hire TrustGate the same way TrustGate discovers everyone else. The system is recursive, not privileged.

The whole stack is drivable from a Next.js 16 dashboard at http://127.0.0.1:3000 with six tabs: Overview (network health, "Run a sample hire" one-click button, scoring rationale, Basescan / 8004scan deeplinks); Agents (full registry browser with capability typeahead, ENS owner names, individual feedback rows, an amber "tokenURI drifted" banner when an agent has updated its card, and a Shift-click compare-two-agents view); Hire (type capability + budget, get a ranked candidate list with the 60/20/20 breakdown); AXL Bridge (three-node mesh health plus a "Run hire-with-fallback" button that exercises the full retry path with per-attempt timing); Settle (the full hire loop end-to-end, covering discovery, A2A delivery, KeeperHub settlement, and onchain feedback, with focused panels for each step); and Self (the "TrustGate is itself an agent" tab: signer balance, ENS reverse-resolved name, JSON card preview, register / setAgentURI dry-run or live, and a free-form ENS forward/reverse resolver).

End-users connect their own wallet via WalletConnect / RainbowKit / wagmi / viem and sign register, setAgentURI, and giveFeedback themselves; TrustGate never holds custody of visitor keys. When a private key or KeeperHub API key isn't configured, TrustGate degrades to an honest stub or dry-run that returns the calldata you'd sign manually, never a fake success. The critical path is verifiably onchain: TrustGate is live as agent #5412, every giveFeedback write goes to the real ReputationRegistry and is visible on 8004scan.app and Basescan, and setAgentURI re-publishes have been demonstrated end-to-end with reputation preserved.

TrustGate is a connector, not a new protocol, and that's the point: ERC-8004, AXL, and KeeperHub all shipped in the last few months; the agents are already registered; the transport and settlement layers are already live. What was missing was the autonomous hiring manager that turns them into a market. That manager is TrustGate.

TrustGate is a single Python backend, a Next.js frontend, and a vendored AXL binary, glued together through HTTP and signed transactions, and deployed as one Docker image. Every piece was chosen to keep the critical path real (no mocks where it matters) while still degrading gracefully when a credential is missing.

Backend (Python) The backend is a Flask service (app/server.py) wrapping four pure-Python modules with clean interfaces, so each can be tested in isolation:

registry_client.py: web3.py reads against the live ERC-8004 IdentityRegistry and ReputationRegistry on Base Sepolia. Event scans are bounded and cached on disk (app/.cache/) so the dashboard's first load is instant; agent cards are hydrated from data:, ipfs:// (with multi-gateway failover across ipfs.io, cloudflare-ipfs.com, and gateway.pinata.cloud), or https:// and stored in a separate cards-*.json cache. ABIs come from the official erc-8004/erc-8004-contracts repo. scorer.py: pure-Python implementation of the 60/20/20 weighted score. No blockchain calls, fully unit-testable, and the same function powers both the CLI and the dashboard's bar-chart breakdown. hiring.py: find_best_agent(capability, budget) and complete_hire_loop(...) orchestrate discover, rank, A2A deliver, KeeperHub settle, and onchain feedback in one call. axl_gateway.py: a thin HTTP wrapper around the vendored AXL binary's /topology, /send, and /recv endpoints, so the Flask layer never has to speak AXL's wire format directly. For onchain writes, gas is computed dynamically via eth_estimateGas (no hardcoded ceiling, so writes succeed on a congested testnet), and ENS resolution falls over across multiple mainnet RPCs so a single rate-limited endpoint doesn't break the Self tab. When PRIVATE_KEY is unset, every write path returns ABI-encoded calldata in dry-run mode that the user can sign and broadcast manually (same code path, same parameters, just stops short of send_raw_transaction). This made it possible to demo every write flow end-to-end on a clean machine before plugging in a real key.

Frontend (Next.js 16 + Tailwind) The dashboard is a single Next.js app with a tab shell (app/page.tsx) and per-tab components (Overview / Agents / Hire / AXL Bridge / Settle / Self), talking to the Flask API through a typed client (frontend/lib/api.ts). All score breakdowns, feedback timelines, and AXL per-attempt panels are rendered client-side from JSON the backend returns; nothing about the visualisation is faked. WalletConnect is wired in via RainbowKit + wagmi + viem, so a visitor on the hosted demo connects their own wallet and personally signs register, setAgentURI, and giveFeedback; TrustGate's backend never receives the visitor's key.

UX touches that turned out to matter: a first-run setup wizard, capability typeahead with "Did you mean…?" suggestions, tooltips on every piece of jargon (ERC-8004, A2A, tokenURI, etc.), a KeeperHub readiness checklist, an "amber drift banner" when an agent's tokenURI has been updated since registration, basescan / 8004scan deeplinks on every entity, and a Shift-click compare-two-agents side-by-side view.

AXL transport (vendored) The official Gensyn AXL repo is vendored into AXL/ as a prebuilt Linux ELF binary. scripts/start_axl_nodes.sh boots three peered nodes (one sender, two receivers with A2A enabled) on 127.0.0.1:9001/9011/9021 (TLS) and :9002/9012/9022 (HTTP API). Two phase4_worker.py processes listen on the receivers' A2A ports and reply to delivered jobs. The third node exists specifically so the fallback path is provably real: when worker-b drops a request (you can force this with --drop-first 1), the dashboard transparently retries through n3 to worker-c and shows the per-attempt JSON-RPC reply.

A worker_sdk Python module + CLI (python -m worker_sdk) lets any third party register and run their own worker against the same registry in a few lines, so the system is open to outside contributors, not closed around the two demo workers.

One-command bring-up + deployment bash scripts/run.sh boots AXL nodes, both workers, the Flask API, and the Next.js dev server in dependency order, with one tagged stream of output. It's idempotent (re-running prints [<svc>] already running and exits clean) and blocks until /api/health returns 200, so the dashboard never loads against a half-booted backend. For the hosted demo, there's a Dockerfile, scripts/run-prod.sh, railway.toml, and CORS narrowed via FRONTEND_ORIGIN so only the deployed frontend can hit the API.

Notable hacky bits A few things worth mentioning because they were either non-obvious or fought us:

The AXL binary is Linux-only ELF, so the entire dev loop runs in WSL on Windows. The Windows-side pnpm shim silently fails to start the Next dev server (exec: node: not found), so the README has a hard rule: pnpm must be installed inside WSL after nvm use default. Several hours were lost to this before it became a CLAUDE.md instruction. Cold IPFS gateways can take minutes to hydrate an agent card. The fix is a per-gateway race in registry_client.py (first responder wins), and the result is cached to cards-*.json so subsequent runs complete in <1s. setAgentURI reputation preservation: by default, re-registering an agent would issue a new agent id and orphan its accumulated feedback. We use setAgentURI (instead of a fresh register) so the agent keeps the same id and the same reputation history, which is the only behaviour that makes the standard usable in practice. Honest dry-run mode: every write path (register, setAgentURI, giveFeedback, settle_payment) has an explicit dry-run branch that returns ABI-encoded calldata instead of broadcasting. This is a small amount of code but it means the demo can be reviewed end-to-end on a machine with zero credentials configured, and what reviewers see is exactly what the live path would send. Multi-RPC ENS failover: the public mainnet RPCs are aggressively rate-limited, so the ENS resolver tries ENS_RPC_URL first, then a fallback list, and caches results in-memory for ENS_CACHE_TTL seconds. Otherwise the Self tab would flicker between "owned by 0xabc…" and "owned by alice.eth" depending on which RPC answered. Sponsor tracks: how we used Gensyn AXL and KeeperHub Gensyn AXL, the transport layer AXL is not a peripheral integration for TrustGate; it is the only way agents talk to each other in this system. Stripping AXL out would collapse the whole thesis, because the alternative is a centrally-coordinated message bus, which is exactly the architecture TrustGate exists to replace.

Concretely, we use AXL three ways:

The vendored AXL binary runs as three peered nodes locally (sender plus two receivers with A2A enabled), boot-strapped by scripts/start_axl_nodes.sh. The dashboard's "AXL Bridge" tab exposes live mesh topology via /topology and shows green/red dots per node so you can see the mesh is real. Job specs travel over the AXL P2P mesh from the requester (the dashboard's Hire tab, or any external agent) into TrustGate via /recv, and from TrustGate out to the chosen worker via the AXL A2A SendMessage primitive on the worker's a2a_port. There is no Flask-to-worker shortcut anywhere in the critical path; the bytes physically traverse the mesh. Retry / fallback is implemented at the AXL layer, not at the application layer. When the top-ranked candidate's worker drops or times out, the gateway retries to the runner-up's AXL node through a separate mesh peer, and the dashboard surfaces the per-attempt timing and the underlying JSON-RPC reply so reviewers can confirm the fallback was real. Why this benefited the project: AXL's "single binary, zero infrastructure, encrypted by default" promise is what made it possible to ship a demo where the trustless story actually holds. A coordinator-based transport would have undermined the entire pitch; it doesn't matter how clean the ERC-8004 reads are if the messages between agents flow through a server we control. AXL meant we could honestly say "no central server in the loop" and back it up with a three-node topology anyone can boot in one command.

KeeperHub, the settlement layer KeeperHub is the payment leg of the hiring loop. Once a worker has delivered the result over AXL, TrustGate has to actually pay them, and "send some USDC to the winner's wallet" is precisely the kind of operation an autonomous agent cannot reliably do by itself with a raw RPC (gas estimation fails, nonces collide, RPCs silently drop transactions, retry logic has to live somewhere). KeeperHub's guaranteed-execution layer absorbs all of that.

Concretely, we integrated KeeperHub through its REST API:

complete_hire_loop posts to /api/execute/transfer on KEEPERHUB_API_URL (default https://app.keeperhub.com/api) with the payee wallet, amount, network (KEEPERHUB_NETWORK, defaulting to base-sepolia), and either a token symbol (KEEPERHUB_PAYER_TOKEN, default USDC) or an explicit KEEPERHUB_TOKEN_ADDRESS override. Source-of-funds is the KeeperHub-managed organisation wallet, which is topped up via the KeeperHub dashboard. Auth uses an Organisation kh_* API key (KEEPERHUB_API_KEY) rather than a per-user key, so the same TrustGate deployment can pay any worker without re-onboarding each one. The Settle tab surfaces KeeperHub's state directly: the top of the tab tells you whether you're in stub mode (no key) or live, and there's a readiness checklist (Phase 9) that walks the user through getting the right key from Settings → API Keys → Organisation tab on app.keeperhub.com. Graceful degradation: when KeeperHub is unreachable or no API key is configured, TrustGate enters a live-unreachable mode that still completes the rest of the loop (delivery + onchain feedback) and reports the settlement step as honestly skipped. Reviewers can drive the entire pipeline without a KeeperHub account. Why this benefited the project: payment is where most "agent demos" wave their hands. KeeperHub let us show a real payout step that runs on Base Sepolia today, with retry semantics and an audit trail we don't have to build, while keeping the demo runnable in a stub mode for reviewers who don't want to provision an org wallet. The combination (AXL for transport, KeeperHub for settlement, ERC-8004 for identity and reputation) is what lets TrustGate plausibly claim to be a complete hiring loop rather than three-quarters of one.