/**
 * Stellar Vault Actions
 *
 * Builds unsigned Soroban transactions for vault deposit/redeem operations.
 * Returns assembled XDR (base64) for wallet signing (e.g. Freighter).
 */
import type { IStellarDepositParams, IStellarRedeemParams } from './types';
/**
 * Deposit assets into a Stellar vault (self-deposit).
 *
 * Builds an unsigned Soroban transaction invoking the vault's `deposit` function.
 * All three address roles (receiver, from, operator) are set to senderAddress.
 *
 * Contract signature: deposit(assets: i128, receiver: Address, from: Address, operator: Address) -> i128
 *
 * @returns Base64-encoded XDR of the unsigned transaction, ready for wallet signing.
 */
export declare function handleStellarDeposit(params: IStellarDepositParams): Promise<string>;
/**
 * Build an unsigned self-redeem Soroban transaction (receiver, owner, and
 * operator all = `receiverAddress`). Assumes the deployed vault exposes
 * `redeem(shares: i128, receiver, owner, operator) -> i128`; divergence
 * surfaces as a generic Soroban simulation error.
 *
 * Side effect on failure: when the *vault* cannot serve the redemption — it
 * rejected the call, or its ledger state needs restoring — the failure is
 * reported to that vault's curator. Stellar vaults are instant-redeem only, so
 * this is the curator's only signal that their depositors cannot get out.
 * Fire-and-forget and deduped; see
 * {@link reportRedeemFailure} and {@link REPORTED_BUILD_STAGES}.
 *
 * Note this includes a caller-caused rejection such as redeeming more shares
 * than the wallet holds: the contract trapping is what we can observe, and
 * telling that apart from a vault-side problem needs the vault's error
 * taxonomy. A bad address, an unfunded account, and an exhausted RPC failover
 * are excluded — none of those reached the vault.
 *
 * @returns Base64-encoded XDR ready for wallet signing; pass the signed
 *   XDR to {@link submitStellarTransaction}.
 */
export declare function handleStellarRedeem(params: IStellarRedeemParams): Promise<string>;