AtomOne is a branch of Gaia that complements the broader Cosmos ecosystem with a security-conscious alternative hub. AtomOne recommits to the founding vision of the Cosmos Hub as a minimal IBC/ICS hub secured by a staking token targeting two-thirds of the stake bonded. AtomOne contributors uphold the original values of the Cosmos Hub—security, sustainability, decentralization—and agree that hub minimalism enforced by a written constitution is the only way to ensure financial security and scale to billions of people.

atomone

Exchange and monetise Trusted Data that is verifiable, portable, and privacy-preserving.

cheqd

mexc

coinbase

Dymension is a blockchain powering the Internet of RollApps. It is a Layer-1 blockchain built to support Modular Rollapps natively with its own RaaS and rollup framework.

dymension

MANTRA is a Real World Asset (RWA) Layer 1 blockchain built with CosmWasm and EVM compatibility, designed for compliant on-chain asset tokenization.

mantrachain

Oraichain connects AI APIs to smart contracts, enabling the development of Dapps with AI capabilities.

oraichain

Quicksilver lets users stake their tokens with their desired staking provider and issues a token that provides liquidity - all while remaining separate from the staking provider.

quicksilver

An interoperable Layer-1 multi-chain Web3 ecosystem focused on the issuance and management of digitally native real-world assets (RWAs). Its design is fully open-source, permissionless, and purpose-built.

realio

Shentu is a security-focused Cosmos SDK blockchain built around the idea of provable trust - combining on-chain security oracles with static and dynamic analysis to surface real-time security insights and prevent attacks before they happen. Beyond the base network, its ecosystem includes OpenMath (decentralized verification of mathematical proofs) and OpenBounty (a Web3 bug bounty platform connecting projects with security researchers), alongside a Cosmos-native multisig wallet for collaborative fund management.

shentu

Follow Logs

Container Status

Restarts the process with the arguments the container was created with - .env edits are not picked up.

Restart

A plain restart ignores .env edits - the container has to be recreated.

Apply .env Changes

The container and its data stay; a stopped validator misses every slot it is given.

Stop

Start Again

What the live container really runs - `docker compose config` only shows what would be applied.

Show Running Arguments

`isSyncing: false` and a few peers means the node is at the head.

Sync Status & Peers

`currentBlock` climbs towards `highestBlock` while syncing.

Sync Progress

Read from the metrics port on the host. Finalized should trail best by only a few blocks - a growing gap means GRANDPA finality is stalling.

Best and Finalized Block

Blocks this node authored in the last hour. 0 is expected until the team adds you to the set and two sessions pass.

Producing Blocks?

Node Version

Local Peer ID

Connected Peers

Account Public Key (hex)

`true` means this node can sign with the keys you registered.

Node Holds the Session Keys

Both halves of `keys` are filled in from the keys field. Both must return true.

Check Aura and GRANDPA Separately

In Polkadot.js Apps. It must return the same keys as `author_hasSessionKeys` checked - otherwise the chain expects keys this node doesn't hold.

Keys Registered On-chain

Only when you mean to replace them: the old keys stop working, and you must submit the new `keys` and `proof` with session.setKeys before the next session.

Rotate Session Keys

Signed from your validator account in Polkadot.js Apps. Removes your session keys on-chain - do this before shutting a validator down for good, and tell the Orbinum team.

Leave the Validator Set

Watchtower already pulls new images within about 5 minutes; this does it immediately.

Update Now

Running Image and Version

Stops following the floating testnet-latest tag, so a bad release can't reach you within 5 minutes.

Pin a Version

Watchtower keeps the previous image on disk. Run the first line, pick the one that worked (by tag, or by IMAGE ID if it shows <none>) and enter it above.

Roll Back to the Previous Image

Watchtower Logs

The image is public; a stale stored GHCR credential causes this.

Pull Fails with "denied"

The node key in .env is your peer identity. Keep a copy somewhere safe.

Back Up .env (node key)

The chain data's real size on disk, then the free space left - `docker system df` can be misleading.

Disk Usage

Removes the node from telemetry.orbinum.network. The team uses it to see whether validators are healthy, so leave it on while you are in the set.

Opt Out of Telemetry

Deletes the chain data AND the keystore (session keys) in the volume. Run session.purgeKeys() first (Keys tab) if the account is still registered.

Remove the Node

Restarts the process with its existing arguments - .env edits are not picked up.

The public endpoint returns errors until it starts again.

An archive node replays from genesis, so the first sync takes a long time.

EVM Block Number

