> ## Documentation Index
> Fetch the complete documentation index at: https://docs.utexo.com/llms.txt
> Use this file to discover all available pages before exploring further.

# RLN Remote Signer

> How Validating Lightning Signer (VLS) keeps private keys off your RGB Lightning Node.

## Overview

Validating Lightning Signer (VLS) is an open-source Rust library for secure, self-custodial Lightning signers. Unlike hot wallets or blind signers, VLS keeps your private keys off the node and validates each signing request, ensuring only legitimate channel operations are approved.

<Note>
  RGB Lightning Node includes generic remote external-signer support introduced in [UTEXO-Protocol/rgb-lightning-node#95](https://github.com/UTEXO-Protocol/rgb-lightning-node/commit/e8aa52e838ad523962e81196c137d6a7b4d45980). The VLS-specific integration described on this page remains tracked in [RGB-Tools/rgb-lightning-node#43](https://github.com/RGB-Tools/rgb-lightning-node/issues/43) and should still be considered experimental until its compatibility and production-readiness are confirmed.
</Note>

## System Architecture

VLS splits Lightning key management into two primary components:

### Lightning Node

Runs the standard LN logic — channel opening, routing, HTLC management. **No private keys are stored here.**

### Remote Validating Signer

Stores private keys in a secure environment and validates each request before generating a signature. If the request fails policy checks, it denies signing.

### Additional Components

| Component                  | Description                                                   |
| -------------------------- | ------------------------------------------------------------- |
| **Policy Engine**          | Customizable rules ensuring no suspicious requests are signed |
| **UTXO Oracle** (optional) | Provides chain data to detect remote breaches                 |
| **State Storage**          | Secure cloud storage with anti-rollback protection            |

## Validation Flow

```text theme={null}
[Lightning Node] --> proposes transaction/state update
        |
        v
[VLS Signer] --> checks protocol correctness + local policy
        |
        +-- valid --> returns signature
        |
        +-- invalid --> rejects request
```

1. The Lightning Node proposes a transaction or state update.
2. VLS checks protocol correctness and local policy.
3. If valid, the signer returns a signature. Otherwise, it rejects the request.

## Why This Matters

Traditional Lightning nodes require private keys to be on the same machine that handles routing and channel logic. VLS decouples these concerns:

* **Reduced attack surface** — a compromised node cannot access signing keys
* **Policy enforcement** — custom rules prevent unauthorized channel operations
* **Self-custody** — keys never leave the secure signing environment