> ## Documentation Index > Fetch the complete documentation index at: https://docs.trdrs.co/llms.txt > Use this file to discover all available pages before exploring further. # Providers > See each built-in provider, how it's signed into, and whether its market data is public or licensed to each user. A provider is a market that a venue's accounts trade through. trdrs wrote the built-in providers on this page, and anyone can write a public provider against the published provider contract. This page is the one list of the built-in providers: every other page describes a provider by its login style and its market data, and links here when you need to know which provider is which. Use this page when you need a provider's id for the `broker` parameter, how a trader signs into it, or where its market data comes from. The list grows, so read it from the API when your code needs it: [List the built-in providers](/api-reference/connect/list-the-built-in-providers-and-how-each-is-signed-into) (`GET /api/connect/providers`) returns each one with its id, its name and its login style, and it needs no key. ## The built-in providers Every built-in provider trades. The id is the value the `broker` parameter takes on the trading and account routes. Market data is public when any key can read it, and licensed to each user when it streams from each trader's own login at the provider. | Provider | Id | Login style | Market data | | - | - | - | - | | Rithmic | `rithmic` | The trader's own login and a system name | Licensed to each user | | Tastytrade | `tastytrade` | OAuth | None | | Hyperliquid | `hyperliquid` | A wallet key | Public | | Binance | `binance` | An API key | Public | | Bybit | `bybit` | An API key | Public | | trdrs paper book | `paper` | None | None | A provider with no market data of its own still trades instruments that another provider prices. The paper book, for example, prices its futures from the trader's own licensed login and its perpetuals from the public feeds. Which of these a venue can plug in as the market its accounts trade through is shown on the venue's Providers tab in the [back office](/guides/back-office). ## Each provider What follows belongs to one provider and to no other. ### Rithmic * **Login.** The trader signs in with their own Rithmic username and password, and a system name: the Rithmic system the login belongs to, usually the trader's firm. A Listed firm's tile fills its system name in, so the trader types only their login. A trader can hold several Rithmic logins, one for each system. * **Firms that choose applications.** Some firms choose which applications their traders may connect with. Today Rithmic knows of two such firms, Apex and Bulenox, and their traders can connect only once the firm enables trdrs. * **Refused logins.** A refused login looks the same whatever the cause: a wrong password, the system's agreements not yet signed, or a firm that hasn't enabled trdrs. The trader signs a system's agreements once, in R|Trader Pro. * **Market data.** Futures prices, CME data today, come only from the trader's own connected login on their firm's system, under that login's own market data subscription. trdrs serves no futures feed of its own and redistributes nothing, so a futures chart without a connected login answers `503` with `feed_requires_connection`. * **One session per login.** A trader streaming the same login on another platform at the same time can displace trdrs's feed. trdrs reconnects once, and if the session is taken again the feed parks with `feed_displaced` rather than fight for it. * **Rithmic Test.** The Rithmic Test environment, the system of Rithmic's development kit, carries no market data and can't sign in to production. The sandbox connects only a Rithmic Test login and refuses a production one with `400` "sandbox requires the sim environment", so futures can't be priced in the sandbox. * **Orders.** An order on a bare futures root, such as `ES`, goes to the one dated contract the product's rule names. ### Tastytrade * **Login.** The trader authorizes trdrs on Tastytrade's own sign-in page (OAuth), so trdrs never sees their password. * **Market data.** trdrs serves no market data from Tastytrade. ### Hyperliquid * **Login.** The trader enters a wallet address and an agent key. * **Market data.** Prices come from Hyperliquid's public feed. * **Instruments.** Its core perpetuals, such as `HYPERLIQUID:BTC`, settle in USDC. ### Binance * **Login.** The trader enters an API key and its secret. * **Market data.** Prices come from Binance's public feed. * **Account mode.** trdrs trades a Binance futures account in One-way Mode only. An account in Hedge Mode is refused as `hedge_position_mode` until the trader switches it at Binance. ### Bybit * **Login.** The trader enters an API key and its secret. * **Market data.** Prices come from Bybit's public feed. ### trdrs paper book * **Login.** None. Signing in to trdrs is the login, so an account on the paper book never asks for a second one. * **Accounts.** It holds a trader's own Demo and every account a firm issues. * **Market data.** It has no feed of its own and prices each instrument from live data. Futures, for example, are priced from the trader's own licensed login, and perpetuals from the public feeds. ## Public providers A public provider declares its own login style in its manifest. When it declares none, the venue connects it with the firm's credentials and its traders type nothing. A venue can plug one in once it passes the [provider self-check](/providers/provider-self-check). ## Next steps See how venues, groups, providers and accounts fit together. Give your traders charts from the login they already hold, with no feed to build. See what a trader sees when they sign into each login style. Build a public provider and prove it follows the contract.