DEV Community: Neurobyteio. Agentrisk M2M

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

Neurobyteio. Agentrisk M2M — Fri, 02 Oct 2026 08:38:06 +0000

The problem

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 a plain
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.

MiniAppShield: Building Infrastructure Intelligence for Telegram Mini Apps

Neurobyteio. Agentrisk M2M — Thu, 01 Oct 2026 11:17:57 +0000

The Hidden Layer Behind Telegram's Mini App Explosion
Telegram Mini Apps have transformed the messenger from a communication tool into a full commercial platform. The numbers tell a story of explosive growth: Mini Apps grew from 2,388 to 8,923 between January and October 2025, while the number of bots surged from 9,297 to 58,482 . Rewarded ads now generate eCPMs of $12-35 in hypercasual games, with completion rates reaching 70-90% .

But beneath this growth lies a structural problem that ad networks and advertisers are only beginning to understand: the infrastructure layer of Telegram Mini Apps is largely invisible.

What Ad Networks Currently See
PropellerAds, RichAds, AdsGram, and Monetag have all built sophisticated anti-fraud systems. They detect bots, filter invalid traffic, score publishers, and monitor behavioral anomalies. PropellerAds explicitly states that Mini App advertising may be less exposed to traditional fraud because "ads are shown during real in-app activity rather than through channel inventory that can be artificially padded" .

RichAds has developed TMA-specific targeting, including options for "Telegram Premium subscribers only" and "users with positive TON wallet balance" . AdsGram advertises multi-layer anti-fraud against bots and dishonest impressions.

These systems work inside the advertising transaction. They answer: Is this impression valid? Is this click real? Is this user human?

What they do not answer is a different question: What is this Mini App? What infrastructure stands behind it? How has it changed over time? Is it related to previously observed risky publishers?

The Infrastructure Intelligence Gap
This is where MiniAppShield operates. Not as a competitor to ad network anti-fraud, but as an adjacent layer that observes the Mini App ecosystem at a structural level.

Consider what our Observatory has already discovered:

A complete K6 cluster: Six Telegram Mini Apps, each connected to every other through shared application-specific JavaScript hashes and API endpoints. Fifteen out of fifteen possible pairs. Sixteen shared JS artifacts and fourteen shared API endpoints per pair.

A GPT-focused K4 cluster: Four AI-related Mini Apps with thirty-nine shared JS artifacts per pair.

Two separate VPN triangles: Six VPN-related Mini Apps forming two independent infrastructure clusters.

These are not coincidences. They are technical fingerprints that reveal shared infrastructure behind different Telegram identities.

Why This Matters for Ad Networks
PropellerAds' own reporting acknowledges that fraud in Telegram has historically involved "fake channel metrics, cloned administrators selling ad placements, and bot-inflated audiences" . The company argues Mini Apps are less vulnerable because ads are served during real activity.

This is partially true. But it misses a critical scenario:

A banned Mini App can return under a new Telegram identity while maintaining the same backend infrastructure.

For an ad network, a new bot ID looks like a new publisher. For MiniAppShield, it looks like a reincarnation—the same domain family, same JS hashes, same API endpoints, same CDN buckets, same analytics IDs.

The network sees a new source. We see continuity with a previously observed risk.

The Time-Based Moat
Scanning Mini Apps can be replicated. Anyone can build a crawler and capture runtime data.

What cannot be replicated retroactively is historical infrastructure intelligence.

MiniAppShield currently tracks:

650+ Telegram Mini Apps

1,100+ historical snapshots

55+ exact technical relationships

Every relationship has an observation_count. Currently, most are at 1—a single observation. But as monitoring continues, these counts grow. A relationship observed across 6 snapshots over 3 weeks becomes something fundamentally different from a one-time detection.

This enables signal types that do not exist elsewhere:

Publisher Reincarnation Detection: Identifying when a previously banned Mini App returns under a new Telegram identity through shared infrastructure artifacts.

Monetization Drift: Detecting when a Mini App that previously served no ads suddenly integrates an ad SDK, adds rewarded video endpoints, or introduces external redirectors—signaling a pivot toward aggressive monetization.

