Managing Nodes

This guide covers all aspects of node management, from adding new machines to configuring settings and handling customer requests.

Browserless / agent-driven node management

Every action in this page is also available from the lium provider CLI — same surface as the portal frontend, scriptable, with --json envelopes for AI agents and CI. For example: lium provider node add --gpu-type "NVIDIA H200 NVL" --gpu-count 8 --ip <IP> --port 8080 --price 1.85 --yes.

Adding New Nodes

Prerequisites

Before adding a node, ensure:

1. Node Software Running: Your GPU machine has the node program running (for Enter the details; Run one command installs it)
2. Network Access: Machine is accessible from the internet
3. Provider connected: Your provider (self-hosted, or the Lium.io Central Provider Server) is running and connected to the portal
4. 8× H200, B200 or B300 only: the node offers GPU splitting with a minimum below 8, GPU profiling, or an attested confidential VM. Without one of these the node earns rental income but no idle pay. The form shows this checklist when you pick one of these models with a count of 8.
5. Confirmed e-mail address (hotkey accounts; not released yet): needed to add a node. An account with no node on its list needs it at once; an account with nodes needs it after 14 days. A held add from the CLI or API answers PROVIDER_EMAIL_REQUIRED. Nodes you already listed, and their rentals, are not affected. See Connect an e-mail address.

Registration Process

Open the popup from the Nodes page with Add Node. For an account that signs in with a hotkey it has two tabs and opens on Run one command on the host (a link that pre-fills any node detail opens Enter the details); an account created with e-mail or Google sees only the form and adds nodes with the install command on its Overview.

Run one command on the host (hotkey accounts, since lium 0.0.45): click Generate command and paste the line it shows into a shell on the GPU machine, as a user who can run Docker, on a host that already meets the Node Quickstart requirements including Sysbox — the command checks for nvidia-smi, the NVIDIA Container Toolkit and Docker and stops if one is missing, and it does not install Sysbox, without which the node registers but is never listed:

curl -fsSL https://lium.io/mine.sh | bash -s -- --register <token>

The token in the line works for one hour and can only add a node to your account and read a node's status; the node list and status the command prints afterwards are public reads that need no token. The command installs the node software, checks the machine, starts the node and adds it to your account with the GPU model and count the machine reports, this machine's public IPv4 address, the node's port and the model's base price (change the price afterwards with Update Price, or append --price <USD per GPU-hour> to the line) — nothing is typed by hand. It then prints the node's status every time it changes until the node is listed, the portal names something to fix, or 45 minutes pass (--wait); in every case the node stays registered and the Nodes page keeps updating on its own. While the command is valid, the popup shows the same status for the nodes added since it was generated.

Enter the details — the form, for a node whose software is already running:

1. Access Add Node Modal:

   • Navigate to the Nodes page
   • Click the "Add Node" button
   • A popup modal will appear

2. Fill Required Information:

   • GPU Type: Select from available options (RTX 4090, A100, etc.)
   • GPU Count: Enter the number of GPUs in the machine
   • Machine IP Address: Public IP address of your node
   • Port: Port number where the node program is running
   • GPU Price: Hourly price per GPU (in USD)
   • Tier: Secure (the default) or Spot; see Node Tier

3. Submit Registration:

   • Review all information for accuracy
   • Click "Add Node" to register

Synchronization

The sync controls below apply when you run a self-hosted provider. If you've opted into the Lium.io Central Provider Server, Lium handles sync for you and these buttons are not needed.

Sync From the self-hosted provider

Sync nodes from your self-hosted provider to the portal:

• Purpose: Import node configurations from your self-hosted provider
• When to Use: After setting up nodes directly on your server
• Process: Click "Sync From Provider Server" button
• Result: Nodes configured on your server appear in the portal

Note

When you first login on portal, the sync process will be done automatically for you.

Sync Into the self-hosted provider

Sync node configurations from the portal to your self-hosted provider:

• Purpose: Export portal configurations to your self-hosted provider
• When to Use: After making changes in the portal that need to be reflected on your server if your server lost connection at that moment.
• Process: Click "Sync Into Provider Server" button
• Result: Portal configurations are applied to your self-hosted provider

Note

The syncing process is done automatically as long as your self-hosted provider is connected to the portal backend and you barely need to do manual sync at all.

Synchronization

Always ensure your self-hosted provider is running and accessible before attempting synchronization.

Post-Registration Steps

After successful registration:

