Crate fedimint_walletv2_server

Re-exports§

db
envs
metrics 🔒
pending 🔒: The pending receive scanner: a guardian-local, non-consensus view of the receive outputs in its mempool and in the blocks just below its chain tip, served to clients so they can render peg-in progress.

BLOCK_COUNT_VOTE_DELAY: Re-exported for existing callers; the constants live in the common crate so that the client can render peg-in confirmation progress against them. How many blocks a peer’s block count vote trails its bitcoin backend: the finality delay, plus one block of slack. Processing a new consensus block count waits for the local backend to report the consensus count plus the finality delay, and without the slack that is exactly the block the voter saw, so a backend a little behind, or a backend status that is stale (it is polled once a minute), stalled item processing on every new block.
CONFIRMATION_FINALITY_DELAY: Re-exported for existing callers; the constants live in the common crate so that the client can render peg-in confirmation progress against them. Number of confirmations required for a transaction to be considered as final by the federation. The block that mines the transaction does not count towards the number of confirmations.
MAX_BLOCK_COUNT_INCREMENT 🔒: Maximum number of blocks the consensus block count can advance in a single consensus item to limit the work done in one process_consensus_item step.
MIN_FEERATE_VOTE_SATS_PER_KVB 🔒: Minimum fee rate vote of 1 sat/vB to ensure we never propose a fee rate below what Bitcoin Core will relay.
TEST_MAX_BLOCK_COUNT_INCREMENT 🔒: Devimint tests can mine many regtest blocks at once, so use a larger cap in test environments to avoid waiting on several consensus sessions.