# Welcome to the Impossible Cloud Network
**Impossible Cloud Network (ICN)** is developing the foundational layer for the next-gen internet. Challenging the dominance of centralized tech giants, and unlike siloed DePIN projects, ICN introduces a fully open, multi-service, permissionless and composable cloud infrastructure that integrates storage, compute, and networking at scale. Our enterprise-grade, decentralized architecture ensures high performance, security, and censorship resistance – making web3 as seamless as web2. With real-world adoption and a pragmatic approach to decentralization, ICN is positioned to become the foundational layer of the future internet, powering the next generation of cloud services, AI agents, enterprise software, and digital ecosystems. ## Why ICN? **Unlimited Scale**: AI and cloud demand cannot be met: Traditional cloud is hitting scalability limits, preventing dynamic expansion and restricting new entrants. The internet needs infrastructure that can adapt to an evolving digital era. **Unrestricted Cloud**: Most of the internet is controlled by a handful of large players, limiting opportunities for individuals and businesses to participate in AI and cloud growth. Web3 offers greater trustlessness, data authenticity, and accessibility with ICNs performance and efficiency. **Networks without demand**: Many Web3 companies are bootstrapping networks without a viable path to profitability. ICN introduces a decentralized, market-driven approach that enables sustainable growth and economic opportunity with a network that dynamically shifts with the ecosystem. ICN decentralizes cloud infrastructure by bringing together a global network of[ Hardware Providers (HPs)](https://docs.icn.global/icn-economics/hardware-providers-hps) and[ Builders](https://docs.icn.global/icn-economics/service-providers) in a transparent and open ecosystem with a deeply enabled crypto-native core. This model allows protocols and businesses to access top-tier computing power and storage capacity without the limitations of traditional cloud services—ensuring scalable, secure, and performant solutions while maintaining composability and trust optionality for a truly modular network layer. ## How Does It Work? At the core of ICN’s network is the ICN Protocol, which acts as a bridge between hardware and software, enabling a seamless exchange of resources. HPs contribute computing resources like storage, GPUs, and CPUs, while Builders leverage this infrastructure to build and deliver cloud services. The ICNP facilitates these interactions through a decentralized coordination mechanism that prioritizes efficiency and ensures optimal resource allocation. ## The ICN Edge With ICN, projects can: * **Deploy True Web3 Protocols**: Web3-enabled infrastructure with performance and security guarantees. * **Highly performant**: Leverage a decentralized structure that ensures fair resource utilization for optimized performance. * **Ensure Security and Reliability**: Benefit from a globally distributed infrastructure with no single points of failure. ## Trust through Transparency ICN integrates[ HyperNodes](https://docs.icn.global/icn-economics/oracle-nodes) to enforce trust between HPs and Builders. These nodes continuously monitor network performance, ensuring threshold performance quality levels are upheld. HPs that fall short face penalties, incentivizing high standards and service reliability throughout the ecosystem. ## The Advantages of a Decentralized Cloud ICN’s decentralized architecture not only mitigates the shortcomings of traditional cloud systems but also paves the way for innovation and collaboration. Unlike traditional providers, where innovation is confined within in-house teams, ICN’s open platform invites developers, businesses, and hardware providers to contribute and collaborate freely. This community-driven approach accelerates the development of cutting-edge applications and services. ## Built for Global Scalability Designed to support projects of all sizes, ICN’s architecture scales exponentially across regions—without being limited by the linear growth constraints of centralized providers. This flexibility enables businesses to deploy resources anywhere in the world, seamlessly adapt to changing needs, and expand globally without being restricted by the physical footprint of a single provider. ## What does this mean for your Project? * **Access Unmatched Flexibility**: Scale resources dynamically based on demand. * **Gain Greater Transparency**: Clear, real-time visibility into resource usage and costs. * **Innovate Faster**: Leverage a platform that supports your growth, whether in AI, real-time analytics, or autonomous technologies. ## A Vision for the Future ICN is more than a cloud platform—it’s a movement toward a truly open, community-powered cloud ecosystem that can handle the most demanding workloads of tomorrow. With a focus on advanced services like GPU computing for AI and edge data processing, ICN is poised to lead the next wave of cloud evolution. This is a network designed to grow with you, leveraging the strength of a global community to ensure that the future of cloud infrastructure is shared, scalable, and accessible to all. To learn more about ICN’s vision and capabilities, you can visit [icn.global](https://icn.global) # Introduction The foundational layer for the next-generation internet. ## Introduction to the Impossible Cloud Network The Web3 ecosystem is in dire need for a native infrastructure layer to build and operate on. Current solutions are not Web3-enabled leaving many protocols and projects to settle for running on Web2 cloud and opening themselves up to key centralization risks that Web3 technologies strive to avoid. The crypto space deserves a new class of system to enable the next generation of protocols and return digital sovereignty back to the user. Impossible Cloud Network (ICN) aims to redefine the way we interact with the internet, leveraging the power of decentralized ecosystems to build an open cloud. The ICN Protocol breaks through scalability limitations of current cloud architecture and opens up limitless innovation at the application layer through a deep, permissionless hardware network. Through this approach, ICN addresses many of the inherent challenges in traditional cloud models, such as high costs, security vulnerabilities, and inefficiencies. ICN is the final stage of DePINs evolutionary path towards the open internet. Here ICN sits at the intersection of a performant Web2 system and an open, composable and transparent Web3 protocol.
* **Phase 1: Blockchain Foundations**: The roots of DePIN trace back to the early days of Bitcoin, which proved the potential of decentralized networks to secure enormous computational resources. While Bitcoin focused on safeguarding financial transactions, it set the stage for a new wave of mutual coordination networks.\\ * **Phase 2: Horizontal Networks**: The second phase saw the rise of projects like Filecoin, which harnessed spare computing capacity for decentralized storage. There was heavy focus on protocolization and building a horizontal network layer and established the foundational technologies for secure resourcing. However it remained a niche solution that could not serve the broader market.\\ * **Phase 3: Vertical Networks**: As horizontal networks struggled to be fit-for-purpose, specialized DePIN projects started to address real-world and enterprise needs, providing scalable, robust solutions that could compete with centralized alternatives. The resulting fragmentation of networks leads to capital inefficiency and lower potential interoperability of an otherwise interconnected system.\\ * **Phase 4: Hyperscaler Challengers**: Today, ICN is at the forefront of a new era of infrastructure aiming to deliver a Web3 alternative to traditional cloud providers. Offering a high-performance, cost-effective hardware network and a composable application layer, ICN is able to enable the next generation of systems and break free from scalability limits that constrain even the hyperscalers of today. With a solid foundation rooted in DePIN’s evolution, ICN is poised to lead the cloud industry into a new era of innovation and growth. ## **Why ICN?** ICN’s open cloud model offers unparalleled advantages, including: * **Scalability and Flexibility**: ICN’s decentralized structure allows the network to scale exponentially and adapt dynamically to changing demands. * **Resilient and Secure**: By decentralizing infrastructure, ICN eliminates single points of failure and mitigates the security risks inherent in centralized systems. * **Performant and efficient**: ICN streamlines resource allocation through configurable blueprints, providing a cost-effective and resource-aware platform for all users, fit-for-use and optimized for performance. ## **How to Get Involved** * [Stake and Earn](/icn-participation/stake-and-earn) * [Become a Hardware Provider](/icn-participation/contribute-hardware) * [Run a HyperNode](/icn-participation/run-a-sla-oracle-node)\ \ If you are a Web3 project looking to deploy to a crypto-native infrastructure, ICN can provide configurable hardware from our decentralized resource network, and a chosen deployment system to launch your software from, from web-app to layer 1 blockchains. Contact us to become a deployer. Whether you are a developer, business, or hardware provider, ICN provides a platform for innovation and collaboration. The network’s open and inclusive nature invites participation from a global community, enabling you to shape the future of cloud computing. \\ # ICN Protocol Overview General overview of the ICN Protocol
## The Web3 Internet ICN Protocol envisions the rearchitecture of an internet protocol that is Web3-enabled and can support the ever evolving digital ecosystems of today into the future. For the internet to remain an equitable and uncensorable resource for all, it must evolve beyond the Web2 infrastructure of the cloud. The internet services of the future should support a pluralistic suite of solutions that allow the user to decide if he wants to operate in Web2 or Web3 paradigms. An interconnected societal system should empower and enable all the important aspects of digital sovereignty and allow an open and optional ecosystem for secure, private and performant systems. ## The Application & Service Layer The Application & Service layer presents a resource-aware software deployment stack that enables the decentralized execution, operation and continued hosting of all software types. Designed to become the fabric for the deployment and hosting of a new generation of internet services, this layer will replace the existing traditional systems to unlock the innovations of an evolving digital society. Individual applications and services are what comprise an open internet ecosystem. At this layer, developers and deployers of internet services, applications, or projects can utilize ICNs abstraction layer to deploy systems on top of ICNs decentralized hardware. Builders access hardware by booking a configurable specification of resources that then is exposed for usage. These can be tailored to the specific needs of the system being deployed including storage amounts, compute modules and networking. ## The Hardware Layer The Hardware layer is a distributed, multi-lateral resource pool that is globally available and accessible. ScalerNodes are the minimum unit of resource in the hardware network and deployers and builders can compose individual units or modules of resources to create macronodes of unified capabilities. Each ScalerNode can be of any hardware class depending on the type of resource it commits to the network, and hardware providers commit these and are rewarded for providing capacity. Hardware providers are all operationally decentralized, and secured through collateral. This way we can ensure that there are no central points of trust or failure and allow an unparalleled level of composability and optionality that can respond dynamically to market needs. Hardware providers commit nodes for certain periods of time to guarantee that the network maintains certain capabilities for known durations and enables long term uptime of services while allowing flexibility for hardware providers to manage their own resource commitments versus rewards. Users can stake to ScalerNodes to earn rewards for helping to collateralize the hardware network security. Read more about the [ScalerNodes here](/network-architecture/scalernode-network). ## The HyperNode Network The HyperNode network is a decentralized guardian system that protects the integrity of the ICN Protocol. It has a key role as a glue to the system that enables our infrastructure to remain decentralized yet secure. Each individual HyperNode performs checks and verifies the performance guarantees of each ScalerNode in the hardware network, ensuring that services and applications are able to operate safely and consistently. HyperNodes execute specific “proof-of-X” challenges, each type depending on the hardware class of the ScalerNode to verify specific behavioural characteristics of the node, in order to properly verify if the ScalerNodes are performing as expected. These checks are then published regularly in a transparent and available system, the Satellite Network, and proofs are submitted on-chain for irrepudiability. Read more about the [HyperNodes here](/network-architecture/hypernode-network). ## The Satellite Network The Satellite Network is a data availability network for HyperNode reports to maintain transparent access to proof data required to validate the HyperNode report results. HyperNodes submit their challenge results to the Satellite Network and a concise version on to the blockchain. Users that want to verify a claim can use data from the Satellite Network to ensure that the result committed provably matches the outcome. The Satellite Network is a key component in maintaining the auditability and transparency of the network. Allowing publicly verifiability is a necessary requirement for a truly decentralized system, giving users the agency to monitor and validate information in a trustless way. Read more about the [Satellite Network here](/network-architecture/satellite-network). ## The Blockchain The Blockchain stands as the final immutability layer for the ICN protocol. Resource management and allocation is processed here to ensure that ICN hardware cannot be double spent and is allocated to the correct user. Staking, collateral and slashing is also managed here to ensure that protocol rules are enforced and system safety is maintained. ICN protocol will initially be launched on Base. As an infrastructure project, we want to ensure that all ecosystems are able to use and contribute to ICN. \\ # Key Features Key Features of the Impossible Cloud Network (ICN) ## 1. Limitless Capabilities The decentralized architecture of ICN enables a deep, heterogeneous network of hardware to support the creation of internet services and applications with exceptional quality, performance, and reliability. Unlike conventional cloud solutions, where data and operations are concentrated within a few entities, ICN’s infrastructure is distributed globally. This distribution minimizes the concerns around data sovereignty, censorship, and trustful systems, enabling operational optionality to support both Web2 and Web3 class of services without compromising on performance. ## 2. Efficient and Performant Resource Management ICN’s resource allocation algorithm is mechanized by a transparent protocol that coordinates resource requirements with configurable hardware blueprints. This model ensures that resources like storage and compute power are allocated efficiently, providing an open access platform to a globally available resource pool. ## 3. Open and Programmable Stack At its core, ICN is a network of composable primitives designed to enable collaboration and innovation. Our stack allows for custom development of services and developers to build new, cutting-edge cloud solutions or protocols to deliver specific needs. This flexibility transforms the platform into a breeding ground for novel systems, setting the scene for ICN as the base layer for the future of digital ecosystems. Developers can deploy and integrate their solutions directly with the ICN Protocol, leveraging our composable layers as a foundation for both Web3-native and traditional Web2 applications. ICN’s open design ensures that innovation isn’t limited by proprietary constraints, offering a truly unbounded space for growth. ## 4. Infinitely Scalable ICN’s architecture allows for more flexible expansion of hardware across regions and zones. As the network is seeded by globally distributed resources that are operationally and logically decentralized it can more dynamically and flexibly scale based on demand. Network growth can expand and contract in rapid response to the market needs enabling both hardware providers and builders to maintain efficient cost and performance. Cost efficiency is further enhanced by the competitive and specialization dynamics within the network. Hardware providers can better align their core competencies in certain hardware classes reducing the per unit cost of resources that are provided to the ICN protocol. This gives us the ability to both be more cost effective yet more performant. # Key Concepts Key Concepts of the Impossible Cloud Network (ICN) The Impossible Cloud Network (ICN) is built on a visionary foundation to create the next generation internet infrastructure with a deep focus on performance, scalability and cost while enabling Web3-native systems. ## A Web3 infrastructure for a Web3 internet The Web3 ecosystem has long needed a crypto-native infrastructure that can truly enable and support the potential of decentralization. Today Web3 projects, from Dapps down to infrastructure projects, ultimately all still operate on top of traditional cloud systems, limiting the innovation possibilities and exposing themselves to undesirable centralization risks. The growth and adoption of Web3 has been stifled by its continued reliance on Web2 cloud architecture. ICN aims to finally unlock the future of Web3 through a new class of infrastructure and returning digital sovereignty back to the user. ## An Ecosystem-Driven Approach Unlike other cloud service providers that often offer single, siloed solutions, ICN focuses on building a multi-service ecosystem. This broad, interconnected platform allows projects and businesses to leverage a suite of cloud services that integrate seamlessly, providing flexibility and innovation across multiple industries. ICN’s approach is designed to challenge the status quo, competing head-on with industry giants by offering a comprehensive alternative. ## Storage as the Core At the heart of ICN’s service offering is storage, a foundational element that acts as the entry point for broader expansion. Data gravity places information flow and data storage at the core of ICN infrastructure focus, ensuring that we support optionality of how data is stored, replicated and owned. With this at our centre, we envision the building out of systems with a deep awareness of data flows enabling more configurable and more controllable access, processing and compute of information, allowing greater level of interoperability and evolution of services and systems. ## Solving the Decentralization vs Scalability dilemma A long standing problem in Web3 is the ability for solutions to meet the scalability needs required for mass adoption. Typically protocols are either decentralized or scale well, never both. ICN has managed to solve this dilemma through a combination of composability and optionality. While our protocol remains unified, the decentralized hardware enables a greater level of separation between operational units of the system that can be composed and constructed independently of each other. This allows modular parts of the system to remain decentralized while allowing the continuous expansion of the network without affecting the existing parts. This achievement unlocks unparalleled flexibility to scale and operational freedom for all participants which crucially allows ICN to remain competitive and performant as an infrastructure layer and maintain our key commitments to decentralization. ## Uncompromising Hardware for High Performance To meet the high expectations of the modern internet, ICN operates primarily on enterprise-level hardware. This ensures the network can deliver the performance, reliability, and security required by businesses as a base standard. ICN’s hardware infrastructure meets or exceeds the modern standards set by leading cloud providers, making it a competitive choice for organizations looking for robust, scalable cloud services. Learn more about ICN's Hardware Requirements:[ Become a Hardware Provider](/icn-participation/contribute-hardware) ## Resolving the DePIN Verification Challenge One of the key innovations ICN brings to the table is its solution to the Decentralized Physical Infrastructure Network (DePIN) verification problem. Ensuring the trust and reliability of a decentralized network is a significant challenge, but ICN’s innovative HyperNode Network and verification processes guarantee the network’s integrity and performance. This gives customers confidence in the security and dependability of ICN’s decentralized infrastructure, allowing it to compete on equal footing with traditional cloud systems. Learn more about how ICN establishes trust in a decentralized System: [HyperNode Network](/network-architecture/hypernode-network) ## A Vision for the Future of Cloud The Impossible Cloud Network is not just a cloud service provider; it’s building a future-ready platform designed to meet the evolving needs of the modern internet. With its open, multi-service ecosystem, foundational storage infrastructure, and enterprise-grade performance, ICN is positioned to lead the open cloud revolution and lead the Web3 movement towards its destination. This vision of scalability, security, and collaboration sets ICN apart as a transformative force in the cloud industry, ready to challenge the dominance of traditional providers. \\ # FAQs Find below a series of Frequently Asked Questions. If you have further questions about ICN don't hesitate to reach out.
What is the Impossible Cloud Network (ICN)? The Impossible Cloud Network (ICN) Protocol is a decentralized cloud infrastructure designed to connect enterprise-grade hardware and application builders in a robust, scalable network. By leveraging an interconnected guardian network known as the HyperNodes, ICN ensures high performance and reliability, enabling cloud services with the transparency and security of decentralized technology.
What is the ICN Protocol? The ICN Protocol (ICNP) functions as a coordination and network formation protocol between hardware resources and software deployers in the ICN network. It incentivizes node participation through reward structures based on demand needs and network performance. ICNP includes a capacity marketplace where Builders can access dedicated hardware capacity. This protocol is mechanized through a robust security and economic incentive that ensures a performance yet robust infrastructure layer.
How does ICN work? The ICN Protocol rewards node operators and providers based on their contributions and network demand, fostering a dynamic and engaged ecosystem. Built for Web3, ICN offers a community-driven, enterprise-grade alternative to traditional cloud providers, prioritizing performance, reliability, and openness for all users. HyperNodes and the ICN Link stakers thereof are rewarded for protecting the integrity of the ScalerNode performance, while ScalerNodes are rewarded for providing core infrastructure resources to the ICN network. Together these nodes form a decentralized ecosystem that can rival modern hyperscalers.
What does ICN provide? ICN has three core-infrastructure layers: * Hardware Network * HyperNode Network * System Layer The hardware network is a decentralized resource pool of computing resources available globally and operated independently. They feed an ever-growing network of capabilities in the ICN infrastructure that can be accessed by anyone for any need. Applications and services can then be deployed and operated on top of the hardware network through the System Layer. The system layer is a software abstraction layer that operates on top of the hardware network. When resources are booked and allocated to a Builder, they are composed together to create a single machine instance that provides a system layer to allow deployment of any software. This can range from Web2 applications and cloud services to Web3 protocols and Dapps. All of this is tied together through the HyperNode network, an interconnected guardian network that protects ICN.
What is a HyperNode? The HyperNodes are a network of decentralized protectors in the ICN Protocol. They monitor and guard our network of resources to ensure a secure and robust hardware layer. The HyperNodes are a core part of the system and play a crucial role in maintaining the infrastructure of the future. This protects our global resource network and upholds the performance thresholds for all ScalerNodes. HyperNodes can be operated from any location and on any device that can support it. It is lightweight and operators & stakers can earn for contributing to the security of the ICN Protocol.
What is a ScalerNode? ScalerNodes are the core units of individual hardware that make up our hardware network. Each ScalerNode can be of any hardware class providing capabilities to our system in storage, compute, networking or memory resources. ScalerNodes are provided by Hardware Providers globally and are secured through collateralization and slashing mechanisms. ScalerNodes can be allocated to Builders that rent resources from the network for deployment of applications and services. They are modular units that can be composed together to create a configurable resource block to run any desired systems inside. ScalerNodes earn rewards for providing resources to the network and additional rewards when they are allocated for usage. Learn how to [become a Hardware Provider ](/icn-participation/contribute-hardware)and provide ScalerNodes.
What ScalerNode classes do you have currently? As of today ICN is primarily comprised of storage class ScalerNodes. We are actively onboarding hardware providers to expand into additional classes of ScalerNodes in the near future to extend the capabilities of the hardware network.
How do HyperNodes keep the network safe? HyperNodes are the guardians of the network. They are a 24/7 constant scouting system that monitors all ScalerNodes across the hardware network. Depending on the resource class of the ScalerNode, the HyperNode will adjust its challenges to check and verify the claimed performance and capabilities of each ScalerNode. HyperNodes sign and publish their reports to the Satellite network where a transparent timeline of records reflect the behaviour of the hardware network at all points in time, allowing any actor to verify and track the ScalerNodes.
What is the Satellite Network? The Satellite Network is a 24/7 availability network that stores and allows access to published records about the ICN protocol. HyperNodes that verify ScalerNodes post results on-chain and the report data used to verify those results are stored off-chain, in the Satellite Network enabling any party to validate the result. Since data is expensive on-chain, only summarized results are submitted there for usage, and the full plain text reports are thus committed instead to the Satellite Network.
What is ICN Link? The ICN Link is an ERC-721 NFT token that is a core component of securing our system. ICN Link holders can stake their Link to nodes to ICN which links their vesting security collateral to the operation of the node that is staked to. They can be staked to either HyperNodes or ScalerNodes. ICN Link holders that stake will earn rewards during the period of their staking as part of contributing to the operation of the nodes. Each Link has a “time-to-live” (TTL) value that captures 48 months of vested security inside. As the Link is staked, this TTL vests as rewards that are claimable as long as the staked node performs work correctly. The more security is staked to nodes in the ICN ecosystem, the greater collateral and security the system has as a whole.
What are the benefits of using the ICN compared to existing services? The ICN offers several benefits over traditional cloud services. It provides high-performant cloud products with better data security, integrity, and resiliency. By leveraging decentralized technologies, it eliminates vendor lock-in and promotes an open, community-driven platform for cloud infrastructure management. Additionally, the ICN's transparent marketplace ensures efficient allocation of resources and competitive pricing.
Can you explain the role of Hardware Providers (HP) and Builders? Hardware Providers (HP) dedicate hardware resources to the ICN network, ensuring its robustness and scalability. They commit capacity to the network and run node software to serve requests from Builders. Builders design and deliver services, applications or cloud products, leveraging the ICN's decentralized architecture to create innovative services for their customers.
How is data security addressed in the ICN? Data security in the ICN is addressed through decentralized technologies and encryption mechanisms subject to functional needs. The network's decentralized architecture ensures better data security, integrity, and resiliency compared to traditional systems and is configurable dependent on the data behaviour properties required by the overarching application. Data replication, information flows, storage etc. are all managed based on tailored rules defined by Hardware Providers’ ScalerNodes offering a diverse optionality of data management schemes to fit the intended use-case. Additionally, hardware performance is continuously monitored, and anomalies are reported and addressed on an incentivization level, enhancing overall data security and reliability. Crucially ICN does not sit in the Builder's application datapath so we 1. Do not affect performance and 2. Do not become a single-point-of-failure.
\\ # Legal Disclaimer ## Disclaimer The present document and/or any other accompanying documentation ("Documentˮ) only provides educational material about the tokenomics of the Impossible Cloud Network and ICNT. Please note that Impossible Cloud Network and ICNT are under active development and are subject to change. The Impossible Cloud Network Stiftung may change this Document at any time at its sole discretion without notice. The information contained in this Document is provided for informational purposes only and there is no guarantee for the completeness of the content. This Document does not constitute an offer to sell or a solicitation of an offer to purchase any ICNT and is not an offering, advertisement, solicitation, confirmation, statement, or any financial promotion that can be construed as an invitation or inducement to engage in any investment activity or similar. All numbers and forward-looking statements mentioned within this Document, as well as any accompanying documentation, reflect mere estimations/indications. The Impossible Cloud Network Stiftung makes no representations, warranties, or covenants with respect to the Impossible Cloud Network and the ICNT as to their technical properties and/or characteristics or performance or their actual or potential usefulness or suitability for any particular purpose. This disclaimer, this Document as well as any accompanying documentation, shall be governed by and construed, and interpreted in accordance with the substantive laws of Switzerland, excluding the Swiss conflict of law rules. The United Nations Convention for the International Sales of Goods is excluded. Any dispute related to or arising out of the information provided within the Document, as well as any accompanying documentation, shall be submitted to the exclusive jurisdiction of the competent courts of the city of Zug, Switzerland, with the exclusion of any other jurisdiction or arbitration. # ICN Glossary Welcome to the ICN glossary. Here you will find definitions and explanations for key terms used across our platform.
DaemonSoftware running on servers to provide essential metrics to HyperNodes.
Satellite NetworkA decentralized, permissionless data storage network where HyperNodes store off-chain proof data.
Hardware ProviderAn entity or individual that supplies ScalerNodes to the ICN Protocol.
ICN ConsoleThe command system interface for users to manage HyperNodes, ScalerNodes, Link staking and other core ICN protocol functions.
ICNP Smart ContractsSmart contracts for key operational functions like rewards, penalties, and collateral management.
ICN LinkA non-fungible token (ERC-721 standard) that grants HyperNode access to the ICN network. It may also be used as hardware collateral to secure participation as a Hardware Node.
RegionA geographic area encompassing multiple zones where Hardware Providers install ScalerNodes.
ClusterA group of ScalerNodes of the same type, often based on geographic proximity or performance characteristics.
BuilderAn entity that accesses virtual machines from ICN to run applications or cloud services such as object storage or GPU computing.
HyperNodeA node that audits and measures the performance of ScalerNodes and virtual machines.
# ICN Protocol Smart Contracts ### All ICN Protocol Smart contracts are currently deployed to the Base blockchain For technical documentation about smart contract [read here](/network-architecture/smart-contracts). Our smart contracts are all audited. Please see below for full audit reports. * [ICN Protocol v5.1 Audit by Cantina/Spearbit](https://console.impossiblecloud.com/static/icn/icnp_v5_1_audit_spearbit_cantina.pdf) * [ICN Protocol v5.0 Audit by Cantina/Spearbit](https://console.impossiblecloud.com/static/icn/icnp_v5_0_audit_spearbit_cantina.pdf) * [ICN Protocol v4.0 Audit by Oak Security](https://console.impossiblecloud.com/static/icn/icnp_v4_0_oak_security.pdf) * [ICN Link v3.0 Audit by Cantina/Spearbit](https://console.impossiblecloud.com/static/icn/icnp_v5_1_audit_spearbit_cantina.pdf) * [ICN Link v2.0 Audit Report by Oak Security](https://console.impossiblecloud.com/static/icn/icnl_audit_oak.pdf) * [ICN Fairdrop v1.0 Contract Audit by Oak Security](https://console.impossiblecloud.com/static/icn/fairdrop_audit_oak.pdf) ### Ethereum | Contract Name | Contract Address | | ------------- | ------------------------------------------------------------------------------------------------------------------- | | ICN Token | [0xe5e0b73380181273abCfD88695F52C4D0C825661](https://etherscan.io/token/0xe5e0b73380181273abCfD88695F52C4D0C825661) | ### Base | Contract Name | Contract Address | | ------------------------------------------ | --------------------------------------------------------------------------------------------------------------------- | | ICN Token | [0xE0Cd4cAcDdcBF4f36e845407CE53E87717b6601d](https://basescan.org/token/0xE0Cd4cAcDdcBF4f36e845407CE53E87717b6601d) | | ICN Link (Proxy) | [0xDa24c1F7669bf9b12EAfE5A3967BC9358eE48A12](https://basescan.org/token/0xDa24c1F7669bf9b12EAfE5A3967BC9358eE48A12) | | ICN Link (Implementation) | [0xA77168C879f7EBaA8CA3C981e389D4578b12C9d8](https://basescan.org/address/0xA77168C879f7EBaA8CA3C981e389D4578b12C9d8) | | ReservePool (Proxy) | [0x5AcBfF1f97CB82E69910a825d7d724880C62Eec8](https://basescan.org/address/0x5AcBfF1f97CB82E69910a825d7d724880C62Eec8) | | ReservePool (Implementation) | [0x5c86CC0b585295151966EC8fc2b590FB1dC737f7](https://basescan.org/address/0x5c86CC0b585295151966EC8fc2b590FB1dC737f7) | | Treasury (Proxy) | [0xFb2d8aDac4f3D5e7A834C28F6376E439c0171C31](https://basescan.org/address/0xFb2d8aDac4f3D5e7A834C28F6376E439c0171C31) | | Treasury (Implementation) | [0x31fb85fD348F2F14AB70E7e41e7C3Df30A8C417d](https://basescan.org/address/0x31fb85fD348F2F14AB70E7e41e7C3Df30A8C417d) | | ICN Protocol (Proxy) | [0x9131f272d9eAA4BeC30eb4254C78B50Df7bc8791](https://basescan.org/address/0x9131f272d9eAA4BeC30eb4254C78B50Df7bc8791) | | Access Control (Implementation) | [0xf97492a5B53eeF9AA10295dDAe6D6A58c7988D21](https://basescan.org/address/0xf97492a5B53eeF9AA10295dDAe6D6A58c7988D21) | | Booking Manager (Implementation) | [0x2e38083d45A72bC12019C54DCC40109d088f7EB5](https://basescan.org/address/0x2e38083d45A72bC12019C54DCC40109d088f7EB5) | | Era Manager (Implementation) | [0xa3A5C7a4aF29F5bA0d8D77EB6B6b2f25536fBc34](https://basescan.org/address/0xa3A5C7a4aF29F5bA0d8D77EB6B6b2f25536fBc34) | | External Contract Manager (Implementation) | [0x9Ed9A87e3237cE29fB1aCd30649dA9d2847987c3](https://basescan.org/address/0x9Ed9A87e3237cE29fB1aCd30649dA9d2847987c3) | | HP Delegation (Implementation) | [0xeD788eF1236E71b1ae503B39b264907Ac97B66c1](https://basescan.org/address/0xeD788eF1236E71b1ae503B39b264907Ac97B66c1) | | HP Rewards (Implementation) | [0x6EC92B42a53F07b4C061F597CF6B3776B4542093](https://basescan.org/address/0x6EC92B42a53F07b4C061F597CF6B3776B4542093) | | ICN Registry (Implementation) | [0x05C5ab6E0ccdFeEDf44a685EfF51E45a982B1563](https://basescan.org/address/0x05C5ab6E0ccdFeEDf44a685EfF51E45a982B1563) | | ICN Registry Getters (Implementation) | [0x9232ede9e52E75af165E73E7a9d8cd740CEeE6a0](https://basescan.org/address/0x9232ede9e52E75af165E73E7a9d8cd740CEeE6a0) | | Link Rewards (Implementation) | [0xe64Fab0952125a5A9968AD41D8a202014869a8cc](https://basescan.org/address/0xe64Fab0952125a5A9968AD41D8a202014869a8cc) | | Link Staking (Implementation) | [0xbA8d6AC691D0946d03e5A4c93bA9e711E82F4D27](https://basescan.org/address/0xbA8d6AC691D0946d03e5A4c93bA9e711E82F4D27) | | Slashing (Implementation) | [0x2f9D478da5DC5304d3C8b3094c70411828C671EB](https://basescan.org/address/0x2f9D478da5DC5304d3C8b3094c70411828C671EB) | | ICN Nodey PFP | [0xC6D855efF2f6d232a83Adcc7C5A185EDe9a890F1](https://basescan.org/address/0xC6D855efF2f6d232a83Adcc7C5A185EDe9a890F1) | | ICN Fairdrop | [0x3E10685609C34eFf6DC2c0F85d2A3122294AC5ae](https://basescan.org/address/0x3E10685609C34eFf6DC2c0F85d2A3122294AC5ae) | # Stake and Earn The easiest way to get involved in the ICN ecosystem and network economy is by contributing stake to the network. Users can stake ICN Link or ICNT to various parts of the system and earn rewards for their contributions. Crucially, these stakes are used to secure the individual nodes of the system that deliver resources and services to the wider network. There are two main parts of the system where users can stake and earn: * HyperNode Network: Secures the ICN Protocol * ScalerNode Network: Decentralization hardware resource nodes ## Stake ICNL to a HyperNode By staking to a HyperNode you will earn rewards based on the verification work done by them. As long as the HyperNode you staked to does valid work in checking and publishing reports about the network performance, you will earn rewards continuously while its misbehaviour and missed jobs will lead to slashing your staked ICN Link.\ \ When staking ICN Links, you can only stake up to 100 ICN Links at a time due to block gas limits. If you want to stake more than 100 Links you will have to submit multiple transactions. Each time you stake multiple Links, they will be bundled together and be managed together until they are unstaked. [Learn how to stake ICNL to a HyperNode](/tutorials-and-education/how-to-stake-icn-link#stake-an-icnl-to-a-hypernode). Read more about the economics of ICN Link staking to [HyperNodes here](/icn-economics/icn-link). ## Stake ICNL or ICNT to a ScalerNode By staking to the ScalerNodes you will earn rewards for helping to collateralize and secure the functioning of the hardware network. As ScalerNodes earn rewards for providing their capabilities and resources to the ICN protocol, stakers can earn a portion of these rewards for supplying liquidity to the collateral that backs each node. Additionally as ScalerNodes are allocated for use by builders that book them, these nodes are paid extra rewards for real utilization of their hardware in the network. Stakers also will earn a portion of these rewards as their stake contributes to maintaining the ability for ScalerNodes to deliver service. ScalerNodes that go offline or fall below performance thresholds for too long will cause the HP-staked ICNT associated with that node to be slashed. Both ICNL and ICNT can be staked to ScalerNodes, and each perform differently in their rewards. [Learn how to stake ICNT to a ScalerNode](/tutorials-and-education/how-to-stake-icnt). [Learn how to stake ICNL to a ScalerNode](/tutorials-and-education/how-to-stake-icn-link#stake-an-icnl-to-a-scalernode). Read more about the economics of staking to ScalerNodes here. \\ # Become a Hardware Provider ICN is fueled by real-world demand from the cloud industry. Our incentive program for hardware providers is designed with clarity and simplicity at its core, directly linked to our cloud expansion. ## Participating as a Hardware Provider on the Impossible Cloud Network The Impossible Cloud Network (ICN) relies on professional hardware providers to contribute to the decentralization of the cloud. This of course while earning corresponding rewards. By joining the ICN, hardware providers become an essential part of the cloud infrastructure of the future, benefiting from real-world demand and network growth. * **Consistent Compensation**: Hardware providers are rewarded proportional to their contributions to the network, ensuring corresponding rewards through the ICN's native token. * **Dynamic Rewards**: As the network expands, hardware providers receive additional rewards, aligned with the growth and demand of the decentralized cloud platform. * **Demand-Driven Growth**: ICN is powered by real-world demand from the cloud industry. Providers can explore new revenue opportunities, including joint demand generation with ICN to accelerate their business growth. ## How to Get Started * **Join the Network**: ICN has strict hardware performance thresholds to be met. To ensure that the right systems are being added, please contact us to be onboarded as a Hardware Provider. * **Add ScalerNode**: Begin by docking your hardware resources to the ICN Protocol. Use the Console to register your ScalerNode, defining its characteristics and capabilities and await verification. During this step you must collateralize ICNT as security for your ScalerNode to be activated as a resource. * **Generate value**: Once activated, your ScalerNodes will start earning corresponding rewards in the ICN native token, based on the scale and quality of your hardware. As a provider of capabilities your ScalerNodes will earn ICNT as a function of the amount of resources you have contributed. * **Collect fees**: While activated as part of the ICN resource network, your ScalerNode may be allocated for usage. This allows you to earn additional rewards as allocation fees for real utilization of your resources, in addition to rewards generated for supplying capacity. * **Explore Growth Opportunities**: As the network grows, you'll have access to additional opportunities to contribute tied to the expansion of ICN's cloud infrastructure. ## The Role of Hardware Providers Hardware providers are crucial in maintaining the network’s foundation and scalability. By participating in a transparent platform, they are incentivized to deliver high-quality infrastructure services. Providers are reliably compensated and contribute to the broader goal of decentralizing the cloud infrastructure, helping to build a secure and efficient ecosystem. Learn more about Being a Hardware Provider in the[ Network Architecture](/network-architecture/scalernode-network) and[ Economics](/icn-economics/hardware-providers-hps) Section. ### Join the hardware network of the future Contribute to the decentralization of the cloud and earn corresponding rewards in line with the growth of the network. \ Learn more or get in touch:[ https://www.icn.global/join-our-protocol/users](https://www.icn.global/join-our-protocol/users)\\ # Run a HyperNode The HyperNode Network ensures that cloud services in ICN are running properly by checking hardware and service availability, helping maintain performance and trust across the decentralized system. The **HyperNode** Network is a required separation of powers within the **Impossible Cloud Network**. It is a decentralized framework responsible for ensuring the reliability and performance of the Network's cloud services. It consists of multiple nodes -operated by independent entities within the ICN Community - by auditing parameters such as hardware capacity and geolocation, while also tracking key **Service Level Indicators (SLIs)** like hardware and service availability. By regularly verifying that resources are delivered as promised, the HyperNode Network ensures **high uptime**, **data integrity**, and **seamless service operation**. HyperNodes act as impartial auditors, continuously challenging and assessing performance across the network. The network’s decentralized model provides a layer of trust by using challenges to verify services and resources. These challenges ensure that hardware remains operational and that builders adhere to their contractual obligations. For example, Hypernodes can perform hardware diagnostics and check the location of hardware to confirm it meets agreed terms. Challenges are executed in cycles (eras), and results are aggregated to provide a clear view of the network's health. The consensus mechanism ensures that even if some nodes fail or behave maliciously, the network still functions accurately and efficiently. To maintain accountability, nodes are verified using ICN Links, ensuring that they cannot be spoofed or compromised. As part of this ecosystem, the HyperNode Network is vital in ensuring the decentralized cloud infrastructure runs smoothly, offering a more reliable, flexible, and secure alternative to traditional centralized cloud services. Learn more about running a HyperNode in the[ Network Architecture](/network-architecture/hypernode-network) and[ Economics](/icn-economics/icn-link) Section.
Who can run a HyperNode? Anyone interested in joining as an HyperNode Operator can do so in the next phase of the project. To contribute to the network now, buy an ICN Link NFT and stake it to one of the existing HyperNodes.
# How to Bridge ICNT Tutorial for bridging ICNT to Base from Ethereum Bridging ICNT from Ethereum to Base is necessary to use the token in the ICN Protocol. ### Step 1: Visit [Superbridge.app](https://superbridge.app/base)
### Step 2: Connect your wallet
### Step 3: Select token to bridge
### Step 4: Enter ICNT
### Step 5: Enter an amount to bridge to Base
### Step 6: Review bridge and confirm

