Previously, Mankun Law Firm received a consultation of this kind: a technical staff member at a digital-asset-related company was primarily responsible for the development and maintenance of the platform's back-end systems. Later, because some of the platform's partner merchants were suspected of using information networks to commit crimes, this technical staff member was also taken away for investigation.
Faced with the investigation, the client was deeply confused:"I was only responsible for writing code and maintaining the system. I neither directly handled customer funds nor participated in business profit sharing, so why would I be involved in criminal liability?"
Such questions are not uncommon in the Web3 industry. Compared with traditional internet companies, cross-border operations and remote collaboration models are more common in Web3 projects. A company may be registered in Singapore, its management team located in Dubai, and its technical staff working in China on a long-term basis, receiving requirements and submitting code through tools such as Telegram and GitHub in their daily work. For many developers, the work consists of completing development, testing and maintenance in accordance with product requirements documents (PRDs); how the platform acquires customers, what business its partner merchants operate, and where the funds ultimately flow may not necessarily fall within the scope of their daily responsibilities.
However, once the platform or its partners are suspected of a crime, the development, maintenance and other technical support provided by technical staff may come within the investigative scope of the judicial authorities. At this point,can "not touching the money, not sharing in profits, only writing code" serve as a ground for exemption from liability? If the technical functions developed are ultimately used for a crime, should the programmer bear criminal liability?
Neither of these questions can be answered simply with "technological neutrality" or "technology assisting a crime." On the one hand, technological outputs have broad legitimate application scenarios, and a developer cannot be deemed to have committed a crime merely because the code is ultimately used for illegal or criminal activities; on the other hand, if technical staff clearly know that the relevant business is suspected of a crime and still continuously provide targeted technical support, they cannot be excluded from criminal liability merely on the ground that they hold a technical position.
Code itself does not directly determine criminal liability. What truly needs to be assessed is what the developer actually participated in, what the developer knew, and what connection exists between the relevant technical support and the specific criminal activity.
I. "The project has problems" and "the programmer is guilty" are two judgments that must be kept separate
Suppose a Web3 platform is ultimately found to be suspected of fraud, illegal business operations, running a casino or other crimes. The fact that a programmer participated in developing this platform can, at the outset, only prove that the programmer had a working connection to the project; it cannot directly establish that the programmer bears criminal liability.
Joint crime under the Criminal Law requires joint intent, and the crime of assisting information network criminal activities likewise requires that the actor "know that others are using information networks to commit crimes" and actually provide corresponding technical support or assistance. Therefore, whether the conduct is ultimately assessed as joint crime or as the crime of assisting information network criminal activities, the actor's subjective knowledge cannot be bypassed. The latest 2025 opinions of the Supreme People's Court, the Supreme People's Procuratorate and the Ministry of Public Security once again emphasized that, in handling cases of assisting information network criminal activities, the three levels of knowledge, assisting conduct and serious circumstances must be accurately grasped, and that mechanical conviction based solely on the fact that a particular objective indicator meets the threshold is opposed. (Gazette website)
Therefore, if a developer joined the project against a relatively normal commercial background, was responsible for general functions, lacked actual knowledge of the platform's subsequent illegal operations, and moreover did not continue to provide targeted assistance after clear anomalies emerged, then the fact that "the code was ultimately used by the project" is in itself insufficient to automatically complete criminal attribution.
The genuinely complex situation is when a programmer's work gradually moves from general technical development into the core of a specific business.
II. Ordinary technical functions and "custom development for exceptional requirements" do not carry the same probative significance
Many Web3 products involve wallets, deposits and withdrawals, order matching, cross-chain functions, address management, API interfaces and user permissions. These functions themselves have a large number of legitimate use scenarios; the mere presence of wallet sweeping, privacy features or cross-chain modules does not mean the code should be directly interpreted as a criminal tool.
What requires further examination is why the function was proposed, and what background information the developers possessed when implementing the requirement.
Even where it is a programmer writing code in both cases, the nature may be entirely different. It is not enough to look only at whether the person "developed a system"; it is also necessary to examine whether the person knew what he was helping with, and whether the function produced was specifically designed to exploit loopholes, evade regulation or conceal illegality.
For example:
1. Developing a normal KYC real-name verification module is not the same as, at the product manager's request, specifically building it so that "users in mainland China can continue trading without completing real-name verification." The latter is clearly circumventing regulation.
2. Developing a normal wallet sweeping system is not the same as specifically building it to enable bulk concealment of the source of funds, evasion of platform blacklists and automatic replacement of high-risk receiving addresses. The latter is helping people evade risk controls and conceal the origin of funds.
3. Developing a normal account management tool is not the same as, after having received a large number of complaints involving criminal matters, continuing to build functions for bulk registration, circumvention of bans and evasion of investigation. The latter is continuing to provide technical assistance while knowing that criminal conduct may be involved.
Therefore, from the perspective of evidence and legal accountability, normal development of tools and knowingly developing functions that "circumvent regulation, evade investigation and conceal illegality" carry different degrees of responsibility.
The 2019 judicial interpretation on the crime of assisting information network criminal activities clearly provides that where a person provides technical support or assistance for another person's commission of a crime, circumstances such as providing programs or tools specifically used for illegal or criminal activities, providing technical support for another person to evade regulation or circumvent investigation, or obviously abnormal transaction methods may serve as important facts for determining that the actor "knew," while at the same time permitting the actor to present contrary evidence; the 2025 new Opinions further require a comprehensive assessment taking into account factors such as occupational identity, the manner and number of times assistance was provided, the tools, illegal gains and evasion of investigation. (Gazette website)
This means that what technical personnel truly need to pay attention to is not "whether a certain piece of code looks dangerous," but ratherwhether the background of the requirements, the purpose of the functions, and the developer's knowledge gradually formed a complete chain of evidence.
III. The point at which programmers are truly at risk is often not the first time they write code, but the later stage of "continuing to do it after knowing"
When many technical personnel join a project, they genuinely do not understand the entire business.
A backend engineer may receive only the requirements for the account system, a wallet developer sees the address generation and signing modules, and a DevOps engineer is responsible for server deployment; based on these initial tasks alone, it is difficult to require every engineer to judge in advance, like a lawyer, whether the platform may be involved in crime in the future.
However, as the project operates, information will continuously reach the technical team: operations feedback that a large number of users are requesting account freezes due to fraud complaints, risk management warnings that certain merchants continue to show abnormal funds, product managers requesting that certain risk identification rules be disabled, the boss explicitly stating that in order to continue serving a certain category of restricted users the region identification logic needs to be modified, and even requirements documents beginning to directly contain content such as "evade," "circumvent," and "anti-tracking."
At this stage, the point in time at which the case is assessed will change.
Judicial authorities may further examine when the technical personnel began to know of the abnormalities, whether they raised objections after learning of them, which functions they subsequently continued to develop, whether those functions were specifically directed at the problems already exposed, and whether the technical personnel obtained additional bonuses, Tokens, or business profit shares as a result; if these facts can correspond to one another, then "knowledge" in the case is often not proven through a single statement, but is reconstructed through a continuously changing work process.
Therefore, for technical personnel,not knowing at the time of joining and still not knowing half a year after the project has been running are not inherently the same factual state.
IV. Receiving only a salary and no profit share affects the assessment, but is not an absolute boundary
Another explanation commonly given by programmers is: "I did not participate in profit sharing; I only receive a fixed salary."
A fixed salary is of course a fact worthy of examination, because it may show that the technical personnel's income is not directly linked to the scale of the illegal business, and that there is a clear distinction between them and core participants who share profits based on fund flows, user losses, recharge amounts, or transaction volumes; however, the manner of income can only explain their interest relationship in the project, and cannot by itself answer whether they knew and provided assistance.
Conversely, a high salary is not evidence of a crime either.
The Web3 industry itself is characterized by a scarcity of technical talent, global recruitment and crypto asset remuneration; therefore, a monthly salary of RMB 50,000 or RMB 80,000, or even higher, or the use of USDT to pay remuneration, cannot by itself directly prove that a programmer knew the project was unlawful. What is genuinely probative is whether the remuneration is clearly tied to the performance of a particular high-risk business line, or whether the project separately pays remuneration far exceeding normal development fees when requiring an employee to undertake abnormal technical tasks.
This is also a form of simplistic reasoning that must be avoided in criminal cases: one cannot conclude that a person is merely an ordinary employee simply because they "draw a salary," nor can one infer subjective knowledge in the reverse direction simply because the "salary is high."
V. The crime of assisting information network criminal activities and complicity in an upstream crime are not the same level of liability
Even if it can already be proven that the programmer knew criminal activity existed on the platform, it is still necessary to continue distinguishing the crime under which the conduct is ultimately assessed.
The 2025 Opinions of the "Two Supreme Courts and One Ministry" expressly require distinguishing the crime of assisting information network criminal activities from complicity in a related crime. If the actor had prior collusion with the upstream criminal actors or formed a relatively stable cooperative relationship with them, the conduct may be assessed as joint commission of the upstream crime. By comparison, the knowledge element in the crime of assisting information network criminal activities is usually more general: the actor knows that they are providing assistance to information network criminal activities, but does not necessarily have an in-depth grasp of how the specific crime is carried out.
Applied to the Web3 programmer scenario, an outsourced developer who knows that a client's business has obvious unlawful anomalies yet continues to provide certain technical support, as compared with a technical lead who participates in business model discussions from the outset of project design, understands the specific criminal process, continuously customizes systems in accordance with that process, and forms stable collaboration with the operations and funds teams, may plainly differ in subjective awareness and depth of participation.
Therefore, a case cannot stop at the level of "he provided technical support, so he is suspected of assisting information network criminal activities"; it must continue to examine what relationship was actually formed between the technical personnel and the core business.
VI. What should truly be preserved is not "self-protection screenshots," but a normal chain of work evidence
One feature of remote work on Web3 projects is that many employees have no formal employee badge, office or complete OA system, and work tasks are scattered across Telegram groups, Slack channels, GitHub Issues, Notion and online meetings. Once a project runs into trouble, a problem instead readily arises: it is difficult even for the employees themselves to fully explain why a certain function was developed, who raised the requirement, whether they themselves raised any risk concerns, and who ultimately decided to launch the final version.
Therefore, for technical personnel, normal work records are themselves of significant importance.
A contract or technical service agreement can explain the scope of work; product requirements and Issue records can explain where a function originated; code commit records can reconstruct who modified what; compliance or risk management communications can prove what attitude the employee took when faced with abnormal requirements; and payroll records can further explain the income structure. These materials are first and foremost part of normal project management, and after a dispute arises in a project, they can also help distinguish individual responsibility from the conduct of the entire team.
It must be particularly noted that the so-called leaving of a trail does not mean taking screenshots on an ad hoc basis after a project is under investigation, deleting unfavorable chat records, or assembling a new set of explanatory materials; on the contrary, proactively deleting chats, cleaning up code repositories, or transferring data may instead cause the loss of an originally favorable work background and affect the case-handling authorities' assessment of subsequent conduct.
Lawyer Observation
The biggest legal misconception among Web3 programmers is not believing in the four words "technological neutrality" themselves, but understanding them to mean that as long as they have not directly received money and have not faced users, they may pay no attention at all to the business that the code ultimately serves.
Technology is of course neutral, and a large number of wallets, privacy, cross-chain, payment, and matching tools simultaneously have lawful and normal use scenarios; criminal law also cannot, merely because a technology may be exploited for crime, extend developer liability indefinitely forward. However, when a technical person has already understood the project's true business through requirements, user feedback, risk-control information, or internal communications, and on that basis continues to provide targeted key technical support, that person's conduct must be re-evaluated according to the specific charge.
The latest 2026 virtual currency regulatory rules likewise make clear that, for domestic entities and individuals that, while knowing or being ought to know that an overseas entity is unlawfully providing virtual-currency-related services to the territory, still provide assistance to it, relevant liability shall be pursued in accordance with law, and criminal liability shall be pursued in accordance with law only where a crime is constituted. Therefore, "violating regulatory provisions," "bearing relevant liability," and "already constituting a criminal offense" still cannot be directly equated.
Whether code is neutral is a technical question; whether a programmer bears criminal liability ultimately remains a question of evidence.
