Permissioned ledger
Internet Computer ticker ICP
Summary
The Internet Computer is a set of independent blockchains called subnets, each run by a fixed group of node machines (typically 13 to 40; the dashboard also lists a few 7-node subnets) that execute WebAssembly smart contracts called canisters. In each round a random beacon ranks a subnet's nodes and the node ranked first proposes a block, with others stepping in after timeouts; a block is notarized and then finalized once at least two-thirds of the subnet's nodes sign shares, assuming fewer than one-third are faulty. Each subnet holds a threshold BLS key, so its outputs can be checked against one network public key. The NNS, where ICP holders lock tokens in neurons to vote, admits node providers, assigns nodes to subnets and upgrades the protocol. Node machines do not post stake. 12414152529
Design
- System
- Permissioned ledgerMany subnet blockchains under one on-chain governance system, the Network Nervous System (NNS). Anyone can use it, deploy canisters or stake ICP to vote, but block production is gated: node providers join only by NNS vote with legal entity and jurisdiction recorded, and the node provider docs (May 2026) say no new node machines are being onboarded. The package table listed a permissionless layer 1; the permissioned class is used because consensus membership is gated, though admission is voted by ICP stakers rather than a company. Subnets are base protocol, not layer 2.
- Settlement family
- Its own design
- Scarce resource
- Other
- State model
- Accounts
- Finality
- Other
- Who makes blocks
- Node machines owned by node providers. A provider files a self-declaration and is accepted by NNS vote before buying hardware; its machines must then pass a validation procedure. NNS proposals also record each provider's legal entity and jurisdiction and assign nodes to subnets. Each round the random beacon puts the subnet's nodes in a random order: the node in first place (rank 0, which the documentation calls the lowest rank) is the primary block maker, and nodes further down the order step in after timeouts.
- Fork choice
- No weight-based fork choice. A block is final once at least two-thirds of the subnet's nodes sign finalization shares, and the protocol then guarantees no other notarized block exists in that round, so finalized blocks are not reorganized. The exception is governance: if a subnet stalls, an NNS proposal can install a recovery catch-up package to restart it.
Qualifications
- Block metrics · Partial. Each subnet produces its own blocks at its own pace; network-wide block or call counts are sums over dozens of independent subnets and do not describe any one chain.
- Validator decentralization · Contested. The project says nodes in a subnet are spread across data centers, operators and jurisdictions. Against that, node providers are admitted by governance vote with recorded legal identity, onboarding is closed, most application subnets have 13 nodes, and the dashboard's subnet list on the review date also included three 7-node application subnets, which tolerate at most two faulty nodes. Concentration was not measured here.
- Economic finality · Not applicable. Finality comes from threshold signatures of at least two-thirds of a subnet's nodes. Node machines do not post stake that could be slashed; providers are paid rewards and can be removed by governance. Finality is therefore recorded as another type rather than stake-backed.
- Subnets as layer 2 · Not applicable. Subnets are base-protocol chains run by NNS-assigned nodes under one network key, not layer-2 systems, so they are not listed as scaling layers.
- Cloud engine subnets · Unknown. DFINITY documents cloud engines: subnets an operator configures, choosing nodes from a marketplace and a replication level, running the same protocol. NNS governance releases in 2026 added proposal types that act on them (deleting a cloud engine subnet, setting the software version cloud engines run), so the NNS keeps some control, and the dashboard's node-provider records count cloud engines. Their full governance, node counts and live use were not verified, and network-wide totals appear to mix them with public subnets.
- Fees paid by users · Partial. Canisters pay for computation, storage and incoming messages with cycles, so calling an app is usually free for the user. Token ledgers still charge the sender a transfer fee, for example 0.0001 ICP on the ICP ledger.
- Evm compatibility · Not applicable. Canisters run WebAssembly, not the EVM. Canisters reach Ethereum through threshold signing and an RPC gateway canister, which does not make ICP an EVM chain.
- Settlement family · Partial. Recorded as other: the Internet Computer runs its own protocol, subnet blockchains of NNS-admitted node machines executing WebAssembly canisters, each subnet holding a threshold key under one network public key.
- Scarce resource · Partial. Recorded as other: consensus membership comes from node machines that node providers operate after admission by an NNS vote. Node machines do not post stake, and ICP holders lock tokens in neurons to vote in governance rather than to produce blocks.
- Finality · Partial. Recorded as other: a subnet block is final once at least two-thirds of the subnet's nodes sign finalization shares, and finalized blocks are not reorganized; the exception is a governance-installed recovery catch-up package after a stall.
Tradeoffs
- Emphasizes
- Scalability and Security
- Gives up
- Open participation and independent verification. Block-producing nodes are admitted by governance vote, must be specified data-center servers, and no new ones are being onboarded. Users cannot run their own copy of a subnet and instead trust threshold signatures from its nodes. Most applications run on 13-node subnets, which stay safe only while fewer than one-third of those nodes are faulty, and a stalled subnet is restarted by a governance vote.Scalability here means adding subnets that run in parallel; each subnet is still a single ordered chain. The security reading refers to fast deterministic finality and threshold keys under the per-subnet fault assumption. The project argues that spreading each subnet's nodes across providers, data centers and countries compensates for small subnets; that argument and the concentration of NNS voting power were not measured here.
- Full node at home
- Not applicable 5232425The reviewed documentation describes no role for an independent node that follows a subnet without being admitted to it. Every node is an NNS-approved machine; the current (Gen-2) hardware guide, dated May 2026, specifies two AMD EPYC server CPUs, 512 GB of RAM (16 x 32 GB) and five 6.4 TB NVMe drives with 10G networking, hosted in data centers, and older Gen-1 machines from before launch also remain. Users check results instead through certified responses signed by the subnet.
- Throughput claims
- Observed window: 25,621 1623Observed in the stated window only; not capacity.Update calls per second: state-changing messages to canisters across all subnets, not ledger transfers.All-time one-minute peak as of DFINITY's measurements dated 2025-07-01; the date of the peak itself is not stated.NNS-approved data-center node machines; the current Gen-2 specification is two server CPUs, 512 GB RAM and about 32 TB NVMe per node, and older Gen-1 machines also run.A sum over dozens of independent subnets; no single node processes this load, and each subnet has its own ceiling. A one-minute peak measured and published by DFINITY, not an independent observation or a sustained rate. An update call is not a token transfer; the mix of calls behind the peak is not described.
- Observed window: 1,076 16Observed in the stated window only; not capacity.Update calls per second, daily average across the whole network.Daily average in DFINITY's measurements dated 2025-07-01.A network-wide average over all subnets, published by DFINITY; the date is more than a year old at review time. Counts canister update calls, not user payments.
- Lab benchmark: 1,200 16Controlled benchmark; not observed network behavior.Sustained update calls per second on one 13-node test subnet running a counter canister with mainnet parameters.Synthetic benchmark dated June 2025.All 13 nodes in one data center.A trivial counter workload in a single data center; DFINITY states that the controlled setup explains lower latency than on mainnet. A second figure with tuned parameters (not mainnet settings) is higher and is not recorded as a network capability.
- Theoretical peak: 84,000 16Theoretical peak; not comparable across chains or with observed load.Update calls per second: DFINITY's extrapolation of a tuned single-subnet benchmark to 42 subnets.Extrapolation published with June 2025 benchmarks.Multiplies a lab result made with non-mainnet parameters by the subnet count; it was never observed. Assumes load spreads evenly across subnets and ignores calls between subnets, state growth and propagation over real network distances.
Scaling layers
No scaling layer recorded in this profile.
Capabilities
| Capability | How it is provided | Notes and sources |
|---|---|---|
| Account abstraction | Structured assessment pending | Not yet assessed for any chain. |
| Atomic swaps | Unknown | Not yet assessed under the current definitions; no hash- and time-locked swap standard was found for ICP ledgers. Calls between canisters are asynchronous and each canister's state is committed at every await, so a swap spanning several canisters is not all-or-nothing unless one escrow canister enforces it; exchanges use approvals (ICRC-2) and escrow canisters. 611 |
| Authenticated data publication | Unknown | Not yet assessed under the current definitions; canisters can commit a 32-byte value (usually a Merkle root) that the subnet signs each round with its threshold key (certified data), and clients verify served data, including web assets, against the network's single public key. The data is held in canister state, which this row does not count, and there is no built-in publish-and-subscribe layer. 57 |
| Light clients | Built into the protocolLimited scope | Certified responses: the subnet signs them with its threshold key, which consensus produces, and clients verify them against one network public key through a chain of subnet and NNS signatures, without downloading blocks. This trusts that at least two-thirds of the subnet's nodes signed honestly rather than re-executing anything. Scope is limited: uncertified query answers come from a single node. 45 |
| Native staking or delegation | Structured assessment pending | Not yet assessed for any chain. |
| On-chain governance | Structured assessment pending | Not yet assessed for any chain. |
| Parallel execution | Structured assessment pending | Not yet assessed for any chain. |
| Payment or state channels | Unknown | No payment or state channel layer anchored to the Internet Computer was found in the reviewed documentation. |
| Programmable spending | Native (protocol or core-team software) Earlier definition | Canisters are WebAssembly smart contracts with persistent memory; token ledgers are themselves canisters with approval-based spending (ICRC-2), and canisters can control Bitcoin, Ethereum and Solana addresses through threshold signatures. This is contract-controlled spending. 4611 |
| Protocol-verified messaging | Structured assessment pending | Not yet assessed for any chain. |
| Reversible transfers or recovery | Unknown | Not yet assessed under the current definitions; no protocol-level sender reclaim or cancellable delayed transfer, and no recovery-vault schedule, was found. Neurons lock ICP behind a dissolve delay for governance, which is a time lock rather than recovery, and ledger history is append-only. 1014 |
| Rollups | Unknown | The earlier note said absence was not exhaustively verified, so under the rule that absence needs a source this is unknown rather than not present. Earlier finding: no rollup settling to the Internet Computer was found; subnets and cloud engines run the base protocol itself and are not rollups. 226 |
| Shielded transfers | Structured assessment pending | Not yet assessed for any chain. |
| Signed partial offers | Unknown | Not yet assessed under this row's current definition. |
Reading these values
- How this feature is provided
- Built into the protocol, core-team software or independent software says where a feature lives and who can change it. These are implementation layers, not quality: core-team software is not closer to the protocol than independent software.
- Structured assessment pending
- The shared review has not assessed this feature for any chain yet (Account abstraction, Native staking or delegation, On-chain governance, Parallel execution, Protocol-verified messaging and Shielded transfers). That does not mean it is absent, and a chain’s profile may already describe it.
- Unknown
- The review has not established this for this chain under the current definition; the note beside it says why. Unknown is not absent and not a low score. A feature reads “Not present” only when a source shows it is absent.
- Earlier definition
- Payment or state channels, Programmable spending and Rollups keep the earlier definition until the next fact-check. There, “Native” does not separate the protocol from core-team software, “Ecosystem software” does not say who publishes it, and “Partial” does not say which layer.
- Reading across rows
- The list of capabilities is incomplete. Do not read these rows as a chain leading or lagging overall.
Ecosystem & custody
| Product type | Status | Notes and sources |
|---|---|---|
| Automated market makers | Established in the ecosystemICPSwap | ICPSwap's repository describes a concentrated-liquidity AMM running in canisters. DFINITY's MULTI/DEX (order book plus a vault-based market maker) currently trades only free dummy assets in a play phase, so it is not counted as a live venue. KongSwap's site could not be reached. Liquidity depth was not measured. 313233 |
| Issuer-native stablecoins | None found | Neither Circle's USDC list nor Tether's supported-protocol list includes the Internet Computer. ckUSDC and ckUSDT are chain-key tokens backed by USDC and USDT held on Ethereum by an NNS-controlled minter; they are counted under bridges, not as issuer-native stablecoins. 183435 |
| Algorithmic stablecoins | Unknown | Algorithmic, synthetic or hybrid dollar tokens on the Internet Computer were not reviewed. |
| Bridges | Native to the protocolckBTC (Bitcoin integration), ckETH and ckERC20 tokens such as ckUSDC and ckUSDT, ckSOL, ckDOGE | Chain-key tokens are ICRC ledgers backed 1:1 by assets that minter canisters hold at addresses controlled through threshold signatures. Bitcoin and Dogecoin data come from protocol adapters; Ethereum and Solana data come from several RPC providers queried through NNS-controlled gateway canisters. ckBTC minting waits for 4 Bitcoin confirmations. Risk: Backing depends on the signing subnet's threshold keys (production keys sit on the fiduciary subnet, listed with 34 nodes on the review date, with a backup copy on another subnet), on the NNS, which controls and can upgrade every minter and ledger canister, and on the data feeds, including third-party RPC providers for Ethereum and Solana. ckBTC deposits and withdrawal addresses are also screened against the US sanctions list by an NNS-controlled checker canister. A chain-key token is only as sound as all of these. 417181920212229 |
| Block explorers | First-partyICP Dashboard (DFINITY), IC Explorer | The ICP Dashboard shows subnets, nodes, canisters, transactions, proposals and tokens; IC Explorer describes itself as an Internet Computer block explorer, and its operator was not identified. Explorer data is provider-indexed; listing is not a quality check. 2830 |
| Hardware wallets | Established in the ecosystemLedger | See custody rows: Ledger lists ICP in its own wallet app and publishes an Internet Computer device app; Trezor lists ICP only as tokens on Ethereum and Base. 363738 |
Hardware-wallet custody
| Device maker | Status | What users can and cannot do |
|---|---|---|
| Ledger | Native supportSame as native: Yes | Can: Manage ICP in the Ledger Live app with each transaction validated on the Ledger device Can: Use the Internet Computer device app on Nano S Plus, Nano X, Flex, Stax and Apex PLower confidence: Ledger's own wallet code shows Internet Computer only when a feature switch is on, and whether Ledger has switched it on for all users could not be read. The native rating rests on Ledger's generic coin page saying ICP accounts can be added. The page does not say whether neuron staking or ICRC tokens such as ckBTC work in Ledger's own app. 363740 |
| Trezor | None foundSame as native: No | Cannot: Manage native Internet Computer accounts in Trezor Suite Cannot: Treat the ICP-labelled tokens Trezor lists on Ethereum and Base as native ICP custodyTrezor's Internet Computer page lists only Base and Ethereum as supported networks, alongside Trezor Suite, MetaMask and Rabby; it lists no Internet Computer network. Third-party signing paths for native ICP accounts were not checked. 3839 |
Public data
iKnow Blockchain has no public-data lookups for Internet Computer yet. This is a limit of the service, not a statement about the network.
| Lookup | Status | What it covers and its limits |
|---|---|---|
| Address or account | Not available yet | Public-data lookups for this chain are not built yet. |
| Tokens and assets | Not available yet | Public-data lookups for this chain are not built yet. |
| NFTs | Not available yet | Public-data lookups for this chain are not built yet. |
| Transactions | Not available yet | Public-data lookups for this chain are not built yet. |
Sourced developments
Developments: Review overdue Reviewed Sep 27, 2026; next review was due Oct 7, 2026, 12:00 UTC.
Publication date · newest first
-
Replica release of 18 September 2026 was elected on the fourth attempt, then deployed subnet by subnet
DFINITY published release-2026-09-18_03-28-base in the dfinity/ic repository on 18 September 2026. The GitHub release has no notes; the notes in the election proposal list mostly internal changes, such as nodes no longer gossiping HTTPS outcall responses that were already delivered, certification version V29, support for SEV firmware upgrades and a Rust compiler upgrade. Election proposals 144021, 144042 and 144043 were adopted but failed when executed, because the registry still referenced a version they tried to retire. Proposal 144044 elected the version on 22 September. Separate proposals then deployed it subnet by subnet, starting later that day, and on 24 September a proposal moved all cloud engines to it.
- Proposal:GuestOS election: 144021, 144042 and 144043 adopted but failed at execution; 144044 adopted and executed on 2026-09-22
- Implementation:built and tagged as release-2026-09-18_03-28-base (commit 2c2c7c9) in dfinity/ic
- Release:GitHub release published 2026-09-18; elected as a GuestOS version on 2026-09-22
- Activation:deployed by per-subnet proposals from 2026-09-22 and to all cloud engines on 2026-09-24; full subnet coverage not confirmed
Sources: DFINITY (GitHub) — Release release-2026-09-18_03-28-base · dfinity/ic (external site) · DFINITY (ICP Dashboard API) — NNS proposal 144044: Elect new IC/GuestOS revision (commit 2c2c7c9) (external site) · DFINITY release engineering (dfinity/dre) — fix(release-controller): derive the GuestOS retire list from the registry (external site) · DFINITY (ICP Dashboard API) — NNS proposal 144043: Elect new IC/GuestOS revision (commit 2c2c7c9) (external site) · DFINITY (ICP Dashboard API) — NNS proposal 144045: Update subnet io67a to replica version 2c2c7c9 (external site) · DFINITY (ICP Dashboard API) — NNS proposal 144115: Update 100% of Cloud Engines to replica version 2c2c7c9 (external site)
-
NNS governance release enabled Mission 70 changes to dissolve delays and voting rewards
DFINITY's NNS governance changelog records proposal 141441, which enabled the Mission 70 voting-reward changes: the maximum neuron dissolve delay fell from eight years to two (existing neurons were capped), neurons can vote with two weeks of dissolve delay instead of six months, the dissolve-delay bonus became quadratic with a three-times maximum, the voting-rewards pool was scaled down by about 36.71%, and neurons that had held the old eight-year maximum were given a 10% bonus.
- Proposal:NNS proposal 141441
- Implementation:implemented in the NNS governance canister
- Release:released per the changelog entry dated 2026-04-17
- Activation:reflected in current governance documentation
Sources: dfinity/ic maintainers — NNS governance changelog (external site) · Internet Computer Developer Docs (DFINITY) — Governance (external site)
-
DFINITY documented cloud engines, operator-configured subnets
An Internet Computer wiki article dated 15 April 2026 describes cloud engines: subnets an operator configures by choosing node providers from a marketplace, filtering by jurisdiction, hardware and uptime, and setting a replication level, while running the same protocol, canisters and cycles model as public subnets. The project home page now advertises configuring private cloud engine subnets.
- Implementation:documented by DFINITY; setup is directed to opencloud.org
- Release:not confirmed
- Activation:live use not verified
Sources: Internet Computer Wiki — Cloud engines (external site) · Internet Computer (internetcomputer.org) — Internet Computer (external site) · dfinity/ic maintainers — NNS governance changelog (external site)
-
Pakistan Digital Authority and DFINITY signed an MoU for a dedicated Pakistan subnet
DFINITY's media release says the Pakistan Digital Authority and the DFINITY Foundation signed a memorandum of understanding covering a dedicated Pakistan subnet described as a sovereign cloud, a national messenger app being piloted, 1,500 Caffeine licences and a local DFINITY presence.
- Proposal:memorandum of understanding
- Implementation:not verified
- Release:Planned
- Activation:no evidence of an active Pakistan subnet in this review
Sources: Internet Computer (internetcomputer.org) — Pakistan Digital Authority and DFINITY partner on sovereign cloud infrastructure (external site) · Internet Computer (internetcomputer.org) — Media releases (external site)
-
DFINITY opened Caffeine, an AI app builder that deploys to ICP, as a public beta
The Internet Computer history page records that the beta of Caffeine, a platform for building apps by chatting with an AI, was made publicly available at caffeine.ai on 15 October 2025; the project's Caffeine page presents the launch as DFINITY's. Caffeine writes a Motoko backend and deploys it as canisters on the Internet Computer.
- Implementation:product launched by DFINITY
- Release:public beta
- Activation:not a protocol change
Sources: Internet Computer (internetcomputer.org) — Network history (external site) · Internet Computer (internetcomputer.org) — Caffeine ecosystem spotlight (external site) · Caffeine — Caffeine - The AIware Generator (external site)
Topics your AI can explain
Your AI can explain these topics for Internet Computer through the connection, with sources.
Known gaps
What this profile's review did not establish:
- Current counts of nodes, subnets and node providers were not reconciled: on the review date the public dashboard API reported 618 nodes and 67 subnets in total, while its subnet list returned 42 subnets and its per-provider node totals add up to more than 618. The difference appears to come from cloud engine subnets but was not confirmed.
- Concentration of NNS voting power, and how much of it follows a few neurons, was not measured.
- The fiduciary subnet's size was read from the dashboard API on one day only; DFINITY's documentation says only that production signing keys run on subnets of 34 or more nodes.
- How often subnets have stalled and been restarted by governance was not reviewed.
- The full governance, minimum node counts and live use of cloud engine subnets were not verified; the NNS changelog shows proposal types that act on them.
- DFINITY's documentation disagrees with itself on two points: its governance page says two weeks of dissolve delay suffice to submit proposals while the governance changelog sets a fixed six months, and its ledger overview says ICP transfer fees go to an NNS fee account while its economics page says they are burned. This profile and the pack follow the changelog and the economics page.
- Launch dates of ckSOL and ckDOGE were not verified; the documentation lists mainnet canister IDs for both.
- KongSwap's site could not be reached, and AMM liquidity depth was not measured.
- Algorithmic or synthetic dollar tokens, atomic-swap mechanisms and channel layers were not found or not reviewed.
- The issuer or bridge behind the ICP-labelled tokens Trezor lists on Ethereum and Base was not traced.
- Ledger support for neuron staking and ICRC tokens such as ckBTC was not confirmed, and neuron management with a Ledger device through DFINITY's governance app was not verified.
- Ledger's remote feature-switch settings and support articles could not be read; if the Internet Computer switch turns out to be off for ordinary users, the Ledger row should drop to partial.
- All throughput figures come from DFINITY's own page and date from mid-2025; the dashboard's figure described as Ethereum-equivalent transactions was not used because its method was not reviewed.
Sources
Oldest dated source check: Source checked Sep 27, 2026 Next check due Oct 27, 2026.
- Consensus (external site)
- Network overview (external site)
- Subnet types (external site)
- Chain-key cryptography (external site)
- Certified data (external site)
- Canisters (external site)
- Edge infrastructure (external site)
- Cycles (external site)
- Cycle costs (external site)
- Ledgers (external site)
- Working with ledgers (external site)
- ICP ledger Candid interface (ledger.did) (external site)
- Network economics (external site)
- Governance (external site)
- NNS proposal types (external site)
- Performance (external site)
- Chain-key tokens (external site)
- Chain-key canister IDs (external site)
- Bitcoin integration (external site)
- Ethereum integration (external site)
- Solana integration (external site)
- Dogecoin integration (external site)
- Node hardware guide (external site)
- Data center and ISP guide (external site)
- Node provider documentation (external site)
- Cloud engines (external site)
- NNS governance changelog (external site)
- ICP Dashboard (external site)
- ICP Dashboard API: subnets (external site)
- IC Explorer - Internet Computer Block Explorer (external site)
- icpswap-v3-service (external site)
- MULTI/DEX ecosystem spotlight (external site)
- MULTI/DEX: Multi-Chain Decentralized Exchange (external site)
- USDC contract addresses (external site)
- Supported protocols (external site)
- ICP wallet (external site)
- Internet Computer app for Ledger devices (external site)
- Safe & secure Internet Computer wallet (external site)
- Supported coins and assets (external site)
- Ledger Wallet currencies gated by feature switches (useCurrenciesUnderFeatureFlag.ts, develop branch) (external site)
Report an error
Found something wrong or out of date? Reporting is free, and every chain goes through the same process. Published corrections appear in the public log.
Funding disclosure
Funding disclosures appear here when an upkeep arrangement exists, in the form “Upkeep funded by [name]; verdicts unaffected.” The funder ledger has not been published yet. Neutrality & funding