A candid response to recent npm spam research, what we changed after 2024, and how PKGX and tea network are being designed to make this class of abuse harder, not easier.

TLDR

‍

• Security researchers at AWS, Endor Labs, Socket, Sonatype and others have documented a massive npm spam and token farming campaign that abused tea-related metadata in over one hundred fifty thousand packages.
• The campaign grew out of patterns first reported in April 2024, when roughly fifteen thousand npm packages were published to farm tea points, and later evolved into the larger IndonesianFoods and Indonesian TEA campaigns that polluted more than 1 percent of npm.
• Once we understood how this behavior was gaming our early reward design, we stopped distribution of rewards for the affected period, cut off the path from those points to any payout, and used that time to redesign our system with Sybil resistance and registry integrity as first class requirements.
• The same economic and architectural weaknesses that made tea an attractive token farming target are also being exploited in far more dangerous supply chain incidents, including self replicating Shai Hulud style worms and Lazarus group operations that target developer credentials and wallets through npm.
• We believe that fixing this problem requires better infrastructure and aligned incentives, not just telling people to behave. PKGX, the evolution of Homebrew written by Max Howell, is being built as both a runner and a cryptographically aware package register that ties packages to verified maintainers and can enforce anti spam and slashing rules.
• As we approach mainnet launch for tea network, we are shipping with an architecture that is explicitly designed to make spammy, Sybil style spamming unprofitable and to work with the security community to keep tightening defenses over time.

How we got here: from 2024 spam to the 2025 token farming headlines

‍

In April 2024, Sonatype researchers documented a wave of more than fifteen thousand npm packages whose main purpose was to farm tea points. Those packages often contained little or no useful functionality. They were published in bulk and instrumented with `tea.yaml` metadata that linked back to tea accounts in an attempt to inflate reputation.

Over the following year, that pattern did not go away. It evolved.

Endor Labs recently published a deep dive into what they call the IndonesianFoods or Indonesian TEA spam campaign. They documented more than forty three thousand spam packages, many with Indonesian themed names, that were published across at least eleven npm accounts over almost two years. These packages linked to `tea.yaml` files and attacker controlled wallets in order to monetize the flood through tea rewards. Endor estimates that at its peak this spam represented more than 1 percent of the entire npm ecosystem.

In November 2025, Amazon Inspector researchers published their findings: more than one hundred fifty thousand malicious packages linked to a coordinated tea.xyz token farming campaign in the npm registry, calling it one of the largest package flooding incidents in open source history.

Coverage from outlets like Dark Reading and The Register has correctly framed this as a token farming and registry pollution event, not a traditional credential stealer or ransomware push, but the scale is unprecedented for a campaign that targets a single reward mechanism.

Socket followed with an important clarification: recent public commentary sometimes labeled this as a worm. Their analysis shows that the latest wave of tea related spam is large and automated, but it is not the same kind of self propagating malware as Shai Hulud that directly hijacks popular packages and steals secrets.

All of these reports have something in common. They show a real problem in the way open registries and incentive schemes interact, and they use tea as a high visibility example of that problem.

We accept that.

What actually happened from tea’s perspective

‍

When we first designed our incentivized testnet, the idea was simple: reward open source work based on real usage, not hype.

Early on, participation was measured through points that could later be mapped to rewards. The design assumed that developers would register genuine projects and focus on improving software that users actually depended on.

That assumption did not survive contact with reality.

A subset of participants realized that you could script npm publishing and generate huge numbers of trivial packages, each tagged with tea metadata, in order to farm points at scale. Some of this activity looked like crude experimentation. Some of it evolved into fully automated spam where a single script could publish hundreds of packages per hour and link them all into circular dependency graphs that amplified their apparent footprint.

As the 2024 research emerged and we dug into the data, it became clear that:

• The incentive design around volume and registration could be gamed.
• The registry itself had no meaningful protection against this kind of flood.
• Continuing to treat those points as valid would be irresponsible to both the tea community and the wider ecosystem.

So we made some hard calls:

• We halted the path from affected point earning activity to any on chain rewards.
• We stopped distribution of rewards for those specific campaigns.
• We began designing a different architecture instead of trying to salvage a design that had already been shown to be Sybil friendly.

Researchers are right that there was a token farming campaign. They are also right that tea was the target of that campaign. Where we have agency is in how we responded, and in how we change our system so that similar abuse is far harder next time.

Why this spam is a canary for something much worse

‍

It would be easy to look at this and say:

“It is just spam. There was no credential stealing payload, so why panic?”

That thinking is exactly what attackers are betting on.

Over the last two years, npm and other registries have seen a steady escalation in supply chain attacks that are not “just spam” at all:

• Self replicating Shai Hulud campaigns that compromise hundreds of packages, including highly popular libraries, and target developer tokens, keys and private repositories.
• Worm like incidents and widespread compromises of core utilities such as `chalk`, `debug`, and related dependencies, where a single account takeover poisoned packages with billions of weekly downloads.
• Lazarus group and other state aligned actors abusing npm, PyPI and GitHub in long running operations that specifically target developers and crypto wallets through manipulated open source packages.

Endor’s Indonesian TEA report explicitly calls out that these spam packages often look like fully formed projects, complete with Next.js scaffolding and real dependencies, and that some have thousands of weekly downloads.

That is the canary.

If a spam network can sit inside npm for two years, representing more than 1 percent of all packages, and no one feels enough economic pain to clean it up, then it is only a matter of time before the same blind spots are used for something much worse.

In that sense, the tea related campaign is not an isolated embarrassment. It is a visible symptom of a broader structural problem:

• Registries are cheap to spam.
• There is little direct economic cost to polluting them.
• Incentive schemes that are not Sybil resistant invite gaming and abuse.

tea is one of the first projects to feel that pressure at scale. We intend to be one of the first to treat it as a design problem rather than a PR nuisance.

What tea has changed since 2024

‍

Following the early reports, we treated the 2024 experience as a failed experiment that needed a redesign, not a marketing problem that needed spin.

Key changes include:

1. Halting legacy incentives that could be gamed by volume

We shut down reward paths where trivial package creation and simple registration could inflate scores. Points that were associated with spammy patterns were not mapped to on chain rewards.

‍

2. Redesigning rewards around contribution, not raw count

The new design is dependency graph aware and contribution aware. Instead of counting how many packages you can publish, tea focuses on:

• How important a package is in real dependency graphs.
• How actively and responsibly it is maintained.
• Whether its maintainers are verifiably tied to the code and to a consistent identity.

The CHAI oracle and related ranking logic are being tuned to reward depth and genuine impact, not surface area and volume.

‍

3. Strengthening identity and provenance signals

We are incorporating stronger signals for ownership and provenance, including:

• GPG style signatures tied to maintainers and repositories.
• Cross checks between registry entries, VCS hosts and verified identities.
• Hooks for zero knowledge or attested identity proofs where appropriate.

The aim is not to deanonymize open source, but to make it much harder to create thousands of pretend identities that look indistinguishable from legitimate maintainers.

‍

4. Introducing financial penalties, not just guidance

The new system is being built with slashing and penalty mechanisms for patterns that look like coordinated spam, Sybil clusters or reward manipulation. Publishing garbage is only attractive when it is free or profitable. Our goal is to flip that equation.

PKGX: from package manager to secure package register

‍

One of the biggest lessons from this period is that tea cannot simply sit on top of existing registries and hope they will evolve in time.

npm, Debian, Homebrew and others have done heroic work in keeping the ecosystem running, but they were not originally designed with economically motivated abuse at this scale in mind. Asking volunteer maintainers or understaffed security teams to manually sort through hundreds of thousands of spam packages is neither fair nor sustainable.

PKGX is our response.

PKGX is the evolution of Homebrew, written by Max Howell, the original creator of Homebrew. It is being built to serve a dual role:

1. Package runner and manager

PKGX can install and run software across diverse environments, with a familiar user experience for developers.

‍

2. Cryptographically aware package register

PKGX maintains its own curated registry where packages are:

• Bound to verified maintainers via cryptographic signatures and identity checks.
• Evaluated for quality, security posture and relationship to the broader dependency graph.
• Subject to explicit anti spam and anti Sybil policies that are enforced by policy, code and economic incentives.

‍

This design allows PKGX to:

• Take on the heavy lifting of supply chain checks that are too expensive to bolt onto legacy registries.
• Integrate directly with tea’s reward logic so that spammy patterns can be detected and penalized at the point of registration, not after the fact.
• Provide a foundation where future mechanisms such as automated bounties, audits and secure build pipelines can plug in.

The goal is not to replace npm or Debian overnight. It is to create a layer where security conscious users, enterprises and maintainers can opt into a system that treats integrity as a first class constraint, and where tea’s economic engine can operate without being trivially gamed by external spam.

How this informs tea network mainnet launch

‍

As we approach mainnet launch for tea network, these lessons are baked into our plan.

At a high level, launch and post launch will include:

‍

1. A conservative initial reward scope

Early rewards will be tightly scoped around:

• Packages and projects that pass ownership and provenance checks.
• Contribution patterns that are consistent with real development and maintenance, not automated spam.
• Risk controls that limit the impact of any single identity or cluster until it has a track record.

‍

2. Continuous Sybil and abuse monitoring

We are designing telemetry and monitoring that focus on:

• Sudden surges in low quality package creation or registration.
• Suspiciously correlated identities and publishing patterns.
• Anomalous dependency graphs that look more like spam networks than organic ecosystems.

When patterns match these signals, rewards can be throttled or slashed, and registrations can be quarantined for further review.

‍

3. Collaboration with security vendors and registries

We are not doing this alone. The research from AWS, Endor Labs, Sonatype, Socket and others has been invaluable in surfacing the scale and mechanics of this campaign.

Going forward, we intend to:

• Share indicators and patterns we see in tea and PKGX with partners, within responsible disclosure norms.
• Consume their findings as input to our own detection and slashing logic.
• Participate in community initiatives that aim to make npm, PyPI and other registries safer, even when that work does not directly involve tea.

‍

4. Accepting that this is an ongoing process

There is no final form of Sybil resistance or spam defense. Attackers adapt. Incentives shift. New infrastructure appears.

What we can promise is that:

• We are prioritizing security and integrity over short term growth metrics.
• We will treat spam and abuse as design feedback, not as noise.
• We will continue to adjust our system when research shows new weaknesses.

Gratitude, accountability, and a call to help us get this right

‍

We want to explicitly thank:

• The Amazon Inspector team, for quantifying the scale of the latest campaign and pushing this into the broader security conversation.
• Endor Labs, for doing the painstaking work of analyzing the IndonesianFoods campaign and connecting it to tea related metadata over a two year span.
• Sonatype and Phylum, for early 2024 reporting that first framed tea as a token farming target and highlighted the registry burden of this behavior.
• Socket, for clarifying that the latest flood is spam and token farming, and for contrasting it with true worm campaigns like Shai Hulud.
• The many other researchers and maintainers who have raised concerns, published analyses and kept pressure on this issue.

At tea, our mission is to fund and sustain open source, not to pollute it. When our early incentive design intersected with structural weaknesses in the registry ecosystem, it produced outcomes that no one should accept.

We did stop the bleeding once we understood what was happening. We cut off rewards from affected campaigns. We have spent the time since designing an architecture that treats Sybil resistance, spam control and supply chain security as critical path requirements for launch, not future nice to haves.

Now we would like your help making it better.

If you are:

• A security researcher with additional data on these campaigns.
• A maintainer who has been affected by tea related spam.
• An enterprise security leader who wants to understand how tea and PKGX fit into your risk model.

We invite you to reach out, to test our assumptions, and to tell us where we still have blind spots.

There is a real, long standing economic and security problem in open source. Attackers already know how to exploit it. The only way we solve it is by aligning incentives and infrastructure so that doing the right thing is easier and more rewarding than doing the wrong one.

tea exists to help build that future. We will be judged by how well we learn from episodes like this and by the systems we ship to prevent them from happening again.

‍