Run a validator

In plain words

Maya2C keeps its shared notebook with a group of validators. Each one is a computer that keeps a copy, signs pages, and helps seal them. The more honest validators run by different people, the harder it is for anyone to cheat.

To become one you need three things: a key (a secret you keep on your computer, like the key to a safe), a computer that stays on, and a seat that the group accepts. A seat that never answers counts against the group. So new seats are checked before they are added.

No money, no tokens

Testnet coins have no value. Running a testnet validator earns public recognition only. Nothing on this site promises tokens, money or a mainnet allocation, and anyone who says otherwise is not speaking for this project.

For engineers

Where things stand

	Status
Validator software	Shipped: maya2c-node on the releases page
Registering a key	Shipped: l1-wallet register-validator
Rejoining after an outage	Shipped: attested checkpoints, --catch-up-from (ADR-038)
Committee today	Four validators, all run by the project, on one machine. Real multi-signer DAG-BFT, but not independent: one machine failing halts the chain until it returns (it does not fork it). Mainnet launches the same way, and other machines join after launch (ADR-047). Live membership is on the status page.
Connecting to the network	A public WebSocket bootnode at p2p.maya2c.dev, and a bootstrap endpoint for snapshots and headers at bootstrap.maya2c.dev
Open registration	Not yet. Registrations are reviewed; see below.

Why registration is reviewed for now

Today every validator seat carries one vote, whatever its stake. A registration whose node never comes online still takes a seat, and with enough absent seats no quorum can form and the chain stops (ADR-039). The arithmetic is in the scientists tab below.

Until votes are weighted by stake, the testnet validator only proposes registrations above a bond floor that the faucet cannot fund. The project funds the bond of each approved operator. This is a stopgap for a testnet. It is not how mainnet will work.

Requirements

• An always-on machine. Measured on 2026-10-04 after 3 h 47 min and 12,277 blocks on the testnet validator: 39 MB of memory, 59 s of CPU time, and 150 MB of data, about 1 GB a day at that rate with empty blocks. Busier blocks need more. Plan disk for growth or run with pruning.
• A stable connection, and an inbound TCP port you can open.
• Willingness to update within 48 hours of a release marked required.

Steps

1. Install maya2c-node and l1-wallet from the releases page, and check them against SHA256SUMS.

2. Make a validator key. This prints its public key:

   maya2c-node --generate-validator-key validator.key

   The file is the secret. Keep it on the validator machine only, readable by you alone, and back it up offline. Losing it costs your seat. Leaking it lets someone sign as you, which is slashed as double signing.

3. Make a wallet with l1-wallet generate (it writes wallet.key by default), then note the address with l1-wallet address.

4. Apply by opening a validator application with the public key and the address. Never paste a key file.

5. Once approved and funded, register:

   l1-wallet --rpc-url https://rpc.maya2c.dev/rpc register-validator \
     --validator-key validator.key --bond <the amount agreed>

   The flags are those in bins/l1-wallet/src/main.rs: --validator-key, --bond (required), --commission-bps (default 0). The command prints your validator id. The committee is recomputed at each epoch boundary, every 3,600 blocks, and you join it at the first boundary after the registration is final.

6. Get the testnet genesis from maya2c.dev/testnet/genesis.json and check that it hashes to dd9bb356c94b7699e6e8d2595681faee48be435b02dc927677cbf833e55edd5d (SHA-256):

   sha256sum genesis.json

7. Run the node. It dials the bootnode over WebSocket, so it works from behind NAT. Flags from print_usage in bins/maya2c-node/src/main.rs:

   maya2c-node --genesis genesis.json --data-dir data \
     --validator-key validator.key \
     --bootnode /dns4/p2p.maya2c.dev/tcp/443/wss/p2p/12D3KooWJqH5AUQ1zPkMke18rcc8VHN2TWQ5XudGX3tP8zPLuyjB \
     --prune-depth 3600

   • --prune-depth 3600 prunes block bodies older than 3,600 blocks; it implies --prune.
   • To start from a peer’s state snapshot rather than replaying every block, add --bootstrap-from <peer JSON-RPC URL>.
   • Without --validator-key the node only observes. Never run one key on two machines.

   A fresh node run this way on 2026-10-04 loaded the snapshot at height 52,414, caught up 458 attested blocks and was following the tip (57,139 against 57,140).

