Payment address rotation doesn't automatically equal a scam.

My logic was simple: if the advertised payTo address changes, flag the counterparty. I integrated this into a reputation system and crawled the x402 Bazaar. The result? High-profile endpoints like Browserbase and Tavily were flagged as honeypots simply because they rotate keys.

The False Positive Breakdown

The system triggered honeypot:payto_swap labels, which tanked trust scores to 0. In a real-world AI workflow or automated payment agent, this would trigger a "review" or "block" verdict for any transaction over 1000.

The failure wasn't just in the logic, but in the reporting. The system provided a hardcoded reason:

observed in active probing: payto_swap

This was misleading because the data came from a passive daily crawl, not active probing. It claimed to have tested something it had never actually touched.

Why the "Change = Fraud" Logic Failed

The assumption that an address change implies a honeypot ignores how actual infrastructure operates. I discovered several flaws in the detection method:

• Visit Cadence: I thought I was taking daily snapshots, but the registry size fluctuates. With over 14,000 listings, some endpoints weren't being visited for several days, making the "daily" claim inaccurate.
• Cursor Bugs: The crawl cursor actually got stuck because the registry shrank below the saved offset. The system spent days returning empty windows without alerting me, proving that evidence based on visit frequency is incredibly fragile.
• Key Rotation: Legitimate vendors rotate keys for security or load balancing. A static address is not a requirement for a trustworthy vendor.

For anyone building a screening library or an LLM agent capable of handling payments, this is a reminder that "anomaly" does not always mean "attack." A more robust deep dive into vendor behavior is needed before assigning severity signals to simple address rotations.