Skip to main content

Santiment (SAN)

Santiment (SAN) — a reference card for a crypto project: what the product does and how verifiable the project’s key claims are; also — alignment with the Decentralized AI thesis (DecAI Fit).

Santiment (SAN) — an Infra, Analytics project; the product is an offchain analytics platform (Sanbase/SanAPI), token SAN (ERC‑20, Ethereum).

Disclaimer

Important: this page is a reference overview of the project. Within DecAIHub, we separately record a verification based on open sources within the AI thesis (what is real AI/onchain/why a token, and which sources this is based on).
This is not financial advice and not a recommendation to buy/sell/hold any asset. We do not assess price, returns, or entry/exit timing.
Conclusions are based on publicly available materials found as of the verification date. The absence of confirmation does not imply the absence of the technology.

TL;DR (for readers who are not into AI)

  • What it is: a crypto analytics and data product/platform (Sanbase, SanAPI) with market/onchain/social‑signal metrics (per Tier‑1 docs).
  • Who it’s for: traders/analysts and developers who need metrics/insights and API access (per Tier‑1 docs).
  • Why onchain/token: the SAN token (ERC‑20) is used for discounts/access to plans and “pay by burning” (described in the Tier‑1 Academy).
  • What you can actually touch (Tier‑1): https://app.santiment.net/explorer (Sanbase Explorer)

How it works (very briefly)

  1. The user does: opens Sanbase/Explorer or uses the API.
  2. The system does: provides metrics and analytical views (as described in the documentation).
  3. The user gets: access to data/insights and analysis tools.
  4. Where the blockchain is: the SAN token is confirmed onchain on the Ethereum network (ERC‑20).
  5. Token role (if any): discounts/access to plans, the option to pay via burning SAN; benefits from holding/staking/liquidity are also described (Tier‑1 Academy).

Quick links: AI thesis fit

Project passport

Field Value
Project name Santiment (SAN)
Also known as (aliases) Santiment; Santiment Network Token; SAN
Logo (logo) ../assets/540_santiment_logo.svg
Token symbol (ticker) SAN
Category Infra | Analytics
Primary chain (chain) Ethereum
Type EVM
Network status mainnet
Consensus (consensus) PoS (Ethereum)
Launch date (launch_date) —
Project status (status) active
Token (standard) ERC-20
Token contract 0x7c5a0ce9267ed19b22f8cae653f198e3e8daf098
Token model (token_type) utility (discounts + payments + staking)
Max supply —
Issuance —
Tokenomics (tokenomics, brief) holding benefits; pay by burning SAN (Tier‑1)
Governance —
Admins/keys —
Audit —
Bug bounty —
Team (team) —
Funding (investors/funding) —
AI component (ai_component) —
Use‑case (use_case) crypto market analytics + on-chain metrics
DecAI Fit — AI thesis fit 0/6 — no AI reality and no AI intent (ai_score=0)
DecAI Fit component summary ai_score 0 / onchain_score 1 / token_score 2 / evidence_score 2
Last verified 2026-02-11

General project overview

Santiment is a data and analytics platform for the crypto market: it provides metrics (onchain/social/development, etc.), the Sanbase interface and API access (SanAPI), as well as auxiliary tools (Sansheets, Queries) — per the Tier‑1 documentation.
The verifiable onchain part within this card is the SAN token (ERC‑20, Ethereum) and the benefits/utility associated with it, as described in the official materials.

Features/modules

  • Sanbase / Explorer: an interface for viewing metrics and analytics.
  • SanAPI: access to metrics via the API.
  • Santiment Queries / Sansheets: tools for data research/integration (per the docs).

Typical scenarios

  • Scenario 1: the user opens Sanbase Explorer → explores metrics/trends.
  • Scenario 2: a developer uses SanAPI → receives metrics in their own application/model.
  • Scenario 3: the user connects a wallet holding SAN to their account → receives benefits/access/discounts (as described in the Academy).

Getting started (wallet/network)

  • What you need: an account/access to the product (Sanbase) and, when using SAN benefits, an EVM wallet.
  • Network/chain: Ethereum (for the SAN token).
  • Fees: Ethereum fees for onchain operations with the token.

