Transparency & Corrections

VDF mislabeling — buyer refund record and pairing confidence note

Following the VDF algorithm correction disclosure (2026-09-09), FairSeal issued a refund of 0.005 USDC to the one confirmed external buyer affected by the mislabeled period (purchases prior to 2026-09-01 04:02 UTC on /v1/rng/latest).

Refund record (verified on-chain): Payer 0xC59E74ED6386b2a12D892FFF2509A6965A0498DC — 0.005 USDC refunded 2026-09-09, tx 0x6cc16a0747370d631d8a75803dfc03b83a8109c8c806fc524c7538ba3ef0d030, block 51,068,540 on Base mainnet (status: success).

Residual uncertainty: The association between this buyer's wallet address and the specific affected purchase is based on nginx timestamp correlation, user-agent string, and payment amount — not a direct link from the x402 payment header or server logs. Classification: hypothesis with high-confidence timing evidence. No other external buyers have been identified in the affected pre-2026-09-01 window (per internal audit 2026-09-09).

Notarize retry: concurrent-retry and lost-response can result in double-charge (open)

Our R8 internal audit (2026-09-11) found that the /v1/notarize endpoint has no application-layer deduplication by payload. Two fault scenarios produce a double notarization and double x402 charge for the same payload:

• S1 (lost-response): server returns 201 but the response is lost in transit; client retries with a new x402 authorization → second receipt anchored.
• S2 (concurrent-retry): two POST requests arrive for the same payload_hash before either completes → both succeed and are anchored.

Both receipts are independently valid and correctly anchored with Merkle proofs. EIP-3009 replay prevention (blockchain-enforced) prevents the same signed authorization from being reused — each double-charge requires a fresh payment, so the scenario is accidental (not adversarial). Root cause: no UNIQUE constraint on payload_hash in the receipts table; no client-supplied Idempotency-Key mechanism.

Impact: Risk of accidental double-charge on network failure or client retry patterns. No production incident has been confirmed to date (per internal audit 2026-09-11). S3 (delayed-anchor) and S4 (service-restart) are safe — verified by fault-injection test.

Current mitigation: Idempotency-Key header design is drafted (Stripe-style client-supplied dedup token with 24h TTL). Implementation requires L3 approval; not yet deployed as of 2026-09-17. Buyers who need immediate dedup assurance should supply a unique payload hash per distinct notarization intent and poll GET /v1/notarize/:id before retrying.

Docs page overclaimed PII results carried cryptographic evidence

Our API docs described /v1/pii/detect as returning a receipt with “cryptographic evidence” — it does not. PII detection responses are regex findings with sanitized text and contain no cryptographic artifacts. The listed HTTP method was also wrong (GET; it is POST). Found by our own four-layer claims-verification gate the same day it went live (L4 for this endpoint: NOT VERIFIED), which is exactly what the gate exists to catch.

Fix (same day): docs wording corrected to state the coverage limits and the absence of cryptographic proof explicitly.

Anchor service failed closed after a nonce collision

During our own end-to-end testing on 2026-09-13, the anchor batch transaction collided with another service sharing the same deployer wallet (REPLACEMENT_UNDERPRICED). That error class was missing from the transient-retry whitelist, so the anchor engine entered its fail-closed degraded state and /v2/anchor returned 503 until an operator restart. No receipts were lost (queue state is persisted) and no incorrect receipts were issued -- fail-closed behaved as designed: refuse service rather than emit evidence we could not stand behind.

Fix (same day): replacement-underpriced errors are now classified as transient and retried with a re-fetched nonce, like other nonce races. We publish this because a refusal outage is still an outage -- and because it is what principle 3 of our manifesto looks like in practice.

Verifier UI broken for 3 days after a security hardening pass

On 2026-09-09 we tightened the Content-Security-Policy on verify.fairseal.io to reduce XSS surface. The tightening also blocked the page's inline event handlers, silently breaking all interactive verification in the browser UI. Our uptime monitoring checks HTTP status, not interaction, so this went unnoticed until 2026-09-12.

Fix: handlers migrated to CSP-compliant code and click-tested headlessly. Lesson adopted: any CSP change now requires an interaction-level test, not just an HTTP 200 check. Receipt verification itself was unaffected — offline verification via @fairseal/verify worked throughout.

VEO endpoint could charge buyers for malformed requests

