Introduction
Our team undertook blockchain wallet development work for a Web3 project party. The parties signed a formal commissioned development contract. At the time the source code was delivered, a version marker was embedded in the delivery package by technical means, and the contract expressly set out the scope of delivery and provided that the project party would thereafter maintain the code itself.
The client wishes to confirm whether the technology provider may still bear legal liability if the project party modifies that version on its own and uses it for illegal or criminal activities.
This question can in fact be broken down into two levels:
First, whether the technology provider's conduct falls within the scope of criminal law assessment;
Second, the extent to which the prior contractual arrangements and the version marker can block or mitigate this risk.
We will break this down point by point today.
I. Criminal law assesses not the single point of [delivery], but a course of conduct
The case-handling authorities' review of the technology provider typically covers three points in time:
(1) The contracting and requirements review stage
Whether the functional requirements proposed by the commissioning party point to a specific illegal use.
For example, where there is an express request for no KYC, built-in coin-mixing functionality (mixing funds from different sources to sever on-chain tracing), or batch generation of fund-collection addresses, such functions themselves have a clear directional use.
(2) Delivery stage
Whether the deliverable itself is a general-purpose development output or a tool specifically intended for illegal or criminal activity.
(3) After delivery
Settlement of the final payment does not mean the legal relationship has ended.
Whether the project party sought technical support from you when modifying the code, whether you continued to operate and maintain the wallet after launch, and whether the project party proposed that you be paid a technical consulting fee based on transaction volume, and whether you accepted and performed such work, are all independent subjects of factual assessment.
Whether the technical party bears criminal liability does not depend on what crime the project party subsequently committed, but on the technical party's conduct and knowledge at these three points in time.
II. Offenses the technical party may be involved in
Under this framework, the offenses the technical party may commit are not limited to a single one:
(1) The crime of assisting information network criminal activities [the crime of assisting information network criminal activities]
The Criminal Law provides that whoever, while knowing that another person is using an information network to commit a crime, provides technical support for that crime, where the circumstances are serious, shall be sentenced to fixed-term imprisonment of not more than three years or criminal detention.
Under Article 12 of the Interpretation on Several Issues Concerning the Application of Law in the Handling of Criminal Cases Involving Illegal Use of Information Networks and Assisting Information Network Criminal Activities (Fa Shi [2019] No. 15), providing assistance to three or more targets, illegal gains of RMB 10,000 or more, and other such circumstances all constitute "serious circumstances."
This is the offense most easily triggered in technical outsourcing scenarios, and the threshold for criminal liability is lower than most people intuitively expect.
(2) The crime of providing programs or tools for intruding into or illegally controlling computer information systems
Article 285, paragraph 3 of the Criminal Law evaluates the act of [providing tools] itself:
Whoever provides programs or tools specially used for intruding into or illegally controlling computer information systems, or knowingly provides such programs or tools to others who are committing such illegal or criminal acts, where the circumstances are serious, commits this crime; where the circumstances are especially serious, the offender is sentenced to fixed-term imprisonment of not less than three years but not more than seven years.
(3) Joint crime in upstream offenses
The Criminal Law provides that a joint crime is a crime committed intentionally by two or more persons jointly.
Where the technical party knows that the project party is committing crimes such as fraud, pyramid selling, or illegal absorption of public deposits and still continuously provides technical support, especially where it participates in profit sharing, it departs from the minor-offense evaluation of the crime of assisting information network criminal activities and directly enters the system of accomplices to upstream offenses.
The sentencing ranges for offenses such as fraud and fund-raising fraud are entirely on a different scale from those for the crime of assisting information network criminal activities.
(4) Connecting provisions on crypto-related regulation
Unlike the three preceding criminal-law offenses, this item is a regulatory connecting provision specific to crypto-related business: Article 18 of the Notice on Further Preventing and Handling Risks Related to Virtual Currencies and Other Matters (Yin Fa [2026] No. 42), issued in February 2026 by the People's Bank of China and seven other departments, establishes two tiers of liability: 1. Those who provide services for business related to virtual currencies or tokenization of real-world assets (RWA) shall be punished in accordance with relevant provisions, and where a crime is constituted, criminal liability shall be pursued in accordance with law. This tier does not limit whether the service recipient is domestic or overseas, and [technical development] itself may fall within the scope of [providing services]; 2. Domestic entities and individuals that knowingly or should have known that an overseas entity is illegally providing virtual currency-related services to the domestic territory and still provide assistance to it shall have relevant liability pursued in accordance with law, and where a crime is constituted, criminal liability shall be pursued in accordance with law. Web3 projects mostly have overseas structures with technical teams located domestically; the project party being overseas does not constitute a risk-isolation barrier for the domestic technical party.
Even if a favorable result is obtained at the criminal level, administrative liability is not necessarily exempted in tandem.Article 38 of the Anti-Telecom and Online Fraud Law provides that those who provide assistance to telecom and online fraud activities and whose acts do not yet constitute a crime may still be subject to detention, confiscation of illegal gains, and fines.
III. [Technological neutrality] cannot preclude the constitution of criminal elements
There is a saying in the tech community: technology is not guilty. In other words, those who write code have no control over those who use it.
But in criminal law this saying is only half right. Criminal law theory does contain exculpatory discussion of [neutral assistance conduct]: ordinary conduct that has a normal business character and conforms to professional appropriateness is not automatically attributed as liability merely because another person abuses it.
However, the Supreme People's Procuratorate has also made a clear statement on this: technological neutrality is not a ground for exculpating conduct. The object of criminal law evaluation is not whether the code itself is neutral, but whether the conduct provided substantive assistance to another person's crime, and whether the actor subjectively knew.
The real distinguishing criterion lies in the use of the tool.
Where general-purpose software with legitimate uses is used by another person to commit a crime, the developer's knowledge cannot be inferred backwards merely from the result of abuse; where a tool is specifically used for illegal or criminal activity and has no legitimate application scenario, its creation and provision may in themselves give rise to a presumption of knowledge, because you cannot give a reason for its lawful existence.
The same reasoning applies to the assessment of blockchain wallet development: a general-purpose wallet framework falls within the former; whereas customized outputs with built-in functions such as KYC exemption, coin mixing, on-chain tracking prevention, and bypassing regulatory interfaces may fall directly within the latter.
IV. Conduct after delivery is the true watershed
Even if the deliverable itself withstands scrutiny as to its use, the issue is not thereby concluded. The contract, version markers, and delivery list fix only the single point in time of [delivery], and can answer only half of the question.
If the requirements at the time of contracting were legitimate, the deliverable was a general-purpose wallet, the parties completely severed ties after delivery, and the technology provider knew nothing of the project party's subsequent conduct, then the assistance conduct ended there; the project party's independent modification and use constitute an independent intervening factor, the causal chain is thereby broken, and criminal attribution is difficult to establish.
However, whether an intervening factor can break the causal relationship is a matter of discussion in academia and practice, and not all case-handling personnel apply the same standard. What truly matters is whether the technology provider's conduct did in fact stop there.
If, after delivery, the following actions occur, the nature gradually deteriorates: providing targeted technical support for the project party's modification requirements; continuing operations and maintenance after the wallet goes live while turning a blind eye to the illegal fund flows on it; and, most seriously, participating in profit sharing based on transaction volume or user numbers, since profit sharing itself indicates that the actor profited from criminal proceeds and, in the assessment of the case-handling authorities, comes close to conclusive evidence of joint crime, greatly narrowing the room for defense.
The true precondition for [delivery means exemption from liability] to hold is that the technology provider did in fact withdraw after delivery.
V. Determining Subjective [Knowledge]: Seven Presumptions and Rebuttal Evidence
[Lack of knowledge] does not depend on the parties' statements. Article 11 of the aforementioned judicial interpretation sets out seven circumstances under which knowledge may be presumed, four of which correspond closely to technology outsourcing scenarios:
1. The transaction price or transaction method is obviously abnormal—for example, where a client commissioning the development of an ordinary-function wallet application quotes a price significantly above market, insists on settlement in USDT, and refuses to use a corporate account.
2. Providing programs or tools specifically used for illegal or criminal activity—that is, the purpose-related issue discussed above.
3. Providing technical support or assistance for others to evade regulation or circumvent investigation—for example, where the client asks you to "build a function that can bypass [controls]" and you do so.
4. Continuing to carry out the relevant conduct after being notified by a regulatory authority—having already been reminded or warned, yet continuing.
In addition, several categories of evidence appear with very high frequency in practice: explicit functional descriptions in requirement documents and chat records—[no KYC to be retained], [funds must be capable of being rapidly dispersed]—such wording is direct evidence of awareness of the purpose; and failing to sign a contract, keeping no minutes, requesting deletion of communication records, and using encrypted communications that self-destruct after reading throughout—such circumvention actions themselves will in turn become material for presuming knowledge.
Of course, a presumption may also be rebutted, but rebuttal depends not on statements but on retained evidence: normal market quotations, corporate settlement records, complete requirement review minutes, and written records of refusing out-of-scope functions.
Establishing [genuine lack of knowledge] requires evidentiary support.
VI. Breaking Down the Second Layer: The Significance of Commissioned Development Contracts and Version Marking
(1) The [Three Can Dos] and [Three Cannot Dos] of a Contract
The three functions a contract can perform:
1. Fix the boundaries of conduct: a written statement clearly specifying the content to be delivered and the functions excluded is the best written proof that [our conduct stops here];
2. Fix the delivery point in time and the version, which together with the code hash value (understandable as the code's fingerprint, which changes if any character changes) constitute a [delivery snapshot];
3. Corroborate the subjective state: the legality commitments and exclusion clauses in the contract all serve to reconstruct the fact that [there was no knowledge at the time of signing].
However, a contract also has three limitations:
1. Criminal liability is personal and non-transferable and is not shifted by agreement; where one provides technical support while knowing that the other party is committing wrongdoing, even the most complete exemption clause cannot preclude it;
2. A contract cannot bind conduct after delivery; each subsequent response is a new fact;
3. Agreement and performance are two different matters; where the contract states that one does not participate in operations and maintenance but in practice one has long answered questions in the maintenance group, the case-handling authorities will rely on actual performance.
(II) Version marking must distinguish two approaches with completely opposite legal significance:
Locking the hash value and version number on the delivery package and having both parties sign to acknowledge them is evidence preservation in the nature of a timestamp; combined with the integrity verification rules in electronic data forensics, it can prove that [the version at issue running on-chain is not the version we delivered]. This approach is advisable.
By contrast, embedding identity watermarks in the finished code so that law enforcement authorities can trace [this was developed by our team] must be handled with caution; embedding them too deeply may be assessed as covert traces or even a backdoor, and the more practical problem is that this amounts to voluntarily handing the investigating authorities a lead that traces back to oneself.
The legitimate function of marking is limited to proving version attribution, not declaring attribution.
VII. Key compliance points for the technical party
Complete customer due diligence before delivery; the project background and the sources of the funding parties should be clearly ascertainable; quotations and settlement methods should remain normal; and the corporate account and market pricing are themselves a buffer.
At the time of delivery, the more detailed the scope is written, the better, in particular expressly stating [which functions are not included], and retaining the hash value on file;
After delivery, keep control and do not become deeply involved in subsequent operations and maintenance; refuse suspicious requests in writing and keep a record; never take a share of transaction volume, because that is a share of profits, not a service fee.
For the technology party, the truly effective protection is never the contract terms themselves, but the combination of conduct compliance and evidence preservation, so that every trace in the code, the contract and the records can testify on its own behalf when necessary.
