> ## 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. # Access model > Understand how Discord identity, registered wallets, passes, rentals, locations, and credentials determine application access. Use the access model to identify which dashboard object grants a product and which credential your application should use. | Layer | What it does | Where you see it | | --------------------------- | -------------------------------------------------------- | ------------------------------------------------------- | | Discord account | Identifies your dashboard account | **Login with Discord** and **Overview** | | Registered wallet | Proves control of a Solana address with a signed message | **Wallets** | | Access source | Grants products for an owned pass or an active rental | **Your passes**, **Your rentals**, and access selectors | | Location token | Authenticates an access on one network and location | **Endpoints** sidebar, **Endpoints** tab | | Product key or registration | Authorizes a product-specific workflow | The product's area under **Endpoints** | The application credential is the final layer. A wallet address or wallet signature is never an API token. ## Discord is the account identity You enter the dashboard with **Login with Discord**. Passes, rentals, registered wallets, and dashboard activity are associated with that account. If an expected access is missing, first confirm that you used the intended Discord account. Signing in with another Discord identity creates a different dashboard context even if the same browser is used. ## Wallets prove address control Registering a wallet requires a signed verification message. The signature proves control of the public address; it does not transfer assets or reveal the private key. You can register up to three wallets per dashboard account. The dashboard uses registered wallets to: * Discover eligible passes held by those addresses * Confirm that a connected payment wallet belongs to the dashboard account * Pay through **Rent** or renew an eligible owned pass Register the wallet in [Wallets](/dashboard/wallets) before paying through **Rent** or **Renew**. ## Passes and rentals grant access An **owned pass** is an eligible NFT held by a registered wallet. An **active rental** grants time-limited access without transferring an NFT. Passes and rentals can both provide RPC location tokens. Select an access to see its products and locations. Their lifecycle differs: | Access source | Starts from | Ends or extends through | | ------------- | ------------------------------------------------------- | ------------------------------------------------------------------------ | | Owned pass | Eligible ownership detected through a registered wallet | **Renew** when the pass is eligible | | Rental | A completed rental checkout | The displayed expiration or continuation option; never through **Renew** | Select a pass or rental to see the products and locations enabled for it. ## Location tokens authenticate applications For RPC and WebSocket access, a token belongs to one access source, network, and location. Open **Endpoints**, keep the **Endpoints** tab selected, then copy the complete URL supplied for the selected location. Location tokens have independent lifecycles: * Generating or rotating one location does not change another location's token. * Revoking one location token does not delete the underlying pass or rental. * An optional IP restriction accepts one IPv4 value and applies to that token's RPC and WebSocket traffic. Use the server's real, globally routable public egress address and test the request after saving it. This boundary lets you rotate one deployment without interrupting another location. ## Product-specific access can differ Not every product uses the RPC URL. Yellowstone gRPC and Pulse appear in the **Streaming** section of **Endpoints** and use location tokens with their own transports. Raw Shred Stream registers your UDP receiver, Replay uses a dedicated per-access key, and Bifrost generates one Private TX key per access and places it in the route URLs copied from enabled locations. ThorNode manages the upstream Bifrost provider credentials. [Choose a product](/getting-started/choose-a-product) before creating a credential so that you use the correct transport and authentication placement. ## Apply the credential lifecycle | Action | Use it when | Result | | ---------- | ---------------------------------------------------------------- | ------------------------------------------------------------------------ | | Create | A deployment needs access in a location | **Token & Endpoints** shows the masked token and connection details | | Restrict | The deployment has one stable public egress IPv4 | Requests from other public addresses stop authenticating with that token | | Regenerate | The application still needs access but the secret may be exposed | The previous token stops working and the panel supplies a replacement | | Revoke | The deployment no longer needs the credential | The location returns to **No token yet** | Keep credentials in a server-side secret manager. See [Security](/reference/security) for storage, redaction, and exposure response. ## Next steps * [Create and test a location token](/dashboard/endpoints). * [Register or remove a wallet](/dashboard/wallets). * [Read current traffic and capacity](/dashboard/usage-and-limits).