Acurast (ACU)

Acurast (ACU): Smartphone-Based Compute With On-Chain Scheduling and Staking

Acurast is building a decentralized cloud system that assigns serverless workloads to smartphone-based processors. ACU pays for network activity, supports staking and governance, and exists across the Acurast mainnet and several bridged networks.

What Acurast is designed to provide

Acurast presents itself as a decentralized compute network in which developers deploy applications, APIs, scheduled jobs, bots, and other workloads to a pool of smartphone-based processors. Its documentation describes hardware-backed Trusted Execution Environments, or TEEs, as a way to make execution confidential and verifiable rather than relying only on the operator’s reputation. The project’s white paper frames the system as a decentralized serverless cloud, but those security and scale properties remain partly dependent on the specific hardware, runtime, and implementation used for each deployment.

The intended users fall into three groups: developers that need compute, providers that operate supported phones, and token holders that stake or delegate ACU. Developers can use the project’s command-line tools and software development kits, while providers install and register processors. This makes Acurast closer to a compute marketplace and orchestration network than to a general-purpose blockchain alone.

How deployments are matched and executed

Acurast separates its consensus, execution, and application layers. The consensus layer records deployments, handles matching, and maintains processor reputation. The Matcher pairs a developer’s resource requirements with available processors and can support different price-discovery methods. A deployment records the code or instructions, scheduling details, resource requirements, and destination for the output.

The documented execution flow moves from registration to processor acknowledgment, assignment, execution, fulfillment, and reporting. A processor may run a workload for a developer’s own hardware, a selected processor, or the public processor pool. The output can be delivered to another blockchain or to a Web2 destination such as a REST API. The design therefore depends on more than chain consensus: processor availability, the selected runtime, destination-chain settlement, and the accuracy of post-execution reporting all affect the final result.

The role of secure hardware and runtimes

The execution layer is modular rather than tied to one runtime. Acurast documents an Acurast Secure Hardware Runtime, or ASHR, and an Acurast Zero-Knowledge Runtime, or AZKR. ASHR is intended to use secure hardware for confidential execution, while the project describes zero-knowledge execution as an alternative source of additional soundness guarantees. The practical security model therefore varies by workload and runtime; the existence of a TEE claim does not by itself establish that every deployment has identical confidentiality or availability properties.

The public code footprint includes an Acurast Substrate chain, protocol-specific pallets, a command-line deployment tool, and related processor-management components. The Substrate repository identifies the network as a Cumulus-based parachain and lists marketplace and core Acurast pallets. This supports the description of Acurast as its own blockchain-coordinated compute system rather than merely an application deployed on Ethereum or another host chain.

What ACU does

ACU is the native utility token of the Acurast network. According to the project documentation, it is used for network transactions, deployment-related costs, staking, provider rewards, collator rewards, cross-chain transfers, and governance. The architecture documentation adds an important detail: compute costs are paid as gas, while processors receive rewards through staking and benchmark pools rather than a simple direct payment from each developer to each processor.

The token is native to the Acurast mainnet and is also represented on Ethereum, BNB Chain, Base, and peaq through documented bridged or LayerZero-based instances. The official contract list identifies separate addresses for those networks and warns users to rely only on the contracts listed in the project documentation. Cross-chain use adds operational dependencies: users must distinguish native ACU from bridged versions and use the correct route for deposits, withdrawals, and settlement.

Staking, inflation, and provider incentives

Acurast uses a Staked Compute model in which providers commit hardware capacity and stake ACU, while token holders can delegate without operating a processor. The project’s tokenomics documentation describes 5% annual inflation, with 70% directed to the Staked Compute Pool, 10% to benchmark rewards, 15% to the treasury, and 5% to collators. The same documentation says the inflation parameters can be changed through governance, so the stated schedule should be treated as a current protocol design rather than an immutable monetary guarantee.

Provider performance is measured through benchmark metrics and execution activity. A provider can receive a deployment execution bonus for running workloads, while failure to maintain committed capacity can make the provider slashable. The documented maximum slash rate is small per epoch, but both the provider and delegators share the slashing exposure. This creates a direct dependency between token staking outcomes and the reliability of physical devices, connectivity, and provider operations.

Governance and practical limits

Acurast Mainnet uses an OpenGov-style referendum system based on Substrate’s referenda and conviction-voting pallets. ACU holders can increase voting power by locking tokens for longer periods. However, the current documentation says there is one Root track and that only council members can submit new referenda. That means token-holder voting exists, but proposal access is more concentrated than a system in which any holder can directly initiate every governance action.

The main unresolved questions concern execution quality at scale, hardware trust assumptions, processor concentration, bridge and contract risk, and the relationship between real compute demand and token inflation. Project documentation reports large network and processor figures, but those figures are project-reported and are not treated here as independent proof of paid usage or service reliability. Developers also need to assess whether smartphone hardware, supported runtimes, destination-chain integrations, and public processor availability meet the requirements of their particular workload.

Key takeaways

• Acurast coordinates serverless workloads across smartphone-based processors rather than relying solely on centralized data centers.
• Its architecture separates consensus, execution, and application layers, with a Matcher assigning deployments to processors.
• ACU is used for network fees, deployment-related costs, staking, provider and collator rewards, and governance.
• Native ACU and bridged ACU are different network instances, so contract and bridge verification matters.
• Staked Compute links token rewards and slashing exposure to the reliability of physical devices and their operators.
• Current governance documentation describes token-holder voting but limits referendum submission to council members.

Risks and open questions

• TEE-based confidentiality depends on supported hardware, runtime implementation, firmware, and the assumptions of each deployment; it is not a blanket guarantee for every workload.
• Public processor availability and reliability may vary by geography, device type, connectivity, and operator concentration.
• ACU has a stated annual inflation schedule, and the documentation says parameters can be changed through governance.
• Users face native-versus-bridged token, bridge, contract, and destination-chain settlement risks across the supported networks.
• Delegators share slashing exposure with providers when committed compute capacity is not maintained.
• Project-reported processor, transaction, and adoption figures require continued independent assessment and do not alone establish commercial demand.