DEV Community: Lavrent Sar

Watch-Only Wallets for Engineers: Address Monitoring, RPC Polling, and Payment UX

Lavrent Sar — Mon, 02 Nov 2026 20:13:28 +0000

Watch-Only Wallets for Engineers: Address Monitoring, RPC Polling, and Payment UX

You built a checkout flow. The user sees a QR code, scans it, and sends tokens. Then you wait. How do you know the money actually arrived without holding the private keys on your production servers? This is where watch-only wallets come in. They let software monitor blockchain state changes—deposits, confirmations, balance shifts—without ever touching signing material. For engineers building payment systems, separating observation from execution isn’t just a security preference. It’s usually an architectural requirement.

Holding private keys on a web-facing backend invites disaster. If that server is compromised, funds are gone. A watch-only setup restricts the backend to read operations. You import a public address or an extended public key (xpub/zpub) into your database or wallet node, and your application simply watches the ledger.

What Exactly Is a Watch-Only Wallet?

A watch-only wallet tracks addresses and transactions but cannot initiate them. It lacks the cryptographic secrets required to sign data. Think of it as a read-only view of a bank account statement. You can see every deposit and withdrawal, but you can’t write checks.

In practice, this usually means importing an address string or a descriptor into a node or a lightweight library. For UTXO-based chains like Bitcoin, developers often use extended public keys to derive an entire tree of receiving addresses deterministically. For account-based networks like TRON or Ethereum, you typically just monitor a specific base58 or hex address.

The core principle remains the same across networks: decouple the system that detects payments from the system that moves funds. Your API server handles the former. An air-gapped machine or a hardware security module handles the latter.

Monitoring Addresses via RPC

To detect incoming payments, your application needs to query the network. Developers generally choose between running a local full node or calling a remote procedure call (RPC) endpoint.

On TRON, which processes a significant volume of stablecoin payments, you interact with the network using HTTP APIs provided by full nodes (often referred to as TronGrid or similar infrastructure, though policies change). To check if a user paid an invoice, you poll the node for transactions involving your watch-only address.

Here is a simplified pattern for checking TRC20 token transfers using a standard JSON-RPC or REST approach. You query the contract's Transfer event logs filtered by your topic (the padded address):

// Conceptual example: polling for TRC20 deposits
const endpoint = "https://api.trongrid.io"; // or your own node
const contractAddress = "TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t"; // Example USDT
const myWatchAddressPadded = "000000000000000000000000" + myWatchAddressHex.slice(2);

async function fetchDeposits(fromBlock, toBlock) {
  const response = await fetch(`${endpoint}/v1/contracts/${contractAddress}/events`, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      event_name: "Transfer",
      block_range: { start: fromBlock, end: toBlock },
      filters: { topic1: myWatchAddressPadded } // topic1 is usually 'to' address
    })
  });
  return response.json();
}

This script doesn't spend anything. It asks the node, "Did anyone send tokens to this padded address between block X and block Y?"

As a rule, you don’t want to poll blindly from genesis. Maintain a cursor in your database storing the last processed block height. When your cron job or worker runs, it queries from last_processed_block + 1 to the current head.

Keep in mind that public RPC endpoints enforce rate limits. If your payment volume scales up, relying on shared infrastructure often leads to throttled requests and missed events. Many engineering teams eventually migrate to dedicated nodes or specialized providers like gf-pay.best to handle RPC traffic reliably when building out crypto checkout flows. Network conditions fluctuate, so having a fallback mechanism or a queue for failed RPC calls is standard practice.

Reconciliation and State Management

Detecting a transaction is only half the job. You must map it to a specific order in your database. This reconciliation process requires careful state management.

When generating a payment request, you usually assign a unique deposit address to the user, or you expect a precise amount to a shared pool address. If you use unique addresses per invoice (a common pattern derived from xpubs), reconciliation is straightforward: any deposit to address X belongs to invoice X.

