anchor-x402 — Threat Model

Version: 1.0 Last reviewed: 2026-05 Audience: institutional procurement, security review, compliance Author / contact: security at the email below

1. Executive summary

anchor-x402 is a public, anonymously-consumable, pay-per-call microservice platform on AWS Lambda. Of its eighteen paid endpoints, this threat model covers the thirteen trust-relevant ones across three families: trust infrastructure & evidence (anchor, attest, screen, intel/wallet, investigate, ledger/report), stateless commodity utilities (decode/tx, decode/calldata, resolve/name, price/token, parse/datetime, ledger/summary), and verifiable RNG (roll). The five LLM content endpoints — roast, oracle, tldr, aura, grade — are out of scope: they take freeform text, return generated content, and produce no wallet-risk verdict or compliance evidence; they inherit only the cross-cutting controls in §4. Settlement is in USDC on Base or Solana mainnet via the x402 v2 protocol; there is no API key, no customer account, no session. What you get for the per-call price is a single signed JSON response and — for anchor, attest, investigate, and ledger/report — an on-chain anchor whose calldata you can independently verify forever, even if anchor-x402 is later compromised, terminated, or attempts to lie. What you do not get is a SOC 2 report, a DPA, per-tenant authentication, a dedicated tenancy plane, or any service-side retention of your inputs beyond the two async job stores (investigate, ledger/report) noted in their tables below. This is by design: the platform is positioned as a commodity tier sitting one layer below a fully-managed assurance product (e.g. our sister project Counsel, which carries WORM evidence, officer allowlists, and Article 17 erasure).

Reviewers should treat the service as a stateless oracle with on-chain evidence as the trust anchor: if you only need a verifiable Merkle commitment that a hash existed at time T, the dual-chain anchor is structurally robust against operator compromise, since forging the record requires reorging two L1s plus breaking SHA-256. For services that depend on upstream data (screen, price/token, decode/calldata, intel/wallet, resolve/name), the trust ceiling drops to “no worse than the upstream” — you should treat results as advisory and re-derive any decision-critical fact from a primary source. Per-service threat tables, cross-cutting threats, and known limitations are below; if you find a vulnerability please follow the disclosure policy in §7.

2. Trust boundaries

2.1 What the consumer trusts

2.2 What the consumer does not have to trust

2.3 Boundary diagram

┌─────────────┐     1. HTTPS + x402 PaymentRequired handshake
│ Consumer    │  ◀──────────────────────────────────────────┐
│  (agent)    │                                              │
└──────┬──────┘                                              │
       │ 2. Signed USDC payment header                       │
       ▼                                                     │
┌──────────────────────────────────────────────────────────┐ │
│ AWS API Gateway (TLS termination, AWS-managed cert)      │ │
└──────────────────────┬───────────────────────────────────┘ │
                       │                                     │
                       ▼                                     │
┌──────────────────────────────────────────────────────────┐ │
│ AWS Lambda  (Python 3.12, FastAPI + x402 middleware)     │ │
│   - reads secret on cold start ───┐                      │ │
│   - in-process 60s cache          │                      │ │
│   - no disk / DB writes           │                      │ │
└─────┬─────────┬─────────┬─────────┼──────────────────────┘ │
      │         │         │         │                        │
      ▼         ▼         ▼         ▼                        │
┌──────────┐┌────────┐┌────────┐┌─────────────┐              │
│ AWS      ││ CDP    ││ Public ││ Public RPC  │              │
│ Secrets  ││ x402   ││ APIs   ││ (Base+Sol)  │              │
│ Manager  ││ facil. ││ (CG,   ││ + ENS / SNS │              │
│ (KMS)    ││ (set-  ││ open-  ││             │              │
│          ││  tle)  ││ chain) ││             │              │
└──────────┘└────────┘└────────┘└──────┬──────┘              │
                                       │                     │
                                       ▼                     │
                              ┌─────────────────┐  3. Signed │
                              │ Base + Solana   │     JSON   │
                              │ mainnet (anchor │  ──────────┘
                              │ + attest only)  │
                              └─────────────────┘

The dotted line: outputs from anchor and attest cross trust boundary 5 (chain finality) and become independently verifiable. Outputs from the other seven services do not — they are signed by AWS TLS only and have the same operator-trust ceiling as any SaaS API.

3. Per-service threat tables (STRIDE-lite)

Each row is a concrete attack scenario, the existing mitigation, and the residual risk the consumer must accept. We focus on threats that change the consumer’s decision-making, not on threats to the operator’s revenue.

3.1 POST /v1/anchor — $0.005 — dual-chain hash anchoring

Differentiator (see §5): for this endpoint the consumer’s trust requirement on anchor-x402 is limited to liveness. Correctness is enforceable independently from the chain.

3.2 GET /v1/screen — $0.02 — wallet risk pre-flight (OFAC + address-reputation)

Known limitation: the OFAC corpus is a static snapshot, not a live feed. This is documented in §6 and in the source comments. Reviewers should not rely on /v1/screen as a primary AML control.

3.3 POST /v1/attest — $0.010 — signature verification + dual-chain anchor

Differentiator (see §5): like /v1/anchor, this endpoint produces an on-chain record that is provable without trusting anchor-x402. The signed message + signature + recovered signer can be re-verified offline by anyone with the response.

3.4 POST /v1/decode/tx — $0.001 — mainnet transaction decoder

3.5 GET /v1/resolve/name — $0.001 — ENS / Bonfida SNS

3.6 GET /v1/price/token — $0.001 — CoinGecko-backed spot price

3.7 POST /v1/decode/calldata — $0.001 — 4byte / openchain.xyz + ABI decode

