Get desktop application:
View/edit binary Protocol Buffers messages
Subset of Neuron that has no collections or big fields that might not exist in most neurons, and the goal is to keep the size of the struct consistent and can be easily stored in a StableBTreeMap. For the meaning of each field, see the Neuron struct.
Adds and/or removes NodeProviders from the list of current node providers.
Used in:
For all Neurons controlled by the given principals, set their KYC status to `kyc_verified=true`.
Used in:
Audit events in order to leave an audit trail for certain operations.
The timestamp of the event.
Reset aging timestamps for https://forum.dfinity.org/t/icp-neuron-age-is-52-years/21261/26
Restore aging timestamp that were incorrectly reset.
Used in:
The neuron id whose aging was reset.
The aging_since_timestamp_seconds before reset.
The aging_since_timestamp_seconds after reset.
Neuron's dissolve state at the time of reset.
Neuron's stake at the time of reset.
Used in:
The neuron id whose aging was restored.
The aging_since_timestamp_seconds before restore.
The aging_since_timestamp_seconds after restore.
Neuron's dissolve state at the time of restore.
Neuron's stake at the time of restore.
Used in: ,
How did a neuron vote in the recent past? This data is used by other neurons to determine what neurons to follow.
Used in: ,
The arguments to the method `claim_or_refresh_neuron_from_account`. DEPRECATED: Use ManageNeuron::ClaimOrRefresh.
The principal for which to refresh the account. If not specified, defaults to the caller.
The memo of the staking transaction.
Response to claim_or_refresh_neuron_from_account. DEPRECATED: Use ManageNeuron::ClaimOrRefresh.
Specified in case of error.
The ID of the neuron that was created or empty in the case of error.
Mainly, calls the deploy_new_sns Candid method on the SNS-WASMs canister. Therefore, most of the fields here have equivalents in SnsInitPayload. Please, consult the comments therein.
Metadata --------
Used in:
Proposal Parameters -------------------
Used in:
Used in:
Used in:
Used in:
Used in:
Used in:
Used in:
Used in:
Used in:
The swap occurs at a specific time of day, in UTC. It will happen the first time start_time occurs that's at least 24h after the proposal is adopted.
The amount that the Neuron's Fund will collectively spend in maturity on the swap.
Whether Neurons' Fund participation is requested. Cannot be set to true until Matched Funding is released
Used in:
This message has a couple of unusual features. 1. There is (currently) only one field. We expect that more fields will be (and possibly other clients) to be able to handle this information in a generic way, i.e. without having to change their code. 2. Fields that might be added later will probably be mutually exclusive with existing fields. Normally, this would be handled by putting all such fields into a oneof. However, Candid has a bug where variant is not handled correctly. Therefore, we refrain from using oneof until we believe that the fix is very imminent.
Used in: ,
Empty message to use in oneof fields that represent empty enums.
Used in:
(message has no fields)
Payload of a proposal that calls a function on another NNS canister. The canister and function to call is derived from the `nns_function`.
Used in:
This enum value determines what canister to call and what NNS function to call on that canister.
The payload of the NNS function.
ID of the NNS proposal that resulted in the creation of the corresponding Swap.
Request was completed successfully.
Used in:
Represents public information suitable for auditing Neurons' Fund participation in an SNS swap.
This represents the whole NNS governance system. It contains all information about the NNS governance system that must be kept across upgrades of the NNS governance system.
Current set of neurons.
Proposals.
The transfers that have been made to stake new neurons, but haven't been claimed by the user, yet.
Also known as the 'normal voting period'. The maximum time a proposal (of a topic with "normal" voting period) is open for voting. If a proposal has not been decided (adopted or rejected) within this time since the proposal was made, the proposal is rejected. See also `short_voting_period_seconds`.
The network economics configuration parameters.
The last reward event. Should never be missing.
Set of in-flight neuron ledger commands. Whenever we issue a ledger transfer (for disburse, split, spawn etc) we store it in this map, keyed by the id of the neuron being changed and remove the entry when it completes. An entry being present in this map acts like a "lock" on the neuron and thus prevents concurrent changes that might happen due to the interleaving of user requests and callback execution. If there are no ongoing requests, this map should be empty. If something goes fundamentally wrong (say we trap at some point after issuing a transfer call) the neuron(s) involved are left in a "locked" state, meaning new operations can't be applied without reconciling the state. Because we know exactly what was going on, we should have the information necessary to reconcile the state, using custom code added on upgrade, if necessary.
The timestamp, in seconds since the unix epoch, at which `canister_init` was run for the governance canister, considered the genesis of the IC for reward purposes.
The entities that own the nodes running the IC.
Default followees A map of Topic (as i32) to Neuron id that is set as the default following for all neurons created post-genesis. On initialization it's required that the Neurons present in this map are present in the initial set of neurons. Default following can be changed via proposal.
The maximum time a proposal of a topic with *short voting period* is open for voting. If a proposal on a topic with short voting period has not been decided (adopted or rejected) within this time since the proposal was made, the proposal is rejected. The short voting period is used for proposals that don't make sense to vote on if the proposal is "old". For example, proposals to set the exchange rate should not be voted on if they're days old because exchange rates fluctuate regularly. Currently, only proposals to set the exchange rate use the short voting period, and such proposals are deprecated.
The maximum time a proposal of a topic with *private voting period* is open for voting. If a proposal on a topic with short voting period has not been decided (adopted or rejected) within this time since the proposal was made, the proposal is rejected. This is useful for proposals that are for "private matters" like NeuronManagement proposals. These proposals are not meant to be voted on by the general public and have limited impact, so a different voting period is appropriate.
Cached value for the maturity modulation as calculated each day.
The last time that the maturity modulation value was updated.
Whether the heartbeat function is currently spawning neurons, meaning that it should finish before being called again.
Migration related data.
A Structure used during upgrade to store the index of topics for neurons to their followers. This is the inverse of what is stored in a Neuron (its followees).
Local cache for XDR-related conversion rates (the source of truth is in the CMC canister).
The summary of restore aging event.
A map of followees to their followers.
Used in:
The key is the neuron ID of the followee.
Used in:
The followers of the neuron with the given ID. These values will be non-repeating, and order does not matter.
Stores metrics that are too costly to compute each time metrics are requested. For bucketed metrics, keys are bucket IDs, i.e., number of full half-year dissolve delay intervals of neurons counted towards this bucket.
Used in:
Records that making an OpenSnsTokenSwap (OSTS) or CreateServiceNervousSystem (CSNS) proposal is in progress. We only want one of these to be happening at the same time, because otherwise, it is error prone to enforce that open OSTS or CSNS proposals are unique. In particular, the result of checking that the proposal currently being made would be unique is liable to becoming invalid during an .await. This is a temporary measure, because OSTS is part of the SNS flow that will be replaced by 1-proposal very soon.
Used in:
Progress of a migration that (potentially) is performed over the course of more than one heartbeat call.
Used in:
Migration status.
The reason why it failed. Should only be present when the status is FAILED. This is only for debugging and it should not be used programmatically (other than its presence).
Migration progress (cursor).
Last neuron id migrated.
Used in:
Unspecified.
Migration is in progress.
Migration succeeded.
Migration failed.
The status of all on-going (and recently completed) migrations (that take place over the course of multiple heartbeat calls). Each Migration field corresponds to one (ongoing or recently completed) migration. After a migration is finished, it should be OK to reserve the tag and lose the data.
Used in:
Migrates neuron indexes to stable storage.
The possible commands that require interaction with the ledger.
Used in:
The timestamp at which the command was issued, for debugging purposes.
A general place holder for sync commands. The neuron lock is never left holding a sync command (as it either succeeds to acquire the lock and releases it in the same call, or never acquires it in the first place), but it still must be acquired to prevent interleaving with another async command. Thus there's no value in actually storing the command itself, and this placeholder can generally be used in all sync cases.
Used in:
(message has no fields)
Used in: , , , , ,
Used in:
The operation was successfully completed.
This operation is not available, e.g., not implemented.
The caller is not authorized to perform this operation.
Some entity required for the operation (for example, a neuron) was not found.
The command was missing or invalid. This is a permanent error.
The neuron is dissolving or dissolved and the operation requires it to be not dissolving (that is, having a non-zero dissolve delay that is accumulating age).
The neuron is not dissolving or dissolved and the operation requires it to be dissolving (that is, having a non-zero dissolve delay with zero age that is not accumulating).
The neuron is not dissolving and not dissolved and the operation requires it to be dissolved (that is, having a dissolve delay of zero and an age of zero).
When adding or removing a hot key: the key to add was already present or the key to remove was not present or the key to add was invalid or adding another hot key would bring the total number of the maximum number of allowed hot keys per neuron.
Some canister side resource is exhausted, so this operation cannot be performed.
Some precondition for executing this method was not met (e.g. the neuron's dissolve time is too short). There could be a change in the state of the system such that the operation becomes allowed (e.g. the owner of the neuron increases its dissolve delay).
Executing this method failed for some reason external to the governance canister.
A neuron has an ongoing ledger update and thus can't be changed.
There wasn't enough funds to perform the operation.
The principal provided was invalid.
The proposal is defective in some way (e.g. title is too long). If the same proposal is submitted again without modification, it will be rejected regardless of changes in the system's state (e.g. increasing the neuron's dissolve delay will not make the proposal acceptable).
The neuron attempted to join the community fund while already a member.
The neuron attempted to leave the community fund but is not a member.
This function is called "ideal" because it serves as the guideline that the Neurons' Fund will try to follow, but may deviate from in order to satisfy SNS-specific participation constraints while allocating its overall participation amount among its neurons' maturity. In contrast, The "effective" matched participation function `crate::neurons_fund::MatchedParticipationFunction` is computed *based* on this one.
Used in:
The encoding of the "ideal" matched participation function is defined in `crate::neurons_fund`. In the future, we could change this message to represent full abstract syntactic trees comprised of elementary mathematical operators, with literals and variables as tree leaves.
Used in: ,
Known neurons have extra information (a name and optionally a description) that can be used to identify them.
Used in: , ,
A response to "ListKnownNeurons"
List of known neurons.
A request to list neurons. The "requested list", i.e., the list of neuron IDs to retrieve information about, is the union of the list of neurons listed in `neuron_ids` and, if `caller_neurons` is true, the list of neuron IDs of neurons for which the caller is the controller or one of the hot keys.
The neurons to get information about. The "requested list" contains all of these neuron IDs.
If true, the "requested list" also contains the neuron ID of the neurons that the calling principal is authorized to read.
A response to a `ListNeurons` request. The "requested list" is described in `ListNeurons`.
For each neuron ID in the "requested list", if this neuron exists, its `NeuronInfo` at the time of the call will be in this map.
For each neuron ID in the "requested list", if the neuron exists, and the caller is authorized to read the full neuron (controller, hot key, or controller or hot key of some followee on the `ManageNeuron` topic).
Response to list_node_providers
List of all "NodeProviders"
Proposals with restricted voting are not included unless the caller is allowed to vote on them. The actual ballots of the proposal are restricted to ballots cast by the caller.
Limit on the number of [ProposalInfo] to return. If no value is specified, or if a value greater than 100 is specified, 100 will be used.
If specified, only return proposals that are strictly earlier than the specified proposal according to the proposal ID. If not specified, start with the most recent proposal.
Exclude proposals with a topic in this list. This is particularly useful to exclude proposals on the topics TOPIC_EXCHANGE_RATE and TOPIC_KYC which most users are not likely to be interested in seeing.
Include proposals that have a reward status in this list (see [ProposalRewardStatus] for more information). If this list is empty, no restriction is applied. For example, many users listing proposals will only be interested in proposals for which they can receive voting rewards, i.e., with reward status PROPOSAL_REWARD_STATUS_ACCEPT_VOTES.
Include proposals that have a status in this list (see [ProposalStatus] for more information). If this list is empty, no restriction is applied.
Include all ManageNeuron proposals regardless of the visibility of the proposal to the caller principal. Note that exclude_topic is still respected even when this option is set to true.
Omits "large fields" from the response. Currently only omits the `logo` and `token_logo` field of CreateServiceNervousSystem proposals. This is useful to improve download times and to ensure that the response to the request doesn't exceed the message size limit.
All operations that modify the state of an existing neuron are represented by instances of `ManageNeuron`. All commands are available to the `controller` of the neuron. In addition, commands related to voting, i.g., [manage_neuron::Follow] and [manage_neuron::RegisterVote], are also available to the registered hot keys of the neuron.
Used in:
This is the legacy way to specify neuron IDs that is now discouraged.
The ID of the neuron to manage. This can either be a subaccount or a neuron ID.
Add a new hot key that can be used to manage the neuron. This provides an alternative to using the controller principal’s cold key to manage the neuron, which might be onerous and difficult to keep secure, especially if it is used regularly. A hot key might be a WebAuthn key that is maintained inside a user device, such as a smartphone.
Used in:
Changes auto-stake maturity for this Neuron. While on, auto-stake maturity will cause all the maturity generated by voting rewards to this neuron to be automatically staked and contribute to the voting power of the neuron.
Used in:
Claim a new neuron or refresh the stake of an existing neuron.
Used in: ,
DEPRECATED: Use MemoAndController and omit the controller.
Claim or refresh a neuron, by providing the memo used in the staking transfer and 'controller' as the principal id used to calculate the subaccount to which the transfer was made. If 'controller' is omitted, the principal id of the caller is used.
This just serves as a tag to indicate that the neuron should be refreshed by it's id or subaccount. This does not work to claim new neurons.
Used in:
Commands that only configure a given neuron, but do not interact with the outside world. They all require the caller to be the controller of the neuron.
Used in: ,
Disburse this neuron's stake: transfer the staked ICP to the specified account.
Used in: ,
The (optional) amount to transfer. If not specified the cached stake is used.
The principal to which to transfer the stake.
Used in:
Disburse a portion of this neuron's stake into another neuron. This allows to split a neuron but with a new dissolve delay and owned by someone else.
Used in: ,
The controller of the new neuron (must be set).
The amount to disburse.
The dissolve delay of the new neuron.
Whether the new neuron has been kyc verified.
The nonce with which to create the subaccount.
Add a rule that enables the neuron to vote automatically on proposals that belong to a specific topic, by specifying a group of followee neurons whose majority vote is followed. The configuration of such follow rules can be used to a) distribute control over voting power amongst multiple entities, b) have a neuron vote automatically when its owner lacks time to evaluate newly submitted proposals, c) have a neuron vote automatically when its own lacks the expertise to evaluate newly submitted proposals, and d) for other purposes. A follow rule specifies a set of followees. Once a majority of the followees votes to adopt or reject a proposal belonging to the specified topic, the neuron votes the same way. If it becomes impossible for a majority of the followees to adopt (for example, because they are split 50-50 between adopt and reject), then the neuron votes to reject. If a rule is specified where the proposal topic is UNSPECIFIED, then it becomes a catch-all follow rule, which will be used to vote automatically on proposals belonging to topics for which no specific rule has been specified. If the list 'followees' is empty, this removes following for a specific topic.
Used in:
Topic UNSPECIFIED means add following for the 'catch all'.
The dissolve delay of a neuron can be increased up to a maximum of 8 years.
Used in:
Join the Internet Computer's community fund with this neuron's present and future maturity.
Used in:
(message has no fields)
Leave the Internet Computer's community fund.
Used in:
(message has no fields)
Merge another neuron into this neuron.
Used in: ,
The neuron to merge stake and maturity from.
Merge the maturity of a neuron into the current stake. The caller can choose a percentage of the current maturity to merge into the existing stake. The resulting amount to merge must be greater than or equal to the transaction fee.
Used in: ,
The percentage to merge, from 1 to 100 (inclusive).
Have the neuron vote to either adopt or reject a proposal with a specified id.
Used in:
Remove a hot key that has been previously assigned to the neuron.
Used in:
An (idempotent) alternative to IncreaseDissolveDelay where the dissolve delay is passed as an absolute timestamp in seconds since the unix epoch.
Used in:
When the maturity of a neuron has risen above a threshold, it can be instructed to spawn a new neuron. This creates a new neuron that locks a new balance of ICP on the ledger. The new neuron can remain controlled by the same principal as its parent, or be assigned to a new principal.
Used in:
If not set, the spawned neuron will have the same controller as this neuron.
The nonce with which to create the subaccount.
The percentage to spawn, from 1 to 100 (inclusive).
Split this neuron into two neurons. The child neuron retains the parent neuron's properties.
Used in: ,
The amount to split to the child neuron.
Stake the maturity of a neuron. The caller can choose a percentage of of the current maturity to stake. If 'percentage_to_stake' is not provided, all of the neuron's current maturity will be staked.
Used in:
The percentage of maturity to stake, from 1 to 100 (inclusive).
Used in:
(message has no fields)
Used in:
(message has no fields)
The response of the ManageNeuron command There is a dedicated response type for each `ManageNeuron.command` field
Used in:
Used in:
(message has no fields)
Used in:
The block height at which the disburse transfer happened
Used in:
The ID of the Neuron created from disbursing a Neuron
Used in:
(message has no fields)
Used in:
The ID of the created proposal
Used in:
A response for merging or simulating merge neurons
Used in:
The resulting state of the source neuron
The resulting state of the target neuron
The NeuronInfo of the source neuron
The NeuronInfo of the target neuron
Used in:
(message has no fields)
Used in:
The ID of the Neuron created from spawning a Neuron
Used in:
The ID of the Neuron created from splitting another Neuron
Used in:
The most recent monthly Node Provider rewards
Used in:
If adopted, a motion should guide the future strategy of the Internet Computer ecosystem.
Used in:
The text of the motion. Maximum 100kib.
Network economics contains the parameters for several operations related to the economy of the network. When submitting a NetworkEconomics proposal default values (0) are considered unchanged, so a valid proposal only needs to set the parameters that it wishes to change. In other words, it's not possible to set any of the values of NetworkEconomics to 0. NOTE: If adding a value to this proto, make sure there is a corresponding `if` in Governance::perform_action().
Used in: ,
The number of E8s (10E-8 of an ICP token) that a rejected proposal will cost. This fee should be controlled by an #Economic proposal type. The fee does not apply for ManageNeuron proposals.
The minimum number of E8s that can be staked in a neuron.
The number of E8s (10E-8 of an ICP token) that it costs to employ the 'manage neuron' functionality through proposals. The cost is incurred by the neuron that makes the 'manage neuron' proposal and is applied regardless of whether the proposal is adopted or rejected.
The minimum number that the ICP/XDR conversion rate can be set to. Measured in XDR (the currency code of IMF SDR) to two decimal places. See /rs/protobuf/def/registry/conversion_rate/v1/conversion_rate.proto for more information on the rate itself.
The dissolve delay of a neuron spawned from the maturity of an existing neuron.
The maximum rewards to be distributed to NodeProviders in a single distribution event, in e8s.
The transaction fee that must be paid for each ledger transaction.
The maximum number of proposals to keep, per topic for eligible topics. When the total number of proposals for a given topic is greater than this number, the oldest proposals that have reached a "final" state may be deleted. If unspecified or zero, all proposals are kept.
Global Neurons' Fund participation thresholds.
This structure represents a neuron "at rest" in governance system of the Internet Computer IC.
Used in: , ,
The id of the neuron. This is stored here temporarily, since its also stored on the map that contains neurons. Initialization uses ids for the following graph. We need neurons to come into existence at genesis with pre-chosen ids, so a neuron needs to have an id. We could alternatively choose a unique naming scheme instead and chose the ids on the initialization of the canister.
The principal of the ICP ledger account where the locked ICP balance resides. This principal is indistinguishable from one identifying a public key pair, such that those browsing the ICP ledger cannot tell which balances belong to neurons.
The principal that actually controls the neuron. The principal must identify a public key pair, which acts as a “master key”, such that the corresponding secret key should be kept very secure. The principal may control many neurons.
Keys that can be used to perform actions with limited privileges without exposing the secret key corresponding to the principal e.g. could be a WebAuthn key.
The amount of staked ICP tokens, measured in fractions of 10E-8 of an ICP. Cached record of the locked ICP balance on the ICP ledger. For neuron creation: has to contain some minimum amount. A spawned neuron with less stake cannot increase its dissolve delay.
The amount of ICP that this neuron has forfeited due to making proposals that were subsequently rejected or from using the 'manage neurons through proposals' functionality. Must be smaller than 'neuron_stake_e8s'. When a neuron is disbursed, these ICP will be burned.
When the Neuron was created. A neuron can only vote on proposals submitted after its creation date.
The timestamp, in seconds from the Unix epoch, corresponding to the time this neuron has started aging. This is either the creation time or the last time at which the neuron has stopped dissolving. This value is meaningless when the neuron is dissolving, since a dissolving neurons always has age zero. The canonical value of this field for a dissolving neuron is `u64::MAX`.
The timestamp, in seconds from the Unix epoch, at which this neuron should be spawned and its maturity converted to ICP according to https://wiki.internetcomputer.org/wiki/Maturity_modulation.
At any time, at most one of `when_dissolved` and `dissolve_delay` are specified. `NotDissolving`. This is represented by `dissolve_delay` being set to a non zero value. `Dissolving`. This is represented by `when_dissolved` being set, and this value is in the future. `Dissolved`. All other states represent the dissolved state. That is, (a) `when_dissolved` is set and in the past, (b) `dissolve_delay` is set to zero, (c) neither value is set. Cf. [Neuron::stop_dissolving] and [Neuron::start_dissolving].
When the dissolve timer is running, this stores the timestamp, in seconds from the Unix epoch, at which the neuron becomes dissolved. At any time while the neuron is dissolving, the neuron owner may pause dissolving, in which case `dissolve_delay_seconds` will get assigned to: `when_dissolved_timestamp_seconds - <timestamp when the action is taken>`.
When the dissolve timer is stopped, this stores how much time, in seconds, the dissolve timer will be started with. Can be at most 8 years. At any time while in this state, the neuron owner may (re)start dissolving, in which case `when_dissolved_timestamp_seconds` will get assigned to: `<timestamp when the action is taken> + dissolve_delay_seconds`.
Map `Topic` to followees. The key is represented by an integer as Protobuf does not support enum keys in maps.
Information about how this neuron voted in the recent past. It only contains proposals that the neuron voted yes or no on.
`true` if this neuron has passed KYC, `false` otherwise
The record of the transfer that was made to create this neuron.
The accumulated unstaked maturity of the neuron, in "e8s equivalent". The unit is "e8s equivalent" to insist that, while this quantity is on the same scale as ICPs, maturity is not directly convertible to ICPs: conversion requires a minting event and the conversion rate is variable.
The accumulated staked maturity of the neuron, in "e8s equivalent" (see "maturity_e8s_equivalent"). Staked maturity becomes regular maturity once the neuron is dissolved. Contrary to `maturity_e8s_equivalent` this maturity is staked and thus locked until the neuron is dissolved and contributes to voting power and rewards. Once the neuron is dissolved, this maturity will be "moved" to 'maturity_e8s_equivalent' and will be able to be spawned (with maturity modulation).
If set and true the maturity rewarded to this neuron for voting will be automatically staked and will contribute to the neuron's voting power.
Whether this neuron is "Not for profit", making it dissolvable by voting.
If set, this neuron is a member of the Community Fund. This means that when a proposal to open an SNS token swap is executed, maturity from this neuron will be used to participate in the SNS token swap.
If set, the neuron belongs to the "known neurons". It has been given a name and maybe a description.
The type of the Neuron. See [NeuronType] for a description of the different states.
Protobuf representing a list of followees of a neuron for a specific topic.
Used in: , ,
The result of querying for the state of a single neuron.
Used in: ,
The exact time at which this data was computed. This means, for example, that the exact time that this neuron will enter the dissolved state, assuming it is currently dissolving, is given by `retrieved_at_timestamp_seconds+dissolve_delay_seconds`.
The current state of the neuron. See [NeuronState] for a description of the different states.
The current age of the neuron. See [Neuron::age_seconds] for details on how it is computed.
The current dissolve delay of the neuron. See [Neuron::dissolve_delay_seconds] for details on how it is computed.
See [Neuron::recent_ballots] for a description.
Current voting power of the neuron.
When the Neuron was created. A neuron can only vote on proposals submitted after its creation date.
Current stake of the neuron, in e8s.
Timestamp when this neuron joined the community fund.
If this neuron is a known neuron, this is data associated with it, including the neuron's name and (optionally) a description.
The type of the Neuron. See [NeuronType] for a description of the different states.
A transfer performed from some account to stake a new neuron.
Used in: ,
When the transfer arrived at the governance canister.
The principal that made the transfer.
The (optional) subaccount from which the transfer was made.
The subaccount to which the transfer was made.
The amount of stake that was transferred.
The block height at which the transfer occurred.
The memo sent with the transfer.
Every neuron is in one of three states. Note that `Disbursed` is not a state of a neuron, as the neuron is consumed through the act of disbursement (using the method [Governance::disburse]). See [neuron::DissolveState] for detail on how the different states are represented.
Used in:
Not a valid state. Required by Protobufs.
In this state, the neuron is not dissolving and has a specific `dissolve_delay`. It accrues `age` by the passage of time and it can vote if `dissolve_delay` is at least six months. The method [Neuron::start_dissolving] can be called to transfer the neuron to the `Dissolving` state. The method [Neuron::increase_dissolve_delay] can be used to increase the dissolve delay without affecting the state or the age of the neuron.
In this state, the neuron's `dissolve_delay` decreases with the passage of time. While dissolving, the neuron's age is considered zero. Eventually it will reach the `Dissolved` state. The method [Neuron::stop_dissolving] can be called to transfer the neuron to the `NotDissolving` state, and the neuron will start aging again. The method [Neuron::increase_dissolve_delay] can be used to increase the dissolve delay, but this will not stop the timer or affect the age of the neuron.
In the dissolved state, the neuron's stake can be disbursed using the [Governance::disburse] method. It cannot vote as its `dissolve_delay` is considered to be zero. If the method [Neuron::increase_dissolve_delay] is called in this state, the neuron will no longer be dissolving, with the specified dissolve delay, and will start aging again. Neuron holders have an incentive not to keep neurons in the 'dissolved' state for a long time: if the holders wants to make their tokens liquid, they disburse the neuron's stake, and if they want to earn voting rewards, they increase the dissolve delay. If these incentives turn out to be insufficient, the NNS may decide to impose further restrictions on dissolved neurons.
The neuron is in spawning state, meaning it's maturity will be converted to ICP according to https://wiki.internetcomputer.org/wiki/Maturity_modulation.
Types of a Neuron.
Used in: , ,
Placeholder value due to the proto3 requirement for a zero default. This is an invalid type; neurons should not be assigned this value.
Represents neurons initially created for Seed accounts in the Genesis Token Canister, or those descended from such neurons.
Represents neurons initially created for Early Contributor Token (ECT) accounts in the Genesis Token Canister, or those descended from such neurons.
This is a view of the NeuronsFundData returned by API queries and is NOT used for storage. Currently, the structure is identical to NeuronsFundData, but this may change over time. Some of the fields, e.g., actual IDs of neurons, are anonymized.
Used in:
See documentation for NeuronsFundData.neurons_fund_participation
See documentation for NeuronsFundData.final_neurons_fund_participation
See documentation for NeuronsFundData.neurons_fund_refunds
This structure contains data for settling the Neurons' Fund participation in an SNS token swap.
Used in:
Initial Neurons' Fund reserves computed at the time of execution of the proposal through which the SNS swap is created.
Final Neurons' Fund participation computed at the time of swap finalization. This field should remain unspecified until either (1) the `settle_neurons_fund_participation` function is called or (2) the NNS handles an error at the SNS deployment stage. If specified, this must be a subset of `initial_neurons_fund_participation`.
Refunds for any leftover Neurons' Fund maturity that could not be used to participate in the swap. This field should remain unspecified `settle_neurons_fund_participation` is called. If specified, this must be equal to the following set-difference: `initial_neurons_fund_participation.neurons_fund_reserves` set-minus `final_neurons_fund_participation.neurons_fund_reserves`.
When the Neurons' Fund decides to participates in an SNS swap, the amount of participation is determined according to the rules of Matched Funding. The amount of ICP tokens contributed by the Neurons' Fund depends on four factors: (1) Direct participation amount at the time of the swap's successful finalization. (2) Amount of maturity held by all eligible neurons that were members of the Neurons' Fund at the time of the CreateServiceNervousSystem proposal execution. (3) Global Neurons' Fund participation thresholds, held in this structure (defined in XDR). (4) ICP/XDR conversion rate at the time of the CreateServiceNervousSystem proposal execution.
Used in:
This is a theoretical limit which should be smaller than any realistic amount of maturity that practically needs to be reserved from the Neurons' Fund for a given SNS swap.
Thresholds specifying the shape of the matching function used by the Neurons' Fund to determine how much to contribute for a given direct participation amount.
The minimum value of the ICP/XDR conversion rate used by the Neurons' Fund for converting XDR values into ICP.
The maximum value of the ICP/XDR conversion rate used by the Neurons' Fund for converting XDR values into ICP.
The thresholds specify the shape of the ideal matching function used by the Neurons' Fund to determine how much to contribute for a given direct participation amount. Note that the actual swap participation is in ICP, whereas these thresholds are specifid in XDR; the conversion rate is determined at the time of execution of the CreateServiceNervousSystem proposal.
Used in:
Up to this amount of direct participation, the Neurons' Fund does not contribute to this SNS.
Say the direct participation amount is `x_icp`. When `x_icp` equals the equavalent of `one_third_participation_milestone_xdr` in ICP (we use ICP/XDR conversion data from the CMC), the Neurons' Fund contributes 50% on top of that amount, so the overall contributions would be `1.5 * x_icp` of which 1/3 comes from the Neurons' Fund.
Say the direct participation amount is `x_icp`. When `x_icp` equals the equavalent of `full_participation_milestone_xdr` in ICP (we use ICP/XDR conversion data from the CMC), the Neurons' Fund contributes 100% on top of that amount, so the overall contributions would be `2.0 * x_icp` of which a half comes from the Neurons' Fund.
Information for deciding how the Neurons' Fund should participate in an SNS Swap.
Used in: ,
The function used in the implementation of Matched Funding. If an NNS Governance upgrade takes place *during* a swap, the original "ideal" matched participation function needs to be recovered at the end of the swap, ensuring e.g., that the amount of maturity stored in `neurons_fund_snapshot` will not not be exceeded for due to a change in this function.
The snapshot of the Neurons' Fund allocation of its maximum swap participation amount among its neurons. This snapshot is computed at the execution time of the NNS proposal leading to the swap opening.
Absolute constraints for direct participants of this swap needed in Matched Funding computations.
Neurons' Fund participation is computed for this amount of direct participation.
Total amount of maturity in the Neurons' Fund at the time when the Neurons' Fund participation was created.
Maximum amount that the Neurons' Fund will participate with in this SNS swap, regardless of how large the value of `direct_participation_icp_e8s` is.
How much the Neurons' Fund would ideally like to participate with in this SNS swap, given the direct participation amount (`direct_participation_icp_e8s`) and matching function (`ideal_matched_participation_function`).
How much from `intended_neurons_fund_participation_icp_e8s` was the Neurons' Fund actually able to allocate, given the specific composition of neurons at the time of execution of the proposal through which this SNS was created and the participation limits of this SNS.
The snapshot of the Neurons' Fund allocation of its maximum swap participation amount among its neurons. This snapshot is computed at the execution time of the NNS proposal leading to the swap opening; it is then used at the end of a swap to compute the refund amounts per Neuron' Fund neuron.
Used in: , ,
Represents one NNS neuron from the Neurons' Fund participating in this swap.
Used in:
The NNS neuron ID of the participating neuron.
Portion of maturity taken from this neuron. Must be less than or equal to `maturity_equivalent_icp_e8s`.
Overall amount of maturity of the neuron from which this portion is taken.
The principal that can vote on behalf of this neuron.
Whether the portion specified by `amount_icp_e8s` is limited due to SNS-specific participation constraints.
List of NNS functions that can be called by proposals.
Used in:
This exists because proto3 defaults to the 0 value on enums.
Combine a specified set of nodes, typically drawn from data centers and operators in such a way as to guarantee their independence, into a new decentralized subnet. The execution of this NNS function first initiates a new instance of the distributed key generation protocol. The transcript of that protocol is written to a new subnet record in the registry, together with initial configuration information for the subnet, from where the nodes comprising the subnet pick it up.
Add a new node to a subnet. The node cannot be currently assigned to a subnet. The execution of this proposal changes an existing subnet record to add a node. From the perspective of the NNS, this update is a simple update of the subnet record in the registry.
A proposal to add a new canister to be installed and executed in the NNS subnetwork. The root canister, which controls all canisters on the NNS except for itself, handles this proposal type. The call also expects the Wasm module that shall be installed.
A proposal to upgrade an existing canister in the NNS subnetwork. This proposal type is executed by the root canister. Beyond upgrading the Wasm module of the target canister, the proposal can also set the authorization information and the allocations.
A proposal to bless a new version to which the replicas can be upgraded. The proposal registers a replica version (identified by the hash of the installation image) in the registry. Besides creating a record for that version, the proposal also appends that version to the list of "blessed versions" that can be installed on a subnet. By itself, this proposal does not effect any upgrade.
Update a subnet's recovery CUP (used to recover subnets that have stalled). Nodes that find a recovery CUP for their subnet will load that CUP from the registry and restart the replica from that CUP.
Update a subnet's configuration. This proposal updates the subnet record in the registry, with the changes being picked up by the nodes on the subnet when they reference the respective registry version. Subnet configuration comprises protocol parameters that must be consistent across the subnet (e.g. message sizes).
Assign an identity to a node operator, such as a funding partner, associating key information regarding its ownership, the jurisdiction in which it is located, and other information. The node operator is stored as a record in the registry. It contains the remaining node allowance for that node operator, that is the number of nodes the node operator can still add to the IC. When an additional node is added by the node operator, the remaining allowance is decreased.
A proposal to upgrade the root canister in the NNS subnetwork. The proposal is processed by the Lifeline canister, which controls the root canister. The proposal updates the Wasm module as well as the authorization settings.
Update the ICP/XDR conversion rate. Changes the ICP-to-XDR conversion rate in the governance canister. This setting affects cycles pricing (as the value of cycles shall be constant with respect to IMF SDRs) as well as the rewards paid for nodes, which are expected to be specified in terms of IMF SDRs as well.
Deploy a GuestOS version to a given subnet. The proposal changes the GuestOS version that is used on the specified subnet. The version must be contained in the list of elected GuestOS versions. The upgrade is completed when the subnet creates the next regular CUP.
Clear the provisional whitelist. The proposal changes the provisional whitelist to the empty list.
Removes a node from a subnet. The node must be currently assigned to a subnet. The execution of this proposal changes an existing subnet record to remove a node. From the perspective of the NNS, this update is a simple update of the subnet record in the registry.
Informs the cycles minting canister that a certain principal is authorized to use certain subnetworks (from a list). Can also be used to set the "default" list of subnetworks that principals without special authorization are allowed to use.
Change the Firewall configuration in the registry. (TODO: Remove when IC-1026 is fully integrated)
Change a Node Operator's allowance in the registry.
Stop or start an NNS canister.
Remove unassigned nodes from the registry.
Uninstall code of a canister.
Update the node rewards table.
Add or remove Data Center records.
(obsolete) Update the config for all unassigned nodes.
Remove Node Operator from the registry.
Update the routing table in the registry.
Add firewall rules in the registry
Remove firewall rules in the registry
Update firewall rules in the registry
Insert or update `canister_migrations` entries.
Remove `canister_migrations` entries.
Add a new SNS canister WASM
Change the subnet node membership. In a way, this function combines the separate functions for adding and removing nodes from the subnet record, but adds the property of atomic node replacement (node swap) on top. The nodes that are being added to the subnet must be currently unassigned. The nodes that are being removed from the subnet must be currently assigned to the subnet.
Updates the available subnet types in the cycles minting canister.
Changes the assignment of subnets to subnet types in the cycles minting canister.
Update the list of SNS subnet IDs that SNS WASM will deploy SNS instances to.
Update the SNS-wasm canister's list of allowed principals. This list guards which principals can deploy an SNS.
A proposal to retire previously elected and unused replica versions. The specified versions are removed from the registry and the "blessed versions" record. This ensures that the replica cannot upgrade to these versions anymore.
Insert custom upgrade path entries into SNS-W for all SNSes, or for an SNS specified by its governance canister ID.
A proposal to change the set of elected GuestOS versions. The version to elect (identified by the hash of the installation image) is added to the registry. Besides creating a record for that version, the proposal also appends that version to the list of elected versions that can be installed on nodes of a subnet. Only elected GuestOS versions can be deployed.
OBSOLETE: use NNS_FUNCTION_REVISE_ELECTED_HOSTOS_VERSIONS instead
OBSOLETE: use NNS_FUNCTION_UPGRADE_HOSTOS_FOR_SOME_NODES instead
Uninstall and Install Root with the WASM provided in the function. If InitArgs are provided They will be passed to the canister_init function of the WASM provided. This function is meant as a Break Glass mechanism for when an open call context in the Root canister is preventing root or another canister from upgrading (in the case of proxied calls).
A proposal to add a set of new API Boundary Nodes using unassigned nodes
A proposal to remove a set of API Boundary Nodes, which will designate them as unassigned nodes
(obsolete) A proposal to update the version of a set of API Boundary Nodes
A proposal to update the version of a set of API Boundary Nodes
A proposal to update the version of all unassigned nodes
A proposal to update SSH readonly access for all unassigned nodes
A proposal to change the set of currently elected HostOS versions, by electing a new version, and/or unelecting some priorly elected versions. HostOS versions are identified by the hash of the installation image. The version to elect is added to the Registry, and the versions to unelect are removed from the Registry, ensuring that HostOS cannot upgrade to these versions anymore. This proposal does not actually perform the upgrade; for deployment of an elected version, please refer to `NNS_FUNCTION_DEPLOY_HOSTOS_TO_SOME_NODES`.
Deploy a HostOS version to a given set of nodes. The proposal changes the HostOS version that is used on the specified nodes.
The entity that owns the nodes that run the network. Note that this is different from a node operator, the entity that operates the nodes. In terms of responsibilities, the node operator is responsible for adding/removing and generally making sure that the nodes are working, while the NodeProvider is the entity that is compensated. Note: The NodeOperatorRecord is defined in: rs/protobuf/def/registry/node_operator/v1/node_operator.proto.
Used in: , , ,
The ID of the node provider.
The account where rewards earned from providing nodes will be sent.
Proposal action to call the "open" method of an SNS token swap canister.
Used in:
The ID of the canister where the command will be sent (assuming that the proposal is adopted, of course).
Various limits on the swap.
The amount that the community fund will collectively spend in maturity on the swap.
A proposal is the immutable input of a proposal submission. This contains all the information from the original proposal submission. Making a proposal implicitly votes yes.
Used in: , , ,
Must be present (enforced at the application layer, not by PB). A brief description of what the proposal does. Size in bytes must be in the interval [5, 256].
Text providing a short description of the proposal, composed using a maximum of 30000 bytes of characters.
The Web address of additional content required to evaluate the proposal, specified using HTTPS. For example, the address might describe content supporting the assignment of a DCID (data center id) to a new data center. The URL string must not be longer than 2000 bytes.
This section describes the action that the proposal proposes to take.
This type of proposal calls a major function on a specified target neuron. Only the followees of the target neuron (on the topic [Topic::ManageNeuron]) may vote on these proposals, which effectively provides the followees with control over the target neuron. This can provide a convenient and highly secure means for a team of individuals to manage an important neuron. For example, a neuron might hold a large balance, or belong to an organization of high repute, and be publicized so that many other neurons can follow its vote. In both cases, managing the private key of the principal securely could be problematic (either a single copy is held, which is very insecure and provides for a single party to take control, or a group of individuals must divide responsibility, for example using threshold cryptography, which is complex and time consuming). To address this, using this proposal type, the important neuron can be configured to follow the neurons controlled by individual members of a team. Now they can submit proposals to make the important neuron perform actions, which are adopted if and only if a majority of them vote to adopt. Nearly any command on the target neuron can be executed, including commands that change the follow rules, allowing the set of team members to be dynamic. Only the final step of dissolving the neuron once its dissolve delay reaches zero cannot be performed using this type of proposal (since this would allow control/“ownership” over the locked balances to be transferred). To prevent a neuron falling under the malign control of the principal’s private key by accident, the private key can be destroyed so that the neuron can only be controlled by its followees, although this makes it impossible to subsequently unlock the balance.
Propose a change to some network parameters of network economics.
See [Motion]
A update affecting something outside of the Governance canister.
Approve Genesis KYC for a given list of principals.
Add/remove NodeProvider from the list of NodeProviders
Reward a NodeProvider
Set the default following
Reward multiple NodeProvider
Register Known Neuron
Obsolete. Superseded by CreateServiceNervousSystem. Kept for Candid compatibility.
Call the open method on an SNS swap canister. This is still supported but will soon be superseded by CreateServiceNervousSystem.
Create a new SNS.
A ProposalData contains everything related to an open proposal: the proposal itself (immutable), as well as mutable data such as ballots.
Used in:
This is stored here temporarily. It is also stored on the map that contains proposals. Immutable: The unique id for this proposal.
Immutable: The ID of the neuron that made this proposal.
Immutable: The amount of ICP in E8s to be charged to the proposer if the proposal is rejected.
Immutable: The proposal originally submitted.
Immutable: The timestamp, in seconds from the Unix epoch, when this proposal was made.
Map neuron ID to to the neuron's vote and voting power. Only present for as long as the proposal is not yet settled with respect to rewards.
Latest tally. Recomputed for every vote. Even after the proposal has been decided, the latest_tally will still be updated based on the recent vote, until the voting deadline.
If specified: the timestamp when this proposal was adopted or rejected. If not specified, this proposal is still 'open'.
When an adopted proposal has been executed, this is set to current timestamp.
When an adopted proposal has failed to be executed, this is set to the current timestamp.
When an adopted proposal has failed to executed, this is set the reason for the failure.
The reward event round at which rewards for votes on this proposal was distributed. Rounds do not have to be consecutive. Rounds start at one: a value of zero indicates that no reward event taking this proposal into consideration happened yet. This field matches field day_after_genesis in RewardEvent.
Wait-for-quiet state that needs to be saved in stable memory.
This is populated when an OpenSnsTokenSwap proposal is first made.
This is populated when OpenSnsTokenSwap is executed. It is used when our conclude_community_fund_participation Candid method is called to either mint ICP, or restore CF neuron maturity.
This gets set to one of the terminal values (i.e. Committed or Aborted) when the swap canister calls our conclude_community_fund_participation Candid method. Initially, it is set to Open, because swap is supposed to enter that state when we call its open Candid method, which is the main operation in the execution of an OpenSnsTokenSwap proposal.
This structure contains data for settling the Neurons' Fund participation at the end of a swap. TODO[NNS1-2566]: deprecate `original_total_community_fund_maturity_e8s_equivalent` and `cf_participants` and use only this field for managing the Neurons' Fund swap participation.
This is a view of the ProposalData returned by API queries and is NOT used for storage. The ballots are restricted to those of the caller's neurons and additionally it has the computed fields, topic, status, and reward_status.
Used in:
The unique id for this proposal.
The ID of the neuron that made this proposal.
The amount of ICP in E8s to be charged to the proposer if the proposal is rejected.
The proposal originally submitted.
The timestamp, in seconds from the Unix epoch, when this proposal was made.
See [ProposalData::ballots].
See [ProposalData::latest_tally].
See [ProposalData::decided_timestamp_seconds].
See [ProposalData::executed_timestamp_seconds].
See [ProposalData::failed_timestamp_seconds].
See [ProposalData::failure_reason].
See [ProposalData::reward_event_round].
Derived - see [Topic] for more information
Derived - see [ProposalStatus] for more information
Derived - see [ProposalRewardStatus] for more information
The proposal status, with respect to reward distribution. See also ProposalStatus.
Used in: ,
The proposal still accept votes, for the purpose of vote rewards. This implies nothing on the ProposalStatus.
The proposal no longer accepts votes. It is due to settle at the next reward event.
The proposal has been taken into account in a reward event.
The proposal is not eligible to be taken into account in a reward event.
The proposal status, with respect to decision making and execution. See also ProposalRewardStatus.
Used in: ,
A decision (adopt/reject) has yet to be made.
The proposal has been rejected.
The proposal has been adopted (sometimes also called "accepted"). At this time, either execution as not yet started, or it has but the outcome is not yet known.
The proposal was adopted and successfully executed.
The proposal was adopted, but execution failed.
The summary of the restore aging event.
Used in:
The timestamp of the restore aging event.
Groups of neurons that were considered for restoring their aging.
Used in:
The neurons in this group were not pre-aging. We don't restore their aging.
The neurons in this group are dissolving or dissolved. We don't restore their aging because it's invalid for a dissolving/dissolved neuron to have age.
The neurons in this group have their stake changed. We restore them to be pre-aged.
The neurons in this group have their stake remain the same and aging changed. We restore them to be pre-aged.
The neurons in this group have their stake remain the same and aging remain the same. We restore them to be pre-aged.
Used in:
The number of neurons in this group.
The previous total stake of neurons in this group when the aging was reset.
The current total stake of neurons in this group when considering to restore aging.
A reward event is an event at which neuron maturity is increased
Used in:
This reward event correspond to a time interval that ends at the end of genesis + day_after_genesis days. For instance: when this is 0, this is for a period that ends at genesis -- there can never be a reward for this. When this is 1, this is for the first day after genesis. On rare occasions, the reward event may cover several days ending at genesis + day_after_genesis days, when it was not possible to proceed to a reward event for a while. This makes that day_after_genesis does not have to be consecutive.
The timestamp at which this reward event took place, in seconds since the unix epoch. This does not match the date taken into account for reward computation, which should always be an integer number of days after genesis.
The list of proposals that were taken into account during this reward event.
The total amount of reward that was distributed during this reward event. The unit is "e8s equivalent" to insist that, while this quantity is on the same scale as ICPs, maturity is not directly convertible to ICPs: conversion requires a minting event to spawn a new neuron.
The total amount of rewards that was available during the reward event.
The amount of rewards that was available during the last round included in this event. This will only be different from `total_available_e8s_equivalent` if there were "rollover rounds" included in this event.
In some cases, the rewards that would have been distributed in one round are "rolled over" into the next reward event. This field keeps track of how many rounds have passed since the last time rewards were distributed (rather than being rolled over). For the genesis reward event, this field will be zero. In normal operation, this field will almost always be 1. There are two reasons that rewards might not be distributed in a given round. 1. "Missed" rounds: there was a long period when we did calculate rewards (longer than 1 round). (I.e. distribute_rewards was not called by heartbeat for whatever reason, most likely some kind of bug.) 2. Rollover: We tried to distribute rewards, but there were no proposals settled to distribute rewards for. In both of these cases, the rewards purse rolls over into the next round.
This proposal payload is used to reward a node provider by minting ICPs directly to the node provider's ledger account, or into a new neuron created on behalf of the node provider.
Used in: , ,
The NodeProvider to reward.
The amount of e8s to mint to reward the node provider.
If this is specified, executing this proposal will create a neuron instead of directly minting ICP into the node provider's account.
If this is specified, executing this proposal will mint to the specified account.
Used in:
This message specifies how to create a new neuron on behalf of the node provider. - The controller of the new neuron is the node provider's principal. - The account is chosen at random. - The stake of the new neuron is `amount_e8s`. - `dissolve_delay_seconds` is as specified in the proto. - `kyc_verified` is set to true, as node providers are (implicitly) KYC'ed. - `not_for_profit` is set to false. - All other values are set as for other neurons: timestamp is now, following is set up per default, maturity is 0, neuron fee is 0.
Used in:
Used in:
If true, reward Node Providers with the rewards returned by the Registry's get_node_providers_monthly_xdr_rewards method
Changes the default followees to match the one provided. This completely replaces the default followees so entries for all Topics (except ManageNeuron) must be provided on each proposal.
Used in:
Obsolete. Superseded by OpenSnsTokenSwap.
Used in:
The swap canister to send the request to.
Arguments that get sent to the swap canister when its set_open_time_window Candid method is called.
TODO(NNS1-1589): Until the Jira ticket gets solved, changes here need to be manually propagated to (sns) swap.proto. This message is obsolete; please use SettleNeuronsFundParticipation instead.
The caller's principal ID must match the value in the target_swap_canister_id field in the proposal (more precisely, in the OpenSnsTokenSwap).
Each of the possibilities here corresponds to one of two ways that a swap can terminate. See also sns_swap_pb::Lifecycle::is_terminal.
When this happens, maturity needs to be restored to CF neurons. The amounts to be refunded can be found in the ProposalData's cf_participants field.
Used in:
(message has no fields)
When this happens, ICP needs to be minted, and sent to the SNS governance canister's main account on the ICP Ledger. As with Aborted, the amount of ICP that needs to be minted can be deduced from the ProposalData's cf_participants field.
Used in:
This is where the minted ICP will be sent. In principal, this could be fetched using the swap canister's get_state method.
Total contribution amount from direct swap participants.
Total contribution amount from the Neuron's Fund. TODO[NNS1-2570]: Ensure this field is set.
Request to settle the Neurons' Fund participation in this SNS Swap. When a swap ends, the Swap canister notifies the Neurons' Fund of the swap's ultimate result, which can be either `Committed` or `Aborted`. Note that currently, the Neurons' Fund is managed by the NNS Governance canister. * If the result is `Committed`: - Neurons' Fund computes the "effective" participation amount for each of its neurons (as per the Matched Funding rules). This computation is based on the total direct participation amount, which is thus a field of `Committed`. - Neurons' Fund converts the "effective" amount of maturity into ICP by: - Requesting the ICP Ledger to mint an appropriate amount of ICP tokens and sending them to the SNS treasury. - Refunding whatever maturity is left over (the maximum possible maturity is reserved by the Neurons' Fund before the swap begins). - Neurons' Fund returns the Neurons' Fund participants back to the Swap canister (see SettleNeuronsFundParticipationResponse). - The Swap canister then creates SNS neurons for the Neurons' Fund participants. * If the result is Aborted, the Neurons' Fund is refunded for all maturity reserved for this SNS. This design assumes trust between the Neurons' Fund and the SNS Swap canisters. In the one hand, the Swap trusts that the Neurons' Fund sends the correct amount of ICP to the SNS treasury, and that the Neurons' Fund allocates its participants following the Matched Funding rules. On the other hand, the Neurons' Fund trusts that the Swap will indeed create appropriate SNS neurons for the Neurons' Fund participants. The justification for this trust assumption is as follows. The Neurons' Fund can be trusted as it is controlled by the NNS. The SNS Swap can be trusted as it is (1) deployed by SNS-W, which is also part of the NNS and (2) upgraded via an NNS proposal (unlike all other SNS canisters). This request may be submitted only by the Swap canister of an SNS instance created by a CreateServiceNervousSystem proposal. TODO(NNS1-1589): Until the Jira ticket gets solved, changes here need to be manually propagated to (sns) swap.proto.
Proposal ID of the CreateServiceNervousSystem proposal that created this SNS instance.
Each of the possibilities here corresponds to one of two ways that a swap can terminate. See also sns_swap_pb::Lifecycle::is_terminal.
When this happens, all priorly reserved maturity for this SNS instance needs to be restored to the Neurons' Fund neurons.
Used in:
(message has no fields)
When this happens, the NNS Governance needs to do several things: (1) Compute the effective amount of ICP per neuron of the Neurons' Fund as a function of `total_direct_participation_icp_e8s`. The overall Neurons' Fund participation should equal `total_neurons_fund_contribution_icp_e8s`. (2) Mint (via the ICP Ledger) and sent to the SNS governance the amount of `total_neurons_fund_contribution_icp_e8s`. (3) Respond to this request with `SettleNeuronsFundParticipationResponse`, providing the set of `NeuronsFundParticipant`s with the effective amount of ICP per neuron, as computed in step (1). (4) Refund each neuron of the Neurons' Fund with (reserved - effective) amount of ICP. Effective amounts depend on `total_direct_participation_icp_e8s` and the participation limits of a particular SNS instance, namely, each participation must be between `min_participant_icp_e8s` and `max_participant_icp_e8s`. - If a neuron of the Neurons' Fund has less than `min_participant_icp_e8s` worth of maturity, then it is ineligible to participate. - If a neuron of the Neurons' Fund has more than `max_participant_icp_e8s` worth of maturity, then its participation amount is limited to `max_participant_icp_e8s`. Reserved amounts are computed as the minimal upper bound on the effective amounts, i.e., when the value `total_direct_participation_icp_e8s` reaches its theoretical maximum.
Used in:
This is where the minted ICP will be sent.
Total amount of participation from direct swap participants.
Total amount of participation from the Neurons' Fund. TODO[NNS1-2570]: Ensure this field is set.
Handling the Neurons' Fund and transferring some of its maturity to an SNS treasury is thus the responsibility of the NNS Governance. When a swap succeeds, a Swap canister should send a `settle_neurons_fund_participation` request to the NNS Governance, specifying its `result` field as `committed`. The NNS Governance then computes the ultimate distribution of maturity in the Neurons' Fund. However, this distribution also needs to be made available to the SNS Swap that will use this information to create SNS neurons of an appropriate size for each Neurons' Fund (as well as direct) participant. That is why in the `committed` case, the NNS Governance should populate the `neurons_fund_participants` field, while in the `aborted` case it should be empty. TODO(NNS1-1589): Until the Jira ticket gets solved, changes here need to be manually propagated to (sns) swap.proto.
Represents one NNS neuron from the Neurons' Fund participating in this swap.
Used in:
The NNS neuron ID of the participating neuron.
The amount of Neurons' Fund participation associated with this neuron.
The principal that can vote on behalf of this neuron.
Whether the amount maturity amount of Neurons' Fund participation associated with this neuron has been capped to reflect the maximum participation amount for this SNS swap.
Request was completed successfully.
Used in:
Additional information about the SNS that's being "swapped". This data is fetched from other canisters. Currently, the swap canister itself, and the root canister are queried, but additional canisters could be queried later. In particular, the ID of the root canister is discovered via the swap canister. (See Governance::fetch_swap_background_information for how this is compiled.)
Obsolete. Superseded by newer fields.
Used in:
Used in:
A canister can be stopped by calling stop_canister. The effect of stop_canister can be undone by calling start_canister. Stopping is an intermediate state where new method calls are rejected, but in-flight method calls are allowed to be fully serviced.
Used in:
Transcribed from sns/root.
Used in:
Absolute constraints of this swap needed that the Neurons' Fund need to be aware of. The fields correspond to those in Swap's `Init` message.
Used in:
A tally of votes.
Used in: ,
When was this tally made
Yeses, in voting power unit.
Noes, in voting power unit.
Total voting power unit of eligible neurons. Should always be greater than or equal to yes + no.
Proposal types are organized into topics. Neurons can automatically vote based on following other neurons, and these follow relationships are defined per topic.
Used in: , ,
The `Unspecified` topic is used as a fallback when following. That is, if no followees are specified for a given topic, the followees for this topic are used instead.
A special topic by means of which a neuron can be managed by the followees for this topic (in this case, there is no fallback to 'unspecified'). Votes on this topic are not included in the voting history of the neuron (cf., `recent_ballots` in `Neuron`). For proposals on this topic, only followees on the 'neuron management' topic of the neuron that the proposals pertains to are allowed to vote. As the set of eligible voters on this topic is restricted, proposals on this topic have a *short voting period*.
All proposals that provide “real time” information about the value of ICP, as measured by an IMF SDR, which allows the NNS to convert ICP to cycles (which power computation) at a rate which keeps their real world cost constant. Votes on this topic are not included in the voting history of the neuron (cf., `recent_ballots` in `Neuron`). Proposals on this topic have a *short voting period* due to their frequency.
All proposals that administer network economics, for example, determining what rewards should be paid to node operators.
All proposals that administer governance, for example to freeze malicious canisters that are harming the network.
All proposals that administer node machines, including, but not limited to, upgrading or configuring the OS, upgrading or configuring the virtual machine framework and upgrading or configuring the node replica software.
All proposals that administer network participants, for example, granting and revoking DCIDs (data center identities) or NOIDs (node operator identities).
All proposals that administer network subnets, for example creating new subnets, adding and removing subnet nodes, and splitting subnets.
Installing and upgrading “system” canisters that belong to the network. For example, upgrading the NNS.
Proposals that update KYC information for regulatory purposes, for example during the initial Genesis distribution of ICP in the form of neurons.
Topic for proposals to reward node providers.
IC OS upgrade proposals ----------------------- ICP runs on a distributed network of nodes grouped into subnets. Each node runs a stack of operating systems, including HostOS (runs on bare metal) and GuestOS (runs inside HostOS; contains, e.g., the ICP replica process). HostOS and GuestOS are distributed via separate disk images. The umbrella term IC OS refers to the whole stack. The IC OS upgrade process involves two phases, where the first phase is the election of a new IC OS version and the second phase is the deployment of a previously elected IC OS version on all nodes of a subnet or on some number of nodes (including nodes comprising subnets and unassigned nodes). A special case is for API boundary nodes, special nodes that route API requests to a replica of the right subnet. API boundary nodes run a different process than the replica, but their executable is distributed via the same disk image as GuestOS. Therefore, electing a new GuestOS version also results in a new version of boundary node software being elected. Proposals handling the deployment of IC OS to some nodes. It is possible to deploy only the versions of IC OS that are in the set of elected IC OS versions.
Proposals for changing the set of elected IC OS versions.
Proposals related to SNS and Community Fund.
Proposals related to the management of API Boundary Nodes
Used to update node provider records There is no need to specify a node provider Principal ID here, as Governance uses the Principal ID of the caller as the Node Provider Principal ID.
The account where rewards earned from providing nodes will be sent.
The types of votes the Neuron can issue.
Used in: , ,
This exists because proto3 defaults to the 0 value on enums. This is not a valid choice, i.e., a vote with this choice will not be counted.
Vote for the proposal to be adopted.
Vote for the proposal to be rejected.
Stores data relevant to the "wait for quiet" implementation.
Used in:
Used in:
/ Time at which this rate has been fetched.
/ One ICP is worth this number of 1/10,000ths parts of an XDR.