DEV Community: Neurobyteio. Agentrisk M2M

AgentRisk: A Pay-Per-Call Risk Oracle for Autonomous Trading Agents

Neurobyteio. Agentrisk M2M — Sat, 19 Sep 2026 13:41:27 +0000

AI trading agents on Base are increasingly autonomous — they see a
token, decide, and execute, often with no human in the loop. But
"decide" usually means trusting whatever on-chain data the agent
can scrape in the few hundred milliseconds it has before the trade
window closes. That's a thin foundation for judgment: honeypot
contracts, unlocked liquidity, rug-pull patterns — none of that is
visible from a raw balance check.

Most existing risk tools are built for humans: a dashboard, a
search box, a subscription. None of that works for an agent that
needs a machine-readable answer in one HTTP call, with no signup
flow, no API key provisioning, no human clicking "I agree" anywhere
in the loop.

AgentRisk is built for that gap specifically — an m2m risk oracle,
not a dashboard.

How it works

Pay-per-call via x402. No subscription, no key. An agent sends
a request, gets a 402 Payment Required response, pays 0.15 USDC on
Base, and the same request goes through. No account creation
anywhere in the flow — which matters when the caller is a bot, not
a person who can fill out a signup form.

Cross-referenced signal, not a single source. Every scan
combines GoPlus token-security data with independent on-chain
checks — LP lock status, holder concentration, sell simulation
against the live pool. A token can look clean on one source and
show a blocked sell path on the other; AgentRisk surfaces both
rather than picking one.

Signed, cacheable verdicts. Every response can carry a signed
attestation: risk score, scan id, rulepack hash, policy version,
input digest, chain, timestamp. This came directly from a
conversation with another agent builder (@AxiomBot / Protean
Labs) who pointed out that agents calling this at scale need to
cache a verdict and trust it without re-querying — the receipt is
what makes that safe. An agent can verify the signature offline,
check the timestamp isn't stale, and skip the network call entirely
on a cache hit.

Machine-readable failure states. A signature check doesn't just
return "invalid" — it distinguishes expired, revoked,
replayed, and unsigned, so a calling agent can decide
programmatically whether to retry, re-scan, or hard-fail.

Integration surface

REST endpoint — POST /scan with a contract address, x402 payment header, get back structured JSON.
MCP server — for agents built on Claude/MCP-compatible stacks, risk scoring is exposed as a tool call.
A2A Agent Card — so other agents can discover the service and its capabilities without hardcoded integration.

Where it stands

The service has been live on Base Mainnet for a few months. It's
listed in a couple of community agent-tooling directories
(awesome-a2a among them) and has processed real scans end to end,
including real x402 payments settling on-chain.

It's early — real usage is still small, and that's an honest
statement, not a hedge. If you're building an agent that trades
autonomously on Base and want pre-trade risk data without wiring up
your own token-security pipeline, the endpoint is open:

agentrisk.dev

Feedback — especially from anyone building m2m agent infrastructure
— is genuinely welcome. The attestation spec above exists because
someone in a Twitter thread asked a sharp question about staleness
and caching; more of that kind of pressure-testing is exactly what
this needs right now.

Giving AI Agents a Way to Say "No" Before They Get Rekt: Building AgentRisk M2M

Neurobyteio. Agentrisk M2M — Mon, 14 Sep 2026 06:25:44 +0000

Giving AI Agents a Way to Say "No" Before They Get Rekt

AI agents are increasingly being handed wallets and told to trade. Swap bots, portfolio agents,
arbitrage bots built on frameworks like Coinbase AgentKit, ElizaOS, and LangChain now execute
on-chain transactions with no human in the loop.

The problem: most of these agents have no built-in way to tell a legitimate token from a honeypot
or a freshly-deployed rug pull before they sign a transaction. A human trader might eyeball a chart
or check a Telegram group. An agent has no such instinct.

Why not just hardcode a checklist?

Because the signals that matter change token by token, and reliable risk data comes from multiple
sources that disagree with each other more often than you'd expect. You need:

Honeypot / sell-tax detection
Deployer wallet history (is this a serial rug-puller?)
Liquidity lock status
Brand impersonation checks (fake "official" tokens)
Cross-referencing off-chain security data against live on-chain state

Bundling all of that into every agent's codebase doesn't scale. So I built it as a standalone,
pay-per-call API instead: AgentRisk M2M.

How it works

AgentRisk is a pre-trade risk scoring API for tokens on Base Mainnet, built specifically for
machine-to-machine consumption:

Payment: x402 protocol — 0.15 USDC per scan, paid directly by the agent via the Coinbase CDP facilitator. No API keys, no signup, no subscription. An agent hits the endpoint, gets a 402 Payment Required response, pays, gets the result.
Stack: Python + FastAPI, deployed on a VPS behind Cloudflare.
Data sources: GoPlus Security, DexScreener, and direct Base RPC calls — cross-referenced against each other, with a confidence field that drops when data sources disagree or key fields (creator address, LP lock status) are missing.

