Thank you for performing real exchanges and documenting the completed payouts.There are two points that should be clarified so readers do not draw a stronger conclusion than the test supports.
1. The rate is floating, not fixedPablo Cash uses a
floating-rate model, not a fixed-rate model.
The absence of JavaScript only means that the quote is refreshed by a server-side request when the
Calculate button is pressed. It does not determine whether a rate is fixed or floating.
The amount displayed when an order is created is an
estimate based on the current market rate. The final payout amount is calculated after the deposit receives the required network confirmations, using the market rate at that time and including the applicable fees.
The two-hour period is the
payment-validity window for the order. It is not a two-hour rate lock.
Our previous wording could have made this distinction insufficiently clear, so it has now been stated explicitly in the FAQ:
Is the rate locked when the order is created?
2. The KayAML result is a risk signal, not proof of stolen BTCYour post correctly notes that KayAMLBot can sometimes classify an address incorrectly.
The KayAML result is worth recording as a screening signal, but it does not establish that the BTC received in this test was stolen.
The payout transaction can be independently inspected here:
01c9f4264e0e86d6d59b85331255f7ce692b66206d911d809f918046ca9d6468The transaction contains:
- Six inputs totalling 620,497 sats;
- A customer payout of 610,149 sats;
- A change output of 9,225 sats;
- A transaction fee of 1,123 sats.
This is a
multi-input pool transaction.
Bitcoin does not assign particular inputs to particular outputs. Therefore, the transaction itself does not show that one specific input funded all, or any defined part, of the customer output.
Under the model described in our rules, customer deposits and payout liquidity are operated as separate pools. The required payout is prepared from the payout pool rather than forwarding one customer’s deposit directly to another customer.
The multi-input transaction with change is consistent with such pooled operation. However, the transaction structure alone should not be treated as a guarantee of absolute cleanliness.
3. The alleged theft path was not suppliedThe KayAML response shown in the review contains no:
- Originating theft transaction;
- Affected amount;
- Hop distance;
- Victim or incident reference;
- Contaminated UTXO;
- Reproducible transaction path.
Its
and
fields are also empty.
Therefore, the
result is an automated address-level label. It is not a reproducible transaction trace proving that 100% of the received satoshis were stolen.
4. Independent providers produced materially different resultsA same-day independent MistTrack recheck classified the receiving address as:
3/100 — Low Risk
No risk details and no malicious label.
The reusable input/change address was also classified as:
3/100 — Low Risk
No risk details and no malicious label.
The official AMLBot check cited in the review returned a materially different
68/100 Medium Risk result with mixed categories, rather than a transaction-level finding that the payout consisted of stolen funds.
This does not justify claiming that any wallet is “guaranteed clean.” It shows that different automated providers produced materially different heuristic results.
AMLBot’s own published methodology explains that a wallet score is a
risk signal rather than a legal verdict, and that even a High Risk result does not prove criminal activity:
AMLBot: What Low, Medium and High Risk Actually Mean
The precise conclusionOne automated checker produced a
alert, but no underlying theft transaction, affected amount or traceable path was supplied.
Another checker returned Medium Risk with different categories, while MistTrack classified the relevant addresses as Low Risk.
The evidence presented is therefore insufficient to conclude that Pablo Cash paid out stolen BTC.
5. The 0.0061 BTC / 0.0065 BTC behaviorThe difference you observed between
0.0061 BTC and
0.0065 BTC is consistent with the route-specific minimum for the asset being received, rather than a fixed-rate mechanism or a blockchain-node failure.
The minimum depends on the payout asset. If the applicable threshold was not displayed clearly enough during your test, that is fair feedback and the presentation should be unambiguous.
Thank you again for documenting the completed tests.
The successful payouts and the reported screening results are both useful facts. They simply need to be described with the appropriate technical limits.
