Open Source Achilles' Heel: Nofx and Its 9,000-Star Drama, Forking Fiasco, and Open Source Controversy

Original Article Title: "Achilles' Heel of Open Source: Nofx and Its 2-Month, 9000-Star Journey Through Hacks, Infighting, and Open Source Drama"

Original Article Author: @wquguru

Writing Background

Before delving into this story, I need to clarify my position in this event.

I am an observer and analyst. During the peak of the Nofx project, I had developed the nof0 project, drawing inspiration from nof1. Throughout the development, I had communications with Nofx's core members, Tinkle and Zack, mainly regarding technical implementations and open-source collaboration.

It is essential to note that my interactions with the Nofx team were purely technical, with no business partnership involved. I had no direct contact with the ChainOpera AI (COAI) team. As I write this article, I strive to maintain an objective and neutral stance. All analyses and judgments are based on publicly available information, including GitHub records, social media posts, security reports, etc.

Timeline of Events:

• Late October 2025: The Nofx project was launched, and within a short span of 2 months, it gained nearly 9000 stars on GitHub.

• November 2025: A security vulnerability was exposed, and SlowMist issued a security advisory (Hackgate).

• December 2025: An open-source license dispute erupted (Open Source Drama), coinciding with internal team rifts coming to light (Infighting).

The entire event spanned about 2 months but starkly exposed multiple contradictions within the Web3 open-source movement.

The purpose of writing this article is not to take sides or blame any party but rather to:

• Provide a comprehensive account of this typical case in the Web3 open-source movement
• Explore the deep-seated conflicts between open-source ethos and commercial interests
• Offer reflection and references for the industry's future standardization efforts

Now, let's start untangling this intricate story from the beginning.

Act I: The Explosive Rise of an AI Trading Project

In late October 2025, an AI automated trading project named Nof1 lit up on Twitter. Within a few days, several open-source variations—including nof0, nofx, and others—garnered thousands of stars on GitHub. Among these, the Nofx project, which commenced development at the end of October, had amassed over 9000 stars by December, emerging as one of the most prominent open-source projects in the AI Trading domain.

However, just two months later, this once-promising project found itself in a triple crisis:

Hack Gate: Blockchain security company SlowMist disclosed a serious security vulnerability in Nofx, exposing the exchange API keys, private keys, and wallet addresses of over 1000 deployed instances on the network. Major exchanges such as Binance and OKX intervened urgently to assist affected users in credential replacement.

Internal Strife Gate: Core project member Tinkle publicly accused co-founder Zack of only being involved for 14 days, contributing a few lines of code, yet demanding a 50% ownership stake and $500,000. Zack, in turn, through legal representation, accused Tinkle of asset embezzlement, profit diversion, and provided partnership registration documents showing a 50% stake for each party.

Open Source Gate: Nofx publicly accused ChainOpera AI (COAI), which raised $17 million, of violating the AGPL open-source license by deploying a commercial product using its code without open-sourcing it. COAI countered, stating that Nofx was still under the MIT license on November 3 and only switched to AGPL on November 4, and their product was developed in Python, completely different from Nofx's Go implementation.

How did an open-source project embraced by the community find itself entangled in such a complex crisis within a mere two months? What systemic issues within the open-source community, entrepreneurial teams, and investment ecosystems does this expose? Let's delve into this controversy through five key questions.

Question 1: Was the Open Source License Actually Violated?

MIT vs. AGPL: Two Divergent Open Source Philosophies

Before discussing the license dispute between Nofx and COAI, we need to understand the fundamental differences between these two open-source licenses:

MIT License (Massachusetts Institute of Technology License) is one of the most permissive open-source licenses. It allows:

• Free use, modification, distribution of code
• Commercial use without the requirement for open-sourcing
• Sole condition: retaining the original copyright notice

AGPL v3.0 (GNU Affero General Public License) is one of the strictest open-source licenses. It mandates:

• Any project using this code must also be open source
• Specifically, even when providing a service over the network (such as SaaS), the source code must be made public
• Original project information must be prominently displayed

From MIT to AGPL is a 180-degree shift from "extremely permissive" to "extremely strict." This is also at the core of the current controversy.

Protocol Change and Time Dispute

The open-source license of the Nofx project was changed from MIT to AGPL, but the specific timing of this change has become a focal point of dispute. This timeline is crucial because it directly determines the protocol that the ChainOpera (COAI) team should adhere to when forking the code.

Evidence Comparison from Both Sides:

• The Nofx team provided GitHub commit records showing the modification time of the license file
• The COAI team, on the other hand, points out that based on their records and observations, there are doubts about the public timing of the protocol change

ChainOpera's Plagiarism Accusations

The Nofx community discovered that ChainOpera (COAI), which raised $17 million and launched on Binance Alpha, had code highly similar to Nofx.

Accusations from the Nofx Side:

• COAI used Nofx's code without attributing the source and without making the source code public
• According to the effective AGPL license at that time, COAI should:
Clearly indicate the source of the code
Make the modified source code public
Adopt the AGPL license as well

Response from the COAI Side:

• They claim that when they forked the code, Nofx was still using the MIT license
• The MIT license allows for commercial use without the need to open-source the code
• The dispute over the timing of the license change affects the nature of the entire event

Open Source License Dispute: Who's Right and Who's Wrong?

This dispute has exposed deep-seated issues in the Web3 open-source ecosystem:

Validity Issue of Protocol Change:

