The Achilles' Heel of Open Source: Nofx, with 9,000 Stars in 2 Months, and Its Hacker Scandal, Internal Conflict, and Open-Source Controversy

2025.12.22

The Achilles' Heel of Open Source: Nofx, with 9,000 Stars in 2 Months, and Its Hacker Scandal, Internal Conflict, and Open-Source Controversy

From rapid rise to facing a triple crisis, Nofx's story is a microcosm of the Web3 open-source movement.

2025.12.22 - 08:03:28

Nofx

Navigating Web3 tides with focused insights

From rapid rise to facing a triple crisis, Nofx's story is a microcosm of the Web3 open-source movement.

Author: WquGuru

Background

Before formally unfolding this story, I need to clarify my position in this event.

I am an observer and analyst. During the period when the Nofx project went viral, I developed the nof0 project—both inspired by nof1. In the development process, I communicated with Tinkle and Zack, core members of Nofx, mainly around technical implementation and open-source collaboration.

It should be made clear: I only had technical exchanges with the Nofx team, without any commercial cooperation; I had no direct contact with the ChainOpera AI (COAI) team. While writing this article, I have tried my best to remain objective and neutral. All analysis and judgments are based on publicly verifiable sources, including GitHub records, social media posts, security reports, etc.

Event timeline:

End of October 2025: The Nofx project launched, gaining nearly 9,000 stars on GitHub within two months
November 2025: Security vulnerabilities exposed, SlowMist issued a security warning (Hack Gate)
December 2025: Open-source license dispute erupted (Open-Source Gate), while internal team division surfaced (Infighting Gate)

The entire incident lasted about two months but concentrated multiple contradictions in the Web3 open-source movement.

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

Fully document this typical case of the Web3 open-source movement
Explore the deep conflict between open-source spirit and commercial interests
Provide reflection and reference for future industry standardization

Now, let's begin 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 called Nof1 exploded on Twitter. Within days, its multiple open-source versions—including nof0, nofx, etc.—gained thousands of stars on GitHub. Among them, the Nofx project, starting development at the end of October, had accumulated over 9,000 stars by December, becoming one of the most watched open-source projects in the AI Trading field.

However, just two months later, this star project fell into a triple crisis:

Hack Gate: Blockchain security firm SlowMist disclosed that Nofx had serious security vulnerabilities, causing API keys, private keys, and wallet addresses of over 1,000 deployed instances across the network to be fully exposed. Major exchanges such as Binance and OKX urgently intervened to assist affected users in changing credentials.

Infighting Gate: Core team member Tinkle publicly accused co-founder Zack of "only participating for 14 days and contributing a few lines of code" yet demanding 50% equity and $500,000. Zack responded by sending formal legal documents through his lawyer, accusing Tinkle of "asset misappropriation and利益输送," providing partnership registration documents showing both held 50% equity.

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

Why did a community-acclaimed open-source project fall into such a complex multi-layered crisis within just two months? What systemic issues in open-source communities, startup teams, and investment ecosystems does this expose? Let us deeply analyze this turmoil through five key questions.

Question 1: Was the Open-Source License Really Violated?

MIT vs AGPL: Two Radically Different Open-Source Philosophies

Before discussing the licensing dispute between Nofx and COAI, we need to understand the fundamental differences between these two licenses:

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

Free use, modification, and distribution of code
Commercial use without requiring open-sourcing
Only requirement: retain original author copyright notice

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

Any project using the code must also be open-sourced
Especially, even if provided as a service over the network (e.g., SaaS), source code must be made public
Original project information must be clearly labeled

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

License Change and Timing Dispute

Nofx changed its open-source license from MIT to AGPL, but the exact timing of the change became a point of contention. This moment is crucial because it directly determines which license ChainOpera (COAI) should have followed when they forked the code.

Comparison of evidence:

Nofx team provided GitHub commit records showing the license file modification time
COAI team pointed out that according to their records and observations, the public timing of the license change is questionable

ChainOpera’s “Plagiarism” Allegations

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

Nofx’s allegations:

COAI used Nofx code without attribution and without open-sourcing
According to the then-effective AGPL license, COAI should: clearly attribute code origin, publish modified source code, and adopt AGPL license

COAI’s response:

Claims they forked the code when Nofx was still under MIT license
MIT license permits commercial use without requiring open-sourcing
The dispute over the timing of the license change affects the nature judgment of the entire event

Open-Source License Dispute: Who Is Right?

This dispute exposes deep-rooted problems in the Web3 open-source ecosystem:

Validity of license changes:

Retroactive enforcement debate: Does a license change bind already-forked code?
Timing determination: Exact time of license change is hard to definitively confirm, both sides disagree
Evidence credibility: GitHub records may be altered, requiring more authoritative third-party verification
License change communication: How effectively was the switch from MIT to AGPL communicated to the community?

Conflict of commercial interests:

