Fluence is most usefully treated as a decentralized cloud marketplace and provider-staking coordination layer, not just as a generic decentralized compute slogan.
The important analytical surface is the split between customer-facing hosted cloud interfaces, provider-side infrastructure/control tooling, and FLT-based staking/governance.
A historical Fluence RFC overview exists, but current product framing is much more cloud-marketplace and infrastructure-operations oriented.
No current standalone whitepaper was located during this pass.
Official provider docs explaining hardware/network requirements and stating that the Provider Application is the primary provider tool and is currently centralized and hosted by the Fluence team.
First-party GitHub profile README summarizing the current network as an Arbitrum Orbit L2-anchored decentralized compute network with USDC payments and FLT staking/governance.
Historical first-party protocol overview showing an earlier peer-to-peer distributed-computing framing that is useful as background but does not cleanly match the present cloud-marketplace product surface.
Key takeaways captured for corpus
Fluence’s current mechanism is a marketplace for independently operated compute capacity coordinated through staking and governance rather than a simple peer-to-peer compute protocol.
The network’s practical control surface includes hosted customer and provider interfaces, especially because the provider application is explicitly centralized today.
Supply-side decentralization is shaped by professional infrastructure requirements, which narrows the real operator set toward data-center-class providers.
USDC-for-consumption and FLT-for-staking/governance is an important design split because it separates billing from collateralized coordination.
Fluence is a strong comparison class for Aleph Cloud, Bacalhau, and Lilypad when asking whether a system is selling cloud capacity, orchestration, or verifiable decentralized execution.