Website integration

The public website integration SDK and installation instructions are TBD. This guide explains the wallet's connection and approval model so applications can plan their integration. Current payments use the local simulator; live Joltzu payment submission remains integration work.

Connection and spending flow

1. Ask the wallet for its advertised capabilities.
2. Request a connection and wait for the user's approval in the side panel.
3. Request a spending grant separately, showing its recipient, asset, operation, fee limits, budgets and expiry.
4. Prepare a payment within those limits, with a unique nonce and expiry.
5. Track the request until it is approved, rejected or expired.

A connection grants account access, not spending permission. A permitted payment must still fit its grant's remaining limits. See connections, grants and approvals.

Handle asynchronous results

Requests can be pending, approved, rejected or expired. Simulator receipt IDs begin sim: and are not transaction hashes. The simulator uses six decimal test units; native JOLT uses 18 decimals.

Stopping a wait does not cancel or reverse a wallet request. Preserve the request ID and inspect its status before retrying. Used nonces cannot be reused. Page response messages are transport results, not cryptographic evidence of ledger settlement.

The current spending profile rejects arbitrary signing, ERC-20 approvals and EVM calldata. Live orderbook execution remains unavailable. A mobile app link or QR string alone is not an authenticated bridge.

For contracts and native transactions, use the public cpp-node integration guides. Wallet integration examples will be added with the released SDK.