COAI secured significant funding and launched on Binance, carrying substantial commercial value
Nofx, as an open-source project, has unclear commercialization path
Core contradiction: Balancing open-source sharing ethos with commercial interest protection

Community opinion split:

Supporters of Nofx believe COAI profited from open-source code without giving back to the community
Supporters of COAI argue MIT license inherently allows commercial use, and the license change timing is disputed
Neutral observers note the timing issue is critical and more reliable evidence is needed

Legal and technical gray areas:

Legal enforceability of open-source licenses in on-chain projects remains unclear
Potential tampering of GitHub records weakens their evidentiary credibility
The Web3 industry lacks mature mechanisms for resolving open-source disputes

Summary: A Contested Accusation

Based on currently available public evidence, Nofx’s allegations of open-source license infringement against COAI have several doubts:

Timing uncertainty: GitHub evidence shows AGPL change only occurred on November 4
Different technical implementations: Same interface naming doesn’t mean identical code
Log explanation reasonable: Statistics function inserted during MIT phase would continue recording
Self涉嫌违规: Embedded statistics without user notification may violate privacy laws
Rushed communication: Email and public accusation sent within the same minute

Notably, the dispute over the license change timing decisively impacts the overall nature judgment of the event. If Nofx’s claim holds, COAI indeed violated the AGPL license; but if COAI’s claim holds, their actions fully comply with the MIT license. Determining this timing still requires more authoritative third-party verification.

Question 2: Is 14 Days Worth 50% Equity?

If the Open-Source Gate is Nofx’s external dispute, the Infighting Gate is the public manifestation of internal contradictions—a founding team battle over "contribution" and "value."

Timeline: From Joining to Confrontation

October 28, 2025: Nofx development began;

October 29, 2025: Zack joined the project (project had been open-sourced for just one day);

Early November 2025: Zack demanded 50% equity, citing ability to introduce Amber Group into commercialization;

Early November 2025: Tinkle refused to grant 50% equity, arguing he was CEO and CTO of the team and Zack’s contribution was insufficient;

November 19, 2025: Zack’s lawyer (JunHe Law Offices Hong Kong) issued a formal "Without Prejudice Save as to Costs" settlement offer, demanding $500,000 to repurchase Zack’s 50% equity;

December 2025: Conflict became public, both parties accusing each other on social media;

From a timeline perspective, Zack went from joining to sending a legal letter in less than a month—indeed very short.

Confrontation: Two Radically Different Sets of Evidence

Tinkle’s narrative:

Zack participated for only 14 days
Contributed a few lines of code ("verifiable")
Joined after the project was already open-sourced and had thousands of Telegram group members
Demanded massive equity in exchange for introducing Amber investment
After rejection, withheld control of the project’s Twitter account
Demanded $500,000 via legal letter, suspected extortion
Zack was previously an Amber intern but left without being hired full-time
Ultimately failed to bring in Amber investment

Zack’s counterattack:

Provided company registration documents for APEIRON LABS PTE. LTD.
Documents show Tinkle and Zack each hold 50% equity
This is public information from Singapore’s corporate registry, verifiable by anyone
The legal letter is a standard "Without Prejudice Save as to Costs" settlement offer, compliant with commercial legal procedures
Main body is a Demand Letter detailing Tinkle’s "asset misappropriation,利益输送"
$500,000 is not extortion, but a buyback of Zack’s legitimate rights at a low valuation
Counter-question: If the company has value, isn't a $1M valuation to repurchase 50% equity reasonable? If it has no value, why does Tinkle call it "blackmail"?

Core Contradiction: How to Quantify Contribution?

The essence of this dispute is an age-old startup dilemma: technical contribution vs. resource introduction—which is more valuable?

From a code contribution standpoint, Tinkle’s argument may have merit. GitHub commit records are public; if Zack truly contributed only minimal code, this is easily verifiable in tech circles. For a project developed over 60 days, another person joining for 14 days indeed creates a huge gap in time and code volume.

But from an equity standpoint, Zack produced legal documents. Registration information for APEIRON LABS PTE. LTD. shows both parties signed a 50-50 equity agreement. This means:

Both parties once reached a formal legal agreement
The agreement recognizes Zack holds 50% equity
This is not a verbal promise, but a legally registered fact with government authorities

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

How much is Amber really worth?

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

Zack’s leverage: He could introduce Amber into Nofx’s commercialization. According to Tinkle, Zack was formerly an Amber intern (though left without full-time employment). In the crypto industry, bringing in endorsement and funding from top-tier institutions carries immense value.

But the final outcome was:

Amber did not formally invest in Nofx
Amber’s official statement: "No formal incubation, investment, or commercial cooperation relationship with Nofx"
Amber acknowledged "friendly exchanges" occurred, but did not lead to formal cooperation

This leads to two possible interpretations:

Interpretation A (supports Tinkle): Zack exaggerated his resource capabilities, exchanged empty promises for equity, failed to deliver, refused to relinquish equity, and resorted to legal threats.

