1. Identify the asset before analyzing it
ZECOIN prioritizes a verifiable technical identity: chain, token or mint address and available provenance. A name or ticker is not enough.
ZECOIN METHODOLOGY
Trust is built by showing how we know.
ZECOIN makes provenance, limits and inconsistencies visible instead of hiding uncertainty behind a single score.
How ZECOIN handles data and limitations.
- Principle
- ZECOIN separates verifiable facts, timestamped observations, and interpretations.
- Sources
- Provenance and a timestamp are shown when they are available and verifiable.
- Missing data
- A missing, stale, or unreachable source remains marked unavailable: no value is invented.
- Limits
- Diagnostics are informational and non-advisory, with no guarantee of safety or future performance.
OBSERVED / INFERRED / UNKNOWN / INSUFFICIENT
- OBSERVED
- Directly returned by the stated source for the exact chain and asset identity.
- INFERRED
- Derived from observed inputs; the derivation must be named and cannot be presented as a direct fact.
- UNKNOWN
- The source did not establish the fact, the capability is unavailable, or the evidence boundary was not met.
- INSUFFICIENT
- Some data exists, but it does not support the public conclusion or indexability threshold.
Example: a revoked Solana mint authority returned by Solana RPC is OBSERVED. “The token is safe” is not a supported inference.
Provenance: every indexed fact must carry a source valid for its fact family and an HTTPS verification location.
Freshness: observedAt describes when the fact was collected; it is not replaced by request time.
Contradictions: conflicting exact-asset sources prevent a confident conclusion and remain UNKNOWN or INSUFFICIENT until resolved.
Limits: no score, page or source guarantees safety, profit, identity, ownership, or future behavior.
2. Separate observation from intelligence
Prices, volumes, liquidity and on-chain data may be observations. A score or conclusion appears only when it is actually produced by a validated method.
3. Measure quality before interpreting
Incomplete or inconsistent data must reduce confidence and trigger an explicit verification or insufficient-information state.
4. Do not turn a technical proxy into human certainty
A token account is not automatically one economic holder, and a technical authority does not prove civil identity.
5. Keep Radar independent from Creator Lab
Creators may pay for tools, never to improve a diagnostic, remove a warning or influence Radar.
6. Fail closed at the public boundary
Public payloads pass shape, value, semantic-consistency and secret-leak checks. On failure ZECOIN returns a neutral state rather than internal details.
What this methodology does not guarantee
No diagnostic guarantees that an asset will rise, a project is honest or a transaction is risk-free. ZECOIN helps reduce uncertainty; it never denies it.