Lokinet Exit 1 — Lokinet exit-node hosting (Iceland, Romania, Monero)
lokinet-1 — Oxen-network exit node with the staking-required wallet integration.
xmrcloud-cli provision --plan=lokinet-1 --region=<is|ro>Order Lokinet Exit 1
no-kyc crypto billing (xmr recommended; btc / ltn / ltc / eth / usdt accepted) — why-monero covers the rationale, payments the flow.
xmrcloud-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
xmrcloud-cli describe --plan=lokinet-1
lokinet-1 is the exit-flavoured tier: 2 vCPU, 4 GB RAM, 60 GB NVMe, 1 Gbps clearnet egress, bonded to an Oxen service-node stake. The operator manages the stake key; you keep the view-key — duties split so staking stays compliance-survivable and routing stays auditable. The reference Oxen exit ACL is preinstalled, and it can equally run as a non-exit service node. Sized for exactly what an Oxen SN needs, no over-provisioning. For non-staked onion hosting see tor-1; for a floodfill see i2p-1.
xmrcloud-cli regions --plan=lokinet-1
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
after you click order
xmrcloud-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.
cat /etc/xmrcloud/baseline.d/*
Every Lokinet Exit 1 ships with the xmrcloud 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.
grep -l 'lokinet-1' /usr/share/doc/xmrcloud/playbook/
- /playbook/vpnself-hosted wireguard / openvpn endpoint — your trust boundary is the vps, not a third-party provider
- /playbook/tor-relayoperate a tor middle/exit relay or obfs4 bridge with bgp-stable uplinks and a sane abuse posture
- /playbook/scrapingstable-asn vps for ethical crawling: clean ip reputation, generous egress, no per-target rate limits
faq -p lokinet-1
Do I have to stake OXEN to run lokinet-1?
Yes — a Lokinet exit is an Oxen service node, which requires the network's service-node stake (currently 15,000 OXEN). You hold the economic stake; the operator hosts the box and manages the stake key while you keep the view-key. The staking workflow, slashing risk, and de-stake unlock window are at /notes/lokinet-exits-and-oxen-staking.
Who controls the stake key on lokinet-1?
Duties are split: the operator manages the stake key so the service node stays registered and compliance-survivable, and you keep the view-key so routing and rewards stay auditable to you. You acquire the OXEN stake separately (Oxen DEX, or an atomic swap from XMR/BTC via SideShift / Trocador); the hosting fee itself is billed in Monero or the usual rails.
Can lokinet-1 run as a non-exit service node?
Yes — a single lokinet.ini directive switches it to a non-exit role, which keeps the descriptor's ContactInfo off third-party abuse-tracking lists while still earning service-node rewards. The staking requirement is identical. The operator can advise the exact config at provisioning via /contact.
Do I need to stake OXEN to run a Lokinet exit node?
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.
Is the OXEN stake at risk of slashing?
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".
Why is there only one tier?
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.
Where is the Lokinet exit hosted?
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 xmrcloud operator does not process third-party abuse reports against tenant traffic — see /contact 'WHAT WE DO NOT PROCESS'.
Can I run a non-exit Lokinet service node instead?
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 xmrcloud operator can advise via /contact at provisioning.
Do I need to pay in Monero for the hosting fee?
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).
no-kyc crypto billing (xmr recommended; btc / ltn / ltc / eth / usdt accepted) — why-monero covers the rationale, payments the flow.
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.