Interpretation B (supports Zack): Both parties indeed reached an equity agreement; Zack made genuine efforts to bring in Amber, but investment failed due to issues on Tinkle’s side (possibly including "asset misappropriation,利益输送"). As a legitimate shareholder, Zack has the right to exit and receive compensation.

Which interpretation is closer to the truth? More internal materials are needed to judge.

Legal procedure or extortion?

Tinkle publicly shared Zack’s legal letter on social media, labeling it "extortion." This is a serious accusation, as extortion is a criminal offense.

But Zack’s response highlights the professionalism of legal procedures:

"Without Prejudice Save as to Costs" is a standard legal procedure in common law systems for commercial dispute settlement negotiations. Its characteristics include:

Legally protected, cannot be used as litigation evidence (except regarding litigation costs)
Aimed at encouraging peaceful resolution of disputes
Making a settlement offer does not constitute blackmail
Main body is a Demand Letter listing the other party’s breach or infringement

Zack’s legal letter demands $500,000, but this amount is based on:

Legal fact of Zack holding 50% company equity
Calculated based on a conservative $1 million company valuation
As a buyback price for Tinkle to acquire Zack’s equity

From a legal perspective, this is a completely legitimate settlement negotiation strategy. If Tinkle truly believes this is "extortion," the proper course is to report it to the police, not post on Twitter.

Zack’s "final warning" is also powerful:

"If you truly believe this is extortion, please report it immediately. If you lack the courage to do so, please stop this absurd performance."

The hidden allegation: Asset misappropriation and利益输送

In this public confrontation, one detail stands out: Zack mentioned the main body of the legal letter is a detailed Demand Letter documenting Tinkle’s "misappropriation of partnership assets, conspiring through illegal means."

The full content of this letter has not been made public, but the allegation is extremely serious. If true, it might involve:

Diverting company funds for personal use
Exchanging benefits with individuals at investment firms
Violating fiduciary duties of the partnership

Tinkle has not directly responded to these allegations, merely stating, "I will no longer respond to this matter, focusing on building the product."

This evasive attitude ironically raises curiosity: What exactly does the Demand Letter contain?

Summary: An Unsolvable Dilemma

Founding team equity disputes are common in the startup world. The reason the Nofx case attracted attention is because it encapsulates typical conflicts inherent in such disputes:

Verbal promises vs. written agreements: Without a written equity agreement, how is contribution determined?
Technical contribution vs. resource introduction: How are these two values measured?
Responsibility for unmet expectations: Whose fault is it when fundraising fails?
Legal procedures vs. moral judgment: Does settlement negotiation equal extortion?

Based on existing evidence:

Zack has legal documents supporting his 50% equity
Tinkle has code contribution records supporting his leadership role
Both parties have their own narratives, but both lack complete chains of evidence

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

Equity distribution should be decided early, in writing, and clearly defined
Contribution quantification should have objective standards (code volume, working hours, resource value)
Critical decisions should be documented
When disputes arise, prioritize legal channels over public relations battles

Question 3: Why Have Open-Source Projects Become Security Disaster Zones?

Before the protocol dispute between Nofx and COAI and the internal equity conflict, a more serious crisis quietly emerged: security vulnerabilities.

In November 2025, blockchain security firm SlowMist released a detailed security analysis report exposing serious security vulnerabilities in the Nofx project. This wasn’t a minor "bug"—it was a major flaw that could lead to complete theft of user funds.

Vulnerability Timeline: From No Authentication to Default Keys

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

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

admin_mode defaulted to true
Middleware allowed all requests to pass without verification
/api/exchanges endpoint completely open

What does this mean? Anyone who knows the address of a server running Nofx can directly access the /api/exchanges endpoint and obtain:

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

With this information, attackers can:

Gain full control over users’ exchange accounts
Perform wash trading
Directly withdraw funds
Manipulate market prices

This is zero-protection exposure—an elementary failure in security design.

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

Possibly aware of the security issue, the Nofx team added JWT (JSON Web Token) authentication in this commit. On the surface, this appeared to be a security enhancement.

But the problem was:

Default jwt_secret was not changed
If users didn’t set environment variables, the system would fallback to a hardcoded default key
/api/exchanges still returned all sensitive fields in raw JSON format

This meant:

Attackers could forge JWT tokens using the default key
Once a valid token was obtained, all keys would still be fully leaked
The "hardened" version remained practically vulnerable

It’s like adding a lock to a door, but leaving the key under the doormat where everyone knows to look.

November 13, 2025 - Dev Branch: Ongoing Hazards

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

authMiddleware implementation still flawed (api/server.go:1471–1511)
/api/exchanges continued to return full ExchangeConfig directly (api/server.go:1009–1021)
Configuration files still hardcoded admin_mode=true and default jwt_secret
Main branch (origin/main) still stuck at the zero-authentication version from October 31

This wasn’t accidental negligence, but a systemic lack of security awareness.

