import type { Transaction, VersionedTransaction } from '@solana/web3.js';
/**
 * The compiled message a signature actually covers. Comparing it before and
 * after a wallet call proves the wallet signed what we asked it to sign, rather
 * than something it rewrote.
 */
export declare function transactionMessageBytes(transaction: Transaction | VersionedTransaction): Uint8Array;
/**
 * Did `address` actually sign this transaction?
 *
 * Observing which account a wallet REPORTS after a call does not answer that: a
 * wallet holding several authorized accounts can keep reporting the first while
 * signing with another, and Solana Mobile discards the account a Wallet Standard
 * request names.
 *
 * Nor does a filled signature SLOT answer it. Slots are positional - the wallet
 * writes whatever it produced into the position of the required signer - so a
 * wallet that signed with another key puts THAT key's signature in this one's
 * slot, and a slot check waves it through. Only verifying the signature against
 * the message and this exact public key answers the question, which is what the
 * chain itself will do later; doing it here turns a transaction that would be
 * rejected on arrival into a refusal with a reason.
 */
export declare function transactionSignedBy(transaction: Transaction | VersionedTransaction, address: string): boolean;
/** The compiled shape both `Message` and `MessageV0` expose. */
type CompiledMessage = {
    header: {
        numRequiredSignatures: number;
    };
    staticAccountKeys: Array<{
        toBase58(): string;
    }>;
    recentBlockhash: string;
    isAccountSigner(index: number): boolean;
    isAccountWritable(index: number): boolean;
    compiledInstructions: Array<{
        programIdIndex: number;
        accountKeyIndexes: number[];
        data: Uint8Array;
    }>;
    addressTableLookups: Array<{
        accountKey: {
            toBase58(): string;
        };
        writableIndexes: number[];
        readonlyIndexes: number[];
    }>;
};
/**
 * Does the message a wallet returned still carry, intact, every instruction we
 * asked it to sign?
 *
 * ACCEPTS a wallet that added guard instructions, renumbered the account table,
 * or retuned the compute budget. REFUSES anything that touches what our
 * instructions actually do.
 *
 * ComputeBudget instructions are the one exception on OUR side: they carry no
 * accounts and cannot move value, they only price and bound the transaction, and
 * a guarding wallet has to raise the unit limit to pay for the guard it just
 * added (measured: 155670 -> 162075). Every other instruction we sent must still
 * be present, in the same relative order, with the same program, the same data
 * bytes, and the same resolved accounts.
 *
 * Returns null when the returned message is acceptable, or the reason it is not.
 */
export declare function describeInstructionDivergence(sent: CompiledMessage, returned: CompiledMessage): string | null;
export {};