From a rapid rise to a triple crisis, the story of Nofx is a microcosm of the Web3 open-source movement.
Author: WquGuru
Writing Background
Before diving into this story, I need to clarify my position in this event.
I am an observer and analyst. During the explosive growth of the Nofx project, I developed the nof0 project—both inspired by nof1. During the development process, I communicated with Nofx's core members Tinkle and Zack, mainly focusing on technical implementation and open-source collaboration.
It is important to clarify: I only had technical exchanges with the Nofx team and no commercial partnership; 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 exposed, SlowMist issued a security warning (Hacker Gate).
December 2025: Disputes over open-source agreements erupted (Open Source Gate), while internal divisions within the team surfaced (Infighting Gate).
The entire event lasted about two months but revealed 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.
Reflections and references for the future regulatory construction of the industry.
Now, let’s start untangling this complex story from the beginning.
Prologue: The Rise of an AI Trading Project
At the end of October 2025, an AI automated trading project named Nof1 exploded on Twitter. In 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: Blockchain security company SlowMist disclosed that Nofx had serious security vulnerabilities, exposing the exchange API keys, private keys, and wallet addresses of users from over 1,000 deployed instances. Major exchanges like Binance and OKX urgently intervened to assist affected users in replacing credentials.
Infighting Gate: Core member Tinkle publicly accused another co-founder Zack of "only participating for 14 days, 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," and provided partnership registration documents showing both held 50% equity.
Open Source Gate: Nofx publicly accused ChainOpera AI (COAI), which raised $17 million, of violating the AGPL open-source agreement 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 agreement really violated?
MIT vs. AGPL: Two Completely Different Open Source Philosophies
Before discussing the agreement dispute between Nofx and COAI, we need to understand the fundamental differences between the two open-source agreements:
The MIT License is one of the most permissive open-source licenses. It allows:
Free use, modification, and distribution of 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-sourced.
Specifically, even if providing services over the network (like SaaS), the source code must be made public.
Original project information must be clearly indicated.
The shift from MIT to AGPL represents a 180-degree turn from "extremely permissive" to "extremely strict." This is also the core of the current dispute.
Agreement Change and Timing Dispute
The open-source agreement 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 agreement 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 agreement file.
The COAI team pointed out that, according to their records and observations, there are doubts about the public timing of the agreement change.
ChainOpera's "Plagiarism" Accusation
The Nofx community discovered that the ChainOpera (COAI) project, which raised $17 million and 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 agreement 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 agreement.
COAI's Response:
Claimed that when they forked the code, Nofx was still under the MIT agreement.
The MIT agreement allows commercial use without the need to make the source code public.
The dispute over the timing of the agreement change affected the nature of the entire event.
Open Source Agreement Dispute: Who is Right and Who is Wrong?
This dispute exposed deep-seated issues within the Web3 open-source ecosystem:
Validity of Agreement Change:
Retroactive effect dispute: Does the change in the open-source agreement bind the already forked code?
Timing determination: The exact timing of the agreement change is difficult to ascertain, with both sides holding firm to their claims.
Credibility of evidence: GitHub records may be modified, requiring more authoritative third-party verification.
Communication of agreement change: To what extent was the message of the change from MIT to AGPL communicated to the community?
Conflict of Commercial Interests:
COAI secured significant funding and launched on Binance, holding immense commercial value.
Nofx, as an open-source project, has an unclear path to commercialization.
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 believe that COAI profited from open-source code without giving back to the community.
Supporters of COAI argue that the MIT agreement allows for commercial use, and the timing of the agreement 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 agreements in on-chain 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 accusation of COAI violating the open-source agreement has several doubts:
Doubts about the timing: GitHub evidence shows the change to AGPL occurred on November 4.
Different technical implementations: Identical interface names do not mean identical code.
Reasonable log interpretation: The statistical function inserted during the MIT phase would continue to record.
Potential self-violation: Not informing users about the embedded statistics may violate privacy laws.
Rash communication procedures: Sending an email and making public accusations within the same minute.
It is noteworthy that the dispute over the timing of the agreement change has a decisive impact on the nature of the entire event. If Nofx's claims are valid, COAI indeed has issues with violating the AGPL agreement; but if COAI's claims hold, their actions fully comply with the MIT agreement. 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 is the dispute between Nofx and external parties, 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 for commercialization;
Early November 2025: Tinkle refuses to grant 50% equity, believing he is the team’s CEO and CTO, and that Zack's contributions are insufficient;
November 19, 2025: Zack's lawyer (JunHe Law Offices, Hong Kong) issues a formal "Without Prejudice Save as to Costs" offer, demanding $500,000 to buy back the 50% equity held by Zack;
December 2025: The conflict becomes public, with both sides accusing each other on social media;
From a timeline perspective, Zack went from joining to sending a lawyer's letter in 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 an intern at Amber but left before being converted to a full-time position.
Ultimately failed to bring in Amber investment.
Zack's Counterattack:
Provide the company registration documents of APEIRON LABS PTE. LTD.
The documents show that Tinkle and Zack each hold 50% equity.
This is public information from the Singapore company registration system, which anyone can verify.
The lawyer's letter is a standard "Without Prejudice Save as to Costs" offer, in line with commercial legal procedures.
The main body is a Demand Letter, detailing Tinkle's actions of "embezzling assets and transferring benefits."
The $500,000 is not extortion but a legitimate buyback of Zack's undervalued equity.
A rhetorical question: If the company has value, isn't it reasonable to buy back 50% equity at a $1 million valuation? If it has no value, then 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 submitted a small amount of code, this is an easily verifiable fact in the tech community. In a project developed over 60 days, having another person participate for 14 days does create a significant disparity in contribution in terms of time and code volume.
However, from the equity perspective, Zack has presented legal documents. The registration information of 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 government authorities.
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 ecosystem accelerator amber.ac.
Zack's leverage is that he can introduce Amber to participate in the commercialization of Nofx. According to Tinkle, Zack was an intern at Amber (though he left before being converted to a full-time position). In the crypto industry, being able to bring in endorsements and funding from top institutions 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 partnership with Nofx."
Amber acknowledged that there were "friendly exchanges," but they did not lead to formal cooperation.
This leads to two possible interpretations:
Interpretation A (supporting Tinkle): Zack exaggerated his resource capabilities, exchanged equity for empty promises, ultimately failed to deliver, and refused to relinquish equity, using a lawyer's letter to threaten.
Interpretation B (supporting Zack): Both parties indeed reached an equity agreement, Zack made efforts to introduce Amber, but due to issues on Tinkle's side (possibly including "embezzling assets and transferring benefits"), the investment did not materialize. As a legitimate shareholder, Zack has the right to demand an exit and compensation.
Which interpretation is closer to the truth? More internal materials are needed to make a judgment.
Legal Procedure or Extortion?
Tinkle publicly shared 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 Anglo-American law used for settlement negotiations in commercial disputes. Its characteristics are:
Legally protected, cannot be used as litigation evidence (unless related to litigation costs).
The purpose is to encourage both parties to resolve disputes peacefully.
Proposing settlement conditions does not constitute extortion.
The main body is a Demand Letter, outlining the other party's breach or infringement.
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 buy out 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 forceful:
"If you really think this is extortion, please report it to the police immediately. If you lack the courage to report it, then please stop this ridiculous performance."
The Hidden Accusation: Embezzlement 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 colluding 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:
Misappropriating company funds for personal use.
Engaging in benefit exchanges with individuals from investment institutions.
Violating fiduciary duties of the partnership.
Tinkle did not respond directly to this part of the accusation, only stating that he would "no longer respond to this matter and focus on product development."
This evasive attitude makes one curious: what exactly is written in the Demand Letter?
Summary: An Unsolvable Dilemma
Equity disputes among founding teams are common in the entrepreneurial world. The reason the Nofx case has attracted attention is that 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 to measure the value of the two?
Responsibility for unmet expectations: Who is responsible for the failed fundraising?
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 own narratives but lack a complete chain of evidence.
Ultimately, the answer may only be provided by the court. But this case serves as a warning to all entrepreneurial teams:
Equity distribution should be done early, in writing, and clearly.
Contribution quantification should have objective standards (code volume, work time, resource value).
Major decisions should be documented.
In the event of a dispute, prioritize legal avenues over public opinion battles.
Question 3: Why Have Open Source Projects Become Hotbeds of Security Issues?
Before the protocol dispute between Nofx and COAI and the internal equity disputes, a more serious crisis had quietly brewed: security vulnerabilities.
In November 2025, 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 major 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 had a fatal flaw:
admin_mode was set to true by default.
The middleware allowed all requests to pass without verification.
The /api/exchanges interface was 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: Aster platform's private key.
With this information, an attacker can:
Completely control the user's exchange account.
Conduct false trades (wash trading).
Directly withdraw funds.
Manipulate market prices.
This is an exposure of zero protection, a fundamental failure in security design.
November 5, 2025 - Commit be768d9: The Illusion of "Hardening"
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.
But the problem is:
The default jwt_secret was not changed.
If the user did not set the environment variable, the system would revert to the hardcoded default key.
The /api/exchanges still returned 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 "hardened" version remains vulnerable in practice.
It's like adding a lock to a door but leaving the key under the doormat, where everyone knows it is.
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).
The /api/exchanges continued to return the complete ExchangeConfig (api/server.go:1009–1021).
The configuration file still hardcoded adminmode=true and the default jwtsecret.
The main branch (origin/main) was even still at the zero authentication version from October 31.
This is not a random 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 vulnerabilities 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 and discovered 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 threat that is currently happening.
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-verification
Used the obtained API keys to track affected users
Notified users and assisted in key rotation
Prevented potential wash trading attacks
Progress Update: As of November 17, 2025, all exposed keys of centralized exchange (CEX) users have been addressed. However, some Aster and Hyperliquid users, due to wallet decentralization, are difficult to reach directly and need 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, Hyperliquid
Exposed not only API keys but also private keys and wallet addresses
Potential Losses:
If attackers act before intervention from the exchanges, user funds could be completely stolen
The nature of AI automated trading systems is high frequency and large amounts, leading to potentially staggering losses
Collapse of Trust:
The community has lost confidence in the security of the Nofx project
Questions arise about the entire open-source AI Trading ecosystem
Developers are more cautious when choosing open-source projects
Deep Questions: Why Such Basic Errors Occurred?
The security vulnerabilities in Nofx are not advanced technical challenges but basic security common sense:
Authentication mechanisms should be enabled by default, not disabled
Default keys should be randomly generated, not hardcoded
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 is more important than security
Insufficient team experience: There may be a lack of security experience in handling user funds
Testing environment configurations moved to production: Authentication was disabled for testing convenience, and this configuration ended up in production
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, there may not be 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
Boundary of Responsibility: How Much Responsibility Should Open Source Authors Bear?
This raises a controversial question: Should open-source authors be held responsible when users suffer losses due to vulnerabilities in open-source software?
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 be a higher standard of security?
The uniqueness of the Nofx case lies in:
It is an AI automated trading system, directly involving user funds
The project has over 9,000 stars and a large user base
The vulnerability is not a hidden advanced attack but a lack of basic protection
The issue existed 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 run automatically 24/7
Once breached, attackers can quickly execute a large number of trades
Users may only discover hours later that their assets have been transferred
The Contradiction Between Open Source and Security:
Open source helps the community improve and review
But it also makes it easier for attackers to find vulnerabilities
By the time security fixes are completed, vulnerabilities may have already been publicly exposed
Lack of User Education:
Many users do not understand the risks of deploying AI trading systems
They use default configurations directly, unaware that they need to change keys
They expose services to the public network without basic security protections
The Model Significance of SlowMist
In this incident, SlowMist's actions are commendable:
Rapid response: Immediately conducted in-depth analysis upon receiving intelligence
Proactive scanning: Did not wait for user reports, 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 a risk reduction effort
This mechanism of Responsible Disclosure 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 convenience for attacks are often two sides of the same coin
User funds must be treated with special care: In systems involving money, security is a non-negotiable 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" Worth?
In the multiple crises of Nofx, there is a detail that 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 broke out, 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" usually implies:
Received investment from the institution
Or at least incubation support
It is a form of officially recognized relationship
Amber Group is a well-known institution in the crypto industry, with strong funding and resources. amber.ac is its ecosystem 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 up
Resource support: Potential access to technical, market, legal, and other 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 they haven't received the money yet, just this endorsement can bring immense value.
Zack's Leverage: I Can Bring Amber
Returning to the background of the internal conflict, Zack's important leverage for demanding 50% equity is that he can introduce Amber to participate in the commercialization of Nofx.
According to Tinkle, Zack was 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 requested 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 a top institution could be the key leap from 0 to 1
Distributing 50% equity at the early stage of a startup to a resource introducer is not without precedent
But the key question is: Did Amber ultimately come through?
Amber's Clarification: "No Formal Incubation, Investment, or Commercial Partnership"
In December 2025, when the internal conflict and open-source issues of Nofx were making headlines, amber.ac released an official statement:
"amber.ac has no formal incubation, investment, or commercial partnership 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 partnership
Acknowledges previous contact: "Friendly exchanges," "industry observations"
Emphasizes procedure: Formal collaborations will be officially 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:
"We appreciate Amber's early support, and due to the current events and the other party's request, we respect their wishes to delete it."
This response raises new questions:
What is "early support": If there is no formal cooperation, what does support refer to?
"The other party's request" to delete: Did Amber actively request the severance?
"Current events" impact: Was the deletion requested because of the scandal?
From Amber's perspective, this severance is necessary:
Nofx is embroiled in security vulnerabilities, equity disputes, and protocol 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 quite awkward:
The once-proud endorsement suddenly disappeared
The impression given to the outside world is "even the investors have run away"
Further undermined community confidence
"Ecological Accelerator" vs "Formal Investment": The Gray Area amber.ac is positioned as an "ecological accelerator," rather than a direct investment fund. This ambiguity in 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" and can be labeled 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 they ultimately 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": It may actually 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 submission
The Real Value Chain of Endorsement:
Top level: Formal investment agreements, specifying amounts and terms
Middle level: Selection by accelerators, with clear support plans
Bottom level: Participation in events, gaining exposure opportunities
Lowest level: Private conversations, providing some advice
The problem is that many projects intentionally package bottom-level relationships as top-level endorsements.
Why do investment institutions tacitly allow this ambiguity:
Expanding influence: More projects mentioning themselves, broadening brand awareness
Option thinking: Establishing weak connections first, which may later convert into investments
Minimal effort: The cost of a single exchange is low, but it holds significant value for the project
Gray benefits: Some institutions may charge "consulting fees" or "brand usage fees"
Why are project parties keen on this:
Financing needs: Having endorsements makes it easier to secure subsequent financing
User trust: The community is more willing to believe in projects with institutional endorsements
Competitive pressure: Other projects are promoting endorsements, and not mentioning it 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 had indeed invested in Nofx:
As a shareholder, there are 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 party uses its name for endorsement, Amber should correct this in a timely manner
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)
Amber, as a professional institution, has social media monitoring capabilities
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 insights from the Amber-Nofx incident:
For project parties: 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, 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 Does This Turmoil Expose?
When we detach from specific accusations and rebuttals, stepping outside the details of the Nofx case, we find that this turmoil points to five deep systemic issues—issues 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 protocol 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: you can 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: use my code? Then you must also open source it and cannot use it for closed-source commercial purposes.
From Nofx's perspective, this shift has its rationale:
Choice of license: Open source authors have the right to reassess their license choices during project development; AGPL is a legal and widely used open-source license
Unequal benefits: When discovering that their code is being used on a large scale by well-funded commercial projects, small open-source teams feel that their contributions do not match the returns
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
Disadvantaged 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 problems are:
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 Analytics was embedded during the MIT phase, collecting user data without informing them
From another perspective, some of Nofx's actions may have their background:
Protective intention: 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 neglected proper community communication processes during the project's rapid growth
Technical needs: Google Analytics may have been intended to understand user usage, identify issues, and improve products, 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 this background understood, the issues in execution remain. This is no longer just about defending the spirit of open source, but about finding a balance between protecting one's rights and maintaining trust in the open-source ecosystem.
The alienation of open source manifests as:
Toolization: Open source becomes a tool for acquiring 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. It is difficult for us 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 issues lie in:
Execution methods: How to change, how to notify, how to handle existing users
Transparency: Whether the decision-making process is public, whether the reasons are adequately explained
Consistency: Whether all similar situations are treated equally
This case exposes more of the systemic issues of the entire Web3 open-source ecosystem lacking mature norms, rather than simply 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; they need to receive due recognition and returns
COAI's demand: Code used legally under the MIT license should not be retroactively required to bear AGPL obligations
The industry's dilemma: How to establish a balance 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, and what is truly needed is the establishment of norms at the industry level.
Issue Two: Lack of Legal Risk Awareness in Startup Teams
The equity dispute between Tinkle and Zack exposes a common issue among crypto startup teams regarding legal compliance.
The chaos of equity distribution:
Zack holds legal documents for 50% equity (registered under APEIRON LABS)
Tinkle believes Zack is only entitled to 10-20% equity (based on code contributions)
This cognitive gap should not exist—equity distribution should be clearly defined and documented from the start
The absence of decision-making records:
Zack claims that he was granted 50% equity based on the promise of bringing in Amber's investment
Tinkle says Zack exaggerated his capabilities and ultimately did not bring in any investment
There are no written records of the agreement conditions at that time: was it "best efforts" or "equity granted upon completion"?
Confusion in communication procedures:
After Zack sent a lawyer's letter, Tinkle did not respond for a month
It was only when Tinkle publicly accused "extortion" that Zack had to publicly retaliate
Why couldn't they negotiate privately first instead of going straight to a public battle?
Abuse of legal tools:
Tinkle referred to the lawyer's letter as "extortion," which is a serious criminal accusation
Zack provided standard business settlement documents to prove that this was a legal procedure
These issues are extremely common in crypto startup teams:
Quick action is prioritized over standardized processes: A "let's get started first" culture leads to many missing legal documents
Dominance of technical thinking: Engineer founders often do not prioritize legal and compliance issues
Illusion of decentralization: Believing that one 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 hidden dangers.
What should be done:
The founding team should have a written equity agreement (Founders' Agreement) from day one
Clearly define each person's type of contribution, equity ratio, and vesting schedule
Keep written records of key decisions (emails, signed documents)
Regularly consult professional lawyers to review company structure and compliance
Seek legal avenues first in case of disputes, rather than resorting to public battles
Issue Three: Severe Disconnection Between Technical Capability and Security Awareness
The security vulnerabilities of Nofx reveal a harsh truth: in the crypto industry, technical capability ≠ security awareness.
Manifestations of capability misalignment:
Nofx is capable of developing an AI automated trading system, which requires considerable technical ability
Yet, at the same time, they committed basic security errors like "zero authentication" and "default keys"
Being able to write functional code does not mean one can write secure code
Fundraising ability does not equate to technical strength:
COAI raised $17 million but was questioned about its coding capabilities
Nofx received enthusiastic community support but frequently encountered security vulnerabilities
In the crypto industry, the ability to tell a story often translates to more funding than actual technical strength
Marginalization of security:
Under the pressure of rapid development, security is seen as something to be addressed "later"
Functionality is prioritized over security, and speed to market is prioritized over code audits
It is only when actual losses occur that the seriousness of the problem is realized
The misconception that open source = security:
Many people believe that open source code is inherently more secure ("millions of eyes")
But the reality is that most users do not look at the code, only the star count
Security audits require expertise and significant time; they do not happen automatically
Special risks of AI Trading:
Involves real user funds, and losses are irreversible
Automated execution means the attack window is short; by the time it is discovered, it is already too late
24/7 operation 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 must prioritize security: It is better to make users feel inconvenienced than to make attackers feel it is easy
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 has unveiled the shameful reality of the endorsement culture in the crypto industry.
Inflation of endorsements:
Almost every project claims to have "support from certain institutions"
But the meaning of these "supports" varies widely
From formal investments to a single conversation, everything can be packaged as "backed by"
The proliferation of gray areas:
"Strategic cooperation": It may just be business matching
"Ecological partners": It may just be mutual retweeting
"Advisory team": It may just be nominal
"Investment institutions": It may just be buying some coins
Why does this culture have a market:
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 means losing at the starting line
Regulatory vacuum: No institution manages the authenticity of endorsements
Vicious cycle:
Project parties 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
Project parties: 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: Comprehensive Absence of Community Governance Mechanisms
In light of Nofx's triple crisis, the deepest issue is that the open-source community lacks effective governance mechanisms.
No arbitration mechanism for protocol disputes:
In the dispute between Nofx and COAI, both sides hold firm to their positions
There is no recognized third party to determine who is right or wrong
They can only rely on public opinion and law, 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 do not have security response teams
Vulnerability disclosure, user notification, and emergency fixes lack standards
No place to appeal equity disputes:
Tinkle and Zack's conflict can only be resolved through law or public opinion
The open-source community lacks a dispute resolution mechanism
DAO governance has been proposed for a long time, but actual operation is rare
Lack of incentives for community participation:
Security audits and code reviews require a significant amount of time
But open-source contributors are often volunteers
Commercial companies have dedicated teams, while open-source projects rely on passion
Attempts at existing governance practices:
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 all parties involved, should include:
Security audit standards: Clearly define which types of projects must undergo audits to be recommended
Dispute arbitration institutions: Neutral third parties to handle protocol 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 financing, endorsements, and equity structure
Root cause 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, quick iterations, and first-mover advantages
Rapid fundraising: Overvaluing fundraising while disregarding compliance details
Rapid growth: Competing on metrics like user numbers, star counts, and community sizes
Rapid monetization: Issuing tokens, listing on exchanges, and cashing out
In this culture:
Security is a burden that slows down progress
Law is a cost that can be minimized
Governance is a hindrance that obstructs 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 potential of open-source collaboration while exposing the various challenges this model faces in reality.
The hacker door reminds us that decentralization does not equal security; the infighting door reveals that disagreements among idealists can be more destructive than external attacks; the open-source door brings a long-standing issue to the forefront: how to protect the rights of open-source contributors in the Web3 world that pursues commercial value?
Particularly noteworthy is that the issue of time recognition in open-source protocol disputes still needs further clarification. This not only relates to the rights and wrongs of specific cases but also concerns the normative construction of the entire Web3 open-source ecosystem. In the future, there may be a need to establish more reliable protocol change record mechanisms and more authoritative third-party arbitration systems.
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 cite the source x@wquguru for any reproduction or adaptation.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