If multiple users pay into a single watch-only address, you have to rely on exact amounts or memos. This gets messy fast because floating-point arithmetic and blockchain decimals rarely align perfectly. Users might send 10.000001 instead of 10.00. Your logic needs tolerances, usually defined by your business rules.

Once a transaction is spotted via RPC, update its status in your database:

Pending: Transaction seen in the mempool or latest block.
Confirming: Block depth increases. Most systems require a certain number of confirmations before crediting the user. On TRON, 19 confirmations are often cited as a standard threshold for finality, but you should verify current network parameters.
Completed: Required confirmations reached. Trigger your webhook to fulfill the order.
Failed/Orphaned: The chain reorganized, and the transaction dropped.

Never trust a zero-confirmation transaction for high-value settlements unless your risk model explicitly allows it. Chain reorganizations happen. A block you saw at height N might not be in the canonical chain five minutes later.

Designing the Payment UX

Backend reliability means nothing if the frontend confuses the user. Payment UX relies heavily on the speed and accuracy of your watch-only monitoring.

Users expect instant feedback. When they broadcast a transaction, their wallet says "Sent." But your system hasn't confirmed it yet. The UI should reflect this reality. Display a "Waiting for network confirmation..." state rather than jumping straight to "Processing" or leaving the user staring at a static spinner.

WebSockets are generally preferred over HTTP polling for the client-side experience. Your backend workers poll the RPC, update the database, and push an event via WebSocket to the specific client session. This keeps the UI snappy without forcing the user's browser to spam your API with "Is it there yet?" requests.

Also, handle edge cases gracefully. What happens if the user sends the wrong token to the watch-only address? What if they send it on the wrong network (e.g., sending ERC20 to a TRC20 address)? Your watch-only wallet will likely ignore it because the RPC filter targets a specific chain and contract. The user thinks they paid; your system sees nothing. Clear instructions on the checkout page specifying the exact network and token contract are mandatory, not optional.

Timeouts are another UX consideration. If a user generates an invoice but doesn't pay within 15 or 30 minutes, invalidate the address or lock the exchange rate. Leaving watch-only addresses open indefinitely complicates your reconciliation logic and exposes you to volatility risks.

Security Boundaries and Key Hygiene

The primary reason to use watch-only architectures is minimizing the blast radius of a breach. If an attacker gains root access to your payment processing server, they should find nothing but public keys and historical transaction logs.

Store private keys offline. Use hardware wallets or air-gapped machines for sweeping funds. When your watch-only wallet accumulates enough deposits, you construct an unsigned transaction on your hot server, move it to the cold environment via QR code or USB, sign it, and broadcast it.

Audit your dependencies. Cryptographic libraries evolve. Vulnerabilities in how an xpub is parsed or how an RPC payload is validated can introduce risks even in read-only systems. Treat your watch-only infrastructure with the same rigor as your signing infrastructure, because while it can't lose funds directly, it controls the information flow that triggers your business logic.

Conclusion

Watch-only wallets solve a fundamental problem in crypto software engineering: how to observe value transfer without holding the keys to the vault. By leveraging RPC polling, maintaining strict reconciliation state, and designing transparent user interfaces, developers can build robust payment systems. Keep your keys cold, your nodes synced, and your database cursors accurate.

Frequently Asked Questions

Can a watch-only wallet accidentally spend funds?
No. By definition, a watch-only wallet lacks the private keys or seed phrases required to cryptographically sign a transaction. Even if the software has a bug, it cannot authorize an outbound transfer. It can only read the blockchain state.

Do I need a full node to run a watch-only wallet?
Not strictly. You can use third-party RPC providers or lightweight SPV (Simplified Payment Verification) clients. However, running your own full node gives you complete control over indexing, removes reliance on external rate limits, and ensures you aren't being fed manipulated chain data.

How do I handle multiple blockchains with one watch-only setup?
Architecture varies significantly between chains. UTXO models (Bitcoin) use extended public keys to derive infinite addresses. Account models (Ethereum, TRON) monitor specific hex/base58 strings and parse internal transaction data or event logs. You usually need separate reconciliation workers tailored to each network's RPC specifications.

