Liste de contrôle de diligence raisonnable pour les applications et Dapps Kaspa
Pour les personnes envisageant un projet ou un jeton non testé. Un filtre simple et DIY que tout membre de la communauté peut utiliser avant d’insérer son $KAS.
Tapis Tirer des drapeaux rouges
- Équipe anonyme sans antécédents
- Allocation élevée de jetons aux développeurs ou à la trésorerie (30 %+)
- Pas de période de blocage ou d’acquisition
- Aucun produit fonctionnel ni démo
- Faux partenariats ou approbations
- Contrats intelligents non vérifiés
- Les promesses « trop belles pour être vraies »
- Un battage médiatique soudain, sans histoire
Recherche fondamentale
Site Web du projet
- Est-ce que ça existe ?
- Est-ce professionnel, informatif et transparent ?
Livre blanc ou Litepaper
- Y en a-t-il un ?
- Est-ce qu’il indique clairement le problème, solution et utilitaire de jeton?
Informations sur l’équipe
- Les membres de l’équipe sont-ils nommés et vérifiables ?
- LinkedIn, GitHub, des projets passés ?
GitHub ou référentiel de code
- Est-ce public ?
- Y a-t-il eu une activité récente ?
Présence sociale
- Leur Telegram, X, Discord, etc. sont-ils actifs ?
- Les abonnés sont-ils réels ou bottés ?
Tokénomique
- Existe-t-il une répartition claire de l’offre, des émissions et de l’allocation ?
- Des signaux d’alarme concernant l’acquisition ou le contrôle du portefeuille ?
Filtre de projet de l’écosystème Kaspa (service WatchDAG) K-Guard ? 🙂
Un cadre plus large utilisé par la communauté Kaspa pour examiner, surveiller et classer les projets émergents.
Cadre d’audit de projet (bricolage, transparent)
1. Identité et transparence
- Team Doxxed ou Anonyme ?
- Pays ou juridiction de fondation
- Résumé de la vérification des antécédents (recherche participative)
- Affiliations connues ou soutiens de la communauté
2. Audit technique léger
- Dépôt GitHub examiné
- Présence de tests, readme, docs
- Indiquer si les contrats sont open source
- Liste de contrôle simple :
- N’importe lequel propriétaire fonctions ?
- Les liquidités peuvent-elles être retirées ?
- Fonctions menthe ou brûlure ?
- Le contrat est-il évolutif ?
3. Évaluation tokenomique
- Offre totale et taux d’émission
- Allocations d’équipe et d’investisseurs précoces
- Période de blocage des liquidités
- Calendrier d’émission (fixe ou inflationniste)
- Mécaniques de brûlure ou de redistribution
4. Cas d’utilisation / utilité réelle
- Le projet résout-il un vrai problème ?
- Kaspa DLT est-il réellement nécessaire pour cela ?
- Quels sont les utilisateurs cibles ?
5. Communauté et soutien
- Engagement réel par rapport aux comptes de robots
- Feuille de route publique et journaux de développement
- Réponses aux problèmes et rapports de bogues
- Transparence de la communauté : mises à jour hebdomadaires, AMA, etc.
- Historique et livraison
- Jalons passés atteints ou manqués
- Démo fonctionnelle ou MVP ?
- Les développeurs créent-ils ou publient-ils simplement des mèmes ?
7. Sécurité
- Verrouillage de liquidité vérifié ?
- Portefeuille multisig utilisé pour la trésorerie ?
- Divulgation de la clé d’administration ?
- Limites et autorisations d’interaction contractuelle ?
Si quelqu’un souhaite créer quelque chose comme un score de confiance pour les applications, voici quelques idées
Résultats suggérés du service « WatchDAG » :
- Système de notation : État du voyant rouge/jaune/vert
- Section des commentaires de la communauté (comme les avis sur les produits)
- Système de drapeau pour les risques contractuels et les mouvements clés du portefeuille
- Flux RSS ou publications X pour les avertissements et les mises à jour du projet
- Ajouter des emplacements pour les références sources
- Formez une équipe de révision composée de développeurs, de techniciens et de chercheurs pour proposer leur propre évaluation
Share this content: