SendCheck — EVM address verification (x402)

org.pennyforge.api由 api.pennyforge.org 发布官方发布者v1.0.0更新于 Oct 24, 2026

Pre-send EVM address checks: free pre-check, $0.01 check, $0.05 deep scan. x402: payment is auth.

已验证Streamable HTTP可网页运行金融安全与监控

概览

AI 生成的概览

远程 MCP 服务器,在付款前校验 EVM 地址:免费 EIP-55 校验和检查,以及按 x402 付费的钱包类型、活动与余额核查。

可以做什么
  • 免费校验 EVM 地址的 EIP-55 校验和,发现拼写错误、漏字符和被篡改的大小写。
  • 付费核查单条链上的一个地址:钱包还是合约、转出活动、原生币与 USDC/USDT 余额,并给出分级结论、原因和下一步建议。
  • 付费深度扫描覆盖 Base、Ethereum、Arbitrum、Optimism 和 Polygon 五条链,包含错误网络检测和代币不匹配标记。
  • 分两阶段完成付费:首次调用返回确切的 x402 付款挑战,第二次带付款信息调用才返回结果。
适用场景
适合在助手或代理即将转出 USDC 或其他 EVM 资产时,先确认目标地址格式正确,并以小额费用判断它是否是正确链上可信的收款方。免费检查足以发现拼写错误;金额较大的转账更适合使用付费核查。
运行要求
远程 streamable HTTP 端点;未声明需要账户、API 密钥或环境变量。免费校验无需任何配置。付费核查通过 Base 上的 x402(EIP-3009)以 USDC 计价,每次 0.01 美元和 0.05 美元,因此客户端需要已充值的钱包和 x402 支付支持。需要能访问该服务主机的网络。
安装前请注意
付费工具会真实花钱:单链核查 0.01 美元、深度扫描 0.05 美元,均以 Base 上的 USDC 支付;两阶段流程意味着必须先应答付款挑战才能拿到结果。校验和通过只说明地址格式正确,并不代表收款方正确。结论仅供参考,且来自个人第三方服务,签署转账前应只把它当作一项信号。

安装

在 SourceWeft 中

  1. 打开 控制台中的 SendCheck — EVM address verification (x402),将其添加到工作区。
  2. 为需要使用其工具的对话启用该服务。

Web executable,通过 Streamable HTTP。 远程服务在工作区中配置后即可从网页运行时运行。

交给智能体安装

把这段提示词粘贴到 Claude Code、Codex、Cursor 等智能体,或 SourceWeft 对话中。智能体会读取该服务器的安装指南,先向你展示发布者、端点和登录方式,经你同意后再把它添加到你的客户端。密钥不会写进任何命令。

阅读 https://sourceweft.com/mcp/org.pennyforge.api%2Fsendcheck/install.md,并按其中说明把这个 MCP 服务器接入我的客户端。修改任何配置之前,先告诉我它的发布者、端点和登录方式,等我确认。不要把 API 密钥写进命令或我会提交的文件;问我密钥应从哪里获取。

查看智能体所依据的安装指南

其他 MCP 客户端

把它添加到你客户端的 mcpServers 配置中。

{
  "mcpServers": {
    "sendcheck-evm-address-verification-x402": {
      "type": "http",
      "url": "https://api.pennyforge.org/mcp"
    }
  }
}

README

sendcheck-verify

[Listed on mcpservers.org]

Verify before you pay. A zero-dependency client for the free GET /validate pre-check on the SendCheck x402 API — the 10-line guard that stops your agent from signing a payment to a mistyped, mismatched, or tampered settlement address.

When an x402 client pays a service, it pays the settlement address the service told it about. A single wrong character (a case-flip, a dropped digit, a substituted address) and the USDC goes somewhere else forever. /validate is the free, no-key, no-account pre-check: is this address even a well-formed, correctly-cased EVM address before you put real money on it?

Since v0.2.0 the package does one more thing: it verifies the service's signed service card — an ES256 JWS over the payTo and the per-route maxPrice that the worker re-signs at every deploy — so a client that pinned the public key once can confirm the challenge's payTo cryptographically, before paying. That is the reference implementation of the drift-proof check (the "signed service card" from the address-drift article).

Why this exists

SendCheck's paid endpoints cost $0.01 (one chain) or $0.05 (all five chains) via x402 — USDC on Base, no account, no API key. But most "is this address garbage?" checks don't need chain data: the EIP-55 checksum alone catches the most common, most expensive failures (typos, dropped characters, tampered casing). So /validate is free, and this package makes calling it one line.

The signed service card (v0.2.0)

Pre-payment address checks have a hole: the "expected payTo" a client compares against usually comes from the same discovery doc it just fetched — so a compromised service can point you at its own new address, and for a service that rotates its address often, every remembered address is stale before the check finishes.