• Retroactive Effect Dispute: Does an open-source license change apply retroactively to code that has already been forked?

• Timestamp Ambiguity: The exact time of the protocol change is difficult to ascertain, with each party sticking to their own version of events

• Evidence Integrity: GitHub records could have been altered, requiring a more authoritative third-party validation

• Protocol Change Dissemination: Changing from MIT to AGPL, to what extent was this message conveyed to the community

Business Interest Conflict:

• COAI receiving substantial funding and listing on Binance, significant commercial value
• Nofx, as an open-source project, lacks a clear commercialization path

• Core Conflict: The delicate balance between the open-source ethos and safeguarding commercial interests

Community Opinion Divergence:

• Supporters of Nofx argue that COAI is leveraging open-source code for profit without giving back to the community
• Supporters of COAI argue that the MIT license permits commercial use and raise doubts about the timing of the protocol change
• Neutral observers point out that the timing dispute is crucial and more reliable evidence is required for judgment

Legal and Technical Gray Areas:

• The legal enforceability of open-source licenses in on-chain projects remains unclear
• The tamperability of GitHub records undermines their evidentiary credibility
• The Web3 industry lacks a mature open-source dispute resolution mechanism

Summary: An Controversial Allegation

Based on the currently available evidence, Nofx's open-source license infringement allegations against COAI raise several doubts:

1. Questionable Timestamp: GitHub evidence indicates the switch to AGPL on November 4th

2. Differential Technical Implementation: Same interface names do not necessarily imply identical code

3. Reasonable Log Interpretation: The statistics feature inserted during the MIT phase would continue to log

4. Self-Implication in Wrongdoing: Failure to inform users about embedded analytics might breach privacy laws

5. Hasty Communication Process: Simultaneous email and public accusation within minutes

It is worth noting that the dispute over the protocol change time has a decisive impact on the nature of the entire event. If Nofx's claim is valid, COAI does indeed have issues with violating the AGPL license; but if COAI's claim is valid, their actions are in full compliance with the MIT license. The determination of this time point still requires more authoritative third-party verification.

Issue 2: Can 14 Days Entitle to 50% Equity?

If the open-source gate is considered the dispute between Nofx and external parties, then the internal struggle gate is the publicization of internal conflicts within this project—a founder team battle over "contribution" and "value."

Timeline: From Joining to Confrontation

October 28, 2025: Nofx starts development

October 29, 2025: Zack joins the project (at this point, the project was just open-sourced a day ago)

Early November 2025: Zack demands 50% equity, stating that he can introduce Amber Group for commercialization

Early November 2025: Tinkle refuses to give 50% equity, claiming to be the team's CEO and CTO, and considers Zack's contribution insufficient

November 19, 2025: Zack's lawyer (from JunHe LLP Hong Kong office) sends a formal "Without Prejudice Save as to Costs" equity buyback demand letter requesting $500,000 to repurchase Zack's 50% equity

December 2025: Publicization of the conflict, with both sides accusing each other on social media

From a timeline perspective, from joining to sending a legal letter, Zack's timeline is less than a month, which is indeed very short.

Standoff: Two Completely Different Sets 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 with thousands of Telegram group members
• Used introducing Amber investment as leverage to demand a large equity share
• Held the project's Twitter account hostage after the request was denied
• Demanded $500,000 through a legal letter, with allegations of extortion
• Zack was a former Amber intern but left before conversion
• Ultimately failed to bring in Amber investment

Zack's Counterattack:

• Provide APEIRON LABS PTE. LTD.'s company registration documents
• Documents show: Tinkle and Zack each hold 50% ownership
• This is public information in the Singapore company registration system, verifiable by anyone
• The lawyer's letter is a standard "no-prejudice settlement offer," in line with commercial legal procedures
• The subject is a Demand Letter, detailing Tinkle's actions of "misappropriation of assets, profit shifting"
• The $500,000 is not extortion but a buyback of Zack's legitimate ownership at a discounted valuation
• Counter-question: If the company holds value, wouldn't it be reasonable to buy back 50% ownership at a $1 million valuation? If it holds no value, why would Tinkle refer to this as "extortion"?

Core Contradiction: How is contribution quantified?

The essence of this dispute is an age-old entrepreneurial dilemma: Technical Contribution vs Resource Referral, which is more valuable?

From the perspective of code contribution, Tinkle's argument may have some merit. GitHub's commit history is public, and if Zack has indeed made only a small number of code commits, this is easily verifiable in the tech community. In a project with a development period of 60 days, if one person is involved for 14 days, there is indeed a significant disparity in contribution in terms of time and code volume.

But from an ownership perspective, Zack has presented legal documents. The registration information of APEIRON LABS PTE. LTD. shows that both parties signed a 50-50 equity allocation agreement. This implies:

1. Both parties had previously entered into a formal legal agreement

2. The agreement acknowledges Zack's 50% ownership

3. This is not a verbal commitment but a legal fact registered with a government entity

So, the question arises: Why did Tinkle agree to such an equity split?

How much is the Ace of Amber worth?

The key variable is the Amber Group—or more precisely, Amber's ecosystem accelerator, amber.ac

Zack's trump card is: his ability to introduce Amber to participate in Nofx's commercialization. According to Tinkle, Zack was previously an intern at Amber (although he left before being converted to a full-time employee). In the crypto industry, securing the endorsement and funding of a top-tier institution through introductions can indeed hold immense value.

But the ultimate result is:

