The matching problem and how the pool solves it
A single shared address forces you to guess which transfer belongs to which payer: similar amounts arrive together, memos get lost, and someone always rounds the sum. The pool removes the guesswork β the address itself carries the information, because it was issued for exactly one request.
The second factor is the exact amount. The payer is shown the sum to the digit, and the transfer that arrives with that sum on that address is bound to the request automatically. No names, no payment comments, no reconciliation by hand in a spreadsheet at midnight.
- One request β one address from the pool; the address is not reused for other requests.
- The amount is part of the identification: the payer sees the exact figure to send.
- A confirmed match appears in the request history immediately, with the transaction hash attached.
What happens on the chain meanwhile
The pool is a set of ordinary TRON addresses. Incoming USDT on an active address is picked up by the polling cycle: recent activity keeps an address in the hot set, addresses swept clean leave it. Balances you see are snapshots of the public chain, not numbers the service invented.
Collecting from the pool β moving accumulated USDT onward β is a separate, deliberately offline step, consistent with the watch-only design of the whole service. The receiving side stays automatic; the moving side stays in the hands of the key holder.
Edges and failure modes worth knowing
If a payer sends a different amount to the right address, automatic matching will not fire β the transfer is on the chain, but it is not bound to the request. This is resolved by hand with the payer's evidence: the hash and the amount actually sent. The honest interface shows the transfer as unmatched rather than silently crediting a request.
If a payer sends the right amount to an address from an old, already completed request, the same applies: the coins exist, the request is done, and support needs the hash to sort it out. Both cases are rare, and both are solvable β but they explain why the bot repeats "exact amount, current address" so stubbornly.
Related reading
How a crypto-to-fiat exchange actually works
From the outside an exchange looks like one magic step. Inside, it is a chain of five distinct stages, each with its own failure modes and its own evidence trail. This guide walks the chain the way the GF-PAY flow walks it.
Evidence that wins a dispute: hash, quote, chat
Most disputes in crypto exchange are not about opinions β they are about facts that were recorded all along: on the chain, in the request, in the chat. This guide is about collecting those facts while things are calm, so they exist when things are not.
Frequently asked questions
How many addresses does the pool hold?
The pool is sized with a reserve so that concurrent requests never share an address, and it is maintained by the service β you do not manage addresses yourself. What matters on your side is simply that each request gets a fresh one.
What if two payers send the same amount at the same time?
They would still be sending to different addresses, because each request draws its own. The pair "address + amount" is what identifies a payment, and the address half is never shared between active requests.
Can payers send from any wallet or platform?
Yes, any source that can transfer USDT TRC20 works. The practical caveat is platforms that deduct their own withdrawal fee β the amount that lands differs from what the payer typed, and the match then needs manual help.