@umbra-privacy/sdk 1.0.0

package/dist/constants/index.d.ts

@@ -0,0 +1,739 @@
+export { A as AltEntry, N as NetworkConfig, g as getNetworkConfig } from '../networks-C-orpSFW.js';
+export { A as AlgorithmVersion, a as AlgorithmVersionSpecifierFunction, D as DEFAULT_ALGORITHM_VERSION, b as DEFAULT_NETWORK, c as DEFAULT_PROTOCOL_VERSION, d as DEFAULT_SCHEME_VERSION, N as Network, e as NetworkSpecifierFunction, P as ProtocolVersion, f as ProtocolVersionSpecifierFunction, S as SchemeVersion, g as SchemeVersionSpecifierFunction, h as assertNetwork, i as assertValidAlgorithmVersion, j as assertValidProtocolVersion, k as assertValidSchemeVersion, l as assertValidVersion, m as getDefaultAlgorithmVersion, n as getDefaultProtocolVersion, o as getDefaultSchemeVersion, p as getNetworkSpecifier } from '../versions-D9PqsEvj.js';
+import { Address } from '@solana/kit';
+import '../cryptography-BTGC72u-.js';
+
+/**
+ * Arcium Protocol Constants
+ *
+ * This module contains constants for interacting with the Arcium protocol,
+ * including the program address and PDA seed prefixes for various account types.
+ *
+ * @module constants/arcium
+ */
+/**
+ * Seed prefix for MXE account PDAs.
+ *
+ * @remarks
+ * Used to derive the MXE account address for a given program.
+ */
+declare const ARCIUM_MXE_ACCOUNT_SEED = "MXEAccount";
+/**
+ * Seed prefix for mempool account PDAs.
+ *
+ * @remarks
+ * The mempool stores pending computations for a cluster.
+ */
+declare const ARCIUM_MEMPOOL_SEED = "Mempool";
+/**
+ * Seed prefix for executing pool account PDAs.
+ *
+ * @remarks
+ * The executing pool tracks computations currently being processed.
+ */
+declare const ARCIUM_EXEC_POOL_SEED = "Execpool";
+/**
+ * Seed prefix for computation account PDAs.
+ *
+ * @remarks
+ * Each computation gets its own account to track state and results.
+ */
+declare const ARCIUM_COMPUTATION_SEED = "ComputationAccount";
+/**
+ * Seed prefix for computation definition account PDAs.
+ *
+ * @remarks
+ * Computation definitions describe the circuit/program to be executed.
+ */
+declare const ARCIUM_COMP_DEF_SEED = "ComputationDefinitionAccount";
+/**
+ * Seed prefix for cluster account PDAs.
+ *
+ * @remarks
+ * Clusters are groups of MXE nodes that process computations together.
+ */
+declare const ARCIUM_CLUSTER_SEED = "Cluster";
+/**
+ * Buffer size for cluster/computation offsets in bytes.
+ *
+ * @remarks
+ * Offsets are encoded as 4-byte little-endian unsigned integers.
+ */
+declare const ARCIUM_OFFSET_BUFFER_SIZE = 4;
+
+/**
+ * Domain Separator Constants
+ *
+ * Domain separators for cryptographic operations in claim functions.
+ * These are used as keys in KMAC256 for domain separation.
+ *
+ * @module constants/domain-separators
+ */
+/**
+ * Types of claim operations that require domain separators.
+ */
+type ClaimType = "SelfClaimableUtxoIntoPublicBalance" | "SelfClaimableUtxoIntoEncryptedBalance" | "ReceiverClaimableUtxoIntoEncryptedBalance";
+/**
+ * Domain separator pair for claim operations.
+ */
+interface ClaimDomainSeparators {
+    /** Domain separator for modified generation index derivation */
+    readonly MODIFIED_GEN_INDEX: string;
+    /** Domain separator for expanded generation index derivation */
+    readonly EXPANDED_GEN_INDEX: string;
+}
+/**
+ * Creates domain separators for a specific claim type.
+ *
+ * @param claimType - The type of claim operation
+ * @returns Domain separator pair for the claim type
+ */
+declare function createClaimDomainSeparators(claimType: ClaimType): ClaimDomainSeparators;
+/**
+ * Pre-built domain separators for all claim types.
+ */
+declare const CLAIM_DOMAINS: {
+    /** Domain separators for self-claimable UTXO claims into public balance */
+    readonly SELF_CLAIMABLE_INTO_PUBLIC_BALANCE: ClaimDomainSeparators;
+    /** Domain separators for self-claimable UTXO claims into encrypted balance */
+    readonly SELF_CLAIMABLE_INTO_ENCRYPTED_BALANCE: ClaimDomainSeparators;
+    /** Domain separators for receiver-claimable UTXO claims into encrypted balance */
+    readonly RECEIVER_CLAIMABLE_INTO_ENCRYPTED_BALANCE: ClaimDomainSeparators;
+};
+/**
+ * Domain separators for linker keystream blinding factor derivation.
+ */
+declare const LINKER_KEYSTREAM_DOMAINS: {
+    /** Self-claimable UTXO claim into public balance */
+    readonly SELF_CLAIMABLE_INTO_PUBLIC_BALANCE: "selfClaimableUtxoIntoPublicBalance / linkerKeystreamBlindingFactor";
+    /** Receiver-claimable UTXO claim into encrypted balance (also used for self-claimable into encrypted balance) */
+    readonly RECEIVER_CLAIMABLE_INTO_ENCRYPTED_BALANCE: "receiverClaimableUtxoIntoEncryptedBalance / linkerKeystreamBlindingFactor";
+};
+/**
+ * Domain separators for random factor generation in polynomial commitment.
+ */
+declare const RANDOM_FACTOR_DOMAINS: {
+    /** Self-claimable UTXO claim into public balance */
+    readonly SELF_CLAIMABLE_INTO_PUBLIC_BALANCE: "selfClaimableUtxoIntoPublicBalance / randomFactorForPolynomialCommitment";
+    /** Receiver-claimable UTXO claim into encrypted balance (also used for self-claimable into encrypted balance) */
+    readonly RECEIVER_CLAIMABLE_INTO_ENCRYPTED_BALANCE: "receiverClaimableUtxoIntoEncryptedBalance / randomFactorForPolynomialCommitment";
+};
+/**
+ * Domain separators for rescue encryption commitment blinding factor derivation.
+ */
+declare const RESCUE_COMMITMENT_DOMAINS: {
+    /** Self-claimable UTXO claim into public balance */
+    readonly SELF_CLAIMABLE_INTO_PUBLIC_BALANCE: "selfClaimableUtxoIntoPublicBalance / rescueEncryptionCommitmentBlindingFactor";
+    /** Receiver-claimable UTXO claim into encrypted balance (also used for self-claimable into encrypted balance) */
+    readonly RECEIVER_CLAIMABLE_INTO_ENCRYPTED_BALANCE: "receiverClaimableUtxoIntoEncryptedBalance / rescueEncryptionCommitmentBlindingFactor";
+};
+
+/**
+ * Encryption Count Constants
+ *
+ * Constants for encryption operations in claim circuits.
+ *
+ * @module constants/encryption-counts
+ */
+/**
+ * Number of linker encryptions per leaf for different claim types.
+ */
+declare const LINKER_ENCRYPTIONS_PER_LEAF: {
+    /**
+     * ATA claims - excludes amount encryption (amounts are public).
+     * Encrypts: senderAddressLow, senderAddressHigh, mintAddressLow, mintAddressHigh, leafCommitment
+     */
+    readonly INTO_ATA: 5;
+    /**
+     * ETA claims - includes amount encryption.
+     * Encrypts: senderAddressLow, senderAddressHigh, amount, mintAddressLow, mintAddressHigh, leafCommitment
+     */
+    readonly INTO_ETA: 6;
+};
+/**
+ * Number of rescue cipher encryptions for different claim types.
+ */
+declare const RESCUE_ENCRYPTIONS_COUNT: {
+    /**
+     * ATA claims - no fee encryption (amounts are public).
+     * Encrypts: mvkLow, mvkHigh, randomFactorLow, randomFactorHigh
+     */
+    readonly WITHOUT_FEES: 4;
+    /**
+     * ETA claims - includes fee encryption.
+     * Encrypts: finalAmount, protocolFees, relayerFees, mvkLow, mvkHigh, randomFactorLow, randomFactorHigh
+     */
+    readonly WITH_FEES: 7;
+};
+/**
+ * KMAC256 output length for 512-bit (64 bytes) output.
+ */
+declare const KMAC_512_OUTPUT_LENGTH = 64;
+/**
+ * Number of elements in the public aggregated hash input array.
+ */
+declare const AGGREGATED_HASH_INPUT_COUNT: {
+    /** ATA claims use 45 elements */
+    readonly ATA: 45;
+    /** ETA claims use 70 elements */
+    readonly ETA: 70;
+};
+
+/**
+ * Solana Program Constants.
+ *
+ * This module defines well-known Solana program addresses and utility helpers
+ * used throughout the Umbra SDK. All addresses are typed as `Address` from
+ * `@solana/kit` and validated at module load time by the `address()` constructor,
+ * ensuring any typo is caught immediately rather than at runtime.
+ *
+ * @remarks
+ * The constants are organized into three groups:
+ *
+ * - **Token program IDs** — {@link SPL_TOKEN_PROGRAM_ID} (legacy) and
+ *   {@link TOKEN_2022_PROGRAM_ID} (extensions). Use the owner field of a
+ *   token account to determine which program governs it.
+ *
+ * - **System programs** — {@link SYSTEM_PROGRAM_ID} (SOL transfers and account
+ *   creation) and {@link ASSOCIATED_TOKEN_PROGRAM_ID} (deterministic ATA
+ *   derivation).
+ *
+ * - **Compute Budget** — {@link COMPUTE_BUDGET_PROGRAM_ADDRESS} and the
+ *   {@link createSetComputeUnitLimitInstruction} helper for raising the per-
+ *   transaction compute unit cap on Umbra's heavier MPC operations.
+ *
+ * @packageDocumentation
+ */
+
+/**
+ * SPL Token Program ID (legacy token program).
+ *
+ * The original SPL Token program that handles standard fungible and non-fungible
+ * tokens on Solana. Most established tokens (USDC, BONK, SOL-wrapped assets,
+ * etc.) use this program.
+ *
+ * @remarks
+ * This program does NOT support extensions such as transfer fees, interest
+ * bearing tokens, or confidential transfers. For tokens that require those
+ * features, see {@link TOKEN_2022_PROGRAM_ID}.
+ *
+ * Use the `owner` field of an on-chain token account to determine which program
+ * governs it:
+ * - `owner === SPL_TOKEN_PROGRAM_ID` → legacy token account
+ * - `owner === TOKEN_2022_PROGRAM_ID` → token-2022 account
+ *
+ * @example
+ * ```typescript
+ * import { SPL_TOKEN_PROGRAM_ID } from "@umbra-privacy/sdk";
+ *
+ * // Determine which token program owns an account
+ * if (tokenAccount.owner === SPL_TOKEN_PROGRAM_ID) {
+ *   console.log("Legacy SPL token account — no transfer fees possible");
+ * }
+ * ```
+ *
+ * @see {@link TOKEN_2022_PROGRAM_ID} for the newer token extensions program
+ * @public
+ */
+declare const SPL_TOKEN_PROGRAM_ID: Address;
+/**
+ * Token-2022 Program ID (token extensions program).
+ *
+ * The successor to the original SPL Token program. Token-2022 (also called
+ * "Token Extensions") supports a rich set of optional mint and account
+ * extensions that enable advanced token mechanics. Each extension is packed
+ * into the account data after the standard token fields.
+ *
+ * @remarks
+ * Umbra SDK pays special attention to the **Transfer Fee** extension because it
+ * affects the amount that arrives at the destination after a transfer. When
+ * depositing a Token-2022 token with active transfer fees, the SDK must
+ * calculate the gross amount (net + fee) so the protocol account receives the
+ * intended net amount.
+ *
+ * The active fee schedule is determined by the current epoch: if
+ * `currentEpoch >= newerTransferFee.epoch`, the newer schedule is active;
+ * otherwise the older schedule applies. Use {@link GetEpochInfo} to fetch the
+ * current epoch before performing this calculation.
+ *
+ * Supported extensions include (but are not limited to):
+ * - Transfer Fee — automatic fee withheld on every transfer
+ * - Interest Bearing — token balances that accrue interest over time
+ * - Non-Transferable — soulbound tokens that cannot be transferred
+ * - Permanent Delegate — irrevocable delegate authority on every account
+ * - Transfer Hook — arbitrary CPI called on every transfer
+ * - Metadata — on-chain token metadata embedded in the mint account
+ * - Confidential Transfer — zero-knowledge balance hiding
+ *
+ * @example
+ * ```typescript
+ * import { TOKEN_2022_PROGRAM_ID } from "@umbra-privacy/sdk";
+ *
+ * // Check if a mint is governed by Token-2022 before parsing extensions
+ * if (mintAccount.owner === TOKEN_2022_PROGRAM_ID) {
+ *   const feeConfig = extractTransferFeeConfig(mintAccount.data);
+ *   if (feeConfig) {
+ *     console.log("Mint has transfer fees — adjust deposit amount accordingly");
+ *   }
+ * }
+ * ```
+ *
+ * @see {@link SPL_TOKEN_PROGRAM_ID} for the legacy token program
+ * @public
+ */
+declare const TOKEN_2022_PROGRAM_ID: Address;
+/**
+ * Solana System Program ID.
+ *
+ * The native Solana program at address `11111111111111111111111111111111` is
+ * responsible for the fundamental account management operations on the network:
+ * creating new accounts, allocating data space, assigning account ownership, and
+ * transferring lamports (SOL).
+ *
+ * @remarks
+ * Every Solana account that is not yet initialized is implicitly owned by the
+ * System Program. Anchor programs typically transfer ownership to their own
+ * program ID during the `init` instruction by using the System Program's
+ * `createAccount` or `createAccountWithSeed` instructions.
+ *
+ * In Umbra SDK transaction building, the System Program is included in account
+ * metas whenever a new on-chain account needs to be created (e.g., initializing
+ * a user's encrypted token account or a pool).
+ *
+ * @example
+ * ```typescript
+ * import { SYSTEM_PROGRAM_ID } from "@umbra-privacy/sdk";
+ *
+ * // Include the System Program when an instruction may create accounts
+ * const accounts = [
+ *   { address: payer, role: AccountRole.WRITABLE_SIGNER },
+ *   { address: newAccount, role: AccountRole.WRITABLE },
+ *   { address: SYSTEM_PROGRAM_ID, role: AccountRole.READONLY },
+ * ];
+ * ```
+ *
+ * @public
+ */
+declare const SYSTEM_PROGRAM_ID: Address;
+/**
+ * Associated Token Account Program ID.
+ *
+ * The Associated Token Account (ATA) program provides a canonical, deterministic
+ * token account address for any `(wallet, mint, tokenProgram)` triple. Because
+ * the address is fully derived from public inputs, any party can compute it
+ * without coordination, making ATAs the de facto standard for token accounts on
+ * Solana.
+ *
+ * @remarks
+ * The ATA address for a given wallet and mint is derived via PDA seeds:
+ * `[wallet, tokenProgramId, mint]` under the ATA program. This derivation is
+ * deterministic — the same inputs always produce the same address.
+ *
+ * When sending tokens to a user for the first time, the sender or a relayer
+ * typically creates the recipient's ATA using the ATA program's `create`
+ * instruction if it does not already exist. The `getOrCreateAssociatedTokenAccount`
+ * pattern is common in Umbra's public (non-confidential) token flows.
+ *
+ * @example
+ * ```typescript
+ * import { ASSOCIATED_TOKEN_PROGRAM_ID } from "@umbra-privacy/sdk";
+ *
+ * // Include when an instruction may create an ATA
+ * const accounts = [
+ *   { address: ASSOCIATED_TOKEN_PROGRAM_ID, role: AccountRole.READONLY },
+ * ];
+ * ```
+ *
+ * @public
+ */
+declare const ASSOCIATED_TOKEN_PROGRAM_ID: Address;
+/**
+ * Solana Compute Budget Program ID.
+ *
+ * The Compute Budget program allows transactions to modify their compute unit
+ * limit and compute unit price. These settings affect transaction prioritization
+ * and whether a transaction will succeed within the default compute cap.
+ *
+ * @remarks
+ * Umbra's MPC-backed instructions (encrypted deposits, transfers, claims) are
+ * computation-heavy and regularly exceed the default 200,000 compute unit limit.
+ * Transactions that include such instructions must prepend a
+ * `SetComputeUnitLimit` instruction using {@link createSetComputeUnitLimitInstruction}
+ * to raise the cap before the Umbra instruction runs.
+ *
+ * @see {@link createSetComputeUnitLimitInstruction} for the helper that builds
+ *   the `SetComputeUnitLimit` instruction targeting this program
+ * @public
+ */
+declare const COMPUTE_BUDGET_PROGRAM_ADDRESS: Address;
+/**
+ * Creates a `SetComputeUnitLimit` instruction for the Solana Compute Budget program.
+ *
+ * Compute Budget instruction discriminator `2` tells the runtime to override the
+ * default per-transaction compute unit limit (200,000 CU) with the specified
+ * `units` value. The instruction must appear before any instructions that need
+ * the higher limit, typically as the first instruction in the transaction.
+ *
+ * @remarks
+ * **Encoding** — The instruction data is 5 bytes:
+ * - Byte 0: discriminator `2` (SetComputeUnitLimit)
+ * - Bytes 1–4: `units` encoded as a little-endian `u32`
+ *
+ * **No accounts** — This instruction requires no account inputs; the `accounts`
+ * field is always an empty tuple.
+ *
+ * **Umbra usage** — Umbra's confidential instructions (encrypted deposits,
+ * transfers, claims) are compute-intensive due to ZK proof verification and
+ * Arcium MPC bookkeeping. The SDK prepends this instruction to those transactions
+ * with a limit of 1,400,000 CU (the maximum allowed per transaction as of this
+ * writing).
+ *
+ * **Maximum value** — The maximum allowed compute unit limit per transaction is
+ * 1,400,000. Requesting more will cause the transaction to fail at preflight.
+ *
+ * @param units - The desired compute unit limit. Must be a non-negative integer
+ *   no greater than 1,400,000. Values are encoded as little-endian `u32`.
+ * @returns A plain instruction object with:
+ *   - `programAddress`: {@link COMPUTE_BUDGET_PROGRAM_ADDRESS}
+ *   - `data`: 5-byte `Uint8Array` encoding the `SetComputeUnitLimit` payload
+ *   - `accounts`: an empty readonly tuple (no accounts needed)
+ *
+ * @example
+ * Adding a compute unit limit to a transaction message:
+ * ```typescript
+ * import { createSetComputeUnitLimitInstruction } from "@umbra-privacy/sdk";
+ * import { appendTransactionMessageInstruction } from "@solana/kit";
+ *
+ * const cuLimitIx = createSetComputeUnitLimitInstruction(1_400_000);
+ *
+ * const txMessage = appendTransactionMessageInstruction(cuLimitIx, baseMessage);
+ * ```
+ *
+ * @example
+ * Checking the serialized instruction bytes:
+ * ```typescript
+ * const ix = createSetComputeUnitLimitInstruction(300_000);
+ * // ix.data === Uint8Array [2, 224, 147, 4, 0]
+ * // 300000 = 0x493E0 → LE bytes: 0xE0, 0x93, 0x04, 0x00
+ * ```
+ *
+ * @see {@link COMPUTE_BUDGET_PROGRAM_ADDRESS} for the program address used
+ * @public
+ */
+declare function createSetComputeUnitLimitInstruction(units: number): {
+    programAddress: Address;
+    data: Uint8Array;
+    accounts: readonly [];
+};
+
+/**
+ * Umbra Protocol Constants
+ *
+ * Defines the configuration constants used when building and validating Umbra protocol
+ * instructions on the client side. These constants mirror on-chain values defined in the
+ * Anchor program (`programs/umbra/src/`) and must be kept in sync with that source of
+ * truth.
+ *
+ * ## Sections
+ *
+ * - **Message signing** — the canonical warning text presented to users before their
+ *   wallet signature is used to derive the master private key.
+ * - **Protocol fee configuration** — the fee schedule applied to the protocol's share
+ *   of each claim or transfer. Set by program admin, enforced on-chain.
+ * - **Relayer fee configuration** — the fee schedule applied to the relayer's commission
+ *   on claim and transfer instructions. Set per-relayer.
+ * - **Fee offset configuration** — the `offset` discriminators used when deriving PDAs
+ *   for fee-related accounts.
+ * - **BPS divisor** — the basis-point denominator used in fee arithmetic.
+ *
+ * @packageDocumentation
+ * @module umbra/constants
+ */
+/**
+ * Canonical message shown to the user before their wallet signature is requested for
+ * master key derivation.
+ *
+ * @remarks
+ * Signing this message is the root of the user's key hierarchy. The resulting signature
+ * is fed into the SDK's key derivation pipeline to produce the `MasterSeed`, from which
+ * all spending keys, viewing keys, and Poseidon private keys are derived.
+ *
+ * The message is deliberately verbose and alarming to ensure that:
+ * 1. Users understand the cryptographic weight of their signature.
+ * 2. Phishing sites that silently request this signature cannot hide the operation from
+ *    an attentive user.
+ *
+ * The exact string (including surrounding newlines) must not be modified without a
+ * corresponding protocol upgrade, because changing the message changes all derived keys
+ * for every existing user.
+ *
+ * @example
+ * ```typescript
+ * import { UMBRA_MESSAGE_TO_SIGN } from "@umbra-privacy/sdk";
+ * import { signMessage } from "@solana/kit";
+ *
+ * // Present to the user before requesting their signature:
+ * console.log(UMBRA_MESSAGE_TO_SIGN);
+ *
+ * // Obtain the signature and pass it to the key derivation pipeline:
+ * const signature = await signer.signMessage(
+ *   new TextEncoder().encode(UMBRA_MESSAGE_TO_SIGN)
+ * );
+ * ```
+ *
+ * @public
+ */
+declare const UMBRA_MESSAGE_TO_SIGN = "\nSigning this message is a sensitive cryptographic operation that generates the master key used to derive your private spending keys and decrypt your account balances. This signature acts as the root of your privacy and financial security within the Umbra ecosystem.\n\nYou must ensure that you are interacting with the official Umbra Privacy application or a verified integration. Signing this message on an unverified or malicious site could allow an attacker to gain full control over your funds and expose your entire transaction history.\n";
+/**
+ * Default fee schedule applied to the protocol's share of each claim or transfer
+ * instruction.
+ *
+ * @remarks
+ * These values mirror the `ProtocolFeesConfiguration` account that is written by the
+ * program admin during pool setup. The SDK uses them client-side to:
+ *
+ * 1. Pre-calculate expected fee amounts before building a transaction, so callers can
+ *    display accurate fee estimates in the UI.
+ * 2. Compute the amount of tokens the user actually receives after fees are deducted
+ *    from the claimed UTXO.
+ *
+ * The on-chain program independently validates the actual fee config account, so these
+ * client-side defaults act as a best-effort estimate rather than an authoritative source.
+ * If the admin updates fee parameters on-chain, callers should fetch the live
+ * `ProtocolFeesConfiguration` PDA and override these defaults.
+ *
+ * ## Fee formula
+ *
+ * ```
+ * fee = clamp(BASE_FEE + floor(amount * BPS / BPS_DIVISOR), LOWER_BOUND, UPPER_BOUND)
+ * ```
+ *
+ * Where `BPS_DIVISOR = 10_000n` (see {@link BPS_DIVISOR}).
+ *
+ * @example
+ * ```typescript
+ * import { PROTOCOL_FEE, BPS_DIVISOR } from "@umbra-privacy/sdk";
+ *
+ * function estimateProtocolFee(amount: bigint): bigint {
+ *   const bpsFee = (amount * PROTOCOL_FEE.BPS) / BPS_DIVISOR;
+ *   const rawFee = PROTOCOL_FEE.BASE_FEE + bpsFee;
+ *   const clamped = rawFee < PROTOCOL_FEE.LOWER_BOUND
+ *     ? PROTOCOL_FEE.LOWER_BOUND
+ *     : rawFee > PROTOCOL_FEE.UPPER_BOUND
+ *       ? PROTOCOL_FEE.UPPER_BOUND
+ *       : rawFee;
+ *   return clamped;
+ * }
+ * ```
+ *
+ * @see {@link RELAYER_FEE} for the relayer's fee schedule.
+ * @see {@link BPS_DIVISOR} for the basis-point denominator.
+ * @public
+ */
+declare const PROTOCOL_FEE: {
+    /**
+     * Fixed base fee charged per operation, denominated in the SPL token's smallest unit.
+     *
+     * @remarks
+     * Added to the proportional BPS fee before clamping. A value of `10n` means 10
+     * token micro-units (e.g. 0.00001 USDC for a 6-decimal token).
+     *
+     * @readonly
+     */
+    readonly BASE_FEE: 10n;
+    /**
+     * Proportional fee rate expressed in basis points (1 BPS = 0.01%).
+     *
+     * @remarks
+     * `35n` corresponds to 0.35%. Applied to the claimed or transferred amount before
+     * adding `BASE_FEE` and clamping to `[LOWER_BOUND, UPPER_BOUND]`.
+     *
+     * @readonly
+     */
+    readonly BPS: 35n;
+    /**
+     * Minimum fee amount. The total fee is never less than this value.
+     *
+     * @remarks
+     * Currently `0n`, meaning there is no enforced minimum beyond the `BASE_FEE`.
+     *
+     * @readonly
+     */
+    readonly LOWER_BOUND: 0n;
+    /**
+     * Maximum fee amount (cap). The total fee is never greater than this value.
+     *
+     * @remarks
+     * Set to `1_000_000n` (one million token micro-units), which equals 1 USDC for a
+     * 6-decimal token. This cap prevents runaway fees on very large claims.
+     *
+     * @readonly
+     */
+    readonly UPPER_BOUND: bigint;
+};
+/**
+ * Default fee schedule applied to the relayer's commission on each claim or transfer
+ * instruction that involves a relayer.
+ *
+ * @remarks
+ * These values mirror the `RelayerFeesConfiguration` account associated with a specific
+ * relayer. The SDK uses them client-side for fee estimation and for constructing the
+ * `expected_fee` field that is verified on-chain during MPC computation.
+ *
+ * Note that `BASE_FEE` is `0n` for relayers by default — relayers are compensated
+ * entirely through the proportional BPS component, unlike the protocol which charges a
+ * fixed base fee on top of BPS.
+ *
+ * ## Fee formula
+ *
+ * ```
+ * relayerFee = clamp(BASE_FEE + floor(amount * BPS / BPS_DIVISOR), LOWER_BOUND, UPPER_BOUND)
+ * ```
+ *
+ * @example
+ * ```typescript
+ * import { RELAYER_FEE, BPS_DIVISOR } from "@umbra-privacy/sdk";
+ *
+ * function estimateRelayerFee(amount: bigint): bigint {
+ *   const bpsFee = (amount * RELAYER_FEE.BPS) / BPS_DIVISOR;
+ *   const rawFee = RELAYER_FEE.BASE_FEE + bpsFee;
+ *   return rawFee > RELAYER_FEE.UPPER_BOUND ? RELAYER_FEE.UPPER_BOUND : rawFee;
+ * }
+ * ```
+ *
+ * @see {@link PROTOCOL_FEE} for the protocol's fee schedule.
+ * @see {@link BPS_DIVISOR} for the basis-point denominator.
+ * @public
+ */
+declare const RELAYER_FEE: {
+    /**
+     * Fixed base fee for relayer operations, denominated in the SPL token's smallest unit.
+     *
+     * @remarks
+     * `0n` — relayers do not charge a fixed base fee; they earn purely through BPS.
+     *
+     * @readonly
+     */
+    readonly BASE_FEE: 0n;
+    /**
+     * Proportional fee rate for the relayer, expressed in basis points (1 BPS = 0.01%).
+     *
+     * @remarks
+     * `35n` corresponds to 0.35%. The relayer earns this percentage of the claimed amount
+     * as compensation for submitting and funding the MPC callback transaction.
+     *
+     * @readonly
+     */
+    readonly BPS: 35n;
+    /**
+     * Minimum relayer fee. Currently `0n`.
+     *
+     * @readonly
+     */
+    readonly LOWER_BOUND: 0n;
+    /**
+     * Maximum relayer fee (cap). `1_000_000n` token micro-units.
+     *
+     * @remarks
+     * Mirrors the protocol fee cap to ensure the combined fee never exceeds a predictable
+     * maximum, protecting users from paying unexpectedly large fees on large claims.
+     *
+     * @readonly
+     */
+    readonly UPPER_BOUND: bigint;
+};
+/**
+ * Offset discriminators used when deriving PDAs for fee-related on-chain accounts.
+ *
+ * @remarks
+ * The Umbra program uses an `offset` field in PDA seeds to allow multiple independent
+ * instances of the same account type to coexist (e.g. multiple fee pools for future
+ * protocol versions). The offset is encoded as a `U128` little-endian byte array and
+ * appended as the final seed when calling `getProgramDerivedAddress`.
+ *
+ * All offsets are currently `0n` because the protocol uses a single canonical instance
+ * of each fee account type. Future upgrades may introduce non-zero offsets for versioned
+ * account sets.
+ *
+ * These values are passed directly to PDA derivation helpers such as
+ * `getProtocolOnlyUnifiedFeesPoolPda`, `getRelayerUnifiedFeesPoolPda`, and
+ * `getProtocolFeesConfigurationPda`.
+ *
+ * @example
+ * ```typescript
+ * import { FEE_OFFSETS } from "@umbra-privacy/sdk";
+ * import { getProtocolFeesConfigurationPda } from "@umbra-privacy/sdk/pda";
+ *
+ * const [feeConfigPda] = await getProtocolFeesConfigurationPda(
+ *   instructionSeed as U128,
+ *   mintAddress,
+ *   FEE_OFFSETS.PROTOCOL_FEES_CONFIG as U128,
+ *   programId,
+ * );
+ * ```
+ *
+ * @see {@link getProtocolOnlyUnifiedFeesPoolPda} for protocol-only pool PDA derivation.
+ * @see {@link getRelayerUnifiedFeesPoolPda} for relayer pool PDA derivation.
+ * @see {@link getProtocolFeesConfigurationPda} for fee config PDA derivation.
+ * @public
+ */
+declare const FEE_OFFSETS: {
+    /**
+     * Offset used in `UnifiedFeesPool` PDA derivation for the unified protocol fees pool.
+     *
+     * @remarks
+     * Passed as the final seed to `getProtocolOnlyUnifiedFeesPoolPda` and
+     * `getRelayerUnifiedFeesPoolPda`. Currently `0n`.
+     *
+     * @readonly
+     */
+    readonly PROTOCOL_FEES_POOL: 0n;
+    /**
+     * Offset used in `ProtocolFeesConfiguration` PDA derivation.
+     *
+     * @remarks
+     * Passed as the final seed to `getProtocolFeesConfigurationPda`. Currently `0n`.
+     *
+     * @readonly
+     */
+    readonly PROTOCOL_FEES_CONFIG: 0n;
+    /**
+     * Offset used in relayer fee configuration PDA derivation.
+     *
+     * @remarks
+     * Passed as the offset seed when looking up the relayer's fee configuration account.
+     * Currently `0n`.
+     *
+     * @readonly
+     */
+    readonly RELAYER_FEES_CONFIG: 0n;
+};
+/**
+ * Denominator for basis-point fee calculations.
+ *
+ * @remarks
+ * Basis points (BPS) express a fee rate as an integer fraction of 10,000.
+ * For example, 35 BPS = 35 / 10,000 = 0.35%.
+ *
+ * To convert a BPS fee rate to a proportional fee amount:
+ * ```
+ * proportionalFee = floor(amount * bps / BPS_DIVISOR)
+ * ```
+ *
+ * Using integer division (`/` on `bigint`) automatically floors the result, which is
+ * the correct behaviour for fee deductions (always round down in favour of the user).
+ *
+ * @example
+ * ```typescript
+ * import { BPS_DIVISOR, PROTOCOL_FEE } from "@umbra-privacy/sdk";
+ *
+ * const amount = 1_000_000n; // 1 USDC in micro-units
+ * const proportionalFee = (amount * PROTOCOL_FEE.BPS) / BPS_DIVISOR;
+ * // proportionalFee = 1_000_000n * 35n / 10_000n = 3_500n (0.0035 USDC)
+ * ```
+ *
+ * @public
+ */
+declare const BPS_DIVISOR = 10000n;
+
+export { AGGREGATED_HASH_INPUT_COUNT, ARCIUM_CLUSTER_SEED, ARCIUM_COMPUTATION_SEED, ARCIUM_COMP_DEF_SEED, ARCIUM_EXEC_POOL_SEED, ARCIUM_MEMPOOL_SEED, ARCIUM_MXE_ACCOUNT_SEED, ARCIUM_OFFSET_BUFFER_SIZE, ASSOCIATED_TOKEN_PROGRAM_ID, BPS_DIVISOR, CLAIM_DOMAINS, COMPUTE_BUDGET_PROGRAM_ADDRESS, type ClaimDomainSeparators, type ClaimType, FEE_OFFSETS, KMAC_512_OUTPUT_LENGTH, LINKER_ENCRYPTIONS_PER_LEAF, LINKER_KEYSTREAM_DOMAINS, PROTOCOL_FEE, RANDOM_FACTOR_DOMAINS, RELAYER_FEE, RESCUE_COMMITMENT_DOMAINS, RESCUE_ENCRYPTIONS_COUNT, SPL_TOKEN_PROGRAM_ID, SYSTEM_PROGRAM_ID, TOKEN_2022_PROGRAM_ID, UMBRA_MESSAGE_TO_SIGN, createClaimDomainSeparators, createSetComputeUnitLimitInstruction };