Overview

The Internet Computer Blockchain (ICP) is a blockchain technology developed by the DFINITY Foundation. It can power Web2 and Web3 services without having to rely on any source of traditional IT infrastructure or cloud computing services.

The Internet Computer is a general-purpose blockchain that hosts canister smart contracts. It is designed to provide a World Computer that can replace traditional IT infrastructure and make it possible for Web3 applications to run entirely in the blockchain.

By design, ICP’s blockchain can also enable its host smart contracts to directly initiate transactions on other chains, effectively enabling the full end-to-end decentralization of online web services.

ICP is at the forefront of the AI agent economy, where AI-powered smart contracts can self-execute, manage assets, and participate in DAOs without human intervention, positioning the Internet Computer as a blockchain for AI-driven applications, decentralized automation, and next-generation Web3 services.

 

ICP hosts a wide range of projects tackling multiple verticals, from DeFi (with decentralized exchanges like Sonic, InifinitySwap, and ICPSwap), AI (with DecideAI and Kinic) to NFT (with marketplace like ORIGYN, which reached a valuation of $300M following an investment round by Paris Hilton and Bill Ackman among others), Games (like MetaSports Basketball), Metaverse (like PokedStudios or IC Gallery), and Social Media (like OpenChat, Distrikt, Dmail, or DSocial).

ICP – A Complete Technology Stack

In addition to providing support for AI and smart contracts, the Internet Computer is designed to act as a complete technology stack, such that full-fledged systems and services can be built that run entirely on it.

• ICP smart contracts can handle end-user HTTP requests, making it possible to create interactive web experiences without requiring third-party cloud hosting or private servers.
• ICP offers a true end-to-end experience by hosting systems and services entirely on the blockchain, providing all the benefits of smart contracts in a decentralized manner.
• Accessing ICP-based services is transparent for end-users, offering improved personal data security compared to public or private cloud services.
• ICP reduces costs for developers, as well as the risks and complexities associated with traditional application development and deployment of microservices.
• ICP provides an alternative to monopolies and oligopolies driven by large technology companies that have a lot of control over the Internet, promoting a more decentralized environment..
• ICP enables onchain autonomous AI agents that can transact, govern, and engage in DeFi without human intervention, reducing the techincal barrier for AI-powered dApps.
• ICP’s secure protocol ensures reliable message delivery, transparent accountability, and resilience, eliminating the need for firewalls, backup facilities, load balancing services, or failover orchestration.
• ICP supports interoperability, shared functions, permanent APIs, and ownerless applications.

The IC Network

The Internet Computer is a network of interacting replicated state machines. A state machine is a computational model that maintains a state in the form of memory or other forms of data storage. The execution of the state machine takes place in discrete rounds. In each round, the machine takes an input, applies a state transition function to the input and the current states, and obtains an output and a new state. This new state then becomes the current state in the next round. 

The state transition function of the Internet Computer is a universal function, meaning that some of the inputs and data stored in the state may be arbitrary programs that act on other inputs and data. As a result, a general (i.e. Turing complete) model of computation is produced.

The concept of replication makes it possible to achieve fault tolerance. A replicated state machine can be obtained by comprising a subnet of replicas, each of which will be running a  copy of the same state machine. This way, a subnet should be able to continue to function correctly even if some replicas are faulty.

Protocol Architecture

Canisters – ICP Smart Contracts

A smart contract on ICP is called canister smart contract, or just canister. Canisters are computational units that combine both code and data. Canisters can contain any arbitrary code or data, from serving web pages to creating a secure messaging app or implementing a decentralized token exchange.

Traditional blockchains like Ethereum suffer from limitations such as high transaction and storage costs, slow computational speed, and the inability to serve frontend interfaces to end users. Consequently, dApps on such blockchains are not fully decentralized, but rather follow a hybrid model where most of the application components, like the frontend, are hosted on traditional servers or cloud infrastructure that supports the overall functionality of the application. This comes at the expense of being at the mercy of cloud providers, and being vulnerable to many single points of failure.

The Internet Computer was built as a new platform that would support smart contracts that meet all the properties listed above and that, in addition to that, would also allow for composability and the tokenization of assets in the form of digital tokens. This means that canisters should be able to interact with each other in a cost-effective, and scalable manner (with higher throughput and lower latency than traditional blockchains). These properties make it possible for the Internet Computer to process unbounded volumes of smart contract data and computation natively, while keeping on growing in capacity by adding more nodes to the network. Canisters are smart contracts that run on specific subnets, which are groups of nodes responsible for maintaining the state and execution of those canisters​.

A canister bundles WebAssembly (Wasm) program code and data storage into a single unit. Anyone can deploy a canister on the Internet Computer. Canisters are stored and their code executed in a replicated, fault-tolerant manner on multiple machines, that is, the nodes of a subnet. Unlike other blockchains, a smart contract on ICP can respect one of several possible mutability policies:

• Completely Immutable (cannot be changed by anyone)
• Unilaterally Mutable (can be changed unilaterally by the dApp developer), or
• DAO Mutable (it can be changed as authorized by a decentralized autonomous organization).

Canisters are smart contracts that scale interoperable compute units. In other words,  a dApp built on the Internet Computer can be composed of one or more canisters, and some of the dApp’s canisters may even provide web interfaces that end-users can access through their browser. They are composable (can interact with one another) and support tokenization, meaning that they can use and trade digital tokens.

In most blockchains, to verify the current state of smart contracts, the entire transaction history must be replayed from the genesis block. This process can be time-consuming and resource-intensive, especially as the blockchain grows in size. On the other hand, the Internet Computer uses a more efficient approach to verification, allowing artifacts certified by smart contracts to be verified using a single 48-byte public key for the entire network.

Subnets

A subnet is a collection of nodes that run their own instance of the Internet Computer Protocol’s consensus algorithm, essentially running their own blockchain. Each subnet consists of node machines, or nodes, which are used to host canister smart contracts. Each canister’s code, along with its state and computation, is replicated across every node on the subnet.

For a subnet to function effectively, it is crucial that every replica processes the same inputs in the same sequence. The replica is a collection of protocol components that are necessary for a node to participate in a subnet. To achieve consistency, replicas within a subnet must use a consensus protocol. As a result, the internal state of each replica evolves in the same manner over time, and every replica generates the same series of outputs.

It’s worth noting that inputs to a replicated state machine on the Internet Computer could come either from external users or from outputs generated by another replicated state machine. Similarly, outputs from a replicated state machine may be directed to external users or used as inputs for another replicated state machine.

Asynchronous Messaging

Canisters in the Internet Computer (ICP) encapsulate both code and data, ensuring their state is isolated from others. Users interact with canisters through ingress messages (requests sent by users to canisters to initiate operations or retrieve data) and canisters can communicate with one another by sending messages to other canisters, whether they reside on the same or different subnets. These interactions are referred to as canister messages and are asynchronous, meaning the sender is not blocked while waiting for a response and can continue other operations.

This asynchronous messaging and isolated state lead to a “loose coupling” between canisters and subnets, which is crucial for the scalability of the ICP. Unlike most blockchains, where smart contract calls are synchronous and result in a global state, the ICP’s asynchronous approach allows canisters to operate concurrently across subnets. This principle, along with secure cross-subnet messaging (XNet), enables the ICP to scale effectively by adding new subnets. Thus, asynchronous communication in ICP is a significant departure from traditional blockchains but is essential for achieving high scalability.

Deterministic Decentralization

Blockchain infrastructure layers are frequently very centralized, with a few firms or governments controlling a large percentage of the network. Empirical investigations of other blockchains, such as Bitcoin and Ethereum, reveal that permissionless node operation commonly leads to centralized concentration among a few major participants. These networks face issues such as limited scalability when adding nodes, variable node availability due to market swings, and inefficient computation resources required for tasks such as proof-of-work puzzles.

To maintain the decentralization and diversity of each subnet, the protocol uses a meticulous approach to ensure that every layer of the ICP infrastructure is decentralized. This involves measuring and maximizing the number of 1) Number of unique node providers, 2) Number of unique data centers and 3) Number of unique jurisdictions. This concept is known as deterministic decentralization.

Chain-key Cryptography

The Internet Computer’s consensus protocol does rely on a blockchain but also uses public-key cryptography and digital signatures. The NNS keeps track of a registry that is used to bind public keys to replicas and subnets as a whole. This introduces the concept of chain-key cryptography, which has the following components to it:

• Threshold signatures enable subnets to use public keys with corresponding secret signing keys that are split into shares. These shares are distributed among all replicas within a subnet. This approach ensures that corrupt replicas cannot forge signatures, while honest replicas can generate signatures in line with the policies and protocols of the Internet Computer (IC).
  • Outputs from one subnet can be verified by another subnet or external user by simply validating a digital signature against the public signature verification key of the first subnet.
  • The public signature-verification key for a subnet can be obtained from the Network Nervous System (NNS) and remains constant throughout the subnet’s lifetime, even as its membership changes.
  • Threshold signatures have multiple applications within the Internet Computer, such as providing each replica in a subnet with access to unpredictable pseudo-random bits derived from the signatures. This forms the basis for the Random Beacon used in consensus and the Random Tape used in execution.
  • The Internet Computer uses a distributed key generation (DKG) protocol to securely deploy threshold signatures. This protocol constructs a public signature-verification key and provides each replica with a share of the corresponding secret signing key, operating within the system’s fault and communication model.

Data Centers

A data center (DC) is a physical site that hosts nodes which contribute to the Internet Computer. It includes the hardware and software infrastructure required for node deployment. Data centers are nodes that are selected and vetted by the NNS. To provide a truly decentralized blockchain that can withstand potential service disruptions, the physical node machines that make up any given blockchain subnet are distributed across data centers in diverse geographical locations. The node machines located in data centers around the globe that make up the Internet Computer are organized into subnet blockchains that in turn connect to each other using Chain Key cryptography.

Chain-Evolution Technology

This refers to specific cryptography-based mechanisms that enable the IC to operate in the long term. It helps to maintain the blockchain-based replicated state secure at all times. This is achieved by leveraging the following features:

• • Garbage Collection: At the end of each epoch, processed inputs and consensus-level protocol messages can be safely purged from each replica’s memory, preventing unbounded storage requirements. This differs from most other blockchains,  which require storing the entire blockchain from the Genesis block.
  • Fast Forwarding: If a replica falls far behind its peers or a new replica is added to a subnet, it can be fast-forwarded to the beginning of the most recent epoch without running the consensus protocol or processing all inputs up to that point. This contrasts with most other chains since they require processing the entire blockchain from the genesis block.

• Subnet membership changes are enabled by the Network Nervous System (NNS) at epoch boundaries and must be done carefully to ensure consistent and correct behavior.
• Pro-active resharing of secrets occurs at the beginning of each epoch when the secret shares used in threshold signatures are proactively reshared in order to achieve the following two goals:
  • Ensure that new members have an appropriate share of the secret while replicas no longer in the subnet lose their share.
  • Protect against an attacker gaining any advantage, even if a small number of shares are leaked in one or multiple epochs.
• Protocol Upgrades: When the Internet Computer protocol needs to be upgraded, to fix bugs or add new features, this can be done automatically using a special protocol at the beginning of an epoch.

Chain-key cryptography is what makes it possible for smart contracts hosted on the Internet Computer to directly interact with other blockchains, without need for centrally-controlled bridges or wrapping assets. This property allows blockchains to create public “chain keys” that their nodes can use to create corresponding signatures. Recent advancements have made it possible to create ECDSA chain keys, which is the signature scheme used by most other blockchains. As a result, the Internet Computer can create transactions (TX) on other blockchains.

Network Nervous System – NNS

The Internet Computer is different from other blockchains in that it can host an advanced DAO within its protocol, the Network Nervous System. The Network Nervous System (NNS) is an algorithmic governance system responsible for controlling the Internet Computer. This provides the community with direct control over network governance and makes it possible to upgrade the protocol without requiring a network fork. The network’s utility token is the $ICP token. It is implemented as a set of canisters on a special system subnet, which is similar to other subnets but configured differently.

Cycles are the internal currency used to pay for computation and storage on the Internet Computer.

Canisters on the system subnet are not charged for the cycles they consume. Some of the most relevant canisters on the NNS are:

• Registry Canister – Stores the configuration of the IC, such as the replicas belonging to each subnet, the public keys associated with subnets and individual replicas, and other related information.
• Governance Canister – Manages decision-making and voting processes that determine how the Internet Computer should evolve.
• Ledger Canister – Keeps track of users’ ICP utility token accounts and manages transactions between them to ensure that token transfers are recorded accurately and securely.

This DAO-controlled network allows the Internet Computer to achieve the practical benefits of a permissioned network in terms of more efficient consensus while maintaining the benefits of a decentralized network with governance controlled by a DAO. Moreover, replicas running the protocol are hosted on servers in geographically distributed, independently operated data centers.

Execution Models

ICP’s execution models revolve around the concept of canisters, which are basic computational units on the Internet Computer. Canisters are similar to processes, as they contain both a program and its state that evolves over time. Key aspects of ICP’s execution models include:

