Node Delegation for Hosting Providers

Node Delegation for Hosting Providers

The Flux Node Delegation system, introduced with the PoUW v2 fork (fluxd v9.0.0, October 2025), allows a node owner to authorize up to four delegate public keys that can restart and manage the node on the owner's behalf. This eliminates the need to share collateral private keys with hosting providers, enabling a clean separation between node ownership (holding collateral) and node operation (restarting, upgrading, monitoring).

Why Delegation Matters for Providers

Before delegation, hosting providers faced a fundamental security dilemma: to restart a customer's node (e.g., after a DOS event or benchmark failure), the provider needed access to the customer's collateral private key. This meant customers had to trust providers with the key that controls their 1,000 / 12,500 / 40,000 FLUX collateral. Delegation solves this entirely.

1. 1

   No private key exposure

   Providers manage customer nodes using their own delegate key. The customer's collateral key never leaves their wallet.

2. 2

   Remote restart capability

   When a node goes offline (DOS status, benchmark failure, network issues), the provider can restart it using the delegate key without contacting the node owner.

3. 3

   Autonomous maintenance

   Providers can remotely upgrade and restart nodes without notifying the owner, reducing response time for outages.

4. 4

   Scalable fleet management

   A provider can use a single delegate key across hundreds of customer nodes, enabling centralized management from a single dashboard.

How Delegation Works

Delegation is implemented at the blockchain level using P2SH (Pay-to-Script-Hash) technology. Delegate authorization is encoded directly into FluxNode start/update transactions, making it a first-class protocol feature rather than an application-layer hack.

What Delegates Can and Cannot Do

Setup: Node Owner's Perspective

The node owner assigns delegates when starting or updating their node. This can be done via the Flux daemon RPC commands or through the Zelcore/SSP wallet interface.

1. 1

   Ensure fluxd v9.0.0+

   Verify your Flux daemon is updated to v9.0.0 or later. ArcaneOS nodes receive this update automatically.

2. 2

   Obtain delegate public keys

   Your hosting provider will give you their delegate public key (a 66-character hex string). You can assign up to 4 delegate keys.

3. 3

   Start node with delegates

   Use the startfluxnodewithdelegates RPC command, providing your collateral details and an array of delegate public keys.

4. 4

   Verify delegation

   After the transaction confirms, the delegate(s) can now manage the node without your private key.

# Start a FluxNode with delegates assigned
# Parameters: collateral_txhash, output_index, [delegate_pubkeys], lock_wallet
flux-cli startfluxnodewithdelegates \
  "your_collateral_txhash" \
  0 \
  '["delegate_pubkey_1", "delegate_pubkey_2"]' \
  true

# For P2SH (multisig) nodes, include delegates in the start transaction
flux-cli createp2shstarttx \
  "redeem_script" \
  "collateral_txid" \
  0 \
  "vps_pubkey" \
  '["delegate_pubkey_1"]'

Setup: Hosting Provider's Perspective

As a hosting provider, you generate a delegate key pair and share the public key with your customers. You keep the private key secure in your management system.

1. 1

   Generate a delegate key pair

   SSH into any running Flux node and run flux-cli createdelegatekeypair. This returns a compressed public key (66 hex characters) and a private key. Alternatively, use SSP Wallet in "Node Management Provider" mode to generate one through the UI. You can use a single key pair for all managed nodes or separate keys per customer group.

2. 2

   Share the public key with customers

   Provide your delegate public key to node owners. They will add it as a delegate when starting or updating their node.

3. 3

   Import the delegate key into your manager

   Import the delegate private key into your node management dashboard or wallet. This allows you to sign restart transactions.

4. 4

   Restart nodes as needed

   When a customer's node goes offline, use the startfluxnodeasdelegate or startp2shasdelegate RPC command to restart it.

# Run on any Flux node with fluxd v9.0.0+
flux-cli createdelegatekeypair

# Output:
# {
#   "pubKey": "02abc123...def456",   ← share this with customers
#   "privKey": "Kx..."               ← keep this SECRET, import into your manager
# }

# Restart a standard FluxNode as a delegate
# Parameters: collateral_txhash, output_index, delegate_privkey, vps_pubkey
flux-cli startfluxnodeasdelegate \
  "customer_collateral_txhash" \
  0 \
  "your_delegate_privkey" \
  "vps_pubkey_of_server"

# Restart a P2SH (multisig) FluxNode as a delegate
# Parameters: redeem_script, collateral_txid, output_index, delegate_privkey, vps_pubkey
flux-cli startp2shasdelegate \
  "redeem_script" \
  "customer_collateral_txid" \
  0 \
  "your_delegate_privkey" \
  "vps_pubkey_of_server"

RPC Commands Reference

VPS Public Key Separation

The PoUW v2 delegation system separates the delegate key from the VPS public key. These are two independent cryptographic identities:

• •Delegate key: Proves you are authorized to manage the node. This is the key the provider holds.
• •VPS public key: Proves which physical server the node runs on. This is tied to the actual hardware.
• •Even if a delegate key is compromised, an attacker cannot impersonate the VPS because the VPS key is separate and stored on the server itself.

Node Management Dashboard

The new node management system (available in Zelcore and SSP wallets) includes a dedicated Node Management Provider mode. This mode is designed for users who "do not own any nodes but manage them for others". Features include:

• •Fleet overview: Track status and uptime of all delegated nodes from a single dashboard
• •Tiered notifications: Assign different alert settings to groups of nodes (by tier, customer, or region) and route to specific email addresses
• •Daily reports: Scheduled daily performance reports, configurable by time zone
• •Automatic retooling: The system supports automatic node retooling in the event of an outage, reducing manual intervention

Security Considerations

1. 1

   Collateral is always safe

   The collateral private key never needs to leave the owner's wallet after initial setup. Delegates cannot access or move funds.

2. 2

   No permission escalation

   Delegates cannot modify the delegate list. Only the collateral owner can add or remove delegates, preventing escalation attacks.

3. 3

   Compromised delegate key has limited blast radius

   If a delegate key is compromised, the attacker can only restart nodes — they cannot steal funds, change configuration, or modify other delegates.

4. 4

   VPS key separation

   The VPS verification key is independent from the delegate key. Compromising one does not compromise the other.

5. 5

   Compressed keys only

   The system requires compressed public key format (33 bytes), preventing weak key attacks. Duplicate keys are rejected.

6. 6

   Feature is optional

   Node operators who prefer the traditional method can continue as before. Delegation is entirely opt-in.

Best Practices for Providers

• •Use separate delegate keys per customer segment: If managing different tiers or customer groups, consider using different delegate keys for isolation.
• •Rotate delegate keys periodically: For high-security environments, rotate delegate keys and have customers update their delegation.
• •Store delegate private keys securely: Use HSMs (Hardware Security Modules) or encrypted key stores for production environments.
• •Document the process for customers: Provide clear instructions on how to add your delegate key when setting up their node.
• •Monitor proactively: Combine delegation with monitoring to automatically detect and restart offline nodes before customers notice.

Integration with Titan Nodes

For users who prefer a fully managed experience without running their own hardware, Titan Nodes offer a delegation-like staking model. Users stake 50–10,000 FLUX in enterprise-grade nodes managed by InFlux Technologies Limited. This is a complementary option — delegation is for providers managing customer-owned nodes, while Titan Nodes are for passive stakers.