Crypto AI Agents Need a New Kind of Compute. Here’s Why Acurast Matters.

 

AI agents are moving beyond conversation. Crypto AI agents can hold wallets, call smart contracts, pay for services and execute tasks onchain without a human approving every step.

 

Infrastructure such as x402 lets agents pay for APIs in stablecoins. Agentic wallets give them the ability to spend within limits set by their owners.

 

But with autonomy also come new security concerns.

 

A chatbot leaking its conversation history is a privacy problem. An autonomous crypto agent leaking its credentials, or running code that someone has secretly modified, can become a security incident with real onchain consequences.

 

Yet many agents still run on laptops, conventional VPS instances or centralized cloud infrastructure. These environments can be convenient, but they raise important questions: Who can access an agent’s runtime? How can anyone verify what code is running? And what happens when a single provider goes offline or decides to shut it down?

 

Crypto agents need more than compute. They need confidential execution, verifiable infrastructure and a way to access compute without relying on a single provider.

 

Acurast offers a different approach: a distributed compute network built on smartphone hardware security.

Five Requirements for Crypto-Native Compute

 

An autonomous agent needs five core properties from its runtime.

These requirements aren’t unique to crypto. But when software can control a wallet or trigger onchain actions, the consequences of getting them wrong become much more significant.

 

Why Conventional Cloud Infrastructure Leaves Gaps

 

Centralized cloud platforms offer familiar tools, reliable infrastructure and straightforward deployment. The issue isn’t that they are inherently insecure. It’s that their trust model may not match the needs of autonomous, wallet-enabled software.

 

• The provider remains part of the trust boundary. Without additional hardware-backed protections, privileged infrastructure operators may be able to inspect a workload’s memory, storage or configuration. For an agent, those surfaces can contain sensitive context and credentials.
• Verifying the runtime can be difficult. When an agent runs on someone else’s infrastructure, users need a way to establish what environment it is running in and whether the deployed workload matches what they expect. A deployment description alone isn’t independent proof of execution.
• Infrastructure can become a single point of failure. An outage, account suspension or policy change at one provider can interrupt every agent that depends on it.
• Traditional provisioning assumes a human operator. Cloud accounts, billing arrangements and access credentials are designed around people or organizations. An autonomous agent that already has a wallet needs a more programmatic way to request compute.

 

The broader industry is moving toward dedicated computing environments for agents. Meta’s Muse and OpenAI’s Dots illustrate this direction.

 

But for crypto-native agents, the question extends beyond giving every agent its own computer.

Acurast: Compute Built on Smartphone Hardware

 

Acurast turns smartphones into a distributed compute network. Rather than relying on centralized data centers, it coordinates a network of phones (Processors) distributed across the world.

 

Its approach addresses the five requirements in different ways.

 

1. Hardware-backed confidentiality

 

Acurast runs Deployments inside hardware-backed Trusted Execution Environments (TEEs).

 

A TEE provides an isolated execution environment designed to protect sensitive data and computation from the surrounding system. This creates a stronger confidentiality boundary than relying on ordinary software permissions alone.

 

Deployment environment variables can supply secrets to a workload at runtime, keeping them within the intended execution boundary.

 

For crypto agents, this is particularly relevant to API credentials, private context and other sensitive configuration. The goal is to reduce the amount of trust users must place in the phone owner or infrastructure operator.

 

As with any security architecture, the actual protection depends on the hardware, implementation and deployment configuration.

 

2. Hardware attestation

 

Confidentiality addresses who can access a workload. Attestation helps establish what kind of hardware is running it.

 

Before a workload is dispatched, Acurast uses hardware attestation to verify eligible phones. This helps distinguish genuine supported hardware from phones that fail the network’s checks.

 

Combined with the deployment process, attestation provides a basis for verifying infrastructure and execution prerequisites rather than relying solely on an operator’s assurances.

 

For autonomous agents, that distinction matters: security claims should be supported by verifiable evidence wherever possible.

 

3. Distributed infrastructure

 

Acurast coordinates Processors across a network of phones operated by different owners.

 

This distributes compute beyond a single conventional infrastructure provider. It can reduce dependence on one company’s machines and operational decisions, although the resilience of any particular deployment still depends on its configuration and the network’s available capacity.

 

For agents that monitor protocols or perform recurring infrastructure tasks, reducing dependence on a single host is a meaningful architectural advantage.

 

4. Existing workloads, without a complete rewrite

 

Through Cargo, developers can deploy a range of Linux workloads, including Python, Go, Rust, C++, shell scripts and binaries.

 

Developers can use familiar tools, inspect logs over SSH and adapt existing agent frameworks rather than rebuilding their entire applications around a proprietary runtime.

 

Cargo supports Linux workloads on Android Processor Core phones, while iOS Processors continue to support JavaScript workloads.

 

This makes Acurast relevant not just to developers building new agents, but also to teams looking to move existing workloads onto a different compute architecture.

 

5. Wallet-based access to compute

 

With the Acurast Deploy Agent, an agent can request compute through an HTTP interface and pay in USDC on Base using x402.

 

Depending on the request, it can obtain a job deployment or request a VPS. A VPS request can return a public, SSH-accessible Ubuntu environment running on a Processor.

 