1. Amber did not formally invest in Nofx

2. Official Amber statement: No formal "incubation, investment, or business partnership" with Nofx

3. Amber acknowledges: There was "friendly communication," but it did not lead to a formal collaboration

This has led to two possible interpretations:

Interpretation A (supporting Tinkle): Zack exaggerated his resource capabilities, exchanged empty promises for equity, ultimately failed to fulfill the commitment, yet refused to hand over the equity and resorted to threats through a lawyer's letter.

Interpretation B (supporting Zack): Both parties did reach an equity agreement, Zack made efforts to onboard Amber, but issues on Tinkle's end (potentially including "asset embezzlement, siphoning of benefits") prevented the investment from materializing. Zack, as a legitimate shareholder, has the right to request an exit and compensation.

Which interpretation is closer to the truth? More internal documentation is needed to determine that.

Legal Procedure or Extortion?

Tinkle publicly shared Zack's lawyer's letter on social media, referring to it as "extortion." This accusation is severe as extortion is a criminal offense.

However, Zack's response revealed the professionalism of the legal process:

“Without Prejudice Save as to Costs” is a standard legal procedure in the Anglo-American legal system used for settlement negotiations in commercial disputes. Its characteristics are:

1. Legally protected and cannot be used as evidence in litigation (except concerning litigation costs)

2. Aimed at encouraging both parties to amicably resolve the dispute

3. Settlement proposals do not constitute extortion

4. The document is a Demand Letter, outlining the other party's breach or infringement

Zack's lawyer's letter requests $500,000, but this amount is based on:

• The legal fact that Zack holds 50% ownership of the company
• Computed based on a conservative valuation of $1 million for the company
• Requesting Tinkle to buy out Zack's equity as a repurchase price

From a legal standpoint, this is a completely legal settlement negotiation strategy. If Tinkle indeed believes this is "extortion," the correct action would be to report it to the authorities rather than tweet about it.

Zack's "final warning" was also quite strong: "If you truly believe this is extortion, please report it to the police immediately. If you don't have the courage to report it, then please stop this absurd performance."

Hidden Accusation: Asset Misappropriation and Benefit Diversion

One noteworthy detail in this public standoff is that Zack mentioned the demand letter's main body is a detailed demand letter, documenting Tinkle's "misappropriation of partnership assets and conspiracy to commit illegal means" behavior

The full content of this letter has not been made public, but this accusation is very serious. If true, it could involve:

1. Misappropriating company funds for personal use

2. Engaging in personal benefit exchanges with investment institutions

3. Violating fiduciary obligations of the partnership enterprise

Tinkle did not provide a direct response to these accusations, only stating that they will no longer address the issue and will focus on product development.

This evasive attitude actually raises curiosity: What exactly was written in the demand letter?

Conclusion: An Unsolvable Dilemma

Equity disputes within founding teams are not uncommon in the startup world. The Nofx case has attracted attention because it encapsulates the typical contradictions of such disputes:

1. Verbal Commitments vs. Written Agreements: How is contribution recognized without a written equity agreement?

2. Technical Contribution vs. Resource Referral: How are two types of value measured?

3. Responsibility for Unmet Expectations: Whose fault is it when fundraising fails?

4. Legal Process vs. Moral Judgment: Is settlement negotiation equivalent to extortion?

Based on the existing evidence:

• Zack has legal documents supporting his 50% ownership
• Tinkle has code contribution records supporting their leading position
• Both parties have their own narratives, but lack a complete chain of evidence

The final answer may only come from a court. However, this case serves as a warning to all startup teams:

• Equity allocation should be done early, in writing, and clearly defined
• Contribution quantification should have objective standards (lines of code, working hours, resource value)
• Major decisions should be documented
• In case of disputes, prioritize legal avenues over public opinion battles

Question 3: Why Has Open Source Projects Become a Security Hotspot?

Prior to the dispute between Nofx and COAI over protocols and internal equity disputes, a more severe crisis quietly brewed: security vulnerabilities.

In November 2025, the blockchain security company SlowMist released a detailed security analysis report, revealing serious security vulnerabilities in the Nofx project. This was not your typical "small bug," but a major flaw that could lead to widespread fund theft by users.

Vulnerability Timeline: From Zero Authentication to Default Key

October 31, 2025 - Commit 517d0c: The Original Sin of Zero Authentication

In this commit, Nofx's code contained a fatal flaw:

• admin_mode set to true by default
• Middleware allowing all requests to pass without validation
• /api/exchanges endpoint completely open

What does this mean? Anyone who knows a server address where Nofx is deployed can directly access the /api/exchanges endpoint to retrieve:

• api_key: User's exchange API key
• secret_key: Exchange secret key
• hyperliquid_wallet_addr: Hyperliquid wallet address
• aster_private_key: Aster platform private key

With this information, an attacker can:

1. Take full control of the user's exchange account

2. Engage in wash trading

3. Directly withdraw funds

4. Manipulate market prices

This is a zero-protection exposure, a fundamental error in security design.

November 5, 2025 - Commit be768d9: The Illusion of "Fortification"

Possibly realizing the security issues, the Nofx team introduced a JWT (JSON Web Token) authentication mechanism in this commit. At first glance, this appeared to be a security reinforcement.

However, the issue lies in:

1. The default jwt_secret has not been changed

2. If a user does not set the environment variable, the system falls back to the hard-coded default key

3./api/exchanges still returns all sensitive fields in the original JSON format

