[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?

[d5000]

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.

Yes, but that loophole is closed by the item I added. It should be worded in a way that it stays clear that the main "coin" of the chain can only be created as a reward for validation.

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 disagree a bit here. The bridge from the point of view of the blockchain is nothing more than a single user, and if it dies, the blockchain's inner workings aren't affected.

Of course you should be wary about all services offered by the development team. But that's imo a different thing than the technical requirements for the software project. It's actually the same thing than the rule that "there should be no malware distributed by the dev team."

Maybe your list should be divided in two categories: requirements for the software, and recommendations for users. The software requirements would be only the 5 items I proposed, while the recommendations for users are the other items, which are not as "hard" as the software requirement, but are also important to evaluate the trustworthiness of the dev team.

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?

Normally at least for the core software the rules can be clear and simple enough that it's impossible to override them by the "team" running another software than the other validators.

In the case of bridges I agree that is not that easy if the bridge is centralized. But as the bridges aren't part of the core rules, but simply "users" of the protocol, then there is no need to treat the bridge differently than a CEX that simply has that coin listed.

And even bridges can imo be tested in a way that they should always deliver the expected result. If not, then the protocol rules for the bridge aren't clear enough, I think.

Back to this part, I have a perfect demonstration of how it unfortunately works in practice.

I think this can be solved with a wording which focuses on the technical character of the "dev tax":

- New coins can only be created for validation. No coins can be derived from the validator reward nor from transaction fees and paid out to a hard-coded address or wallet identifier.

This would even eliminate two more items: it would basically prohibit any kind of premine, any kind of swap for testnet/"ICO tokens", and any kind of dev tax or "community contribution".

(Basically the first sentence is also very similar how a decentralized cryptocurrency is defined in the European rule framework MiCa. All crypto-assets where coins are created for other purposes than validation - with some very limited exceptions - have to be registered at the authorities with a "whitepaper".)

In practice, especially with new coins, it is unfortunately very easy to force people into the "official" version.

Yes, this is maybe an important item but not for the "hard" software requirements but for the "recommendation" section I mentioned above.

Of course you can include what you want in your list, I'm only giving my opinion to be as precise as possible. I created some threads in different local sections about "decentralized" cryptocurrencies, e.g. this one, this one, and this one, and the sentence I outlined is basically the main criterion I'm using. There was also a list by another user here which goes even a bit further as it added some "ecosystem" requirements too. Your list is maybe a bit more in line with his list

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."

Yes, but I think I found a more precise alternative above It could be an excellent clarification of the "pure requirement" though.