Solver Lifecycle

A Solver does not just quote a rate. It commits balance-sheet capacity that moves through distinct states as a loan is opened, maintained, matured, closed, or pushed into distress.

Each debt asset should be understood through four bond buckets:

• Total Bond: the full amount the Solver has deposited for that debt asset.

• Locked Bond: the portion currently assigned to active LoanPods.

• Pending Withdraw Bond: bond that has already entered the withdrawal pipeline and is waiting through the withdrawal delay.

• Idle Bond: bond that can still support fresh underwriting.

Idle Bond = Total Bond - Locked Bond - Pending Withdraw Bond

That is the structural view. Operationally, serious Solver infrastructure should be even more conservative and also reserve against outstanding quotes or other internal commitments that have not yet settled onchain. The same dollar of bond should never be promised twice.

1. Origination: Idle Bond Becomes Locked Bond

When an intent settles, the protocol converts quoted capacity into a live obligation.

At settlement, the protocol sizes the required bond for that exact loan and locks it against the Solver's asset-specific bond pool. In the current contract surface this is the lockBondForLoan(...) step, with sizing derived from calculateRequiredBond(...).

That lock is then associated with the newly created LoanPod, which matters later because release and loss settlement happen on a per-position basis rather than against some abstract global bucket.

From the Solver's perspective, origination does three things at once:

1. creates the live venue debt position inside the pod

2. allocates a dedicated bond amount to that pod

3. reduces reusable bond capacity for future quotes

This is why the meaningful capacity number is never raw deposited bond. It is the portion that remains idle after active locks, pending withdrawals, and quote-side reservations are accounted for.

2. While the Position Is Live: Bond Is Committed Capital

Once a position is active, its locked bond is not reusable capital.

That locked amount exists specifically to back the fixed-rate obligation for that pod while the debt remains open on the underlying venue. It should be thought of as committed capital, not idle inventory.

Idle bond is different, but idle bond still should not be treated casually. In practice, Solvers should reserve idle bond against:

• active position locks

• pending withdrawal requests

• outstanding quotes that may still settle

• internal desk-level risk buffers

• live excess loss already consuming the broader bond pool

That last point matters in stressed books. Even before a formal distressed transition, some otherwise idle capital may already be economically spoken for by adverse carry on existing positions. In the current contract surface, even withdrawal capacity is netted down by this kind of live excess consumption rather than looking only at raw total - locked.

3. Healthy Close: Settlement Happens First, Full Remaining Lock Releases Automatically

The clean path is repayAndClose().

In that flow, the pod first settles the economics of the position. It compares what the borrower owes under the fixed-rate terms against what the pod actually owes on the underlying venue.

If the venue debt is higher, the difference is negative carry and the Solver bond absorbs that deficit first. In the current contract surface this is routed through handleNegativeCarry(...) and slashBondForNegativeCarry(...).

If the venue debt is lower, the positive spread is Solver profit and can be recycled back into the Solver bond pool.

Only after this settlement is complete does the protocol close the loan and release the pod's remaining lock. In the current close path, repayAndClose() ends by calling into core loan closure, which then triggers releaseBondForLoan(...).

That means a normal close should be understood in this order:

1. compute final borrower settlement

2. settle any negative carry against Solver bond if needed

3. repay venue debt and withdraw collateral

4. return collateral to the borrower

5. close the loan in core

6. release the full remaining bond lock for that pod

There is no separate post-close bond cleanup step in the healthy repayment path. Loss is settled as part of the close, and the remaining lock is released automatically once the position is finished.

4. Post-Maturity Checkpoint: Release the Releasable Portion, Retain Residual Bond

There is a second release path for positions that have passed maturity and are already effectively flattened on the underlying venue.

In the current contract surface this is the checkpoint flow. Anyone can call it after maturity, although in practice the Solver is the natural caller. The purpose is to recognize that the venue exposure has already been wound down and that the full active-position lock no longer needs to remain fully encumbered.

