Hopr staking With wxHOPR Node Requirements

Readiness Before Any On-Chain Commitment

The standard entry route requires 30,000 wxHOPR for each node. A qualifying Network Registry NFT opens the reduced 10,000 wxHOPR route. Neither balance creates network access by itself. The operator also needs permissioned onboarding, a HOPR Safe, and a HOPRd node capable of remaining reachable.

Network readiness starts with the access model. New nodes enter through an onboarding and waitlist process, and approval is a separate state from connecting a wallet or holding tokens. This distinction matters because bridging and wrapping assets before confirming the operational requirements can create avoidable transactions.

The smallest bounded action is to connect the intended owner wallet to the HOPR Staking Hub on Gnosis Chain and inspect the onboarding path without moving the stake. The connected network, wallet address, and displayed Safe information should all match the planned setup. Stop if the interface shows an unexpected account or chain.

Readiness is complete when the operator has a valid threshold route, understands the permissioned queue, and can run the node on supported hardware. This checkpoint does not mean the node is approved or earning. It means the required pieces are known before the first irreversible transaction fee is spent.

What Counts as Hopr Staking Today?

Hopr staking uses the SafeStaking model, where stake belongs to a HOPR Safe associated with an operating HOPRd node. The arrangement supports network participation and separates most funds from the node's locally accessible credentials. Rewards require an active node; a wallet holding wxHOPR without node operation does not qualify as a passive staking position.

Stake Thresholds and the NFT Exception

The standard minimum is 30,000 wxHOPR per node, reduced to 10,000 wxHOPR for a node backed by a Network Registry NFT. The exception applies specifically to the Network Registry NFT. Earlier boost NFTs do not inherit that function, so an old collectible should not be treated as threshold evidence.

Each additional node needs enough allocated stake to satisfy its applicable minimum. A large balance attached to one node does not automatically qualify another. Reducing a node below its threshold also removes its reward eligibility, even if the HOPR Safe remains active and the node continues running.

HOPR, xHOPR, and wxHOPR Roles

The three token forms belong to different parts of the asset path. HOPR is the Ethereum-side token, while bridging it to Gnosis Chain produces xHOPR. The HOPR Staking Hub wrapper converts xHOPR into wxHOPR, the form used for node staking. Reversing the wrapper converts wxHOPR back into xHOPR.

Gnosis Chain selection must precede a wrapper transaction. When bridging, use a recipient address compatible with the destination chain. A Safe address created on one chain cannot be reused automatically on another. The wxHOPR threshold is also separate from xDAI used for Gnosis Chain transactions and node operations. Meeting one balance requirement does not satisfy the other.

HOPR Safe Ownership and Key Boundaries

A HOPR Safe holds the stake and provides the account structure used to associate one or more nodes. This separation keeps the main balance under owner-controlled approvals while allowing defined node actions. It also creates a clear boundary between custody decisions and routine relay operations.

Admin and Chain Key Roles

The admin key controls HOPR Safe approvals, while the locally accessible chain key lets the node perform its on-chain work. Keeping the admin and chain keys separate limits the authority available to the online node.

Admin Key Boundary

The admin key belongs to the owner side of the arrangement. It signs approvals governing access to the HOPR Safe and its funds. Storage and recovery therefore deserve stronger controls than credentials exposed to an always-online node. Multiple Safe owners and confirmation thresholds can further separate one lost wallet from complete loss of control.

Chain Key Boundary

The chain key supports transactions the node needs for payment channels and ticket redemption. Because the node can access this key locally, its authority should match the operational task. A compromised node should not automatically gain unrestricted control over the balance held in the HOPR Safe.

Configurable Safe Module Access

The Safe module defines how the node may interact with funds and which approvals apply. An operator can require owner authorization for sensitive actions or permit bounded node access for routine work. The appropriate choice depends on how much automation the node needs and how much exposure the owner accepts. Start with narrow authority, then change permissions only when an observed operational need justifies it.

Permissioned Access Before Activation

Permissioned access means a funded Safe and running process do not immediately make a node a network participant. Onboarding records the Safe address and active HOPRd node address for the waitlist. Access arrives through the allocation process, so the waiting state should remain distinct from approval and active participation.

