In the article “ Can projects going overseas avoid the jurisdiction of Chinese law? Compliance misunderstandings that Web3 entrepreneurs cannot ignore ”, Lawyer Shao mentioned:

A compliance misunderstanding that Web3 entrepreneurs and practitioners tend to overlook is that as long as the project is registered overseas and the server is deployed overseas, "natural compliance" can be achieved.

But in reality, the core of compliance lies in the business model, capital structure and operation substance of the project itself, rather than the superficial overseas structure. In other words, overseas registration can be a part of compliance, but it cannot be a shield to cover up high-risk business practices. In particular, for teams that still reside in China and provide services to Chinese users, they should pay special attention to the legal boundaries and criminal compliance risks of the project.

This article will further analyze: As a developer, how can you quickly determine whether a Web3 project is a "criminal red line project"? We will take the four types of Web3 illegal risk models that are common in practice as examples to help developers establish basic recognition capabilities from the perspectives of project structure, system functions, token circulation, etc. As long as you can identify and avoid these high-frequency project types in the early stages, you can hopefully stay away from most criminal legal risks.

First of all, it should be stated that this article is aimed at technical practitioners who hope to develop in the Web3 industry for a long time, especially developers who attach importance to project compliance and have a certain awareness of legal risks. Our analysis targets projects with basic compliance awareness and certain business planning capabilities. As for fake projects established for the clear purpose of illegal fundraising, currency fraud, money laundering and arbitrage, they are not included in the scope of analysis of this article.

Author: Lawyer Shao Shiwei

In the previous article " Web3 Developers' Guide to Avoiding Pitfalls (I): Four Types of Criminal High-Risk Project Models that Developers Must Know ", we systematically analyzed the four most common "criminal red line project models". It can be seen that when developers participate in Web3 projects, they are often not "outsiders" of legal risks. Due to their deep involvement in system architecture design, key functional modules, etc., technical positions are often at the core of project operations. Once there are compliance risks in the project model, whether the participation of technical personnel may lead to legal liability will often become the focus of judicial review.

So, as a developer, facing the complicated Web3 projects, how can you judge whether the project itself is a failure? And how can you identify risks in a timely manner and reasonably define your own boundaries without having a complete legal knowledge system? We will elaborate on this in this article.

How to determine whether a Web3 project touches the legal red line?

In this section, we will shift our perspective from legal charges to the developer's identification dimension - helping technical personnel identify key high-risk signals that may exist in the project based on business logic and system structure.

This kind of identification does not require developers to have complete legal knowledge. As long as they master the basic framework of "high-frequency patterns + key judgment points", they can preliminarily judge whether a project touches the legal red line.

Identification Dimension 1: Gambling-related (crime of opening a casino)

Typical features: recharge entrance + random gameplay + cash withdrawal path

If a Web3 project constitutes the crime of opening a casino, its key closed-loop elements usually include:

• Whether there is any top-up behavior, especially deposits through virtual currencies (such as USDT);

• Whether the platform has designed lucky draws, guessing games, unboxing and other random and uncertain gameplay;

• Whether there is a withdrawal path, for example, the project tokens can be exchanged for mainstream currencies and circulated to CEX/DEX, and then converted into RMB.

This three-step process of "recharge - betting - withdrawal" can easily be regarded as a "gambling-related closed loop" by judicial authorities.

Taking Web3 games (GameFi) as an example, when a blockchain game project meets the above three points at the same time , even if the developer is only responsible for modules such as the front-end interface, wallet access, and reward mechanism, he may face higher legal risks due to his deep involvement in the construction of a closed loop involving gambling .

Identification Dimension 2: Pyramid Scheme-related (organizing and leading pyramid scheme activities)

Typical features: user payment + invitation rebate + multi-level rebate chain

The risk of such projects lies in whether the incentive mechanism itself constitutes a "pyramid rebate structure". If the technical developer is responsible for building functions such as the rebate calculation system, the level authority module, and the node income distribution logic, and if he lacks the ability to judge the overall business structure and fails to make a prudent judgment on the "capital flow logic + hierarchical structure design", it is easy to inadvertently assist in the technical construction of a pyramid scheme system.

