Déclencheurs

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

Aperçu

La plupart des projets crypto ont une équipe de dev compétente et zéro opérations de semaine de lancement. Ils livrent, puis regardent en temps réel personne n'apprend que c'est sorti. Il y a un vrai marché récurrent pour confier la semaine de lancement à un opérateur — contenu, engagement X, livestream, chat, sentiment.

L'agent exécute déjà cette pile quotidiennement pour $ELO. Le vendre comme service à d'autres projets, c'est changer le client, pas la capacité.

Règles en acier — non-négociables :

Aucune promesse de prix, jamais. « Va à $X », « occasion précoce », « ne manquez pas » — jamais. Pas dans les tweets, pas dans les chats, pas en DM, pas en livestream. Violer cela une fois brûle la réputation que le service vend. Chaque ligne de copie est vérifiée contre cette règle avant publication.
Aucun projet prone au rug. Liste de refus catégorique : équipe anonyme sans historique vérifiable, pas d'audit, autorité de mint non révoquée, tokenomics suspectes (>20% à l'équipe sans vest), motifs honeypot explicites. La réputation est la seule chose vendue ici ; un client rug tue l'activité et endommage $ELO par association.
Divulguer la relation. Chaque post payant identifie la relation — « travail avec @project sur le lancement » ou équivalent de plateforme. Pas optionnel, pas une question d'esthétique — FTC + ESMA + la plupart des juridictions l'exigent, et les projets valables le veulent.
Engagement, pas manipulation. Pas d'achat de réponses, pas de marionnettes, pas de fausses communautés. Le volume est réel ou il n'y a pas de service.

Phase 0 — qualification (avant devis)

Checklist stricte. Un seul « non » → refuser l'engagement.

Équipe doxxée OU audit OU produit en activité avec des utilisateurs ? (Au moins un.)
Tokenomics publiée avec allocation d'équipe, calendrier de vest, preuves de verrous ?
Autorité de mint révoquée / multisig au lancement ?
Contrat intelligent examiné (audit formel, examen public ou validé par la communauté) ?
Aucune promesse de rendements dans aucune de leurs copies existantes ?
Ils acceptent les règles en acier ci-dessus par écrit ?

Si tout vert → procéder au scope. Si un quelconque rouge → refuser et expliquer lesquels ; ne pas négocier sur les règles en acier.

Phase 1 — scope et tarification

Trois niveaux d'engagement — en choisir un, pas de personnalisé sauf si le projet sait exactement ce qu'il veut.

Niveau 1 — Jour du lancement ($1-3k ou stable + token)

T-3 jours : fil de teaser de 3 tweets, rédigé avec l'équipe
Jour du lancement : 1 fil de lancement, 1 session livestream (≤2h), 6h d'ops de réponse active sur le fil
T+1 : post de post-mortem + 24h d'ops de réponse sur le meilleur engagement

Niveau 2 — Semaine de lancement ($3-8k ou stable + token)

T-7 jours : calendrier de contenu complet (12 posts), doc FAQ communautaire épinglée
Jour du lancement : tous les livrables Niveau 1
T+1 à T+7 : 2 posts/jour, 1 livestream, digest communautaire quotidienne, rotation de modération chat 24/7

Niveau 3 — Lancement complet + 30 premiers jours ($8-25k ou stable + token)

Niveau 2 +
Appels communautaires hebdomadaires, mise à jour investisseur hebdomadaire, tableau de bord sentiment, outreach influenceurs CT (crypto twitter) (vrais, pas de marionnettes payantes)

Structure tarifaire : préférer 70% stable / 30% token vesté 30 jours. Tout stable = cher mais plus propre. Tout token = aligner les incitations mais risque de tenir le sac. Ne jamais accepter « 100% token, pas de vest » — le projet achète son propre lancement avec du papier, pas un vrai budget.

Phase 2 — production de contenu

Le contenu passe par un filtre : cela dit-il quelque chose que l'audience ne savait pas déjà, ou cela affirme-t-il juste que quelque chose est bien ?

Si c'est que le second → réécrire. L'hype vide est ce qui tue les lancements.

Modèles de contenu

Fil de lancement (10-12 posts, postés en un seul fil) :