JSON back means Cloudflare, Caddy and the node all work. `-4` avoids a false failure on servers whose IPv6 doesn't route.

Test the Public Endpoint

Indexers and SDKs send batches - both results must come back.

EVM Batch Request

Two blocks: use the one for the web server you picked in the install guide.

Caddy Logs

The guide's Caddy mounts the file, and `git pull` replaces it - only recreating the container picks up the new one. Your own Caddy: validate as the caddy user and reload, never restart.

Apply a Caddyfile Change

Guide's Caddy only: the last requests it answered with 429, and from which client IP.

Rate-limited Clients

Guide's Caddy behind Cloudflare. The monthly cron does this too; run it by hand if Cloudflare returns 521/522.

Refresh Cloudflare IP Ranges

Keep the node key stable - it is this node's peer ID. Keep a copy of the Cloudflare origin key too; it is shown only once.

An archive node only grows - watch the free space.

Deletes the archive data - a new sync starts from genesis. Remove the site from your Caddyfile and the DNS record too.

Produces blocks in the permissioned testnet validator set. The RPC stays private; only P2P is public.

A crypto-friendly provider that allows PoS validation in writing - Hetzner and Contabo are not accepted

Ideally a region the validator set doesn't cover yet - the application asks for provider and region

An Orbinum account with a little test ORB from the faucet, to register your keys

Orbinum ships the node as a ready-made image, so there is nothing to compile - Docker Engine and the Compose plugin are all the server needs. This adds Docker's official apt repository (Ubuntu's own docker.io package lags behind) and lets your user run docker without sudo, which every later step assumes.

Install Docker

Other validators and nodes connect to you on the P2P port - it is the only port a validator needs open. SSH is allowed first so turning the firewall on can't lock you out.

Open the P2P port

The official deploy repo holds a Docker Compose stack per role and the testnet chain spec (genesis and boot nodes). You work from its `testnet/validator` folder from here on.

Download node-deploy

