import type { CurrencyConfig } from '../config';
import type { CoinModuleApi, Memo, MemoNotSupported, TxData, TxDataNotSupported } from './types';
/**
 * A full {@link CoinModuleApi} whose every capability is a "not supported" stub.
 *
 * Spread it and override what the chain does support, for a module that would rather
 * satisfy the complete contract directly than declare a `CoinModuleImpl` and be widened by
 * `withDefaults`:
 *
 * ```ts
 * export function createApi() {
 *   return {
 *     ...notSupportedApi<MyConfig>(),
 *     lastBlock, getBalance, listOperations,
 *   } satisfies CoinModuleApi<MyConfig>
 * }
 * ```
 *
 * The two styles interoperate rather than compete, because the stubs are tagged: a value
 * built this way still tells the truth through `withDefaults`'s `supports()`, which treats a
 * tagged stub as an omitted method rather than as an implementation. So a module may be
 * authored either way, wrapped either way, and reports the same capabilities.
 *
 * It is also what a module can use when it does not implement everything the authoring type
 * requires — a read-only module, or a chain with no crafting path. The contract is satisfied
 * statically, and what the chain does not do stays visible at the definition site.
 *
 * `getAccountInfo` is the one method that does not throw: per ADR-045 a chain carrying no
 * extra account metadata is an answer, not a missing capability, so it resolves the
 * `{ type: 'none' }` sentinel — the same default `withDefaults` supplies. `listFeeOptions` is
 * left absent, likewise matching `withDefaults`.
 *
 * The return type is the contract itself, so a method added to `CoinModuleApi` makes this
 * fail to compile until it is covered here.
 */
export declare function notSupportedApi<ConfigType extends CurrencyConfig, MemoType extends Memo = MemoNotSupported, TxDataType extends TxData = TxDataNotSupported>(): CoinModuleApi<ConfigType, MemoType, TxDataType>;
//# sourceMappingURL=notSupportedApi.d.ts.map