klimadao.finance and app.klimadao.finance, read the way a browser, a crawler, and an agent each actually read them.

app.klimadao.finance does the right thing first: it banners "The Klima 2.0 fair launch period has begun" and links to app.klimaprotocol.com and a fair-launch guide (credited above). But the page underneath still boots its old Polygon Web3 stack, which tries to open a connection to polygon.drpc.org. That connection fails completely at the TLS layer, not a timeout, not a rate limit, an actual protocol-level failure, which cascades into a visible React error and an ethers.js "could not detect network" error in the browser console.

app.klimadao.finance, desktop 1366×900 @2x, captured 2026-08-18. The banner and page render visually; the errors are in DevTools, which is exactly why they're easy to miss and easy for a visiting developer to find.

We ruled out our own network before writing this down: the same sandbox reaches other TLS-1.3 hosts (including drpc.org's own root domain) with no issue, and independently reproduced the exact failure with curl and openssl against polygon.drpc.org specifically, both returning a TLS record-layer error, not a DNS or routing problem.

curl -sI --max-time 10 https://polygon.drpc.org/
# curl: (35) SSL routines:ST_CONNECT:tlsv1 alert protocol version

echo | openssl s_client -connect polygon.drpc.org:443 -servername polygon.drpc.org -tls1_3
# error:...:SSL routines:tls_validate_record_header:wrong version number

# control, same machine, same minute:
curl -sI https://drpc.org/ -o /dev/null -w "%{http_code}\n"   # 200
curl -sI https://cloudflare-eth.com/ -o /dev/null -w "%{http_code}\n"  # 301

Retirement receipts live at klimaprotocol.com/retirements/<address>/<id>. We requested a receipt URL that search engines currently index (a real, or at least once-real, retirement) and a completely fabricated one (0xNONSENSE.../999) with a plain HTTP GET, the way a search crawler, a Slack/Discord/X unfurler, or a lightweight agent would. Both returned HTTP 200 with the exact same generic <title>, meta description, and schema.org/Organization JSON-LD, no retirement-specific data at all, and byte counts within 7 bytes of each other (85,963 vs. 85,956).

curl -sL -o /dev/null -w "%{http_code} %{size_download}\n" \
  "https://www.klimaprotocol.com/retirements/0x7e2213f499920c35346F3BF881D86748B12c23b4/1"
# 200 85963

curl -sL -o /dev/null -w "%{http_code} %{size_download}\n" \
  "https://www.klimaprotocol.com/retirements/0xNONSENSE0000000000000000000000000000000/999"
# 200 85956   (control, a made-up address, made-up id)

Two costs bundled in one gap. First, growth: when someone shares a retirement link to show they offset carbon, Discord, X, and Slack all read the same generic metadata and show a plain "Klima Protocol" card, not the achievement, which is a free viral moment left unclaimed on every share. Second, verification: neither a search crawler nor an agent that fetches HTML without executing JavaScript can tell a real retirement from a fabricated URL from the page itself; both look identical until a full browser runs the client app, which is the only place the true state (present, or "Page Not Found") ever appears.