Confirm that your wallet supports Base

### Step 7: Approve tokens to bridge
### Step 8: Bridge tokens from Ethereum
### Step 9: Wait 3 mins for tokens to arrive on Base
### Step 10: Success! Your Base wallet should now have received the ICNT
# How to Stake ICNT Tutorial for staking ICNT in the ICN ecosystem ICNT is the main utility asset that powers the ICN Protocol. Staking ICNT helps secure the network and power its operation while earning for its contribution to the system. Staking ICNT is a very important process. This tutorial aims to explain the steps for how to do this, and the considerations for deciding how much to stake and how long for. ## Step 0: Acquire ICNT Please visit to see which exchanges we are listed on that you can buy our tokens from immediately. You can also buy our token from Uniswap on Base [here](https://app.uniswap.org/swap?inputCurrency=0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913\&outputCurrency=0xE0Cd4cAcDdcBF4f36e845407CE53E87717b6601d\&chain=base). ## Step 1: Enter ICN Protocol Navigate to to begin.
## Step 2: Connect your wallet
## Step 3: Click Stake!
This will start your staking flow immediately! ## Step 4: Select which asset to stake Here you will choose ICNT.
## Step 5: Select which ScalerNode to stake to Each ScalerNode is hardware that commits resources to the ICN Protocol. They are globally distributed and you can choose between them. To see more details about each node before staking, visit the [hardware network section](https://console.icn.global/hardware-network).
## Step 6: Choose amount to stake The amount you stake here will affect your total rewards. The more you stake, the higher the rewards. This is also dependent on the lock period you choose in the next step.
## Step 7: Choose lock period for your stake amount The most important part of the staking process is choosing your lock period. When your tokens are staked, they must first be locked for a chosen period. This acts as a commitment to the protocol that you are rewarded back with. Once locked, your tokens remain in the protocol for the chosen period. During this time you are able to freely stake and unstake your tokens between different nodes in the system, and you will be able to withdraw the tokens once the lock period has elapsed.

