Shentu (CTK)

Promesse examinée

Ce dossier examine la finalité documentée et les mécanismes rattachés à Shentu (CTK) sur le réseau BNB Smart Chain, identifié par l'identifiant de chaîne eip155:56. La promesse examinée est étroite : identifier ce que la documentation primaire épinglée indique au sujet de cet actif, et séparer ce relevé documentaire de toute affirmation sur le comportement réel du jeton aujourd'hui.

Un relevé épinglé désigne une version spécifique d'un fichier, fixée à une adresse spécifique, de sorte que des modifications ultérieures ne peuvent pas changer silencieusement ce qui a été examiné. Le sujet documentaire est l'adresse de contrat 0xa8c2b8eec3d368c0253ad3dae65a5f2bbb89c929. Cette adresse identifie uniquement le sujet documenté ; le bytecode déployé, les contrôleurs actuels et le fonctionnement du réseau en direct restent non vérifiés.

Un protocole inter-chaînes, comme l'indique la description du registre, est un logiciel destiné à déplacer des données ou de la valeur entre blockchains. Une application décentralisée, ou dApp, est une application dont la logique s'exécute sur une blockchain plutôt que sur le serveur d'une seule entreprise. La notation de sécurité et les remboursements décentralisés sont les objectifs nommés dans la description citée, et ils sont examinés ici uniquement en tant qu'affirmations attribuées au registre.

Faits documentaires

Le relevé épinglé d'intégration Trust Wallet BNB Smart Chain nomme Shentu avec le symbole CTK, l'adresse documentaire 0xa8c2b8eec3d368c0253ad3dae65a5f2bbb89c929 et 6 décimales. Les décimales concernent la représentation des montants, de sorte qu'elles ne disent rien sur l'offre ou la valeur. Le relevé étiquette l'entrée BEP20 et active, et sa description maintenue par la communauté indique qu'il s'agit d'un protocole inter-chaînes avec notation de sécurité et remboursements décentralisés pour construire des dApps et des blockchains sécurisées. Chaque affirmation sur le projet, l'économie, les partenariats, la performance, l'offre, les dates et l'adoption figurant dans cette description citée est une affirmation attribuée au registre, et non une déclaration de l'émetteur établie indépendamment ni une observation opérationnelle.

Le contexte réseau environnant provient du même répertoire épinglé : le relevé Trust Wallet smartchain identifie le répertoire de registre communautaire pour BNB Smart Chain, qui fournit le contexte réseau documentaire pour les entrées de ce répertoire.

Le registre lui-même est un catalogue d'informations sur les jetons et de logos à travers les blockchains, maintenu par la communauté, utilisé par le portefeuille et d'autres projets. Les informations supplémentaires sur les jetons sont facultatives et indisponibles on-chain, quiconque peut soumettre des actifs, et l'inclusion n'implique pas un partenariat direct avec les projets listés. Le README exclut également les jetons tout nouveaux des soumissions, de sorte que cette source ne peut pas fournir un inventaire exhaustif des lancements récents. Le statut actif est une étiquette de métadonnées sans validation sur le réseau en direct.

L'étiquette BEP20 renvoie à une famille d'interfaces de jeton, et la spécification générale ERC-20 est distincte de cette implémentation de jeton. Cette spécification décrit une interface standard pour les jetons fongibles dans les contrats intelligents. Fongible signifie que chaque unité est interchangeable avec une autre. La norme définit les lectures totalSupply et balanceOf, les transferts directs, les transferts par des tiers après autorisation, l'approbation et l'allocation restante. Une allocation est le montant qu'un dépensier nommé peut utiliser, et une approbation répétée écrase ce montant. Les appelants doivent gérer un résultat de transfert faux, et la norme décrit les événements Transfer et Approval. Les métadonnées de nom, de symbole et de décimales sont facultatives dans la norme. Une étiquette ERC20 de portefeuille n'établit aucune conformité vérifiée indépendamment.

Inconnues

Chaque critère applicable reste non observé dans ce lot documentaire : l'identité, l'usage, le rôle du jeton, l'offre, la concentration, la capture de valeur, le contrôle, la sécurité, la gouvernance, la responsabilité, les incidents, la continuité et l'exécution portent tous un statut inconnu sans observation indépendante admise.

