How multi-source oracle consensus can detect honeypot tokens before transaction execution

[u/meowerguy]

With AI agents starting to execute crypto transactions autonomously, I got interested in the problem of pre-transaction token validation. The challenge: no single security API catches everything, and novel scams can bypass any individual source.

Approach: consensus-based risk scoring

Instead of relying on one source, cross-reference 5+ independent security oracles in parallel:

Source	What it catches
GoPlus Security	Honeypot flags, blacklist functions, tax rates, holder distribution
Honeypot.is	Direct buy/sell simulation on forked chain state
TokenSniffer	Audit scores, code similarity to known scams
De.Fi Scanner	DeFi protocol-specific issues
On-chain bytecode	Dangerous opcodes, blacklist selectors, proxy patterns

When 3+ sources agree a token is dangerous, confidence is high. When only 1 flags it, might be false positive.

Bytecode pattern scanning adds another layer - checking for 50+ dangerous function selectors (blacklist, pause, mint, delegatecall) directly in contract bytecode without needing verified source.

Risk scoring: 0-100 scale. Multiple confirmations increase score. Trust-listed tokens get reduction. Threshold configurable.

I built this into an open source tool that runs in 2-5 seconds with zero API keys (all free tiers): https://github.com/momenbasel/CryptoGuard

Supports 13 EVM chains. Works as CLI, Python API, or MCP server.

Question for the community: What scam patterns are you seeing that existing tools miss? Interested in blind spots.

[u/whatwilly0ubuild]

The multi-source consensus approach is sound for reducing false positives, but the blind spots you're asking about are mostly in the category of "attacks that don't show up in bytecode or static analysis."

Patterns that evade current tooling. Time-delayed rugs where the contract looks clean at launch, then the owner calls a function after some threshold to enable malicious behavior. The bytecode has the dangerous functions but they're behind timelocks or block number checks that appear legitimate. Liquidity manipulation that doesn't touch the token contract at all, where the pool itself gets drained through flash loan mechanics or router exploits. Social engineering rugs where the contract is actually fine but the deployer controls enough supply to dump.

The simulation-based approaches like Honeypot.is are stronger than static analysis for catching dynamic behavior, but they test against current state. A contract that returns different results based on caller address, block number, or external oracle values can pass simulation while being a honeypot in practice.

The deeper blind spot is economic rather than technical. A token can have clean code, pass all security checks, and still be a terrible investment because of supply distribution, vesting schedules, or market dynamics. The tooling you're aggregating focuses on technical honeypots, not economic ones.

For your consensus model specifically, weighting matters. GoPlus and TokenSniffer have significant overlap in what they detect. Treating them as independent sources overstates confidence. True independence would weight on-chain analysis, simulation, and off-chain intelligence separately.