Preface

This is the last record in this series. The first three articles completely recorded my transfer from mistakes, the initial appeal and the re-connection of manual customer service in May 2026. The whole process of retrieving the work order, discovering the BVM name change GEB, the invalidity of the old browser domain name, the actual measurement chain network status, and the new domain name to verify the transaction record.
After a year and a half of communication back and forth, repeatedly replenishing evidence, and cooperating with the platform’s requirements in advance 20 The USDT handling fee, multiple connections to the project party to verify the operating status of the chain, update the wallet network configuration, and finally on June 18, 2026 In the morning, I received the platform mail, and the manual review for more than a month was directly rejected. There was no clear reason for the rejection, and only the reason was ‘other’. After a long time to toss, I decided to completely give up this 0.00399895 BTC, write a final review, and give a complete reference to all traders who have encountered similar recharges in the same kind.

1. Event Minimalist Timeline

1. 2025.01.22 Accidents occurred
   Originally planned to recharge BTC to Binance through the BSC (BEP20) network, I first copied the BTC recharge address of the BSC chain of the Binance platform, and then manually switched to BEVM canary (chain) in the MetaMask wallet. id: 1501) The network is transferred, and the address is directly pasted with the Binance BSC recharge address, and the transfer error is caused by the human selection of the wrong chain. Transaction hashing:0x973A64E163D31128C70CFF04B5B026521CBBC988012FEB5AB3E4D1066A7E9F80, 0.00399895 BTC confirmed the account on the BEVM chain, but the Binance account has no assets. The first self-service appeal failed, and the platform could not retrieve the BEVM transaction record directly and rejected it directly.
2. 2026.05 Restart rights protection
   After a year and a half, I found that the BVM project was completely upgraded and changed its name to GEB.bevm.ioThe domain name block browser is completely inaccessible. Give up the self-service form, take the initiative to contact the Binance manual customer service, provide a complete screenshot of UID, transaction hash, and wallet transaction, take the initiative to explain that it is your own operation error: use BEVM Canary network, fill in the BSC recharge address to transfer money, and simultaneously submit the GEB official document supporting the fact that the project is renamed.
3. 2026.05.19 Formal submission application
   According to the customer service requirements, the pre-deposit 20 USDT recovery fee for the spot account, the customer service helps to submit the asset recovery work order, the application number:cxf71hhq3iuaujpi14o8. The platform informs that it is expected that the preliminary review of 2 working days will be more than 30 working days for the overall fund processing cycle, and the page identifies the recharge network as BEVM.
4. 2026.06 Discovery of major hidden dangers of refund, continue to supplement evidence
   Platform requirements are only supportedBEVM same chain original return, but the old domain name browsers and RPCs are all paralyzed, and they are worried that the assets will be locked in the chain after the refund and cannot be operated.

• Connecting to the official GEB community, the administrator confirms that the underlying node of BEVM Canary is normally out of the block, but is independent of the GEB main network, and has no asset migration scheme;
• The measured chainlist chain is continuously updated, which proves that the bottom layer of the chain has not been shut down, but the public service for ordinary users is completely invalid;
• Community users prompt domain name replacement scheme:bevm.ioToGEB.Network, the new browser link can open the transaction record normally, and fully verify the transfer;
• Update the MetaMask network RPC and browser addresses, use GEB’s new domain name configuration, and synchronize the full set of network change evidence to the customer service, and inform the platform that I can receive assets normally after the original road refund.
• Binance backends independently capture BEVM chain blocks to complete independent on-chain data verification, and work orders enter in-depth case evaluation.

1. 2026.06.18 The complaint was dismissed, and the rights protection was completely terminated
   In the early morning, I received an automatic notification email from Binance, clicked on the details to confirm that the review of the work order failed, and there was no detailed basis for rejection, only general classification as ‘other’, the handling fee was 20 USDT not deducted, and the platform remarks only prompted to contact customer service for details. After repeated weighing, it was decided not to continue the appeal and give up the asset.

2. Dismiss the complete information publicity of the work order

Original email notification

uncredited deposit application (audit rejected)
Your uncredited application CXF71hhq3iuaujpi14o8 was rejected, please kindly click the button below for more details.
View more details
Don’t recognize this activity? Please reset your password and contact customer support immediate.
This is an automated message, please do not reply.

Ticket Details

• Application Status: Application has been rejected
• Rejection time: 2026-06-18 00:09:39
• Reason for rejection: other
• Application ID: cxf71hhq3iuaujpi14o8
• Submission time: 2026-05-19 17:49:16
• Application amount: 0.00399895 BTC
• Recharge network: BEVM
• Recharge address: 0x0276bebd9f928644348a59170f5c469f81f03f11
• Refund address: 0xc0f9c501c6cad51bf2d0e966c5b93be6fd11399
• Recovery fee: 20 USDT (not deducted)
• TXID/TxHash: 0x973a64e163d31128c70cff04b 5b026521cbbc988012feb5ab3e4d1066a7e9f80
• Official remarks: Dear Binancian, Please contact customer services for further information, thank you.

3. The full set of complete evidence chains still cannot pass the review

I am fully aware that the root cause is negligent in my own operation, but during the entire rights protection cycle, I have sorted, retained, and submitted all the supporting materials, and there is no problem of lack of evidence and vague information:

1. Full screenshot of MetaMask wallet transfer, including transfer time, amount, chain ID, transaction hash, on-chain confirmation status;
2. Bevm old browser error screenshots, newGEB.NetworkThe full transaction page of the domain name browser can clearly display the transfer and delivery address, the number of BTC, and the GAS information;
3. ChainList website Bevm Canary real-time block height screenshot, prove that the bottom layer of the chain continues to produce blocks;
4. GEB’s official social chat records, the project administrator’s official reply to the operating status of the chain, no asset migration plan;
5. MetaMask two sets of network configuration comparison screenshots, updated valid RPC and browser addresses;
6. The whole process customer service communication screenshots, work order circulation records, and platform background independent verification of the block height page;
7. BEVM changed its name to GEB’s official document link to support the fact that the project domain name and brand change are facts.

