
Deeploy Unlocked: Accessing the Power of Ratio1
For CSPs
Education
Since the beginning, the vision behind Ratio1 has been clear: create a decentralized computing protocol where Cloud Service Providers (CSPs) operate like franchisees, building sustainable businesses on top of the protocol’s economy. Instead of Ratio1 directly chasing end-users, CSPs act as the bridge - thriving on Ratio1’s capabilities while delivering services to their clients.
To make this vision a reality, we built the Deeploy App (R1-301): a simple yet powerful gateway that gives CSPs seamless access to Ratio1’s distributed computing power.
Who Can Become a CSP?
One of the strengths of Ratio1 is its openness. Almost anyone can become a CSP.
At present, the requirements are:
Owning a Node Deed / Master Node Deed License linked to an Oracle Node
Passing the KYC/KYB verification process
Without a licensed Oracle Node, a user cannot interact with the Deeploy App, since the app communicates with the Deeploy API through these nodes.
This article is written both for those just curious about Ratio1, and for those seriously considering stepping into the role of a CSP.
What is the Deeploy App?
Think of the Deeploy App as Ratio1’s control center for CSPs.
It is a continuously evolving application that already comes with pre-built deployment templates for:
Generic applications
Common services
Native apps
And this is just the beginning. As CSPs and their clients demand more, the template library will expand to cover new use cases - ensuring that no workload is left unsupported.
From Node Operator to CSP to Deployed Jobs
Turning a Node into an Oracle
To step into the role of a CSP, a Node Operator must apply to become both an Oracle Operator and a CSP. It’s important to note that once a Node is turned into an Oracle, its license will not directly run jobs, meaning it will not receive Proof of AI rewards from job execution. Instead, its role is to mediate and interact with the Deeploy API.
Deploying a CSP Smart Contract
When a CSP logs in for the first time at deeploy.ratio1.ai, they are prompted to deploy their CSP Smart Contract.
This step is foundational:

Every CSP owns their own smart contract
All CSP activity is traceable on-chain
Deployments remain transparent and independent
In other words: your business as a CSP runs on infrastructure you fully control, with accountability baked in. More information on this subject will be provided in the below “behind the scenes” chapter of this article.
Organizing with Projects & Jobs

Once a CSP has a smart contract, they can begin by creating projects. A project can consist of one or many jobs - for example:
A dApp
A CMS application
A database cluster
This project-based structure keeps things neat, organized, and scalable.
Deployment Flow: Tunnels & Jobs
Before starting a job within a project, CSPs must first create a tunnel.
Why? Because tunnels establish secure communication between applications and the Ratio1 infrastructure. They’re created and managed directly in the Tunnels section of the Deeploy App.
To enable this, CSPs simply connect their Cloudflare credentials, allowing the CSP to create and manage Cloudflare Tunnels directly from the Deeploy App.
This modular setup ensures that even complex, multi-job deployments remain flexible, secure, and manageable.
Deeploying a Job
The actual job deployment journey looks like this:
Create a project and add jobs inside it.
Choose a job type from templates (Generic App, Service, or Native App).

Specify machine requirements - with or without GPU, and the number of nodes.

Apply filters for node selection. Currently, only the KYB label is supported (ensuring Node Operators are verified companies), but more labels are coming soon (e.g., Dora compliance, geographic location, and industry standards).
Review job specs & pricing - including run time.

Fill deployment information - environment variables, ports, image links.

Finalize and pay - lock USDC into the escrow smart contract to confirm deployment.
At this point, the job is officially on Ratio1.
To make onboarding even easier, we’ve created a step-by-step end-to-end application deployment tutorial. This guide walks CSPs through the full process inside the Deeploy App - from creating a project and setting up tunnels, to configuring jobs, locking funds, and launching workloads on Ratio1. Whether you’re new to decentralized compute or an experienced operator, the tutorial ensures you can move from zero to live deployment with confidence.
Watch the full tutorial here:
Link
Behind Deeploy: The Technical Pillars
The Deeploy workflow brings together two layers: off-chain processing handled by the Ratio1 oracle network, and on-chain execution secured by smart contracts. The oracle network takes care of receiving, validating, and launching jobs, while the escrow system ensures that funds are safely locked for the duration of the job (or for the portion already paid). On-chain consensus then guarantees that every job transition is recorded and tamper-proof - for instance, when a worker drops a job and it is instantly reassigned, or when the system scales horizontally by adjusting the number of replicas. This design ensures transparency, immutable records, secure transactions, and budgets that can always be verified.
Your path as a Cloud Service Provider (CSP) begins by building reputation within the network and having one of your nodes granted "oracle status" - a step that, for now, only the Ratio1 team can approve. Once your node becomes an Oracle, you gain access to the Deeploy App, where you will deploy your own CSP Escrow Smart Contract. This contract securely holds the funds committed to job execution and releases them gradually to the participating Node Operators.

