import { InternalizeActionArgs } from '@bsv/sdk';
import { Wallet } from '../../Wallet';
import { AuthId, StorageInternalizeActionResult } from '../../sdk/WalletStorage.interfaces';
/**
 * Internalize Action allows a wallet to take ownership of outputs in a pre-existing transaction.
 * The transaction may, or may not already be known to both the storage and user.
 *
 * Two types of outputs are handled: "wallet payments" and "basket insertions".
 *
 * A "basket insertion" output is considered a custom output and has no effect on the wallet's "balance".
 *
 * A "wallet payment" adds an outputs value to the wallet's change "balance". These outputs are assigned to the "default" basket.
 *
 * Processing starts with simple validation and then checks for a pre-existing transaction.
 * If the transaction is already known to the user, then the outputs are reviewed against the existing outputs treatment,
 * and merge rules are added to the arguments passed to the storage layer.
 *
 * The existing transaction's `status` determines what the merge path does next:
 *  - `'unproven'`, `'completed'`, or `'sending'`: outputs are merged; status is left as-is.
 *    The `'sending'` case covers a transaction this wallet already signed and handed to broadcast processing, but
 *    whose proven_tx_req has not yet been advanced by the normal monitor/posting flow.
 *  - `'nosend'`: the `internalizeAction` call is treated as explicit authorization to advance the lifecycle.
 *    `transactions.status` is promoted to `'completed'` (BUMP-bearing BEEF) or `'unproven'` (otherwise), and the
 *    `proven_tx_req` is moved out of `'nosend'` so Monitor's proof-fetching flow can finalize it. See storage-layer
 *    `internalizeAction` docs for the full rationale.
 *  - Any other status: an error.
 *
 * When the transaction already exists, the description is updated. The isOutgoing sense is not changed.
 *
 * "basket insertion" Merge Rules:
 * 1. The "default" basket may not be specified as the insertion basket.
 * 2. A change output in the "default" basket may not be target of an insertion into a different basket.
 * 3. These baskets do not affect the wallet's balance and are typed "custom".
 *
 * "wallet payment" Merge Rules:
 * 1. Targetting an existing change "default" basket output results in a no-op. No error. No alterations made.
 * 2. Targetting a previously "custom" non-change output converts it into a change output. This alters the transaction's `amount`, and the wallet balance.
 *
 */
export declare function internalizeAction(wallet: Wallet, auth: AuthId, args: InternalizeActionArgs): Promise<StorageInternalizeActionResult>;
//# sourceMappingURL=internalizeAction.d.ts.map