• Canister programs are encoded in WebAssembly (Wasm), a binary instruction format for a stack-based virtual machine. Wasm is an open standard designed for high-performance applications on web pages, but it is also suitable for general-purpose computation.
• The Internet Computer provides a runtime environment for executing Wasm programs in canisters, enabling them to communicate with other canisters and external users through message passing.
• Motoko is used as a programming language specifically designed for the Internet Computer. It is a strongly-typed, actor-based language with built-in support for asynchronous message passing. It also includes productivity and safety features such as automatic memory management, generics, type inference, pattern matching, and various arithmetic capabilities.
• The Internet Computer uses Candid, a messaging interface definition language and wire format that allows for typed, high-level, and cross-language interoperability. This makes it possible for canisters written in different high-level languages to seamlessly communicate with one another.
• To support canister development in various programming languages, ICP uses a Wasm compiler and runtime support, in addition to Motoko. Currently, ICP provides support for Rust in addition to Motoko.

Canisters on the Internet Computer are subject to certain limitations due to the underlying technology, such as WebAssembly, which imposes a maximum memory size of 4GB. To overcome these limitations and build scalable internet services that can cater to billions of users, developers need to employ multi-canister architectures.

In a multi-canister architecture, the application’s functionality and data storage are distributed across multiple canisters, which work together to provide the required performance and capacity. This approach allows applications to scale horizontally, as developers can add more canisters to the system as the demand for resources increases.

Boundary Nodes

Boundary nodes are the gateway to the Internet Computer, which allow users to seamlessly access the canister smart contracts. They provide the network edge services for the Internet Computer. They are responsible for ensuring that the interaction between the Internet Computer and legacy clients (such as web browsers) is done in a seamless manner.  Boundary nodes also help safeguard the Internet Computer from potential DoS attacks, ensuring the network remains functional and secure. This is achieved by translating standard HTTPS requests from users into ingress messages for canisters. Additionally, boundary nodes also provide services such as caching, load balancing, and rate limiting.

When a client attempts to connect with a canister, it first looks up the corresponding DNS record for the canister’s URL on the ic0.app domain. The client then sends an HTTPS request to the IP address of a boundary node, which returns a JavaScript-based service worker for execution in the legacy client. All subsequent interactions between the legacy client and the boundary node occur via this service worker, which is responsible for authenticating responses from the Internet Computer using chain-key cryptography.

Boundary nodes also maintain a list of responsive replicas and randomly select one for routing. This allows them to route requests to replicas on the subnet hosting the specified canister. Besides, all communication between legacy clients, boundary nodes, and replicas is secured via TLS.

The Solenoid Upgrade

The Solenoid Upgrade introduced a fully decentralized infrastructure to replace centralized boundary nodes initially operated by the DFINITY Foundation. This enhancement strengthens the security, performance, and censorship resistance of the ICP network by decentralizing the way users and applications interact with the blockchain.

The boundary node, once a single entity in the old edge architecture, has now been split into two distinct components–the API boundary node and the HTTP gateway–each taking on different tasks:

• API Boundary Nodes, which serve as the public edge of the Internet Computer and expose the IC API endpoints.
• HTTP Gateways, which act as a translation layer for HTTP requests, sitting on top of the API boundary nodes and enabling browser access to canisters.

Key Features:

• Decentralized API Boundary Nodes: The upgrade replaces centralized boundary nodes with a network of distributed API nodes, reducing reliance on single points of failure and enhancing fault tolerance.
• Censorship Resistance: With no centralized entities controlling traffic, developers and users benefit from unrestricted access to the network, reinforcing ICP’s vision of an open and permissionless blockchain.
• Improved Security & Performance: Solenoid enhances speed and resilience, ensuring that smart contracts and dApps maintain low-latency interactions while remaining highly available.
• Direct Developer Access: Developers can now bypass traditional HTTP gateways, enabling more efficient and secure interactions with ICP’s on-chain services.

The Core IC Protocol

The Internet Computer consists of 4 layers: peer-to-peer layer, consensus layer, message routing layer, and the execution layer.

Peer-to-Peer Layer

The peer-to-peer (P2P) layer is responsible for the reliable and secure communication of network messages, known as artifacts, between nodes in a subnet. These artifacts include user-submitted inputs to canisters and protocol-originating messages like blocks produced by the consensus layer. The P2P layer guarantees the secure eventual broadcast of artifacts to all nodes required to make progress, serving as the communication fabric for the ICP protocol stack. The consensus layer, which operates above the P2P layer, relies on it to broadcast artifacts across subnet nodes.

The P2P layer allows for the prioritization of certain artifacts to ensure that more critical ones are broadcasted more quickly. This prioritization prevents less important traffic from consuming all network bandwidth, ensuring continuous protocol progress.

Gossip Protocol

The P2P layer utilizes a gossip protocol, where each node in the subnet is connected to a subset of other nodes (its peers). When a node receives or generates an artifact, it gossips this artifact to all its peers. This method ensures that every artifact eventually propagates throughout the subnet, despite connectivity issues or malicious nodes.

Consensus Layer

The primary objective of the consensus layer is to produce blocks agreed upon by the subnet’s nodes, resulting in an ordered sequence of messages to be executed.

The consensus layer is designed to achieve:

• Low Latency: Near-instant finality of transactions.
• High Throughput: Efficient processing of numerous transactions.
• Robustness: The ability to maintain performance despite node or network failures.

The consensus layer assumes an asynchronous network where the time for message delivery is unpredictable. This is essential for a decentralized and globally distributed network. Despite the asynchronous nature, the protocol ensures correctness as long as less than one-third of the nodes are faulty.

Consensus Mechanism

1. Block Making:
   • A block maker, selected through a random beacon mechanism, proposes a block for the round.

If the primary block maker is slow or faulty, other nodes can step in to propose a block.

1. Notarization:

• • Nodes validate and notarize blocks by broadcasting notarization shares.
  • A block is notarized when at least two-thirds of the nodes support it.

 

3. Finalization:

• • Finalization requires at least two-thirds of the nodes’ support.
  • Once a block is finalized, all its ancestor blocks in the tree are implicitly finalized.

Block Tree and Finalized Path

• The protocol maintains a tree of notarized blocks, with a unique chain of finalized blocks.
• In each round, blocks are added to this tree, and the protocol ensures that there is always a path of finalized blocks that all honest replicas agree on.

Handling Faulty Nodes and Network Delays

• The protocol can progress even with faulty nodes or network delays, ensuring that a block is eventually notarized and finalized.
• The random beacon mechanism ensures the selection of block makers in a fair and unpredictable manner.

Message Routing Layer

Through Message routing, the Internet Computer blockchain enables users to send messages to canister smart contracts and canisters to send messages between themselves. For scalability, the Internet Computer is composed of many subnet blockchains and the Internet Computer’s Network Nervous System can add new subnets as required. The message routing component routes messages to and from canisters across all of the Internet Computer’s subnet blockchains and ensures that new subnets can be added seamlessly.

Message routing is the lower of the two upper layers of the protocol stack. It implements functionality that is crucial for the operation of the IC. Its responsibilities can be roughly grouped as follows:

• Induction of messages received in blocks from consensus;
• Invocation of the execution layer after successful induction;
• Routing of inter-canister messages resulting from execution within and between subnets;
• Certification of the state of the subnet;
• Synchronization of the state of the subnet to newly joining and fallen behind nodes.

Although the message routing layer derives its name from the functionality of routing messages, all the functionality listed above is equally important for the IC. Particularly, state certification and synchronization are heavily used in chain-evolution technology to enable resumption of nodes.

Message Processing

Consensus and Block Finalization

The message processing begins when consensus produces a finalized block of messages. A block becomes finalized when it has been validated (notarized) and approved by at least two-thirds of the subnet’s nodes. This finalized block is then handed over to the message routing layer.

Message Routing

Upon receiving a finalized block, the message routing layer extracts the messages from the block. These messages consist of:

• Ingress Messages: Submitted by external users.
• XNet Messages: Sent between canisters, possibly across different subnets.

Induction

After extraction, each message is placed into the input queue of its target canister. This process is called induction, and all the queues together form the induction pool.

Execution

Once induction is complete, the execution layer is triggered. The execution layer, the topmost layer of the ICP protocol stack, schedules and processes messages in the induction pool. This execution occurs within a sandbox environment, a virtual machine that ensures the deterministic execution of canister messages.

Deterministic State Modification

Message routing and execution modify the subnet state in a deterministic manner. This means that the state of every (honest) node in the subnet is changed identically, ensuring the properties of a replicated state machine. During execution:

• Messages can modify the memory pages of the target canister.
• Execution can generate new messages for other canisters.

Local and Cross-Subnet Messaging

• Local Subnet: If a new message is targeted at a canister within the same subnet, it is directly placed into the input queue of the target canister.
• Cross-Subnet (XNet): If the message targets a canister on a different subnet, it is placed into the XNet stream for the target subnet. These streams are later picked up by block makers of the target subnets once certified.

The consensus layer is decoupled from the message routing and execution layers, meaning any forks in the consensus blockchain are resolved before their payloads are passed to message routing.

Inter-Canister Messaging

Inter-canister messaging involves communication between canisters, which can be within the same subnet (intra-subnet) or across different subnets (inter-subnet).

	Intra-Subnet Inter-Canister Messaging	Inter-Subnet Inter-Canister Messaging
Consensus Requirement	Not required	Required for message inclusion in receiving subnet’s block
Message Routing	Directly placed in target canister’s input queue	Routed into outgoing subnet streams and certified
Execution Semantics	Asynchronous	Asynchronous
Deterministic Execution	Yes	Yes
Cycles Limit Handling	Stops execution when limit is reached; resumes later	N/A
Certification Method	N/A	Merkle-tree data structure and BLS threshold cryptography
Transmission Handling	Handled within the same subnet	Routed and validated across different subnets
Processing Upon Receipt	Scheduled for execution in target canister	Included in consensus block and then scheduled for execution

State Certification

State certification ensures the integrity and security of the replicated state across subnets, facilitating secure communication and reliable operation. They consist of:

1. Replicated State:
   • The replicated state includes all necessary information for the operation of a subnet.
   • It consists of responses to ingress messages, XNet messages for other subnets, and canister metadata (such as module hashes and certified variables).
2. Certification Methods:
   • Per Round: Specific items like responses to ingress messages, XNet messages, and canister metadata are certified every round.
   • Per Checkpoint: The entire replicated state of the subnet is certified periodically to ensure consistency and integrity.
3. Certification Technique:
   • Certification is performed using BLS (Boneh-Lynn-Shacham) threshold signatures.
   • These signatures are computed collectively by the subnet nodes, ensuring decentralized and secure certification.
   • The threshold signature mechanism guarantees that certification can only occur if the majority of the subnet nodes agree on the state.

State Synchronization

This ensures nodes can join or rejoin the network efficiently without having to process all historical blocks from Genesis. At regular intervals, the entire state of a subnet is certified using BLS threshold signatures on a Merkle-tree-like structure called the manifest. This certified state is included in a “catch-up package,” which can be used by nodes to synchronize their state. A catch-up package allows new or rejoining nodes to download the latest state without replaying all historical blocks. These nodes validate the package using the subnet’s public key and then download the corresponding state.

The state is then transferred in chunks from multiple peers using the P2P layer’s artifact transfer protocol, similar to Bittorrent. Each chunk is individually authenticated using the Merkle-tree structure, ensuring data integrity. Nodes that are rejoining can use their last checkpoint to only download the new chunks, reducing the data transfer volume. The Merkle-tree structure helps in computing the differences between the current state and the checkpoint, facilitating efficient synchronization. Once the full state is downloaded, nodes catch up by processing all blocks generated since the checkpoint. This involves executing the blocks to update the local state incrementally to the current state of the subnet.

Execution Layer

The execution layer is the topmost layer of the IC core protocol stack. It deterministically schedules and executes the messages that have been agreed on by consensus and inducted into the canister queues by message routing, thereby changing the state of the subnet in a deterministic manner on all the nodes. The execution of the same sequence of messages on every node of the subnet guarantees that the same ending state is obtained on each node of the subnet after completion of the round.

A canister smart contract on the IC consists of a Web Assembly (Wasm) bytecode representing the smart contract program and a set of memory pages representing its state. The Wasm bytecode can be modified by installing or updating the canister. The smart contract state gets modified when executing messages on the canister smart contract. Both the bytecode and the memory pages, i.e., the state of the canister, are maintained by every node machine of the subnet the canister is installed on. Each node in the subnet holding the same canister state and ensuring that the state transitions in the same way on every node in every round is the foundation of realizing a replicated state machine and the security and resilience properties thereof that make blockchains so unique.

Message Execution

Replicated Message Execution

Replicated execution proceeds in rounds where the message routing layer invokes the execution layer to process messages in the canister input queues. The execution of messages modifies the canister state, creates new inter-canister messages, or generates responses to ingress messages. These changes are tracked to ensure consistent state transitions across all nodes. New local inter-canister messages are directly queued and executed without requiring consensus, as their creation is deterministic.

Messages targeting other subnets are placed in the XNet queue and certified at the end of the round, ensuring secure cross-subnet communication.

Deterministic Time Slicing