What a scan actually checks

Deployer wallet freshness (a nonce ≤3 is flagged — brand-new wallets deploying tokens are a common rug pattern)
Anti-brand-impersonation detection (fake versions of known tokens)
GoPlus-vs-on-chain disagreement flag (when the security data and live chain state don't match)
A human-readable verdict, not just a raw score
A scan receipt with scan_id and timestamp for auditability

Machine-to-machine first

Beyond the raw API, AgentRisk exposes:

A full MCP server implementation, so any MCP-compatible agent can call it as a tool
An A2A Agent Card (.well-known/agent.json, protocol version 0.3) for agent-to-agent discovery
Listings on mcp.so, Smithery, the official MCP Registry, and x402scan

The goal is that an agent framework doesn't need custom integration code — it discovers the tool,
sees the price, pays per use.

What's next

Currently gathering real-world usage data (one honeypot has already been caught in early testing)
and working through developer channels — GitHub issues on agent-framework repos, PR reviews on
base/skills and BankrBot/skills — to get AgentRisk in front of people actually writing agent
trading code today.

If you're building an agent that touches Base tokens, or just curious about the x402 payment flow
for machine-to-machine APIs, happy to talk shop in the comments.

🔗 agentrisk.dev

📦 github.com/Neurobyteio/agentrisk

I Caught a Real Honeypot Live, and It Confirmed Something About How These Scams Actually Work

Neurobyteio. Agentrisk M2M — Wed, 09 Sep 2026 06:12:54 +0000

I record short demos of AgentRisk M2M — a pre-trade risk API for Base tokens — scanning random, live tokens. Most of the time the result is unremarkable: CAUTION here, a HIGH_RISK there. This time it wasn't.

What happened

I ran a scan on a token that, on the surface, looked completely ordinary. Open source, no obvious red flags in a quick glance. The static checks — ownership status, mint functions, blacklist logic — came back mostly clean.

Then the live sell simulation ran. It queries the actual pool state directly, computing what a real sell transaction would return right now, across whichever DEX the token trades on — in this case walking through Uniswap V2/V3-style reserves and V3/V4 slot0 pricing depending on the pool type. The result: unsellable. Not a tax, not a warning — the pool simply would not let a sell go through.

That's the gap a static scanner can't see. The bytecode doesn't have to say "you can never sell this." It just has to route through logic that behaves differently depending on execution context, or rely on a pool configuration that a code read alone won't reveal. The only way to catch it is to actually ask the pool the question a real trade would ask: what happens if I try to sell this right now?

Why this matters more for agents than for humans

A human trader who gets a bad feeling can pause, look something up, ask around. An autonomous trading agent doesn't have that instinct — it acts on whatever signal it's given. If that signal is "the code looks fine," and the code genuinely does look fine, the agent has no reason to stop. It buys, and finds out it can't sell at the exact moment it tries — with real funds already committed.

This is the specific failure mode AgentRisk is built around: not "is this contract written maliciously" but "will this pool actually let you exit right now." The two questions overlap a lot of the time, but not always, and the cases where they diverge are exactly the ones that hurt.

The technical detail worth sharing

Covering this reliably across Base means handling more than one DEX shape. The sell simulation checks getReserves() for V2-style AMM pools, and slot0() for V3/Slipstream-style concentrated liquidity pools — including Uniswap V4's newer singleton PoolManager architecture via its StateView contract, and Aerodrome's own V1 and Slipstream pools. A token that looks safe on a superficial pass can still fail this check if the pool it actually trades through behaves unexpectedly under a real sell.

Where this fits

AgentRisk M2M runs this simulation alongside honeypot detection, deployer wallet history, brand impersonation checks, and on-chain LP-lock verification — returning a single risk score and a clear should-trade decision. Paid per call via x402, 0.15 USDC, no API key. Available directly over HTTP or as native packages for MCP, ElizaOS, LangChain, Vercel AI SDK, and Coinbase AgentKit, so it drops into whatever an agent's stack already looks like.

Repo: github.com/Neurobyteio/agentrisk
Try it: agentrisk.dev

Shipping AgentRisk Into Every Major Agent Framework: MCP, ElizaOS, LangChain, Vercel AI SDK, and Coinbase AgentKit

Neurobyteio. Agentrisk M2M — Sun, 06 Sep 2026 17:16:59 +0000

A pre-trade risk API is only as useful as it is reachable. For a while, AgentRisk M2M was a solid, well-tested HTTP endpoint — but reachable only if a developer already knew it existed and was willing to write the integration code by hand. That's a real barrier, and today it's gone.

The gap

Every major framework for building autonomous agents ships its own convention for adding a capability: an MCP tool, an ElizaOS action, a LangChain tool, a Vercel AI SDK tool, a Coinbase AgentKit action provider. A developer working in any of these doesn't want to hand-roll an HTTP client and parse a JSON response — they want npm install and a working tool in their agent's toolset within a minute.

What shipped

Five packages, each a thin, tested wrapper around the same underlying API (agentrisk.dev/scan) — no duplicated logic, no drift between them:

agentrisk-mcp — a standard MCP server, works with Claude Desktop, Cursor, and any MCP-compatible client. npm install -g agentrisk-mcp, one config block, done.

@agentrisk/plugin-elizaos — an ElizaOS action (CHECK_TOKEN_RISK) that fires when a message mentions a Base address alongside words like "safe," "honeypot," or "rug." Drops straight into a character file's plugin list.

@agentrisk/langchain — a DynamicStructuredTool for LangChain agents, addable to any tool list like any other LangChain tool.

@agentrisk/ai-sdk — a Vercel AI SDK tool using the current inputSchema / execute shape (the API changed between major versions of the ai package — worth checking your installed version before copying examples from older docs).

@agentrisk/agentkit — a Coinbase AgentKit action provider, the one I'd call the most consequential integration here, since AgentKit is Coinbase's own first-party framework and sits in the same ecosystem as the x402 facilitator and Builder Codes I'm already using for payments and attribution.

What each one actually does

Every package calls the same real-time analysis: honeypot detection, deployer wallet freshness, brand impersonation checks, on-chain LP-lock verification, and a live sell simulation across every DEX architecture live on Base — Uniswap V2, V3, V4, and Aerodrome including Slipstream concentrated liquidity. That last part matters more than it sounds: a token can pass every static check and still be unsellable the moment real liquidity conditions are queried, which is exactly the gap a code-only scanner can't see.

A genuinely annoying bug along the way

Building the AgentKit package surfaced a real dependency conflict worth flagging for anyone doing the same: @coinbase/agentkit pins its internal type expectations to Zod 3, while a fresh npm install zod today pulls Zod 4. The compiler error (missing properties from type 'ZodType'... _type, _parse, _getType) gives no hint that version mismatch is the cause. Pinning zod@3.25.76 explicitly fixed it immediately.

Pricing, unchanged

0.15 USDC per scan via x402, no API key, no subscription. Free public checks at agentrisk.dev for anyone who wants to see the output shape before wiring up a package.

Where it stands

Five repos, five packages, one API behind all of them. Whichever framework an agent is built on, the integration path is now identical to installing any other tool in that ecosystem — no special-casing, no manual HTTP client required.

Repos: github.com/Neurobyteio/agentrisk-mcp, agentrisk-eliza, agentrisk-langchain, agentrisk-ai-sdk, agentrisk-agentkit
API: github.com/Neurobyteio/agentrisk
Try it: agentrisk.dev

Verifiable Trust for AI Agents: Signed Receipts, Replay Protection, and Failure Normalization

Neurobyteio. Agentrisk M2M — Fri, 04 Sep 2026 06:23:57 +0000

A few weeks ago, AgentRisk M2M shipped signed risk receipts — every token scan could be cryptographically signed so an agent could confirm a result actually came from the API. That felt complete. It wasn't. Here's what changed after a real back-and-forth with another live agent in the x402 ecosystem, and why each addition closes a specific, concrete gap.

Where it started: a signature, and not much else

The original /verify endpoint answered exactly one question: is this signature real? Necessary, but thin. An agent deciding whether to trust a cached scan result — instead of paying for a fresh one — needs more surface area than a single boolean.

Round one: making the receipt legible

The first round of feedback asked for explicit fields that were technically present but not surfaced clearly: which rulepack hash produced this score, which key signed it, when the verification itself happened (not just when the original scan ran), and what the maximum age threshold actually is. All of this existed inside the signed payload already — the fix was making it visible instead of implicit.

Replay detection took more work than expected. My first pass used a plain in-memory dictionary to track which scan_ids had already been checked. It worked fine in isolated testing and failed silently in production, because the API runs behind four uvicorn workers, each with separate memory. A request landing on worker 1 has no idea worker 3 already saw that scan_id. Switched to SQLite — already used elsewhere in the app, shared across all workers — and the replay window started working correctly: first check returns replay_detected: false, an identical second check within 10 minutes returns true.

Round two: one red light isn't enough

Once the receipt had real signature validation, staleness checks, and replay detection, the next piece of feedback was sharper: bundling every failure mode into a single valid: false throws away information an agent actually needs. Rejecting a scan because it's stale (just re-scan) is a completely different action than rejecting it because the signature doesn't check out (don't trust this source at all).

The fix: a failure_reason field with four distinct, machine-readable values — unsigned, expired, replayed, and revoked — instead of one generic flag. An agent can now branch on the specific reason instead of treating every rejection identically.

The honest gap: revocation

That fourth category, revoked, deserves a direct explanation, because I didn't build a full revocation registry — and I don't think I should have, yet. The textbook approach is a growing database of blocked receipt IDs with an admin endpoint to add to it. I went with a hard 24-hour TTL instead: a receipt that's past its age threshold gets rejected the same way an explicitly revoked one would, without maintaining a blocklist that only grows. The revoked field is reserved in the response schema — always false today — so an agent's parsing logic doesn't have to special-case its absence if a real registry gets built later. Whether that's actually needed depends on whether 24-hour staleness is fast enough for how a given agent uses the data, which is an open question I'd rather answer with a real use case than a hypothetical one.

Why this is worth writing up

There's a pattern here worth naming: a valid/invalid boolean is a verdict. What was actually being asked for, across both rounds, was a reasoning path — enough structured, distinct detail that another agent, or a developer debugging that agent's behavior later, can reconstruct exactly why a receipt was trusted or rejected, not just that it was one or the other. Signature validity, rule currency, staleness, and replay status are independent axes. Collapsing them into one flag discards information that changes what an agent should actually do next.

Where it stands

/verify now takes a signed receipt and returns signature validity, signer key ID, rulepack hash and currency, verification timestamp, explicit TTL, replay detection (SQLite-backed, correct across all workers), and a normalized failure_reason covering all four rejection categories. No new infrastructure beyond one SQLite table.

This sits alongside AgentRisk M2M's core scanning: honeypot detection, deployer wallet history, brand impersonation checks, on-chain LP-lock verification, and a live sell simulation covering every major DEX architecture on Base — Uniswap V2, V3, V4, and Aerodrome including Slipstream concentrated liquidity — paid per call via x402, 0.15 USDC, no API key.

Repo: github.com/Neurobyteio/agentrisk
Try it: agentrisk.dev

Building a Trust Layer for AI Agents: From "Valid: True" to a Full Reasoning Path

Neurobyteio. Agentrisk M2M — Thu, 03 Sep 2026 08:00:27 +0000

A few days ago I shipped signed risk receipts for AgentRisk M2M — a pre-trade token safety API for Base. Every scan could be cryptographically signed, and agents could verify the signature. That felt like a solid stopping point.

Then another live agent in the x402 ecosystem, Axiom, pushed back with a precise, well-thought-out spec: a signature alone isn't enough for another agent to actually reason about whether to trust a result. Here's what changed, and why each piece matters.

The starting point: signed, but thin

The original /verify endpoint answered one question: is this signature real? That's necessary but not sufficient. An agent deciding whether to trust a cached result needs more context than a boolean.

What Axiom asked for, and what it actually took to build

Rulepack hash and signer key ID, explicitly in the response. These existed inside the signed payload already, but weren't surfaced as first-class fields in the verify response itself. Trivial fix — just expose what was already there.

Verification timestamp. Not the time of the original scan, but the time of this specific check. An agent auditing a decision later needs to know when it confirmed trust, separate from when the data was generated.

Explicit max age. The TTL (24 hours) was enforced in code but invisible from the outside — an agent had no way to know the threshold without guessing. Now it's a plain field in the response: max_age_seconds.

Replay detection. This one took an actual debugging round. My first pass used a simple in-memory dictionary to track which scan_ids had already been checked. It worked in isolated testing and failed silently in production — because the API runs behind 4 uvicorn workers, each with its own memory space. A request hitting worker 1 has no idea worker 3 already saw that scan_id five seconds ago. Switched to SQLite (already used elsewhere in the app, shared across all workers) and the replay window started working correctly — first check returns replay_detected: false, an identical second check within the 10-minute window returns true.

The one thing I pushed back on: revocation

Axiom's spec also asked for a "revocation source" — a way to explicitly invalidate a receipt before its TTL expires. The textbook answer is a revocation list: a growing database of blocked receipt IDs, an admin endpoint to add to it, ongoing maintenance.

I didn't build that. The receipt already has a hard 24-hour TTL. An agent checking stale: true gets the same practical outcome as an explicit revocation would — it stops trusting the cached result and asks for a fresh scan. Building a parallel revocation system on top of a TTL that already does most of the job felt like solving a problem that mostly doesn't exist yet. I said so plainly in my reply rather than shipping a half-built CRL just to check a box.

Why this matters beyond one API

There's a pattern worth naming here: "valid: true" is a verdict. What Axiom was really asking for is a reasoning path — enough structured detail that another agent (or the developer debugging that agent's behavior six months later) can reconstruct why something was trusted, not just that it was. Signature validity, rule currency, staleness, and replay status are four independent axes of trust, and collapsing them into one boolean throws away information an agent might actually need to make a good decision.

Where it stands

/verify now returns signature validity, signer key ID, rulepack hash and currency, verification timestamp, age against an explicit TTL, and replay detection — all from a single POST with the receipt. No new infrastructure beyond a SQLite table and a bit more JSON.

Repo: github.com/Neurobyteio/agentrisk
Try it: agentrisk.dev

I Made a Token Safety API Work Across Every DEX Architecture on Base (Including V4)

Neurobyteio. Agentrisk M2M — Wed, 02 Sep 2026 08:40:48 +0000

A few days ago, AgentRisk M2M's "live sell simulation" only worked if a token traded against WETH on Uniswap V3. Today it works across Uniswap V2, V3, V4, and Aerodrome (both classic AMM and Slipstream concentrated liquidity) — every major DEX architecture currently live on Base.

Here's what that journey looked like, because each architecture broke in a genuinely different way.

Where it started: one method, one quote token

The original implementation called Uniswap V3's QuoterV2 with a hardcoded WETH output token, looping through the four standard fee tiers. It worked — right up until I ran it against real, randomly-picked tokens instead of the ones I'd been testing with. Roughly half of them came back sellable: false, which turned out to be wrong. The tokens were fine. My assumption that everything quotes against WETH on Uniswap V3 was not.

Fix #1: stop assuming, start asking

DexScreener already tells you the real quote token and DEX for a pair — quoteToken.symbol and dexId. Instead of hardcoding WETH, the fix was to look up the actual highest-liquidity pair and use whatever it's actually quoted against (VIRTUAL, USDC, whatever). That alone fixed a chunk of false negatives.

Fix #2: two universal read methods instead of one fee-tier-guessing loop

Rather than keep looping through Uniswap-specific fee tiers, I switched to two methods that work across pool types, not specific protocols:

`python

V2-style AMM pools

result = await w3.eth.call({"to": pair, "data": "0x0902f1ac"}) # getReserves()

V3-style concentrated liquidity pools (works on both Uniswap V3 and Aerodrome Slipstream)

result = await w3.eth.call({"to": pair, "data": "0x3850c7bd"}) # slot0()`

getReserves() covers simple constant-product pools. slot0() reads the current price directly off any Uniswap-v3-shaped pool — Uniswap V3 or Aerodrome's Slipstream, since Slipstream is architecturally a v3 fork. This alone took coverage from "Uniswap-only" to "most of Base."

The Aerodrome detour: four factories, one confusing revert

Aerodrome Slipstream has shipped multiple pool factories over time. I found a live, liquid pool that reverted on every quoter call I tried — right selector, right tick spacing, still nothing. Turned out the pool was deployed by a different factory than the one my quoter contract was wired to. Verified by comparing factory() on the quoter against factory() on the pool itself — different addresses. This is apparently a known gotcha; Aerodrome's own dev docs warn against hardcoding factory addresses for exactly this reason. The slot0() approach sidesteps the whole problem, since it reads straight from the pool, not through a factory-bound quoter.

The last piece: Uniswap V4

V4 doesn't have per-pool contracts at all — every pool lives inside one singleton PoolManager, addressed by a PoolId (a bytes32 hash of the pool's parameters) instead of a normal address. DexScreener conveniently labels these pairs "v4" and returns the PoolId directly as the pairAddress field. From there, Uniswap's official StateView periphery contract exposes getSlot0(PoolId) for exactly this kind of off-chain read:

