Built on Blockscout

tidex6: Private Stablecoin Payments Getting Whitechain History from Blockscout

Blockscout

05 Nov 2026 • 3 min read

Supporting privacy on a diverse set of blockchain networks

What tidex6 does

tidex6 is a private stablecoin payment system with disclosure by consent. It runs on Solana, Arc and six EVM networks including Whitechain, and the code is open source. It’s built for people and small businesses who pay in stablecoins, and don’t want every payment public, but still need to show some payment history to an accountant, an auditor or a counterparty. Payments go through a shielded pool. The sender can attach an encrypted note that only a chosen auditor can read.

The problem: Whitechain node pruning forgets old payments

The tidex6 relayer indexes every pool's deposits, so a recipient's browser can find payments addressed to it without scanning the chain itself. This works quickly on most chains, but tidex6 found that Whitechain’s settings were causing problems.

The chain's node prunes receipts, and logs go with them. Anything older than about 7M blocks is gone from eth_getLogs. For users, this meant a recipient on Whitechain could not see older payments sent to them.

How the relayer uses the Blockscout API to get logs

To address the problem, the team set the indexer on Whitechain to read deposit events from Blockscout instead of the node. The loop works like this:

It calls module=logs&action=getLogs, filtered by pool address and event topic, in block windows.
It polls every few seconds.
Each pass re-reads the last 64 blocks, in case of a reorg.
Each log is converted to the same shape eth_getLogs returns, so the rest of the code does not care where it came from.

Blockscout returns the block timestamp with each log, which saves one extra RPC call per payment. And the relayer's public Whitechain RPC endpoint now answers eth_getLogs from Blockscout too, so wallets and scripts that ask the relayer get the full history.

To see more about how it works, the integration is available at src/explorer_logs.rs.

Why not run an archive node

When trying to figure out a strategy to support Whitechain, they also looked into running an archive node. However, this meant a lot of overhead, disk and ongoing upkeep that was only needed for a single chain. Blockscout already held the full history behind an API compatible with the logs query tidex6 was using. The fix came to about 150 lines of Rust.

Other pain points across the networks

While the Blockscout API solved this problem, tidex6 found other problems that differed by chain. Each chain is unique and requires different API tuning to get the best results.

Network	Pain point
All EVM chains	Public RPCs cap eth_getLogs ranges, so each chain is indexed in windows sized to its own limit
HyperEVM	The pool deployment does not fit in a fast block (3M gas), so deployment needs big blocks
Arc	Gas is paid in USDC. The native balance has 18 decimals, the USDC token has 6, and the two are easy to mix up
Robinhood testnet	A stock token with 18 decimals did not fit 64-bit note amounts, so pools now carry a unit scale
Solana	Many RPC providers block getProgramAccounts, so the relayer serves the pool's leaf list itself

What's next

Tidex6 continues to improve the process, and a new note format (v2) is live on all tidex6 testnets. The amount is bound to what was actually paid in, and only the recipient's key can spend a note.

Next on the list are a public trusted-setup ceremony for the v2 circuits, and mainnet on Arc and Solana.

In their words

"Our relayer had no way to reach old Whitechain logs through the node. Blockscout had them all, behind the same kind of logs query we already used. We plugged it in and recipients could see their older payments again."

tidex6 (koshak01 on X/GitHub)