A VPS request works without a conventional Acurast account, a local CLI or ACU tokens.

 

This creates a useful building block for agentic systems: software can request the infrastructure it needs, execute a task and allow the deployment to expire, subject to the configured duration and spending limits.

 

The result is a compute model that fits naturally into wallet-enabled software.

 

Three Ways to Run Crypto AI Agents on Acurast

 

The network’s capabilities translate into three practical deployment patterns.

 

1. Run the entire agent on a Processor

 

For workloads that need continuous execution and access to sensitive configuration, the whole agent can run inside a TEE on an Acurast Processor.

 

Two examples already have Cargo applications in the Acurast example apps repository:

 

Hermes: an autonomous agent with scheduling, memory and tool use.

 

OpenClaw: a personal assistant capable of scheduled and multi-step tasks.

 

Developers can configure the environment in .env, specify the deployment duration in acurast.json and deploy using acurast deploy. The resulting agent URL is delivered to a configured callback endpoint.

 

For teams with their own agent, Cargo templates provide a starting point for bringing an existing framework into the environment.

 

Best suited for: scheduled agents, protocol monitoring, recurring maintenance and workloads that benefit from hardware-backed confidentiality.

 

2. Keep the agent’s reasoning private

 

An agent can protect its runtime credentials and still expose sensitive context if it sends every prompt to a third-party model API.

 

Depending on the workload, Acurast offers two approaches to running inference within a TEE.

 

Run a model directly on a Processor. The Acurast LLM module supports many GGUF models from Hugging Face. This can suit lightweight inference tasks such as classification, extraction and summarization.

 

Run an AI gateway. In an early experiment involving Pocket Network and NodeGhost, an OpenAI-compatible gateway ran as a Cargo build and handled alternating inference and web-search requests for an hour without dropped requests.

 

The gateway experiment is exploratory rather than a guarantee of production-scale performance. It nevertheless demonstrates the potential to run a more complete inference workflow on smartphone-based compute.

 

Best suited for: agents processing confidential documents, internal research, private operational data or prompts that teams don’t want routinely sent to third-party inference providers.

 

3. Let the agent provision its own compute

 

An agent doesn’t necessarily need a permanent server or a human to manage every deployment.

 

Using the Deploy Agent, an agent can make an HTTP request that includes an x402 payment in USDC on Base and a job specification or VPS request.

 

For example, an agent could request a compute environment to perform a scheduled infrastructure task, connect to the returned Ubuntu machine over SSH, complete the task and let the deployment expire.

 

No conventional Acurast account or local CLI is required for this workflow.

 

Paired with an agentic wallet and an explicit spending limit, this provides a practical foundation for programmatic compute provisioning.

 

Best suited for: temporary workloads, automated maintenance, task-specific environments and agents that need to acquire compute on demand.

 

Five Crypto Agent Use Cases

 

The strongest applications are those where continuous operation, confidential execution and verifiable infrastructure provide tangible value.

These are infrastructure use cases, not guarantees that an agent’s decisions or outputs will always be correct. Application logic, data sources, permissions and operational safeguards still matter.

 

The broader point is that agents can be designed to depend less on trust in a single operator. Instead, developers can combine hardware-backed protections, attestation, distributed infrastructure and explicit access controls.

 

That is a natural extension of the principles that have shaped crypto infrastructure from the beginning.

 

The Next Layer of Crypto Infrastructure

 

Crypto spent years building systems that reduce dependence on intermediaries. Autonomous agents introduce a new challenge: software that can act independently also needs infrastructure it can operate on without blindly trusting the operator.

 

Acurast brings together smartphone-based compute, hardware-backed confidential execution, attestation and wallet-based provisioning in an architecture designed for that challenge.

 

It offers developers a way to explore a different model for running agents: one where the runtime can be more confidential, the infrastructure more distributed and access to compute more compatible with autonomous software.

Getting Started

 

The quickest way to explore Acurast is to deploy an existing agent before building your own.

 

Choose an example. Browse the Acurast example apps and start with Hermes or OpenClaw.

 

Follow the deployment tutorial. Configure the environment and deployment duration, then deploy the application, as shown in the Hermes tutorial.

 

Build your own workload. Use the Acurast Quickstart and CLI documentation to adapt your existing agent.

 

Explore autonomous provisioning. Read the Deploy Agent documentation if your agent needs to request and pay for compute programmatically.

 

Whatever infrastructure you choose, follow three basic rules when deploying a crypto agent:

 

• Use a dedicated wallet or account. Grant only the permissions the agent needs, and set explicit spending limits.
• Keep secrets out of prompts and logs. Supply credentials through the appropriate deployment configuration and avoid exposing them in agent conversations.
• Plan for deployment expiry. Set an appropriate duration and store essential state in durable storage, since temporary deployments may stop and their local data may be deleted when they expire.

 

These safeguards matter regardless of where the agent runs. Better compute infrastructure complements sound wallet design and careful application-level security; it doesn’t replace them.

Building on Acurast? If you’re running agents, agent backends or inference services on phones, the Acurast Discord is where builders compare notes. Join the Discord.

Related Blogs