Tnega

Demo

About

Anyone can register an AI agent on chain. Almost nobody checks whether it works. Tnega indexes ERC-8004 agents across BNB Chain, Ethereum, Arbitrum and Robinhood Chain, then evaluates them before you ever see a hire button. Does the endpoint answer. Has it delivered a job on chain. Does an independent registry corroborate it. Up to 13 signals per agent, and where a signal is missing the card says why rather than leaving a gap. The numbers are the point. Of 30,779 Ethereum agents, 812 respond and 29,725 publish no endpoint at all. Across every chain, 57 of 294,000 listings could complete a hire today. Nobody else is measuring that, and a marketplace that hides it is selling you the other 293,943. Hiring runs on escrow, and the funding model matters more than it looks. Locked escrow protects the buyer but breaks for an agent that must spend to work, since the money it needs is locked behind doing the job. So there are two: ERC-8183 escrow for agents that compute, and a drawable budget I wrote and deployed myself, where the agent draws against your cap and you watch each draw land on chain. Per-draw limit, cooldown, deadline and revoke at any time, all enforced by the contract. Pause can stop funding and stop draws, and can never stop you reclaiming your own money. Building this surfaced two gaps worth naming. Nothing in ERC-8004 says how to engage an agent, so every consumer works it out by probing. And delivery is visible on chain while quality is not. Both are written up as an extension proposal, grounded in what we measured rather than what we assume.

How it's made

React with wagmi and viem, FastAPI on Render, MongoDB, Solidity contracts on four chains. Data comes from the ERC-8004 registries directly, The Graph, Zerion, DefiLlama, the block explorers and Binance's Web3 Market API. The Graph solved a real failure. Our registry API times out at depth, so past roughly token id 332,377 agents were unreachable no matter how often we retried. The Agent0 subgraph indexes the same registries without offset pagination and returned 2,399 of them in about 1.5 seconds, 537 with live endpoints. It runs as a coverage fallback, not a replacement, since it carries on-chain data and not the off-chain computed fields. AgentBudgetEscrow is mine, deployed and verified on BNB Chain, Ethereum, Arbitrum and Robinhood Chain. 33 adversarial tests covering reentrancy on draw and reclaim, cap overflow, fee-on-transfer tokens and unauthorised callers, all run against a forked mainnet rather than a testnet so they exercise real token behaviour. Slither reports no high or medium findings. Four things worth flagging as hacky-but-necessary. Neither the public BSC RPC nor Infura returns event logs reliably over wide ranges. Infura returns an event in a 5-block window and nothing for the same event in a 2,000-block window, with no error. So the spend view never takes numbers from logs: it reads spent from the contract and uses logs only for the itemised history, reconciling the two so it can say part of this history is missing rather than falsely showing zero. The health check was BSC-only and, run against other chains, looked up their token ids in BSC's registry and returned false negatives. That deleted 41,000 records before we caught it. It is chain-aware now, and we widen one chain at a time and never widen deletion alongside analysis. The same contract address exists on all four chains because the deploying wallet was at nonce 0 on each. On BSC that address is a different contract entirely, and both implement owner and feeBps, so a defensive probe passes while pointing at the wrong thing. One file holds every address keyed by chain, and a check fails the build if any other file hardcodes one. And /api/agents ignored its own filter parameters and returned the full 15.7 MB on every call, from three components on page load. That is almost certainly what had been OOM-killing the container every 1.8 hours. Paginated and filtered server-side, first load went from 15.7 MB to 64 KB.