Running a Validator
Run a validator to secure the Metalayer message-passing network
Metalayer validators secure messages passed between chains within the Metalayer. A quorum of validators must verify that a message was actually sent prior to being delivered. Validating is a permissioned operation, and the Metalayer mantains a validator set to secure the entire network.
What is a Metalayer Validator?
Metalayer is a cross‑chain message‑passing protocol that wraps Hyperlane-authored but Metalayer-deployed contracts and runs its own off‑chain agent network. This means that validators may run the same executable as a Hyperlane network validator, with a different config. Validators sign the latest Mailbox
dispatched messages each origin chain and publish those signatures so Metalayer relayers can aggregate and forward messages.
How Metalayer Differs from Hyperlane
Topic | Hyperlane | Metalayer |
---|---|---|
Contract addresses | Public hyperlane‑registry repo | Config bundle supplied by Caldera – do not copy Hyperlane values |
Agents network | Global Hyperlane mesh | Isolated Metalayer mesh |
CLI, flags, binary | hyperlane-agent | Same binary (Abacus Works image) |
Staking / PoS | Hyperlane POS contracts | N/A – no on‑chain staking for Metalayer |
Operational commands and flags are otherwise identical.
Requirements
Requirement | Notes |
---|---|
Secure signing key | AWS KMS, Vault HSM, or raw hex. Same CLI flags as Hyperlane (--validator.* ). |
Available gas balance | The signer must hold enough native token to broadcast the on‑chain announce tx. The same signer MAY be reused across multiple chains. |
Public storage (checkpoint syncer) | S3 bucket (prod). |
Machine | 2 vCPU / 2 GB RAM / 4 GB disk is sufficient. |
RPC endpoints | Provide ≥ 2 per chain. Private RPCs ensure validator security. |
Max 1 chain per validator instance | Each validator instance only supports 1 chain at most. For redundancy, operators may choose to run multiple validator instances (e.g., across different availability zones) pointing to the same S3 bucket. |
Quick‑Start
If everything is wired correctly you’ll see signed‑root logs and JSON blobs appearing in your S3 bucket or local folder.
Step‑by‑Step Setup
Coordinate With Caldera (allow‑list)
Provide Caldera with:
- Intended origin chain(s)
- Signer address(es) – one per validator instance.
Create / Secure Signing Keys
Choose one of:
-
AWS KMS (recommended)
-
Raw hex key – fine for testnet
Prepare Checkpoint Storage
- S3 (prod) – bucket
metalayer-validator-sigs-<YOU>
- Local (test) – any directory; flag
-checkpointSyncer.type localStorage
Fetch the Binary
Use the Abacus Works image or build from source.
Docker
Source
Write Your Config
A minimal validator.json
(replace placeholders; defaults noted):
Start & Verify Announcement
Run the Docker command from Quick‑Start. The agent will automatically broadcast announce()
; fund the signer with a small amount of native token first.
Deployment Recipes
docker‑compose
Helm (values snippet – sample only)
Running Multiple Validators
- Reuse the same signing key or create one per instance – both valid.
- Each validator needs a unique
checkpointSyncer.folder
(S3 prefix) and-db
path. - Expose metrics on unique ports.
Monitoring & Troubleshooting
Symptom | Likely Cause | Fix |
---|---|---|
not enough gas | Signer wallet unfunded | Top‑up with native token |
No signatures in S3 | Bad bucket policy / wrong region | Check IAM & checkpointSyncer section |
High db: prune required | Disk too small | Give ≥ 5 GB or mount volume |
Prometheus metrics exposed on :9090/metrics
by default. We suggest implementing Hyperlane’s Grafana dashboard.