A Web3 KOC campaign brief template should make one thing testable: can people with genuine product experience explain a specific use case honestly, with clear disclosures, while the team measures relevant user actions? A useful brief defines who qualifies, what may be claimed, what is paid for, what must be delivered, and how the campaign will be reviewed. It does not treat a small audience as proof of authenticity or a wallet connection as proof of a new customer.
Use the template before recruiting contributors. It is for wallet, DeFi, exchange and other Web3 teams with a working user journey. If that journey cannot be demonstrated safely, fix it first.
Key Takeaways
- Define one product behavior and one eligible audience before assigning KOCs to create content.
- Verify the experience behind each proposed claim; do not demand private keys or unnecessary wallet history.
- Record every material benefit and require a clear disclosure where the endorsement appears.
- Approve facts and safety boundaries, not a compulsory positive opinion or scripted testimonial.
- Report eligible actions, exclusions and unknown-source activity separately from impressions and post counts.
Table of Contents
- What the brief must contain
- How to set the campaign objective
- KOC eligibility and verification
- Deliverables, claims and disclosures
- Measurement, review and pause rules
- Copyable Web3 KOC campaign brief
- Product-specific adjustments
What Should a Web3 KOC Campaign Brief Include?
The brief is a shared decision record for growth, product, compliance and contributors. It must be precise enough that a suggested talking point cannot be mistaken for an instruction to praise the product. The table is a minimum specification, not a universal post count or budget.
| Brief field | Decision to record | Evidence to retain |
|---|---|---|
| Product and use case | Which feature and version may be shown? | Official product URL and approved facts |
| Audience and market | Who is the content for, and where may it run? | Market/language and eligibility rules |
| KOC qualification | What firsthand action must the contributor have completed? | Consent-based demonstration or permitted event |
| Deliverables | What format, channel, language and due date are required? | Draft, live URL and rights terms |
| Incentives | What cash, tokens, access or referral benefit is provided? | Written terms and disclosure copy |
| Claims and safety | What must be accurate, qualified or avoided? | Fact sheet, risk note and correction owner |
| Measurement | What is the primary eligible user action? | Event definition, exclusions and attribution plan |
| Review | Who approves facts, compliance and publication? | Named owners and dated decisions |
The Web3 KOC marketing playbook covers the wider program. This template turns that program into an assignment a contributor and review team can actually execute. It should not be copied unchanged across products: a wallet setup story and a DeFi transaction walkthrough have different risks.
Step 1 — Set One Web3 KOC Campaign Objective
Name the audience, feature and action: “Help first-time users in [market] understand [feature] and complete [eligible action].” Keep awareness, activation and retention separate; reach does not prove product use.
Choose one primary event before publication, specifying version, market, observation window and exclusions. A wallet team might count eligible first activation; a DeFi app might count interaction with a named contract. These are examples, not benchmarks. Record a baseline without automatically attributing change to KOCs.
Provide supported devices, limitations, official URLs, risks and a support contact. Verify that the feature and support route work in the target market; do not ask for an unavailable or unsafe demonstration.
Step 2 — Define KOC Recruitment and Experience Verification
A KOC is selected for relevant firsthand product use, not for falling below a follower threshold. The brief should state the required experience and the lowest-risk way to check it. A permitted in-product event, opted-in walkthrough or support history may establish familiarity with a specific task; none automatically proves that one wallet equals one unique person.
| Evidence level | Example | Suitable brief decision | Limit |
|---|---|---|---|
| Self-report | “I used the product” | Invite to an interview | Not verification |
| Demonstration | Contributor shows the described task | Permit a bounded firsthand claim | May be a test account |
| Permitted event | Consent-based product record | Confirm that an action occurred | Does not prove one person or retention |
| Continued use | Eligible actions across a declared period | Support a longer-use narrative | May still be incentive-driven |
Do not request seed phrases, private keys, complete wallet histories or government IDs unless a separate, lawful process genuinely requires them. Minimize the evidence collected and document who may access it. In the EU, the European Commission's data-protection guidance describes individuals' rights and controllers' information duties; have counsel assess the actual markets and data flows.
Invite candidates neutrally: ask what worked, what failed and what they would tell another user. Record opt-in and proposed benefits before assignment. If a user reports a safety problem, route it to support or security rather than turning it into a campaign asset. Use the separate Web3 KOC verification checklist for a detailed proof-of-use review; the brief needs only the agreed eligibility rule and evidence owner.
Step 3 — Specify Deliverables Without Scripting Praise
For each asset, name the channel, format, language, length or duration, product version, due date, revision allowance, live period and usage rights. Set requirements for accuracy and disclosures, but leave room for a real opinion. A brand can correct an incorrect feature name; it should not transform a negative experience into a positive testimonial.
Ask contributors to show the step they completed, explain one point of friction, and state who the feature may suit. Prohibit invented transactions, fabricated screenshots, guaranteed returns and impersonation. Supply approved referral links and relationship labels.
In the United States, the FTC's endorsement disclosure guide says material connections such as payment or free products should be disclosed clearly. The FTC's Endorsement Guides Q&A adds practical disclosure examples. Use legal review for the relevant market; a contributor's actual product use does not remove the disclosure obligation when a material benefit exists. The KOC incentive-design guide explains how to separate creator compensation from any user rewards; the brief should simply record the chosen terms.
The crypto KOL campaign brief template is a separate reference when the assignment primarily buys expert interpretation or audience distribution. Do not silently recast a paid audience campaign as independent user testimony.
Step 4 — Freeze the Measurement Plan Before Launch
Write down what will be counted at three levels: delivered content, audience response and product outcome. A live post URL is a deliverable, not a user. A referral click is a visit, not an eligible activation. A wallet connection is an event, not evidence of retained use. The KOC campaign reporting template explains unique links, eligible events and the unknown-source bucket; the brief should lock the definitions before the campaign starts.
| Reporting layer | Minimum fields | Decision supported |
|---|---|---|
| Delivery | Contributor, URL, publish date, disclosure, correction status | Was the work completed correctly? |
| Response | Relevant replies, qualified visits, support questions | Did the intended audience engage? |
| Outcome | Eligible actions, exclusions, unknown source, continued use | Did the product receive relevant use? |
| Cost | Fees, rewards, production, management, measurement | What did the pilot actually require? |
An illustrative pilot may use one market, one feature and one primary event. Review a 7-day activation cohort and a 30-day continued-use cohort only if those windows fit the product cycle; these are planning examples, not reported performance norms. For event naming, Google Analytics' recommended events documentation lists standard options such as sign_up and generate_lead, but a Web3 team must implement and validate its own product events.
Do not divide total spend by all wallets when the brief promised qualified people. Define the denominator, duplicate rules and identity limits. Keep unknown-source activity visible; assigning every unattributed action to the nearest content post creates false certainty. Report the cost of the pilot even when sample size is too small for a causal ROI statement.
Step 5 — Set Review, Correction and Pause Rules
Name an owner for product facts, legal/compliance checks, live-link inspection and post-publication correction. Set review deadlines so contributors are not held indefinitely. Keep a record of the original claim, requested edit, decision and live correction.
Require an immediate pause for hidden payment, unsafe links, false use claims, exposed secrets or unsupported financial promises. A pause is a safety control, not proof of misconduct. Explain how contributors can dispute corrections or pressure to change an honest opinion.
Specify reuse channels, duration, paid amplification and what happens if disclosures or product features change. Payment for production does not imply unlimited reuse.
Copyable Web3 KOC Campaign Brief Template
Copy this into a shared document, replace the brackets, and retain the approved version.
WEB3 KOC CAMPAIGN BRIEF — VERSION [ ] / DATE [ ]
1. Product and use case
Product, feature, version and official URL: [ ]
The exact user journey to show: [ ]
Known limitations, risk notes and support contact: [ ]
2. Objective and audience
One primary campaign objective: [ ]
Target users, market, language and channel: [ ]
One eligible product action: [ ]
Baseline, observation window and exclusions: [ ]
3. KOC qualification
Required firsthand experience: [ ]
Consent-based verification method: [ ]
Data collected, access owner and retention period: [ ]
Opt-in confirmation and contact permission: [ ]
4. Assignment
Format, channel, language and deliverables: [ ]
Draft date, publication date and live period: [ ]
Required factual points and approved links: [ ]
Required honest-use detail and permitted criticism: [ ]
Prohibited claims, screenshots and unsafe instructions: [ ]
5. Incentive and disclosure
Cash, tokens, access, referral and other benefits: [ ]
Disclosure language and placement for each channel: [ ]
Payment condition; never contingent on positive sentiment: [ ]
6. Review and rights
Product reviewer, legal/compliance reviewer and final approver: [ ]
Fact-check turnaround and revision limit: [ ]
Usage rights, paid amplification and expiry: [ ]
Correction, dispute and pause contacts: [ ]
7. Measurement and reporting
Placement ID, tagged URL and tested destination: [ ]
Delivery metrics, relevant-response metrics: [ ]
Eligible action, exclusions and unknown-source bucket: [ ]
Fees, rewards, management and measurement costs: [ ]
Review date and continue/revise/stop criteria: [ ]
How Should Wallet, DeFi and Exchange Teams Adapt the Brief?
| Product type | Firsthand experience to verify | Story boundary | Eligible action example |
|---|---|---|---|
| Wallet | Setup or named feature use | Never reveal a seed phrase or private key | Eligible activation of the feature |
| DeFi app | Specific interaction on the stated contract/version | Explain transaction risk; avoid return promises | Eligible completed interaction |
| Exchange | Onboarding or tool use under local rules | Review trading and referral claims by market | Approved account or feature action |
| Layer 1/2 | Developer or app-user journey | Separate testnet, bots and bridge-only activity | Defined app or network action |
These are example events, not conversion benchmarks. The team remains responsible for accurate product facts, safe links, disclosures and measurement.
Conclusion
The Web3 KOC campaign brief template is a practical control for turning real user experience into honest, reviewable content. Start with one product journey and one eligible audience, verify the claimed experience proportionately, document every incentive, permit criticism and define the primary product event before publishing. Use the template as a shared agreement, then revise it after the pilot using the recorded corrections, qualified actions and unknown-source activity—not post volume alone.
