cryptosnif
fly.trade (FLY)
Contrat documenté0x6c9b3a74ae4779da5ca999371ee8950e8db3407f
Non noté · 0% Couverture des preuves
Promesse documentée. Vérification indépendante en attente.
Les preuves disponibles sont insuffisantes pour attribuer une note globale. La description du mécanisme demande une vérification de son fonctionnement actuel.
Consulter les preuvesLa revue des sources explique les mécanismes documentés. Les contrôles indépendants du réseau restent à réaliser.
La promesse examinée
Ce dossier examine le sujet documenté fly.trade, ticker FLY, sous l'identité fly-2-wallet-sonic sur le réseau eip155:146. Le brief pilote se propose d'étudier la finalité et les mécanismes documentés de ce sujet en s'appuyant uniquement sur une documentation primaire épinglée et des logiciels. La promesse énoncée est documentaire : elle décrit ce qu'un ensemble d'enregistrements de registre dit de l'actif, et non ce que l'actif fait en fonctionnement réel. Deux termes importent d'emblée. Un registre est un catalogue maintenu d'informations et de logos de tokens ; ici, le README de Trust Wallet Assets décrit un registre d'informations et de logos de tokens à travers les blockchains, maintenu par la communauté, utilisé par le portefeuille et d'autres projets. L'inclusion signifie que le projet de portefeuille liste un token, et non que le projet qui le sous-tend est vérifié ou qu'un droit quelconque sur le token existe.
Faits documentaires
L'enregistrement épinglé de l'intégration Trust Wallet Sonic nomme fly.trade avec le symbole FLY, l'identifiant documentaire 0x6c9b3a74ae4779da5ca999371ee8950e8db3407f et 18 décimales. Cette entrée est étiquetée ERC20 et active, et sa description maintenue par la communauté indique que fly.trade est un agrégateur de liquidité multichain optimisant les swaps pour les traders, les protocoles et les agents, offrant une UX transparente. Les décimales décrivent la représentation des montants et n'établissent ni offre ni valeur actuelles. L'étiquette ERC20 renvoie à une entrée de catalogue documentaire ; la spécification générale ERC-20 est un document distinct et décrit une interface standard pour les tokens fongibles dans les contrats intelligents. Cette interface définit les lectures totalSupply et balanceOf, les transferts, les transferts par des tiers après autorisation, l'approbation et l'allocation restante, où une allocation est le montant qu'un dépensier nommé peut utiliser et une approbation répétée écrase ce montant. La norme indique aussi que les appelants doivent gérer un résultat de transfert faux et décrit les événements Transfer et Approval ; les métadonnées de nom, symbole et décimales sont optionnelles dans la norme. Séparément, le contexte épinglé du répertoire Sonic nomme Sonic, ce qui n'établit qu'un contexte de répertoire documentaire. Le README du registre indique que ses scripts et sa documentation utilisent la licence MIT, et que l'inclusion n'implique pas de partenariat direct avec les projets listés ; il exclut aussi explicitement les tokens flambant neufs des soumissions, de sorte qu'il ne peut fournir un inventaire exhaustif des lancements récents.
Ce qui reste inconnu
Le brief pilote est explicite : il s'agit d'un dossier de catalogue privé et la correspondance d'adresse documentaire n'établit ni comportement actuel du programme, ni contrôle déployé, ni sécurité. Aucun contrôle déployé, bénéficiaire effectif, offre, réserves, usage, sécurité, dossier complet d'incidents ou résultat d'investissement n'a été vérifié. Aucune observation de réseau en direct n'a été effectuée, et le résumé de l'interface ERC-20 note qu'une étiquette ERC20 de portefeuille n'établit ni conformité vérifiée indépendamment, ni implémentation réellement déployée, ni permissions de contrôleur, ni usage du token, ni offre, ni sécurité, et aucune transaction de token n'a été effectuée dans cette revue. Chacune des treize observations de critères admises dans ce lot documentaire porte le statut inconnu sans preuve admise, et les scores calculés restent non notés à 0 % de couverture dans les dimensions technologie, usage, économie, gouvernance, résilience et liquidité.
Conséquences
Les mécanismes documentaires seuls ne peuvent établir le comportement réel du réseau ni les résultats d'investissement. Une description de registre et une spécification d'interface décrivent ensemble une catégorie et un ensemble de lectures et écritures attendues, et non un déploiement fonctionnel, une niche économique ou un résultat de notation. Le registre Trust Wallet est maintenu par la communauté : quiconque peut soumettre des actifs, les informations supplémentaires sur les tokens sont optionnelles et indisponibles on-chain, et le statut actif est une étiquette de métadonnées sans validation en réseau réel. Cela fait d'une présence au catalogue un signal faible pour une vérification indépendante. La norme ERC-20 est de même un ensemble d'exigences d'interface décrivant ce qu'une implémentation conforme devrait faire, ce qui n'équivaut pas à observer un token déployé le faisant. Pour un lecteur, la conséquence pratique est que toute déclaration propre à un token, partenariat, subvention, économie, performance, offre, date ou adoption rattachée à l'entrée de registre doit être lue comme une allégation de registre non vérifiée, et non comme un fait confirmé indépendamment.
Verdict
La solidité opérationnelle reste non prouvée. L'actif reste non noté avec 0 % de couverture de notation parce qu'aucune observation de critère revue indépendamment n'a été admise dans ce lot documentaire. Les preuves essentielles manquantes incluent l'identité, l'offre et le contrôle. C'est une affirmation sur la couverture des preuves et rien de plus : elle ne rend pas le projet documenté frauduleux ou dangereux, et aucune telle affirmation n'est faite ici. Cela signifie que le dossier documentaire est trop mince pour étayer une note, et que les lacunes sont réelles plutôt que supposées.
Ce qui le changerait
Des contrôles d'identité reproduits, des observations de réseau indépendantes et datées et des preuves spécifiques aux critères feraient passer ce dossier au-delà du stade documentaire, suivis d'une calibration et d'une revue éditoriale. Questions de recherche concrètes : une partie indépendante peut-elle reproduire l'identifiant documentaire face à un contrat déployé sur eip155:146, et une réponse RPC datée confirme-t-elle le contrôle actuel ? Le bytecode déployé met-il en œuvre l'interface décrite dans la spécification ERC-20, y compris la gestion d'un résultat de transfert faux exigée par la norme ? Qui détient l'autorité de mise à niveau ou de frappe, et ce contrôle peut-il être observé plutôt qu'inféré ? Que montre une observation indépendante de l'usage réel, de l'activité de transfert et de la concentration des détenteurs ? Enfin, la description du registre est-elle exacte comme compte rendu de ce que le projet fait réellement et de ce que, le cas échéant, le token confère ? Tant que de telles preuves ne sont pas admises, le sujet reste non noté et le dossier documentaire reste le seul support des affirmations ci-dessus.
Chaque contrôle demande ses preuves.
| Contrôle | Poids | Résultat |
|---|---|---|
| Identité exacte de l’actifEssentiel | 3% | Vérification en attente |
| Usage observable | 15% | Vérification en attente |
| Rôle économique du token | 10% | Vérification en attente |
| Mécanismes d’offreEssentiel | 10% | Vérification en attente |
| Concentration des détenteurs | 8% | Vérification en attente |
| Captation de valeur | 7% | Vérification en attente |
| Pouvoirs de contrôleEssentiel | 10% | Vérification en attente |
| Vérification de la sécurité | 7% | Vérification en attente |
| Processus de décision | 8% | Vérification en attente |
| Responsabilités | 7% | Vérification en attente |
| Historique des incidents | 6% | Vérification en attente |
| Continuité du fonctionnement | 4% | Vérification en attente |
| Conditions d’exécution | 5% | Vérification en attente |
Contrôles propres à la famille: Utilisation observable, nécessité du token et dépendances.
Consulter les preuves
Les sources de cette analyse
Les titres et résumés des sources sont en anglais.
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.
Consulter la source primaire ↗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.
Consulter la source primaire ↗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.
Consulter la source primaire ↗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.
Consulter la source primaire ↗Seuls les résumés originaux sont distribués. Les données de marché brutes sous licence restent privées.