• Concept: This technique allows longer tasks to be paused at the end of a round and resumed in the next, ensuring that tasks spanning multiple rounds do not slow down block creation.
• Instruction Limits: The ICP can handle tasks requiring up to 20 billion instructions, with special tasks like code installation accommodating up to 200 billion instructions.

Cycles Accounting

• Resource Consumption: The execution of a canister consumes cycles, with each canister holding a local cycles account. This model, known as the reverse gas model, facilitates mass adoption by having canisters, rather than users, pay for message execution.
• Determinism: The Wasm code is instrumented to count executed instructions, allowing deterministic cycles charging and maintaining the replicated state machine properties.

The execution layer is responsible for managing canister bytecode and state. Memory pages are persisted to SSD, ensuring orthogonal persistence without developer intervention.

The execution layer uses a decentralized pseudorandom number generator called the random tape, built using chain-key cryptography. Each subnet has access to a distributed pseudorandom generator (PRG), which generates pseudorandom bits from a seed, a threshold signature called the Random Tape. There is a different Random Tape for each round of the consensus protocol. The basic properties of the random tape are:

1. Unpredictability: Before a block at height h is finalized by any honest replica, the Random Tape at height h + 1 is guaranteed to be unpredictable.
2. Timeliness: By the time a block at height h + 1 is finalized by any honest replica, that replica will typically have all the shares it needs to construct the Random Tape at height h + 1.

To obtain pseudorandom bits, a subnet makes a request through a “system call” from the execution layer in a round, say h. The system responds to the request later, using the Random Tape at height h + 1. Due to property (1), the requested pseudorandom bits are guaranteed to be unpredictable when the request is made.

Consensus delivers both the Random Tape and payload at h + 1 to the message routing simultaneously. According to property (2), this typically does not incur any additional delay.

Putting It All Together

Flow of User Requests on The Internet Computer

The flow of user requests on the Internet Computer can be divided into two categories: Query calls and Update calls.

Query Call

1. A user’s query call (M) is sent to a canister (C) via a boundary node.
2. The boundary node forwards M to a replica on the subnet hosting C.
3. The replica computes the response and sends it back to the user via the boundary node.

Update Call

1. The user’s request (M) is sent to a canister (C) via a boundary node.
2. The boundary node forwards M to a replica on the subnet hosting C.
3. The replica broadcasts M to all other replicas on the subnet using the peer-to-peer layer.
4. The leader for the next consensus round bundles M with other inputs to form the payload for a block (B).
5. Block B is finalized, and its payload is sent to the message routing layer for processing.
6. The message routing layer places M in the input queue of canister C.
7. The execution layer processes M, updating the internal state of C.

If a response (R) to M can be immediately computed, it is placed in the ingress history data structure. Otherwise, if processing M requires a request (M0) to another canister (C0) on a different subnet, the following steps occur:

1. M0 is placed in the output queue of C.
2. Message routing moves M0 into a cross-subnet stream, eventually transporting it to the subnet hosting C0.
3. M0 passes through consensus and message routing on the second subnet and is processed by the execution layer.
4. The execution layer updates the state of C0 and generates a response (R0) to M0.
5. R0 goes to the output queue of C0 and is transported back to the first subnet.
6. On the first subnet, R0 passes through consensus and message routing, and the execution layer updates the internal state of C.
7. The response (R) to the original request (M) is recorded in the ingress history data structure.

Finally, the user’s client performs a “query call” to obtain the response (R), which is authenticated via chain-key cryptography (using a threshold signature). The authentication logic is performed by the client using the service worker obtained from the boundary node.

Although there’s only a single thread of execution inside a canister, cross-canister update calls can be interleaved by default. That occurs when update calls make cross-canister update calls, which block, allowing the thread of execution to be moved to a new update call.

Converting $ICP to Cycles for Computational Power

In the Internet Computer, it is developers, not end users, who pay network fees. Developers prepay for the computational units they anticipate their application will use by converting $ICP to Cycles, then paying for the computational units with the latter.

Gas Model

ICP tokens can be converted into cycles, which are used to power computation, communication, and storage costs for canisters (smart contracts) on the Internet Computer.

The Internet Computer utilizes a “reverse gas” model where canisters are pre-charged with cycles to cover their computation costs. This approach ensures that end-users can interact with decentralized applications (dApps), systems, and services without needing tokens for the computations they initiate.

The Tokamak Upgrade

Tokamak represents a comprehensive upgrade of ICP’s messaging and consensus mechanisms, introducing enhancements that minimize response times for users, optimize network routing, and bolster the blockchain’s ability to support high-frequency applications.

The Latency Problem

Before Tokamak, end-to-end transaction latency was a persistent challenge in blockchain-based systems. Decentralized networks inherently require time (latency) to reach consensus, and ICP—despite chain-key cryptography and parallel execution—still faced inefficiencies in message routing and network propagation. The latency bottlenecks arose primarily from:

1. Consensus Layer Delays: The time required for subnet nodes to validate, propagate, and finalize messages.
2. Message Routing Inefficiencies: Unoptimized relay paths between boundary nodes and the consensus layer.
3. Synchronous Processing Dependencies: Some critical update calls required multiple sequential steps before execution, increasing delay.

With Web3 applications demanding real-time performance for DeFi, gaming, and AI-driven services, latency reduction became a crucial engineering goal. The Tokamak Upgrade was specifically designed to resolve these issues.

Key Improvements Introduced by Tokamak

Reduction in Transaction Latency:

The Tokamak Upgrade has significantly reduced end-to-end transaction latency, decreasing average update call times by roughly 51%.

This was achieved through a combination of:

• Optimized Message Propagation: Messages now travel through an enhanced routing system, reducing processing time between nodes.
• More Efficient Consensus Execution: By streamlining the order in which transactions are validated, ICP now minimizes unnecessary computation delays.

This improvement directly benefits smart contract interactions, cross-chain messaging, and DeFi applications, rendering ICP a more agile blockchain for developers and consumers.

Faster Boundary Node Routing:

Boundary nodes serve as ICP’s entry and exit points, processing user requests before relaying them to the subnet where execution occurs. Previously, boundary node routing was subject to variable latency, as messages were sometimes queued inefficiently. Tokamak resolves this issue by:

• Implementing Intelligent Routing Algorithms: Requests are now dynamically distributed to less congested boundary nodes.
• Reducing Relay Overhead: Messages now take a more direct path to consensus, reducing unnecessary hops across the network.

The result is faster request processing, significantly improving user interactions, particularly for applications requiring real-time updates.

Introduction of Abortable Broadcast Over QUIC:

Also introduced in the Tokamak Upgrade is the abortable broadcast over QUIC (Quick UDP Internet Connections). QUIC is a low-latency transport protocol designed to replace traditional TCP, offering faster, more reliable message transmission.

How QUIC Enhances ICP’s Performance

• QUIC enables stream multiplexing, allowing multiple messages to be sent over a single connection without waiting for prior messages to resolve.
• Abortable broadcast ensures that redundant or outdated messages can be canceled mid-transmission, freeing up network bandwidth.
• By integrating QUIC, ICP minimizes retransmission delays, ensuring that updates, transactions, and cross-chain messages execute with maximum efficiency.

This improvement is particularly beneficial for DeFi platforms, gaming applications, and high-frequency trading algorithms, where suboptimal message relays could previously lead to delays or missed opportunities.

Prior to Tokamak, certain update calls were processed asynchronously, requiring multiple steps before a transaction could be finalized. While this architecture ensured security, it also resulted in higher latency for time-sensitive actions.

With the Tokamak Upgrade:

• Synchronous update calls are now supported, reducing the wait time for contract state changes.
• This means that token swaps, asset transfers, and governance proposals execute with near-instant finality.
• Applications built on ICP can now mimic the instant responsiveness of traditional Web2 platforms, further bridging the gap between blockchain-based and centralized services.

The Stellarator Upgrade

The Stellarator Upgrade represents one of the major advancements in the Internet Computer since its inception. Designed to enhance on-chain data persistence, smart contract scalability, and execution efficiency, Stellarator introduces a suite of optimizations that push the boundaries of decentralized networks.

Stellarator came with the implementation of Log-Structured Merge Trees (LSMT), 64-bit memory addressing, and enhanced orthogonal persistence, ICP now boasts vastly improved state management, reduced storage overhead, and a more seamless developer experience.

Prior to Stellarator, on-chain data storage faced efficiency bottlenecks due to the inherent limitations of serialization and deserialization processes. With LSMT, ICP’s storage model undergoes a fundamental shift, allowing for:

• Efficient Data Organization: Instead of rewriting entire state snapshots, LSMT structures data as incrementally updated logs, drastically reducing computational overhead.
• Improved Query Performance: The tree-like structure ensures that frequently accessed data is retrieved in logarithmic time, reducing read latency across the network.
• Optimized Write Operations: By batching and compressing updates, LSMT minimizes storage fragmentation, enabling canisters (smart contracts) to store and process significantly larger datasets without degrading performance.

This implementation enables subnets to host over 1TB of memory per smart contract, marking a major milestone in blockchain scalability.

Another aspect of Stellarator is its Enhanced Orthogonal Persistence (EOP), an improvement to ICP’s existing state persistence model. This advancement eliminates the need for traditional serialization/deserialization cycles during contract upgrades, allowing for:

• Seamless Smart Contract Upgrades: Canisters retain their full execution state without requiring costly rewrites, preserving application stability.
• Reduced Compute Load: Eliminates the inefficiencies of transforming structured data between serialized formats and active memory.
• Scalability for Long-Lived Applications: With persistent state retention, dApps that rely on complex data models or AI-driven analytics can now execute continuously without downtime.

This improvement allows for dynamic application scaling in a decentralized environment, helping areas like Web3 social networks, AI-driven dApps, and high-throughput DeFi platforms.

Perhaps the most forward-looking component of Stellarator is support for 64-bit memory addressing. By expanding beyond the traditional 32-bit architecture, this upgrade:

• Removes Memory Constraints: Smart contracts can now handle significantly larger datasets, allowing for complex computations and AI-driven analytics.
• Supports Large-Scale Smart Contracts: Enables canisters to process multiple terabytes of data, removing one of the primary obstacles to high-performance decentralized applications.
• Future-Proofs ICP: 64-bit memory support aligns the Internet Computer with modern cloud infrastructure, ensuring long-term viability for enterprise-grade blockchain solutions.

This development lays the groundwork for AI, big data, and decentralized machine learning models, enabling developers to create on-chain services that compete with traditional cloud platforms.

Advantages of The Stellarator Upgrade

Benefits For	Features	Advantages
Developers	More Efficient Data Handling (LSMT)	Faster reads/writes, lower cost of frequent state updates
	Seamless Canister Upgrades	Enhanced persistence eliminates costly migrations
	Access to Expanded Memory (64-bit addressing)	Richer application logic and AI-driven automation
End Users	Faster App Performance	Lower latency and improved response times
	Lower Costs	Optimized storage and computation reduce gas-like fees
	Better User Experience	Persistent state means smoother interactions across Web3 applications

The Beryllium Upgrade

The Beryllium Upgrade introduced a suite of enhancements aimed at improving developer experience, system reliability, and overall network performance of the ICP. This upgrade optimizes canister-level operations, focusing on error handling, debugging capabilities, and system stability.

As the ICP ecosystem expands to accommodate more complex applications—including DeAI, AI-powered agents, and decentralized governance tools—the need for efficient debugging, canister state management, and error resolution has grown substantially. The Beryllium Upgrade addresses these critical areas, providing developers with better insight into the behavior of their smart contracts while enhancing the resilience of the underlying infrastructure.

Beryllium brings several foundational improvements to ICP’s smart contract runtime environment, refining the developer experience and canister state management. These improvements fall into three primary categories:

Canister Snapshots

The Beryllium Upgrade introduced Canister Snapshots, an advanced mechanism that enables developers to capture and restore the state of a smart contract (canister) at specific moments in time.

Previously, developers had no efficient way to rollback a canister’s state in the event of a failure or unintended modification. The introduction of snapshots provides a solution, allowing developers to:

• Save a canister’s state at predefined intervals or before making critical updates.
• Revert to a previous snapshot in case of an error, reducing downtime and minimizing risks associated with failed upgrades.
• Enhance fault tolerance by quickly restoring canisters to a last-known good state without disrupting the broader application.

This advancement is particularly beneficial for high-value smart contracts, including DeFi applications, DAOs, and AI-powered services, where data integrity and state consistency are crucial.

Canister Logging & Error Backtracing

The Beryllium Upgrade improves developer tooling by introducing detailed logging capabilities and enhanced error backtracing mechanisms. This update provides greater transparency into execution failures and runtime behavior, empowering developers with critical debugging insights.

Key improvements include:

• Structured Canister Logging: Developers can now access detailed execution logs, allowing them to track function calls, system state changes, and unexpected behaviors.
• Error Backtracing: When a smart contract encounters an issue, ICP now generates comprehensive stack traces, pinpointing exactly where and why a failure occurred.
• Standardized Response Codes: Errors are now categorized with standardized response codes, streamlining troubleshooting and failure recovery processes.

These enhancements cut debugging time significantly, allowing developers to quickly identify and fix issues.

Improved Fault Tolerance & Smart Contract Resilience

The Beryllium Upgrade introduces an execution model, making ICP’s smart contract environment more resilient against unintended failures, infinite loops, and critical errors.

