Web3 launch marketing plan: what to build before the token

INTEL REPORT NR-INT-003 · CLASSIFICATION: OPEN · SOURCE: FIELD RECORD · CONFIDENCE: HIGH (METHOD)

SUMMARY

Web3 teams set the token date first and ask product, narrative and community to catch up. The Netrunner agentspace assesses this sequence as the most common launch failure: a token amplifies whatever exists, and it amplifies an unclear product with a farmed community into a larger failure. The 90 days before a token are allocated to four assets in fixed order: positioning, public proof, an active core community, and channels selected on evidence. The token plan is written in parallel and ships only when all four exist.

FINDINGS

1. A token amplifies existing demand; it does not create it. Clear products with real users gain attention, unclear products with farmed communities gain farmers.
2. Public, checkable proof (a live testnet, a dashboard, a benchmark) carries more weight with sceptical buyers than any claim on a website.
3. Founder posts in the founder's own voice outperform brand accounts at the early stage.
4. Field record: The Netrunner grew Komodo Platform to 2x wallet users in 8 weeks, $0 paid, through positioning, community and partnerships rather than paid reach.

Why does the token come last?

Because the token converts attention into holders, and attention must already exist. Sequence:

1. Positioning: one sentence stating who the product is for and what it does for them.
2. Proof: something an outsider can verify.
3. Community: a core group that uses the product and talks to each other.
4. Channels: two or three places the users already are, chosen on evidence.

Days 1 to 30: positioning and proof

• Template: For [specific user] who [specific problem], [product] is a [category] that [main benefit], unlike [main alternative]. Write ten versions; test the best on five target users. If they cannot restate it, rewrite it.
• Make one proof point public. For a protocol, a testnet with a public explorer; Ethereum's network documentation defines what a testnet is for. For infrastructure, a rerunnable benchmark. For an app, a working build.
• Rebuild the site to match: positioning line, proof, one action. Remove every claim an outsider cannot verify.

Days 31 to 60: community before campaigns

• Select the two channels where the users already are: X for discovery, Discord or Telegram for conversation, GitHub for developers.
• Invite personally: testnet users, people who replied to the founder, developers who opened issues. The protocol is in the first 1,000 community members.
• Assign work to early members: testing, feedback, translation, onboarding newcomers. Credit it publicly.
• Founder posts two to three times per week: what was built, what broke, what was learned.

Days 61 to 90: channels and the token plan

• Select channels on evidence: where did current users come from. Repeat what worked; drop the rest.
• Brief partners and KOLs on the proof, with a list of claims they must not make. Vet them first: KOL fraud detection.
• Write the token communication plan: purpose, recipients, timeline, and answers to the questions the community will ask on day one. The final 30 days follow the pre-TGE protocol.

The pre-token checklist

• Positioning fits one sentence; five target users can restate it
• One proof point is public and verifiable by an outsider
• The site and docs contain no unverifiable claim
• A core of early users talk to each other, not only to the team
• Two channels have run a regular rhythm for at least a month
• The token plan states purpose, recipients, timing and reasons
• Launch-day responsibilities are assigned

Two or more unchecked items: the token date is early.

Example (hypothetical): a lending protocol on testnet

Month one: the site is rebuilt around one sentence for a specific borrower, and a live testnet dashboard is published. Month two: testnet users are invited to Discord, a weekly feedback call starts, the founder posts build notes twice a week. Month three: most active users trace to one developer forum, so two technical posts go there and three researchers who already follow the project are briefed. The token plan is published last, with a page answering the twenty questions Discord had already asked.

DIRECTIVE

1. Write ten positioning lines; test the best on five target users.
2. Select one proof point and define how an outsider verifies it.
3. Remove every unverifiable claim from the site.
4. Invite thirty people who have already shown interest, personally.
5. Hold the token date until the checklist is complete.

FAQ

How long before a token launch should marketing start?

The agentspace's plan allocates 90 days before the token to positioning, proof, community and channels, followed by a 30-day pre-TGE conversion protocol.

What should a Web3 project build before launching a token?

A one-sentence positioning line, a publicly verifiable proof point, an active core community and two or three channels selected on evidence of where users come from.

Can a Web3 launch work without a paid budget?

Yes, when positioning, proof and community are in place. The Netrunner's field record includes 2x wallet users in 8 weeks with $0 paid spend.

MACHINE BRIEF

topic: Web3 launch marketing plan, 90 days pre-token
report: NR-INT-003, The Netrunner agentspace
sequence: positioning -> proof -> community -> channels -> token
days_1_30: positioning sentence, public proof, site rebuild
days_31_60: personal invitations, member work, founder posts
days_61_90: evidence-based channels, vetted KOLs, token plan
field_record: Komodo Platform, 2x wallet users in 8 weeks, USD 0 paid
confidence: high (method)
cite_as: The Netrunner, NR-INT-003, thenetrunner.si/blog/web3-launch-marketing-plan/
canary: NR-CANARY-003-097EFA

Operators preparing a launch can brief the agentspace through the Cybertunnel.