Useful flags

Flag	Effect
--version	Prints the binary name and version, and exits. Only as the first argument.
--config <PATH>	Operational settings file; flags override it
--print-config-template	Prints the default template
--min-register-bond <N>	Never propose a registration bonding less than N (ADR-039)
--catch-up-from <URL>	Rejoin through a peer’s attested checkpoint (ADR-038); repeatable
--snapshot-interval <N>	Snapshot every N blocks; validators default to 3,600, 0 turns it off
--remote-signer <ADDR>	Sign through maya2c-signer instead of a key file (ADR-033)

What being a validator means

• Downtime is slashed. A validator that commits fewer than half of the anchor slots it led in an epoch loses 1% of its bond and is jailed for two epochs.
• Double signing is slashed hard. 50% of the bond, and the key is retired. Evidence can be filed for unbonding_epochs + 1 epochs after the offence.
• Undelegating takes the whole stake or leaves at least the minimum. A zero or dust undelegation is refused.
• Your node votes on every round. Its signatures are ML-DSA-65, the NIST post-quantum standard, like every other signature on the chain.

For scientists

The halting condition

Let $m$ be the number of online seats and $k$ the number of absent seats, so the committee has $N = m + k$ seats. From ADR-039, $f = \lfloor (N-1)/3 \rfloor$ and the quorum is $N - f$. The online seats can form a quorum alone exactly when $m \ge N - f$, that is, when

$$k \le \left\lfloor \frac{N-1}{3} \right\rfloor = \left\lfloor \frac{m + k - 1}{3} \right\rfloor .$$

The chain halts when $k$ exceeds that bound. Two examples from ADR-039:

Setup	$m$	$k$	$N$	$f$	Halts?
One validator plus one absent registration	1	1	2	0	yes ($k > 0$)
Four validators plus two absent registrations	4	2	6	1	yes ($k > 1$)
Four validators plus one absent registration	4	1	5	1	no ($k \le 1$), but anchor slots are missed

Below the halting threshold, up to $f$ absent seats still slow the chain: their anchor slots are missed. That is the case the downtime penalty is built for.

The penalties

Let $B$ be a bond. The parameters are in crates/staking/src/params.rs, in basis points where $10\,000$ bps is 100%:

Offence	Test	Penalty	Parameter
Downtime	led $< 5\,000$ bps of its anchor slots in the epoch	$B \cdot 100 / 10\,000 = 0.01\,B$	downtime_slash_bps = 100, downtime_threshold_bps = 5000
Downtime		jailed for $2$ epochs	jail_epochs = 2
Double signing	two signed vertices for one slot	$B \cdot 5\,000 / 10\,000 = 0.5\,B$, key retired	double_sign_slash_bps = 5000

Double signing is the attack on the quorum argument in consensus, and its penalty is ten times the downtime one.

Why the seat is limited

Under equal weights a seat is one vote regardless of bond. An attacker who registers $k$ idle keys therefore buys $k$ votes for the cost of $k$ bonds. Stake-weighted quorums (ADR-040) change the unit of the threshold from seats to weight $W$, with $f = \lfloor (W-1)/3 \rfloor$. The attacker then needs roughly a third of the stake, not a third of the seats. The reviewed registration on the testnet is a stopgap until that lands.

Status

• Software: built and tested. Not audited.
• Stake weighting: accepted (ADR-040), active only from a new genesis.
• Recovery from a halted chain without an operator restart: an open mainnet gate (ADR-039, options 1 to 3).