What the network still needs

Running a validator keeps blocks coming. But Futureverse also ran a set of quieter jobs on their own servers, and since the handover nobody has done most of them. None stops the chain today. Each one, left alone, slowly breaks something.

If you run a validator (or just a machine that stays on), pick one up.

Already covered, but by one machine

These run today on a single community validator, root-1, from one home internet connection. That makes them a single point of failure: if that machine goes offline, or its home IP address changes, each of them stops until someone fixes it by hand. A second operator, somewhere else, removes that risk.

Job	What it does	How to help
Bootnode	The first node a new node calls to find the network. The chain spec's original bootnodes (bootnode-N.root.rootnet.app) no longer exist.	Forward TCP 30333 to your node, give it a stable DNS name, and send us its address (/dns4/<name>/tcp/30333/p2p/<peer id>; the peer id is system_localPeerId on your node's local RPC).
Public RPC	The address wallets and sites use to read the chain and send transactions. The original, root.rootnet.live, is down.	Run a node with a filter in front (only read and submit methods, rate limits), never the node's raw RPC. Ask us for the filter we use.
History recording	The chain forgets per-era staking data after 84 eras (staking.HistoryDepth), but Vortex reward cycles are 90 days. Someone must record each era, with proofs, or a full cycle can't be calculated.	Record each era with state_getReadProof so anyone can check it later against the block header.
Snapshots	New validators start from a recent copy of the chain instead of syncing from scratch (which fails at block 8,260,345).	Publish a fresh snapshot every few months, with its sha256.

On a home connection, plan for your IP changing. Use a DNS name rather than a raw IP for anything you publish. Update the DNS record when the IP changes (a dynamic-DNS client does this for you). Remember any firewall rule elsewhere that allows your IP in.

Bridges: needed before they can reopen

The Ethereum and XRPL bridges are paused. Before they can reopen safely:

1. Tell Ethereum about validator changes. Every era the chain makes a proof of the new validator set (ethBridge.notarySetId). Someone has to submit each one to the Ethereum bridge contract, paying ETH. If it falls behind, Ethereum refuses withdrawals until every missed set is sent, in order.
2. Keep the XRPL door's signer list current. When validators change, the XRPL door account's signer list must be updated too. The door also needs enough XRP to pay for it.
3. Run relayers. These programs carry transactions between the chains. Futureverse ran all of them.
4. Don't all lean on one free endpoint. Every validator watches Ethereum and XRPL (--eth-http, --xrp-http). The examples use free public endpoints. If those limit traffic, the bridges quietly stop working, so spread out: use your own node, or a different provider from other validators.

Admin and money

• Vortex payouts. Rewards are paid in Vortex tokens after each cycle. The steps are on-chain (vortexDistribution), but someone has to gather prices and points and submit them, with the admin key or sudo. See history recording above.
• The sudo key is held by one person. If it's lost, the chain can never be upgraded or fixed again. It should become a multisig.
• Domains. Old Futureverse domains still matter: some NFT collections load their images from them, and a lapsed domain can be bought by anyone. They must be renewed by whoever controls them.
• Wallet listings. Chainlist and wallets still list the dead root.rootnet.live RPC for chain 7668.

If you take one of these on, tell us, so it's listed here with more than one name against it.