WNF: Web3 Marketing Notes
180 subscribers
44 photos
11 links
Practical Web3 marketing notes from Windy at WNF: content systems, community operations, KOL selection and campaign analysis. Every number carries its source. No signals, no investment advice. Working on something? @wnf_marketing_bot
Download Telegram
A voice guide with no enemy is decoration.

Rainbow's own docs draw the line: keys are generated on the user's device, and backing them up stays the user's job. So the contrast writes itself. "Your keys stay with you" against "support can restore everything for you." In this product, one of those sentences is false.

Real product tension is what makes a voice guide usable. Without it you are handing writers adjectives. Ours lives in the Voice boundary matrix, started the week a lovely, reassuring, completely misleading line nearly shipped. If a line hides a real product responsibility, it dies before approval.

Public example. WNF had no client role.

Write freedom together with responsibility. Soft safety language erases the hardest true thing a product owns.
we run this as an exercise, because it is the most ordinary failure in community work.

A wallet community gets the same recovery question three times in one week. Same shape of words every time. Three good answers get written, and all three sink under a hundred messages about gas. Newcomer four walks into the identical maze.

Repeated wording is not support noise. It is onboarding filing a bug report that nobody reads.

That is why there is a Support-to-FAQ ledger now, with the rule in the open. Three repeats of the same wording in seven days, one FAQ backlog item. Our WNF operating norm.

save the user's exact wording
verify one approved answer against the official source
publish a dated FAQ with the source next to the claim
link that FAQ in later replies and log every repeat

so where do I find that


The last line is what teams skip. If the question keeps coming back after the FAQ exists, the FAQ was not the fix.
The brief was three pages. The useful part was one sentence.

Warden's Halo docs name three roles: consumer, agent, operator. The writing job that finally worked: "Show how one agent buys one inference request from one operator."

One reader question, one mechanism the audience can picture. We call it the One-question brief, and it started the day design, copy and community built three different products in their heads out of the same document.

Public example, we did not work on it.

It is two assignments.
A content calendar gets built last.

Look at what idOS documents and the order appears on its own. Why repeated KYC hurts. What an encrypted portable credential changes. How an Access Grant actually works. When access can be revoked. Four reader decisions, four posts that need each other.

Now look at a calendar with four empty Tuesdays in it. Same number of slots, and each of them will get filled with something wearing a strategy costume.

we sort of covered that already


That sentence is why we keep a Decision-sequence roadmap. If two planned posts answer the same decision stage, they merge or one of them takes a different job.

Public example. WNF had no client role.

Planning holds together when it follows the decisions an audience is actually making.
A quick edit comes back with fourteen comments.

Factual corrections, taste notes, two scope changes, and four duplicates of the same thought. The designer reads it all and still cannot tell which comment blocks publication. (Comment nine and comment twelve were the same note in different moods.)

Mixed feedback turns into work only after two things are explicit: who decides, and what blocks. Everything else is a pile.

So the round runs like this. Sort every comment into fact / goal / taste / scope. Merge the duplicates, and there are always duplicates. Name one decision owner out loud. Send back one ordered change list, blockers at the top.

The Blocker-first change list carries a hard condition: if feedback has no single owner, or mixes facts with taste, it does not go back to design. The WNF internal bar: one owner, one blocker-first list per review round. Comment nine was "vibes are off". It was correct, which made it worse.

Who owned the verdict on your last review round?
Here is what an AMA reliably produces: an hour of attention. Here is what it does not produce on its own: an answer somebody can find next Tuesday.

The announcement holds a guest and a time. No question lanes, no recap owner, no plan for questions that get no answer. The room fills. The room empties. The transcript is four hundred messages of "gm".

We plan the tail before the event:

questions sorted into mechanism, risk, use case, limits
source links ready, plus an honest no-answer path
answered and unresolved marked live, in the room
sourced recap published, durable answers moved into onboarding

That last step is the whole point.

The AMA answer bank exists because we lost three good answers to a chat that scrolled. When an unanswered question has no owner and no source path, the recap is not finished. Our WNF working norm: one sourced recap, one owner for the unresolved pile. A famous guest fills a room. It does not make tomorrow's reader any smarter.
The bug: we published a sentence our own source no longer supported.

A launch thread said the feature was live. The saved link, opened two weeks later, showed an updated roadmap. Nobody could prove which version of that page the sentence came from, because the evidence was a browser tab that had long since been closed.

