cryptosnif
fly.trade (FLY)
Contrato documentado0x6c9b3a74ae4779da5ca999371ee8950e8db3407f
Sin puntuación · 0% Cobertura de las pruebas
Promesa documentada. Verificación independiente pendiente.
Las pruebas disponibles son insuficientes para asignar una puntuación global. El mecanismo descrito requiere verificar su funcionamiento actual.
Consultar las pruebasLa revisión de las fuentes explica los mecanismos documentados. Los controles independientes de la red siguen pendientes.
La promesa examinada
Este dosier examina el sujeto documentado fly.trade, ticker FLY, bajo la identidad fly-2-wallet-sonic en la red eip155:146. El resumen piloto se propone estudiar el propósito y los mecanismos documentados de ese sujeto utilizando únicamente documentación primaria fijada y software. La promesa declarada es de naturaleza documental: describe lo que un conjunto de registros de registro dice sobre el activo, no lo que el activo hace en operación en vivo. Dos términos importan desde el inicio. Un registro es un catálogo mantenido de información de tokens y logotipos; aquí el README de Trust Wallet Assets describe un registro mantenido por la comunidad de información de tokens y logotipos en blockchains, utilizado por la billetera y otros proyectos. La inclusión establece que el proyecto de la billetera lista un token, no que el proyecto detrás de él esté verificado ni que exista algún derecho sobre el token.
Hechos documentales
El registro fijado de integración de Trust Wallet Sonic nombra fly.trade con símbolo FLY, identificador documental 0x6c9b3a74ae4779da5ca999371ee8950e8db3407f y 18 decimales. Esa entrada está etiquetada como ERC20 y activa, y su descripción mantenida por la comunidad declara que fly.trade es un agregador de liquidez multicadena que optimiza swaps para traders, protocolos y agentes ofreciendo una UX fluida. Los decimales describen la representación de cantidades y no establecen suministro ni valor actual alguno. La etiqueta ERC20 se refiere a una entrada de catálogo documental; la especificación general ERC-20 es un documento separado y describe una interfaz estándar para tokens fungibles en contratos inteligentes. Esa interfaz define lecturas de totalSupply y balanceOf, transferencias, transferencias por terceros tras autorización, aprobación y asignación restante, donde una asignación es la cantidad que un gastador nombrado puede usar y una aprobación repetida sobrescribe esa cantidad. El estándar tambié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. Por separado, el contexto fijado del directorio Sonic nombra Sonic, lo que establece únicamente contexto de directorio documental. El README del registro declara que sus scripts y documentación usan la licencia MIT, y que la inclusión no implica una asociación directa con los proyectos listados; también excluye explícitamente los tokens completamente nuevos de las presentaciones, por lo que no puede proporcionar un inventario exhaustivo de lanzamientos recientes.
Lo que permanece desconocido
El resumen piloto es explícito en que este es un dosier de catálogo privado y que la coincidencia documental de direcciones no establece comportamiento actual de programa, control desplegado ni seguridad. No se verificó control desplegado, propiedad beneficial, suministro, reservas, uso, seguridad, registro completo de incidentes ni resultado de inversión. No se realizó observación alguna en red en vivo, y el resumen de la interfaz ERC-20 señala que una etiqueta ERC20 de billetera no establece cumplimiento verificado de forma independiente, implementación desplegada real, permisos de controlador, uso del token, suministro ni seguridad, y no se realizó ninguna transacción de tokens en esta revisión. Cada una de las trece observaciones de criterios admitidas en este lote documental tiene estado desconocido sin evidencia admitida, y las puntuaciones calculadas permanecen sin calificación con 0% de cobertura en las dimensiones de tecnología, uso, economía, gobernanza, resiliencia y liquidez.
Consecuencias
Los mecanismos documentales por sí solos no pueden establecer comportamiento real de red ni resultados de inversión. Una descripción de registro y una especificación de interfaz juntas describen una categoría y un conjunto de lecturas y escrituras esperadas, no un despliegue funcional, un nicho económico ni un resultado de puntuación. El registro de Trust Wallet es mantenido por la comunidad: cualquiera puede presentar activos, la información adicional del token es opcional y no está disponible en la cadena, y el estado activo es una etiqueta de metadatos sin validación en red en vivo. Eso hace que una presencia en catálogo sea una señal débil para verificación independiente. El estándar ERC-20 es asimismo un conjunto de requisitos de interfaz que describen lo que una implementación conforme debería hacer, lo cual no es lo mismo que observar a un token desplegado haciéndolo. Para un lector, la consecuencia práctica es que cualquier declaración específica del token sobre propósito, asociación, subvención, economía, rendimiento, suministro, fecha o adopción adjunta a la entrada del registro debe leerse como una afirmación de registro no verificada, no como un hecho confirmado de forma independiente.
Veredicto
La fortaleza operativa permanece sin probar. El activo permanece sin calificación con 0% de cobertura de puntuación porque no se admitió ninguna observación de criterio revisada de forma independiente en este lote documental. La evidencia esencial faltante incluye identidad, suministro y control. Eso es una declaración sobre cobertura de evidencia y nada más: no hace que el proyecto documentado sea fraudulento o inseguro, y no se hace tal afirmación aquí. Significa que el registro documental es demasiado escaso para sustentar una puntuación, y las lagunas son reales en lugar de supuestas.
Qué lo cambiaría
Verificaciones de identidad reproducidas, observaciones de red independientes con fecha y evidencia específica de criterios llevarían este dosier más allá de la etapa documental, seguidas de calibración y revisión editorial. Preguntas de investigación concretas: ¿puede una parte independiente reproducir el identificador documental contra un contrato desplegado en eip155:146, y confirma una respuesta RPC con fecha el control actual? ¿El bytecode desplegado implementa la interfaz descrita en la especificación ERC-20, incluido el manejo del resultado de transferencia falso que el estándar requiere? ¿Quién posee la autoridad de actualización o acuñación, y puede ese control observarse en lugar de inferirse? ¿Qué muestra una observación independiente sobre el uso real, la actividad de transferencias y la concentración de tenedores? Finalmente, ¿es precisa la descripción del registro como relato de lo que el proyecto realmente hace y de lo que, si algo, transmite el token? Hasta que se admita tal evidencia, el sujeto permanece sin calificación y el registro documental sigue siendo el único sustento de las afirmaciones anteriores.
Cada control exige pruebas.
| Control | Peso | Resultado |
|---|---|---|
| Identidad exacta del activoEsencial | 3% | Verificación pendiente |
| Uso observable | 15% | Verificación pendiente |
| Papel económico del token | 10% | Verificación pendiente |
| Mecanismos de ofertaEsencial | 10% | Verificación pendiente |
| Concentración de titulares | 8% | Verificación pendiente |
| Captación de valor | 7% | Verificación pendiente |
| Poderes de controlEsencial | 10% | Verificación pendiente |
| Verificación de seguridad | 7% | Verificación pendiente |
| Proceso de decisión | 8% | Verificación pendiente |
| Responsabilidades | 7% | Verificación pendiente |
| Historial de incidentes | 6% | Verificación pendiente |
| Continuidad operativa | 4% | Verificación pendiente |
| Condiciones de ejecución | 5% | Verificación pendiente |
Controles específicos de la familia: Uso observable, necesidad de token y dependencias.
Consultar las pruebas
Fuentes de este análisis
Los títulos y resúmenes de las fuentes están en inglés.
Trust Wallet: captured Sonic record for fly.trade
The pinned Trust Wallet Sonic integration record names fly.trade with symbol FLY, documentary identifier 0x6c9b3a74ae4779da5ca999371ee8950e8db3407f and 18 decimal places. Decimal places describe amount representation and establish no current supply or value. The entry is labelled ERC20 and active. Its community-maintained description states: "fly.trade is a multichain liquidity aggregator optimizing swaps for traders, protocols, and agents delivering seamless UX.". Every project, partnership, grant, economic, performance, supply, date and adoption statement above is an attributed registry claim, without independent issuer or operational verification. The directory label does not establish a mainnet deployment, functioning implementation or present token rights. No deployed control, beneficial ownership, supply, reserves, use, safety, complete incident record or investment outcome was checked. The generic application family identifies only a documentary token subject; economic niche and scoring criteria remain unclassified and unknown. The general ERC-20 specification is separate from this token implementation.
Consultar la fuente primaria ↗Trust Wallet: pinned Sonic directory context
The pinned community-maintained Trust Wallet sonic directory context names Sonic. This establishes documentary directory context only. No performance, consensus, mainnet RPC response, current deployment, control or security claim is independently verified.
Consultar la fuente primaria ↗Trust Wallet Assets: README.md (bbe582d25a22)
The Trust Wallet Assets README describes a community-maintained registry of token information and logos across blockchains, used by the wallet and other projects. It says additional token information is optional and unavailable on-chain. Anyone can submit assets, and inclusion does not imply a direct partnership with the listed projects. It also explicitly excludes brand-new tokens from submissions, so this source cannot provide an exhaustive inventory of recent launches. The README states that its scripts and documentation use the MIT license. This source is the wallet project's own integration registry, maintained with community submissions. Its project descriptions are documentary claims from that registry, not independently verified issuer statements or operational observations. The active status is a metadata label, with no live-network validation. No deployment bytecode, controller, supply, reserve, use, concentration, liquidity, security audit, incident completeness or investment return has been established.
Consultar la fuente primaria ↗Ethereum ERC-20: pinned token interface specification
The pinned ERC-20 specification describes a standard interface for fungible tokens in smart contracts. It defines totalSupply and balanceOf reads, transfers, third-party transfers after authorization, approval and remaining allowance. An allowance is the amount a named spender may use; a repeated approval overwrites that amount. The specification says callers must handle a false transfer result and describes Transfer and Approval events. Name, symbol and decimal-place metadata are optional in the standard. These interface requirements describe what a conforming implementation should do. A wallet ERC20 label establishes no independently checked compliance, actual deployed implementation, controller permissions, token use, supply or security. No token transaction was performed in this review. Copyright and related rights are waived under CC0.
Consultar la fuente primaria ↗Solo se distribuyen resúmenes originales. Los datos de mercado brutos bajo licencia permanecen privados.