`python
selector = "c815641c" # getSlot0(bytes32)
data = "0x" + selector + pool_id[2:].zfill(64)
result = await w3.eth.call({"to": state_view_address, "data": data})
sqrt_price_x96 = int.from_bytes(result[0:32], "big")

`
Same sqrtPriceX96 math as everywhere else — just a different entry point.

Where it ended up

The live check now branches by what DexScreener reports about the pool (V4 label → StateView, otherwise try getReserves() then slot0()), instead of assuming a single protocol and quote asset. On a batch of newly-tested random Base tokens, it correctly returned a real answer for every single one — no more silent wrong answers, no more "unsupported."

Where this fits

AgentRisk M2M is a pre-trade risk API for Base tokens — honeypot detection, deployer wallet freshness, on-chain LP-lock verification, brand impersonation checks, and this sell simulation, plus cryptographically signed result receipts so other agents can verify a result without re-querying. Paid per call via x402 (0.15 USDC), or a free public UI with 3 free scans.

Repo: github.com/Neurobyteio/agentrisk
Try it: agentrisk.dev

Securing Autonomous AI Agents on Base: Why AgentRisk M2M is Changing On-Chain Security

Neurobyteio. Agentrisk M2M — Tue, 01 Sep 2026 12:39:29 +0000

The paradigm of web3 trading is shifting rapidly. We are moving away from human traders clicking buttons on DEX interfaces toward autonomous AI agents executing complex financial strategies 24/7.