This means:

• Attackers can forge a JWT token using the default key
• Once a valid token is obtained, all keys are still fully exposed
• The "hardened" version remains vulnerable in reality

This is like putting a lock on a door but leaving the key under the doormat for everyone to find.

November 13, 2025 - Dev Branch: Ongoing Vulnerabilities

Even by November 13, the code in the dev branch still has multiple issues:

• There are still flaws in the authMiddleware implementation (api/server.go:1471–1511)
• /api/exchanges continues to directly return the complete ExchangeConfig (api/server.go:1009–1021)
• The configuration file still hardcodes admin_mode=true and the default jwt_secret
• The main branch (origin/main) is still on the zero-auth version as of October 31

This is not a mere oversight but a systemic lack of security awareness.

Discovery and Response: SlowMist's Key Actions

Intelligence Source: Security researcher @Endlessss20 provided initial intelligence to SlowMist about Nofx's security vulnerabilities.

In-Depth Analysis: SlowMist's security team conducted a comprehensive audit of Nofx's GitHub code, identifying the two main authentication issues mentioned above.

Internet-Wide Scan: More shockingly, SlowMist performed an internet-wide scan and found over 1000 publicly accessible Nofx deployment instances, many of which were using default or vulnerable configurations, exposing user credentials entirely.

This is not a theoretical security risk, but a real-world threat that is happening.

Urgent Coordination: Given the urgency of the risk, SlowMist immediately contacted major exchanges:

• Provided intelligence to the security teams of Binance and OKX
• Both exchanges independently conducted cross-validation
• Tracked affected users using obtained API keys
• Notified users and assisted in key rotation
• Prevented potential wash trading attacks

Progress Update: As of November 17, 2025, all Centralized Exchange (CEX) users' exposed keys have been dealt with. However, some Aster and Hyperliquid users, due to wallet decentralization, are difficult to directly reach 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:

• 1000+ users using Nofx for automated trading
• Involving multiple platforms like Binance, OKX, Hyperliquid, etc.
• Exposed data includes not only API keys but also private keys and wallet addresses

Potential Losses:

• If the attacker acted before exchange intervention, users' funds could be completely stolen
• The AI automated trading system's nature is high-frequency and high-volume, so the losses could be staggering

Trust Erosion:

• 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 in choosing open-source projects

Deep Questions: Why such a basic error?

Nofx's security vulnerability is not a profound technical challenge but rather basic security common sense:

1. Authentication mechanisms should be enabled by default, not disabled by default

2. Default keys should be randomly generated, not hard-coded

3. Sensitive data should be encrypted or anonymized, not returned in clear text

4. Configuration files should explicitly warn of security risks

These are principles that any experienced developer should know. So why did Nofx make these mistakes?

Possible reasons:

1. Emphasis on Quick Development: In the AI Trading frenzy, seizing opportunities was considered more important than security

2. Inexperienced Team: There may have been a lack of experience in handling user funds securely

3. Testing Environment Mirrored Production: Authentication was disabled for testing convenience, and this configuration made its way into the production environment

4. Lack of Security Audit: Open-source projects often lack professional security audits

But the most fundamental reason might be: Open Source ≠ Secure.

Many people believe that open-source code means "many eyes looking out for issues," thus making it more secure. However, the reality is:

• Most users are merely consumers, not reviewers
• Even if issues are found, not everyone may have the capability or willingness to submit fixes
• Security audits require expertise and significant time
• Commercial companies have security teams, whereas open-source projects often do not

Boundary of Responsibility: How much responsibility should an open-source author bear?

This raises a contentious question: Should open-source authors be held responsible when users suffer losses due to vulnerabilities in the software?

From a legal perspective, most open-source licenses (including MIT and AGPL) have disclaimers: "The software is provided as is, with no warranties... The author shall not be held liable for any damages"

However, from an ethical standpoint, when you know that your code will be used to manage real assets, should there be a higher security standard?

Nofx's case is unique in that:

1. It's an AI automated trading system directly involving user funds

2. The project has received 9000+ stars and has a large user base

3. The vulnerability was not a sophisticated covert attack but rather a basic security oversight

4. The issue persisted for weeks, during which new users continued to deploy the system

Industry Insight: Unique Risks of AI Trading

The Nofx Security Incident has revealed 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 swiftly execute numerous trades
• Users may not realize their assets have been transferred until hours later

The Conflict Between Open Source and Security:

• Open source aids community improvement and review
• However, it also makes it easier for attackers to discover vulnerabilities
• Vulnerabilities are often disclosed before security patches are complete

Lack of User Education:

• Many users do not understand the risks of deploying AI trading systems
• They use default configurations without changing keys
• Services are exposed to the public internet without basic security protections

The Significance of SlowMist

In this incident, SlowMist's actions are commendable:

1. Rapid Response: Promptly conducted in-depth analysis upon receiving intelligence

2. Proactive Scanning: Did not wait for user reports, actively discovered affected instances

3. Industry Collaboration: Worked closely with exchanges instead of acting unilaterally

4. Public Disclosure: Released a detailed report after handling the emergency situation to educate the community

5. Clear Stance: Emphasized that this was not criticism but risk mitigation

This Responsible Disclosure mechanism is the cornerstone of industry security

Conclusion: Open Source is not a Silver Bullet

The Nofx security vulnerability incident teaches us:

1. Open Source Projects Require Security Audits: Even for rapidly iterating projects, security checks cannot be skipped

