@upbond/sdk
    Preparing search index...

    Interface UpbondState

    The full observable client state, delivered synchronously via UpbondClient.state and to subscribe listeners on every change.

    interface UpbondState {
        auth: AuthStatus;
        derivedAddresses: DerivedAddresses | null;
        phase: ProgressPhase;
        suiAccount: SuiAccount | null;
        user: IdTokenClaims | null;
        wallet: WalletStatus;
        walletAddress: string | null;
        walletPublicKey: string | null;
        wallets: WalletRef[];
    }
    Index

    OIDC session status.

    derivedAddresses: DerivedAddresses | null

    EVM + Sui addresses computed offline from walletPublicKey (see addressesFromPublicKey), or null when the claim is absent or malformed — or when the client is in redirect mode (see walletPublicKey). Like walletPublicKey, expect null today — no issuer flow supplies the claim (docs/34 rejected). Prefer walletAddress when it is set — it is the bound value and wins over the derived one.

    The operation currently in progress.

    suiAccount: SuiAccount | null

    The Sui-on-secp256k1 account (docs/00-BUILD-SPEC.md §3, issue #205 Option C), derived from the SAME MPC key as walletAddress. Unlike the EVM address there is no issuer claim for it, so it is null until the session's first Layer 2 ceremony (unlock/setup/recovery/signing) — the capture piggybacks on that ceremony and never consumes an extra biometric. Hosts that want it earlier call getSuiAccount().

    user: IdTokenClaims | null

    Decoded id_token claims while signed in, otherwise null.

    wallet: WalletStatus

    Wallet-leg status.

    walletAddress: string | null

    The wallet address once known (after connect/unlock), otherwise null.

    walletPublicKey: string | null

    The wallet's secp256k1 public key from the wallet_public_key claim (compressed SEC1 hex), or null when the claim is absent. No issuer flow populates the claim today: issuer-side pre-derivation was rejected (docs/34, 2026-08-20) because the final TSS key includes ceremony-time client randomness — expect null until a ceremony-side flow supplies it.

    The claim would describe the key under the ISSUER's default verifier (the embedded widget's wallet). A redirect-mode client runs its own verifier / network, whose ceremony key may differ, so this is null whenever wallet (redirect-mode MPC config) is set — a wrong deposit address is a permanent loss. Such a host reads the raw claim from user.wallet_public_key only if it knows its verifier is the default.

    wallets: WalletRef[]

    The user's wallet list (multi-wallet foundation, docs/28). Derived from the wallet_accounts claim — present as soon as the user is signed in, before any wallet connect — with the ceremony-learned address as the fallback for a brand-new wallet whose token predates the binding. Today at most one entry (kind: 'mpc'), the default entry, whose address walletAddress reports once the wallet leg is connected.