Stake to Compute

Staking for NEAR AI is live.

Stake NEAR to pay for confidential inference and to deploy always-on @ironclawAI agents. Credits scale with your stake. No credit card required.

🧵 pic.twitter.com/N3shWe0zun

— NEAR AI (@near_ai) July 30, 2026

A client recently sent me NEAR AI’s stake-to-compute product. The premise was simple: stake NEAR, keep the principal, and use the staking rewards to pay for confidential inference or an always-on agent.

I wanted to know what sat behind that sentence.

I started coding crypto products in 2018, nearly nine years ago. Kryptos, my first public crypto project, was a Python investment assistant with portfolio strategies, exchange data, machine-learning models, workers, and Docker deployment. The chains and tooling have changed since then, but the engineering question has stayed familiar: where does the economic promise end and the operating system begin?

That question has followed me into Solana. I have worked through its token programs, payment verification, x402 settlement, and recurring subscription design. I have also written about why Solana already has the protocols needed for useful financial products. The difficult work is composing those primitives into a product that can survive real custody, billing, and infrastructure failures.

So I reverse-engineered NEAR AI’s economics and mapped them onto Solana. What began as a staking product led me to a harder question: can an AI agent fund its own continued existence?

What NEAR AI actually sells

NEAR AI does not give users free compute for holding tokens. Its terms describe a payment arrangement.

The user retains the staked principal and wallet keys. Protocol rewards go to NEAR AI as payment for service. In return, the user receives non-transferable compute credits rather than yield or a new token.

I read this as compute financed by an assigned revenue stream. The stake produces the payment; the service converts that payment into inference and hosting.

There are two billing models underneath the same product story:

• Agent hosting: stake maps to a monthly allowance that refreshes and expires.
• Cloud inference: stake maps to continuously accrued credits that generally do not expire.

One behaves like a subscription. The other behaves like a metered balance funded by ongoing rewards. I make the same distinction when designing agentic payments: moving value is only the settlement step. A working product still needs metering, entitlements, retries, reserves, and a policy for what happens when the money runs out.

The Solana design

I would not start by writing a new staking protocol. Native Solana stake accounts already separate the stake authority from the withdrawal authority. Delegating SOL does not transfer ownership of the principal to the validator. At each epoch, Solana separates the validator commission from the delegator reward.

That gives me a direct mapping:

The first implementation needs a dedicated validator, native stake accounts, an indexer, and a credit ledger. The indexer attributes effective stake and realized commission to each account. The ledger converts that revenue into a conservative compute allowance.

I would use Solana Subscriptions and Allowances for recurring overages or spending limits, then x402 for requests that should settle at the point of inference. This fits the broader pattern I see in the Solana stablecoin economy: the chain handles authorization and settlement, while the application remains responsible for pricing, accounting, recovery, and compliance.

The product still has to absorb three timing problems.

Stake activates and deactivates across epochs. Validator commission arrives after the service has begun. Compute prices and SOL prices can move in opposite directions. If I grant credits immediately, I am advancing compute against future rewards and taking the balance-sheet risk myself.

A second tradeoff is custody. A user-controlled stake account preserves withdrawal rights, but the user can leave. A program-controlled vault can enforce a stronger commitment, but it weakens the custody story. I would begin with native stake accounts and epoch-based verification because the custody boundary is easier to explain and audit. If the economics later require a vault, that should be an explicit product change.

When the agent can outlive its creator

This architecture becomes more interesting when the delegator is the agent itself.

An agent can have a persistent on-chain identity, control a stake account, and direct its staking revenue toward inference. Identity alone is insufficient, a point I explored in Trustless Agents. An identity tells other systems who the agent is. It does not keep the agent alive.

My test is stricter: could I disappear today without funding another wallet, signing another transaction, renewing an account, or repairing the process, and would the agent still have a credible path to operating one year from now?

For that answer to be yes, I need to verify four properties:

1. The agent controls the withdrawal authority for its stake and the keys cannot be extracted by the host.
2. Realized commission covers inference, TEE hosting, transaction fees, monitoring, and recovery.
3. The agent holds enough reserve to survive validator underperformance, SOL drawdowns, and compute-price increases.
4. The agent can replace a failed validator, RPC provider, model, or host without waiting for its creator.

An attested TEE helps protect code and keys, but it does not solve the whole problem. Hardware fails. Attestations expire. Providers change APIs. Validators miss rewards. Economic sovereignty requires supplier replacement and recovery paths, not only isolation.

What I would build

I would keep the first version narrow:

• Native SOL stake under the agent’s withdrawal authority.
• A dedicated validator with commission revenue attributed by stake account.
• An offchain ledger that grants credits only after applying a reserve factor.
• Attested execution with key rotation and a documented migration path.
• Subscription and x402 payment rails for costs that staking does not cover.

I would then run it long enough to measure realized yield against total operating cost. The decisive metric is not APY. It is months of autonomous runway after compute, infrastructure, failures, and replacement costs.

Nine years of building crypto software have made me suspicious of systems that call themselves autonomous because they can sign a transaction. The stronger claim is earned when the agent can remain solvent, protect its authority, and recover from a failed supplier without me.