Internet Computer Wiki - User contributions [en]

IC message routing layer

2025-07-08T13:15:19Z

Jessie.mongeon:

== Overview ==
The Internet Computer (IC) achieves its security and fault tolerance by replicating computation across node machines located in various independent data centers across the world. For scalability reasons, the Internet Computing Protocol (ICP) composes the IC of multiple independent subnets. Each subnet can be viewed as an independent replicated state machine that replicates its state over a subset of all the available nodes.

Roughly speaking, replication is achieved by having the two lower ICP layers (P2P & Consensus) agree on blocks containing batches of messages to be executed, and then having the two upper ICP layers (Message Routing & Execution) execute them. Blocks are organized as a chain, where each block builds on the previous block. Each block has an associated height in the chain and one can look at execution of a batch of messages corresponding to the agreed upon block at height <math>x</math> by the upper layers as taking the replicated state of version <math>x-1</math>, and "applying" the batch to it to obtain replicated state of version <math>x</math>.

This document describes the role of the Message Routing layer in deterministic batch processing. Its responsibilities are:
* '''Coordinating the deterministic processing of batches:''' Fetching the right versions of the replicated state and the registry view to process the batch, triggering the deterministic processing, and committing the resulting replicated state.

* '''Deterministic processing of batches:''' Deterministic processing of batches relative to some replicated state and some registry view, resulting in an updated replicated state.

* '''Transferring message streams from one subnet to another:''' Moving streams from one subnet to another.

=== Remarks and Required Prior Knowledge ===