The following are common characteristics of MLM structures:

• User payment to join : You need to purchase coins, top up, or purchase service packages before you can qualify to participate;

• Referral rebate : Invite others to register or invest, and the referrer can get rewards;

• Multi-level relationship : There is a hierarchical structure, and rebates are distributed in decreasing order of levels;

• Weak product dependence : Project profitability does not rely on actual goods or services, but is driven by headcount expansion and commissions.

In Web3 promotion strategies represented by "Ambassador Program", "Node Incentives" and "Community Partner Mechanism", if the reward model is built around developing personnel and is directly linked to payment behavior and hierarchical structure , special attention should be paid to whether it is suspected of pyramid selling.

If a technical developer is responsible for building the rebate algorithm, hierarchical database, user settlement logic, and is at the core of the project, even if he or she is not directly involved in the promotion, he or she may be identified as an accomplice for "providing key technical support."

Identification Dimension 3: Illegal fund-raising (illegally absorbing public deposits/fund-raising fraud)

Typical features: Raising funds from the public + Promising returns + No financial qualifications

It is relatively easy to identify illegal fundraising projects, and the risk points are mainly concentrated in two aspects:

First, the source of funds is broad and non-specific , that is, funds are raised from the general public; second, profits or returns are promised to attract capital inflows.

In Web3 projects, if "issuing coins", "investing in mining machines", "exchanging points" and "expected returns" are used as the core fundraising methods, they will easily fall into the qualitative scope of illegally absorbing public deposits or fundraising fraud.

Common high-risk patterns include:

• Issuing tokens to the public for financing without the approval of financial regulatory authorities;

• The platform promises "capital preservation and high returns" or sets a fixed return;

• Fake financial management platforms, mining machine leasing, and dividend distribution mechanisms;

• A fund pool is set up to allow users to exchange tokens or points for cashable assets such as USDT within the platform.

In judicial practice, whether it constitutes the crime of "illegally absorbing public deposits" is usually determined comprehensively based on the "four standards": whether it is illegal (no financial qualifications), public (propaganda to unspecified objects), inducement (promise of high returns), and social (wide sources of funds).

In such projects, if developers are deeply involved in the structural design of token issuance logic, points-token exchange modules, financial product systems, etc., even if they do not participate in operations and external publicity, they may be identified as accomplices due to their "key technical support" behavior.

Especially when the system forms a closed-loop capital flow + return expectations , judicial authorities will often include developers in the scope of crackdown.

Identification Dimension 4: Illegal business operations (illegal business operations)

Typical features: coin-to-coin matching + over-the-counter exchange + fiat currency deposit and withdrawal channels

In Web3 projects, typical risk scenarios of "illegal business operation" often focus on the link where virtual currency platforms are suspected of matching the exchange of RMB and foreign currencies. Especially when virtual currency is used as a cross-border intermediary, it may trigger the legal characterization of cross-border exchange-type illegal operations.

Based on the cases of illegal foreign exchange and illegal business operations handled by our team, it can be seen that in recent years, judicial authorities have continued to increase their crackdown on this type of "virtual currency matchmaking foreign exchange" behavior and the law enforcement standards have become stricter.

The following are common high-risk behavior patterns:

• Provide recharge, withdrawal, deposit and withdrawal services between virtual currency and RMB;

• Set up an over-the-counter (OTC) trading module to facilitate the exchange between currencies and legal tender;

• The platform connects C-end users with overseas accounts to complete exchange through currencies such as USDT or BTC;

• Conducting foreign exchange trading business and providing settlement matching services without permission.

In judicial practice, even if the platform itself does not directly hold customer funds, as long as it has built a matching system, exchange matching logic or transaction matching interface , the technical party may be identified as an accomplice for "organizing and implementing illegal business activities."

Developers should be especially vigilant in the following three typical scenarios:

• The project connects overseas users with domestic funders , forming a counter-trading path;

• The platform uses USDT, BTC, ETH and other currencies as exchange media to realize RMB exchange for foreign currencies or reverse exchange;

