Base WETH Before/After Fix

Scope

This before/after artifact uses the same Base WETH request on both sides of the March 29 false-positive fix: GET /analyze?address=0x4200000000000000000000000000000000000006.

• Exact request: GET /analyze?address=0x4200000000000000000000000000000000000006.
• Before snapshot: observed before the March 29 false-positive fix, when standard dispatcher/default-REVERT patterns could surface as a honeypot warning.
• After snapshot: observed after the fix, including paid production checks on 2026-04-04 and 2026-04-06 returning score=0, level=safe, decision=allow.
• Both JSON blocks are shaped like the live /analyze response contract and are static evidence, not recomputed on page load.

Bytecode size: 2041 bytes

Key findings

• Potential honeypot: conditional REVERT in transfer path honeypot - high - +25 points
  Contract has transfer functions with conditional REVERT patterns that could selectively block token transfers for certain addresses.

This was the wrong operational result for the canonical Base WETH first-call path. The detector was too broad around common control-flow patterns, so the policy layer blocked an otherwise standard wrapped asset.

Exact snapshot JSON

Snapshot captured on 2026-04-09. This block mirrors the live /analyze response shape but is not recomputed on page load.

{
  "address": "0x4200000000000000000000000000000000000006",
  "score": 25,
  "level": "low",
  "decision": "block",
  "recommended_policy": {
    "action": "block",
    "summary": "Block automatic interaction by default. Only proceed with an explicit override after deeper review.",
    "reason_codes": [
      "honeypot_signal"
    ]
  },
  "bytecode_size": 2041,
  "findings": [
    {
      "detector": "honeypot",
      "severity": "high",
      "title": "Potential honeypot: conditional REVERT in transfer path",
      "description": "Contract has transfer functions with conditional REVERT patterns that could selectively block token transfers for certain addresses.",
      "points": 25
    }
  ],
  "category_scores": {
    "honeypot": 25
  }
}

Bytecode size: 4632 bytes

Key findings

After the fix, the same request returns the intended first-call shape: score 0, level safe, and decision allow. That makes Base WETH a better onboarding and evaluator smoke-test target.

Exact snapshot JSON

Snapshot captured on 2026-04-09. This block mirrors the live /analyze response shape but is not recomputed on page load.

{
  "address": "0x4200000000000000000000000000000000000006",
  "score": 0,
  "level": "safe",
  "decision": "allow",
  "recommended_policy": {
    "action": "allow",
    "summary": "Allow by default for first-pass automation. Continue only if this matches your broader strategy and trust model.",
    "reason_codes": []
  },
  "bytecode_size": 4632,
  "findings": [],
  "category_scores": {}
}

What this report proves

• The product became less noisy on a canonical Base contract without widening the API.
• This is the kind of quality proof evaluators need before trusting Augur as a repeat machine-to-machine preflight.
• The first-call example now points at a request that should return a clean allow result rather than a false-positive warning.

Reuse the live API

If you want the same response shape for your own contract list, call the canonical paid endpoint:

curl -s "https://augurrisk.com/analyze?address=0x4200000000000000000000000000000000000006" \
  -H "PAYMENT-SIGNATURE: <x402-payment-proof>" | jq

Payment is per-call in USDC on Base via x402. For the payment flow details, see How Augur payment works.