Maximum lock period gives highest rewards

Lowest lock period gives lowest rewards

Importantly, APY values displayed are live. The numbers provided are projected earnings based on current rates. ## Step 8: Confirm and sign transaction
## Step 9: Success!
Once you have successfully staked, you will be able to view your current stake positions from your wallet.
# How to Stake ICN Link Tutorial for staking ICNL to HyperNodes or ScalerNodes in the ICN ecosystem * [Stake an ICNL to a HyperNode](#stake-an-icnl-to-a-hypernode) * [Stake an ICNL to a ScalerNode](#stake-an-icnl-to-a-scalernode) ## Stake an ICNL to a HyperNode **Step 1**: Enter the ICN Console:
**Step 2**: Connect your wallet:
**Step 3**: Navigate to your Links by going to the Wallet page:
**Step 4**: Scroll down to the ICN Links tab and select the Link(s) you would like to stake and click "Stake"
**Step 5**: Select what node type you want to stake to. Here select HyperNode.

HyperNode or ScalerNode

**Step 6**: Select a HyperNode
**Step 7**: Confirm the transaction and sign
**Step 8**: Success! You are now staked!
Read more about the economics of ICN Link staking to [HyperNodes here](/icn-economics/icn-link). ## Stake an ICNL to a ScalerNode **Step 1**: Enter the ICN Console:
**Step 2**: Connect your wallet:
**Step 3**: Navigate to your Links by going to the Wallet page:
**Step 4**: Scroll down to the ICN Links tab and select the Link(s) you would like to stake and click "Stake"
**Step 5**: Select what node type you want to stake to. Here select ScalerNode.
**Step 6**: Select a ScalerNode
**Step 7**: Confirm the transaction and sign
**Step 8**: Success! You are now staked!
# How to manage my assets and stakes Tutorial for how to manage stake positions and assets in the ICN ecosystem Once you have some assets, ICN Link or ICNT, or you have staked, all your assets and positions can be viewable from the single unified [Wallet page in the Console](https://console.icn.global/funds). Here you will be able to view your wallet balance, currently owned ICN Links, your active stake positions, and any unstaked ICNT. ## Manage your ICNT The first thing you will see in the Wallet page is your current ICNT balance. This is your currently liquid ICNT balance inside your wallet.
Next to it on the right you will see a breakdown of what ICNT you may have in the ICN Protocol. These are not counted towards your wallet balance but will allow you to track what currently staked ICNT you have, what ICNT remains locked in the system and how much has been unlocked ready for withdraw. By click "Stake and earn" you will be able to immediately starting staking your assets into the protocol and begin earning right away. ## Manage your ICN Links Below wallet balance you will find a tabbed view where all your assets live. Here you will be able to see the Links that you own and stake them if they are not already staked. You will be able to toggle between views for staked and unstaked Links.
## Manage your stake positions Once you have staked at least once, you'll be able to find your stake position in the "Stake Positions" tab in the Wallet page. This section contains all your currently staked assets. You will be able to view them, manage them and claim rewards for them here.
Your stake positions can be either ICNT or ICN Link stake and they will be staked to either a HyperNode or a ScalerNode (ICNT can only be staked to ScalerNodes). # How does ICNT staking work? An explainer for ICNT staking in the ICN ecosystem Stake ICNT into the ICN ecosystem to power the future of Web3 internet infrastructure. By staking you will help contribute, secure and earn for bolstering the ScalerNodes that provide decentralized hardware resources to a distributed cloud network. ### At a glance * ICNT can be staked to ScalerNodes only * ICNT must be locked before staking for a chosen period * ICNT can be staked and unstaked freely during its lock period * Staker will choose a lock period which will apply multipliers to earn rates based on the length of the chosen lock * ICNT staking rewards have 0 claim delay * ICNT will be liquid withdrawable after its lock period has elapsed ## Staking Flow 1. Select ScalerNode to stake to 2. Input amount to stake 3. Choose lock period and associated APY 4. Confirm transaction to lock & stake Here is the full lifecycle of ICNT:

