Skip to main content

Intuition

Intuition (TRUST) — 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).

Intuition — an Infra | Identity | Data project (decentralized attestations and a token‑curated knowledge graph), token (symbol: TRUST).

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 network/protocol for structuring claims (attestations) as a knowledge graph and for the cryptoeconomic “weighting of trust” in them via staking.
  • Who it’s for: developers (GraphQL/SDK/API), applications and agents that need a portable identity/reputation/context layer, and users who want to publish/curate data.
  • Why onchain/token: attestations and the economic signal are recorded onchain; TRUST is the unit of payment for write/read operations and the staking/signaling/governance token, as well as the collateral for node operators (with possible slashing).

How it works (very briefly)

  1. The user/application creates entities (Atoms) and claims (Triples/Claims) and/or finds existing ones.
  2. Participants place an economic signal (Signals) — they deposit TRUST into “vaults” (including “for/against” for claims), forming a weighted consensus and ranking.
  3. Indexing nodes collect the onchain+offchain state into a queryable graph and serve queries via an API.
  4. The user gets structured, verifiable and ranked data (context/reputation/signals) for applications and agents.
  5. Where the blockchain is: recording of attestations/Atoms/Triples and economic signals (staking, bonding curves) — onchain.
  6. Token role: TRUST meters write/read operations and is used for staking/signaling, governance and bonding/slashing of node operators.

Quick links: AI thesis fit

Project passport

Field Value
Project name Intuition
Also known as (aliases) Intuition Network; Intuition Protocol; Intuition Systems
Logo (logo) ../assets/103_intuition_logo.svg
Token symbol (ticker) TRUST
Category Infra | Identity | Data
Primary chain (chain) Base
Type EVM
Network status mainnet
Consensus (consensus) L3 (Arbitrum Orbit AnyTrust DA)
Launch date (launch_date) —
Project status (status) active (network live; docs/portal available)
Token (standard) ERC-20
Token contract 0x6cd905dF2Ed214b22e0d48FF17CD4200C1C6d8A3 (Base)
Token model (token_type) utility (payments + staking + governance)
Max supply 1,020,192,307.692307692307692305 TRUST (Max Total Supply per BaseScan)
Issuance emissions (minting schedule, decaying; per the token whitepaper)
Tokenomics (tokenomics, brief) write/read operations metered in TRUST; staking/Signals and bonding curves; bonding for node operators; governance (per the whitepaper)
Governance DAO
Admins/keys the token contract on Base is marked as a proxy (TransparentUpgradeableProxy on BaseScan) ⇒ an upgrade admin exists (risk of admin upgrades)
Audit yes
Bug bounty —
Team (team) Intuition Systems, Inc. (per the token whitepaper)
Funding (investors/funding) “Backed by 100+ Top Investors” (claim on the website; no details)
AI component (ai_component) context/reputation for AI agents (no proven ML core)
Use‑case (use_case) attestations + token-curated knowledge graph
DecAI Fit — AI thesis fit 3/6 — medium alignment with the Decentralized AI thesis
DecAI Fit component summary 1 / 3 / 3 / 3
Last verified 2026-02-11

General project overview

Intuition describes itself as a decentralized attestation system and a “semantic web of trust”, in which claims become structured objects and gain economic weight via staking. At the core is a data model of three primitives: Atoms (entity identifiers), Triples (structured claims in subject‑predicate‑object format) and Signals (stake/weight of trust in an entity/claim).

From the practical side, this is infrastructure for:

  • publishing and curating data/claims in a shared graph,
  • building portable reputation/context,
  • accessing data via API/SDK (including for applications and AI agents).

Key point: the economic mechanisms (TRUST, staking, vaults, bonding curves) are meant to make the “signal” expensive for spam and profitable for early, accurate curation.

Features/modules

  • Intuition Network: an L3 chain (settling to Base) in which attestations/Atoms/Triples are recorded (per the docs).
  • Intuition Protocol: rules/primitives for knowledge representation and economic incentives (vaults, signals, bonding curves).
  • Rust Subnet: the indexing/query layer and developer tools (GraphQL, SDK) (per the docs).
  • Token‑curated knowledge graph: ranking/“price” of data via TRUST staking.