Discovery and Response: SlowMist’s Critical Actions

Intelligence source: Security researcher @Endlessss20 provided SlowMist with initial intelligence about Nofx’s security risks.

Deep analysis: SlowMist’s security team conducted a full audit of Nofx’s GitHub code, identifying the two main authentication issues above.

Internet-wide scanning: Even more shockingly, SlowMist performed internet-wide scans and discovered over 1,000 publicly accessible Nofx deployment instances, many using default or weak configurations, with user credentials fully exposed.

This wasn’t theoretical risk—it was an ongoing real-world threat.

Emergency coordination: Given the urgency, SlowMist immediately contacted major exchanges:

Shared intelligence with Binance and OKX security teams
Both exchanges independently cross-verified
Used obtained API keys to trace affected users
Notified users and assisted in rotating keys
Blocked potential wash trading attacks

Progress: By November 17, 2025, all exposed keys for centralized exchange (CEX) users had been addressed. However, some Aster and Hyperliquid users, due to decentralized wallets, were difficult to reach directly and required self-checks.

Impact Scope: Beyond Technical Issues

The impact of this security incident went far beyond the technical level:

Direct victims:

Over 1,000 users using Nofx for automated trading
Spanning platforms including Binance, OKX, Hyperliquid
Exposed not just API keys, but also private keys and wallet addresses

Potential losses:

If attackers acted before exchange intervention, user funds could have been completely stolen
AI automated trading systems operate at high frequency and large volumes, potentially leading to staggering losses

Trust collapse:

Community lost confidence in Nofx’s security
Doubts arose about the entire open-source AI Trading ecosystem
Developers became more cautious when choosing open-source projects

Deeper Questions: Why Such Basic Mistakes?

Nofx’s security vulnerabilities weren’t advanced technical challenges—they were basic security常识:

Authentication should be enabled by default, not disabled
Default keys should be randomly generated, not hardcoded
Sensitive data should be encrypted or sanitized, not returned in plaintext
Configuration files should clearly warn of security risks

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

Possible reasons:

Speed prioritized over security: In the AI Trading boom, seizing first-mover advantage mattered more than safety
Lack of team experience: Possibly lacked experience handling user funds securely
Test configuration used in production: Authentication disabled for testing convenience, but this config ended up in production
No security audit: Open-source projects often lack professional security audits

But the root cause may be: Open-source ≠ Secure.

Many assume open-source code is safer because "thousands of eyes" are reviewing it. But reality is:

Most users are consumers, not reviewers
Even if issues are found, people may lack ability or willingness to submit fixes
Security audits require expertise and significant time
Commercial companies have security teams; open-source projects often don’t

Liability Boundaries: How Much Responsibility Should Open-Source Authors Bear?

This raises a controversial question: When users suffer losses due to vulnerabilities in open-source software, should the authors bear responsibility?

Legally, most open-source licenses (including MIT and AGPL) include disclaimers:

"Software provided 'as is' without any express or implied warranties... Authors are not liable for any damages."

But morally, when you know your code will be used by users to manage real money, shouldn’t you uphold higher security standards?

What makes Nofx special:

It’s an AI automated trading system directly handling user funds
The project gained over 9,000 stars, with many users
The vulnerability wasn’t a hidden advanced attack, but a basic lack of protection
The issue persisted for weeks, with new users deploying continuously

Industry Insights: Special Risks of AI Trading

Nofx’s security crisis reveals unique risks in the AI Trading domain:

The double-edged sword of automation:

AI trading systems designed to run 24/7 automatically
Once compromised, attackers can execute numerous trades rapidly
Users may not discover asset transfers until hours later

Contradiction between open-source and security:

Open-source helps community improvement and review
But also makes it easier for attackers to find vulnerabilities
Before security patches are ready, vulnerabilities are already public

Lack of user education:

Many users don’t understand the risks of deploying AI trading systems
Use default configurations directly, unaware they need to change keys
Expose services on public networks without basic security measures

SlowMist’s Exemplary Role

In this incident, SlowMist’s actions deserve praise:

Rapid response: Immediately conducted deep analysis upon receiving intelligence
Proactive scanning: Actively discovered affected instances instead of waiting for user reports
Industry collaboration: Worked closely with exchanges rather than operating in silos
Public disclosure: Published a detailed report after emergency handling to educate the community
Clear stance: Emphasized this wasn’t criticism, but risk mitigation

This responsible disclosure mechanism is the cornerstone of industry security.

Summary: Open-Source Isn’t a Get-Out-of-Jail-Free Card

The Nofx security vulnerability incident teaches us:

Open-source projects need security audits: Even rapidly iterating projects cannot skip security checks
Default configurations must prioritize security: Convenience for developers often equals convenience for attackers
User funds must be treated specially: Security is non-negotiable for financial systems
The community needs established security response mechanisms: SlowMist’s actions provide a good example
Technical skill ≠ security awareness: Being able to write functional code doesn’t mean writing secure code

