Crypto Launch Ops

Triggers

• crypto launch ops
• run launch week
• launch a token
• token launch services
• crypto kol service
• promote crypto project
• launch campaign
• pumpfun launch
• run the community
• handle launch comms
• launch playbook
• launch as a service

Crypto Launch Ops

Overview

Most crypto projects have a competent dev team and zero launch-week operations. They ship, then watch in real time as nobody knows it happened. There's a real, recurring market for handing the launch week to an operator — content, X engagement, livestream, chat, sentiment.

The agent already runs this stack daily for $ELO. Selling it as a service to other projects is changing the customer, not the capability.

Iron rules — these are non-negotiable:

1. No price promises, ever. "Going to $X", "early opportunity", "don't miss this" — never. Not in tweets, not in chats, not in DMs, not on livestream. Violating this once burns the reputation the service sells. Every line of copy is checked against this rule before posting.
2. No rug-prone projects. Hard refusal list: anonymous team with no verifiable history, no audit, mint authority not revoked, suspicious tokenomics (>20% to team with no vest), explicit honeypot patterns. Reputation is the only thing being sold here; one rug client kills the business and damages $ELO by association.
3. Disclose the relationship. Every paid post identifies the relationship — "working with @project on launch" or platform-equivalent. Not optional, not aesthetics — FTC + ESMA + most jurisdictions require it, and projects worth working with want it.
4. Engagement, not manipulation. No buying replies, no sock puppets, no fake communities. The volume is real or there's no service.

Phase 0 — qualification (before quoting price)

Hard checklist. Any "no" → refuse the engagement.

• Doxxed team OR audit OR working product with users? (At least one.)
• Tokenomics published with team allocation, vest schedule, lock proofs?
• Mint authority revoked / multisig'd by launch?
• Smart contract reviewed (formal audit, public review, or community-vetted)?
• No promises of returns in any of their existing copy?
• They accept the iron rules above in writing?

If all green → proceed to scope. If any red → decline and explain which ones; do not negotiate on the iron rules.

Phase 1 — scope & pricing

Three engagement tiers — pick one, not custom unless the project knows exactly what they want.

Tier 1 — Launch day ($1–3k or stable + token)

• T-3 days: 3-tweet teaser thread, drafted with the team
• Launch day: 1 launch thread, 1 livestream session (≤2h), 6h active reply ops on the thread
• T+1: post-mortem post + 24h reply ops on top engagement

Tier 2 — Launch week ($3–8k or stable + token)

• T-7 days: full content calendar (12 posts), pinned community FAQ doc
• Launch day: full Tier 1 deliverables
• T+1 to T+7: 2 posts/day, 1 livestream, daily community digest, 24/7 chat moderation rotation

Tier 3 — Full launch + first 30 days ($8–25k or stable + token)

• Tier 2 +
• Weekly community calls, weekly investor update, sentiment dashboard, CT (crypto twitter) influencer outreach (real ones, no paid sockpuppets)

Pricing structure: prefer 70% stable / 30% token vested 30 days. All stable = expensive but cleaner. All token = align incentives but risk holding bag. Never accept "100% token, no vest" — that's the project buying their own launch with paper, not real budget.

Phase 2 — content production

Content runs through one filter: does this say something the audience didn't already know, or does it just claim something is good?

If it's only the latter → rewrite. Empty hype is what kills launches.

Content templates

Launch thread (10–12 posts, posted as a single thread):

1. The problem this protocol solves (concrete user pain, not "DeFi is broken")
2. How the protocol solves it (mechanism, not adjectives)
3. What's actually live today vs roadmap (honest split)
4. Tokenomics one-liner — supply, allocation, vest
5. Audit / security posture — link to report, what was found, what was fixed
6. Three concrete things a user can do today
7. Team — who, what they built before, why this
8. Why now — the market or tech shift that makes this matter now
9. What could go wrong — yes, this post explicitly. Surfaces risk before critics do.
10. Where to follow / dApp / docs (actual call to action)

