Introduction

The Internet connected computers. Blockchain connected value. AI connected intelligence. What was still missing is an open protocol connecting compute. Cloudiy is that protocol: any identity can provide computational resources, and any identity can consume them, through one universal API.

HTTP made the location of a document irrelevant: you ask for a URL, never a server. cloudiy makes the location of computation irrelevant: you declare a workload and the capabilities it needs, and the protocol resolves discovery, placement, isolated execution and settlement. If HTTP standardized exchanging information between computers, cloudiy standardizes exchanging computational capacity between them.

Cloudiy is not a cloud provider, not a marketplace, not a GPU rental platform. You describe what you need; the protocol decides how it runs. Docker, VMs, drivers and networking are implementation details behind swappable interfaces. The end state is that running code somewhere else feels like calling a function:

• • Everything is a Resource: CPU, memory, GPU, VRAM, storage, bandwidth, and future hardware, without redesign.
• • Everything is an Identity: human, AI agent, company, DAO or another protocol: indistinguishable by design.
• • Capabilities are first-class: request cuda:12.8 and pytorch, never "machine X".
• • The unit of execution is the Workload: declared, scheduled, isolated, measured, destroyed. Resources return automatically.

Nobody asks which server hosts a website. Soon nobody will ask which machine ran a workload. cloudiy is not a product at the end of that road, it is the layer other products are built on, the way HTTP carried far more than websites.

Architecture

cloudiy is layered so that each layer only knows the one below it: the protocol defines the nouns, the scheduler turns a declaration into a placement, and the runtime executes it in isolation. Container engines live at the very bottom, behind a trait, they are implementation, never protocol.

The four layers

Reference implementation

The reference implementation is a Rust workspace: protocol (pure domain), scheduler (filter/scorer pipeline), runtime (Runtime trait), common (wire, keys, signing), sdk, and the unified cloudiy binary. Transport is P2P QUIC via iroh (dial-by-NodeID, NAT hole-punching, end-to-end encryption), with an HTTP/WebSocket gateway for browsers.

CloudiyOS

CloudiyOS is the protocol's reference interface, not a separate product. It consumes the same SDKs and gateway available to everyone, anyone can build a different UI on top of the protocol.

CloudiyOS is the network rendered as an operating system in the browser. You log in with a Solana wallet and land on a desktop backed by your own persistent, identity-bound virtual machine, one Docker container plus a named volume that survives stop/start, reachable over the P2P network.

• • My Virtual Machine: compose CPU / RAM / GPU / storage; specs update as you attach hardware.
• • App Store: ready-to-run model endpoints (Ollama, vLLM, SDXL, ComfyUI, LTX-Video, Whisper, Axolotl…).
• • Hardware Store: rent a whole machine or individual parts, or offer your own machine's parts to the network.
• • Terminal: a real PTY shell into your VM (xterm.js over the gateway WebSocket).

A local gateway bridges the browser to the P2P network so the OS runs against real nodes:

Open the gateway origin and everything, model endpoints, the terminal, the wallet-signed escrow deposit, talks to live providers. Served statically (e.g. on Vercel), the same page runs as an interactive preview.

Providers

Providers don't rent computers, they contribute resources. Install the node, and it detects your hardware. You choose the slice to share; the rest stays private:

The Node ID (an ed25519 key) is your address on the network, no port forwarding, no public IP (QUIC hole-punching via iroh). Your Solana keypair receives USDC payouts. Add --require-payment --rpc-url <url> to accept only jobs backed by a verified on-chain escrow, --directory <id> to get listed for discovery, and --runtime runsc|kata-runtime for stronger isolation of untrusted workloads.

Consumers & SDKs

Consumers declare workloads: what to run, which resources, which capabilities. Never a machine, never a driver:

Or from an app / AI agent, via SDK (Rust · Python · JS):