2. Security Should Take Precedence in Default Configurations: Convenience in development and ease of attack are often two sides of the same coin

3. User Funds Must Be Treated with Special Care: In systems involving money, security is a non-negotiable 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 being able to write secure code

Question 4: How Much is Amber's "Endorsement" Really Worth?

In Nofx's multi-layered crisis, there is one detail that is easily overlooked but reveals a common issue in the crypto industry: the endorsement culture

The Emergence of Endorsements: Backed by @amber_ac_

Prior to the incident, if you visited Nofx's Twitter page, you would see this line in the bio: Backed by @amber_ac_

What does this mean? In the crypto industry,

「backed by」 usually means:

• Received investment from the organization
• Or at least received an incubation support
• Is an officially recognized relationship

The Amber Group is a well-known entity in the crypto industry with significant funds and resources. amber.ac is its ecosystem accelerator. For an emerging open-source project, getting an endorsement from Amber means:

1. Credibility Endorsement: The project is more trustworthy, attracting more users

2. Easier Fundraising: Other investors are more willing to follow suit

3. Resource Support: Potential technical, marketing, legal, etc., support

4. Community Confidence: Users are more willing to participate and contribute

It's like an entrepreneur receiving a term sheet from a top VC; even without the money, just the endorsement brings tremendous value.

Zack's Bargaining Chip: I Can Bring in Amber

Going back to the background of the internal strife, an important bargaining chip for Zack to request a 50% stake is: he can introduce Amber to participate in Nofx's commercialization.

According to Tinkle, Zack was formerly an intern at Amber. In the industry, this background implies a certain level of networking resources. Zack promised Tinkle that he could introduce Amber's investment or incubation support. In exchange, he requested a 50% stake.

From a business logic perspective, this transaction makes sense:

• If Zack can indeed bring in Amber's investment, then this value far outweighs a 14-day code contribution
• For an open-source project, receiving endorsement from a top institution may be a pivotal leap from 0 to 1
• Allocating 50% equity to a resource referrer is not unheard of in the early stages of a startup

But the key question is: Did Amber eventually come through?

Ambiguity from Amber: No formal incubation, investment, or business partnership

In December 2025, amidst Nofx's internal strife and open-source debacle, amber.ac released an official statement:

“No formal incubation, investment, or business partnership with Nofx. We have engaged in friendly communication with Nofx based on industry observation, but these interactions have not led to any formal collaboration. All our formal partnerships will be announced on the official website.”

This statement is nuanced:

1. Denial of formal relationship: No investment, no incubation, no business cooperation

2. Acknowledgment of contact: “friendly communication,” “industry observation”

3. Emphasis on process: Formal collaborations will be officially announced

4. Drawing boundaries: This is a public disassociation

So the question arises: How significant is the gap between “friendly communication” and being “backed by”?

Endorsement's vanishing act: Deleting and explaining

Shortly after Amber's statement, the community noticed that Nofx quietly removed the mention of “Backed by @amber_ac_” from their Twitter bio.

Some netizens questioned this, and Nofx’s social media manager responded: “Appreciating Amber's early support, due to current events and the other party's request, respecting the wish to delete.”

This response raised new questions:

1. What is “early support”: If there was no formal collaboration, what does support refer to?

2. Request for deletion by the other party: Did Amber voluntarily request the dissociation?

3. Impact of “current events”: Was the deletion requested due to a scandal?

From Amber's perspective, this dissociation was necessary:

• Nofx Involved in Security Vulnerability, Equity Dispute, Protocol Dispute
• Any association with Nofx could harm Amber's reputation
• Especially if users suffer losses due to using Nofx, Amber does not want to assume any responsibility

From Nofx's perspective, this removal is quite embarrassing:

• The originally proud endorsement suddenly disappears
• Giving the impression to the outside world that "even the investors have run away"
• Further undermining community confidence

「Ecosystem Accelerator」 vs 「Formal Investment」: Gray Area

amber.ac is positioned as an "ecosystem accelerator," rather than a direct investment fund. The ambiguity of this positioning is precisely the root of the problem.

An ecosystem accelerator typically provides:

• Mentor guidance and industry advice
• Community resources and network connections
• Event participation and brand exposure
• But may not necessarily provide direct funding

A formal investment relationship includes:

• Clear investment amount and equity percentage
• Legal documents (investment agreement, shareholder agreement)
• Board seat or observer rights
• Regular financial and operational reporting

The relationship between Nofx and amber.ac may fall into the gray area between the two:

• There has been some communication and guidance (friendly exchanges)
• Nofx considers this to constitute "support," which can be labeled as "backed by"
• amber.ac believes this does not constitute "formal collaboration" and should not be publicly promoted
• Zack may have indeed facilitated these exchanges, but they ultimately did not materialize into an investment

The Proliferation of Endorsement Culture: A Common Issue in the Crypto Industry

The Nofx-Amber event is just the tip of the iceberg. In the crypto industry, the culture of endorsement has run rampant:

Common Endorsement Patterns:

1. XYZ Institution Leads the Investment: Actually, it may only be a small follow-on investment

2. XYZ Big Shot Endorses: It may only be a retweet

3. XYZ Accelerator Incubates: It may only be attending a workshop

4.Exchange Collaboration: Might have only submitted a listing application

Endorsed Value Chain:

• Top Layer: Formal investment agreement with defined amount and terms

• Middle Layer: Accelerator acceptance with a clear support plan

