Skip to content

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.