Workloads run in mandatory isolation (namespaces, cgroups, no host execution) and the environment is destroyed at the end, resources return to the pool. The Python SDK is zero-dependency and exposes as_tool_schema() so an LLM can call remote compute as a function. Without payment the node answers Payment Required with its x402 USDC quote.

AI agents & MCP

Cloudiy is agent-native: cloudiy mcp serves the whole network as MCP tools over stdio. Any MCP client, Claude Code, IDEs, autonomous agents, can discover providers, get an x402 quote, lock USDC in escrow, run a workload and release payment against the on-chain signature check. No API keys, no accounts, no signup.

Eight tools cover the full consumer loop:

Safety rails: devnet by default (--allow-mainnet to opt out), a per-job cap and a cumulative session cap on escrowed USDC, and a --read-only mode that removes every transaction-signing tool. Agents that don't speak MCP can use the zero-dependency Python SDK's as_tool_schema() instead.

Models

A model on cloudiy is a public inference endpoint: a container from the App Store recipe catalog, placed on a live provider and reachable over plain HTTP. There is no model registry to trust and no account to open, the endpoint is just compute that happens to serve a model, priced per request in USDC.

Ready-to-run runtimes

The catalog ships the runtimes teams actually deploy, each a configurable recipe with its own version, GPU, disk and environment variables:

Calling a model

Every endpoint answers Payment Required with its x402 USDC quote, the caller pays and retries, and the request runs. No key, no idle: nothing is billed between calls.

Deploy your own from the App Store, or let an agent do it with cloudiy_deploy. Either way the result carries the provider's ed25519 signature, so payment settles only against a proof of the work.

Payments & Escrow

Settlement is USDC on Solana, behind interfaces. Pricing is quoted over HTTP via the x402 protocol: a node answers 402 Payment Required with its USDC price and the client retries with proof, no accounts, no API keys. For real value transfer, funds are locked in an on-chain escrow and the provider verifies the deposit before executing.

The escrow flow

• 1. pay: the consumer funds an escrow (create_job), locking USDC in a program-owned vault.
• 2. run: the provider verifies the escrow on-chain (right job id, mint, payout, amount) and executes, returning a signed result.
• 3. release: the consumer releases the escrow, paying the provider minus a 4% protocol fee.
• 4. refund: after the deadline, unspent funds return to the consumer.

Program and status

The escrow program (Anchor) is live on devnet: 9zMBC7JDA8SJ2mk3ATYqRuJvn14MQyZVg9q3XPnzc1TN. The full loop is verified end-to-end on devnet. In CloudiyOS, the same create_job is signed directly by your wallet (Phantom), deposit USDC to a provider without leaving the browser; keys never leave the wallet.

Trustless settlement

Every result is signed by the node that produced it, and the escrow can require that proof on-chain before paying out. This is release_verified: unique among compute networks: payment is cryptographically bound to a provider-signed result, not to a dashboard's word.

• 1. The provider signs cloudiy/result/v1 ‖ job-id ‖ sha256(output) with its network identity key (the same ed25519 key behind its Node ID).
• 2. The escrow stored that node key at create_job time, the consumer chose who to pay before the work started.
• 3. release_verified(output_hash) makes the Solana Ed25519 precompile re-verify the signature inside the same transaction; the contract checks the signer is the escrow's node key and the message matches.
• 4. Settlement is permissionless: anyone holding the proof can settle, but the payout addresses are fixed on-chain, a settler can't redirect a cent.

Token-incentive networks verify hardware off-chain and pay on trust. Cloudiy pays in USDC against an on-chain proof that the provider you chose signed the result: adversarially tested on devnet (tampered signatures and wrong-signer proofs are rejected by the contract).

Discovery

You can dial a provider directly by Node ID, or discover many through a directory node: a lightweight bootstrap registry that relays signed provider announcements. Directories can't forge or alter an entry: every announcement is ed25519-signed by the announcing node, and consumers verify the signature before trusting a single field.

The scheduler picks a placement across the discovered pool when you don't name a node. Multiple directories can be listed and merged; unreachable ones are skipped.

CLI reference