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