Inside the OTC Spread: How USDT Pricing Actually Works Under the Hood

Lavrent Sar — Mon, 02 Nov 2026 15:21:33 +0000

Inside the OTC Spread: How USDT Pricing Actually Works Under the Hood

You send a request to an API. The response returns a price for USDT that is 0.15% away from what your local exchange ticker shows. You might call it a bad rate. An engineer building payment systems calls it a map of operational friction.

That gap between the spot price you see on a screen and the executable price an Over-The-Counter (OTC) desk offers isn't arbitrary. It is calculated. It represents network fees, settlement delays, counterparty risk, and the cost of moving capital across fragmented infrastructure. For software engineers building crypto-payment rails or reconciliation engines, treating the spread as a simple margin error means misunderstanding the system entirely.

Let's break down how desks usually construct these prices, looking at liquidity, transport layers, and the technical reality of reconciling it all in code.

Liquidity Is a Graph, Not a Pool

Retail trading interfaces generally present liquidity as a single order book. OTC desks operate differently. They view liquidity as a distributed graph. A desk might hold inventory on multiple chains simultaneously—Ethereum, Tron, Solana, Polygon—while also maintaining fiat balances in various jurisdictions.

When you request a quote for USDT, the desk's pricing engine doesn't just check one balance. It evaluates the cost of sourcing that specific stablecoin on the specific chain you requested, at that exact moment. If their Tron reserves are low but their Ethereum reserves are high, the quoted price for TRC-20 USDT will likely widen to account for the cost of rebalancing their inventory.

This rebalancing takes time. During that window, the desk carries exposure to market volatility. Even with a stablecoin like USDT, which usually maintains a tight peg to the dollar, slight deviations occur during periods of high network congestion or sudden market stress. The spread absorbs this variance. As a rule, the less liquid the specific chain-to-fiat corridor, the wider the spread needs to be to protect the desk's operating capital.

The Cost of Rails: Why Transport Matters

Engineers understand that moving data has latency costs. Moving money has similar constraints, plus financial overhead. The "rails" refer to both the blockchain networks used for the digital asset and the traditional banking systems used for the fiat leg of the transaction.

Settling a trade via a SWIFT wire transfer usually takes one to three business days. During those days, the capital is locked. The desk factors the opportunity cost of that locked capital into the spread. Conversely, settling via a faster domestic payment rail (like SEPA Instant or FedNow, where supported) might reduce the time-risk, but those rails often carry their own fixed transaction fees.

On the crypto side, gas fees dictate routing logic. If the Ethereum mempool is congested, executing a transfer might cost significantly more than usual. Pricing engines query node RPC endpoints to estimate current base fees and priority tips. This data directly influences the final quote.

Here is a simplified example of how a pricing service might structure a quote object, pulling in rail-specific variables before returning a payload to a client:

{
  "quote_id": "q_8f7a9b2c",
  "asset": "USDT",
  "network": "TRC20",
  "base_reference_price": 1.0000,
  "spread_bps": 12,
  "network_fee_estimated": 1.00,
  "final_executable_price": 1.0012,
  "expires_at": "2023-10-27T14:32:00Z",
  "routing_notes": "trc20_low_congestion"
}

Notice the expires_at field. Because gas prices and liquidity shift constantly, quotes are ephemeral. A pricing engine typically invalidates these objects every few seconds. If your application attempts to execute against an expired quote ID, the API will reject the call. Handling this state gracefully in your frontend or backend worker queue is a standard requirement when integrating with institutional desks.

Risk Premiums and Counterparty Logic

Software engineers tend to think in deterministic terms: if X, then Y. Financial systems are probabilistic. OTC desks price in the probability that something goes wrong.

Counterparty risk is a major variable. If a new corporate client requests a large block of USDT without an established settlement history, the desk's risk management policies—which change frequently based on internal compliance reviews—might automatically widen the spread. This isn't a penalty; it is an insurance premium against the possibility of a failed wire, a frozen bank account, or a disputed transaction.

