cryptosnif
fly.trade (FLY)
Documentary contract0x6c9b3a74ae4779da5ca999371ee8950e8db3407f
Unrated · 0% Evidence coverage
Operational strength remains unproven; unrated with 0% scoring coverage.
Documentary mechanisms alone cannot establish actual network behavior or investment outcomes.
Inspect the evidenceThe source review explains documented mechanisms. Independent network checks remain pending.
The examined promise
This dossier examines the documented subject fly.trade, ticker FLY, under the identity fly-2-wallet-sonic on network eip155:146. The pilot brief sets out to study the documented purpose and mechanisms of that subject using pinned primary documentation and software only. The stated promise is a documentary one: it describes what a set of registry records says about the asset, not what the asset does in live operation. Two terms matter from the outset. A registry is a maintained catalogue of token information and logos; here the Trust Wallet Assets README describes a community-maintained registry of token information and logos across blockchains, used by the wallet and other projects. Inclusion states that the wallet project lists a token, not that the project behind it is verified or that any token right exists.
Documentary facts
The pinned Trust Wallet Sonic integration record names fly.trade with symbol FLY, documentary identifier 0x6c9b3a74ae4779da5ca999371ee8950e8db3407f and 18 decimal places. That entry is labelled ERC20 and active, and its community-maintained description states that fly.trade is a multichain liquidity aggregator optimizing swaps for traders, protocols, and agents delivering seamless UX. Decimal places describe amount representation and establish no current supply or value. The ERC20 label refers to a documentary catalogue entry; the general ERC-20 specification is a separate document and describes a standard interface for fungible tokens in smart contracts. That interface defines totalSupply and balanceOf reads, transfers, third-party transfers after authorization, approval and remaining allowance, where an allowance is the amount a named spender may use and a repeated approval overwrites that amount. The standard also 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. Separately, the pinned Sonic directory context names Sonic, which establishes documentary directory context only. The registry README states that its scripts and documentation use the MIT license, and inclusion does not imply a direct partnership with the listed projects; it also explicitly excludes brand-new tokens from submissions, so it cannot provide an exhaustive inventory of recent launches.
What stays unknown
The pilot brief is explicit that this is a private catalogue dossier and that the documentary address matching establishes no current program behavior, deployed control or safety. No deployed control, beneficial ownership, supply, reserves, use, safety, complete incident record or investment outcome was checked. No live network observation was performed, and the ERC-20 interface summary notes that a wallet ERC20 label establishes no independently checked compliance, actual deployed implementation, controller permissions, token use, supply or security, and no token transaction was performed in this review. Each of the thirteen criterion observations admitted in this documentary lot carries unknown status with no admitted evidence, and the calculated scores remain unrated at 0% coverage across the technology, usage, economics, governance, resilience and liquidity dimensions.
Consequences
Documentary mechanisms alone cannot establish actual network behavior or investment outcomes. A registry description and an interface specification together describe a category and a set of expected reads and writes, not a functioning deployment, an economic niche or a scoring result. The Trust Wallet registry is community maintained: anyone can submit assets, additional token information is optional and unavailable on-chain, and the active status is a metadata label with no live-network validation. That makes a catalogue presence a weak signal for independent verification. The ERC-20 standard is likewise a set of interface requirements describing what a conforming implementation should do, which is not the same as observing a deployed token doing it. For a reader, the practical consequence is that any token-specific purpose, partnership, grant, economic, performance, supply, date or adoption statement attached to the registry entry should be read as an unverified registry claim, not as an independently confirmed fact.
Verdict
Operational strength remains unproven. The asset stays unrated with 0% scoring coverage because no independently reviewed criterion observation was admitted in this documentary lot. Missing essential evidence includes identity, supply and control. That is a statement about evidence coverage and nothing more: it does not make the documented project fraudulent or unsafe, and no such claim is made here. It means the documentary record is too thin to support a score, and the gaps are real rather than assumed.
What would change it
Reproduced identity checks, independent dated network observations and criterion-specific evidence would move this dossier past the documentary stage, followed by calibration and editorial review. Concrete research questions: can an independent party reproduce the documentary identifier against a deployed contract on eip155:146, and does a dated RPC response confirm current control? Does the deployed bytecode implement the interface described in the ERC-20 specification, including the false transfer result handling the standard requires? Who holds upgrade or mint authority, and can that control be observed rather than inferred? What does an independent observation show about actual usage, transfer activity and holder concentration? Finally, is the registry description accurate as an account of what the project actually does and what, if anything, the token conveys? Until such evidence is admitted, the subject remains unrated and the documentary record remains the only support for the statements above.
Each check earns its result.
| Check | Weight | Result |
|---|---|---|
| Exact asset identityEssential | 3% | Verification pending |
| Observable use | 15% | Verification pending |
| Economic role of the token | 10% | Verification pending |
| Supply mechanismsEssential | 10% | Verification pending |
| Ownership concentration | 8% | Verification pending |
| Value capture | 7% | Verification pending |
| Control powersEssential | 10% | Verification pending |
| Security verification | 7% | Verification pending |
| Decision process | 8% | Verification pending |
| Accountability | 7% | Verification pending |
| Incident history | 6% | Verification pending |
| Operational continuity | 4% | Verification pending |
| Execution conditions | 5% | Verification pending |
Family-specific checks: Observable usage, token necessity and dependencies.
Inspect the evidence
Sources behind this analysis
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.
Inspect the primary source ↗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.
Inspect the primary source ↗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.
Inspect the primary source ↗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.
Inspect the primary source ↗Only original summaries are distributed. Licensed raw market data stays private.