Typical scenarios

  • Scenario 1 (data publishing): a developer/user creates an Atom/Triple → pays a fee in TRUST and/or stakes → the data appears in the graph and can be reused by others.
  • Scenario 2 (curation/disputes): participants stake “for/against” a claim → an economically weighted signal of trust/dispute is formed.
  • Scenario 3 (context reading): an application/agent queries the graph via the API → receives structured claims and Signals weights → uses them for output/ranking/checks.

Getting started (wallet/network)

  • What you need: an EVM wallet and TRUST for write/read operations and staking (if you publish/curate), or only API access (if you read via the SDK).
  • Network/chain: the TRUST token (and part of the interactions) is visible on Base; the network/protocol describe a separate Intuition Network as a Base L3 (per the docs).
  • Fees: a fee in TRUST for creation/writes/reads/queries (per the token whitepaper: “All write and read operations are metered in TRUST”).

Architecture/tech (non‑AI)

  • Components: the protocol smart contracts (Atoms/Triples/vaults/signals), the TRUST token (ERC‑20), indexing nodes (Rust subnet), API (GraphQL/SDK).
  • Participant roles: data creators, curators (stake/Signals), data consumers (query), node operators (indexing/serving queries).
  • Where logic runs: recording of claims and economic states — onchain; indexing/search/access to the graph — offchain (nodes), but anchored to the onchain source.
  • Dependencies: Base as the base settlement layer; the Arbitrum Orbit stack and AnyTrust DA for the L3 (per the docs); indexer/node infrastructure.

Token/economics (expanded, no forecasts)

  • Token utility: TRUST — the unit of payment for write/read operations and the base asset for staking/signaling on claims and entities (per the token whitepaper and the docs primitives).
  • Protocol necessity drivers: the protocol model relies on “skin‑in‑the‑game” for curation and protection against spam/DoS; without TRUST the claimed economic ranking mechanisms and incentives disappear.
  • Who pays fees: authors/curators when publishing and staking; consumers when querying (whitepaper: “authors place stake… consumers pay ‘gas fees’ when querying”).
  • Where fees go: the whitepaper describes fee redistribution in favor of creators/curators and protocol mechanics; the exact splits/parameters are governable (DAO).
  • Issuance/burn: the whitepaper describes a minting schedule with decaying emissions; detailed numbers/schedules may be moved into separate tables/DAO parameters.
  • Security/incentive mechanisms: staking/Signals (including counter‑stake), bonding curves in vaults; for node operators — bonding TRUST and slashing for downtime/tampering (per the token whitepaper).
  • Distribution/vesting: “team and investor allocations… vesting‑protected” is mentioned, but without specific numbers in the available Tier‑1 fragment; we record it as “— (needs to be confirmed with a distribution/vesting table)”.
  • Treasury: managed by the governance of TRUST holders (per the whitepaper); details of addresses/execution mechanisms are not confirmed by Tier‑1 sources.

Governance

  • Who makes decisions: a DAO model: TRUST holders (per the token whitepaper).
  • How protocol parameters change: via proposals and voting; proposal thresholds/quorum and the possibility of delegation are described; economic parameters (fees/emissions/bonding curves) are governable (per the whitepaper).
  • Where decisions are discussed/made: an explicit governance forum/snapshot is not confirmed by Tier‑1 sources (links_* contains the roadmap/security advisories on GitHub).
  • Keys/multisig: not confirmed. Important: the token contract is marked as a proxy ⇒ an upgrade admin exists (see the passport).

Security and incidents

  • Audits: Security Assessment (Summary Report) — March 28, 2024; high severity: none; medium/low findings and fixes referencing PR/commit are listed (per the audit reports).
  • Bug bounty: — (a Tier‑1 page/terms not found in links_*).
  • Incidents: no Tier‑1 postmortems/incidents were found.
  • Threat model (brief):
    • Economic attacks on curation (manipulation of signals/stakes).
    • Upgradeability risks (the proxy admin can change the logic).
    • Indexer availability/truthfulness risks, compensated by bonding/slashing (per the whitepaper).

Project status and timeline

  • Current status: “The Intuition Network is live” (claim on the website) ⇒ we treat it as mainnet/live.
  • Key releases/milestones: the audit report was updated 2024‑04‑03 (Tier‑1 mark on the audit reports).
  • Roadmap: links_* lists GitHub milestones in the whitepaper repo (as an engineering artifact/pointer); the contents of the milestones were not extracted within this card.

