@formo/analytics 1.36.0 → 1.38.0

package/dist/esm/src/evm/batch.d.ts

@@ -0,0 +1,94 @@
+import { TransactionStatus } from "../types/events";
+/**
+ * EIP-5792 batch settlement, shared by both capture paths.
+ *
+ * The EIP-1193 request wrapper (`EvmRequestTracker`) and the wagmi cache
+ * observer (`WagmiEventHandler`) each see a batch through a different
+ * transport, but a settled batch means the same thing in both. Keeping the
+ * outcome rules in one place is what stops the two paths from drifting into
+ * reporting the same batch differently depending on how the app happened to
+ * integrate the SDK.
+ */
+/** A settled batch as `wallet_getCallsStatus` (or viem's wrapper) reports it. */
+export type BatchStatusResult = {
+    status?: number | string;
+    statusCode?: number;
+    atomic?: boolean;
+    chainId?: number | string;
+    receipts?: BatchReceipt[];
+} | null | undefined;
+export type BatchReceipt = {
+    status?: string | number;
+    transactionHash?: string;
+};
+/**
+ * The batch identifier from a `wallet_sendCalls` result.
+ *
+ * EIP-5792 settled on `{ id }`, but wallets shipped against the earlier
+ * draft return a bare string. Both are accepted so a wallet on either
+ * version is still grouped.
+ */
+export declare function readBatchId(result: unknown): string | undefined;
+/**
+ * The numeric EIP-5792 status code from a settlement result.
+ *
+ * A wallet answers `wallet_getCallsStatus` with a numeric `status`; viem's
+ * `getCallsStatus` renames that to `statusCode` and puts a summary string in
+ * `status` instead. Both shapes arrive here depending on the capture path,
+ * so read the number wherever it is and never trust the string.
+ */
+export declare function readBatchStatusCode(res: BatchStatusResult): number | undefined;
+/**
+ * The chain a settled batch reports itself on.
+ *
+ * EIP-5792 v2 puts `chainId` in the `wallet_getCallsStatus` response as hex;
+ * viem returns it as a number. Either way it names the chain the batch
+ * actually settled on, which outranks a chain merely inferred from the
+ * connection at broadcast time - the wallet can move chains while the
+ * prompt is up.
+ */
+export declare function readBatchChainId(res: BatchStatusResult): number | undefined;
+/**
+ * How one call in a settled batch ended.
+ *
+ * A per-call receipt is authoritative where it exists: that is what makes a
+ * partially reverted non-atomic batch report honestly rather than tarring
+ * every call with the batch's worst outcome. A receipt whose own status is
+ * unreadable falls back to the batch verdict rather than being assumed good.
+ *
+ * Receipt statuses come in two spellings: raw RPC (`"0x0"`/`"0x1"`, or the
+ * numbers) and viem-formatted (`"reverted"`/`"success"`), because the wagmi
+ * path sees receipts after viem has normalised them.
+ *
+ * The codes are EIP-5792's: 200 confirmed, 400 failed BEFORE landing on
+ * chain, 500 reverted, 600 partially reverted. 400 is a rejection, not a
+ * revert - nothing was mined, so calling it reverted would misreport gas
+ * spent and on-chain activity that never happened.
+ *
+ * Returns undefined when the call cannot be decided, which happens on 600
+ * for a call the wallet gave no receipt for.
+ */
+export declare function batchCallOutcome(code: number, receipt?: BatchReceipt): TransactionStatus | undefined;
+/**
+ * The receipt that decides call `index`, honouring atomic execution.
+ *
+ * An atomic batch lands as ONE on-chain transaction, so the wallet returns a
+ * single receipt covering every call. Indexing receipts positionally there
+ * would hand the shared hash to call 0 and leave its siblings hashless and
+ * decided only by the batch verdict. Every call in an atomic batch shares
+ * the one receipt - same hash, same fate - which is also what makes
+ * `count(distinct transaction_hash)` count on-chain transactions correctly.
+ *
+ * The wallet's own `atomic` flag is authoritative in BOTH directions. An
+ * explicit `atomic: false` with a single receipt is a real shape - a
+ * non-atomic batch whose execution stopped after one call mined - and
+ * sharing that receipt would hand calls that never reached the chain a
+ * transaction hash they do not have. Only when the field is ABSENT (a
+ * wallet predating it, reached over raw EIP-1193; viem fills the field in,
+ * so the wagmi path never lands here) does the conservative inference
+ * apply: one receipt for several calls on a batch that is NOT partially
+ * reverted can only be atomic execution (600 explicitly means some calls
+ * reverted and others did not, which one shared transaction cannot do).
+ */
+export declare function batchReceiptForCall(res: BatchStatusResult, index: number, callCount: number): BatchReceipt | undefined;
+//# sourceMappingURL=batch.d.ts.map

