# Service Nodes (SN)

## What Is an XEQM Service Node?

An XEQM Service Node is a core infrastructure node on the XEQMLabs network. It does far more than hold a copy of the blockchain — it processes transactions, enforces privacy, participates in consensus, and powers the developer platform.

On the XEQMLabs network, service nodes are the backbone of the chain. Regular nodes observe the network. Service nodes operate it.

***

### What a Service Node Does

#### Processes and Validates Transactions

Service nodes receive transactions from the network, validate them, and relay them efficiently across peers. This improves speed, reliability, and resilience — especially under load.

#### Enforces Privacy

Because XEQM is a Monero-fork, private-by-default chain, service nodes play a direct role in maintaining privacy at the network layer:

* Routing transactions without exposing sender or receiver
* Handling encrypted transaction data
* Supporting privacy-preserving mechanisms at the protocol level

Balances stay hidden. Amounts stay hidden. Transaction graphs stay unreadable. Privacy is not optional — service nodes enforce it.

#### Participates in Consensus (Pulse)

Service nodes actively participate in Pulse, the network's consensus mechanism. They help agree on the current state of the chain, contribute to block finality, and improve block times and network stability. They are part of deciding what is valid — not just watching it happen.

Pulse rounds run on a **30-second timeout** per round, targeting **1-minute block times**. Each block requires consensus from a quorum of active service nodes — block production is deterministic and stake-weighted, not energy-wasteful.

#### Enables Fast Transactions (Blink)

Service nodes power Blink transactions, which provide near-instant confirmation through quorum-based validation. This is how the network avoids the usual privacy-versus-speed tradeoff — fast transactions without sacrificing privacy.

#### Provides Network Services

Service nodes also handle data routing, peer discovery, network synchronization, and fault tolerance. They are the operators keeping the network running smoothly.

***

### Service Node Economics

#### Staking Requirements

The XEQM mainnet uses a **flat staking requirement of 200,000 XEQM** per service node, constant across all hard forks. There are two ways to operate:

| Mode          | Operator stake       | Contributors                                     | Operator cut |
| ------------- | -------------------- | ------------------------------------------------ | ------------ |
| **Solo node** | 200,000 XEQM (full)  | None                                             | N/A          |
| **Pool node** | 100,000 XEQM minimum | Up to 10 contributors fill the remaining 100,000 | 0–10%        |

Pool nodes enable flexible participation without centralization pressure. Operators who cannot meet the full stake on their own can accept contributions from the community to fill the remainder. **The operator cut is capped at 10%**, ensuring contributors always receive at least 90% of their proportional share.

#### Block Rewards

Each block pays out:

| Recipient             | Reward per block | Notes                                                                      |
| --------------------- | ---------------- | -------------------------------------------------------------------------- |
| Service Node (winner) | **8.25 XEQM**    | Distributed to operator + contributors per stake share, minus operator cut |
| Foundation            | **12.4 XEQM**    | Funds ongoing protocol development and infrastructure                      |
| **Total per block**   | **20.65 XEQM**   | At \~1 minute target block times                                           |

Rewards are batched under HF19's reward batching — payouts are aggregated and distributed at regular intervals rather than per-block, reducing on-chain bloat.

#### Operational Improvements Under XEQM

XEQM significantly improves the service node experience compared to the legacy chain:

* **No renewal requirements** — stake once and operate indefinitely while collateral remains staked
* **Immediate recovery from compliance issues**, replacing the legacy 28-day lockout
* **Consistent 14-day unbonding period** when you choose to exit
* **No reward lockouts** — no more lost earnings from minor downtime
* **Hard fork grace periods** — for 5 days after any hard fork, only temporary decommissions occur (no permanent deregistrations), giving operators time to update without risk to their stake

These changes reduce friction and improve operator reliability across the network.

#### Dual Income Streams (coming soon)

Service node operators who also run an API node earn from two separate and additive sources:

* **Block rewards** from consensus participation (8.25 XEQM per block to the winning SN)
* **Platform fees** from API requests served (35% of all platform fees go to API node operators)

As the developer platform grows and more applications generate usage, the fee-based income stream grows alongside it — creating a direct link between platform adoption and operator earnings.

***

### Reliability & Penalties

XEQM uses a forgiving but firm system of decommissions and deregistrations to keep the network healthy without unfairly punishing operators for brief outages. The system is built around **"decommission credits"** — an outage budget you accumulate by staying online.

#### How credits work

