Distribution archetype

Mining: distribution as a byproduct of paying for security

Bitcoin's whitepaper describes the incentive directly: the first transaction in a block creates a new coin owned by the block's creator, which both distributes coins into circulation and pays for the work securing the chain.¹ There was no allocation table. Supply reached holders because they spent real resources competing to produce blocks.

What this archetype optimizes for is credible neutrality. Nobody was handed supply, so nobody has a cost basis the public cannot match, and there is no vesting schedule to argue about because there is nothing to vest. It is the reason Bitcoin remains the reference point every fair launch claim is measured against.

What it costs is control and capital. Distribution takes years, the team funds development from somewhere other than the token, and the project has no treasury unless it builds one afterwards. Very few teams building an application or a compliance-heavy product can run this way, which is why the archetype is invoked far more often than it is used.

The sale: capital first, holders second

In a sale archetype, tokens go to buyers in exchange for capital, usually in private rounds well before any public trading. dYdX's original distribution allocated about 27.73 percent of its 1,000,000,000 token supply to past investors and about 15.27 percent to founders, employees and consultants, with founder and employee tokens vesting over four years and investor terms running three to five years depending on the individual agreement.²

This archetype optimizes for funding certainty and speed. It also creates the entire vesting problem, because it puts large blocks of supply in the hands of holders with a cost basis far below the public price and a fiduciary duty to realize returns. Every cliff, every vest and every unlock calendar in this glossary exists because of that structure.

It also carries the heaviest regulatory weight of the four. Whether a particular sale structure raises securities questions is fact-specific and jurisdiction-specific, and that analysis belongs with counsel rather than a design document. What a designer controls is the supply consequence, and the supply consequence is a schedule.

The airdrop: distribution first, and the sybil tax

Uniswap set the template. Its genesis supply of 1,000,000,000 UNI put 60 percent with the community, including 400 UNI claimable by every address that had ever called the v1 or v2 contracts before a snapshot date.³ The distribution was retroactive, unannounced, and required nothing from recipients beyond having already used the product.

The archetype optimizes for breadth and speed of ownership, and for rewarding behavior that already happened rather than behavior a team is trying to buy. What it attracts, unavoidably, is address farming. Arbitrum's published eligibility rules subtract points when all of a wallet's transactions occurred inside a 48 hour window and disqualify addresses identified as sybils through the Hop Protocol bounty program.⁴

How much leaked anyway is genuinely unknown. The Arbitrum Foundation published the exclusion rules but no aggregate count of excluded addresses. Two independent analysts put out numbers that disagree by roughly half: X-Explore reported more than 148,595 sybil addresses receiving the airdrop.⁵ Trusta Labs reported 96,755 sybil addresses in the eligible list, capturing about 164 million ARB.⁶ Neither is an official figure. Presenting both is the honest version, and the spread between them is the actual finding.

Not every project takes this route. Sui ran no token airdrop at mainnet launch at all, a deliberate choice its documentation states plainly.⁷ The archetype is a decision, not a default.

Choosing an archetype is choosing your first holders

Each mechanism selects for a different person. Mining selects for operators willing to commit capital equipment. A sale selects for funds with a return horizon and a mandate. A retroactive airdrop selects for people who used the product before there was any reward for it. A pre-announced airdrop selects for people optimizing for the airdrop.

That last distinction is worth sitting with, because it is the one teams get wrong most often. Announcing criteria in advance converts a distribution mechanism into an incentive program, and the behavior you get back is the behavior you specified rather than the behavior you wanted. Retroactive distribution avoids that at the cost of being unable to use the airdrop to drive usage.

Most real launches combine archetypes: private rounds for capital, a retroactive airdrop for breadth, and ongoing emissions for whatever the network needs bootstrapped. Combination is fine. What matters is that each component is chosen on purpose and that the combined supply consequence lands in the same allocation model rather than in three separate conversations.

The archetype cannot rescue a weak business

A distribution mechanism decides who holds tokens on day one. It has nothing to say about why anyone would want to hold them on day four hundred. Across 100+ projects and $100MM+ in combined raises, the launches that struggle are rarely the ones with the wrong archetype. They are the ones where the archetype was asked to substitute for a reason the token should exist.

So the sequence is: establish what the business does and where its revenue comes from, pick the archetype that puts supply with the people who make that business work, then size the buckets. Reverse it and you get a beautifully executed distribution to holders with no reason to stay.

The token is infrastructure. The business is the engine. Nothing on this page is a recommendation to buy, sell or hold any token.