BackgroundI will start with some brief background to explain why we created this topic and how we arrived at the idea of conducting these checks.
Recently, we encountered a situation in which a review was published on KYCNotList without sufficient verification of the underlying order and its final status. We acknowledge that the review should not have been approved.
This case revealed a weakness in our moderation process and showed that our verification requirements were not being applied consistently in every case. Following the incident, we reviewed our internal procedures, strengthened the requirements for approving reviews, and introduced new service-specific review-verification functionality, which is described below.
We are currently investigating how the review passed moderation and conducting a broader retrospective audit of previously published reviews on KYCNotList. As part of this audit, older reviews are being reassessed against the evidence available under our current verification standards.
If a previously published review cannot be sufficiently verified, its verification status will be changed or, where appropriate, the review will be removed and excluded from the aggregated review figures. Until this audit is complete, we will not claim that every historical review has been independently verified under our current standards.
This situation also highlighted a broader technical challenge: exchangers and mixers use different methods for storing and verifying orders. With some services, order details cannot be viewed using a link or Order ID; some allow orders to be deleted; others use PGP or Bitcoin signatures; and in certain cases, the recipient’s wallet address is required in addition to the Order ID.
A common example is a user providing only an Order ID, believing that this is sufficient to verify the exchange. In many cases, however, an Order ID alone does not provide access to all relevant order details or its final status. With some services, it confirms only that an order was created, while other services require additional information, such as the recipient’s wallet address, before any order data can be viewed. Users may not be aware of these technical limitations when submitting a review.
This was one of the main reasons why more than 90% of submitted reviews had to be rejected because the information provided was insufficient, even though some of them may have described genuine transactions.
This technical complexity does not excuse the approval of an unverified review. It means that the required evidence must be defined separately for each service and requested from the user before the review is submitted. Confirming only that an order exists is not sufficient: when a review concerns a completed transaction, the relevant order details and final status must also be confirmed.
New service-specific review-verification functionalityWe have introduced new functionality in which each exchanger or mixer is assigned a verification method based on how that particular service stores and provides access to its order data.
The review form is therefore not identical for every service. When a user submits a review, the form automatically displays the evidence fields configured for that specific exchanger or mixer and makes the relevant fields mandatory before submission. The moderator then checks the evidence supplied through that service-specific verification process.
Depending on the technical capabilities of the selected service, the following requirements apply:
- If the service provides a signed Letter of Guarantee, the form requires the user to submit its full text. The authenticity of its PGP or Bitcoin signature is checked automatically before the review is sent to moderation. The transaction details and final outcome are then checked using the available evidence, including the relevant blockchain records where applicable.
- If the exchange details can be accessed using an Order ID or order link, the form requires the user to provide this information or attach an order screenshot. The moderator then verifies not only that the order exists, but also its relevant details and final status.
- If both an Order ID and the recipient’s wallet address are required to access the order, the form displays both fields and makes both of them mandatory.
- If the order cannot be independently checked using a link or Order ID, the form requires supporting evidence, such as screenshots showing the deposit address, recipient’s address, exchange amount, and transaction status. If the available evidence is insufficient, the review is not presented as transaction-verified.
- For general services, such as VPN providers, where a purchase cannot be independently confirmed through an order system, reviews may be submitted only by users with verified forum profiles. Verification of the author’s profile is not presented by itself as proof that a transaction or purchase occurred.
The supporting evidence submitted through these fields is visible only to moderators.
In other words, users are not shown the same generic evidence fields for every exchanger while moderators decide only after submission what information should have been requested. The verification method configured for the particular service determines in advance which evidence and fields the user must provide. Moderators then examine that evidence and confirm the order details and final result.
If the required information is missing, or if the order and its final outcome cannot be sufficiently confirmed, the review is not published as transaction-verified.
This functionality significantly reduces the risk of review manipulation.
Why this topic was createdKYCNotList displays not only reviews submitted directly on our website, but also review data collected from other directories and monitoring sites.
To avoid misleading users, we need to identify resources that do not adequately verify whether an order exists, whether the submitted details are correct, or whether the transaction was completed. Reviews from sources that fail these checks should not be included in the aggregated figures displayed on the homepage without an appropriate warning.
For external resources, KYCNotList uses the
“Unreliable review source” status when a documented test shows that a platform’s verification process allowed a review to be published without adequately confirming the underlying order or transaction.
This status does not mean that every review published by that resource is false. It means that the verification controls observed during a specific test were insufficient and that its review data should therefore be treated with additional caution.
When users follow a link to such a resource, they see a warning explaining that its reviews may not have been adequately verified and may therefore be susceptible to manipulation.
This is why we created this topic. Here, we will publish the results of our checks of other directories and monitoring sites, provide the supporting evidence, and indicate the status assigned to each resource.
We will also update a resource’s status if its verification procedures change and a later test produces a different result.
We hope for the community’s support and would appreciate any help with conducting these checks. We believe this information will be useful not only to our monitoring service, but also to the wider cryptocurrency community.
Verification statusesPassed verification — during the documented test, the resource verified that the order existed, checked the relevant details, and confirmed its final status.
Does not adequately verify the order — during the documented test, the resource published a review without sufficiently confirming the existence, details, or final status of the underlying order. The resource therefore receives the “Unreliable review source” status on KYCNotList.
Each status reflects the result of a specific check conducted on the stated date. It should not be interpreted as proof that every review published by the resource is genuine or false.
Verification resultsThe table below will list the directories and monitoring sites we have checked, their assigned status, and a link to the post containing the evidence.