1. Monitor Status: Check that the node appears as active
2. Configure Settings: Set notice periods and other parameters

Price Management

Updating Prices

1. Access Price Settings:

   • Navigate to your node details page
   • Click the "Update Price" button
   • Enter the new hourly rate per GPU (in USD) in the GPU Price field
   • Note: The Machine Price field is deprecated and will be ignored

2. Price Considerations:

   • Minimum Viable Price: Set prices that cover your operational costs
   • Competitive Pricing: Research market rates to stay competitive
   • GPU Count Impact: Total rental cost = GPU Price × Number of GPUs rented

Before you set a price, open the public Marketplace prices dashboard (no login); the Update Price dialog links to it. Pick your GPU model at the top. It lists every listed node of that model with its asking price per GPU-hour, whether a customer pod is running on it, and the price that rental pays. Beside and below the list: the percentiles of the rented-at prices right now, the price of every rental started in the time range you pick (the last 7 days by default), and how many hours each node sat unrented before it was rented at a given price. The last four panels compare asking price with paid price per GPU model: the median asking price of unrented nodes against the median price the running rentals pay, now and per day over 30 days; how many hours nodes priced below, at or above their model's median asking price sat unrented before they were rented; and the share of listed nodes rented, hour by hour. Groups under 3 nodes are hidden. The calculator's average price is a 30-day figure; this dashboard shows today.

Price Updates