Le contrôle indépendant actuel, la propriété bénéficiaire, l'usage, l'adoption par les clients, l'offre, la concentration, la liquidité et l'historique complet des incidents restent non vérifiés. Aucun bytecode de déploiement n'a été vérifié, aucune permission de contrôleur n'a été inspectée, et aucune transaction de jeton n'a été effectuée. Aucune observation du réseau en direct n'a été réalisée. Aucune déclaration de l'émetteur n'a été confirmée indépendamment, et aucune affirmation actuelle sur le marché, l'offre, la propriété, la performance ou l'adoption ne peut être faite à partir de ces sources.

Des questions de recherche concrètes découlent de ces lacunes. Qui peut actuellement modifier ou suspendre le contrat documenté, et sous quelle autorité ? Le code déployé sur eip155:56 correspond-il à l'interface que décrit la norme ERC-20 ? Quelles observations datées et reproductibles montrent les transferts, les détenteurs et l'usage réels ? Quels relevés indépendants existent pour les incidents, et quelle est la complétude de cet historique ?

Conséquences

Les mécanismes documentaires seuls ne peuvent pas établir le comportement réel du réseau ni les résultats d'investissement. Une description de registre décrit une intention ; elle ne prouve pas qu'une composante de cette intention fonctionne, que les remboursements nommés se produisent, ou que la notation de sécurité indiquée existe en pratique. Un examen documentaire n'est pas une vérification opérationnelle indépendante, et une adresse correspondante n'établit aucun comportement actuel du programme, aucun contrôle déployé ni aucune sécurité.

Les limites du registre importent pour l'interprétation. Parce que les soumissions sont maintenues par la communauté et que l'inclusion n'implique aucun partenariat, une entrée est un relevé de catalogue plutôt qu'une approbation par le projet de portefeuille. Parce que les jetons tout nouveaux sont exclus, l'absence d'un actif dans cette source ne prouve rien sur son existence, et la présence de cette entrée ne prouve rien sur son fonctionnement actuel. Deux conséquences pratiques en découlent. Premièrement, un lecteur ne peut pas transformer une affirmation documentaire en fait opérationnel sans observation séparée. Deuxièmement, un lecteur ne peut pas traiter une preuve manquante comme preuve d'une faute : une preuve absente est une lacune, non une conclusion, et elle ne rend pas à elle seule un projet frauduleux ou dangereux.

Verdict

La solidité opérationnelle reste non prouvée, et le statut calculé est non noté avec 0 % de couverture de notation. Aucune dimension ne porte de score admis, et les critères essentiels manquants sont l'identité, l'offre et le contrôle. Ce statut non noté est une déclaration sur la couverture des preuves et la méthodologie, non un jugement sur les personnes derrière le projet, et ce n'est pas un aveu public de quelque partie nommée dans le relevé. Il n'y a ici aucun objectif de prix, aucune prévision de rendement ni recommandation.

Ce qui est établi est un ensemble de faits documentaires épinglés : un sujet de jeton nommé, une adresse documentaire, une convention de décimales, une étiquette BEP20, une étiquette de métadonnées active et une description attribuée d'un travail de sécurité inter-chaînes prévu. Ce qui n'est pas établi est de savoir si tout cela fonctionne comme décrit aujourd'hui.

Ce qui le changerait

Un score exige des preuves, et le chemin de non noté à noté est procédural plutôt que rhétorique. Des vérifications d'identité reproduites, des observations indépendantes datées du réseau et des preuves spécifiques aux critères viendraient en premier, suivies d'une calibration et d'un examen éditorial. Une vérification d'identité reproduite confirmerait à quel contrat l'adresse correspond sur le réseau en direct à un moment déclaré. Des observations indépendantes datées du réseau enregistreraient les transferts, les détenteurs ou le comportement du programme produits par des parties autres que le registre et le projet.

Des preuves spécifiques aux critères traiteraient les inconnues une par une plutôt qu'en agrégé : relevés de contrôle et de permission, données sur l'offre et la concentration, documentation des incidents avec contrôles de complétude, et relevés de gouvernance ou de responsabilité là où ils existent. Toute observation admise ferait ensuite face à une calibration et à un examen éditorial avant qu'un score puisse être attribué. Jusqu'à ce que cette séquence soit complétée et documentée, le verdict reste non noté, et les affirmations documentaires restent des affirmations attribuées au registre plutôt qu'un fonctionnement vérifié.