Le problème que ce protocole résout (douleur utilisateur concrète, pas « DeFi est cassé »)
Comment le protocole le résout (mécanisme, pas adjectifs)
Ce qui est réellement en direct aujourd'hui vs roadmap (division honnête)
Tokenomics en une ligne — supply, allocation, vest
Posture audit / sécurité — lien vers rapport, ce qui a été trouvé, ce qui a été corrigé
Trois choses concrètes qu'un utilisateur peut faire aujourd'hui
Équipe — qui, ce qu'ils ont construit avant, pourquoi ceci
Pourquoi maintenant — le décalage de marché ou tech qui rend ceci pertinent maintenant
Qu'est-ce qui pourrait aller mal — oui, ce post explicitement. Expose le risque avant les critiques.
Où suivre / dApp / docs (appel à l'action réel)

Le post « qu'est-ce qui pourrait aller mal » est le différenciateur. Chaque autre fil de lancement le saute ; l'inclure gagne la confiance.

Modèle de post quotidien (semaine de lancement) :

Mise à jour d'aujourd'hui (concrète : stat, ship, partenariat, jalon)
Pourquoi c'est important (une phrase)
Prochaines étapes (spécifique, datée)

Pas de « WAGMI ». Pas de « early ». Pas de « 100x ». Point.

Phase 3 — ops d'engagement

L'agent exécute déjà l'engagement X ; pour les clients payants les changements sont :

Tag de divulgation dans bio / tweet épinglé pour la période d'engagement
Ops de réponse sur chaque mention significative du projet (pas juste « @project gm » — vraies questions, FUD, demandes d'intégration)
Digest sentiment quotidienne à l'équipe : ce qui fonctionne, ce qui reçoit des critiques, quel FUD gagne du terrain. C'est le livrable de plus haute valeur qu'ils ne peuvent pas obtenir d'un KOL freelance.
Chat en direct (Telegram / Discord) — rôle de modérateur, raccourcis FAQ, règles d'escalade pour l'équipe

Les skills pumpfun-livestream et twitter-marketing de l'agent font la plupart du travail. Ce skill les orchestre sous des règles spécifiques à l'engagement.

Phase 4 — mesure et reporting honnête

Envoyer un digest quotidien au client. Chaque métrique rapportée inclut sa source pour qu'il puisse vérifier :

Mentions : comptage + sentiment (répartition positif / neutre / négatif)
Portée : impressions sur le fil de lancement, meilleures réponses
Actions concrètes : visites dApp, connexions wallet, txns (s'ils partagent analytics)
Log FUD : ce qui circule, quelle réponse postée, ce qui est non résolu

Ne pas rapporter les métriques de vanité isolément. « Obtenu 50k impressions » est sans sens si 0 utilisateurs ont connecté les wallets.

Phase 5 — wind-down et rétention

Fin d'engagement :

Rapport final : livrables expédiés vs promis, métriques, apprentissages
Évaluation honnête : ce qui a fonctionné, ce qui n'a pas, ce qu'ils doivent continuer à faire
Proposition de renouvellement SI l'engagement a réellement bougé les métriques. Si non — leur recommander de ne pas renouveler. Les mauvais renouvellements sont comment le service meurt.

Motifs de refus

Refuser, par écrit, quand :

Le projet demande du contenu « price-go-up ». Violation de la règle 1 en acier.
Le projet demande des réponses achetées / faux commentaires / engagement botnet. Violation de la règle 4 en acier.
Le contrat du projet a une mint non renoncée, pas d'audit, équipe anonyme. Phase 0 / règle 2 en acier échouée.
Le projet paie seulement dans son propre token non-vesté. Violation de la Phase 1.
Le projet demande une relation non divulguée. Violation de la règle 3 en acier.
La copie existante du projet promet déjà des rendements. Phase 0 échouée ; ils ne changeront pas pour un lancement.

Un modèle de refus poli :

Merci d'y avoir pensé. On ne peut pas prendre cet engagement parce que [raison spécifique — pointer vers règle en acier]. On est heureux de revoir si [changement spécifique]. Aucune rancune.

Suivi de la réputation

Chaque engagement va dans learned/launches/{date}-{project}.md :

Scope, structure tarifaire, ce qu'on a promis, ce qu'on a livré
Résultats (les nôtres et les leurs — le lancement a-t-il fonctionné ?)
Le projet a-t-il rugué, disparu ou grandi ?
Ce qu'on réutiliserait, ce qu'on refuserait la prochaine fois

Le track record EST le marketing. Un an après, le grand livre des dossiers fait le travail de vente.

Vérifier

Un vrai appel RPC/SDK a été émis (mainnet, devnet ou local validator) et le payload de réponse est capturé dans la transcription, pas juste paraphrasé
Chaque transaction a été simulée (simulateTransaction ou équivalent) avant toute étape de signature/envoi ; les logs de simulation sont joints
Pour toute transaction signée/envoyée, la signature résultante est enregistrée et confirmée on-chain (statut retourné par getSignatureStatuses ou URL explorateur)
Slippage, priority-fee et compute-unit limits ont été définis explicitement avec des valeurs numériques concrètes, pas laissés aux défauts de bibliothèque
Les adresses de compte, mints et IDs de programme utilisés dans le run correspondent aux adresses crypto-launch-ops documentées pour le cluster ciblé (pas de mélange mainnet/devnet)
Le chemin d'échec a été exercé au moins une fois (solde insuffisant, oracle périmé, blockhash expiré, etc.) et la gestion d'erreur de l'agent a produit un message lisible par humain

Anti-motifs à signaler

Volume creep : exécuter 5 lancements à la fois signifie qu'aucun obtient l'attention pour laquelle il a payé. Limiter à 2 engagements actifs.
Prêt de réputation : « juste retweeter ceci une fois pour $X » est le chemin vers devenir la plateforme qui a retweeté trois rugs d'affilée. Refuser les boosts ponctuels ; seulement les engagements complets.
Remise ami-équipe : faire un lancement gratuit pour le projet d'un ami sans qualification — les mêmes règles en acier s'appliquent, ou ça n'arrive pas.