Internet Computer

Internet Computer — 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).

Internet Computer (ICP) — an L1/Infra project on the Internet Computer network, token (symbol: ICP).

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: an L1 network/platform for smart contracts (“canisters”) that can serve web requests and store state onchain.
Who it’s for: application developers, dApp users, teams that need “end‑to‑end onchain” infrastructure.
Why onchain/token: onchain provides execution/state and verifiability; the ICP token is used for governance and for conversion into cycles to pay for compute/storage.
What you can actually touch (Tier‑1): the LLM Chatbot example (canister + UI), which can be deployed via ICP Ninja.

How it works (very briefly)

The developer deploys a canister: the code and state are placed on the network.
The user sends requests: calls to the application/contract are processed by the IC infrastructure.
The network executes the logic and stores the state: the result and data are recorded in the replicated state.
Where the blockchain is: consensus/replication/state certification and onchain execution of canisters.
Token role: ICP participates in governance (NNS) and is converted into cycles to pay for canister resources.

Quick links: AI thesis fit

Project passport

Field	Value
Project name	Internet Computer
Also known as (aliases)	ICP, Internet Computer Protocol
Logo (logo)	../assets/internetcomputer_favicon.svg
Token symbol (ticker)	ICP
Category	AI/Other \| Infra
Primary chain (chain)	Internet Computer
Type	Appchain
Network status	mainnet
Consensus (consensus)	BFT (subnet consensus; f < n/3)
Launch date (launch_date)	2021-05-10
Project status (status)	active
Token (standard)	native
Token contract	—
Token model (token_type)	utility (cycles + governance)
Max supply	—
Issuance	inflationary (minted rewards for governance and node provider payouts)
Tokenomics (tokenomics, brief)	ICP is staked in the NNS (governance) and converted into cycles to pay for canister resources; new ICP is also minted as rewards (Tier‑1).
Governance	DAO (NNS)
Admins/keys	—
Audit	yes
Bug bounty	yes
Team (team)	DFINITY Foundation / DFINITY team
Funding (investors/funding)	—
AI component (ai_component)	AI dev workflow + AI applicability
Use‑case (use_case)	L1 for dApps (including AI apps)
DecAI Fit — AI thesis fit	3/6 — medium alignment with the Decentralized AI thesis
DecAI Fit component summary	ai_score 1 / onchain_score 3 / token_score 3 / evidence_score 3
Last verified	2026-02-10

Links (links_*)

Type	Link
Website	https://internetcomputer.org/
Docs	https://docs.internetcomputer.org/
GitHub	https://github.com/dfinity/ic
Releases / Changelog	https://github.com/dfinity/ic/releases
Whitepaper	https://internetcomputer.org/whitepaper.pdf
Roadmap	https://internetcomputer.org/roadmap/
Security advisories	https://internetcomputer.org/security-advisories
Explorer	https://dashboard.internetcomputer.org/
App / Demo	https://docs.internetcomputer.org/references/samples/rust/llm_chatbot
X	https://twitter.com/dfinity
Discord	https://discord.internetcomputer.org/
Telegram	https://t.me/Official_ICP
Medium	https://medium.com/dfinity
Audit report(s)	https://dfinity.org/third-party-security-audits/
Bug bounty	https://dfinity.org/bug-bounty/
CoinGecko (profile, reference)	https://www.coingecko.com/en/coins/internet-computer
CoinMarketCap (profile, reference)	https://coinmarketcap.com/currencies/internet-computer/

General project overview

Internet Computer (ICP) is an L1 platform for running applications and smart contracts (“canisters”) with state storage and logic execution on the network. Unlike models where the frontend/servers remain in the cloud, IC is positioned as an “end‑to‑end” decentralized stack: canisters can serve HTTP requests and store data. The ICP token is used to govern the network via the NNS (onchain governance) and to pay for resources via the cycles mechanism.

Features/modules

Canisters (smart contracts): code + state, executed on the network.
Subnets: the network layer of replication/consensus for executing canisters.
NNS (governance): management of network parameters and protocol changes via DAO mechanics.
Cycles: the resource unit for paying for canister compute/storage/bandwidth (obtained from ICP).

Typical scenarios

Scenario 1: a developer deploys a canister → the application runs onchain and serves requests.
Scenario 2: a user calls canister functions → the state/result is recorded and verifiable.
Scenario 3: a participant stakes ICP and votes in the NNS → influences network/protocol changes.

Getting started (wallet/network)