Key refinements include:

• Intelligent Resource Allocation: Canisters are now more efficient in managing compute and memory resources, reducing the likelihood of crashes due to resource exhaustion.
• Automatic Recovery Mechanisms: In cases where a canister fails unexpectedly, the system can now recover more gracefully, minimizing downtime and service disruptions.
• Better Execution Isolation: Faulty or malicious canisters cannot compromise the stability of the broader ICP network, reinforcing security and system integrity.

These changes collectively improve the reliability of mission-critical applications, ensuring that developers, businesses, and DAOs can build on ICP with greater confidence in system robustness.

Why the Project was Created

ICP was founded in October 2016 by Dominic Williams and was launched by DFINITY into the public domain on May 10, 2021, although its origins can be traced back to 2015. The DFINITY Foundation is a Switzerland-based non-profit organization that created ICP to address the limitations of the existing internet infrastructure and to reduce the centralization of power in the hands of a few dominant technology companies. The primary objectives were to increase the scalability and security of blockchains, facilitate and promote the development of smart contracts and decentralized applications, and reduce the reliance on centralized service providers.

The core premise for building ICP was to come up with a blockchain design that enables smart contracts to reach their full potential by overcoming the limitations of traditional blockchains with respect to speed, storage costs, and computational capacity. ICP achieves this by connecting nodes through cryptographic protocols to form multiple blockchains that host and execute “canisters,” the Internet Computer’s version of smart contracts.

Canisters can store data, perform a wide range of computations, and serve web pages directly to end-users. To cover computational and storage costs, IC employs a “reverse-gas model” where developers pre-pay using “cycles” obtained from ICP, the platform’s native token. $ICP tokens are also used for governance, with the network managed by a decentralized autonomous organization (DAO) responsible for network topology changes and protocol upgrades.

The Internet Computer addresses several critical issues in the computing and development landscape of current blockchains:

1. Centralization: ICP provides a decentralized infrastructure that reduces the dependency on centralized cloud storage and computing services. It reduces the control of a few major players in the market, ensuring a more open and inclusive ecosystem.

2. Scalability: ICP offers a scalable platform that can handle increasing demands and workloads without compromising performance. This allows developers to build applications that can easily scale with user growth.

3. Simplified development: ICP takes care of many infrastructure-related tasks like database configuration, load balancing, firewalls, network topology, port management, and storage volumes, allowing developers to focus on writing code and building innovative applications.

4. Security and reliability: The simplified development process and the decentralized nature of the IC lead to fewer bugs, vulnerabilities, and points of failure. This results in a more secure and reliable network, less susceptible to hacks and attacks.

5. Cost-effectiveness: By providing a decentralized infrastructure and reducing the need for traditional cloud services, the IC can lead to cost savings for developers and organizations.

6. Data sovereignty and privacy: Decentralized storage of data ensures better control and privacy for users and organizations, as data is not stored in centralized data centers, which can be vulnerable to breaches or misuse.

7. Open and permissionless innovation: The IC fosters an environment for open and permissionless innovation, where developers can build and deploy applications without the need for approval from a centralized authority.

Sector Outlook

The Internet Computer brings several advantages for both end-users and developers. Users can interact with decentralized applications on the Internet Computer just as they would with any other application on the public or private cloud. The Internet Computer eliminates many of the challenges associated with traditional application development and deployment, such as managing infrastructure, firewalls, backup facilities, load balancing, and failover orchestration. This helps IT organizations streamline their technology stack, reducing the need for complex integrations and management, which leads to improved operational efficiency and a more focused approach to application development and maintenance.

The original idea was the promise of a World Computer as a singular blockchain that would have far-reaching consequences across a variety of industries. However, the industry as a whole has gradually shifted towards a multichain environment that promotes interoperability across different smart contract platforms. This is evidenced by the increasing number of smart contract developers versus core protocol developers, as well as the number of users wanting to fully engage with a platform, rather than simply sending transactions or participating in simple payment systems. Thanks to chain-key cryptography, the Internet Computer can become an orchestrator between different blockchains.

The idea of a World Computer comes from 2014, when the Ethereum community envisioned a decentralized platform that could provide an alternative to the traditional IT stack of cloud computing servers, databases, middleware, backup systems, security infrastructure…

The Internet Computer also makes it possible to run dApps that do not run on the cloud. This is often not the case with other blockchains, where centralized providers like the App Store or Google can ban applications. For example, Metamask was banned in the Google Chrome Store in 2018.

User interactions with smart contracts on traditional blockchains typically require a browser wallet loaded with cryptocurrency. This wallet must be downloaded, and the user must purchase and install cryptocurrency in advance. This creates a barrier to entry, which can slow down user adoption and growth.

When it comes to processing tokens in dApps, if the dApp is not truly decentralized, regulatory considerations become an issue, often forcing developers to self-censor. For instance, in the summer of 2021, Uniswap, a major decentralized exchange, delisted more than 100 tokens due to potential legal issues. This is because, although their smart contract code was controlled by governance tokens, their website and much of the processing still ran on centralized cloud services, making the developers liable.

While blockchains host tamper-proof code that doesn’t need to be protected by a firewall, the same cannot be said for cloud services and private server computers. Hackers can potentially gain access to these traditional IT systems and modify the user interface code served to users’ web browsers, enabling them to steal tokens. In the winter of 2021, hackers compromised the IT systems of BadgerDAO and inserted malicious code into the user interface, resulting in the theft of $120 million worth of BTC and ETH from users.

The goal of the Internet Computer is to make it possible to build anything end-to-end on a blockchain by providing a more decentralized and secure platform for creating dApps, with better privacy and reduced reliance on traditional IT infrastructure.

Even if other blockchains have thrived and ICP has not become an Internet Computer, its architectural design allows it to create smart contracts that directly interact with other blockchains, without trusted centralized bridges. This is possible because of chain key cryptography, which allows for composability in a multi-chain environment.

With chain key cryptography, ICP extends each subnet with its own public chain key. The network can then create cryptographic signatures on messages to prove that returned results have not been tampered with and that the network is operating correctly. This functionality involves consensus that depends on threshold cryptography, non-interactive distributed key generation (NIDKG), key resharing techniques, and Merkle trees for scaling. The end result is that the protocol can be extended to allow hosted smart contracts on the Internet Computer to maintain ECDSA public keys and create corresponding signatures without needing to store a private key on the blockchain in a way that would make it vulnerable to theft.

ECDSA is the signature scheme used to sign transactions on other blockchains. This feature allows smart contracts on the Internet Computer to create transactions that other blockchains can directly execute, providing a more secure and decentralized solution for building DeFi frameworks and user experiences.

One application is the provision of special Bitcoin capabilities to canister smart contracts, enabling them to create Bitcoin addresses and send and receive Bitcoin directly on the Bitcoin ledger. This way, smart contracts on the Internet Computer can process Bitcoin almost as though they are hosted by the Bitcoin network themselves, eliminating the need for users to rely on potentially insecure and centralized trusted bridges.

Another application is the signing of transactions designed to invoke smart contracts on other blockchains, such as Ethereum. To interact with Ethereum, an Internet Computer canister smart contract can create an ECDSA public key that functions as an Ethereum Account, which should be charged with some ETH to pay for gas. The smart contract can then invoke calls on the Ethereum blockchain by creating and signing appropriate Ethereum transactions that will be executed by the Ethereum network. The smart contract can determine the results of the transaction using the HTTPS outcalls feature to interact with Ethereum local nodes.

Chain Fusion

Chain Fusion enables smart contracts to interact with multiple networks allowing developers to realize multichain use cases and profit from ICP features. It allows the IC Protocol to interconnect with multiple blockchains in a decentralized manner, eliminating the need for a single trusted intermediary such as a bridge. This is possible through decentralized bi-directional communication of the IC with other chains and the ability of ICP smart contracts to sign and submit transactions to other chains.

Chain Fusion augments smart contracts and decentralized applications (dApps) on other chains with the unique capabilities of ICP, including:

Web2-like User Experience: Due to low cost, fast finality, and the reverse gas model, interacting with a smart contract on ICP closely resembles the user experience of traditional web services. By complementing non-ICP smart contracts with user interfaces served from ICP, the user can interact with these smart contracts using a standard browser, without installing a crypto wallet or relying on a single point of trust.

Performance: Smart contracts on the IC possess the power to support a vast range of web services, from social networks to full-fledged AI models. Thus, Chain Fusion allows to build more powerful dApps combining non-ICP smart contracts with the decentralized compute power of ICP.

Storage: Using a competitive pricing model, a single smart contract on ICP offers up to 1TB+ of storage (post-Stellarator upgrade), enabling all application data to be stored on-chain. Through Chain Fusion, these decentralized storage capacities are made available to non-ICP dApps, making fully on-chain applications more viable than ever.

Decentralized Boundary Nodes (Solenoid Upgrade): Chain Fusion now benefits from decentralized API boundary nodes introduced via the Solenoid upgrade. This:

• Enhances security by eliminating reliance on centralized nodes
• Improves speed and censorship resistance for cross-chain transactions
• Allows developers to connect to API boundary nodes directly instead of relying on HTTP gateways

Autonomy: Smart contracts on ICP are capable of scheduling messages for themselves at any given interval. This functionality allows smart contracts to operate without the need for user inputs or arbitrage to maintain their services. Chain Fusion provides this autonomy to non-ICP smart contracts without sacrificing decentralization.

Interoperability with Web2: ICP’s HTTPS outcall feature permits canisters to reach out to any web service in a replicated fashion, using deterministic response results. Chain Fusion brings this Web2-Web3 interoperability to non-ICP dApps.

Expanded Interoperability with Web3 Networks: With the introduction of Threshold Schnorr and ECDSA signatures, Chain Fusion now allows trustless interaction with multiple blockchain networks, including:

• Bitcoin (via Taproot support and threshold Schnorr signatures)
• Ethereum (via threshold ECDSA and direct Chain-Key transactions)
• Solana, Polkadot, Cardano, and Stellar (via Chain-Key signature expansion)

This enhancement ensures that ICP smart contracts can seamlessly integrate and sign transactions across different chains, removing the need for external bridges.

Some other features include:

• Scalability:

• • • The Internet Computer can process unbounded volumes of smart contract data and computation natively because it can grow in capacity by adding more nodes.

• Dapp code hosted and executed on-chain:

• • • The Internet Computer can serve web content directly to users. This is not the case in other blockchains, who only support smart contracts and rely on centralized providers to host the frontend interface.

• Reverse gas model:

• • • Users can interact with dApps without having to pay in tokens, since the canister can store a certain amount of cycles and pay for the user.

• Processing HTTP requests:

• • The Internet Computer can process computation from regular web servers and act as a layer that translates HTTP requests from users to messages that can be consumed and processed by smart contracts.

Bitcoin Integration

The integration allows for direct communication between ICP and Bitcoin, enabling canisters (smart contracts) to securely sign and submit Bitcoin transactions. The integration involves changes and additions to various layers of the Internet Computer protocol stack, and relies on a novel Schnorr and threshold ECDSA protocol for computing signatures based on a secret shared private key.

This enhancement allows canisters to execute Bitcoin transactions using both key and script paths, increasing privacy and flexibility for Bitcoin DeFi applications. The Bitcoin adapter maintains state information such as block headers and caches for outgoing transactions. Canisters can retrieve UTXOs associated with their Bitcoin addresses and hold and transfer Bitcoin directly on the Bitcoin blockchain.

An external Bitcoin adapter connects to multiple Bitcoin nodes and maintains a local copy of the whole block header chain and a small cache of blocks. In each round, the block maker sends a request from the Bitcoin canister to the Bitcoin adapter, which responds with the latest information. This response is included in the Internet Computer block’s payload.

• The Bitcoin canister maintains a set of recent Bitcoin blocks and the entire UTXO set, which are used together to respond to UTXO and balance queries of canisters.
• The Bitcoin adapter maintains a local copy of the whole block header chain as well as a small cache of blocks that it provides to the replica upon request.

Each replica performs a deterministic validity check of the Bitcoin payload contained in the Internet Computer block. Once the block with the Bitcoin payload has been successfully validated, it is finalized.

When the Bitcoin payload reaches the execution layer, it is sent to the Bitcoin canister where the payload is validated, and the state of the Bitcoin canister is updated accordingly.

P2TR (Taproot) Support

ICP has successfully integrated Pay-to-Taproot (P2TR) support, enhancing its Bitcoin interoperability by enabling smart contracts to create and manage Taproot-compatible Bitcoin addresses. This advancement strengthens privacy, efficiency, and flexibility for Bitcoin transactions executed through ICP’s Bitcoin canister.

Key Features:

• Taproot Address Generation: ICP canisters can now create and control native Taproot (P2TR) addresses, expanding the scope of Bitcoin smart contract applications.
• Threshold Schnorr Signatures: ICP introduced key-tweaking for Schnorr signatures, allowing secure, decentralized Taproot transactions without exposing individual signer identities.
• Enhanced Bitcoin DeFi: The integration enables trustless smart contract custody of BTC, improving scalability and efficiency for Bitcoin-based lending, staking, and payments.
• Cross-Chain Functionality: P2TR support advances Chain Fusion, allowing seamless interactions between Bitcoin and ICP smart contracts while maintaining privacy and reduced transaction costs.

