Decision (2026-06-20): use dRPC as the Polygon WSS provider for the 24/7 eth_subscribe logs stream, replacing Alchemy. Trigger: Alchemy creds were drained. Root cause: Alchemy bills 0.04 CU per BYTE on the eth_subscribe logs stream — byte/event-metered billing structurally drains an always-on subscription. The swap is a single env var (POLYGON_WSS_URL), zero code change.
Why Alchemy drained — the structural problem
Alchemy meters the
eth_subscribe logsstream at 0.04 CU per byte of pushed data. A 24/7 subscription to a busy log topic pushes a continuous byte stream, so the bill scales with traffic volume, not request count. An always-on subscription is exactly the workload this billing model punishes — it will keep draining any prepaid balance. This is a property of byte/event-metered streaming billing, not a misconfiguration.
Pick — dRPC
| Property | dRPC |
|---|---|
| Billing model | flat per-request (20 CU/req) — NOT per-byte |
| Free tier | 210M CU/mo |
| PAYG | $6 / 1M CU, no monthly floor |
| Redundancy | multi-node routing |
Flat per-request billing is the right shape for an always-on subscription: the cost is bounded by how many calls/notifications, not by how many bytes stream through. The new eth_getLogs backfill calls (see watcher-onchain-gap-backfill) also benefit from flat-per-request pricing.
Swap cost = one env var. POLYGON_WSS_URL is the only thing that changes; no code change anywhere. (This is the same env var the copy lane and watcher already read — see the deploy note in copy-trade-lane about the lane idling silently if it’s unset.)
Verify before cutover
Two dRPC specifics must be confirmed on their dashboard before flipping prod:
- per-notification CU cost — confirm a pushed
logsnotification is charged like a request (20 CU), not re-metered some other way.- WSS concurrency limits — confirm the plan allows the long-lived subscription count we need.
Alternatives considered
- Alchemy PAYG (runner-up). No re-integration needed (already wired), but the per-byte streaming bill is the exact thing that drained us — only viable if the stream volume is low or capped. Keep as a fallback, not the primary.
- Self-host a Polygon node. Not worth it at a single WSS connection — the operational cost dwarfs the savings at this scale.
Related
- watcher-onchain-gap-backfill — the
eth_getLogsbackfill sweep that rides the same provider; flat-per-request pricing helps here too - copy-trade-lane — the original Polygon
OrderFilledWSS detection lane + thePOLYGON_WSS_URL-unset-idles-silently gotcha - polymarket-fetch-deploy — where
POLYGON_WSS_URLlives in the deploy env - polymarket-fetch