# Acurast Documentation
> Complete reference documentation for Acurast - the Real Decentralized Compute Network powered by smartphones.
This file contains all documentation content in a single document following the llmstxt.org standard.
## Acurast Orchestrator
The Acurast Orchestrator is a centerpiece of the consensus layer, combining the orchestration (i.e., the scheduling of deployments and enabling the liquid matching) of the Processor’s computational resources and Developers. The orchestrator plays an essential role in the definition, agreement, and enforcement of value exchange between processors and developers.
The orchestrator is where the liquid matching engine pairs the advertised processor resources with the defined requirements of the developers. The orchestrator natively supports various price-finding mechanisms (e.g., auctions and advertisements), making Developer Experience (DevEx) highly accessible and seamless.
Every agreement between processor and developer is specified in an entity called deployment. The deployment specifies (i) a set of instructions that are executed on the processor, (ii) its scheduling parameters, and (iii) the destination configuration (i.e., where the output is further processed or persisted).
## Compute Costs & Rewards
When scheduling a deployment, the developer defines the compute cost for the execution. The cost can be defined in native cACU/ACU tokens. This mechanism allows for deterministic financial planning of executions for developers.
:::info
**All compute costs are paid as gas (transaction) fees. There is no direct reward flow from developers to processors.**
:::
Instead, processors earn rewards through the **[staking pools](/staked-compute/overview)**. When processors execute deployments, they receive a [Deployment Execution Bonus](/processors/rewards#deployment-execution-bonus): a bonus weight on their Benchmark Metrics that increases their scoring—and therefore their share of rewards—in both the Staked Compute Pool and the Compute Pool (Base Benchmarking Rewards) for that epoch. This mechanism ensures processors are incentivized to execute deployments and burn gas fees.
---
## Application Layer
In the Internet of today, almost every application relies heavily on auxiliary systems. Whether external APIs are used for authentication, basic infrastructure (hosting), data availability, reliance, which can benefit from extending or replacing services and core elements with confidential applications, essentially eliminating a host of threat events. The possibilities with Acurast are near-endless since today's centralized Internet is heavily centralized both logically and in terms of trust anchors.
## Use Case Examples
Acurast's architecture transforms the way applications are designed and deployed. Acurast achieves an unparalleled Developer Experience (DevEx) by offering the [Acurast Hub](https://hub.acurast.com) to developers, where a self-service model allows developers to integrate and develop their applications. The following subsections outline potential algorithms and use-cases that can be deployed in a confidential manner through Acurast.
### Zero-Knowledge Proof Applications
Zero-Knowledge Proof protocols find vast application in blockchains [[1]](#references). Potential use cases range from anonymous voting systems [[2]](#references), to secure and privacy-preserving digital assets exchange, secure remote biometric authentication, or Proof-of-Reserves [[3]](#references).
Acurast can be leveraged in multiple areas of ZKP applications, for instance, to offload high intensity computation in a confidential manner [[4]](#references), or to form sub-consortia of processors that can, for instance, mix and generate proofs that the mixing has been performed correctly.
### Privacy-Preserving Mixing
With ZKPs, privacy mixing can occur in a way that allows transactions to be validated without exposing the details of those transactions. However, the mixing is not limited to Web3 transactions and can be extended to other data sensitive to privacy (_e.g.,_ metadata of internet traffic or metadata of files).
### Secure Multi-Party Computation
Secure Multi-Party Computation (SMPC) is a cryptographic primitive that enables distributed parties to conduct joint computations without revealing their own private inputs and outputs to the computation [[7]](#references). For instance, doctors may query a database containing private information, or banks may invest in a fund that must satisfy both banks private constraints. Usually, one trusted entity must know the inputs from all the participants, however, if no Trusted Third Party (TTP) is available or suitable, privacy concerns are evident [[7]](#references). With Acurast, a processors can be selected for SMPC algorithms to execute _e.g.,_ a permissionless poker game [[8]](#references).
### Blockchain Infrastructure
Blockchain networks' rising adoption and complexity of blockchain networks has led to an increasing need for a reliable blockchain infrastructure. Novel incentive structures (_e.g.,_ slashing in PoS) have intensified this further. It is crucial that this infrastructure is neither logically nor physically centralized because it would introduce new trust assumptions that undermine the permissionless nature of blockchains. For these services, Acurast can serve as a decentralized, serverless backend.
### Incorruptible Sequencer
A huge issue in public blockchains is Blockchain Extractable Value (BEV), and Miner Extractable Value (MEV), where DeFi users are at risk of being attacked [[9]](#references) (_e.g.,_ frontrunning and sandwich attacks [[10]](#references). With Acurast, processors can serve as confidential and confidential sequencers, ensuring that the order of transactions is deterministic and immune to external influence.
### Beyond Oracles: Serverless Applications
Oracles and on-chain automation are key ingredients of blockchain infrastructure. While oracles enable external data to be imported into the blockchain, oracles mainly deal with data retrieval and validation, ensuring that accurate and reliable data is fed into smart contracts. However, on-chain automation has a broader scope, encompassing automated liquidity provision, periodic settlements, debt restructuring, yield harvesting, and much more. The emphasis here is on action and execution based on specific conditions.
On-chain automation is about executing predefined actions without manual intervention, based on conditions or triggers that may come from oracles or on-chain data and events.
### Native Cross-Chain DeFi
Native cross-chain DeFi capabilities have been developed to allow seamless interactions and transactions between blockchains, creating a more inclusive and expansive financial ecosystem. Applying Account Abstraction allows for the design of accounts that can interact and integrate across various platforms and protocols, simplifying user experiences and opening the door for innovative use cases.
### Data Availability as-a-Service
(DAaaS) provides decentralized storage solutions to ensure data remains accessible and intact, fortifying the robustness of the entire decentralized ecosystem.
### Decentralized Scraping Infrastructure
Of all the Internet traffic in 2022, 47.4 % was automated traffic, also commonly referred to bots [[5]](#references). Of that automated traffic, 30.2 % were bad bots, while good bots are on the rise too, accounting for 17.3 %. The percentage of human traffic continues its downward trend, from 57.7 % in 2021 to 52.6 % in 2022. Bots, in that context do not refer to volumetric Distributed Denial-of-Service attacks, but the bot activity on layer 7 of the OSI model. In general, good bots are important for various business models and applications, since they are scraping data and feed models for decision making or business logic directly.
With Acurast, the scraping infrastructure can be fully decentralized logically and physically, leveraging the network of processor resources that confidentially execute these tasks, without leaking any data about the querying party. For example, when intelligence is gathered (_e.g.,_ for investment or merger decisions), a large amount of data must be scraped confidentially.
### Artifical Intelligence
The recent surge of Artificial Intelligence (AI) applications has led to increased research and development in these areas. While the potential of these technologies are vast, the risks associated to the centralized deployment and privacy of data is crucial to assess carefully. In Acurast, the _Singularity_ module allows the execution of AI in a decentralized and confidential fashion. _E.g.,_ Acurast enables Large Language Models (LLM) to be executed in a federated, privacy-preserving, and trustless way [[11]](#references).
### Internet of Things
In general terms, the Internet of Things (IoT) refers to interconnected computing devices that form a network and monitor environmental variables (_e.g.,_ health care [[12]](#references). Often, due to its limited resources, heterogeneity, and lack of computing power, IoT faces many security and privacy challenges. Data is transferred between IoT devices without human intervention, making confidentiality an essential aspect in network and trust management. The Acurast _Mesh_ module creates space for novel IoT use cases. Depending on the processor used, built-in Bluetooth modules or WiFi direct connections can be used to collect metrics or data and confidentially process the data.
#### References
[1] X. Sun, F. R. Yu, P. Zhang, Z. Sun, W. Xie, and X. Peng, _A Survey on Zero-Knowledge Proof in Blockchain,_ IEEE Network, Vol. 35, No. 4, pp. 198–205, 2021.
[2] C. Killer, M. Eck, B. Rodrigues, J. von der Assen, R. Staubli, and B. Stiller, _ProvotuMN: Decentralized, Mix-Net-based, and Receipt-free Voting System,_ in 2022 IEEE International Conference on Blockchain and Cryptocurrency (ICBC), 2022, pp. 1–9.
[3] C. Killer, B. Rodrigues, E. J. Scheid, M. F. Franco, and B. Stiller, _Blockchain-based Voting Considered Harmful?_ IEEE Transactions on Network and Service Management, pp. 1–1, 2022.
[4] N. Ni and Y. Zhu, _Enabling Zero Knowledge Proof by Accelerating zk-SNARK Kernels on GPU,_ Journal of Parallel and Distributed Computing, vol. 173, pp. 20–31, 2023.
[5] Imperva, “Imperva 2023 Bad Bot Report,” https://www.imperva.com/resources/resource-library/reports/2023-imperva-bad-bot-report/, May, 2023.
[6] D. C. Nguyen, M. Ding, P. N. Pathirana, A. Seneviratne, J. Li, and H. V. Poor, _Federated Learning for Internet of Things: A Comprehensive Survey,_ IEEE Communications Surveys and Tutorials, Vol. 23, No. 3, pp. 1622–1658, 2021.
[7] W. Du and M. J. Atallah, _Secure Multi-Party Computation Problems and Their Applications: A Review and Open Problems,_ in Proceedings of the 2001 Workshop on New Security Paradigms, ser. NSPW ’01. New York, NY, USA: Association for Computing Machinery, 2001, p. 13–22. Available on: https://doi.org/10.1145/508171.508174
[8] R. Kumaresan, T. Moran, and I. Bentov, “How to use bitcoin to play decentralized poker,” in Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security, Ser. CCS ’15. New York, NY, USA: Association for Computing Machinery, 2015, p. 195–206. [Online]. Available on: https://doi.org/10.1145/2810103.2813712
[9] L. Zhou, X. Xiong, J. Ernstberger, S. Chaliasos, Z. Wang, Y. Wang, K. Qin, R. Wattenhofer, D. Song, and A. Gervais, _SoK: Decentralized Finance (DeFi) Attacks,_ 2023
[10] P. Daian, S. Goldfeder, T. Kell, Y. Li, X. Zhao, I. Bentov, L. Breidenbach, and A. Juels, _Flash Boys 2.0: Frontrunning, Transaction Reordering, and Consensus Instability in Decentralized Exchanges_, 2019.
[11] D. C. Nguyen, M. Ding, P. N. Pathirana, A. Seneviratne, J. Li, and H. V. Poor, _Federated Learning for Internet of Things: A Comprehensive Survey,_ IEEE Communications Surveys and Tutorials, vol. 23, no. 3, pp. 1622–1658, 2021.
[12] S. B. Baker, W. Xiang, and I. Atkinson, _Internet of Things for Smart Healthcare: Technologies, Challenges, and Opportunities,_ IEEE Access, Vol. 5, pp. 26 521–26 544, 2017.
---
## Overview
Acurast separates the consensus, execution, and application layer (c.f., Fig. 1).
Acurast's cloud architecture transforms the way applications are designed and deployed. The modular nature allows native settlements and universal interoperability of ecosystems, i.e., Web3 → Web3 and Web3 → Web2. Ultimately, Acurast serves as a decentralized application platform that ensures the privacy and verifiability of data, without introducing new trusted entities.
Figure 1: Acurast Architecture{" "}
### Consensus Layer
The consensus layer is the permissionless foundation of Acurast, where the Orchestrator matches developer's deployments to processors, as outlined in the End-to-End flow (_c.f.,_ [End-to-End Deployment Execution](/acurast-protocol/architecture/end-to-end) ). The second core part of the consensus layer is the reputation engine (_c.f.,_ ), which as sures that the reputation scores of processors are correctly updated and incentivize honest behavior.
### Execution Layer
The Execution Layer has two significant components. The first one is composed of the different processor runtimes, namely the Acurast Secure Hardware Runtime (_c.f.,_ [ASHR](/acurast-protocol/architecture/execution-layer#acurast-secure-hardware-runtime-ashr)) and the Acurast Zero-Knowledge Runtime (_c.f.,_ [AZKR](/acurast-protocol/architecture/execution-layer#acurast-zero-knowledge-runtime)). The second key component is the Acurast Universal Interoperability Layer, which contains multiple Modules that enable native interaction with different ecosystems.
### Application Layer
The third layer is the application layer, where Web2 or Web3 applications run (\cf Sec.~\ref{sec:application_layer}). Although a host of DeFi protocols already make use of Acurast, Acurast will infuse the development of a wide range of use cases that were previously not possible to implement in a confidential and decentralized manner.
## Implementation
Acurast leverages a Substrate Runtime consisting of multiple Substrate Pallets for the Acurast Protocol (_c.f.,_ [GitHub](https://github.com/acurast) ).
---
## Consensus Layer
The Permissionless Consensus layer forms the base of the Acurast protocol and is based on a variant of the Nominated Proof-of-Stake (NPoS) algorithm [[1]](#references). Unlike traditional Proof-of-Stake (PoS) networks, there are *validators* and *nominators* in NPoS. Block validators verify transactions to be included in the next block, similar to traditional PoS block validators. The key difference is that instead of being randomly chosen, the *validator* nodes are *nominated* by another node.
In Acurast's NPoS, an unlimited amount of token holders can participate as *nominators*, backing a limited set of *validators* with their stake. Having a limited set of *validators* assures the long-term scalability of the consensus, allowing the increase of the maximum threshold through governance decisions. An unlimited set of *nominators* assure that higher value is at stake, assuring a high level of security. Due to its upgradable runtimes, consensus parameters are configurable by governance decisions, *e.g.,* The maximum number of *validators*, and the minimum amount of stake for *validators*.
The Acurast NPoS system heavily leverages nominators to ensure network integrity. Nominators and validators have multiple aligned incentives. Nominators hold a financial stake in the system, which means that they could suffer a loss if a validator acts maliciously. In addition, nominators are financially rewarded for selecting a reliable and high-performance validator. Both nominators and validators have reputational stakes, with the credibility of nominators affected by their validator choices. Finally, the limited number of validator slots in NPoS structures creates a competitive environment, pushing nominators to select the most efficient validators, but also democratizes the process, making voting power essential.
NPoS has proven to be an efficient way to achieve high levels of security, scalability, and decentralization over time. Congruent to [[1]](#references), nominators share the rewards, or eventual slashings, with the validators they nominated on a *per-staked-ACU* basis.
#### References
[1] J. Burdges, A. Cevallos, P. Czaban, R. Habermeier, S. Hosseini, F. Lama, H. K. Alper, X. Luo, F. Shirazi, A. Stewart, and G. Wood, *Overview of Polkadot and its Design Considerations,* 2020.
---
## End-to-End Deployment Execution
Acurast introduces a paradigm shift in verifiable and confidential computation, advancing the way decentralized applications are developed and deployed. To emphasize the inner workings of Acurast, the following description follows a `deployment` from definition and deployment to completion (_c.f.,_ Fig. 1).
Figure 1: End-to-End Deployment Execution{" "}
### (1) `Deployment` Registration
As a first step, developers define their `deployment` details. For example, at what destination the `deployment` should be _settled_, i.e., on which protocol the `deployment` output should be persisted (e.g., on Bitcoin Mainnet). After that, the developer can select `ready-to-deploy` templates, which can be adapted and changed to the developer's needs, or a custom `deployment` can be defined.
Depending integration level of the destination ecosystem with Acurast, the pre-payments for gas fees and rewards are settled in the native currency the developer prefers (e.g., native TEZ for Tezos or ETH for Ethereum) or in native Acurast ACU tokens.
Next, the developer must state on which processors the `deployment` should be executed, either (a) on personal processors, or (b) on selected, known processors (e.g., known trusted entities), or (c) on public processors. For (a), a processor reward is not required, since it is a permissioned setting. For (b) a reward is optional, and for (c) the liquid matching engine and the Acurast orchestrator will match processor resources with developers' `deployment`s.
In addition, more details of the `deployment` need to be declared, such as _scheduling_ parameters, including start time, end time, the interval between executions, as well as the duration in milliseconds and the maximum start delay in milliseconds. Furthermore, specific resource management parameters, such as memory usage, network requests, and storage requirements of the `deployment` need to be declared. Finally, the reward for the execution of the `deployment` should be declared, as well as the minimum reputation (only applies to (c) public processors). Then the `deployment` will be persisted on the Acurast Consensus Layer and reaches `OPEN` state (c.f., Fig. 2).
Figure 2: States of a deployment{" "}
### (2) `Deployment` Acknowledgment
Second, the processor acknowledges the `deployment` and fetches the details from the Acurast chain. Depending on the fulfillment definition of the respective `deployment`, the Merkle root of the `deployment` with proof of assignment is persisted on the target destination (e.g., on a different target chain). Now the `deployment` reaches the `MATCHED` state, and no other processors will attempt to acknowledge it.
A prerequisite for assigning the `deployment` to the processor is that the processor can execute the `deployment` in full, following the _all-or-nothing_ principle. Since `deployment`s can have different scheduling configurations (e.g., on demand, every minute, etc.). Therefore, if the processor acknowledges that all slots can be adhered to, the `deployment` reaches the `ASSIGNED` state.
### (3) `Deployment` Execution
Next, the `deployment_script` is executed in the processor runtime. In the illustrated example of Fig. 1, the execution is performed inside of the Acurast Secure Hardware Runtime (ASHR), _i.e.,_ because _confidentiality_ is ascertained by secure hardware _e.g.,_ an isolated and external coprocessor (Google's Titan M2 Chip). Other runtimes (e.g., the Acurast Zero-Knowledge Runtime (AZKR)) may provide additional soundness guarantees.
### (4) `Deployment` Fulfillment
\textbf{(4) `deployment` Fulfillment:} Once the `deployment` execution is completed, the output is delivered to the declared destination, which could be another Web3 system (e.g., Tezos, Ethereum) or a Web2 system (e.g., REST-API, FL model) that receives the output. In case of a cross-chain transaction, the processor settles the gas fees on the destination chain, since the developer has locked the necessary reward and gas fee amount up front when registering the `deployment`.
### (5) `Deployment` Reporting
After completion, the processor reports back to the Acurast Consensus Layer, more specifically to the reputation engine. If fulfillment was successful, the report contains a transaction hash of the target chain containing the fulfillment transaction. In case of failure, the report contains error messages. Finally, the `deployment` is now in `DONE` state.
To assure the reliability of the Acurast protocol, the reputation engine is continuously fed with reliability metrics, for instance right after `deployment` completion or failure.
---
## Execution Layer
Acurast's execution layer is modular, allowing the flexible selection of runtimes according to the requirements of the use-case and the `deployment`, respectively. Decoupling the execution layer from the consensus and application layer allows the long-term evolution of runtimes, avoiding dependency lock-ins. Additionally, it ensures the highest level of service and confidentiality because security models can iteratively evolve with upgrades as novel threats emerge or new requirements arise.
Acurast offers native and straightforward bootstrapping of permissioned consortia. Depending on the requirements, either _(a)_ developers can directly leverage the Acurast orchestrator to select from a public pool of processors, or _(b)_ or use dedicated processors (_e.g.,_ from trusted entities, or use developer-supported self-service processors). Such composability allows developers to customize access control and define individual trust models depending on the `deployments` that are executed.
The Acurast execution layer natively offers two runtimes, the _(1)_ Acurast Secure Hardware Runtime (ASHR) and _(2)_ Acurast Zero-Knowledge Runtime (AZKR).
### Acurast Secure Hardware Runtime (ASHR)
The Acurast Secure Hardware Runtime (ASHR) is a generic approach to achieve a confidential execution layer while assuming a timely threat model, thus ensuring the highest possible level of security. The security guarantees achieved by secure hardware are generally highly divergent, from virtual processors to on-SoC processors, and finally, to the current bleeding edge of an _external coprocessor_, which is a physically separated and independent chip, dedicated to only security-sensitive operations [[1]](#references). The current ASHR implementation is based on coprocessors provided by the Google Titan chip [[2]](#references). The Titan chip has not been compromised, unlike most secure hardware platforms. Although high-reward bug bounties[[3]](#references) and the highest zero-day vulnerability payouts[[4]](#references) do not _guarantee_ security, they are a solid indication of the security level achieved.
### Rationale on using Mobile Hardware
Smartphones are among the most complex cases when it comes to information security. Their computing power has grown to the point of being almost indistinguishable from computers, they store the most valuable personal data and are used to carry out security-sensitive activities, which make them extremely attractive targets for attackers. With such a wide-ranging threat model and the fact that the vast computing base of a modern OS cannot be fully trusted, vendors have begun to use hardware to improve the security of their systems [[1]](#references).
### On TEEs and Hardware Security
Usually, Trusted Execution Environments (TEE) are created by integrating protection mechanisms directly into the processor or using dedicated external secure elements. However, both approaches only cover a narrow threat model, resulting in very limited security guarantees. For instance, enclaves nested in the application processor provide weak isolation and weak protection against side-channel attacks. Regardless of the approach used, TEEs often lack the ability to establish secure communication with peripherals, and most operating systems run inside TEEs do not provide state-of-the-art defense strategies, making them vulnerable to various attacks. Arguably, TEEs, such as Intel SGX [[5,6]](#references) or ARM TrustZone [[7]](#references), implemented on the main application processor, are insecure, _particularly_ when considering side-channel attacks. For that reason, ASHR is based on the bleeding edge of a dedicated coprocessor.
## Acurast Zero-Knowledge Runtime
The Acurast ZKP-based Runtime (AZKR) is another approach towards achieving general-purpose verifiable computation by leveraging recursive ZKP, which can generate and aggregate proofs for any computation. While the ASHR provides a performance advantage over the AZKR, the trust model of ZK-based protocols draws its core trust assumptions from the cryptographic scheme, not hardware-based security assumptions. The ASHR can scale horizontally across different applications; the AZKR requires specific circuits, assumptions, and requirements. On the other hand, ASHR provides an isolated environment for sensitive code, optimized for efficiency. Finally, trust-wise, ASHR rely on key attestation procedures and hardware-based trust assumptions, while AZKR systems mainly rely on semi-trusted sequencers and the reliance on cryptographic soundness.
#### References
[1] P. T. Maxime Rossi Bellom, Damiano Melotti, _2021: A Titan
M Odyssey_, 2021. Available on: https://i.blackhat.com/EU-21/Wednesday/EU-21-Rossi-Bellom-2021_A_Titan_M_Odyssey-wp.pdf
[2] C. Wankhede, _What is the Titan M2 security chip in Google’s Pixel phones?_ https://www.androidauthority.com/titan-m2-google-3261547/, Jan 2023.
[3] J. Reed, _Google’s bug bounty hits $12 million: What about the risks?_ https://securityintelligence.com/news/googles-bug-bounty-hits-12-million-what-about-the-risks-2/, May 2023.
[4] ZERODIUM, _ZERODIUM Payouts for Mobiles_, https://zerodium.com/program.html
[5] S. van Schaik, A. Kwong, and D. Genkin, _SGAxe: How SGX Fails in Practice_, 2020. Available on: https://api.semanticscholar.org/CorpusID:220248073
[6] S. van Schaik, A. Seto, T. Yurek, A. Batori, B. AlBassam, C. Garman, D. Genkin, A. Miller, E. Ronen, and Y. Yarom, _SoK: SGX. Fail: How stuff get eXposed_, 2022.
[7] S. Pinto and N. Santos, “Demystifying Arm TrustZone: A Comprehensive Survey,” ACM Computing Survey, Vol. 51, No. 6, Jan 2019. Available on
https://doi.org/10.1145/3291047
---
## Instances
Acurast will bootstrap three distinct networks: (a) the Acurast Testnet, (b) the Acurast Canary, and (c) the Acurast Mainnet.
### Acurast Devnet
The test network uses tokens with no governance and no staking utility. The service level provided is for test applications and experimental Proof-of-Concepts. The Acurast Testnet provides instant update cycles, whenever the code is ready, following the philosophy “Build, Break, and Fix Faster”. Testnet updates do not require governance, the Testnet is linked to the [Rococo](https://substrate.io/developers/rococo-network/) relay network.
- [Block Explorer ↗](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Facurast-devnet-ws.prod.gke.papers.tech#/explorer)
- [Acurast Hub ↗](https://hub.acurast.com)
### Acurast Canary
The canary network uses tokens with governance and staking utility. The service level provided is for production-grade applications. Acurast Canary provides shorter update cycles than the Mainnet, and also faster releases and deprecation of features. The canary network follows quarterly update cycles with a 9-month support span. Forkless network upgrades are activated and validated through the Canary network’s governance process, and it is linked to the [Kusama](https://kusama.network/) relay network.
1. **Pre-Net**
Launched on programmer’s day September 13th, 2023. The Pre-Net launched without the governance process and has the Acurast Association’s collators producing blocks. Since there is no block reward, there will be no inflation in this phase. The purpose of this phase is to allow Developers and Processors to onboard and start exchanging their resources, all while providing a production-grade service level. During the pre-net phase, the governance and token transfers will remain disabled and no active transferring of tokens is expected at this stage.
Therefore, developers who want to build zero-trust applications can request tokens through the social engagement faucet, more on this shortly.
1. **Alpha-Net**
The purpose of this phase is to onboard external Collators and enable nominated Proof of Stake for the selection of those Collators.
Comparable to Curve’s voted escrow model, the stake weight is based on the user’s selected lock time duration of the stake provided. The exact mechanics will be outlined in a future blog post.
With the activation of the Alpha-Net, the block production will be rewarded, the rewards will be distributed from the Acurast protocol's adaptive inflation model. Sudo will remain active for this phase.
1. **Beta-Net**
This phase removes sudo and migrates governance to the active stakers and enables token transfers.
Acurast Canary will pave the road for the Acurast Mainnet launch going forward.
### Acurast Mainnet
The Acurast Mainnet uses tokens with governance and staking utility. The service level provided is for production-grade applications. The Mainnet follows yearly update cycles including features only after thorough battle testing on the Acurast Canary with a long-term support span of 5 years. The Mainnet also follows forkless upgrades activated through the Mainnet governance process and it is linked to the [Polkadot](https://www.polkadot.network/) relay network.
Launched in Q1 2026, connected to Polkadot.
---
## Acurast Collator Onboarding
This page describes the steps to take to onboard a collator on the Acurast Canary chain.
## Pre registration checks
- Make sure the node is setup with an identity as described in the [Node Setup ↗](/acurast-protocol/node-setup) guide.
- Make sure the node is fully synced.
- Make sure the node was started with the `--collator` flag.
- Make sure the node is running on hardware that meet the minimum requirements. It is possible to check by looking at the node logs when it first starts:
If the hardware is good enough, there should not be any warning log message after the benchmarks logs shown in the screenshot above.
## Set session key
A session key needs to be registered. To do that, first perform the `author_rotateKeys` RPC call in order to generate a new session key:
```bash
curl -H "Content-Type: application/json" \
--data '{
"jsonrpc":"2.0",
"method":"author_rotateKeys",
"params":[],
"id":1
}' \
http://localhost:9934
```
The output of the above command should be something like:
```json
{
"jsonrpc": "2.0",
"id": 1,
"result": "0xcc038816bd81c238bd1d163c48cea9c5e3b62899b8f193863f68268a719cca44"
}
```
> **_WARNING:_** If the node exposes the RPC port to the internet, directly or through a reverse proxy, please make sure to restart the node with the argument `--rpc-methods safe` so that RPC methods related to the collator keys cannot be called anymore. For more information, see the [RPC Deployment](https://paritytech.github.io/devops-guide/guides/rpc_index.html?#important-flags-for-running-an-rpc-node) page of the Parachain Devops guide.
Next, submit the extrinsic `session.setKeys` with the collator account to the Acurast Canary chain. The first parameter of the extrinsic call is the `result` hex string in the output of the previous RPC call.
Any tool can be used to submit the extrinsic call, the important thing is that it is submitted by the collator account.
One option is to use the [polkadotjs UI web app](https://dotapps-io.ipns.dweb.link/?rpc=wss%3A%2F%2Fpublic-rpc.canary.acurast.com#/extrinsics):
The screenshot above show how to call the `session.setKeys` extrinsic, where the first drop down menu selects the account submitting the extrinsic (in this example, the account comes from the PolkadotJS Chrome extension).
Then the `submit the following extrinsic` box, the `session` pallet and the `setKeys` extrinsic are selected. Finally, provide the arguments: first the key, which corresponds to the result of the previous RPC call, and a `0x00` for the proof argument.
## Register as candidate
Once the session key is registered, the collator can be registered as a candidate, this is done through the extrinsic `collatorSelection.registerAsCandidate`, as before, the important thing is that the extrinsic is submitted by the collator account:
If the extrinsic is submitted successfully, the collator node is now fully onboarded and should start authoring blocks within 6-12 hours.
---
## Node Setup
The recommended way to run the Acurast node is by using the published [Docker image](https://hub.docker.com/r/acurast/node-canary/tags).
## Get the chain spec
Download the Acurast chain spec from the Acurast GitHub repository:
- [Acurast Canary chain spec](https://github.com/Acurast/acurast-substrate/blob/acurast-v0.21.0/chain-specs/acurast-kusama-parachain-2239-raw.json)
- [Acurast Mainnet chain spec](https://github.com/Acurast/acurast-substrate/blob/acurast-v0.21.0/chain-specs/acurast-mainnet-parachain-3396-raw.json)
## Configure the node
Create an `acurast-node` folder. Inside this folder, the following 2 folders and file:
- `chain-specs` - place the downloaded chain spec here
- `data` - this is where the node will store its data
- `docker-compose.yml` - this is where the docker-compose configuration will be placed
In the `docker-compose.yml` file, put the following content:
For Acurast Canary:
```yml
services:
node:
image: "acurast/node-canary:acurast-v0.20.0"
command: "--chain /node/chain-specs/acurast-kusama-parachain-2239-raw.json \
--base-path /node/data \
--bootnodes /ip4/57.129.99.69/tcp/30334/ws/p2p/12D3KooWKrSDeVQ4tVQ1eGjqVAhAW3cgMQFHNCBbJrpmupEvdD4A \
--port 30334 \
--rpc-port 9934 \
--rpc-external \
--rpc-methods safe \
--rpc-cors all \
--name MyNode \ # choose an appropriate name here
--telemetry-url \"wss://telemetry.polkadot.io/submit/ 0\" \
--database=rocksdb \
--pruning=archive"
ports:
- "30334:30334"
- "9934:9934"
volumes:
- ./:/node
logging:
options:
max-size: "10m"
max-file: "3"
```
For Acurast Mainnet:
```yml
services:
node:
image: "acurast/node-mainnet:acurast-v0.20.0"
command: "--chain /node/chain-specs/acurast-mainnet-parachain-3396-raw.json \
--base-path /node/data \
--bootnodes /ip4/82.220.38.222/tcp/30335/ws/p2p/12D3KooWMJM3htCon6tQ6FzRuWkxtwEkd3i5awZitdTviWwJX3KY \
--port 30334 \
--rpc-port 9934 \
--rpc-external \
--rpc-methods safe \
--rpc-cors all \
--name MyNode \ # choose an appropriate name here
--telemetry-url \"wss://telemetry.polkadot.io/submit/ 0\" \
--database=rocksdb \
--pruning=archive"
ports:
- "30334:30334"
- "9934:9934"
volumes:
- ./:/node
logging:
options:
max-size: "10m"
max-file: "3"
```
The configuration above will start the Acurast node with the following options:
- `--chain` - specifies the chain spec file
- `--base-path` - specifies the base path for the node data
- `--bootnodes` - specifies the bootnodes to connect to
- `--port` - specifies the p2p port for the node
- `--rpc-port` - specifies the RPC port for the node
- `--rpc-external` - allows external access to the RPC interface
- `--rpc-methods safe` - allows only safe RPC methods
- `--rpc-cors all` - allows all CORS requests
- `--name` - the name of the node
- `--telemetry-url` - The telemetry URL, the node will send telemetry data to [telemetry.polkadot.io](https://telemetry.polkadot.io/#/0xce7681fb12aa8f7265d229a9074be0ea1d5e99b53eedcec2deade43857901808) under the configured `name`
- `--database=rocksdb` - specifies the database type
- `--pruning=archive` - specifies the pruning mode, change `archive` to the number of blocks to keep if you want to prune the database
## Start the node
In `acurast-node` folder and run the following command:
```bash
docker compose up -d
```
This will start the Acurast node in detached mode. You can check the logs by running:
```bash
docker compose logs -f
```
## Run a Collator
A node can be turned into a collator configuring its identity. One way to do so is to use a tool like [subkey](https://docs.rs/crate/subkey/latest).
```bash
subkey generate
```
The output of the above command is something like:
```
Secret phrase:
Network ID: substrate
Secret seed: 0x4f....
Public key (hex): 0x86....
Account ID: 0x86....
Public key (SS58): 5F7Cm8Kt57dX3SkdtYYDGdMn3yiPvC8dr3oSratmGjjLmSss
SS58 Address: 5F7Cm8Kt57dX3SkdtYYDGdMn3yiPvC8dr3oSratmGjjLmSss
```
Then configure the node with the generated key by calling the following RPC:
```bash
curl -H "Content-Type: application/json" \
--data '{
"jsonrpc":"2.0",
"method":"author_insertKey",
"params":[
"aura",
"INSERT_SECRET_PHRASE",
"INSERT_PUBLIC_KEY_HEX_FORMAT"
],
"id":1
}' \
http://localhost:9934
```
In order for the above call to succeed, the node needs to be started with `--rpc-methods unsafe`. Once the key has been registered, the node can be restarted with the `--collator` flag.
The node is now setup as a collator, but it will not start authoring blocks yet. At this stage, the Acurast team manages the list of collators that can actually author blocks.
## Collator Onboarding
### Pre registration checks
- Make sure the node is setup with an identity as described above.
- Make sure the node is fully synced.
- Make sure the node was started with the `--collator` flag.
- Make sure the node is running on hardware that meet the minimum requirements. It is possible to check by looking at the node logs when it first starts:
If the hardware is good enough, there should not be any warning log message after the benchmarks logs shown in the screenshot above.
### Set session key
A session key needs to be registered. To do that, first perform the `author_rotateKeys` RPC call in order to generate a new session key:
```bash
curl -H "Content-Type: application/json" \
--data '{
"jsonrpc":"2.0",
"method":"author_rotateKeys",
"params":[],
"id":1
}' \
http://localhost:9934
```
The output of the above command should be something like:
```json
{
"jsonrpc": "2.0",
"id": 1,
"result": "0xcc038816bd81c238bd1d163c48cea9c5e3b62899b8f193863f68268a719cca44"
}
```
> **_WARNING:_** If the node exposes the RPC port to the internet, directly or through a reverse proxy, please make sure to restart the node with the argument `--rpc-methods safe` so that RPC methods related to the collator keys cannot be called anymore. For more information, see the [RPC Deployment](https://paritytech.github.io/devops-guide/guides/rpc_index.html?#important-flags-for-running-an-rpc-node) page of the Parachain Devops guide.
Next, submit the extrinsic `session.setKeys` with the collator account to the Acurast Canary or Acurast Mainnet chain. The first parameter of the extrinsic call is the `result` hex string in the output of the previous RPC call.
Any tool can be used to submit the extrinsic call, the important thing is that it is submitted by the collator account.
One option is to use the polkadotjs UI web app:
- [Acurast Canary](https://dotapps-io.ipns.dweb.link/?rpc=wss%3A%2F%2Fpublic-rpc.canary.acurast.com#/extrinsics)
- [Acurast Mainnet](https://dotapps-io.ipns.dweb.link/?rpc=wss%3A%2F%2Fpublic-rpc.mainnet.acurast.com#/extrinsics)
The screenshot above show how to call the `session.setKeys` extrinsic, where the first drop down menu selects the account submitting the extrinsic (in this example, the account comes from the PolkadotJS Chrome extension).
Then the `submit the following extrinsic` box, the `session` pallet and the `setKeys` extrinsic are selected. Finally, provide the arguments: first the key, which corresponds to the result of the previous RPC call, and a `0x00` for the proof argument.
### Register as candidate
Once the session key is registered, the collator can be registered as a candidate, this is done through the extrinsic `collatorSelection.registerAsCandidate`, as before, the important thing is that the extrinsic is submitted by the collator account:
If the extrinsic is submitted successfully, the collator node is now fully onboarded and should start authoring blocks within 6-12 hours.
---
## Token
# Acurast Token (ACU)
## Chains and token contracts
The Acurast Token (ACU) is the native utility token of the Acurast network, powering the decentralized compute economy. Acurast is multichain in nature and the token is available on the Acurast mainnet as well as on various other blockchains and ecosystems. Deployed on its native chain, it can be bridged to Ethereum using the Acurast HyperDrive bridge and further from Ethereum to various EVM chains via LayerZero bridges.
## Overview
ACU serves multiple critical functions within the Acurast ecosystem:
* **Deployment Fees**: Submitted by developers using Acurast Compute
* **Network Fees**: Required for transaction fees on the Acurast network
* **Rewards**: Provides economic security through Staked Compute as well as Base Benchmark Rewards
* **Collator rewards**: Rewards for validators and block producers
* **Cross chain transfers**: Bridged instances of the ACU token, to be moved across various networks
## Token instances
### ACU on Acurast Mainnet
ACU is the native currency of the Acurast Mainnet, which is Substrate-based Polkadot parachain. ACU is used to pay for chain interactions and is the currency to submit for deployments and that is distributed for Staking Rewards, Base Benchmark Rewards and Collator Rewards.
### ACU on Ethereum
On Ethereum, ACU is available as an ERC20 token, deployed at [`0x216b3643ff8b7BB30d8A48E9F1BD550126202AdD`](https://etherscan.io/token/0x216b3643ff8b7BB30d8A48E9F1BD550126202AdD)
Native Acurast tokens from Acurast Mainnet can be bridged to Ethereum and back, using the bridge at [hub.acurast.com](https://hub.acurast.com).
### ACU on Binance Smart Chain (bridged)
On Binance Smart Chain, ACU is deployed as a LayerZero OFT at [`0x6EF2FFB38D64aFE18ce782DA280b300e358CFeAF`](https://bscscan.com/token/0x6EF2FFB38D64aFE18ce782DA280b300e358CFeAF)
ERC20 ACU from Ethereum can be bridged to BSC and back, using the LayerZero bridge via [stargate.finance](https://stargate.finance/) or other LayerZero frontends.
### ACU on Base (bridged)
On Base, ACU is deployed as a LayerZero OFT at [`0xc5fEd7c8cCC75D8A72b601a66DffD7A489073F0b`](https://basescan.org/token/0xc5fEd7c8cCC75D8A72b601a66DffD7A489073F0b)
ERC20 ACU from Ethereum can be bridged to Base and back, using the LayerZero bridge via [stargate.finance](https://stargate.finance/) or other LayerZero frontends.
### ACU on Peaq (bridged)
On Peaq, ACU is deployed as a LayerZero OFT at [`0x165bcb970836F83c15b22c3c1622279d97A20446`](https://peaq.subscan.io/account/0x165bcb970836F83c15b22c3c1622279d97A20446)
ERC20 ACU from Ethereum can be bridged to Peaq and back, using the LayerZero bridge via [stargate.finance](https://stargate.finance/) or other LayerZero frontends.
## Bridging pathways and platforms
Bridging ACU from and to the native Acurast Mainnet, can be done from and to Ethereum, via the [Acurast HyperDrive](/integrations#level-2) bridge.
ACU from Ethereum can then be bridged via [LayerZero](https://layerzero.network/) to and from various EVM chains. Bridging is also possible between all target chains, eg. from BSC to Base, or from Peaq to BSC. ACU will be available on commonly used LayerZero bridging interfaces, like [stargate.finance](https://stargate.finance/).
## Overview of deployed ACU token contracts and instances
:::warning CAUTION
Only token contracts listed on the official Acurast documentation are valid Acurast tokens. Beware of fake tokens sold for the purpose of deceiving users.
:::
| Chain | ChainID | Token Contract | Decimals | Symbol |
|---------------------|-------------------|--------------------------------------------|----------|--------|
| Acurast Mainnet | ParachainID: 3396 | native, no token contract | 12 | ACU |
| Ethereum | 1 (0x1) | [0x216b3643ff8b7BB30d8A48E9F1BD550126202AdD](https://etherscan.io/token/0x216b3643ff8b7BB30d8A48E9F1BD550126202AdD) | 12 | ACU |
| BSC | 56 (0x38) | [0x6EF2FFB38D64aFE18ce782DA280b300e358CFeAF](https://bscscan.com/token/0x6EF2FFB38D64aFE18ce782DA280b300e358CFeAF) | 12 | ACU |
| Base | 8453 (0x2105) | [0xc5fEd7c8cCC75D8A72b601a66DffD7A489073F0b](https://basescan.org/token/0xc5fEd7c8cCC75D8A72b601a66DffD7A489073F0b) | 12 | ACU |
| Peaq | 3338 (0xd0a) | [0x165bcb970836F83c15b22c3c1622279d97A20446](https://peaq.subscan.io/account/0x165bcb970836F83c15b22c3c1622279d97A20446) | 12 | ACU |
## ACU token on Coinlist
Since TGE, the ACU tokens for Coinlist sale participants are withdrawable to Ethereum.
## ACU token on various exchanges
Exchanges decide which instance of the Acurast token they offer. Carefully study which instance has to be deposited or can be withdrawn before transacting these tokens.
## Additional Resources
For more detailed information about the token economics and distribution, please visit the [Tokenomics](/tokenomics) page.
---
## Audits
# Security Audits
Security is a top priority for Acurast. Regular security audits are conducted security to ensure the safety and reliability the Acurast protocol, its components and infrastructure.
As the protocol and ecosystem continue to evolve, the Acurast Association is committed to conduct regular security audits across all components of the Acurast infrastructure.
The table below will be updated over time as new audits are completed, ensuring transparency and maintaining the highest security standards for users and developers.
The following table lists all finalized security audits conducted for Acurast components:
| Date | Name | Auditor | Component | Link |
| ---------- | ---------------------------------- | ----------------------------------------------------- | -------------------------------------------- | ------------------------------------------------------------------------ |
| 2025-10-23 | Acurast Chain Audit | [Monethic](https://monethic.io/) | Acurast Substrate and Pallets Audit | [View Report](/audits/20251023_Monoethic_Substrate.pdf) |
| 2025-10-23 | Acurast Token Smart Contract Audit | [inference](https://inference.ag/) | ACU ERC20 Token Contract for EVM Deployments | [View Report](/audits/20250210_InferenceAG_AcurastERC20Token.pdf) |
| 2024-03-27 | Pentest tzBTC Android App | [Compass Security](https://www.compass-security.com/) | Acurast Processor App (Android) | [View Report](/audits/20240327_Compass_Security_Processor_App_xcBTC.pdf) |
---
## Create Address
This guide explains how to create an address with [Talisman](https://www.talisman.xyz/wallet) wallet. To install the browser extensions, follow their setup instructions or checkout [their walkshrough video](https://www.youtube.com/watch?v=spSPykclJ8I).
:::info
Most wallets allow to create a generic polkadot address that is supported by Acurast, this guide focuses on the Talisman wallet.
:::
Once you created your wallet follow this steps to create an Acurast address:
1. In any view of the Talisman browser extension, choose **`Add Account`** from the sidebar and then click **`New Account`**.
2. Choose **`Polkadot`**.
3. Enter your preferred name and click **`Create ->`**.
4. The extensions will open up your newly created account and shows the name on the top-left. Open the dropdown menu next to Send/Receive and choose **`Copy address`**.
5. Choose **`Substrate (Generic)`**, filter the list to find the item if necessary.
6. In the popup, click **`Copy Address`**
Paste and store the address somewhere for later use.
7. Head over to [Acurast Faucet](https://faucet.acurast.com/) to get some funds.
---
## First App Deployment (Hub)
## Introduction
This tutorial will guide you through deploying a simple application on Acurast.
After deploying any app, you are eligible to get the reward for the "Deploy for the Rebellion" quest on the [Acurast Cloud Rebellion](https://rebellion.acurast.com/).
:::tip
For developers, reading the [First App Deployment](/developers/deploy-first-app) tutorial is recommended.
:::
### Writing the code
Code has been prepared that you can deploy. It is a simple webserver that will return a "Hello, World!" message.
The code is located here: ipfs://Qmb7sw1mH349wNJsoGWRs1HedAwVXtHPsW4YoXok15DeZL
## Deploying the Application
1. Open up the [Acurast Hub](https://hub.acurast.com/) and click on "Create Deployments".
2. You can leave the default settings and scroll down to "Deployment Code". There you click on "IPFS URL" and paste the link from above.
3. Now scroll down. You can optionally select on which processor your app will be deployed to, for example one of your own. But you can also leave it with the default option.
4. In the Execution Schedule settings, you select "One-time" and set the End time to a time in the future.
5. Scroll down and click on "Suggest Reward", then click on "Publish Deployment".
Success! You've successfully deployed your first application on Acurast!
## Verify the Deployment
Once the start time is reached, your app will be available at `https://.acu.run`. (Note: processor addresses are all lowercase.). You can find the address of the processor that runs your app in the deployment details in the Acurast Hub. Open the "Deployments" view, then click on the deployment and look at the "Assigned Processors" section. Copy the "Main Acurast Account", this is the processor address that runs your app.
---
## First App Deployment
## Introduction
This tutorial will guide you through deploying a simple application on Acurast. By the end of this guide, you'll have your first project ready and deployment up and running.
:::tip
If you prefer to jump right in, you can take a look at one of the example projects:
- [Express Server on Acurast](https://github.com/Acurast/acurast-example-apps/tree/26ebfb27b1f0bdf4a146acafa792d47c155a34d5/apps/app-webserver)
- [Fetch data from an API](https://github.com/Acurast/acurast-example-apps/tree/26ebfb27b1f0bdf4a146acafa792d47c155a34d5/apps/app-fetch).
You can either clone those repositories, or set up a blank Acurast starter project by running `npx @acurast/cli new `.
:::
## Prerequisites
- Basic knowledge of Node.js and the Command Line
## Setting up the Project
### Project Structure
The structure of a project looks exactly like a normal Node.js project:
```
├── dist
│ └── bundle.js
├── LICENSE
├── README.md
├── acurast.json
├── package-lock.json
├── package.json
├── src
│ └── index.ts
├── .env
├── tsconfig.json
└── webpack.config.js
```
There is only one file that is specific to Acurast: `acurast.json`. This file configures the deployment and is covered later in the tutorial.
### Writing the code
First, let's start by creating a simple node.js project. You can find the code of the example, including all the build steps and configurations, on [GitHub](https://github.com/Acurast/acurast-example-apps/blob/26ebfb27b1f0bdf4a146acafa792d47c155a34d5/apps/app-webserver/)
If you're interested only in the Acurast part of the tutorial, feel free to skip to the "Installing the Acurast CLI" step.
This app is a simple Express server that returns a "Hello, World!" message. This is the code of the app:
```typescript
/**
* WARNING: This subdomain is NOT secure and should not be used in production.
* Anyone can simply overwrite it with their own project and hijack requests
* This is simply for testing purposes. If you need a secure way to host your
* project, please reach out to us.
*/
const LOCALTUNNEL_SUBDOMAIN = ""; // This is the subdomain where your webserver will be available. Eg. https://example.acu.run
const LOCALTUNNEL_HOST = "https://proxy.acu.run/";
const LOCAL_PORT = 3000;
if (!LOCALTUNNEL_SUBDOMAIN) {
console.log("LOCALTUNNEL_SUBDOMAIN must be set");
process.exit(1);
}
const app = express();
app.use(express.json());
app.get("/", (req, res) => {
res.send(`Hello from Acurast!`);
});
app.listen(LOCAL_PORT, () =>
console.log(`Server listening on port ${LOCAL_PORT}!`)
);
const startTunnel = async () => {
const tunnel = await localtunnel({
subdomain: LOCALTUNNEL_SUBDOMAIN,
host: LOCALTUNNEL_HOST,
port: LOCAL_PORT,
});
console.log("Tunnel started at", tunnel.url);
};
startTunnel();
```
This code starts a webserver using express on port 3000, then starts a localtunnel tunnel to make the server publicly available.
Set the `LOCALTUNNEL_SUBDOMAIN` variable to specify where the server will be available. If set to `example`, the URL will be `https://example.acu.run`.
:::note
This localtunnel server is not secure and should not be used in production. Work is underway to make this secure by default, but if a secure way to host your project is needed now, please reach out via the community channels.
:::
### Building the project
To deploy a project to the Acurast Cloud, it needs to be bundled into a single js file. This example uses webpack. You can find the configuration in the example project on [GitHub](https://github.com/Acurast/acurast-example-apps/blob/26ebfb27b1f0bdf4a146acafa792d47c155a34d5/apps/app-webserver/)
Running `npm run bundle` will then output a single js file which includes all necessary dependencies.
The file is located in `dist/bundle.js`. It includes your code, as well as all the dependencies in a single file.
This is the file that will be deployed to the Acurast Cloud. You can run it locally with `node dist/bundle.js` to test it.
## Setting up the Acurast CLI
Now that the app is ready, the Acurast CLI needs to be set up. The CLI is a tool that allows you to deploy and manage your applications on the Acurast Cloud.
### Installation
Let's install the Acurast CLI globally using npm:
```bash
npm install -g @acurast/cli
```
To verify that the installation worked, you can run `acurast` in the terminal and it will show you the help page:
```text
tutorial % acurast
_ _ ____ _ ___
/ \ ___ _ _ _ __ __ _ ___| |_ / ___| | |_ _|
/ _ \ / __| | | | '__/ _` / __| __| | | | | | |
/ ___ \ (__| |_| | | | (_| \__ \ |_ | |___| |___ | |
/_/ \_\___|\__,_|_| \__,_|___/\__| \____|_____|___|
Usage: acurast [options] [command]
A cli to interact with the Acurast Network.
Options:
-v, --version output the version number
-h, --help display help for command
Commands:
deploy [options] [project] Deploy the current project to the Acurast platform.
init Create an acurast.json and .env file
live [options] [project] Run the code in a live code environment on a remote processor
open Open Acurast websites in your browser
help [command] display help for command
```
### Adding Acurast Config to the Project
The next step is to add the Acurast Config to the project. To do that, run the following command:
```bash
acurast init
```
This will start an interactive guide, which will create `acurast.json` and `.env` files.
```text
tutorial % acurast init
Initializing Acurast CLI
There is no .env file, creating one now...
.env file created. Visit https://github.com/Acurast/acurast-cli to learn more.
The CLI will use the following address: 5GNimXAQhayQq8m8SxJt3xQmG2L3pGzeTkHopx9iPnrS6uHP
Visit the faucet to get some tokens: https://faucet.acurast.com?address=5GNimXAQhayQq8m8SxJt3xQmG2L3pGzeTkHopx9iPnrS6uHP
No package.json file found. This is unusual. Are you sure you are in the right directory?
? Enter the name of the project: tutorial
? Should the app be run one time or in an interval? One Time
? Enter the duration (eg. 1s, 5min or 2h): 1min
? What is the bundled javascript file to run? dist/bundle.js
🎉 Successfully created "acurast.json" and ".env" files
You can deploy your app using 'acurast deploy'
```
During the setup process, default values are set for most of the parameters, and they should work well for this example. You can always open the `acurast.json` file and change the configuration there. In the [CLI Docs](https://github.com/Acurast/acurast-cli?tab=readme-ov-file#configuration-details) you will find more information about the possible configurations.
These are the files that were generated:
acurast.json:
```json
{
"projects": {
"tutorial": {
"projectName": "tutorial",
"fileUrl": "dist/bundle.js",
"network": "canary",
"onlyAttestedDevices": true,
"assignmentStrategy": {
"type": "Single"
},
"execution": {
"type": "onetime",
"maxExecutionTimeInMs": 3600000
},
"maxAllowedStartDelayInMs": 10000,
"usageLimit": {
"maxMemory": 0,
"maxNetworkRequests": 0,
"maxStorage": 0
},
"numberOfReplicas": 1,
"requiredModules": [],
"minProcessorReputation": 0,
"maxCostPerExecution": 1000000000,
"includeEnvironmentVariables": [],
"processorWhitelist": []
}
}
}
```
.env:
```text
ACURAST_MNEMONIC=bounce crack ostrich put entry comic wage all tilt nature rebel position
# ACURAST_IPFS_URL=
# ACURAST_IPFS_API_KEY=
```
### Getting ready for Deployment
To deploy the application, one more step is needed: getting some tokens from the faucet.
> [!TIP]
> You can import the mnemonic that was generated and stored in the .env file and import it in Talisman (Browser Extension) to access the same account in the [Web Console](https://hub.acurast.com/).
Let's get some tokens on your new account. You can run the `acurast deploy` command, which will check your balance, and displays the link to the Faucet page.
```text
tutorial % acurast deploy
Deploying project "tutorial"
Your balance is 0. Visit https://faucet.acurast.com?address=5GNimXAQhayQq8m8SxJt3xQmG2L3pGzeTkHopx9iPnrS6uHP to get some tokens.
```
Visit the link displayed in the CLI and follow the instructions to get some tokens. They should be available in a few seconds.
That's it! You're now ready to deploy your app.
## Deploying the Application
To deploy your application, run `acurast deploy`:
```text
tutorial % acurast deploy
Deploying project "tutorial"
The CLI will use the following address: 5GNimXAQhayQq8m8SxJt3xQmG2L3pGzeTkHopx9iPnrS6uHP
The deployment will be scheduled to start in 5 minutes 0 seconds.
There will be 1 executions with a cost of 0.001 cACU each.
❯ Deploying project (first execution scheduled in 246s)
✔ Submitted to Acurast (ipfs://Qmdk1zGq2h9SiMLUQN845rB9ii6YbpQXdFTHz3j8zXQp8C)
✔ Deployment registered (DeploymentID: 3,461)
⠇ Waiting for deployment to be matched with processors
◼ Waiting for processor acknowledgements
```
Congratulations, your deployment is now being registered in the network and executed soon! Check the CLI for more information about the deployment process.
## Verifying the Deployment
If you followed this tutorial, then your app will be available at `https://.acu.run`. ("\" is the value you set for `LOCALTUNNEL_SUBDOMAIN` in the code).
Success! You've successfully deployed your first application on Acurast!
## Bonus: Working with Secret Environment Variables
You can use secret environment variables in Acurast depoyments. The environment variables that are encrypted during deployment and only decrypted when the code is run on the processor. This is useful for storing sensitive information like API keys.
To use environment variables in your project, you first need to add them to the `.env` file. For example, let's say you have an API key that you want to keep secret. You can add it to the `.env` file like this:
```text
# .env
API_KEY=your-api-key
```
To configure which of your deployments make use of the environment variables, edit the `acurast.json` file and add all the environment variables to include in the deployment to the `includeEnvironmentVariables` array.
```json
{
"projects": {
"tutorial": {
"projectName": "tutorial",
"fileUrl": "dist/bundle.js",
"network": "canary",
"onlyAttestedDevices": true,
"assignmentStrategy": {
"type": "Single"
},
"execution": {
"type": "onetime",
"maxExecutionTimeInMs": 60000
},
"maxAllowedStartDelayInMs": 10000,
"usageLimit": {
"maxMemory": 0,
"maxNetworkRequests": 0,
"maxStorage": 0
},
"numberOfReplicas": 1,
"requiredModules": [],
"minProcessorReputation": 0,
"maxCostPerExecution": 1000000000,
"includeEnvironmentVariables": ["API_KEY"],
"processorWhitelist": []
}
}
}
```
Then, in your code, you can access the environment variables like this:
```typescript
const API_KEY = _STD_.env[API_KEY];
```
When you run `acurast deploy`, the environment variables will now automatically be added to your deployment.
If you run an interval based deployment with multiple executions, then you can even update the environment variables between executions. This is useful if you want to rotate your API keys regularly. To do that, simply update the `.env` file and run `acurast deployments -e`. This will update the environment variables for the deployment with the given ID.
## Conclusion
Congratulations! You've successfully deployed your first application on Acurast! For more advanced features and detailed documentation, refer to [Acurast CLI Documentation](https://github.com/Acurast/acurast-cli/blob/main/README.md). Also make sure to join the Telegram or Discord to be part of the community!
## More Examples
For more inspiration, check out the [Acurast Examples](https://github.com/Acurast/acurast-example-apps) with examples showing various features:
- [app-env-vars](https://github.com/Acurast/acurast-example-apps/tree/main/apps/app-env-vars)
- [external-dependencies](https://github.com/Acurast/acurast-example-apps/tree/main/apps/app-external-dependencies)
- [fetch from API](https://github.com/Acurast/acurast-example-apps/tree/main/apps/app-fetch)
- [heic to png](https://github.com/Acurast/acurast-example-apps/tree/main/apps/app-heic-to-png)
- [puppeteer](https://github.com/Acurast/acurast-example-apps/tree/main/apps/app-puppeteer)
- [telegram-bot](https://github.com/Acurast/acurast-example-apps/tree/main/apps/app-telegram-bot)
- [wasm](https://github.com/Acurast/acurast-example-apps/tree/main/apps/app-wasm)
- [webserver](https://github.com/Acurast/acurast-example-apps/tree/main/apps/app-webserver)
---
## Deployment Runtime Environment
The deployment's script running on Processors has access to the following a set of APIs.
## **Top level functions**
```javascript
/**
* Prints the given message to the console.
* @param {string} message the message to print.
*/
function print(message);
/**
* Performs an HTTP GET request.
* @param {string} url the url to connect to.
* @param {Record} headers the request's headers, for example: { 'Accept': 'application/json' }.
* @param {HttpSuccess} success the success callback function.
* @param {HttpError} error the error callback function.
*/
function httpGET(url, headers, success, error);
/**
* Performs an HTTP GET request.
* @param {string} url the url to connect to.
* @param {string} body a string representing the request's body.
* @param {Record} headers the request's headers, for example: { 'Content-Type': 'application/json' }.
* @param {HttpSuccess} success the success callback function.
* @param {HttpError} error the error callback function.
*/
function httpPOST(url, body, headers, success, error);
/**
* @callback HttpSuccess
* @param {string} payload the http request response payload as text.
* @param {string} certificate a hex string representing the server certificate.
*/
type HttpSuccess = (payload, certificate) => void;
/**
* @callback HttpError
* @param {string} message an error message.
*/
type HttpError = (message) => void;
/**
* Reads value from the environment.
* @param {string} key The key used to get the value from the environment.
* @return {string} The string value for the given key or undefined.
*/
function environment(key);
```
## **The \_STD\_ object**
At the top level, a `_STD_` object is defined. This object exposes additional functionalities.
### **Random**
```javascript
/**
* Generates random bytes.
* @return {string} Hex string representing random bytes.
*/
_STD_.random.generateSecureRandomHex();
```
### **Environment Variables**
```javascript
/**
* Environment object populated with the environment variables defined during deployment creation.
* For example, to access a variable defined with the "MY_KEY" key do: _STD_.env["MY_KEY"].
*/
_STD_.env;
```
### **App Info**
```javascript
/**
* The processor app version as a string.
*
* Example: "1.9.2-canary"
*/
_STD_.app_info.version;
```
### **Deployment Info**
```javascript
/**
* @return {DeploymentId} Object representing a deployment id.
*
* Example:
* {
* origin: {
* kind: "Acurast",
* source: "2273f64ccf6e9dc13aedf111ca19da030909374f18c6a958b8e5c64927dc7b4f"
* },
* id: "3510"
* }
*/
_STD_.job.getId();
type DeploymentId = { origin: { kind: string, source: string }, id: string };
/**
* @return {number} The slot number of this deployment.
*/
_STD_.job.getSlot();
/**
* @return {PublicKeys} Object containing the deployment specific public keys.
*
* Example:
* {
* p256: "03aa8fa2bfe5a5d6789637c3b82b322b617f8c19e29a4b7d3eede17a2583312891",
* secp256k1: "02fcf1a928bab608989a0218831efd585d1e771669756e1033c60cff4bef6f28e5",
* ed25519: "7ce9f9b96a0f898ad109a594ab2c30a1682e7e6425910427c9390fdf16b11dd6"
* }
*/
_STD_.job.getPublicKeys();
type PublicKeys = { p256: string, secp256k1: string, ed25519: string };
```
### **Device Info**
```javascript
/**
* Get the main account public key.
*
* @since 1.9.2 (version code 58)
*
* @return {string} Hex string representing the main account public key.
*/
_STD_.device.getPublicKey();
/**
* Get the main account address.
*
* @since 1.9.2 (version code 58)
*
* @return {string} String representing the main account address.
*/
_STD_.device.getAddress();
```
### **Signers**
```javascript
/**
* Signs the given payload with the secp256r1 key generated for the current deployment.
*
* @since 1.9.2 (version code 58)
*
* @param {string} payload Hex string representing the bytes to sign.
* @return {string} Hex string representing the signature.
*/
_STD_.signers.secp256r1.sign(payload);
/**
* Encrypts the given payload with the secp256r1 key generated for the current deployment.
*
* @since 1.9.2 (version code 58)
*
* @param {string} publicKey Hex string representing the receiver's public key.
* @param {string} salt Hex string representing the salt used for encryption.
* @param {string} payload Hex string representing the bytes to encrypt.
* @return {string} Hex string representing the encrypted payload.
*/
_STD_.signers.secp256r1.encrypt(publicKey, salt, payload);
/**
* Decrypts the given payload with the secp256r1 key generated for the current deployment.
*
* @since 1.9.2 (version code 58)
*
* @param {string} publicKey Hex string representing the sender's public key.
* @param {string} salt Hex string representing the salt used for encryption.
* @param {string} payload Hex string representing the bytes to decrypt.
* @return {string} Hex string representing the decrypted payload.
*/
_STD_.signers.secp256r1.decrypt(publicKey, salt, payload);
/**
* Signs the given payload with the secp256k1 key generated for the current deployment.
*
* @since 1.9.2 (version code 58)
*
* @param {string} payload Hex string representing the bytes to sign.
* @return {string} Hex string representing the signature.
*/
_STD_.signers.secp256k1.sign(payload);
/**
* Encrypts the given payload with the secp256k1 key generated for the current deployment.
*
* @since 1.9.2 (version code 58)
*
* @param {string} publicKey Hex string representing the receiver's public key.
* @param {string} salt Hex string representing the salt used for encryption.
* @param {string} payload Hex string representing the bytes to encrypt.
* @return {string} Hex string representing the encrypted payload.
*/
_STD_.signers.secp256k1.encrypt(publicKey, salt, payload);
/**
* Decrypts the given payload with the secp256k1 key generated for the current deployment.
*
* @since 1.9.2 (version code 58)
*
* @param {string} publicKey Hex string representing the sender's public key.
* @param {string} salt Hex string representing the salt used for encryption.
* @param {string} payload Hex string representing the bytes to decrypt.
* @return {string} Hex string representing the decrypted payload.
*/
_STD_.signers.secp256k1.decrypt(publicKey, salt, payload);
/**
* Signs the given payload with the ed25519 key generated for the current deployment.
*
* @since 1.9.2 (version code 58)
*
* @param {string} payload Hex string representing the bytes to sign.
* @return {string} Hex string representing the signature.
*/
_STD_.signers.ed25519.sign(payload);
```
### **Websocket**
```javascript
/**
* @param {string | string[]} url to the acurast websocket service.
* @param {WsSuccess} success the success callback.
* @param {WsError} error the error callback.
*/
_STD_.ws.open(url, success, error);
/**
* @param {WsSuccess} success the success callback.
* @param {WsError} error the error callback.
*/
_STD_.ws.close(success, error);
/**
* @param {WsHandler} handler the handler called on every incoming message.
*/
_STD_.ws.registerPayloadHandler(handler);
/**
* @param {string} recipient the public key in hex format of the recipient.
* @param {string} payload the payload to send as a hex string.
* @param {WsSuccess} success the success callback.
* @param {WsError} error the error callback.
*/
_STD_.ws.send(recipient, payload, success, error);
/**
* @callback WsSuccess
*/
type WsSuccess = () => void;
/**
* @callback WsError
* @param {string} message an error message.
*/
type WsError = (message) => void;
/**
* @callback WsHandler
* @param {WsPayload} payload the payload message.
*/
type WsHandler = (payload) => void;
type WsPayload = { sender: string, recipient: string, payload: string };
```
### **P2P**
```javascript
/**
* @param {P2PConfig} config the node configuration.
* @param {P2PSuccess} success the success callback.
* @param {P2PError} error the error callback.
*/
_STD_.p2p.start(config, success, error);
/**
* @param {P2PSuccess} success the success callback.
* @param {P2PError} error the error callback.
*/
_STD_.p2p.close(success, error);
/**
* @param {P2PMessageListener} listener the listener called on each incoming message.
*/
_STD_.p2p.onMessage(listener);
/**
* @param {P2PPeer} receiver the peer who should receive the message.
* @param {string} protocol the ID of the message protocol that should be used to transmit the message.
* @param {string} bytes the payload to send as a hex string.
* @param {P2PSuccess} success the success callback.
* @param {P2PError} error the error callback.
*/
_STD_.p2p.request(receiver, protocol, bytes, success, error);
/**
* @param {P2PMessage} request the request to which this message responds.
* @param {string} bytes the payload to send as a hex string.
* @param {P2PSuccess} success the success callback.
* @param {P2PError} error the error callback.
*/
_STD_.p2p.respond(request, bytes, success, error);
/**
* @param {string} peer the address or peer ID of the target peer to establish a connection with.
* @param {P2PConnectOptions|undefined} options an optional configuration of this call.
* @param {P2PSuccess} success the success callback.
* @param {P2PError} error the error callback.
*/
_STD_.p2p.connect(peer, options, success, error);
/**
* @param {string} peer the address or peer ID of the target peer whose connection should be terminated.
* @param {P2PSuccess} success the success callback.
* @param {P2PError} error the error callback.
*/
_STD_.p2p.disconnect(peer, success, error);
/**
* @param {string} peer the address or peer ID of the target peer to which the stream will be opened.
* @param {string} protocol the protocol to be used for the stream.
* @param {P2PStreamSuccess} success the success callback.
* @param {P2PError} error the error callback.
*/
_STD_.p2p.openOutgoingStream(peer, protocol, success, error);
/**
* @param {P2PStreamListener} listener the listener called on each incoming stream.
*/
_STD_.p2p.onIncomingStream(listener);
/**
* @param {P2PConnectedRelayListener} listener the listener called whenever a relay is connected.
*/
_STD_.p2p.onRelayConnected(listener);
/**
* @param {string} publicKey the public key from which the peer ID should be generated.
* @return {string} the peer ID.
*/
_STD_.p2p.peerIdFromPublicKey(publicKey): string;
/**
* @property {string[]} messageProtcols message protocols the node will support and use to send and receive messages.
* @property {string[]} relays a list of public nodes that will serve as a proxy helping establish connections with nodes behind NATs and firewalls.
* @property {number|undefined} idleConnectionTimeout time in milliseconds after which idle connections will be closed, defaults to 15s if not provided.
*/
type P2PConfig = {
messageProtocols: string[]
relays: string[]
idleConnectionTimeout?: number
};
/**
* @callback P2PSuccess
*/
type P2PSuccess = () => void;
/**
* @callback P2PStreamSuccess
* @param {P2PStream} stream
*/
type P2PStreamSuccess = (stream) => void;
/**
* @callback P2PError
* @param {string} message an error message.
*/
type P2PError = (message) => void;
/**
* @callback P2PMessageListener
* @param {P2PMessage} message
*/
type P2PMessageListener = (payload) => void;
/**
* @property {number|string|undefined} timeout an optional duration in milliseconds for which the client will attempt to establish a connection with the peer. If the connection is being established through a relay, the client will wait for a direct connection within the timeout period. If unsuccessful, it will fallback to the relayed connection, if available.
*/
type P2PConnectOptions = {
timeout?: number | string
}
/**
* @callback P2PStreamListener
* @param {P2PStream} stream
*/
type P2PStreamListener = (stream) => void;
/**
* @callback P2PConnectedRelayListener
* @param {string} address the address of the connected relay.
*/
type P2PConnectedRelayListener = (address) => void;
/**
* @property {P2PMessageType} type the type of the message.
* @property {string} id internal id,
* @property {P2Peer} sender the sender of the message.
* @property {string} protocol the message protocol that was used to transmit this message.
* @property {string} bytes the payload represented as a hex string.
*/
type P2PMessage = {
type: P2PMessageType
id: string
sender: P2PPeer
protocol: string
bytes: string
};
type P2PMessageType = 'request' | 'response';
type P2PPeer = { type: P2PPeerType, value: string };
type P2PPeerType = 'address' | 'peerId';
/**
* @property {string} protocol
* @property {P2PPeer} peer
* @function read reads n bytes from the stream.
* @function write writes bytes to the stream.
* @function close closes the stream.
*/
type P2PStream = {
protocol: string
peer: P2PPeer
read: P2PStreamRead
write: P2PStreamWrite
close: P2PStreamClose
};
/**
* @function P2PStreamRead
* @param {number} n the number of bytes to read from the stream.
* @return {Promise} a promise that resolves with bytes read.
*/
type P2PStreamRead = (n) => Promise;
/**
* @function P2PStreamWrite
* @param {Uint8Array | string} bytes the data to be written to the stream, provided as a `Uint8Array` or hex string.
*/
type P2PStreamWrite = (bytes) => Promise;
/**
* @function P2PStreamClose
*/
type P2PStreamClose = () => Promise;
```
### **WebView**
```javascript
/**
* @since 1.23.0 (Android)
*
* Opens a new tab in the WebView.
* @param {string} url the URL to open.
* @param {WebViewNewTabSuccess} onSuccess the success callback.
* @param {WebViewError} onError the error callback.
*/
_STD_.webview.newTab(url, onSuccess, onError);
/**
* @since 1.9.2 (Android)
*
* Closes all open WebView tabs, clears storage, cookies and eventual proxy settings.
* @param {WebViewVoidSuccess} onSuccess the success callback.
* @param {WebViewError} onError the error callback.
*/
_STD_.webview.close(onSuccess, onError);
/**
* @since 1.23.0 (Android)
*
* Gets an array of all currently open tabs.
* @param {WebViewGetTabsSuccess} onSuccess the success callback.
* @param {WebViewError} onError the error callback.
*/
_STD_.webview.getOpenTabs(onSuccess, onError);
/**
* @since 1.23.0 (Android)
*
* Configures the WebView to use a proxy server.
* @param {string} url the proxy URL.
* @param {WebViewProxyConfig|undefined} config additional proxy configuration, optional.
* @param {WebViewVoidSuccess} onSuccess the success callback.
* @param {WebViewError} onError the error callback.
*/
_STD_.webview.useProxy(url, config, onSuccess, onError);
/**
* @since 1.23.0 (Android)
*
* Resets the proxy configuration.
* @param {WebViewVoidSuccess} onSuccess the success callback.
* @param {WebViewError} onError the error callback.
*/
_STD_.webview.removeProxy(onSuccess, onError);
/**
* @since 1.9.2 (Android)
*
* Returns the debug URL of the WebView.
* @return {string} the debug URL.
*/
_STD_.webview.getDebugUrl(): string;
/**
* @since 1.23.0 (Android)
*
* @callback WebViewCloseSuccess
* @param {WebviewTab} tab the opened tab.
*/
type WebViewNewTabSuccess = (tab) => void;
/**
* @since 1.23.0 (Android)
*
* @callback WebViewGetTabsSuccess
* @param {WebViewTab[]} tabs the currently opened tabs.
*/
type WebViewGetTabsSuccess = (tabs) => void;
/**
* @since 1.9.2 (Android)
*
* @callback WebViewCloseSuccess
*/
type WebViewVoidSuccess = () => void;
/**
* @since 1.9.2 (Android)
*
* @callback WebViewCloseSuccess
* @param {string} error the error message.
*/
type WebViewError = (error) => void;
/**
* @since 1.23.0 (Android)
*
* @property {string} id the unique identifier of the WebView tab.
* @function getUrl returns the current URL of the WebView tab.
* @function getTrigger returns the trigger mode of the WebView tab.
* @function close closes the WebView tab.
* @function startRefreshLoop starts the refresh loop for the WebView tab.
* @function stopRefreshLoop stops the ongoing refresh loop for the WebView tab.
*/
type WebViewTab = {
id: string
getUrl: WebViewTabGetUrl;
getTrigger: WebViewTabGetTrigger;
close: WebViewTabClose;
startRefreshLoop: WebViewStartRefreshLoop;
stopRefreshLoop: WebViewStopRefreshLoop;
};
/**
* @since 1.23.0 (Android)
*
* @function WebViewTabGetUrl
* Returns the current URL of the WebView tab.
*/
type WebViewTabGetUrl = () => Promise;
/**
* @since 1.23.0 (Android)
*
* @function WebViewTabGetTrigger
* Returns the trigger mode of the WebView tab: 'manual' if opened via `webview.newTab` call, or 'auto' if opened automatically by one of the tabs.
*/
type WebViewTabGetTrigger = () => Promise<'manual' | 'auto'>;
/**
* @since 1.23.0 (Android)
*
* @function WebViewTabClose
* Closes the WebView tab.
* @param {WebViewCloseOptions|undefined} options
*/
type WebViewTabClose = (options) => Promise;
/**
* @since 1.23.0 (Android)
*
* @property {boolean|undefined} wholeTree whether to close the whole tree of tabs spawned by this tab or only the current one. If not provided, the default is false.
*/
type WebViewCloseOptions = {
wholeTree?: boolean;
}
/**
* @since 1.23.0 (Android)
*
* @function WebViewStartRefreshLoop
* Starts the refresh loop for the WebView tab.
*
* This action may increase resource usage, so it should be used sparingly and
* only if absolutely necessary, for example in preparation for taking a screenshot.
*
* When no longer needed, the refresh loop should be closed with `stopRefreshLoop`.
* @param {WebViewStartRefreshLoopOptions|undefined} options
*/
type WebViewStartRefreshLoop = (options) => void;
/**
* @since 1.23.0 (Android)
*
* @property {number|undefined} interval the interval of consecutive refreshes in milliseconds. If not provided, the default interval of 500 milliseconds is used.
* @property {boolean|undefined} wholeTree whether to refresh the whole tree of tabs spawned by this tab or only the current one. If not provided, the default is false.
*/
type WebViewStartRefreshLoopOptions = {
interval?: number;
wholeTree?: boolean;
}
/**
* @since 1.23.0 (Android)
*
* @function WebViewStopRefreshLoop
* Stops the ongoing refresh loop for the WebView tab.
* @param {WebViewStopRefreshLoopOptions|undefined} options
*/
type WebViewStopRefreshLoop = (options) => void;
/**
* @since 1.23.0 (Android)
*
* @property {boolean|undefined} wholeTree whether to stop ongoing refresh loops for the whole tree of tabs spawned by this tab or only the current one. If not provided, the default is false.
*/
type WebViewStopRefreshLoopOptions = {
wholeTree?: boolean;
}
/**
* @since 1.23.0 (Android)
*
* @property {string|undefined} username Proxy server username.
* @property {string|undefined} password Proxy server password.
* @property {boolean|undefined} fallback Whether to connect directly instead of using a proxy server in case of a failure. Defaults to false.
*/
type WebViewProxyConfig = {
username?: string;
password?: string;
fallback?: boolean;
}
```
### **Substrate functions**
```javascript
/**
* Calls the `fulfill` extrinsic on the target substrate chain.
* @param {string | string[]} nodes the node URL or array of node URLs.
* @param {string} payload the string representation of the fulfill payload.
* @param {object} extra an object with extra arguments. It needs to provide a `callIndex` which is the hex representation of the `fulfill` extrinsic's call index on the target substrate chain.
* @param {SubstrateSuccess} success the success callback.
* @param {SubstrateError} error the error callback.
*/
_STD_.chains.substrate.fulfill(nodes, payload, extra, success, error);
/**
* @callback SubstrateSuccess
* @param {string} operationHash the operation hash of the submitted extrinsic.
*/
type SubstrateSuccess = (operationHash) => void;
/**
* @callback SubstrateError
* @param {string[]} message an error message.
*/
type SubstrateError = (message) => void;
```
### **Substrate signer functions**
```javascript
/**
* Sets the curve type to use when signing.
* @param {'SECP256K1' | 'SECP256R1'} curveType
*/
_STD_.chains.substrate.signer.setSigner(curveType);
/**
* Signs a payload.
*
* @since 1.9.2 (version code 58)
*
* @param {string} payload Hex string to sign.
* @return {string} Hex string representing the signature.
*/
_STD_.chains.substrate.signer.sign(payload);
```
### **Substrate codec functions**
```javascript
/**
* Hashes the given string using blake2b 256 bit.
* @param {string} value
* @return {string} The blake2b hash of the input value.
*/
_STD_.chains.substrate.codec.blakeTwo256(value);
/**
* Encodes a number to the SCALE encoding.
* @param {number | string} value the number to encode.
* @param {8 | 32 | 64 | 128} bitSize the number's bit size.
* @return {string} Hex string representing the SCALE encoded number.
*/
_STD_.chains.substrate.codec.encodeUnsignedNumber(value, bitSize);
/**
* Encodes a number to the compact SCALE encoding.
* @param {number | string} value the number to encode.
* @return {string} Hex string representing the compact SCALE encoded number.
*/
_STD_.chains.substrate.codec.encodeCompactUnsignedNumber(value);
/**
* Encodes bytes to SCALE encoding.
* @param {string | ArrayBuffer} value hex string or an ArrayBuffer representing the bytes to encode.
* @return {string} Hex string representing the SCALE encoded bytes.
*/
_STD_.chains.substrate.codec.encodeBytes(value);
/**
* Encodes a boolean value to SCALE encoding.
* @param {boolean} value the boolean value to encode.
* @return {string} Hex string representing the SCALE encoded boolean.
*/
_STD_.chains.substrate.codec.encodeBoolean(value);
/**
* Encodes a substrate address to SCALE encoding.
* @param value the address to encode.
* @return {string} Hex string representing the SCALE encoded address.
*/
_STD_.chains.substrate.codec.encodeAddress(value);
/**
* Encodes a substrate address to a `MultiAddress` SCALE encoded vale.
* @param value the address to encode.
* @return {string} Hex string representing the SCALE encoded multi address.
*/
_STD_.chains.substrate.codec.encodeMultiAddress(value: string);
```
### **Substrate contract functions**
```javascript
/**
* Calls the `fulfill` extrinsic on a contract deployed on a chain integrating the substrate contract pallet (`pallet-contract`).
* @param {string | stirng[]} nodes the node URL or array of node URLs.
* @param {string} callIndex an hex string representing the call index of the `call` extrinsic of `pallet-contract`.
* @param {string} destination the contract address.
* @param {string} data the contract call arguments as an hex string.
* @param {object} extra objet containing additional arguments, it has to at least provide `refTime` and `proofSize` as string values. Additionally it can provide a `value` as a string representing the amount to transfer with the contract call, `method` as a string representing the method name to use instead of `fulfill` and `storageDepositLimit` as a string value. Example: `{ refTime: "3951114240", proofSize: "629760" }`.
* @param {SubstrateSuccess} success the success callback.
* @param {SubstrateError} error the error callback.
*/
_STD_.chains.substrate.contract.fulfill(
nodes,
callIndex,
destination,
data,
extra,
success,
error
);
/**
* Calls the `fulfill` extrinsic on a contract deployed on a chain integrating the substrate contract pallet (`pallet-contract`).
* @param {string | stirng[]} nodes the node URL or array of node URLs.
* @param {string} method a string representing the method name to call on the destination contract.
* @param {string} destination the contract address.
* @param {string} data the contract call arguments as an hex string.
* @param {object} extra objet containing additional arguments. It can provide a `blockNumber` as a string to sepcify at what lever to read from and `storageDepositLimit` as a string value.
* @param {SubstrateSuccess} success the success callback.
* @param {SubstrateError} error the error callback.
*/
_STD_.chains.substrate.contract.callView(
nodes,
method,
destination,
data,
extra,
success,
error
);
```
### **Substrate Gear functions**
```javascript
/**
* Sends a message to an active Gear program extrinsic on a chain integrating the Gear protocol.
* @param {string | stirng[]} nodes the node URL or array of node URLs.
* @param {string} callIndex an hex string representing the call index of the `gear.sendMessage` extrinsic.
* @param {string} destination the active program address.
* @param {string} data an hex string encoding the method and arguments to call on the program.
* @param {object} extra objet containing additional arguments, it has to provide `gasLimit` as a string, `value` as a string and `keepAlive` as a boolean. Example: `{ gasLimit: "2000000000", value: "0", keepAlive: true }`.
* @param {SubstrateSuccess} success the success callback.
* @param {SubstrateError} error the error callback.
*/
_STD_.chains.substrate.gear.sendMessage(
nodes,
callIndex,
destination,
data,
extra,
success,
error
);
```
### **Tezos functions**
```javascript
/**
* Calls the `fulfill` entrypoint on the Tezos Acurast Proxy contract.
* @param {string | string[]} nodes the node URL or array of node URLs.
* @param {any} payload the second argument for the `fulfill` entrypoint call on the Acurast Proxy contract. It represents a Michelson value that will be packed to bytes.
* @param {object} extra object with extra arguments, it has to at least provide the values for the `fee`, `gasLimit` and `storageLimit` as numbers. Additionally it can provide an `entrypoint` as a string to use instead of `fulfill`. Example: `{ fee: 1500, gasLimit: 3000, storageLimit: 0 }`.
* @param {TezosSuccess} success the success callback.
* @param {TezosError} error the error callback.
*/
_STD_.chains.tezos.fulfill(nodes, payload, extra, success, error);
/**
* Calls a custom entrypoint on a Tezos contract.
* @param {string | string[]} nodes the node URL or array of node URLs.
* @param {any} payload a Michelson value representing the arguments of the entrypoint being called.
* @param {object} extra object with extra arguments, it has to at least provide the values for the `fee`, `gasLimit` and `storageLimit` as numbers. Additionally it can provide an `entrypoint` as a string to use instead of `fulfill` and `destination` as a string for the contract address to use instead of the default Acurast Proxy contract. Example: `{ fee: 1500, gasLimit: 3000, storageLimit: 0 }`.
* @param {TezosSuccess} success the success callback.
* @param {TezosError} error the error callback.
*/
_STD_.chains.tezos.customCall(nodes, payload, extra, success, error);
/**
* @callback TezosSuccess
* @param {string} operationHash the operation hash of the submitted operation.
*/
type TezosSuccess = (operationHash) => void;
/**
* @callback TezosError
* @param {string[]} message an error message.
*/
type TezosError = (message) => void;
```
### **Tezos encoding functions**
```javascript
/**
* Packs the given micheline structure.
* @param value an object representing a micheline structure.
* @return {string} Hex string representing the packed value.
*/
_STD_.chains.tezos.encoding.pack(value);
/**
* Encodes the given micheline structure into a hex value that can be used as key for big map values.
* @param {object} value an object representing a micheline structure.
* @return {string} Hex string representing the script hash encoded value.
*/
_STD_.chains.tezos.encoding.encodeExpr(value);
```
### **Tezos message signing**
```javascript
/**
* Signs the given message and returns the signature.
*
* Before signing, the message is prepended with the utf8 bytes of the
* string 'acusig' and the script's ipfs hash ('acusig' + SCRIPT_HASH + message),
* then the resulting bytes are hashed with blake2b256.
*
* @param {string} message an hex string representing the bytes to sign
* @return {string} Hex string representing the signature
*/
_STD_.chains.tezos.signer.sign(message);
```
### **Ethereum functions**
```javascript
/**
* Calls `fulfill` on a ethereum contract.
*
* The `extra` argument is an object that can provide the following:
* - `methodSignature`: an optional string representing the method signature, if not provided `fulfill(bytes)` is used.
* - `gasLimit`: a string representing the transaction's gas limit, if not provided '9000000' is used.
* - `maxPriorityFeePerGas`: a string representing the transaction's maxPriorityFeePerGas, if not provided '0' is used.
* - `maxFeePerGas`: a string representing the transaction's maxFeePerGas, if not provided '0'.
*
* @param {string} url the node URL.
* @param {string} destination the contract's address.
* @param {string} payload a hex string representing the arguments for the method call.
* @param {object} extra object with extra arguments.
* @param {EthereumSuccess} success the success callback.
* @param {EthereumError} error the success callback.
*/
_STD_.chains.ethereum.fulfill(url, destination, payload, extra, success, error);
/**
* @callback EthereumSuccess
* @param {string} operationHash the operation hash of the submitted operation.
*/
type EthereumSuccess = (operationHash) => void;
/**
* @callback EthereumError
* @param {string[]} message an error message.
*/
type EthereumError = (message) => void;
/**
* @return {string} The processor's ethereum address for the current deployment.
*/
_STD_.chains.ethereum.getAddress();
```
### **Ethereum message signing**
```javascript
/**
* Signs the given message and returns the signature.
*
* Before signing, the message is prepended with the utf8 bytes of the
* string 'acusig' and the script's ipfs hash ('acusig' + SCRIPT_HASH + message),
* then the resulting bytes are hashed with Keccak256.
*
* @param {string} message an hex string representing the bytes to sign
* @return {string} Hex string representing the signature
*/
_STD_.chains.ethereum.signer.sign(message);
```
### **Ethereum ABI functions**
```javascript
/**
* Encodes the given value.
*
* @param {any} value A string, number or an array/object containing strings and numbers.
* @return {string} Hex string representing the encoded value.
*/
_STD_.chains.ethereum.abi.encode(value);
/**
* Encodes a numeric value.
*
* @param {number|string} value A number or a hex string representing a big integer.
* @param {number} bitLength A number specifying the bit length.
* @param {boolean} isNatural A boolean indicating if it is a natural number.
* @return {string} Hex string representing the encoded value.
*/
_STD_.chains.ethereum.abi.encodeNumeric(value, bitLength, isNatural);
/**
* Encodes an objects as a structure.
*
* @param {any} value A string, number or an array/object containing strings and numbers.
* @param {boolean} isDynamic A boolean indicating if it is a dynamic strucure.
* @return {string} Hex string representing the encoded value.
*/
_STD_.chains.ethereum.abi.encodeStruct(value, isDynamic);
```
### **Bitcoin functions**
```javascript
/**
* Returns the public key for the bitcoin chain.
*
* @since 1.5.0 (version code 28)
*
* @return {string} Hex string representing the public key
*/
_STD_.chains.bitcoin.getPublicKey();
/**
* Returns an extended public key for the given derivation path.
*
* @since 1.7.0 (version code 38)
*
* @param {string} version an hex string representing the bytes that will be prepended to the extended public key bytes before the base58check encoding
* @param {string} derivationPath the derivation path to use. Currently, the only valid value is "m/0/1".
* @return {string} String representing the extended public key
*/
_STD_.chains.bitcoin.getExtendedPublicKey(version, derivationPath);
```
### **Bitcoin message signing**
```javascript
/**
* Signs the given message and returns the signature.
*
* Before signing, the message is prepended with the utf8 bytes of the
* string 'acusig' and the script's ipfs hash ('acusig' + SCRIPT_HASH + message).
*
* @since 1.4.0 (version code 26)
*
* @param {string} message an hex string representing the bytes to sign
* @return {string} Hex string representing the signature
*/
_STD_.chains.bitcoin.signer.sign(message);
/**
* Signs the given message and returns the signature.
*
* @since 1.4.0 (version code 26)
*
* @param {string} message an hex string representing the bytes to sign
* @return {string} Hex string representing the signature
*/
_STD_.chains.bitcoin.signer.rawSign(message);
/**
* Hashes the given value using SHA256.
*
* @since 1.4.0 (version code 26)
*
* @param {string} value an hex string representing the bytes to hash
* @return {string} Hex string representing the sha256 hash
*/
_STD_.chains.bitcoin.signer.sha256(value);
/**
* Signs the given message with a key derived with the given derivation path and returns the signature.
*
* Before signing, the message is prepended with the utf8 bytes of the
* string 'acusig' and the script's ipfs hash ('acusig' + SCRIPT_HASH + message).
*
* @since 1.7.0 (version code 38)
*
* @param {string} message an hex string representing the bytes to sign
* @param {string} derivationPath the derivation path to use. Currently, the only valid value is "m/0/1"
* @return {string} Hex string representing the signature
*/
_STD_.chains.bitcoin.signer.signHD(message, derivationPath);
/**
* Signs the given message with a key derived with the given derivation path and returns the signature.
*
* @since 1.7.0 (version code 38)
*
* @param {string} message an hex string representing the bytes to sign
* @param {string} derivationPath the derivation path to use. Currently, the only valid value is "m/0/1"
* @return {string} Hex string representing the signature
*/
_STD_.chains.bitcoin.signer.rawSignHD(message, derivationPath);
```
### **Bitcoin utils functions**
```javascript
/**
* Derives the given extended public key.
*
* @since 1.7.0 (version code 38)
*
* @param {string} xpub a string representing the extended public key to derive
* @param {string} derivationPath the derivation path to use
* @return {string} Hex string representing the derivced public key
*/
_STD_.chains.bitcoin.utils.derivePublicKey(xpub, derivationPath);
/**
* Encodes the given bytes using base58check.
*
* @since 1.7.0 (version code 38)
*
* @param {string} value an hex string representing the bytes to encode
* @return {string} The base58check encoded value
*/
_STD_.chains.bitcoin.utils.base58CheckEncode(value);
/**
* Encodes the given bytes using base58.
*
* @since 1.7.0 (version code 38)
*
* @param {string} value an hex string representing the bytes to encode
* @return {string} The base58 encoded value
*/
_STD_.chains.bitcoin.utils.base58Encode(value);
/**
* Decodes the given base58check value.
*
* @since 1.7.0 (version code 38)
*
* @param {string} value a string representing the base58check value to decode
* @return {string} Hex string representing the decoded value
*/
_STD_.chains.bitcoin.utils.base58CheckDecode(value);
/**
* Decodes the given base58 value.
*
* @since 1.7.0 (version code 38)
*
* @param {string} value a string representing the base58 value to decode
* @return {string} Hex string representing the decoded value
*/
_STD_.chains.bitcoin.utils.base58Decode(value);
```
### **Aeternity functions**
```javascript
/**
* Calls `fulfill` on an aeternity contract.
*
* The `extra` argument is an object that can provide the following:
* - `functionName`: an optional string representing the method name, if not provided `fulfill` is used.
* - `gasLimit`: a string representing the transaction's gas limit, if not provided '25000' is used.
* - `gasPrice`: a string representing the transaction's gas price, if not provided '1000000000' is used.
*
* @since 1.3.32
*
* @param {string} url the node URL.
* @param {string} destination the contract's address.
* @param {[object]} payload an array of encoded values. The objects inside this array need to be constructed using the functions found under `_STD_.chains.aeternity.data`.
* @param {object} extra object with extra arguments.
* @param {AeternitySuccess} success the success callback.
* @param {AeternityError} error the success callback.
*/
_STD_.chains.aeternity.fulfill(
url,
destination,
payload,
extra,
success,
error
);
/**
* Returns the Aeternity address.
*
* @since 1.3.34 (version code 19)
*
* @return {string} The Aeternity address
*/
_STD_.chains.aeternity.getAddress();
/**
* @callback EthereumSuccess
* @param {string} operationHash the operation hash of the submitted operation.
*/
type AeternitySuccess = (operationHash) => void;
/**
* @callback EthereumError
* @param {string[]} message an error message.
*/
type AeternityError = (message) => void;
```
### **Aeternity data encoding functions**
```javascript
/**
* Returns an object representing an integer that can be used as payload in the `fulfill` call.
*
* @since 1.3.32
*
* @param {number | string} value a value representing an integer.
* @return {object} an object representing an integer that can be used as payload in the `fulfill` call.
*/
_STD_.chains.aeternity.data.int(value);
/**
* Returns an object representing a string that can be used as payload in the `fulfill` call.
*
* @since 1.3.32
*
* @param {string} value a string value.
* @return {object} an object representing a string that can be used as payload in the `fulfill` call.
*/
_STD_.chains.aeternity.data.string(value);
/**
* Returns an object representing bytes that can be used as payload in the `fulfill` call.
*
* @since 1.3.32
*
* @param {string} value an hex string representing the bytes.
* @return {object} an object representing bytes that can be used as payload in the `fulfill` call.
*/
_STD_.chains.aeternity.data.bytes(value);
/**
* Returns an object representing a list of objects that can be used as payload in the `fulfill` call.
*
* @since 1.3.32
*
* @param {object[]} values an array of objects that were created using the functions found under `_STD_.chains.aeternity.data`.
* @return {object} an object representing a list of objects that can be used as payload in the `fulfill` call
*/
_STD_.chains.aeternity.data.list(values);
/**
* Returns an object representing a tuple can be used as payload in the `fulfill` call.
*
* @since 1.3.32
*
* @param {object[]} values an array of objects that were created using the functions found under `_STD_.chains.aeternity.data`.
* @return {object} an object representing a tuple can be used as payload in the `fulfill` call.
*/
_STD_.chains.aeternity.data.tuple(values);
/**
* Returns an object representing a map can be used as payload in the `fulfill` call.
*
* The input value is an array of arrays of objects. The items need to be an array of size 2,
* where the first element represents a map key and the second element represents its value:
*
* _STD_.chains.aeternity.data.map([
* [_STD_.chains.aeternity.data.string("key1"), _STD_.chains.aeternity.data.string("value1")],
* [_STD_.chains.aeternity.data.string("key2"), _STD_.chains.aeternity.data.string("value2")]
* ]);
*
* @since 1.3.32
*
* @param {object[][]} values an array of arrays of objects that were created using the functions found under `_STD_.chains.aeternity.data`.
* @return {object} an object representing a map can be used as payload in the `fulfill` call.
*/
_STD_.chains.aeternity.data.map(values);
/**
* Returns an object representing an account pubkey can be used as payload in the `fulfill` call.
*
* @since 1.3.32
*
* @param {string} value a string representing an account pubkey .
* @return {object} an object representing an account pubkey can be used as payload in the `fulfill` call.
*/
_STD_.chains.aeternity.data.account_pubkey(value);
```
---
## How to run an LLM on Acurast
## Introduction
This tutorial walks you through deploying and running an LLM on Acurast.
Acurast includes a module for running LLMs. Most models from [Hugging Face](https://huggingface.co/) in the `GGUF` format are supported.
:::tip
If you prefer to jump right in, you can take a look at the example project:
- [LLMs on Acurast](https://github.com/Acurast/acurast-example-apps/tree/main/apps/app-llm)
You can either clone the repository, or set up a blank Acurast starter project by running `npx @acurast/cli new `.
:::
## Prerequisites
- Basic knowledge of Node.js and the Command Line
## Setting up the Project
### Project Structure
The structure of a project looks exactly like a normal Node.js project:
```
├── dist
│ └── bundle.js
├── LICENSE
├── README.md
├── acurast.json
├── package-lock.json
├── package.json
├── src
│ └── index.ts
├── .env
├── tsconfig.json
└── webpack.config.js
```
There is only one file that is specific to Acurast: `acurast.json`. This file configures the deployment and is covered later in the tutorial.
### Writing the code
First, let's start by creating a simple node.js project. You can find the code of the example, including all the build steps and configurations, on [GitHub](https://github.com/Acurast/acurast-example-apps/tree/main/apps/app-llm)
The app will host a local LLM server and make it available over HTTP.
```typescript
MODEL_URL,
MODEL_NAME,
STORAGE_DIR,
LOCALTUNNEL_HOST,
} from "./constants";
declare let _STD_: any;
const MODEL_FILE = path.resolve(STORAGE_DIR, MODEL_NAME);
async function downloadModel(url: string, dst: string) {
console.log("Downloading model", MODEL_NAME);
const res = await fetch(url);
if (!res.body) {
throw new Error("No response body");
}
console.log("Writing model to file:", dst);
const writer = createWriteStream(dst);
await finished(Readable.fromWeb(res.body as any).pipe(writer));
}
async function main() {
if (!existsSync(MODEL_FILE)) {
await downloadModel(MODEL_URL, MODEL_FILE);
} else {
console.log("Using already downloaded model:", MODEL_FILE);
}
console.log("model downloaded");
_STD_.llama.server.start(
["--model", MODEL_FILE, "--ctx-size", "2048", "--threads", "8"],
() => {
// onCompletion
console.log("Llama server closed.");
},
(error: any) => {
// onError
console.log("Llama server error:", error);
throw error;
}
);
const tunnel = await localtunnel({
port: 8080,
host: LOCALTUNNEL_HOST,
subdomain: _STD_.device.getAddress().toLowerCase(),
});
console.log(tunnel.url);
}
main();
```
This code first downloads a model from Hugging Face, then starts the integrated LLM server and loads it. Finally, it uses localtunnel to make the server publicly available.
:::tip
The API is compatible with the [OpenAI-like API endpoints](https://lmstudio.ai/docs/basics/server#openai-like-api-endpoints)
:::
Set the `LOCALTUNNEL_SUBDOMAIN` variable to specify where the server will be available. If set to `llm`, the URL will be `https://llm.acu.run`.
:::note
This localtunnel server is not secure and should not be used in production. Work is underway to make this secure by default, but if a secure way to host your project is needed now, please reach out via the community channels.
:::
### Building the project
To deploy a project to the Acurast Cloud, it needs to be bundled into a single js file. This example uses webpack. You can find the configuration in the example project on [GitHub](https://github.com/Acurast/acurast-example-apps/blob/main/apps/app-llm/)
Running `npm run bundle` will then output a single js file which includes all necessary dependencies.
The file is located in `dist/bundle.js`. It includes your code, as well as all the dependencies in a single file.
This is the file that will be deployed to the Acurast Cloud.
## Setting up the Acurast CLI
Now that the app is ready, the Acurast CLI needs to be set up. The CLI is a tool that allows you to deploy and manage your applications on the Acurast Cloud.
### Installation
Let's install the Acurast CLI globally using npm:
```bash
npm install -g @acurast/cli
```
To verify that the installation worked, you can run `acurast` in the terminal and it will show you the help page:
```text
tutorial % acurast
_ _ ____ _ ___
/ \ ___ _ _ _ __ __ _ ___| |_ / ___| | |_ _|
/ _ \ / __| | | | '__/ _` / __| __| | | | | | |
/ ___ \ (__| |_| | | | (_| \__ \ |_ | |___| |___ | |
/_/ \_\___|\__,_|_| \__,_|___/\__| \____|_____|___|
Usage: acurast [options] [command]
A cli to interact with the Acurast Network.
Options:
-v, --version output the version number
-h, --help display help for command
Commands:
deploy [options] [project] Deploy the current project to the Acurast platform.
init Create an acurast.json and .env file
live [options] [project] Run the code in a live code environment on a remote processor
open Open Acurast websites in your browser
help [command] display help for command
```
### Adding Acurast Config to the Project
The next step is to add the Acurast Config to the project. To do that, run the following command:
```bash
acurast init
```
This will start an interactive guide, which will create an `.env` file.
If you checked out the sample project, the `acurast.json` already exists, so this step will be skipped. You can open the `acurast.json` file and change the configuration there. In the [CLI Docs](https://github.com/Acurast/acurast-cli?tab=readme-ov-file#configuration-details) you will find more information about the possible configurations.
### Getting ready for Deployment
To deploy the application, one more step is needed: getting some tokens from the faucet.
> [!TIP]
> You can import the mnemonic that was generated and stored in the .env file and import it in Talisman (Browser Extension) to access the same account in the [Web Console](https://hub.acurast.com/).
Let's get some tokens on your new account. You can run the `acurast deploy` command, which will check your balance, and displays the link to the Faucet page.
```text
tutorial % acurast deploy --dry-run
Deploying project "app-llm"
Your balance is 0. Visit https://faucet.acurast.com?address=5GNimXAQhayQq8m8SxJt3xQmG2L3pGzeTkHopx9iPnrS6uHP to get some tokens.
```
Visit the link displayed in the CLI and follow the instructions to get some tokens. They should be available in a few seconds.
That's it! You're now ready to deploy your app.
## Deploying the Application
To deploy your application, run `acurast deploy`:
```text
tutorial % acurast deploy
Deploying project "tutorial"
The CLI will use the following address: 5GNimXAQhayQq8m8SxJt3xQmG2L3pGzeTkHopx9iPnrS6uHP
The deployment will be scheduled to start in 5 minutes 0 seconds.
There will be 1 executions with a cost of 0.001 cACU each.
❯ Deploying project (first execution scheduled in 246s)
✔ Submitted to Acurast (ipfs://...)
✔ Deployment registered (DeploymentID: ...)
⠇ Waiting for deployment to be matched with processors
◼ Waiting for processor acknowledgements
```
Congratulations, your deployment is now being registered in the network and executed soon! Check the CLI for more information about the deployment process.
## Verifying the Deployment
If you followed this tutorial, then your app will be available at `https://.acu.run`. ("\" is the value you set for `LOCALTUNNEL_SUBDOMAIN` in the code).
Success! You've successfully deployed your first application on Acurast!
## Conclusion
Congratulations! You've successfully deployed your first application on Acurast! For more advanced features and detailed documentation, refer to [Acurast CLI Documentation](https://github.com/Acurast/acurast-cli/blob/main/README.md). Also make sure to join the Telegram or Discord to be part of the community!
## More Examples
For more inspiration, check out the [Acurast Examples](https://github.com/Acurast/acurast-example-apps) with examples showing various features:
- [app-env-vars](https://github.com/Acurast/acurast-example-apps/tree/main/apps/app-env-vars)
- [external-dependencies](https://github.com/Acurast/acurast-example-apps/tree/main/apps/app-external-dependencies)
- [fetch from API](https://github.com/Acurast/acurast-example-apps/tree/main/apps/app-fetch)
- [heic to png](https://github.com/Acurast/acurast-example-apps/tree/main/apps/app-heic-to-png)
- [puppeteer](https://github.com/Acurast/acurast-example-apps/tree/main/apps/app-puppeteer)
- [telegram-bot](https://github.com/Acurast/acurast-example-apps/tree/main/apps/app-telegram-bot)
- [wasm](https://github.com/Acurast/acurast-example-apps/tree/main/apps/app-wasm)
- [webserver](https://github.com/Acurast/acurast-example-apps/tree/main/apps/app-webserver)
---
## Deployments On Demand
On demand deployments are special kind of deployments that can be used to access a processor on demand from a dapp. This is achieved by having the deployment open a websocket connection to the acurast websocket service and setup handlers to process incoming messages.
### On Demand deployment script
The snippet below shows a very simple on demand deployment script that setups a websocket connection to the acurast websocket service and registers a payload handler that just sends back the message it receives.
```javascript
_STD_.ws.open(
// open a websocket connection to the provided server
["wss://ws-1.ws-server-1.acurast.com", "wss://ws-1.ws-server-2.acurast.com "],
() => {
print("open: success");
_STD_.ws.registerPayloadHandler((payload) => {
// register a handler for incoming messages
_STD_.ws.send(payload.sender, payload.payload); // just send back the received message
});
},
(err) => {
print("open: error " + err);
}
);
```
An on demand deployment should be scheduled with a long duration since the deployment needs to continuously run in order to be able to process incoming messages.
### dApp integration
A dApp can start interacting with a running on demand deployment by integrating the [Acurast Typescript SDK](https://github.com/Acurast/acurast-typescript-sdk). See the example dapp for on how a simple integration works.
### Acurast websocket service
The Acurast websocket service is a P2P service that allows to simply send messages to clients connected to it. Clients are authenticated during the initial connection setup by signing a challenge with their private key (in case of a processor, that would be the private key specifically generated for the deployment creator).
The initial connection setup and authentication flow is as follows:
- Client sends an `init` message to the websocket service.
- Websocket service responds with a `challenge` message, providing the bytes to be signed.
- Client creates the payload to sign by concatenating the `challenge` bytes, the client public key and a 16 bytes nonce.
- Client signs the payload and responds to the challenge by sending beck the signature alongside the originally received challenge bytes, client public key and nonce.
- Websocket service verifies the signature and if it is valid accepts the connection.
After a client is authenticated, it can be addressed by specifying its public key as the recipient.
---
## FAQ
## Overall
### What is Acurast
Acurast is redefining compute by utilizing billions of smartphones – no data centers required. This verifiable, scalable, and confidential compute network enables users to run secure applications on decentralized infrastructure at scale—without compromising speed or privacy.
Acurast has already onboarded 227'181 compute units worldwide on its incentivized testnet making it the most decentralized verifiable compute network available today. This impressive amount of compute already powers mission critical workloads with high-security and AI requirements.
This isn’t just another DePIN protocol — it’s a game-changer that’s redefining how the world computes.
### How can you provide compute with your phone on Acurast?
Get started as a [Processor](/acurast-processors) on Acurast and provide compute to receive rewards, either with Lite or Core:
#### **Acurast Processor Lite**
Lite is more flexible, can be installed on your everyday phone and activated to provide compute when it’s feasible for you. [How to onboard ↗](https://youtu.be/2Pxw2u0pZ_E?si=jHPCk82QI5I7rOKA)
Install the Acurast Processor Lite application on Android or iOS to get started.
[**Google Play ↗**](https://play.google.com/store/apps/details?id=com.acurast.attested.executor.sbs.canary)
[**Apple App Store ↗**](https://apps.apple.com/kh/app/acurast-processor/id6517361921)
#### **Acurast Processor Core**
Core is meant for dedicated phones with the only purpose of providing compute to Acurast, completely locked down. [How to onboard ↗](https://www.youtube.com/watch?v=uLpBRUnmiPY)
**[Acurast Hub ↗](https://hub.acurast.com/)**
### Why is Acurast Using Mobile Phones?
When it comes to compute, phones are powerful and underestimated. These devices stand their ground in comparison with the server hardware of data centers. Still, they are more affordable in terms of acquisition cost and especially in terms of running cost due to their lower energy consumption. With your contribution, you can make them the perfect contender to disrupt the entire Compute industry.
### What are the use-case of Acurast?
Acurast enables decentralized, confidential, and scalable compute for various applications, including secure AI execution, decentralized bandwidth VPN services, automated on-chain trading strategies, and high-performance distributed computing for cost-efficient clusters, resilient website hosting, scalable zkProof generation and others.
### What wallets can I use on Acurast?
**[See the full list of supported wallets ↗](/wallets/wallet-overview)**
### What is the difference between MIST, cACU & ACU?
- MIST are points, not tokens, used to incentivize rebels via the Cloud Rebellion.
- cACU is the Acurast Canary (incentivized testnet) token.
- ACU is the native token of the Acurast Mainnet.
### How can I fund my wallet?
Acurast tokens ACU, are available on various markets, see directories like [CoinMarketCap ↗](https://coinmarketcap.com/currencies/acurast/#Markets) or [CoinGecko ↗](https://www.coingecko.com/en/coins/acurast) for a list of markets.
Depending on the type of token you get (EVM or Acurast native), you might need to bridge it first, before you can send it to the wallet you use for Acurast Mainnet. See token section: [Acurast Token](/token).
### Why is my balance decreasing sometimes?
Your balance may decrease slightly due to transaction fees when your Processor interacts with the Acurast network. Whenever the Processor reports to the chain (heartbeats, deployment acknowledgements, execution reports), minimal gas fees have to be paid, which can result in a decreasing balance. These fees are typically minimal, usually around 0.01 ACU per transaction.
### What is the cACU to ACU conversion mechanism?
#### How it works
1. User initiates conversion on Acurast Canary
2. cACU are burned on Canary
3. ACU is assigned to the account on Mainnet with a 1 to 1 ratio.
e.g., 1000 cACU = 1000 ACU
4. On Mainnet the lock can be updated once between 3 to 48 cycles:
4.1. Default: Unlocked after 48x cycles at 28 days (3.7 years) = 1 to 1 ratio
4.2. Minimum: Unlocked after 3x cycles (2.8 months) = 6.5% ACU
4.3. Example: Unlocked after 24x cycles (1.75 years) = 50% ACU
#### Features
- The Conversion window is 90 days from its Activation afterwards no Conversion can be done.
- Converted and locked ACU can be Staked in Staked Compute Pool from Day 1 of Mainnet.
⟶ Staking Rewards are transferable (not locked) and claimable every epoch (1.5h)
- Converted and locked ACU can be used to participate in on-chain Governance
- If you continue to provide compute, you'll receive ACU rewards, that are transferable, from the Compute Pool.
### Is there an Airdrop?
The Acurast Association has announced the Cloud Rebellion Airdrop with 10,000,000 ACU tokens to be distributed based on MIST☁️ collected across all seasons (24 months linear vesting).
[More details ↗](https://acurast.com/blog/announcements/the-acurast-association-is-announcing-the-cloud-rebellion-airdrop-to-reward-its-rebels/)
## Acurast Processor
### What is the difference between Acurast Processor Core and Lite?
Acurast Processor Core is meant for dedicated phones, completely locked down, and intended only to provide compute to Acurast.
Whereas Lite is more flexible, can be installed on your everyday phone and activated to provide compute when it's feasible for you.
If you have a phone that you don't need any more for anything else, go with Core.
**[Learn more about Acurast Processors ↗](/acurast-processors)**
### What Android and iOS version are required?
The Android version required is Android 12 or higher, while the iPhone must be a 6s or later.
**[Check the list of recommended phones ↗](https://docs.google.com/spreadsheets/d/1ZvzmMVey4CM2tuif_zJfWiIxH1qkgA-l7BNJMw4vh54/edit?gid=1844886586#gid=1844886586)**
### Is there a difference in rewards between Acurast Processor Core and Lite?
As long as your phone is connected to the internet, and the Processor application app is running, you get a reward. You can increase the rewards by staking your ACU tokens, see [Staked Compute](/staked-compute/overview).
Typically, Acurast Core scores 15-20% better in the benchmark tests, which will result in higher Base Benchmark Rewards and more Compute that can be committed in Staking.
Read more about the [Rewards here](/processors/rewards).
### I’m already running other Processors. Can I manage them all with one account?
Yes, most likely, you’ve connected a wallet to the Acurast Hub; follow these steps:
- Go to the Acurast Hub and select “Add New Device” to create a new QR code
- Install Acurast Processor Lite from Google Play or the Apple App Store on the phone
- Open Lite and select “Connect to Hub”
- Scan the QR code
- Complete the setup process, Lite is now connected to the Hub
### How can I tell how many heartbeats a processor has had?
The device heartbeats every 30 minutes. Scanning the blockchain allows you to look for all heartbeats, but that would take some time. To track the recent performance of your Processors, you can use the [Acurast Monitoring Bot](https://t.me/AcurastBot) on Telegram.
### Do I still get rewards if my Processor is missing heartbeats?
**[Benchmark rewards](/processors/rewards)** are distributed if one of 3 heartbeats of an epoch (roughly 90 minutes) was received on chain. This means your device can miss some heartbeats without missing out on rewards.
### Do I need to factory reset my phone?
You only need to factory reset your phone if you are onboarding a Core device. However, for Processor Lite, you can use your everyday device without factory resetting it.
Learn more about the differences between **[Core and Lite ↗](/acurast-processors)**
For step-by-step instructions on getting started, see the **[Compute Provider onboarding guide ↗](/processors/become-compute-provider)**.
## Lite
### How do I install Acurast Processor Lite?
Acurast Lite can be installed within minutes. The Acurast Processor Lite application can run on Android or iOS.
**[Follow the step-by-step installation guide ↗](/processors/become-compute-provider#for-processor-lite)**
### Android: Why do I need to setup an "Android Work" profile?
Android Work profiles are a built-in feature of Android, typically used by organizations to separate work apps and data from personal apps on the same device. This creates a secure, isolated container managed by an enterprise or organization.
The Acurast Processor Lite leverages this proven Android feature to create a secure, isolated environment for providing compute. The Work profile acts as a second profile completely independent from your private profile. By keeping your private profile separate from the one that provides compute, you'll get the best security and have no impact on your privacy.
### Android: Who manages the "Android work" profile?
You do. You're in complete control. Your device is connected to the decentralized Acurast protocol (Acurast Canary) and controlled by you. In no way do any individuals have access to your phone to install other applications in that work profile or make changes to it.
**Important Note:** During setup, you may see standard Android messages like "Your device isn't private" or "Your IT admin may see your data...". These are default warnings that appear whenever a work profile is created. In the case of Acurast, you remain in complete control - these are simply standard messages Android displays for all work profile setups.
### Android: How do I uninstall Acurast Processor Lite?
Because Lite uses the Android work profile, you’ll have to remove it completely to uninstall the app from your device.
If you have set up Lite with "Get Started" without a connection to your Acurast Hub, make sure that you backup your secret before removing the app; otherwise, you will lose access to your cACU.
Uninstalling Processor Lite:
1. Open the "Settings" with the cog on the top right on the Acurast Processor application (make sure you can see the compute status)
1. Click "Uninstall" and "Continue"
1. The Processor app in the work profile has been removed, you can now uninstall the lite app from your private profile and the work profile should be removed too (might be subject to Android version).
## Core
### How do I install Acurast Processor Core?
Acurast Processor Core is designed for dedicated Android phones. Follow the detailed installation instructions to get started.
**[Follow the step-by-step installation guide ↗](/processors/become-compute-provider#for-processor-core)**
### How to add Acurast Processor Core with NFC?
A short video by a community member onboard a device with a broken screen and an NFC.
**[NFC Onboarding ↗](https://youtu.be/lbAYV1kmV6o?si=_IbU5RfXYdlp5p-w)**
## Acurast Hub
### The "Add New Device" QR code is not showing?
When this happens, you can do two things:
- Disconnect and connect your wallet to the Hub.
- Use another browser.
---
## From Canary To Mainnet - Overview
# Acurast: Migration to Mainnet and Conversion from cACU to ACU
## Migration vs Conversion
### Migration
Migration describes the process of moving funds and processors from Canary (cACU) to Mainnet (ACU). The migration window for cACU tokens is 90 days from when Mainnet goes live. After these 90 days, tokens can NEVER again be migrated from Canary to Mainnet. Processors can always be migrated from Canary to Mainnet (but never back).
:::warning Attention
**cACU tokens from Canary can only be migrated to Mainnet within the first 90 days after Mainnet start. After 90 days they can NEVER be migrated again to Mainnet. Plan accordingly!**
:::
### Conversion
Conversion describes the process of unlocking ACU tokens, which were created by migrating cACU from Canary to Mainnet, using a time-based linear ratio system. After migrating from Canary to Mainnet (which must occur within 90 days), users' tokens are locked for a minimum of approximately 84 days before they can begin the conversion unlock process.
The conversion ratio is directly proportional to the lock time elapsed: the percentage of maximum lock time completed equals the percentage of tokens received, creating a linear relationship. Any tokens not received due to early unlocking are sent to the treasury.
Importantly, conversion-locked tokens can be staked immediately to earn liquid rewards, though unstaking is required before triggering the final conversion unlock.
### Conversion Examples
Locked for the full duration: If the maximum lock time has passed (19353600 blocks, roughly 1344 days or 3.7 years) users receive 100 ACU for 100 conversion-locked ACU.
Locked for half of the maximum duration: If only half of the time has passed (9676800 blocks, roughly 672 days or 1.8 years) users receive 50 ACU for 100 conversion-locked ACU.
Locked for 10% of the maximum time: If only 10% of the maximum lock time has passed (1935360 blocks, roughly 134 days or 0.37 years) users get 10 ACU for 100 cACU
Locked for the minimum time of 84 days: If the minimum lock time of 84 days has passed (1209600 blocks) users get 6.25 ACU for 100 cACU.
| | Blocks | Seconds | Hours | ~ Days | ~ Months (30d) | ~ Years | Ratio % |
|---|---|---|---|---|---|---|---|
| **Max Duration** | 19353600 | 116121600 | 32256 | 1344 | 44.8 | 3.73 | **100** |
| **Half duration** | 9676800 | 58060800 | 16128 | 672 | 22.4 | 1.87 | **50** |
| **10% of Max Duration** | 1935360 | 11612160 | 3225.6 | 134.4 | 4.48 | 0.37 | **10** |
| **Min Duration** | 1209600 | 7257600 | 2016 | 84 | 2.8 | 0.23 | **6.25** |
### How to migrate and convert
1. User initiates migration on Acurast Canary on the [Acurast Hub](https://hub.acurast.com/)
2. All cACU, except for a minimum existential amount, are burned on Canary
3. ACU is assigned to the same account on Mainnet with a 1 to 1 ratio (e.g., 1000 cACU = 1000 ACU)
4. Users can decide to unlock their tokens at any time after the minimum lock time has passed (1209600 blocks, roughly 84 days)
5. Upon unlocking, a conversion ratio is applied that is relative to the time passed
6. User will keep the converted amount, while the remaining amount is sent to the treasury
### Conversion lock and Staking
Conversion-locked ACU can be staked in the Staked Compute Pool starting from day one of Mainnet. All staking rewards are fully claimable and transferable, they are not locked.
To trigger the conversion unlock, all tokens must first be completely unstaked. Please note that unstaking alone does not automatically remove the conversion lock.
#### Conversion with Staking Example:
A user has 1000 cACU. The total conversion lock time is roughly 3.7 years (44.8 months). They decide to stake with a cooldown period of 2 months.
After 20.4 months (672 days) the cooldown period is triggered by the user and then the two month cooldown period starts. After a total of 22 months the stake is finalized. However, the tokens are still conversion locked. The user can now decide to stake again, or to unlock the tokens and convert them. Since they went through half the duration, if they decide to unlock them completely, a ratio of 2:1 is applied and the user would receive 0.5 ACU for each 1 cACU of their conversion locked balance.
## Migration & Conversion FAQ
#### What happens on conversion unlock to the tokens which are not distributed to the user due to preliminary unlock?
These tokens are sent to the Treasury.
#### If I get staking rewards on my conversion locked tokens, are the rewards liquid after unstaking, while the conversion locked tokens are still locked?
Yes, the the staking rewards are liquid
#### Will my rewards from Base Benchmark Rewards and Staking Rewards for running processors be locked?
No. All rewards are liquid (unless you selected autocompound in Staking, then the staking rewards are added to your locked Stake).
#### What if I want my funds and processors on a different account on Mainnet than on Canary? Can I split up accounts?
Migration strictly happens between the exact same account on Canary as on Mainnet. If you want to transfer to different accounts you need to do that BEFORE the migration. Some limitations apply:
**Transfer Processors:** Processors from one account can only be migrated as a whole from Canary to Mainnet and they will be assigned to the same manager account as before. It is possible to transfer all processors on Canary from one account to another, but only ALL processors at once and only to a fresh and unused Acurast account. You cannot split up processors between accounts, you cannot "send" processors to existing accounts that already have processors or tokens.
**Transfer Tokens:** Tokens from one account can only be migrated as a whole from Canary to Mainnet and they will be assigned to the same manager account as before. But before the Migration function is activated, token transfers will also be activated on Canary. This means you can decide to split up funds between different Canary accounts BEFORE migrating them to mainnet. Once the funds are migrated, they will be locked and cannot move again, until they are unlocked. See Conversion about the locking mechanism that kicks in after migration.
#### What is the right order to do all of this?
1. Unstake your stakes on Canary. Make sure to do that BEFORE the 90 day window ends. Unstaking comes with a cooldown of up to two days!
2. Migrate your funds from Canary to Mainnet
3. Migrate your processors from Canary to Mainnet
---
## Transfers on Canary
:::info
Token transfers on Canary have been activated on Tuesday, November 11, 2025 - 5pm UTC
:::
Migration (the process of moving funds and processors from Canary to Mainnet) strictly happens between the exact same account on Canary as on Mainnet. If you want to transfer tokens or processors to different accounts you need to do that **BEFORE** the migration on Canary. Some limitations apply:
## Transfer Processors
Processors from one account can only be migrated as a whole from Canary to Mainnet and they will be assigned to the same manager account as before. It is possible to transfer all processors on Canary from one account to another, but only ALL processors at once and only to a fresh and unused Acurast Canary account. You cannot split up processors between accounts, you cannot "send" processors to existing accounts that already have processors or tokens.
## Transfer Tokens
Tokens from one account can only be migrated as a whole from Canary to Mainnet and they will be assigned to the same manager account as before. But before the Migration function is activated, **token transfers have been activated on Canary**. This means you can decide to split up funds between different Canary accounts BEFORE migrating them to Mainnet. Once the funds are migrated to Mainnet, they will be locked and cannot move again, until they are unlocked. See [Conversion](/from-canary-to-mainnet/overview) about the locking mechanism that kicks in after migration.
## Transfers and Impact on Stakes
:::warning Attention
**Do not transfer your processors to a different account if you have an active stake. You risk being slashed. Unstake first, wait for the cooldown to end, then transfer processors.**
:::
You must unstake and wait for the cooldown to end, if you want to transfer your processors to a different account, the account with the stake will suddenly lose all of its compute and you will be exposed to staking penalties. It's the same as if you would suddenly cut your internet connection.
You must unstake and wait for the cooldown to end, before you can migrate to Mainnet. As the cooldown can take up to 48 hours, you should absolutely trigger unstake before the migration window of 90 days ends.
## How to Transfer Funds on Canary
There are two ways how you can transfer cACU tokens on Canary:
**A) Use your Substrate based wallet**
1. Use your Substrate based wallet (e.g. Talisman, SubWallet)
2. Make sure you see the token in your account (check [Wallet page](/wallets/wallet-overview) for how-to)
3. Transfer as usual: select token, enter target address and amount, send
4. Sign with your wallet
**B) Use the transfer function on [hub.acurast.com](https://hub.acurast.com) (e.g. using Metamask or walletconnect enabled wallets)**
1. Go to the balance section of the hub
2. Click **Transfer**
3. Enter amount and target address
4. Click **Transfer** and sign with your wallet
**Remember, tokens which are locked by staking cannot be transferred.**
## How to Transfer Processors on Canary
**DO NOT TRANSFER PROCESSORS IF YOU ARE STAKING! REALLY!**
1. Go to the Phones section on [hub.acurast.com](https://hub.acurast.com)
2. **Toggle Advanced** on top right
3. In Processor Ownership click **Transfer**
4. Carefully read what it says on the screen
5. Enter your target address
6. Double check your target address to ensure it's yours
7. Click **Transfer Ownership**
Remember, you can only transfer processors to fresh unused accounts with 0 balance. Otherwise it won't work. You can also only transfer all processors at once.
---
## Post Mortem - 2025-11-04 - Acurast Canary chain stalled
## Post Mortem
### Date & Time
11.04.2025 at 2:30 GMT+2
### Engineer
Andreas Gassmann, Mike Godenzi
### Summary
The Acurast Canary chain stopped regularly producing new blocks for about 40mins, afterwards block production resumed but blocks were not finalized, after 2 hours blocks were finalized again.
### Status
Resolved
### Root causes
The Acurast collators could not produce any new blocks because the Kusama relay chain nodes they were connected to were in a crash loop, exhibiting the behavior described in [this Github issue](https://github.com/paritytech/polkadot-sdk/issues/4934).
The Kusama nodes were running on a version containing the bug detailed in the issue linked above. Restarting the nodes did not improve the situation.
After around 2 hours the Kusama relay nodes started to work properly again.
### Trigger
Kusama relay chain nodes used by the Acurast collators entered in a crash loop because of a bug described in [this Github issue](https://github.com/paritytech/polkadot-sdk/issues/4934).
### Resolution
The relay chain nodes affected started to work again after around 2 hours. Afterwards they have been all updated to the latest version.
In addition, all Acurast collators node have been configured with additional relay chain nodes as fallback.
### Timeline
2:30:
- block production halts
2:42:
- initial triage of issue
- discovered Kusama relay chain nodes used by the Acurast collators entered in a crash loop
- restarting of Kusama relay chain nodes
- restarting of all acurast parachain nodes
- blocks started to be produced but they were not getting finalized
- continues triage of issue after chain still did not recover
4:33:
- Kusama relay chain nodes started to work again
### Lesson learned
- Keep Kusama nodes up to date
- Have more additional backup nodes configured as the relay chain nodes for the Acurast Collators.
---
## Ecosystems & Integrations
# Supported Ecosystems & Integrations
Acurast is built with interoperability at its core and is able to support various Web3 ecosystems and has multiple ways of being integrated within various environments such as EVM, WASM, Substrate and others.
## Supported Ecosystems
Acurast supports ecosystems that have an active developer community and smart contract environments.
| | Network | Environment | [Level 1 Integration ↗](#level-1) | [Level 2 Integration ↗](#level-2) |
| --------------------------------------------------------------------------------------------------------- | ------------------------- | ---------------- | --------------------------------- | --------------------------------- |
|  **Aleph Zero** | In Development | WASM | ✅ | ❌ \* |
|  **Arbitrum** | Mainnet, Goerli | EVM | ✅ | ❌ \* |
|  **Astar** | Mainnet, Shibuya, zKatana | WASM, EVM, zKEVM | ✅ | ❌ \* |
|  **Base** | Mainnet, Goerli | EVM | ✅ | ❌ \* |
|  **Binance Smart Chain** | Mainnet, Testnet | EVM | ✅ | ❌ \* |
|  **BoB** | Testnet | EVM | ✅ | ❌ \* |
|  **Ethereum** | Mainnet | EVM | ✅ | ❌ \* |
|  **Monad** | Testnet | EVM | ✅ | ❌ \* |
|  **Moonbeam** | Mainnet, Moonbase | EVM | ✅ | ❌ \* |
|  **Optimism** | Mainnet, Goerli | EVM | ✅ | ❌ \* |
|  **Pendulum** | Testnet | EVM | ✅ | ❌ |
|  **Polygon** | Mainnet, Mumbai | EVM | ✅ | ❌ \* |
|  **Peaq** | krest | EVM | ✅ | ❌ \* |
|  **Tezos** | Mainnet, Ghostnet | Tezos | ✅ | ✅ |
|  **æternity** | In Development | æternity | ✅ | ❌ \* |
_\* In Development_
Support for additional ecosystems are added on a regular basis.
:::info
Are you considering an Acurast integration for your ecosystem and have questions?
Reach out to us on [hi@acurast.com](mailto:hi@acurast.com), on [Discord](https://discord.gg/wqgC6b6aKe) or [Telegram](https://t.me/acurastnetwork).
:::
## Integration Levels
### Level 1
With a _Level 1_ integration, the Acurast Protocol is capable to accept Deployments for the given destination ecosystem e.g., Ethereum smart contract. Developers are creating their Deployment requests through the Acurast Hub directly on the Acurast Protocol, funding the rewards with Acurast Tokens. Processors are capable of interacting with the destination directly, signing transactions and injecting them.
A simplified representation of the Level 1 flow:
**Key takeaways:**
- Processors can interact with the destination and submit their output
- Developers create Acurast Deployments through the Acurast Hub directly on the Acurast Protocol which requires an Acurast Wallet and Acurast Tokens
- Developers need to fund transaction fees of the Processors with the asset of the destination ecosystem
### Level 2
A _Level 2_ integration provides a much improved developer experience and streamlined onboarding. An Acurast Proxy contract is deployed in the destination ecosystem that establishes a bi-directional cross-chain communication channel with Acurast Hyperdrive to the Acurast Protocol. Users e.g. on Ethereum can connect with their Ethereum wallet to the Acurast Hub and create a Deployment by interacting with the Proxy contract and rewarding Processors in the native currency. The created request is forwarded to the Acurast Protocol where that matches with eligible Processors that in turn then provide their output to the destination.
A simplified representation of the Level 2 flow:
**Key takeaways:**
- Developers create Acurast Deployments through the Acurast Hub with a wallet from their ecosystem e.g., Metamask for Ethereum
- Rewards and transaction fees are provided in a native asset e.g., ETH
- Acurast Hyperdrive is used for cross-chain communication
## Integrations
Support for Acurast in a Web3 ecosystem can be achieved through various integration approaches:
- EVM
- Substrate
- Substrate with WASM
- Tezos
---
## Real Decentralized Compute Network
### Real Decentralized Compute Network - Powered by Phones
Acurast is redefining compute by utilizing billions of smartphones – no data centers required. This verifiable, scalable, and confidential compute network enables users to run secure applications on decentralized infrastructure at scale—without compromising speed or privacy.
Acurast has already onboarded 227'181 compute units worldwide on its incentivized testnet making it the most decentralized verifiable compute network available today. This impressive amount of compute already powers mission critical workloads with high-security and AI requirements.
This isn’t just another DePIN protocol — it’s a game-changer that’s redefining how the world computes.
### Get Started
**[Deploy your first app ↗](/developers/deploy-first-app)**
**[Provide compute with your phone ↗](/acurast-processors/)**
As global demand for computing power continues to skyrocket, control has gradually shifted into the hands of a few large, centralized providers. With AI’s rapid growth further accelerating the need for massive computing resources, the call for a truly decentralized, global-scale network—by the people, for the people—has never been stronger.
The only way to deliver on this vision is by rethinking decentralized compute from the ground up. Instead of relying on data centers or even servers, Acurast harnesses the world’s most abundant, powerful, and secure form of compute: smartphones.
### Decentralized by Design:
Tens of thousands of phones serve as compute units across the globe — no centralized data centers required. United by a growing community of Compute Providers active in over 140 countries, this network sets a new standard for true decentralization.
### Scalable by Design:
By tapping into the compute of billions of smartphones worldwide, it’s primed to reach an unprecedented scale. Backed by academic research benchmarking its performance against leading centralized providers, it’s built for the future of decentralized compute. Battle-tested: The Acurast protocol has processed more than 250 million transactions on Testnet, demonstrating its impressive scalability and resilience.
### Secure by Design:
Acurast safeguards over $200 million in digital assets across leading networks—such as Bitcoin, Ethereum, Tezos, Polkadot, peaq and others. The smartphone's best-in-class Trusted Execution Environments (TEEs) confirm that hardware is genuine rather than fake, while maintaining confidentiality without requiring trust in the device owner. This strong emphasis on verifiability and confidentiality delivers the robust security essential for mass adoption of decentralized compute.
---
## Networks
A list of all related core infrastrucuture for each deployed Acurast network. More details on the functionalities of each network can be found in the [Protocol Architecture ↗](/acurast-protocol/architecture/instances)
## Acurast Mainnet
| | Details |
| -------- | ---------------------------------------------------------------- |
| Token | ACU |
| RPC | [wss://public-rpc.mainnet.acurast.com](wss://public-rpc.mainnet.acurast.com) |
| Explorer | [Block Explorer](https://acurastbot.com/explorer) |
## Acurast Canary
| | Details |
| -------- | ------------------------------------------------------------------------------------------------------------- |
| Token | cACU |
| RPC | [wss://public-rpc.canary.acurast.com](wss://public-rpc.canary.acurast.com) |
| Explorer | [Block Explorer](https://canary.acurastbot.com/explorer) |
| Faucet | [faucet.acurast.com](https://faucet.acurast.com/) |
## Acurast Devnet
| | Details |
| -------- | ------------------------------------------------------------------------------------------------------ |
| Token | dACU |
| RPC | [wss://acurast-devnet-ws.prod.gke.papers.tech](wss://acurast-devnet-ws.prod.gke.papers.tech) |
| Explorer | [Block Explorer](https://polkadot.js.org/apps/?rpc=wss://acurast-devnet-ws.prod.gke.papers.tech#/explorer) |
:::note
Public RPC nodes might be rate-limited. If you run into issues for your use case, please reach out in the community channels.
:::
---
## Post-mortem - Acurast Air Drop
**Date:** 2026-02-02
**Authors:** Mike Godenzi
**Status:** Complete
---
## Summary
On the 27th of January 2026, Acurast launched the Air Drop event that allowed users of the Cloud Rebellion to receive ACU tokens on Acurast Mainnet.
The received tokens were supposed to be locked in a vesting schedule for 24 months. Unfortunately some users were able to receive the ACU tokens partially or fully unlocked.
## Impact
Some of the users that claimed their Air Drop received the claimed ACU tokens partially or fully unlocked. Before the system was shut down, around 600'000 ACU tokens were claimed.
## Detection
Users reported being able to transfers the tokens that were just claimed for the Air Drop.
## Root Causes
The Air Drop functionality is implemented in the [pallet-acurast-token-claim](https://github.com/Acurast/acurast-substrate/tree/acurast-v0.23.14/pallets/token-claim) pallet.
The claim functionality would transfer the claimed amount to the provided address and setup a vesting schedule through Substrate's [pallet-vesting](https://docs.rs/pallet-vesting/latest/pallet_vesting/) pallet. This vesting pallet places a lock on the user's account balance for the amount specified, which in this case is the Air Drop claimed amount. Users are then able to call the `vest` extrinsic on `pallet-vesting` to released from the lock the vested token so far.
Users are also able to convert cACU token from the Acurast Canary network to Mainnet ACU tokens via the [pallet-acurast-token-conversion](https://github.com/Acurast/acurast-substrate/tree/acurast-v0.23.14/pallets/token-conversion) pallet. The converted tokens are placed in a `Hold` state on the user's account.
The issue occurred because the lock used by `pallet-vesting` to lock up the claimed token is an overlapping lock that also takes into consideration the balance on `Hold`. This means that if a user used both the cACU to ACU conversion feature and the Air Drop claim, the converted balances would be counted in the locked balance in the vesting pallet, allowing the additional claimed Air Drop amount to be unlocked.
## Trigger
Any user using both the cACU to ACU conversion and the Air Drop claim features would trigger the issue described above.
## Resolution
At first, the Air Drop feature was disabled, then it was re-implemented to not use the [pallet-vesting](https://docs.rs/pallet-vesting/latest/pallet_vesting/) pallet.
Instead now the claimed amount is not right away sent to the user's account, but rather booked internally by the [pallet-acurast-token-claim](https://github.com/Acurast/acurast-substrate/tree/acurast-v0.23.14/pallets/token-claim) pallet and only released to the user's account when the `vest` extrinsic is called.
---
## Action Items
| Action Item | Type | Owner | State |
|-------------|------|-------|-------|
| Disabling of Air Drop feature | mitigate | Andreas Gassmann | DONE |
| Implementation of long term fix | prevent | Simon Wehrli | DONE |
| Acurast Mainnet runtime upgrade to deploy fix | process | Mike Godenzi | DONE |
---
## Timeline
- **2026-01-27 12:30 UTC** - Air Drop functionality released
- **2026-01-27 14:30 UTC** - Air Drop issue surfaced and functionality disabled
- **2026-02-03** - Corrected Air Drop functionality re-released
---
## Lessons Learned
### What went well
Once the issue was surfaced, the Air Drop functionality was quickly disabled.
### What went wrong
The issues took too long to surface.
### Conclusion
It is not trivial to coordinate different subsystems that handle receiving and locking of some tokens on a user's account in a way that do not interfere with each other.
Either the subsystems need to tightly coordinate and carefully lock/unlock the proper amounts, or they should be fully independent and do not use the shared locking system.
Going forward, similar features can be fully tested on the Canary network before enabling them on Mainnet.
---
## Processor Lite and Core
The Acurast processor is the app that is running on smartphones which take part in the Acurast Decentralized Compute Network. Acurast Processors are the infrastructure providers for Acurast's decentralized compute network. Processors provide the compute power of their phone and are used by developers to run their Deployments.
## Acurast Processor Core
_Only available for Android_
Provide compute with a dedicated phone, completely locked down and setup as a compute provider and join Acurast's decentralized compute network. Processor Core transforms your Android device into a dedicated compute node, offering maximum performance and reliability.
**Key Features:**
- **Dedicated Setup**: The device runs only the Acurast Processor app with everything else completely locked down
- **Maximum Performance**: Optimized for continuous operation and higher deployment execution rates
- **Enhanced Security**: Factory-reset device ensures a clean, secure environment
- **24/7 Operation**: Designed to run continuously, maximizing your reward potential
- **Priority Selection**: Developers often prefer Core devices for longer-running, critical deployments
**Requirements:**
- Android 12 or newer
- Device must not be rooted
- Locked bootloader required
- Factory reset necessary during setup
**[Setup Guide ↗](/processors/become-compute-provider#step-4-install-and-setup)**
## Acurast Processor Lite
Provide compute with your everyday phone and join Acurast's decentralized compute network. Processor Lite allows you to contribute compute power during edge-times (like while you sleep and charge) without dedicating an entire device.
**Key Features:**
- **Use Your Everyday Phone**: No need for a dedicated device - runs alongside your regular apps
- **Flexible Operation**: Provide compute during edge-times when your phone is idle (e.g., while charging overnight)
- **No Factory Reset**: Install and start providing compute immediately without wiping your device
- **Cross-Platform**: Available on both Android and iOS
- **Easy Setup**: Simple installation process with minimal configuration required
- **Android Work Profile**: Uses isolated work profile on Android for enhanced security and privacy
**Requirements:**
- **Android**: Android 12 or newer (non-rooted, locked bootloader)
- **iOS**: iPhone 6S or newer (iOS 15+)
**[Google Play ↗](https://play.google.com/store/apps/details?id=com.acurast.attested.executor.sbs.canary)**
**[Apple App Store ↗](https://apps.apple.com/us/app/acurast-processor/id6517361921)**
**[Setup Guide ↗](/processors/become-compute-provider#step-4-install-and-setup)**
## Security
For information about security audits, please visit **[Security Audit ↗](/audits)**.
---
## Become an Acurast Compute Provider
Join Acurast's decentralized compute network and start receiving rewards by providing compute power with your smartphone. This guide will walk you through everything you need to get started as a Compute Provider.
## What is a Compute Provider?
Compute Providers are people who run the Acurast Processor App to provide infrastructure for Acurast's decentralized compute network. As a Compute Provider, you provide the compute power of your phone to developers who run their applications (called Deployments) on the Acurast network. In return, you receive rewards in the form of tokens.
## What you need to become a Compute Provider
Getting started as a Compute Provider is simple. Here's what you need:
**One or more Compatible Smartphones**
- **Android**: Android 12 or newer (non-rooted, locked bootloader)
- **iOS**: iPhone 6S or newer (iOS 15+)
- Higher specs (CPU, RAM, Storage) will potentially result in higher rewards
- Check the [Recommended Phones list ↗](https://docs.google.com/spreadsheets/d/1ZvzmMVey4CM2tuif_zJfWiIxH1qkgA-l7BNJMw4vh54/edit#gid=1844886586) for optimal reward potential
**Internet Connection**
- Stable Wi-Fi or mobile data connection
- Reliable connectivity ensures consistent uptime and maximum rewards
**Power Source**
- Keep your device charged or connected to power
- Continuous operation maximizes your rewards
**Acurast Wallet**
- Created automatically when you install the Acurast Processor app
- Or import an existing wallet if you already have one
That's it! No technical expertise required - the Acurast Processor app handles everything else.
## Recommended Phones
Make sure to check out if your phone is on the list of recommended phones. In general, phones with higher specs will receive more rewards.
:::info
**[Recommended Phones ↗](https://docs.google.com/spreadsheets/d/1ZvzmMVey4CM2tuif_zJfWiIxH1qkgA-l7BNJMw4vh54/edit#gid=1844886586)**
:::
## Quick Start Guide
### Step 1: Check Device Compatibility
Before getting started, make sure your device meets the requirements:
**Android Requirements:**
- Android 12 or newer
- Device must not be rooted
- Bootloader must be locked
**iOS Requirements:**
- iPhone 6S or newer
- iOS 15 or newer
### Step 2: Get an Acurast Compatible Wallet
Before setting up your Processor, you'll need a wallet to receive your rewards.
**Recommended Wallets:**
- **[AirGap Wallet ↗](https://airgap.it/)** - Air-gapped self custody wallet
- **[Talisman ↗](https://talisman.xyz/)** - Full-featured Substrate wallet
- **[SubWallet ↗](https://www.subwallet.app/)** - Multi-chain Substrate wallet
For more supported wallets and detailed wallet setup guides, see the [Wallet Documentation](/wallets/wallet-overview).
**Quick Setup (Talisman):**
1. Install the [Talisman browser extension ↗](https://talisman.xyz/)
2. Click "New Wallet" and create a strong password
3. Write down your recovery phrase and store it safely (never share this!)
4. Add Acurast network: Click the network dropdown → Search for "Acurast" → Enable it
### Step 3: Choose Your Processor Type
Acurast offers two types of Processors:
**Acurast Processor Core** (Android only)
- Dedicated device setup for maximum performance
- Requires factory reset of your Android phone
- Only the Acurast Processor app will run on this phone (everything else is completely locked down)
- Best for serious compute providers
- [Setup via Acurast Hub ↗](https://hub.acurast.com/)
**Acurast Processor Lite** (Android & iOS)
- Runs on your everyday phone in edge-times (e.g. while you sleep and charge)
- No factory reset required
- Easy to get started
- [Download for Android ↗](https://play.google.com/store/apps/details?id=com.acurast.attested.executor.sbs.canary)
- [Download for iOS ↗](https://apps.apple.com/us/app/acurast-processor/id6517361921)
### Step 4: Install and Setup
#### For Processor Core
1. Factory reset your Android phone
2. Visit [Acurast Hub ↗](https://hub.acurast.com/) and connect with your wallet
3. Follow the detailed setup instructions for dedicated processors
4. Lock down the device as a dedicated compute provider
#### For Processor Lite
1. Download the app from [Google Play ↗](https://play.google.com/store/apps/details?id=com.acurast.attested.executor.sbs.canary) or [Apple App Store ↗](https://apps.apple.com/us/app/acurast-processor/id6517361921)
2. Open the app and give the required permissions
3. Visit [Acurast Hub ↗](https://hub.acurast.com/), connect your wallet and use 'Onboard with hub'. Alternatively tap "Get Started" and a wallet will be created for you on the app.
4. Complete the initial setup wizard
5. Keep your device connected to the internet
### Step 5: Start Receiving Rewards
Once your Processor is set up and running, you'll automatically start receiving rewards:
**Base Benchmark Rewards**
- Receive ACU tokens for providing compute power based on four benchmark metrics of processors
- Receive +10% benchmark metric bonus, when your processors are matched to execute deployments
- Higher-spec devices typically receive more Base Benchmark Rewards
**Staking Rewards**
- Receive ACU tokens for staking your compute
- Receive +10% benchmark metric bonus, when your processors are matched to execute deployments
- Staking more tokens for a longer duration generates more staking rewards
**Cloud Rebellion Points**
- Join the [Cloud Rebellion ↗](https://rebellion.acurast.com/) to receive MIST points
- Complete quests and onboard more Compute Providers
- Invite others to join and receive additional rewards
## Best Practices
To maximize your rewards and ensure smooth operation:
- **Keep your device connected to the internet** - Your Processor needs stable internet to receive and execute deployments
- **Ensure adequate power** - Keep your device charged or connected to power
- **Use recommended devices** - Higher-spec phones from the recommended list will receive more benchmark rewards
- **Run multiple processors** - Scale your compute provision by running [multiple devices](/acurast-processors/multiple-processors)
- **Monitor performance** - Check your benchmark scores and uptime regularly
## Next Steps
Now that you're set up as a compute provider, explore these resources:
- Learn about [Processor Lite and Core](/acurast-processors) in detail
- Understand how [Benchmarks](/acurast-processors/benchmarks) affect your rewards
- Scale up by running [Multiple Processors](/acurast-processors/multiple-processors)
- Join the [Cloud Rebellion ↗](https://rebellion.acurast.com/)
- Follow us on [X ↗](https://x.com/Acurast)
- Join the community on [Discord](https://discord.gg/wqgC6b6aKe) or [Telegram](https://t.me/acurastnetwork)
## Need Help?
If you encounter any issues during setup or have questions:
- Check the [FAQ](/faq) for common questions
- Join the [Discord community ↗](https://discord.gg/wqgC6b6aKe)
- Reach out on [Telegram ↗](https://t.me/acurastnetwork)
- Contact support through the [Acurast Hub ↗](https://hub.acurast.com/)
Welcome to the Acurast network!
---
## Benchmarks
Benchmark tests on Acurast phones are vital to determine the compute power of the participating devices. The compute metrics determined by these benchmark tests are relevant for **matching phones** to the right tasks based on their capabilities, **calculating benchmark rewards** distributed for the provision of phones, and **determining [staked compute rewards](/staked-compute)**. Better hardware usually leads to a higher benchmark score.
## Overview
The [Acurast Benchmark](https://github.com/Acurast/acurast-benchmark) suite is designed to evaluate the performance of Processors running in the Acurast network. It provides a comprehensive set of tests to measure computational throughput, memory allocation and access efficiency, and storage read/write performance. The benchmarks include support for multithreaded execution to leverage modern multi-core architectures.
The benchmark suite evaluates three main components: **CPU**, **RAM**, and **Storage**. Each component contributes to the overall performance score of the device.
## CPU Benchmarks
The CPU benchmarks evaluate the computational capabilities of the device through three test categories:
### Test Categories
- **Crypto**: Measures encryption and decryption throughput using [AES-256](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard) and hashing throughput using [SHA-256](https://en.wikipedia.org/wiki/Secure_Hash_Algorithms).
- **Math**: Tests matrix multiplication performance, with support for three algorithms:
- [**Divide and Conquer**](https://en.wikipedia.org/wiki/Matrix_multiplication_algorithm#Divide-and-conquer_algorithm): A recursive algorithm used for single-threaded execution when SIMD is disabled or for multithreaded benchmarks in general.
- [**Iterative**](https://en.wikipedia.org/wiki/Matrix_multiplication_algorithm#Iterative_algorithm): A straightforward implementation used when SIMD optimization is enabled but the device lacks the required hardware capabilities.
- **SIMD-Optimized**: An optimized version of the iterative algorithm leveraging SIMD instructions, used when the device supports the required hardware capabilities.
- **Sort**: Benchmarks sorting algorithms, including single-threaded and multithreaded [merge sort](https://en.wikipedia.org/wiki/Merge_sort).
### Execution Modes
The CPU benchmark suite is available in two variations:
- **Single-Core**: Executes all tests using a single thread to evaluate the performance of a single core.
- **Multi-Core**: Executes all tests using multiple threads to leverage the full computational power of the device.
### Configuration
- **Crypto**: Configure the duration of the test and the size of the data to encrypt and hash.
- **Math**: Specify the matrix size, whether to enable SIMD optimizations, and the duration of the test.
- **Sort**: Define the size of the dataset and the duration of the test.
### Score Calculation
The CPU score is calculated as the average of the throughput ($TPS$) values from the Crypto, Math, and Sort benchmarks. Higher throughput results in a higher score.
$$
score_{CPU} = \frac{TPS_{crypto} + TPS_{math} + TPS_{sort}}{3}
$$
## RAM Benchmarks
The RAM benchmarks assess memory allocation and access patterns through two test categories:
### Test Categories
- **Allocation**: Measures the time taken to allocate and initialize memory.
- **Access**: Evaluates sequential, random, and concurrent memory access patterns.
### Configuration
- **Allocation**: Specify the number of iterations and the size of memory to allocate in each iteration.
- **Access**: Configure the number of iterations and the size of data for sequential, random, and concurrent access patterns.
### Score Calculation
The RAM score is calculated based on the inverse of the average times ($T$) for Allocation and Access benchmarks. Higher efficiency results in a higher score. The total available RAM memory is also recorded.
$$
score_{RAM} = \frac{T_{alloc}^{-1} + T_{access\_seq}^{-1} + T_{access\_rand}^{-1} + T_{access\_concurr}^{-1}}{4}
$$
## Storage Benchmarks
The storage benchmarks focus on file I/O performance through read and write operations.
### Test Categories
- **Access**: Measures sequential and random read/write throughput for files on the storage medium.
### Configuration
- **Access**: Define the number of iterations and the size of data for sequential and random read/write operations.
### Score Calculation
The Storage score is calculated as the average of the inversed average times ($T$) for sequential and random read/write operations. Lower average times result in a higher score. The available storage capacity is also recorded.
$$
score_{storage} = \frac{T_{access\_seq}^{-1} + T_{access\_rand}^{-1}}{2}
$$
## Overall Scoring
The compute overall score is calculated as a weighted average that combines performance metrics from CPU, RAM, and Storage benchmarks to provide a comprehensive evaluation of a device's computational capabilities.
$$
score_{all} = w(score_{CPU\ SC}) + w(score_{CPU\ MC}) + w(mem_{RAM}) + w(score_{RAM}) + w(mem_{storage}) + w(score_{storage})
$$
Where:
$$
w(m) = \frac{m}{N_{m}} \times W_{m}
$$
And:
- $W_{m}$: Weight assigned to each metric pool ($0 \leqslant W_{m} \leqslant 1$ and $\sum_{m} W_{m} = 1$)
- $N_{m}$: Normalization factor representing the sum of all scores submitted to the metric pool. Uses the previous epoch's total if available, otherwise the current epoch's total, or defaults to $m$ if no data exists on the chain.
- $score_{CPU\ SC}$: CPU performance score (Single-Core)
- $score_{CPU\ MC}$: CPU performance score (Multi-Core)
- $mem_{RAM}$: Total available RAM memory
- $score_{RAM}$: RAM performance score
- $mem_{storage}$: Available storage capacity
- $score_{storage}$: Storage performance score
To make the final score human-readable, a scaling factor of $10^9$ is applied.
$$
score_{display} = score_{all} \times 10^9
$$
### Component Weights
The components are weighted as follows:
- CPU Single-Core: $W_{CPU\ SC} = 0.2307$
- CPU Multi-Core: $W_{CPU\ MC} = 0.2307$
- RAM Total: $W_{RAM\ mem} = 0.4615$
- RAM Speed: $W_{RAM\ score} = 0$
- Storage Total: $W_{storage\ mem} = 0.0769$
- Storage Speed: $W_{storage\ score} = 0$
If all weights equal $0$, the components are weighted equally:
$$
W_{m} = \frac{1}{n} \text{ if active, or } W_{m} = 0 \text{ otherwise}
$$
Where:
- $n$: The number of active metric pools
---
## Run Multiple Processors (Farms)
### Running multiple Acurast Processors
Running multiple Acurast Processors presents additional challenges. For optimal performance and availability, it is recommended to set up each Processor with Acurast Core on a freshly wiped device. Below are recommendations and best practices for managing multiple Acurast devices.
### Use a separate wallet
Each Acurast Processor is managed by a designated manager address. If you plan to run multiple Acurast Processors, ensure they are all managed by the same account. This manager account will be responsible for overseeing all devices and will collect the associated computation rewards.
Good experiences have been made with the following wallets:
- Metamask
- Talisman
- Solana wallets
- SubWallet
- Other EVM wallets via Walletconnect
Set up an Acurast account, back up the seed phrase according to standard best practices, and connect the account to the Acurast Hub. Then, obtain some initial funds from the faucet - these are required to register your first devices on the Acurast chain.
### Onboarding multiple phones at once
To onboard multiple phones simultaneously, users can opt to receive a QR code designed for bulk onboarding. This QR code can also include Wi-Fi access point information, eliminating the need to manually enter it on each device.
1. Connect your wallet to the [Acurast Hub](https://hub.acurast.com)
2. Click _Add Phone_ and sign from your wallet
3. Above the QR code change to _Multi Use_ and sign again
4. A QR code for multiple onboardings will be displayed
5. Toggle the _Advanced_ functions
6. Set the WiFi SSID to your Access Point, enter the WiFi Password for that AP and set the right WiFi Type, click _Save Changes_
7. Ensure phones are wiped, tap 6x on the first screen after starting the phone and scan the displayed QR code to set up the phones
8. Follow the instructions on screen
### Manage the phones in the Hub
The Acurast Hub is the place to manage your Acurast Processors. Users find it on [hub.acurast.com](https://hub.acurast.com)
#### Phones list page
On the _Phones_ page users see a list of phones they have deployed the Acurast Processor to. This page helps you to manage your devices.
- _Acurast address_: Device address with _identicon_ (click on the identicon to copy the device's address)
- _Last seen_: When the last heartbeat was detected
- _Attested_: If the device got attestation
- _Battery_: Battery health information (needs to be activated, see below)
- _Star rating_: Devices reputation, based on successfully completed jobs (default is 0.5)
- _Processor version_: OS and Processor version
- _Status_: Number of currently running Deployments
- _Settings_ (Cog wheel:) Opens the device settings
- _Bin_: Remove the device from your list and deregister it from Acurast
- _Advanced_: Toggle advanced settings
- _Activate management endpoint_ (needed to activate battery monitoring)
- _Enter_ a custom management endpoint (eg. for a self hosted management backend)
- _Processor Ownership:_ Transfer all Processors to a different manager
- _Update Processors_: Sends a signal to trigger the update of the Processor apps (the update can take a few minutes to be reflected)
### Monitoring Processors
#### Telegram Bot
To track the recent performance of the Processors and additional information, users can use the Acurast Monitoring Bot on Telegram: [@AcurastBot](https://t.me/AcurastBot)
#### Battery monitoring
The Acurast Hub offers some battery health and status indicators for every phone. This feature needs to be activated.
1. Connect your wallet to the [Acurast Hub](https://hub.acurast.com)
2. Go to _Phones_
3. Toggle the _Advanced_ functions
4. Toggle management endpoint by setting it to _active_
5. Wait until the devices show a battery indicator (this can take up to 2 heartbeats and a reload of the page)
#### Advanced battery monitoring with self hosted management backend
This tool is intended for advanced users who can host their own software and need to monitor a large number of phones. It also enables integration with external systems — for example, to control smart plugs or trigger third party systems. An early version of the tool is available here: [Acurast Processor Management Backend](https://github.com/Acurast/acurast-Processor-management-backend).
### Practical issues
#### WiFi recommendations
- Ideally, the WiFi access point for Acurast should be separate and not used for other purposes.
- 5Ghz WiFi is preferable if users want to connect many devices as it offers more non-overlapping channels.
- If you run a massive farm, ensure your devices have the network capacity, even if they all are running deployments
#### Safety Recommendations
Running smartphones 24/7 — especially older or partially damaged devices - can accelerate wear and tear, particularly on the battery. Some users have reported battery swelling, which is a sign of degradation and potential risk. While there have been no known fire incidents among Acurast users, all operators, especially those running multiple devices, are strongly advised to take basic safety precautions:
- Avoid placing phones on flammable surfaces.
- Ensure adequate ventilation around devices to prevent overheating.
- Regularly check batteries for swelling or unusual heat. Remove phones with swelled batteries.
- Use certified chargers and power strips with surge protection.
Your safety is a priority - please run your setup responsibly.
---
## Processor Rewards
As a Compute Provider running Acurast Processors, you receive rewards for contributing your device's compute power to the network. The reward system is designed to incentivize reliable compute provision, high-quality hardware, and active participation in the Acurast ecosystem.
## Reward Types
### Base Benchmark Rewards (Compute Pool)
Providers receive rewards based on the [benchmarks](/acurast-processors/benchmarks) of their participating devices. These rewards are paid from Acurast's token inflation. On Canary and Mainnet, a total of 10% of Acurast's inflation are distributed per epoch (900 blocks / roughly every 1.5 hours). This equals to 856.164 tokens per epoch to distributed as Base Benchmark Rewards (Compute Pool) among all Compute Providers, independent of their participation in Staked Compute. These rewards are split up to the different benchmarks pools and each phone competes with the others in the 4 benchmark pools. Higher specs usually lead to higher Base Benchmark Rewards (Compute Pool).
Distribution per Benchmark Metric on Canary Network
### Staking Rewards (Staked Compute Pool)
Compute Providers who participate in [Staked Compute](/staked-compute/overview) earn additional rewards by committing their compute power and staking tokens. 70% of Acurast's inflation is distributed as Staking Rewards (Staked Compute Pool) every epoch, which is 5'993.15 tokens. Staking Rewards (Staked Compute Pool) are distributed based on hardware performance, stake size, and commitment duration. Learn more about [how Staked Compute works](/staked-compute/overview) and how to maximize your staking rewards.
Acurast Inflation Distribution
### Deployment Execution Bonus (aka Busy Bonus)
When a processor is detected executing a deployment during an epoch, based on the first successful heartbeat of that epoch, it receives a bonus weight of 10% on the Benchmark Metrics. This will increase the scoring - and therefore the rewards - in both the **Staked Compute Pool** and the **Compute Pool (Base Benchmarking Rewards)** for that epoch.
The deployment costs for all deployments are paid by the developers and are burned after successful execution, creating a deflationary effect on the total supply.
### Cloud Rebellion
Join the [Cloud Rebellion](https://rebellion.acurast.com/) and harvest MIST points. Become a Rebel and cloud-harvest MIST (points) by completing quests, onboarding Processors, and inviting others to join the Rebellion.
---
## Roadmap
Key milestones achieved and upcoming:
- Genesis Mainnet Launch, TGE (Q1 2026). ✅
- Governance Activation for Decentralized Community Involvement. ✅
- Codename Cargo (Compute Containers) for modularized workloads, making serverless deployments even easier to deploy and scale.
- Codename Cray (Compute Clusters) cluster of hundreds of devices enabling high-performance compute tasks capable of running even the largest LLMs available. Effectively mitigating the vertical compute limitation arising from working with phones.
- Furthermore, the future roadmap includes:
- Codename Bazaar (Compute Economy), creating an active decentralized compute economy for developers to distribute entire software solutions seamlessly without limitations.
- Codename Rice (Compute Futures), innovating long-term decentralized compute economic strategies. Allowing compute providers to leverage their infrastructure and support their future scaling.
Acurast’s growth strategy is about activating a network effect at scale, where more phones bring more compute, more compute brings more builders, and more builders bring more value into the ecosystem. It’s a positive-sum loop powered by real-world demand, seamless integrations, and decentralized ownership, creating a compute marketplace flywheel.
Here’s how Acurast is scaling fast—and sustainably:
### 1. Mainnet Launch → Permissionless, Global Access
With the **Genesis Mainnet and TGE launched in Q1 2026**, Acurast is now fully open, decentralized, and permissionless. Anyone with a smartphone can become a compute provider. Anyone with workloads, from solo builders to AI startups, can deploy confidential applications on a decentralized network backed by hundreds of thousands of real, verifiable phones.
Mainnet is Acurast’s on-ramp to true global accessibility, where compute is no longer gatekept by geography, capital, or centralized infrastructure.
### 2. Seamless Native Integrations with Major Web3 Ecosystems
Acurast is being embedded directly into the world's most active blockchain ecosystems, **Solana, Ethereum, Polkadot, and beyond**, so web3 developers can access decentralized, confidential compute as easily as calling a smart contract.
These native integrations mean:
- Developers can spin up secure compute from within their dApp flows
- Protocols gain censorship-resistant backends
- Ecosystems unlock AI, automation, and zero-knowledge tasks without centralized dependencies
This makes Acurast not just complementary, but critical infrastructure for Web3’s next phase.
### 3. Expanding Beyond Web3: Serving SMEs and Enterprises
While crypto-native at its core, Acurast is **not limited to Web3**. **SMEs and enterprise use cases** are actively being supported — especially around **confidential AI, confidential compute, and secure edge deployments:**
- Allowing enterprises to tap into AI without the fear of exposing business-critical and proprietary data by tapping into confidential AI compute
- Workloads requiring confidential compute without the complexity or cost of standing up traditional cloud infrastructure
- Enterprises in emerging markets lacking access to reliable data centers
Acurast offers these users **a confidential, on-demand, scalable, and cost-efficient alternative** to centralized compute.
### 4. Hyper-Onboarding of Smartphones at Global Scale
The onboarding strategy is rooted in mutual value creation. Initiatives like the **Cloud Rebellion**, major partnerships, and region-specific programs are designed to scale from 70,000 devices to over 1 million, converting dormant phones into high-value, secure nodes.
Each new phone adds network supply, but also unlocks new regions and new use cases, especially in areas where traditional compute is inaccessible.
### 5. Unlocking New Economic Layers
With milestones like:
- **Cargo** (modular compute containers)
- **Cray** (clustered high-performance compute)
- **Bazaar** (open compute marketplace)
- and **Rice** (long-term compute futures)
This is not just scaling tech—it's building an open compute economy, where compute is programmable, tradable, and ownable. Each upgrade compounds utility, revenue, and token demand.
### 6. Community-Driven Governance & Protocol Expansion
The Acurast community shapes protocol decisions through **on-chain governance** and a self-replenishing treasury. This turns users into stakeholders, and stakeholders into contributors.
**\*In short:** Acurast's growth strategy creates a flywheel:
**More devices → more demand → more utility → more contributors → more value.**
And at the center of that flywheel is a single insight: **you don’t need a data center to be part of the future of compute—just your phone.**
Now is the time to join.
---
## How To Stake
## How to Stake
On the Staking page in the Acurast Hub, users can stake and have an overview over their Stakes and Delegations.
To create a stake, Compute Providers (aka Committers) have to:
1. Compute: select the amount of Compute they are comfortable to commit.
2. Cooldown: select the Cooldown period. The cooldown period is measured in blocks. The Staking Frontend also provides an estimate expressed in time (days etc.)
3. Tokens: Select the amount of tokens to stake
4. Compound: Select if Autocompoundung is ON or OFF
To do a delegation, Delgators have to:
1. Committer: Select a Committer
2. Cooldown: Select a Cooldown period
3. Tokens: Select the amount of tokens to delegate
4. Compound: Select if Autocompoundung is ON or OFF
## Staking Lifecycle
**Committer:**
* **Start staking:** Committer chooses the amount of computation to commit, tokens to stake, and cooldown length, then creates a stake.
* **While staking:** Committers can add more tokens to the stake, increase duration and committed compute, and either compound or withdraw rewards. They must maintain their committed compute level to avoid slashing.
* **Exit staking:** Committer triggers cooldown (reducing rewards to 50% but maintaining full slashing risk) and waits until it ends.
* **Finalize (Withdraw/Claim):** After cooldown ends, committer finalizes the stake, withdrawing the unlocked funds and any unclaimed rewards.
**Delegator:**
* **Start Staking:** Delegators choose one or several committers to delegate to, then select the amount of tokens and cooldown period (which cannot exceed their chosen committer's cooldown).
* **While staking:** Delegators can add more tokens, increase duration, compound or withdraw rewards. They can also redelegate their stake to a different committer with equal or greater parameters (committed compute, stake size, and cooldown duration).
* **Exit staking:** Delegator triggers cooldown (reducing rewards to 50%) and waits until it ends.
* **Finalize (Withdraw/Claim):** After cooldown ends, delegator finalizes the stake, withdrawing the unlocked funds and any unclaimed rewards.
## Reward compounding (Autocompound)
When creating a stake, committers and delegators can choose whether their staking rewards should be automatically compounded (automatically added back to their stake) or made available for withdrawal. If they choose not to autocompound, rewards accumulate and can be withdrawn at any time - users are then free to move these rewards or manually stake them again. Autocompounding simply automates this process, maximizing reward growth over time without requiring manual action.
---
## Staking Mainnet vs. Canary
Acurast operates two networks - Mainnet and Canary - each with different staking reward structures and purposes.
## Staking on Acurast Canary Network
Canary serves as Acurast's testing and experimental network, where new features are deployed and tested before moving to Mainnet. Staking on Canary pays 5% of the inflation of 856.16 cACU per epoch.
:::warning Canary Stakes And Conversion to Mainnet
When Mainnet goes live, a 90 days conversion phase starts, allowing users to convert their funds from Canary to Mainnet using the Conversion process. In order to convert staked Canary funds to mainnet, all stakes and delegations on Canary need to be unstaked / undelegated. Users are advised to do that as soon as the conversion phase starts, in order to have enough time to convert. Non converted Canary funds and stakes can not be converted to Mainnet once the Conversion phase has ended.
:::
## Staking on Acurast Mainnet
Mainnet is Acurast's production network with a mature reward structure designed for long-term sustainability. Here, 70% of epoch inflation goes to the Staked Compute Pool (staking rewards), while the remaining inflation is distributed to: 15% Treasury, 10% Benchmark rewards, and 5% Collators (block producers).
## Key Parameters Comparison (Mainnet vs. Canary)
| Parameter | Canary | Mainnet |
|-----------|---------|---------|
| Total Epoch Rewards (100%) | 856.16 cACU | 8,561.64 ACU |
| Staking Rewards per Epoch | 42.81 cACU (5% of 856.16) | 5,993.15 ACU (70% of 8,561.64) |
| Base Benchmark Rewards | 0 cACU (0%) | 856.16 ACU (10%) |
| Collator Rewards | 0 cACU (0%) | 428.08 ACU (5%) |
| Treasury | 813.35 cACU (95%) | 1,284.25 ACU (15%) |
| Min Cooldown Period | 600 blocks (~ 1 hour) | 403,200 blocks (~ 28 days) |
| Max Cooldown Period | 28,800 blocks (~ 48 hours)| 19,353,600 blocks (~ 1344 days / 3.68 years)|
| Max Slashing per Epoch | 0.003424657534% of stake | 0.003424657534% of stake |
---
## Overview(Staked-compute)
## Acurast Staked Compute
Acurast is building a decentralized compute network where anyone can contribute processing power using smartphones. To ensure this network stays reliable and doesn't degrade over time, Acurast uses a staking mechanism that creates economic incentives for consistent hardware availability.
### How It Works
**Compute Providers (Committers)** run the Acurast processor app on actual devices and commit to providing specific compute capacity for a period of time. They stake Acurast tokens as collateral - essentially making a promise backed by Acurast tokens. If they keep their hardware online 24/7 and fulfill their commitment, they earn staking rewards based on their compute amount, stake size, and chosen cooldown duration. If they fail, they lose a portion of their stake through slashing.
**Delegators** are token holders who don't run hardware but want to support the network. They delegate their tokens to committers they trust, earning a share of the rewards (minus the committer's delegation fee). This helps strengthen providers' commitments while letting more people participate. However, delegators share the risk-if their chosen committer fails, delegators also get slashed proportionally. They can redelegate to different committers anytime.
### Why This Matters
This creates "skin in the game" for everyone. Providers are economically motivated to maintain their devices and keep capacity online because failure means losing staked capital. Delegators carefully choose reliable providers because they share the consequences.
For developers, this means predictable, reliable compute capacity they can build on. Long-term commitments backed by financial collateral ensure the infrastructure will be there when needed.
The result is a win-win ecosystem: providers earn rewards for reliability, delegators earn passive income, and the network becomes more valuable as participation grows. Governance voting rights for staked tokens are enabled through the Acurast DAO.
---
## Slashing
## How Slashing Works
Slashing is a penalty mechanism designed to ensure committers keep their promise of providing consistent compute power over time. If a committer fails to stay online or their measured compute in any of the four benchmark metrics falls below what they committed - for example, because phones went offline and were not replaced - their stake gets slashed in proportion to the shortfall. For instance, if a committer promised 100 GB of RAM but only delivers 80 GB, they will be slashed proportionally for that 20% shortfall in the RAM metric.
This mechanism incentivizes providers to actively maintain their deployed Acurast phones and farms, ensuring they're always running and replacing capacity with equally powerful devices when needed. Both the committer and their delegators share this risk, as slashing affects all staked tokens proportionally.
### When Slashing Occurs
When a committer's Current Compute falls below their Committed Compute in any of the four benchmark metrics during an epoch, they become slashable for that epoch. Slashing must be triggered on-chain by a **Slasher**- anyone with an Acurast account who detects the violation. Slashing can be triggered earliest in the epoch after the epoch where the commitment was violated.
### How Slashing Penalties Are Calculated
Once slashing is triggered, penalties are calculated independently for each Benchmark Metric where there's a shortfall. The slashing amount for each metric is determined by multiplying the stake amount by the maximum slash rate (0.003424657534% per epoch), the metric's weight, and the percentage shortfall.
For example, if a committer with a 1,000-token stake falls 50% short on RAM (which has a weight of 0.4615), they would be slashed 0.0079 tokens for that metric alone. If they have shortfalls across multiple metrics, each penalty is calculated separately and then summed together - though the total can never exceed 0.003424657534% of the stake per epoch.
### Slashing Examples
_Example 1: Complete Loss of Compute_
A committer has a 1,000-token stake. In an observed epoch, their Current Compute falls 100% short in all four metrics (CPU Single, CPU Multi, RAM, and Storage). Since they failed to provide any of their committed compute, they face the maximum penalty of 0.003424657534% of their stake per epoch, resulting in a total slash of 0.0342 tokens for this epoch. This breaks down as: 0.0079 tokens for CPU Single Core, 0.0079 tokens for CPU Multi Core, 0.0158 tokens for RAM, and 0.0026 tokens for Storage.
_Example 2 (fictional): Partial Loss of exactly 50% Across All Metrics_
A committer has a 1,000-token stake. In an observed epoch, their compute falls 50% short across all four metrics. They are slashed proportionally for this epoch: 0.0040 tokens for CPU Single Core, 0.0040 tokens for CPU Multi Core, 0.0079 tokens for RAM, and 0.0013 tokens for Storage - totaling 0.0171 tokens (0.00171% of their stake per epoch).
_Example 3 (realistic): Variable Shortfalls_
A committer has a 1,000-token stake. In an observed epoch, their compute falls short by different amounts: 12% in CPU Single Core, 15% in CPU Multi Core, 10% in RAM, and 12% in Storage. The resulting penalties for this epoch are: 0.000948 tokens for CPU Single Core, 0.001185 tokens for CPU Multi Core, 0.001580 tokens for RAM, and 0.000316 tokens for Storage - totaling approximately 0.0040 tokens slashed for this epoch.
### What Happens to Slashed Tokens
Of the slashed amount, 10% goes to the Slasher as a reward for detecting the violation, while the remaining 90% is immediately burned, reducing total supply and inflation.
## Slashing Impact
Importantly, committers still earn rewards for any metrics where they met their commitment; only metrics with shortfalls result in slashing. This means partial performance is still rewarded, while failures are penalized proportionally.
Just as rewards flow from committers to their delegators, slashing penalties also affect delegators proportionally based on their stake. When a committer is slashed, each delegator loses the same percentage of their delegated stake as the committer loses from their own stake. However, delegators can redelegate to another committer at any time if they're concerned about their chosen committer's performance.
---
## Staking FAQ
## Understanding the Basics
### What is the Cooldown period?
When a stake is created, the Committer or Delegator chooses a cooldown length. The allowed range differs between networks: on Mainnet, cooldown periods range from 28 days to roughly 3.68 years, while on Canary, they range from 1 hour to 48 hours. When the user decides to unstake, they trigger the cooldown countdown. Only when the cooldown has ended can they withdraw their staked tokens. During cooldown, the reward weight and vote weight are reduced to 50% of the previous value. See the [Mainnet vs. Canary comparison](/staked-compute/mainnet-vs-canary) for exact block values.
### What is the reason for the Cooldown Period to exist?
The cooldown period protects the network from sudden losses of compute capacity. Without it, committers could instantly withdraw their stakes and shut down their hardware, leaving the network vulnerable to instability. The cooldown gives the network time to adjust and allows other providers to fill the gap. It also ensures that committers remain committed to their promise: during cooldown, they must continue maintaining their full committed compute (with full slashing risk) even though their rewards are reduced to 50%. This design discourages impulsive exits and rewards long-term commitment, which is essential for building a reliable, predictable compute network that developers and users can depend on.
### What are Risk/Reward Tradeoffs of Staking with Acurast?
Staking with Acurast follows a clear principle: higher commitment equals higher rewards, but also higher risk. Committers who commit more compute, stake larger amounts of tokens, and choose longer cooldown periods earn proportionally greater rewards - but they also face greater slashing penalties if they fail to maintain their committed compute levels. For example, committing 80% of your measured compute yields more rewards than committing 50%, but falling short on that 80% commitment results in larger slashing penalties. Delegators face a similar tradeoff: they can earn staking rewards without running hardware, but they share in their chosen committer's slashing risk. The key is finding the right balance - commit what you can reliably maintain over the long term. Conservative commitments (lower compute percentage, shorter cooldown) offer lower rewards but also lower risk, while aggressive commitments maximize rewards but require consistent, reliable operation of your hardware.
## Getting Started with Staking
### Why do I only see one slider to Commit Compute, when the four metrics are treated separately anyway?
Even though any stake is basically a separate committement for each of the four of the benchmark pools (CPUs, CPUm, RAM, Storage), the staking frontend only shows one slider for simplicity reasons. For example, if the Committer selects to stake 50% of the measured compute, his stake is a committment to keep up 50% of the compute per Benchmark Metric Pool. Means to upkeep 50% of the CPU Single Core Benchmark Metric, 50% of the CPU Multi Core Benchmark Metric, 50% of the RAM Benchmark Metric and 50% of the Storage Benchmark Metric over the lifetime of the stake.
### Why can I only commit 80% of my measured Compute?
The maximum a user can commit is capped at 80% of the currently total measured compute, in order to prevent early Slashings if the Committer's Compute is fluctuating due to processors going offline.
### Why can I only stake 999 tokens if I have 1000?
When a user stakes tokens, all of these tokens will be locked and cannot be moved. This means that the users account won't be able to pay for gas fees caused by processors to report heartbeats and deployment execution reports. This would result in a situation where this account won't be able to receive rewards from benchmarks or computation without getting additional tokens. Therefore a safeguard deposit of 1 cACU / ACU was introduced.
### What is the maximum of tokens a user can stake?
A committer can stake as much as they want up to the limit defined by their compute metric × the allowed ratio. The higher their benchmark (more or stronger devices), the more stake they can back it with. The committer's own stake cannot exceed some multiple of their compute metric capacity (benchmark score). This prevents someone from locking an enormous amount of ACU behind a tiny phone and unfairly capturing rewards.
## Managing Your Stake
### Can a stake be reduced while it exists?
No. Once a stake is set up, it can only be extended - by a longer cooldown period, committing more computation, or adding more tokens. None of these parameters can be reduced in an active stake.
### How many stakes can a Committer have?
A committer can only have one own stake, but they can delegate one additional stake to themselves and they can delegate unlimited stakes to other committers (one stake per committer), allowing them to create stakes with different cooldown periods and size.
### What happens to my Stake when I migrate or when I transfer processors to a different account?
You must unstake and wait for the cooldown to end, before you can migrate to mainnet or transfer processors to a different account. As the cooldown can take up to 48 hours, you should absolutely trigger unstake before the migration window of 90 days ends.
If you move your processors to a different account, the account with the stake will suddenly lose all of its compute and you will be exposed to staking penalties. It's the same as if you would suddenly cut your internet connection.
## Delegation
### How many delegations can a Committer accept?
While the number of delegations is not limited, a committer's delegated stake is limited dynamically by several parameters, in dependence of their current delegations, the state of these delegations and their own staked compute.
### What happens to the Delegator's stake when the Committer starts cooldown?
Delegators can only choose a cooldown period that is shorter (never longer) than the selected Committer's cooldown. For example, if the selected Committer choses a cooldown of 6 months and the Delegator chose 2 months, once the Committer starts cooldown, it will take 4 months until the Delegator's cooldown automatically starts as well.
Delegators can see when their Committers start cooldown and can redelegate their stake to a different Committer, regardless of whether their own cooldown period has already started.
### What happens to the Delegator's stake when their Committer is slashed?
Delegators are affected by slashing and will lose a pro rata share of their stake if their Committer is slashed. Delegators can choose to redelegate their stake to a different Committer.
## Rewards
### How much in rewards can a Committer or Delegator expect?
Staking rewards in the Acurast network are dynamic and cannot be precisely predicted in advance, as they depend on the collective behavior of all participants. Your individual rewards are determined by your share of the total network commitmen - calculated from your benchmark scores, stake size, and cooldown duration relative to all other stakers. As more participants join with varying parameters, or as existing participants adjust their commitments, the reward distribution shifts accordingly. Additionally, rewards are split across four separate benchmark metric pools, meaning your performance in each metric directly impacts your share of that pool's rewards.
Once the system goes live and staking activity stabilizes, estimated Annual Percentage Rates (APR) will become available to help participants gauge potential returns. However, the fundamental principle remains: stronger hardware, larger stakes, and longer commitment periods will always yield proportionally higher rewards compared to participants with lower commitment levels.
---
## Staking Glossary
## Core Concepts
### Compute Provider
(aka Manager): A user that runs the Acurast processor app on one or more phones.
### Committer
(aka Staker, Manager, Compute Provider): A user that is a Compute Provider who commits compute by Staking.
### Delegator
Users that are Staking Acurast tokens with Committer by attaching their stake to a Committer's stake.
### Stake
A Committers commitment, backed by an amount of Committed Compute, an amount of Acurast tokens and a Cooldown period of a chosen length.
## Compute Metrics
### Benchmark Metrics
Four standardized tests that measure a device's computational capacity: CPU Single Core (0.2307 weight), CPU Multi Core (0.2307 weight), RAM Size (0.4615 weight), and Storage Size (0.0769 weight). These metrics are measured during every device heartbeat and reported on-chain to determine Current Compute and calculate rewards and slashing.
### Current Compute
The amount of compute that was measured across all processors in the last epoch for a specific Compute Provider. During that epoch, all devices ideally had written three heartbeats including three benchmark results. In order to determine the Current Compute for an epoch, the first recorded heartbeat of each device is being used.
### Committed Compute
The amount of compute a Compute Provider commits to providing during the lifetime of a Stake, including its Cooldown period.
### Stake Health
The health state of a Stake, regarding the Current Compute in relation to the Committed Compute.
## Staking Mechanics
### Cooldown
A countdown triggered when a user chooses to exit their stake. During the cooldown period, reward weights are reduced to 50% while slashing risk remains at 100%. When the cooldown period ends, the stake can be finalized and tokens become unlocked and transferable again. The cooldown is measured in blocks and ranges differ by network: Mainnet (28 days to ~3.68 years) and Canary (1 hour to 48 hours). See [Mainnet vs. Canary](/staked-compute/mainnet-vs-canary) for details.
### Unstake
The process of signaling the intention to end a Stake. Unstaking triggers the Cooldown.
### Finalize
The process of withdrawing a stake after the cooldown period has ended, returning the unlocked tokens and any unclaimed rewards to the staker or delegator. Also called "claiming a finalized stake."
### Recommit
Stakes in cooldown cannot be recommitted. After the cooldown ended, they can be finalized and withdrawn.
## Rewards & Penalties
### Total Staking Rewards
The rewards paid to all Stakers by the inflation of the Acurast Blockchain per epoch.
### Autocompounding
Adding accrued rewards to the existing Stake instead of claiming them.
### Claiming rewards
Requesting the accrued rewards to be sent to the Staker or Delegator.
### Slashing
A penalty that can be forced upon Committers, if they do not succeed in keeping up the amount of Compute they committed to (the Committed Compute).
### Slasher
A user that triggers Slashing for a Stake that did not provide enough Compute to match its Committed Compute.
### Slasher's Reward
A percentage of the slashed amount, that is given to the Slasher as a reward for detecting a violated compute commitment.
## Delegation
### Redelegate
Detaching a running Delegation from one Committer and attaching it to a new Committer. Can only be done if the new Committer shares the exact same or higher parameters (Committed Compute, Staked Tokens, Cooldown duration) than the previous Committer and is not in Cooldown.
Redelegation can only be done if the current delegation is older than 7 days or if the stake of the chosen Committer is in cooldown.
### Delegation Fee
A fee Committers can set once upon creating a Stake and will receive from the rewards of the Delegations attached to their stake. The Delegation fee cannot be increased during the lifetime of a Stake, but it can be decreased.
The delegation fee is expressed as a percentage and is deducted from the delegator's earned rewards before distribution. This fee compensates committers for maintaining reliable hardware and high compute capacity that benefits all delegators staking with them.
**Example:** If a committer sets a 10% delegation fee and their delegators collectively earn 100 tokens in rewards during an epoch, the committer receives 10 tokens as their delegation fee from all delegators' accrued tokens, and the delegators receive the remaining 90 tokens.
### Delegation Capacity
The amount of delegations a Committer can accept.
### Stale Delegation
A Delegation is stale if the Committer it was delegated to did trigger a cooldown which did end. A stale delegation will not earn any rewards and should be finalized.
### Committer in Cooldown
A delegation shows "Committer in cooldown" to indicate that the Committer this delegation was delegated to, started the cooldown. All following rewards will be halved, while slashing penalty will stay the same. Delegators can choose to trigger their own cooldown or to delegate to a different committer.
## Time & Measurement
### Epoch
One epoch equals 900 blocks (approximately 1.5 hours).
### Heartbeat
A sign of life that all Acurast Processors emit in the form of a transaction that is sent to the Acurast blockchain. The heartbeat information also contains the results of a new benchmark test. Usually heartbeat is emitted and recorded once per cycle, which is three times per epoch. If a processor is offline, it will not emit heartbeats.
---
## Staking Mechanics
## What is Compute?
Compute is the processing power and core value the Acurast Network offers to developers. Compute is physically embodied in the smartphones which run the Acurast processor app all around the globe. The main components of these phones, which are important for Acurast are their processors (CPU), the memory (RAM) and the Storage.
### What is Current Compute?
The measured compute of a Compute Provider is displayed as **Current Compute** on the Staking frontend. It represents the current total compute power measured across all of a provider's devices. Compute is broken down into four benchmark metrics: CPU Single Core, CPU Multi Core, RAM, and Storage.
### How Current Compute is measured
Current Compute is measured through four benchmark tests (CPU Single Core, CPU Multi Core, RAM and Storage) conducted on every device running the Acurast processor. These tests run automatically during each device heartbeat (every 30 minutes) and the results are reported on-chain. The first valid benchmark report per epoch (900 blocks / roughly 90 minutes) will set a processor's Current Compute per benchmark metric and it's deployment activity state for that epoch. Read more about the technical aspects of the benchmark tests [here](/acurast-processors/benchmarks).
The results of the latest benchmark tests, show on the display of the processor app, if you tap the "Compute Score" card. Each Benchmark Metric card displays the exact results from the last benchmark test. The Relative Compute Score on top represents how this device scores against the global score of all devices in the Acurast network.
Screenshot of the processor app
On the Staking UI, the sum of all benchmark test scores is displayed - summed up per benchmark metric. Again, the Total Current Compute displayed on top, is just a relatve amount. The absolute sum per benchmark metric across all devices of this committer is shown below.
Screenshot of the staking UI
All scoring activities, which lead to rewards and potentially slashings, are done using the four absolute benchmark metrics which were reported in an epoch - not on the singular number that is displayd as "Relative Compute Score" on the processor or as "Total Current Compute" on the Staking UI.
### Benchmark Metric Weights define Benchmark Metric Pools
Each of the four benchmark metrics has a weight assigned to reflect its importance to the Acurast network's computational requirements and resource priorities. These weights ensure that providers are incentivized to maintain balanced, high-quality compute resources, with RAM being the most heavily weighted metric due to its critical role in application performance:
| Benchmark Metric | Weight |
|-----------------|--------|
| CPU Single Core | 0.2307 |
| CPU Multi Core | 0.2307 |
| RAM | 0.4615 |
| Storage | 0.0769 |
These Benchmark Metric Weights define how staking rewards are split between the different Benchmark Metrics pools. For each 1 ACU that is emitted as staking reward, 0.2307 are assigned to the CPU Single Core Pool, 0.2307 are assigned to the CPU Multi Core Pool, 0.4615 is assigned to the RAM pool and 0.0769 is assigned to the Storage pool.
The Staking frontend is showing the four metrics, as measured in the last epoch for each Committer.
## Rewards
Staking rewards are generated from Acurast's token inflation and distributed every epoch to committers and delegators who support the network. The amount each participant earns depends on three key factors: the strength of their committed compute (measured by benchmark scores), the size of their staked tokens, and the length of their cooldown period. In short: stronger hardware, bigger stake, longer commitment = bigger rewards.
## Reward Flow
Staking Rewards trickle down through several pools and are split up:
**Inflation → Staked Compute Pool**
Each epoch, a share of the inflation (70% on Mainnet and 5% on Canary) goes to the Staked Compute Pool. These reward tokens are created by the protocol and minted directly into the Staked Compute Pool.
**Staked Compute Pool → 4 Benchmark metric pools**
From the Staked Compute Pool, the reward tokens are further split between four Benchmark Metric Pools according to the Benchmark Metric Weights that are composeed from the committer's and his delegators' chosen parameters, mainly
- the staked token amount (shared for all metric pools commited into)
- the chosen cooldown periods for these stakes (shared for all metric pools commited into)
- the committed compute (for the metric pool of consideration)
:::info
**Limited stake per commitment (incl. delegations)**
Every committer will attract delegations, depending on his set fee. The total value (own stake + delegations' stake) we call the _commitment stake_. The desired total _commitment stake_ needs careful planning from the committer since it has a limit. Depending on the committer's own stake he can attract more or less delegated stake. The limit consists of two parts, whatever hits first rules:
- the committer needs to provide at least one part out of 10 from the total commitment stake (incl the delegators stakes). This corresponds a ratio of 1:9, own vs delegators stake.
- An additional limit ensures that the stake backing a single farm stays within a reasonable range. This limit prevents someone from locking an enormous amount of ACU behind a small device and unfairly capturing rewards. The limit is derived from a global $\text{target\_weight\_per\_compute}^{(p)}$, that is in turn dependent from the total supply and total onboarded compute power, measured in regular benchmarked:
$
T^{(p)} := \frac{0.8 \times \text{total\ supply}}{\text{total\ benchmarked\ metric}^{(p)}}
$
that expresses the ideal staking rate given the current compute offered over our system.
:::
**Committer's Share → Self vs. Delegators**
A committer's reward is split relative to the token amounts and chosen cooldown periods, between their own weight
$
\text{committer\_weight}_c := \text{stake}_c \times \frac{\text{cooldown}_c}{\text{MAX\_COOLDOWN}}
$
and the total weight of their delegators
$
\text{delegators\_weight}_d := \sum_d{\left[ \text{stake}_d \times \frac{\text{cooldown}_d}{\text{MAX\_COOLDOWN}} \right]}
$
**Benchmark Metric Pools → Committers**
The share of rewards each committer gets depends on a score calculated from following factors, which can be chosen or influenced by the committer when creating the stake.
The reward split is calculated for each Benchmark Metric Pool $p$ separately. The relative score of a participant $c$ compared to other participants is calculated as
$
\text{committer\_score}_c^{(p)} = \min\left[\text{committer\_weight}_c + \text{delegators\_weight}_d, \; T^{(p)} \times \text{metric}_c^{(p)}\right]
$
In each epoch, the staking reward is split into rewards for each metric pool, $\text{REWARD}^{(p)}$, according to the weights described in [Benchmark Metric Weights](#benchmark-metric-weights).
For one specific pool $p$ a committer $cs reward (to be shared with his delegators) is
$
\text{reward}_c^{(p)} = \frac{\text{committer\_score}_c^{(p)}}{\sum_c{\text{committer\_score}_c^{(p)}}}
$
In short: stronger hardware, bigger stake, longer commitment = bigger rewards.
**Delegators Split**
The remaining delegator rewards are split between all delegators of the same committer, according to each delegator's weight. Also the delegation fee is split off to the Committer. The following factors influence delegation rewards for a delegator $d$ towards a committer $c$:
$
\text{delegator\ reward}_d = \text{delegator\ weight}_d - \text{delegation\ fee}_c - \text{potential\ slashings}_c
$
### Where the rewards come from
Acurast inflates its token supply every year, by 5% (currently, can be changed by governance). On Acurast Mainnet, that inflation is split between the following pools:
- 70% → Staked Compute Pool (The rewards for Staking)
- 15% → Treasury
- 10% → Base Benchmark Rewards (independent from Staking)
- 5% → Acurast blockchain block producers (Collators aka Validators)
### When are rewards distributed
Rewards are distributed to every committer and their delegators once every epoch (one epoch is 900 blocks) with the first reported heartbeat of the committer.
## Rewards to be Expected
Staking rewards in the Acurast network are dynamic and cannot be precisely predicted in advance, as they depend on the collective behavior of all participants. Individual rewards are determined by the participant's share of the total network commitment - calculated from benchmark scores, stake size, and cooldown duration relative to all other stakers. As more participants join with varying parameters, or as existing participants adjust their commitments, the reward distribution shifts accordingly. Additionally, rewards are split across four separate benchmark metric pools, meaning performance in each metric directly impacts the share of that pool's rewards.
Once the system goes live and staking activity stabilizes, estimated Annual Percentage Rates (APR) will become available to help participants gauge potential returns. However, the fundamental principle remains: stronger hardware, larger stakes, and longer commitment periods will always yield proportionally higher rewards compared to participants with lower commitment levels.
## Impact of Cooldown on Rewards and Slashings
### Reduced Rewards During Cooldown
When a committer triggers the cooldown period to exit their stake, both their reward weight and their delegators' reward weights are immediately reduced to 50% of the previous value. This means that throughout the entire cooldown period, the committer and all their delegators will earn only half the staking rewards they earned before cooldown was initiated. This reduction reflects the reduced commitment to the network, as the participant has signaled their intention to withdraw.
### Slashing Remains at Full Rate
Importantly, while rewards are halved during cooldown, slashing penalties are not reduced. Committers must continue to maintain their full committed compute throughout the cooldown period, and any shortfalls will result in standard slashing penalties calculated at 100% of the normal rate. This ensures that committers cannot reduce their hardware commitment once they've initiated cooldown - they must maintain their promised compute capacity until the cooldown period ends and they finalize their stake.
---
## Staked Compute
If you are not redirected automatically, please click [here](/staked-compute/overview).
---
## Claiming Vested ACU
Some entities and individuals have received ACU tokens that are vested for a certain period of time, as outlined in the [token allocations](/tokenomics#token-allocations). Vested tokens originate from early funding rounds, team allocations, and airdrops. As time passes, the owners can claim the released tokens.
To claim the released tokens, follow these steps:
1. Log in to [hub.acurast.com](https://hub.acurast.com) using the account that owns the vested tokens.
2. Go to the **Balances** tab.
3. Next to the vested balance, a claim button should be visible and the amount of claimable tokens will be displayed.
4. Click **"Claim"** and sign the transaction when prompted in your wallet.
---
## Tokenomics
Acurast is the decentralized compute network designed to power the emerging decentralized compute economy by aligning developers, compute providers, and end-users around shared incentives.
At the heart of Acurast is the ACU token and economic model, fueling a secure, scalable, and decentralized compute ecosystem while incentivizing active collaboration and sustainable growth.
Also, with tokenomics, the focus is on a sustainable community-first approach.
## Key Highlights
- **Initial Supply:** 1,000,000,000 ACU
- **Fixed inflation:** 5% fixed annual inflation distributed to Staked Compute Pool (70%), Compute Pool (10%), On-chain Treasury (15%), Collators (5%)
- **Only 6.5% allocated to early backers** — while important for funding and supporting development all the way to mainnet, this allocation was kept very low in order to facilitate a fair launch of the token.
- **Nearly 70%** of tokens are allocated to the community or community-supporting purposes (Community Treasury, Community Activation, Operational Funds, Liquidity Provision).
- **Team and Advisors have a 6 month lock-up and 36 months linear vesting,** aligning them with the long-term mission of the project.
By capping Early Backers at just 6.5% and allocating the majority of tokens to the community and community-supporting initiatives, the token distribution **puts the ecosystem interests first,** acknowledges early contributions to the broader crypto ecosystem, and **fosters the creation of services and products** on top of Acurast — ultimately supporting the project's roadmap and long-term objectives. Moving the needle again to decentralization, because decentralized compute is not for the few but for the many.
## Token Utility
The ACU token is what makes the entire decentralization of the protocol possible. Decentralization is one of Acurast's core values and impacts every protocol-related decision. ACU enables users to participate and interact with the protocol with these key functions:
1. **Network Fees** As a very active orchestration layer (over 395M transactions on testnet) the Acurast network requires transaction fees to avoid spamming and to keep a high quality of service to this crucial component.
2. **Incentivization of compute provision:** Similar to how Bitcoin rewards miners for creating blocks, Acurast is incentivizing compute providers through fixed inflation.
3. **Staking:** The novel concept of Staked Compute allows Acurast to economically secure reliable, verifiable, and widely accessible compute resources through staking collateral. This enables participants, including those without hardware, to earn rewards, delegate stakes, and leverage restacking for enhanced capital efficiency and network governance.
4. **Governance:** With an on-chain treasury of over 24% allocation, which replenishes itself from part of the inflation. With token holders making the protocol and future development-related decisions.
## Genesis Token Allocation
### Allocation Categories
- **Community Activation:** Tokens from the participation of the CoinList Token Launch, canary token conversions, airdrops and additional broader activation of the community on TGE.
- **Community Treasury:** With decentralization in mind from the first day, a large part of the tokens are allocated towards the community treasury, allowing ACU holders to determine through on-chain governance the future development of the protocol and support significant contributions via governance proposals.
- **Operational Funds:** Strategic funds with the mandate to foster protocol acceleration and growth, governed by the Acurast Association council.
- **Liquidity Provision:** This allocation is used exclusively to ensure enough liquidity of the Acurast Token on centralized and decentralized exchanges.
- **Early Backers:** A small, diverse group providing initial funding to ensure the protocol reaches mainnet maturity without heavy institutional influence.
- **Team and Advisors:** Tokens for the core contributors of the protocol, encompassing employees, advisors, founders and future key team members, with a 6 months lock-up and 36 month vesting; this allocation is structured to align for long-term incentives.
### Token Allocations
| Category | Supply | Token Amount (ACU) | Available at TGE | Vesting Cliff (months) | Linear Vesting (months) |
| ------------------------------------------------------------------------ | ------ | ------------------ | ---------------- | ------------------------------------------------------------------------ | ----------------------- |
| Community Activation | 5% | 50,000,000 | 0% | 0 | 24 |
| Early Compute Providers(cACU to ACU Conversion) _(Community Activation)_ | 6.5% | 65,000,000 | 0% | 3 – 44 (user selectable one time; exit possible any time after 3 months) | 0 |
| Cloud Rebellion Airdrop _(Community Activation)_ | 1% | 10,000,000 | 0% | 0 | 24 |
| Listing Incentives _(Community Activation)_ | 5% | 50,000,000 | 100% | 0 | 0 |
| CoinList Token Launch _(Community Activation)_ | 6.50% | 65,000,000 | 100% | 0 | 0 |
| Operational Funds | 11.50% | 115,000,000 | 0% | 3 | 24 |
| Community Treasury | 24.00% | 240,000,000 | 0% | 3 | 24 |
| Team and Advisors | 24.00% | 240,000,000 | 0% | 6 | 36 |
| Liquidity Provision \* | 10% | 100,000,000 | 100% | 0 | 0 |
| Early Backers | 6.50% | 65,000,000 | 0% | 0 | 24 |
_\* No lockups but only 30% allocated at TGE. These tokens are exclusively used to foster liquidity long-term._
## Token Utility
**Network Fees:** The Acurast network, a Proof of Stake blockchain, acts as an orchestrator for the decentralized compute economy. To interact with the Acurast network, ACU is required for gas fees (_i.e.,_ transaction fees).
**Staking:** Processors and delegators stake ACU to participate in the [Staked Compute Pool](/staked-compute/overview), earning rewards from epoch inflation for providing and securing compute capacity. Every ACU holder can participate through Delegation without running their own Processor.
**Compute Costs:** When developers schedule deployments, compute costs are paid as gas fees.
**Governance:** Holders of ACU can engage in protocol governance by voting on a variety of proposals brought forward by the community, guiding the development of the protocol and its components, and ensuring true decentralization and future-proof evolution by design.
## Inflation
Inflation is what makes the Acurast process sustainable by rewarding active participation in the protocol and creating incentives to be run as a decentralized protocol indefinitely. The protocol sets a fixed inflation of 5% annually, depending on various on-chain metrics, and can be further adapted through governance votes.
- 70% → Staked Compute Pool (The rewards for Staking). More on [**Staked Compute ↗**](/staked-compute/overview)
- 15% → Treasury
- 10% → Benchmark rewards (Base rewards processors, shared in relation to the benchmarks, independent from Staking). More on [**Benchmarks ↗**](/acurast-processors/benchmarks)
- 5% → Acurast blockchain block producers (Collators aka Validators)
---
## Wallets
A non exhaustive list of wallets supporting Acurast:
- [AirGap](https://airgap.it/)*, see a comprehensive guide here: **[Use AirGap with Acurast ↗](/wallets/wallets-airgap)**
- [Talisman](https://talisman.xyz/)*, see a comprehensive guide here: **[Use Talisman with Acurast ↗](/wallets/wallets-talisman)**
- [SubWallet](https://www.subwallet.app/)*, see a comprehensive guide here: **[Use SubWallet with Acurast ↗](/wallets/wallets-subwallet)**
- [Nova Wallet](https://novawallet.io/)
- [Phantom](https://phantom.com/)
- [WalletConnect compatible wallets](https://reown.com/)
- [Metamask](https://www.metamask.io)
- [Coinbase Wallet](https://www.coinbase.com/wallet) — requires "Base mode" to be disabled, see guide: **[Base Wallet ↗](/wallets/wallets-base)**
\* Recommended wallets
---
## AirGap Wallet
# Secure offline setup of AirGap for Acurast
AirGap is a self-custody solution, developed by Papers AG, with a two-device approach:
- **Offline signer** holding the private keys
- **Online wallet** to execute transactions
Signing payloads are transported via QR codes.
## 1. Make the offline phone ready and install AirGap Vault
:::info
You can also download AirGap Vault from the Google Play or Apple App store and take the phone offline afterwards.
For the best possible security, follow the steps below.
:::
1. Get a new phone that will only be used for offline signing and never has a connection to the internet.
- An Android phone is recommended.
- Also get a fresh USB stick which you can connect to the phone.
2. You don't need to log in to a Google Account, but you need to set a **PIN code, pattern, fingerprint or face-id** for your device.
3. Start the phone and update it to the latest OS.
4. Take the phone offline, remove all previous Wi-Fi connections (so it can't connect accidentally), and set it to **Airplane Mode**.
5. Download the latest [AirGap Vault APK from GitHub](https://github.com/airgap-it/airgap-vault/releases) and move it to the USB stick.
6. Plug it in and install the APK on your phone, give the necessary permissions.
## 2. Install AirGap Wallet on the online phone
7. On the online phone, install AirGap Wallet from the [Google Play Store](https://play.google.com/store/apps/details?id=it.airgap.wallet) or [Apple App Store](https://apps.apple.com/app/airgap-wallet/id1420996542).
## 3. Generate a new secret
8. Open the AirGap Vault app, skip through the initial messages and accept the disclaimer.
9. Select the **offline configuration** and skip to the screen where you can generate a new secret.
10. Select **Generate** and give permissions for camera and microphone.
11. Go through the entropy generation process (touch, gyro, camera, mic).
12. Write down the secret recovery seed phrase and store it according to best practices.
- ❌ Do not store the seed phrase on an online device.
- ❌ Do not store it in an online password manager.
13. Verify the written-down recovery seed phrase.
14. Set an **encryption password** and ensure you always remember it.
- ✅ You may use a password manager here (but never store the seed in it).
## 4. Generate an Acurast account and sync with AirGap Wallet
15. Add an Acurast account and confirm with your encryption password and the device PIN. A new Acurast address will be generated.
16. Click on the new Acurast account, then click on the **AirGap Wallet** button → a QR code will be displayed.
17. Open AirGap Wallet and scan the QR code of the offline device.
- The account's **public key** will be imported into your AirGap Wallet.
## 5. Verify the recovery
18. In AirGap Vault, go back to the main screen.
19. Click on the card of the newly generated secret.
20. Tap on the 3-dot menu → **Secret management** → scroll down and select **Delete** → Confirm Secret Removal.
- The secret is now wiped from the offline phone.
21. Go back to the main screen and select **Import**.
22. Import the secret recovery phrase from your written notes.
23. Set the same encryption password as before.
24. Once done, generate an Acurast account.
25. Compare the recovered account to the account synced in step 17.
- ✅ If they match → recovery successful.
- ❌ If not → delete and start again from step 10.
## Important to know
1. The **encryption password** set in step 14 will determine the derived account.
- If you forget it, recovery is impossible even with the seed phrase.
2. Follow best practices when storing the seed phrase:
- Example: metal plate in safe, paper note in safe, ensure you can identify the right seed.
3. Do not store the encryption password in the same place as the recovery seed.
4. More documentation: [AirGap Support](https://support.airgap.it/)
5. **NEVER** connect your offline phone to the internet.
- If you must, first completely remove the secret from the phone.
6. If you need to copy the account address, copy it from the online phone with AirGap Wallet.
## Resources
- [AirGap Step by Step Setup Guide](https://support.airgap.it/guides/step-by-step-guide/)
- [AirGap Vault Releases on GitHub](https://github.com/airgap-it/airgap-vault/releases)
- [AirGap Wallet Releases on GitHub](https://github.com/airgap-it/airgap-wallet/releases)
- [AirGap Wallet on Google Play Store](https://play.google.com/store/apps/details?id=it.airgap.wallet)
- [AirGap Vault on Google Play Store](https://play.google.com/store/apps/details?id=it.airgap.vault)
- [AirGap Wallet on Apple App Store](https://apps.apple.com/app/airgap-wallet/id1420996542)
- [AirGap Vault on Apple App Store](https://apps.apple.com/app/airgap-vault/id1417126841)
---
## Base Wallet
Base Wallet's smart wallet mode ("Base mode") is not yet supported on Acurast. If you have it enabled, you will need to disable it before connecting to the Acurast Hub.
## Error
When trying to connect with "Base mode" enabled, you will see the following error:
**Connection Failed** — *Please disable "Base mode" in the Wallet settings and try again.*
## How to disable Base mode
1. Open the Coinbase Wallet app and tap your **profile icon** (top-left).
2. Scroll down and toggle off **Base mode**.
3. Go back to [hub.acurast.com](https://hub.acurast.com/) and reconnect your wallet.
---
## Ledger Hardware Wallet (coming soon)
:::caution Ledger Support Not Yet Available
Ledger hardware wallets **cannot currently be used to sign Acurast transactions**. While it is possible to derive an Acurast address using a Ledger device, transaction signing is not yet supported. This means you cannot send tokens, stake, or interact with the Acurast network using a Ledger.
Full Ledger support is being worked on and will be announced once available.
:::
## Current Limitations
- **Transaction signing is not supported** — You cannot approve or submit any on-chain transactions (transfers, staking, etc.) using a Ledger device on Acurast.
- **Message signing only** — Ledger can currently only be used to sign messages, not transactions.
- **Do not transfer funds** to a Ledger-derived Acurast address until full transaction signing support is confirmed, as you will not be able to move them.
## What to Use Instead
In the meantime, you can use one of the following supported wallets to interact with Acurast:
- [SubWallet](/wallets/wallets-subwallet)
- [Talisman](/wallets/wallets-talisman)
- [AirGap](/wallets/wallets-airgap)
---
## SubWallet
This guide explains how to create an address with [SubWallet](https://www.subwallet.app/). SubWallet is a comprehensive non-custodial wallet for Polkadot, Substrate, and Ethereum ecosystems.
:::info
SubWallet is the recommended wallet for Acurast due to its excellent support for Polkadot parachains and user-friendly interface. It's available as a browser extension and mobile app.
:::
## 1. Install SubWallet
### Browser Extension
1. Visit the official SubWallet website: [www.subwallet.app](https://www.subwallet.app/)
2. Click **"Download"** and select your browser (Chrome, Firefox, Brave, or Edge)
3. You'll be redirected to your browser's extension store
4. Click **"Add to [Browser]"** to install the extension
5. Pin the extension to your browser toolbar for easy access
### Mobile App
1. Download SubWallet from:
- **iOS**: [Apple App Store](https://apps.apple.com/us/app/subwallet-polkadot-wallet/id1633050285)
- **Android**: [Google Play Store](https://play.google.com/store/apps/details?id=app.subwallet.mobile)
2. Install and open the app
## 2. Create a New Wallet
When you first open SubWallet:
1. Click **"Create a new account"**
2. SubWallet will generate a recovery phrase (seed phrase) for you
3. **Write down your recovery phrase** and store it securely offline
4. Confirm your recovery phrase by selecting the words in the correct order
5. Create a strong master password for your wallet
6. Click **"Continue"** to complete the setup
:::danger IMPORTANT
Your recovery phrase is the master key to your wallet. Anyone with access to it can access your funds. Never share it, and keep multiple secure backups.
:::
## 3. Enable Acurast Network
To use Acurast with SubWallet, you need to enable the Acurast network:
1. Open the SubWallet extension or app
2. Click the **hamburger menu** (three horizontal lines) in the top left
3. Select **"Manage networks"** or **"Manage chains"**
4. In the search bar, type **"Acurast"**
5. Enable the Acurast network by toggling the switch:
- For Mainnet: Enable **"Acurast"** (coming soon)
- For Canary: Enable **"Acurast Canary"**
6. Close the network settings
Your SubWallet will now display your Acurast balance and allow you to interact with the Acurast network.
## 4. Get Your Acurast Address
To receive Acurast tokens, you'll need your Acurast address:
1. Open the SubWallet extension or app
2. Make sure you have the Acurast network enabled
3. Your main account view will show your balance
4. Click on the account name or address to view details
5. Click on your address or the **copy icon** to copy your Acurast address
6. Your address will be copied to the clipboard in the correct Acurast format
You can now share this address to receive ACU (Mainnet) or cACU (Canary) tokens.
## 5. Connect SubWallet to the Acurast Hub
To interact with the Acurast Hub using SubWallet:
1. Go to [hub.acurast.com](https://hub.acurast.com/) and click **Enter Hub**
2. Click **Connect**
3. Select **SubWallet** from the list of available wallets
4. In the SubWallet extension popup, review the connection request
5. Select the account(s) you want to connect to the hub
6. Click **Connect** or **Approve**
7. On the connection modal of the hub, your account will appear
8. Click on your account to enter the hub
You are now connected and can manage your Acurast deployments and processor operations.
## Troubleshooting
### SubWallet not connecting to Acurast Hub
- Make sure you have the Acurast network enabled in SubWallet
- Try refreshing the hub page
- Check that the SubWallet extension is unlocked
- Try to reconnect it to the hub, by clicking the connector icon next to your account
- Clear your browser cache and try again
### Balance not showing
- Verify that you've enabled the Acurast network in SubWallet settings
- Check that you're looking at the correct account
- Try switching networks and switching back to Acurast
- Wait a few moments for the network to sync
## Additional Resources
- [SubWallet Official Website](https://www.subwallet.app/)
- [SubWallet Documentation](https://docs.subwallet.app/)
- [SubWallet Support](https://docs.subwallet.app/main/support)
- [Acurast Hub](https://hub.acurast.com/)
---
## Talisman
This guide explains how to create an address with [Talisman](https://talisman.xyz/) wallet. To install the browser extensions, follow their setup instructions.
:::info
Most wallets allow you to create a generic polkadot address that is supported by Acurast, this guide focuses on the Talisman wallet.
:::
## 1. Create an Acurast address with Talisman
Once you created your recovery phrase follow these steps to create an Acurast address:
1. Open the settings menu (more) in your Talisman browser extension and select *Add Account*
2. Choose *New Polkadot Account*.
3. Select the Recovery Phrase to use and give your Account a name, eg "Acurast", then click *Create*
4. In order to display Acurast tokens, go to *Networks & Tokens* in the Settings menu and select *Manage Networks*. Then click *+ Add network*
5. Select *Polkadot* as platform, then enter the following data:
For Acurast Canary:
RPC Url: **`wss://public-rpc.canary.acurast.com`**
Native Token Symbol: **`cACU`**
Native Token Decimals: **`12`**
Native Token Name: **`cACU`**
Display Balances: **`Yes`**
6. Your Acurast Account on Talisman is now ready to be used and to sign transactions
## 2. Get the address of your Acurast account on Talisman
Open your Talisman browser extension and select the Acurast account. Then click on the copy&paste symbol on top right and your Acurast account address will be copied into the clipboard.
## 3. Connect your Talisman account to the Acurast Hub
1. Go to [hub.acurast.com](https://hub.acurast.com/) and click *Enter Hub*
2. Click *Connect*
3. Open your Talisman browser extension
4. On top of your Talisman extension, select the account you want to connect to hub.acurast.com
Select it and the bullet point will turn green:
5. Go back to the hub.acurast.com page and click *Talisman*. The account will now appear under *Select Account*. Click it
6. You are now connected to hub.acurast.com
---
## Whitepapers
## Acurast Whitepaper
**Published:** March 17, 2025
The original Acurast whitepaper introducing the decentralized compute network powered by smartphones and Trusted Execution Environments (TEEs).
[Read on arXiv →](https://arxiv.org/abs/2503.15654)
---
## MiCA Whitepaper
**Published:** February 21, 2025
The MiCA (Markets in Crypto-Assets) whitepaper is Acurast's regulatory compliance document for the European Union's crypto-asset regulation. It provides detailed disclosure about the ACU token, its utility, governance, risks, and compliance with EU regulatory requirements.
[Read the whitepaper →](https://docsend.com/view/vxyaenm9z2mfghg9)