Codeberg writes cryptocurrency projects into its terms as reputation harm

On 22 July 2026, Codeberg e. V. put a new rule into force with almost no fanfare in the pull request that carried it. Gusted merged Codeberg/org#1254, posted "This has passed." with a screenshot of the assembly vote result, and the Terms of Use changed by a single clause. Section 2(1) had long barred "Content that harms the reputation of Codeberg." It now bars "Content that harms the reputation of Codeberg, such as cryptocurrency related projects."

That is the entire substantive amendment. There is no definition of "cryptocurrency related," no carve-out for research, libraries, wallets that do not mint a coin, or documentation, and no published inventory of what already on the platform falls inside the new example. The enforcement ladder is the one that already sat in section 2(2): first failure brings immediate removal of the content plus a warning; further violations might bring immediate account suspension; in non-obvious cases the Presidium decides removals and suspensions by simple majority. The rule is in force. The public record does not yet show which projects, if any, have been removed under it.

For a volunteer-run, member-governed forge that markets itself as a home for free and open source software, the move is startling on several axes at once. It elevates a whole technology category to the status of presumptive reputation harm. It does so through an assembly proposal whose operative wording was frozen before members finished asking what the words meant. And one of the three sources the proposal cited for its rationale, a forum thread titled for taking a stance against cryptocurrency, now returns HTTP 404.

From SourceHut precedent to a Codeberg rule

The argument did not appear overnight. In October 2022, SourceHut announced planned 2023 terms updates that would prohibit cryptocurrency- or blockchain-related projects. Codeberg/Community#794, opened on 10 November 2022 under the title "Taking a stand against cryptocurrency/blockchain," put that announcement in front of Codeberg's community and quoted SourceHut at length. SourceHut's own framing, as reproduced there, was blunt: "SourceHut is planning to roll out updates to our terms of service, effective in 2023. The changes most likely to impact users is the prohibition of cryptocurrency- or blockchain-related projects on SourceHut." The rationale that followed was not a narrow fraud filter. "These domains are strongly associated with fraudulent activities and high-risk investments which take advantage of people who are suffering from economic hardship and growing global wealth inequality. Few to no legitimate use-cases for this technology have been found."

Issue 794 closed after 33 comments. It did not produce a Codeberg terms change. Nearly three years later, on 25 October 2025, Codeberg/Community#2184 opened with a harder title: "Codeberg must take a stricter stance against cryptocurrency projects." That issue, closed after 14 comments, named projects then hosted on the platform, including darkrenaissance/darkfi and Flowee/thehub. It argued that such work was "already banned on Codeberg alternatives such as SourceHut," that "the effects to the environment are severe," and that "PoW (Proof-Of-Work) projects waste an astonishing amount of computational energy." DarkFi was characterised in the issue framing as seemingly crypto designed for criminals, with a citation to an FBI director, and its readme was noted as describing a PoW blockchain.

Those two community issues, plus a forum thread at forum.codeberg.org under the path for taking a stance against cryptocurrency, became the cited lineage when Gusted opened Codeberg/org#1254 on 2 July 2026: "Proposal for Assembly 2026: Disallow cryptocurrency projects." The proposal was not a long policy white paper. It was a vehicle to put a one-line terms change in front of the assembly. On 7 July, Gusted told the pull request thread that the operative text was locked to what voters had seen. "The text is now as-is because it was send out for votes. Small clarifications can be made afterwards by Presidium or Board. The whole spirit of the vote makes it clear this is a 'not limited to' case."

Two days later, on 9 July, johnnyjayjay asked the question the diff does not answer: "Is there a definition of 'cryptocurrency-related' somewhere?" The pull request thread contains no reply. On 22 July Gusted merged the change and declared passage. The assembly had accepted writing cryptocurrency related projects into the reputation-harm clause as an illustrative case, and Gusted's reading of the vote's spirit was that the illustration was not a closed list.

What the text does and does not say

Technically, the amendment is minimal. It does not add a new section, a new enforcement process, or a glossary. It takes an existing, open-ended reputation standard and nails one example onto it. That drafting choice has consequences in both directions.