What you need: an IC developer account/tools and ICP/cycles to pay for canister resources.
Network/chain: Internet Computer mainnet.
Fees: canister resources are paid for with cycles (converted from ICP); details — in the Tier‑1 whitepaper.

Architecture/tech (non‑AI)

Components: the node network (subnets), the consensus/replication layer, canisters (Wasm), boundary nodes.
Participant roles: canister developers and users; node operators; governance participants (NNS).
Where logic runs: canister execution and state storage — onchain/on the IC network; clients/UX — offchain.
Dependencies: — (integrations depend on the specific application).

Token/economics (expanded, no forecasts)

Token utility: ICP is converted into cycles to pay for compute/storage/bandwidth; ICP is also used for governance (staking/voting).
Protocol necessity drivers: cycles are the basic model for paying for resources; the governance token is needed for DAO governance of the network (NNS).
Issuance/burn: Tier‑1 sources describe minted rewards (including node providers/voting rewards) and the cycles model for paying for resources; specific issuance parameters are not recorded in this card.
Security/incentive mechanisms: incentives for node providers and governance participants are described in the whitepaper/NNS (Tier‑1).

Governance

Who makes decisions: DAO governance via the Network Nervous System (NNS).
How protocol parameters change: via proposals and voting in the NNS (described in the Tier‑1 whitepaper).

Security and incidents

Audits: there is a page with third-party audits (see links_*).
Bug bounty: there is a public program (see links_*).
Incidents: —.
System model: L1/protocol parameters and BFT assumptions (for example, the (f < n/3) assumption per subnet) are described in the whitepaper.

Project status and timeline

Current status: mainnet.
Key releases/milestones: code releases are published in GitHub Releases (see links_*).
Roadmap: published on the official website (see links_*).

Ecosystem/integrations

Integrations: —.
Partners: —.
Where it’s actually used: network activity is observable via the official dashboard/explorer (see links_*).

AI component of the project

What is real AI here? In the IC Tier‑1 documentation, AI is listed as an area of applicability and there is an AI-oriented workflow (“Create using AI”), but this does not prove an “AI component of the protocol”.
What is real AI here? In the IC Tier‑1 documentation, AI is listed as an area of applicability and there are examples of AI dApps (for example, LLM Chatbot), but this does not prove an “AI component of the protocol”.
What is truly onchain? The L1 network executes canisters and stores state/certifies results.
Why is a token needed? ICP is used for governance (NNS) and is converted into cycles to pay for canister resources.
Red flags (based on the information found): substituting “AI as applicability/a development tool” for an “AI module of the base protocol”; absence of Tier‑1 metrics/demos of a protocol-level AI component.

DecAI Fit component summary

DecAI Fit: 3/6 — medium alignment with the Decentralized AI thesis

Component	Level	Score
AI reality	medium	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): 0
Claim (one line): There are signs of AI reality per Tier‑1 (see AI_1..AI_4), so the AI_0 flag (intent‑only) does not apply.
Evidence: Tier‑1 — see Evidence/links in AI_1..AI_4.
Why sufficient / why not (one line): AI_0=1 is admissible only when AI_1..AI_4=0; here ai_score without AI_0 = 1.
Conflict note (if any): —

AI_1 — what the AI does (1/0)

AI_1 (decision): 0
Claim (one line): Tier‑1 sources do not describe an “AI component of the base IC protocol” as a mandatory part of the network.
Evidence: Tier‑1 — https://docs.internetcomputer.org/
Why sufficient / why not (one line): Mentioning AI as applicability/a workflow ≠ a description of a working AI module of the protocol.
Conflict note (if any): —

AI_2 — demos/examples (1/0)

AI_2 (decision): 1
Claim (one line): The Tier‑1 developer docs contain a reproducible AI dApp example: LLM Chatbot (a canister interacting with an LLM, with a UI), which can be deployed via ICP Ninja.
Evidence: Tier‑1 — https://docs.internetcomputer.org/references/samples/rust/llm_chatbot
Why sufficient / why not (one line): This is a demonstration of an AI use case/AI application in the IC ecosystem; at the same time, it does not prove an AI component of the base protocol (AI_1 remains 0).
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.internetcomputer.org/
Why sufficient / why not (one line): There are no Tier‑1 quality metrics for an AI subsystem at the base protocol level.
Conflict note (if any): —

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

AI_4 (decision): 0
Claim (one line): There is a technical description of the IC protocol, but not a technical description of an “AI component of the protocol”.
Evidence: Tier‑1 — https://internetcomputer.org/whitepaper.pdf
Why sufficient / why not (one line): The whitepaper describes consensus/architecture/the token, not an AI module.
Conflict note (if any): —

