Secure Web RPC Gateway

An abuse-resistant Solana RPC URL for dApp frontends — https://www-rpc.venum.dev/v1/<your-id>. Only real users in real browsers can call it; scrapers, bots, and scripts pointed at the same URL get denied at the edge.

Distinct from the free Solana RPC at rpc.venum.dev, which is the right pick for server-side, scripted, or bot use.

When to use which

Use case	Endpoint
Browser-rendered dApp frontend	Secure Web RPC (www-rpc.venum.dev/v1/<id>)
Backend service / cron / indexer	rpc.venum.dev (guide)
Local dev script, CI test	rpc.venum.dev
Wallet adapter inside a dApp page	Secure Web RPC

The Secure Web RPC is shaped for browser traffic and abuse-resistant by design — server-side clients are intentionally pointed at rpc.venum.dev instead.

Setup (30 seconds)

1. Sign in at app.venum.dev. Your dashboard shows your Secure Web RPC URL.
2. Copy https://www-rpc.venum.dev/v1/<your-id>.
3. Replace your existing RPC URL in your dApp:

// before
const conn = new Connection('https://example-rpc.provider.com/<your-key>');

// after
const conn = new Connection('https://www-rpc.venum.dev/v1/abcdefghijkl');

That's the change. Every standard Solana JSON-RPC method works — read methods, sendTransaction, simulateTransaction, the lot.

What you get

• Abuse-resistant by design. Bots, scrapers, and scripted clients pointing at your gateway URL are denied at the edge. Your dApp's quota stays for your real users.
• Drop-in compatibility. Same JSON-RPC contract as any Solana RPC. No SDK changes, no special client code.

Plug your own RPC Paid tier

Secure your existing RPC against abuse and bots.

Already paying for your own RPC or running your own validator? Keep it. Forward your Secure Web RPC to your own URL and we'll filter the traffic before it reaches your upstream — same browser-only enforcement, your bandwidth, your contract.

1. Upgrade to Starter, Growth, or Pro at app.venum.dev.
2. Expand the Plug your own RPC card under your Secure Web RPC URL.
3. Paste your provider URL (the one with the secret in it). We probe it once with getHealth to make sure it's reachable.
4. Save. Your dApp keeps calling https://www-rpc.venum.dev/v1/<your-id> — every request now lands on your upstream, after our abuse filters.

Your URL is stored server-side and never echoed back to any client — the dashboard only sees a connected flag, not the URL itself. Disconnect any time to fall back to Venum RPC. Downgrading to Free pauses the forwarding (your URL stays saved); upgrading restores it.

Edge response caching Growth+

Cut latency and upstream credit burn without staleness risk.

When enabled, the gateway answers a small set of safe-to-cache Solana RPC methods from a per-POP in-process cache, before crossing to your upstream. Cache TTLs are tight enough that per-POP staleness is bounded by what you'd see on a fresh request anyway.

Method	TTL	Notes
getVersion	60 s	Cluster version, near-immutable between validator upgrades
getLatestBlockhash	80 ms hold + 30 s monotonic max-age	Per-commitment; serves the highest-ever lastValidBlockHeight your dApp has seen
getRecentPrioritizationFees (no params)	1 s	Global variant only; scoped variants pass through to upstream
getSlot	80 ms hold	Per-commitment; monotonic
getBlockHeight	80 ms hold	Per-commitment; monotonic

Account state (getAccountInfo, getMultipleAccounts, getProgramAccounts, getTokenAccountBalance, etc.), simulateTransaction, and sendTransaction are never cached — they always go to upstream so reads stay current and writes always submit.

Enable per gateway: in your dashboard, expand the Secondary Gateways section and click the Edge cache chip on each gateway you want it active on. Caching is opt-in per gateway, so you can enable it on a credit-metered BYOK upstream (where deflected requests save credits) while leaving it off on a flat-rate upstream (where you want first-hand freshness).

Counter on the dashboard: the per-gateway metrics table shows a Cache hits column. Each hit is a request that never left the gateway POP — it's also folded into the $ saved per month tile at $5/M deflected.

Custom domain support

The pooled Venum upstream is enabled for every Venum account — Free tier included. Plug-your-own-RPC, edge response caching, and custom-domain support (rpc.yourdomain.com via CNAME) are paid-tier features.

Server-side access

If your code is running on a server, in CI, or anywhere outside a real browser, use rpc.venum.dev (it's free). The Secure Web RPC will deny those requests on purpose so they don't drain your dApp's quota.

// server-side / bot
const conn = new Connection('https://rpc.venum.dev/?apiKey=<YOUR_VENUM_API_KEY>');

See the Solana RPC guide for the full reference.

FAQ

Does it support WebSocket subscriptions? Yes — accountSubscribe, slotSubscribe, etc. work the same way as on rpc.venum.dev. Browsers connect via wss://www-rpc.venum.dev/v1/<your-id> (web3.js derives this automatically from the HTTP URL).

My dApp also runs in a Node.js test environment. Will those requests work? No — point Node tests at rpc.venum.dev (free, allows server-side clients).

Can I rotate my Secure Web RPC URL? Open a ticket at app.venum.dev and we'll issue a fresh <id>. The old one stops working immediately.

Does edge caching work for my BYOK upstream? Yes — that's its main job. With caching enabled, ~30% of typical dApp polling traffic (getVersion handshakes, latest blockhash polling, prioritization-fee estimator calls) is served at the edge and never reaches your upstream. For credit-metered providers like Helius, that's deflected credit spend; for flat-rate providers (Triton dedicated nodes, your own validator), it's freed-up RPS headroom.

What's NOT cached? Account state reads (getAccountInfo, getMultipleAccounts, getProgramAccounts, getTokenAccountBalance), simulateTransaction, and sendTransaction. These always go to upstream so reads stay current and writes always submit.