> ## Documentation Index > Fetch the complete documentation index at: https://docs.li.fi/llms.txt > Use this file to discover all available pages before exploring further. # Concepts > The create, authorize, execute pattern behind every mutating call, who signs what, and where venue credentials are stored. Three ideas explain most of the SDK's behaviour: every mutating operation is a three-stage pipeline, authorization is split between the user and the SDK, and each venue's credentials live behind a storage adapter you can replace. ## Create, authorize, execute Orders, cancellations, setup, and withdrawals all run the same pipeline. You send the venue, the account, the action type, and its parameters. The backend returns an array of steps. One call can return more than one: raising leverage before an order arrives as two steps, in order. Each step carries exactly one authorization payload, selected by the step's signing method. Either the user's wallet signs it or the SDK signs it with the credential it holds for that account. Signed steps go back and the response returns one result per step. Success carries the venue's identifiers; failure carries an error and often a structured code. The step variants differ by what has to be produced to authorize them: | Step carries | Authorized by | | ---------------------- | ------------------------------------------------------------ | | Typed data | An EIP-712 signature | | A signing blob | The venue's own signer | | Transaction parameters | A wallet-submitted transaction | | A request | A signature computed over the exact request bytes | | A sign-in challenge | A personal-sign challenge on the user's address | | A session request | The provider plugin, client-side, with no execute round trip | That last one is the exception to the pattern. A session step never goes to execute, because the plugin completes it directly. Do not infer a credential type from the venue name. The SDK and the registered plugin decide how a step is authorized, and a venue can return different step variants for different actions. Branch on the step, not on the venue. ## Who signs Every action declares who authorizes it, and there are two answers. **The user** authorizes anything that grants a capability or moves money out: approving the agent, depositing, signing in, and withdrawals on some venues. These invoke the wallet. **The SDK** authorizes trading, using the credential it owns for that account on that venue. This is why order flow has no wallet popup. The credential was granted once, during setup, by a user action that did. Some actions list both, because the protocol needs a contribution from each. The high-level trading methods handle the SDK-signed half without being asked, and setup is coordinated end to end by a single call rather than by you scripting each venue's scheme. ## Where credentials live Each venue's plugin persists its own trading credentials through a storage adapter, and the adapter is replaceable. The default targets the browser. Values are encrypted before they are written to local storage, and the key that encrypts them is held as a non-extractable handle in the browser's own key store rather than as a value the page can read back. An environment missing either of those primitives falls back to a session that does not persist, rather than writing the credential out in the clear. Pass your own adapter to a provider's store to keep credentials somewhere else. That is the supported path for server-side or native integrations, where the browser default does not apply. The practical consequence is that a user who clears site data is a user who has to run setup again. That is a supportable outcome, but it is one your interface should recognize rather than surfacing as a trading error. ## Streaming Market and account updates arrive over WebSocket connections made to the venue itself rather than proxied. You register a streaming provider per venue, and subscribing returns the function that tears the subscription down. Multiple listeners on one channel share a single wire subscription, so components can subscribe independently without opening a connection each. Each venue has its own native protocol and its own rate limits underneath, which the plugin maps onto the common channel names. ## Failure Results come back one per step, which means a multi-step action can partially succeed. An order preceded by a leverage change can leave the leverage applied and the order rejected, and treating the whole call as failed would misreport that. Structured error codes are the thing to branch on. A plugin can also react to results before a failure reaches you, which is how a credential the venue has stopped accepting gets evicted locally instead of failing every subsequent order the same way. ## Next steps How each venue implements setup, signing, and withdrawals. The pipeline above, as running code. The full code list and what each one means. Parameters and return shapes for every method.