• Technical personnel led the development of functional modules such as deposit and withdrawal modules, automatic matching programs, and key API interfaces.

Regardless of whether the developer directly participates in the settlement, as long as the system has the capabilities of "matching + exchange + multi-currency conversion" , it is easy to fall into the category of illegal business crime.

How to accurately identify high-risk Web3 projects and stay away from criminal legal risks?

Many developers often put forward the defense after the incident: "I just developed the function according to the demand, I don't understand the specific gameplay."

However, in judicial practice, this argument is often difficult to establish. The reason is that whether criminal liability is constituted depends not only on whether the person directly participates in illegal acts, but also on whether the person "knows" that the system he developed is providing substantial assistance to illegal acts.

According to the theory of complicity in China's criminal law, as long as the perpetrator is aware that others are committing a crime and still provides technology, assistance, and convenient conditions , he may be identified as an aider or accomplice and bear criminal responsibility according to law.

For technical personnel, judicial authorities usually judge whether they " should have known " that the project has illegal risks from the following perspectives:

• Whether he is a core member of the project, such as technical partner, CTO, system architect, etc.;

• Whether they are deeply involved in key modules such as capital structure, token logic, deposit and withdrawal channels, etc.

• Whether there have been any questions or suggestions for changes regarding the legality of the project, the flow of funds, the compliance of gameplay, etc.;

• Whether they receive high remuneration, sign in-depth cooperation agreements, enjoy dividend ratios, etc., indicates that they have deep interest ties with the platform.

In Web3 projects, technical developers are often not marginal auxiliary roles, but key links in promoting the implementation and operation of projects.

The more key roles the technical personnel play, such as CTO, system architect, core developer, etc., the more difficult it is for them to claim "I was not aware" or "I just outsourced" - these technical backbones are often regarded by judicial authorities as people who have actual control over the operation of the project.

So, as a developer, how can you identify risk signals and clarify the boundaries of responsibility at the beginning of a project to avoid being blamed? The following are some of the recommendations that technical personnel must check before joining the company or taking on a collaboration.

Before developers participate in any Web3 project, they must have a basic legal risk identification framework. Whether considering joining, outsourcing cooperation, or participating in project launch as a partner, the following three steps of self-examination are particularly critical:

• Look at the model : Are there four high-frequency criminal risk structures such as "gambling (gambling gameplay)", "MLM (hierarchical recruitment)", "illegal fund-raising (issuing coins to attract funds)" or "illegal operation (currency matching)"?

• Question logic : Does the project have tokens issued? Where do the tokens/points come from? How do user funds enter the platform? How do funds exit? Who redeems the tokens? Is there a legal currency exchange path?

• Keep records : In the technical agreement and requirements specification, clearly state that you only provide development services and do not assume responsibility for platform operations. At the same time, record discussions with the project party on "game compliance" and "funding path" as evidence for later self-insurance.

Conclusion: Be a developer who understands both technology and law

Whether it is the core developer of the project, the system architect, or the technical leader of the entrepreneurial team, they should all have basic criminal legal risk identification capabilities. Especially in the initial stage of the Web3 project, it is necessary to determine as early as possible whether it involves high-risk models such as gambling, religious cults, illegal fundraising or illegal operations, and to issue early warnings and take proactive measures to prevent being caught in the vortex of criminal responsibility due to negligence.

In the complex and ever-changing Web3 ecosystem, only developers who have both the ability to implement technology and the ability to identify legal red lines can become builders with real judgment and survival capabilities.

Beyond technology, "legal compliance awareness" is the indispensable hard power for contemporary developers.

The development of the Web3 industry is inseparable from compliance construction, and developers are the most easily overlooked but most core link. We hope to work with more technical peers in the future to jointly promote the implementation of the project on a safe and transparent basis. If you also have thoughts on project structure, system compliance and criminal liability boundaries, welcome to communicate.

This article is an original article written by lawyer Shao Shiwei and only represents the personal views of the author and does not constitute legal advice or legal opinion on specific matters.