import { EvmNetworkConfig, ExecutionConfig, OperationResult, TransactionStatusUpdate, TxStatus } from "@openzeppelin/ui-types";
import { Abi, Chain } from "viem";

//#region ../adapter-evm-core/dist/index-CmTidOM3.d.mts

//#region src/types/providers.d.ts
/**
 * EVM Contract Definition Provider keys and ordering
 * Avoid magic strings by using typed constants and a union type.
 */
declare const EvmProviderKeys: {
  readonly Etherscan: "etherscan";
  readonly Sourcify: "sourcify";
};
type EvmContractDefinitionProviderKey = (typeof EvmProviderKeys)[keyof typeof EvmProviderKeys];
//#endregion
//#region src/types/artifacts.d.ts
interface EvmContractArtifacts {
  /** The deployed contract address (required) */
  contractAddress: string;
  /** Optional manual ABI JSON string (for unverified contracts) */
  contractDefinition?: string;
  /** Optional proxy detection configuration */
  __proxyDetectionOptions?: {
    /** Skip automatic proxy detection */
    skipProxyDetection?: boolean;
  };
  /** Optional forced provider for this load attempt (session-scoped override) */
  __forcedProvider?: EvmContractDefinitionProviderKey;
}
/**
 * Type guard to check if an object matches EvmContractArtifacts structure
 */
declare function isEvmContractArtifacts(obj: unknown): obj is EvmContractArtifacts;
//#endregion
//#region src/types/network.d.ts
/**
 * Network configuration types for EVM-compatible networks
 */
/**
 * Base interface for any EVM-compatible network configuration.
 * This allows core functions to work with both EVM and Polkadot (and future) adapters.
 * The ecosystem field is generic to allow strict typing while maintaining flexibility.
 *
 * @typeParam E - The ecosystem type, defaults to `string` for maximum flexibility.
 *                Adapters can use specific string literals (e.g., `'polkadot'`) for stricter typing.
 *
 * @remarks
 * Core functions don't actually use the `ecosystem` field at runtime - they rely on
 * `chainId`, `rpcUrl`, and other EVM-compatible fields. This type relaxation eliminates
 * the need for adapter wrapper functions that only exist to convert types.
 *
 * @example
 * ```typescript
 * // Flexible usage (defaults to string)
 * function processConfig(config: EvmCompatibleNetworkConfig) { ... }
 *
 * // Strict typing for specific adapters
 * type PolkadotConfig = EvmCompatibleNetworkConfig<'polkadot'>;
 * ```
 */

/**
 * EVM-specific network configuration with strict `ecosystem: 'evm'` constraint
 * and strongly-typed viem `Chain` (narrowed from `unknown` in `EvmNetworkConfig`).
 *
 * Use this type in EVM-only contexts where you want strict ecosystem typing.
 * For function signatures that should accept configs from multiple adapters
 * (EVM, Polkadot, etc.), use `EvmCompatibleNetworkConfig` instead.
 */
interface TypedEvmNetworkConfig extends EvmNetworkConfig {
  viemChain?: Chain;
}
//#endregion
//#region src/types/abi.d.ts
/**
 * EVM-specific ABI type definitions
 */
/**
 * Represents an item in an Ethereum ABI
 */

/**
 * Defines the structure for parameters required to execute a contract write operation via viem.
 */
interface WriteContractParameters {
  address: `0x${string}`;
  abi: Abi;
  functionName: string;
  args: unknown[];
  value?: bigint;
}
//#endregion
//#region src/types/index.d.ts
//#endregion
//#region ../adapter-evm-core/dist/helpers-ZShvV2Sa.d.mts

//#endregion
//#region src/capabilities/helpers.d.ts
/**
 * The injected transaction-submission callback shared by every write-capable capability
 * factory (`createAccessControl`, `createIRS`, `createERC3643`, `createERC4626`, …). The
 * adapter runtime supplies this; capabilities never touch wallet/signing infrastructure
 * directly.
 *
 * ## Execution-contract conformance (FR-018 — CONFIRMED, research.md R6)
 *
 * This is the same injected-callback shape as `ExecutionCapability.signAndBroadcast`
 * (`@openzeppelin/ui-types`), whose optional `waitForTransactionConfirmation(txHash)` already
 * expresses the async submit-then-poll model the RI plugin needs. No new execution primitive
 * was added: the callback may submit and then poll internally before resolving the confirmed
 * hash, and the existing `EoaExecutionStrategy` / `RelayerExecutionStrategy` compose behind it
 * unchanged (the RI plugin's future strategy submits in-process and polls, then resolves here).
 * Capabilities stay strategy-agnostic and carry no Relayer-plugin-runtime coupling (FR-011).
 * Verified by `erc3643/__tests__/erc3643.execution-strategy.test.ts` (submit-then-poll) and
 * `erc3643.strategies.test.ts` (strategy-agnostic composition).
 */
type SignAndBroadcast = (transactionData: unknown, executionConfig: ExecutionConfig, onStatusChange: (status: TxStatus, details: TransactionStatusUpdate) => void, runtimeApiKey?: string) => Promise<{
  txHash: string;
  result?: unknown;
}>;
//#endregion
//#endregion
export { isEvmContractArtifacts as a, WriteContractParameters as i, EvmContractArtifacts as n, TypedEvmNetworkConfig as r, SignAndBroadcast as t };
//# sourceMappingURL=helpers-ZShvV2Sa-DopIiEty.d.mts.map