* The goal of this document is to provide the next level of detail compared to the material in the [https://internetcomputer.org/how-it-works "How it works" section of internetcomputer.org]. So it is recommended to study the material available there first.
* This page builds upon definitions made in the page describing the [[IC state manager|state manager]]. Please refer to this page for missing definitions related to the replicated state etc.
* Also see [https://mmapped.blog/posts/08-ic-xnet.html this] and [https://mmapped.blog/posts/02-ic-state-machine-replication.html this] blog post for some relevant and easier to digest background information.
* The documentation provided in this page may slightly deviate from the current implementation in terms of API as well as naming of functions, variables, etc. However, it still conveys the high-level ideas required to understand how the component itself works and how it interacts with other components. The implementation also contains several optimizations which are, however, not important for the conceptual overview here and therefore skipped.
* The notation used in this page is described [[Notation|here]].

=== Replicated vs. Canonical State ===
While the external API functions defined in this document will always take state in its implementation specific representation, i.e., as <code>ReplicatedState</code>, the operation the message routing component performs on the state based on its canonical representation, i.e., the <code>CanonicalState</code> is described. Given the relations between <code>ReplicatedState</code> and <code>CanonicalState</code> as defined in the specification of the state manager, this will implicitly define how an implementation needs to act on the respective parts of the <code>ReplicatedState</code>. An implicit conversion from <code>ReplicatedState</code> to <code>CanonicalState</code> is assumed whenever some state passed to this component via an API function is accessed.

== Guarantees Provided by Message Routing ==
Intuitively, the goal of the message routing layer is to enable transparent communication of canisters across subnets. This means that this layer formally does not add any guarantees the system provides, but simply needs to make sure that system invariants are preserved. Those system invariants include

* guaranteed replies (each canister-to-canister request will eventually receive a reply),

* canister-to-canister ordering (the order of canister-to-canister requests sent from one canister to another canister is preserved), and

* authenticity (only messages that come from canisters on the IC are processed).

To ensure that the system invariants hold, message routing needs to provide the following guarantees:

* Canister-to-canister messages will eventually be passed to the execution layer at the subnet the destination canister lives on exactly once.

* If a message can not be delivered, a synthetic reject response must be produced.

* If a canister <math>A</math> sends two messages <math>m_1</math> and <math>m_2</math> to a canister <math>B</math>, then, if none of them gets synthetically rejected, it must be guaranteed that they are put in canister <math>B</math>'s input queue from <math>A</math> in that order.

== Preliminaries ==
=== Description of the Relevant Parts of the Registry ===
The registry can be viewed as a central store of configuration information of the IC that is maintained by the NNS DAO. The content of the registry is held by a canister on the NNS subnet, and, roughly speaking, its authenticity is guaranteed by obtaining a certification on the content on behalf of the NNS using the certification mechanism as described in the [[IC state manager|state manager]] wiki page. Throughout this document it is assume that the registry contents are authentic.

The registry entries required by this component are set of all existing subnet ids, as well as a canister-to-subnet mapping subnet_assignment. Note that the actual implementation may choose to represent the required fields differently as long as they are conceptually equivalent.
<nowiki>Registry {
subnets : Set<SubnetId>,
subnet_assignment: CanisterId ↦ SubnetId
...
}</nowiki>

=== Description of the Relevant Canonical State ===
This section defined the parts of the canonical state which are relevant for the description of this component together with some constraints imposed on the replicated state. Abstractly the <code>CanonicalState</code> is defined as a nested partial map. For easier readability the entries of the outermost map are bundled together in a data structure with multiple fields where the names of the fields represent the keys in the respective partial map, e.g., for some <code>s : CanonicalState</code> one can use <code>s.ingress_queue</code> to access <code>s[ingress_queues]</code>

This section defines the individual fields of the type </code>CanonicalState</code> which are relevant in the context of this document. After that there are more details about the datatypes of the individual fields. There is a distinction made between the parts which are exclusively visible to message routing, and the parts which are also visible to the execution layer.

'''Parts visible to message routing and execution'''
<nowiki>CanonicalState {
...
ingress_queues : IngressQueues,
input_queues : InputQueues,
output_queues : OutputQueues,
...
}</nowiki>

'''Parts visible to Message Routing only'''
<nowiki>CanonicalState {
...
streams : Streams,
expected_xnet_indices : Set<(SubnetId × StreamIndex)>
...
}</nowiki>

Even though there are parts of the state that are accessed by both message routing and execution, one can enforce a conceptual boundary between them. In particular, for input queues, message routing will only ever push messages to them, whereas for output queues, message routing will only ever pull messages from them. The opposite holds for the execution environment.

==== Abstract Queues ====
Define a generic queue type <code>Queue<T></code> which has the following fields:
<nowiki>Queue<T> {
next_index : ℕ, // Rolling index; the index of the next message to be inserted
elements : ℕ ↦ T // The elements currently in the queue
}</nowiki>

Define a new queue as <code>new_queue : Queue<T></code> with <code>new_queue.elements = ∅</code> and <code>new_queue.next_index = 1</code>. Furthermore, it has the following associated functions:

* <code>push</code> takes a queue and a partial map of integers mapping to T, and returns a new queue consisting of the old queue with the given values appended. It also updates the next_index field so that it points to the index after the last inserted message.
<nowiki>push : Self × (ℕ ↦ T) → Self
push(self, values) :=
self with
├─ next_index := self.next_index + |values|
└─ elements := self.elements
∪ { (i - 1 + k ↦ t) | i = self.next_index ∧
(j ↦ t) ∈ values ∧
k = rank(j, dom(values)) }</nowiki>

* <code>delete</code> removes the given elements from the queues keeping the <code>next_index</code>
<nowiki>% REQUIRE: values ⊆ self.elements
delete : Self × (ℕ ↦ T) → Self
delete(self, values) :=
self with
├─ next_index := self.next_index
└─ elements := self.elements
\ values</nowiki>

* <code>clear</code> removes all elements from the queues keeping the next_index
<nowiki>clear : Self → Self
clear(self) :=
self with
├─ next_index := self.next_index
└─ elements := ∅</nowiki>

Partial maps of type <code>SomeIdentifier ↦ Queue<T></code> are often used, in which case the following shorthand notation is used. With <code>q</code> being a queue of the aforementioned type, and <code>v</code> being a partial map of type <code>(SomeIdentifier × ℕ) ↦ T</code>, define the following semantic for the functions <code>f ∈ { push, delete }</code> associated to <code>Queue<T></code>:
<nowiki>f_map : (SomeIdentifier ↦ Queue<T>) × ((SomeIdentifier × ℕ) ↦ T) → (SomeIdentifier ↦ Queue<T>)
f_map(q, v) = { (id ↦ queue') | (id ↦ queue) ∈ q ∧
(id ↦ values) ∈ v ∧
queue' = f(queue, values)
} ∪
{ (id ↦ queue') | (id ↦ values) ∈ v ∧
∄ (id ↦ ·) ∈ q ∧
queue' = f(Queue<T>::new_queue, values)
} ∪
{ (id ↦ queue) | (id ↦ queue) ∈ q ∧
∄ (id ↦ ·) ∈ v
}</nowiki>

For the functions <code>f ∈ { clear }</code> use
<nowiki>f_map : (SomeIdentifier ↦ Queue<T>) → (SomeIdentifier ↦ Queue<T>)
f_map(q) = { (id ↦ queue') | (id ↦ queue) ∈ q ∧
queue' = f(queue)
}</nowiki>

Henceforth the <code>map</code> postfix will be omitted in <code>f_map</code> and simply use <code>f</code> if it is clear from the input type that the map variant of <code>f</code> should be used.

==== Indices ====
Define an <code>Index</code> to be an arbitrary length sequence, where every element in the sequence up to the last one can have an arbitrary type, and the last one is a natural number.
<nowiki>Index : X × ... × Y × ℕ</nowiki>

In addition the following semantic is defined:

* Define the prefix of an index Index <code>i := (x, …, y, seq_nr)</code> as <code>prefix(i) := i[1…|i| - 1] = (x, …, y)</code>, i.e., it contains all elements of i except the last one.

* Define the postfix of an Index <code>i := (x, …, y, seq_nr)</code> as </code>postfix(i) := i[|i|] = seq_nr</code>, i.e., the last element of the index sequence. As already mentioned, the postfix of an index is required to be a natural number.

* For an <code>Index i</code>, the operation <math>i + 1</math> is defined as <code>concatenate(prefix(i), postfix(i) + 1)</code>.

* Two indices, <code>Index i</code> and <code>Index j</code>, are incomparable if <code>prefix(i) ≠ prefix(j)</code>.

* For two indices, <code>Index i</code> and <code>Index j</code>, it is the case that <math>i \leq j</math> if <code>prefix(i) = prefix(j)</code> and <code>postfix(i) ≤ postfix(j)</code>.

==== Queues ====

Three different types of queues exist in the replicated state: ingress queues, input queues, and output queues. Ingress queues contain the incoming messages from users (i.e., ingress messages). Input queues contain the incoming canister-to-canister messages. Output queues contain the outgoing canister-to-canister messages.

Ingress queues are organized on a per destination basis. Messages in ingress queues are indexed by a concrete instance of Index called <code>IngressIndex</code>, which is a tuple consisting of the destination canister ID and a natural number, i.e.,
<nowiki>IngressIndex : CanisterId × ℕ</nowiki>

Input queues and output queues are organized on a per-source-and-destination basis. Messages in input- and output queues are indexed by a concrete instance of Index called QueueIndex, which is defined as follows:
<nowiki>QueueIndex : CanisterId × CanisterId × ℕ</nowiki>

The type representing all of the ingress queues is defined as follows:
<nowiki>IngressQueues : CanisterId ↦ Queue<Message>,</nowiki>
which means that <code>IngressQueues.elements : IngressIndex ↦ Message</code>.

The type representing all of the input queues is defined as follows:
<nowiki>InputQueues : (CanisterId × CanisterId) ↦ Queue<Message>,</nowiki>
which means that <code>InputQueues.elements : QueueIndex ↦ Message</code>.

The type representing all of the output queues is defined as follows:
<nowiki>OutputQueues : (CanisterId × CanisterId) ↦ Queue<Message>,</nowiki>
which means that <code>OutputQueues.elements : QueueIndex ↦ Message</code>.

==== Streams ====
Each individual <code>Stream</code> is scoped to a pair of subnets—the subnet a stream originates from and subnet the stream is targeted at. An individual stream is organized in multiple substreams identified by a <code>SubstreamId</code>. The concrete definition of <code>SubstreamId</code> is up to the implementation. In the current implementation <code>SubstreamId</code> is defined to be the unit type <code>()</code>, i.e., flat streams. Messages in streams are indexed by a concrete instance of <code>Index</code> called StreamIndex which is defined as follows:
<nowiki>StreamIndex : SubstreamId × ℕ</nowiki>
A <code>Stream</code> is comprised of a sequence of <code>Signal</code> messages <code>signals</code> and a sequence of canister-to-canister messages <code>msgs</code>.
<nowiki>Stream {
signals : StreamIndex ↦ {ACCEPT, REJECT},
msgs : SubstreamId ↦ Queue<Message>
}</nowiki>
which means that <code>Stream.msgs.elements : StreamIndex ↦ Message</code>.

While the subnet the stream originates from is implicitly determined, the target subnet needs to be made explicit. Hence, a data structure Streams is defined holding all streams indexed by destination subnetwork:
<nowiki>Streams : SubnetId ↦ Stream</nowiki>

Notation may be sometimes abused and directly access the fields defined for an individual <code>Stream</code> on the Streams type, in which case maps of the following type are obtained:
<nowiki>Streams.signals : SubnetId ↦ (StreamIndex ↦ {ACCEPT, REJECT})

Streams.msgs : SubnetId ↦ (SubstreamId ↦ Queue<Message>)</nowiki>

==== (Certified) Stream Slices ====
<code>StreamSlices</code> and <code>CertifiedStreamSlices</code>, respectively, are used to transport streams from one to an other subnet within <code>XNetPayloads</code> that are part of consensus blocks. Essentially, a <code>StreamSlice</code> is a slice of a stream which retains the begin and the end of the original stream. A <code>StreamSlice</code> is wrapped in a <code>CertifiedStreamSlice</code> for transport so that authenticity can be guaranteed. Neither <code>CertifiedStreamSlices</code> nor <code>StreamSlices</code> are ever explicitly created within message routing, but instead one relies on the encoding and decoding routines provided by the state manager: A <code>CertifiedStreamSlice</code> is created by calling the respective encoding routine of the state manager. Such a <code>CertifiedStreamSlice</code> can then be decoded into a <code>StreamSlice</code> using the corresponding decoding routine provided by the state manager.
<nowiki>StreamSlice {
stream : Stream,
begin : Set<StreamIndex>,
end : Set<StreamIndex>
}</nowiki>

<nowiki>CertifiedStreamSlice {
payload : PartialCanonicalState
witness : Witness
signature : Certification
}</nowiki>

For the precise relation of <code>StreamSlice</code> and <code>CertifiedStreamSlice</code>, refer to the specification of the state manager.

==== Batch ====
A batch consists of multiple elements including an <code>ingress_payload</code> constituting a sequence of ingress messages, and an <code>xnet_payload</code>.
<nowiki>Batch {
batch_number : Height
registry_version : RegistryVersion
ingress_payload : ℕ ↦ Message
xnet_payload : SubnetId ↦ CertifiedStreamSlice
requires_full_state_hash : { TRUE, FALSE }
}</nowiki>

==== Decoded Batch ====
A decoded batch represents a batch where all transport-specific things are decoded into the format suitable for processing and some things which are not required inside the deterministic state machine are stripped off.
<nowiki>DecodedBatch {
ingress_payload : ℕ ↦ Message
xnet_payload : SubnetId ↦ StreamSlice
}</nowiki>

Currently this only means decoding the <code>CertifiedStreamSlices</code> into <code>StreamSlices</code> because it is assumed that the ingress payload is suitable to be processed right away. Formally there is a function, which, based on the own subnet id and the given batch decodes the batch into a decoded batch:
<nowiki>decode : SubnetId × Batch → DecodedBatch
decode(own_subnet, b) :=
DecodedBatch {
with
├─ ingress_payload := b.ingress_payload
└─ xnet_payload :=
{ (src_subnet ↦ slice) |
(src_subnet ↦ cert_slice) ∈ b.xnet_payload ∧
slice = StateManager.decode_valid_certified_stream(own_subnet,
cert_slice
)
}
}</nowiki>

== Message Routing ==
Message routing is triggered by incoming batches from consensus. For each <code>Batch b</code>, message routing will perform the following steps:
[[File:Message Routing Components.png|thumb|Components interacting with message routing during a deterministic processing round]]
[[File:MR Interactions.png|thumb|Interactions of message routing with other components during a deterministic processing round]]

* Obtain the <code>ReplicatedState s</code> of the right version w.r.t. <code>Batch b</code>.

* Submit <code>s</code>, <code>decode(own_subnet, b)</code> for processing by the deterministic state machine comprised of the message routing and execution layer. This includes

** An induction phase (cf. <code>pre_process</code>), where the valid messages in <code>decode(own_subnet, b)</code> are inducted. Among others, a message m in a <code>StreamSlice</code> from subnet <code>X</code> is considered valid if <code>registry.get_registry_at(b.registry_version).subnet_assignment</code> maps <code>m.src</code> to <code>X</code>.

** An execution phase (cf. <code>execute</code>), which executes messages available in the induction pool.

** An XNet message routing phase (cf. <code>post_process</code>), which moves the messages produced in the execution phase from the per-session output queues to the subnet-to-subnet streams according to the mapping defined by the subnet assignment in the registry.

* Commit the replicated state, incrementally updated by the previous steps, to the state manager via <code>commit_and_certify</code>.

=== Deterministic State Machine ===
As shown in the sequence diagram above, the deterministic state machine implemented by message routing and execution applies batches provided by consensus to the appropriate state, additionally using some meta information provided by the registry. As discussed above, state of type <code>CanonicalState</code> is used to generally describe the operations of the message-routing-related operations of this component.

[[File:Message-routing-data-flow.png|thumb|Data flow during batch processing]]

The flow diagram below details the operation of the component. Its operation is logically split into three phases.

* The induction phase, where the messages contained in the batch are preprocessed. This includes extracting them from the batch and, subject to their validity and the decision of VSR, added to the induction pool or not.

* The execution phase, where the hypervisor is triggered to perform an execution cycle. The important thing from a message routing perspective is that it will take messages from the input queues and process them, which causes messages to be added to the output queues.

* The XNet message routing phase, where the messages produced in the execution cycle are post-processed. This means that they are taken from the canister-to-canister output queues and routed into the appropriate subnet-to-subnet streams.

All messages will be added to the respective destination queue/stream preserving the order they appear in the respective source stream/queue.

==== API ====
The deterministic state machine does not provide any external API functions. It only provides the following functions resembling the state transformations implemented by the individual steps of the deterministic state machine depicted above. Refer to the previous section for context regarding when the individual functions are called.

* <code>pre_process(s : CanonicalState, subnet_assignment : (CanisterId ↦ SubnetId), b : DecodedBatch) → CanonicalState</code>: Triggers the induction phase.

* <code>execute(s : CanonicalState) → CanonicalState</code>: Triggers the execution phase.

* <code>post_process(s : CanonicalState, subnet_assignment : (CanisterId ↦ SubnetId)) → CanonicalState</code>: Triggers the XNet message routing phase.

==== Abstractions of Other Parts of the System ====

'''Valid Set Rule (VSR)'''
The VSR is a component that makes the decision of whether to <code>ACCEPT</code> a message or to <code>REJECT</code> a message. For message routing, <code>ACCEPT</code> has the semantic that the execution layer takes responsibility for the message, whereas <code>REJECT</code> has the semantic that the message is dropped and may require action from the message routing layer.

The operation of the VSR on ingress messages is defined as follows, where <code>vsr_check_ingress : CanonicalState × Batch → Set<ℕ></code> is a deterministic function returning the indices of the messages in the ingress payload accepted by the VSR, which returns a possibly empty set of index-message tuples corresponding to the accepted messages in the ingress_payload of the batch. The set is determined by the concrete implementation of the VSR.
<nowiki>VSR(state, batch).ingress :=
{ ((m_i.dst, j) ↦ m_i) | (i ↦ m_i) ∈ batch.ingress_payload
∧ i ∈ vsr_check_ingress(state, batch)
∧ j = Rank(i, vsr_check_ingress(state, batch))
}</nowiki>

The VSR for cross-net messages is defined as follows, where <code>vsr_check_xnet : CanonicalState × Batch → Set<(SubnetId × StreamIndex)></code> is a deterministic function that determines the indices of the messages in the individual substreams contained in <code>xnet_payload</code> to be inducted.

It is required that the implementation of the VSR (or the layer above) makes sure that all reply messages are accepted by the VSR. Formally this means that for any valid State-Batch combination <code>(s, b)</code> it holds that for all <code>(subnet, index)</code> so that <code>b.xnet_payload[subnet].msgs[index]</code> is a reply message that <code>(subnet, index) ∈ vsr_check_xnet(s, b)</code>.

Based on this rule one can straight-forwardly define the interface behavior of the VSR.

<nowiki>VSR(state, batch).xnet :=
{ (index ↦ msg) |
(index ↦ msg) ∈ batch.xnet_payload.msgs ∧
index ∈ vsr_check_xnet(state, batch)
}

VSR(state, batch).signals :=
{ (concatenate(subnet, index) ↦ ACCEPT) |
(subnet ↦ stream) ∈ batch.xnet_payload ∧
(index ↦ msg) ∈ stream.msgs ∧
(subnet, index) ∈ vsr_check_xnet(state, batch)
}
∪ { (concatenate(subnet, index) ↦ REJECT) |
(subnet ↦ stream) ∈ batch.xnet_payload ∧
(index ↦ msg) ∈ stream.msgs ∧
(subnet, index) ∉ vsr_check_xnet(state, batch)
}</nowiki>

'''Scheduler and Hypervisor'''. From the point of view of message routing, one can look at the the scheduler and the hypervisor together as one component. The functionality of scheduler and hypervisor are modeled as a deterministic function <code>schedule_and_execute : CanonicalState → (IngressIndex ↦ Message) × (QueueIndex ↦ Message) × (QueueIndex ↦ Message)</code> which computes the change set introduced by the Scheduler and the Hypervisor. It takes messages from the input queues, executes them and puts new messages to the output queues.

This function will be used lated when it's described how the state transition function <code>execute(CanonicalState) → CanonicalState</code> transforms the state. For the sake of compact notation, the following fields are used to access the individual return values of the schedule_and_execute function.

* <code>consumed_ingress_messages</code>, which contains a partial map <code>IngressIndex ↦ Message</code> containing all consumed ingress messages.

* <code>consumed_xnet_messages</code>, which contains a partial map <code>QueueIndex ↦ Message</code> containing all consumed cross-net messages.

* <code>produced_messages</code>, which contains a partial map <code>QueueIndex ↦ Message</code> containing all produced messages, where the order of the messages implied by the queue index determines the order in which they need to be added to the queues.

==== Description of the State Transitions ====

'''Induction Phase'''. In the induction phase, one starts off with a <code>CanonicalState S</code>, some <code>subnet_assignment</code> and a <code>DecodedBatch b</code> and applies <code>b</code> to <code>S</code> relative to <code>subnet_assignment</code> to obtain <code>S'</code>, i.e., one computes <code>S' = pre_process(S, subnet_assignment, b)</code>.

This section describes things w.r.t. to a version of the VSR which will accept all messages, while in reality the VSR may reject some messages in case canisters migrate across subnets or subnets are split. So while the possibility that messages can be REJECTed by the VSR would require specific action of the message routing layer those actions are omitted here for simplicity as they are not crucial to understand the basic functionality of message routing.

Before defining the actual state transition, a couple of helper functions are defined. First, it is needed to define a function that determines the order of the messages in the queues based on the order of the messages in the incoming stream slices.
<nowiki>% REQUIRES: ∄ (s1 ↦ m1), (s2 ↦ m2) ∈ S :
% └─ m1 = m2 ∧ s1 ≠ s2
%
% ENSURES: ∀ S satisfying the precondition above,
% └─ ∀ (q1 ↦ m1), (q2 ↦ m2) ∈ queue_index(S) :
% ├─ ∃ s1, s2 :
% │ └─ (s1 ↦ m1) ∈ S ∧ (s2 ↦ m2) ∈ S ∧
% └─ (m1.dst = m2.dst ∧ s1 ≤ s2) ==> q1 ≤ q2
%
queue_index: ((SubnetId × StreamIndex) ↦ Message) → ((CanisterId × ℕ) ↦ Message))
queue_index(S) := {
% There is no concrete implementation of this function provided as there are
% multiple possible implementations and the choice for one also depends on
% how priorities/fairness etc. are handled.
%
% A trivial implementation is to iterate over the given stream slices S per
% subnet and for each individual slice iterate over all the messages in the
% order they appear in the slice and push each message m on the right queue,
% i.e., the one belonging to the destination canister. This is also the way
% things are currently implemented.
}</nowiki>

Based on this a function can now be defined that maps over the indexes of the valid XNet messages.
<nowiki>map_valid_xnet_messages : (SubnetId ↦ Slice) ×
(CanisterId ↦ SubnetId) →
((CanisterId × ℕ) ↦ Message)
map_valid_xnet_messages(slices, subnet_assignment) :=
queue_index({ ((subnet, index) ↦ m) | (subnet ↦ slice) ∈ slices ∧
(index ↦ m) ∈ slice.msgs ∧
subnet_assignment[m.src] = subnet ∧

})</nowiki>

Finally, the state <code>S'</code> resulting from computing <code>pre_process(S, b)</code> can be defined:
<nowiki>S with
% Append the ingress messages accepted by the VSR to the appropriate ingress_queue
ingress_queues := push(S.ingress_queues, VSR(S, b).ingress)

% Append the canister to canister messages accepted by the VSR to the appropriate
% input queue.
input_queues := push(S.input_queues,
map_valid_xnet_messages(VSR(S, b).xnet, subnet_assignment)
)

% Garbage collect the messages which have accepted by the target subnet.
% (As soon as the VSR does no longer ACCEPT all messages, one would have
% to make sure that rejected messages are appropriately re-enqueued in
% the streams)
streams.msgs := delete(S.streams.msgs,
{ (concatenate(subnet, index) ↦ msg) |
(subnet ↦ slice) ∈ b.xnet_payload ∧
(i ↦ ·) ∈ slice.signals ∧
index = concatenate(subnet, i)
}
)

% Add the signals reflecting the decisions made by the VSR in the current round and
% garbage collect the signals which have already been processed on the other subnet
% (one knows that a signal has been processed when the message is no longer included
% in a given slice).
streams.signals := S.streams.signals
∪ VSR(S, b).signals
\ { (index ↦ signal) |
(subnet ↦ slice) ∈ b.xnet_payload ∧
(i ↦ signal) ∈ S.streams[subnet].signals ∧
index = concatenate(subnet, i) ∧
j ∈ slice.begin ∧
i < j
}

% Update the expected XNet indexes so that the block maker can compute which messages
% to include in a block referencing this state.
expected_xnet_indices := { index | index ∈ S.expected_xnet_indices ∧
∄ (i ↦ ·) ∈ b.xnet_payload.msgs.elements :
└─ prefix(index) = prefix(i)
} ∪
{ index + 1 | index ∈ max(dom(b.xnet_payload.msgs.elements)) }</nowiki>

'''Execution Phase'''. In the execution phase, one starts off with a <code>CanonicalState S</code>, schedules messages for execution by the hypervisor, and triggers the hypervisor to execute them, i.e., one computes <code>S' = execute(S)</code> where <code>S</code> is the state after the induction phase. From the perspective of message routing, the state <code>S'</code> resulting from computing <code>execute(S)</code> looks as follows:
<nowiki>S with
% Delete the consumed ingress messages from the respective ingress queues
ingress_queues := delete(S.ingress_queue, schedule_and_execute(S).consumed_ingress_messages)

% Delete the consumed canister to canister messages from the respective input queues
input_queues := delete(S.input_queues, schedule_and_execute(S).consumed_xnet_messages)

% Append the produced messages to the respective output queues
output_queues := push(S.output_queues, schedule_and_execute(S).produced_messages)

% Execution specific state is transformed by the execution environment; the precise transition
% function is out of scope here.</nowiki>

'''XNet Message Routing Phase'''. In the XNet message routing phase, one takes all the messages from the canister-to-canister output queues and, according to the subnet_assignment, puts them into a subnet-to-subnet stream, i.e., it computes <code>S' = post_process(S, registry)</code>, where <code>S</code> is the state after the execution phase and registry represents a view of the registry.

Before defining the state transition, a helper function is defined to appropriately handle messages targeted at canisters that do not exist according to the given subnet assignment.
<nowiki>% Remove all messages from output queues targeted at non-existent canisters according
% to the subnet assignment.
filter : ((CanisterId × CanisterId) ↦ Queue<Message>) × (CanisterId ↦ SubnetId) → ((CanisterId × CanisterId) ↦ Queue<Message>)
filter(queues, subnet_assignment) :=
delete(queues, { (q_index ↦ msg) | (q_index ↦ msg) ∈ queues.elements ∧
q_index = (·, dst, ·) ∧
dst ∉ dom(subnet_assignment)
}
)
</nowiki>

Produce <code>NON_EXISTENT_CANISTER</code> replies telling the sending canister that the destination canister does not exist.
<nowiki>% Produce NON_EXISTENT_CANISTER messages to be pushed to input queues
% of the senders of messages where the destination does not exist
non_existent_canister_replies : ((CanisterId × CanisterId) ↦ Queue<Message>) × (CanisterId ↦ SubnetId) → (QueueIndex ↦ Message)
non_existent_canister_replies(queues, subnet_assignment) :=
{ ((dst, src, i) ↦ NON_EXISTENT_CANISTER) | (q_index ↦ msg) ∈ queues.elements ∧
q_index = (src, dst, i) ∧
dst ∉ dom(subnet_assignment)
})</nowiki>

''Non flat streams.'' As already mentioned before, the specification leaves it open whether one flat stream is produced per destination subnet, or whether each of the streams has multiple substreams—this can be decided by the implementation. To enable this, a <code>StreamIndex</code> is defined to be a tuple of <code>SubstreamId</code> and a natural number. If there is a flat stream, <code>StreamIndex</code> is defined to be the unit type <code>()</code> which effectively means that the implementation can use natural numbers as stream index as one does not need to make the <code>SubstreamId</code> explicit in this case. In contrast, if there is a per-destination (or per-source) substreams, <code>StreamIndex</code> is defined to be a <code>CanisterId</code>.

Formally, this means that the implementation must fix a mapping function that—based on a given prefix of a <code>QueueIndex</code>, i.e., a src-dst tuple—decides on the prefix of the <code>StreamIndex</code>, i.e., the SubstreamId.
<nowiki>substream_id: (CanisterId × CanisterId) → SubstreamId

% Definition of substream_id for flat streams
substream_id((src, dst)) := ()

% Definition of substream_id for per-destination canister substreams
substream_id((src, dst)) := dst
</nowiki>

''Description of the actual state transition''. The state <code>S'</code> resulting from computing <code>post_process(S, subnet_assignment)</code> is defined as follows:
<nowiki>S with
% Clear the output queues
output_queues := clear(S.output_queues)

% Route the messages produced in the previous execution phase to the appropriate streams
% taking into account ordering and capacity management constraints enforced by stream_index.
streams.msgs := {
let msgs = S.streams.msgs

% Iterate over filtered messages preserving order of messages in queues.
for each (q_index ↦ msg) ∈ filter(S.output_queues, subnet_assignment)
msgs = push(msgs, { (concatenate(substream_id(prefix(q_index)), postfix(q_index)) ↦ msg) })

return msgs
}

% Push NON_EXISTENT_CANISTER replies to input queues of the respective canisters
input_queues := push(S.input_queues,
non_existent_canister_replies(S.output_queues, subnet_assignment))</nowiki>

''Ordering of Messages in the Stream & Fairness''. As long as the invariant that the canister-to-canister ordering of messages is preserved when iterating over the filtered messages in the state transition described above, the implementation can take the freedom to apply alternative orderings.

Also note that, while the state transition defined above empties the output queues completely, this is not crucial to the design and one could hold back messages as long as this does not violate the ordering requirement.

== XNet Transfer ==
After calling <code>commit_and_certify</code> at the end of a deterministic processing cycle, the state manager will take care of getting the committed state certified. Once certification is complete, the certified stream slices can be made available to block makers on other subnets. The <code>XNetTransfer</code> subcomponent is responsible to enable this transfer. It consists of

[[File:Xnet.png|thumb|XNet transfer component diagram]]

* An <code>XNetEndpoint</code> which is responsible for serving certified stream slices and making them available to <code>XNetPayloadBuilders</code> on other subnetworks.

* An <code>XNetPayloadBuilder</code>, which allows the block makers to obtain an <code>XNetPayload</code> containing the currently available certified streams originating from other subnetworks. The <code>XNetPayloadBuilder</code> obtains those streams by interacting with <code>XNetEndpoints</code> exposed by other subnets. The <code>XNetPayloadBuilder</code> also provides functionality for notaries to verify <code>XNetPayloads</code> contained in block proposals.

There are no specifications about the protocol run between the <code>XNetEndpoint</code> and the <code>XNetPayloadBuilder</code> to transfer the streams between two subnetworks. The only requirement is that certified streams made available by an <code>XNetEndpoint</code> of an honest replica on some source subnetwork, they can be obtained by an <code>XNetPayloadBuilder</code> of an honest replica on the destination subnetwork and that the information regarding which endpoints to contact is available in the Registry.

=== Properties and Functionality ===
Assume an XNet transfer component on a replica part of subnet <code>own_subnet</code>. The interface behavior of the XNet transfer component will guarantee that for any payload payload produced via

<nowiki>get_xnet_payload(registry_version, reference_height, past_payloads, size_limit)</nowiki>

For any <code>(remote_subnet ↦ css) ∈ payload</code>:

* <code>StateManager.decode_certified_stream(registry_version, own_subnet, remote_subnet, css)</code> succeeds, i.e., returns a valid slice slice that is guaranteed to come from remote_subnet.

* Furthermore, for each slice it will hold that a soon as the state corresponding to height <code>h = reference_height + |past_payloads|</code> is available that <code>concatenate(remote_subnet, min(dom(slice.msgs.elements))) ∈ StateManager.get_state_at(h).expected_indexes</code>. This means that the streams will start with the expected indexes stored in the previous state, i.e., they gap freely extend the previously seen streams.

Payloads verified using <code>validate_xnet_payload</code> are accepted if they adhere to those requirements, and are rejected otherwise.

=== XNet Endpoint ===
The <code>XNetEndpoint</code> serves the streams available on some subnet to other subnets. For an implementation this will typically mean that there is some client which will handle querying the API of the <code>XNetEndpoint</code> on the remote subnet in question. The following abstraction is used to avoid explicitly talking about this client: Assume that there is a function <code>get : SubnetId → XNetEndpoint</code> which will return an appropriate instance of <code>XNetEndpoint</code> which can directly be queried using the API described below.

[[File:Xnet-sequence.png|thumb|XNet transfer sequence diagram]]

* <code>get_stream(subnet_id : SubnetId, begin : StreamIndex, msg_limit : ℕ, size_limit : ℕ) → CertifiedStreamSlice</code>: Returns the requested certified stream slice in its transport format.

It is required that an honest <code>XNetPayloadBuilder</code>-<code>XNetEndpoint</code> pair is able to successfully obtain slices over this API.

Looking at the bigger picture, the intuition for why this will yield a secure system is that in each round a new pair of block maker and endpoint will try to pull over a stream, which, in turn, means that eventually an honest pair will be able to obtain the stream and include it into a block.

=== XNet Payload Builder ===
The <code>XNetPayloadBuilder</code> builds and verifies payloads whenever requested to do so by the block maker. The rules for whether a payload is considered valid or not must be so that every notary is guaranteed to make the same decision on the same input and that a payload built by an honest payload builder will be accepted by honest validators. Essentially the rules resemble what is described in the section on properties and functionality. However, given that the execution may be behind one can not directly look up the expected indexes in the appropriate state but need to compute it based on the referenced state and the payloads since then. Below, a figure is provided to illustrate the high-level functionality: generally speaking blocks are considered valid if they adhere to the rules described in the figure and are considered invalid otherwise.

[[File:Payload-building.png|thumb|Rules for payload building]]

This section formally defines the operation of the component. The following helper functions are first defined. Assume that <code>XNetPayloadBuilder</code> has an associated field <code>own_subnet</code> which is passed whenever constructing an <code>XNetPayloadBuilder</code>:
<nowiki>new : SubnetId → Self
new(own_subnet) :=
XNetPayloadBuilder {
with
└─ own_subnet := own_subnet
}
</nowiki>

The API defines the past_payloads as a vector where the past payloads are ordered with respect to the corresponding height in the chain. While this ordering allows for a more efficient implementation of the functions below it does not matter on a conceptual level. Hence resort to looking at it as a set for the sake of simplicity.

* The function <code>slice_indexes</code> returns the set of expected indices for the block to be proposed, solely based on a set of Slices.
<nowiki>% Take the maximum index for each individual (sub-)stream in the given set of slices and add
% 1 to obtain the next indexes one would expect when solely looking at the past payloads but
% ignoring the state.
slice_indexes : (SubnetId ↦ StreamSlice) → Set<(SubnetId × StreamIndex)>
slice_indexes(slices) := { i + 1 | i ∈ max(dom(slices.msgs.elements)) }</nowiki>

* The function <code>state_and_payload_indexes</code> returns the set of expected indices for the block to be proposed, taking into account both the expected indices in the given replicated state and the more recent messages in the given slices from the past payloads.
<nowiki>% Take the expected indexes from the state, remove whatever index appears in the given
% slices and add the expected indexes according to the streams in the slices.
%
% FAIL IF: ∃ i, j ∈ state_and_payload_indexes(state, slices) :
% prefix(i) = prefix(j) ∧ postfix(i) ≠ postfix(j)
%
state_and_payload_indexes : ReplicatedState ×
(SubnetId ↦ StreamSlice) →
Set<(SubnetId × StreamIndex)>
state_and_payload_indexes(state, slices) := state.expected_xnet_indices
\ dom(slices.msgs.elements)
∪ slice_indexes(slices)</nowiki>

* The function <code>expected_indexes</code> returns the set of expected indices for the block to be proposed, taking into account both the expected indices in the given replicated state and the more recent messages in the given past payloads.
<nowiki>% Decode the slices in the given payload and compute the expected indexes using the
% expected_indexes function above
expected_indexes : SubnetId ×
ReplicatedState ×
(SubnetId ↦ StreamSlice) →
Set<(SubnetId × StreamIndex)>
expected_indexes(own_subnet, state, slices) :=
state_and_payload_indexes(
state,
{ (src ↦ slice) | payload ∈ slices ∧
(src ↦ cert_slice) ∈ payload ∧
slice = StateManager.decode_valid_certified_stream(own_subnet,
cert_slice)
}
)</nowiki>

==== Creation of XNet Payloads ====
Based on the functions above, it is possible to define the function <code>get_xnet_payload : Height × Height × Set<XNetPayload> → XNetPayload</code>. Note that the gap-freeness of streams is an invariant of the datatype, which is why the rule for gap-freeness is not explicitly included here.
<nowiki>% Build an xnet payload containing the currently available streams. The begin is either given
% by the expected index, and, if there is no expected index for a given prefix, the index
% ONE is expected.
%
% ENSURES: size_of(get_xnet_payload(self, ·, ·, ·, size_limit)) ≤ size_limit ∧
% each payload output by get_xnet_payload will be accepted by validate_xnet_payload
%
get_xnet_payload : Self × RegistryVersion × Height × Vec<XNetPayload> × ℕ → XNetPayload
get_xnet_payload(self, registry_version, reference_height, past_payloads, size_limit) :=
{ (remote_subnet ↦ slice) |
S = StateManager.get_state_at(reference_height)
∧ subnets = Registry::get_registry_at(registry_version).subnets \ { self.own_subnet }
∧ (remote_subnet, begin_index) ∈
expected_indexes(self.own_subnet, S, past_payloads)
∪ { (subnet_id, StreamIndex::ONE) |
subnet_id ∈ subnets
\ { s | (s, ·) ∈ expected_indexes(self.own_subnet,
S,
past_payloads)
}
}
% msg_limit and size limit need to be set by the implementation as appropriate
% to satisfy the post condition
∧ slice = XNetEndpoint::get(subnet).get_stream(remote_subnet, begin_index, ·, ·)
∧ ERR ≠ StateManager.decode_certified_stream(registry_version,
self.own_subnet,
remote_subnet,
slice)
}</nowiki>

==== Validation of XNet Payloads ====
Validation of XNetPayloads works analogously to the creation. The function <code>validate_xnet_payload</code> is defined as follows, where it is assumed that it evaluates to false in case an error occurs. Again, note that the gap-freeness of streams is an invariant of the datatype, which is why the rule for gap-freeness is not explicitly included here.
<nowiki>% Check whether a given xnet payload was built according to the rules given above.
%
% FAIL IF: size_of(payload) > size_limit
%
validate_xnet_payload : Self × RegistryVersion × Height × Vec<XNetPayload> × XNetPayload × ℕ → Bool
validate_xnet_payload(self, registry_version, reference_height, past_payloads, payload, size_limit) :=
S = StateManager.get_state_at(reference_height) ∧
∀ (remote_subnet ↦ css) ∈ payload :
{
slice = StateManager.decode_certified_stream(registry_version,
self.own_subnet,
remote_subnet,
css) ∧
∀ index ∈ min(dom(slice.msgs.elements)) :
{
(remote_subnet, index) ∈ expected_indexes(S, past_payloads) ∨
index = (remote_subnet, StreamIndex::ONE)
}
}</nowiki>

Maturity

2025-07-01T13:18:00Z

Jessie.mongeon:

{{#externalredirect: https://learn.internetcomputer.org/hc/en-us/articles/34084120668692-Neurons#01JJ7BJX36NH538SCDQFHSJSVD}}

Maturity represents the voting rewards accumulated in a neuron. Each day the network rewards participants by allocating to every voting neuron a portion of the total reward, based both on its voting power at the time proposals were made, and the number of proposals it voted on.

Please note that different tax authorities may take different views on the taxation status of the voting rewards. Neuron owners who receive voting rewards and convert them to ICP should consult appropriate professionals.

For those who wish to compound the voting power in their neuron, the most natural activity is to "stake maturity" on a regular basis. If you wish to liquidate rewards you earn from the neuron and convert them to ICP, you can "spawn" maturity into a reward neuron.

Main Page

2025-07-01T13:10:03Z

Jessie.mongeon:

<templatestyles src="Template:Main_page/styles.css"/>

<div>

<div>

</div>

==Introduction to Internet Computer Protocol (ICP) Blockchain==


The [[Introduction_to_ICP | 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 and host a new generation of Web 3.0 services and applications that run solely from the blockchain, without the need for traditional IT. It can also play the role of Web 3.0 orchestrator, by interacting with other blockchains.

It has a completely unique design that reflects a ground-up rethink of blockchain architecture and the application of modern cryptography, [https://web.archive.org/web/20150914013643/http://dfinity.io/ which can be traced back to 2015]. It was built by the largest [https://dfinity.org/team ongoing R&D effort in crypto], which has employed many notable cryptographers, computer science researchers and engineers. The blockchain underwent genesis in May 2021 and became part of the public internet.

See more at [[Introduction to ICP]].

<div style="clear: both;"></div>

==Main Sections ==


<div id="audiences" class="mainpage_row">


<div class="mainpage_box overview" id="overview">
<h3>

<span>'''Overview''': ICP Blockchain and ICP Ecosystem</span>
</h3>
<div id="mainpage-users" title="Users" class="items">
* [[Introduction to ICP]] blockchain
* [[Popular Explainers of ICP |Popular explainers of ICP]] blockchain
* [https://internetcomputer.org internetcomputer.org website]
* [https://dashboard.internetcomputer.org ICP Network Dashboard]
* [[Web3: The bull case for the Internet Computer]]
* [[ICP Ecosystem Stats |ICP ecosystem stats]]
* [[ICP Community |ICP community]]
* [[ICP Tokenomics |ICP tokenomics]]
</div>
</div>


<div class="mainpage_box users">
<h3 class="mainpage_box_header_users">

<span>'''For Users''': Getting Started with ICP</span>
</h3>
<div id="mainpage-users" title="Users" class="items">
* Aquire an [[Internet Identity]] (not necessary, but highly recommended)
* [[Tutorials for acquiring, managing, and staking ICP |Managing and staking ICP tokens]]
* [https://internetcomputer.org/ecosystem/ Examples of ICP smart contracts and dapps]
* [https://support.dfinity.org/ DFINITY support center]
</div>
</div>


<div class="mainpage_box developers">
<h3>

<span>'''For Developers''': Building ICP Smart Contracts</span>
</h3>
<div id="mainpage-devs" title="Developers" class="items">
* [https://internetcomputer.org/docs/current/home Developer Documentation]
* [https://forum.dfinity.org/t/announcing-technical-working-groups/11781 Technical working groups]
* Launching an [[Service Nervous System (SNS) |SNS]] DAO
* Smart contracts with [[Bitcoin integration]]
* [[The Internet Computer for Ethereum Developers |ICP for Ethereum developers]]
* [https://forum.dfinity.org/ Developer forum] for ICP developers.
</div>
</div>
</div>


<div id="misc-news" class="mainpage_row nodes">

<div class="mainpage_box">
<h3>

<span>'''For Node Providers''': Joining ICP Network</span>
</h3>
<div id="mainpage-help-contribute" title="Support and Contributing" class="items">
*[[Node Provider Documentation]]
*[[Node Provider Roadmap]]
*[[Node Provider Troubleshooting]]
* Status of the network on [https://dashboard.internetcomputer.org ICP Dashboard]
* [[Node Provider Matrix channel|IC Node Provider Matrix channel]]
* ICP is a [[Sovereign Network]] using [[Deterministic Decentralization]] with [[Proof of Useful Work]] consensus
</div>
</div>

<div class="mainpage_box community">
<h3>

<span>'''For ICP Community''': Participating in ICP</span>
</h3>
<div id="mainpage-help-contribute" title="Support and Contributing" class=" items">
* [[Governance of the Internet Computer |ICP governance]]
* [[Contributing to the wiki]]
</div>
</div>

<div class="mainpage_box researchers">
<h3>

<span>'''For ICP Researchers''': Deep Dive into ICP</span>
</h3>
<div id="mainpage-researchers" title="Deep Dive into ICP" class=" items">
* [https://eprint.iacr.org/2022/087 "Internet Computer for Geeks" white paper]
* [[IC architecture overview]]
* [https://www.reddit.com/r/dfinity/comments/ozboyi/megathread_technical_amas/ Technical AMAs on Reddit by different IC and DFINITY teams]
</div>
</div>

</div>

<div style="background-color: #ffd700; padding: 10px; margin-bottom: 20px;">
<strong>Want to contribute to the IC Wiki? See [[Contributing_to_the_wiki |here]] </strong>
</div>

</div>

Decentralization in ICP: Protocol Governance

2025-06-30T22:02:06Z

Jessie.mongeon:

{{#externalredirect: https://learn.internetcomputer.org/hc/en-us/articles/33692645961236-Overview}}

==Summary==

As a blockchain protocol, decentralization is very important to the design and implementation of ICP. This article is one of a subset explaining the design intent and the current state of the world when it comes to ICP decentralization. Its main focus is analyzing '''protocol governance'''. To see the whole picture, it is recommended to see the following articles:

* [[Decentralization in ICP]]
* [[Decentralization in ICP: Critical Dapps on the IC]]
* [[Decentralization in ICP: Infrastructure Governance]]

==Background ==

The [[Network Nervous System]] (NNS) is an open algorithmic governance system that oversees the ICP network and the token economics. This governance system, the NNS, is controlled by a DAO of users all voting. The example below illustrates what this means in practice.

==Design Intent and how users join the NNS DAO ==

The NNS is designed to hold the following properties:

* '''Anyone can participate in the NNS DAO''' by staking ICP into neurons and voting in proposals. Each neuron has a voting power corresponding to the amount of ICP staked, how long it is staked for and how long the neuron has existed.
* NNS DAO controls everything in the network including software and hardware changes.
* NNS allows liquid democracy so stakers can have their neurons follow the votes of other neurons.
* Create a structured way for the network to quickly update itself (in comparison to other blockchains where upgrades can take a lot of time and manual effort).

==Example: Upgrading the network’s code ==

ICP is a network of nodes running “replica code” that is identical for each node. At the time of this writing, they were all running replica code version [https://dashboard.internetcomputer.org/proposal/107483 935b417d]. As usual, this [https://dashboard.internetcomputer.org/release/935b417d6f5dd2befa7f9ad7bfc975df32f8c641 particular replica version] has a lot of bug fixes, features, and optimizations. But more importantly, this code was accepted as the new version after a few steps:

1. Developers code up a new replica version

2. Developers submit the new replica version as a [https://dashboard.internetcomputer.org/proposal/107483 proposal to the NNS DAO]

3. NNS DAO votes on the proposal

4. If NNS DAO passes the proposal, the replica code is “blessed” (read: approved) and subsequent proposals update each of the subnets.

The NNS is the system (or “steering wheel” for the network) which is controlled by the DAO, so in the case of the Internet ComputerProtocol governance, what matters most is to evaluate decentralization of the NNS and DAO.

[[File:Nns proposal example.png |800px ]]

==Current State of Decentralization ICP ==

To see the latest measures of NNS decentralization, see: https://medium.com/@dfinity/nns-and-decentralization-5f4963e83df7

==See Also==
* [[Decentralization in ICP]]
* [[Decentralization in ICP: Infrastructure Governance]]
* [[Decentralization in ICP: Critical Dapps on the IC]]
* [[Weighted average of logs of NCs in Protocol]]
* [[Weighted average of logs of NCs in infrastructure]]

New Subnet Creation

2025-06-30T22:01:40Z

Jessie.mongeon:

{{#externalredirect: https://learn.internetcomputer.org/hc/en-us/articles/34209955782420-Subnet-Creation}}

Ever wondered about the meaning behind DFINITY? It’s Decentralized + Infinity. It’s named that way because the Internet Computer is designed to scale infinitely. It means that the Internet Computer can host an unlimited number of canisters (smart contracts), store an unlimited amount of memory, process an unlimited amount of transactions per second. In simple words, Internet Computer is designed to host even large scale social media platforms in a fully decentralized way.

There are two types of widely-used approaches to improve scalability. (1) Vertical Scaling, and (2) Horizontal Scaling. Vertical scaling means adding more CPU, RAM and disk to a single computer. Horizontal scaling means adding more computers to scale. There is a limit to vertical scaling. But with horizontal scaling, one can achieve unlimited scalability. Internet Computer is one of the first blockchains to successfully use horizontal scaling.

The nodes in the Internet Computer are divided into subnets, each containing a few dozen nodes. The set of nodes in a subnet together maintain one blockchain. Each subnet can host a few thousand canisters and process messages received by those canisters. Each subnet has a limited capacity in terms of the number of canisters (a few thousand), amount of storage (a few TB), and bandwidth (a few hundred transactions per second). But as more subnets are added to the Internet Computer, its overall capacity increases proportionately. There is no limit on the number of subnets that can be added, resulting in unlimited scalability.

There are two things needed to create a new subnet.
* Add/Register new nodes.
* Create a new subnet with the registered nodes that were not yet assigned to any subnet.

== Adding/Registering New Nodes ==
This sections describes a series of steps that need to be followed to add a new node to the Internet Computer.
* Node provider purchases a NitroKey (a Hardware Security Module), generates a public-key/secret-key pair, and submits an NNS proposal to add his public key to the NNS registry. The community votes on the proposal. If the majority accept the proposal, then the node provider's credentials are added to the NNS registry. From now on, the NNS canisters trust the messages signed by the node provider's secret key. The entire process is specified in the [https://wiki.internetcomputer.org/wiki/Node_Provider_Onboarding node provider onboarding article].
* Node provider purchases node hardware with the recommended specifications and places it in a data center rack that meets the recommended specifications.
* The node doesn't yet have any operating system. The node provider needs to install the IC-OS operating system on the node. The detailed procedure can be found in the IC-OS installation runbook articles ([https://wiki.internetcomputer.org/wiki/IC_OS_Installation_Runbook_-_Supermicro Installation for SuperMicro], [https://wiki.internetcomputer.org/wiki/IC_OS_Installation_Runbook_-_Dell_Poweredge Installation for Dell Poweredge]).
* The node provider inserts the NitroKey usb stick into the node machine. The NitroKey contains the secret key of corresponding to the node provider's registered public key.
* The node provider then switches on the node to boot the IC-OS operation system, which starts a few processes including orchestrator, crypto and http adapter processes.
* The crypto process finds that it never generated any cryptographic key material before. The crypto process then generates new cryptographic keys. This includes node signing key, NIDKG key, ECDSA key, TLS key, etc.
* The cryptographic key material need to be registered with the NNS registry. For this, the crypto process sends the keys to the orchestrator, which then crafts a message containing the key material, signs the message with the node provider's signing key present in the NitroKey, and sends the message to the NNS registry canister.
* The NNS registry canister creates a record for the new node and stores its cryptographic key material.
* The node is now registered in the Internet Computer, but not yet assigned to any subnet.

== Creating a New Subnet ==
This section describes the process of creating a new subnet. To create a new subnet, one just needs to submit an NNS proposal. The proposal specifies a type (create subnet) and a payload ([[#Payload for 'Create_Subnet' Proposal]]). A few sample proposals to create a new subnet can be found in the dashboard ([https://dashboard.internetcomputer.org/proposal/57048 Proposal 57048], [https://dashboard.internetcomputer.org/proposal/49018 Proposal 49018], [https://dashboard.internetcomputer.org/proposal/55730 Proposal 55730]). Anyone who staked their ICP can vote on the proposal within a deadline. After the deadline, if the majority of the voters accept the proposal, then the subnet is created as described below.

The NNS has a canister called "registry", which stores the configuration of the Internet Computer including the configuration of each node and subnet. When the 'Create subnet' proposal is accepted, it automatically calls a method of the NNS Registry with input the payload included in the NNS proposal. The registry canister then creates a new subnet configuration based on the information in the payload, and stores the subnet record.

Each node in the Internet Computer maintains a local copy of the NNS registry. Each node runs a "registry replicator" process ([https://github.com/dfinity/ic/tree/master/rs/orchestrator/registry_replicator github]) which is a part of the orchestrator and is responsible for regularly syncing NNS registry and maintaining the local registry copy. Once every few seconds (can be configured by setting <code>poll_delay_duration_ms</code> variable, which has a default value of 5 seconds), the registry replicator queries the NNS registry for the changes that happened after the recent sync, and applies those changes to the local registry copy. The local registry is stored on the disk and any process running on the node can read the contents of the local registry.

The orchestrator monitors the local registry to see what subnet the node has been assigned to. If the unassigned node has now been assigned to a new subnet according to the registry, the orchestrator first downloads the replica software using the url in the subnet's registry configuration. The orchestrator now installs the replica software ([[#Installing_the_Replica]]) and restarts the node.

== Payload for 'Create Subnet' Proposal ==
The payload for the 'Create Subnet' NNS proposal contains the list of parameters to be used by the new subnet. Some of the fields in the payload are as follows. The structure of payloads for every type of NNS proposal can be found on [https://github.com/dfinity/ic/blob/master/rs/registry/canister/canister/registry.did github].
* subnet_type - The type of the subnet to be created. Subnets of different type might exhibit different behavior, e.g. being more restrictive in what operations are allowed or privileged compared to other subnet types. There are a few types of subnets.
** Application subnet - A normal subnet where no restrictions are applied.
** System subnet - A more privileged subnet where certain restrictions are applied, like not charging for cycles or restricting who can create and install canisters on it.
** Verified application subnet - A subnet type that is like application subnets but can have some additional features.
* node_ids - List of node ids of unassigned nodes to be included in the subnet.
* replica_version_id - The version id of the replica software to be installed in the nodes of the subnet.
** A replica image has to be first uploaded to a publicly accessible server.
** Then one needs to create an NNS proposal of type "Elect new binary replica revision" and specify the replica image url and version id in the payload. A sample proposal can be found in the dashboard ([https://dashboard.internetcomputer.org/proposal/92338 proposal 92338]).
** When the proposal is accepted by the majority of voters, the replica version is stored in the NNS registry.
** This replica version id can now be specified in any other NNS proposals including "create subnet".
* Parameters for the P2P layer -
**gossip_max_chunk_size - The maximum chunk size supported on this subnet.
**gossip_retransmission_request_ms - Period for sending retransmission request.
**gossip_receive_check_cache_size - History size for receive check.
**gossip_registry_poll_period_ms - Period for polling the registry for updates.
**gossip_max_duplicity - Max duplicate requests in underutilized networks.
**gossip_max_chunk_wait_ms - Timeout for an outstanding request.
**gossip_pfn_evaluation_period_ms - Period for re evaluating the priority function.
**gossip_max_artifact_streams_per_peer - The maximum number of outstanding request per peer MIN/DEFAULT/MAX.
**advert_best_effort_percentage -
* Parameters for the Consensus layer
** max_block_payload_size - The maximum combined size of the ingress and xnet messages that fit into a block.
** max_ingress_bytes_per_message - The maximum amount of bytes per message. This is a hard cap, which means ingress messages greater than the limit will be dropped.
** max_ingress_messages_per_block - The maximum number of ingress messages allowed per block.
** ingress_bytes_per_block_soft_cap
** initial_notary_delay_millis - Initial delay for notary (in milliseconds), to give time to rank-0 block propagation.
** unit_delay_millis - Unit delay for blockmaker (in milliseconds).
* Parameters for the execution layer
** max_instructions_per_message - The maximum number of instructions a message can execute.
** max_instructions_per_round - The maximum number of instructions a round can execute.
** max_instructions_per_install_code - The maximum number of instructions an "install_code" message can execute.
** max_number_of_canisters - The maximum number of canisters that may be present on the subnet at any given time. A value of 0 is equivalent to setting no limit. This also provides an easy way to maintain compatibility of different versions of replica and registry.
* Parameters related to cryptographic keys
** dkg_dealings_per_block
** ecdsa_config - This field is optional. It specifies the configuration settings to be used for ECDSA signature scheme.
** dkg_interval_length - This is the number of rounds in an epoch. At the end of each epoch, the nodes run a distributed key generation protocol to reshare their secret key shares.
* SSH Access to Subnet
** ssh_readonly_access - The list of public keys whose owners have "readonly" SSH access to all replicas on this subnet, in case it is necessary to perform subnet recovery.
** ssh_backup_access - The list of public keys whose owners have "backup" SSH access to nodes on the NNS subnet to make sure the NNS can be backed up.
* Subnet Features - The list of feature flags to be used for the subnet. This indicates the features that are to be enabled/disabled in the subnet. This includes the following features.
** Canister sandboxing - This feature flag controls whether canister execution happens in sandboxed process or not. It is disabled by default.
** Http requests - This feature flag controls whether canisters of this subnet are capable of performing http(s) requests to the web2.
** Bitcoin testnet feature - Whether or not the subnet is capable of serving requests to the bitcoin testnet canister.
** Bitcoin - Controls whether the bitcoin feature is enabled and which bitcoin network is supported.
* is_halted - If "true", the subnet will be halted: it will no longer create or execute blocks.
* start_as_nns - If set to yes, the subnet starts as a (new) NNS.
* subnet_id_override - This field is optional. If a principal id is specified, then that principal id will be used for the new subnet.

== Executing the 'Create Subnet' Proposal ==
When the 'Create Subnet' NNS proposal is voted and accepted by the community, the proposal is executed automatically. To execute the proposal, a method in the registry canister is called ([https://github.com/dfinity/ic/blob/master/rs/registry/canister/src/mutations/do_create_subnet.rs github]), which mutates the registry to add configuration information of the new subnet. The registry is a versioned key-value storage. Each mutation to the registry is stored as a new version.

The registry canister performs the following steps.
* Run the [[Distributed Key Generation]] protocol.
** The first step is to generate the cryptographic information required for the new subnet to work properly. After every round of the Internet Computer protocol, the nodes of the subnet agree upon and sign their latest [https://wiki.internetcomputer.org/wiki/Replicated_state_structure replicated state]. For this, the subnet utilizes a threshold BLS signature scheme. In a nutshell, each node in the subnet holds a "share" of the subnet's signing key (none of the nodes know the complete subnet's signing key). After every round, each of the nodes individually sign their replicated state using their signing key "share". If at least a "threshold" number of nodes agree upon the same replicated state, their signature "shares" can be combined to obtain the signature of the replicated state using the subnet's signing key. A subnet also utilizes threshold BLS signature scheme for many other purposes including the generation of random beacon in the consensus layer and generation of random tape in the execution layer.
** In order to generate the above signing key share for each node in the new subnet, the nodes in the NNS engage in a distributed key generation (DKG) protocol. At the end of the protocol, all the nodes in the NNS agree on a few "dealings" for each node in the new subnet. The dealings of a node can be combined to obtain the signing key share of the node. The dealings for each node are encrypted with the encryption key registered by the node.
* Create a genesis block and [[Catch-Up Package]]
** The registry canister creates a genesis block. This is the first block in the blockchain. Structurally, this is a [[Summary Block]] containing the DKG dealings computed above.
** The registry canister then generates a Catch-Up Package which contains the above genesis block along with other information required for the subnet to start the consensus protocol.
* Create a Subnet Record
** Each subnet has a subnet record storing all its configuration information. The subnet record of the new subnet contains all the information present in the payload of the 'Create Subnet' proposal.
* Perform the following 5 mutations to the registry. The registry is a versioned key-value storage.
** Append to subnet list.
*** For the key <code>subnet_list</code>, the registry stores the list of all subnets. Append the new subnet to this list.
** Store subnet record.
*** Add a key-value pair with key = <code>subnet_record_{subnet_id}</code> and value = newly created subnet record, where {subnet_id} is the subnet id of the newly created subnet.
** Store catch-up package.
*** Add a key-value pair with key = <code>catch_up_package_contents_{subnet_id}</code> and value = newly created catch-up package.
** Store subnet threshold signing key.
*** Add a key-value pair with key = <code>crypto_threshold_signing_public_key_{subnet_id}</code> and value = threshold BLS signing key generated above.
** Routing table mutation.
*** Each subnet has a range of canister ids that are utilized for canisters in that subnet. The range of canister ids for each subnet is called the routing table. The routing table helps us route canister traffic to the appropriate subnet. When a new subnet is created, the next available set of <code>CANISTER_IDS_PER_SUBNET</code> (currently set to 2^20) canister ids is assigned as the range for the subnet. This information is stored in the key <code>routing_table</code> of the registry.

== Installing the Replica ==
The orchestrator uses a [https://en.wikipedia.org/wiki/Blue-green_deployment blue/green deployment] to start the replica software, which works as follows. The disk is divided into 3 partitions -- 2 partitions for the replica process and 1 partition for the data. If a node is not assigned to any subnet, both the replica partitions are empty. If the node is actively participating in a subnet, one of the replica partitions is used to run the replica process and the other replica partition is empty. To install the new replica software,
* The orchestrator loads the replica image into an empty replica partition.
* The orchestrator then modifies the boot loader settings to use the newly loaded replica partition.
* The orchestrator restarts the node.
* When the node boots up again, the newly loaded replica partition is used as per the boot loader settings.

==See Also==
* '''The Internet Computer project website (hosted on the IC): [https://internetcomputer.org/ internetcomputer.org]'''

Boundary Nodes

2025-06-30T22:01:10Z

Jessie.mongeon:

{{#externalredirect: https://learn.internetcomputer.org/hc/en-us/articles/34212818609684-ICP-Edge-Infrastructure#h_01JJSTH3K32T43FGFWBMP84FVC}}

IC P2P (peer to peer) layer

2025-06-30T22:00:47Z

Jessie.mongeon:

{{#externalredirect: https://learn.internetcomputer.org/hc/en-us/articles/34207428453140-Peer-to-peer}}

IC consensus layer

2025-06-30T22:00:24Z

Jessie.mongeon:

{{#externalredirect: https://learn.internetcomputer.org/hc/en-us/articles/34207558615956-Consensus}}

IC message routing layer

2025-06-30T22:00:02Z

Jessie.mongeon:

{{#externalredirect: https://learn.internetcomputer.org/hc/en-us/articles/34208241927316-Message-Routing}}

== Overview ==
The Internet Computer (IC) achieves its security and fault tolerance by replicating computation across node machines located in various independent data centers across the world. For scalability reasons, the Internet Computing Protocol (ICP) composes the IC of multiple independent subnets. Each subnet can be viewed as an independent replicated state machine that replicates its state over a subset of all the available nodes.

Roughly speaking, replication is achieved by having the two lower ICP layers (P2P & Consensus) agree on blocks containing batches of messages to be executed, and then having the two upper ICP layers (Message Routing & Execution) execute them. Blocks are organized as a chain, where each block builds on the previous block. Each block has an associated height in the chain and one can look at execution of a batch of messages corresponding to the agreed upon block at height <math>x</math> by the upper layers as taking the replicated state of version <math>x-1</math>, and "applying" the batch to it to obtain replicated state of version <math>x</math>.

This document describes the role of the Message Routing layer in deterministic batch processing. Its responsibilities are:
* '''Coordinating the deterministic processing of batches:''' Fetching the right versions of the replicated state and the registry view to process the batch, triggering the deterministic processing, and committing the resulting replicated state.

* '''Deterministic processing of batches:''' Deterministic processing of batches relative to some replicated state and some registry view, resulting in an updated replicated state.

* '''Transferring message streams from one subnet to another:''' Moving streams from one subnet to another.

=== Remarks and Required Prior Knowledge ===

* The goal of this document is to provide the next level of detail compared to the material in the [https://internetcomputer.org/how-it-works "How it works" section of internetcomputer.org]. So it is recommended to study the material available there first.
* This page builds upon definitions made in the page describing the [[IC state manager|state manager]]. Please refer to this page for missing definitions related to the replicated state etc.
* Also see [https://mmapped.blog/posts/08-ic-xnet.html this] and [https://mmapped.blog/posts/02-ic-state-machine-replication.html this] blog post for some relevant and easier to digest background information.
* The documentation provided in this page may slightly deviate from the current implementation in terms of API as well as naming of functions, variables, etc. However, it still conveys the high-level ideas required to understand how the component itself works and how it interacts with other components. The implementation also contains several optimizations which are, however, not important for the conceptual overview here and therefore skipped.
* The notation used in this page is described [[Notation|here]].

=== Replicated vs. Canonical State ===
While the external API functions defined in this document will always take state in its implementation specific representation, i.e., as <code>ReplicatedState</code>, the operation the message routing component performs on the state based on its canonical representation, i.e., the <code>CanonicalState</code> is described. Given the relations between <code>ReplicatedState</code> and <code>CanonicalState</code> as defined in the specification of the state manager, this will implicitly define how an implementation needs to act on the respective parts of the <code>ReplicatedState</code>. An implicit conversion from <code>ReplicatedState</code> to <code>CanonicalState</code> is assumed whenever some state passed to this component via an API function is accessed.

== Guarantees Provided by Message Routing ==
Intuitively, the goal of the message routing layer is to enable transparent communication of canisters across subnets. This means that this layer formally does not add any guarantees the system provides, but simply needs to make sure that system invariants are preserved. Those system invariants include

* guaranteed replies (each canister-to-canister request will eventually receive a reply),

* canister-to-canister ordering (the order of canister-to-canister requests sent from one canister to another canister is preserved), and

* authenticity (only messages that come from canisters on the IC are processed).

To ensure that the system invariants hold, message routing needs to provide the following guarantees:

* Canister-to-canister messages will eventually be passed to the execution layer at the subnet the destination canister lives on exactly once.

* If a message can not be delivered, a synthetic reject response must be produced.

* If a canister <math>A</math> sends two messages <math>m_1</math> and <math>m_2</math> to a canister <math>B</math>, then, if none of them gets synthetically rejected, it must be guaranteed that they are put in canister <math>B</math>'s input queue from <math>A</math> in that order.

== Preliminaries ==
=== Description of the Relevant Parts of the Registry ===
The registry can be viewed as a central store of configuration information of the IC that is maintained by the NNS DAO. The content of the registry is held by a canister on the NNS subnet, and, roughly speaking, its authenticity is guaranteed by obtaining a certification on the content on behalf of the NNS using the certification mechanism as described in the [[IC state manager|state manager]] wiki page. Throughout this document it is assume that the registry contents are authentic.

The registry entries required by this component are set of all existing subnet ids, as well as a canister-to-subnet mapping subnet_assignment. Note that the actual implementation may choose to represent the required fields differently as long as they are conceptually equivalent.
<nowiki>Registry {
subnets : Set<SubnetId>,
subnet_assignment: CanisterId ↦ SubnetId
...
}</nowiki>

=== Description of the Relevant Canonical State ===
This section defined the parts of the canonical state which are relevant for the description of this component together with some constraints imposed on the replicated state. Abstractly the <code>CanonicalState</code> is defined as a nested partial map. For easier readability the entries of the outermost map are bundled together in a data structure with multiple fields where the names of the fields represent the keys in the respective partial map, e.g., for some <code>s : CanonicalState</code> one can use <code>s.ingress_queue</code> to access <code>s[ingress_queues]</code>

This section defines the individual fields of the type </code>CanonicalState</code> which are relevant in the context of this document. After that there are more details about the datatypes of the individual fields. There is a distinction made between the parts which are exclusively visible to message routing, and the parts which are also visible to the execution layer.

'''Parts visible to message routing and execution'''
<nowiki>CanonicalState {
...
ingress_queues : IngressQueues,
input_queues : InputQueues,
output_queues : OutputQueues,
...
}</nowiki>

'''Parts visible to Message Routing only'''
<nowiki>CanonicalState {
...
streams : Streams,
expected_xnet_indices : Set<(SubnetId × StreamIndex)>
...
}</nowiki>

Even though there are parts of the state that are accessed by both message routing and execution, one can enforce a conceptual boundary between them. In particular, for input queues, message routing will only ever push messages to them, whereas for output queues, message routing will only ever pull messages from them. The opposite holds for the execution environment.

==== Abstract Queues ====
Define a generic queue type <code>Queue<T></code> which has the following fields:
<nowiki>Queue<T> {
next_index : ℕ, // Rolling index; the index of the next message to be inserted
elements : ℕ ↦ T // The elements currently in the queue
}</nowiki>

Define a new queue as <code>new_queue : Queue<T></code> with <code>new_queue.elements = ∅</code> and <code>new_queue.next_index = 1</code>. Furthermore, it has the following associated functions:

* <code>push</code> takes a queue and a partial map of integers mapping to T, and returns a new queue consisting of the old queue with the given values appended. It also updates the next_index field so that it points to the index after the last inserted message.
<nowiki>push : Self × (ℕ ↦ T) → Self
push(self, values) :=
self with
├─ next_index := self.next_index + |values|
└─ elements := self.elements
∪ { (i - 1 + k ↦ t) | i = self.next_index ∧
(j ↦ t) ∈ values ∧
k = rank(j, dom(values)) }</nowiki>

* <code>delete</code> removes the given elements from the queues keeping the <code>next_index</code>
<nowiki>% REQUIRE: values ⊆ self.elements
delete : Self × (ℕ ↦ T) → Self
delete(self, values) :=
self with
├─ next_index := self.next_index
└─ elements := self.elements
\ values</nowiki>

* <code>clear</code> removes all elements from the queues keeping the next_index
<nowiki>clear : Self → Self
clear(self) :=
self with
├─ next_index := self.next_index
└─ elements := ∅</nowiki>

Partial maps of type <code>SomeIdentifier ↦ Queue<T></code> are often used, in which case the following shorthand notation is used. With <code>q</code> being a queue of the aforementioned type, and <code>v</code> being a partial map of type <code>(SomeIdentifier × ℕ) ↦ T</code>, define the following semantic for the functions <code>f ∈ { push, delete }</code> associated to <code>Queue<T></code>:
<nowiki>f_map : (SomeIdentifier ↦ Queue<T>) × ((SomeIdentifier × ℕ) ↦ T) → (SomeIdentifier ↦ Queue<T>)
f_map(q, v) = { (id ↦ queue') | (id ↦ queue) ∈ q ∧
(id ↦ values) ∈ v ∧
queue' = f(queue, values)
} ∪
{ (id ↦ queue') | (id ↦ values) ∈ v ∧
∄ (id ↦ ·) ∈ q ∧
queue' = f(Queue<T>::new_queue, values)
} ∪
{ (id ↦ queue) | (id ↦ queue) ∈ q ∧
∄ (id ↦ ·) ∈ v
}</nowiki>

For the functions <code>f ∈ { clear }</code> use
<nowiki>f_map : (SomeIdentifier ↦ Queue<T>) → (SomeIdentifier ↦ Queue<T>)
f_map(q) = { (id ↦ queue') | (id ↦ queue) ∈ q ∧
queue' = f(queue)
}</nowiki>

Henceforth the <code>map</code> postfix will be omitted in <code>f_map</code> and simply use <code>f</code> if it is clear from the input type that the map variant of <code>f</code> should be used.

==== Indices ====
Define an <code>Index</code> to be an arbitrary length sequence, where every element in the sequence up to the last one can have an arbitrary type, and the last one is a natural number.
<nowiki>Index : X × ... × Y × ℕ</nowiki>

In addition the following semantic is defined:

* Define the prefix of an index Index <code>i := (x, …, y, seq_nr)</code> as <code>prefix(i) := i[1…|i| - 1] = (x, …, y)</code>, i.e., it contains all elements of i except the last one.

* Define the postfix of an Index <code>i := (x, …, y, seq_nr)</code> as </code>postfix(i) := i[|i|] = seq_nr</code>, i.e., the last element of the index sequence. As already mentioned, the postfix of an index is required to be a natural number.

* For an <code>Index i</code>, the operation <math>i + 1</math> is defined as <code>concatenate(prefix(i), postfix(i) + 1)</code>.

* Two indices, <code>Index i</code> and <code>Index j</code>, are incomparable if <code>prefix(i) ≠ prefix(j)</code>.

* For two indices, <code>Index i</code> and <code>Index j</code>, it is the case that <math>i \leq j</math> if <code>prefix(i) = prefix(j)</code> and <code>postfix(i) ≤ postfix(j)</code>.

==== Queues ====

Three different types of queues exist in the replicated state: ingress queues, input queues, and output queues. Ingress queues contain the incoming messages from users (i.e., ingress messages). Input queues contain the incoming canister-to-canister messages. Output queues contain the outgoing canister-to-canister messages.

Ingress queues are organized on a per destination basis. Messages in ingress queues are indexed by a concrete instance of Index called <code>IngressIndex</code>, which is a tuple consisting of the destination canister ID and a natural number, i.e.,
<nowiki>IngressIndex : CanisterId × ℕ</nowiki>

Input queues and output queues are organized on a per-source-and-destination basis. Messages in input- and output queues are indexed by a concrete instance of Index called QueueIndex, which is defined as follows:
<nowiki>QueueIndex : CanisterId × CanisterId × ℕ</nowiki>

The type representing all of the ingress queues is defined as follows:
<nowiki>IngressQueues : CanisterId ↦ Queue<Message>,</nowiki>
which means that <code>IngressQueues.elements : IngressIndex ↦ Message</code>.

The type representing all of the input queues is defined as follows:
<nowiki>InputQueues : (CanisterId × CanisterId) ↦ Queue<Message>,</nowiki>
which means that <code>InputQueues.elements : QueueIndex ↦ Message</code>.

The type representing all of the output queues is defined as follows:
<nowiki>OutputQueues : (CanisterId × CanisterId) ↦ Queue<Message>,</nowiki>
which means that <code>OutputQueues.elements : QueueIndex ↦ Message</code>.

==== Streams ====
Each individual <code>Stream</code> is scoped to a pair of subnets—the subnet a stream originates from and subnet the stream is targeted at. An individual stream is organized in multiple substreams identified by a <code>SubstreamId</code>. The concrete definition of <code>SubstreamId</code> is up to the implementation. In the current implementation <code>SubstreamId</code> is defined to be the unit type <code>()</code>, i.e., flat streams. Messages in streams are indexed by a concrete instance of <code>Index</code> called StreamIndex which is defined as follows:
<nowiki>StreamIndex : SubstreamId × ℕ</nowiki>
A <code>Stream</code> is comprised of a sequence of <code>Signal</code> messages <code>signals</code> and a sequence of canister-to-canister messages <code>msgs</code>.
<nowiki>Stream {
signals : StreamIndex ↦ {ACCEPT, REJECT},
msgs : SubstreamId ↦ Queue<Message>
}</nowiki>
which means that <code>Stream.msgs.elements : StreamIndex ↦ Message</code>.

While the subnet the stream originates from is implicitly determined, the target subnet needs to be made explicit. Hence, a data structure Streams is defined holding all streams indexed by destination subnetwork:
<nowiki>Streams : SubnetId ↦ Stream</nowiki>

Notation may be sometimes abused and directly access the fields defined for an individual <code>Stream</code> on the Streams type, in which case maps of the following type are obtained:
<nowiki>Streams.signals : SubnetId ↦ (StreamIndex ↦ {ACCEPT, REJECT})

Streams.msgs : SubnetId ↦ (SubstreamId ↦ Queue<Message>)</nowiki>

==== (Certified) Stream Slices ====
<code>StreamSlices</code> and <code>CertifiedStreamSlices</code>, respectively, are used to transport streams from one to an other subnet within <code>XNetPayloads</code> that are part of consensus blocks. Essentially, a <code>StreamSlice</code> is a slice of a stream which retains the begin and the end of the original stream. A <code>StreamSlice</code> is wrapped in a <code>CertifiedStreamSlice</code> for transport so that authenticity can be guaranteed. Neither <code>CertifiedStreamSlices</code> nor <code>StreamSlices</code> are ever explicitly created within message routing, but instead one relies on the encoding and decoding routines provided by the state manager: A <code>CertifiedStreamSlice</code> is created by calling the respective encoding routine of the state manager. Such a <code>CertifiedStreamSlice</code> can then be decoded into a <code>StreamSlice</code> using the corresponding decoding routine provided by the state manager.
<nowiki>StreamSlice {
stream : Stream,
begin : Set<StreamIndex>,
end : Set<StreamIndex>
}</nowiki>

<nowiki>CertifiedStreamSlice {
payload : PartialCanonicalState
witness : Witness
signature : Certification
}</nowiki>

For the precise relation of <code>StreamSlice</code> and <code>CertifiedStreamSlice</code>, refer to the specification of the state manager.

==== Batch ====
A batch consists of multiple elements including an <code>ingress_payload</code> constituting a sequence of ingress messages, and an <code>xnet_payload</code>.
<nowiki>Batch {
batch_number : Height
registry_version : RegistryVersion
ingress_payload : ℕ ↦ Message
xnet_payload : SubnetId ↦ CertifiedStreamSlice
requires_full_state_hash : { TRUE, FALSE }
}</nowiki>

==== Decoded Batch ====
A decoded batch represents a batch where all transport-specific things are decoded into the format suitable for processing and some things which are not required inside the deterministic state machine are stripped off.
<nowiki>DecodedBatch {
ingress_payload : ℕ ↦ Message
xnet_payload : SubnetId ↦ StreamSlice
}</nowiki>

Currently this only means decoding the <code>CertifiedStreamSlices</code> into <code>StreamSlices</code> because it is assumed that the ingress payload is suitable to be processed right away. Formally there is a function, which, based on the own subnet id and the given batch decodes the batch into a decoded batch:
<nowiki>decode : SubnetId × Batch → DecodedBatch
decode(own_subnet, b) :=
DecodedBatch {
with
├─ ingress_payload := b.ingress_payload
└─ xnet_payload :=
{ (src_subnet ↦ slice) |
(src_subnet ↦ cert_slice) ∈ b.xnet_payload ∧
slice = StateManager.decode_valid_certified_stream(own_subnet,
cert_slice
)
}
}</nowiki>

== Message Routing ==
Message routing is triggered by incoming batches from consensus. For each <code>Batch b</code>, message routing will perform the following steps:
[[File:Message Routing Components.png|thumb|Components interacting with message routing during a deterministic processing round]]
[[File:MR Interactions.png|thumb|Interactions of message routing with other components during a deterministic processing round]]

* Obtain the <code>ReplicatedState s</code> of the right version w.r.t. <code>Batch b</code>.

* Submit <code>s</code>, <code>decode(own_subnet, b)</code> for processing by the deterministic state machine comprised of the message routing and execution layer. This includes

** An induction phase (cf. <code>pre_process</code>), where the valid messages in <code>decode(own_subnet, b)</code> are inducted. Among others, a message m in a <code>StreamSlice</code> from subnet <code>X</code> is considered valid if <code>registry.get_registry_at(b.registry_version).subnet_assignment</code> maps <code>m.src</code> to <code>X</code>.

** An execution phase (cf. <code>execute</code>), which executes messages available in the induction pool.

** An XNet message routing phase (cf. <code>post_process</code>), which moves the messages produced in the execution phase from the per-session output queues to the subnet-to-subnet streams according to the mapping defined by the subnet assignment in the registry.

* Commit the replicated state, incrementally updated by the previous steps, to the state manager via <code>commit_and_certify</code>.

=== Deterministic State Machine ===
As shown in the sequence diagram above, the deterministic state machine implemented by message routing and execution applies batches provided by consensus to the appropriate state, additionally using some meta information provided by the registry. As discussed above, state of type <code>CanonicalState</code> is used to generally describe the operations of the message-routing-related operations of this component.

[[File:Message-routing-data-flow.png|thumb|Data flow during batch processing]]

The flow diagram below details the operation of the component. Its operation is logically split into three phases.

* The induction phase, where the messages contained in the batch are preprocessed. This includes extracting them from the batch and, subject to their validity and the decision of VSR, added to the induction pool or not.

* The execution phase, where the hypervisor is triggered to perform an execution cycle. The important thing from a message routing perspective is that it will take messages from the input queues and process them, which causes messages to be added to the output queues.

* The XNet message routing phase, where the messages produced in the execution cycle are post-processed. This means that they are taken from the canister-to-canister output queues and routed into the appropriate subnet-to-subnet streams.

All messages will be added to the respective destination queue/stream preserving the order they appear in the respective source stream/queue.

==== API ====
The deterministic state machine does not provide any external API functions. It only provides the following functions resembling the state transformations implemented by the individual steps of the deterministic state machine depicted above. Refer to the previous section for context regarding when the individual functions are called.

* <code>pre_process(s : CanonicalState, subnet_assignment : (CanisterId ↦ SubnetId), b : DecodedBatch) → CanonicalState</code>: Triggers the induction phase.

* <code>execute(s : CanonicalState) → CanonicalState</code>: Triggers the execution phase.

* <code>post_process(s : CanonicalState, subnet_assignment : (CanisterId ↦ SubnetId)) → CanonicalState</code>: Triggers the XNet message routing phase.

==== Abstractions of Other Parts of the System ====

'''Valid Set Rule (VSR)'''
The VSR is a component that makes the decision of whether to <code>ACCEPT</code> a message or to <code>REJECT</code> a message. For message routing, <code>ACCEPT</code> has the semantic that the execution layer takes responsibility for the message, whereas <code>REJECT</code> has the semantic that the message is dropped and may require action from the message routing layer.

The operation of the VSR on ingress messages is defined as follows, where <code>vsr_check_ingress : CanonicalState × Batch → Set<ℕ></code> is a deterministic function returning the indices of the messages in the ingress payload accepted by the VSR, which returns a possibly empty set of index-message tuples corresponding to the accepted messages in the ingress_payload of the batch. The set is determined by the concrete implementation of the VSR.
<nowiki>VSR(state, batch).ingress :=
{ ((m_i.dst, j) ↦ m_i) | (i ↦ m_i) ∈ batch.ingress_payload
∧ i ∈ vsr_check_ingress(state, batch)
∧ j = Rank(i, vsr_check_ingress(state, batch))
}</nowiki>

The VSR for cross-net messages is defined as follows, where <code>vsr_check_xnet : CanonicalState × Batch → Set<(SubnetId × StreamIndex)></code> is a deterministic function that determines the indices of the messages in the individual substreams contained in <code>xnet_payload</code> to be inducted.

It is required that the implementation of the VSR (or the layer above) makes sure that all reply messages are accepted by the VSR. Formally this means that for any valid State-Batch combination <code>(s, b)</code> it holds that for all <code>(subnet, index)</code> so that <code>b.xnet_payload[subnet].msgs[index]</code> is a reply message that <code>(subnet, index) ∈ vsr_check_xnet(s, b)</code>.

Based on this rule one can straight-forwardly define the interface behavior of the VSR.

<nowiki>VSR(state, batch).xnet :=
{ (index ↦ msg) |
(index ↦ msg) ∈ batch.xnet_payload.msgs ∧
index ∈ vsr_check_xnet(state, batch)
}

VSR(state, batch).signals :=
{ (concatenate(subnet, index) ↦ ACCEPT) |
(subnet ↦ stream) ∈ batch.xnet_payload ∧
(index ↦ msg) ∈ stream.msgs ∧
(subnet, index) ∈ vsr_check_xnet(state, batch)
}
∪ { (concatenate(subnet, index) ↦ REJECT) |
(subnet ↦ stream) ∈ batch.xnet_payload ∧
(index ↦ msg) ∈ stream.msgs ∧
(subnet, index) ∉ vsr_check_xnet(state, batch)
}</nowiki>

'''Scheduler and Hypervisor'''. From the point of view of message routing, one can look at the the scheduler and the hypervisor together as one component. The functionality of scheduler and hypervisor are modeled as a deterministic function <code>schedule_and_execute : CanonicalState → (IngressIndex ↦ Message) × (QueueIndex ↦ Message) × (QueueIndex ↦ Message)</code> which computes the change set introduced by the Scheduler and the Hypervisor. It takes messages from the input queues, executes them and puts new messages to the output queues.

This function will be used lated when it's described how the state transition function <code>execute(CanonicalState) → CanonicalState</code> transforms the state. For the sake of compact notation, the following fields are used to access the individual return values of the schedule_and_execute function.

* <code>consumed_ingress_messages</code>, which contains a partial map <code>IngressIndex ↦ Message</code> containing all consumed ingress messages.

* <code>consumed_xnet_messages</code>, which contains a partial map <code>QueueIndex ↦ Message</code> containing all consumed cross-net messages.

* <code>produced_messages</code>, which contains a partial map <code>QueueIndex ↦ Message</code> containing all produced messages, where the order of the messages implied by the queue index determines the order in which they need to be added to the queues.

==== Description of the State Transitions ====

'''Induction Phase'''. In the induction phase, one starts off with a <code>CanonicalState S</code>, some <code>subnet_assignment</code> and a <code>DecodedBatch b</code> and applies <code>b</code> to <code>S</code> relative to <code>subnet_assignment</code> to obtain <code>S'</code>, i.e., one computes <code>S' = pre_process(S, subnet_assignment, b)</code>.

This section describes things w.r.t. to a version of the VSR which will accept all messages, while in reality the VSR may reject some messages in case canisters migrate across subnets or subnets are split. So while the possibility that messages can be REJECTed by the VSR would require specific action of the message routing layer those actions are omitted here for simplicity as they are not crucial to understand the basic functionality of message routing.

Before defining the actual state transition, a couple of helper functions are defined. First, it is needed to define a function that determines the order of the messages in the queues based on the order of the messages in the incoming stream slices.
<nowiki>% REQUIRES: ∄ (s1 ↦ m1), (s2 ↦ m2) ∈ S :
% └─ m1 = m2 ∧ s1 ≠ s2
%
% ENSURES: ∀ S satisfying the precondition above,
% └─ ∀ (q1 ↦ m1), (q2 ↦ m2) ∈ queue_index(S) :
% ├─ ∃ s1, s2 :
% │ └─ (s1 ↦ m1) ∈ S ∧ (s2 ↦ m2) ∈ S ∧
% └─ (m1.dst = m2.dst ∧ s1 ≤ s2) ==> q1 ≤ q2
%
queue_index: ((SubnetId × StreamIndex) ↦ Message) → ((CanisterId × ℕ) ↦ Message))
queue_index(S) := {
% There is no concrete implementation of this function provided as there are
% multiple possible implementations and the choice for one also depends on
% how priorities/fairness etc. are handled.
%
% A trivial implementation is to iterate over the given stream slices S per
% subnet and for each individual slice iterate over all the messages in the
% order they appear in the slice and push each message m on the right queue,
% i.e., the one belonging to the destination canister. This is also the way
% things are currently implemented.
}</nowiki>

Based on this a function can now be defined that maps over the indexes of the valid XNet messages.
<nowiki>map_valid_xnet_messages : (SubnetId ↦ Slice) ×
(CanisterId ↦ SubnetId) →
((CanisterId × ℕ) ↦ Message)
map_valid_xnet_messages(slices, subnet_assignment) :=
queue_index({ ((subnet, index) ↦ m) | (subnet ↦ slice) ∈ slices ∧
(index ↦ m) ∈ slice.msgs ∧
subnet_assignment[m.src] = subnet ∧

})</nowiki>

Finally, the state <code>S'</code> resulting from computing <code>pre_process(S, b)</code> can be defined:
<nowiki>S with
% Append the ingress messages accepted by the VSR to the appropriate ingress_queue
ingress_queues := push(S.ingress_queues, VSR(S, b).ingress)

% Append the canister to canister messages accepted by the VSR to the appropriate
% input queue.
input_queues := push(S.input_queues,
map_valid_xnet_messages(VSR(S, b).xnet, subnet_assignment)
)

% Garbage collect the messages which have accepted by the target subnet.
% (As soon as the VSR does no longer ACCEPT all messages, one would have
% to make sure that rejected messages are appropriately re-enqueued in
% the streams)
streams.msgs := delete(S.streams.msgs,
{ (concatenate(subnet, index) ↦ msg) |
(subnet ↦ slice) ∈ b.xnet_payload ∧
(i ↦ ·) ∈ slice.signals ∧
index = concatenate(subnet, i)
}
)

% Add the signals reflecting the decisions made by the VSR in the current round and
% garbage collect the signals which have already been processed on the other subnet
% (one knows that a signal has been processed when the message is no longer included
% in a given slice).
streams.signals := S.streams.signals
∪ VSR(S, b).signals
\ { (index ↦ signal) |
(subnet ↦ slice) ∈ b.xnet_payload ∧
(i ↦ signal) ∈ S.streams[subnet].signals ∧
index = concatenate(subnet, i) ∧
j ∈ slice.begin ∧
i < j
}

% Update the expected XNet indexes so that the block maker can compute which messages
% to include in a block referencing this state.
expected_xnet_indices := { index | index ∈ S.expected_xnet_indices ∧
∄ (i ↦ ·) ∈ b.xnet_payload.msgs.elements :
└─ prefix(index) = prefix(i)
} ∪
{ index + 1 | index ∈ max(dom(b.xnet_payload.msgs.elements)) }</nowiki>

'''Execution Phase'''. In the execution phase, one starts off with a <code>CanonicalState S</code>, schedules messages for execution by the hypervisor, and triggers the hypervisor to execute them, i.e., one computes <code>S' = execute(S)</code> where <code>S</code> is the state after the induction phase. From the perspective of message routing, the state <code>S'</code> resulting from computing <code>execute(S)</code> looks as follows:
<nowiki>S with
% Delete the consumed ingress messages from the respective ingress queues
ingress_queues := delete(S.ingress_queue, schedule_and_execute(S).consumed_ingress_messages)

% Delete the consumed canister to canister messages from the respective input queues
input_queues := delete(S.input_queues, schedule_and_execute(S).consumed_xnet_messages)

% Append the produced messages to the respective output queues
output_queues := push(S.output_queues, schedule_and_execute(S).produced_messages)

% Execution specific state is transformed by the execution environment; the precise transition
% function is out of scope here.</nowiki>

'''XNet Message Routing Phase'''. In the XNet message routing phase, one takes all the messages from the canister-to-canister output queues and, according to the subnet_assignment, puts them into a subnet-to-subnet stream, i.e., it computes <code>S' = post_process(S, registry)</code>, where <code>S</code> is the state after the execution phase and registry represents a view of the registry.

Before defining the state transition, a helper function is defined to appropriately handle messages targeted at canisters that do not exist according to the given subnet assignment.
<nowiki>% Remove all messages from output queues targeted at non-existent canisters according
% to the subnet assignment.
filter : ((CanisterId × CanisterId) ↦ Queue<Message>) × (CanisterId ↦ SubnetId) → ((CanisterId × CanisterId) ↦ Queue<Message>)
filter(queues, subnet_assignment) :=
delete(queues, { (q_index ↦ msg) | (q_index ↦ msg) ∈ queues.elements ∧
q_index = (·, dst, ·) ∧
dst ∉ dom(subnet_assignment)
}
)
</nowiki>

Produce <code>NON_EXISTENT_CANISTER</code> replies telling the sending canister that the destination canister does not exist.
<nowiki>% Produce NON_EXISTENT_CANISTER messages to be pushed to input queues
% of the senders of messages where the destination does not exist
non_existent_canister_replies : ((CanisterId × CanisterId) ↦ Queue<Message>) × (CanisterId ↦ SubnetId) → (QueueIndex ↦ Message)
non_existent_canister_replies(queues, subnet_assignment) :=
{ ((dst, src, i) ↦ NON_EXISTENT_CANISTER) | (q_index ↦ msg) ∈ queues.elements ∧
q_index = (src, dst, i) ∧
dst ∉ dom(subnet_assignment)
})</nowiki>

''Non flat streams.'' As already mentioned before, the specification leaves it open whether one flat stream is produced per destination subnet, or whether each of the streams has multiple substreams—this can be decided by the implementation. To enable this, a <code>StreamIndex</code> is defined to be a tuple of <code>SubstreamId</code> and a natural number. If there is a flat stream, <code>StreamIndex</code> is defined to be the unit type <code>()</code> which effectively means that the implementation can use natural numbers as stream index as one does not need to make the <code>SubstreamId</code> explicit in this case. In contrast, if there is a per-destination (or per-source) substreams, <code>StreamIndex</code> is defined to be a <code>CanisterId</code>.

Formally, this means that the implementation must fix a mapping function that—based on a given prefix of a <code>QueueIndex</code>, i.e., a src-dst tuple—decides on the prefix of the <code>StreamIndex</code>, i.e., the SubstreamId.
<nowiki>substream_id: (CanisterId × CanisterId) → SubstreamId

% Definition of substream_id for flat streams
substream_id((src, dst)) := ()

% Definition of substream_id for per-destination canister substreams
substream_id((src, dst)) := dst
</nowiki>

''Description of the actual state transition''. The state <code>S'</code> resulting from computing <code>post_process(S, subnet_assignment)</code> is defined as follows:
<nowiki>S with
% Clear the output queues
output_queues := clear(S.output_queues)

% Route the messages produced in the previous execution phase to the appropriate streams
% taking into account ordering and capacity management constraints enforced by stream_index.
streams.msgs := {
let msgs = S.streams.msgs

% Iterate over filtered messages preserving order of messages in queues.
for each (q_index ↦ msg) ∈ filter(S.output_queues, subnet_assignment)
msgs = push(msgs, { (concatenate(substream_id(prefix(q_index)), postfix(q_index)) ↦ msg) })

return msgs
}

% Push NON_EXISTENT_CANISTER replies to input queues of the respective canisters
input_queues := push(S.input_queues,
non_existent_canister_replies(S.output_queues, subnet_assignment))</nowiki>

''Ordering of Messages in the Stream & Fairness''. As long as the invariant that the canister-to-canister ordering of messages is preserved when iterating over the filtered messages in the state transition described above, the implementation can take the freedom to apply alternative orderings.

Also note that, while the state transition defined above empties the output queues completely, this is not crucial to the design and one could hold back messages as long as this does not violate the ordering requirement.

== XNet Transfer ==
After calling <code>commit_and_certify</code> at the end of a deterministic processing cycle, the state manager will take care of getting the committed state certified. Once certification is complete, the certified stream slices can be made available to block makers on other subnets. The <code>XNetTransfer</code> subcomponent is responsible to enable this transfer. It consists of

[[File:Xnet.png|thumb|XNet transfer component diagram]]

* An <code>XNetEndpoint</code> which is responsible for serving certified stream slices and making them available to <code>XNetPayloadBuilders</code> on other subnetworks.

* An <code>XNetPayloadBuilder</code>, which allows the block makers to obtain an <code>XNetPayload</code> containing the currently available certified streams originating from other subnetworks. The <code>XNetPayloadBuilder</code> obtains those streams by interacting with <code>XNetEndpoints</code> exposed by other subnets. The <code>XNetPayloadBuilder</code> also provides functionality for notaries to verify <code>XNetPayloads</code> contained in block proposals.

There are no specifications about the protocol run between the <code>XNetEndpoint</code> and the <code>XNetPayloadBuilder</code> to transfer the streams between two subnetworks. The only requirement is that certified streams made available by an <code>XNetEndpoint</code> of an honest replica on some source subnetwork, they can be obtained by an <code>XNetPayloadBuilder</code> of an honest replica on the destination subnetwork and that the information regarding which endpoints to contact is available in the Registry.

=== Properties and Functionality ===
Assume an XNet transfer component on a replica part of subnet <code>own_subnet</code>. The interface behavior of the XNet transfer component will guarantee that for any payload payload produced via

<nowiki>get_xnet_payload(registry_version, reference_height, past_payloads, size_limit)</nowiki>

For any <code>(remote_subnet ↦ css) ∈ payload</code>:

* <code>StateManager.decode_certified_stream(registry_version, own_subnet, remote_subnet, css)</code> succeeds, i.e., returns a valid slice slice that is guaranteed to come from remote_subnet.

* Furthermore, for each slice it will hold that a soon as the state corresponding to height <code>h = reference_height + |past_payloads|</code> is available that <code>concatenate(remote_subnet, min(dom(slice.msgs.elements))) ∈ StateManager.get_state_at(h).expected_indexes</code>. This means that the streams will start with the expected indexes stored in the previous state, i.e., they gap freely extend the previously seen streams.

Payloads verified using <code>validate_xnet_payload</code> are accepted if they adhere to those requirements, and are rejected otherwise.

=== XNet Endpoint ===
The <code>XNetEndpoint</code> serves the streams available on some subnet to other subnets. For an implementation this will typically mean that there is some client which will handle querying the API of the <code>XNetEndpoint</code> on the remote subnet in question. The following abstraction is used to avoid explicitly talking about this client: Assume that there is a function <code>get : SubnetId → XNetEndpoint</code> which will return an appropriate instance of <code>XNetEndpoint</code> which can directly be queried using the API described below.

[[File:Xnet-sequence.png|thumb|XNet transfer sequence diagram]]

* <code>get_stream(subnet_id : SubnetId, begin : StreamIndex, msg_limit : ℕ, size_limit : ℕ) → CertifiedStreamSlice</code>: Returns the requested certified stream slice in its transport format.

It is required that an honest <code>XNetPayloadBuilder</code>-<code>XNetEndpoint</code> pair is able to successfully obtain slices over this API.

Looking at the bigger picture, the intuition for why this will yield a secure system is that in each round a new pair of block maker and endpoint will try to pull over a stream, which, in turn, means that eventually an honest pair will be able to obtain the stream and include it into a block.

=== XNet Payload Builder ===
The <code>XNetPayloadBuilder</code> builds and verifies payloads whenever requested to do so by the block maker. The rules for whether a payload is considered valid or not must be so that every notary is guaranteed to make the same decision on the same input and that a payload built by an honest payload builder will be accepted by honest validators. Essentially the rules resemble what is described in the section on properties and functionality. However, given that the execution may be behind one can not directly look up the expected indexes in the appropriate state but need to compute it based on the referenced state and the payloads since then. Below, a figure is provided to illustrate the high-level functionality: generally speaking blocks are considered valid if they adhere to the rules described in the figure and are considered invalid otherwise.

[[File:Payload-building.png|thumb|Rules for payload building]]

This section formally defines the operation of the component. The following helper functions are first defined. Assume that <code>XNetPayloadBuilder</code> has an associated field <code>own_subnet</code> which is passed whenever constructing an <code>XNetPayloadBuilder</code>:
<nowiki>new : SubnetId → Self
new(own_subnet) :=
XNetPayloadBuilder {
with
└─ own_subnet := own_subnet
}
</nowiki>

The API defines the past_payloads as a vector where the past payloads are ordered with respect to the corresponding height in the chain. While this ordering allows for a more efficient implementation of the functions below it does not matter on a conceptual level. Hence resort to looking at it as a set for the sake of simplicity.

* The function <code>slice_indexes</code> returns the set of expected indices for the block to be proposed, solely based on a set of Slices.
<nowiki>% Take the maximum index for each individual (sub-)stream in the given set of slices and add
% 1 to obtain the next indexes one would expect when solely looking at the past payloads but
% ignoring the state.
slice_indexes : (SubnetId ↦ StreamSlice) → Set<(SubnetId × StreamIndex)>
slice_indexes(slices) := { i + 1 | i ∈ max(dom(slices.msgs.elements)) }</nowiki>

* The function <code>state_and_payload_indexes</code> returns the set of expected indices for the block to be proposed, taking into account both the expected indices in the given replicated state and the more recent messages in the given slices from the past payloads.
<nowiki>% Take the expected indexes from the state, remove whatever index appears in the given
% slices and add the expected indexes according to the streams in the slices.
%
% FAIL IF: ∃ i, j ∈ state_and_payload_indexes(state, slices) :
% prefix(i) = prefix(j) ∧ postfix(i) ≠ postfix(j)
%
state_and_payload_indexes : ReplicatedState ×
(SubnetId ↦ StreamSlice) →
Set<(SubnetId × StreamIndex)>
state_and_payload_indexes(state, slices) := state.expected_xnet_indices
\ dom(slices.msgs.elements)
∪ slice_indexes(slices)</nowiki>

* The function <code>expected_indexes</code> returns the set of expected indices for the block to be proposed, taking into account both the expected indices in the given replicated state and the more recent messages in the given past payloads.
<nowiki>% Decode the slices in the given payload and compute the expected indexes using the
% expected_indexes function above
expected_indexes : SubnetId ×
ReplicatedState ×
(SubnetId ↦ StreamSlice) →
Set<(SubnetId × StreamIndex)>
expected_indexes(own_subnet, state, slices) :=
state_and_payload_indexes(
state,
{ (src ↦ slice) | payload ∈ slices ∧
(src ↦ cert_slice) ∈ payload ∧
slice = StateManager.decode_valid_certified_stream(own_subnet,
cert_slice)
}
)</nowiki>

==== Creation of XNet Payloads ====
Based on the functions above, it is possible to define the function <code>get_xnet_payload : Height × Height × Set<XNetPayload> → XNetPayload</code>. Note that the gap-freeness of streams is an invariant of the datatype, which is why the rule for gap-freeness is not explicitly included here.
<nowiki>% Build an xnet payload containing the currently available streams. The begin is either given
% by the expected index, and, if there is no expected index for a given prefix, the index
% ONE is expected.
%
% ENSURES: size_of(get_xnet_payload(self, ·, ·, ·, size_limit)) ≤ size_limit ∧
% each payload output by get_xnet_payload will be accepted by validate_xnet_payload
%
get_xnet_payload : Self × RegistryVersion × Height × Vec<XNetPayload> × ℕ → XNetPayload
get_xnet_payload(self, registry_version, reference_height, past_payloads, size_limit) :=
{ (remote_subnet ↦ slice) |
S = StateManager.get_state_at(reference_height)
∧ subnets = Registry::get_registry_at(registry_version).subnets \ { self.own_subnet }
∧ (remote_subnet, begin_index) ∈
expected_indexes(self.own_subnet, S, past_payloads)
∪ { (subnet_id, StreamIndex::ONE) |
subnet_id ∈ subnets
\ { s | (s, ·) ∈ expected_indexes(self.own_subnet,
S,
past_payloads)
}
}
% msg_limit and size limit need to be set by the implementation as appropriate
% to satisfy the post condition
∧ slice = XNetEndpoint::get(subnet).get_stream(remote_subnet, begin_index, ·, ·)
∧ ERR ≠ StateManager.decode_certified_stream(registry_version,
self.own_subnet,
remote_subnet,
slice)
}</nowiki>

==== Validation of XNet Payloads ====
Validation of XNetPayloads works analogously to the creation. The function <code>validate_xnet_payload</code> is defined as follows, where it is assumed that it evaluates to false in case an error occurs. Again, note that the gap-freeness of streams is an invariant of the datatype, which is why the rule for gap-freeness is not explicitly included here.
<nowiki>% Check whether a given xnet payload was built according to the rules given above.
%
% FAIL IF: size_of(payload) > size_limit
%
validate_xnet_payload : Self × RegistryVersion × Height × Vec<XNetPayload> × XNetPayload × ℕ → Bool
validate_xnet_payload(self, registry_version, reference_height, past_payloads, payload, size_limit) :=
S = StateManager.get_state_at(reference_height) ∧
∀ (remote_subnet ↦ css) ∈ payload :
{
slice = StateManager.decode_certified_stream(registry_version,
self.own_subnet,
remote_subnet,
css) ∧
∀ index ∈ min(dom(slice.msgs.elements)) :
{
(remote_subnet, index) ∈ expected_indexes(S, past_payloads) ∨
index = (remote_subnet, StreamIndex::ONE)
}
}</nowiki>

IC execution layer

2025-06-30T21:59:27Z

Jessie.mongeon:

{{#externalredirect: https://learn.internetcomputer.org/hc/en-us/articles/34208985618836-Execution-Layer}}

Trustless multi-chain web3 using the IC

2025-06-30T21:39:16Z

Jessie.mongeon:

{{#externalredirect: https://learn.internetcomputer.org/hc/en-us/articles/34329023770260-Chain-Fusion}}

'''On the Internet Computer, you can [https://internetcomputer.org/multichain create smart contracts that directly interact with other blockchains], without trusted centralized bridges that can get hacked and do rug pulls. This has been made possible using [[chain key cryptography]].'''

Decentralized applications and services can delight users by incorporating the assets and functionality of multiple blockchains. Using the Internet Computer, developers gain the technical superpowers necessary to deliver such game-changing experiences, while preserving user safety and convenience.

The web3 environment contains multiple blockchains that have different characteristics and excel in different roles. A key web3 philosophy is [https://en.wikipedia.org/wiki/Service_composability_principle service composability], in which different blockchain services are composed to create new services and functionality. Tokenized assets and liquidity must also be able to move between services, whichever blockchain they are on. The Internet Computer provides a means to fully support this paradigm in a multi-chain environment without need for trusted bridges run by central controllers such as companies.

For example, when building a DeFi framework on the Ethereum blockchain today, a means must be found to create the user experience. Typically, this is built on centralized servers or cloud services today, creating a serious security vulnerability, and exposing the developers who pay for the servers or cloud services to legal liabilities (since regulators can argue that the service built using Ethereum is not running in the mode of a decentralized protocol). Therefore, it would be better if the user experience could be created on the Internet Computer using canister smart contracts, which are controlled by a DAO. A means has been provided to do this (please check developers docs to see what is in production at any one time).

The functionality has been provided by extending the novel [[chain key cryptography]] protocols that power the Internet Computer. These protocols provide each [[Limitless_Scaling#Subnet Architecture|subnet blockchain]] within the overall Internet Computer network with their own public [[chain key]], for which they can create cryptographic signatures on messages that prove returned results have not been tampered with, and that they are operating correctly (for the technically minded: this functionality involves consensus that depends on [https://en.wikipedia.org/wiki/Threshold_cryptosystem threshold cryptography] and other cryptography schemes, including [https://internetcomputer.org/how-it-works/noninteractive-distributed-key-generation-nidkg/ non-interactive distributed key generation] (NIDKG) and key resharing techniques, which provide for chain keys to be maintained indefinitely, even as network nodes come and go, with signing scaled using [https://en.wikipedia.org/wiki/Merkle_tree Merkle trees]).

The chain key cryptography protocol engine was extended so that hosted smart contracts can maintain [https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm ECDSA] public keys, and make corresponding signatures, without need to store a [https://en.wikipedia.org/wiki/Public-key_cryptography private key] on the blockchain in a way that would allow it to be stolen. Crucially, ECDSA is the signature scheme used to sign TX on ''other blockchains'', and allows smart contracts on the Internet Computer to create TX that other blockchains directly execute.

One application has been the provision of special Bitcoin capabilities to canister smart contracts. This allows them to create bitcoin addresses, and send and receive bitcoin directly ''on'' the Bitcoin ledger, without any need for insecure trusted intermediaries such as bridges. Essentially, smart contracts on the Internet Computer can process bitcoin almost as though they are hosted by the Bitcoin network themselves. This provides a way to use bitcoin within web3 services built on the Internet Computer, without asking users to wrap their bitcoin using a trusted bridge run by central controller, which might get hacked, or do a "rug pull".

Another application is the signing of TX designed to invoke smart contracts on other blockchains, such as Ethereum. For example, to interact with Ethereum, an Internet Computer canister smart contract would first create an ECDSA public key that functions as an [https://ethereum.org/en/developers/docs/accounts/ Ethereum Account] (before use this should be charged with some ETH to pay for gas). Thereafter, the smart contract can invoke smart contract calls on the Ethereum blockchain, by creating and signing appropriate Ethereum TX that will be executed by Ethereum network. The smart contract can then determine the results of the TX by using the [[HTTPS outcalls]] feature to interact with Ethereum local nodes.

Using the power of chain key cryptography, the Internet Computer can thus be used as an orchestration blockchain, or meta blockchain, upon which new services can be built that combine functionality and assets provided by ''other blockchains'' in the web3 universe - all without the need to trust a central party, and without the inconvenience and risk of using wrapping and bridges.

'''Pro tip: At the time of writing, there are no other blockchains in existence that can create TX on other blockchains for their smart contracts. Blockchains that talk about "native integrations" are usually talking about a bridge run by the company that backs them.'''

Network Nervous System

2025-06-30T21:38:40Z

Jessie.mongeon:

{{#externalredirect: https://learn.internetcomputer.org/hc/en-us/articles/33692645961236-Overview}}

Chain key cryptography

2025-06-30T21:38:17Z

Jessie.mongeon:

{{#externalredirect: https://internetcomputer.org/docs/references/t-sigs-how-it-works}}

Please see this description of [https://medium.com/dfinity/chain-key-technology-one-public-key-for-the-internet-computer-6a3644901e28 chain key cryptography].

Replace traditional IT with a World Computer

2025-06-30T21:37:50Z

Jessie.mongeon:

{{#externalredirect: https://learn.internetcomputer.org/hc/en-us/articles/34574399808788-ICP-and-the-Internet}}

'''The Internet Computer aims to realize the [[World Computer]] vision first mooted within the [[Ethereum]] community in 2014. It is an open and decentralized platform that provides an alternative to the traditional IT stack, which is comprised of things such as [[cloud computing]] services, server computers, database servers, web servers, middleware, backup systems, and security infrastructure such as firewalls. The Internet Computer network provides an alternative platform that can be used to build and run almost any online system or service.'''

How, you might ask, can a public network provide an alternative to the $5-trillion-dollar-a-year IT industry (according to Gartner). The answer is that the Internet Computer is a radical new form of blockchain made possible by [[chain key cryptography|novel cryptography]] and math. Unlike traditional blockchains, it does not need to indefinitely store old blocks of transactions, does not need [[local node]]s in its network, and can scale its capacity to host compute, with orders of magnitude more efficiency.

On the Internet Computer, developers can build almost any online system or service desired, just by writing [[canister smart contract]] code. Canisters are [[smart contract]]s with breakthrough levels of efficiency, have the speed to process HTTP requests and serve interactive web experiences directly to end users, and can be composed to ''build almost any system or service''. Furthermore, their data is weakly private, with stronger privacy options in the works. Yet, while they work differently, for example running in parallel, they also have the key magical properties of traditional [[smart contract]]s.

For example, [[canister]]s are unstoppable, and also tamperproof, which means that when their code is invoked, the Internet Computer is guaranteed to run the correct logic against the correct data. Furthermore, they can be made to run autonomously if required, and can process tokens.

===No firewalls or security infrastructure necessary===

One obvious advantage that the Internet Computer provides over traditional IT is security.

Systems and services running from the Internet Computer, which have been built using canister smart contracts, don't need to be protected by firewalls. This is similar to how DeFi smart contracts on [[Ethereum]] don't need to be protected by firewalls. Instead, they are secure by default, which is the exact opposite of systems built using traditional software that run on traditional IT, which have no security by default, and must be protected by teams of security administrators, special configurations, and special security tech such as [https://en.wikipedia.org/wiki/Firewall_(computing) firewalls] and [https://en.wikipedia.org/wiki/Security_information_and_event_management SIEM logging].

[https://www.vox.com/recode/22428774/ransomeware-pipeline-colonial-darkside-gas-prices When systems and services are built using traditional IT, just one simple mistake can allow a hacker can steal data, or encrypt systems using ransomware, with catastrophic results], and it happens all the time. In 2022, worldwide expenditure on IT security will be $172 billion dollars (according to Gartner), but the intangible costs of constant hacks and potential business disruption is much higher.

Traditional IT is in the midst of a security meltdown, and the Internet Computer provides a way out. Because systems built on the Internet Computer using canisters are secure by default, the costs involved with security tech and its operation can be avoided, as can the vast majority of the intangible costs of hacks, and the damage they cause.

''Where Web3 services and applications are concerned, which involve token assets that can be stolen, security is even more critical. Here it's possible to go one step further, by placing the canisters behind the service or application under the full control of a [[DAO]], so that if a developer goes rogue and wishes to hack the system, they are unable to do so because they cannot change its code in an unmoderated manner.''

===Build on a public network, not on a Big Tech fly trap===

The game-changing advantages of the Internet Computer go far beyond security. In the 1990s, there was an ongoing debate regarding whether the public internet, or walled-garden networks, such as AOL, Compuserve and the [https://www.microsoft.com/en-us/research/publication/on-ramp-prospects-for-the-information-superhighway-dream/ "Information Superhighway" Microsoft imagined], would prevail. Eventually the internet easily won out because it was permissionless, and provided a free market, and nobody wanted to be fed content that was carefully curated for them by mega corporations.

It was a free market because, if Alice and Bob created profitable but competing websites, say, then Alice could not call up the owner of the internet and say "if you slow down the public's access to Bob's website, I will give you stock in my company." The permissionless free market provided the foundations for social impact and freedoms, innovation and massive economic growth.

''The internet provided decentralized, permissionless and global network connectivity that now connects almost everyone and everything. The industry now needs to go one step further and do the same for computation using a [[World Computer]].''

The lives of the nearly 8 billion people on this planet could not be supported without the massive computing power that automates our global society's infrastructure. For example, it automates markets and supply chains that facilitate farming through the manufacture of fertilizer and tractors, and then the efficient transport of farm produce to supermarkets. Meanwhile, online interactions have created a social and business fabric that is an indispensable part of our personal and work lives.

Given how pivotal society's information infrastructure has become to human existence, it makes no sense to build it out on the back of a few anointed Big Tech services, such as [[Amazon Web Services]], who will then make us all captive. Moreover, when compared to what the Internet Computer can provide as a blockchain, these platforms have serious disadvantages.

To use traditional IT, developers must combine and integrate a veritable menagerie of components — such as servers or cloud instances, cloud orchestration layers, databases, web servers, memcached, backup systems, content distribution networks, middleware, security tools and much more — creating systems and services that resemble [https://en.wikipedia.org/wiki/Rube_Goldberg_machine Rube Goldberg machines] that are fragile and unnecessarily complex.

Managing this complexity is the source of the biggest cost of all. Of the $5 trillion dollar global IT spend, 80% of that is spent on IT operations, which is comprised from human beings spending much of their time managing complexity. Organizations operating an important but simple website, say, will often hire systems administrators, database administrators and security administrators just to keep it running. This costs crazy amounts of money. These complex systems also cannot be updated quickly, creating opportunity costs.

Meanwhile, when building on traditional IT, the reward is typically to become a captive customer of a [[cloud computing]] service provider and other vendors. Those building using the proprietary and complex stack provided by [[Amazon Web Services]], for example, often eventually find themselves in a similar predicament to those building using the Microsoft software stack twenty years ago, and get stuck there because the re-engineering costs involved with moving are too great. Cloud computing services keep releasing new platform features, and a large part of the reason, is to better trap those lured into building there.

The Internet Computer now provides a clear alternative in the form of a public network. On this open platform, you build using canister smart contract code that is unstoppable and secure without firewalls, and which greatly simplifies the construction and maintenance of systems and services.

===Build on the internet to emit less CO<sub>2</sub>===

Traditional IT evolved in a time when computers were vastly less powerful, and the internet vastly slower, embedding architectural decisions that are no longer relevant at the root of an evolutionary branch of technology that is increasingly wrong-headed in the modern world.

Even though the Internet Computer is an advanced blockchain, it may come as a surprise that when used as an alternative to traditional IT, it can reduce CO<sub>2</sub> emissions. That is because its architecture, cryptography and network governance, is able to configure the replication of computation and data within its network (a key source of inefficiency within traditional blockchain networks), in a ways that constrain the order of replication to the minimum needed to provide the strong liveness (unstoppability) and security guarantees expected of a blockchain.

Very deliberately, the Internet Computer's architecture and math embraces the replication of computation and data, using it to provide a platform for unstoppable and secure tamperproof code, while also scaling certain kinds of computation, such as data queries and web serving.

By contrast, traditional IT is replete with accidental, tacked-on replication. When you create a system or service, very often data is replicated across several database nodes, backup systems, middleware, and more copies are kept handy by the code producing web pages, for example using memcached. Then the web pages and other content served are further replicated by [[Content Distribution Network (CDN)|CDNs (content distribution networks)]].

When systems and services built using traditional IT components are considered as a whole, this accidental hidden replication is often very substantial. However, despite all the hidden replication involved, when systems and services are built using traditional IT, they are not unstoppable or secure and tamperproof.

The Internet Computer challenges deeply held misconceptions about blockchain science. In the popular imagination, it is defined by computationally expensive [https://en.wikipedia.org/wiki/Proof_of_work proof-of-work networks], which Satoshi introduced in his 2008 paper. These sometimes use as much power as a small country, yet can only process a handful of transactions a second.

The Internet Computer flips this narrative. It is a blockchain that can play the role of an end-to-end platform, which provides an alternative to traditional IT that will arguably be more efficient with respect to electricity consumption.

===Web3 and cloud are incompatible===

Today, if you ask much of the public and journalists what Web3 is, they will mostly propose that it is something to do with [[NFT]]s. But those working at the forefront of the field understand it as something much more profound and impactful. Web3 is about replacing today's Web 2.0 services, which are mostly run by big corporations, with an infrastructure that engages users through the tokenization of assets and participation rights, and by assigning full control over these services to [[DAO]]s (decentralized autonomous organizations), so they can be run by their communities.

In the future, Web3 online services will run rather like open economies. They will be controlled by DAOs, which in turn will be controlled by voting using [[governance tokens]]. These tokens will be held by founders, core developers, investors and, most importantly, the end users of the services themselves. Algorithms will be give them out to users who contribute, perhaps because they are prolific creators of popular content, refer other users to the service, or help with content moderation. Users will be the owners of services, and also part of the team that runs them — which will enable them to scale fast, and make them more viral and sticky.

Entire metaverse world's will run entirely from the blockchain. For example, one metaverse project being built on the Internet Computer today enables users to create their own 3D island, in the style of Minecraft, which they can share via a URL on their social media profiles. That world is itself an NFT, but they can also import ready-crafted objects into their metaverse islands, such as a castle or art gallery, by acquiring NFTs, then use the space to sell art NFTs. Island owners can create gateways to other islands, as a means to share traffic, and then sell the gateways as NFTs. This only scratches the surface of what is being done: The metaverse is an economy.

Meanwhile, in Web3, everything blends with DeFi. For example, social media can blend with DeFi to become [[SocialFi]]. Open Chat ([https://oc.app oc.app]) is a messaging service that runs entirely from the Internet Computer blockchain, where smart contracts process and store text messages and media messages such as video. But this is no normal messaging service. A user account can also play the role of a crypto wallet, which maintains bitcoin, [[ICP Tokenomics#Uses_of_ICP_token|ICP]] and other tokens that can be sent along with chat messages. On top, it is being integrated by other Web3 developers, and special group chats now provide users with easy ways to vote on DAO governance proposals, among other things.

The question of how security and regulation are handled by these new services is critical. Users do not want to lose their NFTs in a hack, especially if they confer ownership of a valuable and highly trafficked metaverse they created, say, and they also do not want to have their cryptocurrency and other tokens stolen. Furthermore, the developers of such services, do not want to find themselves classified as [https://en.wikipedia.org/wiki/Money_transmitter money transmitters], say, because they were constructed using centralized traditional IT.

Any reasonable analysis shows that the only practical way to solve these problems is to run Web3 services in the mode of protocols, just like blockchains themselves. This can be done by building them exclusively using smart contracts that are then placed under the ''full and exclusive control of community DAOs''. Once control has been transferred to a community DAO, and the service runs 100% from the blockchain without the use of traditional IT, the developers cannot arbitrarily change the code in an unmoderated way to steal crypto balances. Nor can anyone else steal the crypto balances unless their code is flawed.

Moreover, when a Web3 service truly runs autonomously in cyberspace, under the exclusive control of a community DAO, then its management and ownership is no longer rooted in a jurisdiction and it runs in the manner of a decentralized protocol. There is no centralized entity such as a person, group of developers, or corporation that is responsible for its ongoing operations. This is very different to a Web3 service built using a cloud computing service, or other traditional IT, which roots it in a jurisdiction and directly transfers legal responsibility to those who control and own the cloud account. This responsibility is also transitively transferred to any shadow controllers.

The Internet Computer provides for any Web3 service or application to be built entirely on chain using smart contracts, without need for cloud computing, server computers, or any other traditional IT. Furthermore, services and applications can be placed under the full control of DAOs, either using the built-in [[Service Nervous System]] DAO framework, or third party DAO frameworks.

===Web3 TL;DR===

However you plan to build a Web3 service or application, you need to ditch the cloud and traditional IT. You can either build exclusively on the Internet Computer, or [[Extend_Bitcoin,_Ethereum_and_other_blockchains|combine smart contract code on the Internet Computer with smart contract code on other chains such as Ethereum]].

Today, finally, thanks to years of work by engineers, computers science researchers and cryptographers, ''blockchain is the stack''.

[https://internetcomputer.org/developers Get started building systems, applications and services using canister smart contracts running on a real World Computer].

==See Also==
* '''The Internet Computer project website (hosted on the IC): [https://internetcomputer.org/ internetcomputer.org]'''

Canister smart contract

2025-06-30T21:37:28Z

Jessie.mongeon:

{{#externalredirect: https://learn.internetcomputer.org/hc/en-us/articles/34210839162004-Canister-Smart-Contracts}}

IC architecture overview

2025-06-30T21:37:04Z

Jessie.mongeon:

{{#externalredirect: https://learn.internetcomputer.org/hc/en-us/articles/34206453538964-Blockchain-Protocol}}

[[File:IC-protocol-stack.png|500px]]

As illustrated in the above diagram, the Internet Computer Protocol consists of four layers:
* [[IC execution layer]]
* [[IC message routing layer]]
* [[IC consensus layer]]
* [[IC P2P (peer to peer) layer]]

Description of specific features:
*[[IC Smart Contract Memory]]
*[[Bitcoin integration]]
*[[HTTPS outcalls]]
* [[Subnet splitting]]

Canisters serving the web:
* [[HTTP asset certification]]
* [[Boundary Nodes]]

==See Also==
* '''The Internet Computer project website (hosted on the IC): [https://internetcomputer.org/ internetcomputer.org]'''

DAO

2025-06-30T21:36:38Z

Jessie.mongeon:

{{#externalredirect: https://learn.internetcomputer.org/hc/en-us/articles/34574082263700-Tokenomics-Governance}}

A Decentralized Autonomous Organization, or DAO for short, is a system that allows many parties to jointly control an entity.

<span id="what-is-a-dao"></span>
== What is a DAO? ==
Let’s first clarify what ''decentralized'' means in this context. First, an application can run on a ''decentralized platform''. This means that the platform itself is controlled by many different parties and, in particular, that even if some of these parties fail or turn malicious, the application will still keep running successfully. The IC is such a platform as it is run by many nodes that are owned by independent node providers. Therefore, applications that run on the IC are called ''decentralized applications'' or ''dapps''.

A second kind of decentralized denotes who is in control of changing a dapp, or a smart contract more generally. In general, dapps running on the IC or smart contracts on other decentralized platforms can still be controlled by a single, central entity and thus still be under centralized control. As motivated below, it is often beneficial if a dapp is also under ''decentralized control''. This means that no single party can decide how the dapp is evolved. Instead, the dapp can only be changed according to decisions that many parties jointly make. This decentralized control of a dapp is what a DAO achieves.

<span id="motivation-why-a-dao"></span>
== Motivation: why a DAO? ==

The following discusses the main motivations for DAOs from the point of view of two main actors on the IC: the dapp developers, who build dapps on the IC, and the end-users, who interact with and invest in dapps.

<span id="dapp-users"></span>
=== Dapp users ===

Dapps on the IC are realized as a set of canister smart contracts. Canisters define a ''controller'' specifying which principals can modify them. Most dapp canisters are either controlled by some developers or have no controller at all. Both situations have downsides for a dapp’s users. In the case where a dapp is controlled by a centralized group of developers, users of the dapp must trust these developers not to stop the application and not to modify the application in an undesirable way, e.g., that favors the developers. In the case where the canister has no controller, it cannot be upgraded at all. This not only prevents evolving the dapp regarding new requirements but might also be a problem when it is necessary to fix security bugs.

DAOs provide a third option, namely to hand over the control over a dapp to a community that can jointly decide how to evolve a dapp in an open governance system, i.e., to ''decentralize a dapp’s control''. This protects users as the control is now in the hand of a community rather than in the hand of a few parties. Moreover, dapp users can join the open governance themselves and thereby directly impact how the dapp is evolved.

===limitations of DAO concept===
As the ICP ecosystem scales, many new dapps are appearing which need to be integrated with each other. Only focusing on the functions and features of a single dapp will not make ICP successful. Therefore, the overall architecture of all ICP dapps need to be considered and smart integrations need to be designed ([https://nuance.xyz/manitas/11754-434go-diaaa-aaaaf-qakwq-cai/a-true-world-computer-or-a-couple-of-isolates-apps-hosted-on-a-blockchain- linked research paper]).

ICP staking options

2025-06-30T21:36:10Z

Jessie.mongeon:

{{#externalredirect: https://learn.internetcomputer.org/hc/en-us/articles/34084120668692-Neurons}}

Depending on how you custody your ICP, you have different staking options.

== 3rd Party Solutions ==
There are currently no 3rd party staking solution.

== Self Custody==

=== NNS Frontend dapp ===
If you custody with NNS frontend dapp, see [[ICP staking with NNS frontend dapp]].

=== Ledger Nano ===
If you custody with Ledger Nano, see [https://medium.com/dfinity/integrating-ledger-nano-with-the-nns-front-end-dapp-user-manual-9c5600925e16 Integrating Ledger Nano With the NNS Front-End Dapp: User Manual]

=== Air-gapped machine===
If you custody with Ledger Nano, see [[ICP staking with seed phrase and air-gapped computer]].

==See Also==
* [[Managing ICP holdings]]
* [[ICP custody options]]
* [[ICP custody with seed phrase and air-gapped machine]]
* [[ICP staking with NNS frontend dapp]]

Governance of the Internet Computer

2025-06-30T21:35:47Z

Jessie.mongeon:

{{#externalredirect: https://learn.internetcomputer.org/hc/en-us/articles/33692645961236-Overview}}

The Internet Computer blockchain is governed by the [[Network Nervous System]] (NNS) <ref>https://medium.com/dfinity/the-network-nervous-system-governing-the-internet-computer-1d176605d66a</ref>. The NNS is an algorithmic governance system that oversees the network and the token economics that make it possible to build DeFi dapps, open internet services and enterprise systems.

Holders of the Internet Computer’s [[ICP Tokenomics | ICP utility tokens]] can lock their tokens in [[Neurons 101 | neurons]] to participate in governance and contribute to decision-making, such as voting to determine whether or not a new collection of nodes (also called a subnet) should be added to the network.

=== Why the Internet Computer needs a Network Nervous System<ref>https://medium.com/dfinity/the-network-nervous-system-governing-the-internet-computer-1d176605d66a</ref> ===
The Internet Computer is a distributed protocol run by a [[Sovereign Network | network of node machines]], which are hosted in different data centers. The nodes communicate with one another over the internet to achieve a [[Proof of Useful Work | consensus]] on what the Internet Computer’s state should be. A collection of nodes engaging in consensus is called a subnet. On top of this underlying communication and consensus protocol, the Internet Computer hosts [[Canister Smart Contracts]] called ''canisters'', which are stateful programs that can also communicate with each other. The state of all of the canisters has to be replicated across all of the nodes. Therefore, to allow the Internet Computer to scale indefinitely, the network is made up of not just one subnet, but multiple subnets.

Different [[Subnet_blockchain | subnets]] can communicate with one another, enabling [[Canister Smart Contracts]] that are hosted on different subnets to also communicate with each other. For the Internet Computer to scale on-demand, the network must be able to add new subnets over time to increase compute capacity. Moreover, the robustness of the subnets can be improved by adding new nodes to them over time. Eventually, the Internet Computer will run millions of nodes at scale. This means that there needs to be a mechanism by which the nodes and subnets are organized, tracked, and managed. For example, decisions must be made about when subnets and nodes should be added or removed. In addition, the Internet Computer was launched with an initial feature set, which evolves over time. Therefore, the Internet Computer needs to be able to make decisions on how to evolve the protocol in a distributed manner.

==See Also==
* [[ICP Tokenomics]]
* [[Tutorials for acquiring, managing, and staking ICP]]
* [[Staking, voting and rewards]]
* [[Network Nervous System]]
* [[Total supply, circulating supply, and staked ICP]]
* [[NNS neuron operations related to maturity]]
* [[Roll-over of NNS voting rewards]]
* [[Maturity]]
* [[Replica Upgrades]]

Proof of Useful Work

2025-06-30T21:33:02Z

Jessie.mongeon:

{{#externalredirect: https://learn.internetcomputer.org/hc/en-us/articles/34207558615956-Consensus}}

==Background==

When Satoshi designed Bitcoin, he wrestled with two primary problems. Firstly, he needed to find a way to prevent what is known as a "Sybil attack", which would allow an adversary (i.e. the bad guys) to add additional nodes to the decentralized network, until they could take control. Secondly, he needed to find a way to bring the network to consensus regarding changes to the ledger (i.e. what transactions were processed, and in which order).

His solution was proof-of-work (now sometimes shortened to PoW). Although often described as a decentralized consensus protocol, it is both a decentralized Sybil-resistance scheme, and a consensus protocol. In order to participate in "mining" bitcoin, it is necessary for miners to run special hardware that creates large numbers of cryptographic hashes of blocks they wish to propose, until a "winning" hash is found, whereupon they can submit the block to the network. In practice, the relative number of blocks that each miner produces, and the rewards they earn, is proportional to the amount of hashes that their hardware can perform.

Proof-of-work solves the Sybil problem because vast volumes of hashes have to be calculated to have a chance of producing a block, which involves the dedication of expensive mining hardware, and copious amounts of electricity. As participation in the Bitcoin network grew, it quickly became too expensive for any adversary to acquire and run sufficient hashing hardware that they could perform a large enough share of the network's hashing that they might gain control (for example to double-spend). By fortune, the Sybil-resistance scheme also helped solved consensus, since hashes are random numbers, and winning hashes are discovered randomly only through brute force, and thus a random miner is assigned the job of creating each block.

A great advantage of proof-of-work is that it results in a chain that is produced by relatively stable, dedicated hardware, creating a secure network. Essentially, the Bitcoin network that produces blocks can be thought of as a giant decentralized hashing factory. However, the downside is that the scheme essentially works as a hashing competition, in which the total money miners spend on hashing hardware, and the large amounts of electricity necessary to keep it running, tends towards the value of the block rewards that Bitcoin provides. Moreover, the scheme does not reach consensus quickly.

As a result of the expense, the blockchain industry worked on proof-of-stake (often shortened to PoS) schemes, in which individual network nodes would be joined to the network by staking ("locking") some amount of cryptocurrency, then producing blocks, and earning rewards, in proportion to the amount of cryptocurrency that they have staked. This replaced the expense of the dedicated hashing hardware, and the electricity used to run it, with the cost of capital involved in staking. Ethereum 2.0 migrated the network from a PoW architecture to a PoS architecture. Not only did this allow the network to run much faster, because it could use alternative consensus schemes, but it prevented the environmentally-costly expenditure of electricity to power the hashing hardware.

However, PoS has numerous challenges, which are becoming increasingly apparent. Firstly, once the need for dedicated hardware was removed, a block-producing network node (or "client") could simply be spun up anywhere, including the corporate cloud, and activated just by staking some cryptocurrency. As a result, the vast majority of nodes on PoS networks, run in the cloud. The dangers of running a blockchain in the cloud were recently brought into sharp relief – the Hetzner cloud, in Europe, [https://decrypt.co/113429/is-solana-decentralized-cloud-provider-hetzner-ban-raises-questions recently suddenly banned Solana nodes], immediately causing 40% of its network to disappear in the blink of an eye. A PoS network running in the cloud is very different to a sovereign network, and the potential exists for cloud providers to interfere with nodes, as well as to close them down.

Another challenge with PoS is that cryptocurrency, by its nature, is highly liquid, raising the possibility of swift changes in network architecture and the distribution of power, which is something an attacker can potentially exploit. For example, clever manipulations of DeFi, or the catastrophic hack of an exchange, might provide an attacker with sufficient stake that they can break the network – allowing them to profit after suitably hedging their staked cryptocurrency. PoS networks often provide frameworks that make it easy to spin up new nodes on the cloud in an instant, allowing a suitably financed adversary to launch an attack by running a script.

==Proof of useful work==

Proof-of-useful-work (PoUW) is the Internet Computer's answer to these kinds of considerations, and is more complex than the foregoing schemes. It involves a blockchain being produced by dedicated hardware called "node machines" that are of very similar, standardized specification. On the Internet Computer, these run highly sophisticated consensus protocols that lean into the power of advanced cryptography, often referred to as Chain Key Crypto. PoUW is concerned with membership in the network.

Naturally, as per PoW, the purchase, hosting and operation of node machine hardware acts as the stake. However, these machines don't do hashing, and simply produce and process blocks of transactions that represent smart contract computations. The reason that combined node machines must be built to the same standardized specification, is that rather than compete to perform hashing, they must try not to "statistically deviate" by producing more or less blocks. In essence, rather than trying to perform more computation, they try to perform the same amount of computation, and can be punished for deviating from the group.

A key ingredient of the scheme is the [[Network Nervous System]] (or NNS), a sophisticated permissionless DAO that is integrated with the Internet Computer's protocols. This fully controls the network, configuring it, and upgrading the software run by node machines. Amoung its responsibilities, it combines node machines to create "subnet blockchains," which themselves are combined into a single blockchain using Chain Key Crypto. This achieves two important things. Firstly, expense aside, it is not possible for an adversary simply to add nodes to a subnet blockchain, since the NNS carefully selects nodes by looking at the node provider, the data center the node is installed within, and its geography and jurisdiction, in a scheme of "deterministic decentralization." Secondly, the NNS can remove (or "slash") nodes that statistically deviate.

By applying deterministic decentralization, the NNS creates a highly secure scheme in which the Internet Computer runs on a sovereign network of dedicated hardware, formed from node machines, which machinery can be tightly held to correct behavior in order to continue its participation in block production (through which its owners, the node providers, earn rewards). In PoUW, the repetitive hashing work of PoW, whose purpose relates primarily to network operation, has been replaced by useful smart contract computation. Since this is work that must be performed anyway, a supremely efficient network is produced.

==Useful historical resources==

Project founder Dominic Williams was an early pioneer in the study of crypto Sybil resistance and consensus. Here in May 2015 [https://www.youtube.com/watch?v=dfGDhDR_3Gc he gives a talk discussing Sybil resistance and consensus at San Francisco Bitcoin Devs], in which he discusses the "3 E's of Sybil Resistance." Other interesting historical material that provides insights into the development of PoUW, include a [https://www.youtube.com/watch?v=1KaQsrqC94s panel on scalability with Vitalik Buterin and Gavin Wood], and a talk [https://www.youtube.com/watch?v=3iSw03pJ-gk introducing consensus theory], at Ethereum's DEVCON1 later that year.

==See also==
* [[Deterministic Decentralization]]
* [[Sovereign Network]]

Deterministic Decentralization

2025-06-30T21:32:41Z

Jessie.mongeon:

{{#externalredirect: https://learn.internetcomputer.org/hc/en-us/articles/34207558615956-Consensus}}

==Introduction==

Deterministic Decentralization is the idea that ICP should measure and maximize the the diversity and decentralization of each subnet, rather than ''optimistically'' hope for decentralization by allowing any node to join network. Deterministic Decentralization tries to maximize the decentralization of every sub-layer of the infrastructure layer. This means, for example, maximizing the following:

# Number of unique node providers
# Number of unique data centers
# Number of unique jurisdictions

==Design Intent==

===Background===

* An empirical pattern from studying other blockchains: infrastructure layers tend towards high-concentration (2-4 entities) controlling 51% of the infrastructure and 1-2 jurisdictions (e.g. US, China) controlling 51% of the infrastructure. In practice, permissionless (even without a DAO) infrastructure layers tend to a concentration where the “anyone can run a node from home” tends to be a figleaf for concentration of a few big players.

* Networks like BTC or ETH have protocol-level limitations where the protocol will have the same throughput of transactions whether it has 10 nodes or 10,000 nodes. These do not scale by adding more nodes.

* Many networks have inconsistent node uptime/availability as miners switch off/on their nodes due to unpredictable crypto markets, sometimes making nodes unprofitable to run.

* A lot of the node’s computation in other blockchains is used up in puzzles (e.g. Proof of Work) rather than useful computation.

===ICP is designed to have the following properties===

* The IC's method of "manicured" subnets, even though less decentralized in theory, actually gives you better decentralization in practice.

* ICP compute capacity grows by adding more nodes

* To balance ICP minting rate and developer demand for compute, the NNS DAO decides how many more nodes to add

* To maximize decentralization, NNS DAO measures and maximizes decentralization, rather than leave it to chance

* To incentivize ICP to have maximum availability, the node reward has predictable rewards for each node

* To incentivize general availability, the NNS DAO rewards nodes for being part of the system and removes them if they start to deviate consistently.

* To maximize reliability and health of the network, NNS DAO can remove nodes that consistently deviate (maybe they are faulty or are malicious).

==See Also==

* [[Sovereign Network]]
* [[Decentralization in ICP: Infrastructure Governance]]

Sovereign Network

2025-06-30T21:32:21Z

Jessie.mongeon:

{{#externalredirect: https://learn.internetcomputer.org/hc/en-us/articles/34206453538964-Blockchain-Protocol}}

'''The Internet Computer blockchain network is hosted by special [[Glossary#node|node machines]], which are hardware devices that are dedicated to the task (thus creating a sovereign network). This is conceptually similar to how the internet is hosted by network routing devices.'''

==Design Intent==

Traditional blockchains are different. Their network nodes are created using simple software, which interacts with other nodes and maintains a copy of blockchain state. Today, software programs are very easy to spin up on [[cloud computing]] "instances" using services such as [[Amazon Web Services]]. A consequence has been that the majority of nodes in traditional blockchains are cloud computing instances. Because these can be spun up in an instant, the investment required to create or destroy a node is minimal (notwithstanding any cryptocurrency stake that might be required to add a node to the network).

A grave risk with these kinds of architectures is that control over the blockchain network is handed to a small number of giant corporations. These corporations might decide they must switch off the nodes, owing to changes in regulation, or competitive threats, or malicious insiders might use their access to the physical cloud infrastructure to steal keys, or otherwise disrupt the networks.

''These issues do not exist with the Internet Computer, because it runs on a sovereign network.''

Every node in the Internet Computer network is a dedicated physical device, called a [[Glossary#node | node machine]], which is run by an independent [[Node providers|node provider]], typically from rack space in an independent [[data center]]. The nodes cannot therefore be switched off or tampered with by a small number of corporate cloud computing service providers.

While this is an important advantage, there are other technical reasons that special [[Glossary#node | node machine]]s are required to participate in hosting the Internet Computer network. The node machines are built to standardized public hardware specifications. This means that when the network is under load, they do not fall behind other nodes inside the same [[subnet blockchain]], which statistical deviation the network's decentralized governance DAO might notice, and sanction them for.

==Joining The Network==

===Decentralization===
The blockchain uses [[Deterministic Decentralization | deterministic decentralization]] to maximize the [[Decentralization in ICP: Infrastructure Governance | infrastructure decentralization]] of the network.

===Node Providers===
[[Node providers]] invest in and operate the node hardware which powers the ICP network. Running these nodes in data centers provides the high performance and the cost-effectiveness of the Internet Computer. Every node provider is allowed a limited amount of nodes.
* [[Node Provider Onboarding]]
* [[Node Provider Remuneration]]
* [[Node Provider Self-declaration]]

==See also==
* [[Proof of Useful Work]]
* [[Deterministic Decentralization]]

Roll-over of NNS voting rewards

2025-06-30T21:31:50Z

Jessie.mongeon:

{{#externalredirect: https://learn.internetcomputer.org/hc/en-us/articles/34142993417108-Voting-Rewards}}

==Background & goal==
* The automation of exchange rate proposals is planned to be released in May ‘23.
* Post this release, on some days (in particular on weekends) no NNS proposals might be submitted. Previously this was not possible as exchange rate proposals were submitted every 10 minutes.
* As a consequence, there might be days during which no NNS proposals will settle. Since the distribution of NNS rewards is linked to the ballots of settled proposals, on those days no rewards are distributed. Rather, rewards will roll over to the following day.
* On this page the roll-over mechanism is explained.

==Reward roll-over mechanism==
* For any given day t_0 the NNS determines the total amount of available rewards R(t_0) for that day as a function of total supply and the voting reward function. For further background information on voting rewards see [https://internetcomputer.org/docs/current/tokenomics/nns/nns-staking-voting-rewards/#voting-rewards here].
* Now assume that on day t_0, no proposal settled and thus no rewards could be distributed.
* As a consequence, the NNS will roll over the rewards to the following day t_1. This means that on day t_1 a total amount of R(t_0) + R(t_1) is available for distribution.
* If at least one proposal settled on day t_1 then this triggers a reward distribution. Otherwise rewards will again roll over to the following day and so on.

==How this will be displayed in the NNS dapp==
The NNS dapp will provide users information about the last time voting rewards were distributed, as you can see from the below screenshot.

[[File:NNS dapp roll-over.png|800px|center]]

If the indicated date is more than one day in the past, then NNS rewards are currently rolling over.

NNS neuron operations related to maturity

2025-06-30T21:31:14Z

Jessie.mongeon:

{{#externalredirect: https://learn.internetcomputer.org/hc/en-us/articles/34140499557908-Neuron-Attributes}}

== Background & goal ==

* Maturity is an attribute of a neuron; it is not a tradable asset. Neurons receive voting rewards in the form of maturity.
* Whenever you burn maturity to create newly minted ICP, [https://wiki.internetcomputer.org/wiki/Maturity_modulation maturity modulation] is applied.
* Maturity modulation introduces uncertainty in the conversion process from maturity to ICP, depending on the ICP price trend.
* This article explains how the maturity modulation interacts with neuron operations related to maturity, in particular spawn maturity and stake maturity.
* For further background on neurons and the NNS, please see [https://medium.com/dfinity/the-network-nervous-system-governing-the-internet-computer-1d176605d66a#:~:text=The%20Network%20Nervous%20System%2C%20or,how%20to%20update%20this%20information. here].

== Spawning maturity ==

* If a user triggers spawn maturity, a new neuron will be immediately spawned; however, this newly spawned neuron will have no ICP at start, only maturity.
* Spawned neurons have a dissolve delay of 7 days and are dissolving.
* After 7 days when the neuron is dissolved, the amount of ICP, determined by the maturity modulation function, will be minted and be available to the user.

== Staking maturity ==

* A user can stake maturity which locks the maturity until the neuron is dissolved. Once a neuron is dissolved, staked maturity is unlocked and becomes normal maturity.
* Staked maturity contributes to the voting power of the neuron as determined by Voting Power = (ICP staked + maturity staked) x Dissolve Delay Bonus x Age Bonus
* No ICP is (or can be) produced from staked maturity until the neuron is dissolved and the maturity is spawned (as described in the section above), at which point it is subject to maturity modulation.

== Auto-staking of maturity ==

* Daily voting rewards may be received either as staked maturity or maturity.
* This choice can be changed for future rewards at any time.
* If rewards are received automatically as staked maturity, voting rewards accumulate over time as voting power of the neuron increases with every reward event.

== Outlook on maturity operations ==
* Merge maturity (which adds maturity of a neuron to the ICP stake) is deprecated in the NNS II UX, NNS hardware wallet and NNS quill.
* Spawn maturity is planned to be replaced by a new operation called disburse maturity (this is already implemented for the SNS).
** This operation begins a 7 day clock that completes with a modulation of the amount of minted ICP to be received.
** This final amount of newly minted ICP is then transferred into the account of a neuron holder.
* The community has requested to enhance the proposed disburse maturity functionality, to support automatic re-staking of the newly minted ICP. This would provide a similar functionality to the previous merge function , but with the 7 day delay & modulation applied. DFINITY is looking into how best to support this.

==See Also==
* '''The Internet Computer project website (hosted on the IC): [https://internetcomputer.org/ internetcomputer.org]'''

Total supply, circulating supply, and staked ICP

2025-06-30T21:30:11Z

Jessie.mongeon:

{{#externalredirect: https://learn.internetcomputer.org/hc/en-us/articles/34090810571284-Tokenomics}}

For a crypto community to understand the [[Governance of the Internet Computer | governance]] and [[ICP Tokenomics | tokenomics]] of ICP, understanding the supply of ICP is important.

==Definitions==

===Total supply===

Total supply is the sum of all tokens currently in the system (whether they are locked/staked or not).

The total supply changes over time due to inflation and deflation. Its current value can be seen on the [https://dashboard.internetcomputer.org/circulation IC Circulation page] of the IC dashboard.

===Circulating supply===

The circulating supply is all tokens except liquid (non-staked) tokens owned by the DFINITY Foundation. The circulating supply definition was updated to its current definition on 18APR23 through an approved vote by the NNS on [https://dashboard.internetcomputer.org/proposal/117360 proposal 117360.]

The current circulating supply can be seen on the [https://dashboard.internetcomputer.org/circulation IC Circulation page] of the IC dashboard.

===Staked ICP===

Staked ICP supply is the sum of all the tokens that are locked or dissolving in neurons at any given time that are earning rewards. At this time, there is a minimum lockup period of 6 months to accrue voting rewards.

The total amount of staked ICP changes over time. Its current value can be seen on the [https://dashboard.internetcomputer.org/neurons Neurons page] of the IC dashboard.

==Numbers==

===At network Genesis===

May 10, 2021:
* Total supply: 469 million
* Circulating supply: 123 million

===Current status===
As of March 17th, 2025:
* Total supply: 530.6 million ICP
* Circulating supply: 481.7 million (90.8% of total supply)
* Staked ICP: 234.1 million (44.1% of total supply).
** 87.2% of ICP staked is staked with more than a 1-year dissolve delay
** 61.5% of ICP staked is staked for an 8-year dissolve
** One can see the breakdown of staked ICP by dissolve delays in [https://dashboard.internetcomputer.org/neurons IC neuron dashboard].

* As outlined in the section above Circulating supply represents ICP that was ever liquid. A subset of the circulating supply is locked in neurons as staked ICP.

==Inflationary mechanisms==

The NNS mints ICP tokens for two reasons:
* For voting rewards (Governance).
* For node provider rewards.

The amount of ICP minted since Genesis can be seen in the [https://dashboard.internetcomputer.org/circulation "Total Rewards" chart] on the IC dashboard.

===Paying staking rewards===

Voting rewards are generated by minting ICP, although this minting only happens at the moment rewards are spawned, maturity is merged, or the neuron is disbursed.

The voting rewards rate schedule is designed with the goal that 90% of the token supply is staked in neurons. With this goal in mind, in the first year, the NNS allocates 10% of the total supply to generate voting rewards. Note the term "allocates" rather than "mints", because 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, this allocation rate drops quadratically until it reaches 5% by year 8. See chart below from the [https://dashboard.internetcomputer.org/circulation IC Circulation page] on the IC dashboard.:

[[File:NNS minting % by year.png|800px|frameless]]

'''Like all parameters in the NNS, this rate schedule can be changed via NNS proposals.'''

See more in [[Staking, voting and rewards]].

===Node provider rewards===

Node providers are rewarded for running the node machines that power the Internet Computer.

==Deflationary mechanisms==

The NNS burns ICP tokens for three reasons:

* To mint cycles, used to pay for compute and storage.
* For transaction fees.
* For failed NNS proposal fees.

The amount of ICP burned since Genesis can be seen in the [https://dashboard.internetcomputer.org/circulation "Total ICP Burned" chart] on the IC dashboard.

===Paying for compute and storage===

Dapp and smart contract developers pay computation and storage costs with cycles. Cycles are acquired from the NNS by converting ICP to cycles, which burns the converted ICP.

The cycles costs for IC computation and storage can be seen at [https://smartcontracts.org/docs/developers-guide/computation-and-storage-costs.html Computation and Storage Costs].

===Transaction fees===

Transferring ICP across accounts incurs a transaction fee of 0.0001 ICP, which is burned.

===Failed NNS proposals===

It costs 25 ICP to submit a proposal. If the proposal passes, the 25 ICP is returned to the proposer. If the proposal is rejected, the 25 ICP is burned. Note that this only happens at disbursement or merging of neurons, so accumulated failed proposal fees can persist for a while before finally contributing to deflation.

==Historical factors affecting circulating supply==

The Internet Computer blockchain is a result of several years of unyielding R&D. By Genesis, the DFINITY foundation, a major contributor to the Internet Computer was over 200 full-time members. Over the past several years the foundation raised financing in three main rounds and also allocated ICP tokens to the community in the form of an airdrop event.

For a breakdown of the different rounds and vesting schedules, see Messari's report [https://messari.io/article/an-introduction-to-dfinity-and-the-internet-computer?referrer=asset:internet-computer "Introduction to ICP"]. The unlocking of neurons has been the '''largest contributing factor''' to circulating supply since Genesis, so it's important to understand the context.

1. '''Seed Round, Feb-2017 (Public ICO):''' This round was advertised by a tweet and open to the public by downloading a web extension. DFINITY raised CHF3.9 million (US$3.9 million) from 370 participants, at a valuation of $16 million, or a price of $0.03 per token. It held a portion of these funds in ETH and BTC during the 2017 crypto bull run. Seed round participants received all of their tokens at genesis but are staked inside 49 neurons. Each neuron has a different dissolve delay counting from 0 to 48 months. So this is practically equivalent to a 48-month "vesting schedule" see [https://medium.com/dfinity/how-to-access-seed-and-airdrop-icp-tokens-and-participate-in-the-internet-computer-network-e6cd663a0c3c How to Access ‘Seed’ and ‘Airdrop’ ICP Tokens and Participate in the Internet Computer Network].

2. '''Strategic Round, Jan-2018:''' DFINITY raised $20.54 million for 7.00% of the initial supply (the number has been revised from the previously cited 6.84%). This allocation vests monthly over three years starting from mainnet launch (May 2021). Participants include Polychain Capital, Andreessen Horowitz, CoinFund, Multicoin Capital, and Greycroft Partners. This round marks the first token a16z invested in. Polychain and DFINITY later collaborated to create the "DFINITY Ecosystem Venture Fund" (later renamed [https://dfinity.org/ecosystem/fund/ "Beacon Fund"]) of an undisclosed size. The goal is to fund new projects that would grow the IC's application ecosystem. The media reported that DFINITY raised a much larger amount of $61 million, some of which related to funds committed to projects building on the Internet Computer.

3. '''Presale, Aug-2018:''' 110 participants contributed $97 million for 4.96% of the initial supply, sold at 4 CHF (around $4 at the time) per ICP token. This number has been revised from 4.75% previously reported. This allocation came with a monthly vesting schedule of one year from mainnet launch. Vesting began one month after the initial token distribution event on May 10, 2021. Participants in this round include Andreessen Horowitz, Polychain Capital, SV Angel, Aspect Ventures, Electric Capital, ZeroEx, Scalar Capital, and Multicoin Capital.

4. '''Airdrop, May-2018:''' $35 million worth of ICP tokens (formerly DFN), or 0.80% of the initial supply, was airdropped to early supporters by being part of their mailing list, forums, and community. At this time, valuations reached $1.89 billion. Airdrop participants received the IOU version of their ICP tokens in September 2020. This allocation came with a monthly distribution schedule of one year from mainnet launch, which began on May 10, 2021.

==Conclusion==

'''Ultimately, the NNS is controlled by the community so it can vote to change any of the parameters. The parameters and mechanisms described are the current ones.'''

The ICP token has a Total Supply of 530.6MM, Circulating Supply of 481.7MM as of March 2025. 234.1MM ICP (44.1% of total supply) is staked by token holders in the form of neurons with over 87.2% locked for over 1 year.

The number of tokens is constantly changing. The rewards paid out to the node providers and governance participants contribute to the inflation in token supply while factors like compute/storage fees and transaction fees cause deflation in the total supply.

Neurons 101

2025-06-30T21:29:37Z

Jessie.mongeon:

{{#externalredirect: https://learn.internetcomputer.org/hc/en-us/articles/34084120668692-Neurons}}

On the Internet Computer, a neuron is a unit that holds tokens and can vote on governance proposals. Simply put, you can lock ICP in the NNS into neurons that can vote on NNS proposals. Switching to the SNS tab, you can lock SNS1 tokens in the SNS into neurons to vote on SNS-1 proposals (using OpenChat or DSCVR).Neurons have different properties and can perform different actions. To clear up any confusion let’s go through these properties and actions. NOTE: not all of these are available in the SNS yet on the NNS frontend dapp.

==Properties==
* '''Stake''' (NNS / SNS) - The amount of tokens that a neuron holds. You can always increase this stake, however you only will get access to these tokens again, once the neuron’s “Dissolve Delay” (see below) hits 0.

* '''Dissolve Delay''' | Remaining (NNS / SNS) - Every neuron has a dissolve delay (also displayed as “remaining”). This is the time it would take your tokens in the neuron to become liquid (unlocked) after you “Start Dissolving”. The higher the dissolve delay, the higher the voting power (and voting rewards in case it’s configured).

* '''Age Bonus''' (NNS / SNS) - Age Bonus is a multiplier that gets applied to your voting power. The longer you keep your neuron locked the higher this multiplier is. Clicking “Start Dissolving” resets this number to 0 immediately.

* '''Voting Power''' (NNS / SNS) - Voting power is how much your locked tokens count when used for voting. Voting power depends on the stake, dissolve delay and age bonus. Example: 10 ICP locked for 8 years that has 0 age bonus, will have a voting power of 20. The way voting power is calculated can be changed by the DAO.

* '''Maturity''' (NNS) - Maturity is the voting rewards you collected that are not yet minted. You can use maturity in two ways: “Stake Maturity” or “Disburse MaturitySpawn Neuron” (see below). Voting rewards are configured to be 0 for SNS-1, this can be changed by the SNS-1 DAO through a proposal.

* '''Minimum Staking Period for Voting''' (NNS / SNS) -The minimum dissolve delay your neuron needs to have in order to be eligible to vote on proposals.
** NNS - 6 months
** SNS-1 - 1 month

==Actions==
* '''Vote''' (NNS / SNS) - Neurons can vote on governance proposals. In the NNS, you have a tab called “Voting” where you can see all proposals. In SNS-1, you can vote using OpenChat or DSCVR.

* '''Start/Stop Dissolving''' (NNS / SNS) - When a neuron is dissolving, the time it is locked for is ticking down. Once it goes down to 0, your tokens become liquid. The reason why you would want to keep your neuron locked and not dissolving is so that it stays above minimum required dissolve delay to vote and so that it accrues age bonus increasing its voting power.

* '''Increase Dissolve Delay''' (NNS/SNS) - You can always increase a neuron’s dissolve delay, but only decrease it by dissolving.

* '''Stake Maturity''' (NNS)- Staking maturity locks your voting rewards for the same period as the dissolve delay which will contribute to the neuron’s voting power. Once your neuron is completely dissolved, you get both your original stake and the staked maturity. Staking maturity allows for compounding rewards.

* '''Add Hotkey''' (SNS/NNS) - Adding a hotkey to a neuron allows another principal to vote with your neuron. If you add your OpenChat or DSCVR principal as a hotkey, you will be able to vote using OpenChat’s or DSCVR’s UI.

* '''Follow Neurons''' (NNS / SNS): An advantage of the liquid democracy implemented in the NNS is that neurons can follow other neurons. This way you can delegate your voting to other neurons and still receive voting rewards. This will soon be added to SNS.

* '''Disburse''' (NNS/SNS) - Make the tokens inside a neuron liquid.

SNS-1 tokens need to be locked for at least 30 days for them to be eligible to vote. Clicking “Start Dissolve“ will start the timer, however once it dips below 30 days, the neuron will not be eligible to vote.

==See Also==
* [https://dscvr.one/post/6958037/neurons-101 neurons 101 on DSCVR]'''

Decentralization in ICP: Infrastructure Governance

2025-06-30T21:29:05Z

Jessie.mongeon:

{{#externalredirect: https://learn.internetcomputer.org/hc/en-us/articles/34574082263700-Tokenomics-Governance}}

==Summary==

As a blockchain protocol, decentralization is very important to the design and implementation of ICP. This article is one of a subset explaining the design intent and the current state of the world when it comes to ICP decentralization. '''Its main focus is analyzing ICP as a [[sovereign network]] with a DAO controlling infrastructure governance'''.

To see the whole picture, it is recommended to see the following articles:

* [[Decentralization in ICP]]
* [[Decentralization in ICP: Critical Dapps on the IC]]
* [[Decentralization in ICP: Protocol Governance]]

==Background: Sovereign Network using Deterministic Decentralization==

The infrastructure layer of ICP is best summarized as:
* ICP is a [[sovereign network]] composed of [https://dashboard.internetcomputer.org/subnets subnets] that follow [[Deterministic Decentralization]]
* Each subnet is composed of nodes (owned and controlled by node providers), which are remunerated in ICP by the network minting ICP
* Each node lives in an independent data center (not cloud providers), which the node provider pays to upkeep and maintain. An example of data centers include Equinix in Spain.

==Current State of Infrastructure Decentralization==

To best understand current state of ICP topology and node diversification, the following forum posts lay the most information:

1. [https://forum.dfinity.org/t/ic-topology-series-node-diversification-part-i/23402 IC node diversification (Part 1)]

2. [https://forum.dfinity.org/t/ic-topology-node-diversification-part-ii/23553 IC node diversification (Part 2)]

==Example: Adding a node to the network==

For a concrete example, adding a node to the network takes the following steps:

===1. Node provider submits a proposal to [https://dashboard.internetcomputer.org/proposal/107568|become a node provider]===

[[File:Node provider submits a proposal to become a node provider.png |800px ]]

===2. NNS DAO decides if they want to add this node provider===

===3. If accepted by the NNS DAO, submit proposal to add node to subnet or data center===

* Node provider submits a proposal to add a node in a specific subnet in a [https://dashboard.internetcomputer.org/proposal/107569 specific data center] in a specific location

[[File:Proposal_to_add_data_center.png |800px ]]

===4. NNS DAO evaluates whether to accept the proposal based on questions like===
* Does ICP need more nodes?
* Does this node provider have too many nodes already?
* Does this subnet need more nodes?
* Does this data center have too many nodes?
* Does this location have too many nodes?

==See Also==
* [[Decentralization in ICP]]
* [[Decentralization in ICP: Protocol Governance]]
* [[Decentralization in ICP: Critical Dapps on the IC]]

Troubleshooting Failed NNS proposals

2025-06-30T21:25:38Z

Jessie.mongeon:

{{#externalredirect: https://learn.internetcomputer.org/hc/en-us/articles/34084113508500-Proposals}}

=== Background ===
Occasionally, a proposal on the Network Nervous System (NNS) may be adopted but fail during execution. This usually happens due to violations of certain invariants (constraints) in the NNS Registry.

==== Example of a Failed Proposal ====
An instance of such a failure can be seen in https://dashboard.internetcomputer.org/proposal/125578.

==== Screenshot ====
A screenshot of the failed proposal as displayed on the dashboard, for future reference, of https://dashboard.internetcomputer.org/proposal/125578
[[File:Failed-nns-proposal.png|center|thumb|791x791px|Screenshot of a failed NNS proposal in the dashboard]]

=== Identifying the Cause of Failure ===
As of now, the specific reasons for a proposal's failure are not directly accessible on the proposal page. To find out why a proposal failed, you need to interact with the governance canister directly.

==== Steps to Follow ====

# Visit the governance canister page https://dashboard.internetcomputer.org/canister/rrkah-fqaaa-aaaaa-aaaaq-cai.
# Scroll down to the section labeled <code>get_proposal_info</code>
# Use the toggle field to input the proposal number and click "Call".[[File:Failed-proposal-get-info.png|center|thumb|654x654px|Get info on the failed NNS proposal, on the public dashboard]]
# Once the result appears, select "JSON" to view it in Json format.
# The failure reason will be detailed in the output.

==== Example Output ====
Below is an example JSON output for a failed proposal. In this case, the proposal failed because an existing Node Operator record was being duplicated.

Example:

Open that toggle field, enter the proposal number, and click "Call". Once you get the result, you can click on "JSON" to get the Json format, and you can read the failure reason in the output. In this case, the same Node Operator record was already present in the registry when the proposal attempted to re-add the same record.
[
{
"id": [
{
"id": 125578
}
],
"status": 5,
"topic": 5,
"failure_reason": [
{
"error_message": "Error executing ExecuteNnsFunction proposal. Rejection message: IC0503: Canister rwlgt-iiaaa-aaaaa-aaaaa-cai trapped explicitly: Panicked at '[Registry] Verification of the mutation type failed with the following errors: [Registry Canister Error. Msg: Key already present: node_operator_record_mbnsu-w4xfc-pmdok-r2lwo-wxfr4-gigu5-4idcm-5uuuy-znvby-biiny-jqe].', rs/registry/canister/src/registry.rs:293:13",
"error_type": 12
}
],
"ballots": [
[
"14315117116521128082",
{
"vote": 0,
"voting_power": 196565756
}
]
],
"proposal_timestamp_seconds": 1699617467,
"reward_event_round": 0,
"deadline_timestamp_seconds": [
1699963110
],
"failed_timestamp_seconds": 1699878752,
"reject_cost_e8s": 1000000000,
"derived_proposal_information": [],
"latest_tally": [
{
"no": 66258822305525,
"yes": "45221535235544100",
"total": "45541158736625569",
"timestamp_seconds": 1699878752
}
],
"reward_status": 1,
"decided_timestamp_seconds": 1699878752,
"proposal": [
{
"url": "",
"title": [
"Add mbnsu as a Node Operator of Node Provider: 4jjya"
],
"action": [
{
"ExecuteNnsFunction": {
"nns_function": 8,
"payload": "4449444c056c06a795f3ad04018af3a2b108029bf499bd0878bbf187b70c03dddfde9b0d02dba7aaae0d716e716e686d046c020071017901000001011d97289ec1b951d2eceb5cb1e1906a77881899da5298cb6a1c05086e13020a000000000000000001011d78c0a5ff79e51f8d11fa75ad5db01d3d7cee8fecd6658d81c6deb6a20203726731"
}
}
],
"summary": "Node provider “MB Patrankos šūvis” is adding 10 nodes in the rg1 data center"
}
],
"proposer": [
{
"id": "1482125923012887388"
}
],
"executed_timestamp_seconds": 0
}
]

Service Nervous System (SNS)

2025-06-30T21:20:17Z

Jessie.mongeon:

{{#externalredirect: https://learn.internetcomputer.org/hc/en-us/articles/34084394684564-SNS-Service-Nervous-System}}

Similarly to how the Network Nervous System (NNS) is the open tokenized [[DAO]] that controls the Internet Computer blockchain (IC), service nervous systems (SNSs) are algorithmic [[DAO]]s that allow developers to hand over control of their dapp to decentralized, token-based governance systems. This means, each dapp that would like to be under decentralized control will have a separate SNS.

Developers can now hand over their Web3 service to an SNS there are also [https://wiki.internetcomputer.org/wiki/How_to_get_a_DAO_on_the_IC other alternatives of how developers can get a DAO]. The community can get governance tokens to take ownership and control through the SNS DAO and shape the dapp’s future.

<span id="sns-canisters"></span>
== SNS canisters ==

The SNS consists of a governance canister, a ledger canister with archive canisters and an index canister, a root canister, and a decentralization swap canister that is explained in the next section.

The ''ledger canister'' implements the [https://github.com/dfinity/ICRC-1 ICRC-1 standard] and contains SNS tokens, which are unique tokens for each SNS. It stores which accounts own how many SNS tokens and the history of transactions between the principals.
The archive canisters stores the history of the ledger transactions and the index canister allows one to find all the transactions associated with an account.

The ''governance canister'' enables decentralized decision making. It stores ''proposals'' that are suggestions on how to evolve the dapp that the SNS governs and ''neurons'' that define who the governance participants are. Neurons facilitate stake-based voting as they contain staked SNS tokens. Everyone can become a government participant by staking SNS tokens in a neuron.

The root canister is responsible for upgrading the other SNS canisters and the dapp canisters that the SNS controls.

<span id="sns-lifecycle"></span>
== SNS lifecycle ==

<span id="sns-launch"></span>
=== SNS launch process ===
SNS canisters are [https://wiki.internetcomputer.org/wiki/How_to_get_a_DAO_on_the_IC maintained and blessed by the IC community]. In more detail, the blessed SNS versions and upgrade paths are stored on an NNS canister called the [[SNS wasm modules canister]] SNS-W.

An SNS is launched by developers handing over their dapp to the NNS. An NNS proposal then defines the exact parameters with which an SNS is created and the conditions of the launch. If this proposal is adopted, an SNS is created and the dapp is handed over to this SNS. If the proposal is rejected, then the dapp is given back to the developer’s control.

===== SNS decentralization swap =====
A crucial part of launching an SNS is how it can be decentralized. That is, the newly created tokens must be distributed to a large community to ensure proper decentralization of voting power. There are of course many ways to do so. The first SNS version provides one simple way to achieve this: a developer can hand over their dapp to the NNS and ask it to start a decentralization swap. In the decentralization swap, a fixed number of newly created SNS tokens are given away. The swap collects ICP tokens and, in the end, the conversion rate is computed as the number of ICP collected by the number of SNS tokens - the tokens are swapped. After a successful decentralization swap, SNS tokens are thus owned by a large community and therefore the SNS governance control is decentralized. Moreover, the ICP that were collected in the decentralization swap provide initial funding for the SNS project.

If you are looking to decentralize a dapp, you can find more information in the [https://internetcomputer.org/docs/current/developer-docs/integrations/sns/ developer documentation]. If you want to participate, you can find more information on [https://internetcomputer.org/sns the SNS website].

<span id="sns-maintenance"></span>
=== SNS DAO ===

There are some important maintenance tasks that have to be performed by an SNS community, such as deciding and voting on when an SNS should be upgraded to a new blessed version, adjusting the SNS parameters when needed, and making sure that the SNS canisters do not run out of cycles.
There is more information about how to [https://internetcomputer.org/sns participate in an SNS DAO] and more technical details of how to contribute to [https://internetcomputer.org/docs/current/developer-docs/integrations/sns/managing/manage-sns-intro managing an SNS DAO] as a community member.

Staking, voting and rewards

2025-06-30T21:19:40Z

Jessie.mongeon:

{{#externalredirect: https://learn.internetcomputer.org/hc/en-us/articles/34084120668692-Neurons}}

ICP Tokenomics

2025-06-30T21:16:01Z

Jessie.mongeon:

{{#externalredirect: https://learn.internetcomputer.org/hc/en-us/articles/34090810571284-Tokenomics}}

Web3: The bull case for the Internet Computer

2025-06-30T21:15:30Z

Jessie.mongeon:

{{#externalredirect: https://learn.internetcomputer.org/hc/en-us/articles/33152818663444-What-is-ICP}}

The next wave of innovative applications, business, digital personas, finance, and entertainment will be built on decentralized infrastructure. Their creation will come ''from'' the community, ''for'' the community and further will be ''controlled by'' the community. Such are the promises of Web3.

== Once upon a time in Web1 ==
In the 90's, ''surfing the web'' often entailed getting over-excited the sound of a dial-up internet connection and the count of results from early search engines. For the first time the world had access to information like never before. Looking back, it seems primitive, but the revolutionary nature of the network that came together to form Web1 should not be discarded.

Considering the history of the internet, the two major contributions of web1 were
* The '''creation of the network''' itself
* '''Read access''' - users access and read materials from a select bunch of early internet contributors.

== Enter Web2 ==
Web2 will largely be remembered as the iteration of the internet that introduced social media, advertising, and digital content in general. Web2 brought many great applications that enabled users to engage in a more meaningful way with the internet. Through the platformization of services, users moved from the era of 'read-only' web to one where they could 'read and write' and begin to digitize their lives.

With more and more information being created and stored on the web, questions of security and privacy became much more prevalent. Two of the greatest contributions to Web2 were TLS (which allows information to flow across the internet in an encrypted manner) and the Signal protocol (which allows end-to-end encrypted messaging (in the Signal app, Whatsapp, and Facebook messenger, to name a few.)) While these security advances provided greater integrity for data flows on the internet, it was left to the discretion of centralized organizations to implement and use them, if and when they chose to. While information flows may not be visible to the public, large amounts of data are visible to the owner of the platform. This means that the core of the services and applications on the internet remain in the hands of a few organizations, rather than with the users who provide and consume the content.

Furthering the history of the internet, the major contributions of Web2 are
* '''Monetization''' of apps
* The possibility of '''security and privacy'''
* '''Read and write access'''

== Growing to Web3 ==
Web3 aims to overcome the issues found in web2 by removing the central point of trust and shifting control to the people who build, contribute to, and use the internet and its services. There are a number of ways in which this can be achieved, but the most promising is by leveraging decentralization of information and computing offered by blockchains.

It has become widely know that blockchains support tokens, often in the form of cryptocurrencies, but other tokens are emerging which enable users to take a more active role in the applications they use. With tokenization, users can move to a 'read, write and own' iteration of the internet.

An important point to note is that in the transition to web3, to truly overcome the pitfalls of web2, users should aim to build applications that are decentralized at every point in the stack. If any part of developing, operating, or governing is not decentralized then it remains the case that there is a single party who can control our use of the dapp.

When looking back on the evolution of the internet, it's expected to see Web3 contributions as
* Integrating '''identity'''
* Systems with '''native payments'''
* The incubator for the birth of '''DAOs (Decentralized Autonomous Organizations)'''
* The '''read, write, and own''' model of the internet.

=== Identity on Web3 ===
* Users should be able to use a dapp without requiring tokens: no entrance barrier with Internet Identity
* [[Internet Identity]] - allows to interact with dapps without the need for tokens

=== The rise of DAOs ===
* It should be possible to easily tokenize dapps so that users can participate in ownership, success, and governance, while developers have a sustainable way to raise funds
* [[Network Nervous System|Network Nervous System]] - allows users to stake tokens, and earn rewards for participating in governance of the Internet Computer
* '''[[Service Nervous System (SNS)| Service nervous system]]''' - allows developers to easily tokenize dapps to raise funds, giving ownership to the users, and to crowdsource decision making

=== Native payments ===
One suggested reason why Web2 ended up being so centralized is that there was no native system for making (micro and/or web) payments. This made it difficult for digital creators and entrepreneurs to build a business without relying on large centralized organizations and platforms to build upon. Given that decentralized applications are generally built on blockchain platforms, it's often the case that there is a native token and payment mechanism. This eases the flow of funds between peers.

The ease of token/fund transfer, coupled with the formation of DAOs makes it substantially more convenient to raise funds to start a business and grow different types of economies.

== Decentralized Future ==
Right now the world is still working its way into Web3. The industry is figuring out what it means to remove trust from a single organization and pass it on to a group. Builders are debating between different models of authentication, tokenization, control, buisness, infrastructure and much more.
Some of the things are are needed for a decentralized Web3 are
* '''Automation & upgradability''' - Currently, even given the rise of DAOs and digital liquid democracy, it is often the case that decentralized decisions are passed on to a single authority to execute the decision. Trust removal falls at the final hurdle. For a true Web3 experience, DAOs should be, as their name applies, autonomous. Read more about the [[Network Nervous System]] of the IC.
* '''Interoperability''' - As the ecosystem grows it becomes increasingly important to maintain interoperability between applications and chains in s secure (i.e. bridge-free) manner. Read more about [[Bitcoin integration]].
* '''Censorship resistance''' - it should be the case the users have the right to write, the right to read, and the right to own.
* '''Accessability''' - * Developers should be able to build dapps that are fully onchain. It should be the case that a dapp can serve content directly into users browser. The operational cost of running a dapp should be comparable to running a web2 application (e.g. on AWS). Read more about [[Canister smart contracts]] allow to serve webpages without the need for centralized services.

Subnet blockchain

2025-06-30T20:21:06Z

Jessie.mongeon:

{{#externalredirect: https://learn.internetcomputer.org/hc/en-us/articles/34209955782420-Subnet-Creation}}

A subnet (subnetwork) is a collection of nodes that run their own instance of the consensus algorithm to produce a subnet blockchain that interacts with other subnets of the IC using chain key cryptography.

==Subnet Architecture==
The IC is designed to be highly scalable and efficient in terms of hosting and executing canister smart contracts. The top-level building blocks of the IC are subnetworks, or subnets: the IC as a whole consists of many subnets, where each subnet is its own blockchain that operates concurrently with and independently of the other subnets (but can communicate asynchronously with other subnets). Each subnet hosts canister smart contracts, up to a total of hundreds of gigabytes of replicated storage. A subnet consists of node machines, or nodes. Each node replicates all the canisters, state, and computation of the subnet using blockchain technology. This makes a subnet a blockchain-based replicated state machine, that is, a virtual machine that holds state in a secure, fault-tolerant, and non-tamperable manner: the computations of the canisters hosted on a subnet will proceed correctly and without stopping, even if some of the nodes on the subnet are faulty (either because they crash, or even worse, are hacked by a malicious party) New subnets can be created from nodes added to the IC to scale the IC, analogous to how traditional infrastructures such as public clouds scale out by adding machines. Such a scale-out architecture is rather the exception than the rule in the blockchain space and allows for limitless scaling, i.e., combining the security and resiliency properties of blockchains with the scalability properties enjoyed by the public cloud.

==List of Subnets==

All of the subnets, with their corresponding topologies and activities are listed on the IC dashboard: [https://dashboard.internetcomputer.org/subnets ICP subnets].

==See Also==
* [[New Subnet Creation]]
* [[Sovereign Network]]

Limitless Scaling

2025-06-30T20:20:12Z

Jessie.mongeon:

{{#externalredirect: https://learn.internetcomputer.org/hc/en-us/articles/34209955782420-Subnet-Creation}}

'''The Internet Computer (IC) can scale its capacity without limit, simply by adding additional nodes to fuel new subnets. Nodes are added via the Network Nervous System (NNS) which forms new subnets almost on a weekly basis since genesis. In contrast, most other blockchains have transaction limits baked into the protocol (e.g. adding more servers to Bitcoin does not increase the throughput) and need cumbersome layers to address scaling.

See Internet Computer Dashboard for current scale and performance numbers: https://dashboard.internetcomputer.org/'''

=== Subnet Architecture ===

Please see [https://internetcomputer.org/docs/current/concepts/nodes-subnets Subnet architecture]

==See Also==
* '''The Internet Computer project website (hosted on the IC): [https://internetcomputer.org/ internetcomputer.org]'''

Principal

2025-06-30T16:24:37Z

Jessie.mongeon:

{{#externalredirect: https://internetcomputer.org/docs/building-apps/getting-started/identities}}

A '''principal''' is an identifier for an entity on the IC such as a user, a canister (dapps/smart contracts), or a subnet.

Motoko’s shared functions support a simple form of '''caller identification''' that allows to inspect the Internet Computer principal associated with the caller of a function. The principal associated with a call is a value that identifies a ''unique'' user or canister.
Using the principal associated with the caller of a function allows to implement a basic form of '''access-control''' in a program.

== Types of principals ==
There are several types of principals.

=== Management principal ===
The management principal is used to reference the management canister.

=== Opaque principal ===
An opaque principal is chosen by the protocol. This kind of principal is used to reference any canister that is not the management canister.

=== Self-Authenticating principal ===
A self-authenticating principal is a hash of a public signature key. This kind of principal is for instance used to reference a subnet or user.

=== Derived principal ===
The principal is derived from a registering principal. This type of principal is currently not used.

=== Anonymous principal ===
The anonymous principal is used to reference an anonymous user.

== Representation ==

=== Binary ===
A principal consists of a variable-length byte array of up to 29 bytes. The last byte is used to indicate the type. The table below gives the type inferred from the last byte.
{| class="wikitable"
|'''Byte'''
|'''Type'''
|-
|none
|Management
|-
|<code>0x01</code>
|Opaque
|-
|<code>0x02</code>
|Self-Authenticating
|-
|<code>0x03</code>
|Derived
|-
|<code>0x04</code>
|Anonymous
|-
|<code>0x05</code>
|Unassigned
|}

=== Textual ===
A principal is shown in textual format by prepending it with its [[wikipedia:Cyclic_redundancy_check#CRC-32_algorithm|CRC-32]] value in big-endian byte order, applying [[wikipedia:Base32|Base32]] encoding without padding, grouping characters by length five, and separating them by a hyphen. The maximal length of the encoding, including hyphens, is 63 characters. The table below gives some common principals.
{| class="wikitable"
!Principal
!Description
|-
|<code>aaaaa-aa</code>
|[[Management Canister|management canister]]
|-
|<code>rrkah-fqaaa-aaaaa-aaaaq-cai</code>
|[[Governance Canister|governance canister]]
|-
|<code>ryjl3-tyaaa-aaaaa-aaaba-cai</code>
|[[Ledger Canister|ledger canister]]
|-
|<code>tdb26-jop6k-aogll-7ltgs-eruif-6kk7m-qpktf-gdiqx-mxtrf-vb5e6-eqe</code>
|[[Network Nervous System|network nervous system]]
|-
|<code>2vxsx-fae</code>
|anonymous user
|}

== Further Information ==
* Check the [https://internetcomputer.org/docs/current/motoko/main/base/Principal/ Motoko Base Library] to see how to use principal functions.
* See the [https://internetcomputer.org/docs/current/motoko/main/caller-id/ principals and caller identification] documentation for a more in-depth guide to the uses of principals on the IC.
* See the [https://internetcomputer.org/docs/current/developer-docs/backend/motoko/access-control/ access-control with identity] tutorial to add extra functionality to a dapp.

Tutorials for acquiring, managing, and staking ICP

2025-06-30T16:24:13Z

Jessie.mongeon:

{{#externalredirect: https://youtu.be/XU54fbCzFmE?feature=shared}}

__NUMBEREDHEADINGS__
The governance of the Internet Computer depends on people staking their [[ICP Tokenomics | ICP token]] and voting on proposals. To do this, there are four steps. Each step has different sets of options (with trade-offs):

# Acquire ICP
# Custody
# Staking
# Voting

This article is an entry point into these four topics. For a simple, opinionated tutorial that makes choices to maximize simplicity, see [[Staking for dummies]].

==Acquire ICP==

To get started, you first need to acquire ICP tokens. You can do this buying them in an exchange or by having someone you send you ICP.

===Buy ICP from Crypto Onramps===
Crypto onramps allow you to buy ICP directly from your credit card or bank account without having to open an account. They don't store your tokens, instead send them directly to your wallet address (see [[ICP custody options|Wallet & Custody options]]).

*[https://banxa.com Banxa]
*[https://guardarian.com Guardarian]
*[https://ramp.alchemypay.org/ AlchemyPay]
*[https://transak.com Transak]
*[https://onramp.money Onramp.money]
*[https://www.simplex.com Simplex]
* [https://bity.com/ Bity]

===Buy/Sell ICP at Exchanges===
Please check below for a list of exchanges where you can buy/sell ICP

*[https://coinmarketcap.com/currencies/internet-computer/#Markets CoinMarketCap list of ICP exchanges]
*[https://www.coingecko.com/en/coins/internet-computer CoinGecko list of ICP exchanges]

===Seed Round Contributors===

Seed round participants who wish to claim their neurons (from 2021) should first see: [[How-To: Claim neurons for seed participants]].

==Custody==

Custody is the act of managing your ICP. There are many options, each with different security and usability trade-offs. For a summary of the range of options available to you depending on your comfort level, see [[ICP custody options]].

==Staking==

Once you decide on your custody, staking is the action of locking ICP within a [[neuron]] with a [[dissolve delay]]. [[Staking and voting]] are critical to [[Governance of the Internet Computer]].

By staking you can vote on NNS Proposals and collect NNS rewards. There are many options for staking, each with different security and usability trade-offs. See [[ICP staking options]].

==Voting==

Voting is the act of voting on [[NNS proposals]] using neurons. See [[ICP voting options]].

==See Also==
*'''The Internet Computer project website (hosted on the IC): [https://internetcomputer.org/ internetcomputer.org]'''
*[[Governance of the Internet Computer]]
*[[Staking and voting]]
*[[Staking for dummies]]

==External links==

*https://www.dfinitycommunity.com/best-exchanges-to-buy-icp/
*https://medium.com/dfinity/the-community-led-governance-of-the-internet-computer-b863cd2975ba
*https://medium.com/dfinity/earn-substantial-voting-rewards-by-staking-in-the-network-nervous-system-7eb5cf988182
*https://medium.com/dfinity/introducing-the-ledger-internet-computer-icp-app-for-nano-wallets-eed38c549f0d

ICP custody with Ledger Nano

2025-06-30T16:23:49Z

Jessie.mongeon:

{{#externalredirect: https://www.youtube.com/watch?v=0-nSOBC3bxE}}

== Ledger Nano ==

The [https://www.ledger.com/ Ledger] Nano is one of the world’s most popular hardware wallets for safely storing crypto assets. A Ledger wallet combined with the Ledger Live app gives users complete control over their crypto, ensuring ownership over their assets while providing maximum security.

== ICP and Ledger Nano==

To use the Ledger Nano to manage your ICP follow these instructions, you need three things:

* Networked computer
* [https://identity.ic0.app/ Internet Identity] with [https://nns.ic0.app/v2/ NNS frontend dapp]
* Ledger Nano

You can follow the user manual here: [https://medium.com/dfinity/integrating-ledger-nano-with-the-nns-front-end-dapp-user-manual-9c5600925e16 Integrating Ledger Nano With the NNS Front-End Dapp]. If you prefer using CLI, there is a [[Hardware Wallet CLI]] that you can also use to manage any ICRC-1 token.

==Features==

The Ledger Nano + NNS dapp integration supports the following actions:

* Receive/send ICP
* Stake a neuron
* View neurons
* Add neurons as hotkeys
* Dissolve neurons
* Disburse neurons
* Increase dissolve delay of neurons
* View NNS proposals
* Vote on NNS proposals
* Choose neurons to follow for voting

==Benefits==

* Maximum control of one's seed phrase (NNS frontend dapp does not access one's seed phrase)
* Has all the functionality one needs for custody, staking, voting
* Ideal for people who want to want to combine easy web experience with to control of their seedphrase ICP

==Trade-offs and risks==

If you use this combination, you are accepting the following trade-offs:

* '''Risk of losing access''' - If you only have lose access your Ledger Nano AND forget seed phrase, you lose access to your ICP.

* '''Risk your devices do not support it''' - Not all devices and browsers support WebAuthn, so this option is sometimes not available. Supported browsers for Ledger Nano integration currently include Chrome (desktop) v89+, Edge v89+, and Opera v76+.

== Security ==

The Ledger Internet Computer (ICP) app was built by a collaboration between the [https://zondax.ch/ Zondax] team of engineers and cryptographers and the DFINITY Foundation. It was released and announced on December 3, 2021 [https://medium.com/dfinity/introducing-the-ledger-internet-computer-icp-app-for-nano-wallets-eed38c549f0d].

The Ledger Internet Computer (ICP) app has undergone a third-party audit and has been reviewed and approved by Ledger. You can access the Ledger Internet Computer (ICP) app repository here: https://github.com/Zondax/ledger-icp.

== See Also ==
* [[Managing ICP holdings]]
* [[ICP custody options]]

World Computer

2025-06-30T16:23:21Z

Jessie.mongeon:

{{#externalredirect: https://internetcomputer.org/what-is-the-ic}}

'''[[Ethereum]] was the first blockchain that could host [https://en.wikipedia.org/wiki/Turing_completeness Turing complete] [[smart contract]]s, which are secure units of code that process and store data ''on'' the blockchain itself. Back in 2014, the dramatic realization that a blockchain could play the role of a computer, led to someone proposing the concept of a "World Computer."'''

The original idea was that Ethereum would become a "World Computer", but over time the concept faded into obscurity within the Ethereum community. Clearly, a true World Computer blockchain would have to be capable of hosting most of the world's computation and data to live up to its name, whereas the design trajectory of Ethereum meant this was truly out of reach.

During these early years, Ethereum follower and supporter Dominic Williams was working on applied cryptography and distributed computing math with the aim of speeding up blockchains, and allowing them to scale infinitely. He was deeply struck by the concept of a World Computer, and pivoted his work towards the idea.

During 2015, he researched techniques that might be used to create a World Computer, even tentatively producing an unfinished [https://web.archive.org/web/20150914013643/http://dfinity.io/ website to share his ideas in the Fall]. He has described hoping his work would have been used to create Ethereum 2.0, but eventually realizing the Ethereum project's path was incompatible with creating a World Computer.

Dominic then founded the Dfinity Foundation in Switzerland in late 2016, to develop a "World Computer" blockchain having received support from a Palo Alto incubator, String Labs, during the summer. The project raised initial funds by selling its token February 24, 2017.

Creating a "World Computer" was an enormously complex endeavor, and the Dfinity Foundation had to build-out the largest R&D operation in blockchain, which currently employs more cryptographers than any other organization in tech. The [[Internet Computer]] blockchain — the first true realization of the World Computer vision — finally underwent network genesis, May 10th 2021.

The Internet Computer has a different architecture to traditional blockchains, which is enabled by [[Chain key cryptography|novel cryptography]]. It has numerous unique capabilities, which allows it to play the role of a World Computer. For example, the [[canister smart contract]]s it hosts can process HTTP requests to serve interactive web experiences directly to users.

The purpose of the Internet Computer is to provide a World Computer that will eventually replace traditional IT, and host all of humanity's systems and services, as well as enabling Web3 that is fully on-chain.

Popular Explainers of ICP

2025-06-30T16:22:35Z

Jessie.mongeon:

{{#externalredirect: https://internetcomputer.org/what-is-the-ic}}

As a protocol, ICP has many ways of describing not just its design intent, but also its usage. The ICP community has written various introductions to ICP (including this wiki) which people have found helpful:

==Popular places to start==
* '''[https://internetcomputer.org/ internetcomputer.org]'''
** This is the website for the project, and its itself hosted on ICP
* [[Introduction to ICP]]
* [https://www.youtube.com/watch?v=IfM3I8pudFs&t=327s Internet Computer overview video from 2022 IC hackathon]
* [https://internetcomputer.org/icig.pdf Internet Computer Infographic (PDF)]
* [[Glossary | Glossary of ICP terms]]

==For a more technical audience==
* [https://eprint.iacr.org/2022/087 "Internet Computer for Geeks" paper]
* [[IC architecture overview]]
* The [https://internetcomputer.org/howitworks "How it works" series] with videos and in-depth articles on various topics.
* [https://www.reddit.com/r/dfinity/comments/ozboyi/megathread_technical_amas/ Technical AMAs on Reddit by different IC and DFINITY teams]

ICP Community

2025-06-30T16:21:06Z

Jessie.mongeon:

{{#externalredirect: https://internetcomputer.org/education-hub}}

ICP Ecosystem Stats

2025-06-30T16:20:35Z

Jessie.mongeon:

{{#externalredirect: https://internetcomputer.org/education-hub}}

Index of dapps on the Internet Computer ecosystem

2025-06-30T16:20:13Z

Jessie.mongeon:

{{#externalredirect: https://internetcomputer.org/ecosystem}}

= Index of dapps on the Internet Computer =

The most actively updated source of dapps on the Internet Computer is the [https://internetcomputer.org/ecosystem ICP ecosystem page].

==Additional List of IC ecosystem aggregators==
* [https://n7ib3-4qaaa-aaaai-qagnq-cai.raw.ic0.app/?locale=en#/ ICApps]
* [https://dfinity.org/showcase/ DFINITY Showcase]
* [https://zire.github.io/awesome-IC/ The Awesome IC Repository]
* [https://internetcomputer.today/ Internet Computer Today]

Glossary

2025-06-30T16:19:38Z

Jessie.mongeon:

{{#externalredirect: https://internetcomputer.org/docs/references/glossary}}

IC Smart Contract Memory

2025-06-30T16:19:16Z

Jessie.mongeon:

{{#externalredirect: https://internetcomputer.org/docs/motoko/orthogonal-persistence/modes}}

==Overall Architecture==
Canister smart contracts running on the Internet Computer (IC) store data just like most other programs would. To this end, the IC offers developers two types of memory where data can be stored, as depicted in Figure 1. The first is the regular '''heap memory''' that is exposed as the Web Assembly virtual machine heap. This should be used as a scratch, temporary memory that will be cleared after any canister upgrade. The second type of memory is the '''stable memory''', which is a larger memory (several orders of magnitude larger than the heap) used for permanent data storage.

[[File:Canister memory 2.png|alt=|512x512px|Figure 1. The two memories that can be accessed by the canister smart contracts.|center|frameless]]

==Orthogonal Persistence==

<syntaxhighlight lang="rust">
use ic_cdk_macros::{query, update};
use std::{cell::RefCell, collections::HashMap};

thread_local! {
static STORE: RefCell<HashMap<String, u64>> = RefCell::default();
}

#[update]
fn insert(key: String, value: u64) {
STORE.with(|store| store.borrow_mut().insert(key, value));
}

#[query]
fn lookup(key: String) -> u64 {
STORE.with(|store| *store.borrow().get(&key).unwrap_or(&0))
}
</syntaxhighlight>

The IC offers orthogonal persistence, an illusion given to programs to run forever: the heap of each canister is automatically preserved and restored the next time it is called. For that, the execution environment needs to determine efficiently which memory pages have been dirtied during message execution so that the modified pages are tracked and periodically persisted to disk. The listing above shows an example key-value store that illustrates how easy it is to use orthogonal persistence. The key-value store in this case is backed by a simple Rust HashMap stored on the heap by means of a thread-local variable. A RefCell is used to provide interior mutability. The example would also be possible without it, but mutating the thread-local variable would be unsafe in that case, as the Rust compiler cannot guarantee exclusive access to it.

==Main Memory==
Canisters running on the IC are programmed either in Rust or Motoko. The canisters are then compiled down to web assembly (Wasm). All the variables and data structures defined in these higher-level languages are then stored in the Wasm heap. All accesses to data structures and variables defined in the higher-level languages are then translated to memory copy operations in Wasm (e.g., load, store, copy, grow). The Wasm main memory (also known as heap memory) has a maximum size of 4GiB, due to the 32-bit address space that backs the Wasm programs. The memory pages are persistent between calls to a canister (changes made by calls that throw exceptions are reverted, so these pages never enter an inconsistent state). However, they are reset when the canister's software bytecode is upgraded. Typically, canisters that need to be upgraded, serialize data in main memory to stable memory to perform upgrades. More precisely, because possible changes in data structures and in Wasm (and high-level language) compilers, the heap layout might change (i.e., data structure layouts) which could leave the canister in an unusable state when a canister is upgraded. Thus, the heap should not be used as a permanent memory, but rather as a (faster) scratch, temporary memory.

==Stable Memory==
Next to the heap memory, canister developers can make use of the stable memory. This is an additional 64-bit addressable memory, which is currently 400GiB in size, with plans to increase it further in the future. Programs written in either Rust or Motoko need to explicitly use stable memory by using the API. This API offers primitives to copy memory back and forth between the Wasm heap and the stable memory. An alternative to using this lower level API directly is to use the stable structures API, which offers developers a collection of Rust data structures (e.g., B-trees) that operate directly in stable memory. Next to using the stable memory through stable data structures, a pattern often used by developers is to persist heap state between canister upgrades. This is achieved via serializing heap memory (or data structures), saving it to stable memory and applying the opposite operations (copying back and deserializing) when the upgrade is done.

==Behind the scenes: Implementation==
To serve memory contents to canister smart contracts, the IC software stack has the following design. First, it is important to mention that every N (consensus) rounds, canister state (heap, stable memory and other data structures) are checkpointed on disk. This is called a checkpoint file. Whenever a canister executes messages after a checkpoint, all its memory resides in the checkpoint file. Therefore, all memory requested will be served from the checkpoint file. Memory modifications (i.e., dirtied pages in terms of operating systems) are saved in a data structure called the heap delta. The following paragraphs describe how this design enables orthogonal persistence.

[[File:Screen_Shot_2022-12-01_at_14.30.58.png|512px|thumb|Figure 2. The memory faulting architecture which encompasses the checkpoint file and the heap delta.
.]]

Any implementation of orthogonal persistence has to solve two problems: (1) How to map the persisted memory into the Wasm memory?; and (2) How to keep track of all modifications in the Wasm memory so that they can be persisted later. Page protection is used to solve both problems.The entire address space of the Wasm memory is divided into 4KiB pages. All pages are initially marked as inaccessible using the page protection flags of the operating system.

The first memory access triggers a page fault, pauses the execution, and invokes a signal handler. The signal handler then fetches the corresponding page from persisted memory and marks the page as read-only. Subsequent read accesses to that page will succeed without any help from the signal handler. The first write access will trigger another page fault, however, and allow the signal handler to remember the page as modified and mark the page as readable and writable. All subsequent accesses to that page (both r/w) will succeed without invoking the signal handler.

Invoking a signal handler and changing page protection flags are expensive operations. Messages that read or write large chunks of memory cause a storm of such operations, degrading performance of the whole system. This can cause severe slowdowns under heavy load.

==Versioning: Heap Delta and Checkpoint Files==

A canister executes update messages sequentially, one by one. Queries, in contrast, can run concurrently to each other and to update messages. The support for concurrent execution makes the memory implementation much more challenging. Imagine that a canister is executing an update message at (blockchain) block height H. At the same time, there could still be a previous long-running query that started earlier, at block height H-K. This means the same canister can have multiple versions of its memory active at the same time; this is used for the parallel execution of queries and update calls.

A naive solution to this problem would be to copy the entire memory after each update message. That would be slow and use too much storage. Thus, our implementation takes a different route. It keeps track of the modified memory pages in a persistent tree data-structure called Heap Delta that is based on Fast Mergeable Integer Maps. At a regular interval (i.e., every N rounds), there is a checkpoint event that commits the modified pages into the checkpoint file after cloning the file to preserve its previous version. Figure 2 shows how the Wasm memory is constructed from Heap Delta and the checkpoint file.

====Memory-related performance optimizations====
'''Optimization 1:''' Memory mapping the checkpoint file pages.
This reduces the memory usage by sharing the pages between multiple calls being executed concurrently. This optimization also improves performance by avoiding page copying on read accesses. The number of signal handler invocations remains the same as before, so the issue of signal storms is still open after this optimization.

'''Optimization 2:''' Page Tracking in Queries
All pages dirtied by a query are discarded after execution. This means that the signal handler does not have to keep track of modified pages for query calls. As opposed to update calls, queries saw the introduction of a fast path that marks pages as readable and writable on the first access. This low-hanging fruit optimization made queries 1.5x-2x faster on average.

'''Optimization 3:''' Amortized Prefetching of Pages
The idea behind the most impactful optimization is simple: to reduce the number of page faults, more work is needed per signal handler invocation. Instead of fetching a single page at a time, the signal handler tries to speculatively prefetch pages. The right balance is required here because prefetching too many pages may degrade performance of small messages that access only a few pages. The optimization computes the largest contiguous range of accessed pages immediately preceding the current page. It uses the size of the range as a hint for prefetching more pages. This way the cost of prefetching is amortized by previously accessed pages. As a result, the optimization reduces the number of page faults in memory intensive messages by an order of magnitude.

A downside of this approach is that prefetched page content needs to be compared with previous content after message execution to determine if a page was modified instead of relying on tracking write accesses via signal handlers.

These optimizations bring substantial benefits for the performance of the memory faulting component of the execution environment. The optimizations allow the IC to improve its throughput for memory-intensive workloads.

==See Also==
* '''The Internet Computer project website (hosted on the IC): [https://internetcomputer.org/ internetcomputer.org]'''

HTTPS outcalls

2025-06-30T16:18:30Z

Jessie.mongeon:

{{#externalredirect: https://internetcomputer.org/docs/building-apps/network-features/using-http/https-outcalls/overview}}

HTTP asset certification

2025-06-30T16:18:02Z

Jessie.mongeon:

{{#externalredirect: https://learn.internetcomputer.org/hc/en-us/articles/34276431179412-Asset-Certification}}

This content has moved to the learn hub ([https://learn.internetcomputer.org/hc/en-us/articles/34276431179412-Asset-Certification Asset Certification] and [https://learn.internetcomputer.org/hc/en-us/articles/34211943471892-HTTP-Gateway-Protocol HTTP Gateway Protocol]) and the [https://internetcomputer.org/docs/references/http-gateway-protocol-spec HTTP Gateway Protocol Specification].

ICP voting with NNS frontend dapp

2025-06-30T16:17:00Z

Jessie.mongeon:

{{#externalredirect: https://internetcomputer.org/docs/building-apps/governing-apps/nns/using-the-nns-dapp/nns-dapp-voting-on-proposals}}

You can choose the proposal types and proposal topics that you see and vote on—either directly or by [[How-To:_Set_your_neuron_to_follow_another_neuron|following other neuron stakeholders—using filters in the Network Nervous System dapp]]. For example, if you want to review and vote on all proposals that involve network participants such as data center identities and node operators, but aren’t interested in viewing proposals related to the current market value of ICP, as measured by an International Monetary Fund (IMF) Special Drawing Right (SDR), you can select the Participant Management topic filter and deselect the Exchange Rate topic filter.

[[How-To:_Set_your_neuron_to_follow_another_neuron|To vote by following another neuron.]]

To manually vote on proposals:

1. Open a browser and navigate to the Network Nervous System (NNS) dapp.

2. Click Login to connect using your Internet Identity.

3. Verify your identification number, then click Login to authenticate using the device and authentication method you have registered.

4. Click Proceed to access to the Network Nervous System (NNS) dapp.

5. Click Voting.

You can click any of the proposals listed to view information about the proposal, including a brief description of the proposal, a link for viewing additional information about the proposal, the number of votes that were cast to adopt or reject the proposal, and the votes cast by your neurons.

6. Use the Topics, Reward Status, and Proposal Status filters to control the list of proposals displayed.

For example, open the Topics list to see if there are any proposal topics that you want to include in the proposal list that are not currently displayed and open the Proposal Status to verify that you are viewing all open proposals.

7. Click any Open proposal to see its details and the voting power for the neurons associated with your identity.

8. Select the neuron identifiers with voting power that you want to use to cast your vote.

9. Click Adopt or Reject to cast your vote.

For more information about maturity and spawning new neurons, see the following articles:

* [https://medium.com/dfinity/earn-substantial-voting-rewards-by-staking-in-the-network-nervous-system-7eb5cf988182 Earn Substantial Voting Rewards by Staking in the Network Nervous System]

*[https://medium.com/dfinity/understanding-the-internet-computers-network-nervous-system-neurons-and-icp-utility-tokens-730dab65cae8 Understanding the Internet Computer’s Network Nervous System, Neurons, and ICP Utility Tokens]

*[https://medium.com/dfinity/getting-started-on-the-internet-computers-network-nervous-system-app-wallet-61ecf111ea11 Getting Started on the Internet Computer’s Network Nervous System App & Wallet]

ICP voting options

2025-06-30T16:16:33Z

Jessie.mongeon:

{{#externalredirect: https://internetcomputer.org/docs/building-apps/governing-apps/nns/using-the-nns-dapp/nns-dapp-voting-on-proposals}}

Voting an in important part of ICP governance as it is is how the community controls the Internet Computer.

==NNS Rewards==

Every day the NNS mints [[NNS Rewards]] and these rewards are apportioned to those neurons who voted that day.

==Viewing Proposals==

Two most common ways of viewing proposals are:

* [https://dashboard.internetcomputer.org/governance Internet Computer Dashboard: Governance]
* '''Voting''' tab on [https://nns.ic0.app/#/accounts NNS Frontend dapp]

==How to Vote==

There are two forms of voting: manual voting and following neurons.

=== Manual Voting===
Users can vote on proposals manually by using the NNS Frontend dapp, see: [[ICP voting with NNS frontend dapp]].

===Following neurons===
A neuron can follow any neuron. See [[How-To:_Set_your_neuron_to_follow_another_neuron|instructions]]. See [[Editing following for neurons]]

==See Also==
* [[Managing ICP holdings]]
* [[ICP custody options]]
* [[ICP staking with NNS frontend dapp]]

Editing following for neurons

2025-06-30T16:15:58Z

Jessie.mongeon:

{{#externalredirect: https://internetcomputer.org/docs/building-apps/governing-apps/nns/using-the-nns-dapp/nns-dapp-following-other-neurons}}

How-To: Set your neuron to follow another neuron

2025-06-30T16:15:39Z

Jessie.mongeon:

{{#externalredirect: https://internetcomputer.org/docs/building-apps/governing-apps/nns/using-the-nns-dapp/nns-dapp-following-other-neurons}}