ICNT Lifecycle

When ICNT is locked it also locks in a specific APY curve multiplier that defines the earn rate for the ICNT *when staked.* ICNT cannot be removed from the system during this period and importantly rewards are only earned during periods when the ICNT is staked. Once staked ICNT can be unstaked and staked again freely if a user wants to change which node it stakes on. If ICNT's lock expires, then the owner will be able to withdraw that back to liquid ICNT. If the ICNT lock expires while it is staked, it must be first unstaked and then withdrawn. ## Lock Period When staking fresh ICNT, you will need to select a lock period. The lock period ranges from 1 day up to 48 months. This only applies to how long the ICNT is locked inside the ICN Protocol, it does not affect staking time and users will be able to stake the locked ICNT for as long as they like on any node. Longer lock periods offer longer commitment times of ICNT to the ecosystem creating a greater level of security for the network, which is rewarded with greater earn rates which reflect the value generated in the network. Finally after the lock period elapses a user is able to withdraw their ICNT again for fluid usage like transfers. Crucially, if a user keeps his ICNT locked, he will enjoy the same earn rate as his original lock period when staking. Users are incentivized to lock for long periods in order to get higher allocation efficiency per ICNT staked. # How to claim ICN Link initial drop Tutorial for ICN Link holders to claim their initial ICNT drop **Step 1**: Enter the ICN Console: and enter the Rewards section
**Step 2**: Click Airdrops from the Rewards page
**Step 3**: Navigate to the ICN Link holder initial drop tab in the Airdrops page
**Step 4**: Click "Claim & Withdraw all" and you will begin the claiming flow. Here you will be presented with an option to immediately withdraw your tokens, or immediately stake it into the protocol to earn rewards.
**Step 5**: Complete! # Design Overview This section provides an in-depth overview of the core components of ICN’s architecture, explaining how each component contributes to the overall system.

Fig. ICN overview

## Core Components 1. **Smart Contracts**:\ Enforces the ICN economic & resource allocation system, and implements the performance validation logic. 2. **ScalerNodes**:\ Base resource unit node in the protocol. Physical servers of specific hardware class provisioned to the network by Hardware Providers. 3. **Daemon**:\ Core diagnostic agent for provisioning, telemetry, and hardware response. Provisioning of ScalerNodes is achieved through the installation of the Daemon. 4. **HyperNodes**:\ Independent validator nodes verifying Hardware resource quality and performance. HyperNodes reports are evaluated by the ICN Smart Contracts, ensuring that Builders receive the expected quality of service. 5. **Satellite Network**:\ Guarantees the availability and integrity of off-chain challenge data. In the current implementation, the Satellite Network is bootstrapped as part of the system setup. 6. **Services & Apps**:\ Builders book capacity in the network in ScalerNode units and deploy services and applications at scale. ## Protocol Lifecycle

Fig. Protocol Lifecycle

The ICN architecture operates via a streamlined workflow that ensures efficiency and accountability: 1. **Provisioning**:\ ScalerNodes join the protocol under a specific hardware class and Daemons are deployed. 2. **Resourcing**:\ Builders, via the Console, book capacity in ScalerNode units in a specific region and access to the hardware is provided for deployment of services. 3. **Monitoring**:\ HyperNodes continuously audit performance metrics against the Daemons and submit reports off-chain to the Satellite Network. Daemons and HyperNodes execute challenges in sync via an Indexer from events captured from Smart Contracts. 4. **On-chain Settlement**:\ Smart contracts settle penalties and rewards based on challenge results from the Satellite Network and commit verifications. # ScalerNode Network Hardware providers contribute physical servers with specific hardware classes to the ScalerNode Network. ## Hardware Classes ICN defines Hardware Classes as optimized combinations of hardware resources that cater to specific use cases. By standardizing these classes, ICN ensures homogeneity across diverse hardware configurations provided by vendors. For instance, when offering ScalerNodes optimized for storage, ICN specifies tailored configurations for storage capacity, disk I/O operations and vCPU count. In contrast, accelerated computing ScalerNodes would prioritize GPU quantity and model, as well as memory allocation. ScalerNodes with the same hardware class guarantee equivalent hardware resources, such as identical number of disks and storage capacity. This consistency is maintained even when devices from different manufacturers are used, although performance may vary slightly. If significant differences arise between ScalerNode, they are classified into separate classes. During registration, Hardware Providers assign a specific hardware class to ScalerNodes. These nodes are then grouped according to their hardware class. Currently, only one storage class is available in ICN, simplifying initial deployment and focusing on storage capacity optimization.

Fig. Regions and clusters hierarchy

## Regions and clusters ScalerNodes are registered within regions depending on their geographical location, ensuring data locality and compliance with regional regulations. Within a region, ScalerNodes are then assigned to clusters based on their hardware class and other economic factors. 1. **Region**: The highest level of geographic scope, representing a location or metropolitan area. When registering a new ScalerNode, Hardware Providers select one region from the available options in ICN. Within a Region, all ScalerNodes share certain economic parameters such as subsidy rewards or collateral requirements for each specific hardware class. 2. **Cluster**: A logical group within a region containing ScalerNodes from one or more Hardware Providers belonging to the same hardware class. Every cluster defines the maximum price that a ScalerNode can have for the specific hardware class. Builders book capacity in units of ScalerNodes at the cluster level. ## ScalerNode Hardware Providers are responsible for the management and configuration of the physical servers and the physical network, ensuring secure remote access to the ScalerNodes. Hardware provider’s main set of responsibilities are: 1. Physical host maintenance including firmware updates and maintenance of attached devices such as storage drives, RAM, GPUs, etc. 2. Boot configuration via PXE or iPXE to enable automated bootstrapping of the host operating system. 3. Internal network configuration and management including routers, switches, and firewalls. 4. External network connectivity to the Internet and ensure reachability from outside. Hardware Providers register ScalerNodes in ICN by specifying the following parameters: 1. Hardware Class: Type of hardware class\* of the ScalerNode. 2. Location: Geographic location of the ScalerNode following ISO 3166. 3. Capacity: The total capacity of the ScalerNode for a certain hardware class\*. 4. Rewards Share: Percentage of the rewards shared with delegators from 0 to 100%. 5. ReservationPrice: Price of the ScalerNode in ICNT per unit of capacity\* per day. 6. Maximum booking duration: Maximum booking duration (by default 180 days). \*Currently, only one storage class is available with unit of capacity in terabytes (TB). As part of the registration process, Hardware Providers are required to collateralize their ScalerNodes (please refer to the HP collateral requirements section for details). ### Daemon Upon successful on-chain registration and collateralization, ScalerNodes are provisioned by granting access for Daemon deployment, enabling their integration into the ICN Protocol. The Daemon serves as the core diagnostic agent, collecting and reporting hardware-related performance metrics to the HyperNodes. After successful on-chain registration, the following steps are carried out: 1. Capacity verification: Verifies the capacity of the registered ScalerNode. 2. Daemon installation: Installs the necessary Daemon software on the ScalerNode. 3. Cluster assignment: Assigns the ScalerNode to a specific cluster in the region, based on its hardware class. Once verified and activated on-chain, the ScalerNode begins earning capacity rewards, and becomes available to Builders for deployment. The deployed Daemon continuously runs challenges against the HyperNode Network (see HyperNode Network section for details) and reports relevant telemetry data. This information is accessible to Hardware Providers via the Console, enabling real-time monitoring and troubleshooting capabilities. # HyperNode Network The HyperNode Network operates in a decentralized manner, relying on a global community of individuals on the Internet. A single HyperNode Operator can deploy multiple HyperNodes, each requiring activation through staking at least one ICN Link. On a regular basis, HyperNodes conduct challenges using cryptographic signatures against ScalerNodes to monitor key performance metrics. ### HyperNode HyperNode Operators are responsible for the registration and management of HyperNodes, ensuring that HyperNodes are accessible from the Internet. The registration process of HyperNodes should specify: 1. Address: Blockchain address for the HyperNode. The private key of this account is used for signing challenges exchanged between daemons and HyperNodes. 2. Location: Geographic location of the HyperNode following ISO 3166. 3. Endpoint: FQDN or IP address of the HyperNode, which is reachable from the Internet. Once registered, the HyperNode Operator launches HyperNode passing the private key as argument. From this point, when one or more ICNLs are staked to the HyperNode, this becomes active and the challenges are started. ### Challenges Challenges within the protocol occur at scheduled intervals known as eras. Each era lasts approximately one hour, measured in blocks. The challenge execution within an era is illustrated below:

Fig. Challenges

To synchronize challenge execution, both Daemons and Hypernodes retrieve data from the era manager smart contract. This data indicates the era’s duration in number of blocks and the starting block; which allows for the approximate calculation of the era’s end time. During each era, the daemon initiates a challenge with every active HyperNodes in ICN. Specifically, each daemon sends one challenge to each active HyperNode per era which follows as: 1. Daemon sends a challenge request to HyperNode 1. 2. HyperNode 1 signs the challenge and returns the response to the Daemon. 3. Both Daemon and HyperNode submit a report to the Satellite Network (for reports, see Satellite Network section) The ICN protocol currently assesses ScalerNode availability as the percentage of time a daemon is reachable and responds to challenges correctly. To achieve that, HyperNodes must be accessible via the Internet to receive challenges from daemons. Each HyperNode must respond to one availability challenge from each ScalerNode in every era. \\ # Satellite Network All availability challenges in ICN require the use of both ScalerNodes and HyperNodes to submit reports on the Satellite Network. By leveraging the Satellite Network, reports are ensured to be accessible off-chain for a predetermined duration, after which all data is securely deleted. The availability reports currently include the following information: 1. Originator: Type of node submitting the report (ScalerNode or HyperNode). 2. Originator version: Software version running on the originator node. 3. Era ID: The era number in which the challenge occurred. 4. ScalerNode ID: The unique identifier of the ScalerNode that initiated the challenge. 5. HyperNode ID: The unique identifier of the HyperNode that responded to the challenge. 6. Signatures: A record of the signatures from both the ScalerNode and HyperNode, including their corresponding public keys. \\ # Services and Apps Builders reserve network capacity in ScalerNode units where applications and services are deployed. When submitting capacity requests, this triggers the automatic allocation of necessary resources and rewards within the network. Builders can submit capacity requests at the level of clusters where the ICN protocol then assigns to a specific ScalerNode. Then, a Builder booking specifies: 1. Builder address: Blockchain address of the Builder. 2. Cluster ID: Unique identifier of the cluster within a specific region. 3. Capacity Request: The amount of requested capacity units. 4. Duration Request: Requested duration of the booking period. And based on the following ScalerNode’s parameters: 1. ScalerNode capacity: The total capacity of the ScalerNode for a certain hardware class\*. 2. Minimum booking duration: Minimum booking duration of the ScalerNode set by ICN (currently 90 days). 3. Maximum booking duration: Maximum booking duration of the ScalerNode set by the HP (minimum 180 days). 4. Cluster Price: Minimum value between: 1. Maximum price: max price for a cluster in ICNT for a hardware class\*. 2. Reservation price: price of the ScalerNode in ICNT set by the HP. 5. Collateral commitment duration: Duration of the lock period of the collateral (min. 36 months). \*Currently, only one storage class is available with unit of capacity in terabytes (TB). \\ The protocol assigns the requested capacity to any ScalerNode that fulfills the following requirements: 1. Capacity request is equal to the capacity of the ScalerNode. 2. Booking duration requested is within minimum and maximum booking duration periods of the ScalerNode. 3. Duration request is shorter than the collateral commitment period of the ScalerNode. If more than one ScalerNode fulfills the request, the ICN protocol assigns the first available ScalerNode from the pool. \\ # Smart Contracts Smart contracts implement and enforce the ICN’s economic model, managing resource allocation, and implementing the logic for performance validation. Smart contracts automate and regulate transactions and interactions within the ICN ecosystem, to automatically execute actions like distributing rewards, processing payments, or verifying performance based on predefined conditions. This automation removes the need for intermediaries and minimizes the potential for human error or manipulation, contributing to a transparent and trustworthy system. ICN smart contracts uses a multi-implementation proxy. This has the following benefits: 1. Unlimited size for code deployment: Breaking down large and complex logic into smaller, more manageable pieces, effectively bypassing gas limit constraint on contract sizes. 2. Modularity: The logic of related functionalities lives in a separated contract and can be upgraded independent of any other module. This design allows for the separation of concerns, making it easier to update or modify specific components without affecting other parts of the system. For example, if one component is updated, it won't break dependent components that use older versions. 3. Extensibility: modules can be added as the requirements for new functionality are received. New features and functionalities can be seamlessly integrated into the existing system by deploying additional contracts, allowing for incremental growth and evolution of the smart contract ecosystem. 4. Structured organization of the storage: Data storage is organized in a hierarchical manner, making it easier to manage and maintain complex state transitions. 5. Improved security through compartmentalization: With each contract responsible for a specific aspect of the system's functionality, potential vulnerabilities are isolated and contained within their respective contracts, reducing the attack surface and making it harder for hackers to exploit weaknesses. 6. Enhanced maintainability and debugging capabilities: As each component is separate and self-contained, developers can focus on specific parts of the system without being overwhelmed by complex interactions between multiple components. This leads to faster development cycles, improved code quality, and more efficient debugging processes. ### Architecture
ICN smart contracts modules are divided into: 1. Access Control: Management and regulation of who has permission to interact with various parts of ICN. Main functions within this module include granting and revoking roles from a specific account. 2. ICN Registry: Includes all functions related to registration and removal of entities in ICN (i.e. regions, clusters, HPs, ScalerNodes, SPs, HyperNodes, etc.) and the related update functions for their parameters such as updating reservation price of a ScalerNode. 3. Booking Manager: Controls all the operations related to booking resources within ICN and related parameters. 4. Era Manager: Responsible for tracking eras within ICN, this module also allows for updating the era duration in number of blocks. 5. HP Delegation: All functions related to collateralization of ScalerNodes and delegation of ICNT for network collateral, including locking, claiming and withdrawal of accrued rewards. 6. HP Rewards: It includes all required functions for the calculation of capacity and utilization rewards of ScalerNodes, as well as delegator rewards generated from the reward share. 7. Link Rewards: Controls all operations related to ICN Link rewards such as claiming and withdrawal of accrued rewards. 8. Link Staking: Includes functions related to staking and unstaking of ICN Links and updating functions for related parameters such as minimum staking periods or maximum number of ICN Links that can be staked on a single HyperNode. 9. Slashing: It includes functions for slashing of ScalerNodes in case of misbehavior. # Tokenomics ## Introduction to Tokenomics The Impossible Cloud Network (ICN) is powered by its native utility token, ICNT, which serves as the fuel for the entire network. ICNT plays a central role in incentivising network participants, ensuring access to services, and maintaining decentralisation. ### Key Roles of ICNT: * Accessing Network Services: Builders provide ICNT to access storage, compute, and other network resources. * Collateral Functionality: ICNT can be staked by hardware operators to join the Network as Hardware Nodes. ICNT holders will thus transfer the ICNT to a staking smart contract, and the ICNT will be locked there. If the Hardware Node misbehaves, the Hardware Collateral will be subject to slashing by the Network.