3.8 POST /v1/parse/datetime — $0.001 — freeform datetime parser

3.9 GET /v1/intel/wallet — $0.005 — bundled wallet intelligence

3.10 POST /v1/investigate — $1.77 — agent-driven wallet due diligence (async)

Async: the paid POST returns a job_id; the deliverable arrives at /v1/investigate/status/{job_id} in 5–10 min. The investigation runs on an isolated AWS Bedrock AgentCore worker over read-only public data.

Differentiator (see §5): the finished report is on-chain-verifiable like /v1/attest.

3.11 POST /v1/ledger/summary — $0.01 — x402 spend accounting

3.12 POST /v1/ledger/report — $0.35 — signed + anchored expense report (async)

Async: the paid POST returns a job_id; poll /v1/ledger/report/{job_id}. Worker path: scan → render (markdown + CSV) → sign → anchor → S3.

Differentiator (see §5): on-chain-verifiable like /v1/attest.

3.13 POST /v1/roll — $0.001 — verifiable signed RNG

4. Cross-cutting threats

These apply uniformly to the endpoints documented here and are not repeated in the per-service tables.

4.1 AWS account compromise

4.2 Treasury key leak

4.3 x402 facilitator (CDP) compromise

4.4 Upstream API compromise

4.5 Supply chain (pip dependencies)

4.6 DoS amplification ($0.001 inbound → $$ outbound)

The cheapest endpoints ($0.001) are the highest amplification surface. Threat profile per endpoint:

/v1/intel/wallet is the only endpoint where a single paid call can fan out to multiple RPC providers. Lambda concurrency is the cap. Mitigation roadmap: per-IP API Gateway throttling. Currently relies on the AWS API Gateway default account-wide limit (10,000 RPS) which is well above any griefing budget at $0.005 per call.

4.7 Single-region deployment

The service is deployed only in us-east-1. A regional AWS outage takes the service down. There is no failover region. Consumers requiring multi-region SLA should not adopt this service for critical-path use.

5. On-chain verifiability — the structural differentiator

For most covered endpoints, anchor-x402 is a normal SaaS API: you trust TLS, the AWS runtime, and the operator’s good faith. For /v1/anchor, /v1/attest, /v1/investigate, and /v1/ledger/report, the trust model is fundamentally different — each produces an artifact whose sha256 is anchored on two L1s (and, except anchor, EIP-191-signed), so correctness is verifiable without trusting the operator. /v1/roll is signed but not anchored by default, so it is verifiable-as-issued but not bias-resistant (see §3.13). The mechanics below use /v1/anchor and /v1/attest as the canonical examples; the other anchored endpoints follow the same attest-style pattern.

5.1 What lands on chain

For every successful call to /v1/anchor:

• Base mainnet: an EIP-1559 transaction whose data field is exactly 0x + the 64-character merkle root. From → to is the operator’s treasury address (self-send). Cost: ~21,400 gas + 64 bytes calldata.
• Solana mainnet: a Memo program instruction containing the merkle root as UTF-8.

For /v1/attest, the same dual-chain anchor is performed, but the merkle root is computed deterministically as:

sha256("anchor-x402/attest/v1\ninput=<hash>\noutput=<hash>\ndecision=<label>")

— so any third party holding (input_hash, output_hash, decision) can re-derive the merkle root and verify it matches the on-chain calldata.

5.2 What this defeats

5.3 What it does not defeat

5.4 Verification recipe (consumer-side)

For any anchor or attest response, the consumer should run:

# Python pseudo-code
from eth_utils import to_bytes
import requests

# 1. Re-derive the merkle root from your own copy of the inputs
expected = sha256(canonical_bytes(your_inputs)).hexdigest()
assert expected == response["merkle_root"]

# 2. Pull the Base tx and confirm calldata
tx = base_rpc.eth_getTransactionByHash(response["base"]["tx"])
assert tx["input"].lower() == "0x" + expected
assert tx["from"].lower() == operator_treasury_address.lower()

# 3. Pull the Solana tx and confirm Memo data
sol = solana_rpc.getTransaction(response["solana"]["tx"], maxSupportedTransactionVersion=0)
memo_data = extract_memo(sol)  # the Memo program instruction's data bytes
assert memo_data.decode("utf-8") == expected

If these three checks pass, the merkle root commitment is non-repudiable regardless of what anchor-x402 does next.

6. Known limitations (explicit)

This is the deliberate, documented gap between anchor-x402 and an institutional-tier product. None of these are bugs; all are listed so that procurement can make an informed buy/no-buy decision.

6.1 Comparison: anchor-x402 (commodity tier) vs Counsel/gavel (assurance tier)

The two products share the same on-chain anchor primitive. A Counsel customer’s audit trail and an anchor-x402 consumer’s anchor land on the same Base + Solana, with the same Merkle commitment format. This is intentional: the commodity tier is the open, public-priced primitive; the assurance tier is the wrapper with retention, identity, and process controls institutions need.

7. Disclosure policy

If you discover a vulnerability:

• Email: [email protected] (subject: [anchor-x402 security] <one-line summary>).
• PGP: key on request.
• Response SLA: acknowledgement within 72 hours; status update within 7 days; coordinated disclosure on resolution.
• Scope: the deployed Lambda, the services in this repository, and the published OpenAPI spec. Out of scope: third-party services we depend on (CoinGecko, openchain.xyz, public RPCs, the CDP facilitator, AWS infrastructure) — please report those upstream.
• Safe harbor: good-faith research that does not exfiltrate user data, drain treasury beyond the price of one paid call, or degrade availability is welcome. We will not pursue legal action against researchers acting in good faith.
• No bounty fund yet. Public credit on resolution is offered.

8. Change log