Ethereum Integration

With chain key cryptography, smart contracts on ICP can directly interact with the Ethereum network and other networks that are using the Ethereum Virtual Machine (EVM), such as Polygon and Avalanche. It gives the Internet Computer the ability to sign transactions that invoke smart contracts on Ethereum. To interact with Ethereum, an Internet Computer canister smart contract can create an ECDSA public key that functions as an Ethereum Account, which should be charged with some ETH to pay for gas. The smart contract can then invoke calls on the Ethereum blockchain by creating and signing appropriate Ethereum transactions that will be executed by the Ethereum network. Similarly, the integration would also enable Ethereum smart contracts to interact with ICP smart contracts.

This entails a native trustless integration that will enable smart contracts on both networks to interact with each other. Like native Bitcoin on ICP, Ethereum transactions could be signed using ECDSA signatures.

• Every canister smart contract would have an ECDSA key pair (actually, it can have many) that it could use to derive an Ethereum address and sign transactions.
• A private signing key would be secretly shared among many nodes and periodically reshared.
• ECDSA signatures are computed using cryptographic multi-party computation (MPC) protocols, which are resilient against attacks by malicious parties.

Besides ECDSA signatures, an on-chain Ethereum RPC API running on the Internet Computer is required in order to enable seamless two-way calls between smart contracts on both platforms.

Given the scale and complexity of implementing an on-chain Ethereum full node API, the ETH <> ICP integration was built in two phases:

• Phase 1: Initial integration focused on providing basic functionalities for canister smart contracts on the Internet Computer to interact with the Ethereum network via HTTPS outcalls. This may include creating and signing transactions, querying account balances, and invoking smart contract calls on the Ethereum blockchain.

Canister HTTPS outcalls on the Internet Computer blockchain allow direct interaction with Web 2.0 APIs and other blockchains without oracles. This way, canister smart contracts can make HTTPS outcalls to specified URLs in order to directly obtain off-chain data, or to interact with off-chain systems, such as Web 2.0 services or enterprise IT infrastructure.

• Phase 2: The second phase expands the integration to support more advanced functionalities and seamless two-way communication between smart contracts on both platforms. This will involve an on-chain Ethereum API on the Internet Computer by running Ethereum full nodes next to each ICP replica on a large ICP subnet and communicating with these subnets from the replicas through ICP consensus.

Some of the most remarkable features of ICP include:

• Speed:
  • The Internet Computer has a latency of around 200 milliseconds for query calls, which are read-only operations that retrieve data from the network.
  • The Internet Computer has a latency of around 2 seconds for update calls, which involve writing or modifying data on the network.
• Low cost:
  • $5 per GB per year
  • Smart contracts as “secure-by-default”. This removes a lot of software complexity that developers do not need to build. This design reduces the time necessary to build and maintain software compared to traditional systems.

• Scalability:

• • • The Internet Computer can process unbounded volumes of smart contract data and computation natively because it can grow in capacity by adding more nodes.

• dApp Code Hosted and Executed On-Chain:

• • • The Internet Computer can serve web content directly to users. This is not the case in other blockchains, who only support smart contracts and rely on centralized providers to host the frontend interface.

• Reverse Gas Model:

• • • Users can interact with dApps without having to pay in tokens, since the canister can store a certain amount of cycles and pay for the user.

• Processing HTTP Requests:

• • The Internet Computer can process computation from regular web servers and act as a layer that translates HTTP requests from users to messages that can be consumed and processed by smart contracts.

Chain-Key Tokens

With Chain Fusion, ICP introduces Chain-Key Tokens, backed 1:1 by the native token and held entirely on-chain by an ICP smart contract; chain-key tokens act as a secure alternative to traditional wrapped tokens which rely on intermediaries. These tokens use ICP’s chain-key cryptography protocols, such as threshold signatures, to provide decentralization and security without the need for centralized bridges.

By doing away with the requirement for middlemen, chain-key tokens lower the possibility of vulnerabilities based on trust. The backing of native tokens maintained on-chain assures transparency and security. Transactions with chain-key tokens on the ICP network are typically faster and cheaper than those on the tokens’ native networks, this is possible due to ICP’s advanced chain-key cryptography and decentralized architecture which is also highly interoperable and enables smooth and seamless cross-chain swapping of chain-key tokens.

Each chain-key token adheres to an ICRC (Internet Computer Registry Contract) token standard, simplifying integration with services like wallets and decentralized exchanges (DEXs). The ICRC standards define the token type, usage, and integration procedures. To use chain-key tokens in smart contracts, developers make calls to the ICRC ledger for the specific chain-key token. This process does not require a specialized type of smart contract and supports various programming languages. Currently supported chain-key tokens include:

• ckBTC: A 1:1 digital twin of Bitcoin.
• ckETH: A 1:1 digital twin of Ethereum.
• ckERC20 Tokens: Examples include ckLINK, ckPEPE, ckUSDC, ckDAI etc.

Requirements for Chain-Key Tokens

To ensure high security and decentralization, chain-key tokens must meet the following criteria:

• True Digital Twin: Chain-key tokens must allow seamless conversion between the native token and the chain-key token, fully backed by the corresponding native token at all times. Conversions might be delayed if a chain is temporarily unavailable, but they must be finalized eventually.
• Transparency: All conversions must be transparent, with tokens traceable on-chain.
• Decentralized Management: The canister handling conversions must use chain-key signatures for managing the underlying native token and read data from the native chain in a decentralized manner.
• Decentralized Canisters: All canisters must be open source, have reproducible builds, and be immutable or controlled by a DAO (e.g., an SNS or a threshold canister with many verified voters).

ckBTC

A 1:1 digital twin of Bitcoin, Chain-key Bitcoin (ckBTC) is an ICRC-2-compliant token that is backed 1:1 by $BTC held 100% on the mainnet. ckBTC does not rely on a centralized bridge to facilitate the conversion between $BTC and ckBTC, which makes it substantially more secure when compared to other traditional ‘wrapped’ tokens.

ckBTC and $BTC have the same value and can be swapped for one another seamlessly, however ckBTC has several advantages. ckBTC has faster transactions that are finalized within a few seconds, and ckBTC transactions on ICP are significantly cheaper than those on the Bitcoin network. Beyond enabling faster and cheaper $BTC transactions, ckBTC can power token swaps on decentralized exchanges, streamline point-of-sale operations, facilitate crowdfunding campaigns, and underpin e-commerce platforms. With fees as low as 0.0000001 ckBTC, which is equivalent to less than a cent or 10 satoshis, bitcoin-based commerce can run natively in an ICP smart contract, allowing for custodial solutions without mitigated third-party risks

The ckBTC ledger is responsible for keeping account balances and for transferring ckBTC between accounts. It provides the following functionality:

• Enables the ckBTC minter to mint and burn ckBTC.
• Facilitates the transfer of ckBTC among users.

The ckBTC minter is responsible for the minting and burning of ckBTC tokens. It uses the following workflow:

• Tokens are minted when a user transfers bitcoins to a specific Bitcoin address under the ckBTC minter’s control. The Bitcoin address uniquely identifies the owner of the sent bitcoins.
• The ckBTC minter waits for confirmations of all Bitcoin transactions that affect the total supply of ckBTC (because of the lack of finality in Bitcoin).

For Bitcoin retrieval requests, the ckBTC minter burns ckBTC before transferring the corresponding BTC amount (minus fees) using a regular Bitcoin transaction.

ckETH

Chain-key Ethereum (ckETH) is an ICRC-2-compliant token that is backed 1:1 by $ETH held 100% on the mainnet. Like ckBTC, ckETH does not rely on a centralized bridge to facilitate the conversion between $ETH and ckETH, which makes it substantially more secure when compared to other traditional ‘wrapped’ tokens. ckETH has the same attributes and advantages as ckBTC, but corresponds to $ETH rather than $BTC. ckETH and $ETH have the same value and can be swapped for one another seamlessly, and ckETH has faster and cheaper transactions than $ETH.

The ckETH minter is responsible for the minting and burning of ckETH tokens. It uses the following workflow:

• Tokens are minted when a user calls the deposit function of the helper contract on Ethereum with some $ETH attached. The deposit function takes the receiver’s principal as an argument and emits a ReceivedEth event with the sender, value, and receiver as payload.
• The ckETH minter listens to the ReceivedEth event by periodically fetching logs from multiple Ethereum JSON RPC cloud providers and mints the corresponding amount of ckETH to the receiver’s account on the ckETH ledger.
• Users can withdraw ETH by creating an ICRC-2 approval on the ledger and calling withdraw_eth with a receiver ETH address as an argument on the minter.
• The minter will then burn the ckETH on the ledger and create an Ethereum transaction and submit it to the Ethereum network.

ckERC20

Chain-key ERC-20 (ckERC20) tokens are ICRC-2-compliant tokens that are backed 1:1 by the corresponding ERC-20-compliant token on Ethereum. For example, there are chain-key tokens for $USDC and $LINK. Just like other chain-key tokens, such as ckBTC and ckETH, the ckERC20 tokens do not rely on any centralized bridge to facilitate the conversion between the ckERC20 token and the ERC-20 token, which makes the conversion substantially more secure compared to other traditional ‘wrapped’ tokens. A ckERC20 token can be created for any ERC-20 token. The process of adding a ckERC20 token involves creating an NNS proposal.

For Users: Getting Started with ICP

Internet Identity

To access and interact with applications on the Internet Computer, users need to authenticate themselves, and one of the most commonly used methods for authentication is via Internet Identity. This allows users to access dApps without the need for traditional usernames and passwords. A user account is identified by a unique Identity Anchor, a smallish natural number chosen by the canister.

It utilizes a passkey to register and authenticate with websites and applications. Passkeys are a unique cryptographic public/private key pair. Internet Identity issues a new identity for each dApps that a user authenticates with, and the identity cannot be linked back to the user. No personal data is shared with dApps or the Internet Identity application itself, and no software downloads are required.

• This provides a high level of convenience for users, as they can authenticate to dApps with minimal friction, while also benefiting from a high level of security without having to manage cryptographic key material themselves.
• The system offers some degree of privacy for users by generating a pseudonym for each dApp that prevents the dApp from tracking users across different dApps they use.
• Users can create as many identity anchors as they wish, and they are not required to set and manage passwords or provide any personal identifying information to dApps or to Internet Identity.

Internet Identity works by building on top of the Web Authentication (WebAuthn) API running in a single canister that serves both the Internet Identity frontend and backend code. When a user sends a request to the frontend code, the backend authentication service issues a delegation on the user’s behalf. This delegation is then signed with the user’s passkey.

How to Create an Internet Identity

• To create an Internet Identity, navigate to the frontend URL: https://identity.ic0.app/

• Select ‘Create New’ from the UI.
• Next, select ‘Create Passkey’.

• A prompt requiring the device to set up the passkey on would pop up.
• Enter and complete a CAPTCHA test to prive humanity.

After this, your Internet Identity has been created! It’ll be shown on the screen, and it is recommended that you write it down in a safe location to save it. This number is your Internet Identity. With this number and your passkey, you will be able to create and securely connect to ICP dapps. If you lose this number, you will lose any accounts that were created with it. This number is not a secret, but is unique to you.

Once you save it, select the ‘I saved it, continue’ button. After this, you can connect your Internet Identity to dApps shown in the Dapps Explorer. It is highly recommended to enable the recovery methods so that you can recover your Internet Identity if the hardware passkey is ever lost.

Internally, users have a different pseudonym for each dApp, but a pseudonym for any single dApp is the same across all of the user’s devices. All devices of a particular user simply represent different methods they can use to authenticate their Internet Identity anchor.

On top of being able to add multiple devices and use passkeys, users can set up account recovery options with a seed phrase or security key.

• The seed phrase option generates a cryptographically secure sed phrase that the user can use to recover an identity anchor. This seed phrase must be stored somewhere safe and not be shared, since it has the ability to take over an identity anchor.
• The security key option makes it possible to recover an identity anchor in the event that a user loses access to their authorized devices. This key should also be stored somewhere safe and be only available to the user. Possession of that key grants access to the user’s identity anchor.

Visit here for more instructions in creating and managing your Internet Identity.

Managing and Staking $ICP Tokens

The Internet Computer is governed by people staking their $ICP tokens and voting on proposals. There are 4 steps involved to participate in that process.

• Buy $ICP or have someone send $ICP tokens to you

• Keep $ICP under custody. There are many custody options, each with different security and usability trade-offs.

• Stake by locking $ICP tokens within a neuron with a dissolve delay. By staking you get access to voting on NNS proposals and collect NNS rewards. There are multiple ways to participate in staking, each  with its own set of tradeoffs.

• Vote on NNS proposals using neurons. There are two ways to vote:

1. 1. Manual voting on proposals by using the NNS frontend application
   2. Following a neuron. This allows users to automate their voting and receive the maximum voting rewards. Users can follow neurons on all topics or only specific topics.

For Developers

ICP Ninja

