Server diagrams
These diagrams give a visual overview of how WalletAPIServer brokers communication between a Live App and a wallet. Read them alongside the server reference and the RpcNode reference.
The diagrams come from this introductory slideshow and have been adapted to be readable on their own.
1. Direct wallet–app interaction
Without a JSON-RPC layer, every Live App and every wallet would need ad-hoc message contracts. The Wallet API exists to replace this with a structured, capability-based bridge.
2. Processing requests with requestHandlers
When the Live App sends a request, the server looks up requestHandlers by method ID, runs the matching handler with the parsed parameters and walletContext, then writes the result back to the transport.
3. Asking the wallet for data or actions with walletHandlers
Most request handlers cannot fulfil a request alone: they need wallet-side capabilities such as prompting the user, signing, or reading accounts. They delegate to walletHandlers, which the wallet implements.
4. Bidirectional transport
The transport carries strings in both directions: the Live App’s send becomes the server’s onMessage, and vice versa. The transport itself is implementation-specific (postMessage, WebSocket, IPC).
5. Data and permissions flowing into walletContext
The wallet pushes accounts, currencies, configuration, and permissions into the server using the matching setters. The server combines them into walletContext, the read-only view that request handlers consume. Permissions filter both what handlers a Live App can call and what currencies and accounts they can see.
See also
- Server reference: full list of properties, methods, and the constructor signature.
- RpcNode: the abstract class that handles JSON-RPC framing and error translation.
- Server slideshow: the original Excalidraw deck.