On a node with no pod, a new price applies to new rentals at once; on a rented node the marketplace shows it after the next platform sync, about 15 minutes. A raise is accepted at any time, also while a rental on the node is young, and new rentals pay it from that listing. What counts for a running rental is your new price against what that rental pays today, not whether you moved the number up or down: a rental that pays less than the new price moves to it, on a Secure node, 7 days after the renter is told (by e-mail and on the pod page) and never before it is 21 days old; on a Spot node, 24 hours after the renter is told and never before it is 15 days old. In a rental's first 14 days the renter is not told yet and the notice has not started; the e-mail goes out on the rental's day 14 (for example, on a Secure node, a rental started on 1 October at $2 and a raise to $2.40 on 5 October: new renters pay $2.40 at once, that rental's renter is told on 15 October and it pays $2.40 from 22 October); a rental that pays more than the new price moves to it with that sync, with no notice, at any age of the rental. Lowering a price is never limited and needs no notice; a lower price also reaches the running rentals on that node, including the rented GPUs of a partly rented node. If you raise the price again inside that notice (7 days, or 24 hours on a Spot node), the renter is told again and the notice starts over from it; if you lower it but it stays above what the rental pays, the rental moves to the lower price on the date already given. A renter gets at most one such e-mail per pod per 24 hours, so a change within 24 hours of the last one waits for the next e-mail, and the notice runs from it: moving the price up and down several times a day delays the raise rather than speeding it up. The price form on a rented node shows the same line. While a node is rented, you can also raise its price only once per calendar month (UTC), and by at most 25% over what the rental pays per GPU; see Price limits. A running rental's increase is capped at 125% of what that rental pays now, whatever the listing: for example, a rental paying $1 on a node whose price you lower from $3 to $2.50 moves to $1.25 after the notice, not to $2.50, while new rentals pay $2.50.

Pausing New Rentals

Use Pause New Rentals when you want a node to stop accepting new rentals but keep it listed in the portal. On an idle node the pause applies at once. On a rented node it applies after the current renter is done; this does not stop, delete, or interrupt the active pod.

When to use it

• You want to keep an idle machine listed in the portal but not for rent for a while (it earns no unrented availability reward while paused)
• You plan to take the machine offline after the current rental ends
• You want to drain a node before maintenance or hardware changes
• You want the current renter to finish normally, but do not want another renter to immediately take the node

Rented nodes stay active

While the pause is pending, the current rental remains active and the node is still checked by validators. The node is removed from new-rental availability immediately, including partial GPU rentals on GPU-splitting nodes.

Request a pause

1. Open the node details page in the Provider Portal.
2. Click Pause New Rentals. The button is enabled whether the node is rented or idle.
3. Read the dialog and click Pause New Rentals to confirm. It states what the pause does. On a rented node: the node leaves the marketplace at once, the current rental keeps running and billing, and once the last pod ends the node earns no idle pay until you resume new rentals. On an idle node: the node leaves the marketplace and stops earning idle pay at once, and Lium's default job on it stops.

After the request is saved:

• The node is hidden from new-rental availability.
• On an idle node the pause is active straight away: the node's status reads NEW RENTALS PAUSED and the New Rentals (provider setting) row reads Paused, and it stops earning the unrented availability reward until you resume.
• Lium's default job stops on a node whose pause is active within about five minutes, and does not start there again until you resume. A Default Job you assigned yourself keeps running; see Default Jobs.
• On a rented node, existing pods continue to run and the node shows a pending pause state until the last active pod on that node ends. While the pause is pending, Lium can keep or start a default job on the node's free GPUs (GPU-splitting nodes).

After the current rental ends

When the final active pod on the node is deleted, the pause becomes active. At that point:

• The node stays hidden from new-rental availability.
• The node is not eligible for unrented availability rewards.
• Lium's default job stops on the node within about five minutes and does not start again until you resume.
• The node can be brought back with Resume New Rentals.

Cancel or resume

• Use Cancel New Rentals Pause while the pause is still pending and the node is still rented.
• Use Resume New Rentals after the pause has fully applied and you want the node to accept rentals again.

From the portal API

The buttons call POST /executors/{id}/new-rentals/pause and DELETE /executors/{id}/new-rentals/pause on the portal API (provider-api.lium.io), signed in. A script or an agent that pauses a node before a fix can tell whether its own call set the pause:

• When the pause call sets the pause, it answers paused_by_this_call: true and a new pause_id. On a node that is already paused it changes nothing and answers paused_by_this_call: false with the existing pause's pause_id. That id is null for a pause set without one, such as a pause from before the id existed or a pause the platform sets itself (which also clears an id already set), so a null never proves whose pause it is.
• GET /executors/{id}, GET /executors and GET /executors/listing show pause_id next to new_rentals_pause_requested_at. Both are null when the node is not paused.
• DELETE /executors/{id}/new-rentals/pause?pause_id=<id> resumes only while that pause is still the current one. Otherwise it answers 409 with detail.code PAUSE_ID_MISMATCH and detail.current_pause_id, and changes nothing: someone resumed or paused the node again after you. Without pause_id, the call lifts any pause, as the button does.

Price limits

These limits apply to the price you can set; all but the soft limit reject the price:

Constraint	Effect
Price below machine_min_price_rate × the GPU model's reference price	Portal rejects with HTTP 400 — the price is not saved. Portal-only: nothing else on the platform checks the floor
Price above machine_max_price_rate × the GPU model's reference price	Portal rejects with HTTP 400 — the price is not saved. Enforced beyond the portal: the platform refuses to save or refresh a node reporting a price above the cap, and the validator scores that node 0
While the node is rented: a second raise in the same calendar month (UTC)	The portal rejects it with HTTP 400 and names the date of the next allowed change. A raise counts in the month it reaches the marketplace (the next platform sync); until then a new price replaces the one you sent, and sending the node's current price or the price the marketplace already lists is not a change. A decrease is never limited and does not count
While the node is rented: a raise of more than 25% over the price per GPU the rental pays (the cheapest one when several rentals run)	The portal rejects it with HTTP 400 and names the highest price allowed. The cap also holds below the minimum allowed price: a node whose rental pays less than the minimum ÷ 1.25 (or $0) cannot raise its price until that rental ends. Separately, a running rental never moves up by more than 125% of what it pays now: a listing already above that (for example $2.50 over a $1 rental) moves the rental to $1.25 after the notice, and new rentals pay the listing
Price above the GPU model's soft limit (a price per GPU-hour, in the Soft Limit column of the Rewards Calculator)	Nothing is rejected — the node stays rentable and earns from rentals, and while idle it earns no unrented incentive. See Price and the unrented incentive

A node counts as rented while it has an ongoing rental, which includes one that is stopped, provisioning, starting, stopping or recovering. A node with no ongoing rental can change its price any number of times, by any amount within the allowed range.

The live list of soft limits loads in the browser, with JavaScript on. Each GPU model's soft limit is also in the Soft Limit column of the rewards calculator.

Both the reference prices and the floor/cap multipliers (the floor is 0.5; the cap is the machine_max_price_rate published at https://lium.io/api/v1/shared-config) change as the platform adds GPU models or rebalances rates, so read the limits from the API. The machines endpoint applies the multipliers for you — each GPU model carries its reference price in USD/hr, the allowed range as p_min and p_max, and the soft limit as soft_price_limit (null for a model that has no soft limit; see Price and the unrented incentive):

curl https://lium.io/api/machines

GPU Splitting

GPU splitting allows you to rent individual GPUs from a single node to multiple customers simultaneously, enabling more efficient resource utilization and flexible pricing.

Prerequisites

GPU splitting requires Docker to enforce a per-container storage limit. Check the host with the one-command probe in Docker Storage Setup, and complete the setup on that page if the probe fails — the Edit button on the GPU Splitting panel stays disabled until preflight reports the host as ready.

Setting Minimum GPU Count for Rental

After configuring the prerequisites, you must set a minimum GPU count to enable GPU splitting on your node.

1. Access GPU Splitting Settings:

   • Navigate to your node details page in the portal
   • Locate the "GPU Splitting" section in the details panel
   • If your node meets all prerequisites, you will see an "Edit" button

2. Configure Minimum GPU Count:

   • Click the "Edit" button
   • Set the minimum GPU count — at least 1, and below the node's total GPU count. A minimum equal to the total is a whole-host rental, not splitting.
   • Save your changes

Minimum GPU Count

GPU splitting requires a minimum GPU count to be configured. If the minimum GPU count is not set, the node will not support GPU splitting, and customers will only be able to rent all GPUs on the node. Once configured, customers can rent any number of GPUs from the minimum up to the total available GPUs on the node.

Disabling GPU Splitting: You can remove the minimum GPU count to disable GPU splitting. However, you can only remove it when there are no pods currently renting a partial number of GPUs.

Cluster Fabrics (InfiniBand and RoCE)

Nodes with an RDMA card can be wired into one fabric, which is what a distributed job across several machines needs. Both wires are sold: InfiniBand, paired by the subnet manager both nodes report, and RoCE (RDMA over Ethernet), paired when two of your nodes answer on one IPv4 segment. The portal shows where each of your nodes stands, and customers rent a ready fabric as one order from the Clusters tab — see Multi-node clusters for what they get when they do.

A RoCE pair also needs the switch between the two nodes to carry RDMA: lossless queueing, PFC/ECN. Lium measures that link between your two free nodes before offering the pair, so a switch that drops RDMA means the pair is never sold as a cluster at all. Configure it before you offer the pair.

Cluster badges

The Cluster status switch above the Nodes list shows or hides these badges; it covers both wires at once and the choice is remembered in your browser. With it on, the Nodes list and the node details page show one of:

• CLUSTER READY +N (RoCE: ROCE CLUSTER READY +N) — this node shares a fabric with N of your other nodes. The details page links to them.
• IB UNPAIRED / ROCE UNPAIRED — the link works, but the node has nothing to join: no other node of yours on the same fabric, or the fabric itself is not joinable. The tooltip names the reason and what fixes it — including a RoCE card that qualifies but holds no usable IPv4 address yet.
• IB LINK DOWN / ROCE LINK DOWN — the card is installed but no port is active. The link is down or not cabled.

Nodes without an RDMA card show no badge, and nodes are only ever paired with your own. If you run several miner hotkeys, nodes registered under different hotkeys are treated as separate fabrics even when they sit behind the same switch. A node holding both a live InfiniBand port and a live RoCE card is sold on InfiniBand, and its badge reads the InfiniBand side.

A RoCE pair must also pass Lium's link measurement: the validator runs an RDMA transfer between your free nodes and records the result. The tooltip tells you where the pair stands — measured and ready, waiting for a measurement, or failed. A failed measurement points at the switch: enable lossless Ethernet (PFC/ECN) and the next cycle re-measures it.

On a RoCE node's details page you also get the speed measured to each of its cluster partners, slowest first, with the slowest one repeated at the top: a distributed job runs no faster than the weakest link, so that is the one worth fixing. The port rate shown beside it is what the card reports it can do — a measurement far below it means the network between the two nodes, not the card.

Making nodes cluster-ready

1. Bring the port up — ibstat must report an ACTIVE port. A DOWN or Polling port usually means the cable is missing or the card is not connected to the switch.
2. Put the nodes on one fabric — connect them to the same switch, served by one subnet manager. A host running the subnet manager on its own port is a one-host subnet that nothing can join, and a host whose ports report different subnet managers is ambiguous and is not paired either. RoCE has no subnet manager: give the two cards one address each in the same /24, and put the switch in lossless mode. One address per host — when two of your nodes claim the same address, they sit behind different networks that only look alike, and the badge says so. A host with a live InfiniBand port is sold on InfiniBand and never on RoCE, even when it also carries a RoCE card, so a mixed host shows no RoCE pairing — its badge reads the InfiniBand side.
3. Keep them in one partition — nodes in different partitions cannot talk even on one subnet, so the portal does not pair them. Read a port's partition key with cat /sys/class/infiniband/<device>/ports/<port>/pkeys/0; 0xffff is the default full-membership one, and a value below 0x8000 is a limited member. Two limited members cannot reach each other, so at least one node of a pair has to be a full member. RoCE has no partitions; skip this step there.
4. Match the hardware — a cluster is rented as one GPU model at one density, because a single image runs against one architecture and an uneven number of GPUs per node paces the job by the smallest node. Two different cards on one fabric, or the same card at 8 GPUs on one node and 4 on another, are two separate groups.
5. Keep the node whole — a node opened for partial rentals cannot join a cluster: the RDMA devices only reach a pod that holds the entire host. Clear the minimum GPU count for rental on the node to make it joinable.
6. Open UDP port 51820 between your nodes — the nodes of a cluster first find each other over a private overlay, and only then does the job move onto the fabric. That overlay uses UDP port 51820. On a RoCE cluster the nodes reach each other over the fabric they already share, so nothing is open to the internet, but your own firewall must not drop UDP inside that segment. On InfiniBand they use their public addresses, so the port has to be open there. A blocked port gives no warning here: the node looks cluster-ready, and then it cannot join the job.
7. Wait for the next validation — the badge follows the validator's node scrape, so it updates within roughly 15 minutes.

Why bother

Very little supply on the network can serve multi-node jobs at all, and a cluster is rented as one all-or-nothing order: every member is taken at once, as a whole host. Wiring your nodes together is the slow part, and it is done once.

Taking a rented node out of service

A rented node leaves the platform in one of three ways, each from the node's detail page:

• Pause New Rentals: the current rental runs until the renter ends it, and no new renter can take the node. See Pausing New Rentals.
• Permanent removal notice: at a start time you pick at least 48 hours ahead, the platform deletes the renter's pod and marks the node removed. Every renter on the node gets an e-mail when you add the notice. See Notice Period Management.
• Force close (Mark broken): the recovery path for a pod whose container is already gone on the host; the renter is refunded and, on a Secure node, you take the provider penalty. See Force-closing a pod.

To keep the node and the renter at a new rate, raise the price: a running rental that pays less than the new price moves to it 7 days after its renter is told and never before it is 21 days old on a Secure node, or 24 hours after and never before day 15 on a Spot node. See Updating Prices.

Notice Period Management

Understanding Notice Periods

A notice period tells the renters of a node that it will be down, and tells the platform that you planned it.

• Maintenance needs 24 hours of notice. The period is 60 minutes at most.
• A permanent removal needs 48 hours of notice. At the start time the platform deletes the renter's pod and marks the node removed; the node is marked removed even when the renter has already left, so it is not rented again.
• Every renter with a pod on the node gets an e-mail when you click Add.
• If the node goes offline between the start time and the end of the notice, the interruption costs you no penalty. Before the start time it can. The dialog shows the two times once you pick a start time and a period; for a permanent removal it shows the start time.
• Every notice time in the portal is UTC. The node card and the node page show the same moment on your own clock next to it and count down to the start.

Setting Notice Periods

1. Open the node's detail page and click Add Notice Period. The button is active while the node is rented.
2. Read the lead time and the penalty window in the blue box.
3. Pick the start time. The time is UTC, and the current UTC time ticks under the picker. The picker refuses a time under 24 hours ahead, or under 48 hours for a permanent removal.
4. Enter the period in minutes (60 at most), or tick Permanent remove?. The start time is now shown again under the picker with the same moment on your own clock and a countdown ("starts in 2 d 3 h").
5. Click Add.

Notify Machine Request from Customer

Respond to customer requests efficiently:

1. Access Notify Feature:

   • Go to your node details page
   • Click the "Notify" button in the top-right corner
   • A modal window displays available machine requests (it needs a node verified by a validator — see Machine Requests)

2. Select and Notify:

   • Review available machine requests
   • Select appropriate requests based on your node's capabilities
   • Click "Notify" to send notification to the renter

Force-closing a pod (Mark broken)

Why this exists & when to use it

Sometimes a pod's container disappears or dies on your host machine, but Lium still shows the pod as rented. When that happens the node gets stuck: the rental isn't actually running, so the node keeps scoring zero incentive, and you have no way to clear the dangling pod on your own — leaving the machine unusable even after a penalty has been applied.

Force-closing is the recovery path for exactly this situation. By marking the dead pod broken you accept the provider penalty and refund the renter what they paid; in return, the pod is cleared and your node returns to the rentable pool so it can be rented and earn its score again.

Use it when:

• A rented pod's container is gone or dead on the host but still shows as rented/running in Lium, and
• You have no other way to recover the node.

It's a recovery tool, not a routine action — it costs you a penalty and disrupts the renter, so only reach for it when the node is genuinely stuck.

How to do it

1. Open the node's details page in the Provider Portal.
2. In the pod status table, find the pod and click Force close / Mark broken.
3. Read the confirmation, then click Mark as broken.

What happens

• A provider penalty is applied in any pod status (a stuck pod in REBOOT_FAILED or a pod on an inactive node included): the renter is credited for the disruption, and you lose 48 hours of the rental's price, taken from your later payouts (see Penalties).
• The pod's GPUs are released back to the rentable pool, so the node can be rented again and recover its score.
• For the renter, the pod turns to BROKEN — they're notified they were credited and the pod can only be deleted.
• The node stays listed. Force-closing never sets the node inactive by itself.

Two pods per node per 24 hours

You can force-close at most 2 pods on one node within 24 hours. A third is refused with HTTP 429 (MARK_BROKEN_RATE_LIMITED) and nothing happens to that pod: it stays open. Only a pod that was starting or running on a listed node counts. Marking the same pod again does not use another slot, and closing a stuck pod (for example one in REBOOT_FAILED, or any pod on a node that is already inactive) does not count. The limit follows the machine and the account, not the node entry: a node registered again with the same GPUs keeps its count, and across all your nodes together at most 3 pods can be force-closed within 24 hours. The check runs again when the close is processed: a pod that was restarting when you marked it and is running by then uses a slot, and stays open when no slot is left.

The container is NOT torn down for you

Marking a pod broken only updates billing and state. The platform does not stop the container — you must kill it yourself on the host machine. Otherwise it keeps running and consuming resources.

Tier affects the penalty

On Secure nodes a force-close applies the penalty above. On Spot nodes no money is withheld (renters already accept that Spot pods may be interrupted): the penalty is recorded as a dry run, which counts in your reliability score only when the rental was forced Spot. See Node Tier: Secure vs Spot and Penalties recorded as a dry run.

Force-closing a rental minutes after it started (not yet active)

Billing runs every 5 minutes. Force-closing a running pod on a Secure rental costs 48 hours of the rental's price even when nothing was billed yet, one minute after the start included: nothing is withheld, and the whole amount is booked as a debt taken from your later payouts.

A pod that was still starting and never ran has nothing to charge. Its close is recorded as a PROVIDER_KILL penalty event with nothing withheld (on a Spot-tier rental, a running pod closed before its first billed minutes is recorded the same way), and the rental's tier (fixed when it started) decides what the event does:

• Secure rental: the event lowers your public reliability score, and until it is reverted, or for 30 days, it is an open penalty that keeps the Lium team from removing the node as stale.
• Forced Spot rental (force_spot, for example a banned hotkey): the event is a dry run. It lowers your reliability score, and the node stays removable.
• Spot rental on a node you set to Spot yourself: the event is a dry run. Your reliability score and the node's removal stay as they were.

See Penalties for the full rule.

If you need to take a node out of service, use Pause New Rentals first (see above) and let the running rentals end.

Reclaiming collateral

Lium rents and pays nodes with zero collateral. A node that still holds collateral from an earlier deposit keeps serving and earning while you withdraw it from the node page, with the EVM wallet that made the deposit:

1. Reclaim signs the reclaim request in your wallet. The portal shows the request id, the amount and its expiration time; the request is approved within about 10 minutes.
2. Finalize Reclaim, once the expiration time has passed, signs the finalize call in your wallet and the TAO arrives in that wallet. The node's collateral then reads 0, and the portal accepts a delete.

The node page's Reclaim panel shows the latest request and its status.

Node Deletion

When to Delete a Node

Consider deleting a node when:

• Hardware Issues: Machine has failed
• Upgrade Plans: Replacing with better hardware
• Cost Optimization: Reducing operational costs
• Relocation: Moving to a different location

Deletion Process

1. Delete Node:
   • Delete from the portal
   • The node leaves the rental listing within a few minutes, whether your provider is online or offline
   • An offline provider receives the delete the next time it connects and drops the node from its own list
   • (not released yet) For 60 minutes after the delete, a validator report about the node does not list it again (a report can still be on its way when you delete). Adding the node back in the portal lists it right away.
   • (not released yet) A deleted node takes no new rentals, even when a validator report about it arrives after the delete.

Delete is refused while the node holds collateral or is rented

The portal does not delete a node that still has collateral in the contract or an active rental; the dialog stays open and says which. To clear it: reclaim the collateral (node page → Reclaim, then Finalize Reclaim once approved) and wait for the reclaim to confirm, or wait for the rental to end (or set a notice period) — then delete. Until then the node is still yours: adding the same IP and port again is refused with a link to the existing node. An address registered under another account is refused too. Some old registrations can be replaced when you add a node. If Add Node says the address belongs to another account and the machine is yours, contact support. Any collateral on that old registration stays in the contract for whoever deposited it to reclaim.

Archived nodes

Archived nodes are nodes silent for 30 days. A node with no sign of life for more than 30 days leaves Current nodes and moves to the Archived nodes tab on the Nodes page (under the miner selector). The tab shows how many nodes are in it and uses the same table and page controls as Current nodes, so every archived node can be listed. "Sign of life" is the newest of: the day you added the node, the validator's last verification start, its last report about the node and the node's last verified date. A tier, GPU-detail or splitting change in the portal leaves that clock as it is. A price change on a checked node that is still unrented counts as activity and restarts the 30 days; a node that has been rented is archived on silence alone.

An archived node is hidden from renters. Nodes that are being reclaimed, rented or live stay under Current nodes.

• The archived table adds Last seen. When All miners is selected it also shows the miner.
• Remove deletes one node you own. Remove all N is only on your own miner list; it deletes those nodes one after the other and the button shows the progress.
• The same rule as a single delete applies: a node that still holds collateral in the contract, or is rented, stays and the message says so.
• The delete reaches your miner server when it is connected; an offline miner server receives it the next time it connects and drops the node from its own list.
• If a machine comes back, the validator sees it again and the node returns to the main table on the next page load. Nothing is needed from you.

Troubleshooting

Common Issues

Node Not Appearing

• Check Registration: Verify all required fields were filled correctly
• Network Connectivity: Ensure machine is accessible from the internet
• Provider connected: Confirm your provider is running and connected (self-hosted, or Lium.io Central Provider Server toggle on)
• Address already registered: If another account already has that IP and port, the portal skips the node when your provider lists it. The node stays off your list. Add it in the portal when the address is free, or use a different IP and port.
• Validation: a new node shows VALIDATION PENDING until a validator has verified it and published — 21 minutes at the median, 64 at the 90th percentile over the 175 nodes added in the 30 days to 6 Sep 2026. Each badge and what to do about it: Monitoring → What each status means

Score dropped to 0 after the node's public IP changed

What you see: the node scores 0 every cycle with no other error; the Job Logs show the placeholder executor id 11111111-1111-1111-1111-111111111111 and Miner returned zero executors in AcceptSSHKeyRequest. The node itself is healthy — the validator is dialling the address registered for the node, and nothing answers there any more. A dynamic ISP address is the usual cause.

Why editing .env does not help: the address the validator dials is the one in the node's registration, and nothing edits it in place — the portal changes a node's price, tier and GPU details, not its address, and EXTERNAL_IP_ADDRESS in a self-hosted provider's .env is the provider host's own address, not a node's.

Fix: delete the node in the portal and add it again with the new IP (same port, GPU type, count and price — see Adding New Nodes). It re-registers under a new node id and goes through VALIDATION PENDING again like a new node (21 minutes at the median, 64 at the 90th percentile — see Monitoring → What each status means); your earnings history stays with your hotkey. The portal refuses the delete while the node still has a rental recorded or collateral in the contract — the error says which — so wait for the rental to end first.

This is the same on the Lium.io Central Provider Server and on a self-hosted provider: the portal sends the delete and the add to your connected provider. remove-executor and add-executor on the provider container change only the provider's own node list; the portal does not learn about them until you sync.

A fixed public IP avoids the reset altogether. While the node is unreachable, any rental running on it cannot be torn down by the validator, which counts as a penalty — move to a static address if this happens more than once.