The active captcha provider and site key to hand the captcha widget — returned by getCaptchaSettings; null overall means captcha is not enabled. provider is one of 'hcaptcha' | 'cloudflareTurnstile'.
One chain's embedded-wallet config. name is a short code ('EVM', 'SOL', 'BTC'...), NOT a verifiedCredential chain name ('eip155', 'solana'...) — those are a different wire vocabulary entirely.
P-256 device key for signed-nonce request authentication. Backed by Secure Enclave / Android Keystore / platform crypto; raw key material never leaves the host.
WalletSigner provided by a wallet the user already has (MetaMask, ...), which signs under its own UI. Implemented by ExternalWalletExtension. Adds no methods to WalletSigner, for the same reason as EmbeddedWalletSigner.
One HTTP response, unparsed. A non-2xx status is NOT an error at this layer — the caller decides, because some hosts report failures in a 200 body (Sui GraphQL) and some in the status.
Host-injected HTTP transport. Accepts absolute URLs and adds no headers. Only ApiClient supplies Dynamic credentials; flows may use this service for public endpoints only.
One network's configuration, within a NetworkChainConfiguration group — either read from the dashboard (getNetworksData) or host-registered (e.g. getEvmHostNetworks, built from a UseEvm EvmNetwork). iconUrls/nativeCurrency/blockExplorerUrls are optional even though the upstream wire schema always populates them for a dashboard entry: a host-registered one has no such guarantee (EvmNetwork carries only chainId/rpcUrl/name), and a wrong guess (e.g. assuming ETH as every EVM chain's native currency, which is false for many L2s) is worse than an absent field — see each field's own doc for which entries actually populate it.
The authentication ceremony's response sub-object. clientDataJson is this DSL's OWN consistent internal name for the field — see this file's header doc for the register-vs-signin wire-casing asymmetry this deliberately sidesteps.
The registration ceremony's response sub-object. clientDataJson is this DSL's OWN consistent internal name for the field — see this file's header doc for the register-vs-signin wire-casing asymmetry this deliberately sidesteps.
Credential to exclude during registration or allow during authentication. The server omits type in allowCredentials; flows add public-key before the platform ceremony.
Runs platform WebAuthn ceremonies. Takes full options and returns full results as JSON strings. Cancellation must throw a distinct error, not resolve normally or use the generic ceremony-failure error.
The relying party (this app/environment) a passkey is scoped to. id is the domain the OS's Associated Domains / Digital Asset Links config must match — never the app's own name.
The account a NEW passkey is being registered for (creation options only — there is no equivalent on sign-in/auth options, since the whole point of allowCredentials there is that the user hasn't been identified yet).
Deliberately narrow subset of dynamic-labs sdk-api-core's FeatureFlags — only the one flag isExternalWalletScreeningEnabled reads. Add fields here as this DSL needs to read more of them.
P-256 session key, distinct from the device key. Signs privileged payloads; its public key binds API requests to the session through x-dyn-session-public-key. Rotates at sign-out.
A Solana cluster target the extension can talk to: JSON-RPC endpoint, display name, and the cluster moniker (mainnet-beta / devnet / testnet) used for explorer links.
Hot state stream backing a <field>Changed getter: a new listener
immediately receives the current value, then every update. Dependency-free
mirror of the flutter-sdk BehaviorSubject.seeded store.
A loaded Horizon account: sequence number (for building a transaction) and native XLM balance. Non-native asset balances are not modeled — checkTrustline reads them off the real platform SDK response StellarExtension already holds.
Horizon reads and XDR transaction building/submission for a single Stellar network. Implemented by a concrete SDK per platform; StellarExtension is constructed with one and never talks to Horizon directly.
Broadcasts a signed transaction. Response: data.executeTransaction — errors is a non-empty list when the node rejected it, otherwise effects.transaction.digest is the landed digest.
executeTransaction's variables. Both are BASE64, not hex: bcs is the serialized TransactionData and sigs the SerializedSignatures over it (flag || sig || pubkey — 97 bytes for ed25519).
A coin object that covers a transaction, with its balance parsed to a number so the largest can be picked. Never wire data — assembled from a getCoins response.
The coin objects an address owns, for gas-payment selection. Response: data.address.objects.nodes[] with address/version/digest and contents.json.balance.
A page of owned objects. Not paginated by this SDK: one gas coin has to cover the transfer, so the first page is either enough or the caller has to consolidate coins.
Whether a transaction landed. Response: data.transactionEffects — absent means the node has never seen the digest, status is SUCCESS or a failure, and executionError.message carries why.
Embedded-wallet MPC engine owned by WaasExtension. initialize must reuse the engine for the same authToken across all chains and rebuild it when the session changes. The reference implementation uses a hidden waas-v1 WebView.
One key share's backup metadata, as carried in VerifiedCredential.walletProperties.keyShares (dynamic-labs sdk-api-core's WalletKeyShareInfo). Deliberately narrow: only backupLocation is modeled — id/passwordEncrypted/walletShareDeveloperKeyEncrypted/externalKeyShareId/keygenId are out of scope, nothing here reads them yet.
One of a WaaS wallet's active MPC share sets — its own (VerifiedCredential.walletProperties.shareSetId/shareSetType) or another auth principal's (walletProperties.otherShareSets). shareSetType is one of 'rootUser' | 'delegated' | 'server' | 'businessAccountUser' | 'offlineRecovery' — server-defined string, not modeled as an enum here (see VerifiedCredential.format's own convention).
Deliberately narrow subset of dynamic-labs sdk-api-core's WalletProperties — only the fields hasDelegatedAccess/getWalletAccountShareSets (waas.flows.ts) actually read. Excludes every non-WaaS wallet-provider variant's fields (the turnkey-prefixed fields, hardwareWallet, coinbase-mpc, ...) and the WaaS-only fields nothing here reads yet (version/settings/derivationPath/isAuthenticatorAttached/...).
An additional address associated with a wallet (dynamic-labs sdk-api-core's WalletAdditionalAddress) — e.g. a chain that exposes more than one address format per key (BTC: legacy/segwit/taproot) or per network (mainnet/testnet). Carries the public key for that address, which VerifiedCredential itself does NOT — this is the only place a wallet's public key is available after the fact (WaasCreatedWallet's own publicKeyHex, from createWallet's result, only exists transiently at creation time and is never persisted). Confirmed against dynamic-js-sdk's getPublicKeyForWalletAccount, which reads exactly this field to build a BTC PSBT.
Combines server primary-wallet selection with reactive client chain and network state.
Instances share the root client's state. NOTE: not yet thread-safe.
items ordered by the keys keys return, each ascending, the second only
deciding ties in the first. A new list — a generated sortBy never sorts in
place.
