import type { AnalyzeRisksOptions, RiskFlag, TraceFrame } from "../types.js";
/**
 * A risk rule inspects a single frame and returns zero or more findings. Rules
 * run during the call-tree walk in `analyzeRisks`; each frame is passed through
 * every registered rule. The `reverted` field is stamped on by the analyzer —
 * rules don't see or set it. Rules must be pure (no I/O) and cheap, since they
 * run once per frame.
 *
 * Returning an array (vs. a single flag) lets log-based rules report every
 * matching event on a frame — a router that emits N `Approval`s shouldn't
 * collapse into one finding.
 */
export type RiskRule = (frame: TraceFrame, depth: number, childIndex: number, options: AnalyzeRisksOptions) => Omit<RiskFlag, "reverted">[];
/**
 * Flag any DELEGATECALL whose target is not in the user-supplied whitelist.
 * Rationale: DELEGATECALL executes the callee's code in the caller's storage
 * context, giving the callee full authority over the caller's state. A
 * delegate target that isn't explicitly trusted is a high-severity finding —
 * the canonical proxy-implementation upgrade exploit shape.
 *
 * When no whitelist is supplied every delegatecall is flagged; consumers can
 * suppress known-good implementations by passing them in.
 */
export declare const delegatecallUnrecognized: RiskRule;
/**
 * Flag any ERC-20 Approval whose value is at or above the configured
 * threshold. Default threshold is `2n ** 256n - 1n` (literal "unlimited"
 * approval, the canonical phishing footgun). Pass
 * `options.largeApprovalThreshold` to lower it — `2n ** 128n` catches the
 * fake-unlimited patterns malicious frontends use to dodge naive
 * detection.
 *
 * ERC-721 Approval is filtered out by topic count (4 topics vs ERC-20's 3).
 * The `address` on the resulting flag is the spender — the party being
 * granted control — since that's what consumers care about for review.
 */
export declare const largeApproval: RiskRule;
/**
 * Flag ERC-20 Transfer events whose recipient is a token contract — funds
 * sent to a token's own contract address are functionally burned, as the
 * token contract has no mechanism to forward or recover them.
 *
 * Two cases are detected:
 *  1. Self-transfer: `to === log.address` (sending tokenA to tokenA). Caught
 *     unconditionally — it's a syntactic check, no external knowledge needed.
 *  2. Cross-token: `to` is a different token contract (sending tokenA to
 *     tokenB). Caught only when the consumer provides
 *     `options.classifyAddress`, since the SDK has no built-in registry of
 *     token contracts to consult. A typical consumer wires this to a
 *     `code(to).length > 0` + ERC-165/EIP-1820 check, or a token-list lookup.
 *
 * Severity is `warning` (not `danger`) because while the funds are unrecoverable,
 * the action is observable and self-inflicted — there's no exploit involved.
 * ERC-721/1155 share the topic hash but have different topic shapes; this
 * rule deliberately matches only the ERC-20 shape via topic-count filter.
 */
export declare const tokenSentToTokenContract: RiskRule;
/** Built-in rule registry. Order is preserved in the output `RiskFlag[]`. */
export declare const BUILTIN_RULES: readonly RiskRule[];
//# sourceMappingURL=rules.d.ts.map