PrivateDAO RPC Architecture

PrivateDAO does not treat one browser RPC endpoint as a sufficient production architecture.

Current architecture

Write path

• wallet signs in the browser
• the signed transaction is sent over the active RPC path
• the UI keeps retry and fallback logic for:
• blockhash expiry
• endpoint failure
• transient network faults

Read path

• preferred: backend read node and indexer
• fallback: direct browser RPC

RPC pool

The read node resolves a Devnet pool from:

• `SOLANA_RPC_URL`
• `ALCHEMY_DEVNET_RPC_URL` or `ALCHEMY_API_KEY`
• `HELIUS_API_KEY`
• `RPC_FAST_DEVNET_RPC`
• `QUICKNODE_DEVNET_RPC`
• `EXTRA_DEVNET_RPCS`
• public Devnet RPC

Why the split matters

• proposal lists are heavier than individual wallet-signed writes
• runtime panels and reviewer surfaces create repeated reads
• wallet UX should stay focused on signing, not on carrying all indexing pressure
• MagicBlock and reviewer surfaces can query runtime state without routing every heavy read through the browser

Mainnet recommendation

For mainnet readiness, use:

• same-domain frontend and read node
• pooled authenticated RPCs behind the read node
• direct frontend RPC as emergency fallback only
• monitoring over:
• rate limits
• stale blockhash incidents
• slot lag
• request latency
• read-node route metrics

Not in scope

This read node is not:

• a signer
• a treasury operator
• a custody surface
• a hidden execution relay

It is a read-heavy resilience layer designed to keep governance UX and reviewer surfaces stable under load.