DEVNETYou are on Solana devnet. Funds are not real. Behavior matches mainnet.

Settlement & waterfall

When an auction ends with a winning bid, settlement runs the same waterfall regardless of whether the auction was Dutch or English. The waterfall determines how the bid amount is distributed among the beneficiaries: lenders (via the pool), the protocol fee account, and — notably not the defaulted borrower.

The waterfall, in three lines

Let bid be the winning amount, debt = principal + fixed_interest_due be the loan's full payoff, and auction_fee_bps be the protocol's configured share of any surplus.

  • If bid <= debt: the entire bid goes to the pool. The pool absorbs the shortfall as a loss to NAV. The protocol takes no fee on shortfalls.
  • If bid > debt: surplus = bid − debt. The protocol's share is surplus × auction_fee_bps / 10,000. The pool receives debt + (surplus − protocol_share).
  • The defaulted borrower receives zero in either case.

In production today, auction_fee_bps = 5,000 (50%), so the protocol takes half of any surplus and the pool's NAV gains the other half.

A worked example

Suppose:

  • The defaulted loan has principal $1,000 and fixed interest $24.66, so debt = $1,024.66.
  • The Dutch auction's winning bid is $1,500.
  • auction_fee_bps = 5,000 (50%).

Then:

  • surplus = $1,500 − $1,024.66 = $475.34.
  • protocol_share = $475.34 × 50% = $237.67.
  • pool_share = $1,024.66 + ($475.34 − $237.67) = $1,262.33.
  • borrower_share = $0.

The pool's NAV moves up by $1,262.33 − $1,000 = $262.33 (the $1,000 principal returns + $262.33 of yield). The protocol fee account gains $237.67. The borrower lost the card and any of its potential upside.

If the same auction had cleared at exactly the reserve ($1,024.66):

  • surplus = $0. No protocol fee.
  • The pool gets exactly the debt back. NAV gains nothing beyond recovering principal — the protocol simply broke even on the loan.
  • Borrower again gets $0.

If the auction had cleared below the reserve (which would only happen with a Dutch auction whose reserve is hit and a discount applies, or with a misconfigured English auction):

  • bid < debt. Entire bid goes to the pool. NAV drops by the shortfall. No protocol fee.

Why borrowers don't receive surplus

The architectural choice is deliberate. Once a loan defaults:

  • The borrower has demonstrably failed to repay despite the grace window, so the protocol no longer has a contractual relationship with them on the upside.
  • Allowing surplus to flow back creates a perverse incentive — borrowers can effectively "use the auction to sell their card" with the protocol taking on the disposal work for free.
  • It simplifies the on-chain accounting: lenders are made whole first, the protocol takes its fee, and the rest reinforces NAV for future default scenarios.

This is one of the most important rules to internalize as a borrower: the optimal strategy is always to repay before default. Letting a loan default is strictly worse than a market sale of the same card.

On-chain mechanics

The settlement instruction (auction_settle) does the following in one atomic transaction:

  1. Validates the caller

    The signer must be the auction winner (the highest bidder for English auctions, or the only bidder for Dutch). This prevents random third-parties from claiming someone else's card.

  2. Computes the waterfall

    Calls the same shared waterfall function used for both auction formats, producing pool_amount, protocol_amount, and borrower_amount (always zero).

  3. Moves the USDC

    Transfers the entire winning bid from the auction escrow into the pool's quote vault, and increments the pool's protocol_fees_accumulated counter by protocol_amount. The protocol fee is recorded on the pool, not transferred immediately.

  4. Moves the NFT

    Transfers the card from the loan's collateral vault to the winner's associated token account, signed by the loan authority PDA. This step has separate code paths for standard NFTs (freeze + transfer) and programmable NFTs (delegate + revoke).

  5. Updates pool aggregates

    Decrements the pool's outstanding_principal by the loan's principal and the accrued_interest by the loan's fixed interest, since both are now resolved.

  6. Closes loan and auction accounts

    Frees the rent on the loan account, the auction account, the collateral vault, the bid escrow, and the locks. Refunds flow to the relevant rent payers per the program's account-closing rules.

The protocol fees that accumulate on the pool are swept by a separate admin instruction (protocol_withdraw_fees), which routes them to the protocol fee recipient and a configured insurance fund split.

Read next