Skip to main content
HOW-TO

Set Up Your Elastos DAO Council Node

You won a seat on the Elastos DAO Council. Congratulations — now you need to run a node.

This page is the orchestration guide: it sequences the existing technical pages into the order a newly elected council member actually needs them, and adds the council-specific bits (binding the node to your DID, claiming it on-chain) that no single existing page covers end-to-end.

If you have not won (or run) yet, start at Run for the Council and Vote in a Council Election.

At a glance
  • Who: Newly seated council members
  • What you need: A dedicated Linux server (see prerequisites), your council DID, root/sudo access
  • How long: ~2–4 hours hands-on, plus full-chain sync time (can take a day)
  • What you'll end up with: A live full supernode running the ELA main chain, ESC, EID, both Oracle services and the Arbiter, claimed under your council DID, earning validator-side rewards

The shape of a Council node​

A "Council node" is not a single process — it's a full supernode stack of six co-located services:

Council members run this complete stack — not just BPoS — because the Arbiter coordinates cross-chain operations between the main chain and the sidechains, and that arbiter set is drawn from elected council seats.

Step 1: Provision the server​

Before installing anything, make sure your server meets the spec. See Node Prerequisites for the canonical hardware, OS, ports, and bandwidth requirements.

Key non-negotiables for a Council node:

  • Uptime is reputational. A council node that misses arbiter rounds or misses block proposals after claim is visible on-chain and counts against you in the next election.
  • Open the ports listed in Ports Reference — incoming P2P traffic must reach all six services.
  • Dedicated host preferred. Don't co-locate with anything else that could starve disk I/O or burst the CPU.

Step 2: Deploy the full supernode stack​

This is the bulk of the work. Follow Full Supernode Deployment end-to-end. It walks through:

  1. Installing node.sh
  2. Initializing every component (ela / esc / esc-oracle / eid / eid-oracle / arbiter)
  3. Starting services in the correct dependency order
  4. Setting up auto-restart on reboot
  5. Verifying every chain is syncing

When the verification step shows all chains reporting healthy heights, your supernode is alive.

Wait for full sync before continuing

Do not proceed to Step 4 until every chain has caught up to current network height. Claiming a node that isn't synced will get it jailed almost immediately.

Step 3: Secure & configure​

A council node is a piece of public infrastructure. Treat it that way.

Step 4: Bind your node to your council DID and claim it​

This is the on-chain step that flips your running supernode into a council validator. It uses the CRCouncilMemberClaimNode transaction (type 0x31).

You submit one transaction that says: "This BPoS node public key belongs to me — council member with this DID." Once accepted, your node joins the active validator set alongside the community-elected BPoS validators.

For the exact transaction payload (NodePublicKey, CRCouncilMemberDID, CRCouncilMemberSignature), see Council Member Guide → Claiming a Validator Node.

Most council members submit the claim transaction through the Essentials wallet, which builds the payload from the council DID and the node's public key shown by node.sh.

After the transaction confirms, your node joins the active validator set within the next election round and begins producing blocks on its turn.

Step 5: Monitor and maintain​

A council node is a production validator. Run it like one.

  • Live metrics: Node Monitoring — set up alerts on missed blocks, sync lag, and disk usage
  • Upgrades: Upgrading Your Node — track release announcements; coordinate upgrades to avoid mass downtime
  • Issues: Troubleshooting — common failure modes and recovery
  • Backups: Backup & Recovery — practice the restore path on a spare server before you need it for real

Step 6: Understand the penalties​

If a council node misbehaves — extended downtime, double-signing, missing arbiter rounds — there are on-chain consequences. Read Jailing & Slashing before going live so the response when something goes wrong is muscle memory, not panic.

Frequently Asked Questions​

Is a Council node the same as a BPoS supernode? The Council node includes a BPoS validator role, but it also runs the ESC, EID, both Oracle services, and the Arbiter. A community BPoS supernode runs only the ELA main chain and the BPoS validator role.

Do I need to claim a validator node? Can I just do governance? Claiming is optional. You can serve as a council member without claiming — you'll still review proposals and vote. But claiming earns validator-side rewards on top of governance participation, which is why most members do it.

What happens if my node goes down? Short outages are tolerated; the network has a backup candidate set that fills in. Extended outages get the node jailed (temporarily removed from the active set) and dock voter rewards. See Jailing & Slashing for the specifics.

Can I switch the underlying server later? Yes — provision the new server, sync it, then submit an UpdateInfo-equivalent flow to repoint the council seat at the new node. Brief overlap is fine. Coordinate the cutover during a low-activity window.

Where do I claim my BPoS rewards? Same place as any BPoS supernode: use the claim_bpos command shown in BPoS Supernode Operations → Claiming Rewards.