Broccoli (FirstBroccoli) (BROCCOLI)

La promesa examinada

Este dossier examina un único sujeto documentado: Broccoli (FirstBroccoli), símbolo BROCCOLI, en BNB Smart Chain, identificado por la red eip155:56 y la dirección de contrato documental 0x12b4356c65340fb02cdff01293f95febb1512f3b.

El propósito específico del token declarado proviene de una entrada fijada del registro de Trust Wallet. Esa entrada es un registro mantenido por la comunidad, y su descripción atribuye el origen del token a una publicación en la que Changpeng Zhao reveló el nombre de su perro, lo que, según el registro, desencadenó una ola de memecoins nombradas en honor al canino.

La promesa que este dossier pone a prueba es limitada. Pregunta si el propósito y los mecanismos documentados de este token pueden establecerse a partir de documentación primaria fijada y resúmenes de software, y delimita qué puede sustentar realmente esa documentación.

Hechos establecidos

Primero, una definición. BEP20 es un estándar de interfaz de token para BNB Smart Chain; es la familia local de una interfaz que especifica cómo los tokens fungibles exponen lecturas, transferencias y eventos de autorización.

El registro de integración de Trust Wallet para BNB Smart Chain fijado nombra a Broccoli con el símbolo Broccoli, la dirección documental 0x12b4356c65340fb02cdff01293f95febb1512f3b y 18 decimales. Los decimales conciernen únicamente la representación de cantidades y no miden la oferta ni el valor. El registro etiqueta la entrada como BEP20 y activa. La etiqueta activa es un estado de metadatos, no un resultado de red en vivo.

El README de Trust Wallet Assets describe un registro mantenido por la comunidad de información de tokens y logotipos en distintas blockchains, utilizado por la billetera y otros proyectos. Afirma que la información adicional del token es opcional y no está disponible en la cadena, que cualquiera puede enviar activos y que la inclusión no implica una asociación directa con los proyectos listados. También excluye los tokens recién creados de los envíos, por lo que la fuente no puede proporcionar un inventario exhaustivo de lanzamientos recientes. Sus scripts y documentación usan la licencia MIT.

La especificación ERC-20 fijada, un estándar distinto de esta implementación de token, define una interfaz estándar para tokens fungibles en contratos inteligentes. Describe las lecturas totalSupply y balanceOf, las transferencias, las transferencias de terceros tras la autorización, la aprobación y la asignación restante. Una asignación es la cantidad que un gastador designado puede usar, y una aprobación repetida sobrescribe esa cantidad. La especificación indica que quienes llaman deben manejar un resultado de transferencia falso y describe los eventos Transfer y Approval. Los metadatos de nombre, símbolo y decimales son opcionales en el estándar.

Todas las declaraciones sobre el proyecto, la economía, las asociaciones, el rendimiento, la oferta, las fechas y la adopción dentro de la descripción del registro son afirmaciones atribuidas al registro, no declaraciones del emisor ni observaciones operativas establecidas de forma independiente.

Lo que permanece desconocido

No se realizó ninguna observación de red en vivo para este dossier. El lote de evidencia no admitió ninguna observación de criterio revisada de forma independiente, por lo que la identidad, el uso, el rol del token, la oferta, la concentración, la captura de valor, el control, la seguridad, la gobernanza, la rendición de cuentas, los incidentes, la continuidad y la ejecución permanecen desconocidos.

El control independiente actual, la propiedad beneficiaria, el uso, la adopción por parte de clientes, la oferta, la concentración, la liquidez y el historial completo de incidentes permanecen sin verificar. El bytecode desplegado, los controladores actuales y el funcionamiento de la red permanecen sin verificar. La familia de aplicación genérica identifica únicamente un sujeto documental de token; su nicho económico y sus criterios de puntuación permanecen sin clasificar.

La falta de evidencia no establece fraude ni inseguridad. Establece que las afirmaciones documentadas no han sido comprobadas de forma independiente. Una revisión de documentación no es una verificación operativa independiente.

Consecuencias

La coincidencia de la dirección documental no establece ningún comportamiento actual del programa, control desplegado ni seguridad. Una etiqueta ERC20 de billetera no establece ningún cumplimiento comprobado de forma independiente, implementación desplegada real, permisos de controlador, uso del token, oferta ni seguridad. La especificación general ERC-20 es distinta de esta implementación de token, por lo que sus requisitos de interfaz describen lo que debería hacer una implementación conforme, y no lo que hace este token.

Debido a que el registro se describe a sí mismo como mantenido por la comunidad y opcional, la inclusión es una afirmación documental de ese registro, no una declaración del emisor. Debido a que los decimales conciernen la representación de cantidades, no pueden leerse como oferta ni valor. Debido a que los criterios separados permanecen sin observar, la puntuación calculada permanece sin calificación con un 0% de cobertura de puntuación, y ninguna admisión pública acompaña ese estado.

Esta interpretación es editorial. Se deriva de los límites documentales citados, no de ninguna observación independiente del token en funcionamiento.

Veredicto

La fortaleza operativa permanece no demostrada. Este activo está sin calificación con un 0% de cobertura de puntuación, con la identidad, la oferta y el control entre los elementos esenciales faltantes. El mecanismo documentado requiere verificación independiente antes de que pueda asignarse una puntuación.

Este veredicto refleja el estado de la evidencia suministrada. No es un juicio sobre la intención del proyecto y no hace ninguna afirmación sobre precio, rendimiento ni seguridad.

Evidencia que lo cambiaría

Preguntas de investigación concretas acercarían este dossier hacia un veredicto calibrado. ¿Puede reproducirse la dirección de contrato documental 0x12b4356c65340fb02cdff01293f95febb1512f3b contra bytecode desplegado recuperado de forma independiente, y ese bytecode expone las funciones y eventos de la interfaz ERC-20 descritos en el estándar? ¿Qué dirección controla el contrato actual, y mediante qué modelo de permisos? ¿Qué observaciones independientes con fecha muestran el uso del token, la concentración de tenedores y el comportamiento de transferencia?

Un historial de incidentes documentado, evidencia específica por criterio para identidad, oferta, control y los criterios desconocidos restantes, y una comprobación separada de si el token implementa los metadatos opcionales del estándar serían relevantes en cada caso. Si llegan, el material se calibraría y se revisaría editorialmente antes de que cambie cualquier puntuación. Hasta entonces, los desconocidos permanecen sin alteración.