The claims we removed from our marketing (and why)

In April we did an internal audit of our marketing pages and found two claims that didn't match reality the way our copywriting implied. One was a chain-count overstatement. The other was a settlement-time number that came from estimation rather than measurement. Neither was malicious — both were the residue of a fast-moving product that out-ran the docs — but both were wrong in ways that would have embarrassed us under any kind of scrutiny.

This post is the audit, the corrections, and the policy and tooling we built to prevent the next round of drift. It's the kind of post most companies don't write. We think we ought to.

What we found

Claim #1: our marketing page asserted a count of chains in places where the reality was four EVM chains in hosted checkout. The API supported wallet verification and chain-ingest on Solana and Tron — so the higher number wasn't a complete invention — but those chains hadn't yet shipped to the hosted-checkout surface that the marketing page was about. A close reader would have correctly inferred that we could not actually accept a USDC payment on Solana through our hosted checkout at the time the marketing said we could. The mismatch had drifted in twice in the prior 30 days because different team members had different mental models of "supported."

Claim #2: our settlement-time copy quoted a number in the hero. The figure came from a back-of-the-envelope estimate based on a typical EVM block time at the time of writing, not from instrumented production data. Real settlement time on the platform varies meaningfully by chain, by congestion, and by how strictly the merchant defines confirmed. A single number in a hero is a number you have to be able to defend in a press screenshot, and we couldn't.

What we did

Re Claim #1: the page now says "four EVM networks (Base, Ethereum, Polygon, Arbitrum)" wherever it's about hosted checkout. Where the API layer matters — e.g. on the docs page describing wallet verification — we say "API-ready on Solana and Tron" with the qualifier in the same sentence. The phrase "four EVM chains" or the explicit list is the canonical form. We don't use a higher count without an explicit "API-ready" disambiguation.

Re Claim #2: numeric settlement-time claims are forbidden in our copy until the instrumentation lands and the number comes from a metrics endpoint that we own and can update. The copy says "same-block confirmation" or "in seconds (chain-dependent)" — qualitative language that matches what a customer actually sees, without putting our thumb on a number we can't defend.

How we prevent it next time

We wrote a guard script. It reads a source-of-truth JSON file listing forbidden phrases and the canonical claim each one is forbidden in service of, and it scans the marketing source tree on every commit. If a developer adds back a forbidden phrase, the pre-commit hook (and CI) refuses the commit and points the developer at the canonical replacement.

$ pnpm check:honest-claims
honest-claims: ok (full scan)

When we need to add or update a canonical claim, we edit the JSON file. When a page legitimately needs to talk about a forbidden phrase (e.g. this very post, which has to be able to discuss our old wrong copy), we add an inline marker on the line that tells the guard to skip it. The marker is meant to be used twice a year, not twice a week — if you find yourself adding it often, the canonical claim probably needs updating, not the guard.

The JSON file lives at docs/marketing/honest-claims.json. The script is at scripts/check-honest-claims.mjs. Both are public in the OpenSettle.io repo for anyone who wants to copy the pattern.

Why we're publishing this

Marketing in this category — non-custodial payments, stablecoin billing, all the words near "crypto" — has a reputation problem for good reasons. The least we can do is be specific about what we say, why we say it, and what we won't say. A guard script doesn't make us more honest than the next team. It makes our copy enforceable, which is a smaller and less interesting claim, but at least it's a true one.

We'll repeat this audit on a quarterly cadence and write up any further corrections. If you spot a claim on the site that doesn't match reality — including in this post — please email us. We'll add it to the next round.