Ecosystem/integrations

  • Integrations (Tier‑1 mentions): the docs mention a GraphQL API and SDK; the website and docs show a “Portal” as the user entry point.
  • Partners: the website has an “Our Partners / Trusted by” block, but without verifiable terms/integration details in Tier‑1 (we record it as a marketing claim).
  • Where it’s actually used: no specific Tier‑1 production integrations (other than the project’s own portal/SDK/API) are recorded.

AI component of the project

  • What is real AI here? Tier‑1 sources position the system as infrastructure useful for AI agents (context/reputation/graph queries), but no Tier‑1 evidence of the protocol’s own ML models/inference was found.
  • What is truly onchain? attestations and economic signals are recorded onchain (Atoms/Triples/Signals, vaults/staking); the TRUST token is onchain (ERC‑20 on Base).
  • Why is a token needed? TRUST meters write/read operations and is used for staking/signaling and governance; it is also the collateral for node operators (with slashing risk).
  • Red flags (based on the information found): AI‑washing — high risk of terminological “AI” without a verifiable AI core (AI_1..AI_4 need to be confirmed); onchain‑washing — low (the onchain logic is the core); token‑washing — low (the token utility is described in detail in Tier‑1 in the whitepaper). What to double‑check: the presence/absence of a real AI component at the product level (not “for AI”, but “does AI”).

DecAI Fit component summary

  • DecAI Fit: 3/6 — medium alignment with the Decentralized AI thesis
Component Level Score
AI reality low (there is AI intent, but no Tier‑1 artifacts of “does AI”) 1
Onchain necessity high 3
Token necessity high 3
Evidence Tier‑1 present 3
Details

AI reality

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

  • AI_0 (decision): 1
  • Claim (one line): the project explicitly positions its graph/attestations as infrastructure useful for AI/agents (intent/direction), without confirmation of its own models.
  • Evidence: Tier‑1 — https://www.intuition.systems/ (the “Artificial Intelligence (AI)” block), https://docs.intuition.systems/docs/introduction/overview (mention that the Subnet is “powering AI agents…”).
  • Why sufficient / why not (one line): these are Tier‑1 claims about AI orientation/usage context, but not evidence of a working AI component in the protocol.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 0
  • Claim (one line): the available Tier‑1 sources do not describe specific ML/AI functionality performed by the protocol (inference/training/agents as a product).
  • Evidence: Tier‑1 — https://docs.intuition.systems/docs/introduction/overview, https://www.docs.intuition.systems/docs/primitives/overview
  • Why sufficient / why not (one line): data/attestations/signals and infrastructure are described, but not “what exactly the AI does”.
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 0
  • Claim (one line): no Tier‑1 demo of an “AI component” (in the sense of an ML function) was found.
  • Evidence: Tier‑1 — https://www.intuition.systems/, https://www.docs.intuition.systems/
  • Why sufficient / why not (one line): there is a product/docs, but no demonstration of an AI function as part of the protocol.
  • 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.intuition.systems/docs/introduction/overview
  • Why sufficient / why not (one line): no Tier‑1 AI quality metrics/benchmarks are provided.
  • Conflict note (if any): —

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

  • AI_4 (decision): 0
  • Claim (one line): there is an architecture of the protocol/primitives, but no technical description of models/versions (as for an AI component).
  • Evidence: Tier‑1 — https://docs.intuition.systems/docs/introduction/overview
  • Why sufficient / why not (one line): the documentation is about the network/protocol/indexing, not about ML models.
  • Conflict note (if any): —

