Cluster Migration

Forced Migration

The costs of migrations due to slashing (e.g. extended downtime, repeated cheating, etc.) as well as migrations due to drops in stake (see Rapid Drops in Stake below) are spread proportionally across all of an Arx node's stakeholders (the node operator's self-delegation and all 3rd-party delegations) since all of the Arx node's delegators take collective responsibility for evaluating the node operator as well as monitoring the level of stake delegated to the Arx node. Since migration costs will typically be quite small, in practice each of the node's stakeholders will likely only pay a minor amount towards a forced migration — likely appearing as only a minor reduction in rewards revenue for the epoch where the forced migration occurs.

Planned Migration

In the event that an Arx node opts to shut down, in order to avoid slashing penalties, it must announce its intention to exit the network a full epoch in advance. Additionally, the costs associated with migrating to a new cluster node set are subtracted from the Arx node's self-delegation, before the self-delegation is released. The MINIMUM_SELF_DELEGATION_PER_1000_CLUSTERS network constant (see the node Operation Incentives section) is used to enforce that each Arx node can always cover migration costs of the Clusters that it is a member of, thus an Arx node's self-delegation is always sufficiently large enough to cover the costs of the total number of Cluster migrations that it could potentially need to pay for when shutting down.

The new Cluster (resulting from the migration) will be constructed of Arx nodes based on the Cluster's configuration parameters, namely if it has other available Arx nodes defined in the Node Priority List or if it has the Automatic Alternative Node Selection mechanism enabled (see the Cluster Formation section).

Note that when a Cluster gets migrated, scheduled computations could potentially be cancelled if the new Cluster set has a different maximal computational load capacity (see the Self-Claimed Hardware Specification section) which is insufficient for any of the scheduled computations — however, this is the Computation Customer's responsibility since when creating a Cluster the customer must decide the specs of all nodes, including backup nodes.

Rapid Drops in Stake

If an Arx node's eligible hardware goes down due to a decrease in the stake delegated to that particular node (see the Self-Claimed Hardware Specification section), and as a result the Arx node then falls below the required computation capacity limit of one of the Clusters that the node is a member of (see the Cluster Formation section for more on how Computation Customers set this computation capacity limit when creating Clusters), then the Arx node is dropped from the Cluster and a forced migration occurs (see the Forced Migration section above).

The computation capacity limits for the Clusters that an Arx node is in are publicly available and thus monitoring tools will exist for node stakeholders to stay updated regarding undelegations and redelegations that could cause forced migrations. Therefore node stakeholders have the collective responsibility to actively monitor these changes in total stake delegation to their Arx node and take action in the current epoch (before the changes take effect) when needed to avoid incurring minor costs associated with forced migrations.