$ pwd
[$ ] use-case: crypto-node
// NAME
crypto-node — crypto node & validator hosting.
// SYNOPSIS
xmrhost-cli playbook describe --workload=crypto-node
xmrhost-cli provision --workload=crypto-node --region=<is|ro>// TL;DR
$ head -n1 README
// run a btc/eth/xmr/lightning node or pos validator on hardware you control, in a crypto-neutral jurisdiction.
// DESCRIPTION
$ man playbook(crypto-node)
// deterministic uplink for validators + crypto-neutral fiscal posture
A staking validator's economics are uplink-determined. Beacon-chain attestations have a 12-second slot and a 32-slot epoch; missed inclusion above ~1% on small validator counts is the difference between profit and loss. Mainstream cloud providers price egress and offer no SLA on the network path between the consensus client and the BN — running on bare-metal or close-to-bare-metal VPS in BGP-stable jurisdictions removes the variance.
Storage profile matters as much as uplink. A pruned Bitcoin Core node fits comfortably on vps-2 (50 GB NVMe); archive Bitcoin lives on storage-class plans (~600 GB and growing). Monero archive runs ~180 GB and benefits from 2c/4GB minimum due to RingCT validation cost. Ethereum execution + consensus pairing (Geth/Reth + Lighthouse/Prysm) wants 2 TB NVMe and 16 GB RAM minimum — a ds-mid is the sweet spot for solo staking. Light clients are explicitly not what the audience wants.
Jurisdiction matters less for the validator itself (the chain is global) than for the operator's tax and custody posture. Iceland and Romania both treat validator yield as ordinary income with no staking-specific anti-tax workaround attempts. We accept Monero only — the reasoning is documented at /why-monero — and key custody is entirely customer-side; USB/IP forwarding for hardware wallets (Trezor, Ledger, Coldcard) is supported for cold-signing flows on request.
// see also
- Bitcoin Core — Full Node Requirements (bitcoin.org/en/full-node)
- Ethereum — Solo Staking Guide (ethereum.org/en/staking/solo)
- Lightning Network Whitepaper (Poon & Dryja, 2016)
- Monero Research Lab — Bulletproofs (Bünz et al., 2018)
// RECOMMENDED NODES
$ xmrhost-cli list --workload=crypto-node
// 8 plans flagged for this workload. all xmr-billed.
// RECOMMENDED REGIONS
$ xmrhost-cli regions list --workload=crypto-node
-
is — iceland : Geothermal-powered Tier III facilities, low ambient temp (free cooling), validator yield treated as ordinary income. Outside Five Eyes / Fourteen Eyes signal-intelligence sharing.
-
ro — romania : Tier-1 carrier diversity + RoNIX direct peering = sub-10ms RTT to most of EU. Validator workloads benefit from the lower attestation jitter; ANCOM enforces standard EU lawful-intercept only.
// THREAT MODEL + AUP BOUNDARY
$ xmrhost-cli scope --workload=crypto-node
// the hosting layer is one component of the threat model. what we cover, and what we explicitly don't:
// scope: in
- Deterministic uplink for attestation-time-sensitive validators
- Bare-metal-class GPU/CPU for archive nodes (storage-1) without virtualisation tax
- USB/IP forwarding documented for Trezor / Ledger / Coldcard cold-signing flows
- Crypto-neutral fiscal jurisdictions for the validator income posture
// scope: out
- Custody — the operator never touches private keys, full stop
- Slashing protection — that is the customer's client-config concern
- Tax filing in the customer's home jurisdiction (we host validators, not accountants)
- MEV extraction or bundle relay choice — those are application-layer decisions
// AUP boundary
Customers running validators or full nodes remain responsible for tax reporting in their own jurisdiction. Crypto custody, key management, and signing operations are entirely under customer control; we have no access to private keys.
// SEE ALSO
// playbook — full workload list, node — full catalog, location — region posture, why-monero — billing rationale.