Onchain necessity

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

OC_1 (decision): 1
Chain: Internet Computer mainnet
Addresses/identifiers: — (in this card we record the existence of the network/explorer; specific IDs depend on the entity)
Evidence: Tier‑1 — https://dashboard.internetcomputer.org/ ; https://internetcomputer.org/whitepaper.pdf
Why sufficient / why not (one line): The existence of a mainnet and an official dashboard confirms the onchain network.
Conflict note (if any): —

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

OC_2 (decision): 1
What useful logic is onchain: canister execution, state replication/certification, request processing.
Evidence: Tier‑1 — https://internetcomputer.org/whitepaper.pdf ; https://docs.internetcomputer.org/
Why sufficient / why not (one line): The product = L1 compute/state, not “just a token”.
Conflict note (if any): —

OC_3 — onchain is critical (1/0)

OC_3 (decision): 1
“Replace the blockchain” test: without onchain, the trusted model of canister execution and result certification breaks down.
Evidence: Tier‑1 — https://internetcomputer.org/whitepaper.pdf
Why sufficient / why not (one line): IC is described as a blockchain platform for executing smart contracts; replacing it with a centralized server changes the trust model.
Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

TK_0 (decision): 0
Claim (one line): The project has a native token, ICP.
Evidence: Tier‑1 — https://internetcomputer.org/whitepaper.pdf
Why sufficient / why not (one line): The whitepaper describes the functions of ICP in the network economy.
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): ICP is converted into cycles to pay for canister compute/storage/bandwidth.
Evidence: Tier‑1 — https://internetcomputer.org/whitepaper.pdf
Why sufficient / why not (one line): The whitepaper describes: ICP → cycles, which are used to pay for canister resources.
Conflict note (if any): —

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

TK_2 (decision): 1
Claim (one line): The network model provides for payouts to node providers and rewards to governance participants (minted ICP).
Evidence: Tier‑1 — https://internetcomputer.org/whitepaper.pdf
Why sufficient / why not (one line): The whitepaper describes node provider payouts and voting rewards as incentives.
Conflict note (if any): —

TK_3 — governance (1/0)

TK_3 (decision): 1
Claim (one line): ICP is staked in the NNS to obtain voting power and participate in governance (DAO).
Evidence: Tier‑1 — https://internetcomputer.org/whitepaper.pdf
Why sufficient / why not (one line): The whitepaper explicitly describes staking ICP in the NNS for governance.
Conflict note (if any): —

TK_4 — token is replaceable (1/0)

TK_4 (decision): 0
Claim (one line): The token does not look replaceable without changing the resource payment model and governance.
Evidence: Tier‑1 — https://internetcomputer.org/whitepaper.pdf
Why sufficient / why not (one line): ICP is embedded in the cycles payment model and the PoS governance of the NNS.
Conflict note (if any): —

Evidence (table)

Tier	Source	What it proves
Tier‑1	https://medium.com/dfinity/recap-the-internet-computers-mercury-genesis-launch-event-790d916b5537	Public launch/Genesis date: the network’s transition to fully public mode (May 10, 2021).
Tier‑1	https://docs.internetcomputer.org/	Tier‑1 docs: platform positioning; AI as applicability/AI workflow; dev artifacts.
Tier‑1	https://docs.internetcomputer.org/references/samples/rust/llm_chatbot	Tier‑1 demo/example of an AI dApp: LLM Chatbot (canister + UI, deploy via ICP Ninja).
Tier‑1	https://internetcomputer.org/whitepaper.pdf	Architecture/consensus/the ICP token: governance (NNS), cycles as payment for resources, security assumptions.
Tier‑1	https://dashboard.internetcomputer.org/	The existence of a mainnet and an observable onchain state via the official dashboard.
Tier‑1	https://github.com/dfinity/ic	Open implementation of the protocol (codebase).
Tier‑1	https://github.com/dfinity/ic/releases	Code releases/changes (development life cycle).
Tier‑1	https://internetcomputer.org/roadmap/	Roadmap (development plans).
Tier‑1	https://internetcomputer.org/security-advisories	Security advisories (publication of vulnerabilities/security updates).
Tier‑1	https://dfinity.org/third-party-security-audits/	The existence of third-party security audits.
Tier‑1	https://dfinity.org/bug-bounty/	The existence of a bug bounty program.