> For the complete documentation index, see [llms.txt](https://docs.spacecoin.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.spacecoin.org/spacerouter-proxy/concepts.md).

# Concepts

### The four roles

**Proxy Consumer** Anyone who sends traffic through SpaceRouter Proxy — a developer running an SDK, a script using curl, or an app calling the gateway. Consumers pay for the bandwidth they use.

**Proxy Provider** Anyone running the SpaceRouter Proxy app on a computer at home (or a server) to share their internet connection. Providers stake SPACE to qualify, serve traffic, and earn SPACE in return.

**Gateway** The single entry point for all consumer traffic. The gateway authenticates the consumer, picks a Provider that matches the request's region and IP type, and relays the traffic. You can think of it as the network's switchboard.

**Coordination API** The brain that registers Providers, runs health checks, calculates rewards, and pays Providers on-chain. Consumers don't interact with it directly.

### Status states for a Provider

The app on a Provider's machine and the staking dashboard show one of four status states. They tell you whether you are earning right now, and what to do if you are not.

<table><thead><tr><th width="118.421875">State</th><th>What it means</th><th>What to do</th></tr></thead><tbody><tr><td><strong>earning</strong></td><td>Your node is online, your stake is approved, and you are earning SPACE on every request routed through you.</td><td>Nothing — keep the node online.</td></tr><tr><td><strong>qualifying</strong></td><td>Your node is online and staked, but the network is still verifying your reliability for the current period. New nodes spend their first review window here.</td><td>Wait. Reviews run every 4 hours at fixed UTC times; full approval typically lands within one or two review cycles.</td></tr><tr><td><strong>unstaked</strong></td><td>Your node is online, but your stake is below the minimum required to earn.</td><td>Open the staking dApp and stake more SPACE.</td></tr><tr><td><strong>inactive</strong></td><td>Your node is offline, your wallet is draining, or no staking address is set.</td><td>Restart the app and check your network mode in Troubleshooting.</td></tr></tbody></table>

### Periods and review windows

SpaceRouter Proxy scores Provider reliability in fixed windows called **periods**. At the end of each period, the Coordination API decides which Providers earned during the window and approves new ones. Periods are measured in minutes, not blocks — they have nothing to do with Substrate eras.

### Tokens you'll see

<table><thead><tr><th width="102.3359375">Symbol</th><th>What it is</th><th>Where it's used</th></tr></thead><tbody><tr><td><strong>SPACE</strong></td><td>The Spacecoin token. ERC-20 on Creditcoin mainnet.</td><td>Stake to qualify as a Provider; deposit to escrow to pay for proxy traffic; receive as Provider rewards.</td></tr><tr><td><strong>CTC</strong></td><td>Creditcoin's native gas token.</td><td>Pays the gas fee on every on-chain transaction (deposit, claim, withdraw). You only need a small amount.</td></tr><tr><td><strong>SPC</strong></td><td>The testnet-only equivalent of SPACE.</td><td>Used on the Creditcoin CC3 testnet for development. <strong>Never used in production.</strong></td></tr></tbody></table>

### How you pay for traffic

You hold SPACE in your wallet, deposit some into the on-chain escrow contract, and your SDK signs a tiny receipt for every request. The gateway settles those receipts on-chain in batches. No subscription, no card, no per-month commitment. See the Pay with SPACE guide.

### The two-leg payment model

Behind the scenes, every paid proxy request produces two receipts:

* **Leg 1 — Consumer → Gateway.** The consumer's SDK signs this receipt with their wallet. It pays the network.
* **Leg 2 — Gateway → Provider.** The gateway pays the Provider for serving the traffic. The Provider claims these receipts on-chain when they're ready.

Consumers only ever sign Leg 1. Providers only ever claim Leg 2. The gateway keeps a small margin between the two — that funds operations.

### Wallets a Provider needs

A Provider has up to three Ethereum-style addresses. Most users keep them all the same; they only diverge if you deliberately separate custody.

<table><thead><tr><th width="114.16015625">Wallet</th><th>What it does</th><th>Funds it needs</th></tr></thead><tbody><tr><td><strong>Staking</strong></td><td>Holds your staked SPACE. You picked this when you staked.</td><td>SPACE (your stake)</td></tr><tr><td><strong>Collection</strong></td><td>Where your SPACE earnings land when you claim. Defaults to your Staking wallet.</td><td>None — it just receives</td></tr><tr><td><strong>Identity</strong></td><td>Created automatically by the app on first launch. Signs API requests <em>and</em> broadcasts your on-chain claim transactions.</td><td><strong>A small amount of CTC</strong> for gas. Without CTC here, claims fail.</td></tr></tbody></table>

{% hint style="warning" %}
**Most common provider mistake**

Forgetting that the Identity wallet needs CTC. You stake from your Staking wallet, but the app claims earnings from the Identity wallet. Top up the Identity wallet with \~1 CTC before your first claim.
{% endhint %}

### Glossary

**Receipt** — A small signed message that says "this many bytes were served at this price for this request." Used as on-chain proof of bandwidth.

**Escrow** — The on-chain contract that holds Consumer SPACE deposits and pays Providers when receipts are claimed.

**Claim** — A Provider's on-chain transaction that submits a batch of signed receipts and transfers earned SPACE into the Collection wallet.

**Identity key** — The private key the app generates on first launch. Stored at `~/.spacerouter/certs/node-identity.key`. Back this up.

**Region / IP type** — Routing preferences a Consumer can attach to a request: a 2-letter country code (e.g. `US`, `KR`) and one of `residential`, `mobile`, `business`, or `hosting`.

**Period — A fixed-length review window (currently 240 minutes /** 4 hours) used to aggregate Provider health-probe results. The Coordination API runs a review every 4 hours (at 00:00, 04:00, 08:00, 12:00, 16:00, 20:00 UTC) to approve or disapprove Providers based on their pass rate over the window.