• Bottom Layer: Participation in an event, gaining exposure opportunity

• Bottommost Layer: Private chat, providing some advice

The issue is that many projects intentionally present bottom-layer relationships as top-layer endorsements.

Why Investment Firms Tolerate This Vagueness:

1. Expanded Influence: More project mentions enhance brand visibility

2. Option Thinking: Establishing weak ties first, which may convert to investments in the future

3. Minimal Effort: Low cost of a single interaction but significant value to the project team

4. Gray Income: Some firms may receive "advisory fees" or "branding fees"

Why Project Teams Are Enthusiastic About This:

1. Fundraising Need: Easier to secure follow-up funding with endorsements

2. User Trust: Community is more willing to trust projects endorsed by institutions

3. Competitive Pressure: Other projects are all promoting endorsements, falling behind by not doing so

4. Ego Psychology: Founders also seek this kind of acknowledgment

Reflection: Where is the boundary of endorsement responsibility?

The Nofx-Amber incident raised a profound question: When an institution's name is used for endorsement, how much responsibility should it bear?

If Amber Actually Invested in Nofx:

• As a shareholder, it has oversight and governance responsibilities
• In case of major project issues, investors should intervene
• User losses might lead to a certain moral responsibility for investors

If it's just "friendly communication":

• Amber has no legal obligations
• But if the project associates their name with Amber, Amber should promptly correct it
• If aware of misuse and not taking action, does it constitute tacit approval?

In the Nofx case:

1. Nofx tagged "Backed by Amber" on Twitter for weeks (possibly months)

2. Amber, as a professional institution, has social media monitoring capabilities

3. If they truly didn't have a formal partnership, why not clarify earlier?

4. Is it a case of waiting until Nofx runs into trouble before rushing to disassociate?

This "previously ambiguous, post-cut ties" pattern damages the trust foundation of the entire industry.

Key takeaway: Endorsement is not a free lunch

Insights from the Amber-Nofx incident:

1. For the project team: Do not exaggerate relationships with institutions; false endorsements will be exposed sooner or later

2. For investment institutions: Define the boundaries of endorsement, promptly correct misuse, and take corresponding responsibility

3. For users: Learn to identify genuine endorsements, verify through official channels of investment institutions

4. For the industry: Establish endorsement standards and norms to reduce gray areas

In the crypto industry, endorsement is a form of social capital. However, like all forms of capital, it requires rules and responsibility. When everyone is overusing this trust, the ultimate result is the collapse of the industry's credibility

Question 5: What Systemic Issues Does This Controversy Expose?

When we move away from specific accusations and rebuttals, beyond the details of the Nofx case, we find that this controversy points to five deep-seated systemic issues — they not only exist within Nofx but are the "Achilles' heel" of the entire crypto open-source ecosystem.

Issue One: The Alienation of the Open-Source Spirit in the Wave of Commercialization

From the protocol change of Nofx from MIT to AGPL, what seems like a technical decision is actually a reflection of the fundamental conflict between the open-source spirit and commercial interests.

The Original Intent of Open Source:

• Code Sharing to Foster Collaboration
• Standing on the Shoulders of Giants to Avoid Reinventing the Wheel
• Community-Driven with Collective Wisdom

The Reality of Commercialization:

• Need to Protect Commercial Interests
• Preventing Competitors from Free-riding
• Seeking Monetization Paths

The MIT License represents the idealism of open source: use it as you please, just give credit. This generosity has attracted a large number of developers and community attention, enabling Nofx to quickly accumulate 9000+ stars.

But when Nofx saw projects like COAI, which raised $17 million in funding, potentially using their code, they had a change of heart. The AGPL License is the strictest "firewall" in the open-source world: use my code? Then you must also open-source yours and cannot use it for closed-source commercial purposes.

From Nofx's Perspective, this change had its rationale:

• Right to Choose License: Open source authors have the right to reevaluate the license choice during the project's development, and the AGPL itself is a legitimate and widely used open-source license

• Asymmetric Benefit: When they discovered their code being used at scale by well-funded commercial projects, small open-source teams felt that the contribution did not match the return

• Ecosystem Protection: The "viral" nature of the AGPL is aimed at preventing open-source code from being "appropriated," safeguarding the sustainable development of the open-source ecosystem

• Vulnerable Position: Faced with a competitor with $17 million in funding, open-source projects are at a clear disadvantage in terms of resources, legal matters, and the market

This change itself is understandable—open-source authors have the right to choose a license. However, the issue lies in:

1. Lack of Community Notification: The license change was not announced to the community, and developers already using the MIT version may be unaware

2. Retrospective Enforcement: Using a license changed on November 4 to hold accountable actions taken on November 3

3. Selective Accusations: Why accuse COAI specifically, and not other projects using the MIT version?

4. Privacy Data Collection: In the MIT phase, Google Analytics was embedded to collect user data without disclosure

From another perspective, some of Nofx's practices may have their own context:

• Original Intent: The fundamental purpose of the protocol change may be to protect the interests of community contributors, rather than target specific competitors

• Capability Limitation: As a small team, during the project's rapid growth phase, they may have indeed overlooked the standard community communication process

• Technical Needs: Google Analytics may have been used to understand user behavior, identify issues, and improve the product, rather than for malicious data collection

• Resource Pressure: Faced with well-funded commercial competition, open-source projects do lack equivalent legal and market resources

