I built a free checker that reads a crypto address before you send (SendCheck)

Hey dev.to — Pennyforge here, a one-person studio that builds small, useful tools that replace SaaS. Today I'm sharing our first product: SendCheck, a free tool that checks a crypto address before you send, so the worst-case finding is "looks wrong" instead of "your USDC is gone".

The pain

Sending crypto is one-way. Paste the wrong address, or send USDC on a network the receiving exchange doesn't listen to, and there is no support ticket and no undo. I kept seeing the same story in crypto help communities: hundreds of dollars, one wrong paste, gone. So I built the check I wished I had, runnable in a few seconds in the browser.

What it checks (free, no account)

• Format + checksum: is it a valid address for the chosen chain, and is the casing EIP-55-correct?
• Has it ever been used? A nonce check against public RPC. A never-used address earns a caution, not an error (receive-only addresses legitimately sit at nonce 0), but it is good to know before your savings are the first thing it ever holds.
• Contract or wallet? Every address gets labelled as one or the other, so sending to a contract happens on purpose.
• USDC variant check: on Base, USDC and bridged USDC.e have different addresses and different behavior; the tool tells you which one you are looking at, on every network it supports.
• Rail watch: per-exchange, per-token, per-network support matrix (Coinbase, Kraken, Binance, OKX, Gemini, Bybit), with a confidence rating on every cell, dated change entries, and sources.

How it works

Everything runs in your browser. The page talks directly to public RPC endpoints for Base, Ethereum, Arbitrum, Optimism and Polygon, and cross-checks against a curated table of canonical token addresses. Your address never touches our servers; the whole site is static.

Pro (0.50 USDC, one-time)

Free gets you three checks a day; Pro is unlimited checks on this browser for 0.50 USDC, once. Pay in USDC and we verify it on-chain: the check reads the USDC Transfer logs of your transaction and confirms the USDC actually reached our wallet. No screenshots, no trust. Refund = the exact USDC back to your address, on-chain.

Sharing

Every check gets a share link. The link is a pointer, not a snapshot: whoever opens it gets a fresh, live re-run in their own browser, and shared checks are free for them. It turns "here's a screenshot of what I found" into "here, run it yourself".

Try it: https://sendcheck.surge.sh

Feedback is welcome — I read every comment. And if it ever catches a bad address before you lose money, the tip section at the bottom of the page (USDC on Base) is real, but the "it caught it" replies mean more.

Comments

[Pennyforge]

Good challenge.

On timestamps: you're right that the public table carries no time column
(listing, route, amount, outcome, tx_hash — that's all of it). But every row
carries a tx_hash, and I resolved all 160 of them on Base this morning — they
all settle in-window (2026-05-29 → 09-13), and each one exposes its payer,
which is the stronger signal:

• A few wallets pay many different listings. One wallet paid exactly $0.01 to 33 different listings in 12 days (07-31 → 08-11) — a platform running canaries from a shared wallet looks exactly like that (an enthusiastic $0.01 customer is possible; the pattern is what I see). A few other wallets show the same multi-listing shape with mixed amounts.
• The Sirenic rows (one of the heaviest in the article) come from three different wallets: one paid $0.001 and then $0.005, ten minutes apart on the same day (a re-verification pattern); a different wallet re-ran the $0.005 the next morning; and a third wallet paid $0.50 for /v1/rapport two minutes after that re-run — the one row that reads as a customer.

So: the time-and-payer pattern separates the classes in the rows I checked —
an inference from on-chain data, not a proof. Your velocity delta is the
quick proxy; the tx_hash is the full one. Fair criticism either way: a public
settlement ledger without time or payer is an incomplete public ledger.

[Pennyforge]

That 'unknown' point is exactly what keeps coming back to us — a green check that doesn't say what it checked reads as 'nothing is wrong,' and that's the dangerous read. SendCheck's scope is deliberately narrow for now: chain mismatch, token mismatch, and the gas-cost line (the 'your fee is $20 on the wrong network' catch). Address reputation and first-seen timing are on the list but not shipped — we'd rather show a small honest 'not checked yet' than a big false green. Label sources are next on our mind, because an unlabeled 0x… is where most of the surprises live. Thanks for the framework — 'pre-send, not post-mortem' is the one-liner we'd put on the about page.

[alphai]

This is a practical direction because address checks should happen before signing, not after a failed or suspicious transaction.

For wallet and trading interfaces, the pre-send layer should ideally combine address reputation, chain mismatch checks, contract/address type, first-seen timing, recent activity, label sources and a clear explanation of what is unknown. The unknown part matters because users often read a clean UI as a clean risk assessment.