Skip to content
Open app

Install and run a solver

AI-generated

Read IMPORTANT before operating a solver. Starting run can spend ETH, XMR, and PROVE.

Use one host and one active process with dedicated Ethereum and SP1 identities, Monero wallet account 0, and durable state. Other programs must not spend from those identities.

Provide:

  • An Ethereum EOA with no deployed code, enough ETH for bonds/gas, and private services meeting the RPC requirements.
  • A trusted synchronized Monero mainnet daemon, two distinct fallback propagation hosts, and authenticated loopback wallet RPC. Configure the wallet’s own daemon consistently.
  • Mature spendable XMR outputs, a funded Succinct mainnet requester, and a reviewed nonempty prover whitelist.
  • Private storage supporting atomic replacement and file/directory fsync.

Use Rust 1.97.1 and adjacent checkouts:

Terminal window
git clone git@github.com:chainjump/chainjump.git
git clone git@github.com:chainjump/chainjump-solver.git
cd chainjump
git checkout f6625ded8455d65d8df9c01ab6d5cb9934bb4e3f
cd ../chainjump-solver
git checkout f2aa8013d0a2ca3abda4799dee04d2dc5b80c71e
cargo build --release --locked -p chainjump-solver-sp1 --bins

The SP1 adapter builds both executables and embeds the reviewed program-key artifact.

Terminal window
umask 077
mkdir -p state
cp config/example.toml config/solver.toml

Replace all placeholders using the deployment reference. Review configuration budgets and paths. Secret files must be regular owner-only files, such as 0600; use a private state directory such as 0700. Relative paths use the process working directory.

Terminal window
./target/release/chainjump-solver --config config/solver.toml check-config
./target/release/chainjump-prover --config config/solver.toml account
./target/release/chainjump-solver --config config/solver.toml run

check-config is offline; account checks the requester through the network. Supervise the single runner and monitor it. Do not use SP1_CIRCUIT_MODE=dev or the deployment-test hold flag.

Stop the runner before manual commands or configuration changes. Preserve deployment, identities, guest, and state for active obligations; restart through recovery.

Drain obligations before changing deployment or guest. Update runtime attestation, deployment block, guest artifact, and requester settings together, and check that the new release can recover existing records. Never overwrite newer state with an old backup without reconciling external activity.