ICP Ninja is a web-based integrated development environment (IDE) for creating and deploying canister smart contracts. It acts as a springboard for developers to start building on ICP quickly and seamlessly. ICP Ninja abstracts away from the traditional development workflow for ICP developers, which typically includes downloading the IC SDK, creating a developer identity, then getting cycles to pay for the canister’s resources. With ICP Ninja, deploying an app is as easy as opening a template project and clicking “Deploy.”

Key Features:

• One-Click Deployment: Developers can write, test, and deploy smart contracts directly from their browser, eliminating the need for complex local setups.
• Pre-Built Templates: ICP Ninja provides ready-to-use project templates, accelerating development by offering preconfigured environments for Motoko and Rust.
• AI-Assisted Debugging: The platform integrates AI-driven troubleshooting tools, enabling developers to detect and resolve issues efficiently.
• Support for Multiple Languages: While currently supporting Rust and Motoko, ICP Ninja plans to expand to Python and TypeScript, broadening its usability for developers from different backgrounds.

EVM Compatibility & Chain Fusion Integration: The IDE includes an EVM Block Explorer, allowing developers to test and deploy cross-chain applications leveraging ICP’s interoperability with Ethereum, Bitcoin, and other networks.

Building ICP Smart Contracts

Creating canister smart contracts typically involves using a Canister Development Kit (CDK). CDKs facilitate the public interface of a canister, manage memory, enable communication with other canisters, and interface with the system API. The Internet Computer supports dApps compiled to standard WebAssembly modules, allowing developers to use a variety of programming languages to create canisters.

Although theoretically, any language that can be compiled into a WebAssembly module can be used for an ICP smart contract, the level of CDK and library support varies within the ICP developer ecosystem. The most common languages for developing canisters on the Internet Computer are Motoko, Rust, Typescript, and Python.

• Developer docs
• ICP for Ethereum developers
• Forum

Some of the key differences with Ethereum and EVM development are:

• Contracts are upgradeable by default. This is not the case in EVM-compatible chains, where contracts are immutable (nothing can be done if bugs are found) by default and developers rely on proxy contracts (which add extra complexity and risk)

• Inter-contract calls are asynchronous and not atomic, while the EVM is synchronous and transactions are atomic. This means if a user sends a transaction the transaction is either executed completely or the state is rolled back – only consuming the gas attached to the transaction. This is a detriment for scalability, since the entire network acts as a single process. On the Internet Computer inter-contract calls are asynchronous. Every time you use `await` the state is committed. In case a function traps, the state is only rolled back to the last occurrence of await.

• Contracts are deleted when they run out of gas, whereas in Ethereum contracts are permanent.

• • • Ethereum’s state grows without bounds, and there is little incentive for developers to free up space in the state. This can lead to scalability issues and increased storage costs for running nodes.
    • On the Internet Computer, contracts consume cycles according to their actual resource consumption. This includes computation, memory, and storage. Even if contracts are not called, they still consume some cycles, although very little. This approach encourages developers to optimize their applications for resource efficiency, as unused or inefficient contracts will gradually consume cycles and may eventually be removed if they run out of cycles.

• Gas fees are predictable, whereas in the EVM specific operations have a defined cost in gas but the exchange rate between ETH and gas is entirely defined by the market.

• 48-bytes are enough to verify the state of the IC. On the contrary, verifying the state on the EVM is a resource-intensive process where nodes need to verify the whole blockchain from genesis. While it is possible to use light nodes that verify only the header chain, most users rely on centralized APIs to access the Ethereum state, most notably Infura. The Internet Computer, in contrast, allows clients to verify the state with a constant 48-byte public key. This public key could be hardcoded into software such as browsers or even hardware like Internet of Things devices to let them interact securely with contracts on the IC.

• The Internet Computer can scale horizontally since it is a network of subnets where contracts can interact transparently across subnets.

• Contract storage is orders of magnitudes cheaper. In Ethereum, every node in the network needs to store and execute every contract and transaction. This can lead to scalability issues and high storage costs, limiting the practicality of hosting large amounts of data or full web applications on Ethereum. This is not the case in ICP, where execution and state are replicated only within specific subnets, reducing the resource requirements for individual nodes.

• External accounts are not (directly) part of the global state, whereas Ethereum consists of external accounts (users) and internal accounts (contracts), and each account has an associated ETH balance. On the IC only canister principals are part of the state. Each canister principal has an associated cycle balance which is not public by default. This has privacy advantages since a user can interact with canisters on the IC in an authenticated manner without disclosing its principal in the public state. The downside of this approach is that users can’t hold cycles directly, but need a canister like the cycles wallet.

• The global state is not public, but only parts. This is not the case on Ethereum, where everyone can run a node and everything is public. In the Internet Computer, neither the actual byte code nor the (cycles) balance of a contract is public. Nodes are permissioned by the NNS and only certain parts of the IC are public, such as the subnet of the contract, the name of the contract, the hash of the WASM module of the contract, and the controllers of the contract.

• Contracts can trigger themselves, whereas in Ethereum  every state change has to be triggered by an external account.

• Contracts have access to cryptographic randomness and can hold private keys and sign messages.  On Ethereum, every smart contract is public, which means that contracts cannot store private information securely. This limitation makes it impossible for Ethereum contracts to sign messages since they cannot securely store private keys.

Building on ICP with Bitcoin

At the heart of ICP’s Bitcoin integration is the Bitcoin canister, an on-chain smart contract that functions as a Bitcoin light node. This canister receives, holds, and indexes Bitcoin’s entire UTXO set, making it efficiently queryable for smart contracts on ICP. As a result, developers can build applications that interact directly with the Bitcoin network without requiring external APIs or third-party services.

Unlike traditional Bitcoin light nodes that require off-chain infrastructure, the Bitcoin canister operates entirely on-chain, providing the following advantages:

• Decentralized Transaction Signing: Smart contracts can submit signed Bitcoin transactions directly to the network.
• Seamless UTXO Management: The canister efficiently indexes and manages UTXOs for optimized transaction execution.
• Secure Custody: Native Bitcoin assets can be held and transacted on ICP without reliance on external custodians.

ICP enhances Bitcoin interoperability with ckECDSA, an advanced threshold ECDSA implementation designed for asynchronous environments. Unlike conventional multi-party computation (MPC) schemes, ckECDSA is uniquely suited for blockchain-based signing operations, providing a secure, decentralized, and trustless mechanism for Bitcoin transactions.

By leveraging ckECDSA, canister smart contracts on ICP can custody and transact native Bitcoin directly—without intermediaries. This eliminates risks associated with traditional wrapped BTC solutions, which often rely on centralized entities for issuance and redemption.

The deep integration of Bitcoin into ICP unlocks a broad range of new possibilities for builders and users alike:

• Bitcoin DeFi: Trustless lending, borrowing, and staking solutions leveraging native BTC.
• Cross-Chain Smart Contracts: Smart contracts that interact with both ICP and Bitcoin seamlessly.
• Fast and Cheap Payments: Merchants and businesses can accept Bitcoin payments instantly and without the high fees of the Bitcoin mainnet.
• NFTs & Ordinals: On-chain assets that leverage Bitcoin’s security while benefiting from ICP’s scalability and smart contract flexibility.

Explore ICP’s Bitcoin canister, ckECDSA, and ckBTC here to create Bitcoin-powered dApps.

Service Nervous System – SNS

Service Nervous Systems (SNSs) are DAOs that enable developers to transfer control of their dApps to decentralized, token-based governance systems. By doing so, each dApp that wants to be under decentralized control can have its own unique SNS.

Developers have the option to hand over their Web3 service to an SNS, or they can explore other alternatives for creating a DAO. Once an SNS is in place, the community can purchase governance tokens, which grant them ownership and control of the dApp through the SNS DAO.

Creating and launching a Service Nervous System (SNS) involves two main steps:

1. 1. Creating SNS canisters and setting initial parameters:
      1. Developers first create the SNS canisters by making a manual call to the NNS canister called SNS-W (SNS wasm modules canister).
      2. The dApp’s control is then handed over to these SNS canisters, which are in a pre-decentralization-swap state with limited capabilities.
      3. In this state, developer neurons exist and they can upgrade the dApp canisters through the SNS.

• Submitting an NNS proposal:

• An NNS proposal is submitted for the SNS to initiate the decentralization swap process.

• NNS voters can verify the parameters in the existing SNS canisters and the swap parameters set in the proposal.

• If the proposal is adopted, the decentralization swap for the SNS will be initiated. If the proposal is rejected, the SNS launch fails, and control of the dApp is returned to the developers.

To prevent malicious parties from creating unauthorized SNS canisters, SNS-W maintains a list of allowed principals who are permitted to install an SNS. A principal can be added to this list through an NNS proposal, which allows the principal to install exactly one SNS. After this one call, SNS-W automatically removes the principal from the list, ensuring that this can only be done once. This mechanism helps maintain the integrity and security of the SNS subnet.

For Node Providers: Joining The ICP Network

The Internet Computer is hosted by node machines, which are hardware devices dedicated to running and securing the network.

Traditional blockchain nodes are usually created using software that runs on cloud computing instances like Amazon Web Services (AWS). The investment required to create or destroy a node is minimal, aside from any cryptocurrency stake needed to join the network. In contrast, each node in the Internet Computer network is a dedicated physical device called a node machine, run by an independent node provider, which requires a more significant investment. This design aims to protect against centralization risk, where a small number of corporations that provide cloud computing services might end up deciding to shut down nodes due to regulatory issues. Also,  ICP’s decentralized governance can notice and sanction any statistically deviant nodes, ensuring the network operates efficiently and securely.

• Node provider docs

• ICP network dashboard

• Node provider onboarding 

• Node provider self-declaration 
• Node provider remuneration 

Each subnet has a table of Nakamoto Coefficient for each of the following subsystems (e.g. independent node providers, independent data centers, geographies)

The infrastructure of ICP creates a sovereign network using deterministic decentralizations. In practice, this means that each subnet is composed of nodes (owned and controlled by node providers), which are remunerated in ICP.

Each node lives in an independent data center (not cloud provider), which the node provider pays to upkeep and maintain its operations.

Adding a node to the network involves the following steps:

1. Node provider submits a proposal to a node provider.
2. NNS DAO decides if they want to add this node provider.
3. If accepted by the NNS DAO,  the node provider submits a proposal to add the node to a subnet or data center in a specific location.
4. The NNS DAO evaluates whether to accept the proposal based on questions like:
   1. Does ICP need more nodes?
   2. Does this node provider have too many nodes already?
   3. Does this subnet need more nodes?
   4. Does this data center have too many nodes?
   5. Does this location have too many nodes?

Node Providers Remuneration

Node providers receive rewards (remuneration) for operating node machines that run the IC network. The single source of truth for node provider rewards is the NNS, where changes can only be made through NNS proposals adopted by the IC community.

NNS’s reward distribution depends on the following:

• Node hardware version
• Geography

Considering the variations in capital expenditure (CAPEX) and operating expenditure (OPEX) due to different hardware versions and geographical factors, it should be noted that the hardware prices provided are based on quotes obtained from various vendors.

The calculations are based on a four-year amortization period for CAPEX. However, it’s important to acknowledge that the real costs of hardware and operational expenses may differ depending on the negotiation between individual Node Providers and their respective vendors. All prices mentioned are in XDR.

The above table clarifies the relationship between the different Hardware types and Remuneration models, which can be explained in the following categories:

• Gen1 Hardware 
  • This has been used by Node Providers to set up nodes during the Genesis launch. For these Node Providers, what is called V1 (Version 1) Remuneration model applies.
  • As work is being done to upgrade the Gen1 hardware with additional storage, the V1 remuneration will need to be updated in the future. This updated remuneration, which will be called V1.1 (Version 1.1) remuneration, will be described in a separate wiki page once an NNS motion proposal for this remuneration has been worked out in detail.
• Gen2 Hardware
  • The new Hardware specification is generic (instead of vendor-specific) and supports VM memory encryption and attestation which will be needed in future features on the IC. Since the HW specification is different, a new version of the remuneration, which will be called the V2 (Version 2) remuneration model is defined.
  • In the future, remuneration will be proposed that is fully decentralized and includes both automated incentives, rewards and penalties. For clarity, this will be called V3 (Version 3) remuneration.

Rewards

The NNS mints Node Provider Rewards every ~2,629,700 seconds (30.4 Days), which is 1/12th of a year. It uses the 30-day moving average price of ICP in XDR. This value is tracked on the Internet Computer Dashboard.

Version 1 Remuneration Model (Genesis)

The initial compensation plan incorporated a 150% margin to compensate for the considerable risk undertaken by early Node Providers who invested in hardware and operations before the Genesis phase. In simpler terms, the distributed rewards were 2.5 times the anticipated expenses.

The table below presents a comprehensive breakdown of expenses and rewards disbursed, categorized by geography.

Following the successful implementation of the initial nodes, it was determined that the storage capacity of all nodes needed to be expanded in order to accommodate larger subnet states. This expansion necessitated additional hardware and operational costs.

Once the added storage becomes operational for use by the IC, a proposition has been put forth to revise the Gen-1 compensation model to encompass all expenses. A separate motion proposal outlining these changes will be presented to the community for voting.

Version 2 Remuneration Model

This section proposes a new remuneration model for 2nd generation Node Providers.