1. Escrow Smart Contracts - Proof of AI (R1-302)
For the oracles network to accept and start a job through Deeploy, each workload needs to lock the expected budget inside a verifiable smart contract, so that every oracle knows the payout is guaranteed before allocating compute. This is why we developed CSP Escrow Smart Contracts, implemented with the Beacon Proxy pattern: the CSP is the on-chain owner of its escrow instance for creating jobs, topping up balances, and adjusting replicas, while the Ratio1-owned beacon guards upgrades and protocol rules across all escrows.
How this works:
- Each escrow deployment mints a dedicated contract instance initialised with the CSP address as `cspOwner`. Only this address can call job lifecycle methods such as `createJobs`, `extendJobDuration`, or `extendJobNodes`, keeping economic control in the CSP's hands.
- Consensus-sensitive operations remain delegated to the PoAI Manager (`PoAIManager.sol`). Only the manager can write oracle observations on-chain (`updateActiveNodes`) or trigger epoch distributions (`allocateRewardsToNodes`), ensuring that no single CSP can bypass multi-oracle agreement.
- During every allocation cycle the contract separates the job budget into rewards and a protocol burn: 85% is queued for node operators, 15% is swapped to R1 and burned, meaning each CSP contributes to the long-term health of the token economy.
- Rewards are tracked per node inside the escrow (`virtualWalletBalance`). Node Owners claim them via the PoAI Manager, which swaps the accumulated USDC to R1 and transfers the tokens on-chain, providing auditable settlement for every epoch.
- Safeguards such as balance checks, per-epoch accounting, and the ability for the manager to reconcile jobs ensure Node Providers cannot be short-changed, even if a CSP fails to extend or close jobs on time.
- Jobs are always pre-funded: `createJobs` multiplies the catalogued price-per-epoch by the number of requested replicas and prepaid epochs (minimum 30), instantly transferring the matching USDC into escrow so capital is locked before a single container launches.
2. Deeploy & ChainDist - Distributed Consensus for Workloads (R1-342)
ChainDist is the glue between what Deeploy launches off-chain and what the smart contracts recognise on-chain. The `chain_dist_monitor.py` service runs on every oracle node, continuously syncing local telemetry with contract state to keep the Ratio1 network honest.
It orchestrates a set of consensus-driven loops:
- Validation loop: Oracles pull the list of unvalidated jobs from the PoAI Manager (`get_unvalidated_job_ids`) and compare it with the workloads they see running. Only when at least one third of oracles report the same node set does the manager persist that view via `submitNodeUpdate`, aligning the escrow `activeNodes` with reality.
- Closure loop: When a job budget is exhausted, oracles coordinate to tear it down. Each monitor queries `get_first_closable_job_id` to agree on the next job that should be sunset, waits a randomised backoff, removes workloads from the network, and submits an empty node list on-chain so the job is marked closed and funds stop streaming out.
- Rewards loop: After each epoch ends, monitors stagger calls to `allocate_rewards_across_all_escrows()`. The PoAI Manager iterates through every escrow, moving accrued balances to node wallets and enforcing the burn. If an oracle misses its slot, others can finalise the distribution, preserving liveness.
- Availability loop: `check_all_active_jobs` continuously reconciles every running job, stops any extra nodes that are executing workloads without being on the paid roster, and redeploys replicas on healthy nodes whenever a worker disappears, keeping applications highly available.
Under the hood the monitor cross-references on-chain data with the live fleet: it inspects the applications each node advertises (`network_known_apps`) to build the canonical worker set, converts those identifiers into Ethereum addresses with `node_address_to_eth_address`, and only then votes on consensus. The same map powers safeguards such as `get_first_closable_job_id` queries, automated pipeline removals, and proactive job restarts, ensuring node providers are never left running unpaid workloads while customers retain the capacity they purchased. Consensus thresholds are explicit: more than half the active oracles must submit a view before PoAI Manager evaluates proposals, and one third plus one matching submissions is required before the contract mutates state.
Because each of these loops settles with an on-chain transaction, oracle operators need to keep a buffer of ETH in their nodes to pay gas for validation votes, closures, and reward allocation calls - participating in consensus without it would stall the network. Reminder: each individual node has its own private EVM key and thus each individual wallet with Base L2 accessible funds.
By combining deterministic contracts with this off-chain consensus mesh, Deeploy keeps job assignments, payouts, burns, and jobs status in sync across the entire network.
3. Open Development & Templates
Ratio1 is designed as an open ecosystem. On GitHub, CSPs can find:
Deployment templates
Service adapters
Best practices for secure and scalable deployments
That means both developers as well as CSPs are able to deploy both 3rd party applications but also applications and frameworks developed by Ratio1 Community for various purposes - from cybersecurity to computer vision, from sensor network monitoring to decentralized private storage. Community contributions continuously enrich the protocol - expanding what CSPs can offer their clients.
Why Deeploy Matters
For CSPs:
A one-stop gateway to onboard, deploy, and manage jobs
On-chain accountability through CSP smart contracts
New revenue opportunities through the Ratio1 economy
For Clients:
Access to a growing network of providers
Transparent, verifiable deployments
Proof of computation integrity
For the Ecosystem:
Expanding marketplace of applications
Stronger decentralization by lowering CSP entry barriers
A thriving protocol economy powered by real workloads
The Road Ahead
The Deeploy App is just the beginning. With every iteration, it will become more intuitive, efficient, and flexible - making it easier for anyone to tap into Ratio1’s decentralized compute.
Whether you’re a seasoned cloud provider or a curious newcomer, Deeploy is your gateway to unlocking the power of Ratio1.
Petrica Butusina
Sep 3, 2025

