Interface RedeemParams

Send a partial redemption on the first Trove drawn even when it is price fragile (MK-103).

Default false: redeem() throws RedemptionPriceFragile before spending gas when the partial would cancel, and so revert the call, on a price move smaller than the measured two block move. Set it when you have decided that the chance of a same price block is worth the gas.

MUSD to redeem for BTC (burned from the caller).

SDK-side cap on the redemption RATE, as a 1e18 scaled fraction, compared against redemptionRate(). Rate against rate: it is not a cap on the fee amount.

This is advisory and is NOT an on-chain guarantee (MK-011). redeemCollateral takes no fee cap parameter at all (TroveManager.sol:294-301), so nothing on chain enforces this, and no other MUSD write path takes one either: the full signatures in docs/01-ground-truth.md §5.1 are (amount, upperHint, lowerHint) shaped throughout. There is nothing to pass a cap to.

The race, spelled out in the order it happens: the SDK reads the rate; it compares that value against your cap and may throw; it sends. Between the read and the mine the governable rate can change, and the transaction goes through at whatever is live then. Nothing reverts. A passing check means the rate was within your cap when it was read, and nothing more. It is opt in and defaults to no cap, so the DEFAULT behavior is to accept any rate the protocol charges.

If you need a real bound, the enforcement has to be yours: compare the fee from the Redemption event after the receipt, or do not send while the rate is moving.

Cap on the eligible Troves the call redeems from, sent to getRedemptionHints and redeemCollateral as their _maxIterations. Default DEFAULT_REDEMPTION_MAX_ITERATIONS.

0n means no limit (MK-114), which is what both contract functions do with zero (TroveManager.sol:353-355, HintHelpers.sol:107-109), and the precheck walk reads it the same way. It is accepted rather than refused because it is the contract's documented meaning, typing 0n is a deliberate act, and the work it asks for is bounded by amount: the loop stops once the request is covered. Negative values and values above the largest uint256 throw InvalidAmount.