Figure 1: ICNT Flow Through the ICN Ecosystem

This diagram illustrates the flow of ICNT contributions within the ICN. Builders provide ICNT to the treasury, which acts as a central repository. Governance Decisions, represented as a control agent, allocate ICNT from the Treasury to the Reward Reserve or reinvest for the purpose of the further development of ICN based on protocol needs and governance actions. The Reward Reserve distributes ICNT as rewards to Hardware Providers and Hypernodes, ensuring network incentives remain robust ## ICNT Supply ### Circulating Supply The circulating supply of ICNT represents the number of tokens that are actively available in the market, being used for network services, rewards, and trading. This number evolves over time as tokens are unlocked from unlock schedules. * Unlock Schedules: A portion of ICNT tokens distributed to early investors, the team, and other stakeholders are subject to unlock schedules, meaning they are released gradually over a defined period. This prevents sudden market oversaturation, maintaining stability. For more details, visit the[ Circulating Supply](/icn-economics/tokenomics/the-icnt/circulating-supply) page. ### Total Supply The **total supply of ICNT is permanently fixed at 700 million tokens.** All tokens were minted at genesis, and there is **no inflation**. Any change to this hard cap would require a formal governance proposal and community approval; none is currently planned. For a more detailed breakdown of the total supply, visit the[ Total Supply](/icn-economics/tokenomics/the-icnt/total-supply). *** ## Token Utility ICNT is the backbone of the Impossible Cloud Network (ICN). It powers the network by enabling users to access services, rewarding contributors, and securing the network’s decentralised infrastructure. Below are the key utilities of ICNT: ### Accessing Network Services Builders need ICNT to access the storage and compute resources available on the network. By using ICNT, Builders can store, retrieve, and process data on the network. This creates demand for the token as more participants join and utilise the resources. * Fees for Services: Builders contribute ICNT to use network resources. These ICNT are collected in the Treasury. Transfers from the Treasury to the Reward Reserve are made based on governance decisions, ensuring flexibility and adherence to network needs. For more detailed information on how ICNT is used to access network resources, visit the [Builders](/icn-economics/service-providers) section. ### Incentives and Rewards ICNT is used to incentivise network participants such as Hardware Providers (HPs), Builders, and Hypernodes. By rewarding these contributors, the network ensures its sustainability and decentralisation. * HP Rewards: HPs earn ICNT as rewards for providing storage and compute resources. * Hypernodes: Hypernodes are responsible for monitoring network performance, and the ICN Link holders that have delegated to the Hypernodes earn ICNT based on their service level monitoring duties. For more information on rewards, visit the[ HP Rewards](/icn-economics/hardware-providers-hps/hp-rewards) and [HyperNodes](/icn-economics/icn-link) sections. ### Collateral for HPs Hardware Providers are required to lock a portion of ICNT as collateral to participate in the network. This collateral ensures that HPs commit to providing the agreed-upon resources and meet their performance thresholds. If they fail to do so, their collateral may be slashed, enforcing reliability. For further details on how collateral works, visit the[ Collateral](/icn-economics/hardware-providers-hps/collateral) section. *** ## Burn Mechanisms Currently, there are no burn mechanisms in place within the Impossible Cloud Network (ICN). However, as the network evolves, burn mechanisms may be introduced through governance decisions. These mechanisms would allow for the permanent removal of ICNT from circulation, potentially increasing the scarcity and value of the token. For more details on how burn mechanisms could be introduced, visit the[ Burn Mechanisms](/icn-economics/tokenomics/the-icnt/burn-mechanisms) section. *** ## Initial Allocation At the launch of the Impossible Cloud Network (ICN), the initial allocation of ICNT tokens was carefully structured to balance network growth, incentives, and ecosystem development. The total initial supply of 700 million ICNT tokens was distributed across several key groups to ensure the long-term sustainability and decentralisation of the network. #### Breakdown of Initial Allocation * Investors: A portion of the initial supply was allocated to early investors who helped fund the network’s development. * Team: The founding team and other core contributors received a share of the tokens, but these are subject to vesting schedules to ensure long-term commitment. * Development Company: A specific allocation was reserved for ongoing network and software development to ensure that the network can continue to evolve. * Node Sale: A portion of the supply was reserved for ICN Link holders, enabling them to contribute resources to the network. * Reward Reserve: A significant amount of tokens were allocated to the Reward Reserve, which is used to incentivise Hardware Providers (HPs) for their contributions. For more details on the specific token distribution, visit the Initial Allocation section. *** ## Unlock Schedule The unlock schedule ensures that tokens distributed during the initial allocation are not immediately available for use or trading. This gradual release of tokens helps maintain network stability by preventing sudden market fluctuations and ensuring that participants remain committed to the long-term success of the Impossible Cloud Network (ICN). #### Unlock Periods * Team Tokens: Tokens allocated to the founding team are vested over a four-year period, with a 12-month cliff, meaning no tokens are unlocked for the first year. * Investor Tokens: Similarly, tokens allocated to investors are released over time, ensuring alignment with the long-term goals of the network. * Development and Partner Funds: Funds allocated for network development and partnerships are also subject to vesting schedules to prevent short-term liquidation and incentivise continuous ecosystem growth. For more detailed information on how the vesting periods work, visit the[ Unlock Schedule](/icn-economics/tokenomics/vesting-schedule) section. # The ICNT **Introduction to ICNT** The Impossible Cloud Network Token (ICNT) is the native digital asset of the Impossible Cloud Network (ICN). Serving as the fundamental unit of value, ICNT is crucial for enabling various interactions across the ecosystem, including accessing services and rewarding contributors. ICNT holders can use the token to: * Access decentralised cloud resources provided by Hardware Providers (HPs). * Earn rewards by contributing collateral to the network from the staked HPs or HyperNode successfully performing their tasks. *** For more in-depth information, explore the following subpages: * [**Circulating Supply**](/icn-economics/tokenomics/the-icnt/circulating-supply): Learn about the ICNT supply that is actively available for transactions and its role in network economics. * [**Total Supply**](/icn-economics/tokenomics/the-icnt/total-supply): Understand the overall supply limits of ICNT and how this impacts scarcity and token valuation. * [**Token Minting**](/icn-economics/tokenomics/the-icnt/token-minting): Read the formal statement confirming that **no additional ICNT will ever be minted**. * [**Burn Mechanisms**](/icn-economics/tokenomics/the-icnt/burn-mechanisms): Details about potential future mechanisms for reducing circulating supply through token burns. For more details, visit each subpage to gain insights into the token's role in maintaining and growing the ICN ecosystem. \\ # Circulating Supply The circulating supply of ICNT tokens refers to the total amount of tokens that are actively available and tradable in the market. This includes tokens that are no longer locked in vesting contracts or staking mechanisms and are freely circulating among network participants. The circulating supply plays a crucial role in the dynamics of the Impossible Cloud Network (ICN), influencing everything from the market price of the token to the incentives distributed to Hardware Providers (HPs), Builders, and HyperNodes. *** ## Factors Influencing Circulating Supply * **Initial Allocation and Vesting**:\ A portion of ICNT tokens is subject to vesting schedules for the founding team, investors, and early contributors. As these tokens vest and are released, they gradually increase the circulating supply.\ \ Example: The team’s tokens are released over a period of 4 years, with a portion being unlocked every 12 months. This gradual release helps ensure stability in the token’s supply. * **Token Minting**:\ The total supply is permanently capped at **700 million ICNT**; no further tokens will ever be created. Circulating supply can grow only through the scheduled unlocking of existing tokens.\ \ For more details on token minting, visit the[ Token Minting](/icn-economics/tokenomics/the-icnt/token-minting) page. * **Burn Mechanisms**:\ In the future, burn mechanisms could be introduced as a way to decrease the circulating supply, reducing the overall token supply and potentially increasing scarcity. Burn mechanisms would involve permanently removing ICNT tokens from circulation by destroying them.\ \ For more information, visit the[ Burn Mechanisms](/icn-economics/tokenomics/the-icnt/burn-mechanisms) page. *** ## Mathematical Representation of Circulating Supply The circulating supply can be thought of as the sum of tokens held by various participants in the Impossible Cloud Network (ICN): Circulating Supply = Unlocked Investor Tokens + Speculative Investors + Builders + Hardware Providers (HPs) + ICN Link Holder In this formula: * **Unlocked Investor Tokens**: Tokens that have been released from vesting schedules and are now in circulation. * **Speculative Investors**: Tokens held by market participants (including CEX/DEX liquidity and market makers) * **Builders**: Tokens held by Builders, which they use to access network services. * **Hardware Providers (HPs)**: Tokens earned by HPs for providing storage and compute resources. * **ICN Link Holders**: Tokens earned through HyperNodes for monitoring the network and through delegated staking. *** ## Visual Representation of Circulating Supply Below is a visual representation of the circulating supply of ICNT tokens as buckets, each representing different groups of token holders:

Figure 1: Circulating Supply as Buckets

This diagram illustrates the circulating supply as buckets of tokens held by various participants, including unlocked investor tokens, speculative investors, Builders, Hardware Providers (HPs), and ICN Link Holder. These different groups contribute to the overall circulating supply of ICNT tokens. *** ## Why Circulating Supply Matters The circulating supply of ICNT is a key metric that influences several aspects of the ICN ecosystem: * **Market Dynamics**: The circulating supply directly affects the market capitalisation and price of ICNT. As the supply of tokens increases or decreases, it can create fluctuations in the market price. * **Liquidity**: A larger circulating supply ensures more liquidity, making it easier for participants to trade ICNT and for the network to function efficiently. * **Incentives and Rewards**: The circulating supply affects the distribution of incentives and rewards to HPs, Builders, and ICN Link Holders, as rewards are provided in ICNT based on the available circulating tokens. * **Network Growth**: As the ICNT circulating supply grows, it signals the gradual decentralisation of the network, with more participants gaining access to tokens and contributing to the growth of the ICN ecosystem. # Total Supply ICNT is governed by a **hard cap of 700 million tokens**. No further tokens can be issued under the current protocol rules. | Parameter | Value | | ------------------ | -------------------------------------- | | **Maximum Supply** | **700 000 000 ICNT** (fixed) | | **Inflation** | *0 %* | | **Change to Cap** | There is no supply cap change planned. | *** ### Components of the 700 M Supply | Component | Purpose | Reference | | ---------------------- | ------------------------------------------------------------------------------ | ------------------------------------------------------------------------------ | | **Initial Allocation** | Distributed to founding team, investors, partners; subject to unlock schedules | See[ **Initial Allocation** ](/icn-economics/tokenomics/initial-allocation)doc | | **Reward Reserve** | Incentives for Hardware Providers (HPs), HyperNodes and other participants | — | | **Unlock Schedule** | Controls the gradual release of vested tokens into circulation | See[ **Unlock Schedule** ](/icn-economics/tokenomics/vesting-schedule)doc | *There is **no minting component**; all rewards and emissions draw from the fixed supply and the Reward Reserve.* *** ### Why a Fixed Cap Matters 1. **Predictable Economics** – Zero inflation simplifies valuation and planning. 2. **Long‑Term Value** – Scarcity supports sustainable token economics. 3. **Governance Clarity** – Any change requires explicit community consent. # Token Minting ICNT operates with a **fixed supply of  700 million tokens**. | Parameter | Value | | ---------------------- | -------------------- | | **Total Supply** | **700 000 000 ICNT** | | **Additional Minting** | *None* | All reward schedules and on‑chain incentives draw exclusively from this capped supply. # Burn Mechanisms There are no burn mechanisms planned for the first phase of the Impossible Cloud Network (ICN). During this initial period, the primary focus is on network growth, decentralisation, and incentivising participation. In the maturity phase, burn mechanisms may be implemented as part of the network's evolution. For example, a portion of ICN's Treasury may be burned to permanently remove ICNT from circulation, helping to manage inflation and support the token's long-term value. # Initial Allocation ### Initial Allocation of ICNT Tokens (700M) The initial allocation of ICN Tokens (ICNT) is essential for ensuring the long-term sustainability of the Impossible Cloud Network (ICN) ecosystem. The total supply at launch is 700 million tokens, distributed across key stakeholders and contributors. Below is a breakdown of the allocation, with explanations for each category and its role in the network.

Figure 1: Starting token allocation pie chart

*** #### Summary Table: Initial Token Allocation | Category | Percentage | Tokens Allocated (ICNT) | | --------------- | ---------- | ----------------------- | | Team | 23.2% | 162.5 million | | Investors | 22.9% | 160.1 million | | DevCo | 5.5% | 38.5 million | | EcoDev Fund | 7.5% | 52.5 million | | Partner Fund | 10.9% | 76.3 million | | Node Sale | 20.0% | 140.0 million | | Rewards Reserve | 10.0% | 70.0 million | | TOTAL | 100.0% | 700.0 million | ## Detailed Allocation Breakdown ### 1. Team (23.2%) Tokens Allocated: 162.5 million ICNT Reserved for founders, the core team, and future hires. TGE unlock: \~1.2 million tokens (July 2025). Cliff: 0 tokens, Aug–Oct 2025. Ramp-in: \~0.28 million down to \~0.24 million tokens/month, Nov 2025–Jul 2026. Primary vesting: \~6.52–6.66 million tokens/month, Aug 2026–Jul 2028. Tail phase: \~0.09 million down to \~0.03 million tokens/month, Aug 2028–Oct 2029. Fully vested from Nov 2029. Total schedule: 52 months. ### 2. Investors (22.9%) Tokens Allocated: 160.1 million ICNT TGE unlock: \~1.4 million tokens (July 2025). Cliff: 0 tokens, Aug–Oct 2025. Ramp-in: \~0.32 million down to \~0.28 million tokens/month, Nov 2025–Jul 2026. Primary vesting: \~6.38–6.54 million tokens/month, Aug 2026–Jul 2028. Tail phase: \~0.10 million down to \~0.04 million tokens/month, Aug 2028–Oct 2029. Fully vested from Nov 2029. Total schedule: 52 months. ### 3. DevCo (5.5%) Tokens Allocated: 38.5 million ICNT Assigned to Impossible Cloud GmbH (DevCo), this allocation will fund ongoing development and operational costs, ensuring that the project continues to innovate and expand. TGE unlock: \~19.6 million tokens (July 2025). Linear vesting: 787,500 tokens/month, Aug 2025–Jul 2027 (24 months). Fully vested from Aug 2027. Total schedule: 25 months. ### 4. Ecosystem Development Fund (EcoDev Fund) (7.5%) Tokens Allocated: 52.5 million ICNT The EcoDev Fund supports the long-term growth of the ICN ecosystem through grants, partnerships, and initiatives that encourage developers and organisations to build on the ICN platform. TGE unlock: \~17.5 million tokens (July 2025). Linear vesting: \~1.46 million tokens/month, Aug 2025–Jul 2027 (24 months). Fully vested from Aug 2027. Total schedule: 25 months. ### 5. Partner Fund (10.9%) Tokens Allocated: 76.3 million ICNT Allocated pre-TGE, the Partner Fund incentivises early contributors and partners who help bring the project to life. This includes strategic partners (e.g., liquidity providers, exchanges, and hardware providers like early HPs) as well as community engagement measures, such as airdrops. TGE unlock: \~37.8 million tokens (July 2025). Linear vesting: \~1.07 million tokens/month, Aug 2025–Jul 2028 (36 months). Fully vested from Aug 2028. Total schedule: 37 months. ### 6. Node Sale (20.0%) Tokens Allocated: 140.0 million ICNT This allocation is reserved for participants in the Node Sale, specifically ICN Link holders to delegate tokens to HPs for collateral or to delegate tokens to HyperNodes ### 7. Rewards Reserve (10.0%) Tokens Allocated: 70.0 million ICNT The Rewards Reserve is designated to incentivise Hardware Providers (HPs). # Token Unlock Schedule ## **Unlock Schedule Overview** The unlock schedule for the ICN Tokens (ICNT) ensures a controlled and gradual release of tokens, designed to incentivize long-term commitment and prevent market instability. Below is a breakdown of the vesting schedules for each category of token holders, along with accompanying explanations. ***

