The Achilles' Heel of Open Source: Nofx with 9,000 Stars in 2 Months and Its Hacking Gate, Infighting Gate, Open Source Gate
From rapid rise to falling into a triple crisis, the story of Nofx is a microcosm of the Web3 open-source movement.Author: WquGuru
Writing Background
Before formally unfolding this story, I need to clarify my position in this event.
I am an observer and analyst. During the peak popularity of the Nofx project, I developed the nof0 project—both inspired by nof1. During the development process, I communicated with core members of Nofx, Tinkle and Zack, mainly focusing on technical implementation and open-source collaboration.
It is important to clarify that: my interaction with the Nofx team was purely technical, with no commercial cooperation; I had no direct contact with the ChainOpera AI (COAI) team. While writing this article, I strive to maintain an objective and neutral stance, with all analyses and judgments based on publicly available information, including GitHub records, social media statements, security reports, etc.
Timeline of Events:
Late October 2025: The Nofx project launched, gaining nearly 9,000 stars on GitHub in just two months.
November 2025: Security vulnerabilities were exposed, and SlowMist issued a security warning (Hacker Gate).
December 2025: A dispute over the open-source license erupted (Open Source Gate), and internal team divisions surfaced (Infighting Gate).
The entire event lasted about two months, revealing multiple contradictions within the Web3 open-source movement.
The purpose of writing this article is not to take sides or blame any party, but to hope for:
A complete record of this typical case in the Web3 open-source movement.
An exploration of the deep conflicts between the spirit of open source and commercial interests.
Reflection and reference for the future regulatory construction of the industry.
Now, let’s start from the beginning to untangle this complex story.
Prologue: The Rise of an AI Trading Project
At the end of October 2025, an AI automated trading project named Nof1 exploded on Twitter. Within just a few days, its multiple open-source versions—including nof0, nofx, etc.—gained thousands of stars on GitHub. Among them, the Nofx project started development at the end of October and had accumulated over 9,000 stars by December, becoming one of the most watched open-source projects in the AI Trading field.
However, just two months later, this star project fell into a triple crisis:
Hacker Gate: The blockchain security company SlowMist disclosed that Nofx had serious security vulnerabilities, exposing the API keys, private keys, and wallet addresses of users from over 1,000 deployed instances across the network. Major exchanges like Binance and OKX urgently intervened to assist affected users in replacing their credentials.
Infighting Gate: Core project member Tinkle publicly accused another co-founder, Zack, of "only participating for 14 days and contributing a few lines of code" while demanding 50% equity and $500,000. Zack, in turn, issued a formal legal document through his lawyer, accusing Tinkle of "embezzling assets and transferring benefits," providing partnership registration documents showing both held 50% equity.
Open Source Gate: Nofx publicly accused the $17 million-funded ChainOpera AI (COAI) of violating the AGPL open-source license by using its code to deploy commercial products without open-sourcing it. COAI countered that Nofx was still under the MIT license on November 3 and only switched to AGPL on November 4, and that their product was developed in Python, which was completely different from Nofx's Go implementation.
Why did a community-favored open-source project fall into such a complex triple crisis in just two months? What systemic issues within the open-source community, entrepreneurial teams, and investment ecology were exposed behind this? Let’s delve into this storm through five key questions.
Question 1: Was the Open Source License Really Violated?
MIT vs. AGPL: Two Completely Different Open Source Philosophies
Before discussing the licensing dispute between Nofx and COAI, we need to understand the fundamental differences between the two open-source licenses:
The MIT License is one of the most permissive open-source licenses. It allows:
Free use, modification, and distribution of the code.
Commercial use without the need to open source.
The only requirement: retain the original author's copyright notice.
AGPL v3.0 (GNU Affero General Public License) is one of the strictest open-source licenses. It requires:
Any project using the code must also be open source.
Specifically, even if providing services over the network (such as SaaS), the source code must be made public.
The original project information must be prominently displayed.
The shift from MIT to AGPL represents a 180-degree turn from "extremely permissive" to "extremely strict." This is also the core of this dispute.
License Change and Timing Dispute
The open-source license of the Nofx project changed from MIT to AGPL, but the specific timing of the change became a focal point of contention. This timing is crucial as it directly determines the protocol that the ChainOpera (COAI) team should adhere to when forking the code.
Comparison of Evidence from Both Sides:
The Nofx team provided GitHub commit records showing the modification time of the license file.
The COAI team pointed out that, according to their records and observations, the public timing of the license change is questionable.
ChainOpera's "Plagiarism" Accusation
The Nofx community discovered that the $17 million-funded ChainOpera (COAI) project, which was launched on Binance Alpha, had code that was highly similar to Nofx.
Accusations from Nofx:
COAI used Nofx's code without attribution and without making the source code public.
According to the AGPL license in effect at the time, COAI should have: clearly indicated the source of the code, made the modified source code public, and also adopted the AGPL license.
COAI's Response:
Claimed that when they forked the code, Nofx was still under the MIT license.
The MIT license allows commercial use without the need to make the source code public.
The dispute over the timing of the license change affected the nature of the entire event.
Open Source License Dispute: Who is Right and Who is Wrong?
This dispute exposes deep-seated issues within the Web3 open-source ecosystem:
Validity of License Change:
Retroactive Effect Dispute: Does the change in the open-source license bind the already forked code?
Timing Determination: The exact timing of the license change is difficult to ascertain, with both sides holding differing views.
Credibility of Evidence: GitHub records may be modified, requiring more authoritative third-party verification.
Communication of License Change: How effectively was the change from MIT to AGPL communicated to the community?
Conflict of Commercial Interests:
COAI secured significant funding and launched on Binance, representing substantial commercial value.
Nofx, as an open-source project, lacks a clear commercialization path.
Core contradiction: the challenge of balancing the spirit of open-source sharing with the protection of commercial interests.
Divergence of Community Opinions:
Supporters of Nofx argue that COAI profited from open-source code without giving back to the community.
Supporters of COAI argue that the MIT license inherently allows commercial use, and the timing of the license change is questionable.
Neutral observers point out that the timing dispute is key and that more reliable evidence is needed for judgment.
Legal and Technical Gray Areas:
The legal effectiveness of open-source licenses in blockchain projects remains unclear.
The alterability of GitHub records undermines their credibility as evidence.
The Web3 industry lacks a mature mechanism for resolving open-source disputes.
Summary: A Controversial Accusation
From the currently available evidence, Nofx's accusations of COAI violating the open-source license contain several doubts:
Questionable Timing: GitHub evidence shows the license changed to AGPL only on November 4.
Different Technical Implementations: Identical interface names do not imply identical code.
Reasonable Log Explanation: The statistical function inserted during the MIT phase would continue to log.
Self-Incrimination: Failing to inform users of the embedded statistics may violate privacy laws.
Hasty Communication Procedures: Sending emails and making public accusations within the same minute.
It is noteworthy that the dispute over the timing of the license change has a decisive impact on the nature of the entire event. If Nofx's claims are validated, COAI indeed has issues violating the AGPL license; however, if COAI's claims are validated, their actions fully comply with the MIT license provisions. The determination of this timing still requires more authoritative third-party verification.
Question 2: Is 14 Days Worth 50% Equity?
If the Open Source Gate represents Nofx's dispute with the outside world, then the Infighting Gate is the publicization of internal contradictions within the project—a battle over "contribution" and "value" among the founding team.
Timeline: From Joining to Confrontation
October 28, 2025: Nofx begins development;
October 29, 2025: Zack joins the project (the project had just been open-sourced for one day);
Early November 2025: Zack demands 50% equity, claiming he can introduce Amber Group to participate in commercialization;
Early November 2025: Tinkle refuses to grant 50% equity, believing he is the CEO and CTO of the team and that Zack's contributions are insufficient;
November 19, 2025: Zack's lawyer (from JunHe Law Firm's Hong Kong office) issues a formal "Without Prejudice Save as to Costs" offer, demanding $500,000 to buy back Zack's 50% equity;
December 2025: The conflict becomes public, with both sides accusing each other on social media.
From a timing perspective, Zack's transition from joining to sending a lawyer's letter took less than a month, which is indeed very short.
Confrontation: Two Completely Different Pieces of Evidence
Tinkle's Narrative:
Zack only participated for 14 days.
Contributed a few lines of code ("verifiable").
Joined after the project was already open-sourced and had thousands of TG group members.
Used the introduction of Amber investment as leverage to demand a large equity stake.
After being refused, he seized the project's Twitter account.
Demanded $500,000 through a lawyer's letter, suspected of extortion.
Zack was once an intern at Amber but left before being converted to a full-time position.
Ultimately failed to bring in Amber investment.
Zack's Counterattack:
Provided company registration documents for APEIRON LABS PTE. LTD.
The documents show that Tinkle and Zack each hold 50% equity.
This is public information from Singapore's company registration system, verifiable by anyone.
The lawyer's letter is a standard "Without Prejudice Save as to Costs" document, compliant with commercial legal procedures.
The main body is a Demand Letter, detailing Tinkle's "embezzlement of assets and benefit transfer" actions.
The $500,000 is not extortion but a legitimate buyback of Zack's undervalued rights.
Questions: If the company has value, isn't it reasonable to buy back 50% equity at a $1 million valuation? If it has no value, why does Tinkle call it "extortion"?
Core Contradiction: How to Quantify Contribution?
The essence of this dispute is an age-old entrepreneurial dilemma: technical contribution vs. resource introduction, which is more valuable?
From the perspective of code contribution, Tinkle's argument may have some merit. GitHub's commit records are public, and if Zack indeed only made a few code submissions, this is easily verifiable in the tech community. A project developed over 60 days versus another person participating for 14 days shows a significant gap in contribution in terms of time and code volume.
However, from the equity perspective, Zack produced legal documents. The registration information for APEIRON LABS PTE. LTD. shows that both parties signed a 50-50 equity distribution agreement. This means:
Both parties had previously reached a formal legal agreement.
The agreement recognizes Zack's 50% equity.
This is not a verbal promise but a legal fact registered with a government agency.
So the question arises: why would Tinkle agree to such an equity distribution?
How much is the Amber card really worth?
The key variable is Amber Group—or more accurately, Amber's ecological accelerator amber.ac.
Zack's leverage is that he can introduce Amber to participate in the commercialization of Nofx. According to Tinkle, Zack was once an intern at Amber (though he left before being converted to a full-time position). In the crypto industry, the ability to bring in top-tier institutional endorsement and funding is indeed of great value.
But the final outcome is:
Amber did not formally invest in Nofx.
Amber's official statement: there is "no formal incubation, investment, or commercial cooperation relationship" with Nofx.
Amber acknowledged: there were "friendly exchanges," but they did not lead to formal cooperation.
This leads to two possible explanations:
Explanation A (supporting Tinkle): Zack exaggerated his resource capabilities, exchanged equity for empty promises, ultimately failed to deliver, yet refused to relinquish equity and resorted to threats through a lawyer's letter.
Explanation B (supporting Zack): Both parties indeed reached an equity agreement, and Zack made efforts to introduce Amber, but due to issues on Tinkle's side (possibly including "embezzlement of assets and benefit transfer"), the investment did not materialize. As a legitimate shareholder, Zack has the right to demand an exit and compensation.
Which explanation is closer to the truth? More internal materials are needed for judgment.
Legal Procedure or Extortion?
Tinkle publicly disclosed Zack's lawyer's letter on social media, calling it "extortion." This accusation is serious, as extortion is a criminal offense.
However, Zack's response reveals the professionalism of legal procedures:
"Without Prejudice Save as to Costs" is a standard legal procedure in common law jurisdictions for settlement negotiations in commercial disputes. Its characteristics include:
Protected by law, cannot be used as litigation evidence (unless related to litigation costs).
The purpose is to encourage both parties to resolve disputes amicably.
Proposing settlement conditions does not constitute extortion.
The main body is a Demand Letter, detailing the other party's breach or infringement actions.
Zack's lawyer's letter demands $500,000, but this amount is based on:
The legal fact that Zack holds 50% equity in the company.
Calculated based on a conservative valuation of the company at $1 million.
As a buyback price, requesting Tinkle to purchase Zack's equity.
From a legal perspective, this is a completely legitimate settlement negotiation strategy. If Tinkle truly believes this is "extortion," the correct course of action would be to report it to the police, not to tweet about it.
Zack's "final warning" is also quite powerful:
"If you really think this is extortion, please report it to the police immediately. If you lack the courage to report it, then stop this ridiculous performance."
The Hidden Accusation: Embezzlement of Assets and Benefit Transfer
In this public confrontation, one detail is worth noting: Zack mentioned that the main body of the lawyer's letter is a detailed Demand Letter, recording Tinkle's actions of "embezzling partnership assets and conspiring through illegal means."
The full content of this Letter has not been made public, but this accusation is very serious. If true, it may involve:
Misappropriation of company funds for personal use.
Engaging in benefit exchanges with individuals from investment institutions.
Violating the fiduciary duty of the partnership.
Tinkle did not respond directly to this part of the accusation, merely stating that he "will no longer respond to this matter and will focus on product development."
This evasive attitude raises curiosity: what exactly is written in the Demand Letter?
Summary: An Unsolvable Dilemma
Equity disputes among founding teams are common in the entrepreneurial world. The Nofx case has attracted attention because it encapsulates the typical contradictions of such disputes:
Verbal Promises vs. Written Agreements: If there is no written equity agreement, how is contribution determined?
Technical Contribution vs. Resource Introduction: How are the values of these two measured?
Responsibility for Unmet Expectations: Who is responsible for the failure to secure funding?
Legal Procedures vs. Moral Judgments: Does settlement negotiation equate to extortion?
From the existing evidence:
Zack has legal documents supporting his 50% equity.
Tinkle has code contribution records supporting his leadership position.
Both sides have their narratives but lack a complete chain of evidence.
The final answer may only be provided by the court. However, this case serves as a warning to all entrepreneurial teams:
Equity distribution should be done early, in writing, and clearly defined.
Contribution quantification should have objective standards (code volume, work time, resource value).
Significant decisions should be documented.
In the event of disputes, legal avenues should be prioritized over public opinion battles.
Question 3: Why Do Open Source Projects Become Hotbeds for Security Issues?
Before the licensing dispute between Nofx and COAI and the internal equity conflict, a more serious crisis had quietly brewed: security vulnerabilities.
In November 2025, the blockchain security company SlowMist released a detailed security analysis report, revealing serious security risks in the Nofx project. This was not a typical "small bug," but a significant vulnerability that could lead to the complete theft of user funds.
Vulnerability Timeline: From Zero Authentication to Default Keys
October 31, 2025 - Commit 517d0c: The Original Sin of Zero Authentication
In this commit, Nofx's code contained a fatal flaw:
admin_mode default set to true.
Middleware allowed all requests to pass without verification.
/api/exchanges interface completely open.
What does this mean? Anyone who knows the address of a server deployed with Nofx can directly access the /api/exchanges interface to obtain:
api_key: User's exchange API key.
secret_key: Exchange secret.
hyperliquidwalletaddr: Hyperliquid wallet address.
asterprivatekey: Private key for the Aster platform.
With this information, an attacker can:
Completely control the user's exchange account.
Conduct false transactions (wash trading).
Directly withdraw funds.
Manipulate market prices.
This is a zero-protection exposure, a fundamental failure in security design.
November 5, 2025 - Commit be768d9: The Illusion of "Fortification"
Perhaps realizing the security issue, the Nofx team added a JWT (JSON Web Token) authentication mechanism in this commit. On the surface, this appears to be a security enhancement.
However, the problems are:
The default jwt_secret was not changed.
If the user did not set the environment variable, the system would revert to the hard-coded default key.
/api/exchanges still returns all sensitive fields in raw JSON format.
This means:
Attackers can forge JWT tokens using the default key.
Once a valid token is obtained, all keys will still be fully exposed.
The "fortified" version remains vulnerable in practice.
It's like adding a lock to a door but leaving the key under the doormat, where everyone knows.
November 13, 2025 - Dev Branch: Ongoing Hazards
Even by November 13, the code in the dev branch still had multiple issues:
The implementation of authMiddleware still had flaws (api/server.go:1471--1511).
/api/exchanges continued to directly return the complete ExchangeConfig (api/server.go:1009--1021).
The configuration file still hard-coded adminmode=true and default jwtsecret.
The main branch (origin/main) was still stuck on the zero authentication version from October 31.
This is not a mere accidental oversight but a systemic lack of security awareness.
Discovery and Response: Key Actions by SlowMist
Intelligence Source: Security researcher @Endlessss20 provided SlowMist with initial intelligence about the security risks in Nofx.
In-depth Analysis: The SlowMist security team conducted a complete audit of Nofx's GitHub code, identifying the two major authentication issues mentioned above.
Internet-wide Scan: More shockingly, SlowMist conducted a scan across the internet, discovering over 1,000 publicly accessible Nofx deployment instances, many of which used default or weak configurations, with user credentials fully exposed.
This is not a theoretical security risk but a real and ongoing threat.
Emergency Coordination: Given the urgency of the risk, SlowMist immediately contacted major exchanges:
Provided intelligence to the security teams of Binance and OKX.
Both exchanges independently conducted cross-validation.
Used the obtained API keys to track affected users.
Notified users and assisted in key rotation.
Prevented potential wash trading attacks.
Progress of Handling: As of November 17, 2025, all exposed keys for centralized exchange (CEX) users had been addressed. However, some Aster and Hyperliquid users, due to wallet decentralization, were difficult to reach directly and needed to self-check.
Scope of Impact: More Than Just a Technical Issue
The impact of this security incident goes far beyond the technical level:
Direct Victims:
Over 1,000 users using Nofx for automated trading.
Involving multiple platforms such as Binance, OKX, and Hyperliquid.
Exposed not only API keys but also private keys and wallet addresses.
Potential Losses:
If attackers acted before the exchanges intervened, user funds could be completely stolen.
The characteristics of AI automated trading systems involve high frequency and large amounts, leading to potentially staggering losses.
Collapse of Trust:
The community lost confidence in the security of the Nofx project.
Raised doubts about the entire open-source AI Trading ecosystem.
Developers became more cautious when choosing open-source projects.
Deep Questions: Why Such Basic Errors Occurred?
The security vulnerabilities in Nofx are not high-level technical challenges but basic security common sense:
Authentication mechanisms should be enabled by default, not disabled.
Default keys should be randomly generated, not hard-coded.
Sensitive data should be encrypted or anonymized, not returned in plain text.
Configuration files should clearly warn of security risks.
These are principles that any experienced developer should know. So why did Nofx make these mistakes?
Possible Reasons:
Rapid Development Priority: In the AI Trading boom, seizing the opportunity was prioritized over security.
Insufficient Team Experience: They may lack experience in handling user funds securely.
Testing Environment Configuration in Production: To facilitate testing, authentication was disabled, and this configuration ended up in the production environment.
Lack of Security Audits: Open-source projects often lack professional security audits.
But the fundamental reason may be: open source ≠ security.
Many people think that open-source code means "millions of eyes" are reviewing it, so it is safer. But the reality is:
Most users are just users, not reviewers.
Even if issues are discovered, they may not have the ability or willingness to submit fixes.
Security audits require expertise and significant time.
Commercial companies have security teams, while open-source projects often do not.
Responsibility Boundaries: How Much Responsibility Should Open Source Authors Bear?
This raises a controversial question: when users suffer losses due to vulnerabilities in open-source software, should open-source authors bear responsibility?
From a legal perspective, most open-source licenses (including MIT and AGPL) contain disclaimers:
"The software is provided 'as is,' without any express or implied warranties… the authors are not liable for any damages."
But from a moral perspective, when you know your code will be used by users to manage real assets, should there not be higher security standards?
The uniqueness of the Nofx case lies in:
It is an AI automated trading system directly involving user funds.
The project received over 9,000 stars, with a large number of users.
The vulnerabilities are not hidden advanced attacks but basic protective failures.
The issues persisted for weeks, during which new users continued to deploy.
Industry Insights: The Special Risks of AI Trading
The security crisis of Nofx reveals the special risks in the field of AI Trading:
The Double-Edged Sword of Automation:
AI trading systems are designed to operate automatically 24/7.
Once breached, attackers can quickly execute a large number of trades.
Users may discover hours later that their assets have been transferred.
The Conflict Between Open Source and Security:
Open source facilitates community improvement and review.
But it also makes it easier for attackers to find vulnerabilities.
Before security fixes are completed, vulnerabilities may already be publicly exposed.
Lack of User Education:
Many users do not understand the risks of deploying AI trading systems.
They directly use default configurations without knowing to change keys.
Exposing services on the public network without basic security protections.
The Exemplary Significance of SlowMist
In this incident, SlowMist's actions are commendable:
Rapid Response: Conducted in-depth analysis immediately upon receiving intelligence.
Proactive Scanning: Did not wait for user reports but actively discovered affected instances.
Industry Collaboration: Worked closely with exchanges rather than fighting alone.
Public Disclosure: Released a detailed report after handling the emergency, educating the community.
Clear Stance: Emphasized that this is not criticism but risk reduction.
This responsible disclosure mechanism is the cornerstone of industry security.
Summary: Open Source is Not a Get-Out-of-Jail-Free Card
The Nofx security vulnerability incident teaches us:
Open-source projects need security audits: Even rapidly iterating projects cannot skip security checks.
Default configurations should prioritize security: Convenience for development and ease for attackers are often two sides of the same coin.
User funds must be treated with special care: Systems involving money must have uncompromising security as a bottom line.
The community needs to establish a security response mechanism: SlowMist's actions provide a good example.
Technical ability ≠ security awareness: Being able to write functional code does not mean one can write secure code.
Question 4: How Much is Amber's "Endorsement" Really Worth?
In the multiple crises of Nofx, one detail is easily overlooked, but it reveals a common issue in the crypto industry: the culture of endorsement.
The Emergence of Endorsement: "Backed by @amberac"
Before the incident erupted, if you visited Nofx's Twitter homepage, you would see this line in the bio: "Backed by @amberac."
What does this mean? In the crypto industry, "backed by" typically implies:
Received investment from that institution.
Or at least incubation support.
It indicates an officially recognized relationship.
Amber Group is a well-known institution in the crypto industry, with strong funding and resources. amber.ac is its ecological accelerator. For an emerging open-source project, gaining Amber's endorsement means:
Credit endorsement: The project is more credible, attracting more users.
Financing convenience: Other investors are more willing to follow suit.
Resource support: Potential access to technical, market, and legal support.
Community confidence: Users are more willing to participate and contribute.
This is akin to an entrepreneur receiving a term sheet from a top VC; even if the money hasn't been secured yet, just this endorsement can bring immense value.
Zack's Leverage: I Can Bring Amber
Returning to the context of the Infighting Gate, Zack's demand for 50% equity was significantly based on: he could introduce Amber to participate in the commercialization of Nofx.
According to Tinkle, Zack was once an intern at Amber. In the industry, this background implies certain networking resources. Zack promised Tinkle that he could bring in Amber's investment or incubation support, in exchange for which he demanded 50% equity.
From a business logic perspective, this deal is reasonable:
If Zack can indeed bring in Amber's investment, that value far exceeds 14 days of code contribution.
For an open-source project, gaining endorsement from top institutions could be a key leap from 0 to 1.
Distributing 50% equity at the early stage is not without precedent for resource introducers.
But the key question is: Did Amber ultimately come in?
Amber's Clarification: "No Formal Incubation, Investment, or Commercial Cooperation Relationship"
In December 2025, as the infighting and open-source gate of Nofx were making headlines, amber.ac released an official statement:
"amber.ac has no formal incubation, investment, or commercial cooperation relationship with Nofx. We have had friendly exchanges with Nofx based on industry observations, but these exchanges did not lead to any formal cooperation. All our formal collaborations will be publicly announced through our official website."
This statement is quite subtle:
Denies formal relationships: No investment, no incubation, no commercial cooperation.
Acknowledges previous contact: "Friendly exchanges," "industry observations."
Emphasizes procedure: Formal cooperation will be publicly announced.
Draws a clear line: This is a public severance.
So the question arises: How big is the gap between "friendly exchanges" and "backed by"?
The Disappearance of Endorsement: Deletion and Explanation
Shortly after Amber released its statement, the community discovered that Nofx had quietly removed the phrase "Backed by @amberac" from its Twitter bio.
Some netizens questioned this, and the Nofx editor responded:
"Grateful for Amber's early support, but due to the current events and the other party's request, we respect their wishes to delete it."
This response raises new questions:
What does "early support" mean: If there was no formal cooperation, what does support refer to?
Did the other party request deletion: Did Amber actively request the severance?
Did the "current events" influence this: Was it requested to be deleted because of the scandal?
From Amber's perspective, this severance is necessary:
Nofx is embroiled in security vulnerabilities, equity disputes, and licensing conflicts.
Any association with Nofx could damage Amber's reputation.
Especially if users suffer losses due to using Nofx, Amber does not want to bear any responsibility.
From Nofx's perspective, this deletion is awkward:
The endorsement they were once proud of suddenly disappears.
The impression given to the outside world is "even the investors are running away."
This further undermines community confidence.
"Ecological Accelerator" vs. "Formal Investment": The Gray Area amber.ac is positioned as an "ecological accelerator," rather than a direct investment fund. The ambiguity of this positioning is the root of the problem.
Ecological accelerators typically provide:
Mentorship and industry advice.
Community resources and networking connections.
Participation in events and brand exposure.
But may not necessarily provide direct funding.
Formal investment relationships include:
Clear investment amounts and equity ratios.
Legal documents (investment agreements, shareholder agreements).
Board seats or observer rights.
Regular financial and operational reports.
The relationship between Nofx and amber.ac may lie in the gray area between the two:
There were some exchanges and guidance ("friendly exchanges").
Nofx believes this constitutes "support," allowing them to label it as "backed by."
amber.ac believes this does not constitute "formal cooperation" and should not be publicly promoted.
Zack may have indeed facilitated these exchanges, but ultimately they did not translate into investment.
The Proliferation of Endorsement Culture: A Common Malady in the Crypto Industry
The Nofx-Amber incident is just the tip of the iceberg. In the crypto industry, the culture of endorsement has become rampant:
Common Endorsement Tactics:
"Certain institution leads the investment": In reality, it may just be a small follow-on investment.
"Certain big shot endorses": It may just be a retweet.
"Certain accelerator incubates": It may just be participation in a workshop.
"Certain exchange cooperates": It may just be a coin listing application.
The Real Value Chain of Endorsement:
Top Level: Formal investment agreements, specifying amounts and terms.
Middle Level: Accelerator selection, with clear support plans.
Bottom Level: Participation in events, gaining exposure opportunities.
Lowest Level: Casual chats, providing some advice.
The problem is that many projects intentionally package bottom-level relationships as top-level endorsements.
Why Investment Institutions Tolerate This Ambiguity:
Expanding Influence: More projects mentioning themselves expands their brand.
Option Thinking: Establishing weak connections may eventually convert into investments.
Minimal Effort: The cost of a single conversation is low, but the value to the project is significant.
Gray Profits: Some institutions may charge "consulting fees" or "brand usage fees."
Why Projects Are Enthusiastic About This:
Financing Needs: Having endorsements makes it easier to secure subsequent financing.
User Trust: Communities are more willing to trust projects with institutional endorsements.
Competitive Pressure: Other projects are promoting endorsements, and not doing so feels like falling behind.
Vanity: Founders also need this recognition.
Reflection: Where Are the Boundaries of Endorsement Responsibility?
The Nofx-Amber incident raises a deep question: when an institution's name is used for endorsement, how much responsibility should it bear?
If Amber truly invested in Nofx:
As a shareholder, it has supervisory and governance responsibilities.
If the project encounters significant issues, investors should intervene.
If users suffer losses, investors may bear some moral responsibility.
If it was merely "friendly exchanges":
Amber has no legal obligations.
But if the project uses its name for endorsement, Amber should correct this misuse promptly.
If they knowingly allow misuse without intervening, does that constitute tacit approval?
In the Nofx case:
Nofx labeled "Backed by Amber" on Twitter for weeks (possibly months).
As a professional institution, Amber has the capability to monitor social media.
If they truly had no formal cooperation, why not clarify earlier?
Did they wait until Nofx encountered issues before hastily severing ties?
This "vague beforehand, severing afterward" model undermines the trust foundation of the entire industry.
Summary: Endorsement is Not a Free Lunch
The Nofx-Amber incident's insights:
For Projects: Do not exaggerate relationships with institutions; false endorsements will eventually be exposed.
For Investment Institutions: Clearly define the boundaries of endorsements, promptly correct misuse, and bear corresponding responsibilities.
For Users: Learn to identify genuine endorsements and verify through official channels of investment institutions.
For the Industry: Establish standards and norms for endorsements to reduce gray areas.
In the crypto industry, endorsements are a form of social capital. But like all capital, it requires rules and responsibilities. When everyone is overextending this trust, the ultimate result is the collapse of the entire industry's credibility.
Question 5: What Systemic Issues Did This Storm Expose?
When we detach from specific accusations and rebuttals, stepping outside the details of the Nofx case, we find that this storm points to five deep systemic issues—ones that exist not only in Nofx but are the "Achilles' heel" of the entire crypto open-source ecosystem.
Issue One: The Alienation of Open Source Spirit in the Wave of Commercialization
The change of Nofx's license from MIT to AGPL appears to be a technical decision on the surface, but it actually reflects the fundamental conflict between the spirit of open source and commercial interests.
The Original Intention of Open Source:
Code sharing to promote collaboration.
Standing on the shoulders of giants to avoid reinventing the wheel.
Community-driven, collective wisdom.
The Reality of Commercialization:
The need to protect commercial interests.
Prevent competitors from "free-riding."
Seeking monetization paths.
The MIT license represents the idealism of open source: use it freely as long as you credit the source. This generosity attracted a large number of developers and community attention, allowing Nofx to quickly accumulate over 9,000 stars.
However, when Nofx saw projects like COAI, which raised $17 million potentially using their code, they changed their minds. The AGPL license is the strictest "firewall" in the open-source world: want to use my code? Then you must also open source it and cannot use it commercially without opening it.
From Nofx's perspective, this shift has its rationale:
Right to Choose License: Open-source authors have the right to reassess their license choices as the project develops; AGPL is a legitimate and widely used open-source license.
Unequal Interests: When realizing that their code is being used extensively by well-funded commercial projects, small open-source teams feel that their contributions and returns are mismatched.
Ecological Protection: The "infectious" nature of AGPL aims to prevent open-source code from being "claimed as one's own," protecting the sustainable development of the open-source ecosystem.
Vulnerable Position: Facing competitors with $17 million in funding, open-source projects are at a clear disadvantage in terms of resources, legal standing, and market presence.
This shift itself is not objectionable—open-source authors have the right to choose their licenses. However, the objective problem is:
No Notification to the Community: The license change was not announced to the community, and developers who had already used the MIT version may be unaware.
Retroactive Enforcement: Using the agreement changed on November 4 to pursue actions from November 3.
Selective Accusations: Why specifically accuse COAI and not other projects using the MIT version?
Privacy Data Collection: Google statistics were embedded during the MIT phase, collecting user data without informing them.
From another perspective, some of Nofx's actions may have their background:
Protective Intent: The fundamental purpose of the license change may be to protect the interests of community contributors rather than targeting specific competitors.
Capability Limitations: As a small team, they may have indeed overlooked the standard community communication processes during the project's rapid growth phase.
Technical Needs: Google statistics may have been intended to understand user usage, identify issues, and improve the product rather than maliciously collecting data.
Resource Pressure: Facing well-funded commercial competition, open-source projects indeed lack equivalent legal and market resources.
However, even with an understanding of these backgrounds, the issues with execution remain. This is no longer just about defending the spirit of open source but finding a balance between protecting one's rights and maintaining trust in the open-source ecosystem.
The Alienation of Open Source is Manifested by:
Toolization: Open source becomes a tool for gaining users and attention rather than an end in itself.
Weaponization: Open-source licenses become weapons to attack competitors rather than a basis for collaboration.
Unidirectionality: Only demanding others to open source while being able to change rules at will.
This judgment requires caution. We find it difficult to fully understand the internal decision-making processes and true motivations of the Nofx team from the outside. The change of open-source licenses is a legal right; the key issue lies in:
Execution Method: How to change, how to notify, how to handle existing users.
Transparency: Whether the decision-making process is public and whether the reasons are adequately explained.
Consistency: Whether all similar situations are treated equally.
This case exposes more systemic issues of the entire Web3 open-source ecosystem's lack of mature norms rather than merely malicious actions from one party.
Both sides have reasonable demands:
Nofx's Demand: The labor results of open-source contributors should not be occupied by commercial projects without compensation and should receive due recognition and returns.
COAI's Demand: Code legally used under the MIT license should not be retroactively required to bear AGPL obligations.
The Industry's Dilemma: How to establish a balanced mechanism between encouraging open-source sharing and protecting creators' rights.
This alienation harms the trust foundation of the entire open-source ecosystem. When developers are uncertain whether an MIT project will suddenly change to AGPL and enforce retroactive measures, will they still dare to use open-source code? When open-source authors find their contributions commercialized without any returns, will they still be willing to continue open sourcing?
This is a lose-lose dilemma; what is truly needed is regulatory construction at the industry level.
Issue Two: The Lack of Legal Risk Awareness in Entrepreneurial Teams
The equity dispute between Tinkle and Zack exposes a common issue among crypto entrepreneurial teams regarding legal compliance.
Confusion in Equity Distribution:
Zack holds 50% equity according to legal documents (APEIRON LABS registration).
Tinkle believes Zack deserves only 10-20% equity (based on code contributions).
This cognitive gap should not exist—equity distribution should be clearly defined and documented from the start.
Lack of Decision Records:
Zack claims he was granted 50% equity based on the promise of bringing in Amber investment.
Tinkle says Zack exaggerated his capabilities and ultimately did not bring in investment.
Both sides lack written records of the agreement conditions at that time: was it "best efforts" or "equity granted upon completion"?
Confusion in Communication Procedures:
Zack's lawyer's letter went unanswered by Tinkle for a month.
By the time Tinkle publicly accused "extortion," Zack had no choice but to respond publicly.
Why could they not negotiate privately first instead of going straight to a public opinion battle?
Abuse of Legal Tools:
Tinkle called the lawyer's letter "extortion," which is a serious criminal accusation.
Zack provided a standard commercial settlement document, proving this is a legal procedure.
These issues are extremely common in crypto entrepreneurial teams:
Rapid Action Over Standard Processes: A "let's just get started" culture leads to many missing legal documents.
Dominance of Technical Thinking: Engineer founders often do not prioritize legal and compliance matters.
Decentralized Illusion: Believing they can bypass traditional laws in the crypto world.
Cost Considerations: Early-stage projects cannot afford professional lawyers.
However, when projects grow larger or disputes arise, these early "omissions" can become significant hazards.
What Should Be Done:
Founding teams should have a written equity agreement (Founders' Agreement) from day one.
Clearly define each person's type of contribution, equity ratio, and vesting schedule.
Retain written records of key decisions (emails, signed documents).
Regularly consult professional lawyers to review company structure and compliance.
In the event of disputes, seek legal avenues first rather than public opinion battles.
Issue Three: A Serious Disconnect Between Technical Ability and Security Awareness
The security vulnerabilities in Nofx reveal a harsh truth: in the crypto industry, technical ability ≠ security awareness.
Manifestations of Capability Misalignment:
Nofx was able to develop an AI automated trading system, which requires considerable technical ability.
Yet it simultaneously committed basic security errors like "zero authentication" and "default keys."
Being able to write functional code does not mean one can write secure code.
Financing Ability Does Not Equate to Technical Strength:
COAI raised $17 million but was questioned about its coding capabilities.
Nofx gained community acclaim but faced frequent security vulnerabilities.
In the crypto industry, the ability to tell a story often secures funding more than technical strength.
Marginalization of Security:
Under the pressure of rapid development, security is often seen as something to be addressed "later."
Functionality takes precedence over security, and speed of launch takes precedence over code audits.
It is only when actual losses occur that the severity of the issues becomes apparent.
The Misunderstanding that Open Source Equals Security:
Many people believe open-source code is inherently safer ("millions of eyes").
But the reality is that most users do not review code; they only look at star counts.
Security audits require expertise and significant time; they do not happen automatically.
The Special Risks of AI Trading:
Involves real user funds, making losses irreversible.
Automated execution means the attack window is short, and by the time issues are discovered, it is already too late.
Running 24/7 amplifies the impact of security issues.
Lessons from the Nofx Case:
Security is a baseline, not an option: Systems involving user funds must undergo professional security audits.
Default configurations should prioritize security: It is better to inconvenience users than to make it easy for attackers.
Rapid iteration is not an excuse: MVPs can be functionally simple but must not be security weak.
The community needs a security response mechanism: Roles similar to SlowMist should be institutionalized.
Issue Four: The Proliferation of Endorsement Culture in the Crypto Industry
The Nofx-Amber incident unveils the facade of the endorsement culture in the crypto industry.
Inflation of Endorsements:
Almost every project claims to have "support from certain institutions."
But the meanings of these "supports" vary widely.
From formal investments to a single chat, everything can be packaged as "backed by."
The Proliferation of Gray Areas:
"Strategic cooperation": May just be business matchmaking.
"Ecological partners": May just be mutual retweets.
"Advisory teams": May just be nominal.
"Investment institutions": May just have bought some coins.
Why This Culture Has Market Demand:
Information Asymmetry: Ordinary users find it difficult to verify the authenticity of endorsements.
Herd Mentality: "If someone invested, it must be reliable."
Competitive Pressure: Not promoting endorsements feels like losing at the starting line.
Regulatory Vacuum: No institution manages the authenticity of endorsements.
Vicious Cycle:
Projects exaggerate endorsements → Gain more attention and funding.
Seeing successful cases, more projects imitate.
Investment institutions tacitly allow ambiguous relationships for influence.
When projects encounter issues, institutions rush to distance themselves.
Users and the industry bear the losses.
How to Break the Cycle:
Investment Institutions: Establish an official investment portfolio list, clearly stating investment amounts and dates.
Projects: Only promote verifiable formal relationships and provide proof documents.
Media and KOLs: Verify the authenticity of endorsements before reporting.
Users: Learn to verify and not blindly trust endorsements.
Regulation: Punish false endorsements (some jurisdictions have already begun).
Issue Five: The Comprehensive Absence of Community Governance Mechanisms
In light of Nofx's triple crisis, the deepest issue is: the open-source community lacks effective governance mechanisms.
No Arbitration Mechanism for License Disputes:
The dispute between Nofx and COAI sees both sides holding firm to their positions.
There is no recognized third party to determine who is right and who is wrong.
They can only rely on public opinion and legal avenues, the former being unjust and the latter costly.
Lack of Standard Processes for Security Issues:
SlowMist's timely response is an exception, not the norm.
Most open-source projects lack security response teams.
Vulnerability disclosures, user notifications, and emergency fixes lack standards.
No Place to Appeal Equity Disputes:
Tinkle and Zack's conflict can only resort to legal or public opinion battles.
The open-source community lacks a dispute resolution mechanism.
DAO governance has been proposed for a long time, but actual operations are rare.
Lack of Incentives for Community Participation:
Security audits and code reviews require significant time.
But open-source contributors are often volunteers.
Commercial companies have dedicated teams, while open-source projects rely on goodwill.
Existing Governance Practices Attempt:
OpenSSF (Open Source Security Foundation): Promotes best practices for open-source security.
CVE (Common Vulnerabilities and Exposures): Vulnerability numbering and tracking system.
Bug Bounty: Incentivizes security researchers with rewards.
Code of Conduct: Community behavior norms.
Foundation Model: Establishes foundations to manage projects (e.g., Linux Foundation).
However, the application of these mechanisms in the crypto open-source field is still very limited.
An ideal governance mechanism for open source, balancing the interests of users and all parties, should include:
Security Audit Standards: Clearly define which types of projects must pass audits to be recommended.
Dispute Arbitration Institutions: Neutral third parties to handle licensing and equity disputes.
Responsibility Disclosure Processes: How to notify, fix, and announce vulnerabilities after discovery.
Community Participation Incentives: Reward contributors through tokens, NFTs, or other means.
Transparency Requirements: Mandatory disclosure of key information such as funding, endorsements, and equity structures.
Root Causes of Systemic Issues: The Trade-off Between Speed and Quality
The common root of these five issues is the extreme pursuit of speed in the crypto industry:
Rapid Development: Seizing hot topics, quickly iterating, gaining first-mover advantage.
Rapid Financing: Overvaluing during high interest, disregarding compliance details.
Rapid Growth: Competing on metrics like user numbers, star counts, and community sizes.
Rapid Monetization: Issuing tokens, listing on exchanges, cashing out.
In this culture:
Security is a burden that slows down progress.
Legal matters are costs to be minimized.
Governance is a hindrance to decision-making.
Long-termism is a joke; bull markets wait for no one.
But when speed trumps everything, quality becomes the sacrifice. Nofx gained 9,000 stars in two months but also lost considerable credibility in the same timeframe.
Conclusion: The Real Dilemma of Open Source Ideals
From a rapid rise to falling into a triple crisis, the story of Nofx is a microcosm of the Web3 open-source movement. It showcases the powerful force of open-source collaboration while exposing the various challenges this model faces in reality.
Hacker Gate reminds us that decentralization does not equal security; Infighting Gate reveals that the differences among idealists can be more destructive than external attacks; Open Source Gate brings a long-standing issue to the forefront: in the pursuit of commercial value in the Web3 world, how can we protect the rights of open-source contributors?
Particularly noteworthy is that the timing dispute in the open-source license conflict still needs further clarification. This not only relates to the rights and wrongs of specific cases but also concerns the regulatory construction of the entire Web3 open-source ecosystem. In the future, there may be a need to establish a more reliable mechanism for recording license changes and a more authoritative third-party arbitration system.
This article is based on publicly available information and analysis and does not represent support or denial of any party. All technical details, timelines, and legal documents mentioned can be verified through public channels such as GitHub and Twitter. Please credit the source for any reproduction or adaptation: x@wquguru.
Risk warning Risk warning