All settings live in `.env`. Fill in the fields and the command writes them for you, generates the node key (your node's P2P identity - only on the first run, so it is safe to run again) and prints the result to check.

Configure your node

Pulls the image and starts two containers: the validator, and Watchtower, which checks for a new testnet image every 5 minutes and restarts the node on it - node updates are automatic.

Warp sync is complete, continuing with state sync.
⚙️  State sync, Downloading state, 69%, 388.11 Mib (8 peers), best: #0 …
     <- the % can sit still while the Mib keeps rising - that is progress
⚙️  State sync, Importing state, 69%, 560.62 Mib (8 peers), best: #0 …
     <- then nothing moves for a few minutes: the state is being written to disk
State sync is complete, continuing with block sync.
🏆 Imported #997485 (0x8e26…355d → 0xbcd2…59d0)   <- at the chain head
⏩ Block history, #58176 (8 peers), best: #997486 …
     <- old block headers backfill in the background; the node already works

⚙️  Syncing … target=#… (8 peers)      <- replaying blocks from genesis, takes a while
💤 Idle (8 peers), best: #…, finalized #…   <- at the chain head

Start the node

Session keys can only be generated on a synced node. The first command shows whether it is still syncing, the second how far it still has to go. Your node should also appear on telemetry under `{{name}}` within a minute.

Wait for the sync

A validator is registered from a normal Orbinum account. Create one in Talisman, SubWallet or the Polkadot.js extension - the address starts with 5 - and enter it below: its public key is read straight from the address. Claim test ORB from the faucet now too; you need it in step 9, where registering the keys is a signed transaction that pays a fee.

Create and fund your account

Asks the node to create its Aura (block production) and GRANDPA (finality) keys inside its own keystore, and to sign a proof that they belong to your account - the public key from the previous step is already filled into the command. The private keys never leave the server; only the public half goes on-chain. Run it once, then paste `keys` and `proof` from the output below.

Generate session keys

Submit `session.setKeys` from the same account whose public key you used. First run the check below on the server - it confirms the node holds the keys you pasted, so a wrong paste is caught before you pay for a transaction. Then in Polkadot.js Apps open Developer → Extrinsics, select that account, choose `session` → `setKeys(keys, proof)`, copy the values below in and sign.

Register the keys on-chain

Two things must be true before you apply, both checked from our server with the buttons below: the chain has your keys registered for your account (the same keys the node holds, checked in the previous step - if the chain points to keys the node doesn't hold, you miss your blocks), and other nodes can reach the node's P2P port.

Verify

The testnet validator set is permissioned - up to 32 validators, no bonding. It is a human review, not a scored form: no SLA and no guaranteed slot, and a short honest email reads better than a long one. The team confirms your node is synced on telemetry before approving. Once added, the node starts producing blocks after two session rotations (about 2 hours).

Apply to the validator set

A public HTTPS/WSS endpoint for wallets, dApps and explorers - an archive node behind Caddy, and Cloudflare in the official setup. No consensus, no keys.

A domain you control - on Cloudflare for the recommended setup

The official deploy repo holds a Docker Compose stack per role and the testnet chain spec (genesis and boot nodes). You work from its `testnet/rpc` folder from here on.

Writes your settings into .env and generates the node key on the first run. Two values stay as shipped on purpose: `COMPOSE_PROJECT_NAME=testnet` pins the data volume's name, and `RPC_PORT` is internal - public traffic arrives on 443 and Caddy forwards it.

In Cloudflare, add an A record for the domain and switch it to Proxied (orange cloud), so visitors only ever see Cloudflare's IPs. Then set SSL/TLS → Overview to Full (strict).

Point your domain at Cloudflare

Add an A record pointing straight at the server. If the domain is on Cloudflare, set it to DNS only (grey cloud) - otherwise Let's Encrypt's check lands on Cloudflare and the certificate is never issued.

Point your domain at the server

Caddy proves itself to Cloudflare with a Cloudflare Origin Certificate - free, valid 15 years, no renewal, trusted only by Cloudflare, which is all this hop needs. You get it from the Cloudflare dashboard, not from the server: open your domain → SSL/TLS → Origin Server → Create Certificate, keep the defaults (RSA, your domain and `*.domain`, 15 years) and click Create. The next page shows two text blocks - Origin Certificate and Private Key - with the format set to PEM. Keep that page open and paste each block into its file below. The private key is shown only once.

==> origin.pem <==
-----BEGIN CERTIFICATE-----

==> origin.key <==
-----BEGIN PRIVATE KEY-----

==> /etc/caddy/certs/{{domain}}.pem <==
-----BEGIN CERTIFICATE-----

==> /etc/caddy/certs/{{domain}}.key <==
-----BEGIN PRIVATE KEY-----

Install the Origin Certificate

The shipped Caddyfile pins the Cloudflare certificate. Deleting that one line turns Caddy's automatic Let's Encrypt back on. The compose file still mounts `origin.pem` and `origin.key`, so create them empty - otherwise Docker creates directories in their place.

Switch Caddy to Let's Encrypt

Appends one site to the Caddyfile your server already uses and reloads it - your other sites keep running. `flush_interval -1` keeps WebSocket (wss://) connections from stalling. The node sends its own CORS headers, so browsers and wallets work without extra config.

Add the RPC to your Caddy

This stack uses host networking, so unlike the validator's port mapping, ufw really does guard every port here. Open SSH and P2P, open 80/443, and keep the node's own RPC and metrics closed - every request has to go through Caddy. On a server that already runs other services, check `sudo ufw status` first: enabling ufw blocks every port you haven't allowed.

Configure the firewall

The node syncs as an archive node from genesis - warp sync isn't allowed for archive, the container would crash-loop - so this takes much longer than a validator's first sync. With the guide's Caddy, its custom image (a rate-limit plugin, 100 requests per 10 s per client) is built once before the first start.

Start the RPC node

The public endpoint answers only once the node has caught up. Ask the node directly, inside its container, so neither Cloudflare nor Caddy is involved.

Wait for the archive sync

From any machine. The endpoint serves `https://{{domain}}` (HTTP and EVM JSON-RPC) and `wss://{{domain}}` (WebSocket - Polkadot.js, Talisman). Batch requests must work too; indexers and SDKs rely on them.

Test your endpoint

Orbinum is a privacy-focused blockchain built on Substrate with EVM compatibility. Balances and transfers inside its shielded pool are hidden behind zero-knowledge (Groth16) proofs. The testnet validator set is permissioned: no bonding or delegation, validators register session keys and are added by the team.

orbinum

Celestia is the first modular data availability network, allowing anyone to easily launch their own blockchain (a rollup) with minimal overhead. Mocha is Celestia's public testnet, used for testing rollups and node infrastructure before mainnet deployment.

celestia

Worrell is a proof-of-stake blockchain built with Ignite CLI and the Cosmos SDK, focused on payments and energy infrastructure.

Orbinum

About this chain

Chain Information

Activity

GitHub Activity

For operators

Resources

Contact Us