Ethereumonarm BOOTSTRAP.md
OpenClaw startup configuration from Ethereumonarm.
This BOOTSTRAP.md is the first-run script for the Valkyrie Ethereum node agent — the file OpenClaw
works through once, before the persona in SOUL.md and the recurring checks in HEARTBEAT.md take
over. It is the longest file in that set, and deliberately so: it is where an agent that will later
operate semi-autonomously learns what machine it is actually on.
Its central idea is discover-then-specialise. Step one is a single block of read-only commands that inventories the board model and OS, which Ethereum clients are installed and which are running, where config and chain data live, whether the JWT secret exists, how much disk and memory are free, what the CPU temperature is, whether monitoring is up, and whether the agent's own user can read the journal and reach the local RPC endpoint. Every later step is written to consume that inventory rather than to assume a layout.
The steps it walks through
- Discover the environment — the read-only inventory described above, with results recorded for later steps.
- Review and update the skill file — reconcile the shipped skill documentation against what step one actually found: installed clients, config paths, service and log commands, API endpoints, monitoring commands, the package-update workflow, and the safety rules.
- Verify the heartbeat checklist — confirm the periodic checks and their alert thresholds match this machine.
- Create cron jobs — register six recurring jobs through the OpenClaw CLI, from a fifteen-minute health check down to a five-minute validator-attestation check and a weekly update check, then verify the registration.
- Sudoers rule — generate a least-privilege sudo policy covering only the clients found in step one, and print it for the human to install.
- Self-verify — re-run the key probes to confirm the agent can see the workspace, its cron jobs, and both node APIs.
- Report to user — a fixed status template summarising board, clients, sync state, peers, temperature, disk, cron count, and monitoring.
What is worth borrowing
The constraints block at the end is the most transferable part: during bootstrap the agent may not start or stop services, may not edit node config, may not install packages, and may not write files outside its own workspace. A first run is exactly when an agent knows least and can break most, so this file confines it to reading, writing its own notes, and registering timers.
The sudoers handling is the other lesson. The agent composes the policy — scoped to the clients that exist, with the validator restricted to status-only — but is explicitly forbidden from installing it, printing the command for a human to run instead. Generating a privilege grant and applying one are different acts, and the file keeps the second on the human's side of the line.