Regulatory friction adds another layer. Moving fiat across borders involves correspondent banks, each with their own compliance checks. A payment route that touches three intermediary banks will inherently carry more risk of delay or rejection than a direct domestic transfer. The pricing algorithms weigh these routes. Sometimes, a slightly more expensive rail is chosen because it offers higher settlement certainty. The desk optimizes for successful completion, not just the lowest theoretical fee.

For stablecoins specifically, de-peg risk is modeled. While USDT historically stays very close to $1.00, brief fluctuations happen. Desks monitor oracle feeds and secondary market spreads continuously. If the broader market shows signs of stress, the automated spread widens to prevent the desk from selling inventory below its actual replacement cost.

Reconciliation: The Engineering Reality

Quoting a price is only half the system. Reconciling the executed trade is where most integration headaches occur. When your application interacts with an OTC desk—often through platforms like gf-pay.best or direct API integrations—you must reconcile two separate states: the fiat ledger and the blockchain ledger.

Blockchain transactions have finality thresholds. On Bitcoin, you might wait for six confirmations. On Tron, finality is faster but still requires monitoring the block height to ensure no reorganizations occur. Your system cannot simply mark a trade as "settled" the moment the RPC endpoint returns a transaction hash. You must poll or listen for webhooks indicating the required confirmation depth has been reached.

Furthermore, floating-point math is dangerous here. Engineers should handle all currency values as integers (representing the smallest unit, like satoshis or wei) or use dedicated decimal libraries. Standard IEEE 754 floats will introduce rounding errors that cause reconciliation mismatches over thousands of transactions.

A typical reconciliation loop looks like this:

Client initiates trade via API.
Desk locks the quote and provides a deposit address or expects a push.
System monitors the relevant chain via RPC/WebSocket for the incoming asset.
Once confirmations hit the required threshold, the system updates the database state.
The fiat leg is verified against bank statement APIs or webhook notifications.
Only when both legs are confirmed does the system emit a TRADE_SETTLED event.

If step 3 and step 5 fall out of sync—say, the crypto arrives but the wire is delayed by a weekend—the spread originally quoted had to account for this exact asymmetry. Your database schema needs to support partial states (CRYPTO_RECEIVED_FIAT_PENDING) without breaking downstream reporting tools.

Building for Volatility, Not Just Throughput

When designing systems around crypto payments, it is tempting to focus purely on throughput and latency. But OTC pricing teaches us that reliability and accurate state management matter more. A system that processes trades instantly but fails to account for rail-specific costs or confirmation delays will bleed capital through unresolved discrepancies.

The spread is essentially a serialized summary of system complexity. Every basis point represents a real-world constraint—a slow bank, a congested mempool, a compliance check, or a temporary lack of inventory on a specific chain. Understanding this anatomy allows engineers to build better parsers, smarter retry logic, and more resilient payment architectures.

Frequently Asked Questions

Why do OTC spreads for USDT change so rapidly?
Spreads are dynamically calculated based on real-time inputs. Network congestion alters gas fees, available inventory shifts as other clients execute trades, and fiat banking hours open or close. Pricing engines typically recalculate these variables every few seconds, meaning a quote generated at 10:00:00 AM might be invalid by 10:00:15 AM.

Can I bypass the spread by using smart contracts directly?
Smart contracts automate execution, but they don't eliminate operational costs. If you route through a decentralized liquidity pool, you still pay network gas fees, face potential slippage if the pool lacks depth, and bear the responsibility of managing your own fiat off-ramps. OTC desks bundle these complexities into a single quoted price, handling the bridging between traditional finance and decentralized networks.

How should my application handle an expired quote error?
Your system should treat quote expiration as a standard state, not an exception. Build a retry mechanism that automatically requests a fresh quote via the API if the previous one expires before user confirmation or execution. Ensure your UI clearly communicates that prices are time-bound, preventing users from attempting to settle trades against stale data.