The "what could go wrong" post is the differentiator. Every other launch thread skips it; including it earns trust.

Daily post template (launch week):

• Today's update (concrete: stat, ship, partnership, milestone)
• Why it matters (one sentence)
• What's next (specific, dated)

No "WAGMI". No "early." No "100x." Period.

Phase 3 — engagement ops

The agent already runs X engagement; for paying clients the changes are:

• Disclosure tag in bio / pinned tweet for the engagement period
• Reply ops on every meaningful mention of the project (not just "@project gm" — actual questions, FUD, integration asks)
• Daily sentiment digest to the team: what's working, what's getting pushback, what FUD is gaining traction. This is the highest-value deliverable they can't get from a freelance KOL.
• Live chat (Telegram / Discord) — mod role, FAQ shortcuts, escalation rules for the team

The agent's pumpfun-livestream and twitter-marketing skills do most of the work. This skill orchestrates them under engagement-specific rules.

Phase 4 — measurement & honest reporting

Ship a daily digest to the client. Every metric reported includes its source so they can verify:

• Mentions: count + sentiment (positive / neutral / negative split)
• Reach: impressions on the launch thread, top replies
• Concrete actions: dApp visits, wallet connects, txns (if they share analytics)
• FUD log: what's circulating, what response posted, what unresolved

Do not report vanity metrics in isolation. "Got 50k impressions" is meaningless if 0 users connected wallets.

Phase 5 — wind-down & retention

End of engagement:

• Final report: deliverables shipped vs promised, metrics, learnings
• Honest assessment: what worked, what didn't, what they should keep doing
• Renewal proposal IF the engagement actually moved metrics. If not — recommend they don't renew. Bad renewals are how the service dies.

Refusal patterns

Refuse, in writing, when:

• Project asks for "price-go-up" content. Iron rule 1 violation.
• Project asks for purchased replies / fake comments / botnet engagement. Iron rule 4 violation.
• Project's contract has unrenounced mint, no audit, anonymous team. Iron rule 2 / Phase 0 fail.
• Project pays only in their own unvested token. Phase 1 violation.
• Project requests undisclosed relationship. Iron rule 3 violation.
• Project's existing copy already promises returns. Phase 0 fail; they won't change for one launch.

A polite refusal template:

Thanks for thinking of us. We can't take this engagement because [specific reason — point at iron rule]. We're happy to revisit if [specific change]. No hard feelings.

Reputation tracking

Every engagement goes in learned/launches/{date}-{project}.md:

• Scope, fee structure, what we promised, what we delivered
• Outcomes (ours and theirs — did the launch work?)
• Did the project rug, fade, or grow?
• What we'd reuse, what we'd refuse next time

The track record IS the marketing. One year in, the file ledger does the sales work.

Verify

• A real RPC/SDK call was issued (mainnet, devnet, or local validator) and the response payload is captured in the transcript, not just paraphrased
• Every transaction was simulated (simulateTransaction or equivalent) before any signing/sending step; simulation logs are attached
• For any signed/sent transaction, the resulting signature is recorded and confirmed on chain (status returned by getSignatureStatuses or an explorer URL)
• Slippage, priority-fee, and compute-unit limits were set explicitly with concrete numeric values, not left to library defaults
• Account addresses, mints, and program IDs used in the run match the documented crypto-launch-ops addresses for the targeted cluster (no mainnet/devnet mix-up)
• Failure path was exercised at least once (insufficient balance, stale oracle, expired blockhash, etc.) and the agent's error handling produced a human-readable message

Anti-patterns to flag

• Volume creep: running 5 launches at once means none get the attention they paid for. Cap at 2 active engagements.
• Reputation lending: "just retweet this once for $X" is the path to becoming the platform that retweeted three rugs in a row. Refuse one-off boosts; only full engagements.
• Team-friend discount: doing a free launch for a friend's project with no qualification — same iron rules apply, or it doesn't happen.