SendCheck closes that hole by signing its payment details. The worker signs the settlement address and the per-route max prices with a stable ES256 (EC P-256) key at every deploy, and serves the signed block { jws, key } in three places:

<origin>/.well-known/x402   →  top-level "attestation"<origin>/openapi.json       →  info["x-attestation"]the 402 challenge itself    →  extensions["x-sendcheck-attestation"]

SendCheck signs its payment details with a stable key at every deploy, so any client that has pinned that key once can cryptographically confirm — before paying — that the address in the payment challenge is one we signed; first contact is still trust-on-first-use.

What the signature buys: key continuity for returning, stateful clients — a compromised worker/DNS/CDN cannot silently redirect your payments, and a rotated key is a loud event you can flag. What it does not buy (we under-claim on purpose): first-visit authenticity (that is TOFU), protection for ephemeral agents with no pin, or a price below the signed maxPrice.

The signed payload also carries a per-route maxPrice, so verifyChallenge catches a challenge that quietly raises the price above what the key signed.

The drift-proof wiring

js
import { checkService, verifyChallenge, ATTESTATION_EXTENSION } from "@pennyforgeorg/sendcheck-verify";
const origin = "https://api.pennyforge.org";
// 1) Once: pin the public key (first contact = trust-on-first-use).const first = await checkService(origin);          // { ok, keyId, key: JWK, payTo, … }// persist { kid: first.keyId, x: first.key.x, y: first.key.y } somewhere durable
// 2) Every call: confirm the card still verifies and the key has not rotated.const svc = await checkService(origin, { pinnedKey: storedPin });if (svc.keyChanged) { /* loud: the key rotated — inspect before trusting */ }if (!svc.ok) throw new Error("service card not valid: " + svc.attestation.reason);
// 3) At payment time: bind the 402 CHALLENGE to the signed card.//    (challenge = decoded base64 PAYMENT-REQUIRED header, or the 402 JSON body)const verdict = await verifyChallenge(challenge, svc.block, { origin });if (!verdict.valid) throw new Error("challenge not signed: " + verdict.reason);// …now sign the EIP-3009 payment to challenge.accepts[0].payTo.

verifyChallenge checks the challenge's payTo against the signed one and the challenge price against the signed maxPrice for the challenged route. Failure reasons: signature_invalid, challenge_payto_mismatch, price_exceeded, route_not_signed, expired, iat_future, service_mismatch, kid_mismatch, malformed.

Install

bash
# GitHub npm registry (v0.2.0 published 2026-09-08)npm install @pennyforgeorg/sendcheck-verify --registry https://npm.pkg.github.com

GitHub's npm registry asks for any valid GitHub token even on public reads — put //npm.pkg.github.com/:_authToken=<your GH token> in your .npmrc (classic PAT or fine-grained with Packages:Read works). No token handy? Install from the public repo:

bash
npm install github:pennyforgeorg/sendcheck-verify

Requires Node 18+ (uses global fetch). Zero dependencies. MIT.

Quickstart

js
import { verifyBeforePay } from "@pennyforgeorg/sendcheck-verify";
// Throws SendCheckVerifyError unless the address passes the free pre-check.await verifyBeforePay("0x9504A5939AB5be2B2B1F8beA7D7ebeCcd96c485D");
// …then sign your x402 payment.

CommonJS:

js
const { verifyBeforePay } = require("@pennyforgeorg/sendcheck-verify");

Typical wiring inside an x402 client:

js
import { verifyBeforePay } from "@pennyforgeorg/sendcheck-verify";import { wrapFetchWithPayment } from "x402-fetch"; // or your own x402 stack
const pay = wrapFetchWithPayment(fetch, { wallet });
async function call(serviceUrl, address, body) {  await verifyBeforePay(address);          // free — catch bad addresses here  const res = await pay(serviceUrl, {      // paid only when the address is clean    method: "POST",    headers: { "content-type": "application/json" },    body: JSON.stringify(body),  });  return res.json();}

If you already normalize addresses on your side and just want the result object (no throw):

js
const r = await verifyBeforePay(addr, { throwOnError: false });// { valid, status: "valid" | "plain" | "mismatch" | "format" | "network" | "http",//   message, normalized, checked }

API

verifyBeforePay(address, opts?)

  • address — EVM address, 0x + 40 hex.
  • opts.baseUrl — override the API host (default: the live worker).
  • opts.fetchFn — inject a fetch implementation (tests / proxies).
  • opts.throwOnError — default true; pass false to always get the result back.

Behavior notes:

  • A string that isn't even 0x+40-hex fails the local format check and throws (or returns checked: false) without sending a request — you never pay a round trip for garbage input.
  • status: "plain" = valid address, all-lowercase or all-uppercase (no case information). That's fine to pay; the response includes the normalized EIP-55 form.
  • status: "mismatch" = the casing does not match the address hash — usually a typo or tampering. This is the one to treat as hard-fail.

looksLikeAddress(addr) — offline format check, no network.

verifyAttestation(attestation, opts?)

Verify a signed block { jws, key } (ES256 JWS over a canonical-JSON payload). Pure + async (WebCrypto); no network. Returns { valid, reason?, payload, keyId, signedAt, expiresAt, warning? }. opts: origin, expectedPayTo, challengePayTo, route, challengeMaxAmount (atomic USDC string), now (unix seconds, for tests). Time windows: exp hard-reject with a 60s clock-skew grace; iat may be up to 60s in the future; an iat older than 30 days is valid but returns warning: "stale". reason codes: malformed, header_mismatch, kid_mismatch, signature_invalid, service_mismatch, payto_mismatch, challenge_payto_mismatch, route_not_signed, price_exceeded, expired, iat_future.

checkService(origin, opts?)

Fetch <origin>/.well-known/x402, verify its signed card against the doc's own advertised payTo, and report whether a pinned key changed. Returns { ok, origin, payTo, keyId, signedAt, expiresAt, warning?, attestation, keyChanged, endpoints: [{resource, amount}] }. opts.fetchFn (inject fetch), opts.pinnedKey ({kid} or {kid,x,y}), opts.throwOnError. keyChanged is the loud rotation signal.

verifyChallenge(challenge, attestation, opts?)

Bind a 402 challenge to a signed card. challenge is the decoded 402 declaration ({ resource: { url }, accepts: [{ payTo, maxAmountRequired }] }) — decode the base64 PAYMENT-REQUIRED header with JSON.parse(Buffer.from(hdr, "base64").toString("utf8")). The route is derived from resource.url. Returns the verifyAttestation result.

ATTESTATION_EXTENSION — "x-sendcheck-attestation", the extension name

the signed block rides in under inside the 402 challenge's extensions map.

canonicalJson(value) — RFC-8785-style canonical JSON (recursively sorted

keys) — exported for anyone re-implementing the signer.

SendCheckVerifyError — thrown on non-valid results; err.result carries

the full result object.

The endpoint, in plain terms

GET https://api.pennyforge.org/validate?address=0x…→ 200 { "valid": true, "status": "valid", "message": "Valid EIP-55 checksum.",        "normalized": "0x…" }

Free. No key. No account. JSON in, JSON out. The paid siblings — POST /check ($0.01, one chain: wallet-vs-contract, activity, balances, verdict) and POST /deep ($0.05, all five chains + wrong-network detection) — use x402 (USDC on Base). Machine-readable docs: llms.txt and openapi.json on the same host.

Who runs it

SendCheck is a one-person studio (Pennyforge). The worker runs on Cloudflare Workers; the address engine is MIT and public here. If the free endpoint ever moves, opts.baseUrl is the only thing you change.

License

MIT — see LICENSE.

来源:README.md,提交 53eb096

工具

3

validate_address

FREE pre-send check of an EVM address: EIP-55 checksum verification (catches typos, dropped characters, clipboard malware) + a note that a passing checksum is a spell-check, not payee verification. Run this before paying for check_address.

输入参数address必填

check_address

Paid pre-send verification of one EVM address on one chain ($0.01 USDC via x402, EIP-3009 on Base): checksum, wallet-vs-contract, outgoing activity, native/USDC/USDT balances, leveled verdict with reasons and next action. TWO-PHASE: call without x_payment first to get the exact payment challenge (payTo, amount, asset), sign the USDC transfer, then call again with x_payment = the resulting X-Payment header to get the report. No account, no API key — the payment is the authentication.

输入参数chainaddress必填x_payment

deep_scan

Paid deep scan: the full verification across ALL FIVE chains (Base, Ethereum, Arbitrum, Optimism, Polygon) incl. wrong-network detection and USDC/USDT token-mismatch flags ($0.05 USDC via x402, EIP-3009 on Base). TWO-PHASE like check_address: first call returns the payment challenge; second call with x_payment returns the report.

输入参数address必填x_payment

版本历史

1
  1. v1.0.0最新Sep 16, 2026

评分

已满足适用检查项的 100%

该评分衡量此收录条目的完整程度,依据注册中心条目、端点与公开来源计算得出。它不是对服务器本身的评价,也不表示服务器安全或当前可用:可连通性是带日期的检查结果,评分也不包含安装量或用户评价。

  • 近 30 天内可连通必需25 分
  • 已声明认证方式必需10 分
  • 已列出工具必需15 分
  • 描述必需15 分
  • 图标10 分
  • 文档15 分
  • 许可证10 分