Skip to main content

Providers

Overview​

Providers form the core of the Atlas Network and are responsible for contributing CPU resources to a shared pool. This section provides all the information required for providers, including technical and staking requirements, as well as a step-by-step guide on onboarding as a provider.

Prerequisites​

To provide compute machines, you must be registered and satisfy the following requirements.

Requirements​

  • Dedicated machine satisfying the following minimum requirements:
    • CPUs or vCPUs: ≥2
    • GB RAM: ≥4
    • SSD storage: ≥80GB NVMe Storage
    • Network bandwidth: ≥1Gbps unlimited
    • Uptime: ≥ 99%
    • OS: Debian (12+) or Ubuntu (22.04+) installation with Linux kernel 6.1+, updated with the latest security patches
    • Allow all IPv4 address traffic on ports:
      • UDP 8472
      • TCP 10250
      • UDP 51820
      • UDP 51821
info

Providing compute is a commitment. Your compute must be from a standalone machine which you're not using for anything else. That means a personal computer will not qualify. Compute may be provided by a desktop, laptop, VM or server instance on a centralized or decentralized cloud. Atlas will handle the firewall.

  • A fresh installation of Debian (version 12 or higher) or Ubuntu (version 22.04 or higher) with a Linux kernel version 6.1 or higher, including the latest security updates and kernel
  • No third-party applications or monitoring agents installed
  • No intervention with the workload or machines
  • Atlas Network's integration must be run directly on a machine at root:
    • You can't run it in Docker
    • Don't run it on a homelab
danger

Failing to meet these prerequisites may result in the suspension of the provider’s email address, wallet, and machine being banned across all platforms, as well as a slashing of funds.

Provider Capacity​

In Atlas Network, the capacity that every provider adds to the pool is measured in a unit called a Compute Unit (CU). One CU is a machine with one CPU, 2GB RAM, and 30 GB storage.

1 CU = 1 CPU | 2GB RAM | 30 GB Storage

Every machine a provider adds gets broken down into the number of CUs; the total of all the minimum CUs is the provider capacity.

Example: One provider brings three machines to the pool.

Machine1: 1 CPU | 4 GB RAM | 100 GB Storage Machine2: 2 CPU | 4 GB RAM | 200 GB Storage Machine3: 4 CPU | 8 GB RAM | 500 GB Storage

CU of Machine1: min(1 | 2 | 3.3) = 1 CU of Machine2: min(2 | 2 | 6.6) = 2 CU of Machine3: min(4 | 4 | 16.6) = 4

The provider capacity = 1+2+4 = 7

Here is another example. Consider a machine with this spec. 4 CPU | 7.57 GB RAM | 150.16 GB Storage

CU: min (4 | 3 | 5) = 3

Staking​

In Atlas Network, every provider must stake 2000 $NODE for provider onboarding. For every CU the provider brings to the pool, an additional stake of 200 $NODE for each machine.

In the above example, the provider stakes 2000 $NODE for provider onboarding and stake 200, 400, & 800 $NODE for each machine.

Node Scheduling and Deployment​

In the Atlas Network, different nodes can run on provider machines.

Node operators can choose from several options for their node deployment; for details, refer to Node Operators. Every auto-assign workload deployment happens on a machine best suited for it. The Atlas Network Scheduler is responsible for finding the best machine whenever a new auto-assign workload is added to the pipeline.

Auto-assign deployment flow

The scheduler logic works in three stages:

  1. It searches for all the machines among all the providers with free CUs that are more than or equal to the CU requirement for the workload.
  2. Next, the scheduler picks the least utilized machine among all these machines.
  3. Finally, the machine with the most uptime gets selected from this group for the workload deployment.

The second condition ensures that the workload deployment distribution is fair and does not become concentrated among a few providers.

Uptime is a crucial metric for all providers and their machines. It measures the amount(%) of time the machine has been available in the provider pool.

In Atlas Network, we want to put machines with the highest uptime ahead in the workload deployment queue. Since rewards are also dependent on running workloads, providers are incentivized to have machines with the maximum uptime they can.

Machine Uptime

If more than one machine passes the third condition, the logic will randomly select one machine from this group. Once the final machine is selected, the Atlas Network client receives a deployment request, which triggers the actual deployment process.

Service Level Agreement(SLA)​

Since provider machines will run nodes of various protocols, they must have a high uptime. Providers must ensure that their machines have 99% or more uptime annually. Machines that meet this requirement are chosen for node deployments, which means having a less uptime machine will impact the earning potential.

To maintain a robust network, machines with less than 99% uptime could be removed.

Rewards & Slashing​

Coming soon

Troubleshooting​

Q. Can I check why my machine is not transitioning to active state? A. Yes. From the machine terminal, and run the following command to check if you're facing any issue or if you haven’t met the requirements.

journalctl -fu atlas*

Next steps​

If you are ready to become a provider, follow our Get Started guides to: