Pricing
Last updated
Last updated
The execution cost associated with a Computation is deterministic, meaning that it is always possible to calculate in advance the amount of computational work required to run a given Computation. On the Arcium Network, the performance of Computation execution is always set to an economically viable level for nodes, via "base pricing". Computation Customers may optionally set a priority fee on top of a Computation's base price which enables faster (more prioritized) execution of the Computation.
Execution costs must always be set to a minimally economically viable level since non-participation of Arx nodes is impermissible. Set by the protocol, base pricing serves as a baseline to cover Arx node operation costs in all market conditions. The base price itself is a unit rate, measured in CUs, that's applied to Computations — so differently sized Computations have different base costs resulting from the same base price.
Without base pricing, in the event that, at some point, insufficient computation-side demand exists on the Network, Arx nodes could be under-compensated for Computations. Unlike in a typical free-market-style decentralized network (e.g. Solana, typical DPoS chains, etc.), Arx nodes cannot opt to not participate in the case that demand decreases (and thereby fees decrease), since this would be classified as non-participation and punished via slashing. Furthermore, the cost to enter and exit the Arcium Network is substantial — due to lockup times as well as the requirement to pay for the migration of Clusters from the self-delegation deposit. In order to ensure sufficient compensation for nodes to cover their operational expenses in all market conditions (high or low demand), a central-planning-style approach is applied to base pricing.
The price of a CU is set before a new epoch starts. Node Operators cast stake-weighted votes (the stake being their self-delegations) on how much the price of a CU should be in the next epoch. Node Operators may submit their votes for the next epoch's price at any point during the current epoch. Abstaining from the vote equates to voting for the current price, thus voting for no price change. The price of a CU for the next epoch is the stake-weighted average price, with abstaining stake counted as voting for the existing price.
Only self-delegated Node Operator stake is able to participate in this once-per-epoch vote. Furthermore, only a Node Operator's self-delegated stake that is less than the amount of stake required to activate all of the Node's hardware is eligible to vote — if a Node Operator's self-delegated stake is greater than the total amount of stake required to activate all of the Node's hardware, ignoring 3rd-party stake, then only the portion of the Node Operator's self-delegation that is under this threshold would be counted towards the base price vote. For more on the stake activation of an Arx nodes hardware, see the Self-Claimed Hardware Specification section.
Third-party (non-node) delegators are not permitted to participate in the voting process, since, from a Game Theoretic perspective, only Node Operators themselves have a genuine direct interest in the price being set accurately — 3rd-party delegators do not directly pay for infrastructure (only indirectly via fees changed by Arx nodes that they delegate to) and could therefore game the system for short-term benefit by setting a higher base price. Node Operators have a direct interest in setting a sustainable and competitive price, since, if the price is too high, Computation volume (and therefore revenue) will be reduced, while if the price is too low, direct revenue per Computation will be reduced, and in either case it may become unsustainable to operate Arx nodes. A sustainably balanced base-price is freely found via plutocratic voting.
Lock-up periods force Arx nodes to be long-term thinking concerning their Computation revenue — thus short-term operational cost volatility or changes in job volume will not distract them significantly. Additionally, slashing penalties for non-participation, as well as penalties associated with exiting the Network (see the Cluster Migration section), dissuade Arx nodes from non-participation or leaving, even in the case that market volatility leads to temporary (until the next epoch) under-compensation for computational work.
Arx nodes will conduct base price voting via a separate subkey in order to mitigate key management risk, since a node's base voting key will often be stored hot (on the node). Arx nodes may opt to run bespoke internal automated voting scripts connected to their own external pricing oracles.
Arx nodes' Computation revenue is the combination of customer-defined priority fees and base cost revenue (see the Base Pricing section). Varying priority fee values create unique fee markets, as free-market supply and demand control the premiums required for faster Computation execution times. Siloed fee markets associated with unions of clusters emerge, since Computations are only competing for execution priority with other Computations sharing the same Cluster, as well as with Computations in other Clusters sharing any of the same Nodes, and so on, recursively — Nodes that are in multiple Clusters join fee markets together since each node has a limited amount of computational resources available at one time.
The Arcium Network's on-chain active mempool is segregated such that all Computations currently in the active mempool are organized into priority queues based on siloed unions of Clusters associated with the Computations. The dependent mempool does not have a priority-based system and Computations simply wait in it until they have no dependencies still in the active mempool. In practice, there may be moments where all Clusters on the Network are part of the same union (if computational volume is high and many interconnected Clusters are executing Computations concurrently), however this mechanism ensures that when fee markets can be siloed, or broken-down into smaller fee markets, they are. See the On-Chain Mempools section for more on the mempool design.
If a Computation Customer would like to use all of the resources available in a given Cluster for one (likely very large) Computation immediately (waiting no longer than the completion of any currently in-progress Computations), then the customer must set a priority fee that is higher than those of all other Computations in the recursive union of Clusters with an overlapping Arx node-set. Furthermore, priority fees alone are used to determine Computation execution ordering, so, for example, if one Arx node in a Cluster is already at capacity (with higher priority Computations, or because it is not able to use all of its available hardware due to having a disproportionately small amount of stake, see the Staking section), then other Computations simply must wait for execution.