Taking into account feedback from Node Providers and the community regarding the initial V2 remuneration proposal, as discussed in this forum post.

The Version 2 Remuneration Model is based on several principles:

• Higher Rewards for First Nodes: The model provides higher rewards for the first nodes of a new Node Provider to attract more Node Providers and improve ownership decentralization.
• Geographical Decentralization: The model offers more refined rewards for nodes in new geographies, like South America, Africa, Asia, and Australia, to stimulate further geographical decentralization.

The model is parameterized by:

• Geography Multiplier (mult): This multiplier is lower (2) for regions with many nodes (e.g., Europe and North America), and higher (3) for regions where there are currently limited nodes present (such as Africa and South America).
• Reduction Coefficient (r): The node reward of the n-th node of a Node Provider is multiplied by r ^ (n-1). The reduction coefficient r is dependent on the geography of the Node Provider. As a result, the first nodes of a Node Provider get attractive rewards, but it is increasingly less attractive to add additional nodes.

Version 2.1 Remuneration Model

The Version 2.1 Remuneration Model is an updated model for the 2nd generation Node Providers on the Internet Computer. It includes several changes compared to the previous Version 2:

• Regional Entries: No entry for the region Asia will be used anymore. Instead, specific country entries will be used. Specific entries for Hong Kong and India have been added to the remuneration table.
• Multiplier: The multiplier is set to a value of 2 for all countries. In the future, this might be updated through a new NNS proposal if the community determines that the risk premium for projects should be different for different countries.
• Node Limit: A limit is set to the number of nodes in new countries for which the remuneration applies. Once this limit is reached, the reduction coefficient for additional nodes will be adjusted. Currently, the limit of the number of nodes per country is set to 50 nodes.
• Time Period: Version 2 was relevant for a limited time period in 2023. Version 2.1 became the current model as of May 2023.

The monthly reward for the first node onboarded is based on the Remuneration Version 2.1 and varies depending on the geography-dependent values. For instance, the monthly reward for the first node in the US is 1294 XDR, while for India it’s 2100 XDR.

For the ICP Community: Participating in ICP

The wiki’s content is maintained by and for the IC Community.

How to Contribute

Anyone can contribute to this wiki, all one needs to do is create an account, or join the developers discord.

Types of Users

There are two types of users:

• User – Users can propose new articles or changes to existing articles. Anyone can become a user.
• Moderator – Moderators approve changes from users. Moderators are granted moderator status by other moderators. The intent is to grow this list.

For transparency, an up to date list of moderators can be found here.

Housekeeping Rules

• Keep a factual and sober tone, the purpose of the wiki is to convey accurate information, not to advertise.
• Refrain from redundancy, such as referring to the Internet Computer in article titles. This is, after all, the Internet Computer Wiki.
• Consistent with Wikipedia, for capitalization use headline style in page and section headings (H1 & H2), and sentence style for subheadings (H3 and below). DFINITY is always stylized in all-caps.
• Avoid the word “we”, many people may later edit the article leaving “we” ambiguous.

Creating a New Wiki Page

There are a number of ways to create a new page. After logging into the wiki, either

• In the wiki search bar, search for the page title you would like to create, then on the search results page you will see
  • If the page exists, then you can edit it
  • The option to create the page if it doesn’t exist
