[$ xmrhost] _

$ man node-lokinet-exit

[$ ] node/lokinet exit — Lokinet exit-node hosting, Iceland and Romania

// NAME

node/lokinet exit — Lokinet exit-node hosting, no-KYC crypto billing (XMR / BTC / Lightning / LTC / ETH / USDT via OxaPay), deployed in Iceland and Romania.

// SYNOPSIS

xmrhost-cli provision --type=<slug> --region=<is|ro>

$ xmrhost-cli list --type=lokinet-exit

// 1 plan returned. all xmr-billed.

slug name spec $/mo notes
lokinet-1 Lokinet Exit 1 2c 4GBDDR4 $27 Oxen-network exit node with the staking-required wallet integration.

// 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

// WHEN TO PICK LOKINET-EXIT

$ man -k workload-fit

lokinet-exit is the right pick when the workload is an Oxen-network exit-role service node — hosting the Lokinet exit-routing capacity that the network's clients depend on. The role requires the customer to hold the Oxen staking requirement (currently 15,000 OXEN); the operator hosts the box, the customer holds the stake. The lokinet-1 tier is sized for what an Oxen service node actually needs (1 vCPU, 2 GB RAM, 50 GB SSD, 1 Gbps egress).

lokinet-exit is not the right pick when the customer wants Lokinet routing without staking (the protocol does not allow non-staked exit nodes), when the workload is a non-exit Lokinet relay (the same lokinet-1 tier configures for non-exit on request — the staking requirement is the same, the upstream-network noise floor is much smaller for non-exit), or when the customer is uncomfortable with proof-of-stake economic exposure (slashing risk is non-zero, even if historically bounded).

Iceland or Romania, customer's pick. 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'.

// TIER COMPARISON

$ diff /etc/xmrhost/tiers.d/*

Single tier at MVP (lokinet-1) — Lokinet exit-node hosting is a niche workload at this stage; the operator ships one tier until demand justifies splitting into per-role sizes. The tier is sized for the documented Oxen service-node spec (1 vCPU / 2 GB / 50 GB / 1 Gbps egress); over-provisioning would be marketing.

Customers wanting to run multiple service nodes (a small Oxen-stake-pool operator) request additional boxes via /contact rather than scaling a single tier — the staking-and-deregistration mechanics on Oxen are per-node, not per-host.

// FAQ

$ faq -t lokinet-exit

Q.Do I need to stake OXEN to run a Lokinet exit?

A.Yes — the Oxen service-node staking requirement (currently 15,000 OXEN) is a network-layer prerequisite. 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. The honest framing is at /notes/lokinet-exits-and-oxen-staking.

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 xmrhost operator can advise via /contact at provisioning.

Q.Where is the Lokinet exit hosted?

A.Iceland (Reykjavik, RIPE) or Romania (Bucharest, RIPE) — customer's pick at order time. Both jurisdictions accept exit-node operation under the AUP (/legal/aup); both have the upstream-provider relationships set up so that traffic is not throttled. The operator does not process third-party abuse reports.

Q.Do I pay the hosting fee in OXEN or in another crypto?

A.Hosting fee is paid in any of the OxaPay-supported rails (XMR recommended; BTC / Lightning / LTC / ETH / USDT accepted) — separate from the OXEN stake. The customer acquires OXEN separately for the stake (the Oxen DEX or peer-to-peer venues; SideShift / Trocador for atomic swaps from XMR / BTC).

// SEE ALSO

$ ls /usr/share/doc/xmrhost/related

// no-kyc crypto billing (xmr recommended; btc / ltn / ltc / eth / usdt accepted) — why-monero covers the rationale, payments the flow.