Figure 1: Vesting schedule for ICN tokens, showing token unlocks over time.

*** ### **Summary Table: Unlock Schedule**
CategoryInitial AllocationUnlock PeriodNotes
Team23.2% (162.5M ICNT)TGE–52 monthsTGE unlock, 3-month cliff, ramp-in, then primary vesting and tail phase.
Investors22.9% (160.1M ICNT)TGE–52 monthsTGE unlock, 3-month cliff, ramp-in, then primary vesting and tail phase.
Development Company5.5% (38.5M ICNT)TGE–24 months~50.9% unlocked at TGE, remainder linear over 24 months.
EcoDev Fund7.5% (52.5M ICNT)TGE–24 months~33.3% unlocked at TGE, remainder linear over 24 months.
Partner Fund10.9% (76.3M ICNT)TGE–36 months~49.6% unlocked at TGE, remainder linear over 36 months.
Node Sale20.0% (140.0M ICNT)TGE–48 monthsUnlocked over the first 48 months, following the degressive schedule.
Rewards Reserve10.0% (70.0M ICNT)TGEFully unlocked at TGE. Available for ecosystem rewards.
*** ## **1. Team** * **Allocation**: 23.2% (162.5M ICNT) * **Unlock Period**: TGE to 52 months * **Details**: TGE unlock \~1.2M tokens. Cliff of 0 tokens, months 2–4. Ramp-in from \~0.28M down to \~0.24M/month, months 5–13. Primary vesting of \~6.52M–6.66M/month, months 14–36. Tail phase from \~0.09M down to \~0.03M/month, months 37–52. Fully vested from month 53. *** ## **2. Investors** * **Allocation**: 22.9% (160.1M ICNT) * **Unlock Period**: TGE to 52 months * **Details**: TGE unlock \~1.4M tokens. Cliff of 0 tokens, months 2–4. Ramp-in from \~0.32M down to \~0.28M/month, months 5–13. Primary vesting of \~6.38M–6.54M/month, months 14–36. Tail phase from \~0.10M down to \~0.04M/month, months 37–52. Fully vested from month 53. *** ## **3. Development Company** * **Allocation**: 5.5% (38.5M ICNT) * **Unlock Period**: TGE to 24 months * **Details**: \~50.9% (19.6M) unlocked at TGE, remainder released linearly at 787,500 tokens/month over 24 months. Fully vested from month 26. *** ## **4. Ecosystem Development Fund (EcoDev Fund)** * **Allocation**: 7.5% (52.5M ICNT) * **Unlock Period**: TGE to 24 months * **Details**: \~33.3% (17.50M) unlocked at TGE, remainder released linearly at \~1.46M/month over 24 months. Fully vested from month 26. *** ## **5. Partner Fund** * **Allocation**: 10.9% (76.3M ICNT) * **Unlock Period**: TGE to 36 months * **Details**: \~49.6% (37.8M) unlocked at TGE, remainder released linearly at \~1.07M/month over 36 months. Fully vested from month 38. *** ## **6. Node Sale** * **Allocation**: 20.0% (140.0M ICNT) * **Unlock Period**: TGE to 48 months. The token unlock follows a degressive model as outlined below: | Month | % Token per Month | | ----- | ----------------- | | 1 | 18.4% | | 2 | 3.4% | | 3 | 3.4% | | 4 | 3.2% | | 5 | 3.2% | | 6 | 3.2% | | 7 | 3.0% | | 8 | 3.0% | | 9 | 3.0% | | 10 | 2.8% | | 11 | 2.8% | | 12 | 2.8% | | 13 | 2.6% | | 14 | 2.6% | | 15 | 2.6% | | 16 | 2.3% | | 17 | 2.3% | | 18 | 2.3% | | 19 | 2.1% | | 20 | 2.1% | | 21 | 2.1% | | 22 | 1.9% | | 23 | 1.9% | | 24 | 1.9% | | 25 | 1.7% | | 26 | 1.5% | | 27 | 1.5% | | 28 | 1.5% | | 29 | 1.3% | | 30 | 1.3% | | 31 | 1.3% | | 32 | 1.1% | | 33 | 1.1% | | 34 | 1.1% | | 35 | 0.9% | | 36 | 0.9% | | 37 | 0.6% | | 38 | 0.6% | | 39 | 0.6% | | 40 | 0.6% | | 41 | 0.6% | | 42 | 0.6% | | 43 | 0.4% | | 44 | 0.4% | | 45 | 0.4% | | 46 | 0.4% | | 47 | 0.4% | | 48 | 0.4% | * **Details**: Tokens are gradually unlocked over the first 48 months, following the degressive schedule mentioned above. Figures are rounded. *** ## **7. Rewards Reserve** * **Allocation**: 10.0% (70.0M ICNT) at TGE # Token Utility ## **Introduction** **The ICN Token (ICNT)** is the core utility token that powers the Impossible Cloud Network (ICN). The token is used to access network resources, reward network participants, and to secure the network. Key points: * **Accessing Network Services**: Builders need ICNT to obtain access to network resources such as data storage and computing capacity. * **Rewarding Network Participants**: Hardware Providers (HPs) and HyperNodes are rewarded with ICNT for their network contributions * **Securing the Network**: Hardware Providers (HPs) lock collateral in ICNT when committing hardware resources to the network, ensuring that the network remains decentralised, reliable, and secure. *** ## Core Functions of ICNT #### Accessing Network Services Builders are required to use ICNT to access ICN's network resources such as cloud storage capacity. For more details, see the[ Access to Network Resources](/icn-economics/service-providers/access-fees) page. Builders provide ICNT, which is collected in the Treasury. To understand more about the roles and operations of Builders within the ICN, refer to the [Builders](/icn-economics/service-providers) page. Hardware Providers (HPs) earn ICNT for providing and maintaining network resources (such as storage capacity). The more reliable and performant their services, the more their resources are being used by Builders the more they are rewarded. Learn more about the HP reward system on the[ HPs](/icn-economics/hardware-providers-hps) page. This incentive structure ensures that the network is reliable, decentralised, and self-sustaining, with rewards directly tied to the quality of service provided by HPs and the reliability of HyperNodes. #### Collateral Hardware Providers (HPs) must lock up a certain amount of collateral in the form of ICNT to contribute network resources to ICN. This collateral acts as a security deposit, ensuring that HPs provide reliable services and adhere to network standards. Key points: * **Collateral Requirements**: HPs must lock up collateral proportional to the amount of network resources they contribute (Network Collateral) and earnings (Node Collateral). * **Commitment Period**: HPs must lock their collateral for a minimum period, with the option to extend in 6-month increments. HPs are incentivised to lock collateral for longer periods, as this increases their likelihood of being selected for service requests, ultimately enhancing their rewards. * **Staking and Slashing**: Collateral is subject to slashing if HPs fail to meet their service level requirements, and there are mechanisms in place for delegated staking, allowing external delegators to participate. More details on these mechanisms can be found in the[ Staking](/icn-economics/hardware-providers-hps/collateral/delegation) and[ Slashing](/icn-economics/hardware-providers-hps/collateral/slashing) sections. For further information on how the collateral system works, including slashing slashing, please see the[ **Collateral Documentation**](/icn-economics/hardware-providers-hps/collateral). # Builders **Builders** are one of the user classes of the **Impossible Cloud Network (ICN)** who require decentralised storage and computing resources. **Builders** access these resources by providing ICNT token requirements, which allows them to use the network’s distributed infrastructure. **Builders** play a critical role in sustaining the ICN ecosystem, as their ICNT access requirements help reward **Hardware Providers (HPs)** and **HyperNodes**, ensuring the network continues to function efficiently. By submitting capacity requests, Builders initiate the flow of resources and incentives within the network.

Figure 1: Flow of Builders in the ICN

This flowchart illustrates the interaction between Builders and the Impossible Cloud Network (ICN). Builders submit Capacity Requests and provide ICNT for access. These ICNTs funds contribute to the Treasury. *** ### Accessing Network Services Builders in the Impossible Cloud Network (ICN) use ICNT tokens to access the network’s decentralised storage and compute resources. Builders submit storage capacity requests to the protocol, which then allocates the required resources from Hardware Providers (HPs) based on availability. #### The Process of Accessing Network Resources * **Submit Capacity Request**:\ Builders submit a request for storage capacity, specifying: * The amount of storage required (e.g., 1PB). * The location where the storage is needed (e.g., a particular cluster). * The duration for which the storage is required. * **Provide ICNT**:\ To access the requested resources, Builders provide ICNT tokens based on number of factors: the cluster price, booked capacity, protocol margin, and booking duration. Once validated by the network, Builders are allocated storage and can begin utilizing it. $$ \text{Booking Price} = (1 + \text{Protocol Margin}) \times \text{Cluster Price} \times \text{Booked Capacity} \times \text{Period} $$ where: * Cluster Price is the base rate per TB for the selected cluster. * Booked Capacity is the amount of storage requested (in TB). * Period is the number of months the storage is required. * Protocol Margin is a percentage fee retained by the protocol (e.g., 25%). **Receive Network Resources**: Once the request is processed and the ICNT access requirements are provided, Builders get access to ScalerNodes with the amount of storage requested. For detailed information on how Access Requirements are calculated and distributed, visit the[ Access to Network Resources](https://docs.icn.global/icn-economics/service-providers/access-fees) page. *** ## Capacity Allocation When an Builder submits a capacity request, the ICN protocol automatically assigns the request to the most suitable ScalerNode (SN) within the cluster where multiple HPs coexist. This process ensures that Builders are allocated storage efficiently and that HPs are compensated fairly for the resources they provide. ### How Capacity is Allocated * Pre-Assignment: The protocol pre-assigns the requested storage to a ScalerNode based on several key factors: * Reservation Price: HPs set a minimum price (Reservation\_Price) for every ScalerNode they provide. * Cluster-Level Allocation: The protocol allocates ScalerNodes at the cluster level, meaning Builders do not select individual HPs. Instead, the network assigns a ScalerNode that meets the requirements requested. \\ *** ## Builders Responsibilities As participants in the Impossible Cloud Network (ICN), Builders have certain responsibilities to ensure smooth operation and proper use of network resources. ### Ensuring Sufficient ICNT for Services: Builders must ensure they have enough ICNT tokens available for the capacity they request from Hardware Providers (HPs). Access to network resources requires an upfront provision of ICNT as access to network resources, calculated based on the amount of capacity requested and the Cluster\_Price and the duration of the booking period. ### Accurate Request Details: Builders must provide accurate details regarding the amount, location, and duration of the storage capacity needed. Incorrect information may lead to failed capacity assignments or overcharges. \\ # Access to Network Resources

Figure 1: Network Resources Flow in the ICN

This flowchart illustrates how Builders request capacity and provide ICNT tokens, which are collected in the Treasury. *** ## How Access to Network Resources are Calculated * Capacity Request: Builders submit a request specifying: * Storage amount (e.g., 1PB). * Location (Cluster) * Duration of required storage. * Pre-Assignment and Price Calculation: * Cluster Price: The price within a cluster is determined based on HP reservation prices * Max Cluster Price: A cap to ensure that pricing within clusters remains fair and accessible. * Final ICNT Requirement Calculation: * After pre-assignment, the ICN protocol calculates the total ICNT requirement that an Builders must provide, factoring in the protocol margin. * Formula:\ \ $$\text{ICNT Requirement} = (1 + \text{Protocol Margin}) \times \text{Cluster Price} \times \text{Booked Capacity} \times \text{Period}$$ * where: * Cluster Price is the rate per TB per month * Booked Capacity is the amount of storage requested (in TB) * Period is the number of months the storage is needed * Protocol Margin is a percentage retained by the protocol (e.g., 25%) to keep the network sustainability and maintenance.\ \ **Example**: If a Builder requests 1 PB of storage for 1 month and the selected Cluster Price is 2.8 ICNT per TB per month, with a Protocol Margin of 25%, the final ICNT access requirement will be:\ \ $$\text (1 + 0.25) \times 2.8 \times 1,000 \times 1 = {3,500 ICNT}$$ *** ## Distribution of Builders ICNT Access Requirements The ICNT provided by Builders is collected in the Treasury. Allocations from the Treasury to various parts of the network are determined by governance decisions to ensure the network's smooth operation and adaptability: * **Reward Reserve**: Based on governance decisions, a portion of the ICNT incoming to the Treasury are reallocated to the Reward Reserve. This reserve is responsible for distributing ICNT rewards to Hardware Providers (HPs) and HyperNodes for their services. * **Protocol Treasury**: Another portion of the ICNT, as decided by governance, is allocated to the Protocol Treasury. This allocation supports network upkeep, development, and future use cases. *** For more information about how Builders interact with the network, see the[ Capacity Allocation](/icn-economics/service-providers/capacity-allocation) page. # Capacity Allocation In the Impossible Cloud Network (ICN), Builders can request and allocate storage capacity across the network, allowing them to access decentralised cloud services efficiently. The allocation of capacity is handled automatically by the ICN protocol, ensuring that the best-suited Hardware Providers (HPs) within a cluster are selected to meet the Builder’s needs.

Figure 1: Capacity Allocation in the Impossible Cloud Network (ICN)

