DeFi

Part III - Programmable, Usage‑Constrained Credit (Cross‑Chain Solvers and Beyond)

Part I asked what are we pricing when we quote a rate and answered with expected loss, capital, and margin. Part II focused on mechanism and guarantees. The final part of this series focuses on programmable, usage-constrained credit.

The moment you treat guarantees as code, you can underwrite routes and states rather than people. This part develops a concrete architecture for usage‑constrained credit in cross‑chain intent fulfillment, then generalizes it to other closed‑loop loans.

1) The promise

A solver receives a revolving credit line that can only be spent on executing a specific intent. Funds never touch the solver’s externally controlled wallet. At the destination chain, proceeds are swept into a repayment sink that pays the lender first. Only the surplus, if any, can leave the system. Misuse is structurally impossible; underwriting focuses on route risk.

2) The flow in words

Route risk in PD/LGD/EAD terms

An intent is posted and claimed (see Fig. 2). The solver locks a bond. The credit vault authorizes the source‑chain router to fund the route, tagging the bridge transfer so it can only land in the destination‑side sink. The destination router can call only whitelisted venues. When the trade completes, the sink retains principal, accrued interest, and protocol fees, and emits an attestation back to the source. Upon confirmation, accounting rolls forward and any surplus is released to the solver or shared with the user. If anything fails, timeouts and partial‑repayment rules determine how bonds are seized and how insurance funds step in.

Fig. 2: Stash Credit Flow Sequence

3) Why this is credit

No user pre‑funds the destination; the protocol fronts capital. The rate charged is the price of route risk: bridge failure, stale oracles, thin books, message delays. Loss given default is bounded by the repayment sink, by the solver’s bond, and by an insurance pool. Exposure at default is the funded notional during execution. Tightening allowlists, reducing timeouts, and sizing bonds cheapen the rate by cutting expected loss.

4) From solvers to other uses

Once you have repayment sinks and allowlisted routers, many “closed‑loop” credits fall out: merchant payouts where settlement currency must be converted along the way; RWA vaults where incoming cash flows must amortize a facility before any dividends are paid; programmatic capex loans that can buy only specific on‑chain inventory. The technology is the same; only the whitelists and oracles change.

5) Risks and their honest names

Code cannot erase risk; it only reshapes it. Priority becomes a matter of contract logic rather than contract law. Solvency depends on buffers that reflect finality lags and market depth at the destination. Reversibility is limited to what the mechanism allows; once a sink pays out, the system needs a credible path to recover mis‑routed funds. These constraints are not bugs—they are the design surface.

Conclusion — Why this matters (and what to build next)

We started with rates as prices of risk, moved through mechanisms for moving value while we wait, and ended with guarantees that can be expressed as law or as code. The practical takeaway is simple: separate pricing from plumbing. Price the thing you actually risk (people, positions, routes); then pick the lightest mechanism that keeps obligations safe—ideally one that nets and batches until the boundary, backed by guarantees you can verify. As more cashflows originate on programmable rails, expect guarantees to migrate from paper to code and for non‑deliverables, repayment sinks, and risk engines to become standard parts of product design.

If you’re building cross-chain intents, routing, or solver infra and want route-first credit with real LP yield, reach out—we’re onboarding early partners.