Cases where tens or even hundreds of thousands are spent hiring an outsourced team to develop a Web3 project, only for the project to finally go live and then have user assets stolen and the project collapse because the developer planted a technical backdoor, are not uncommon in the industry. Many project owners think that getting the source code means the project has been fully delivered, but they overlook permission and backdoor risks, and in the end the project they worked so hard to build goes to zero overnight. In fact, we do not need to fully understand complex code; by focusing on four core checkpoints, we can avoid most technical risks intentionally left by people.

First, strictly verify smart contract permissions and reclaim administrator, superuser, and contract upgrade permissions. Many development teams, when writing contracts, will default to retaining administrator permissions. Here is a real example: after a certain RWA project went live, the developer held the contract administrator permission and directly called backend functions to transfer users’ staked assets within the contract, leaving the project owner completely unable to intervene. Once contract deployment is complete, the first thing the project owner should do is confirm that all administrator permissions, super-admin permissions, and contract upgrade proxy permissions have been transferred or destroyed. Do not leave the highest contract permissions in the hands of the development team, so as to fundamentally eliminate the possibility that the other party can tamper with rules or transfer assets from behind the scenes.

Second, tightly control all project wallets; the private keys and signing permissions must be fully held by you. Projects typically involve three core wallet types: deployment wallets, funding pool wallets, and multisig management wallets. Many projects cut corners by having the development team hold the wallet private keys directly. There was once a blockchain game: the funding wallet was kept by the development team on behalf of the project; after the project operated for a while, the developers simply ran off with hundreds of thousands of USDT from the pool. The project had no way to seek remedies. No matter how trustworthy they seem, the private keys and signing permissions for the deployment wallet, funding wallet, and multisig wallet must never be handed to the development team. All signing operations must be performed by the project owner themselves—do not delegate asset entry management to the developers.

Third, completely wipe out backend server privileges—keep the highest authority in your own hands. Many DApps and platform backends run on servers provided by the development party. Some outsourcing teams quietly retain server login accounts and database backend entry points. Even if the source code has been delivered, as long as they still have server access, they can still modify front-end pages, tamper with backend data, and steal user-related information. During the project handover stage, be sure to change all top administrator accounts for the servers, backends, and databases. Delete all developer team login accounts, SSH keys, and backend operation permissions. After that, log in yourself to do a second verification and confirm there are no leftover backdoor accounts.

Second, verify the online/on-chain code, compare it with the delivered source code, and bring in a third-party audit to identify potential risks. Here it’s very easy to fall into a trap: the source code the developers deliver to you may not be the same as the code actually running on-chain. Some teams deliver clean source files, but the deployed on-chain version secretly embeds special blacklisted addresses and hidden functions that transfer assets. Looking only at the delivered source code is meaningless—you must check whether the deployed on-chain contract bytecode matches the source code compilation result. Ordinary project owners usually can’t complete this work; it’s recommended to commission a third-party audit firm to compare the code and look for hidden backdoors and special high-risk addresses.

Here’s a reminder to all project owners: project delivery doesn’t mean the job is finished once you get the source code. Source code is only one of the deliverables. The four items—smart contract permissions, various wallet private keys, server backend permissions, and on-chain code consistency—must all be verified and all must be kept and controlled by the project owner. Only then can you truly consider the handover complete.

Many tragedies in the industry aren’t because the contracts themselves have vulnerabilities, but because humans improperly retain permissions, leading to human-made incidents. Many project owners focus on implementing functionality early on, neglecting security checks during handover/closing out. Only after assets are stolen do they regret it too late.

Web3 project assets are at extremely high risk—don’t gamble on trust in the developer team’s professionalism. On the process side, reclaim all permissions and make sure verification work is properly carried out; only then can you prevent the development team from manipulating the project later and keep the project’s asset safety bottom line.