This flowchart illustrates the capacity allocation process in the ICN. Builders submit a request for capacity, which the protocol automatically evaluates and assigns based on several criteria such as reservation price, commitment period, and availability. The assignment proceeds through hierarchical levels, starting with clusters and then individual ScalerNodes (HNs). The entire process is automated through smart contracts, ensuring efficient and reliable capacity allocation without manual intervention. *** ## Hierarchical Layers for Resource Allocation ScalerNodes within the Impossible Cloud Network are grouped based on a multi-layer hierarchical structure, providing efficiency and flexibility when assigning resources. These layers are structured to ensure that Builders receive the necessary resources, with assignment decisions being based on established rules within the smart contract. ### Hierarchical Layers * **Region**: The broadest geographical classification, such as Europe West (EUW). * **Cluster**: Each zone is divided into clusters, which group together several hardware nodes (HNs). Clusters, such as FRA-1 or FRA-3, are responsible for handling capacity assignments. Each hierarchical level serves a specific purpose in the ICN's infrastructure, enabling optimized allocation, pricing, and performance. From a protocol perspective, nodes within each cluster are treated as interchangeable. The protocol handles both reward/fee logic and assignment logic at the cluster level. *** ## How Capacity Allocation Works ### Pre-Assignment by the Protocol The ICN protocol assigns capacity from an HN that meets the requested criteria. The assignment is based on several factors: * **Reservation Price**: Each HP sets the reservation price for their ScalerNodes * **Cluster-Level Pricing**: If multiple HPs meet the criteria, the protocol compares their prices and assigns the booking to the HP with the most favourable price $$ \text{Cluster Price}=\min(\text{Unit Price}, \text{Max Cluster Price}) $$ ### Capacity Allocation Across Network Layers **Cluster-Level Assignment**: Capacity is always assigned at the cluster level, meaning the protocol selects the best-suited ScalerNode within the same cluster. At no point can a Builder select a specific HP or hardware node directly; all selections are made by the ICN protocol based on performance, pricing, and availability. ### Capacity and Time Durations Capacity can always be secured for up to 6 months in advance with a minimum time duration of 3 months. However, each Builder can extend this period to secure capacity requests that are farther in the future if the HP is willing to take on the additional price risk. As Builders provide ICNT for reserved capacity upfront, the access fee is fixed at the time of booking. This means that for longer request periods and times farther in the future, the price risk shifts increasingly towards the protocol and ultimately to the HP that fulfills the capacity request. ### Reading Available Capacity & Price * Builders can query the protocol to read available capacity and current prices for various clusters * Based on the query results, Builders can decide which capacity they want to book at the listed price. ### Single-Transaction Booking Once the Builder has identified the desired capacity, they submit a booking transaction directly to the protocol. This transaction includes: * The selected capacity details (e.g., Cluster ID, desired size in PB). * The total ICNT cost based on the listed price of the capacity at the time of booking. The protocol, via smart contract, will: * Validate that the specified capacity is still available. * Confirm that all transaction fields, including price, are correct. If all criteria are met, the booking is confirmed, and the ScalerNode is allocated to the Builder. ### Automatic Assignment & Allocation The smart contract handles all resource allocation based on the specified booking. It will: * Assign the resources automatically based on the Builder’s selection. * Make any necessary decisions about resource assignment where multiple nodes within a cluster may fulfill the request. Once assigned, the ScalerNode is reserved for the Builder, and the transaction is completed. ### No Manual Checks or Confirmations The entire process is automated by the smart contract, without the need for protocol-level checks or intermediate confirmations. After the transaction is accepted, the capacity is immediately booked, and no further steps are required from the Builder. # Hardware Providers (HPs) ## **Introduction to Hardware Providers (HPs)** **Hardware Providers (HPs)** are the backbone of the **Impossible Cloud Network (ICN)**, responsible for providing the essential resources—such as storage and compute capacity—that power the network. By supplying these resources, HPs enable Builders and users to access ICN's decentralised cloud services. HPs are rewarded with ICNT tokens for their contributions. These rewards are designed to incentivise HPs to maintain high performance standards, comply with performance requirements, and commit to the network over the long term by locking collateral. The structure of these rewards also encourages the growth of the network during its initial stages and ensures efficient, high-quality service as the network matures.

Figure 1: Hardware Provider (HP) Subsystem in the ICN
This flowchart illustrates the interactions and mechanisms of Hardware Providers (HPs) within the Impossible Cloud Network (ICN). HPs provide critical storage and compute resources and lock collateral to secure their commitment. They receive ICNT rewards through Utilisation Rewards based on booked capacity and Base Rewards, which are time-limited subsidies to encourage early network participation. HPs can also receive external collateral through the Delegation mechanism. If HPs fail to meet performance standards, slashing occurs, affecting both their own and any delegated collateral.

*** ## **Capacity and Collateral Requirements** **Hardware Providers (HPs)** must meet specific collateral requirements to contribute their storage and computing power to the ICN. Collateral acts as a security measure, ensuring that HPs remain committed to their obligations and perform their duties reliably. It also protects the network against disruptions caused by poor performance or non-compliance. #### Collateral Requirements * **Node Collateral**: HPs are required to lock collateral based on their expected monthly reward. This collateral must be fully provided to participate in the network, and 100% of HP rewards are diverted until the Node Collateral requirement is fully satisfied. Once fully collateralised, any additional overcollateralisation can be used by HPs to expand their capacity at no extra cost. * **Network Collateral**: Network Collateral is proportional to the storage capacity offered by the HP and must be provided to support the network’s stability. If Network Collateral falls below the required threshold, rewards are diverted to fill the gap based on specific percentages, depending on the level of undercollateralisation. Overcollateralisation results in increased reward multipliers. HPs must lock their collateral for an initial period of 36 months, with the option to extend this period. Longer commitment periods result in higher reward multipliers, providing further incentives for HPs to remain committed to the network. ### **Overcollateralisation & Undercollateralisation** * **Overcollateralisation**: HPs that provide more collateral than required can expand their capacity. Overcollateralisation is a signal of reliability and stability, benefiting both the HP and the network. * **Undercollateralisation**: If HPs fall below the required collateral threshold, they are considered undercollateralised, and a percentage of their rewards is diverted to meet the collateral requirements until compliance is achieved. Depending on the extent of undercollateralisation, different percentages of rewards are redirected. **Hardware Providers (HPs)** must meet **Node Collateral** and **Network Collateral** requirements to contribute resources to the **Impossible Cloud Network (ICN)**. * **Node Collateral**: Ensures the reliability of each hardware node. Collateral must be six times the monthly reward and is locked for at least 36 months. If undercollateralised, 100% of HP rewards are diverted until compliance is restored. * **Network Collateral**: Calculated as 30% of the total unlocked ICNT supply, based on the node's share of the network's capacity. Collateral can be self-provided or delegated. Rewards are diverted if undercollateralised, though this will not happen in the initial phase HPs may extend their commitment period in 6-month increments, improving their reward potential. **Overcollateralisation** allows HPs to expand their capacity, while undercollateralisation results in reward diversion until requirements are met. For more detailed information on collateral and how it impacts HP rewards, visit the[ Collateral](/icn-economics/hardware-providers-hps/collateral) page. *** ## Delegation & ICN Link The ICN system allows external delegators to help HPs meet their collateral requirements through a delegation mechanism. This creates a collaborative ecosystem where both HPs and external delegators benefit from network growth. The ICN system allows external delegators to help HPs meet their collateral requirements through delegation and the ICN link mechanism. This creates a collaborative ecosystem where both HPs and external delegators benefit from network growth. ### ICN Link The ICN Link allows token holders to stake their ICNL tokens in support of Hardware Providers (HPs). In practice, these staked ICNL tokens represent an equivalent amount of locked ICNT (vICNT) under the hood, which serves as the effective collateral. By meeting the collateral requirements on behalf of HPs, stakers help maintain network reliability. In return, they are eligible to receive rewards based on factors such as overall network participation. ### Delegation of Collateral Users who do not possess an ICN Link can still delegate collateral by providing their ICNT tokens to HPs. This mechanism parallels the ICNL staking process, allowing ICNT holders to participate in collateral provisioning. Rewards for these delegations are similarly calculated based on the amount delegated. Delegation carries risks. For more information, visit the[ Delegation](/icn-economics/hardware-providers-hps/collateral/delegation) page. *** ## **Reward System for HPs** HPs are rewarded based on their capacity contributions and their level of commitment to the network. The rewards system is designed to encourage high performance, reliable services, and long-term participation. **Reward Types** * **Utilisation Rewards**: HPs earn Utilisation Rewards based on how much of their capacity is used by Builders. These rewards are tied to the Cluster Price, which depends on the capacity booked within a cluster. The more that an HP's capacity is utilised, the higher the rewards they will receive. Utilisation Rewards are self-sustaining and covered by the access contributions provided by Builders. * **Capacity Rewards**: Capacity Rewards are a time-limited protocol subsidy designed to bootstrap new network regions or hardware classes. Capacity Rewards help HPs earn rewards even during the early stages of network growth when utilisation is low. Over time, these rewards fade out to encourage self-sustainability. For detailed information on HP rewards, see the[ HP Rewards](/icn-economics/hardware-providers-hps/hp-rewards) page. *** ## **Slashing & Penalties** To maintain the integrity of the network, HPs must comply with the key performance thresholds that ensure uptime. When an HP fails to meet these obligations, their collateral—both their own and any delegated collateral—may be subject to slashing. **When Slashing Occurs** * **Behaviour Violations**: If an HP fails to meet service requirements, such as experiencing downtime, the protocol may slash a portion of the HP's locked collateral. For more information, visit the[ Slashing page](/icn-economics/hardware-providers-hps/collateral/slashing). *** ## **Technical Requirements for HPs** To operate as a **Hardware Provider (HP)** within the **Impossible Cloud Network (ICN)**, HPs must meet specific technical requirements, including hardware specifications and geographic distribution considerations. For full details on these technical requirements, refer to the[ Contribute Hardware](/icn-participation/contribute-hardware) page, which outlines the necessary hardware and steps to become an HP. For more information on the network hierarchy and how HPs are organised geographically, visit the[ Network Architecture](/network-architecture/scalernode-network) page. # HP Rewards Hardware Providers (HPs) play a critical role in the Impossible Cloud Network (ICN), and the rewards structure is designed to incentivize their contribution effectively. The ICN reward system encourages strong growth in network capacity, fosters high utilisation, and ensures HPs maintain high service standards.

Figure 1: Flow of HP Rewards in the ICN Network