Question 4: How Much Is Amber’s “Endorsement” Really Worth?

In the midst of Nofx’s multiple crises, one detail is easily overlooked, yet it reveals a widespread problem in the crypto industry: endorsement culture.

The appearance of endorsement: "Backed by@amber_ac_"

Before the incident broke out, if you visited Nofx’s Twitter profile, you’d see this line in the bio: "Backed by@amber_ac_"

What does this mean? In the crypto industry, "backed by" typically implies:

Receiving investment from the entity
Or at least incubation support
An officially recognized relationship

Amber Group is a well-known player in the crypto space, with strong capital and resources. amber.ac is its ecosystem accelerator. For an emerging open-source project, receiving Amber’s endorsement means:

Credibility boost: The project appears more trustworthy, attracting more users
Easier fundraising: Other investors are more willing to follow
Resource support: Potential access to technical, marketing, legal assistance
Community confidence: Users are more willing to participate and contribute

It’s like a founder getting a term sheet from a top VC—even before receiving funds, the mere endorsement brings tremendous value.

Zack’s leverage: I can bring Amber

Returning to the background of the infighting gate, Zack’s key bargaining chip for demanding 50% equity was: he could bring Amber into Nofx’s commercialization.

According to Tinkle, Zack was formerly an Amber intern. In the industry, this background implies certain connections. Zack promised Tinkle he could bring Amber investment or incubation support in exchange for 50% equity.

From a business logic perspective, this deal is reasonable:

If Zack truly brings Amber investment, its value far exceeds 14 days of code contribution
For an open-source project, securing backing from a top institution could be the critical leap from zero to one
Allocating 50% equity to a resource introducer isn’t unprecedented in early-stage startups

But the key question is: Did Amber actually come?

Amber’s clarification: "No formal incubation, investment, or commercial cooperation relationship"

In December 2025, amid the escalating Nofx infighting and open-source gate controversies, amber.ac issued an official statement:

"amber.ac has no formal incubation, investment, or commercial cooperation relationship with Nofx. We engaged in friendly exchanges with Nofx based on industry observation, but these did not lead to any formal cooperation. All our formal collaborations will be announced via our official website."

This statement is subtle:

Denies formal relationship: No investment, no incubation, no commercial cooperation
Admits contact occurred: "Friendly exchanges," "industry observation"
Emphasizes procedure: Formal collaborations will be officially announced
Draws a clear boundary: This is a public disassociation

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’s statement, the community noticed Nofx quietly removed the "Backed by@amber_ac_" text from its Twitter bio.

When questioned by netizens, Nofx’s admin replied:

"Grateful for Amber’s early support; respecting their request, we’ve removed it due to current events."

This response raises new questions:

What was "early support": If there was no formal cooperation, what kind of support was it?
"Their request" to remove: Did Amber proactively demand disassociation?
Impacted by "current events": Was removal requested due to the scandal?

From Amber’s perspective, this disassociation was necessary:

Nofx was embroiled in security vulnerabilities, equity disputes, and license controversies
Any association with Nofx could damage Amber’s reputation
Especially if users suffered losses using Nofx, Amber wouldn’t want to bear any responsibility

From Nofx’s perspective, this deletion is awkward:

A previously proud endorsement suddenly vanished
Creates the impression that "even investors have fled"
Further erodes community confidence

"Ecosystem accelerator" vs. "formal investment": The gray area amber.ac's positioning as an "ecosystem accelerator" rather than a direct investment fund is precisely the root of the problem.

Ecosystem accelerators typically provide:

Mentorship and industry advice
Community resources and networking
Event participation and brand exposure
But not necessarily direct funding

Formal investment relationships include:

Clear investment amounts and equity stakes
Legal documents (investment agreements, shareholder agreements)
Board seats or observer rights
Regular financial and operational reporting

The relationship between Nofx and amber.ac may lie in the gray zone between these two:

Had some exchanges and guidance ("friendly exchanges")
Nofx interpreted this as "support" and felt justified in labeling it "backed by"
amber.ac considers this not a "formal cooperation" and shouldn’t be publicly promoted
Zack may have facilitated these exchanges, but they ultimately didn’t convert into investment

The proliferation of endorsement culture: An industry-wide disease

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

Common endorsement tactics:

"Led by XYZ institution": Might actually be just a small follower investment
"Supported by XYZ influencer": Might just be a retweet
"Incubated by XYZ accelerator": Might just have attended a workshop
"Partnered with XYZ exchange": Might just have submitted a listing application

The real value chain of endorsements:

Top tier: Formal investment agreements with clear amounts and terms
Middle tier: Accelerator acceptance with defined support plans
Bottom tier: Event participation, exposure opportunities
Lowest tier: Private chats, receiving some advice

The problem is, many projects deliberately package bottom-tier relationships as top-tier endorsements.

Why do investment firms tolerate this ambiguity:

Expand influence: More projects mentioning them increases brand visibility
Option mindset: Establish weak connections now, potentially converting to investments later
Low cost: One conversation costs little but brings great value to the project side
Gray benefits: Some firms may charge "consulting fees" or "brand usage fees"

Why do projects pursue this:

Fundraising needs: Having endorsements makes subsequent fundraising easier
User trust: Communities are more willing to trust projects backed by institutions
Competitive pressure: If others promote endorsements, staying silent puts you behind
Vanity: Founders also crave such recognition

Reflection: Where should the responsibility boundary of endorsements lie?

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

If Amber had truly invested in Nofx:

As shareholders, they’d have supervisory and governance responsibilities
When major issues arise, investors should intervene
If users suffer losses, investors may bear some moral responsibility

If it was just "friendly exchanges":

Amber has no legal obligation
But if the project uses their name for endorsement, Amber should promptly correct it
If they knowingly allow misuse without stopping it, does that constitute tacit approval?

In the Nofx case:

Nofx labeled "Backed by Amber" on Twitter for weeks (possibly months)
As a professional institution, Amber has social media monitoring capabilities
If they truly had no formal cooperation, why didn’t they clarify earlier?
Did they wait until Nofx got into trouble before rushing to disassociate?

This pattern of "pre-event ambiguity, post-event disassociation" undermines the entire industry’s foundation of trust.

Summary: Endorsements Aren’t Free Lunches

Lessons from the Amber-Nofx incident:

For projects: Don’t exaggerate relationships with institutions; false endorsements will eventually be exposed
For investment firms: Clearly define endorsement boundaries, promptly correct abuses, and assume corresponding responsibilities
For users: Learn to identify genuine vs. fake endorsements, verify through official channels
For the industry: Establish standards and norms for endorsements, reducing gray areas

In the crypto industry, endorsements are a form of social capital. But like all capital, they require rules and responsibilities. When everyone is over-drawing from this trust, the ultimate result is a collapse of industry-wide credibility.

Question 5: What Systemic Problems Does This Turmoil Reveal?

When we step back from specific accusations and rebuttals, and rise above the details of the Nofx case, we find this turmoil points to five deep systemic issues—not only present in Nofx, but representing the "Achilles' heel" of the entire crypto open-source ecosystem.

Problem 1: The Alienation of Open-Source Spirit Amid Commercialization Waves

Nofx’s license change from MIT to AGPL, seemingly a technical decision, actually reflects the fundamental conflict between open-source ideals and commercial interests.

The初心 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:

Need to protect commercial interests
Prevent competitors from "free-riding"
Seek monetization paths

The MIT license represents open-source idealism: Use freely, just credit the source. This generosity attracted vast developer and community attention, enabling Nofx to quickly accumulate over 9,000 stars.

But when Nofx saw projects like COAI—raising $17 million—potentially using their code, they changed their mind. The AGPL license is the strictest "firewall" in the open-source world: Use my code? Then you must also open-source yours, and cannot keep it closed for commercial use.

From Nofx’s perspective, this shift is understandable:

Right to choose license: Open-source authors have the right to reassess license choices during project development. AGPL itself is a legitimate and widely used open-source license
Unbalanced interests: Upon discovering their code being extensively used by well-funded commercial projects, small open-source teams feel their contributions aren’t fairly rewarded
Ecosystem protection: The "infectious" nature of AGPL aims to prevent open-source code from being "privatized," protecting the sustainable development of the open-source ecosystem
Disadvantaged position: Facing competitors with $17 million in funding, open-source projects are clearly disadvantaged in resources, legal capacity, and market presence

This shift itself is not wrong—open-source authors have the right to choose licenses. But objectively, problems exist:

No community notification: The license change wasn’t announced to the community; developers using the MIT version may have been unaware
Retroactive enforcement: Using a license changed on November 4 to accuse actions from November 3
Selective accusations: Why specifically target COAI, not other projects using the MIT version?
Privacy data collection: Google Analytics embedded during MIT phase collected user data without disclosure

From another angle, some of Nofx’s practices may have context:

Protective intent: The fundamental purpose of the license change might be to protect contributors’ interests, not target specific competitors
Capacity limitations: As a small team, they may genuinely have neglected proper community communication during rapid growth
Technical necessity: Google Analytics might have been intended to understand user behavior, identify issues, and improve the product, not malicious data harvesting
Resource pressure: Faced with well-funded commercial competition, open-source projects indeed lack equivalent legal and market resources

Yet, even understanding these contexts, execution issues remain. This is no longer just about defending open-source ideals, but about finding balance between protecting one’s rights and maintaining trust in the open-source ecosystem.

The alienation of open-source manifests as:

Instrumentalization: Open-source becomes a tool to gain users and attention, not an end in itself
Militarization: Open-source licenses become weapons against rivals, not foundations for collaboration
One-way street: Demanding others open-source while arbitrarily changing rules oneself

