From 7007747c51170652e600dd37be382248818844ce Mon Sep 17 00:00:00 2001 From: Shivashish Yadav <168800321+Shivashish-Spheron@users.noreply.github.com> Date: Thu, 2 Jan 2025 16:55:43 +0530 Subject: [PATCH] Changed ticker name (#228) Change ticket name from $SPHN to $SPON --- pages/core-concepts/payment-system.mdx | 18 +++++++++--------- pages/core-concepts/providers.mdx | 12 ++++++------ pages/fizz/reward-details.mdx | 2 +- pages/providers/reward-details.mdx | 2 +- 4 files changed, 17 insertions(+), 17 deletions(-) diff --git a/pages/core-concepts/payment-system.mdx b/pages/core-concepts/payment-system.mdx index 3e39fa51..87761c74 100644 --- a/pages/core-concepts/payment-system.mdx +++ b/pages/core-concepts/payment-system.mdx @@ -9,7 +9,7 @@ Spheron Network introduces an advanced Payment System, underpinned by a token-ba This section delves into the mechanisms and structures of the payment system, highlighting its role in addressing inefficiencies within the current market and ensuring that providers are appropriately rewarded for their contributions. ## Introduction to the Token-Based Economy -The Payment System in this network is based on a token economy, where any token, including $SPHN tokens, can be used as a medium of exchange. This innovative approach is designed to make transactions within the network smoother and easier, allowing for a seamless transfer of value between users and providers. It also enables a great ecosystem of contributors and opens up opportunities for foundations or other players to bring utility to the network by enabling different tokens for payment. However, any token used for payment must be approved through the token governance model. +The Payment System in this network is based on a token economy, where any token, including $SPON tokens, can be used as a medium of exchange. This innovative approach is designed to make transactions within the network smoother and easier, allowing for a seamless transfer of value between users and providers. It also enables a great ecosystem of contributors and opens up opportunities for foundations or other players to bring utility to the network by enabling different tokens for payment. However, any token used for payment must be approved through the token governance model. The foundation of this Payment System on blockchain technology ensures that all transactions are transparent, auditable, and secure, thereby increasing trust and reliability across the entire network. ## User Payment Contributions @@ -22,7 +22,7 @@ The user also needs to mention how many days/hour it wants to lock the initial f In short, the system delineates a clear and flexible mechanism for user payments: -- **Compute Escrow Wallets:** Users establish contract wallets on the blockchain, serving as compute escrows into which they deposit a minimum amount. This escrow system allows users to deposit an array of tokens, including $SPHN, offering the flexibility to manage their funds according to compute usage. +- **Compute Escrow Wallets:** Users establish contract wallets on the blockchain, serving as compute escrows into which they deposit a minimum amount. This escrow system allows users to deposit an array of tokens, including $SPON, offering the flexibility to manage their funds according to compute usage. - **Withdrawal and Fund Management:** Users have the capability to withdraw any remaining funds from the escrow wallet, ensuring they only pay for the compute resources utilized. The escrow wallet also facilitates the transfer of instance ownership and funds between users, providing a layer of versatility and control over resource allocation and usage. - **Maximum Resource Allocation Mechanism:** Upon the deposition of funds into the escrow wallet, the user's allocation of computational resources is governed by a predefined bracket system. This system systematically determines the quantity of resources allocated based on the amount of funds deposited, ensuring a structured and equitable distribution of computing power. For instance, a deposit of $15 entitles the user to a specific allocation of computational resources, encapsulated as follows: - **For standard compute allocations:** The user is entitled to access 8 CPUs, 32 GB of RAM, and 512 GB of Disk space. @@ -37,25 +37,25 @@ However, providers can withdraw the funds that have accumulated in the escrow ac Additionally, providers must contribute 20% of the total deployment payment to the Spheron Foundation. If either the provider or the user decides to cancel an ongoing lease, the remaining balances of both parties are updated. The final balances are then transferred to their respective accounts, and the lease is officially closed. Furthermore, if the locked funds become insufficient to continue supporting the active lease, the Lease Smart Contract will automatically terminate the lease. After that, the Order Smart Contract will trigger an event to shut down the server. -To encourage the use of the $SPHN token in transactions and improve the network's economic efficiency, Spheron has implemented a specific fee structure. +To encourage the use of the $SPON token in transactions and improve the network's economic efficiency, Spheron has implemented a specific fee structure. ### User Fees: -- Payments made with tokens other than $SPHN attract a 2% facilitation fee. -- Payments made with $SPHN are not subject to any fees. +- Payments made with tokens other than $SPON attract a 2% facilitation fee. +- Payments made with $SPON are not subject to any fees. ### Provider Fees: - Liveness rewards do not incur any fees. - For utilization payments: - - Payments to providers in tokens other than $SPHN or $SPHN incur a 1% fee. - - Payments made in $SPHN are free from any fees. + - Payments to providers in tokens other than $SPON or $SPON incur a 1% fee. + - Payments made in $SPON are free from any fees. -This fee strategy is designed to incentivize the utilization of the network’s native token, $SPHN, thereby reducing transaction costs for both users and providers while supporting the sustainability and growth of the network. +This fee strategy is designed to incentivize the utilization of the network’s native token, $SPON, thereby reducing transaction costs for both users and providers while supporting the sustainability and growth of the network. ### Compensation Model The compensation model for providers is meticulously structured to ensure fairness and incentivize participation: - **Utilization Payments:** Providers will receive payment in any token that the user has used to start the deployment. A provider can mention all the token it want to support and will be matched with orders which give payments in the token the provider supports. -- **Liveness Rewards:** Provider nodes are incentivized by the foundation to continue to be a part of the network if there is less utilization of the provider capacity in any Era timeframe. This will make sure the providers are not leaving the network, in case providers are not able to make enough ROI on their hardware and aren’t able to pay for their OpEx charges. The rewards will be given in $SPHN tokens, over a defined period known as an Era. +- **Liveness Rewards:** Provider nodes are incentivized by the foundation to continue to be a part of the network if there is less utilization of the provider capacity in any Era timeframe. This will make sure the providers are not leaving the network, in case providers are not able to make enough ROI on their hardware and aren’t able to pay for their OpEx charges. The rewards will be given in $SPON tokens, over a defined period known as an Era. diff --git a/pages/core-concepts/providers.mdx b/pages/core-concepts/providers.mdx index d5cd9d77..65afe075 100644 --- a/pages/core-concepts/providers.mdx +++ b/pages/core-concepts/providers.mdx @@ -19,7 +19,7 @@ For providers to join the network, they must undergo a comprehensive verificatio 1. **Provider Registration Proposal:** Providers interested in joining the network must first submit a registration proposal. This proposal includes detailed specifications about the provider’s resources, such as region, compute capacity, tier, and type of compute. 2. **Governance Review:** The governance body reviews the proposal. Upon approval, the provider’s details are registered in our Provider Registry smart contract. This registration triggers the creation of a new smart contract specific to the provider, updating the proxy address in the registry contract. -3. **Staking Requirement:** Following registration, providers are required to stake $SPHN tokens. This stake activates the provider’s bidding engine, allowing them to start submitting bids for new deployments. +3. **Staking Requirement:** Following registration, providers are required to stake $SPON tokens. This stake activates the provider’s bidding engine, allowing them to start submitting bids for new deployments. **NOTE:** Initially, to lower barriers to entry and accelerate network growth, provider registration proposals will be automatically approved. However, once the network reaches a certain level of maturity, we plan to introduce a curation process by submitting a governance proposal to disable the automatic approval mechanism. @@ -80,24 +80,24 @@ Providers can also declare their connectivity capabilities, which are crucial fo ## Incentive and Staking Mechanism -Provider Nodes are mandated to stake $SPHN tokens to participate in the network actively. This staking mechanism fulfills several critical roles: it secures a vested interest in the network's prosperity, establishes a method for penalizing misconduct, and synchronizes providers objectives with the network's overarching goals. Acts of malfeasance such as prolonged downtime, delays in system upgrades, or misuse of user deployments incur penalties, including the slashing of stakes. This robust accountability framework is instrumental in bolstering network security and maintaining participant trust. +Provider Nodes are mandated to stake $SPON tokens to participate in the network actively. This staking mechanism fulfills several critical roles: it secures a vested interest in the network's prosperity, establishes a method for penalizing misconduct, and synchronizes providers objectives with the network's overarching goals. Acts of malfeasance such as prolonged downtime, delays in system upgrades, or misuse of user deployments incur penalties, including the slashing of stakes. This robust accountability framework is instrumental in bolstering network security and maintaining participant trust. ## Reward System for Provider Nodes Provider Nodes receive compensation based on the utilization of their computational resources. This reward structure is meticulously designed to motivate the ongoing provision of resources while ensuring that contributions are equitably remunerated. Additionally, in periods of low utilization or idle period, the foundation provides liveness incentives to ensure that providers remain active within the network, thereby preventing potential exits due to insufficient returns on investment (ROI) or inability to cover operational expenses (OpEx). -## Delegation of $SPHN Tokens and Rewards +## Delegation of $SPON Tokens and Rewards -The system also enables the delegation of $SPHN tokens to Provider Nodes by token holders aiming to strengthen network security. This mechanism increases a node’s likelihood of being selected for deployments, enhancing potential earnings. Providers need to provide a commission on the rewards earned by the liveness rewards given by the foundation, which will be allocated to the stakers to provide delegation on their node. +The system also enables the delegation of $SPON tokens to Provider Nodes by token holders aiming to strengthen network security. This mechanism increases a node’s likelihood of being selected for deployments, enhancing potential earnings. Providers need to provide a commission on the rewards earned by the liveness rewards given by the foundation, which will be allocated to the stakers to provide delegation on their node. The Annual Percentage Rate (APR) for stakers is dynamic, influenced by factors such as the provider's liveness rewards during a given epoch, and the network's inflation rate. This comprehensive incentive and staking mechanism ensures that Provider Nodes are not only motivated to maintain high standards of operation but are also financially supported to sustain participation in the network, thereby aligning individual success with the network's overall health and longevity. ## Slashing Mechanism -Providers are subject to penalties for any misconduct within the network, such as user data misuse or spoofing, as identified by the Spheron Team or the broader ecosystem. In such instances, the provider's $SPHN collateral—which includes both staked and delegated funds—along with any accrued rewards, will be slashed. This measure is intended to provide restitution for any data breaches or other damages inflicted upon consumers. +Providers are subject to penalties for any misconduct within the network, such as user data misuse or spoofing, as identified by the Spheron Team or the broader ecosystem. In such instances, the provider's $SPON collateral—which includes both staked and delegated funds—along with any accrued rewards, will be slashed. This measure is intended to provide restitution for any data breaches or other damages inflicted upon consumers. -Additionally, providers face penalties for downtime during active leases. The value of the liveness reward corresponding to the duration of the downtime is deducted from the provider’s $SPHN collateral. In scenarios where there are no active leases, only the liveness rewards are slashed, sparing the main collateral. However, providers can enter Maintenance Mode during scheduled maintenance or upgrades to prevent collateral slashing during these periods. +Additionally, providers face penalties for downtime during active leases. The value of the liveness reward corresponding to the duration of the downtime is deducted from the provider’s $SPON collateral. In scenarios where there are no active leases, only the liveness rewards are slashed, sparing the main collateral. However, providers can enter Maintenance Mode during scheduled maintenance or upgrades to prevent collateral slashing during these periods. To ensure stability within the network and discourage intermittent connectivity, a cooldown period of 3 hours is imposed on earning Availability Rewards whenever a node is terminated or paused and then reconnected. This policy aims to promote consistent service availability and prevent nodes from exploiting the reward system through frequent disconnects and reconnects. diff --git a/pages/fizz/reward-details.mdx b/pages/fizz/reward-details.mdx index a8efb57d..aa13b4f6 100644 --- a/pages/fizz/reward-details.mdx +++ b/pages/fizz/reward-details.mdx @@ -9,7 +9,7 @@ To understand the rewarding system for Fizz nodes, let's first understand how re Fizz nodes are incentivized with liveness points based on the resources they contribute to the network. This approach encourages participation and helps cover operational expenses (OpEx). -- The liveness points are currently issued in FN (Fizz Node) Points until the launch of the $SPHN token. These points are non-transferable. +- The liveness points are currently issued in FN (Fizz Node) Points until the launch of the $SPON token. These points are non-transferable. - The liveness point is issued every **ERA** (which is 24 hours) and will be accumulated in the Fizz node's wallet. diff --git a/pages/providers/reward-details.mdx b/pages/providers/reward-details.mdx index 26515fea..1c2ba070 100644 --- a/pages/providers/reward-details.mdx +++ b/pages/providers/reward-details.mdx @@ -9,7 +9,7 @@ To understand rewarding system, let's first understand how reward emission works Providers are incentivized with liveness points based on tiers and multipliers to ensure they remain active within the network. This approach prevents potential exits due to insufficient returns on investment (ROI) or the inability to cover operational expenses (OpEx). -- The liveness points are currently issued in a points system until the launch of the $SPHN token. These points are non-transferable. +- The liveness points are currently issued in a points system until the launch of the $SPON token. These points are non-transferable. - The liveness reward is issued every **ERA** (which is 24 hours) and will be accumulated in the provider's wallet.