Overview
Staking is integral to the Arcium Network, activating Arx Nodes and unlocking their computational resources. Without sufficient stake, Nodes are ineligible to perform work, ensuring that computational resources are securely allocated to trusted and reliable Nodes.
Operation Requirements and the Node Hardware Claim
To activate an Arx Node, Node Operators must meet the Network constant referred to as MINIMUM_SELF_DELEGATION_PER_1000_CLUSTERS, representing the minimum self-stake needed for the Node to join up to 1000 Clusters.
Additionally, when activating, a Node Operator also makes a claim regarding their Node's maximum possible computational load capacity, called the Node Hardware Claim. This claim must be backed up by a corresponding amount of delegated stake in order to make the Node's hardware eligible to perform work for the Network.
Activation of the Node Hardware Claim
To quantify and calculate stake activation of Arx Nodes' hardware, a Network-wide constant ratio exists between the amount of stake (both 3rd-party and self-stake) required to attest to a given hardware claim.
This ratio is named REQUIRED_STAKE_PER_UNIT_OF_CU_LOAD_CAPACITY.
This ratio links the amount of stake to the Node's self-claimed hardware specification.
If a Node's total delegation falls short of this requirement, it will only be assigned computation jobs proportional to its actual stake, rather than its maximum claimed capacity.
Conversely, if delegations exceed the necessary stake, Node Operators must upgrade their hardware to justify the increased stake. Otherwise, rewards for the surplus delegation are subject to a sub-linear reduction, discouraging over-delegation beyond the hardware's capabilities.
The Arcium Network staking approach discourages centralization, by creating a near-linear relationship between the hardware that an Arx Node provides to the Network and the amount of stake required to activate it.
Delegation Flow and Rewards
Once activated, Arx Nodes can receive additional stake delegations from both Node Operators and Third-Party Delegators. All stake delegations unlock more computational capacity, allowing the Node to process greater workloads—up to the amount corresponding to the Hardware Claim.
Delegation Mechanics
Stake becomes active at the beginning of the next epoch after it is delegated. Once active, Nodes receive an equal share of the rewards from the computations executed in the Clusters that they are members of, while Delegators earn a pro-rata share of the rewards received by the Node they are delegated to (with percentage fees subtracted to compensate Node Operators for running the infrastructure).
Delegators' rewards auto-compound but they can always undelegate them which unlocks them at the start of the next epoch.
Epoch-Based Rewards
Rewards are allocated at the end of each epoch. If Delegators choose to withdraw their stake or switch their delegation to a different Node (a process known as redelegation), it triggers a one-epoch cooldown period. During this time, the stake remains locked before being reassigned or withdrawn.
Example Workflow
To illustrate how the delegation process works:
A Node Operator self-delegates the minimum required stake to activate the Arx Node.
Third-Party Delegators contribute additional stake to increase the Node’s computational capacity.
Once active, the Node executes computations, and the rewards that it receives are distributed among its Delegators based on the proportions of their stake delegated to the Node, minus a fee collected by the Node Operator.
Delegators can either withdraw their rewards at the end of the epoch or allow them to compound for future rewards automatically.
Key Points include:
Nodes with insufficient stake are ineligible to process computations.
Delegation beyond the stake proportional to the Node's hardware claim cannot increase capacity unless the computational capacity (and claim) of the Node is increased.
A near-linear stake-to-capacity relationship discourages over-delegation and promotes decentralization.
Last updated