Architecture/tech (non‑AI)

  • Components: web products/data infrastructure (offchain) + the SAN token (onchain).
  • Participant roles: platform users; API developers; token holders.
  • Where logic runs: analytics/metrics — offchain; the SAN token — onchain (Ethereum).
  • Dependencies: Ethereum (for the token) + the service infrastructure (offchain; details not disclosed as a protocol).

Token/economics (expanded, no forecasts)

  • Token utility: Tier‑1 Academy: holding benefits (discounts), “pay by burning SAN”, free access to Sanbase PRO (the conditions depend on holding/staking/liquidity).
  • Protocol necessity drivers: per Tier‑1, the utility token is used as part of the access/benefits model; the “mandatory nature” of the token as the only payment/access mechanism is not established everywhere.
  • Who pays fees: users for onchain operations on Ethereum.
  • Where fees go: to the Ethereum network validators (gas); Santiment protocol fees — not established.
  • Issuance/burn: the option to pay via burning SAN is described in the Tier‑1 Academy; other parameters — see the whitepaper/docs.
  • Security/incentive mechanisms: the Tier‑1 Academy mentions benefits from holding/staking/liquidity (the details of the conditions require reading the specific benefits pages).
  • Distribution and token issuance schedule: — (not extracted per Tier‑1 within this card).
  • Treasury: —.

Governance

  • Who makes decisions: — (not established per Tier‑1 within this card)
  • How protocol parameters change: — (not established per Tier‑1)
  • Where decisions are discussed/made: — (not established per Tier‑1)
  • Keys/multisig: — (not established per Tier‑1)

Security and incidents

  • Audits: — (not established per Tier‑1 within this card)
  • Bug bounty: — (not established per Tier‑1)
  • Incidents: — (not established per Tier‑1)
  • Threat model: risks of the offchain infrastructure/data and risks of the token (ERC‑20); the details of the security measures require separate verification per Tier‑1.

Project status and timeline

  • Current status: active (docs/products available; the token is on mainnet)
  • Key releases/milestones: see the changelog (Tier‑1) in links_*.
  • Roadmap: — (not found per Tier‑1)

Ecosystem/integrations

  • Integrations: SanAPI / Sansheets / Queries (per Tier‑1 docs).
  • Partners: — (not established per Tier‑1)
  • Where it’s actually used: as an analytics/metrics product (Sanbase/Explorer, API) — see the Tier‑1 links in links_*.

AI component of the project

  • What is real AI here? No Tier‑1 confirmation of an AI component (in the sense of “what the AI does” as part of the product/protocol) is recorded in this card → ai_score = 0.
  • What is truly onchain? The SAN token (ERC‑20) on the Ethereum network.
  • Why is a token needed? Tier‑1 Academy: discounts/benefits, “pay by burning SAN”, access to Sanbase PRO (depending on holding/staking/liquidity).
  • Red flags (based on the information found): ai_score = 0; onchain logic other than the token is not confirmed by Tier‑1; the benefits/staking conditions should be double‑checked on the Tier‑1 pages.

DecAI Fit component summary

  • DecAI Fit: 0/6 — no AI reality and no AI intent (ai_score=0)
Component Level Score
AI reality no Tier‑1 data 0
Onchain necessity low 1
Token necessity medium 2
Evidence Tier‑1 present 2
Details

AI reality

AI_0 — AI intent (Tier‑1 roadmap) (1/0)

  • AI_0 (decision): 0
  • Claim (one line): No Tier‑1 roadmap/claim about AI intentions is recorded.
  • Evidence: Tier‑1 — https://docs.santiment.net/
  • Why sufficient / why not (one line): In the available Tier‑1 materials there is no explicit record of AI intent as a separate roadmap element.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 0
  • Claim (one line): What exactly the AI component does (task/input‑output) is not established per Tier‑1.
  • Evidence: Tier‑1 — https://docs.santiment.net/
  • Why sufficient / why not (one line): The docs describe metrics/analytics, but an AI component as a product entity is not singled out.
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 0
  • Claim (one line): A public demo confirming specifically an AI component is not established per Tier‑1.
  • Evidence: Tier‑1 — https://app.santiment.net/explorer
  • Why sufficient / why not (one line): There is a demo of the analytics product, but it does not prove an AI component.
  • Conflict note (if any): —

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 0
  • Metrics: —
  • Context (version/date/how measured): —
  • Evidence: Tier‑1 — https://docs.santiment.net/
  • Why sufficient / why not (one line): Quality metrics of the AI component are not presented, since the AI component is not established per Tier‑1.
  • Conflict note (if any): —