The Staking Hub exposes onboarding indicators for the associated node. Those indicators are better evidence than a completed token transfer because they show whether the required stages have advanced. If approval is missing, adding more stake does not grant access automatically. For applicants without a Network Registry NFT, however, stake size helps determine waitlist priority. Preserve the existing setup and wait for the access process instead of rebuilding the node.

Open full-size image

Node Capacity and Reachability

A workable HOPRd host needs Linux or macOS, a dual-core CPU or two virtual CPUs, 2 GB of RAM, and at least 5 GB of disk space. These are minimum operating requirements, not performance promises. Docker, Docker Compose, a native package, a binary, or Dappnode can provide the runtime.

Reachability matters because Cover Traffic nodes and peers must connect to the HOPRd endpoint. A public static address is the simpler arrangement. A dynamic address requires dynamic DNS and correct configuration. Port 9091 carries TCP and UDP peer-to-peer traffic in the documented setup. A node with a public IP behind NAT needs both protocols forwarded, while a node without a public IP can use NAT mode for TCP connections to public nodes.

NAT mode can enable TCP connections, but it does not guarantee normal operation or rewards. Node availability, public reachability, synchronization, payment-channel state, and chain connectivity still matter. Continuous rewards also assume the node remains online, making power, network stability, monitoring, and updates part of the staking cost.

How Does Stake Affect Node Rewards?

Stake affects the probability a node receives Cover Traffic, while node performance determines whether it can relay that traffic and redeem the resulting tickets. More wxHOPR therefore does not compensate for an unreachable or unsynchronized node. At least one outgoing payment channel must also be open before the node satisfies the documented reward conditions.

The Dufour economic model applies reduced marginal reward weight above 75,000 wxHOPR per node. That threshold belongs to the published model, not a guaranteed return. Actual rewards depend on traffic allocation, successful relay work, ticket aggregation, redemption, and operating availability. A fixed APY would conceal those inputs and can become stale as network conditions change.

Activation Evidence From the Node and Hub

Activation evidence begins with the node appearing under the intended HOPR Safe. The Staking Hub should show its address, onboarding status, version, last-seen time, availability record, and native-token balance. A token balance alone proves none of these operational states.

Node synchronization supplies the next observable checkpoint. The Admin UI reports synchronization progress. Wait for it to finish before checking the remaining reward conditions; adding stake or creating another Safe does not complete synchronization.

An open outgoing payment channel is another acceptance signal. After the channel opens, it should appear in the outgoing-channel view rather than merely producing a submitted transaction. This recorded state shows the node has completed the channel action needed for Cover Traffic eligibility.

A node can show full synchronization yet remain unreachable from peers. In that edge case, check the announced endpoint, public reachability, port handling, and chain connection. Keep the existing stake and Safe intact while correcting connectivity, then check the last-seen and availability fields again.

Pre-Commitment Decision Checklist

The checklist separates token possession from a complete node plan. Every item should have a concrete answer before bridging, wrapping, or allocating stake:

• Identify the 30,000 wxHOPR route or confirm a qualifying Network Registry NFT and the 10,000 wxHOPR route.
• Confirm the owner wallet, HOPR Safe plan, and recovery arrangement.
• Prepare a supported Linux or macOS host meeting the minimum CPU, memory, and disk requirements.
• Confirm a reachable endpoint, stable addressing method, and ability to keep the node online.
• Account for Gnosis Chain transaction funds separately from the wxHOPR stake.

Reversible Stop Points and the Next Decision

The easiest point to stop without another transaction is before bridging, wrapping, or depositing tokens. Insufficient wxHOPR, unsupported hardware, or uncertain Safe ownership should pause the process at that point. Keeping assets in their existing form avoids adding transactions while the missing prerequisite remains unresolved.

SafeStaking has no staking lock-up period, so funds can be withdrawn. Dropping below the applicable threshold ends reward eligibility and may affect a pending waitlist position. Removing a node from the HOPR Safe is a separate administrative action. Once every readiness and activation condition is understood, the next decision is whether continuous node operation justifies allocating the required wxHOPR.