Presign Guard

presign-guard

· Live status ·

A pre-sign risk check for AI agents. Before an agent signs a transaction, approval, or EIP-712 signature, it pays a few cents per call over x402 and gets back a green / orange / red verdict with machine-readable reason codes. Optionally, it also gets a plain-language explanation in Dutch or English.

Watch the 1-minute explainer: presign-guard.fizzl.eu/media/explainer.mp4

New: the token verdict in 45 seconds: presign-guard.fizzl.eu/media/token.mp4

Part of Klaartaal by FIZZL AI.

Use it in a few lines: presign-guard-wallet

For agents on viem, the npm package presign-guard-wallet wraps the wallet so every sendTransaction, writeContract and signTypedData is checked first: green signs, orange stops (or asks), red never signs. Each verdict's signed receipt is verified before the wallet acts.

import { guardWallet } from "presign-guard-wallet";

const wallet = guardWallet(walletClient, { pay, onOrange: "stop" }); // pay = an x402 fetch, $0.01 per check
await wallet.writeContract({ address: token, abi, functionName: "approve", args: [spender, amount] });

npm install presign-guard-wallet viem @x402/fetch @x402/evm · source and options

Endpoints

Payment is x402 v2 with the exact scheme, on every paid route in USDC on Base, Solana, Algorand or Stellar, or in RLUSD on the XRP Ledger (xrpl:0, the same dollar amount, issuer rMxCKbEDwqr76QuheSUMdEGf4B9xJ8m5De; the payer signs an XRPL Payment with the challenge's extra.invoiceId as InvoiceID, see @x402/xrpl, and the server verifies and submits it itself). The 402 carries Bazaar discovery metadata (input example, input and output schema), and the challenge is mirrored into the JSON body for clients that don't read the PAYMENT-REQUIRED header. You are never charged for an error. Invalid requests (400) and upstream outages (503) cancel settlement, and they always return verdict: null, never a guessed verdict.

Credit packs

Agents that call presign-guard often can prepay: one x402 payment of $0.80 for 100 credits or $7.00 for 1000 credits (20% and 30% off), valid for a year. A credit is $0.01 of checks: POST /v1/check, GET /v1/token and GET /v1/screen cost 1, GET /v1/approvals 2, POST /v1/check/explain 3.

# 1. Buy a pack (any x402 client); the answer holds your key
GET /v1/credits/100   ->  { "credit_key": "pgc_…", "credits": 100, "expires_at": "…" }

# 2. Send the key instead of paying; no new payment needed
curl -X POST https://presign-guard.fizzl.eu/v1/check -H 'x-credit-key: pgc_…' -H 'content-type: application/json' -d '{…}'
#    -> the verdict (signed as usual), with headers x-credit-status: paid and x-credits-remaining: 99

# 3. Balance
curl https://presign-guard.fizzl.eu/v1/credits -H 'x-credit-key: pgc_…'

A call that fails (400 or 5xx) gives its credits back. With no key, a malformed or unknown key, or too few credits, the call gets the normal 402 (x-credit-status says why), so a client can always fall back to paying per call. Keep the key secret: anyone who has it can spend the credits, and it cannot be recovered (only a SHA-256 of it is stored). Credits work over HTTP; MCP tools are paid per call.

Packs are only offered when balances persist: set CREDITS_REDIS_URL (a persistent Redis, for example a free Upstash database; Render only). Without it the credit routes don't exist.

Agent skill

skills/presign-check is an Agent Skill that teaches a coding agent (Claude Code, Codex, Cursor and others that read SKILL.md) to check before it signs, buys or sends:

• a token verdict before buying or accepting a token (free quick verdict, or /v1/token);
• /v1/check before every approval, transaction, signature or Solana, XRPL or Algorand transaction, with intent and from;
• /v1/screen before sending to an address;
• /v1/approvals to clean up a wallet.

It follows green / orange / red every time.

npx skills add Fizzl13/presign-guard

In Claude Code, the skill also comes as a plugin together with the MCP server below, from the Fizzl marketplace in the x402 Doctor repository:

/plugin marketplace add Fizzl13/x402-doctor
/plugin install presign-guard@fizzl

The plugin is this repository's skills/ folder. Without an MCP client that pays x402, only the free MCP tools work; the skill pays over HTTP with your own x402 client.

Every Fizzl skill (x402 Doctor, presign-guard, the Agent Wallet and Ichimoku Signal) is listed in Fizzl13/fizzl-skills.

MCP

https://presign-guard.fizzl.eu/mcp is an MCP server (Streamable HTTP, stateless) for Claude, Cursor and agent frameworks, listed in the official MCP registry as io.github.Fizzl13/presign-guard. Directories can read its tools without connecting from the server card at /.well-known/mcp/server-card.json (the same list as tools/list).

Using Claude Code for trading agents? See Pre-trade checks for Claude Code agents: a token check and an Ichimoku trend check before every order, with a ready-made CLAUDE.md rule.

The three check tools also take an XRP Ledger transaction: {"type": "xrpl", "tx": {…unsigned tx JSON…}, "network": "xrpl:0"}, and an Algorand transaction or group: {"type": "algorand", "transaction": "<base64 msgpack>"} or "transactions": [...] (no chainId), with the same rules as POST /v1/check.

The paid tools are paid inside the MCP call with the x402 MCP transport (_meta["x402/payment"]), in USDC on Base, Solana or Algorand or in RLUSD on the XRP Ledger, to the same payout wallets as the HTTP routes. Invalid input is refused before payment, and a failed check is not charged.

On Hugging Face, the Space x402Fizzl/presign-guard (hf-mcp/, published by hf-mcp-space.yml) is a Gradio app that is also an MCP server (https://x402fizzl-presign-guard.hf.space/gradio_api/mcp/, or added under Hugging Face's MCP settings), with three free tools: screen_address (an OFAC screen against the open list of GET /v1/sanctions, matched in the Space and so unlimited), token_quick_verdict and presign_quick_check. The last two share the free limit above, with the whole Space as one caller. It never pays or holds a key. Publishing needs the repository secret HF_TOKEN (a write token of a Hugging Face PRO account; Gradio Spaces need PRO); the variable HF_MCP_SPACE overrides the name.

Token verdict

GET /v1/token?chain=solana&address=<mint> (or chain=base|ethereum|arbitrum|optimism|polygon|bsc with a 0x token contract) answers one question before an agent buys, holds or accepts a token: is the token itself a trap?

XRP Ledger: chain=xrpl&address=CURRENCY.rIssuer (e.g. RLUSD.rMxCKbEDwqr76QuheSUMdEGf4B9xJ8m5De; names longer than 3 characters may be given as text or as the ledger's 40-hex code). Read from the issuer account on the ledger and DexScreener's XRPL market: red TOKEN_FROZEN (global freeze), TOKEN_ISSUER_NOT_FOUND, TOKEN_IMPERSONATION (called RLUSD but not Ripple's); orange CLAWBACK_ENABLED, PERMISSIONED_TOKEN (RequireAuth), MINT_AUTHORITY_ACTIVE (the issuer isn't blackholed, so it can issue more), TRANSFER_FEE / HIGH_TRANSFER_FEE, plus the market rules (LOW_LIQUIDITY, NO_DEX_MARKET, NEW_TOKEN); info ISSUER_BLACKHOLED (master key off, no usable regular key and no signer list: fixed supply and settings), FREEZE_AUTHORITY_ACTIVE (no NoFreeze flag). Ripple's own RLUSD keeps clawback, freeze and minting on purpose: info, with ISSUER_IS_RIPPLE.

Algorand: chain=algorand&address=<asset id> (e.g. 31566704 for USDC). Read from the asset's parameters on a public node (AlgoNode; ALGORAND_INDEXER_URL overrides its indexer), the indexer (age, holders) and DexScreener's Algorand market: red TOKEN_IMPERSONATION (called USDC, USDt or USD but not Circle's 31566704 or Tether's 312769), TOKEN_NOT_FOUND; orange CLAWBACK_ENABLED (the clawback address can take tokens out of any account), PERMISSIONED_TOKEN (holdings frozen by default), TOKEN_IMPERSONATION for an asset named ALGO, NEW_TOKEN (created less than a day ago), TOP_HOLDERS_CONCENTRATED (of the circulating supply: the reserve and the DEX pool are left out; app and vault accounts can't be told apart from wallets yet), LOW_LIQUIDITY, NO_DEX_MARKET; info FREEZE_AUTHORITY_ACTIVE, ISSUER_RENOUNCED (no manager, freeze or clawback address left), KNOWN_STABLECOIN (Circle's USDC and Tether's USDt keep clawback and freeze on purpose), INDEXER_UNAVAILABLE. An asset's supply is fixed when it is created, so there is no minting on Algorand.

{
  "verdict": "orange",
  "grade": "RISKY",
  "one_liner": "RISKY: 1% transfer fee; $21k liquidity; 1 h old (+2 more)",
  "reasons": [{ "code": "TRANSFER_FEE", "severity": "orange", "details": { "feePct": 1 } }, "…"],
  "token": { "chain": "solana", "address": "…", "name": "…", "symbol": "…" },
  "market": { "priceUsd": 0.0004, "liquidityUsd": 21000, "marketCapUsd": 400000, "volume24hUsd": 90000, "firstPairAt": "…", "ageSeconds": 3600, "url": "https://dexscreener.com/…" },
  "sources": ["goplus", "dexscreener", "rugcheck"],
  "checkedAt": "…"
}

Grades: SAFE (green), CAUTION (one orange reason), RISKY (two or more), AVOID (red). The one-liner states facts only.

A permissioned Solana token (Token ACL, sRFC 37, which Metaplex MPL-3643 builds on) is a Token-2022 mint whose new token accounts start frozen and whose freeze authority is a Token ACL MintConfig PDA; an issuer-chosen gate program decides which wallets are thawed. When GoPlus reports a freeze authority, the verdict reads the mint and its MintConfig from a Solana RPC (SOLANA_RPC_URL, default the public mainnet endpoint) and reports one PERMISSIONED_TOKEN reason instead of FREEZE_AUTHORITY_ACTIVE: only approved wallets can hold or send it, so a buyer who isn't approved may not be able to sell. The response then carries a permissioned block (gate program, config authority, default-frozen, permanent delegate, pausable). A permanent delegate stays a separate BALANCE_MUTABLE.

When the top holders of a Solana token look concentrated, the verdict first asks the chain who owns them: a Metaplex Genesis launch bucket (an account of program GNS1S5J5AspKXgpjz6SvKL66kPaKWAhaGRhCqPRxii2B, holding supply until the launch distributes it) is not a whale. It is left out of the count and reported as GENESIS_LAUNCH_ESCROW with its share.

For a proxy token (USDC, cbBTC, EURC on Base) GoPlus reports no pause or blacklist fields, so the verdict asks the token itself with eth_call on the standard getters (paused, pauser, PAUSER_ROLE, blacklister, isBlacklisted, isBlackListed); those reasons carry source: "onchain" and the role address, and sources includes chain. If the chain RPC is down they are left out and the verdict still answers.

On a token on the GoPlus trust list (USDC, USDT), the issuer's powers (mint, freeze, change balances) are info: the issuer keeps them on purpose. Missing data never makes a token red. If GoPlus or DexScreener is down there is no verdict (503, not charged); if RugCheck is down the verdict comes without it and says so.

Wallet approval audit

GET /v1/approvals?chain=base&address=<wallet> (or chain=ethereum|arbitrum|optimism|polygon|bsc, or solana, below) is the follow-up to /v1/check: that one asks "should I sign this approval?", this one asks "which approvals did I already give, and which should I revoke?". Agents with their own wallet can run it as a periodic check.

{
  "verdict": "red",
  "grade": "AVOID",
  "one_liner": "AVOID: 5 approvals, 1 to a flagged address, 1 to a plain wallet, 1 unlimited; revoke 3",
  "reasons": [{ "code": "SPENDER_MALICIOUS", "severity": "red", "details": { "count": 1, "spenders": ["0x…"] } }, "…"],
  "summary": { "approvals": 5, "tokens": 2, "unlimited": 2, "toRevoke": 3 },
  "approvals": [{
    "token": { "address": "0x…", "symbol": "USDC" },
    "spender": { "address": "0x…", "name": null, "trusted": false, "contract": true },
    "amount": "500", "unlimited": false, "approvedAt": "…", "severity": "red",
    "codes": [{ "code": "SPENDER_MALICIOUS", "severity": "red", "details": { "behaviors": ["phishing_activities"] } }],
    "revoke": true
  }, "…"],
  "revokeUrl": "https://revoke.cash/address/0x…?chainId=8453"
}

Every approval with an orange or red code has revoke: true. The grades are the same as the token verdict. Source: GoPlus token_approval_security (ERC-20 allowances); NFT approvals are not covered. If GoPlus is down there is no verdict (503, not charged).

On Solana

GET /v1/approvals?chain=solana&address=<wallet> audits the Solana form of an allowance: an SPL token delegation. A signed Approve lets a delegate move up to an amount of one token account's tokens without the owner, which is what Solana drainers ask for. The wallet's token accounts (SPL Token and Token-2022) are read from the Solana RPC; every account with a delegate and an amount left is one approval, in the same shape as above plus tokenAccount (where to revoke it), program and balance.

There is no revoke.cash for Solana: revokeUrl is null and revokeHint says how (an SPL Token Revoke on the listed tokenAccount, signed by the wallet; most wallets have it in the token's settings). If the RPC is down there is no verdict (503, not charged).

Wallet screen

GET /v1/screen?address=<address> answers "may I pay this address, or accept money from it?". One address, any chain: the format tells which (EVM 0x…, Solana, Tron, Bitcoin, XRP Ledger, Algorand, or another currency OFAC lists). For sellers screening who pays them, and for agents checking who they are about to pay.

The address is matched exactly against every digital currency address in the OFAC SDN list, which presign-guard downloads from the US Treasury itself (SDN.XML) and re-checks every 6 hours. That matters beyond EVM: GoPlus answers sanctioned: 0 for OFAC-listed Tron, Solana and XRPL addresses. EVM addresses also get the GoPlus address reports (theft, phishing, laundering, mixers).

{
  "verdict": "red",
  "grade": "AVOID",
  "one_liner": "AVOID: on the OFAC SDN list (BANK MARKAZI JOMHOURI ISLAMI IRAN)",
  "reasons": [{ "code": "SANCTIONED_ADDRESS", "severity": "red", "details": { "list": "OFAC SDN", "matches": ["…"], "published": "2026-10-09" } }],
  "address": { "address": "TNiq9AXBp9EjUqhDhrwrfvAA8U3GUQZH81", "format": "tron" },
  "sanctions": {
    "list": "OFAC SDN", "listed": true, "published": "2026-10-09", "source": "ofac-sdn",
    "matches": [{ "uid": 4632, "name": "BANK MARKAZI JOMHOURI ISLAMI IRAN", "type": "Entity", "programs": ["IRAN", "IFSR", "IRGC", "SDGT"], "currency": "TRX" }]
  },
  "sources": ["ofac-sdn"]
}

It is an exact match on the addresses OFAC publishes, not legal advice: it does not cover unlisted addresses of sanctioned persons or indirect exposure. Without any list (just started and the Treasury site down; PG1 stands in for EVM addresses) there is no verdict (503, not charged). /health shows the list's size and date under ofac.

Request types

// Token approval
{ "type": "approval", "chainId": 8453, "token": "0x…", "spender": "0x…", "amount": "1000000" }

// Raw transaction (approve / increaseAllowance / setApprovalForAll are decoded)
{ "type": "transaction", "chainId": 8453, "to": "0x…", "data": "0x…", "value": "0", "from": "0x…" }

// EIP-712 signature: pass the eth_signTypedData_v4 payload as an object or JSON string
{ "type": "signature", "chainId": 8453, "typedData": { "domain": {…}, "types": {…}, "primaryType": "PermitSingle", "message": {…} } }

Supported chains: 1, 10, 56, 137, 8453, 42161.

Plain messages (personal_sign, eth_sign)

// The text or 0x-hex about to be signed; method defaults to personal_sign, chainId and from are optional
{ "type": "message", "method": "personal_sign", "message": "app.example wants you to sign in with your Ethereum account:\n0x…", "origin": "https://app.example", "from": "0x…" }

A message moves no tokens by itself, but two kinds are traps. Red: ETH_SIGN (eth_sign signs a raw 32-byte hash, so nobody can see what is agreed to; it can be a transaction or permit in disguise), SIGN_IN_DOMAIN_MISMATCH (a Sign-In with Ethereum message, EIP-4361, for another site than the origin asking: a phishing site relaying a real site's login). Orange: UNREADABLE_MESSAGE (the bytes aren't readable text; details.looksLike: "a 32-byte hash" when it is exactly 32 bytes), SIGN_IN_URI_MISMATCH (the message's URI is on another site than its domain), SIGN_IN_ADDRESS_MISMATCH (it signs in another account than from), SIGN_IN_CHAIN_MISMATCH (its Chain ID differs from chainId). Info: SIGN_IN_REQUEST (the site, account, URI and expiry of a sign-in message), PLAIN_MESSAGE. The origin gets the same phishing-list and domain-age checks as any request, and intent works too. The answer's subject carries kind: "message", the method and the first 200 characters of the text (preview).

EIP-7702 authorizations

// The authorization about to be signed: the contract the wallet would delegate to; authorizationChainId (0 = every chain), nonce and from are optional
{ "type": "authorization", "chainId": 8453, "address": "0x…", "authorizationChainId": 8453, "nonce": "0", "from": "0x…", "origin": "https://app.example" }

An EIP-7702 authorization makes the wallet run the code at address: from then on that contract can move everything the wallet holds. Drainers ask for exactly this ("sweeper" contracts that empty every wallet delegated to them), so any delegation is orange EIP7702_AUTHORIZATION (ask the user; sign only for a smart-account implementation they chose), and info only when the contract is on GoPlus's trust list. Red: AUTHORIZATION_TO_NO_CONTRACT (no code at that address yet: whoever deploys there later, for example through CREATE2, controls the wallet), AUTHORIZATION_TO_UNVERIFIED_CONTRACT, AUTHORIZATION_TO_FLAGGED_CONTRACT (GoPlus address flags, malicious behaviour or the doubt list; details.flags), AUTHORIZATION_TO_DELEGATED_WALLET (the address is itself a delegated wallet, not a contract), SANCTIONED_ADDRESS. Orange: AUTHORIZATION_ALL_CHAINS (authorizationChainId: 0, valid on every chain), RECENTLY_DEPLOYED, DELEGATE_CODE_UNKNOWN (the chain RPC couldn't be asked). Info: REVOKES_DELEGATION (address 0x0…0 clears a delegation: green), ON_TRUST_LIST, CURRENT_DELEGATION (with from: the contract the wallet delegates to now, unchanged: true when it is the same), SANCTIONS_SCREENED. origin and intent work as for any request. What a verified contract's code does is not audited. A counterparty that already is a delegated wallet is handled in the other request types (EIP7702_DELEGATED_WALLET, MALICIOUS_DELEGATE, UNVERIFIED_DELEGATE).

Solana transactions

// The base64 wire transaction about to be signed (legacy or v0); from is optional (default: the fee payer)
{ "type": "solana", "transaction": "AQAAAAAA…", "origin": "https://…" }

Solana has no allowances like EVM: drainers go after the account itself. The instructions are decoded and the transaction is simulated on the RPC (simulateTransaction, signatures not checked, SOLANA_RPC_URL overrides the public endpoint) to see what really happens to the wallet, also inside other programs. Red: SOLANA_TOKEN_ACCOUNT_TAKEOVER (SetAuthority gives the owner or close authority of the wallet's token account to someone else: the account and everything in it is theirs), SOLANA_ACCOUNT_ASSIGN (System Assign hands the wallet to a program). Orange: SOLANA_UNLIMITED_DELEGATE (Approve with an unlimited amount), SOLANA_DURABLE_NONCE (once signed it never expires), SOLANA_CLOSE_TO_OTHER (a token account closed with its SOL sent elsewhere), SOLANA_SET_AUTHORITY (another authority change), HIDDEN_APPROVAL (a delegate set that no instruction shows), SIMULATION_FAILS. Info: SOLANA_TOKEN_DELEGATE (a limited delegate), SIMULATED (the wallet's SOL and token changes), SOLANA_LOOKUP_TABLES, SIMULATION_UNAVAILABLE. A takeover or assign seen only in the simulation is red too (details.hidden: true). The answer carries simulation: { ok, changes, fee }; origin and intent work as for EVM.

Transactions built for the agent, sent in order. Services that build unsigned transactions for agents often split setup from action. Project 0's P0 MCP, for example, returns a first deposit as two v0 transactions with submit: "sequential": one creates the account, the next deposits. Check each one just before signing it, after the one before has landed:

// P0 builds, presign-guard checks, the agent's wallet signs: one transaction at a time.
for (const { base64 } of p0.transactions) {
  const res = await pay("https://presign-guard.fizzl.eu/v1/check", { // pay = an x402 fetch; $0.01 per check, USDC on Solana works
    method: "POST", headers: { "content-type": "application/json" },
    body: JSON.stringify({ type: "solana", transaction: base64, intent: "deposit 1 USDC into Project 0" }),
  });
  const { verdict, reasons } = await res.json();
  if (verdict !== "green") throw new Error(`not signing: ${reasons.map((r) => r.code).join(", ")}`);
  await signSendAndConfirm(base64); // your wallet: sign, send, wait until it has landed
}

The deposit checked before the account exists fails in the simulation: still orange SIMULATION_FAILS, now with details.missingAccounts (accounts it writes to that don't exist yet and that it doesn't create itself) and a note to check it again after the earlier transaction has landed. Checked after, it comes back green with exactly what leaves the wallet (1 USDC plus the fee). With submit: "bundle" (all signed with one blockhash and sent together as a Jito bundle) there is no landing in between: each transaction is still decoded, but a later one's simulation can fail only because the earlier ones haven't run yet (look for missingAccounts).

XRP Ledger transactions

// An unsigned XRPL transaction (no chainId; network defaults to "xrpl:0", mainnet)
{ "type": "xrpl", "network": "xrpl:0", "tx": { "TransactionType": "Payment", "Account": "r…", "Destination": "r…", "Amount": "15000" } }

There are no token approvals on the XRPL: what drains accounts there is handing the account over. Red: XRPL_REGULAR_KEY_CHANGE (SetRegularKey to another key), XRPL_SIGNER_LIST_CHANGE (SignerListSet with other signers), XRPL_DISABLE_MASTER_KEY (AccountSet asfDisableMaster), XRPL_ACCOUNT_DELETE (all remaining XRP goes to the destination), XRPL_FAKE_RLUSD (a token called RLUSD that isn't issued by Ripple: a trust-line currency code, or an MPT whose metadata ticker is RLUSD), XRPL_DELEGATE_FUNDS (a DelegateSet, XLS-75, that lets another account sign Payment, CheckCreate, EscrowCreate, PaymentChannelCreate/Fund, OfferCreate, NFT offers, AMM deposits, bridge commits, PaymentMint or PaymentBurn for you: it can send your funds to itself; details.movesFunds), PHISHING_SITE. Orange: XRPL_PARTIAL_PAYMENT, XRPL_DESTINATION_TAG_MISSING (the destination, often an exchange, requires a tag), XRPL_DESTINATION_REFUSES (Deposit Authorization), XRPL_DESTINATION_NOT_ACTIVATED, XRPL_DESTINATION_NO_TRUSTLINE, XRPL_DESTINATION_DISALLOWS_XRP, XRPL_ISSUER_CAN_CLAW_BACK / XRPL_ISSUER_FROZEN / XRPL_TRANSFER_FEE / XRPL_ISSUER_NOT_FOUND (on a TrustSet; Ripple's own RLUSD has clawback by design, which is info), XRPL_ENABLE_CLAWBACK, XRPL_ENABLE_DEPOSIT_AUTH, XRPL_SIGNER_LIST_REMOVED, XRPL_ESCROW_TO_OTHER, XRPL_CHECK_TO_OTHER (the destination can cash up to SendMax), XRPL_CHANNEL_TO_OTHER (a payment channel created or funded for another destination; it claims with claims signed by the channel's PublicKey), XRPL_CHANNEL_NOT_FOUND, XRPL_NFT_GIVEAWAY (an NFT sell offer for nothing), XRPL_OFFER_FAR_BELOW_MARKET (a DEX order whose limit is more than 5% worse than the best rate the order book or AMM pool gives now: on a thin book it can fill down to that price; details.yourRate, marketRate, worseByPct, source), XRPL_NO_MARKET (no book or pool for the pair), the issuer checks above for the token an order buys and for AMM deposits and new pools, XRPL_CREDENTIAL_ISSUE (CredentialCreate for another account: you vouch for it, and services or permissioned domains that accept your credentials let it in), XRPL_CREDENTIAL_NOT_FOUND / XRPL_CREDENTIAL_EXPIRED / XRPL_CREDENTIAL_ALREADY_ACCEPTED (a CredentialAccept that would fail; a valid one is info XRPL_CREDENTIAL_ACCEPT, with the type and expiry), XRPL_DELEGATE_SET (a DelegateSet giving another account permissions that don't move funds, such as TrustlineAuthorize or AccountDomainSet; details.permissions), XRPL_DELEGATE_NOT_FOUND (the delegate account doesn't exist, so it fails), XRPL_BATCH_NOT_ATOMIC (a Batch with transactions of several accounts whose mode isn't tfAllOrNothing: your part can go through while the other account's part fails), XRPL_TX_NOT_ANALYZED (a transaction type this check doesn't judge), LOOKALIKE_SITE, NEW_DOMAIN, DOMAIN_NOT_REGISTERED. Info: XRPL_NEW_DESTINATION, XRPL_REGULAR_KEY_REMOVED, XRPL_DELEGATE_REMOVED (an empty Permissions list), XRPL_BATCH (the mode and inner transaction types), XRPL_LEDGER_UNAVAILABLE. A Batch (XLS-56) is judged by every transaction in RawTransactions, with the same rules as when signed on its own: their reasons carry details.inner (the place in the list) and details.account when another account sends it. It must hold 2 to 8 transactions and set exactly one mode flag, as the ledger requires. MPTs (XLS-33): opting in to hold one (MPTokenAuthorize) gets the issuer checks above from its issuance (clawback, locked, transfer fee), and XRPL_MPT_NOT_FOUND when there is no such issuance; a payment in an MPT that would fail is XRPL_MPT_LOCKED (the issuance or the destination's balance), XRPL_MPT_NOT_TRANSFERABLE (the issuer only allows transfers to and from itself), XRPL_DESTINATION_NO_MPTOKEN (the destination hasn't opted in) or XRPL_DESTINATION_NOT_AUTHORIZED (the issuer requires authorisation and hasn't given it); the issuer, read from the issuance ID, is screened like any party. Vaults (XLS-65) and lending (XLS-66), ready for when the SingleAssetVault and LendingProtocol amendments go live: a VaultDeposit is orange with XRPL_VAULT_LENDS when the vault lends deposits out (it has a loan broker or assets out on loan; loans are unsecured and the vault owner picks the borrowers; details.lentOutPct, firstLossCoverPct), XRPL_VAULT_LOCKUP for a closed-ended vault (a fixed-term fund: no withdrawals between its subscription end and redemption date), XRPL_VAULT_PAPER_LOSS when the vault carries an unrealized loss (deposits are priced at the full value, withdrawals at the value minus the loss; info on a withdrawal), and gets the issuer checks for the vault's token (no transfer fee: vaults don't charge one). XRPL_WITHDRAW_TO_OTHER: a VaultWithdraw or LoanBrokerCoverWithdraw whose Destination is another account. A LoanSet always carries info XRPL_LOAN_TERMS (borrower and lender, what the borrower receives after the origination fee, the payments, the total repaid, the interest and effective yearly rate, late terms, grace period); XRPL_LOAN_COSTLY (orange) when interest and fees together cost the borrower more than 36% a year. LoanPay carries info XRPL_LOAN_PAYMENT (the amount due and next due date). Orange because the transaction would fail: XRPL_VAULT_NOT_FOUND, XRPL_VAULT_WRONG_ASSET, XRPL_VAULT_CLOSED (a fund past its subscription), XRPL_VAULT_LOCKED (a withdrawal during the fund's term), XRPL_VAULT_ILLIQUID (more than the vault has available), XRPL_VAULT_FULL, XRPL_LOAN_BROKER_NOT_FOUND, XRPL_LOAN_NOT_THE_BROKER, XRPL_LOAN_NO_BORROWER, XRPL_BORROWER_NOT_FOUND, XRPL_LOAN_OUTSIDE_TERM (a fund lends only during its term, and the last payment must fall before redemption), XRPL_LOAN_NOT_FOUND, XRPL_LOAN_NOT_YOURS, XRPL_LOAN_PAID_OFF, XRPL_LOAN_PAYMENT_LATE (past due without tfLoanLatePayment). Info XRPL_VAULT_PRIVATE: only members of the vault's permissioned domain can deposit. The vault owner, lender and borrower are screened like any party. The owner's own vault and broker transactions (VaultCreate, VaultSet, LoanBrokerSet, LoanBrokerCoverDeposit, LoanManage, …) and the issuer's clawbacks are green. The ledger is read through public JSON-RPC (xrplcluster.com; testnet.xrpl-labs.com), cached for 5 minutes. Same price and route as the EVM check.

Algorand transactions

// One base64 msgpack transaction (algosdk.encodeUnsignedTransaction, or a signed one), or a whole atomic group;
// no chainId: the network (mainnet or testnet) comes from the transaction's genesis hash
{ "type": "algorand", "transaction": "iqNhbXTOAA9CQKNmZWXN…" }
{ "type": "algorand", "transactions": ["iqNhbXTO…", "iqRhcGlk…"], "from": "ABC…" }

Algorand has no token approvals either: one field on an ordinary-looking transaction gives the account away. Every transaction the wallet sends (from, or the first transaction's sender) is judged by its fields; transactions from other accounts in the group are theirs to sign. Red: ALGORAND_REKEY (rekeyTo hands the account's signing power to another key), ALGORAND_CLOSE_ACCOUNT (closeRemainderTo sends all remaining ALGO to someone and closes the account), ALGORAND_ASSET_CLOSE (an asset transfer's closeRemainderTo sends the whole balance of that asset to someone else), ALGORAND_FAKE_STABLECOIN (an asset called USDC or USDt that isn't Circle's 31566704 or Tether's 312769). Orange: ALGORAND_CLAWBACK_TRANSFER, ALGORAND_ASSET_CLAWBACK / ALGORAND_ASSET_DEFAULT_FROZEN (opting in to such an asset), ALGORAND_APP_UPDATE_OR_DELETE, ALGORAND_APP_CLEAR_STATE, ALGORAND_ASSET_CONTROL_CHANGE / ALGORAND_ASSET_CONTROL_CLEARED / ALGORAND_ASSET_DESTROY, ALGORAND_KEYREG_NONPARTICIPATION, ALGORAND_HIGH_FEE (over 0.1 ALGO), ALGORAND_FAKE_ALGO, ALGORAND_GROUP_UNSEEN (one transaction of a group: the rest runs with it unchecked), ALGORAND_GROUP_MISMATCH, ALGORAND_TX_NOT_ANALYZED, SIMULATION_FAILS. The group is simulated on a public node (algod simulate, empty signatures allowed; ALGORAND_ALGOD_URL / ALGORAND_TESTNET_ALGOD_URL override AlgoNode), which also tells how much a close would send (details.closingAlgo, details.closingAmount). subject.transactions lists what each transaction does. origin and intent work as for the other types.

Optional on every EVM type: "intent": "swap 10 USDC for ETH on Uniswap", what the agent says it is doing, in one sentence (up to 500 characters). TypeSafe's Jev compares it with what signing actually does (the decoded action, who gets an allowance, a payment or tokens, how much, unlimited or not): signing that does more than, or something else than, the intent is orange (INTENT_MISMATCH, details.intent, details.probability, details.decidedBy jev or jev+claude); a clear match is info (INTENT_MATCHES). This catches a prompt-injected agent about to sign something its user never asked for, such as an unlimited approval while it says it is paying for an API. Only when the server has TypeSafe set up; never red, never makes a verdict green.

Optional on every type: "origin": "https://…", the site asking for the signature or transaction (a URL or a hostname). Its domain age is looked up: a domain registered less than 30 days ago is orange (NEW_DOMAIN), which catches the fresh phishing sites wallet drainers run on. It is also checked against phishing lists and lookalikes: on MetaMask's eth-phishing-detect blocklist (via PG1) or GoPlus's phishing list is red (PHISHING_SITE, details.flaggedBy names the lists); a lookalike of a known brand (PG1's typosquat detection, e.g. metamask-login.com → metamask.io) is orange (LOOKALIKE_SITE); with METAMASK_SCAN=on (off by default: MetaMask's site-scanner endpoint has no published API or licence), a site MetaMask's own site scanner (Blockaid) blocks is orange (WALLET_BLOCKS_SITE), not red, because that scanner also blocks legitimate browser-payment pages. A source that can't be reached is SITE_REPUTATION_UNAVAILABLE (info), never a clean result. ORIGIN_REPUTATION=off turns these checks off. Local and IP origins are not looked up.

Recognised signatures: EIP-2612 Permit, DAI-style permit, Permit2 (PermitSingle, PermitBatch, PermitTransferFrom, batch and witness variants), EIP-3009 TransferWithAuthorization / ReceiveWithAuthorization (what x402 asks an agent to sign to pay), and Seaport OrderComponents.

An x402 payment moves one fixed amount to one recipient and grants no allowance, so paying a plain wallet is green (PAYMENT_AUTHORIZATION, info). It turns red if the recipient is flagged, and orange if the amount is effectively unlimited or the authorization stays valid for more than a month. Anything else comes back at least orange (UNRECOGNIZED_SIGNATURE).

Transaction simulation. Send a transaction with from (the wallet that would send it) and presign-guard runs it against the latest block (eth_simulateV1 with traceTransfers, on all six chains: 1, 10, 56, 137, 8453 and 42161) to see what it really does, also inside routers, multicalls and EIP-7702 batches. The answer then carries simulation: { ok, changes: [{ type: "transfer"|"approve", asset: "native"|"erc20"|"erc721"|"erc1155"|"nft_all", token, symbol, from, to, amount, rawAmount, tokenId }], gasUsed, source: "alchemy"|"rpc" }, and an info line SIMULATED with what leaves and what arrives. Orange: HIDDEN_APPROVAL (the transaction sets an approval, or an approval for all NFTs of a collection, that the decoded call doesn't show), SIMULATION_NFT_OUT (an NFT leaves the wallet), SIMULATION_FAILS (it would revert; details.error). With intent, the intent check compares it with the simulated balance changes, so "swap 10 USDC" while 5,000 USDC leaves is caught. Runs on Alchemy when the server has ALCHEMY_API_KEY, otherwise (or when Alchemy fails) on the chain's public RPC (RPC_URL_<chainId> overrides); SIMULATION=off turns it off. When no RPC answers, the check goes on without it (never a guessed green). GET /health shows a startup self-test per chain under simulation.

Address poisoning. With from, the recipients of a transfer (what the simulation sees leave the wallet, else the decoded transfer) are compared with the addresses this wallet has sent ETH or tokens to before (its latest 1,000 transfers, via Alchemy's alchemy_getAssetTransfers). A new recipient that starts and ends like one of them (at least 3 characters each side, 7 together) is red ADDRESS_POISONING with details.lookalikeOf: the classic trick of planting a look-alike address in the wallet's history so it gets copied. Info: KNOWN_RECIPIENT (paid before), NEW_RECIPIENT (never paid, no look-alike). Needs ALCHEMY_API_KEY; without it, or when Alchemy doesn't answer, the check is skipped (ADDRESS_HISTORY=off turns it off). GET /health shows its self-test under addressHistory.

x402 requirements check. Paying a 402 challenge? Send the entry of its accepts list you are paying as x402 (either { "accepted": { … } } or the entry itself, x402 v2 amount or v1 maxAmountRequired, CAIP-2 eip155:8453 or v1 base) next to the EIP-3009 payment. presign-guard checks that the signature pays exactly what the seller asked, read from the typed data, never from a claim. Red: X402_AMOUNT_ABOVE_REQUIRED (it pays more than asked; details.required, details.signing), X402_RECIPIENT_MISMATCH (another payTo), X402_ASSET_MISMATCH (another token), X402_NETWORK_MISMATCH (another chain). Orange: X402_VALIDITY_TOO_LONG (the authorization stays valid well past the seller's maxTimeoutSeconds, at least an hour; anyone holding it can settle it until then, like a bearer token), X402_DOMAIN_MISMATCH (the seller's extra.name/version differ from the signature's EIP-712 domain), X402_SCHEME_UNEXPECTED, X402_NETWORK_UNKNOWN. Info: X402_REQUIREMENTS_MATCH, or X402_AMOUNT_BELOW_REQUIRED (the seller will refuse it). Why: research on x402 in 2026 (Hardening x402, Five Attacks on x402, a study of 15 facilitators) shows a hostile server or a broken client library can inflate the price, swap the recipient or token, or ask for a long-lived authorization.

Mandate check (x402 authority extension, draft). An agent that pays under a spending mandate from its principal (x402-mandate/1: "spend up to CAP, to recipients in R, until T", Ed25519-signed) can send it along with the EIP-3009 payment as mandate: { mandate, alg: "Ed25519", sig, paymentId }. presign-guard checks the payment about to be signed against the grant, offline: the issuer's signature, payer = subject, token = asset, recipient in recipients (or "*", orange MANDATE_ANY_RECIPIENT), amount within perPayment and cap, not past notAfter, and the authorization's nonce equal to the binding of (mandate, paymentId) (§7), so the settled payment proves which grant it used. Outside the mandate is red (MANDATE_INVALID, MANDATE_BAD_SIGNATURE, MANDATE_WRONG_PAYER, MANDATE_WRONG_ASSET, MANDATE_RECIPIENT_OUT_OF_SCOPE, MANDATE_OVER_LIMIT, MANDATE_EXPIRED, MANDATE_BINDING_MISMATCH with details.expectedNonce); inside it adds MANDATE_OK (info) and the answer carries mandate: { ok, digest }. Payer, recipient and asset may be written as a bare 0x address, a CAIP-10 account (eip155:8453:0x…) or a CAIP-19 asset (eip155:8453/erc20:0x…). Only the single-payment checks (§6, §7): cumulative spend against the cap needs the accountant's spend log and is not checked. The wire values match the draft's conformance vectors byte for byte (test/mandate.test.mjs).

Response

{
  "version": "2",
  "verdict": "red",
  "reasons": [
    { "code": "UNLIMITED_APPROVAL", "severity": "orange", "subject": "0x…", "details": { "token": "0x…" } },
    { "code": "SIGNATURE_GRANT_TO_EOA", "severity": "red", "subject": "0x…" }
  ],
  "subject": { "chainId": 8453, "kind": "permit2_allowance", "offchain": true, "grants": [ … ] },
  "scope": "…",
  "sources": ["goplus"],
  "checkedAt": "2026-09-23T12:00:00.000Z"
}

Every token that is approved, permitted or paid is also checked with GoPlus token security (honeypot, impersonation, owner powers, taxes). Each grant in subject.grants carries tokenSymbol and tokenName when GoPlus knows the token. The verdict is the most severe reason: any red makes it red, otherwise any orange makes it orange. info reasons never change the verdict.

Reason codes

Signed verdicts

Every paid answer (HTTP and MCP) carries a receipt signed by presign-guard, so you can later prove which verdict was delivered for which request, not only that you paid:

"receipt": {
  "request_id": "5f0c…",
  "route": "POST /v1/check",
  "input_sha256": "9a1e…",
  "payment": { "network": "eip155:8453", "asset": "0x8335…", "amount": "10000", "pay_to": "0x6B0F…", "payer": "0x0fD3…", "nonce": "0x5c1d…", "proof": "eip3009" },
  "signed_at": "2026-09-27T09:30:00.000Z",
  "signer": "0x…",
  "algorithm": "eip191-canonical-json-v1",
  "signature": "0x…"
}

• What is signed: the whole response with receipt.signature left out, as canonical JSON (profile js-json-stringify-sorted-utf16-ascii-v1: keys sorted by UTF-16 code units at every level, no whitespace, every code unit from U+007F up escaped as lowercase \uXXXX, numbers spelled as JavaScript's JSON.stringify writes them — 1.0 → 1, 0.000001 → 0.000001, 1e21 → 1e+21 — then UTF-8 bytes). Python's json.dumps matches only for ASCII keys and integers (it writes 1.0 and 1e-06); use examples/canonical.py, with EIP-191 personal_sign. Flipping the verdict, or moving it to another request id, breaks the signature.
• input_sha256 is the SHA-256 of the canonical JSON of {"route": …, "input": …}, where input is your JSON body (POST), your query parameters as strings (GET), or the tool arguments (MCP, route mcp <tool>). Recompute it to prove the verdict answers your request.
• payment ties the verdict to the payment that bought it, from your x402 payment payload. On Base: the payer and the EIP-3009 nonce, so anyone can find the settlement on-chain as the USDC contract's AuthorizationUsed(payer, nonce) event without trusting us. On Solana: the payer and a SHA-256 of the signed transaction you sent (the facilitator adds its fee-payer signature at settlement, so the final transaction id is not known when we sign).
• Signer addresses: /.well-known/presign-guard-signer.json. Retired signers stay listed with their dates, so old receipts keep verifying.
• Check one for free: POST /v1/verify with {"response": <the signed answer>, "route": "POST /v1/check", "input": <what you sent>} returns valid, signer, known_signer and input_matches.

Verify it yourself (Node, viem):

import { recoverMessageAddress } from "viem";
const { signature, ...rest } = answer.receipt;
const signer = await recoverMessageAddress({ message: canonicalJson({ ...answer, receipt: rest }), signature });
// signer must equal answer.receipt.signer and be listed in /.well-known/presign-guard-signer.json

Python (eth-account), with examples/canonical.py (not json.dumps, which spells numbers differently):

from canonical import verify_receipt
assert verify_receipt(answer) == answer["receipt"]["signer"]
# and the signer must be listed in /.well-known/presign-guard-signer.json (or certified by the payout wallet)

Key rotation without client updates: the payout wallet (0x6B0F4651eD42893ab58139938175E4a69f175F25, the payTo of every payment) authorises each signing key with a certificate: a personal_sign over

fizzl receipt signer
service: presign-guard
signer: <signing key address>
valid_from: <YYYY-MM-DD>

Set it as RECEIPT_SIGNER_CERT (YYYY-MM-DD:0x<signature>; the page /sign-receipt-key produces it from the wallet's browser; /sign-receipt-key?service=x402-doctor does the same for x402 Doctor, so the payout wallet signs on one site only). It is checked at startup and carried inside every receipt as receipt.cert, so a client that pins only the payout wallet verifies receipts from a new key offline. To rotate: generate a new RECEIPT_SIGNER_SECRET, sign a new certificate, move the old address to RECEIPT_RETIRED_SIGNERS.

The signing key comes from RECEIPT_SIGNER_SECRET (any long random string; it holds no funds and signs nothing but receipts). Without it, answers are unsigned.

Not covered

The simulation of signatures (only transactions are simulated), and what a site does with a signed plain message. Treat a green verdict as "no known risk signals", not as a guarantee.

Payment security (Five Attacks on x402)

Five Attacks on x402 (Li, Wang and Wang, 2026) describes five ways an x402 payment can go wrong between the HTTP request and the chain, and maps each to a mitigation. How this service handles them:

Feedback

Found a bug, or missing something? Send it with POST /feedback (free, no payment) or the MCP tool feedback:

curl -X POST https://presign-guard.fizzl.eu/feedback \
  -H 'content-type: application/json' \
  -d '{"type": "feature", "message": "Support Arbitrum in /v1/token", "endpoint": "/v1/token"}'

type is bug, feature or other; message is required (up to 2000 characters); endpoint and contact are optional. The answer is 202 with an id. At most 10 reports per hour per caller. Reports go to the usage log, and a person reads every one; nothing in a report is run or changed automatically. GET /feedback shows the schema.

Run locally

cp .env.example .env   # fill in PAY_TO and ANTHROPIC_API_KEY
npm install
npm test               # 36 tests, network mocked
npm run dev

End-to-end payment test (Base Sepolia)

Fund a throwaway wallet with Base Sepolia test USDC, set AGENT_PRIVATE_KEY and CHECK_URL in .env, then run:

npm run client

The script makes a valid call, which should return 200 with a settlement receipt, and an invalid call, which should return 400 with no charge.

Deploy to Render

The live service runs on Base mainnet: render.yaml sets X402_NETWORK=eip155:8453, which needs CDP_API_KEY_ID and CDP_API_KEY_SECRET (Coinbase CDP facilitator; the service refuses to start on mainnet without them). After the first paid call settles through CDP, the routes are listed in the CDP Bazaar. To test without real money, set X402_NETWORK=eip155:84532 (Base Sepolia, public x402.org facilitator); without X402_NETWORK the code also defaults to Base Sepolia.

PAY_TO_SOLANA (optional) is a Solana address for USDC payments on Solana, offered on every paid route (the checks, the token verdict and the approvals audit); those payments settle through the PayAI facilitator (SOLANA_FACILITATOR_URL to override). Without it, they are paid on Base (and XRPL / Algorand when set).

ALGORAND_PAY_TO (optional) is an Algorand address for USDC payments on Algorand (ASA 31566704), offered on every paid route and credit pack at the same dollar price; those payments settle through GoPlausible's public facilitator (ALGORAND_FACILITATOR_URL to override), which pays the Algorand fee. The account must have opted in to USDC. Unset or off: no Algorand option.

STELLAR_FACILITATOR_KEY (optional) is an API key for OpenZeppelin's "Built on Stellar" facilitator (generate one at channels.openzeppelin.com/gen); with it every paid route and credit pack also takes USDC on Stellar mainnet (the Stellar Asset Contract, 7 decimals) at the same dollar price, fees paid by the facilitator. STELLAR_FACILITATOR_URL points at another facilitator. STELLAR_PAY_TO is the receiving account, by default Frits's account with the USDC trustline; off: no Stellar option.

BUILDER_CODE (optional) is a Base Builder Code (ERC-8021, minted at base.dev), declared in every paid route's 402 as the builder-code extension: the buyer's x402 client echoes it and the facilitator writes it into the settlement, so Base attributes the payment. Unset or not a valid code: none.

MPP_SECRET (optional, mainnet) turns on MPP payment next to x402 on the paid routes, for agents that speak MPP (mppx): method evm, USDC on Base, settled by the CDP facilitator only after a successful answer. Any long random string; it signs the challenge ids. MPP_TEMPO_RECIPIENT adds MPP method tempo (push mode: the agent sends USDC.e on Tempo with the MPP memo and answers with the transaction hash, checked on a Tempo RPC): the address that receives it on Tempo. MPP_TEMPO_CHAIN=42431 switches to the Moderato testnet, MPP_TEMPO_RPC overrides the RPC.

MPP_TEMPO_OPERATOR_KEY (optional, with MPP_TEMPO_RECIPIENT and CREDITS_REDIS_URL) adds MPP sessions (intent session, mppx): the agent opens a payment channel on Tempo once and pays each call with a signed voucher, no transaction per call. The channel pays out to MPP_TEMPO_RECIPIENT; the key is a separate operator account that only settles and closes channels and pays the gas (a few dollars of USDC.e on Tempo is plenty). Channel state lives in Redis; spend is settled on-chain after $0.50 or 10 minutes.

PAY_TO must be an EVM address (0x + 40 hex characters). Surrounding spaces are trimmed; anything else stops the server at startup with a clear error, so a typo can't publish an unpayable 402.

Data sources

Risk data comes from the GoPlus Security API. Sanctions screening uses the OFAC SDN list straight from the US Treasury, in the wallet screen and in every check: the spender or recipient on EVM, and on Solana, the XRP Ledger and Algorand every party a transaction pays, hands control to or trades with (OFAC_SDN_URL overrides the address, OFAC_SDN=off skips the download; credited as ofac-sdn in sources). Until the list is loaded after a restart, EVM checks screen through PG1, which also gives the domain age (public OFAC and RDAP data, credited as pg1 in sources; set PG1_API_KEY to a PG1 membership key to be exempt from PG1's anonymous rate limit); the token verdict adds RugCheck (Solana) and DexScreener (market data). Transactions sent with from are simulated with the standard eth_simulateV1 call, on Alchemy when ALCHEMY_API_KEY is set (credited as alchemy in sources), else on the public RPC. Plus eth_getCode on a public RPC to recognise EIP-7702 wallets (override with RPC_URL_<chainId>). Explanations come from Claude (Anthropic).

License

Copyright (C) 2026 Frits Zwager. Licensed under the GNU Affero General Public License v3.0 only (AGPL-3.0-only); see LICENSE. If you run a modified version as a network service, you must offer its source code to the users of that service.