Original Title: "The Achilles' Heel of Open Source: Nofx with 9000 Stars in 2 Months and Its Hacking Scandal, Internal Conflict, and Open Source Controversy"
Original Author: @wquguru
Writing Background
Before formally starting this story, I need to clarify my position in this event.
I am an observer and analyst. During the explosive rise 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:
• End of October 2025: The Nofx project launched, gaining nearly 9000 stars on GitHub in just 2 months.
• November 2025: Security vulnerabilities were exposed, and SlowMist issued a security warning (Hacking Scandal).
• December 2025: A dispute over the open source license erupted (Open Source Controversy), while internal divisions within the team surfaced (Internal Conflict).
The entire event lasted about 2 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. 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 9000 stars by December, becoming one of the most关注的 open source projects in the AI Trading field.
However, just two months later, this star project fell into a triple crisis:
Hacking Scandal: Blockchain security company SlowMist disclosed that Nofx had serious security vulnerabilities, exposing the API keys, private keys, and wallet addresses of users from over 1000 deployed instances. Major exchanges like Binance and OKX urgently intervened to assist affected users in replacing their credentials.
Internal Conflict: Core member Tinkle publicly accused another co-founder, Zack, of only participating for 14 days, contributing a few lines of code, yet demanding 50% equity and $500,000. Zack, in turn, issued a formal legal document through his lawyer, accusing Tinkle of "embezzling assets and interest transfer," providing partnership registration documents showing both held 50% equity.
Open Source Controversy: Nofx publicly accused ChainOpera AI (COAI), which raised $17 million, 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 changed 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 multiple 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 protocol dispute between Nofx and COAI, we need to understand the fundamental differences between the two open source licenses:
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 source.
• 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.
Protocol 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, there are doubts about the public timing of the license 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 license in effect at the time, COAI should have:
Clearly indicated the source of the code.
Made the modified source code public.
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 exposed deep-seated issues within the Web3 open source ecosystem:
Validity of License Change:
• Retroactive Effect Dispute: Does a change in the open source license bind already forked code?
• Timing Determination: The exact timing of the license change is difficult to fully 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: 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 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 more reliable evidence is needed for judgment.
Legal and Technical Gray Areas:
• The legal effectiveness of open source licenses 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
Based on the currently available evidence, there are multiple doubts regarding Nofx's accusation of COAI's infringement of the open source license:
1. Doubts about Timing: GitHub evidence shows the change to AGPL occurred on November 4.
2. Different Technical Implementations: Identical interface names do not imply identical code.
3. Reasonable Log Explanation: The statistical function inserted during the MIT phase would continue to record.
4. Potential Violations on Their Part: Failure to inform users about the embedded statistics may violate privacy laws.
5. Hasty Communication Procedures: Sending an email and making public accusations within the same minute.
It is worth noting that the dispute over the timing of the license change has a decisive impact on the judgment of the nature of the entire event. If Nofx's claims are valid, COAI indeed has issues with violating the AGPL license; but if COAI's claims are valid, their actions fully comply with the MIT license's 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 controversy is the dispute between Nofx and external parties, then the internal conflict is the publicization of internal contradictions within the project—a struggle over "contribution" and "value" among the founding team.
Timeline: From Joining to Confrontation
October 28, 2025: Nofx began development.
October 29, 2025: Zack joined the project (just one day after the project was open-sourced).
Early November 2025: Zack demanded 50% equity, claiming he could introduce Amber Group for commercialization.
Early November 2025: Tinkle refused to grant 50% equity, believing he was the team’s CEO and CTO, and that Zack's contributions were insufficient.
November 19, 2025: Zack's lawyer (from JunHe Law Firm's Hong Kong office) issued 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 became public, with both sides accusing each other on social media.
From a timing 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 huge 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:
• Provided 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 "embezzlement of assets and interest transfer" actions.
• The $500,000 is not extortion but a legal buyback of Zack's undervalued equity.
• The counter-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, why does Tinkle claim this is "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, if another person only participated for 14 days, the disparity in contribution in terms of time and code volume is indeed significant.
However, from the equity perspective, Zack 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 acknowledges that Zack holds 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 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, the ability 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, trading equity for empty promises, ultimately failing to deliver but refusing to relinquish equity and threatening through a lawyer's letter.
Interpretation B (supporting Zack): The two parties did indeed reach an equity agreement, and Zack made efforts to introduce Amber, but due to issues on Tinkle's side (possibly including "embezzlement of assets and interest transfer"), 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 because extortion is a criminal offense.
But Zack's response reveals the professionalism of legal procedures:
The "Without Prejudice Save as to Costs" is a standard legal procedure in common law systems for settlement negotiations in commercial disputes. Its characteristics are:
Protected by law, 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, detailing 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 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 of Assets and Interest 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 interest exchanges with individuals from investment institutions.
Violating the fiduciary duty of the partnership.
Tinkle did not respond directly to this part of the accusation, only stating that he would no longer respond to the matter and would 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:
1. Verbal Promises vs. Written Agreements: If there is no written equity agreement, how is contribution determined?
2. Technical Contribution vs. Resource Introduction: How are the values of these two measured?
3. Responsibility for Unmet Expectations: Whose responsibility is it when fundraising fails?
4. Legal Procedure vs. Moral Judgment: Does settlement negotiation equate to extortion?
Based on 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 both lack a complete chain of evidence.
The final 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 Do Open Source Projects Become Hotbeds of Security Issues?
Before the protocol dispute between Nofx and COAI and the internal equity dispute, 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 is 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.
• 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:
• apikey: User's exchange API key.
• secretkey: Exchange secret key.
• 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 an exposure of zero protection, a fundamental failure in security design.
November 5, 2025 - Commit be768d9: The Illusion of "Hardening"
Possibly realizing the security issues, 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 the original JSON format.
This means:
• Attackers can use the default key to forge JWT tokens.
• 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.
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 still stuck on the zero authentication version from October 31.
This is not a coincidence 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: SlowMist's 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 1000 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 happening.
Emergency Coordination: Given the urgency of the risk, SlowMist immediately contacted major exchanges:
• Provide intelligence to the security teams of Binance and OKX.
• Both exchanges conduct independent cross-validation.
• Use the obtained API keys to track affected users.
• Notify users and assist in key rotation.
• Prevent potential wash trading attacks.
Processing Progress: As of November 17, 2025, all exposed keys of centralized exchange (CEX) users have been processed. However, some Aster and Hyperliquid users are difficult to reach directly due to wallet decentralization and need to self-check.
Impact Scope: Not 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.
• Involves multiple platforms including Binance, OKX, and 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.
Trust Collapse:
• The community has lost confidence in the security of the Nofx project.
• Doubts arise about the entire open-source AI Trading ecosystem.
• Developers become more cautious when choosing open-source projects.
Deep Inquiry: 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 plaintext.
- 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:
1. Rapid Development Priority: In the AI Trading boom, seizing the opportunity is deemed more important than security.
2. Insufficient Team Experience: There may be a lack of security experience in handling user funds.
3. Testing Environment Configuration in Production: Authentication was disabled for testing convenience, and this configuration ended up in the production environment.
4. Lack of Security Audits: Open-source projects often lack professional security audits.
But the fundamental reason may be: Open Source ≠ Security.
Many people believe that open-source code means "millions of eyes" are reviewing it, making it safer. But the reality is:
• Most users are just users, not reviewers.
• Even if issues are discovered, there may not be the capability 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: "Software is provided 'as is', without any express or implied warranties… Authors are not liable for any damages."
But from a moral standpoint, 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 received over 9,000 stars and has a large user base.
- The vulnerabilities are not hidden advanced attacks but a lack of basic protections.
- The issues persisted for weeks, during which new users continued to deploy.
Industry Insights: The Unique Risks of AI Trading
The security crisis of Nofx reveals the unique risks in the AI Trading field:
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 that their assets have been transferred hours later.
The Contradiction of Open Source and Security:
• Open source helps improve and review by the community.
• 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 use default configurations without knowing 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:
1. Rapid Response: Immediately conducted in-depth analysis upon receiving intelligence.
2. Proactive Scanning: Did not wait for user reports but actively discovered affected instances.
3. Industry Collaboration: Worked closely with exchanges rather than fighting alone.
4. Public Disclosure: Released a detailed report after handling the emergency, educating the community.
5. Clear Position: 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:
1. Open-source projects need security audits: Even rapidly iterating projects cannot skip security checks.
2. Default configurations should prioritize security: Convenience for development and convenience for attacks are often two sides of the same coin.
3. User funds must be treated with special care: In systems involving money, security is an uncompromising bottom line.
4. The community needs to establish a security response mechanism: SlowMist's actions provide a good example.
5. 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 erupted, if you visited Nofx's Twitter profile, you would see this line in the bio: Backed by @amberac.
What does this mean? In the crypto industry,
"backed by" usually means:
• 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 funds and resources. amber.ac is its ecosystem accelerator. For an emerging open-source project, receiving Amber's endorsement means:
1. Credit Endorsement: The project is more credible, attracting more users.
2. Financing Convenience: Other investors are more willing to follow suit.
3. Resource Support: Possible access to technical, market, legal, and other support.
4. Community Confidence: Users are more willing to participate and contribute.
This is like an entrepreneur receiving a term sheet from a top VC; even if the money hasn't been received 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, obtaining endorsement from a top institution could be a key leap from 0 to 1.
• Distributing 50% equity in the early stages 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 causing a stir, amber.ac released an official statement:
"There is 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 cooperation will have official announcements.
- 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 the statement, the community discovered that Nofx had quietly removed the phrase "Backed by @amberac" from its Twitter bio.
Some netizens questioned this, and Nofx's editor responded: "We appreciate 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:
1. What is "early support": If there is no formal cooperation, what does support refer to?
2. "The other party's request" to delete: Did Amber actively request the severance?
3. "Current events" impact: Was the deletion requested because of the scandal?
From Amber's perspective, this severance is necessary:
• Nofx is mired in security vulnerabilities, equity disputes, and protocol disputes.
• 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 that was once a point of pride suddenly disappears.
• The impression given to the outside world is "even the investors have run 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. 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 a gray area between the two:
• There have been 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 ultimately, they did not translate into investment.
The Proliferation of Endorsement Culture: A Common Issue 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:
1. Certain institutions lead the investment: In reality, it may just be a small follow-on investment.
2. Certain big names endorse: They may have just retweeted something.
3. Certain accelerators incubate: They may have only participated in a workshop.
4. Certain exchanges cooperate: They may have just submitted a listing application.
The Real Value Chain of Endorsement:
• Top Level: Formal investment agreements, clearly stating 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 Investment Institutions Tolerate This Ambiguity:
1. Expanding Influence: More projects mentioning themselves, expanding their brand.
2. Option Thinking: Establishing weak connections first, which may later translate into investment.
3. Minimal Effort: The cost of a single exchange is low, but it holds significant value for the project side.
4. Gray Benefits: Some institutions may charge "consulting fees" or "brand usage fees."
Why Project Parties Are Keen on This:
1. Financing Needs: Having endorsements makes it easier to secure subsequent financing.
2. User Trust: The community is more willing to trust projects with institutional endorsements.
3. Competitive Pressure: Other projects are promoting endorsements, and not mentioning it would put them at a disadvantage.
4. Vanity Psychology: Founders also need this kind of recognition.
Reflection: Where Are the Boundaries of Endorsement Responsibility?
The Nofx-Amber incident raises a profound question: When an institution's name is used for endorsement, how much responsibility should it bear?
If Amber Had Really 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 Just "Friendly Exchanges":
• Amber has no legal obligations.
• However, if the project party uses its name for endorsement, Amber should correct it in a timely manner.
• If they are aware of the misuse and do not stop it, 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 it 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:
1. For Project Parties: Do not exaggerate relationships with institutions; false endorsements will eventually be exposed.
2. For Investment Institutions: Clearly define the boundaries of endorsements, promptly correct misuse, and bear corresponding responsibilities.
3. For Users: Learn to identify genuine endorsements, verify through official channels of investment institutions.
4. 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 Turmoil Expose?
When we detach from specific accusations and rebuttals and step 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 raising $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 itself is a legal and widely used open-source license.
• Unequal Interests: 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: Faced with competitors having $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 problems that objectively exist are:
1. No Notification to the Community: The license change was not announced in the community, and developers who had already used the MIT version may be unaware.
2. Retroactive Enforcement: Using the agreement changed on November 4 to pursue actions from November 3.
3. Selective Accusations: Why specifically accuse COAI and not other projects using the MIT version?
4. Privacy Data Collection: Google Analytics was embedded during the MIT phase, collecting user data without informing users.
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 neglected proper community communication processes during the project's rapid growth phase.
• Technical Needs: Google Analytics may have been intended to understand user usage, identify issues, and improve products rather than maliciously collecting data.
• Resource Pressure: Faced with well-funded commercial competition, open-source projects indeed lack equivalent legal and market resources.
However, even understanding this background, the issues with execution still exist. This is no longer just a matter of 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 as:
• Toolization: Open source becomes a tool for acquiring users and attention rather than an end goal.
• 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 the rules at will.
This judgment needs to be cautious. 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 issue lies in:
1. Execution Method: How to change, how to notify, how to handle existing users.
2. Transparency: Whether the decision-making process is public and whether the reasons are adequately explained.
3. 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 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; 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 afterward.
• 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.
Confusion in 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.
Lack of Decision-Making Records:
• Zack claims 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.
• Neither party has written records of the agreement conditions at that time: was it a best-effort basis or completion that would grant equity?
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 Zack of extortion that Zack had to publicly retaliate.
• Why could they not negotiate privately first instead of going straight to a public battle?
Abuse of Legal Tools:
• Tinkle claims the lawyer's letter is extortion, which is a serious criminal accusation.
• Zack provided standard business settlement documents, proving this was a legal procedure.
These issues are extremely common in crypto startup teams:
1. Rapid Action Over Standard Processes: The culture of "let's get it done first" leads to many missing legal documents.
2. Dominance of Technical Thinking: Engineer founders often do not prioritize legal and compliance matters.
3. Decentralization Illusion: The belief that one can bypass traditional laws in the crypto world.
4. 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 contribution type, equity ratio, and vesting schedule.
• Key decisions should be documented in writing (emails, signed documents).
• Regularly consult professional lawyers to review company structure and compliance.
• Seek legal avenues first in case of disputes, rather than engaging in public battles.
Issue Three: Serious 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 AI automated trading systems, which requires considerable technical ability.
• Yet, they simultaneously commit 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 Represent Technical Strength:
• COAI raised $17 million but was questioned about its coding capabilities.
• Nofx received enthusiastic community support, yet frequently encountered 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 seen as something to be addressed "later."
• Functionality takes precedence over security, and speed to market takes precedence over code audits.
• It is only when actual losses occur that the seriousness of the problem is realized.
The Misunderstanding That Open Source Equals Security:
• Many believe that open source code is inherently more secure ("millions of eyes").
• However, the reality is that most users do not look at the code; they only look at the star count.
• Security audits require expertise and significant time; they do not happen automatically.
Special Risks of AI Trading:
• Involves real user funds, making losses irreversible.
• Automated execution means attack windows are short; by the time issues are discovered, it is too late.
• Operating 24/7 amplifies the impact of security issues.
Lessons from the Nofx Case:
1. Security is a Bottom Line, Not an Option: Systems involving user funds must undergo professional security audits.
2. Default Configurations Must Prioritize Security: It is better to inconvenience users than to make it easy for attackers.
3. Rapid Iteration is Not an Excuse: MVPs can be functionally simple but must not be security weak.
4. 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 unveiled the shameful reality of endorsement culture in the crypto industry.
Inflation of Endorsements:
• Almost every project claims to have "support from certain institutions."
• However, the meaning of these "supports" varies widely.
• From formal investments to a casual chat, anything can be packaged as "backed by."
Proliferation of Gray Areas:
• Strategic cooperation: may just be business matching.
• Ecological partners: may just be mutual retweets.
• Advisory teams: may just be nominal.
• Investment institutions: may have only bought a small amount of coins.
Why This Culture Has a Market:
1. Information Asymmetry: Ordinary users find it difficult to verify the authenticity of endorsements.
2. Herd Mentality: "If someone invested, it must be reliable."
3. Competitive Pressure: Not promoting endorsements means losing at the starting line.
4. Regulatory Vacuum: No institutions manage the authenticity of endorsements.
Vicious Cycle:
• Project parties exaggerate endorsements → Gain more attention and funding.
• Seeing successful cases, more projects imitate.
• Investment institutions tacitly approve ambiguous relationships for influence.
• When projects encounter issues, institutions rush to disassociate.
• Users and the industry bear the losses.
How to Break the Cycle:
1. Investment Institutions: Establish an official investment portfolio list, clearly stating investment amounts and dates.
2. Project Parties: Only promote verifiable formal relationships and provide proof documents.
3. Media and KOLs: Verify the authenticity of endorsements before reporting.
4. Users: Learn to verify and not blindly trust endorsements.
5. Regulation: Penalize false endorsements (some jurisdictions have already begun).
Issue Five: Comprehensive Absence of Community Governance Mechanisms
Considering the triple crisis of Nofx, the deepest issue is that the open-source community lacks effective governance mechanisms.
Protocol Disputes Lack Arbitration Mechanisms:
• The dispute between Nofx and COAI has both sides sticking to their claims.
• There is no recognized third party to determine who is right or wrong.
• Reliance is only on public opinion and law, the former being unjust and the latter costly.
Security Issues Lack Standard Processes:
• SlowMist's timely response is an exception, not the norm.
• Most open-source projects lack security response teams.
• Vulnerability disclosure, user notification, and emergency fixes lack standards.
Equity Disputes Have No Place for Appeals:
• The conflict between Tinkle and Zack can only be resolved through law or public opinion.
• The open-source community has no 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 significant time.
• However, 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, Balance, and Users Should Include:
1. Security Audit Standards: Clearly define which types of projects must undergo audits to be recommended.
2. Dispute Arbitration Institutions: Neutral third parties to handle protocol and equity disputes.
3. Responsibility Disclosure Processes: How to notify, fix, and announce after discovering vulnerabilities.
4. Community Participation Incentives: Reward contributors through tokens, NFTs, or other means.
5. Transparency Requirements: Mandatory disclosure of key information such as financing, endorsements, and equity structures.
Root Causes of Systemic Issues: The Game 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 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, 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 Gate reminds us that decentralization does not equal security; the Infighting Gate reveals that disagreements among idealists can be more destructive than external attacks; the Open Source Gate brings to the forefront a long-standing issue: 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 determination issue 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.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
