> For the complete documentation index, see [llms.txt](https://docs.coti.io/coti-documentation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.coti.io/coti-documentation/node-ecosystem/ui-guide/glossary.md). # Glossary Terms you will encounter in the COTI Node Ecosystem web app, the installer, and this documentation. Definitions are authored for node operators; wording may differ from internal field names while preserving the same meaning. ## Node states ### Node status The operational state of the node process, derived from the node's JSON-RPC `eth_syncing` method and peer presence: * **Active** — the node is online and fully synced with the tip of the chain. * **Syncing** — the node is online but still catching up on blocks. * **Offline** — the node is not currently observed in the peer set. "Online" in the UI refers to any node that is **Active** or **Syncing**. ### NFT state The on-chain thermal flag stored on the node's Soulbound NFT: * **Hot** — the NFT has been minted and is currently marked hot. * **Cold** — either the NFT has not been minted yet (treated as cold by default), or the NFT has been marked cold after a prolonged outage. ### Thermal status The combined state shown to operators, derived from node status + NFT state: | Node status | NFT state | Thermal status | | ---------------- | --------- | ---------------- | | Active / Syncing | Cold | **Warming up** | | Active / Syncing | Hot | **Hot** | | Offline | Hot | **Cooling down** | | Offline | Cold | **Cold** | ### Warming up A node is **warming up** when it is online and reachable but has not yet been continuously present long enough for the ecosystem to consider it stable. No NFT has been minted yet. The operator should keep the node online — the warm-up progress bar in `/my-nodes` tracks remaining time. ### Cooling down A node is **cooling down** when it was previously hot (NFT minted) but has gone offline. If the node comes back online before all connected time in the rolling **103-hour** window has aged out, it can remain hot. If it stays offline until peer presence in that window reaches zero, the NFT flips to cold and the node must warm up again (\~**72 hours** of connected time within the window). ### Time to thermal update Time remaining until the node transitions thermal state — until it becomes **hot** if currently warming up, or until it becomes **cold** if currently cooling down. Not shown when the node is already in a stable state (hot-while-online or cold-while-offline). ## Warm-up & cooldown windows The thermal state machine is driven by four configuration values maintained by the ecosystem. They are exposed so operators understand the timing of their node's transitions. ### HOT\_WINDOW\_HOURS The length of the rolling window used to decide whether a node is stable enough to become hot. Defaults to **103 hours** (one epoch). ### HOT\_THRESHOLD\_HOURS The minimum number of hours *within* `HOT_WINDOW_HOURS` that a node must be present as a peer to qualify as hot and receive its Soulbound NFT. Defaults to **72 hours**. In plain language: *"To become hot, a node must be seen by peers for at least `HOT_THRESHOLD_HOURS` hours during the last `HOT_WINDOW_HOURS` hours."* #### Becoming hot — illustrated example (production values) In production the ecosystem uses **`HOT_THRESHOLD_HOURS` = 72** and **`HOT_WINDOW_HOURS` = 103**. Peer discovery evaluates a **rolling** window: at any moment, only the last 103 hours count. Connected time that started **before** that window has already slid out and no longer contributes. ``` Each cell = 1 hour. █ = connected as peer · = offline or not yet in window NOW ─────────────────────────────────────────────────────────────────────► time │◄──────────── 103-hour rolling window ────────────►│ │ │ Case A — warming up │································████████████░░░░░░░│ 50 h connected → not hot yet │ │ (need 72 h) Case B — qualifies │································██████████████████│ 72 h connected → HOT │ │ (NFT minted) Case C — hours lost │████████████████████ (80 h connected long ago) │ │ │◄── 103 h window ──────────►│ │ ················████████████│ 53 h still count │ (offline since then) │ 27 h already slid out │ │ → not hot (need 72 h) ``` **How to read the diagram** | Case | What happened | Connected in window | Result | | ----- | ------------------------------------------------------------------------------------------------------------------------------------- | ------------------- | ----------------------------------------------------------------------- | | **A** | Node came online recently and has been up steadily | 50 h | Still **warming up** — 22 h short of 72 | | **B** | Same node, still online, a while later | 72 h | **Hot** — threshold met inside the window | | **C** | Node was connected for 80 h, then went offline; by the time it is evaluated again, the first 27 h of that streak are older than 103 h | 53 h (80 − 27 lost) | **Not hot** — earlier connected hours are **lost** for warm-up purposes | The window moves forward continuously. Every hour that passes drops the oldest hour from the count and adds a new empty hour at the trailing edge — unless the node stays connected, in which case that new hour accrues as connected time. ### COLD\_WINDOW\_HOURS The length of the rolling window used to decide whether a previously-hot node should be demoted back to cold. Defaults to **103 hours** (one epoch). ### COLD\_THRESHOLD\_HOURS Configured alongside `COLD_WINDOW_HOURS`; in production both default to **103 hours**. Peer discovery marks a hot node **cold** when it has **zero peer presence** anywhere in the rolling `COLD_WINDOW_HOURS` window. In plain language: *"A hot node that stays offline until all connected time in the last 103 hours has aged out cools back to cold and must redo the warm-up (\~103 hours of continuous absence)."* ## Identity & ownership ### Node private key The 64-hex secret that identifies a node on the network. It is generated locally in the browser (or supplied by the operator), written to the node's `nodekey` file by the installer, and **never transmitted to any COTI server**. ### Node address (public key) The Ethereum-style address derived from the node private key. It is used as the node's identity on-chain and is the wallet that receives the Soulbound Node NFT. ### Wallet address The wallet connected to the web app (for example via MetaMask). For the per-operator dashboard to show a node, the connected wallet must be the node address — that is, the wallet that owns the Soulbound NFT. ### FQDN (Fully Qualified Domain Name) The public hostname the operator uses for their node. It may be **your own domain** (for example `node1.example.com`) or a **COTI-assigned** name when using the tunnel installer (`--with-frp`), typically under a managed zone such as `*.testnet.nodes.coti.network` on testnet. The FQDN is a **prerequisite for rewards**: the ecosystem probes JSON-RPC through that name to determine uptime. See [**Installation**](/coti-documentation/node-ecosystem/installation.md), [**Own domain**](/coti-documentation/node-ecosystem/installation/installation-own-domain.md), and [**Wizard tunnel**](/coti-documentation/node-ecosystem/installation/installation-wizard-tunnel.md). ### RPC URL The public HTTPS endpoint the node exposes after installation, typically `https:///rpc`. After your node becomes **hot** and a monitor is registered, Better Stack polls the **Node Health Monitor**, which in turn calls this URL to verify block progression — Better Stack does not call your node directly. ### Soulbound Node NFT A non-transferable NFT minted to the operator's wallet once the node becomes hot. It stores the node's name and image and is the on-chain proof of node ownership. Because it is soulbound, it cannot be transferred between wallets. ## Rewards ### Epoch A fixed 103-hour reward period. At the end of each epoch, the rewards service evaluates eligibility and credits eligible nodes. ### Eligibility The set of rules a node + operator must satisfy in an epoch to receive rewards. The web app describes **two paths**; you qualify if **either** path is fully met (see **`/eligibility`**): * **Path 1 — USDC + COTI.** USDC on the COTI network ≥ combo threshold **and** COTI (non-custodial; **not** CEX) ≥ combo threshold **and** uptime ≥ configured percentage. * **Path 2 — COTI only.** COTI ≥ solo threshold (no USDC) **and** uptime ≥ configured percentage. Whitelisted operators are exempt from the holdings rules and only need to meet the uptime rule. ### Eligible A node that was found eligible for rewards in at least one epoch. The home-page stats card counts unique nodes that have ever been eligible; the `/my-nodes` per-epoch history marks each epoch with **Eligible** / **Ineligible**. ### Whitelisted An operator flag that exempts the wallet from the **Path 1 / Path 2** holdings checks. Uptime is still required. Whitelisting is managed centrally by COTI; most operators will not be whitelisted. ### Blacklisted An operator flag that prevents a node from being accepted as a peer candidate. Blacklisted nodes do not appear in the ecosystem's dataset and cannot accrue rewards. Blacklisting is used for operational or abuse reasons and is not a state a normal operator encounters. ### Uptime The percentage of an epoch during which the node was judged healthy by the monitoring stack. An RPC that merely answers is not enough — the health check confirms that the node is actually operating, and only healthy results accrue uptime. Displayed both per-epoch and all-time. ### Rewards (total / last epoch) * **Total Rewards** — all-time COTI earned by a node across every epoch it was eligible for. * **Last Epoch Rewards** — COTI earned in the most recently closed epoch. * **Next Epoch Rewards** — the size of the pool that will be distributed in the upcoming epoch (configured centrally). Rewards accrue in the on-chain **rewards smart contract** rather than being deposited directly into the operator's wallet. Operators withdraw their balance via the **Claim Now** button in the **My Node** dashboard, or by calling the rewards smart contract directly. ## Other terms you may see ### Live node heartbeats The home-page visualization showing the count of nodes currently observed by peer discovery. The pulsing tiles are purely decorative; only the counter reflects real data. ### Better Stack The external uptime-monitoring platform used by the ecosystem to probe every hot node. Operators do not sign up for or configure Better Stack directly — the ecosystem registers monitors automatically after NFT minting. ### Status page The public Better Stack dashboard that aggregates every hot node's monitor state (up / down). It is the fastest way to see the current health of the whole fleet. URLs are listed in [Networks](/coti-documentation/node-ecosystem.md#networks). ### Operator status dashboard (local) A small **local** web UI shipped with [`coti-full-node`](https://github.com/coti-io/coti-full-node), bound to **localhost** at port **8090** after `./start_coti-full-node.sh`. It shows process health, peer count, sync state, and (when configured) DNS/TLS or FRPC gateway checks — distinct from the **Nodes web app** dashboard at `/my-nodes`. With **host Nginx** or the **COTI tunnel** (via the internal **`nginx-frpc-gateway`** container), the same page is also available at **`https:///operator/`**. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## 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://docs.coti.io/coti-documentation/node-ecosystem/ui-guide/glossary.md?ask= ``` 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.