On one reading, friendly to the proposers, reputation harm was always a judgment call. Naming cryptocurrency related projects tells moderators and users that the association SourceHut described (fraud, high-risk investment pitches, thin legitimate use) is how Codeberg will treat the category unless a non-obvious case goes to the Presidium. Gusted's "not limited to" gloss pushes further: the spirit is a category stance, not a narrow ban on a few notorious coin launches. Small clarifications, on that view, can be issued later by the Presidium or Board without re-running the assembly. Section 2(2) already assumes the Presidium will majority-vote the hard calls.

On another reading, hostile to the drafting, the forge has criminalised a research and implementation domain by example without saying where the example stops. Is a pure cryptographic library that happens to be used by a chain "cryptocurrency related"? Is a Bitcoin Core mirror? An academic paper's companion code for a consensus protocol? A block explorer? A Lightning documentation set? A project that implements proof-of-stake rather than proof-of-work? The environmental critique in Community#2184 leaned heavily on PoW energy use, but the terms line says "cryptocurrency related projects," not "proof-of-work mining software." johnnyjayjay's unanswered question sits on top of that ambiguity. A rule that can end in immediate content removal and, on repetition, account suspension is a poor place for a silent definition.

The enforcement inheritance matters. Because section 2(2) was not rewritten, first contact with the new example is not a gentle notice that a policy discussion is underway. It is immediate removal of the content together with a warning. Only the non-obvious cases are promised a Presidium majority. Whether a repository is "obviously" cryptocurrency related is exactly the sort of boundary fight the missing definition would have reduced.

Reactions: move-in shock and overbreadth

The social reaction landed the same day as the merge and the day after. charlesrocket, posting on 22 July after the rule was already live, wrote: "Fk hell I just moved to a forge that banned bitcoin! Is this a joke???" The complaint is mundane and therefore cutting. People migrate forges for licensing culture, uptime, and escape from other platforms' policies. Discovering on arrival that a major technology domain is written into the terms as reputation harm is the sort of surprise that burns trust even among users who have no coin to grind.

On 23 July, nekogirl pressed the reputation theory directly: "Please explain how do cryptocurrency projects harm codeberg's reputation." In a second comment the same morning, nekogirl attacked the category logic rather than the motives: "Not all of them are about it. First of all, in context of so called code forges, this is a tech. What kind of headache do you have, that you judge the whole group by isolated cases, and block ANY such projects, even those that have real technical value?" That is the classic overbreadth brief. A forge can and does remove scams, phishing, and malware when it finds them. Collapsing every cryptocurrency related repository into reputation harm, on this view, substitutes a technology test for a behaviour test and sweeps up work whose only offense is the problem domain.

exidot, minutes later, framed the change as part of a pattern after inbound transfers: "When some projects were transferred over, you started behaving strangely." The record does not develop that claim further. It stands as a user perception that the stricter line followed the arrival of particular projects, including those Community#2184 had named.

Independently, the proposal's first cited rationale is gone. The forum thread it pointed at for taking a stance against cryptocurrency returns 404 on the Codeberg e. V. Forum (beta). nekogirl noted the dead citation in the reaction thread. The other two citations, Community#794 and Community#2184, remain as ordinary closed issues. Whatever the forum once contained, assembly voters and later readers cannot retrieve it from the address the proposal gave. That is a process failure even if one agrees with the outcome. Governance narratives are supposed to remain inspectable after the vote.

Steelmanning the ban

None of the procedural roughness erases the case the campaign actually made.

A forge is not a common carrier. Codeberg e. V. is a non-profit association that sets terms for a service it pays to run. SourceHut had already demonstrated that a respected FOSS host can decide the fraud and inequality associations around cryptocurrency and blockchain are disqualifying, and can say aloud that it sees few to no legitimate use cases. Codeberg's members were entitled to look at that precedent and adopt a similar line. Community#2184 added an environmental claim that does not depend on liking SourceHut: if proof-of-work systems externalise astonishing energy cost, hosting their development is not a neutral act of bit storage. It is material support for a class of systems whose resource burn is the point of the consensus mechanism.