This judgment requires caution. We cannot fully understand Nofx team’s internal decision-making processes and true motivations from the outside. Changing open-source licenses is a legitimate right. The key issues lie in:

Execution method: How the change was implemented, communicated, and how existing users were handled
Transparency: Whether the decision process was open and reasons adequately explained
Consistency: Whether similar situations were treated equally

This case exposes more a systemic lack of mature norms across the entire Web3 open-source ecosystem, rather than pure malice from one party.

Both sides have legitimate claims:

Nofx’s claim: Open-source contributors’ labor should not be freely exploited by commercial projects; they deserve recognition and fair returns
COAI’s claim: Code legally used under MIT license should not retroactively be subject to AGPL obligations
Industry dilemma: How to establish balanced mechanisms encouraging open-source sharing while protecting creators’ rights

This alienation harms the trust foundation of the entire open-source ecosystem. When developers can’t predict whether an MIT project might suddenly switch to AGPL and enforce it retroactively, will they dare use open-source code? When open-source authors see their contributions commercialized without reward, will they continue to open-source?

This is a lose-lose dilemma. What’s truly needed is industry-level standardization.

Problem 2: Lack of Legal Risk Awareness in Startup Teams

The equity dispute between Tinkle and Zack exposes widespread legal compliance issues among crypto startup teams.

Chaotic equity distribution:

Zack holds legal documentation (APEIRON LABS registration) for 50% equity
Tinkle believes Zack deserves only 10-20% equity (based on code contribution)
This perception gap shouldn’t exist—equity distribution should have been clearly defined and documented from the start

Lack of decision records:

Zack says his 50% equity was granted based on promising to bring Amber investment
Tinkle says Zack overstated his capabilities and ultimately failed to bring investment
No written record of the original agreement: Was it "best effort" or "successful delivery required for equity"?

Chaotic communication:

After Zack sent the legal letter, Tinkle didn’t respond for a month
Only when Tinkle publicly accused him of "extortion" did Zack feel compelled to respond
Why not negotiate privately first, instead of going straight to public warfare?

Abuse of legal tools:

Tinkle labeled the legal letter "extortion," a serious criminal accusation
Zack provided standard commercial settlement documents proving it was a legitimate procedure

These issues are extremely common among crypto startup teams:

Speed over process: The "build first, figure it out later" culture leads to missing legal documents
Engineering mindset dominance: Tech-founder-led teams often undervalue legal and compliance
Decentralization illusion: Belief that traditional laws can be bypassed in the crypto world
Cost considerations: Early-stage projects can’t afford professional lawyers

But when projects grow or disputes arise, these early "omissions" become massive liabilities.

What should be done:

Founding teams should have a written founders’ agreement from day one
Clearly define each person’s contribution type, equity percentage, vesting schedule
Keep written records of key decisions (emails, signed documents)
Regularly consult professional lawyers to review corporate structure and compliance
When disputes arise, seek legal avenues first, not public relations battles

Problem 3: Severe Disconnect Between Technical Ability and Security Awareness

Nofx’s security vulnerabilities reveal a harsh truth: In the crypto industry, technical ability ≠ security awareness.

Manifestations of capability mismatch:

Nofx could develop an AI automated trading system, requiring considerable technical skill
Yet simultaneously committed basic security errors like "no authentication," "default keys"
Being able to write functional code doesn’t mean being able to write secure code

Funding ability ≠ technical strength:

COAI raised $17 million, but its coding capability is questioned
Nofx gained community popularity, but suffers frequent security flaws
In crypto, storytelling ability often translates to funding more easily than technical prowess

Security marginalization:

Under pressure for rapid development, security is seen as "something to handle later"
Features prioritized over security, launch speed over code audits
Only realize severity after actual losses occur

Misconception that open-source = secure:

Many assume open-source code is naturally safer ("thousands of eyes")
But in reality, most users don’t read code, they just check star counts
Security audits require specialized knowledge and significant time—they don’t happen automatically

Special risks of AI Trading:

Involves users’ real funds, losses irreversible
Automated execution means short attack windows; by the time discovery happens, it’s too late
24/7 operation amplifies impact of security issues

Lessons from the Nofx case:

Security is a baseline, not optional: Systems handling user funds must undergo professional security audits
Default configurations must prioritize security: Better to inconvenience users than make it easy for attackers
Rapid iteration isn’t an excuse: MVPs can have simple features, but cannot have fragile security
The community needs established security response mechanisms: Roles like SlowMist should be institutionalized

Problem 4: Rampant Endorsement Culture in Crypto

The Nofx-Amber incident pulls back the curtain on the crypto industry’s endorsement culture.

Endorsement inflation:

Almost every project claims "supported by XYZ institution"
But the meaning of "support" varies wildly
Everything from formal investment to a single chat might be packaged as "backed by"

Proliferation of gray areas:

"Strategic partnership": Might just be business outreach
"Ecosystem partner": Might just be mutual retweets
"Advisor team": Might just be honorary titles
"Investment firm": Might just have bought some tokens