Onchain necessity

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

  • OC_1 (decision): 1
  • Chain: Base (for the ERC‑20 TRUST); the Intuition Network is described as a Base L3 (Orbit stack) in the docs.
  • Addresses/identifiers: TRUST ERC‑20: 0x6cd905dF2Ed214b22e0d48FF17CD4200C1C6d8A3 (proxy).
  • Evidence: Tier‑1 — https://basescan.org/token/0x6cd905dF2Ed214b22e0d48FF17CD4200C1C6d8A3, https://docs.intuition.systems/docs/introduction/overview
  • Why sufficient / why not (one line): there is a specific onchain token address and a Tier‑1 description of the network/layer.
  • Conflict note (if any): —

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

  • OC_2 (decision): 1
  • What useful logic is onchain: attestations/Atoms/Triples and economic Signals (staking in vaults, including “for/against”), bonding curves — described as onchain primitives/actions.
  • Evidence: Tier‑1 — https://docs.intuition.systems/docs/introduction/overview, https://www.docs.intuition.systems/docs/primitives/overview
  • Why sufficient / why not (one line): the protocol’s useful logic is claimed as onchain and is not reducible to the token.
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 1
  • “Replace the blockchain” test: without onchain, the verifiable recording of attestations and the economic signal (stake/Signals) on which ranking and incentives are built disappear.
  • Evidence: Tier‑1 — https://docs.intuition.systems/docs/introduction/overview, https://raw.githubusercontent.com/0xIntuition/trust-whitepaper/main/trust-whitepaper.md
  • Why sufficient / why not (one line): onchain recordability and the economic layer are the claimed core; replacement with web2 breaks the “verifiable/tokenized/portable” properties.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): the project has a token, TRUST (ERC‑20).
  • Evidence: Tier‑1 — https://basescan.org/token/0x6cd905dF2Ed214b22e0d48FF17CD4200C1C6d8A3
  • Why sufficient / why not (one line): the token clearly exists and is verifiable in the 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): write and read operations are metered in TRUST (fees/“gas fees” for queries).
  • Evidence: Tier‑1 — https://raw.githubusercontent.com/0xIntuition/trust-whitepaper/main/trust-whitepaper.md (Abstract: “All write and read operations are metered in TRUST…”)
  • Why sufficient / why not (one line): a direct Tier‑1 description of the token’s payment role.
  • Conflict note (if any): —

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

  • TK_2 (decision): 1
  • Claim (one line): staking TRUST forms Signals; node operators must bond TRUST and can be punished with slashing for downtime/tampering.
  • Evidence: Tier‑1 — https://www.docs.intuition.systems/docs/primitives/overview (Signals via staking), https://raw.githubusercontent.com/0xIntuition/trust-whitepaper/main/trust-whitepaper.md (node operator bonding/slashing)
  • Why sufficient / why not (one line): token incentives and collateral are described as a key security/quality mechanism.
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 1
  • Claim (one line): TRUST is described as a governance token; holders vote on upgrades/fees/bonding curves/treasury allocations.
  • Evidence: Tier‑1 — https://raw.githubusercontent.com/0xIntuition/trust-whitepaper/main/trust-whitepaper.md (Abstract + Governance Framework)
  • Why sufficient / why not (one line): the governance role is explicitly recorded in the project’s Tier‑1 document.
  • Conflict note (if any): —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 0
  • Claim (one line): per the Tier‑1 description, the token is part of the core of the mechanism (metering + staking/Signals + bonding/slashing + governance); replacing it with “just a subscription/USDC” changes the claimed design.
  • Evidence: Tier‑1 — https://raw.githubusercontent.com/0xIntuition/trust-whitepaper/main/trust-whitepaper.md
  • Why sufficient / why not (one line): the token is embedded in the protocol’s economy and trust mechanisms, not a “payment layer on top”.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://docs.intuition.systems/docs/introduction/overview description of the architecture (Network/Protocol/Subnet), L3 on the Orbit stack/AnyTrust DA, primitives and the onchain role
Tier‑1 https://www.docs.intuition.systems/docs/primitives/overview definitions of Atoms/Triples/Signals and the role of staking as the “weight of trust”
Tier‑1 https://raw.githubusercontent.com/0xIntuition/trust-whitepaper/main/trust-whitepaper.md role of the TRUST token: metering write/read, staking/Signals, node bonding+slashing, governance
Tier‑1 https://basescan.org/token/0x6cd905dF2Ed214b22e0d48FF17CD4200C1C6d8A3 ERC‑20 TRUST on Base: address, max total supply, proxy/upgradability fact
Tier‑1 https://tech.docs.intuition.systems/contracts/audit-reports existence of a security assessment; high severity: none; list of fixes (PR/commits)
Tier‑1 https://www.intuition.systems/ high‑level positioning, “network is live”, AI orientation at the intent level

No comments to display

Back to top