$ pwd
/node/lokinet-exit/lokinet-1
[$ ] Lokinet Exit 1 — Lokinet exit-node hosting (Iceland, Romania, Monero)
// NAME
lokinet-1 — Oxen-network exit node with the staking-required wallet integration.
// SYNOPSIS
xmrhost-cli provision --plan=lokinet-1 --region=<is|ro> // SPEC
$ xmrhost-cli spec --plan=lokinet-1
// NOTES
- Staking-required Oxen wallet provisioned at order (operator-managed key, customer-controlled view-key)
- Exit policy follows the Oxen reference exit ACL
- Service-node uptime SLA: 99.5% rolling 30-day
// REGIONS
$ xmrhost-cli regions --plan=lokinet-1
// ORDER
Order Lokinet Exit 1
// no-kyc crypto billing (xmr recommended; btc / ltn / ltc / eth / usdt accepted) — why-monero covers the rationale, payments the flow.
// DESCRIPTION
Lokinet exit-node hosting
Lokinet is the exit-flavoured workload in this brand's catalog. Each exit node is bonded to an Oxen service-node stake, the operator manages the stake key, and the customer keeps the view-key — a separation of duties that makes the staking compliance-survivable for the operator and the routing audit-able for the customer.
// pre-configured defaults
- Lokinet built from upstream Oxen release, run as unprivileged lokinet user
- Oxen service-node helper image preinstalled (oxend + lokinet + oxen-storage-server)
- Reference exit ACL preinstalled (matches the Oxen project's published policy)
- Staking-required Oxen wallet provisioned at order — operator-managed stake, customer view-key
- Service-node uptime SLA: 99.5% rolling 30-day (refunded in XMR if missed)
- Bandwidth: 1 Gbps clearnet egress, no per-tunnel cap
Why Lokinet specifically (and not a Tor exit): Tor exits attract a different volume and posture of complaint; the operator's blanket answer would have to be 'no Tor exits at all' to be honest. Lokinet's exit ACL is documented, the Oxen team publishes its expected mix, and the staking model means the abuse-feedback loop is short. That's the workload this brand can responsibly host.
// see also
// PROVISIONING
after you click order
$ xmrhost-cli provision --plan=lokinet-1 --region=is
[ok] reserving capacity in region=is
[ok] node allocated: lokinet-1-is-93
[ok] applying hardened-by-default profile (sshd, fail2ban, unattended-upgrades)
[ok] bonding stake to oxen service-node, exit ACL applied
[ok] handoff key sealed → view via the console at /console
provisioned in 47s. ssh access via onion-auth or wireguard, your choice. // you receive the onion-auth key + initial sshd config in the same handoff. no email-shipped credentials. nothing is logged to the operator side.
// HARDENING BASELINE — WHAT SHIPS BY DEFAULT
$ cat /etc/xmrhost/baseline.d/*
Every Lokinet Exit 1 ships with the xmrhost hardening baseline applied on the first boot — no opt-in flag, no add-on, no separate purchase. The baseline is the same across the catalog (vps / dedicated / gpu / tor / i2p / lokinet); category-specific extras are listed below the common section. Detailed per-control runbooks live in /docs; the cross-cutting overview is at /hardening.
- KERNEL. KSPP-baseline sysctls applied
(
kernel.kptr_restrict=2,kernel.yama.ptrace_scope=1,kernel.unprivileged_bpf_disabled=1,vm.unprivileged_userfaultfd=0,net.ipv4.tcp_syncookies=1, +12 more), unprivileged user-namespace creation gated, kexec disabled at runtime. Full list and rationale: /docs/kernel-hardening-checklist. - SSHD.
PasswordAuthentication no,ChallengeResponseAuthentication no,KbdInteractiveAuthentication no,PermitRootLogin prohibit-password,MaxAuthTries 3, Ed25519-only host keys (RSA host keys removed), legacy KEX / cipher / MAC families disabled. fail2ban preconfigured with the sshd-default ruleset. Runbook: /docs/harden-sshd; key migration: /docs/ssh-key-migration. - AUDIT. auditd enabled with the
laurel-compatible default ruleset (auth, identity, network-config,
time-change, mount, perm-mod). unattended-upgrades on for
main/securityonly — feature releases stay operator-controlled. systemd-journald persistent storage withSystemMaxUse=512M. - NETWORK. Egress-default-permit (the box reaches the internet), ingress-default-deny (only sshd + the customer's declared services). Outbound port 25 (SMTP) closed by default; customers operating a real MTA request the lift via /contact with the reverse-DNS pointing to a domain they control. Dual-stack IPv4 + IPv6 (/64 routed). RIPE- allocated PI on Iceland and Romania.
- MONITORING. node_exporter (Prometheus textfile
exporter) listening on
127.0.0.1:9100— the operator's monitoring scrapes via wireguard from the management VLAN, never from the public internet. Customers wanting their own metrics tap add a second exporter on a private interface. - LOKINET PRECONFIG. Oxen service-node binary preinstalled, lokinet.ini sized for an exit role, customer supplies the staked OXEN address at provisioning. Operator does not run a third-party abuse-report intake — see /contact 'WHAT WE DO NOT PROCESS'.
// the baseline is editorial-stable — when the operator changes a default, the change is logged in /notes with the rationale and the migration notes for boxes already in service. /hardening is the canonical pillar; /docs is the procedural manual.
// RECOMMENDED PLAYBOOKS
$ grep -l 'lokinet-1' /usr/share/doc/xmrhost/playbook/
- /playbook/vpn — self-hosted wireguard / openvpn endpoint — your trust boundary is the vps, not a third-party provider
- /playbook/tor-relay — operate a tor middle/exit relay or obfs4 bridge with bgp-stable uplinks and a sane abuse posture
- /playbook/scraping — stable-asn vps for ethical crawling: clean ip reputation, generous egress, no per-target rate limits
// FAQ
$ faq -p lokinet-1
Q.Do I need to stake OXEN to run a Lokinet exit node?
A.Yes — the Oxen service-node staking requirement (currently 15,000 OXEN) is a network-layer prerequisite for participating as a service node, which is the role that Lokinet exits use. The customer holds the stake; the operator hosts the box. The /notes/lokinet-exits-and-oxen-staking writeup covers the staking workflow, slashing risk, and the de-staking unlock window.
Q.Is the OXEN stake at risk of slashing?
A.Slashing on Oxen service nodes is non-zero but historically bounded (the network slashes for verified deregistration, not for routine downtime under the grace window). The customer assumes the staking risk; the operator assumes the box-uptime risk. Detailed: /notes/lokinet-exits-and-oxen-staking. The honest framing is "if you're not comfortable with proof-of-stake economic exposure, lokinet-exit is not the right pick".
Q.Why is there only one tier?
A.Lokinet exit-node hosting is a niche workload at MVP — the operator ships one tier (lokinet-1) until demand justifies splitting into tiers. The single tier is sized for what an Oxen service node actually needs (1 vCPU, 2 GB RAM, 50 GB SSD, 1 Gbps egress); over-provisioning would be marketing rather than a real spec choice.
Q.Where is the Lokinet exit hosted?
A.Iceland (Reykjavik, RIPE) or Romania (Bucharest, RIPE). Both jurisdictions accept exit-node operation under the AUP (/legal/aup) and the upstream provider's terms. Lokinet exits attract third-party abuse-report attempts the same way Tor exits do; the xmrhost operator does not process third-party abuse reports against tenant traffic — see /contact 'WHAT WE DO NOT PROCESS'.
Q.Can I run a non-exit Lokinet service node instead?
A.Yes — the lokinet-1 tier can be configured as a non-exit service node (the staking requirement is the same, the upstream-network noise floor is much smaller). Some Oxen operators prefer non-exit roles to keep the relay descriptor's ContactInfo out of third-party abuse-tracking lists. The configuration is a single lokinet.ini directive; the xmrhost operator can advise via /contact at provisioning.
Q.Do I need to pay in Monero for the hosting fee?
A.No — same payment rails (XMR recommended, BTC / Lightning / LTC / ETH / USDT accepted via OxaPay). Note that the OXEN stake itself is held in OXEN, not paid to the operator — the customer acquires OXEN separately (the Oxen DEX or peer-to-peer venues; SideShift / Trocador for atomic swaps from XMR / BTC).
// ORDER
$ xmrhost-cli order --plan=lokinet-1// no-kyc crypto billing (xmr recommended; btc / ltn / ltc / eth / usdt accepted) — why-monero covers the rationale, payments the flow.
// BEFORE YOU ORDER — RELEVANT GUIDES
$ ls /guide
- /guide/buy-vps-with-monero — step-by-step XMR checkout walkthrough.
- /guide/buy-vps-with-bitcoin — BTC / Lightning flow + chain-analytics caveat.
- /guide/how-to-host-a-website-anonymously — three-tier threat-model guide.
- /guide/best-offshore-vps-2026 — evaluation methodology + plan-to-use-case mapping.