A new Layer-1 attracts its first serious projects by offering what those teams cannot get on an established chain: early users, launch liquidity and a partner who will carry their launch. Grants alone rarely decide it. Serious teams have options, and Electric Capital’s 2024 data shows about one in three crypto developers already work on more than one chain.
Who decides this
The head of ecosystem at the Layer-1 owns this decision. They are accountable for which projects the chain courts, what it offers each one, and whether those projects are still live and used a year after launch. The foundation council sets the budget and the rules. The head of ecosystem decides how to spend them, and should report on outcomes, not on the number of announcements or signed letters of intent.
Which projects count as “serious” for a new chain?
A serious project is a team with funding, a shipped product somewhere else, an audit history and users who would follow it. Those are the teams that turn a chain from a testnet with a token into a place people use. They are also the hardest to win, because they are being courted by every other chain.
Layer 1 ecosystem development should start from a short named list, not an open call. Write down the categories the chain cannot work without: a stablecoin route, a decentralized exchange, lending, an oracle, a bridge, wallets and an explorer. Then name two or three target teams per category. Electric Capital reports that developers with two or more years in crypto make 70% of code commits. That is the pool a new chain is competing for, and it is small.
Approach each target with a specific proposal, not a generic pitch deck. Say why the chain needs that team, what it would offer, which other projects will be live at the same time, and who on the ecosystem team will own the relationship. Senior teams judge a chain by how prepared its first conversation is.
What can the chain offer that a team cannot get elsewhere?
The chain should offer economics and distribution a team cannot get on a larger network, because on raw grants it will usually be outbid. Chains have built several distinct levers, and each attracts a different kind of team.
| Lever | Example | What it attracts | What it costs the chain | Main risk |
|---|---|---|---|---|
| Upfront grants | Foundation grant programmes | Early-stage builders | Treasury tokens, paid before results | Grant farming and abandoned projects |
| Fee sharing | Sonic pays developers 90% of the network fees their apps generate | Teams with real usage | Fee revenue the network would otherwise keep | Rewards activity, not quality |
| Retroactive rewards | Avalanche’s $40M Retro9000 programme | Teams confident they will deliver | Budget paid after results | Cannot fund a team that needs capital to start |
| Usage incentives | Arbitrum’s 50 million ARB short-term incentive programme | Live protocols chasing liquidity | Tokens paid to users and protocols | Activity that leaves when incentives end |
| Launch and distribution support | Co-marketing, launch partners, liquidity planning | Teams launching a token or product | Staff time and partner relationships | Promises the chain cannot keep |
Two of these deserve more attention than they get. Sonic’s fee monetization programme sends 90% of an app’s network fees to its developers and 10% to validators, which turns the chain into a revenue partner rather than a grant-giver. Avalanche’s Retro9000, launched in November 2024, offered $40 million in retroactive rewards to builders on its new testnet. Both reward teams for what they produce, which filters for the teams a chain actually wants.
Should the chain pay upfront or reward results?
Pay upfront only for infrastructure the chain needs before any application can work, and reward everything else on results. Upfront money buys commitment from teams that would not otherwise come. It also buys commitment from teams that are only there for the money, and the chain cannot easily tell them apart in advance.
The evidence on incentives is real but partial. OpenBlock’s analysis of Arbitrum’s incentive programme found that 30 grantee protocols grew TVL by 118.2% during the programme, against 35.6% for protocols without grants. It did not report what remained after incentives stopped. A head of ecosystem should treat in-programme growth as the start of the measurement, not the result.
In what order should the first projects arrive?
Infrastructure first, then core financial applications, then consumer products. A lending market needs an oracle and a stablecoin. A consumer app needs wallets, a bridge and somewhere to trade. Courting a game studio before the chain has these is asking it to build on an empty street.
Arbitrum’s gaming programme reflected this in its design. The original proposal set aside 40 million of its 200 million ARB for infrastructure and tooling, alongside 160 million for onboarding and growing game builders. A new Layer-1 should go further. It should close its infrastructure gaps before launching any application-facing programme, and publish the list of what is live so serious teams can check it.
What does the chain owe a project after it deploys?
The chain owes its first projects users and liquidity on launch day, because that is the gap between a new chain and an established one. Deployment is the easy part. A serious team will ask, before it signs, who will use the product in week one and where the liquidity will come from.
User-side programmes can answer part of that. Sonic’s airdrop programme set aside 190.5 million S for users, with 75% of each user’s allocation maturing over 270 days and early withdrawals partly burned. Programmes like this give users a reason to stay on the chain long enough to try its applications. They do not replace a launch plan for each project.
The chain should also line up the venues its first projects will need. That means wallets that support the chain on launch day, at least one route for users to bring stablecoins in, and exchanges or aggregators where each project’s token or product can be found. A project that launches into a chain with none of these in place spends its first months on plumbing instead of users.
How should the chain measure whether onboarding is working?
Measure what the first projects are still doing six and twelve months after launch, not how many signed on. Deployment counts and letters of intent are easy to collect and say little about whether the chain is working.
We would track four numbers for each project in the first cohort: monthly active users, liquidity in its main markets, fees or revenue generated on the chain, and whether the team is still shipping. Review them monthly with the project, not only internally. A project that is struggling in month three can still be helped. One that is found to be struggling in month twelve usually cannot.
Report the same numbers to the foundation council for the cohort as a whole. This changes what the ecosystem team is rewarded for. It also gives the council a basis for deciding whether to fund a second cohort, change the levers, or stop programmes that are not producing results. Ecosystem growth that cannot be shown in these terms is usually announcement growth.
What goes wrong: distribution left to chance
The common failure is a chain that wins projects and then leaves each one to find its own users. The ecosystem team counts deployments. The announcements go out. A few months later, most of the new applications have thin liquidity and little repeat use, and the teams start shipping to other chains.
The cause is that onboarding projects to a chain was treated as the finish line. No one planned the launch sequence across projects, so they competed for the same small audience in the same weeks. No one arranged launch liquidity, wallet placement or exchange support. Each team assumed the chain would bring users, and the chain assumed the teams would.
The fix is to run the first cohort as one coordinated launch programme. Stagger launches so each gets attention. Plan liquidity and token unlocks for each one. Give every project a named contact on the chain’s team who is accountable for its first ninety days.
How Alcyone approaches it
Alcyone works with chains on the launch plan for their first projects, not only on attracting them. That means sequencing launches, planning liquidity, setting up locks and vesting, and naming an owner for every part. Alcyone’s ecosystem and launch advisory work includes a major Layer-1 where the first token launch on the chain brought 5,000+ new holders. Engagements begin with a thirty-minute call with a senior partner, followed by a fixed-scope, fixed-fee assessment credited against further work.