Infrastructure Relationship Graph: Mapping hidden connections between seemingly unrelated Mini Apps, revealing clusters that operate as coordinated entities.

Beyond the Username: Analyzing Telegram Mini Apps with MiniAppShield

Neurobyteio. Agentrisk M2M — Wed, 30 Sep 2026 13:14:44 +0000

A Telegram Mini App can look like an independent product while sharing its frontend, backend, and advertising infrastructure with other apps.

For advertisers, developers, and security researchers, those connections matter. But they are difficult to spot from a Telegram username or a few screenshots.

MiniAppShield is a Telegram Mini App intelligence platform that combines runtime analysis, advertising technology detection, technical relationships, and historical observations into one Full Audit.

Here is a real example of what that analysis can reveal.

Four Mini Apps, one technical cluster

During our research, MiniAppShield identified exact technical relationships between:

@aqptuuybot
@fpngoobot
@xoimqrbot
@gretaxrobot

The applications shared:

Evidence	Finding
Launch destination	The same launch URL
Frontend code	16 shared app-specific JavaScript fingerprints
Backend surface	14 shared API endpoints
Runtime behavior	Very similar runtime profiles
Technical relationships	All 6 possible pairs matched

These findings establish shared technical infrastructure. They do not prove common ownership or fraudulent activity.

For someone evaluating advertising placements, that distinction is valuable: four different usernames may represent substantially overlapping technical products.

What MiniAppShield examines

A username starts the investigation. The Full Audit brings together several evidence layers.

Identity and launch destination: Is this a Telegram Mini App or an ordinary bot? Where does the application load?

Browser runtime: What network requests, JavaScript assets, API activity, storage indicators, and rendered content appear during execution?

Runtime quality: Were navigation errors, failed requests, HTTP errors, or page-level exceptions observed?

Advertising technology: Which advertising components, SDK configurations, and execution signals were captured?

Technical relationships: Does the app share distinctive artifacts with other applications?

History: What changed between observations?

Users receive a summary in Telegram and can open a detailed browser report to inspect the supporting evidence.

JavaScript fingerprints and API endpoints

JavaScript fingerprinting helps identify matching code across applications. A content hash supports an exact match for a captured JavaScript asset.

However, shared public libraries are common. Two apps using the same framework do not necessarily have a meaningful relationship.

App-specific code is more informative, especially when multiple fingerprints match alongside API endpoints and launch destinations.

That combination made our four-app cluster interesting. It was more than a shared analytics script: it included 16 application-specific JavaScript fingerprints and 14 API endpoints.

Advertising SDK detection versus ad execution

For Telegram advertisers and ad networks, detecting advertising technology is useful—but the evidence needs precise interpretation.

An SDK reference, a configuration response, an ad request, and an impression event represent different stages.

An SDK may load without requesting an ad. A request may return no fill. A tracking reference alone does not establish a completed impression.

MiniAppShield separates observed advertising infrastructure from observed advertising execution, helping reviewers understand what the captured session actually shows.

Runtime errors need context

A failed image and a failed authentication request can both increase an error counter. Their impact on the application is very different.

Useful runtime analysis asks:

Which resource failed?
Was it part of a core user flow?
Did the application initialize successfully?
Did the problem repeat?

Similarly, an HTTP 403 response to an automated scanner does not establish that regular Telegram users encounter the same restriction.

The goal is to connect technical observations to practical consequences.

Why historical evidence matters

A single scan captures one session. Historical comparisons help reveal destination changes, advertising stack changes, repeated failures, and newly observed infrastructure relationships.

As the database grows, new Mini Apps can be compared with previously captured JavaScript fingerprints and API surfaces.

This supports Telegram Mini App due diligence, publisher review, portfolio analysis, and security research.

The central question becomes:

What is this Mini App technically connected to, and where have we seen these artifacts before?

Explore MiniAppShield

MiniAppShield brings together Telegram Mini App analysis, JavaScript fingerprinting, advertising intelligence, runtime inspection, and infrastructure relationship detection.

🌐 https://appshield.app/

Which evidence matters most to you when evaluating a Mini App: advertising activity, runtime reliability, or shared infrastructure?