The facts are clear and can be checked: I switched to the BVM niche testnet by myself, and filled in the BSC recharge address to cause the funds to enter the platform address on the BVM chain; the chain itself has not been abandoned, and it can be queried normally after changing the domain name With the operation, there is no risk of asset locking for the original refund; the whole process is active in confessing its own operation errors, and at the same time, it cooperates with all the process requirements of the platform, prepaid fees, supplements various materials, and actively provides verification channels. The final review is only rejected for vague ‘other’ reasons, without any detailed explanation of technical and evidence levels, and the experience is extremely poor.

The most frustrating things about the whole thing

1. Rules are rigid and lack case flexibility
   The platform uniformly stipulates that the wrong charge assets only support the return of the same chain, and do not consider special scenarios such as niche test network, project name change, and domain name failure. Even if I come up with complete evidence to prove that the network configuration can be collected normally after updating the network configuration, the background has independently verified the data on the chain, and still refuses to deal with special treatment.
2. The reason for refusal is vague, and there is no transparent audit standard
   It took more than a month for manual review, and finally only marked ‘others’, and did not inform the specific refusal card points. The user cannot judge whether it is a chain technology limitation, an internal process problem or other hidden requirements, and there is no direction for supplementary materials and secondary complaints.
3. Customer service can only transmit information, no decision-making authority
   The whole process is connected to a number of manual customer service, and the customer service can only record and forward appeals, and cannot intervene in the conclusion of the refund review department. Many communications have only repeated unified words, and cannot be handled upwards in response to the special circumstances of the niche unpopular chain.
4. Seriously unbalanced time
   From the mistakes of his own operation at the beginning of 2025, to repeatedly following up, collecting evidence, connecting with project parties, and revising the configuration of his wallet, he has invested dozens of hours of energy, which took a year and a half.

5. Final decision: give up completely, stop continuing to defend your rights

I know that the root of the mistake is myself, but after receiving the review feedback, if I reject it, I will contact the customer service again to ask the specific reason and supplement the materials for the second complaint. After comprehensive consideration, choose a stop loss:

1. The volume of assets is not large, and the continuous investment time and energy cost performance are extremely low;
2. The platform review standard is not transparent, even if the work order is submitted again, there is still the possibility of no reason to reject it;
3. BEVM Canary belongs to the niche canary test chain. The exchange has a very low priority for recharging the unpopular network by mistake, and repeated communication will only repeat the same result;
4. There have been complete incident records, and as a lesson from oneself stepping on the pit, no additional cost entanglement will be invested.

6. Summary of a full set of stepping on the pit, giving advice to all traders in the currency circle

Combined with a year and a half of the complete experience, organize some of the most practical experiences to prevent others from repeating the same mistakes:

1. Strictly distinguish the main network and canaries/test network, Chain ID is the only judgment standard
   Multiple chains under the same project are independent of each other, and assets do not communicate with each other. Don’t judge the network only by the project name; double check the Chain ID, RPC, and browser domain names before the transfer. The niche chain is very prone to domain name replacement and node failure. This time it is a typical example, manually cutting the wrong BEVM testnet, and reusing the BSC address directly causes losses.
2. The unpopular niche chain is wrongly charged, and the recovery rate is extremely low
   Exchange asset recovery resources give priority to mainstream public chains (BSC, ETH, TRC20, etc.), such as BVM For all test networks, even if the complete confession is wrong and the evidence is complete, the manual review is very easy to reject, so be careful before the operation.
3. Triple verification before transfer: address, currency, network, indispensable
   The format of the EVM tether address is exactly the same, and it is easy to copy the main network address of the exchange and then switch to other niche chain transfers. Before transferring, confirm that the current Chain ID of the wallet is completely matched with the exchange recharge network, and the small test transfer is preferred.
4. Once the wrong charge, keep a full set of evidence as soon as possible
   Screenshots of wallet transactions, block browser pages, official announcements of the project party, and all screenshots of community communication records are backups;
5. Recovering the psychological expectations of the wrong chain is lowered, and prepare for the loss
   Even if the platform collects the recovery fee and assists in the submission of work orders, it does not mean that the assets can be recovered. Even if you are at fault, it is difficult to recover through complaints.
6. The self-service form is extremely limited, and the unpopular problem can be directly found by manual customer service
   The platform self-recovery form only supports filling in TXID, and special scenarios such as cross-chain and project name change cannot be fully explained.

7. Written at the end

At this point, this Bevm Canary wrong-chain recharge protection story, which has spanned a year and a half, due to negligence in its own operation, has officially come to an end. 0.00399895 BTC completely lost, there is no huge loss, but the tortuous and fuzzy review and processing methods of the whole process really make people feel speechless.

I don’t avoid the root cause of the mistakes caused by switching the network and addressing by myself, but I just actively cooperated with all the requirements of the platform and provided a full set of verifiable evidence.

Write down four complete records, on the one hand, keep your own experience as a warning, and on the other hand, it also gives a complete practical reference for all users who have wrongly charged the wrong chain, especially the niche and unpopular network. The blockchain transfer is irreversible, and there is no 100% guarantee for the wrong recharge of the exchange. The safest way is always to double-check before the transfer, and avoid mistakes from the root cause.

In the future, the work order will not be followed up, and the customer service will no longer be contacted to appeal. This article is the final article of this series and will not update the relevant progress.