Why this culture thrives:

Information asymmetry: Ordinary users struggle to verify endorsement authenticity
Herd mentality: "If XYZ invested, it must be reliable"
Competitive pressure: Not promoting endorsements means losing at the starting line
Regulatory vacuum: No authority oversees endorsement authenticity

Vicious cycle:

Projects exaggerate endorsements → gain more attention and funding
Seeing success cases, more projects imitate
Investment firms, seeking influence, tacitly accept ambiguous relationships
When projects fail, institutions rush to disassociate
Users and the industry bear the losses

Breaking the cycle:

Investment firms: Establish official portfolio lists, clearly stating investment amounts and dates
Projects: Only promote verifiable formal relationships, provide proof documents
Media and KOLs: Verify endorsement authenticity before reporting
Users: Learn to verify, don’t blindly trust endorsements
Regulators: Penalize false endorsements (already happening in some jurisdictions)

Problem 5: Complete Absence of Community Governance Mechanisms

Considering Nofx’s triple crisis collectively, the deepest issue is: Open-source communities lack effective governance mechanisms.

No arbitration mechanism for license disputes:

Nofx and COAI dispute, each side insists on their own view
No recognized third party to determine who is right
Reliant only on public opinion and law—former unjust, latter costly

Lack of standardized processes for security issues:

SlowMist’s timely response was an exception, not the norm
Most open-source projects lack dedicated security response teams
No standards for vulnerability disclosure, user notification, emergency fixes

No recourse for equity disputes:

Tinkle and Zack’s conflict can only resort to law or public opinion
Open-source communities lack dispute resolution mechanisms
DAO governance proposed long ago, but rarely operationalized

Lack of incentives for community participation:

Security audits and code reviews require significant time
But open-source contributors are often volunteers
Commercial companies have dedicated teams; open-source projects rely on goodwill

Existing governance attempts:

OpenSSF (Open Source Security Foundation): Promoting best practices in open-source security
CVE (Common Vulnerabilities and Exposures): Vulnerability numbering and tracking system
Bug Bounty: Incentivizing security researchers with rewards
Code of Conduct: Community behavior guidelines
Foundation model: Establishing foundations to manage projects (e.g., Linux Foundation)

But these mechanisms have limited application in the crypto open-source space.

An ideal governance mechanism balancing open-source and user interests should include:

Security audit standards: Clear requirements for which types of projects must undergo audits before recommendation
Dispute arbitration bodies: Neutral third parties handling license and equity disputes
Responsible disclosure procedures: Protocols for notifying, fixing, and announcing vulnerabilities
Community participation incentives: Rewarding contributors via tokens, NFTs, or other means
Transparency requirements: Mandatory disclosure of funding, endorsements, equity structures, etc.

Root of systemic problems: The trade-off between speed and quality

The common root of these five problems is the crypto industry’s extreme pursuit of speed:

Rapid development: Seizing trends, fast iteration, first-mover advantage
Rapid fundraising: Capitalizing on hype for high valuations, ignoring compliance details
Rapid growth: Competition over metrics like user count, star count, community size
Rapid monetization: Launching tokens, listing, cashing out

In such a culture:

Security is a burden slowing things down
Law is a cost to minimize
Governance is cumbersome hindering decisions
Long-term thinking is a joke—the bull market waits for no one

But when speed trumps everything, quality becomes the casualty. Nofx gained 9,000 stars in two months—and lost significant credibility in the same timeframe.

Conclusion: The Realistic Dilemma of Open-Source Ideals

From rapid rise to falling into a triple crisis, Nofx’s story is a microcosm of the Web3 open-source movement. It showcases the powerful force of open-source collaboration while exposing the various challenges this model faces in reality.

The Hack 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 pushes forward a long-standing issue: In a Web3 world pursuing commercial value, how can we protect the rights of open-source contributors?

Particularly noteworthy is that the timing dispute in the open-source license conflict still awaits further clarification. This not only concerns the right or wrong of a specific case but also relates to the standardization of the entire Web3 open-source ecosystem. In the future, more reliable license change record mechanisms and more authoritative third-party arbitration systems may be needed.

This article is compiled and analyzed based on public information, not representing support or opposition toward any party. All technical details, timelines, and legal documents mentioned can be verified through public channels such as GitHub and Twitter. Please credit x@wquguru when reposting or adapting.

Join TechFlow official community to stay tuned

Telegram:https://t.me/TechFlowDaily

X (Twitter):https://x.com/TechFlowPost

X (Twitter) EN:https://x.com/BlockFlow_News

Source

Add to Favorites

Share to Social Media

Author

WquGuru

@wquguru

The Achilles' Heel of Open Source: Nofx, with 9,000 Stars in 2 Months, and Its Hacker Scandal, Internal Conflict, and Open-Source Controversy

TechFlow Selected TechFlow Selected