Broccoli (FirstBroccoli) (BROCCOLI)

La promesse examinée

Ce dossier examine un seul sujet documenté : Broccoli (FirstBroccoli), symbole BROCCOLI, sur BNB Smart Chain, identifié par le réseau eip155:56 et l'adresse de contrat documentaire 0x12b4356c65340fb02cdff01293f95febb1512f3b.

L'objectif déclaré propre au jeton provient d'une entrée épinglée du registre Trust Wallet. Cette entrée est un enregistrement maintenu par la communauté, et sa description attribue l'origine du jeton à une publication dans laquelle Changpeng Zhao a révélé le nom de son chien, ce qui, selon l'enregistrement, a déclenché une vague de memecoins nommés d'après le canidé.

La promesse que ce dossier teste est étroite. Elle demande si l'objectif et les mécanismes documentés de ce jeton peuvent être établis à partir de documentation primaire épinglée et de résumés logiciels, et elle trace la limite de ce que cette documentation peut réellement étayer.

Faits établis

Une définition d'abord. BEP20 est une norme d'interface de jeton pour BNB Smart Chain ; c'est la famille locale d'une interface qui spécifie comment les jetons fongibles exposent les lectures, les transferts et les événements d'autorisation.

L'enregistrement épinglé d'intégration Trust Wallet BNB Smart Chain nomme Broccoli avec le symbole Broccoli, l'adresse documentaire 0x12b4356c65340fb02cdff01293f95febb1512f3b et 18 décimales. Les décimales concernent uniquement la représentation des montants et ne mesurent ni l'offre ni la valeur. L'enregistrement étiquette l'entrée BEP20 et active. Un libellé actif est un statut de métadonnées, pas un résultat de réseau en direct.

Le README de Trust Wallet Assets décrit un registre maintenu par la communauté d'informations sur les jetons et de logos à travers les blockchains, utilisé par le portefeuille et d'autres projets. Il indique que des informations supplémentaires sur les jetons sont facultatives et indisponibles on-chain, que quiconque peut soumettre des actifs, et que l'inclusion n'implique pas un partenariat direct avec les projets listés. Il exclut également les jetons tout nouveaux des soumissions, de sorte que la source ne peut pas fournir un inventaire exhaustif des lancements récents. Ses scripts et sa documentation utilisent la licence MIT.

La spécification ERC-20 épinglée, une norme distincte de cette implémentation de jeton, définit une interface standard pour les jetons fongibles dans les contrats intelligents. Elle décrit les lectures totalSupply et balanceOf, les transferts, 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. La spécification indique que les appelants doivent gérer un résultat de transfert faux et décrit les événements Transfer et Approval. Le nom, le symbole et les métadonnées de décimales sont facultatifs dans la norme.

Toutes les déclarations de projet, économiques, de partenariat, de performance, d'offre, de date et d'adoption dans la description du registre sont des affirmations attribuées au registre, et non des déclarations d'émetteur ou des observations opérationnelles établies de manière indépendante.

Ce qui reste inconnu

Aucune observation de réseau en direct n'a été effectuée pour ce dossier. Le lot de preuves n'a admis aucune observation de critère examinée de manière indépendante, de sorte que l'identité, l'usage, le rôle du jeton, l'offre, la concentration, la captation de valeur, le contrôle, la sécurité, la gouvernance, la responsabilité, les incidents, la continuité et l'exécution restent tous inconnus.

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. Le bytecode déployé, les contrôleurs actuels et l'exploitation du réseau restent non vérifiés. La famille d'applications générique n'identifie qu'un sujet de jeton documentaire ; sa niche économique et ses critères de notation restent non classés.

L'absence de preuves n'établit pas une fraude ni une absence de sécurité. Elle établit que les affirmations documentées n'ont pas été vérifiées de manière indépendante. Un examen de documentation n'est pas une vérification opérationnelle indépendante.

Conséquences

La correspondance de l'adresse documentaire n'établit aucun comportement actuel du programme, aucun contrôle déployé ni aucune sécurité. Un libellé ERC20 de portefeuille n'établit aucune conformité vérifiée de manière indépendante, aucune implémentation réellement déployée, aucune permission de contrôleur, aucun usage du jeton ni aucune sécurité. La spécification ERC-20 générale est distincte de cette implémentation de jeton, de sorte que ses exigences d'interface décrivent ce qu'une implémentation conforme devrait faire, et non ce que ce jeton fait.

Parce que le registre se décrit comme maintenu par la communauté et facultatif, l'inclusion est une affirmation documentaire de ce registre, et non une déclaration d'émetteur. Parce que les décimales concernent la représentation des montants, elles ne peuvent pas être lues comme une offre ou une valeur. Parce que des critères distincts restent non observés, le score calculé reste non noté avec une couverture de notation de 0 %, et aucune admission publique n'accompagne ce statut.

Cette interprétation est éditoriale. Elle découle des limites documentaires citées, et non d'une quelconque observation indépendante du jeton en fonctionnement.

Verdict

La solidité opérationnelle reste non prouvée. Cet actif est non noté avec une couverture de notation de 0 %, l'identité, l'offre et le contrôle figurant parmi les éléments essentiels manquants. Le mécanisme documenté nécessite une vérification indépendante avant qu'un score puisse être attribué.

Ce verdict reflète l'état des preuves fournies. Il ne constitue pas un jugement sur l'intention du projet et n'émet aucune affirmation sur le prix, le rendement ou la sécurité.

Éléments qui le modifieraient

Des questions de recherche concrètes feraient évoluer ce dossier vers un verdict calibré. L'adresse de contrat documentaire 0x12b4356c65340fb02cdff01293f95febb1512f3b peut-elle être reproduite par rapport à un bytecode déployé récupéré indépendamment, et ce bytecode expose-t-il les fonctions et événements d'interface ERC-20 décrits dans la norme ? Quelle adresse contrôle le contrat actuel, et par quel modèle de permission ? Quelles observations datées indépendantes montrent l'usage du jeton, la concentration des détenteurs et le comportement des transferts ?

Un historique documenté des incidents, des preuves propres à chaque critère pour l'identité, l'offre, le contrôle et les critères restants inconnus, ainsi qu'une vérification distincte de l'implémentation éventuelle des métadonnées facultatives de la norme par le jeton seraient chacun pertinents. Si ces éléments arrivent, le matériel serait calibré et examiné sur le plan éditorial avant tout changement de score. D'ici là, les inconnues restent inchangées.