LienFi

On-chain lending has two unsolved problems: credit scoring requires exposing private financial data, and liquidation auctions are transparent (meaning bidders see each other's bids and can game the outcome). These problems compound in mortgage systems — you need credit assessment, collateral management, and liquidation all working correctly. LienFi attacks both simultaneously using different privacy primitives for each.

The credit assessment runs inside a Chainlink CRE (Chainlink Runtime Environment) confidential enclave. The enclave fetches Plaid data via Confidential HTTP (API keys never exposed), runs hard-gate checks (LTV ≤ 80%, income coverage ≥ 3×, no recent defaults), passes processed metrics (not raw data) to Gemini, and discards everything before writing the approve/reject verdict on-chain. The auction uses Vickrey mechanics: winner = highest bid, price = second-highest bid. Only bid hashes are stored on-chain — amounts and bidder identities stay in the enclave until settlement.

The architecture is event-driven: submitting a loan request emits LoanRequestSubmitted, which auto-triggers the CRE assessment workflow. No manual step needed. The requestHash pattern anchors everything — it's computed from borrower address + tokenId + amount + tenure, stored both in the API DB and on-chain. The enclave fetches from DB using the hash, recomputes it to verify integrity, then proceeds. If hashes don't match, the assessment aborts. Privacy boundary: PRIVATE (CRE only): Plaid data, credit score, property address, bid amounts ON-CHAIN (public): approve/reject verdict, requestHash, opaque bid hashes, winner + price

Chainlink CRE is a powerful but opinionated framework — the KeystoneForwarder pattern for writing verdicts back on-chain requires careful ABI encoding. The bigger lesson was about privacy boundaries: defining exactly what should be private (and enforcing those boundaries architecturally) is harder than implementing any individual privacy technique.