API ReferenceLOC lifecycleType Alias
RedeemLOCParams
type RedeemLOCParams = object;One redemption within RedeemLOCsParams.redemptions: which LOC, how much of its face value, where the tokens go, and — when the caller is not the beneficiary — the beneficiary’s signed authorization.
Properties
amount
amount: bigint;Credited-token amount to redeem, in the credited token’s smallest unit; greater than zero and at most the LOC’s remaining OutstandingLetterOfCredit.remainingCredited. Less than the full amount is a partial redemption and the LOC stays open with the remainder; the full amount settles and removes the LOC.
beneficiaryAuthorization?
optional beneficiaryAuthorization?: Bytes;EIP-712 RedeemAuthorization signed by the LOC’s beneficiary. Build and sign it with
sdk.loc.buildRedeemAuthorizationWorkflow; it binds id, amount, the LOC’s current credited
amount, destinationAddress, and the beneficiary’s next redeem nonce. Required when the connected
signer is not the beneficiary, and for every entry when
RedeemLOCsParams.redemptions has more than one element. Explicit
undefined is equivalent to omission.
destinationAddress?
optional destinationAddress?: Address;Account that receives the redeemed tokens. A direct redemption defaults to the connected signer. A
delegated redemption with beneficiaryAuthorization defaults to the LOC beneficiary. An explicit
value must be the address the beneficiary signed for. Explicit undefined is equivalent to
omission.
id
id: bigint;ID of the LOC to redeem (LetterOfCreditReference.id). The LOC must not have expired.
liquidator?
optional liquidator?: Address;Contract implementing ILiquidator that converts the LOC’s collateral into the credited token, so
the redemption pays out in the credited token. Omitted, the caller liquidates the collateral
themselves: they receive the collateral (plus the liquidator incentive) rather than the credited
token, and — unless they are also the destinationAddress — must hold and have approved the
credited amount the contract pulls from them. This accepts any contract implementing ILiquidator;
the SDK binds no liquidator deployments of its own. The SDK picks none by default because the two
modes pay out different assets. Only valid on a single redemption.
liquidatorParams?
optional liquidatorParams?: Bytes;Opaque calldata forwarded verbatim to liquidator.liquidate — for the passthrough liquidators, an
off-chain-computed swap route. Meaningless without a liquidator, and empty ('0x') when omitted.
Only valid on a single redemption.
oraclePriceUpdate?
optional oraclePriceUpdate?: OraclePriceUpdate | null;Signed Pyth price update, from sdk.pricing.getOraclePriceUpdate, priced with the LOC’s collateral
token as inputToken and its credited token as outputToken. Its fee is attached as the
transaction’s value. There are three modes for a dynamic LOC (collateral token differs from
credited token): an update object is forwarded verbatim; undefined automatically fetches one while
the transaction is built; and null explicitly uses the price already on chain without contacting
Hermes. If an automatic fetch fails, the SDK uses the on-chain price only after proving it is still
fresh. The contract otherwise reverts PriceUpdateStale past Pyth’s
window (60 s on mainnet, 300 s on staging). An object whose data is '0x' is invalid: use null
for the explicit on-chain mode. Every mode is ignored for a LOC that has already converted, which
needs no price. Only valid on a single redemption.