Paving the Way: Framework for Community-Driven Forks

By DeHub Team — 2023-07-04

In Q3 2023, having just been through it, we established a framework for future community-driven forks.

Why formalise something that worked informally

Because it worked once, with a specific group, under conditions that will not repeat.

The fan.site fork was led by large, long-term holders we knew. Everything was negotiated as it arose. That is fine once and a poor way to run a permissionless system, because the next group will be strangers with a different market and a different level of goodwill, and "it depends who you are" is precisely the property decentralisation is supposed to remove.

A framework written after a good outcome and before a difficult one is worth considerably more than one written during a dispute.

What it covers

What a fork can expect from us. The code is already theirs. The framework sets out what else is available — the engineering knowledge transfer we ran for fan.site, and on what basis.

Where the boundaries are. Brand, communications and community are not forked. A fork gets the technology, not our name or our audience. Separation was handled deliberately for fan.site — minimal inter-community communication, no cross-promotion — and that is the default rather than a special case.

How holders are treated. Airdrops to DeHub stakers had been part of the model since the first whitepaper in 2021, and the fan.site partner airdrop followed that pattern. Stating the expectation up front is better than leaving each fork to invent its own arrangement.

What we will not do. We do not obstruct forks. We also do not endorse them, and we do not carry responsibility for what they become.

The part that is genuinely difficult

A fork can do something we would not do. That is not a bug in the arrangement — it is the arrangement. Deciding in advance where support ends is much easier than deciding it once a specific project has done something specific that you dislike.

Writing it down before that happens is the only version that has any integrity, because a rule invented in response to a case you object to is not a rule.

Where this sits

It follows the same pattern as everything else in this archive that worked: publish the rule first, apply it mechanically, and remove the need to trust our judgement in the moment. That is the reasoning behind provably fair randomisation, the published DEX policy and the snapshot rules attached to every airdrop we have run.

A framework for forks is the same idea applied to governance. As we put it at the time: we may not always agree with every industry, but we cannot stop someone forking our app and airdropping our holders. Given that, the only question is whether it happens under stated terms or improvised ones.

What it does not do

It does not make a fork our responsibility, and it does not make one our endorsement.

That distinction is doing a lot of work and it will eventually be tested by a fork we would rather not be associated with. When that happens, the framework is what stops the response from being improvised — support is engineering, the boundary is brand and community, and neither expands or contracts based on how we feel about a particular project.

It also does not oblige us to airdrop anyone. Fork teams decide what they distribute and to whom. The pattern set by fan.site is an expectation the ecosystem has inherited, not a rule we can enforce on somebody else's token.