package/dist/esm/src/evm/batch.js

@@ -0,0 +1,123 @@
+import { TransactionStatus } from "../types/events";
+/**
+ * The batch identifier from a `wallet_sendCalls` result.
+ *
+ * EIP-5792 settled on `{ id }`, but wallets shipped against the earlier
+ * draft return a bare string. Both are accepted so a wallet on either
+ * version is still grouped.
+ */
+export function readBatchId(result) {
+    if (typeof result === "string" && result.length > 0)
+        return result;
+    if (result && typeof result === "object") {
+        var id = result.id;
+        if (typeof id === "string" && id.length > 0)
+            return id;
+    }
+    return undefined;
+}
+/**
+ * The numeric EIP-5792 status code from a settlement result.
+ *
+ * A wallet answers `wallet_getCallsStatus` with a numeric `status`; viem's
+ * `getCallsStatus` renames that to `statusCode` and puts a summary string in
+ * `status` instead. Both shapes arrive here depending on the capture path,
+ * so read the number wherever it is and never trust the string.
+ */
+export function readBatchStatusCode(res) {
+    if (typeof (res === null || res === void 0 ? void 0 : res.statusCode) === "number")
+        return res.statusCode;
+    if (typeof (res === null || res === void 0 ? void 0 : res.status) === "number")
+        return res.status;
+    return undefined;
+}
+/**
+ * The chain a settled batch reports itself on.
+ *
+ * EIP-5792 v2 puts `chainId` in the `wallet_getCallsStatus` response as hex;
+ * viem returns it as a number. Either way it names the chain the batch
+ * actually settled on, which outranks a chain merely inferred from the
+ * connection at broadcast time - the wallet can move chains while the
+ * prompt is up.
+ */
+export function readBatchChainId(res) {
+    var raw = res === null || res === void 0 ? void 0 : res.chainId;
+    if (typeof raw === "number" && Number.isFinite(raw) && raw > 0)
+        return raw;
+    if (typeof raw === "string") {
+        var parsed = parseInt(raw, 16);
+        if (Number.isFinite(parsed) && parsed > 0)
+            return parsed;
+    }
+    return undefined;
+}
+/**
+ * How one call in a settled batch ended.
+ *
+ * A per-call receipt is authoritative where it exists: that is what makes a
+ * partially reverted non-atomic batch report honestly rather than tarring
+ * every call with the batch's worst outcome. A receipt whose own status is
+ * unreadable falls back to the batch verdict rather than being assumed good.
+ *
+ * Receipt statuses come in two spellings: raw RPC (`"0x0"`/`"0x1"`, or the
+ * numbers) and viem-formatted (`"reverted"`/`"success"`), because the wagmi
+ * path sees receipts after viem has normalised them.
+ *
+ * The codes are EIP-5792's: 200 confirmed, 400 failed BEFORE landing on
+ * chain, 500 reverted, 600 partially reverted. 400 is a rejection, not a
+ * revert - nothing was mined, so calling it reverted would misreport gas
+ * spent and on-chain activity that never happened.
+ *
+ * Returns undefined when the call cannot be decided, which happens on 600
+ * for a call the wallet gave no receipt for.
+ */
+export function batchCallOutcome(code, receipt) {
+    var receiptStatus = receipt === null || receipt === void 0 ? void 0 : receipt.status;
+    if (receiptStatus !== undefined) {
+        return receiptStatus === "0x0" ||
+            receiptStatus === 0 ||
+            receiptStatus === "reverted"
+            ? TransactionStatus.REVERTED
+            : TransactionStatus.CONFIRMED;
+    }
+    if (code >= 600)
+        return undefined;
+    if (code >= 500)
+        return TransactionStatus.REVERTED;
+    if (code >= 400)
+        return TransactionStatus.REJECTED;
+    return TransactionStatus.CONFIRMED;
+}
+/**
+ * The receipt that decides call `index`, honouring atomic execution.
+ *
+ * An atomic batch lands as ONE on-chain transaction, so the wallet returns a
+ * single receipt covering every call. Indexing receipts positionally there
+ * would hand the shared hash to call 0 and leave its siblings hashless and
+ * decided only by the batch verdict. Every call in an atomic batch shares
+ * the one receipt - same hash, same fate - which is also what makes
+ * `count(distinct transaction_hash)` count on-chain transactions correctly.
+ *
+ * The wallet's own `atomic` flag is authoritative in BOTH directions. An
+ * explicit `atomic: false` with a single receipt is a real shape - a
+ * non-atomic batch whose execution stopped after one call mined - and
+ * sharing that receipt would hand calls that never reached the chain a
+ * transaction hash they do not have. Only when the field is ABSENT (a
+ * wallet predating it, reached over raw EIP-1193; viem fills the field in,
+ * so the wagmi path never lands here) does the conservative inference
+ * apply: one receipt for several calls on a batch that is NOT partially
+ * reverted can only be atomic execution (600 explicitly means some calls
+ * reverted and others did not, which one shared transaction cannot do).
+ */
+export function batchReceiptForCall(res, index, callCount) {
+    var _a;
+    var receipts = Array.isArray(res === null || res === void 0 ? void 0 : res.receipts) ? res.receipts : [];
+    var code = (_a = readBatchStatusCode(res)) !== null && _a !== void 0 ? _a : 0;
+    var atomic = (res === null || res === void 0 ? void 0 : res.atomic) === true ||
+        ((res === null || res === void 0 ? void 0 : res.atomic) === undefined &&
+            receipts.length === 1 &&
+            callCount > 1 &&
+            code < 600);
+    return atomic ? receipts[0] : receipts[index];
+}
+//# sourceMappingURL=batch.js.map