How to Audit a Telegram Mini App Before Running Ads

Neurobyteio. Agentrisk M2M — Sat, 26 Sep 2026 11:13:23 +0000

How to Audit a Telegram Mini App Before Running Ads
Telegram Mini Apps have become a real distribution layer for games, Web3 products, wallets, utilities, e-commerce experiences, loyalty systems, advertising funnels, and many other services.
But for advertisers, agencies, ad networks, traffic partners, and ecosystem operators, one problem remains:
What do you actually know about a Mini App before sending traffic or budget to it?
A Telegram username and a landing page are not enough.
A Mini App may look completely normal while still having technical characteristics that matter commercially:

its destination URL may have changed
its backend infrastructure may have changed
advertising SDKs may have been added or removed
runtime behavior may differ from what was observed previously
multiple Mini Apps may share exact technical artifacts
multiple apps may use the same observed advertising identity
a Mini App may technically load while showing degraded runtime behavior
advertising infrastructure may exist even when active ad delivery is not observed in a particular session This is the problem we are working on with MiniAppShield. MiniAppShield is a Telegram Mini App intelligence and audit system designed to turn technical observations into evidence that can be reviewed before commercial decisions are made. Why Telegram Mini App due diligence is difficult Traditional website checks are not enough for Telegram Mini Apps. The application often depends on several layers at once:
Telegram bot metadata
Telegram Mini App launch configuration
WebView destination
frontend application
backend APIs
third-party SDKs
analytics systems
advertising infrastructure
wallet or blockchain integrations
runtime behavior A static URL check only covers a fraction of this. For example, discovering an advertising SDK in JavaScript does not prove that an advertisement was actually delivered. Likewise: SDK detected ≠ ad execution ad request ≠ impression technical relationship ≠ common ownership absence of observed advertising ≠ advertising is never present These distinctions are important if the output is supposed to be used for real due diligence. What MiniAppShield analyzes Our current Full Audit pipeline combines multiple independent intelligence layers.
Identity and relationships MiniAppShield looks for exact observed relationships between Mini Apps. These can include:
shared advertising identity signals
shared technical artifacts
infrastructure relationships
application-specific fingerprints
connected Mini App clusters The goal is not to make unsupported claims such as "these apps have the same owner." Instead, we preserve the evidence and describe the relationship that was actually observed. For example: Exact technical relationship observed through a shared application-specific artifact.

That statement is much stronger and more defensible than guessing who operates the applications.

Activity and liveness A Mini App can exist in a catalog or Telegram while being partially broken, inactive, inaccessible, or operational only under certain conditions. MiniAppShield therefore examines runtime evidence such as:
HTTP response state
rendered application content
DOM activity
Telegram WebView bridge activity
network requests
interactive surfaces
runtime failures
page-level errors
console errors
server errors This gives a more useful question than simply: Does the URL exist?

The real question is:
Was meaningful Mini App runtime activity observed during the audit?

Runtime quality Operational status is tracked independently from security or commercial interpretation. Examples of runtime diagnostics include:
failed network requests
HTTP 4xx responses
HTTP 5xx responses
navigation failures
JavaScript page errors
console errors
total observed requests
runtime coverage A degraded runtime observation does not automatically mean the application is malicious. It simply means that technical instability was observed during that audit.
Advertising intelligence Advertising inside Telegram Mini Apps is particularly interesting because static detection is not enough. MiniAppShield separates several levels of evidence. Advertising technology observed An ad SDK, script, configuration, or advertising endpoint may be present. Advertising execution observed The application actually performs advertising-related runtime activity. Creative delivery observed Evidence associated with an advertising creative is observed. Impression-related evidence observed Runtime evidence indicates a later stage of the advertising lifecycle. This prevents one of the most common analytical mistakes: detecting an advertising library and immediately claiming that the Mini App is actively serving ads.
Network and infrastructure intelligence During runtime observation, MiniAppShield records structural network information such as:
contacted domains
application endpoints
third-party services
advertising endpoints
analytics infrastructure
JavaScript assets
technical artifacts These observations can later become useful when comparing applications. A single domain may not mean much. But the same specific technical artifact appearing across several otherwise unrelated Mini Apps may be much more interesting.
Change intelligence One scan tells you what happened once. A historical dataset tells you what changed. This is one of the most important parts of the MiniAppShield direction. Repeated observations can reveal:
destination changes
infrastructure changes
SDK changes
advertising stack changes
technical relationship changes
audience metadata changes
runtime behavior changes This turns a scanner into an observatory. For commercial due diligence, history is often more valuable than a single point-in-time verdict.
Telegram audience intelligence Where Telegram exposes audience information, MiniAppShield can preserve observations such as monthly active user metadata. But audience numbers are treated separately from traffic quality. For example: 100,000 monthly active users