However, even with an understanding of these backgrounds, issues with the execution still remain. This is no longer just a matter of upholding the open-source spirit, but about finding a balance between protecting one's own interests and maintaining trust in the open-source ecosystem.

The alienation of open source manifests as:

• Tooling: Open source has become a tool to acquire users and attention, rather than an end

• Weaponization: Open-source licenses have become weapons to attack opponents, rather than the foundation of collaboration

• One-sidedness: Demanding others to open-source while being able to change rules at will

Such judgments need to be made cautiously. It's challenging to fully understand Nofx team's internal decision-making process and true motivations from the outside. The change in open-source licenses is a legitimate right in itself, and the key issue is:

1. Execution: How the change is made, how users are informed, and how existing users are handled

2. Transparency: Whether the decision-making process is public, and if reasons are adequately explained

3. Consistency: Whether all similar situations are treated equally

What this case exposes is more of a systemic issue of the entire Web3 open-source ecosystem lacking mature norms, rather than just the malicious behavior of a single party.

Both Parties Have Legitimate Claims:

• Nofx's Claim: The work of open-source contributors should not be unjustly exploited by commercial projects without recognition and fair compensation

• COAI's Claim: Code used legally under the MIT License should not retroactively be subjected to AGPL obligations

• Industry Dilemma: How to establish a balance mechanism between encouraging open sharing and protecting creators' rights

This kind of alienation damages the trust foundation of the entire open-source ecosystem. When developers are unsure if an MIT project might suddenly switch to AGPL and enforce its provisions retroactively, would they still dare to use open-source code? When open-source authors find their contributions being commercialized without receiving any reward, would they still be willing to continue open-sourcing?

This is a lose-lose dilemma, and what is truly needed is industry-level norm construction

Issue 2: Lack of Legal Risk Awareness Among Entrepreneurial Teams

The equity dispute between Tinkle and Zack has exposed a common issue among crypto startup teams regarding legal compliance.

Disorder in Equity Distribution:

• Zack holds legal documents stating 50% ownership (APEIRON LABS registration)
• Tinkle believes Zack is only entitled to 10-20% ownership (based on code contributions)
• Such a cognitive gap should not exist—equity distribution should be clearly defined and documented from the beginning

Lack of Decision Records:

• Zack claims his 50% ownership was based on the commitment to bring in Amber Investments
• Tinkle alleges Zack overstated his capabilities, and ultimately, no investment was secured
• There is no written record of the agreement terms at that time: was equity to be given for effort or only upon completion?

Confusion in Communication Procedures:

• After Zack sent a legal letter, Tinkle did not respond for a month
• It was only when Tinkle publicly accused Zack of extortion that Zack had to respond publicly
• Why was there no attempt at private negotiation first, resorting directly to a public relations battle?

Abuse of Legal Tools:

• Tinkle referred to the legal letter as extortion, which is a serious criminal charge
• Zack provided a standard business resolution document, proving this was a lawful process

These issues are extremely common in the crypto startup world:

1. Bias Towards Action Over Formal Processes: The "move fast and break things" culture has led to many legal documents being overlooked

2. Tech-Centric Thinking: Engineer founders often disregard legal and compliance matters

3. Decentralization Illusion: Belief that traditional laws can be bypassed in the crypto world

4. Cost Considerations: Early-stage projects cannot afford professional legal assistance

However, as the project grows or disputes arise, these early "omissions" can turn into significant liabilities.

What Should Be Done:

• The founding team should have a written Founders' Agreement from day one
• Clearly define each person's contribution type, equity share, vesting schedule
• Keep written records of key decisions (emails, signed documents)
• Regularly have a professional attorney review the company structure and compliance
• In case of disputes, seek legal remedies first rather than engaging in a public relations battle

Issue 3: Severe Disconnect Between Technical Ability and Security Awareness

Nofx's security vulnerability revealed a harsh truth: in the crypto industry, technical ability ≠ security awareness.

Manifestation of Skill Misalignment:

• Nofx was able to develop an AI automated trading system, requiring significant technical prowess
• But at the same time, they committed basic security errors like "zero authentication" and "default keys"
• Being able to write functional code does not mean being able to write secure code

Fundraising Ability Does Not Equate to Technical Strength:

• COAI raised $17 million but faced doubts about their coding capabilities
• Nofx garnered community excitement but suffered from frequent security vulnerabilities
• In the crypto industry, storytelling prowess often attracts funding more than technical ability

Marginalization of Security:

• Under the pressure of rapid development, security is often considered a "later" concern
• Functionality takes precedence over security, and speed of deployment over code audits
• It's not until actual losses occur that the seriousness of the issue is realized

The Misconception of Open Source ≠ Security:

• Many people believe that open-source code is inherently more secure ("many eyes")
• However, in reality, most users do not read the code; they only look at the star count
• Security audits require expertise and a significant amount of time; they do not happen automatically

The Unique Risks of AI Trading:

• Involves real user funds, and losses are irreversible
• Automated execution leads to a short window for attacks, by the time they are discovered, it's often too late
• Operates 24/7, amplifying the impact of security issues

The Lessons of the Nofx Case:

1. Security is a Baseline, Not an Option: Systems involving user funds must undergo professional security audits

2. Security-First Default Configurations: It's better to inconvenience users than to make it easy for attackers

3. Rapid Iteration Is Not an Excuse: An MVP can be feature-light, but it must not be security-light

4. The Community Needs a Security Response Mechanism: Roles like SlowMist should be institutionalized

