import { P as PasskeyProviderConfig, S as SponsorshipConfig, T as ThemeConfig, ab as GetAssetsOptions, ae as AssetsResponse, z as AuthWithModalOptions, A as AuthResult, L as LoginWithModalOptions, B as CreateAccountWithModalOptions, D as ConnectResult, ah as CheckConsentOptions, ai as CheckConsentResult, aj as RequestConsentOptions, ak as RequestConsentResult, al as GrantPermissionsOptions, am as GrantPermissionsResult, an as ListSessionGrantsOptions, ao as ListSessionGrantsResult, F as AuthenticateOptions, G as AuthenticateResult, q as SigningRequestOptions, r as SigningResult, a2 as SendIntentOptions, j as SendIntentResult, au as SendBatchIntentOptions, av as SendBatchIntentResult, a8 as IntentHistoryOptions, aa as IntentHistoryResult, K as SignMessageOptions, M as SignMessageResult, N as SignTypedDataOptions, O as SignTypedDataResult, E as EmbedOptions } from './types-BN6cCuAd.js';

declare class OneAuthClient {
    private config;
    private theme;
    private sponsorship;
    private eoaDialogState;
    private prewarmState;
    private eoaSerialQueue;
    /** Clear the default cache plus every provider bound to this client. */
    private forgetApplicationSessions;
    /** Forget embedder-side sessions from any trusted dialog transport. */
    private installDisconnectListener;
    /**
     * Create a new OneAuthClient.
     *
     * Normalizes the config (filling in default URLs), then immediately injects
     * `<link rel="preconnect">` tags for the passkey domain so that DNS lookup
     * and TLS handshake start before the first dialog is opened, shaving
     * noticeable latency from the first user interaction.
     *
     * @param config - Client configuration including optional providerUrl, dialogUrl,
     *   clientId, theme, and redirect settings.
     */
    constructor(config: PasskeyProviderConfig);
    /**
     * Update the sponsorship configuration at runtime. Pass `undefined` to
     * disable sponsorship.
     */
    setSponsorship(sponsorship: SponsorshipConfig | undefined): void;
    /**
     * Whether the caller opted into SDK telemetry propagation or callbacks.
     */
    private shouldUseTelemetry;
    /**
     * Resolve the host app's current trace context. Callback failures are
     * ignored because observability can never be allowed to break signing.
     */
    private getTelemetryTraceContext;
    /**
     * Resolve host-provided SDK event attributes and remove undefined fields.
     */
    private getTelemetryAttributes;
    /**
     * Create per-operation telemetry context shared by callbacks, HTTP headers,
     * dialog URL params, and PASSKEY_INIT messages.
     */
    private createTelemetryOperation;
    /**
     * Emit a telemetry event to the host app. The callback is intentionally
     * fire-and-forget and exception-safe so app telemetry cannot affect users.
     */
    private emitTelemetry;
    /**
     * Attach SDK correlation and optional W3C trace context to dialog URLs.
     */
    private appendTelemetryParams;
    /**
     * Add SDK correlation headers to passkey API calls. These headers are also
     * valid W3C trace propagation inputs when the host app supplies traceparent.
     */
    private telemetryHeaders;
    /**
     * Embed telemetry context in PASSKEY_INIT payloads for dialog-side API calls.
     */
    private telemetryPayload;
    /** Resolve the public funding policy while preserving the legacy user-paid alias. */
    private resolveSponsorshipMode;
    /**
     * Determine whether this signing call should request invisible dialog mode.
     * Resolution order: per-call option wins over the constructor config, which
     * wins over the platform-wide {@link DEFAULT_BLIND_SIGNING}. This lets an app
     * flip the global default for itself while still overriding individual
     * high-risk calls.
     */
    private shouldRequestBlindSigning;
    /**
     * Fetch the app's access token (JWT). Called up front, before
     * `/api/intent/prepare`, so the passkey server can authenticate the
     * orchestrator quote call with the app's JWT instead of a service-level
     * API key.
     *
     * Does not depend on `intentOp` — can run in parallel with anything that
     * also doesn't depend on the quote.
     */
    private fetchAccessToken;
    /**
     * Fetch one extension token per canonical sponsorship intent input, aligned
     * with `sponsorFlags`. Sponsored prepare uses the same token for the final
     * quote and later submission, so route construction and execution share one
     * digest-bound authorization.
     */
    private fetchExtensionTokens;
    /**
     * Update the theme configuration at runtime
     */
    setTheme(theme: ThemeConfig): void;
    /**
     * Serialize the active theme into URL query parameters for the dialog.
     *
     * Merges the instance-level theme (set via constructor or `setTheme`) with any
     * per-call override, so callers can temporarily change the appearance for a
     * single dialog invocation without mutating shared state.
     *
     * @param overrideTheme - One-shot theme values that take precedence over the
     *   instance theme for this call only.
     * @returns A URL-encoded query string (e.g. `"theme=dark&accent=%230090ff"`),
     *   or an empty string if no theme properties are set.
     */
    private getThemeParams;
    /**
     * Resolve the URL of the dialog app (the Vite/Next.js frontend that renders
     * the WebAuthn UI inside the iframe).
     *
     * `dialogUrl` is a separate config option to support split deployments where
     * the API server and the dialog frontend run at different origins. Falls back
     * to `providerUrl` when not explicitly configured — the common case.
     *
     * @returns The base URL used when constructing all dialog endpoint paths.
     */
    private getDialogUrl;
    /**
     * Extract the trusted origin used to validate incoming postMessage events.
     *
     * All `window.addEventListener("message", ...)` handlers in this class check
     * `event.origin` against this value to prevent cross-origin spoofing. Wraps
     * `getDialogUrl()` in a `new URL()` parse so that paths and query strings are
     * stripped — only the scheme + host + port are compared.
     *
     * Falls back to the raw dialog URL string if URL parsing fails (e.g. during
     * unit tests with non-standard URL formats).
     *
     * @returns The scheme + host + optional port of the dialog app (e.g. `"https://passkey.1auth.app"`).
     */
    private getDialogOrigin;
    /**
     * Get the base provider URL
     */
    getProviderUrl(): string;
    /**
     * Get the configured client ID
     */
    getClientId(): string | undefined;
    /**
     * Whether this client operates on testnet chains only.
     */
    getTestnets(): boolean;
    /**
     * Get a unified token portfolio for a 1auth account across mainnets and
     * testnets.
     *
     * @example
     * ```typescript
     * const assets = await client.getAssets({
     *   accountAddress: "0x1111111111111111111111111111111111111111",
     * });
     * console.log(assets.mainnets.balances, assets.testnets.balances);
     * ```
     */
    getAssets(options: GetAssetsOptions): Promise<AssetsResponse>;
    /**
     * Poll the intent status endpoint until a transaction hash appears or the
     * intent reaches a terminal failure state.
     *
     * This is used after `sendIntent` resolves (with `waitForHash: true`) to
     * continue waiting for the on-chain hash even after the dialog has been
     * dismissed. It is intentionally separate from the in-dialog polling loop so
     * callers that don't need the hash can skip it entirely.
     *
     * Errors during individual poll attempts are swallowed so that transient
     * network issues don't abort the wait prematurely.
     *
     * @param intentId - The Rhinestone intent ID returned by the execute endpoint.
     * @param options.timeoutMs - Maximum wait time in milliseconds (default 120 000).
     * @param options.intervalMs - Time between polls in milliseconds (default 2 000).
     * @returns The transaction hash string, or `undefined` if the deadline was
     *   reached or the intent failed/expired before a hash was produced.
     */
    private waitForTransactionHash;
    /**
     * Open the authentication modal (sign in + sign up).
     *
     * Handles both new user registration and returning user login in a single
     * call — the modal shows the appropriate flow based on whether the user
     * has a passkey registered.
     *
     * @param options.theme - Override the theme for this modal invocation
     * @param options.oauthEnabled - Set to false to hide OAuth sign-in buttons
     * @param options.flow - Force the login or account-creation route instead
     *   of the default auto-detect entry route
     * @returns {@link AuthResult} with user details and typed address
     *
     * @example
     * ```typescript
     * const result = await client.authWithModal();
     *
     * if (result.success) {
     *   console.log('Signed in as:', result.user?.address);
     *   console.log('Address:', result.user?.address); // typed `0x${string}`
     * } else if (result.error?.code === 'USER_CANCELLED') {
     *   // User closed the modal
     * }
     * ```
     */
    authWithModal(options?: AuthWithModalOptions): Promise<AuthResult>;
    /**
     * Open the sign-in modal directly.
     *
     * This bypasses the `/dialog/auth` auto-router and targets the dedicated
     * returning-user flow. Use it when the embedding app already knows the user
     * is creating a login session, for example after an app-level "Log in"
     * button. The result intentionally matches {@link authWithModal}.
     *
     * @param options.theme - Override the theme for this modal invocation
     * @returns {@link AuthResult} with user details and typed address
     */
    loginWithModal(options?: LoginWithModalOptions): Promise<AuthResult>;
    /**
     * Open the account-creation modal directly.
     *
     * This bypasses the `/dialog/auth` auto-router and targets the dedicated
     * sign-up flow. Account creation still happens server-side in the passkey
     * service; the SDK only opens the dialog and receives the postMessage result.
     *
     * @param options.theme - Override the theme for this modal invocation
     * @param options.oauthEnabled - Set to false to hide OAuth sign-in buttons
     * @returns {@link AuthResult} with the newly authenticated account details
     */
    createAccountWithModal(options?: CreateAccountWithModalOptions): Promise<AuthResult>;
    /**
     * Open one of the passkey authentication modal routes and wait for the
     * login-result message.
     *
     * Keeping URL construction in one helper prevents the explicit login/signup
     * methods from drifting away from the legacy `authWithModal` behavior.
     */
    private openAuthModal;
    /**
     * Generate a per-dialog nonce used to correlate iframe close messages with
     * the SDK modal that opened them. Chromium can report a different
     * `MessageEvent.source` WindowProxy after the `/dialog/auth` redirect, so
     * auth close handling needs a stable in-band identifier without accepting
     * stale close messages from earlier dialogs.
     */
    private createDialogRequestId;
    /**
     * Resolve the passkey app route for a requested auth flow.
     */
    private getAuthDialogPath;
    /**
     * Open the connect dialog (lightweight connection without passkey auth).
     *
     * This method shows a simple connection confirmation dialog that doesn't
     * require a passkey signature. Users can optionally enable "auto-connect"
     * to skip this dialog in the future.
     *
     * If the user has never connected before, this will return action: "switch"
     * to indicate that the full auth modal should be opened instead.
     *
     * @example
     * ```typescript
     * const result = await client.connectWithModal();
     *
     * if (result.success) {
     *   console.log('Connected as:', result.user?.address);
     * } else if (result.action === 'switch') {
     *   // User needs to sign in first
     *   const authResult = await client.authWithModal();
     * }
     * ```
     */
    connectWithModal(options?: {
        theme?: ThemeConfig;
    }): Promise<ConnectResult>;
    /**
     * High-level connect entry point — the method most integrators want.
     *
     * Tries the lightweight {@link connectWithModal} first (no passkey ceremony
     * for returning users on the same browser), and transparently falls back to
     * {@link authWithModal} when the connect dialog reports it has no stored
     * credentials for this origin (`action: "switch"`). First-time visitors get
     * one passkey ceremony to register; subsequent connects on the same browser
     * resolve with no biometric prompt — and silently when the user has enabled
     * "Connect automatically".
     *
     * The return shape is the same {@link ConnectResult} discriminated union as
     * {@link connectWithModal}, so callers can treat both paths uniformly. When
     * the auth-modal fallback runs, its successful result is normalized into a
     * `ConnectResult` (no `id` field — the embedder origin must not see it).
     *
     * Cancellation: if the user cancels either dialog, the result is
     * `{ success: false, action: "cancel", error: { code: "USER_CANCELLED", … } }`.
     *
     * @param options - Forwarded to whichever underlying modal is shown.
     *   `oauthEnabled` only applies to the auth-modal fallback path.
     * @returns A {@link ConnectResult} discriminated union.
     *
     * @example
     * ```typescript
     * const result = await client.connect();
     * if (result.success) {
     *   console.log("Connected as", result.user?.address);
     * }
     * ```
     */
    connect(options?: {
        theme?: ThemeConfig;
        oauthEnabled?: boolean;
        /**
         * Opt into "wallet as signer" mode for the auth-modal fallback — see
         * {@link AuthWithModalOptions.eoaConnect}. Set by {@link createOneAuthConnection}.
         */
        eoaConnect?: boolean;
    }): Promise<ConnectResult>;
    /**
     * Open the account management dialog.
     *
     * Shows the account overview with guardian status and recovery setup
     * options. The dialog closes when the user clicks the X button or
     * completes their action.
     *
     * @example
     * ```typescript
     * await client.openAccountDialog();
     * ```
     */
    openAccountDialog(options?: {
        theme?: ThemeConfig;
    }): Promise<void>;
    /**
     * Open the account-recovery backup flow directly.
     *
     * Deep-links into the "Backup your account" flow inside the account dialog
     * (rather than the account overview): the user verifies with their passkey,
     * then saves a recovery passphrase and downloads an encrypted backup file.
     * Use this to prompt users to secure their account after sign-up.
     *
     * Requires an authenticated user (call `authWithModal()` / `connect()`
     * first) — the dialog reads the signed-in user from the passkey origin.
     *
     * Resolves `{ completed: true }` when the user finishes the backup, or
     * `{ completed: false }` if they dismiss it — so callers can mark an
     * onboarding step done or re-prompt later.
     */
    setupRecovery(options?: {
        theme?: ThemeConfig;
    }): Promise<{
        completed: boolean;
    }>;
    /**
     * Check if a user has already granted consent for the requested fields.
     *
     * @deprecated Data-sharing consent is disabled.
     *
     * Always returns `{ hasConsent: false }`.
     */
    checkConsent(options: CheckConsentOptions): Promise<CheckConsentResult>;
    /**
     * Request consent from the user to share their data.
     *
     * @deprecated Data-sharing consent is disabled.
     *
     * Always returns an `INVALID_REQUEST` result.
     */
    requestConsent(options: RequestConsentOptions): Promise<RequestConsentResult>;
    /**
     * Open the dedicated SmartSession permission grant dialog.
     *
     * The app owns the session key material and sends only the public
     * `sessionKeyAddress`. 1auth renders the permission review, collects the
     * owner's passkey authorization, submits the install/enable intent, and
     * returns a persistable session handle.
     */
    grantPermissions(options: GrantPermissionsOptions): Promise<GrantPermissionsResult>;
    /**
     * List SmartSession grants previously granted to the current browser origin.
     *
     * 1auth derives the app identity from the request Origin header. The SDK does
     * not send `clientId` for this lookup because grants are origin-scoped.
     */
    listSessionGrants(options: ListSessionGrantsOptions): Promise<ListSessionGrantsResult>;
    /**
     * Authenticate a user with an optional challenge to sign.
     *
     * This method combines authentication (sign in / sign up) with optional
     * challenge signing, enabling off-chain login without on-chain transactions.
     *
     * When a challenge is provided:
     * 1. User authenticates (sign in or sign up) through the normal auth dialog
     * 2. User signs the challenge through the normal signing dialog
     * 3. Returns user info + signature for server-side verification
     *
     * This composes the same supported provider routes as calling
     * `authWithModal()` followed by `signMessage()`, so challenge auth cannot
     * drift onto a provider route that the passkey service does not expose.
     *
     * @example
     * ```typescript
     * const result = await client.authenticate({
     *   challenge: `Login to MyApp\nTimestamp: ${Date.now()}\nNonce: ${crypto.randomUUID()}`
     * });
     *
     * if (result.success && result.challenge) {
     *   // Verify signature server-side
     *   const isValid = await verifyOnServer(
     *     result.user?.address,
     *     result.challenge.signature,
     *     result.challenge.signedHash
     *   );
     * }
     * ```
     */
    authenticate(options?: AuthenticateOptions & {
        theme?: ThemeConfig;
    }): Promise<AuthenticateResult>;
    /**
     * Show signing in a modal overlay (iframe dialog)
     */
    signWithModal(options: SigningRequestOptions & {
        theme?: ThemeConfig;
    }): Promise<SigningResult>;
    /**
     * Send an intent to the Rhinestone orchestrator
     *
     * This is the high-level method for cross-chain transactions:
     * 1. Prepares the intent (gets quote from orchestrator)
     * 2. Shows the signing modal with real fees
     * 3. Submits the signed intent for execution
     * 4. Returns the transaction hash
     *
     * @example
     * ```typescript
     * const result = await client.sendIntent({
     *   accountAddress: '0x...',
     *   targetChain: 8453, // Base
     *   calls: [
     *     {
     *       to: '0x...',
     *       data: '0x...',
     *       label: 'Swap ETH for USDC',
     *       sublabel: '0.1 ETH → ~250 USDC',
     *     },
     *   ],
     * });
     *
     * if (result.success) {
     *   console.log('Transaction hash:', result.transactionHash);
     * }
     * ```
     */
    sendIntent(options: SendIntentOptions): Promise<SendIntentResult>;
    /**
     * Send a batch of intents for multi-chain execution with a single passkey tap.
     *
     * This method prepares multiple intents, shows a paginated review,
     * and signs all intents with a single passkey tap via a shared merkle tree.
     *
     * @example
     * ```typescript
     * const result = await client.sendBatchIntent({
     *   accountAddress: '0x...',
     *   intents: [
     *     {
     *       targetChain: 8453, // Base
     *       calls: [{ to: '0x...', data: '0x...', label: 'Swap on Base' }],
     *     },
     *     {
     *       targetChain: 42161, // Arbitrum
     *       calls: [{ to: '0x...', data: '0x...', label: 'Mint on Arbitrum' }],
     *     },
     *   ],
     * });
     *
     * if (result.success) {
     *   console.log(`${result.successCount} intents submitted`);
     * }
     * ```
     */
    sendBatchIntent(options: SendBatchIntentOptions): Promise<SendBatchIntentResult>;
    /**
     * Send transaction status to the dialog iframe
     */
    private sendTransactionStatus;
    /**
     * Listen for a signing result that belongs to a specific `requestId`.
     *
     * Used by legacy server-side signing request flows (popup/embed/modal) where
     * the dialog was pre-loaded with a signing request created via the API. The
     * `requestId` filter is needed because multiple dialogs may be open or there
     * may be stale messages from a previous dialog in the queue.
     *
     * Resolves on `PASSKEY_SIGNING_RESULT` matching `requestId`, or on
     * `PASSKEY_CLOSE` (user dismissed the dialog).
     *
     * @param requestId - The signing request ID to match against incoming messages.
     * @param dialog - The `<dialog>` element (opened before this call) used to
     *   `showModal()` so the dialog becomes interactive.
     * @param _iframe - Unused; kept for signature consistency with other wait helpers.
     * @param cleanup - Idempotent teardown function that closes and removes the dialog.
     * @returns A `SigningResult` discriminated union.
     */
    private waitForIntentSigningResponse;
    /**
     * Listen for a signing result from the currently open modal dialog.
     *
     * Unlike `waitForIntentSigningResponse`, this variant does not filter by
     * `requestId` because the inline intent flow (sendIntent / signMessage /
     * signTypedData) owns the dialog exclusively — there is no risk of collisions
     * from other dialogs.
     *
     * Handles two result shapes:
     *   - New "secure flow": dialog executed the intent server-side and returns
     *     only an `intentId` (no signature exposed to the SDK).
     *   - Legacy flow: dialog returns a raw `WebAuthnSignature` for the SDK to
     *     forward to the execute endpoint.
     *
     * @param dialog - The `<dialog>` element wrapping the signing iframe.
     * @param iframe - The signing iframe; used to authenticate the source of
     *   `PASSKEY_CLOSE` so a sibling same-origin dialog can't forge a rejection.
     * @param cleanup - Idempotent teardown that closes and removes the dialog.
     * @returns A `SigningResult` extended with an optional `signedHash` field
     *   populated when the dialog performs message signing.
     */
    private waitForSigningResponse;
    /**
     * Listen for a signing result while also handling quote-refresh requests.
     *
     * Quotes from the Rhinestone orchestrator have a short TTL (typically ~60 s).
     * When the user takes too long to review and the quote expires, the dialog
     * sends `PASSKEY_REFRESH_QUOTE`. This method intercepts that message, calls
     * the provided `onRefresh` callback to fetch a new quote, and replies with
     * either `PASSKEY_REFRESH_COMPLETE` (success) or `PASSKEY_REFRESH_ERROR`
     * (failure) — allowing the dialog to stay open and show the updated fees
     * without requiring a full restart.
     *
     * Once the user confirms or rejects, the promise resolves with the signing
     * result exactly as `waitForSigningResponse` would.
     *
     * @param dialog - The `<dialog>` element wrapping the signing iframe.
     * @param iframe - The iframe element; used to post refresh messages back.
     * @param cleanup - Idempotent teardown that closes and removes the dialog.
     * @param dialogOrigin - Trusted origin for message validation (passed in to
     *   avoid redundant `getDialogOrigin()` calls from the hot path).
     * @param onRefresh - Async callback that fetches a fresh quote and returns the
     *   updated intent fields, or `null` if the refresh failed.
     * @returns A `SigningResult` extended with an optional `signedHash`.
     */
    private waitForSigningWithRefresh;
    /**
     * Wait for the dialog to be explicitly closed by the user or the iframe.
     *
     * Resolves on either:
     *   - `PASSKEY_CLOSE` postMessage from the iframe (user clicked the X button
     *     or the dialog programmatically closed itself after showing a result).
     *   - The native `<dialog> close` event (escape key or `dialog.close()` call).
     *
     * Calling `cleanup()` before awaiting this is safe — both resolution paths
     * call `cleanup()` internally but it is idempotent. The primary use case is
     * keeping the dialog open while the SDK polls for a transaction hash, then
     * showing the final success/error state before letting the user dismiss.
     *
     * @param dialog - The `<dialog>` element to watch.
     * @param cleanup - Idempotent teardown that closes and removes the dialog.
     */
    private waitForDialogClose;
    /**
     * Hidden blind-signing iframes have no user-visible Done or Close button.
     * Once the SDK has the result it needs, tear them down immediately instead
     * of waiting for an iframe close event that can never be clicked.
     */
    private waitForDialogCloseUnlessBlind;
    /**
     * After a prepare error has been surfaced in the dialog, wait for the user
     * to either close the dialog (give up) or click "Try Again", which the
     * dialog forwards as `PASSKEY_RETRY_PREPARE`.
     *
     * On `"closed"` the dialog has been cleaned up; on `"retry"` it stays open
     * (showing its loading skeleton) while the caller re-runs prepare. Without
     * this, "Try Again" after a prepare failure was a dead end: the dialog
     * reset its local state but the SDK had already given up, so the quote
     * never arrived and the Sign button stayed disabled forever.
     */
    private waitForPrepareRetryOrClose;
    /**
     * Inject a `<link rel="preconnect">` tag for the given URL's origin.
     *
     * Browsers use preconnect hints to resolve DNS, perform the TCP handshake,
     * and negotiate TLS before a resource is actually requested, reducing
     * time-to-first-byte when the dialog iframe loads. The tag is deduplicated —
     * if one already exists for the same origin it will not be added again.
     *
     * Only called in browser environments (guarded by `typeof document` in the
     * constructor). Invalid URLs are silently ignored.
     *
     * @param url - Any URL whose origin should be preconnected to.
     */
    private injectPreconnect;
    /**
     * Warm the dialog ahead of the first user interaction.
     *
     * `preconnect` (run in the constructor) only warms DNS/TLS. This goes
     * further: it loads the dialog into a hidden, off-screen iframe so the
     * browser downloads and parses the dialog HTML + JS bundle and the font, and
     * keeps the cross-origin connection alive. When the user later opens a real
     * auth/sign dialog, the fresh iframe serves those bytes from cache over the
     * warm connection and paints far sooner — so the SDK preload overlay is shown
     * only briefly (or imperceptibly) instead of covering a full cold load.
     *
     * It loads a dedicated `/dialog/warm` route, NOT a real flow route. That
     * matters for two reasons:
     *   - **No side effects.** The real `/dialog/auth` route runs the signup
     *     flow on mount (identity probe → `POST /api/auth/register?step=start`),
     *     which writes an `AuthChallenge` row and counts against the register
     *     rate limiter. Warming must never create backend auth state for a user
     *     who hasn't acted, so the warm route renders nothing and runs no flow.
     *   - **No message cross-talk.** The warm route posts no `PASSKEY_READY` /
     *     `PASSKEY_RENDERED`, so a slow warm can never satisfy a visible modal's
     *     readiness listener and drive it to `PASSKEY_INIT` at the wrong moment.
     * The warm route still pulls the shared Next.js framework + main + dialog
     * layout chunks (the bulk of every flow's bundle), so the real open is fast.
     *
     * Best called on a *likely-intent* signal — `pointerenter`/`focus` of your
     * "Sign in" / "Pay" button — rather than on page load, so visitors who never
     * authenticate don't pay for a cross-origin iframe. Pass `prewarm: true` in
     * the client config to have the SDK schedule this once on an idle callback.
     *
     * Idempotent: repeated calls return the same in-flight/settled promise.
     * Resolves `true` once the hidden iframe's document has loaded, `false` on
     * timeout or failure. Never throws and never blocks a real dialog open — a
     * failed prewarm just means the next open does a normal (cold) load.
     *
     * @returns Whether the dialog became warm.
     */
    prewarm(): Promise<boolean>;
    /**
     * Tear down the hidden prewarm iframe created by {@link prewarm}.
     *
     * The HTTP cache that prewarm populated survives teardown, so a subsequent
     * open is still bundle-warm; this only releases the parked frame (and its
     * keep-alive connection). Call it when auth is no longer likely on the
     * current view. Safe to call when nothing is warmed.
     */
    destroyPrewarm(): void;
    /**
     * Wait for the dialog iframe to signal ready, but defer sending `PASSKEY_INIT`
     * until the caller decides the time is right.
     *
     * This is the deferred variant of `waitForDialogReady`, used by flows that run
     * the dialog and a background API call in parallel (the "two-phase" approach).
     * Rather than blocking until both the iframe is ready AND the API call is done,
     * this method resolves as soon as `PASSKEY_READY` arrives and returns a
     * `sendInit` callback. The caller invokes `sendInit` once prepare data is
     * available, which may happen before or after the iframe is ready.
     *
     * Timeout: if the iframe never signals ready within 10 seconds (e.g. network
     * error, origin mismatch), resolves with `{ ready: false }` and calls cleanup.
     *
     * @param dialog - The `<dialog>` element wrapping the iframe.
     * @param iframe - The iframe element that will receive `PASSKEY_INIT`.
     * @param cleanup - Idempotent teardown that closes and removes the dialog.
     * @returns `{ ready: true, sendInit }` when the iframe is ready, or
     *   `{ ready: false }` if the dialog was closed or timed out first.
     */
    private waitForDialogReadyDeferred;
    /**
     * Call the passkey service to obtain a Rhinestone orchestrator quote for an
     * intent (a single target-chain transaction or swap).
     *
     * The service contacts the Rhinestone orchestrator, which returns a signed
     * `intentOp` structure containing the quote, fees, and a WebAuthn challenge
     * the user must sign to authorize execution.
     *
     * The `X-Origin-Tier` response header is forwarded to the dialog so it can
     * display tier-specific UI (e.g. "Free" vs "Premium" badge).
     *
     * Side effect: if the server returns "User not found", the cached user entry
     * is removed from `localStorage` to force re-authentication.
     *
     * @param requestBody - Serialized intent options (bigint amounts converted to
     *   strings before this call).
     * @returns On success: `{ success: true, data: PrepareIntentResponse, tier }`.
     *   On failure: `{ success: false, error: { code, message, details? } }`.
     */
    /**
     * Request a non-sponsored draft solely to obtain the SDK-canonical intent
     * input that the embedding app must authorize. The passkey service returns
     * no signable quote or user data in this phase.
     */
    private prepareSponsorshipDraft;
    private prepareIntent;
    /**
     * Call the passkey service to obtain orchestrator quotes for all intents in a
     * batch, returning a single shared WebAuthn challenge.
     *
     * The service prepares each intent independently and assembles a merkle tree
     * whose root becomes the challenge. Signing that root once authorizes every
     * intent in the batch. Partially-failed batches are supported: the response
     * includes both `intents` (succeeded) and `failedIntents` (per-intent errors),
     * so the dialog can still show the successful subset for signing.
     *
     * Side effect: same "User not found" localStorage cleanup as `prepareIntent`.
     *
     * @param requestBody - Serialized batch options (bigint amounts converted to
     *   strings before this call).
     * @returns On success: `{ success: true, data: PrepareBatchIntentResponse, tier }`.
     *   On failure: `{ success: false, error, failedIntents? }`.
     */
    /**
     * Draft, authorize, and authoritatively quote a batch without losing caller indices.
     * Preferred sponsorship failures are retried only by an explicit full-batch
     * self-funded re-quote so every returned intent shares one fresh merkle root.
     */
    private prepareBatchWithFunding;
    /** Request canonical batch sponsorship inputs without returning signable data. */
    private prepareBatchDraft;
    private prepareBatchIntent;
    /**
     * Forward a prepare-phase error to the dialog iframe so it can display a
     * human-readable failure message instead of hanging on the loading state.
     *
     * The dialog listens for `PASSKEY_PREPARE_ERROR` and transitions to an error
     * view. The user can then dismiss the dialog, at which point
     * `waitForDialogClose` resolves and the SDK returns the error to the caller.
     *
     * @param iframe - The iframe element to post the error to.
     * @param error - Human-readable error message from the prepare response.
     */
    private sendPrepareError;
    /**
     * Poll for intent status
     *
     * Use this to check on the status of a submitted intent
     * that hasn't completed yet.
     */
    getIntentStatus(intentId: string): Promise<SendIntentResult>;
    /**
     * Get the history of intents for the authenticated user.
     *
     * Requires an active session (user must be logged in).
     *
     * @example
     * ```typescript
     * // Get recent intents
     * const history = await client.getIntentHistory({ limit: 10 });
     *
     * // Filter by status
     * const pending = await client.getIntentHistory({ status: 'pending' });
     *
     * // Filter by date range
     * const lastWeek = await client.getIntentHistory({
     *   from: new Date(Date.now() - 7 * 24 * 60 * 60 * 1000).toISOString(),
     * });
     * ```
     */
    getIntentHistory(options?: IntentHistoryOptions): Promise<IntentHistoryResult>;
    /**
     * Forward a raw EIP-1193 request to the iframe so the active EOA connector
     * can handle it (wallet-connect session or injected wallet). Opens
     * `/dialog/sign-eoa`, which looks up the wagmi connector and delegates to
     * `connector.getProvider().request({ method, params })`. The wallet's own
     * UI is the review screen; the dialog just transports the request.
     */
    requestWithWallet(options: {
        method: string;
        params?: unknown[] | Record<string, unknown>;
        expectedAddress?: `0x${string}`;
        theme?: ThemeConfig;
    }): Promise<{
        success: true;
        result: unknown;
    } | {
        success: false;
        error: {
            code: string;
            message: string;
        };
    }>;
    private doRequestWithWallet;
    /**
     * Lazily create the persistent `/dialog/sign-eoa` iframe and reveal it.
     * Subsequent calls just re-open the existing `<dialog>` so the iframe's
     * in-page state (notably the WalletConnect SignClient) is preserved
     * between transactions.
     */
    private ensureEoaDialog;
    private waitForEoaIframeReady;
    private waitForEoaResponse;
    /**
     * Sign an arbitrary message with the user's passkey
     *
     * This is for off-chain message signing (e.g., authentication challenges,
     * terms acceptance, login signatures), NOT for transaction signing.
     * The message is displayed to the user and signed with their passkey.
     *
     * @example
     * ```typescript
     * // Sign a login challenge
     * const result = await client.signMessage({
     *   accountAddress: '0x...',
     *   message: `Sign in to MyApp\nTimestamp: ${Date.now()}\nNonce: ${crypto.randomUUID()}`,
     *   description: 'Verify your identity to continue',
     * });
     *
     * if (result.success) {
     *   // Send signature to your backend for verification
     *   await fetch('/api/verify', {
     *     method: 'POST',
     *     body: JSON.stringify({
     *       signature: result.signature,
     *       message: result.signedMessage,
     *     }),
     *   });
     * }
     * ```
     */
    signMessage(options: SignMessageOptions): Promise<SignMessageResult>;
    /**
     * Sign EIP-712 typed data with the user's passkey
     *
     * This method allows signing structured data following the EIP-712 standard.
     * The typed data is displayed to the user in a human-readable format before signing.
     *
     * @example
     * ```typescript
     * // Sign an ERC-2612 Permit
     * const result = await client.signTypedData({
     *   accountAddress: '0x...',
     *   domain: {
     *     name: 'Dai Stablecoin',
     *     version: '1',
     *     chainId: 1,
     *     verifyingContract: '0x6B175474E89094C44Da98b954EecdeCB5BE3830F',
     *   },
     *   types: {
     *     Permit: [
     *       { name: 'owner', type: 'address' },
     *       { name: 'spender', type: 'address' },
     *       { name: 'value', type: 'uint256' },
     *       { name: 'nonce', type: 'uint256' },
     *       { name: 'deadline', type: 'uint256' },
     *     ],
     *   },
     *   primaryType: 'Permit',
     *   message: {
     *     owner: '0xabc...',
     *     spender: '0xdef...',
     *     value: 1000000000000000000n,
     *     nonce: 0n,
     *     deadline: 1735689600n,
     *   },
     * });
     *
     * if (result.success) {
     *   console.log('Signed hash:', result.signedHash);
     * }
     * ```
     */
    signTypedData(options: SignTypedDataOptions): Promise<SignTypedDataResult>;
    signWithPopup(options: SigningRequestOptions): Promise<SigningResult>;
    signWithRedirect(options: SigningRequestOptions, redirectUrl?: string): Promise<void>;
    signWithEmbed(options: SigningRequestOptions, embedOptions: EmbedOptions): Promise<SigningResult>;
    /**
     * Create and append a signing iframe to a caller-supplied container element.
     *
     * Used by the `signWithEmbed` flow where the integrator wants the signing UI
     * to appear inline on their page rather than in a modal overlay. The iframe
     * loads a pre-created signing request URL and fires `options.onReady` once
     * the page has loaded.
     *
     * @param requestId - The signing request ID; used to construct the iframe src
     *   and give it a stable DOM id for later removal via `removeEmbed`.
     * @param options - Embed configuration including the container element,
     *   optional dimensions, and lifecycle callbacks.
     * @returns The created `<iframe>` element (already appended to the container).
     */
    private createEmbed;
    /**
     * Post `PASSKEY_VIEWPORT_INFO` with the parent's
     * `window.innerHeight` to the iframe whenever it signals
     * `PASSKEY_READY`, and re-post on `window.resize` (rAF-debounced)
     * so the dialog's internal max-height cap follows the user's
     * actual screen.
     *
     * Inside the iframe, `vh`/`dvh` units refer to the iframe's own
     * height (recursive when the iframe auto-sizes), so the parent is
     * the only reliable source of "what 75% of the user's screen is".
     * The dialog stores the value in `dialog-context` and falls back
     * to auto-grow when the value is absent — so it's safe to call
     * this even for embedders that don't actually cap (modal mode
     * uses `fullViewport` which has its own outer cap).
     */
    private wireViewportInfo;
    /**
     * Listen for a signing result from an embedded (inline) signing iframe.
     *
     * Matches incoming `PASSKEY_SIGNING_RESULT` messages against `requestId`
     * to avoid reacting to messages from other iframes on the page. On resolution
     * (success or failure), the iframe is removed from the DOM and
     * `embedOptions.onClose` is invoked.
     *
     * @param requestId - The signing request ID to match against incoming messages.
     * @param iframe - The embedded signing iframe.
     * @param embedOptions - Embed configuration; `onClose` is called after cleanup.
     * @returns A `SigningResult` discriminated union.
     */
    private waitForEmbedResponse;
    removeEmbed(requestId: string): void;
    handleRedirectCallback(): Promise<SigningResult>;
    /**
     * Register a signing request with the passkey service and receive a
     * short-lived `requestId`.
     *
     * Used by the legacy popup, redirect, and embed flows. The passkey service
     * stores the challenge and metadata server-side so the dialog page can fetch
     * them by `requestId` without relying on URL parameters alone. This avoids
     * exposing potentially large challenge payloads in query strings.
     *
     * @param options - The signing options (challenge, accountAddress, description, etc.).
     * @param mode - How the dialog will be opened (`"popup"`, `"redirect"`, or `"embed"`).
     * @param redirectUrl - Only required for `"redirect"` mode; the URL the dialog
     *   will navigate back to after signing.
     * @returns The created signing request with its unique `requestId`.
     * @throws If the API call fails.
     */
    private createSigningRequest;
    /**
     * Open a centered popup window for the signing or auth dialog.
     *
     * Positions the popup near the top of the current window (50px from the top)
     * and horizontally centered relative to the browser window. Uses `popup=true`
     * to request a minimal chrome popup (no address bar) on browsers that support
     * the Window Management API.
     *
     * @param url - The full URL to open in the popup.
     * @returns The popup `Window` reference, or `null` if the browser blocked it.
     */
    private openPopup;
    /**
     * Wait for the dialog iframe to signal ready, then immediately send init data.
     *
     * This is the synchronous-init variant: `initMessage` is available at call
     * time, so it can be posted as soon as `PASSKEY_READY` arrives. Use
     * `waitForDialogReadyDeferred` when init data depends on an in-flight API call.
     *
     * Also handles early close (X button, escape key, backdrop click) during the
     * ready phase so those paths resolve cleanly without leaking event listeners.
     *
     * Timeout: resolves `false` after 10 seconds if the iframe never signals ready
     * (e.g. origin mismatch or network error loading the dialog app).
     *
     * @param dialog - The `<dialog>` element wrapping the iframe.
     * @param iframe - The iframe element that will receive `PASSKEY_INIT`.
     * @param cleanup - Idempotent teardown that closes and removes the dialog.
     * @param initMessage - The `PASSKEY_INIT` payload to send when ready.
     * @returns `true` if the dialog is ready and init was sent; `false` if the
     *   dialog was closed or timed out before becoming ready.
     */
    private waitForDialogReady;
    /**
     * Create and open a full-viewport `<dialog>` containing a passkey iframe.
     *
     * The SDK owns the browser `<dialog>` plus a minimal generic preload shell
     * that appears immediately on click. The passkey iframe owns all branded and
     * origin-specific UI (TitleBar, trust icon, action cards); the shell is
     * removed as soon as the iframe reports that its centered card has painted.
     *
     * Lifecycle:
     *   1. A themed generic preload shell is injected and shown immediately
     *      while the iframe loads. It intentionally contains no TitleBar or
     *      origin chrome so that UI has a single implementation in apps/passkey.
     *   2. When the iframe sends `PASSKEY_RENDERED`, the overlay is removed and
     *      the iframe becomes fully visible in the same frame.
     *   3. The returned `cleanup` function tears down all event listeners,
     *      disconnects the MutationObserver, closes the `<dialog>`, and removes
     *      it from the DOM. It is idempotent — safe to call multiple times.
     *
     * Browser quirks handled:
     *   - The 1Password extension sets `inert` on the `<dialog>`, making it
     *     non-interactive. A MutationObserver removes the attribute immediately.
     *   - Password managers may also set `inert` on dialog siblings; cleanup
     *     restores those as well.
     *   - The iframe sandbox includes `allow-popups-to-escape-sandbox` so that
     *     1Password's popup UI can render outside the sandboxed context.
     *   - `allow-downloads` lets the passkey iframe trigger the recovery-key
     *     JSON fallback download without sending sensitive data to the parent.
     *
     * @param url - The full URL (including query params) to load in the iframe.
     * @returns References to the dialog, iframe, and a cleanup function.
     */
    private createModalDialog;
    /**
     * Listen for the auth result from the modal dialog.
     *
     * Each modal call generates a per-session nonce that the iframe must
     * echo back in `PASSKEY_CLOSE` / `PASSKEY_LOGIN_RESULT` /
     * `PASSKEY_RETRY_POPUP` messages. Without an echo, a queued CLOSE
     * from the previous iframe could be dispatched to the new modal's
     * listener (postMessage events tagged with `event.source` from a now-
     * destroyed iframe still reach the parent's message handler) and
     * silently cancel the fresh auth attempt. The nonce makes that race
     * harmless: a stale message that doesn't carry the current modal's
     * nonce is ignored.
     *
     * Also handles the `PASSKEY_RETRY_POPUP` message: sent by the dialog when a
     * password manager (e.g. Bitwarden) intercepts the WebAuthn call inside the
     * iframe. In that case the SDK seamlessly re-opens a standalone popup window,
     * where WebAuthn works without cross-origin iframe restrictions, and waits
     * for the result from there instead.
     *
     * @param _dialog - Unused; kept for signature consistency.
     * @param iframe - The iframe element; used to send `PASSKEY_INIT` on ready.
     * @param cleanup - Idempotent teardown for the modal dialog.
     * @returns An `AuthResult` discriminated union.
     */
    private waitForModalAuthResponse;
    /**
     * Open a popup for auth and wait for the result.
     * Used when iframe mode fails (e.g., due to password manager interference).
     */
    private waitForPopupAuthResponse;
    /**
     * Listen for the connect result from the connect dialog.
     *
     * The connect flow is a lightweight "are you still you?" confirmation that
     * does not require a new passkey ceremony. On success, the dialog returns the
     * user's address and an `autoConnected` flag indicating whether the
     * user had previously enabled auto-connect (in which case no UI was shown).
     *
     * On failure with `action: "switch"`, the caller should redirect to the full
     * auth flow because the user has no cached session to confirm.
     *
     * @param _dialog - Unused; kept for signature consistency.
     * @param _iframe - Unused; kept for signature consistency.
     * @param cleanup - Idempotent teardown for the modal dialog.
     * @returns A `ConnectResult` discriminated union.
     */
    private waitForConnectResponse;
    /**
     * Listen for grant-permission results and bridge sponsorship token requests.
     *
     * The grant iframe owns the passkey ceremony and install intent submission.
     * Extension-token minting stays in the app origin, so the SDK exposes a
     * narrow postMessage round-trip that never gives the iframe app secrets.
     *
     * @param _dialog - Unused; kept for signature consistency.
     * @param iframe - The grant iframe that receives extension-token responses.
     * @param cleanup - Idempotent teardown for the modal dialog.
     * @param sponsor - Whether this grant flow should request an extension token.
     * @returns A `GrantPermissionsResult` discriminated union.
     */
    private waitForGrantPermissionResponse;
    /**
     * Listen for a signing result from a server-request-based modal dialog.
     *
     * Similar to `waitForIntentSigningResponse` but intended for the older
     * `signWithModal` path that pre-creates a signing request via the API (rather
     * than inlining all data in `PASSKEY_INIT`). Filters by `requestId` to handle
     * the case where stale messages from a previous dialog may still be in flight.
     *
     * @param requestId - The signing request ID to match against incoming messages.
     * @param _dialog - Unused; kept for signature consistency.
     * @param _iframe - Unused; kept for signature consistency.
     * @param cleanup - Idempotent teardown that closes and removes the dialog.
     * @returns A `SigningResult` discriminated union.
     */
    private waitForModalSigningResponse;
    /**
     * Listen for a signing result from a popup window.
     *
     * Polls for popup closure every 500 ms as a fallback to detect when the user
     * closes the popup without completing the signing flow (no `PASSKEY_CLOSE`
     * message is fired in that case because the popup's unload event cannot
     * reliably postMessage to the opener on all browsers).
     *
     * On success or cancellation, the popup is programmatically closed and the
     * interval is cleared.
     *
     * @param requestId - The signing request ID to match against incoming messages.
     * @param popup - The popup `Window` reference returned by `openPopup`.
     * @returns A `SigningResult` discriminated union.
     */
    private waitForPopupResponse;
    /**
     * Fetch the completed signing result from the passkey service by request ID.
     *
     * Used by the redirect flow: after the passkey service redirects back to
     * `redirectUrl`, the integrator calls `handleRedirectCallback()`, which
     * extracts `requestId` from the URL query params and delegates here to
     * retrieve the full signature from the server.
     *
     * @param requestId - The signing request ID from the redirect callback URL.
     * @returns A `SigningResult` discriminated union.
     */
    private fetchSigningResult;
}

export { OneAuthClient as O };