This path should be documented differently from a normal close.

A normal repayAndClose() is a full end-to-end settlement and release. A post-maturity checkpoint is a release action for an already matured position whose venue state has already been brought down to closed or dust.

In the updated lifecycle model, this checkpoint should not be described as freeing the entire original lock. It should be described as releasing the matured position's bond except for a residual bond amount that remains behind until final expiry-side accounting is fully resolved.

So the post-maturity release path is:

1. the position is past maturity

2. the underlying venue position is already effectively closed

3. anyone may trigger the release checkpoint

4. the protocol releases the releasable portion of the pod's bond

5. a residual bond amount stays retained until the expired position is fully resolved

That residual bond is the tail reserve. It exists so that maturity release is not treated as identical to a fully settled borrower close.

5. Distressed Settlement: Bond Is Consumed Before Anything Becomes Idle Again

If a position ends in loss, the protocol does not release first and settles the loss first.

When underlying venue debt outruns the fixed-rate borrower settlement, Solver bond becomes loss-absorbing capital. The position-specific lock is the first capital associated with that pod, and any broader asset-pool exposure can also be consumed if needed.

The lifecycle consequence is straightforward:

• realized deficit remains locked

• only the unlocked remainder can later become reusable

• release is always downstream of settlement, never upstream of it

This is the right mental model for all distressed states. Bond release is not a blind unlock based only on time or status. It always comes after the protocol has accounted for what that position actually cost the Solver.

6. Withdrawal Is a Separate Lifecycle From Release

Released bond is not the same thing as instantly withdrawable bond.

Once capital is no longer locked to an active position, it returns to the Solver's idle pool. If the Solver wants to remove that capital from the protocol entirely, it should first move into Pending Withdraw Bond, wait through bondWithdrawDelay, and only then become claimable.

That two-step flow matters because it stops Solvers from briefly posting bond to win flow and immediately draining the backing capital before recently quoted or recently matured positions have fully cleared the system.

For documentation purposes, that means:

• release is about moving capital out of a pod-specific lock

• pending withdraw is about moving idle capital toward exit

• claim is the final withdrawal step after the delay has elapsed

These are different lifecycle stages and should not be collapsed into a single idea.

Practical Capacity Mental Model

A Solver should reason about capacity in this order:

1. deposit bond into the correct debt-asset pool

2. reserve quote capacity before settlement

3. lock bond when a quote becomes a live loan

4. keep locked bond committed while the pod is active

5. settle profit or loss at close

6. fully release remaining lock on normal repayment close

7. partially release matured positions through checkpoint while retaining residual bond

8. move only truly idle capital into pending withdrawal

9. claim withdrawn capital after the delay elapses

That is what makes Solver capital reusable without making Solver accountability disposable.

Distressed Position Handling

When a Solver prices a loan, it is taking exposure to future variable-rate moves on the underlying venue. The bond exists to absorb that spread and keep the borrower's fixed terms intact while the position remains safely covered.

If the loss grows to the point where the remaining bond is no longer sufficient to keep extending that protection, the position becomes liquidatable and transitions into fallback.

Liquidation & Slasher Rewards

BondManager.liquidatePosition(address pod)

• Can be called by anyone.

• Computes the slash amount from the available bonded capital.

• Pays the keeper incentive.

• Penalizes the failing Solver.

• Ends active fixed-rate maintenance for the position.

The Fallback Path

Once fallback begins:

1. The Solver bond is slashed to absorb as much of the shortfall as possible.

2. The debt remains on the underlying venue already carrying the position.

3. The fixed-rate wrapper is no longer treated as active.

4. The borrower may close the position based on the amount owed through the covered fixed period.

5. If the borrower delays closing, the position is exposed to the venue's live borrowing conditions.

The important operational point is that fallback is a closeout state, not a fresh underwriting phase.