Wallets and Balances

A member's wallet is their on-chain account. XKOVA provisions the current Thirdweb MPC wallet from the exact tenant and account-holder identity, independently of Hosted Auth, FI OIDC, Quick Demo, API, or another approved creation channel. XKOVA never receives or exports the MPC private-key material.

Member in-app wallets

Each account holder resolves to one canonical Thirdweb custom-JWT subject and MPC wallet. The subject is derived from the XKOVA tenant and account-holder records, not from an email address or the authentication provider. The wallet holds balances and produces the member's transfer signatures. Thirdweb keeps MPC private-key material non-exportable, so XKOVA and the integrator do not receive it.

A valid XKOVA custom JWT plus the public Thirdweb client can establish a general provider signing session for the canonical wallet. It is not limited by Thirdweb to one XKOVA payment. XKOVA therefore issues a fresh 60-second bootstrap only after purpose authorization, uses memory-only browser storage, verifies the exact frozen payload and signer, and disposes the provider session immediately. See Non-custodial Model and Wallet Providers.

How a wallet is provisioned

A wallet is provisioned through XKOVA's durable wallet lifecycle. A successful member binding creates or wakes one canonical provisioning job for that account holder. The steps are:

Bind. XKOVA derives the provider identity from the verified account-holder binding.
Provision. A durable coordinator creates or resolves the provider wallet and records the canonical public address.
Reconcile. Retries and sign-ins resume the same job until monitoring and wallet readiness are complete.

The browser can send a bodyless wake request for its own signed-in member, but it cannot select an account holder, provider identity, address, chain, wallet, credential, or registration proof. The same verified member resolves to the same provider wallet. MPC private-key material never enters XKOVA, and ordinary provisioning does not grant browser signing authority.

Balances

A balance is the member's holding of an asset from the automatic workspace catalog, maintained as a running total that XKOVA updates as it observes the wallet's on-chain activity and keeps in sync with the chain through continuous reconciliation (rather than fetching a live chain read on every request). A member can have a wallet on each applicable active chain and can hold the active external and workspace-issued assets indexed there. Each balance entry carries a numeric chain_id that identifies the chain it lives on (one of the chains described in Supported Networks); the full embedded chain descriptor is carried on the wallet resource, not on individual balance rows.

The account holder behind the wallet

Every member wallet hangs off an account holder: the member record your backend provisions, either explicitly or just in time on the member's first sign in. The record carries far more than the wallet: self-service balances and bank sub-accounts, a contacts address book, policy consents, a right-to-access data export, an avatar, and the compliance hold and release actions. See Account Holders for the full surface.

What a wallet is used for

Signing transfers. The member signs payment and escrow intents in their wallet, and the XKOVA Relayer submits them. See Payments and Escrow and Claims.
Holding assets. The wallet holds the member's stablecoin balance and any tokens issued to it through XKOVA TAMS.

See Wallet Providers for the current Thirdweb MPC trust boundary and the provider abstraction, and the interactive reference for wallet readiness, bodyless provisioning, listing, and balance operations.

Was this helpful?