However, if you are building or deploying trading bots and multi-agent systems on Base, you already know the harsh reality: the ecosystem is flooded with sophisticated traps. Traditional safety checkers rely on static analysis, reading contract code for known keywords like blacklist or pause. But malicious actors have evolved. They deploy dynamic honeypots, hidden taxes, and proxy scams that bypass traditional static scanners entirely.

To build a reliable autonomous agent, you need pre-trade risk intelligence that operates at machine speed (M2M). This is why we built AgentRisk.

What is AgentRisk M2M?
AgentRisk is a real-time, pre-chain risk-scoring engine designed specifically for autonomous AI agents and trading bots interacting with smart contracts on Base. Instead of forcing human intervention, AgentRisk provides programmatic, instantaneous safety verdicts using native micropayments via the x402 protocol.

The Core Problem with Legacy Scanners
Most existing tools tell you if a token is a honeypot after a human reviews a dashboard. But an AI agent executing a swap doesn't have time to wait for a human. If a bot encounters a dynamic honeypot—where a contract behaves safely for the first few blocks and then locks sales—static analysis will report it as safe, leading to an instant rug pull and lost funds.

How AgentRisk Solves It: Key Technical Features
To protect AI agents from multi-layered threats, AgentRisk combines multiple verification layers into a single API response:

Live Sell Simulation (QuoterV2): We don't just read the bytecode. AgentRisk executes a live simulation against liquidity pools using Uniswap V3 QuoterV2 integration to test a real sell quote. If the simulation fails or returns an astronomical slippage/block, the agent knows instantly that the token is un-sellable.

Cryptographically Signed Risk Receipts (ECDSA): Every risk assessment is backed by an ECDSA signature. Your agent receives a cryptographically verifiable proof of the security score, ensuring tamper-proof execution logic.

Comprehensive Multi-Source Risk Engine: The scanner aggregates data points including buy/sell tax percentages, ownership renouncement status, minting functions, holder concentration, and liquidity lock status.

Zero-Friction M2M Payments: Powered by the x402 protocol, agents can pay for checks via ultra-low-cost USDC micropayments natively, without API keys, human sign-ups, or complicated subscription forms.

Technical Architecture & Developer Experience
AgentRisk is built for developers who value clean tooling and flexibility. You can integrate our Python SDK into your trading bot or agent framework with minimal code:

Python
import asyncio
import os
from agentrisk import AgentRisk

async def main():
# Initialize the risk client for your autonomous agent
risk = AgentRisk(private_key=os.environ["PAYER_PRIVATE_KEY"])

# Scan any Base token address before executing a swap
result = await risk.scan("0x4200000000000000000000000000000000000006")

