[MANIFESTO] Proof of Fair Launch - a checklist for honest chain launches

[proofra]

Proof of Fair Launch

A checklist for honest chain launches

I've been around this space long enough to be tired of one thing: almost every project says "fair launch", and almost every time, the catch is sitting right next to it.

Sometimes it's a presale. Sometimes 10% "for the team". Sometimes a per-block dev fee, an admin mint key, a "liquidity" reserve, or a quiet head start before anyone outside the inner circle was even watching. "No premine" goes in the headline; the real story is two lines down. Every time I went digging, there it was.

I'm not naming anyone. If you've been here a while, you already have your own list.

So instead of just complaining, here's a standard you can actually check, in public, before mining begins:

• No premine, no reserved allocation - any size
• No presale, private sale, or pre-chain IOU / market
• No dev / team / foundation allocation
• No block reward tax and no treasury - not even a "transparent" one
• No admin mint or supply-control key
• No hidden mining; mining starts in public from block zero
• Every component open source; source, binaries, checksums, genesis and launch time public before mining starts
• Consensus changes only at a future, announced height - never retroactive

Fair does not mean equal outcomes.

It means equal access and equal rules, with nothing reserved for insiders. Being early (low difficulty, paying attention, your own hardware) is a legitimate, reproducible advantage; anyone could have done the same. A private allocation or a secret head start is not, and never was.

Why post this, and not a coin

Honestly: this is hosted on the site of a chain I'm building, so I'm not pretending to be neutral; of course I have a stake in it. I'd rather say that openly than hide it.

