@formo/analytics 1.36.0 → 1.38.0

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

@@ -5,6 +5,13 @@ import { AutocaptureEventType } from "../tracking/TrackingPolicy";
 /** What the request tracker needs from the SDK that owns it. */
 export interface EvmRequestTrackerDeps {
     isAutocaptureEnabled(eventType: AutocaptureEventType): boolean;
+    /**
+     * Hybrid-capture dedup: true when a PENDING wagmi mutation already covers
+     * this request, so the mutation handler owns the capture. TanStack sets a
+     * mutation pending BEFORE its mutationFn issues the wallet call, so a
+     * hook-driven request always matches; an imperative one never does.
+     */
+    shouldSkipRequestCapture?(method: string, params: unknown[]): boolean;
     signature(params: {
         status: SignatureStatus;
         chainId?: ChainID;
@@ -23,16 +30,6 @@ export interface EvmRequestTrackerDeps {
         function_args?: Record<string, unknown>;
     }, properties?: IFormoEventProperties): Promise<void>;
 }
-/**
- * Autocapture for signatures and transactions, by wrapping a provider's
- * `request`.
- *
- * The wrapper is deliberately thin: it observes the call the dapp was already
- * making and never issues one of its own. That rule is why the chain a
- * request ran on is read from `eth_chainId` calls the app makes, rather than
- * probed - an SDK-issued lookup on a serialising transport can wedge the
- * user's wallet, which is never an acceptable price for a label.
- */
 export declare class EvmRequestTracker {
     private readonly wallet;
     private readonly registry;
@@ -50,6 +47,8 @@ export declare class EvmRequestTracker {
     constructor(wallet: WalletStateStore, registry: EvmProviderRegistry, deps: EvmRequestTrackerDeps);
     /** Stop every poll in flight. Terminal, like the event queue's close(). */
     cleanup(): void;
+    /** Providers whose owner list includes this instance; pruned on cleanup. */
+    private wrappedProviders;
     /** Re-arm a poll, unless this tracker has been torn down. */
     private schedulePoll;
     /**
@@ -59,6 +58,25 @@ export declare class EvmRequestTracker {
      * would be missed for the rest of the session.
      */
     registerRequestListeners(provider: EIP1193Provider): boolean;
+    /** Install the wrapper function onto the provider; separated so the
+     * routing shim above stays small. */
+    private installWrappedRequest;
+    /**
+     * The wrapper body proper: everything a request observation does, run
+     * against THIS instance's registry, wallet state, and event queue. Kept
+     * as a method so a surviving wrapper installed by a previous SDK
+     * instance can hand calls to the current one.
+     */
+    private dispatchWrappedRequest;
+    /**
+     * Wallet attribution for request-derived events.
+     *
+     * Live per read through the registry, so a WalletConnect session names
+     * its actual signer ("MetaMask Wallet", "Ledger Live") - the live-test
+     * rows had provider_name EMPTY on every signature and transaction, which
+     * made per-wallet activity unanswerable in the warehouse.
+     */
+    private attributionFor;
     private buildSignatureEventPayload;
     private buildTransactionEventPayload;
     /**
@@ -68,42 +86,20 @@ export declare class EvmRequestTracker {
     /**
      * One `transaction` event per call in an EIP-5792 batch.
      *
-     * A batch is not a transaction. It maps to several on-chain transactions,
-     * so reporting it as one event would understate volume and make revenue and
-     * per-contract attribution wrong for every app that adopts smart accounts.
-     * Each call is reported on its own, carrying the batch id so the calls can
-     * be reassembled downstream.
+     * The CALL is the unit of attribution: each has its own target, calldata,
+     * and value, and folding a batch into one event would misattribute revenue
+     * and per-contract activity for every app that adopts smart accounts. How
+     * many on-chain transactions a batch becomes depends on execution - an
+     * atomic batch lands as ONE transaction, a non-atomic fallback as several -
+     * so on-chain volume is `count(distinct transaction_hash)`, wallet actions
+     * `count(distinct batch_id)`, never the event count. Each call is reported
+     * on its own, carrying the batch id so the calls reassemble downstream.
      *
      * Status is per BATCH, because that is what `wallet_getCallsStatus` reports.
      * When it resolves, every call in the batch moves together, except where
      * per-call receipts say otherwise on a non-atomic batch.
      */
     private trackBatchedCalls;
-    /**
-     * 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.
-     *
-     * 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.
-     */
-    private batchCallOutcome;
-    /**
-     * 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.
-     */
-    private readBatchId;
     /**
      * Resolve a batch through `wallet_getCallsStatus`.
      *