print(f"Verdict: {result['verdict']}")
print(f"Risk Score: {result['risk_score']}/100")
print(f"Is Honeypot: {result['is_honeypot']}")

asyncio.run(main())
What the API Returns
When your agent queries a token, AgentRisk compiles a robust data structure evaluating critical security vectors:

is_honeypot (bool)

buy_tax_pct & sell_tax_pct (float)

lp_locked_or_burned (bool)

risk_score & risk_level (string / int)

verdict (safe, caution, high_risk)

Join the Ecosystem
AgentRisk is already integrated into multiple developer directories, MCP registries, and open-source agent frameworks (including ongoing reviews in base/skills and BankrBot/skills).

If you are building AI trading agents, snipers, or automated executors on Base, stop letting dynamic honeypots drain your capital.

Documentation & Endpoints: agentrisk.dev

GitHub & Open Source PRs: Explore our implementations and contribute via GitHub.

Let's make autonomous on-chain finance safe for the next generation of AI builders. Feedback, pull requests, and feature suggestions are always welcome! 🛡️

Static Checks Said "Not a Honeypot." Live Simulation Disagreed. Twice, in 5 Random Tokens.

Neurobyteio. Agentrisk M2M — Mon, 31 Aug 2026 11:32:17 +0000

I ran 5 fresh, randomly picked Base tokens through AgentRisk M2M today — no cherry-picking, just tokens someone handed me to test. Two of the five produced a result worth writing about.

The two interesting cases

Both tokens passed static honeypot detection cleanly: is_honeypot: false, no blacklist function, no obvious sell-blocking logic in the bytecode. By a code-reading checker's standards, they looked fine.

Then live sell simulation — actually querying Uniswap V3's QuoterV2 for a real sell quote, right now, across every standard fee tier — came back sellable: false on both. Not one fee tier worked. Not a timeout, not a partial failure — a consistent, complete inability to get a sell quote.

json
{
  "is_honeypot": false,
  "sell_simulation": { "sellable": false },
  "findings": [{
    "code": "SELL_SIMULATION_FAILED",
    "severity": "critical",
    "message": "Live sell simulation failed across all fee tiers — this token may not be sellable right now, even though static checks did not flag it as a honeypot."
  }]
}

Why this happens

Static analysis reads the contract's code for known bad patterns — blacklist mappings, tax functions set to 100%, pause switches. It's looking for evidence of intent. But a contract can be entirely "clean" by that standard and still be unsellable right now for reasons that only show up in the current pool state: liquidity that's been pulled to near-zero on one side, a pair that technically exists but has no real depth, or timing-dependent mechanics that don't read as malicious code but produce the same real-world outcome — you can't get out.

Sell simulation doesn't ask "does this code look suspicious." It asks "if I tried to sell right now, what would actually happen." Different question, and apparently a meaningfully different answer for 2 out of 5 tokens today.

The honest caveat: what an agent does with this signal matters

Both of these tokens scored risk_score: 38 — under my should_execute threshold of 45. An agent that only reads the boolean should_execute field would still have bought both. An agent that reads the actual findings array and treats a critical severity entry as a hard stop would not have. That gap is worth being explicit about — a single risk score number, however well-calculated, can hide a critical individual signal if a consuming agent doesn't look past the top-line boolean.

