import type { DirectExecution } from '@funkit/api-base'; import { type Address, type WalletClient } from 'viem'; import type { MergedMultiStepDirectExecution } from '../domains/checkoutNotifications'; /** * The backend answering "no such record", rather than failing to answer at all. * Only the former says anything about the record; a network or 5xx failure says * only that we could not ask. */ export declare function isDirectExecutionNotFound(error: unknown): boolean; export declare function getDirectExecutionCreatedTimeMs(directExecution: DirectExecution): number; export declare function getDirectExecutionUpdatedTimeMs(directExecution: DirectExecution): number; /** * Unique key for a DE notification record, stable between synthetic and real record. * * When a synthetic deposit-detection DE is replaced by the real DE, the txHash * changes but triggeringTxHash stays the same. Preferring triggeringTxHash keeps * the identity stable across that swap, avoiding a flash/remount of the notification. */ export declare function getDirectExecutionNotificationKey(item: DirectExecution): string; export declare function getDirectExecutionRunTimeSeconds(directExecution: DirectExecution): number; /** * The completion hash a host can actually look up, given what * {@link getCompletionTxInfo} reported. * * - Relay echoes the DE's own `txHash` back as `toTxId` while it has no fill to * report, and the zero hash before that. Neither is linkable, and for an * account-abstraction DE `txHash` is a userOpHash no explorer serves at `/tx`. * - Cross-chain, only a real destination tx is reportable: the DE's own hash is * the *source*-chain one, and pairing it with the destination `chainId` the * screen renders would point at the wrong explorer. * - Same-chain can fall back to `onChainTxHash`, the bundle tx that delivered * the funds. * * Mirrors the backend's `resolveRollyDepositTxHash`, which leads with the same * chain check for the same reason. */ export declare function resolveOnChainCompletionTxHash(directExecution: MergedMultiStepDirectExecution, completionTxHash: string | undefined): string | undefined; /** * Resolves the completion transaction chain, hash, and explorer URL for a direct execution. * * Chain resolution: if LayerZero OFT data is present, use the LZ destination chain; * otherwise fall back to the DE's toChainId. * * Hash resolution: for Lighter L1 deposits (new user flow where toChainId is NOT Lighter), * the completion explorer should point to Lighter using lighterExecutionStatusResponse.hash. * For the existing user flow (toChainId IS Lighter), relay already puts the correct * Lighter hash into listenerInfo.txHashes, so the default path works. */ export declare function getCompletionTxInfo(directExecution: DirectExecution): { chainId: string; txHash: string | undefined; customRedirectUrl: string | undefined; }; /** * Returns a proxied wallet with getCapabilities patched to disable atomic batch support. * This forces Relay to use sequential transactions instead of batched ones. */ export declare function disableAtomicBatchIfSupported(wallet: WalletClient, chainId: number): Promise; /** * The direct execution recording an arrival at `depositAddress`, if one has * appeared since we started watching. * * - The scanner stamps the address it saw the transfer at into `sourceOfFund` * (`eoa_scanner|eoa|0x…`), the only field on a DE carrying the full address — * `clientMetadata.depositAddress` comes back null. * - A deposit address is reused by every withdrawal sharing its destination, so * `knownTxHashes` must exclude whatever was already listed when watching * began, or an earlier settled withdrawal matches as an instant success. Two * concurrent withdrawals to the same destination cannot be told apart by any * field a DE carries. */ export declare function findDirectExecutionForDepositAddress(directExecutions: MergedMultiStepDirectExecution[] | undefined, depositAddress: Address | undefined, knownTxHashes: ReadonlySet): MergedMultiStepDirectExecution | undefined; //# sourceMappingURL=directExecution.d.ts.map