| Threshold                    | Value          | Meaning                                                                                                         |
| ---------------------------- | -------------- | --------------------------------------------------------------------------------------------------------------- |
| Initial credit (new SN)      | **2 hours**    | Every newly registered node starts with a 2-hour buffer                                                         |
| Credit earned per day online | **48 minutes** | Stay online, build up your buffer                                                                               |
| Maximum credit cap           | **48 hours**   | Credits stop accumulating once you have 48h banked                                                              |
| Minimum credit threshold     | **2 hours**    | If you drop below this when caught failing, you face permanent deregistration instead of temporary decommission |

#### What happens when you go offline

The protocol distinguishes between two types of failures:

* **Temporary decommission** — you have credits remaining. You're suspended from earning rewards, but your stake stays in place. Come back online and a quorum will automatically *recommission* you.
* **Permanent deregistration** — you've exhausted your credits. Your stake is locked under penalty for 7 days before you can withdraw.

This gives operators significant runway. A new SN can be offline for up to 2 hours immediately after registration with no permanent consequence. A long-running SN (with credits maxed out) can be offline for up to 48 hours and still recover cleanly.

#### Stake lock durations

When a service node leaves the network — whether by choice or by penalty — there's a waiting period before the staked funds become withdrawable.

<table><thead><tr><th>Scenario</th><th width="112">Duration</th><th>What it represents</th></tr></thead><tbody><tr><td><strong>Voluntary unlock</strong></td><td>14 days</td><td>Service obligation period — your node continues operating and earning during the wind-down</td></tr><tr><td><strong>Involuntary deregistration</strong></td><td>7 days</td><td>Punitive cooldown — your stake is frozen, your credits are forfeited, your key images are blacklisted from re-registration during this period</td></tr></tbody></table>

The voluntary period is longer because you remain a contributing node during it. The involuntary period is shorter in calendar time but harsher in what it costs you: you lose accumulated credits, forfeit pending rewards, and cannot use the same stake to re-register until the lock expires.

#### Uptime proof requirements

Service nodes submit uptime proofs to the network on a regular cadence:

* **Every 10 minutes** — your daemon submits a fresh uptime proof
* **21-minute validity window** — if no proof has been accepted within 21 minutes, you're considered offline by the obligations quorum

In practice this means short network blips are absorbed, but a sustained outage of more than \~20 minutes will start counting against your credit balance.

#### Quorum tests

Each service node is tested by rotating quorums on multiple dimensions:

| Test                 | What it checks                                       | Threshold                      |
| -------------------- | ---------------------------------------------------- | ------------------------------ |
| **Uptime proofs**    | Are you reachable and submitting fresh proofs?       | 21-minute validity             |
| **Pulse votes**      | Are you participating in block production consensus? | At most 4 missed out of last 8 |
| **Checkpoint votes** | Are you signing off on chain checkpoints?            | At most 4 missed out of last 8 |
| **Timestamp votes**  | Is your clock in agreement with the network?         | At most 4 missed out of last 8 |

Failing any single test triggers credit consumption — but as long as you have credits available, the worst that happens is a temporary decommission.

#### Network safeguards

* **Maximum 1 SN deactivated per block** — even if many SNs simultaneously fail, only one decommission/deregistration can land per block. This prevents cascading failures and gives operators time to react.
* **Minimum 12 active SNs required for Pulse** — below this threshold the network would stall, so the deactivation rate-limit becomes especially important during bootstrap or post-fork periods.

***

### Why Service Nodes Matter

Without service nodes, the network is slower, privacy guarantees weaken, consensus becomes fragile, and advanced features like Blink do not work.

With service nodes, the chain stays fast, stays private, stays decentralized, and the community — not a centralized company — runs the infrastructure.

***

### Service Nodes and the Developer Platform

XEQMLabs is not just a privacy coin. It is a private developer network. Service nodes are what make it possible to build private applications, route private data, support oracle and real-world data services, and scale the network without turning it into a surveillance chain.

Every privacy-native application built on the XEQMLabs platform relies on service nodes to deliver the guarantees that make those applications work. Service nodes are foundational infrastructure — not optional add-ons.

***

### TL;DR for prospective operators

If you're considering running a service node:

* **Stake 200,000 XEQM** (solo) or **100,000 XEQM** (pool, with contributors filling the rest)
* **Pool node operator cut up to 10%** of distributed rewards
* **Earn 8.25 XEQM per block won**, plus a share of platform fees if running an API node
* **Stay online and reachable** on ports 9230 (P2P) and 9232 (Quorumnet) — proofs go out every 10 minutes
* **You have a 2-hour grace period** as a new node, building up to 48 hours of outage budget
* **Brief outages are forgiven** automatically; sustained downtime with no credits results in a 7-day stake lock
* **Voluntary exit takes 14 days** to unlock your stake
* **Post-fork grace period of 5 days** protects against permanent deregistration during upgrade windows


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://xeqmlabs.gitbook.io/docs/documentation/whitepaper/service-nodes-sn.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.