Impact was small. Embarrassment was not.

The fix has four parts and none of them are clever. Store the claim next to its primary source. Record the page title and the date it was checked. Write down the exact limit that source supports, in one line. Recheck anything dynamic on the day it publishes.

where did we get this again


That question is what the Claim receipt log answers now. If a dynamic claim has no check date, it stays out until someone verifies the primary source again. The WNF operating bar: every dynamic claim gets a publication-day recheck, deliberately boring.

Evidence needs an address, a date, and a limit. Browser history is none of the three.
That yellow box between the red ones is the whole method: one thing lights up, everything else stays sealed.

We once changed five four things in a single test, then argued for a week about which change worked. There was no answer inside the data. There never is.

Hence the Single-variable test sheet. Take Aster: the docs describe Hidden Orders, and they describe position mode inside Shield Mode. Two different mechanisms, so two creatives. Audience fixed, landing page fixed, visual fixed, call to action fixed. That is the entire difference between them.

The result line on this card took us longest to believe: no difference still teaches. When one variable moved and nothing changed, we just learned the audience does not care which mechanism leads, and that argument stops getting budget. The WNF internal rule holds: one variable per test, always. A flat result reads as noise only if three other things moved with it.
what happens now that it's connected


Three newcomers asked that in one week, and all three got a helpful answer. The confusing step stayed put.

This collectible is our old reflex: save, answer, add to onboarding. We ran it for months: the pile of saved wording grew, the wallet-connect path stayed confusing. A resolved question proves the reply worked. And definitely not the interface. Fault isolation comes first:

1. Walk the wallet-connect path with no guidance, like a stranger
2. Sort findings into wording confusion and interface failure
3. Change one line of copy, watch the next three newcomers
4. If the path is broken, escalate with screenshots and exact steps

one copy fix, one path test, then a new FAQ entry

That order is our WNF working norm, kept in the Wallet-connect fault-isolation sheet. If the question returns after the wording fix, the next move is the interface. FAQ can describe a broken door beautifully. It cannot open it.
My first version of the Decision-linked budget map was useless. It sorted spend by category, which is exactly how the problem hides.

A token-launch budget carries one line called miscellaneous, and inside it: design revisions, community tools, paid distribution. Three completely different jobs sharing one number. Then the date moves, somebody asks what can be cut, and the room goes quiet.

The second version sorts by job instead:

what job does this money do
which decision does it support
what breaks if we halve it
who owns it, and when do we look again

Four questions, four columns, and the budget can answer something.

If a line has no job, no owner, and no stated consequence of cutting it, it does not get approved. Not by me. No miscellaneous line passes without an owner and a consequence written beside it, our own WNF operating bar.

The dangerous line is never the biggest. It is the line nobody in the room can explain.
Everything on the dashboard is green. Nobody came back.

Reach up. First visits up. What it does not contain: repeat visits, completed onboarding, or why anyone would open the thing twice.

so we're doing great, right


The report measured arrival. Arrival is easy to measure, which is exactly why it ends up on the slide.

Fixing it took four small moves. Split arrival from return. Name the next action a user should take. Add one return signal and one qualitative reason, in the person's own words. Then choose the next content experiment from the second visit.

That shape is the Arrival-return scorecard, born after we planned a quarter of retention content off a report that could not see retention. The WNF internal norm: one arrival signal, one return signal, one reason, per report. If a report carries no return signal, it does not choose retention work.

Reach tells us somebody noticed the door. Retention only starts when we know why anyone opens it a second time.
The detective on this card is me, and I have one suspect: a genuinely good hook.

It was built on a blog post eighteen months old. Current docs word it differently. The visual has no rights record anyone can find. The line is charming, which is the dangerous part, because good hooks survive review on charm. The better the hook, the harder the interrogation.

The questioning runs down the card, three checks and one move:

official source and its date
current status and the exact claim boundary
asset provenance and use rights
verify, then write and polish

Nothing gets polished until those are clean. We call this the Evidence-and-rights checklist. If source status, claim boundary, or asset rights are missing, the work stops before polish, and every unknown stays marked unknown. The WNF working bar: one source, one check date, one rights record, one factual reviewer.

An unverified claim does not get truer when the sentence gets prettier.
Thirty screenshots of competitor homepages is not a category audit. It is a moodboard with a serious face on.