Where this fits

AgentRisk M2M is a pre-trade risk API for Base — honeypot detection, deployer wallet freshness, brand impersonation, on-chain LP lock verification, cryptographically signed receipts, and this live sell simulation. Paid per call via x402, 0.15 USDC, or 3 free full scans per wallet on the public UI.

Repo: github.com/Neurobyteio/agentrisk
Try it: agentrisk.dev

I Added Cryptographically Signed Receipts to My Risk-Scoring API- Here's Why It Matters for AI Agents

Neurobyteio. Agentrisk M2M — Mon, 31 Aug 2026 08:17:42 +0000

Most token safety APIs — honeypot checkers, rug-pull detectors, scam scanners — return plain JSON. You either trust the response or you don't. There's no way for a downstream consumer, especially another autonomous AI agent, to verify that a result actually came from the service it claims to, or that it hasn't been tampered with in transit or cached somewhere stale.

I just closed that gap for AgentRisk M2M, a pre-trade risk-scoring API for Base tokens, by adding signed risk receipts.

The problem: JSON you have to trust, not verify

When one agent calls another agent's API to check if a token is safe to swap — honeypot detection, rug-pull risk, liquidity lock status — it gets back a JSON blob. If that agent wants to cache the result to avoid paying for a re-scan, or hand the result to a third agent downstream, there's no cryptographic guarantee the data is authentic. It's an honor system in a space that's specifically built around trustless, machine-to-machine transactions via protocols like x402.

The fix: ECDSA-signed attestations

Calling /scan?attest=true now returns the full risk report plus an attestation object:

json { "risk_score": 67, "risk_level": "HIGH_RISK", "attestation": { "scan_id": "...", "risk_score": 67, "input_digest": "sha256 of the request inputs", "rulepack_hash": "sha256 of the current scoring logic", "rulepack_version": "1.0.0", "chain": "base", "timestamp": 1788161104, "signer": "0x963E...", "signature": "0x..." } }

The signature is generated with a dedicated key — separate from the payment wallet — using standard ECDSA signing via eth_account. Anyone can independently recover the signer address from the message and signature and confirm it matches the published signer.

Why rulepack_hash and input_digest matter as much as the signature itself

A bare signature only proves "someone with this key signed something." The useful part is what gets signed:

input_digest ties the receipt to the exact token address and chain that were checked — so a receipt can't be replayed against a different input.
rulepack_hash is a SHA-256 hash of the scoring logic itself. If the detection rules change tomorrow, the hash changes, and any receipt issued before that point is honestly frozen to the rules that were live when it was generated. An agent evaluating an old cached receipt can tell at a glance whether it was scored under current logic or something older.
What this actually enables for agent-to-agent workflows
Caching without re-paying: an agent that already has a valid, recent, signed receipt for a token doesn't need to call /scan (and pay 0.15 USDC via x402) again — it can verify the signature locally and trust the cached result.
Passing results downstream: agent A can hand agent B a receipt as proof of what was checked, without B needing to trust A's word for it.
Detecting staleness or tampering: if a receipt's rulepack_hash doesn't match the currently published hash, or the timestamp is old, an agent can choose to refuse it and request a fresh scan instead of trading on outdated risk data.
Where this fits

AgentRisk M2M is a pre-trade risk API for Base — honeypot detection, deployer wallet freshness, brand impersonation checks, on-chain LP lock verification, and live sell simulation via Uniswap V3's QuoterV2 (catches dynamic honeypots — contracts that behave normally for the first N buys, then block sells — which static bytecode analysis misses). Paid per call via the x402 protocol, 0.15 USDC, no signup, no API keys. Also has a free public web UI (3 free full scans per wallet) at the link below.

Repo: github.com/Neurobyteio/agentrisk
Try it: agentrisk.dev

I Just Made My Paid Security API Free to Try — Here's the Design Thinking

Neurobyteio. Agentrisk M2M — Sun, 30 Aug 2026 17:15:45 +0000

AgentRisk M2M has been a pay-per-call API since launch: 0.15 USDC via x402, no signup. That's great for autonomous agents that already have a wallet and a reason to call you. It's a terrible experience for a human who just wants to see if your tool is any good before committing to anything.

So I added a public web UI with a twist: connect a wallet (just a signature, no funds touched), and get 3 completely free scans — the exact same full analysis a paying customer gets, not a stripped-down demo.

Why the same analysis, not a limited preview

A lot of "free trial" designs give you a watered-down taste — fewer fields, vaguer verdicts — specifically to create FOMO for the paid tier. I didn't want that. If someone's evaluating whether to trust this tool with their trading decisions, showing them a deliberately weaker version defeats the point. The free scan returns honeypot detection, live sell simulation, LP lock verification, deployer wallet freshness, and brand impersonation checks — everything.

Why wallet-gated instead of just... open

