pay3: Real-Time Multi-Chain Payments on Streams

A watchlist that grows with every user, on every chain

When a user signs up, they add wallet addresses across EVM chains, Solana, and Tron. From that moment, pay3 has to know the instant anything lands at any of them. Across the user base, that watchlist grows with every signup, and gets harder to monitor with each new chain.

Polling could not keep the promise

The obvious starting point was polling: querying each chain on a loop for new transactions. It burned RPC requests, introduced unpredictable latency between a payment landing and the user seeing it, and across four chains became both expensive and unreliable. For a product whose entire promise is instant confirmation, polling was not a foundation pay3 could build on.

pay3 built its detection layer on Quicknode Streams, the real-time data pipeline that watches the addresses, contracts, and events you specify and pushes a webhook the moment something matches.

One registration model, four chains

A user adds their wallet addresses, pay3 registers them with Streams, and Streams watches Ethereum, BNB Smart Chain, Solana, and Tron for any incoming transaction. The moment a payment hits, Streams fires a webhook to pay3's backend, pay3 confirms it, and the receiver sees the confirmation within seconds. Ethereum went live first. BNB Smart Chain, Solana, and Tron followed the same registration model, with no new tooling and no separate pipeline.

Solana and Tron are load-bearing, not add-ons

Tron carries the largest share of pay3's retail USDT transfers, so pay3 needed all four chains from day one, not EVM-first with the rest bolted on later. Streams supports all four in the same product. Adding a chain is a config change, not a rebuild.