I know because I did it myself. Two Three days of collecting dark backgrounds and neon gradients, and the finding was that everyone uses dark backgrounds and neon gradients. Dark mode is not insight.

A pattern is a repeated decision. So the folder became a decision-coded competitor matrix: the user question each page answers, the promise, the proof, the risk wording, the first action, the date the evidence was captured.

The small version, runnable this week: five wallets, visuals ignored, coded on how each explains recovery, what proof it shows, what it asks you to do first. Split convention from message strategy. Whatever survives is a testable choice for the brand.

If an observation cannot be coded across at least five comparable examples, it is inspiration, and inspiration should never be filed as category strategy.
A content system is only real if the next draft costs less than the last.

Take CheckDot. Write about Trust Score twice and you will reopen the same twenty tabs twice. Unless one reusable claim record already holds the claim, the official source, the plain-language meaning, the limitation, the owner, and the last verification date. Six fields. Then draft two starts at minute one.

The rule around it is unkind on purpose: any empty field and the claim cannot enter a scheduled draft. Six fields, no exceptions, and that is a WNF internal bar we hold ourselves to.

And the limitation field, well... look, that is the field keeping a careless adjective from turning a score into a promise. The next writer should inherit evidence.
Self-custody is not a feature list. It is a first task with a consequence attached.

Rainbow is a project WNF took part in promoting, so I have spent real hours inside it. The concrete entry is three things and no more: create or import a wallet, back up the secret phrase, and understand that nobody at the company can recover that phrase for you.

That third part is the whole concept. Freedom is the easy half to write. The irreversible half is what makes the first half mean anything, and it is the half every draft wants to soften.

ok and what if I lose it


Worth answering on screen one.

Hence the First-task map: what does the person do first, and what becomes permanently theirs the moment they do it. If a first screen cannot name both, the explanation is unfinished, and the feature list underneath it is protocol wallpaper.
Our drill deck holds a mock NFT card with my face on it, and behind the frame an old key. The key is the lesson.

"Legendary, 1 of 50" describes the frame. Holding a token and being let through are two different sentences. So the copy starts from a rights-access-dependency table: right, access condition, dependency, utility today. Right first, then rarity.

When a field stays unevidenced, rarity drops below it. Our internal rule.

Sparkle is allowed. Ambiguous rights are not.
This thumbs up is a gate.

The tea dependency joke: a skyscraper balanced on one forgotten package. The joke compresses the tension. It cannot carry the mechanism. The caption does that: teaRank maps influence across the open source dependency graph, with no automatic rewards promised. Our Meme mechanism note was born the day we shipped the joke without that half.

If the caption cannot restore the mechanism and its limit, the meme is not ready.

Public example. WNF had no client role.
Six workstreams, one recurring trap.

The WNF engagement with CheckDot covered branding, CMC, community, token deployment, PR and partnerships. Different surfaces, the same failure mode waiting inside each one: a bright verification badge lands first, and the reader takes it for certainty before learning what was actually checked.

Known to the team: what the check covered. Unknown to the reader unless somebody writes it down: everything the check did not touch. That second list is where trust breaks.

So the proof route runs in a fixed order:
one concrete check
the evidence behind it
the boundary it does not cross
the decision it can inform

That order lives in the Verification message map, which we started after a draft that opened with the badge and had to be rebuilt backwards, sentence by sentence.

If the badge appears before the check, the evidence and the boundary, reverse the order. A badge is a conclusion. It is not the argument that earns one.
Three of us pointing at each other, and every finger is a different word: sent, arrived, pending.

That is the meme, and that is also most bridge interfaces, which keep spending one of those words to mean the other two. The button says arrived done while the destination transaction is still pending. Everyone recognises that half second. That recognition is the entire value of a reaction visual: it names the state the user wrongly believes they are in.

Then the caption has to do the boring half. An Orbiter route has a source chain, a destination chain, a recipient, slippage, route steps and a status check, and submission is not completion. Our State-transition caption sheet began as a list of the words support kept re-explaining after one launch.

If the visual says done while the destination is still pending, change the state word or explain the step that is left.

Public example. WNF had no client role.
A reserve claim becomes useful when it carries a date, scope, method and limit.

Backpack's 14 June 2026 Proof of Reserves article described daily public proofs and a user verification path.

Those four fields travel with every proof snapshot.


Which part of the proof can a user verify directly?