Our own payment-path audit (2026-09-09) found that a structurally invalid request body to the paid VEO endpoint could return HTTP 200 and settle the x402 payment — meaning a buyer could be charged for a request that produced no valid receipt.

Fix (2026-09-10): structural validation now runs before payment settlement. Malformed bodies return 400 payment_canceled with a machine-readable hint, and the buyer is not charged. Verified end-to-end with real payments.

/v2/anchor pricing: listed price vs batch-amortized cost

The anchor endpoint was listed at $0.01/request while the underlying on-chain anchoring cost is batch-amortized (many receipts share one Base transaction). We added an explicit disclosure of the batch-amortization model to the machine-readable .well-known/x402 manifest so buyers can see exactly what the price covers.

@fairseal/commit ≤0.1.3: verifier was not fail-closed

In @fairseal/commit versions up to 0.1.3, verifyReceipt() never actually invoked beacon signature verification — a receipt with a forged beacon signature could report beaconVerified: true. This defeated the point of independent verification for that field.

Fix (v0.1.4, published 2026-09-09): beacon verification is wired in, offline beacons are explicitly rejected rather than silently trusted, and self-reported resolution.verified flags are ignored. 47/47 tests pass. If you verified receipts with ≤0.1.3, upgrade and re-verify.

VDF algorithm mislabeled as Wesolowski before 2026-09-01

Before 2026-09-01, responses from /v1/rng/latest labeled the VDF as wesolowski-2048 while the engine actually in production was an iterated SHA-256 chain (also sequential, but not a Wesolowski VDF and without its verification asymmetry). This was our most serious labeling error and the reason this page exists.

Fix (2026-09-01): a genuine Wesolowski RSA-2048 VDF with verifiable proof output is now live in production. Disclosure (2026-09-09): full notice published with the audited affected window and buyer contact path: Service Notice — VDF Algorithm Correction. We apologized to affected buyers and stand by that apology.

Site copy claimed BLS12-381 signatures; live receipts use EIP-191 / Ed25519

Marketing and docs copy referenced BLS12-381 aggregate signatures. No live receipt has ever been signed with BLS — production uses EIP-191 (secp256k1) for VEO-1 and Ed25519 for VEO-2. Copy was corrected across the landing page, verifier page, and llms.txt on 2026-09-05. The cryptography actually in use was always disclosed in receipt payloads; the error was in descriptive copy.

Overclaim cleanup: "cannot be backdated" and related copy tightened

A claims-precision pass replaced loose language with exact statements: "cannot be backdated" became a precise description of entropy ordering and external anchoring; verification code examples were corrected to check anchored === true before acceptance; CSR (Committed Selection Receipt) wording was narrowed to what the evidence actually proves. Our standing rule: the homepage may not claim more than the receipts prove.

A real paying customer hit a 404 after paying

Our first external x402 buyer completed a paid commit, then hit a 404 because they followed a path template literally (/v1/reveal/{id} with braces). The failure was ours: discovery metadata invited the mistake and the error response gave no way to recover.

Fix: requests containing template braces now return a machine-readable 400 with explicit self-correction hints (the full three-step flow), and discovery descriptions were rewritten to prevent path-guessing. Verified end-to-end five times.

Notarize routing gap on payment host + @fairseal/verify 0.3.2

The payment host was missing a route for /v1/notarize (the API host had it); fixed with regression checks across all paid endpoints. @fairseal/verify 0.3.2 published: fail-closed verification semantics, on-chain anchor checking, EIP-191 and Ed25519 support, CJS compatibility fix — 50/50 tests.

Full payment-path integrity audit

We audited all 7 paid endpoints against replayed payments, expired payments, missing payments, and malformed bodies. Replay, expiry, and no-payment scenarios were all correctly rejected. The audit surfaced the VEO malformed-body issue (fixed 09-10, above). We run this class of audit recurringly and publish material findings here.

Genuine Wesolowski RSA-2048 VDF live in production

Real Wesolowski VDF (T=568,300, ~5s epochs, ~30,000× verification asymmetry) replaced the prior engine. 24-hour burn-in: 113/113 proof verifications passed. All algorithm labels across API responses, pricing manifests, and discovery metadata were re-audited for consistency.

rng/latest was unpurchasable due to a metadata encoding issue

The payment facilitator rejected our endpoint description because it contained a non-ASCII character (an em-dash), which silently made the endpoint unpurchasable. Fixed and a guard note added at the source. All paid endpoints now have recurring purchase tests.