{
  "object": "jepeta_content_article",
  "schemaVersion": "1.0.0",
  "id": "article.token-risk-evidence-limits",
  "contentType": "security_intelligence",
  "title": "What a Base Token Risk Check Can Prove, and Where Its Evidence Stops",
  "slug": "token-risk-evidence-limits",
  "category": "security",
  "intent": "Explain the scope, blind spots and evidence freshness of a Base token risk scan so readers do not interpret PASS as a safety guarantee.",
  "directAnswer": "A Base token risk scan summarizes observed contract, market and permission signals using the sources available at a particular time. A successful scan is not a smart-contract audit, an investment recommendation or proof that liquidity will remain accessible. Unknown and stale inputs must remain visible rather than being treated as clean safety evidence.",
  "sections": [
    {
      "heading": "A risk report is a dated observation, not a certificate",
      "paragraphs": [
        "Jepeta's [methodology](https://jepeta.dev/methodology.html) describes evidence-led screening rather than an audit of every execution path in a smart contract. A result reflects inputs observed from external providers and the canonical risk policy at a specific time. Ownership controls, transfer restrictions, selected liquidity and holder concentration can be useful warning indicators. None proves what a deployer or market participant will do next. A lower reported score means the screening engine classified available evidence differently, not that the asset became a safe investment."
      ]
    },
    {
      "heading": "Read the provenance before the score",
      "paragraphs": [
        "| Field in a result | Question to ask |\n| --- | --- |\n| Token address and chain | Is this the exact Base contract I meant to inspect? |\n| Last checked | How old are the underlying observations? |\n| Source status | Which providers responded and which failed? |\n| Data quality | Are key inputs complete enough for a decision? |\n| Liquidity market | Which actual pair or pool was selected? |\n| Risk reasons | Which verified observations produced PASS, WARN or BLOCK? |\n\nDo not compare differently scoped or dated outputs as if they measured identical conditions. The same ticker can refer to unrelated token contracts; an address and chain identity are essential."
      ]
    },
    {
      "heading": "How missing source data should change your decision",
      "paragraphs": [
        "If a required permission, ownership, sellability or market field is missing, its absence cannot be used as positive evidence. A provider may time out, block automated traffic or omit a recently deployed token. Jepeta's public API contract can distinguish a complete risk result from a partial or unavailable-source response. An HTTP success code from a third-party API does not by itself prove the returned fields are complete. If a critical check is unavailable, treat that uncertainty as unresolved rather than turning it into a reassuring green verdict."
      ]
    },
    {
      "heading": "Liquidity and holder signals need context",
      "paragraphs": [
        "Liquidity values may depend on the chosen pool, chain, timestamp and pricing source. A move from one selected pool to another is not the same as a like-for-like change in the depth of a single pool. Holder concentration may also change with transaction activity, excluded addresses and the source's coverage. This is why two risk snapshots are not automatically a publishable news event. Compare their methodology versions and source context before claiming that the market objectively became more or less risky."
      ]
    },
    {
      "heading": "The scanner cannot inspect your personal wallet permissions",
      "paragraphs": [
        "Token-level contract controls do not tell you which spenders your wallet previously authorized. [Ethereum.org's token-access guide](https://ethereum.org/guides/how-to-revoke-token-access) explains that allowances are chain-specific authorizations which may persist after a site connection ends. A scan of a token cannot revoke an approval, cancel a signed transaction or verify the authenticity of every dapp interface. Read our [approval hygiene guide](https://jepeta.dev/articles/token-approval-hygiene-guide/) to check a separate risk surface."
      ]
    },
    {
      "heading": "What Base recommends outside token screening",
      "paragraphs": [
        "[Base's developer security documentation](https://docs.base.org/base-chain/security/avoid-malicious-flags) emphasizes verified contract source, reducing exposure of user funds, transparent onchain actions and appropriate contract reviews. These are controls at the application and user-interaction layer. A token scanner cannot certify that a website's button matches the contract it will call or that an operator can be trusted. Research the application's contract addresses and permission requests independently before using it."
      ]
    },
    {
      "heading": "A responsible pre-action workflow",
      "paragraphs": [
        "1. Verify the exact chain and contract address through a trustworthy source.\n2. Run a fresh scan and inspect the full risk reasons, timestamps and source availability.\n3. Review permissions and market/liquidity context independently.\n4. Stop when any critical required signal is missing or contradictory.\n5. If you proceed, inspect every wallet approval on the device or wallet screen; do not rely only on webpage copy.\n6. Return to the sources when conditions change, especially for thin or newly listed markets.\n\nThis sequence organizes checks; it cannot guarantee a particular trading outcome."
      ]
    },
    {
      "heading": "Evidence and editorial boundary",
      "paragraphs": [
        "Jepeta reports first-party risk-engine outputs with their sources and limits. Its Content and Intelligence reviews should not label a token fraudulent, safe or audited without separate support for that statement. This explanation is educational and not a new risk score, an allegation against any listed token or a claim of independent onchain forensics. The useful output is a better decision process, not a false promise of certainty."
      ]
    }
  ],
  "sources": [
    {
      "id": "jepeta_method",
      "label": "Jepeta Risk Guard canonical methodology",
      "url": "https://jepeta.dev/methodology.html",
      "sourceType": "jepeta",
      "publishedAt": null,
      "verifiedAt": "2026-10-09T05:35:44.898Z"
    },
    {
      "id": "base_security",
      "label": "Base: application and contract security guidance",
      "url": "https://docs.base.org/base-chain/security/avoid-malicious-flags",
      "sourceType": "primary",
      "publishedAt": null,
      "verifiedAt": "2026-10-09T05:35:44.898Z"
    },
    {
      "id": "ethereum_revoke",
      "label": "Ethereum.org: token allowances are separate wallet permissions",
      "url": "https://ethereum.org/guides/how-to-revoke-token-access",
      "sourceType": "primary",
      "publishedAt": null,
      "verifiedAt": "2026-10-09T05:35:44.898Z"
    }
  ],
  "sourceDates": [
    {
      "sourceId": "jepeta_method",
      "publishedAt": null,
      "verifiedAt": "2026-10-09T05:35:44.898Z"
    },
    {
      "sourceId": "base_security",
      "publishedAt": null,
      "verifiedAt": "2026-10-09T05:35:44.898Z"
    },
    {
      "sourceId": "ethereum_revoke",
      "publishedAt": null,
      "verifiedAt": "2026-10-09T05:35:44.898Z"
    }
  ],
  "originalEvidence": [
    {
      "type": "structured_comparison",
      "description": "Primary-source editorial comparison of documented security or import/tax procedures, including a task-oriented checklist and limits. No live wallet test, tax filing, or exchange API account verification is claimed.",
      "url": "https://jepeta.dev/methodology.html",
      "observedAt": "2026-10-09T05:35:44.898Z"
    }
  ],
  "datePublished": "2026-10-09T05:35:44.898Z",
  "dateModified": "2026-10-09T05:35:44.898Z",
  "reviewedAt": "2026-10-09T05:35:44.898Z",
  "affiliate": {
    "enabled": false,
    "partnerId": null,
    "linkId": null,
    "disclosureRequired": false,
    "rel": null
  },
  "disclosure": null,
  "internalLinks": [
    "/articles/jepeta-security-evidence-audit/",
    "/articles/token-approval-hygiene-guide/",
    "/articles/token-approval-risk-before-swap/",
    "/methodology.html",
    "/#scanner"
  ],
  "telegramCohort": {
    "surface": "article",
    "cohortId": "article"
  },
  "format": "markdown",
  "seoTitle": "Base Token Risk Evidence: Scanner Limits and Missing Signals",
  "metaDescription": "A Base token risk scan summarizes observed contract, market and permission signals using the sources available at a particular time. A successful scan is n",
  "quality": {
    "decision": "publish",
    "citabilityScore": 100,
    "reviewedAt": "2026-10-09T05:35:44.898Z",
    "policyVersion": "1.0.0"
  },
  "canonicalUrl": "https://jepeta.dev/articles/token-risk-evidence-limits/",
  "jsonUrl": "https://jepeta.dev/articles/token-risk-evidence-limits/index.json"
}