$FLT: Staking for Compute Resources
Fluence has architected its protocol to enable the largest, most performant and widespread computing network in the world. To be successful, such a network requires an economic model to provide trust that works on a global scale, is resistant to attacks and does not rely on centralized actors. Resources provided to the network should be easily discoverable, provably accounted, efficiently utilized, and fairly compensated, while resource consumers should receive the best service at a significantly lower price than comparable cloud service platforms. The network should be resistant to misbehavior and dishonest actors, ensuring they are penalized for void, incomplete, or fake work.
Because Fluence is permissionless and anyone can provide computing resources, trustless assumptions should be stronger than the trust in centralized systems that rely on brand reputation.
Fluence Model
Fluence’ economics model is powered by the FLT token, which secures both compute resources (hardware servers), and actual compute jobs that these resources run. Trust in cloud compute companies is replaced by cryptographic proofs and incentive systems. Also, while many web3 protocols use volatile tokens for payments for resources (compute), the Fluence token is primarily used to provide trust via staking and gas payments, while compute customers pay for compute services in stablecoins.
There are three main roles in the network:
- Compute providers who earn FLT rewards for adding compute resources to the network and and earn payments for providing resources to customers
- Customers / Developers consume compute by paying in stablecoin (USDC)
- Delegators / Token holders who stake on providers’ hardware and earn staking rewards
How Staking Works
Securing compute capacity and jobs
Every compute resource and compute job is secured with FLT stake. When providers add resources, they submit Capacity Commitments that specify the amount of CPU cores provided and the rental price for these cores. Every CPU core must receive FLT stake on it to be activated.
Activated hardware generates Proofs of Capacity, which are validated on the Fluence chain. For submitting required amounts of proofs, providers and stake delegators are rewarded with FLT. If insufficient proofs are submitted - stake is slashed. This mechanism guarantees that the hardware is connected, available, and performant consistent with the compute provider’s representation.
Stake required is defined by protocol and denominated in USD equivalent. The protocol target is $200 of FLT tokens to be staked per each core added (disclaimer: for initial stage of network operation stake targets are set to lower values). So, for example, typical 64-core server CPU would need $200 * 64 = $12,800 stake in FLT.
This stake is locked for the duration of the capacity commitment which ranges from a minimum of 1 month to several years. When the capacity commitment expires, the stake is released and new stake is required for a subsequent commitment. The USD value of the stake may fluctuate during the commitment period as the value of FLT moves, but only upon a new commitment will the $200 per core price be recalibrated in FLT. It isn’t possible to end a capacity commitment early without suffering a slashing penalty.
These CPU cores secured by stake are called Compute Units and they are allocated to run customer jobs whenever necessary. When the Compute Units are allocated to a job, the stake secures the correctness of the job execution and can be slashed.
Delegation / Staking
Providers do not need to provide stake themselves – they set up and operate the hardware. For every Capacity Commitment, a provider may set a delegation rate from 0 to 100%, which defines the share of rewards for the delegator who provides the stake. Stakers will have a choice of providers and offers, and may diversify their stake across a variety of providers.
Rewards
The protocol optimizes for: ~$10 revenue per Compute Unit per month for target network capacity. Every CPU core added to the network should earn this amount on average in FLT rewards, until the network reaches its economically sustainable capacity. If more resources than current maximum are added, the FLT reward pool is distributed among more resources, reducing average revenue per Compute Unit, attracting only the most efficient hardware operators.
In every epoch (1 day), the FLT pool is distributed among all resources that submitted the minimum Proofs of Capacity. The FLT pool adjusts by a maximum of 10% per day to help keep a constant USD reward value. For example, if yesterday Compute Units earned $0.4 in FLT each, the protocol will reduce the reward pool for today to meet the $0.33 per core per day target ($10 per month).
When a Compute Unit is switched from Proof of Capacity to a customer job, the Compute Unit earns USDC, and the revenue is split between the provider and delegator in the same proportion as the existing Capacity Commitment.
Vesting of Rewards
Rewards are not distributed to providers and delegators immediately. Newly awarded FLT at each epoch vests (daily) over the following 6 months, dependent on the provider continuing to provide compute services. This vesting incentivizes providers to stay and continue contributing resources to the network.
Stake Slashing
If a provider fails to submit the required amount of Proof of Capacity for every committed CPU core, this core stake gets slashed by 0.3% every next epoch until it reaches the maximum of 1.5% slashing ratio and this commitment stops and the stake is returned to the delegator. All unvested FLT rewards for failed commitment are discarded, so providers are incentivized to maintain reliable operations. For later stages of the network, slashing rates may be significantly higher as the network matures to build trust and attract useful work.
Disclaimer: for the initial stage of network operation stake slashing is turned off. Capacity Commitments may fail if they do not receive enough proofs, but stake is returned to the delegator entirely.
Notes on Pricing and Locked Capital
Fluence protocol incentivizes participants to look for equilibrium in terms of optimal amount of CPU cores in the network based on cost-efficiency, FLT price, cost of capital locked in unvested rewards. Overall, the more CPU cores added, the more stake is required. So the network capacity growth creates strong demand for more FLT stake to secure it.
At launch, Fluence had 250,000 CPU cores under signed LOIs (Letters of intent) and our waitlist has grown by an additional 600,000 cores. Onboarding all this hardware will require $170 million stake in FLT. To put this capacity in perspective, AWS has over a hundred data centers and just one of their data centers has 50,000 CPUs (over 3 million cores) which, when Fluence reaches that scale, would require $600 million of FLT staked. The total AWS network has approximately 2 million CPUs, or 128 million cores, with Google and Microsoft each operating on a similar scale.
Additionally, new customers who want to utilize the platform by running compute jobs bring stablecoin revenue, which goes to both providers and delegators instead of FLT rewards for Useful Compute Payments. Because providers set their prices for customer jobs, they will generally expect to earn more from useful compute jobs than from capacity rewards. However, capacity rewards vest over six months and some compute providers may be comfortable accepting a lower price for useful work which is not subject to a lock up. Other providers may value the FLT reward more highly than USD payments and so require a higher USDC payment for useful work. Overall, we expect pricing of compute on Fluence to be in a range but the pricing floor to be below the $10 monthly FLT capacity reward.
Staking Availability
Staking is limited by the quantity of hardware on the network and because Fluence is rolling out the platform progressively, there may be periods with no hardware available for staking.
Please follow our updates as we add more providers, onboard additional hardware, and increase the availability for adding stake to earn rewards.