There is also a moderation practicality argument. Case-by-case fraud enforcement requires catching specific scams, pump documents, and impersonation repos after they land. A category rule is crude, but crude rules are how small staffs and volunteer boards avoid playing endless whack-a-mole across every new token and every new "decentralised" wrapper. Writing the category into the reputation clause, then routing edge cases to the Presidium under the existing simple-majority path, is a coherent design if one accepts the premise that the category's center of gravity is harmful. Gusted's insistence that the voted spirit is "not limited to" the named example is, on this steelman, honesty rather than mission creep: voters were not tricked into a narrow illustration; they were asked to take a stance.

Naming darkfi and Flowee/thehub in the 2025 issue can be read the same way. Campaigners pointed at concrete hosted roots rather than vibes. DarkFi's own materials, as characterised in that issue, described a PoW blockchain, and the issue author connected the project to crime-oriented framing via an FBI director citation. If a board believes some of what it already hosts is reputation poison, waiting for a perfectly tidy ontology of "cryptocurrency-related" before acting has a cost too.

Steelmanning the critics

The contrary case is equally structural.

First, technology bans are different in kind from behaviour bans. Free-software forges have long survived by hosting code whose authors they dislike and whose applications they would never run, so long as the license and the conduct on the platform stay inside the rules. Cryptography, peer-to-peer networking, consensus algorithms, and monetary software are all ordinary computer science. nekogirl's line that "in context of so called code forges, this is a tech" is a claim about the purpose of the institution. If the institution starts pruning research domains by reputation association, critics will ask which domain is next, and they will not be wrong to ask.

Second, the definitional gap is not a nitpick. johnnyjayjay asked for a definition in the proposal thread while the text was still a live pull request. No definition appeared. Gusted offered post-vote clarifications by Presidium or Board instead. That sequence inverts the usual order for coercive rules. Clarify before the assembly binds the membership, not after people have already moved hosts and after removal-plus-warning is the default first step. "Small clarifications" also sits uneasily beside "not limited to." If the spirit is expansive, clarifications are not small; they are the real policy.

Third, the evidentiary trail is weaker than a terms change of this breadth usually demands. One of three cited pillars is a 404. The SourceHut quotes are real and sharp, but they are another operator's philosophy, not a Codeberg-specific incident log. Community#2184's environmental claims about PoW energy use are serious in the large, yet the terms line covers "cryptocurrency related projects" without limiting itself to PoW. The leap from "some crypto projects are scams or energy-hungry" to "cryptocurrency related projects harm the reputation of Codeberg" as a standing example is exactly the leap nekogirl challenged: judging the whole group by isolated cases.

Fourth, existing named projects and future boundary projects now live under a cloud without a public enforcement record. The shocking part is not that a forge might remove a scam. It is that a forge has announced, in the terms, that an entire relatedness category is reputation harm, while leaving relatedness undefined, while citing a missing forum post, and while inheriting an immediate-removal first strike. Users who transferred repositories in good faith, charlesrocket's situation in miniature, have no machine-readable way to know whether they are already in violation.

Process, politics, and open questions

As governance, org#1254 is almost a caricature of how member assemblies both empower and underspecify. The assembly form gave the change democratic cover inside Codeberg e. V. Gusted's dual role as proposal author and merger kept the path short. The Presidium and Board are written in as the bodies that can clarify and that must majority-vote non-obvious suspensions and removals. That is real structure. It is also a structure that can bury the hard questions in later private or low-visibility decisions unless those bodies publish how they read "cryptocurrency related."

The open questions are concrete. What counts as cryptocurrency-related, including libraries, research code, non-PoW systems, and documentation only? How will a technology-category ban be applied consistently compared with the behaviour-based rules elsewhere in the terms? How will projects previously named in Community#2184, or others like them, be treated now that the example is live? Why is the cited forum rationale unreachable, and will any replacement rationale be published? What clarifications, if any, will the Presidium or Board actually issue?

Until those are answered, the shocking fact remains the one on the face of TermsOfUse.md. Codeberg did not merely reserve the right to handle crypto scams. It told the world that cryptocurrency related projects are the paradigm case of content that harms its reputation, on the strength of a years-long campaign, a frozen sentence voters could not edit in place, an unanswered definition question, and a citation that resolves to 404. Supporters will say the spirit was clear and the category had it coming. Critics will say a code forge just confused a technology with a behaviour, and then declined to say where the technology ends. Both descriptions fit the record. The terms, not the commentary, are what users must now parse.