does not automatically mean:
100,000 high-quality advertising users.

Audience size, audience authenticity, conversion quality, and advertising performance are different questions.
A practical Mini App audit workflow
A useful pre-flight workflow can look like this:
Step 1 — Identify the exact Telegram source
Start from the Telegram username rather than a manually supplied external website.
This reduces ambiguity about which Mini App is actually being analyzed.
Step 2 — Resolve the Mini App launch destination
Observe the Main WebView or other legitimate application route.
Step 3 — Perform static and structural analysis
Collect technical characteristics without making conclusions from a single indicator.
Step 4 — Observe the application runtime
Launch the application in a controlled environment and observe:

initialization
network activity
Telegram bridge behavior
runtime errors
third-party integrations
advertising execution Step 5 — Compare against historical observations Ask:
Has the destination changed?
Has the advertising stack changed?
Have new domains appeared?
Have important technical artifacts changed? Step 6 — Compare against other Mini Apps Look for exact observed technical or advertising relationships. Step 7 — Present evidence, not a magic score A single "risk score" can hide too much context. MiniAppShield instead separates independent layers such as:
identity and relationships
activity and liveness
runtime quality
advertising activity
change intelligence
observation depth
audience intelligence This makes the result easier to explain and review. What MiniAppShield is becoming MiniAppShield started as a Mini App scanner. The larger direction is different. We are building a growing Telegram Mini App Observatory. The process includes:
discovering Mini Apps from multiple public sources
removing bots, aliases, duplicates, and weak candidates
validating actual Mini App runtime
preserving structured technical observations
identifying exact relationships
monitoring applications over time We already have hundreds of confirmed Telegram Mini Apps in the dataset, with additional candidates going through discovery and validation. The goal is not simply to collect the largest possible list of usernames. The goal is to build a clean, deeply analyzed, historical intelligence dataset for Telegram Mini Apps. Who can use this type of intelligence? Potential users include: Advertising networks Before accepting a new traffic source or Mini App partner, a network can inspect its technical and advertising context. Performance marketing agencies Agencies buying Telegram traffic can perform technical due diligence before committing campaign budget. Advertisers An advertiser can review the environment where campaigns may appear. Security teams Security analysts can investigate runtime behavior, infrastructure, and application relationships. Wallet and Web3 teams Telegram has become an important distribution channel for crypto, gaming, TON, and wallet-related products. Runtime and infrastructure intelligence can provide additional context around applications interacting with these ecosystems. Investors and due-diligence teams Historical technical observations can complement product, financial, and legal due diligence. Why historical intelligence matters Imagine evaluating a Mini App today. Everything looks normal. But historical observations show that:
its WebView destination changed three times
a new advertising integration appeared two weeks ago
the backend domain changed recently
an exact technical artifact also appears in several other Mini Apps
the runtime behavior changed after the previous observation None of those facts independently proves wrongdoing. But together they provide context that a one-time website inspection cannot provide. That is the real value of continuous Mini App intelligence. MiniAppShield MiniAppShield is being developed as an independent intelligence layer for the Telegram Mini App ecosystem. The current platform focuses on:
Telegram Mini App audit
runtime analysis
advertising intelligence
infrastructure analysis
technical relationships
historical monitoring
change intelligence
Telegram audience observations
Mini App discovery You can follow the project at: Website: https://appshield.app/ Telegram: @MiniAppShield Telegram Bot: @MiniAppShield_bot

Building a Pre-Trade Token Safety API for AI Trading Agents on Base — Lessons from Shipping x402 Bazaar Discovery