Question Four: The Endorsement Culture's Overabundance in the Crypto Industry

The Nofx-Amber incident unveiled the fig leaf covering the cryptocurrency industry's endorsement culture

The Inflation of Endorsements:

• Nearly every project claims to be "backed by" some institution
• However, the meaning of this "backing" varies widely
• Everything from formal investment to a casual chat may be packaged as "backed by"

The Proliferation of Gray Areas:

• Strategic Partnerships: Could be mere business networking
• Ecosystem Partners: Might just be mutual promotion
• Advisory Teams: Could be in name only
• Investment Firms: Might have simply bought a small amount of tokens

Why Does This Culture Thrive:

1. Information Asymmetry: Regular users find it difficult to verify the authenticity of endorsements

2. Herd Mentality: "So and so invested, it must be reliable"

3. Competitive Pressure: Losing the race without leveraging endorsements

4. Regulatory Void: Lack of institutional oversight on the authenticity of endorsements

Vicious Cycle:

• Project exaggerates endorsements → Gains more attention and funding
• Other projects emulate successful cases
• Investment institutions, for influence, tacitly approve vague relationships
• When the project faces issues, institutions quickly distance themselves
• Users and the industry bear the losses

Breaking the Cycle:

1. Investment Institutions: Establish an official investment portfolio list, specifying investment amounts and dates

2. Project Teams: Only promote verifiable formal relationships, provide supporting documents

3. Media and KOLs: Verify the authenticity of endorsements before reporting

4. Users: Learn to verify, not blindly trust endorsements

5. Regulation: Impose penalties for false endorsements (already initiated in some jurisdictions)

Issue Five: Comprehensive Lack of Community Governance Mechanisms

Summing up Nofx's triple crisis, the fundamental issue lies in the open-source community lacking effective governance mechanisms

Protocol Disputes Lacking Arbitration Mechanisms:

• The Nofx and COAI dispute, with each side holding their own claims
• No recognized third party to adjudicate right from wrong
• Only recourse is to rely on public opinion and the law, with the former being biased and the latter costly

Security Issues Lacking Standard Procedures:

• SlowMist's prompt response is an exception, not the norm
• Most open-source projects lack a security response team
• Vulnerability disclosure, user notifications, and emergency patches all lack standardization

Lack of Appeals for Equity Disputes:

• Tinkle and Zack's conflict can only resort to legal action or public opinion
• The open-source community lacks a dispute resolution mechanism
• DAO governance has been proposed for a long time but is rarely operational

Lack of Community Incentives:

• Security audits, code reviews take a lot of time

• But open-source contributors are often volunteers
• Commercial companies have dedicated teams, while open-source projects rely on altruism

Attempts at Existing Governance Practices:

1. OpenSSF (Open Source Security Foundation): Promoting open-source security best practices

2. CVE (Common Vulnerabilities and Exposures): Vulnerability numbering and tracking system

3. Bug Bounty: Incentivizing security researchers with rewards

4. Code of Conduct: Community behavior standards

5. Foundation Model: Establishing a foundation to manage the project (e.g., Linux Foundation)

However, the application of these mechanisms in the crypto open-source space is still limited.

The ideal governance mechanism for open source and balance between all parties should include:

1. Security Audit Standards: Clearly defining which types of projects must undergo an audit to be endorsed

2. Dispute Resolution Body: A neutral third party to handle protocol and equity disputes

3. Vulnerability Disclosure Process: How to notify, remediate, and disclose vulnerabilities once discovered

4. Community Incentives: Rewarding contributors through tokens, NFTs, or other means

5. Transparency Requirements: Mandating disclosure of key information such as funding, endorsements, equity structure, etc.

Root Cause of Systemic Issues: The Trade-off Between Speed and Quality

The underlying cause of these five issues is the crypto industry's extreme pursuit of speed:

• Rapid Development: Seizing hot trends, rapid iterations, first-mover advantage
• Quick Funding: Capitalizing on high valuations, disregarding regulatory details
• Fast Growth: Competing on metrics like user count, star count, community size
• Swift Monetization: Issuing coins, listing, and cashing out

In this culture:

• Security is a burden, slowing things down
• Legal is a cost, to be minimized where possible
• Governance is a hindrance, impeding decision-making
• Long-term thinking is a joke, as the bull market waits for no one

But when speed reigns supreme, quality becomes a casualty. Nofx gained 9000 stars in two months, only to lose a considerable amount of reputation in the same timeframe.

Epilogue: The Reality Dilemma of the Open-Source Ideal

From rapid rise to a triple crisis, Nofx's story is a microcosm of the Web3 open-source movement. It showcases both the tremendous power of open-source collaboration and the various challenges this model faces in reality

Hackergate reminds us that decentralization does not equate to security; Infightinggate reveals that internal rifts among idealists can be more destructive than external attacks; Opengate puts a long-standing issue in the spotlight: How can we protect the rights of open-source contributors in a Web3 world driven by commercial value?

Of particular note is the time stamping issue in open-source license disputes that still requires further clarification. This is not only about the right or wrong of specific cases but also about the normative development of the entire Web3 open-source ecosystem. It may be necessary in the future to establish a more reliable protocol change tracking mechanism and a more authoritative third-party arbitration system

This article is based on publicly available information and analysis, and does not represent support or denial of any party. All technical details, timelines, and legal documents mentioned in the article can be verified through public channels such as GitHub, Twitter, etc.

Original Article Link