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

# Security

> Place, store, rotate, and report ThorNode credentials without exposing them.

Treat every ThorNode token, route credential, replay key, and credential-bearing endpoint URL as a secret. Keep each secret on a trusted server, place it only where that product expects it, and track every consumer so you can rotate it safely.

Wallet private keys and seed phrases are never ThorNode support credentials. Never share them with ThorNode or anyone claiming to troubleshoot your access.

## Credential scope and placement

| Product                    | Scope                                                                                | Required placement                                                                                         |
| -------------------------- | ------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------- |
| ThorEdge RPC and WebSocket | Selected access, network, and location                                               | Use the complete URL copied from that location's dashboard view. The URL carries or resolves to the token. |
| Yellowstone gRPC           | Selected access and location                                                         | Attach the token as `x-token` request metadata; never append it to the dial target.                        |
| Pulse Decoded Shreds       | Selected access and location                                                         | Send the token in the first Pulse client control message; never append it to the target.                   |
| Bifrost Transaction Routes | The dashboard issues one Private TX key per access for its enabled Bifrost locations | Use the complete HTTPS route URL copied for the selected location and operation.                           |
| Replay                     | Selected access                                                                      | Use the dedicated replay key for ShredReplay jobs only.                                                    |
| Raw Shred Stream           | Dashboard registration                                                               | UDP packets do not carry a customer credential; the dashboard authorizes the receiver registration.        |

Do not move a credential into a URL, header, query parameter, or control message unless the product row requires it. Copy location-bound targets and credentials together; see [Locations](/reference/locations#apply-location-scope-correctly) when moving a workload.

## Store secrets outside code

Inject production values through a secret manager or deployment environment. A committed `.env.example` should contain placeholders only:

```dotenv theme={null}
THORNODE_RPC_URL=<complete-url-copied-from-dashboard>
THORNODE_YELLOWSTONE_TARGET=<target-copied-from-dashboard>
THORNODE_YELLOWSTONE_TOKEN=<location-token>
PULSE_TARGET=<host:port-copied-from-dashboard>
PULSE_TOKEN=<location-token>
BIFROST_ROUTE_URL=<complete-route-url-copied-from-dashboard>
SHREDREPLAY_KEY=<replay-key>
```

Exclude real `.env` files, secret-manager exports, wallet files, and generated production configuration from version control.

<Warning>
  Removing a committed secret in a later commit does not remove it from Git
  history. Rotate the exposed credential first, then use your repository
  provider's history-remediation procedure.
</Warning>

## Keep complete URLs private

ThorEdge supplies complete URLs containing authentication material. A copied Bifrost route URL also contains the Private TX key. Use these values exactly as provided, but redact the **entire URL** anywhere an untrusted party could see it, including:

* Browser and mobile application bundles
* Repositories, issues, CI output, and build artifacts
* Logs, traces, analytics, and crash reports
* Screenshots, recordings, and support messages
* Shared shell history, process listings, and command output
* Browser navigation that could emit a referrer header

For diagnostics, keep only the product, location, time, status code, and hostname when the hostname itself contains no credential. Redact credential paths as well as query parameters.

## Verify transport and network controls

* Prefer the `https://` and `wss://` targets supplied by the dashboard.
* Yellowstone currently uses plaintext gRPC. Keep the token in `x-token` metadata and carry the connection through a trusted private network, VPN, or encrypted tunnel.
* Official Pulse clients validate the certificate chain and target hostname by default. Keep verification enabled, use the dashboard hostname, and add a private CA explicitly when your environment requires one.
* Bifrost route URLs must use `https://` and reject requests with a missing or invalid Private TX key. ThorNode manages the upstream provider credential; do not add or expose a provider API key.
* Keep public hostnames intact; substituting a resolved IP can break TLS validation and routing.
* Restrict a ThorEdge location token to a stable public egress IPv4 address when the dashboard offers that control.
* Restrict inbound Raw Shred Stream and Replay UDP traffic with host firewalls, cloud security groups, and trusted source ranges.

An IP restriction reduces where a token can be used; it does not make a leaked token safe. Continue to store and redact it as a secret.

## Rotate or revoke a credential

Regenerate a credential when the application still needs access but the current value may be exposed or its owner changes. Revoke it when the consumer no longer needs access. A ThorEdge regeneration or revocation invalidates the old token for that location; other location tokens are unaffected.

Plan for an immediate cutover. Old and new values may not overlap, and a previously authenticated streaming connection can remain open until it disconnects or the service closes it.

<Steps>
  <Step title="Inventory consumers">
    Identify the access, product, network, location, services, jobs, and secret
    stores that use the credential. Include long-lived streaming clients.
  </Step>

  <Step title="Prepare the replacement">
    Stage the configuration update and a minimal verification operation without
    placing the value in source code, logs, or a command transcript.
  </Step>

  <Step title="Regenerate or revoke">
    Use the credential-specific dashboard control. For Bifrost, revoke the
    Private TX key and generate a replacement, then verify the old URL is
    rejected before treating rotation as complete. For Replay, use its dedicated
    key control. Contact support when the applicable safe control is not
    available.
  </Step>

  <Step title="Deploy and verify">
    Update the secret store, restart or reload every consumer, and verify one
    authenticated operation. Restart long-lived streams so they cannot continue
    on an earlier authentication state.
  </Step>

  <Step title="Remove residual copies">
    Purge the old value from local files, CI variables, caches, logs, tickets,
    and artifacts where possible.
  </Step>
</Steps>

## Respond to suspected exposure

1. Regenerate or revoke the affected credential immediately.
2. Stop public logs, builds, pages, or artifacts from distributing it.
3. Review dashboard usage and available access logs for unexpected traffic.
4. Replace the value in every legitimate consumer and restart long-lived sessions.
5. Remove cached copies and remediate repository history where necessary.
6. Contact [ThorNode support](mailto:support@thornode.io) with the access identifier, product, location, and exposure window—never the secret.

Use the [safe support checklist](/reference/troubleshooting#contact-support-safely) when reporting an incident.

## Next steps

* [Pair targets and credentials by location](/reference/locations)
* [Verify the live capacity attached to an access](/reference/plans-and-limits)
* [Diagnose authentication and transport failures](/reference/troubleshooting)