package/dist/esm/src/provider/detection.d.ts

@@ -41,6 +41,36 @@ export interface ProviderInfo {
  * ```
  */
 export declare function detectInjectedProviderInfo(provider: EIP1193Provider): ProviderInfo;
+/**
+ * Was this error the USER declining, whatever transport delivered it?
+ *
+ * Three dialects say "the user said no":
+ * - EIP-1193: code 4001 (UserRejectedRequest).
+ * - WalletConnect sdkErrors: codes 5000-5005 (USER_REJECTED and its
+ *   variants). A LIVE MetaMask Mobile session rejecting a transaction
+ *   produced one of these and the SDK's 4001-only match reported nothing -
+ *   every WalletConnect rejection was silently uncounted.
+ * - viem: a typed UserRejectedRequestError, sometimes without the numeric
+ *   code surviving the wrapping.
+ *
+ * The real code often hides under `cause` (viem nests, WC wraps), so the
+ * chain is walked a few levels.
+ */
+export declare function isUserRejectionError(error: unknown): boolean;
+/**
+ * The wallet on the far side of a WalletConnect session.
+ *
+ * WalletConnect is a transport, not a wallet: the signing wallet (Ledger
+ * Live, MetaMask Mobile, Safe, ...) identifies itself in the session's peer
+ * metadata. Reporting only "WalletConnect" hides every wallet behind it -
+ * production showed Ledger at effectively zero while its sessions were being
+ * tracked under the transport's name. Reads synchronous state only; never
+ * issues an RPC.
+ */
+export declare function readWalletConnectPeer(provider: EIP1193Provider): {
+    name: string;
+    url?: string;
+} | undefined;
 /**
  * Validates that a provider implements the required EIP-1193 interface
  *

package/dist/esm/src/provider/detection.js

@@ -1,6 +1,17 @@
 /**
  * Provider detection utilities for identifying wallet providers
  */
+var __assign = (this && this.__assign) || function () {
+    __assign = Object.assign || function(t) {
+        for (var s, i = 1, n = arguments.length; i < n; i++) {
+            s = arguments[i];
+            for (var p in s) if (Object.prototype.hasOwnProperty.call(s, p))
+                t[p] = s[p];
+        }
+        return t;
+    };
+    return __assign.apply(this, arguments);
+};
 /**
  * Default icon for providers without custom icons
  */
@@ -76,6 +87,55 @@ export function detectInjectedProviderInfo(provider) {
         icon: DEFAULT_PROVIDER_ICON,
     };
 }
+/**
+ * Was this error the USER declining, whatever transport delivered it?
+ *
+ * Three dialects say "the user said no":
+ * - EIP-1193: code 4001 (UserRejectedRequest).
+ * - WalletConnect sdkErrors: codes 5000-5005 (USER_REJECTED and its
+ *   variants). A LIVE MetaMask Mobile session rejecting a transaction
+ *   produced one of these and the SDK's 4001-only match reported nothing -
+ *   every WalletConnect rejection was silently uncounted.
+ * - viem: a typed UserRejectedRequestError, sometimes without the numeric
+ *   code surviving the wrapping.
+ *
+ * The real code often hides under `cause` (viem nests, WC wraps), so the
+ * chain is walked a few levels.
+ */
+export function isUserRejectionError(error) {
+    var cursor = error;
+    for (var depth = 0; cursor && depth < 5; depth++) {
+        var code = cursor.code;
+        if (code === 4001 ||
+            (typeof code === "number" && code >= 5000 && code <= 5005) ||
+            cursor.name === "UserRejectedRequestError") {
+            return true;
+        }
+        cursor = cursor.cause;
+    }
+    return false;
+}
+/**
+ * The wallet on the far side of a WalletConnect session.
+ *
+ * WalletConnect is a transport, not a wallet: the signing wallet (Ledger
+ * Live, MetaMask Mobile, Safe, ...) identifies itself in the session's peer
+ * metadata. Reporting only "WalletConnect" hides every wallet behind it -
+ * production showed Ledger at effectively zero while its sessions were being
+ * tracked under the transport's name. Reads synchronous state only; never
+ * issues an RPC.
+ */
+export function readWalletConnectPeer(provider) {
+    var _a;
+    var session = provider.session;
+    var metadata = (_a = session === null || session === void 0 ? void 0 : session.peer) === null || _a === void 0 ? void 0 : _a.metadata;
+    if (!metadata || typeof metadata.name !== "string" || metadata.name.length === 0) {
+        return undefined;
+    }
+    return __assign({ name: metadata.name }, (typeof metadata.url === "string" && metadata.url.length > 0
+        ? { url: metadata.url }
+        : {}));
+}
 /**
  * Validates that a provider implements the required EIP-1193 interface
  *

package/dist/esm/src/provider/index.d.ts

@@ -1,6 +1,6 @@
 /**
  * Provider-related exports
  */
-export { detectInjectedProviderInfo, isValidProvider, DEFAULT_PROVIDER_ICON, } from './detection';
+export { detectInjectedProviderInfo, isValidProvider, readWalletConnectPeer, isUserRejectionError, DEFAULT_PROVIDER_ICON, } from './detection';
 export type { WalletProviderFlags, ProviderInfo, } from './detection';
 //# sourceMappingURL=index.d.ts.map

package/dist/esm/src/provider/index.js

@@ -1,5 +1,5 @@
 /**
  * Provider-related exports
  */
-export { detectInjectedProviderInfo, isValidProvider, DEFAULT_PROVIDER_ICON, } from './detection';
+export { detectInjectedProviderInfo, isValidProvider, readWalletConnectPeer, isUserRejectionError, DEFAULT_PROVIDER_ICON, } from './detection';
 //# sourceMappingURL=index.js.map

package/dist/esm/src/types/base.d.ts

@@ -19,6 +19,17 @@ export interface IFormoAnalytics {
     page(category?: string, name?: string, properties?: IFormoEventProperties, context?: IFormoEventContext, callback?: (...args: unknown[]) => void): Promise<void>;
     reset(): void;
     cleanup(): void;
+    /**
+     * Track a constructed (non-injected) EIP-1193 provider, such as a
+     * WalletConnect or Ledger provider the app built itself. Returns true when
+     * the provider is tracked, false when refused (wagmi mode, EVM disabled,
+     * or not a valid provider).
+     */
+    registerProvider(provider: EIP1193Provider, info?: {
+        name?: string;
+        rdns?: string;
+        icon?: `data:image/${string}`;
+    }): boolean;
     detect(params: {
         rdns: string;
         providerName: string;
@@ -171,6 +182,18 @@ export interface ReferralOptions {
  * Allows the SDK to hook into Wagmi v2 wallet events instead of wrapping EIP-1193 providers
  */
 export interface WagmiOptions {
+    /**
+     * OPT-IN: fall back to the EIP-1193 request wrapper for wallet calls the
+     * wagmi caches cannot see - imperative viem calls
+     * (walletClient.sendTransaction, .signMessage, .writeContract, raw
+     * request) that create no mutation. The active connector's provider gets
+     * the same wrapper the SDK's default mode uses. Off by default: wagmi
+     * mode's baseline contract is observing wagmi state and caches without
+     * touching the signing transport, and enabling this is an explicit,
+     * auditable decision. Hook-driven calls are never double-counted (a
+     * pending wagmi mutation stands the wrapper down).
+     */
+    eip1193Fallback?: boolean;
     /**
      * Wagmi config instance from createConfig()
      * The SDK will subscribe to this config's state changes to track wallet events

package/dist/esm/src/types/provider.d.ts

@@ -20,6 +20,22 @@ export type WrappedRequestFunction = (<T>(args: RequestArguments) => Promise<T |
     [WRAPPED_REQUEST_SYMBOL]?: boolean;
 };
 export declare const WRAPPED_REQUEST_REF_SYMBOL: unique symbol;
+/**
+ * The SDK instance a provider's installed wrapper currently reports to.
+ *
+ * The wrapper survives an SDK rebuild (nothing restores `provider.request`),
+ * and its closure holds the instance that installed it - whose event queue
+ * is CLOSED after cleanup. Without this slot, a rebuilt instance saw
+ * "already wrapped", reported success, and every request-derived event
+ * silently died in the old instance's queue. The slot holds the LIST of
+ * instances that registered this provider, in registration order; the
+ * wrapper routes each call to the newest one still live. A list rather
+ * than a single ref for two reasons: with several live instances (multi
+ * write-key pages) a cleanup degrades to newest-live-wins instead of
+ * dead-instance-wins, and the list is attached at install time, so
+ * rebinding mutates it and works even on a provider frozen AFTER wrapping.
+ */
+export declare const WRAPPED_REQUEST_OWNER_SYMBOL: unique symbol;
 export interface WrappedEIP1193Provider extends EIP1193Provider {
     [WRAPPED_REQUEST_REF_SYMBOL]?: WrappedRequestFunction;
 }

package/dist/esm/src/types/provider.js

@@ -1,3 +1,19 @@
 export var WRAPPED_REQUEST_SYMBOL = Symbol("formoWrappedRequest");
 export var WRAPPED_REQUEST_REF_SYMBOL = Symbol("formoWrappedRequestRef");
+/**
+ * The SDK instance a provider's installed wrapper currently reports to.
+ *
+ * The wrapper survives an SDK rebuild (nothing restores `provider.request`),
+ * and its closure holds the instance that installed it - whose event queue
+ * is CLOSED after cleanup. Without this slot, a rebuilt instance saw
+ * "already wrapped", reported success, and every request-derived event
+ * silently died in the old instance's queue. The slot holds the LIST of
+ * instances that registered this provider, in registration order; the
+ * wrapper routes each call to the newest one still live. A list rather
+ * than a single ref for two reasons: with several live instances (multi
+ * write-key pages) a cleanup degrades to newest-live-wins instead of
+ * dead-instance-wins, and the list is attached at install time, so
+ * rebinding mutates it and works even on a provider frozen AFTER wrapping.
+ */
+export var WRAPPED_REQUEST_OWNER_SYMBOL = Symbol("formoWrappedRequestOwner");
 //# sourceMappingURL=provider.js.map

package/dist/esm/src/version.d.ts

@@ -1,2 +1,2 @@
-export declare const version = "1.36.0";
+export declare const version = "1.38.0";
 //# sourceMappingURL=version.d.ts.map

package/dist/esm/src/version.js

@@ -1,4 +1,4 @@
 // This file is auto-generated by scripts/update-version.js during npm version
 // Do not edit manually - it will be overwritten
-export var version = '1.36.0';
+export var version = '1.38.0';
 //# sourceMappingURL=version.js.map

package/dist/esm/src/wagmi/WagmiEventHandler.d.ts

@@ -96,6 +96,8 @@ export declare class WagmiEventHandler {
      * broadcast to match the receipt against.
      */
     private get pendingTransactions();
+    /** Broadcast batches awaiting `callsStatus`, shared like the map above. */
+    private get pendingBatches();
     constructor(formoAnalytics: FormoAnalytics, wagmiConfig: WagmiConfig, queryClient?: QueryClient);
     /**
      * Set up listeners for wallet connection, disconnection, and chain changes
@@ -202,6 +204,7 @@ export declare class WagmiEventHandler {
      * already recorded the new address synchronously by the time this runs. The
      * `lastAddress` check below is what makes the two paths mutually exclusive.
      */
+    private handleActiveAddressChangeEntryKick;
     private handleActiveAddressChange;
     /**
      * Record and emit a chain move for the wallet already being tracked.
@@ -228,6 +231,30 @@ export declare class WagmiEventHandler {
      * Handle query cache events (transaction confirmations)
      */
     private handleQueryEvent;
+    /**
+     * Settle a just-registered batch from a status query that already ran.
+     *
+     * Best-effort by design: the minimal QueryClient interface the SDK
+     * accepts is not guaranteed to expose cache lookup, and a missing
+     * `getAll` just means settlement waits for the next query event, which
+     * is where it normally comes from anyway.
+     */
+    private settleFromCachedCallsStatus;
+    /**
+     * Settle an EIP-5792 batch from a `callsStatus` query.
+     *
+     * Only batches whose broadcast this SDK observed are settled: the batch id
+     * must be in `pendingBatches`, for the same reason receipt queries are
+     * gated on an observed hash - queries are visible to any code sharing the
+     * QueryClient, and emitting for an id we never saw broadcast would let a
+     * forged query invent transactions.
+     *
+     * Outcome semantics are shared with the EIP-1193 path (`src/evm/batch.ts`):
+     * per-call receipts outrank the batch verdict, an atomic batch's single
+     * receipt reaches every call, and a 600 leaves receipt-less calls
+     * unsettled rather than guessed.
+     */
+    private handleCallsStatusQuery;
     /**
      * Handle waitForTransactionReceipt query completion
      * Emits CONFIRMED or REVERTED transaction status
@@ -240,11 +267,48 @@ export declare class WagmiEventHandler {
     /**
      * Handle signature mutations (signMessage, signTypedData)
      */
+    /**
+     * Is a PENDING wagmi mutation already covering this wallet request?
+     *
+     * The hybrid-capture dedup. TanStack dispatches `pending` BEFORE the
+     * mutationFn issues the wallet call (verified against query-core), so a
+     * hook-driven request always finds its mutation here and the request
+     * wrapper stands down; an imperative viem call never does, and the
+     * wrapper captures it. Matching is by mutation type, refined with cheap
+     * parameter checks where the shapes allow, and errs toward NOT skipping:
+     * a duplicate is visible and diagnosable, a silent loss is neither.
+     */
+    hasMatchingPendingMutation(method: string, params: unknown[]): boolean;
+    /**
+     * Wallet attribution for mutation- and query-derived events.
+     *
+     * Mid-session events (signatures, transactions) fire after the peer
+     * lookup has resolved, so a WalletConnect connector names its actual
+     * signer here - the first observable consumer of the peer cache.
+     */
+    private mutationAttribution;
     private handleSignatureMutation;
     /**
      * Handle transaction mutations (sendTransaction, writeContract)
      */
     private handleTransactionMutation;
+    /**
+     * One `transaction` event per call in an EIP-5792 batch, wagmi path.
+     *
+     * Mirrors `EvmRequestTracker.trackBatchedCalls` exactly: the CALL is the
+     * unit of attribution, so each call gets its own STARTED at pending and
+     * BROADCASTED (with `batch_id`) when the wallet returns an id. The batch's
+     * on-chain outcome arrives through the `callsStatus` query, handled in
+     * `handleCallsStatusQuery`.
+     *
+     * Rejection matches the 1193 path's rule: only a user rejection (4001
+     * anywhere in the error chain) marks the calls rejected - one dismissal
+     * dismisses the whole prompt, so every call in it is rejected, and
+     * reporting only the first would undercount. Any other error (a wallet
+     * without EIP-5792 support, a transport failure) emits nothing further:
+     * inventing a rejection the user never made would be worse.
+     */
+    private handleSendCallsMutation;
     /**
      * Get the current Wagmi state
      * Supports both getState() method and direct state property access
@@ -277,6 +341,29 @@ export declare class WagmiEventHandler {
      * Get the connector name from Wagmi state
      */
     private getConnectorName;
+    /**
+     * Start resolving the wallet behind a WalletConnect connection.
+     *
+     * Fire-and-forget on purpose: emission paths are synchronous by design
+     * and must never wait (see the connect marker comment). Called at the
+     * START of the status/address flows rather than only at read time - the
+     * lookup is one microtask for an initialised connector, and the emission
+     * sits behind several awaits, so kicking early usually means even the
+     * FIRST connect names the real wallet. When the race is lost the event
+     * honestly says "WalletConnect" and every later event names the peer.
+     */
+    /**
+     * Install the request wrapper on the active connector's provider.
+     *
+     * This is what lets wagmi mode capture IMPERATIVE viem calls
+     * (walletClient.sendTransaction / .signMessage / .writeContract / raw
+     * request), which create no mutation and were silently lost. Hook-driven
+     * calls stay owned by the mutation handlers via the pending-mutation
+     * dedup. Fire-and-forget per connection; a provider that cannot be
+     * produced simply keeps mutation-only capture.
+     */
+    private wrapActiveConnectorProvider;
+    private kickWalletConnectPeerLookup;
     /**
      * Clean up all subscriptions
      */