• Navigate to the URL that you want to create (e.g., https://wiki.internetcomputer.org/wiki/HTTP_Gateway) and then click on “create this page”.
• In edit mode on an existing page, choose a location for a link to a page you’d like to create, then type two open square brackets followed by the link text followed by two closed square brackets. This will create a link to a new wiki page. After saving the parent page (and pending moderation if needed) the new page will be created.

Investors

ICP Ecosystem

There are over 320 projects on the Internet Computer Protocol, according to the official website, or 387 according to cyql, a website containing a curated list of projects of the blockchain network.

The ICP ecosystem, being a blockchain that has been established for some years, contains a wide variety of projects. These projects consists of the following categories:

• SocialFi
• Bitcoin
• AI
• NFT
• Tools/Infrastructure
• DeFi
• Wallet
• Metaverse
• Games
• DAO

According to the official ecosystem website, tool and infrastructures projects contain the most projects followed by Creator projects and DeFI respectively. However, it is worth noting that some projects may have multiple tags, so the numbers may not be accurate.

SocialFi

DSCVR: DSCVR is an end-to-end decentralized Web3 social media platform that allows communities to form into groups called Portals. These Portals can be NFT gated, airdrop fungible and non-fungible tokens to their members, and much more. DSCVR uses Internet Identity for its 200,000+ users and also allows for tipping posts in a growing number of cryptos.

ICP Coins: Lists ICP coins by market cap. Aggregates stats from all IC DEXes. Price, Volume & Liquidity score charts.

Funded: A Web3 crowdfunding platform. Thanks to ICP’s low transaction fees and advanced smart contract technology, you can participate in crowdfunding with ICP, BTC and ETH without worrying about losing money on gas fees.

Plethora: Plethora is all about abundance and making you feel fulfilled. Plethora empowers NFT projects to launch their collections with immersive experiences customized for you.

Kontribute: Kontribute is a web3 creators’ platform that brings story writing and digital art collectibles together. Features include decentralized story storage, likes, tipping, polls, NFT marketplace, and NFT minting.

Tools/Infrastructure

Juno: Juno is an open-source platform that combines the power of Web3 with the ease and simplicity of Web2 development, enabling programmers to build decentralized apps faster and easier than ever before.

Dank: Dank is the first Decentralized Bank built on the Internet Computer, developed by Fleek. Through a collection of Open Internet Services for users and developers, Dank makes cycle management seamless.

DeFi

Infinity Swap: InfinitySwap is a platform to create, stake, and swap tokens on the Internet Computer. Backed by Polychain Capital and 9YardsCapital (amongst others) – InfinitySwap offers users the ability to swap tokens cheaply with their novel technology build on the ICP blockchain. They are also planning to release their own token standard IS20 to support these initiatives. The platform currently has 2 pools available, with a total of around $600K liquidity and 7 days volume of around $50K.

ICDex: ICDex is the flagship product of ICLighthouse, an orderbook-based DEX that runs 100% on-chain. The world’s first orderbook DEX – made possible by advanced ICP smart contracts.

AI

DecideAI: DecideAI is an ecosystem that consists of three products, Decide Protocol, Decide ID, and Decide Cortex, designed to meet the needs of the high-end, specialized LLM market.

Seers: The Social Network of Autonomous AI Agents.

Wallet

Bitfinity Wallet: The Bitfinity Wallet is a multi-chain wallet built and open sourced by InfinitySwap. It is a browser extension that allows you to store and transfer your BTC, ICP, SNS-1, NFT and other tokens – as well as log into Internet Computer dApps with a single click. The InfinitySwap Wallet also supports Internet Identity, the powerful authentication framework provided by the Internet Computer.

Earth Wallet: Earth Wallet is the self-proclaimed Key to Web3 The open-source wallet allows users to participate in DeFi, Governance, and Treasury (DAO) protocols with negligible fees and faster transaction settlement than legacy wallets. Now supporting the Internet Computer.

Metaverse

UnfoldVR: UnfoldVR empowers creators to author 3D NFTs using easy-to-use tools both on the Web and in Virtual Reality.

PokedStudio Bots: PokedStudio Bots are a collection of 10,000 unique bots designed by acclaimed digital artist, Jonathan Ball. The Ultimate Master Bot which sold for 3,000 $ICP (~$172,140), marks the largest single NFT purchase on the Internet Computer and is one of the largest across all blockchain projects to date.

Games

Mission Is Possible: Mission is Possible – 3rd place winner of the DSCVR Hackathon Season 2 – is a PVP third-person shooter hosted on the Internet Computer blockchain. The John Wick inspired game is built using the Unity 3D Game Engine, and hosted on the IC enabling decentralized login with Internet Identity.

Rise of the Magni: Rise of the Magni, built by Toniq Labs, winner of the DSCVR hackathon for games on the Internet Computer. Buy, earn, and trade collectibles, compete in tactical battles online to earn in-game tokens, and venture through story mode to experience one of the first games built on the Internet Computer.

DAO

Factland DAO: Factland is a Web3 DAO with a mission to slow the spread of misinformation online. Factland makes it easy for anyone to flag untrustworthy claims and have them promptly adjudicated by a decentralized community of fact checkers rewarded in crypto.

Business Model

The DFINITY Foundation is responsible for the research, development, and maintenance of the ICP. It doesn’t have a traditional business model like a company selling products or services. Instead, it operates on a token economy, where the ICP tokens play a crucial role in the functioning and governance of the network. It is a non-profit scientific research organization. It was initially funded through donations of bitcoin (BTC) and ether (ETH) during the Seed donation round in February 2017, where contributors were rewarded with ICP tokens. The value of the $ETH and $BTC received increased substantially before it was sold by the foundation, providing it with the necessary funds to begin expanding its operations.

Revenue Streams

ICP Tokens: ICP tokens are utility tokens that are used for governance and operation of the Internet Computer network. They can be locked to create neurons for voting in the Network Nervous System (NNS), or converted into cycles to power computation and storage on the network.

Node Providers: Node Providers are independent entities that provide computing capacity to the network. They are compensated for their services with ICP tokens, which are minted and distributed as rewards.

Developers and Users: Developers pay for the resources their applications (canisters) consume on the network using cycles, which are purchased with ICP tokens. Users interact with these applications without needing to pay for computations, thanks to the reverse gas model employed by ICP.

Developer Grants: Developers can receive grants of tokens through the Internet Computer Association (ICA) or the DFINITY Foundation for contributing to the development of the Internet Computer ecosystem.

Economics

ICP Dashboard

The Internet Computer Dashboard is a platform that provides real-time and historical information about the Internet Computer blockchain. It offers transparency regarding blockchain properties such as decentralization, governance, tokenomics, and more. The dashboard can be used for typical block explorer tasks, such as checking the status of a transaction. It also provides insights into various aspects of the Internet Computer, including:

• Total Canister State: The total amount of data stored in canisters on the Internet Computer.
• Internet Identities: The total number of unique identities registered on the Internet Computer.
• Total Supply: The total number of ICP tokens that have been minted.
• Circulating Supply: The number of ICP tokens that are currently in circulation.
• ICP Transactions: The total number of ICP transactions that have taken place.
• Total Burned: The total number of ICP tokens that have been burned.
• ckBTC Total Supply: The total supply of ckBTC tokens, which are backed 1:1 by Bitcoin.
• ckETH Total Supply: The total supply of ckETH tokens, which are backed 1:1 by Ethereum.
• Million Instructions Executed Per Second (MIEPs): The number of instructions executed per second on the Internet Computer.
• NNS Proposals: The total number of proposals made to the Network Nervous System (NNS), the decentralized governance system of the Internet Computer.
• Neurons’ Fund Stake: The total amount of ICP tokens staked in neurons, which are used to participate in network governance and earn voting rewards.
• Neurons’ Fund Maturity: The total maturity of the ICP tokens staked in neurons.

The dashboard also provides information about the Internet Computer’s integration with Bitcoin, including the total supply of ckBTC tokens and the volume of ckBTC tokens transferred, minted, or burned.

Tokenomics

The tokenomics of the Internet Computer (IC) is designed to establish a self-sustaining ecosystem that balances various goals and constraints.

• Low and stable storage and compute costs for developers: Ensuring that developers can build and maintain their dApps at a minimal and predictable cost.
• Sufficient rewards for node providers: Incentivizing node providers to join and remain part of the network.
• Balanced voting rewards: Encouraging staking and active participation in governance while also limiting inflation.

The Internet Computer’s tokenomics is a dynamic system. As such, it relies on the community to monitor its performance and make adjustments as needed. By submitting and voting on Network Nervous System (NNS) proposals, the community can evolve and optimize the tokenomics, ensuring that it continues to meet its goals and serve the needs of its users and stakeholders.

The total supply of $ICP is variable, with both minting (inflationary) and burning (deflationary) mechanisms:

• ICP inflation rewards node providers and governance participants.
• ICP deflation occurs when $ICP is burnt for computation, failed NNS proposals or for transactions/proposal submission fees.

At Genesis (May 10, 2021):

• Total Supply: 469 million
• Circulating Supply: 123 million

Currently:

• Total Supply: 521 million
  
• Circulating Supply: 468 million
• [Staked $ICP by Dissolve Delays]

The voting rewards for the Internet Computer are generated by minting $ICP tokens. However, this minting only occurs at the moment when rewards are spawned, maturity is merged, or the neuron is disbursed.

The voting rewards rate schedule is designed with the aim of having 90% of the token supply staked in neurons. To achieve this goal, during the first year, the Network Nervous System (NNS) allocates 10% of the total token supply to generate voting rewards.

It’s important to note the use of the term “allocates” rather than “mints,” as rewards are not minted (increasing the total supply) until they are spawned, merged, or the neuron is disbursed.

As the network becomes more stable over time, the allocation rate for voting rewards decreases quadratically, eventually reaching 5% by year 8.

The Internet Computer uses $ICP as the utility token, which has the following functionality:

• Staking in the NNS (Network Nervous System) to acquire voting rights and be able to participate in the DAO that controls the network. Staking $ICP also entitles users to receive newly minted $ICP tokens as a voting reward.
• Conversion To Cycles To Pay For The Use Of The Network: $ICP tokens can be converted to cycles (i.e. burned) and these cycles are used to pay for the cost of creating canisters and for the resources that canisters use, such as storage, CPU, and bandwidth.

• Payment to Node Providers — these are entities that own and operate the computing nodes that host the replicas that make up the Internet Computer.
• Transaction/Proposal Fees. When an $ICP holder transfers their $ICP from one wallet to another they incur a small transaction fee paid in $ICP (0.0001 ICP). $ICP holders also pay a small fee for submitting new proposals to the NNS.

Neurons are containers within the NNS that can hold staked $ICP tokens. Once staked, users can participate in governance matters.

If you don’t want to personally maintain a high level of activity or don’t have the time to stay informed about various proposals, you can delegate your $ICP tokens to more active neurons managed by other users. Delegation allows your tokens to be “borrowed” by another neuron for voting, and in return, you can receive a share of the rewards that the managing neuron earns.

Token Distribution

 

• 24.72% Seed Investors: those who invested in Feb-2017 for a total of CHF3.9 million (Swiss Francs)
• 23.9% Dfinity Foundation: The Dfinity Foundation manages the capital raised from the token sales and oversees its Foundation Endowment of $ICP tokens. These tokens are held or spent by the Foundation to fund R&D, operations, acquire technology, finance community-building programs, and partner incentives.
• 18.0% Team Members: There are ~200 team members
• 9.5% Early Contributors: these are the 50 people who helped in the team before the Foundation was set up
• 7.0% Strategic Investors: from the $20.54 million raise from Polychain Capital, Andreessen Horowitz, CoinFund, Multicoin Capital, and Greycroft Partners
• 4.96% Private Presale Investors: from the $97 million raised from a16z, Polychain, SV Angel, Aspect Ventures, Electric Capital, ZeroEx, Scalar Capital, and Multicoin Capital.

Governance

When you stake ICP tokens in a neuron, the tokens are locked for a specific duration, which you choose when creating the neuron. The lock period is called the “dissolve delay,” and it affects both your voting power and the rewards you receive.

• The longer the dissolve delay, the more voting power your neuron will have, up to a maximum of 8 years.
• A longer dissolve delay leads to increased rewards, incentivizing users to commit their tokens for more extended periods.
• Periodic Confirmation of Following: Neuron holders must now confirm their follow settings every 6 months to maintain voting rewards. Failure to confirm results in gradual loss of voting power and eventual removal from governance participation.

 

Keep in mind that once you start the “dissolve” process, your tokens will unlock gradually over the chosen dissolve delay period. You won’t be able to withdraw all your tokens immediately, but they will become available bit by bit until the delay period is over, and all tokens are fully unlocked.

Decision-Making on the NNS

Anyone can stake $ICP tokens in order to participate in NNS governance. $ICP tokens are staked in neurons, and neuron holders can suggest and vote on proposals. The voting power of neurons is based on a proof-of-stake system. Intuitively, neurons with more staked $ICP tokens have more voting power. However, voting power also depends on other neuron characteristics, such as commitment to keeping tokens staked for a longer period of time, which grants more voting power.

Proposals are adopted or rejected at any point if an absolute majority (more than half of the total voting power) is in favor or against the proposal, respectively. Each proposal has a predetermined voting period, and a proposal is adopted if, by the end of the voting period, a simple majority of the total voting power has voted in favor. There is a voting quorum for Yes-votes, which must exceed currently 3% of the total voting power. If these conditions are not met, the proposal is rejected.

If a proposal is adopted, the governance canister automatically executes the decision. For instance, if a proposal suggests changing the network topology and is adopted, the governance canister automatically updates the registry with the new configurations.

Service Nervous System

The Service Nervous System allows developers to easily tokenize dApps to raise funds, giving ownership to users and crowdsourcing decision making. The SNS framework allows developers to decentralize control of dApps, giving token holders governance rights over project decisions.

SNS Key Features:

• Decentralized Ownership: SNS allows users to collectively manage and upgrade dApps.
• Tokenized Governance: Developers can issue governance tokens to distribute decision-making power.
• Automated Governance Execution: Successful proposals automatically implement updates to the governed dApp’s code and policies.
• Enhanced SNS Tools: 2024 updates improved SNS proposal transparency and operational monitoring, making governance more user-friendly and resilient.

The combination of NNS and SNS ensures a fully decentralized governance structure, enabling the Internet Computer ecosystem to operate without centralized control while maintaining scalability, security, and transparency.

Risks

• Regulatory uncertainties surrounding blockchain technology and their associated tokens.
• Competition from existing and emerging blockchain platforms.
• Adoption challenges due to network effects and developer adoption.
• Technical issues, such as bugs or vulnerabilities in the protocol.

Security

Audits

The Internet Computer has undergone several security audits.

• The Ledger Internet Computer (ICP) app, a collaboration between the Zondax team of engineers and cryptographers and the DFINITY Foundation, has undergone a third-party audit and has been reviewed and approved by Ledger.
• The SNS framework has undergone two security audits by Trail of Bits in 2022 and 2023 with no severe issues found.
• BTC integration and ckBTC have undergone a security audit by Trail of Bits in 2023 with no severe issues found.
• Another third-party security audit of protocol and code was published as “Threshold ECDSA Cryptography Review”.
• Then again, there was the Threshold ECDSA Integration and Bitcoin Canisters Security Review by Trail of Bits

These audits are part of the DFINITY Foundation’s commitment to security. They conduct various security checks and reviews internally before a feature is released, and many of the major technical features built on the Internet Computer go through additional external security assessments conducted by leading organizations. After addressing the issues, DFINITY makes the audit reports public to allow the community an independent view of a feature’s security posture.

Economic Attack Vectors and Liquidity Risk

One of the key security concerns within the Internet Computer Protocol is the prevention of an attacker gaining 51% of the voting power, or even just enough that they can tip the balance in favor of those who vote unwisely, which will damage the success of the network. This is often referred to as a “51% attack” and is a common concern in many blockchain networks.

The term “attacker” here applies equally to an actor who wishes to harm the network, an actor whose influence will be maligned by accident, and one that might simply excessively centralize power. However, the colossal value of ICP locked inside the Network Nervous System (NNS) makes it exorbitantly expensive to acquire such a stake. Furthermore, the financial investment required would be difficult to recoup, since ICP that has been purchased and locked would dramatically lose value if the network were harmed.

Even if resources were less of a concern — for example, where an attacker was a malign state actor — unlocked ICP could not be purchased quickly on financial exchanges, since the vast majority of the overall ICP supply is locked in neurons to earn rewards. This would force such an attacker to build up their position slowly over time, with the buy pressure created by significant purchasing also driving up the price, such that successive purchases become ever more expensive.

As for liquidity risk, the Internet Computer faced substantial disruption in the markets for its ICP utility token due to price manipulation attacks launched against the project at its launch. This led to misconceptions and disinformation about the project becoming widespread. However, this situation is slowly clearing, and it did little to dent developer interest in the project.

Team

The DFINITY Foundation is led by Dominic Williams (Founder and Chief Scientist) and features a diverse team of experienced professionals with backgrounds in computer science, cryptography, software development, and business operations. It is a Swiss-based not-for-profit organization with one of the largest R&D teams with over 1,600 employee publications, 100,000+ citations, 270+ team members, and 250+ employee patents.

Some of the team members include:

Leadership

• Dominic Williams, Chief Scientist:
  • A serial entrepreneur with a background in crypto research and distributed computing.
  • Williams designed the Internet Computer’s Threshold Relay.
• Gian Bochsler, Foundation Council member & Swiss Operations
  • An experienced entrepreneur, fund manager, and board member.
  • Has deep experience in blockchain, having co-founded Bitty, a leading European digital asset exchange, among many other ventures.
• Josh Drake, Chief Operation Officer
  • Prior to joining DFINITY Josh worked at Coinbase, a digital currency wallet, and platform.
  • Past work experiences include Veritas Technologies, Maxim Integrated, Triple Canopy, Law Enforcement, and the United States Marine Corps.
  • Josh is also an avid investor and pilot.
• Jan Camenisch, VP of Head of Research & Crypto:
  • Previously at IBM Research, where he led the Privacy and Cryptography research team
  • Jan has published 130 papers and holds 140 patents.
• Samuel Burri, Vice President of Engineering
  • Samuel spent the last 8 years leading a global team who builds and maintains Schindler’s elevator control software.
  • Previously, he worked for IBM Research where he focused on formal methods for modeling and enforcing authorization constraints in business processes.
• Lomesh Dutta, Vice President of Growth
  • Lomesh has over 17 years of experience building and scaling startups.
  • Most recently, he was the Head of Growth and Marketing at the crypto banking service, Abra. Before that, he served as the VP of Growth at Paytm, the largest fintech in India.
  • He has started/sold 2 startups and is passionate about tackling innovative and unique problems.
• Saskia Lenkeit, Head of HR
  • Saskia was previously an HR Business Partner at Google for 7 years supporting over 900 software engineers in Zurich, Switzerland.
  • During her last 3 years, her scope expanded to a more strategic HR role, where she supported the EMEA Cloud leadership team, as well as responsible for HR across two office locations.
• Paul Meeusen, Vice President of Finance
  • Paul is an experienced entrepreneur, finance, and risk manager. He co-founded the insurance blockchain firm B3i and was elected by Acord among the Top Ten InsurTech Leaders in 2018. Prior to this, he spent 25 years in finance, risk, operations, and audit management roles at Swiss Re and PwC, across Europe, US, and Asia.
  • Paul holds an MS in economics from the University of Leuven (Belgium) and is a Certified Internal Auditor.
• Riccardo Coli, Chief of Staff
  • Riccardo has over 15 years of experience transforming the way companies engage with their markets, their clients, and their people.
  • His experiences are in high-tech, aerospace, and defense industries, with reference to the EU and Asia market.
  • He holds a Bachelor’s degree in Sociology & Communication at IULM University, a Master of Science in Marketing Management at L. Bocconi University and an Executive Program in Blockchain for Business at SDA Bocconi.
• Maria Dubovitskaya, Director of Engineering
  • Maria is a cryptographer working on designing provably secure protocols for privacy protection and bringing research into practice.
  • Maria holds a Ph.D. from ETH Zurich and joined DFINITY after 11 years as an engineer and researcher at IBM. Maria has published many papers and promotes STEM for young women.
• Johan Georg Granström, Director of Engineering:
  • Former tech lead manager at YouTube, Google.

Some of the staff members amongst the 270+ listed on the DFINITY site include:

• Andreas Rossberg, Researcher and Engineer:
  • Former Google employee and JavaScript language team lead at Chrome V8.
  • Co-creator of WebAssembly and creator of the Internet Computer’s programming language Motoko.
• Benjamin Lynn, Engineer:
  • Lynn is the “L” in BLS Signatures, a significant cryptography concept.
  • Former Google employee and holds a Ph.D. in Computer Science from Stanford University.
• Timo Hanke, Principal Researcher:
  • Former mathematics and cryptography professor
  • Inventor of AsicBoost, a method that improves Bitcoin mining efficiency.
• Mahnush Movahedi, Senior Researcher:
  • Formerly at Yale University, her work focused on scalable and fault-tolerant distributed algorithms for consensus and secure multi-party computation, secret sharing, and interactive communication over noisy channels.

Project Investors

The DFINITY foundation raised financing in 3 main rounds and also allocated $ICP tokens to the community in the form of an airdrop event.

• Seed Round (Feb 2017)
  • $3.9 million from 370 participants at a valuation of $16 million, with a token price of $0.03, although total cash receipts were greater, as the value of the ETH and BTC received increased substantially before it was sold by the foundation.
  • Participants received their tokens at Genesis but they were staked inside 49 neurons with dissolve delays ranging from 0 to 49 months (functioning as a vesting schedule).
• Strategic Round (Feb 2018)
  • DFINITY raised $61 million in exchange for 7.00% of the initial token supply, which vests monthly over three years starting from mainnet launch (May 2021).
  • Of the $61 million funding, $21 million will go directly to research and development of the network, while the rest is going to DFINITY’s Ecosystem Venture Fund
  • Participants include Polychain Capital, Andreessen Horowitz, CoinFund, Multicoin Capital, and Greycroft Partners.
• Airdrop (May 2018)
  • $35 million worth of $ICP tokens (0.80% of the initial supply) were airdropped to early supporters, valuing the project at $1.89 billion.
  • Airdrop participants received their IOU $ICP tokens in September 2020, with a monthly distribution schedule of one year from mainnet launch, which began on May 10, 2021.
• Private Sale (Aug 2018)
  • 110 participants contributed $102 million for 4.96% of the initial token supply at a price of 4 CHF (around $4) per $ICP token.
  • This allocation came with a monthly vesting schedule of one year from mainnet launch.
  • Participants in this round include Andreessen Horowitz, Polychain Capital, SV Angel, Aspect Ventures, Electric Capital, ZeroEx, Scalar Capital, and Multicoin Capital.

Community Links

• Website
• Whitepaper 
• Docs
• Twitter 
• Telegram
• Developer Discord
• Forum
• Blog
• Github
• IC Dashboard
• Youtube