The ICN reward system for HPs is split into two main categories: * **Utilisation Rewards**: Based on actual usage by Builders, rewarding HPs for the capacity they actively contribute to the network. * **Capacity Rewards**: A temporary subsidy designed to bootstrap new network capacity, gradually decreasing as utilisation rises to sustainable levels. This flowchart illustrates how **Hardware Providers (HPs)** earn rewards within the **Impossible Cloud Network (ICN)**. The rewards structure is influenced by several factors, including **Access Contributions** provided by **Builders**, **commitment periods**, and **collateralisation levels**. Rewards are split into two categories: **Utilisation Rewards**, which are generated based on actual usage and **Access Requirements**, and **Capacity Rewards**, which are temporary incentives for capacity contribution and regional utilisation. These rewards are summed and adjusted with a **Reward Multiplier**, resulting in the **Total HP Rewards**. *** ## Utilisation Rewards Utilisation Rewards are provided to HPs based on the actual use of their hardware resources by Builders. This aligns rewards with network activity, encouraging HPs to provide capacity at competitive rates. Reward Formula: $$ \text{Utilisation Reward (ICNT)} = \text{Cluster Price} \times \text{Booked Capacity} \times \text{Period} $$ **Self-Sustaining Model**: Utilisation rewards are fully covered by Builder Access Requirements.\ \ **Competitive Incentive**: HPs within a cluster can adjust their prices to compete for Builder capacity requests. The cluster price is defined as: $$ \text{Cluster Price}=\min(\text{Unit Price}, \text{Max Cluster Price}) $$ *** ## Capacity Rewards Capacity Rewards are a temporary subsidy designed to bootstrap new network capacity in early stages of growth. They are distributed to **Hardware Providers (HPs)** regardless of the utilisation of their resources, helping support the network during its initial phase. * **Definition**: The Capacity Reward is an incentive provided to HPs to ensure capacity is available, even when utilisation is low. * **Reward Scaling**: * **Subsidy for New Capacity**: Aimed at incentivizing capacity growth in new network regions. * **Based on Capacity Contribution**: HPs receive rewards proportional to the capacity they provide to the network. * **Scaled by Regional Utilisation**: The reward level adjusts depending on how much of the capacity is being used within a region. * **Decreases Over Time**: Capacity Rewards gradually taper off as regional utilisation improves and the network becomes self-sustaining. * **Decreases with Token Price Increases**: When ICNT appreciates significantly, rewards are dynamically adjusted downward via the Market Adjustment Factor (MAF) to avoid excessive issuance. $$ \begin{align\*} \text{Capacity Rewards Per SN }(t) &= \text{SN CapacityShare} \times (1 - \text{Region Utilization}(t)) \\ &\quad \times \text{Bootstrap Release}(t) \times \text{MAF} \\ \\ \text{SN Capacity Share} &= \frac{\text{SN Capacity}}{\text{Region Target Capacity}} \\ \\ \text{Region Utilization}(t) &= \frac{\text{Region Booked Capacity}}{\text{Region Target Capacity}} \\ \\ \text{Region Booked Capacity} &= \text{Capacity Booked in a Region} \\ \\ \text{Region Target Capacity} &= \text{Region-Specific Target Capacity Parameter} \\ \\ \text{Bootstrap Release}(t) &= \text{Region Max Release} \times \left(1 - \frac{t}{48} \right) \\ \\ \text{Region Max Release} &= \text{Region-Specific MaxRelease Parameter} \\ t &= \text{Month (1 to 48)} \end{align\*} $$ | Region | Region Target Capacity, TB | Region Max Release, ICNT/TB/month | Max Cluster Price (ICNT/TB/month) | | ------- | -------------------------- | --------------------------------- | --------------------------------- | | POL-WAW | 50,000 | 5.60 | 1.40 | | DEU-FRA | 100,000 | 6.44 | 1.40 | | NLD-AMS | 100,000 | 6.44 | 1.40 | | DNK-CPH | 100,000 | 6.44 | 1.40 | | GBR-LON | 100,000 | 6.44 | 1.40 | | USA-NYC | 100,000 | 6.44 | 1.40 | * **Purpose**: The capacity rewards aim to attract HPs during the network’s growth phase, providing incentives for expanding capacity until the network reaches a sustainable level of utilisation. ### Market Adjustment Factor (MAF) To avoid misaligned rewards during significant price shifts, **Capacity Rewards** are corrected using the **Market Adjustment Factor**, which adjusts rewards based on fortnightly price movements. MAF is updated every 28 days, only if the volatility threshold is triggered. Volatility threshold: $$ \left| \frac{P\_t - P\_{\text{ref},t}}{P\_{\text{ref},t}} \right| > k \cdot \sigma\_{28d} $$ Where: $$ \begin{aligned} & P\_t && \text{: current price} \\ & P\_{\text{ref},t} && \text{: price at last MAF update} \\ & \sigma\_{28d} = \sqrt{ \frac{1}{27} \sum\_{i=0}^{27} \left( r\_{ i} - \bar{r}*{28d} \right)^2 } && \text{: 28-day standard deviation of daily log returns} \\ & \quad r*{i} = \log\left(\frac{P\_{i}}{P\_{i - 1}}\right) && \text{: daily log return on day } i \\ & \quad \bar{r}*{28d} = \frac{1}{28} \sum*{i=0}^{27} r\_{i} && \text{: average log return over last 28 days} \\ \ & P\_{\min}= $0.36 && \text{: minimum recovery anchor} \\ & k=3&& \text{: sensitivity multiplier} \end{aligned} $$ The update mechanism if the volatility threshold is met is defined as: **Price Increase — Suppress MAF** $$ \text{If } P\_t > P\_{\text{ref},t}: \mathrm{MAF}*{t+1} = \left( \frac{\max(P*{\text{ref},t}, P\_{\min})}{P\_t} \right) \cdot \mathrm{MAF}\_t $$ #### Price Decrease — Recover MAF $$ \text{If } P\_t < P\_{\text{ref},t}: \mathrm{MAF}*{t+1} = \left(1 - \frac{P\_t - P*{\min}}{\max(P\_{\text{ref},t}, P\_{\min}) - P\_{\min}} \right) \cdot (1 - \mathrm{MAF}\_t) + \mathrm{MAF}\_t $$ > If the price drops to or below the defined recovery floor ($0.36), the MAF is fully restored to 1.0. This mechanism ensures that the protocol remains adaptive to market conditions while protecting the ICNT reserve from unsustainable depletion. Current MAF : 1.0 *** ## **Payout Timing** All earned HP rewards are **disbursed with a one-month delay** (≈ 30 days after the end of each accrual period) to allow for metric verification, dispute resolution, and any applicable slashing adjustments before funds are released. *** ## Slashing & Penalties To maintain network integrity, **slashing** is enforced in cases where HPs fail to meet their commitments, including downtime, performance quality violations **When Slashing Occurs** * **Collateral at Risk**: HPs put up Node Collateral as a guarantee of their service. * **Slashing Events**: Triggered by service failures or breaches of performance thresholds, slashing can apply to both the HP’s own collateral and any delegated collateral. For more detailed information on the slashing mechanism and its consequences, visit the[ Slashing](https://docs.icn.global/icn-economics/hardware-providers-hps/collateral/slashing) section. *** ## Rewards for HPs At the end of the commitment period, HPs have the option to either withdraw or recommit their collateral, enabling them to maintain eligibility for rewards. \\ # Collateral ## Collateral Overview Collateral is a foundational requirement for Hardware Providers (HPs) within the Impossible Cloud Network (ICN). It ensures HP reliability and safeguards the network by holding HPs accountable for their performance. ### What is Collateral? Collateral consists of ICNT tokens locked by HPs, proportional to their provided storage capacity. Tokens remain locked for the entire commitment period, signifying HPs' dedication to fulfilling network obligations. ### Purpose of Collateral * **Network Reliability**: Ensures accountability, penalising HP underperformance via slashing. * **Long-Term Commitment**: Encourages sustained participation, enhancing network stability. *** ## Collateral Requirements Collateral is categorised into Node Collateral and Network Collateral. ### Node Collateral Directly provided by HPs to guarantee node reliability. Calculated as: $$ \text{Node Collateral} = (\text{Reward per Petabyte} \times \text{Capacity (PB)}) \times 6 $$ * **Initial Requirement**: 100% upfront. * **Undercollateralisation**: 100% of HP rewards diverted until fully collateralised. ### Network Collateral Ensures overall network stability, calculated as: $$ \text{Network Collateral} = \left(\frac{\text{Node Capacity}}{\text{Network Capacity}}\right) \times \text{Total Unlocked Supply} × 0.5 $$ * Provided by HPs or external delegators. * ICNT Collateral providers (HPs and delegators) earn additional staking APY based on total network collateralisation. *** ## Commitment Periods * **HP Commitment**: Initially 36 months, extendable in increments of 6 months. * **Delegator Commitment**: Regular ICNT holders can delegate for a minimum of 1 day, allowing flexibility. *** ## Overcollateralisation & Undercollateralisation ### Node Collateral * **Undercollateralisation**: Full reward diversion until the requirement is satisfied. * **Overcollateralisation**: Allows HPs to add additional capacity without needing extra collateral. ### Network Collateral * **Undercollateralisation**: Triggers proportional reward diversion (initially 0% during early protocol stages). *** ## Delegation Delegation allows ICNT holders and ICN Link holders to provide Network Collateral to HPs, sharing network rewards and fostering decentralisation. ### External Delegators #### **ICN Link Holders** * **Locked Token Delegation (vICNT)**: Delegation permitted during the vesting period. * **Post-Maturation Delegation**: Once tokens mature into ICNT, they can delegate as regular ICNT holders. #### **Regular ICNT Holders** * **Liquid Token Delegation**: ICNT can be directly delegated to HPs. * **Minimum Delegation Period**: 1 day, after which tokens can be re-delegated or withdrawn. *** ## Slashing and Penalties Collateral may be slashed due to performance violations; specifically downtime ensuring HP accountability. ### Triggering Events * Service downtime * Performance threshold violations *** ## Withdrawal and Recommitment Collateral remains locked for the entire commitment duration. Upon expiry: * **Withdrawal**: Full collateral becomes available. * **Recommitment**: HPs may extend commitments in 6-month increments. *** ## Staking APY for Network Collateral ICNT providers receive a staking subsidy (APY). The APY depends on two factors: * **Total Tokens Staked (TTS)**: A higher percentage of total tokens staked results in a lower APY. * **Commitment Duration**: The APY rates below reflect a commitment period of 4 years. Shorter commitment periods will result in lower APYs. *** ### APY Formula The base APY is calculated using a convex interpolation formula: $$ APY(S) = \left(1 - \left( \frac{S}{T\_S} \right) ^ p \right) \cdot APY\_{\text{start}} + \left( \frac{S}{T\_S}\right)^p\cdot APY\_{\text{end}} $$ Where: * $$S$$ is the current staking ratio (from 0 to 1) * $$T\_S$$ is the target stake (e.g., 0.5 for 50%) * $$p$$ is the curvature exponent * $$APY\_{\text{start}}$$ is the APY when $$S=0$$ * $$APY\_{\text{end}}$$ is the APY when $$S = T\_S$$ *** #### Commitment Duration Scaling To reward longer commitments, a scaling factor is applied to the base APY $$ \text{ScalingFactor}(\tau\_{\text{stake}})=0.01\cdot\left(\frac{C\_1 \cdot \tau\_{\text{stake}}+C\_2}{\tau\_{\text{stake}}+C\_3}\right) $$ Where: * $$\tau\_{\text{stake}}$$ is the commitment duration in days * $$C\_1 = 153; C\_2=925; C\_3 = 950$$ are constants calibrated to approximate an exponential curve This rational formula was chosen to approximate exponential growth while remaining efficient for on-chain implementation. *** ### Final APY The final APY is calculated as: $$ APY\_{\text{final}}(S,\tau\_{stake}) = APY(S)\cdot\text{ScalingFactor}(\tau\_{\text{stake}}) $$ This mechanism ensures that staking rewards scale down as total participation increases, while boosting incentives for long-term contributors.
| Total Staked (TTS %) | APY at 4-Year Commitment (%) | | -------------------- | ---------------------------- | | 0% | 110.00% | | 5% | 40.59% | | 10% | 30.27% | | 15% | 23.54% | | 20% | 18.42% | | 25% | 14.24% | | 30% | 10.68% | | 35% | 7.57% | | 40% | 4.80% | | 45% | 2.29% | | 50%+ | 0.00% | \\ # Delegation ## **Delegation** Delegation within the Impossible Cloud Network (ICN) enables token holders to contribute Network Collateral to Hardware Providers (HPs). This mechanism allows external participants to support HPs in meeting their collateral obligations, earning shared rewards and staking incentives in return. ***

Figure 1: Delegation Process Flowchart

This flowchart illustrates the delegation process in the ICN. Delegators (including ICN Link holders with locked vICNT and regular ICNT holders) provide tokens as Network Collateral through automated smart contracts. Delegators receive a portion of HP rewards and an additional staking subsidy, with tokens becoming available for withdrawal or re-delegation at the end of their chosen delegation period. *** ## How Delegation Works Delegation involves two primary categories: * **ICN Link Holders**: * **Delegating Locked Tokens (vICNT)**: Holders can delegate locked tokens (vICNT) during the lock-up period to provide Network Collateral to HPs. * **Transition to Regular Delegation**: Once tokens mature into ICNT, holders can recommit these as regular ICNT. * **Regular ICNT Holders**: * **Delegating Liquid Tokens**: Regular ICNT holders can delegate tokens directly as Network Collateral to HPs. * **Flexible Commitment Period**: Minimum delegation duration is 1 day, with longer periods available to enhance rewards. Delegated tokens are secured through automated smart contracts, ensuring that Network Collateral remains locked according to the delegator's chosen commitment period. *** ## Rewards for Delegators Delegators earn rewards based on the share of HP rewards they help secure, combined with a staking subsidy (APY): * **Reward Share from HPs**:\ The specific percentage is set by the HPs and can be from 0 to 100% * **Additional Staking Subsidy (APY)**:\ All Network Collateral contributors (delegators and HPs) receive an additional staking reward. The APY depends on: * **Total Tokens Staked (TTS)**: Higher total staked amounts across all staking participants reduce the APY. * **Commitment Duration**: Longer commitments significantly increase staking rewards, with maximum rewards available at 4-year commitments. This reward structure incentivises long-term delegation, reinforcing network stability and supporting HP operations. *** ## Withdrawal and Re-delegation Delegators can choose to withdraw or re-delegate their tokens at the end of their selected lock-up period: * **Re-delegation**: Extend support to the same or another HP to continue earning rewards. * **Withdrawal**: Tokens become available for withdrawal once the delegation period concludes, subject to any slashing penalties applied during the period. Delegated tokens remain at risk if the HP fails to meet their Network Collateral obligations or performance standards. *** ## Incentives for Hardware Providers Delegation provides substantial benefits to HPs, helping them to: * **Expand Network Capacity**: Delegated collateral allows HPs to increase capacity without needing to lock additional ICNT themselves. * **Optimise Collateral Requirements**: HPs can efficiently manage their financial commitments by attracting external collateral providers, allowing for greater flexibility and network growth. This structure encourages continuous HP participation, supporting overall network expansion and reliability. # Slashing Slashing is a penalty mechanism within the Impossible Cloud Network (ICN), designed to ensure that Hardware Providers (HPs) consistently meet network standards. If an HP violates their obligations, a portion of their locked collateral is slashed, protecting network reliability and incentivising consistent performance. ### How Slashing Works Slashing penalties are triggered by Service Downtime, detected by Hypernodes. ### Slashing Timeline Slashing operates on an era-based system. Collateral remains exposed to slashing from the moment of staking (Era E-2) until slashing has been evaluated and executed (end of Era E+1). ### Slashed Collateral Usage Slashed collateral is transferred to the Protocol Treasury. For additional details, refer to the Collateral and Delegation pages. # ICN Link ## **Introduction to ICN Link** **ICN Links** are integral to the **Impossible Cloud Network (ICN)**. They can be staked to **HyperNodes** whose role is to monitor **Hardware Providers (HPs)** and verify that these providers meet the network’s performance standards. > **Why ICN Link matters**\ > • A HyperNode can only operate when **at least one ICN Link (ICNL)** is delegated to it.\ > • Delegating ("staking") an ICN Link starts the ICNT reward schedule that is attached to that Link.\ > • The Link holder keeps full control and can re‑delegate to another HyperNode at any time. This means HyperNodes supply the monitoring work, but the **ICN Link is the asset that secures it, earns and routes the rewards.**

Figure 1: HyperNodes in the ICN

This flowchart illustrates the role of HyperNodes within the Impossible Cloud Network (ICN). HyperNodes monitor Hardware Providers (HPs) and submit reports on performance. Although they perform the monitoring, any ICNT rewards go to the ICNL stakers who delegate their stake to these HyperNodes. Any further distribution of rewards is outside the scope of the core ICN mechanics. *** ### HyperNode Responsibilities #### Performance Monitoring HyperNodes continuously measure HP uptime, latency, and other key performance indicators to confirm compliance with network standards. #### Reporting Performance Violations If an HP falls below threshold, the HyperNode submits a report. These reports decide whether HPs keep their incentives or face penalties and help maintain accountability across the network. Persistent failure to report — or inaccurate reporting — triggers penalties for the HyperNode itself *** ### Incentives and Rewards (per ICN Link) Each ICN Link carries a time-to-live (TTL) curve. This TTL curve is a **48‑month ICNT distribution schedule** and will begin when the ICN Protocol goes live. When rewards are active and you stake an ICN Link to a HyperNode, you will earn rewards from the TTL. As long as you are staked you will be actively earning on the curve. If you are not staked, any periods of the TTL that were missed are forever lost. The table below shows how the total reward is released over time. Percentages are relative to the Link’s maximum claimable rewards. | Months | % of Total | | Months | % of Total | | ------ | ----------- | - | ------ | ----------- | | 0 | 15 % | | 25 | 1.70 % | | 1–3 | 3.40 % each | | 26–28 | 1.49 % each | | 4–6 | 3.19 % each | | 29–31 | 1.28 % each | | 7–9 | 2.98 % each | | 32–34 | 1.06 % each | | 10–12 | 2.76 % each | | 35–36 | 0.85 % each | | 13–15 | 2.55 % each | | 37–42 | 0.64 % each | | 16–18 | 2.34 % each | | 43–48 | 0.43 % each | | 19–21 | 2.13 % each | | | | | 22–24 | 1.91 % each | | | | **Performance modifier** – If the delegated HyperNode misses its monitoring obligations, the current month’s ICNT for that Link is reduced, and repeated issues can shorten the Link’s remaining term. ### **Payout Timing** Except for the initial **Month 0** reward (paid immediately), all subsequent ICNL rewards are **released three months after they are earned**. The delay allows time for performance verification, dispute resolution, and any applicable slashing before funds are distributed. ### Penalties & Slashing * **Missed / inaccurate SIA Reports** → reduced ICNT for the affected month. * **Ongoing non‑compliance** → the validity period of delegated Links can be shortened (e.g., –3 months). * **Restoration** – Once issues are resolved, the Link resumes earning its scheduled monthly amounts. The result is a balanced system: **ICN Link holders** earn rewards while choosing reliable operators, and **HyperNodes** are incentivised to maintain high performance. ### Related Topics * **Delegated Staking with Hardware Providers** – ICN Links can also be used as collateral for HPs. Details are in the [Delegation guide](/icn-economics/hardware-providers-hps/collateral/delegation).