Neurobyteio. Agentrisk M2M — Fri, 25 Sep 2026 06:53:22 +0000

AgentRisk M2M is a pre-trade token risk and honeypot detection API built for autonomous AI trading agents operating on Base. Every AI agent that trades ERC-20 tokens faces the same problem before executing a swap: is this contract a honeypot, a rug pull, or a legitimate token? Doing that check reliably — not just reading a static score, but verifying a token is actually sellable — turns out to be harder than it looks.

The core problem: static safety scores aren't enough

Most token safety checkers return a single boolean or score based on static bytecode analysis. That catches obvious red flags — mint functions, blacklist functions, ownership that was never renounced — but it misses a critical class of scams: contracts that look clean statically but block sells dynamically, through logic that only triggers under specific conditions.

AgentRisk M2M's core differentiator is live sell simulation — instead of trusting a static flag, it actually simulates a sell against the live pool state on-chain, across Uniswap V2, V3, V4, and Aerodrome (both V1 and Slipstream). If the simulated sell reverts, the token is flagged as a honeypot regardless of what the static analysis says.

What the API checks
Honeypot detection (via live sell simulation + GoPlus Security cross-reference)
Buy/sell tax percentage, including hidden tax flags
Ownership: renounced status, hidden owner detection, "can take back ownership" flag
Mint, blacklist, whitelist, pause, and self-destruct function presence
LP lock/burn status and percentage
Holder concentration (top-10 holder %, creator %)
Deployer wallet reputation and freshness
Brand impersonation detection
Exit Liquidity Score — simulated price impact at $100/$1k/$10k sell sizes

The output is a machine-readable riskScore (0–100), a riskLevel (SAFE / CAUTION / HIGH_RISK / CRITICAL_HONEYPOT), and a shouldExecute boolean an agent can act on directly — no natural-language parsing required.

Payment: x402, not API keys

AgentRisk uses the x402 protocol for pay-per-call access — 0.15 USDC per scan on Base, settled directly on-chain. No signup, no API key management, no rate-limit tiers. An agent's wallet signs a payment authorization, the facilitator (Coinbase CDP) verifies and settles it, and the scan result comes back in the same request. A free trial (3 scans per wallet) is available via /scan-trial for testing before committing to paid calls.

This matters specifically for autonomous agents: there's no human in the loop to manage credentials. The agent's wallet is the identity.

Discovery: what actually makes an agent find your API

Here's the part most people skip when writing about x402: shipping an API that accepts x402 payments is not the same as being discoverable by autonomous agents. That requires implementing the x402 Bazaar discovery extension correctly — declaring input/output schemas in your 402 response so a facilitator can catalog your service and agents can find it via semantic search, not just direct URL knowledge.

I found this out the hard way: a builder-code attribution extension I'd added was being merged into the extensions object with a dict-unpack (**declare_builder_code_extension(...)) instead of being nested under its own named key. That silently broke the Bazaar extension's schema validity — the service was accepting payments and returning valid results the whole time, but wasn't properly cataloged for discovery. Fixed by nesting each extension under its constant key (BUILDER_CODE: declare_builder_code_extension(...)) instead of unpacking blindly.

Lesson: if you're building an x402 service, decode your own 402 response and check the extensions object structure against the spec. A working payment flow tells you nothing about discoverability.

Where it's live
API / MCP server: agentrisk.dev
x402 Bazaar: cataloged and discoverable
MCP Registry: io.github.Neurobyteio/agentrisk
Smithery: daniel-arbitr/agentriskm2m
Integrations: MCP server, Python SDK (agentriskm2m), MetaMask Snap, ElizaOS plugin, LangChain tool, Vercel AI SDK tool, Coinbase AgentKit action provider
Live on-chain stats: viewable on x402 Lens — transaction volume and settlement data, publicly verifiable
What's next

Still early — the goal now is getting the API in front of more agent developers building on Base, not adding more features. If you're building a trading agent, an MEV bot, or any autonomous system that needs pre-trade due diligence on Base tokens, I'd genuinely like feedback: github.com/Neurobyteio/agentrisk.

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

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

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

How it works

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

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

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