But it isn't only about my project, and I'm not here to sell anything (there's no token, sale or mainnet yet anyway). I'm posting the checklist because I'm tired of how this scene tends to work, and I want it to get fairer and more decentralized, with more projects actually doing this. Mine is one attempt at a first step; I'd be glad to see others take it further.

Links

Manifesto:
https://proofra.org/manifest/

Fair Launch Test (run it on any coin):
https://proofra.org/fair-launch-test/


Open question for the forum:

What's missing from this checklist? What would you add, or argue with?

Tear it apart - criticism, feedback, all welcome.

[Bray_marcelo]

Open question for the forum:
What's missing from this checklist? What would you add, or argue with?

This is a really solid list. You've basically got tokenomics and emission design covered pretty well.
One thing I think is missing though is day-one infrastructure.
A chain can have zero premine, open-source code, and no dev tax, but if the founders are running all seed nodes, initial validators, and public RPCs on their own servers, it still ends up being pretty centralized in practice. Users get fair access to tokens, sure, but operationally the team still has a lot of control over access and availability.

I'd probably add something like:
Independent infrastructure: seed nodes and public RPC endpoints should include independent third parties from genesis, or close to it.

Fair launch is not only about distribution. It's also about reducing operational control at the network level.
We see this pattern quite a bit working on validator and RPC setups at Crouton Digital. A lot of projects get the economics right, but still rely on a single operator for access and data in the early stages.
Good initiative overall. More of this thinking is needed in the space.

[proofra]

Hey, appreciate the reply, thanks for the contribution.

Independent infrastructure: seed nodes and public RPC endpoints should include independent third parties from genesis, or close to it.

This is a really good point. I was also covering this in my planning, or better to say, since I am not even in testnet yet with my PoC, I am still thinking through a few things.

But honestly, I have not thought about it in this "from day one"-way. I was thinking about having everything open source, encouraging everyone to contribute, and making it more rewarding to do so. Some concepts I try to implement initially are meant to make it lucrative to host part of the infrastructure and get some monetary reward for it. But this is more about tokenomics and incentives, and it should encourage more decentralization. It does not fully solve the infrastructure point by itself.

At the same time, I understand that not every coin or chain can follow all those points perfectly. Somewhere it is about speed, somewhere about other metrics, and each project has its own vision, mission, goal, or purpose.

So I am thinking a bit about this one now, and how would you propose to solve that point in practice? If I find some contributor who is motivated and willing to help and host a node, it can still look like the "CoinName Team" just got bigger and got one more node, or something like that.

What does really independent mean here? I was thinking about having a few weeks of public testnet, so everyone can have time to inspect the project and its code, to learn about it, and to host their own infrastructure. But of course, this is not a guarantee.

Then specifically for EVM chains, there is also the archive and explorer side. Some data is needed for archive nodes and explorers, because historical state can get pruned even on full nodes, as there is usually a lot of data. If there are no archive nodes or explorers early enough, it does not mean the chain data is gone forever, because blocks and transactions can still be reprocessed, but it can become much harder to query old states, balances, traces, and contract data later.

For this I was thinking about bootstrap nodes, downloadable snapshots or states, public instructions for archive nodes, and similar things, so everyone can access and verify the data and not only depend on the core team. (Although it would still have the same kind of kickoff as the core source code and the first node instances at the beginning, and later it can be distributed through users as usual, but much easier if the core team supports it from the start)

I am curious how you would define this in a fair-launch checklist. Would you make independent infrastructure a hard requirement from genesis, or more like a transparency requirement where the project should disclose who runs seed nodes, RPCs, archive nodes, and explorers, and what the plan is to get independent operators online?

I would also like to extend the manifesto with your point, but I would prefer to shape the wording together instead of just adding my own interpretation and calling it done. So for you and everyone else reading this, feel free to give feedback or discuss it. I want to work this out with the crypto community and make the checklist better before treating it as something fixed.

[d5000]

In general I agree with the list. It could even be simply shortened to these 4 items:

- no premine
- no instamine (your point "no hidden mining [...]")
- no dev tax
- everything open source before launch time.

There is no way to do an ICO or other kinds of sales if there is no premine, so this requirement already covers some other "unfair" tokenomic cases.

I'm almost sure the consensus change item is also not really needed: the open source requirement basically removes the possibility of a retroactive consensus change, because if the code is open source, everybody could just run the code without consensus change. But of course the "team" could try to force people into the forked code by committing to promote only that version and threaten to sell all (legitimately mined) coins on the fork without the change. But if the coins are allocated fairly at the start it is difficult to achieve a large amount of coins which could give the "team" power to "extort" the users.

I think the point by Bray_marcelo is not that important in tradtitional cryptocurrencies, it is also covered by the "open source" rule, but there may be cryptos where checkpoints are very important, so it can be a good recommendation, but I don't think a "proof" is needed here.

I would add however one point I've stumbled upon in some projects, in particular, Kaspa:

- mainnet launch should be from a new genesis block and be called "mainnet" right away, no "rights" on coins/tokens should be possible to be acquired by previous "testnets" or "bootstrap nets".

That "trick" is really annoying but some seem to fall for it.

[proofra]

@d5000, thanks for your contribution too.

There is no way to do an ICO or other kinds of sales if there is no premine, so this requirement already covers some other "unfair" tokenomic cases.

In general I agree, but I think there is still a tokenomic loophole here: even without a premine, a project can launch a token or IOU on a different chain before the actual coin mainnet, and later promise that it will be swappable into mainnet coins.

There is also a separate trust problem around bridges and project-controlled infrastructure. A coin developer can create a bridge service, contract, backend or relayer setup that only he owns or controls. If this bridge dies, has bugs, or if he is simply not willing to help with problems that occur, then you basically got scammed, even if there was no premine.

I saw this exact case. There was a bridge, exactly as described, and the code was even open-source. But there was a bug where the bridge wrongly returned coins after a swap, even though the transaction was successful. In one of the transactions the bridge threw a general error, marked the transaction as successful, and that was it. Resulting in coins gone and no swap processed.
There was no mention anywhere, no commits on GitHub. I looked it up, tried to find the error, and tried to understand if it was a bug or some kind of ban/shadow-ban. In the end I found out that the owner had identified the bug, thought I was doing it on purpose, and rolled out new code that would block swaps through the bridge if there was any "debt". I had not checked the balance and was not even aware of the returned transaction from the bridge.
So to wrap it up, code was injected that was not publicly visible, even though the project was supposed to be open-source and had a GitHub repository for everyone to check. Audits can show that everything is fine, no scam, but the owner can still block specific behaviour or addresses without anyone even knowing. Or he can decide that everything under amount X is fine, but if it is 20k USD, then he just scams and keeps the money.

This is the point that is missing for me: how do we verify that something is really open-source, and how do we verify that the exact code is running without further modifications?

In many cases, you can't really verify it. There are loopholes. There is no useful checksum you can display if the same party controls the output of the webserver and can show whatever he wants. So there is trust involved, and in my opinion that should not be required in the first place. I know this is hard for many projects, because some are intentionally designed that way and some are just badly structured, but it is still a real problem.

This is also why my tokenomic list is kind of an extended version. There are really a lot of loopholes, even just by launching a token before mainnet on a different chain, promising that it will be swappable in the future, and so on.

There is no way to do an ICO or other kinds of sales if there is no premine, so this requirement already covers some other "unfair" tokenomic cases.

Back to this part, I have a perfect demonstration of how it unfortunately works in practice. There is a ANN in BitcoinTalk, title contains literally "No Premine".
Open the thread, you will find there a 10% "Development Allocation". And I am sorry to tell you, it is not only a one single coin, there are many of them.
Some openly market themselves as "fair launch", others (like the example above) don't claim "fair launch" outright, but still state "fair" in some form.
And the "dev tax" is hidden by such a beautiful words like "Community Contribution", "Market Liquidity Asset", "Team Allocation / Development Funding", "Infrastructure Extension".
I totally get the goal of it and it can be fair if done properly, but this would fall into the dev tax section of our Manifest. There is technical no difference on the purpose or amount.
It only sounds different if you add REAL transparency to that.

I'm almost sure the consensus change item is also not really needed: the open source requirement basically removes the possibility of a retroactive consensus change, because if the code is open source, everybody could just run the code without consensus change.

About this point, I don't fully agree. In theory yes, everybody can just run the old code. In practice, especially with new coins, it is unfortunately very easy to force people into the "official" version.

Most people go for the official coin. They mine it, they run nodes from the official public GitHub repository, and they do not do much research or due diligence. So everything can look like a fair launch, and a few days later an updated version can invalidate a chain because there was some kind of bug and a quick fix was needed. This is also a real story: no warning, no announcement, no future height activation.

But of course the "team" could try to force people into the forked code by committing to promote only that version and threaten to sell all (legitimately mined) coins on the fork without the change.

That is basically the problem, but I think it does not even need to be that explicit. The "official" repository and the "official" team already have a lot of power in the first days. Mining pools are often small services that just update to the latest node version and mine with massive hashrate for that small coin. They usually do not care about the deeper fairness question, they just run what the project tells them to run.

And once that worked once, it can happen again in a more polished way. A few days later the team can announce a future height activation (after critique and complaints on the non-announced bad managed case, the one with immediate activation), push update notices, and add something like a x% dev fee from each block. Also a real story here.
So an initially fair-looking coin can become totally unfair in a matter of days.

I think the point by Bray_marcelo is not that important in tradtitional cryptocurrencies, it is also covered by the "open source" rule, but there may be cryptos where checkpoints are very important, so it can be a good recommendation, but I don't think a "proof" is needed here.

I understand the argument, but this again depends on how much trust is hidden behind "open-source". If the published code is not necessarily the exact running code, or if the project can silently control infrastructure around it, then "open-source" alone is not always enough.

For traditional cryptocurrencies this may be less important, yes. But for projects that depend on bridges, checkpoints, bootstrap servers, special launch tooling, or any kind of centrally controlled service, I think it becomes important very quickly. The user should not have to trust that the team runs the same thing they published.

mainnet launch should be from a new genesis block and be called "mainnet" right away, no "rights" on coins/tokens should be possible to be acquired by previous "testnets" or "bootstrap nets".

About testnet rewards going to mainnet: yes, it is a good promotion technique to engage people, make them participate, test the network, and so on. I would compare it to an airdrop or eligibility program: past activity creates a later mainnet allocation. That does not make every airdrop unfair, but if a "testnet" creates rights to mainnet coins, then it is no longer just a testnet in the fair-launch sense.

But I also would not call it fair. If a testnet can create mainnet rights, then the "real" testnet basically has to be treated like mainnet: public announcement, launch date, equal preparation time, and fair access for everyone. Otherwise it is just another hidden allocation mechanism.

That "trick" is really annoying but some seem to fall for it.

Yes, exactly. It looks harmless because it is called testnet, bootstrap net, community reward, early support reward or something similar. But in the end it can still create rights before the real fair launch, and that is the part I would avoid. This is why the wording in the PoFL is very strict: it doesn't matter how it is called, more important is how it works.

For the Proof of Fair Launch checklist, I would add it like this: "no pre-mainnet token, bridge claim, testnet/bootstrap reward, or other IOU should create any right to mainnet coins; mainnet should start from a fresh, publicly announced genesis with reproducible public code."

Would you agree with that wording?