connecting to the coordinator

Run a storage provider.

A provider is a Linux box with spare disk and a public HTTPS address. It holds encrypted chunks it cannot read, answers a merkle proof challenge for each object on a continuous cycle, and is paid in USDC for every proof it passes. The software is one open-source binary; the network it joins is the one on the live network page.

active storage providers · failure domains
fleet capacity · used
objects under contract
merkle proofs passed, last cycle ·

Live from coordinator.obsideo.io/network, recomputed every 60 seconds. Aggregates only, the same feed as /network/.

01What a provider does

Holds ciphertext, proves it, gets paid

  • Stores encrypted 1 MiB chunks. Customers encrypt before upload; a provider never sees plaintext and never holds a key. Each object is written as chunk files under a merkle root, so ZFS, ext4 or XFS all work.
  • Answers proof challenges. On a continuous cycle of roughly four hours the coordinator asks for a random chunk and its merkle path for each object you hold. Your node signs the answer with an identity it generated on first start.
  • Earns per passed proof. Payouts are challenge based and settled in USDC: you are paid for the storage the network can continuously prove you are holding. A failed proof earns nothing for that object that cycle; there is no score to rebuild.
  • Serves restores, not traffic. This is origin and backup storage. Objects are read on restore and for verification, so read volume stays low. You are paid to hold durable, provable copies, not to run a delivery endpoint.

What you keep

  • Your hardware, your rules. The coordinator can place data on you and verify it; it cannot log in, cannot read what you hold, and has no administrative delete path. Upgrades are an ask, never a push.
  • Your signing key. The node's Ed25519 identity is created locally at mode 600 and never leaves the box. Every proof you produce is attributable to it.
  • Your capacity. You declare what you offer at registration and can re-register with a new figure. The node does not enforce the cap itself, so keep disk monitoring on the data volume.
  • Your exit. Stop the node and the network re-replicates what you held to keep every object at three copies.

02Requirements

NeedDetail
Linux, amd64Any modern distribution. The release is a single static Go binary with no runtime dependencies; a Windows build exists for testing.
Direct HTTPS on 443A public DNS name that resolves to your host, with TLS terminated at the node or at a reverse proxy (Caddy, nginx) that forwards to the provider's local port. A routable public IP or a port forward is fine. Relays and tunnels are not supported on the data path (ngrok, Cloudflare Tunnel, Tailscale Funnel): they throttle bulk transfer and a tunnelled node underperforms on placement.
CapacityDisk you are willing to fill, declared in bytes at registration. Put the data directory on a persistent volume; the network verifies what you hold, it does not back you up.
Outbound HTTPSThe node heartbeats to the coordinator every 30 seconds and refreshes its coverage list daily. No inbound ports other than 443.
A wallet, eventuallyPayouts go to a Noble (Cosmos) USDC address. You can register without one and add it later in the config.

03Four commands

Download the release and check its signature, run init, and start. init fetches the coordinator's public key, generates your node identity, writes the config, checks that your public address really reaches this process, registers, and prints your provider id. Everything it does is also spelled out step by step in OPERATOR_SETUP.md if you prefer to do it by hand.

# 1. get the release and verify it $ wget https://github.com/Regan-Milne/obsideo-provider/releases/latest/download/obsideo-provider-linux-amd64 \ https://github.com/Regan-Milne/obsideo-provider/releases/latest/download/SHA256SUMS $ sha256sum -c SHA256SUMS --ignore-missing $ chmod +x obsideo-provider-linux-amd64 && mv obsideo-provider-linux-amd64 obsideo-provider # 2. key, identity, config, reachability check, register (needs your TLS proxy already forwarding 443 to :3334) $ ./obsideo-provider init --address https://storage.example.com --capacity 10TB --data /srv/obsideo # 3. after approval: paste the API key into config.yaml, then $ ./obsideo-provider start --config config.yaml

04What happens after you register

STEP 1 · MINUTES

Pending

Your registration lands with status pending. Send the provider id to regan@obsideo.io or post it in the Telegram group. Approval is manual today.

STEP 2 · ON APPROVAL

Your API key

Approval issues your provider API key. It is shown exactly once on our side and comes to you out of band, through whatever channel your security policy prefers. It is never emailed automatically.

STEP 3 · ~5 MINUTES

Heartbeating

Start the node with the key in place. It heartbeats every 30 seconds; after 10 consecutive heartbeats it becomes eligible to receive objects.

STEP 4 · FIRST CYCLE

Proving and earning

Objects arrive as customers store data. Each is challenged on the next cycle, roughly every four hours. You earn for every proof you pass, settled in USDC to the wallet in your config.

Payout rates are agreed per operator and confirmed before your node goes live; the mechanism is the same for everyone: prove it, get paid. Existing operators and the current fleet are on the network page.

05Data centres

Why a data centre is different

  • You are a failure domain. The network's durability story is three copies across independent operators and facilities. A node in your facility, on your network, is independence the fleet does not get from adding another box to an existing site.
  • The requirements are a non-issue. A public IP, TLS on 443 and a static route to the node are what you already do. No agents on your side, no shared credentials, no inbound access for us.
  • Self-serve by design. Your engineers take the release from the public repository and stand the node up. We never touch your machines; we approve the registration and issue one credential.
  • Nothing in the setup is sensitive. The coordinator key you fetch is public. The only secret in the process is the provider API key issued at approval, and you choose how it reaches you.

What we ask for, and what you may ask us

  • From you: the node's public address, the capacity you are offering, a technical contact, and a rough sense of timing. That is enough to approve.
  • From us, on request: a written operator agreement, a security and architecture sheet for your compliance review (the trust model and security policy are already public), the rate card, and the published proof format so your team can verify possession independently.
  • A staged start. Begin with a bounded slice of capacity, watch the first proof cycles land, then grow. There is no commitment in registering a node.
  • Write to regan@obsideo.io with "storage node" in the subject and we will set up a call or reply in writing, whichever you prefer.

Software: github.com/Regan-Milne/obsideo-provider, MIT licence, releases with published SHA-256 checksums. This page carries no per-node figures and no proof pass rates; per-provider rates vary by node and we have chosen not to publish them. Network aggregates last generated: .