AI_4 — tech description/architecture/versions (1/0)

  • AI_4 (decision): 0
  • Claim (one line): A tech description of the AI module/model architecture was not found per Tier‑1.
  • Evidence: Tier‑1 — https://docs.santiment.net/
  • Why sufficient / why not (one line): The documentation describes the product/metrics but does not record the architecture of an AI component.
  • Conflict note (if any): —

Onchain necessity

OC_1 — contracts/addresses/chain (1/0)

  • OC_1 (decision): 1
  • Chain: Ethereum
  • Addresses/identifiers: 0x7c5a0ce9267ed19b22f8cae653f198e3e8daf098
  • Evidence: Tier‑1 — https://etherscan.io/token/0x7c5a0ce9267ed19b22f8cae653f198e3e8daf098
  • Why sufficient / why not (one line): The token contract is confirmed in the block explorer.
  • Conflict note (if any): —

OC_2 — onchain beyond just a token (1/0)

  • OC_2 (decision): 0
  • What useful logic is onchain: not established per Tier‑1 (within this card only the token is confirmed).
  • Evidence: Tier‑1 — https://docs.santiment.net/
  • Why sufficient / why not (one line): The available Tier‑1 sources do not describe an onchain protocol/logic other than the token.
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 0
  • “Replace the blockchain” test: it is not established that without the blockchain the product loses a key property (per Tier‑1).
  • Evidence: Tier‑1 — https://docs.santiment.net/
  • Why sufficient / why not (one line): The main product/metrics are provided offchain; no Tier‑1 justification of onchain criticality was found.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): The project has a token, SAN (ERC‑20).
  • Evidence: Tier‑1 — https://etherscan.io/token/0x7c5a0ce9267ed19b22f8cae653f198e3e8daf098
  • Why sufficient / why not (one line): The token is confirmed by the contract in the block explorer.
  • Conflict note (if any): —

TK_1..TK_4 (1/0)

TK_1 — payment for the service (1/0)

  • TK_1 (decision): 1
  • Claim (one line): Tier‑1 Academy: there is an option to pay for services via burning SAN (“pay by burning SAN tokens”).
  • Evidence: Tier‑1 — https://academy.santiment.net/san-tokens/
  • Why sufficient / why not (one line): The official material explicitly describes the payment role of the token (via burning).
  • Conflict note (if any): —

TK_2 — incentives/collateral/penalties (1/0)

  • TK_2 (decision): 1
  • Claim (one line): Tier‑1 Academy: benefits depend on holding/staking and liquidity participation (discounts/access/benefits).
  • Evidence: Tier‑1 — https://academy.santiment.net/san-tokens/
  • Why sufficient / why not (one line): The official material claims an incentive logic via holding/staking/liquidity.
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 0
  • Claim (one line): A specific governance mechanic of the SAN token is not established per Tier‑1.
  • Evidence: Tier‑1 — https://academy.santiment.net/san-tokens/
  • Why sufficient / why not (one line): The available Tier‑1 material contains a general wording about “governance” as a direction, but without a voting mechanic.
  • Conflict note (if any): —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 0
  • Claim (one line): The replaceability/irreplaceability of the token is not established per Tier‑1.
  • Evidence: Tier‑1 — https://academy.santiment.net/san-tokens/
  • Why sufficient / why not (one line): Without a strict Tier‑1 comparison of alternatives (subscription/stablecoin), we conservatively set 0.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://santiment.net/ Tier‑1: the official website of the product/platform.
Tier‑1 https://docs.santiment.net/ Tier‑1: documentation on products/metrics/plans.
Tier‑1 https://app.santiment.net/explorer Tier‑1: the public product entrypoint (Sanbase Explorer).
Tier‑1 https://academy.santiment.net/san-tokens/ Tier‑1: the utility of the SAN token (discounts/benefits, pay by burning, access).
Tier‑1 https://etherscan.io/token/0x7c5a0ce9267ed19b22f8cae653f198e3e8daf098 Onchain fact: the SAN token (ERC‑20, Ethereum).

No comments to display

Back to top