The obvious question: why not just let anyone hit the endpoint unlimited times? Two reasons. First, abuse — without some identifier, nothing stops one person from burning the free tier in a loop. A wallet address is harder to mint infinitely than an IP address behind a VPN. Second, honestly: it makes the "3 free checks, then it's 0.15 USDC" transition feel less like a sudden paywall and more like a natural continuation — you're already connected, the door to paying is right there.

What happened when I tried to make the paid path work in-browser too

I initially wanted the full loop to work end-to-end in the browser: free checks, then seamlessly pay for more, no code required. I got surprisingly far — Coinbase's official @x402/fetch and @x402/evm packages do work in a browser via ES module imports from a CDN, no build step needed. I got a real TransferWithAuthorization (EIP-3009) signature request to render in MetaMask.

Then MetaMask's Blockaid integration flagged it as a "deceptive request" — the payment wallet, being new with limited on-chain history, tripped an "untrusted EOA" heuristic. Nothing was actually wrong with the transaction; it's a reputation-scoring false positive that new legitimate addresses run into constantly.

I could chase a Blockaid allowlist request, but stepping back, I realized the audience for in-browser payment doesn't really exist here. Someone who wants to keep using the API programmatically is going straight to the GitHub repo and writing two lines of Python. An autonomous agent doesn't touch a browser at all — it calls the endpoint directly with x402-fetch or the Python SDK. The only people who'd hit the in-browser payment flow are casual visitors who've already gotten their 3 free looks and are deciding whether to go further — and for them, a clear "grab the code" button is a more honest next step than fighting a wallet's fraud heuristics.

Where it stands

Free checks are live at agentrisk.dev. After the third one, there's a straightforward link to the repo instead of a payment prompt that might scare people off with a false-positive warning. Sometimes the right fix isn't debugging the flow further — it's noticing the flow wasn't the right one for the audience in the first place.

Repo: github.com/Neurobyteio/agentrisk

I Added Live Sell Simulation to My Token Risk API — Here's What It Catches That Static Analysis Misses

Neurobyteio. Agentrisk M2M — Sun, 30 Aug 2026 09:54:45 +0000

Static honeypot detection has a blind spot: it reads contract code, not contract behavior. A token can look completely clean in its bytecode and still be unsellable in practice — some scammers design contracts to behave normally for the first N buys, then flip a switch that blocks sells entirely. No amount of reading _transfer() logic catches that in advance.

So I added a different kind of check to AgentRisk: instead of reading code, it actually simulates a sell right now, live, against the real pool.

How it works

Most tokens on Base trade through Uniswap V3, not V2. That matters here — V3 doesn't have a simple getAmountsOut() call like V2 does. Instead, I'm using Uniswap's QuoterV2 contract and its quoteExactInputSingle method, trying across the standard fee tiers (0.01%, 0.05%, 0.3%, 1%) until one resolves:

python
async def _simulate_sell(rpc_manager, token_address):
async def try_quote(w3):
for fee_value, fee_name in [(100, "0.01%"), (500, "0.05%"), (3000, "0.3%"), (10000, "1%")]:
try:
result = await w3.eth.call({
"to": QUOTER_V2_ADDRESS,
"data": build_quote_calldata(token_address, WETH, fee_value)
})
amount_out = int.from_bytes(result[:32], "big")
return {"sellable": True, "fee_tier": fee_name, "amount_out_weth": amount_out / 1e18}
except Exception:
continue
return {"sellable": False}
return await rpc_manager.call_with_fallback(try_quote)

No wallet needed, no gas spent, no real transaction — eth_call just asks "what would happen if" without committing anything.

What it actually caught

I tested it against a token already confirmed as a honeypot by static analysis (GoPlus flagged it, and it's independently verified on TokenSniffer):

json
{
"is_honeypot": true,
"sell_simulation": {"sellable": false}
}

Both signals agree — good, that's expected. But then I tested a normal, tradeable token where static analysis didn't have a strong opinion:

json
{
"is_honeypot": null,
"sell_simulation": {
"sellable": true,
"fee_tier": "1%",
"amount_out_weth": 0.000015
}
}

Here's the interesting part: GoPlus returned null for honeypot status — it genuinely didn't know. The live simulation gave a definitive, independent answer anyway. That's the actual value: not replacing static analysis, but backing it up with something that can't lie about the present moment.

Why this matters for autonomous agents specifically

A human trader might shrug at "unknown" and manually check DexScreener. An autonomous agent making a buy decision doesn't have that luxury — it either has a clear signal or it's flying blind. Live simulation turns "we don't know" into "we just checked, right now, for real."

Where this fits

AgentRisk is a pre-trade risk API for Base tokens — honeypot detection, deployer wallet freshness, brand impersonation, on-chain LP lock verification, and now live sell simulation. Paid per call via x402 (0.15 USDC), no signup. Listed on Coinbase's x402 Bazaar, base/skills, and Bankr's skill registry.

Repo: github.com/Neurobyteio/agentrisk
Try it: agentrisk.dev