Token design is four decisions that must be made together, because each one sets limits on the other three. In our view, allocation shapes governance more than any voting rule. A European Central Bank study of four large DeFi protocols found the top 100 holders controlled more than 80% of governance tokens in every one.
Most token models are built in pieces. Supply comes from an economist, allocation from the cap table, utility from the product team and governance from a template. Each piece can be sound and the token still fail, because nobody checked how they interact.
Who decides this
The foundation council owns token design as a whole. It approves the supply schedule, the allocation, the utility the token is promised to carry and the governance rules that let holders change any of them. The council is accountable to holders for how those parts fit together, and it should not delegate that fit to the specialists who design each part. Its practical job is to refuse any one decision that has not been tested against the other three.
What should the supply schedule be built to do?
Supply should be designed as a policy tied to usage, not as a single number chosen for the token paper. A fixed maximum supply, an emission schedule and a burn are all tools. The question is what each one is meant to fund or offset.
Emissions pay for something: validators, liquidity, staking or growth. Each emission line needs a purpose, a budget owner and an end date or review date. Without those, emissions become a standing sale of the token to pay for activity nobody has measured.
Burns tie supply to activity. Ethereum’s EIP-1559 change in August 2021 split fees so that the base fee is burned rather than paid out. In the first week, about 32,100 ETH was burned against roughly 61,600 ETH issued to miners. The design made net supply depend on network use. That is the point of good token supply design: the schedule should respond to the thing the token exists to support.
A fixed maximum supply is not a safe default either. It removes the option to pay for security or growth later without a governance change. We would rather see a cap with a stated emissions budget than a cap that the team quietly expects to raise.
For a council, the test is simple. For every source of new supply, name what it buys. For every sink, name the activity that drives it. If either list contains an item with no answer, the schedule is not finished.
How should allocation be split, and what does each bucket owe the system?
Each allocation bucket should exist to do a job in the system, with a release schedule matched to that job. Allocation is not only a fairness question. It decides who can sell, who can vote and who has a reason to build.
The market has no standard. Tokenomist, which has proposed standard allocation categories because projects report them so inconsistently, found insider allocations averaging over 51% of supply among liquid staking tokens. Derivatives tokens averaged about 49% to the community. Its analysis did not treat either level as good or bad in itself. What it flagged was the effect on centralisation and on selling when insider tokens unlock.
Community allocations have their own design problem. Keyrock’s review of 62 airdrops found that drops under 5% of supply tended to do well at 15 days but often sold off within three months. Drops above 10% did best over longer horizons. Keyrock pointed to Drift, which rewarded long-term users and released in stages, as an example of a drop that limited farming and selling.
Release schedules complete the allocation. Streamflow’s May 2026 benchmark, a vesting vendor’s reading of the market, describes a 12-month team cliff followed by three to four years of linear vesting as the standard for founders and core teams. The council should treat that as a floor to explain deviations from, not a template.
What is the token for, and does value reach it?
A token needs a mechanism that makes holding it worthwhile: it is required to use the network, it receives a share of value, or it controls decisions with economic weight. Good token utility design names the mechanism and shows the path by which value reaches holders.
The hard part is that utility depends on the other three decisions. A fee share or buyback changes net supply. A governance-only token depends on allocation, because a vote is only worth something if holders can influence it. And adding utility later requires governance to approve it.
Uniswap shows the cost of deferring the decision. Its UNI token launched as a governance token without a protocol fee flowing to holders. In December 2025, governance approved a proposal with 99.9% support that sends part of trading fees to the protocol to buy and burn UNI. It also set a one-time burn of 100 million UNI, which The Block describes as an estimate of what might have been burned had the fee switch been active from launch. The decision was eventually made, but through a vote and years after launch. A council designing now should decide the value path before launch, even if it switches it on later.
Does the governance design match who will hold the tokens?
Governance rules should be designed for the token register the allocation will produce, not for an idealised community. Quorums, proposal thresholds and delegation only mean something relative to who actually holds and votes.
The ECB paper is the clearest public evidence on how this plays out. In the four protocols studied, the top five holders alone controlled between about 36% and 59% of supply. Voting ran mainly through delegates, and the share of circulating supply delegated was modest: 5% at Ampleforth, about 15% at MakerDAO and about 27% at Uniswap. The authors concluded that, on public data, it was unclear who held decision-making power. Note that the data dates from late 2022 and May 2023, and the Uniswap Foundation has disputed parts of the Uniswap figures.
Delegation is not a fix on its own. It moves power from many holders to a few delegates, which can be healthy if the delegates are known and accountable. It is a risk if they are not.
For a council, three design checks follow. First, model the register at launch and after each major unlock, and ask who could pass a proposal alone. Second, decide which parameters governance may change, and which stay fixed or behind a delay. Third, keep a record of who controls admin keys and upgrade rights, because governance that cannot touch them is governance in name only.
How the four decisions constrain each other
The table shows the dependencies a council should test before approving any single decision.
| Decision | Depends on | What breaks if it is set alone | Council test |
|---|---|---|---|
| Supply | Utility, allocation | Emissions fund activity nobody measures; burns with no usage behind them | Every source and sink of supply named with what it buys or reflects |
| Allocation | Supply, governance | Insiders can pass any vote; unlocks cluster in thin months | Model the token register at launch and after each major unlock |
| Utility | Supply, governance | Value path needs a later vote; fee share changes net supply unmodelled | Value path decided before launch, even if switched on later |
| Governance | Allocation, utility | Quorums meaningless against the real register; admin keys outside its reach | Who could pass a proposal alone, and what governance cannot change |
What goes wrong: tokenomics the contractor rewrote
The council approves a system. The build is then split across contractors, and each changes its piece without seeing the others.
The staking developer sets an emission rate that seemed reasonable for the staking product. It was never added to the supply schedule. The governance module ships with the framework’s default quorum, which a handful of insider wallets can meet. A distribution vendor drops the staged release from the airdrop to save a contract. Each contractor made a defensible local choice. Together they rewrote the token design, and the council finds out from on-chain dashboards after launch.
The defence is one owner for the whole system through the build, not just the design. Every deployed parameter is reconciled against the approved model before launch. Any change after that goes back to the council with a note on which of the other three decisions it affects.
How Alcyone approaches it
Alcyone treats the token as one system, and its engagements run from the plan through the launch window, so the council can check that the parameters that ship are the ones it approved. Vesting structures sit together with fundraising strategy in Alcyone’s fundraising and tokenomics advisory, and every part of the plan has a named owner. In one published case, a major Layer-1’s first token launch brought more than 5,000 new holders, the kind of register the governance design then has to serve. Clients are under no obligation to use TrustSwap products.