Appearance
Morpho
Morpho is a lending protocol. We use it on the cash-advance side, not gift cards.
An example
A cardholder's card just bought a $500 laptop for a buyer. The buyer's $450 sits in escrow for 30 days in case the laptop comes back. The cardholder wants their money now.
At delivery we mint a token that says: whoever holds this gets the $450 when the window closes. The cardholder can sell that token, or put it up as collateral on Morpho and borrow, say, $400 from outside lenders. When the escrow releases, the $450 pays off the loan and the rest goes to the cardholder.
Why lenders trust it
The escrow pays whoever holds the token, not just us. If the cardholder does not repay, a liquidator takes the token and redeems it. It is backed by stablecoins already locked up, the payout date is known, and outside lenders fund it, not our balance sheet. The borrowing limit is priced by how likely a return is, per merchant and category.
Meanwhile the idle escrow money sits in a Morpho vault earning interest, which grows our reserve.
Each lending market is isolated, so a bad market never touches gift cards or any other market.
The open problem, and the leading fix
If the buyer returns the laptop, the escrow refunds them and the token is worth nothing while the loan is still out.
The leading fix uses two things we already have. We own the merchant account, so a return can only start through our app. So a return does not start until the loan is settled: repaid from the cardholder's parked balance or pending payouts first, and if that does not cover it, the return waits, or the loan was never allowed on that order. The merchant's refund never reaches the cardholder's card until the lender is whole.
Where it still leaks: a cardholder can walk into the store and return in person, around our app. Backstops for that: no borrowing on returnable orders at first, lower limits, and borrowing only for cardholders with history or a parked balance as stake. Not settled. See the roadmap.
Later: cash against unsold gift cards
A seller takes cash now against a card nobody has bought yet. Only safe where the merchant lets us move the balance to a number only we hold, so the seller cannot spend it after borrowing. Our balance reads are the price feed, and our own buyers are the liquidators, since they want the card. Everywhere else it is an internal advance with recourse, not a market. Opt-in: keep the card and wait for a buyer at a small discount, or take cash now at a bigger one. Seller balances left in the app earn yield and count as stake.
The long version
Status: 🔵 Built and tested, never proven. Six gates are green. No transaction has been sent. The live round trip is blocked on a funded testnet wallet.
Why a lending market is here at all
In the cash advance, escrow money sits idle for days to weeks between funding and release, because the return window that keeps it safe has to close first. Parked in a vault, it earns yield for the reserve. A bigger reserve lets the share paid out up front rise over time instead of staying fixed. So Morpho is how the release schedule improves.
Supply side only
We deposit into an ERC-4626 vault. We do not create Morpho Blue markets, write oracles or mint collateral, for reasons settled below.
The load-bearing position
Settlement never waits on the venue.
We only deposit the money we do not expect to need for refunds. The refund buffer itself can never be deposited. If the vault cannot hand money back, the release goes out from the buffer anyway, and the operator is paged.
Settlement never waits because the obvious design (recall the funds, then release) fails when it is needed most: a lending market is least able to return capital when it is most utilised, and "most utilised" correlates with "bad day."
There are five distinct outcomes: full, partial, none, timeout, error. A hung RPC and a frozen market look the same to the release and get the same answer.
The buffer draw is a debt to repay. It is a real, temporary solvency cost: until the venue repays, the book is less able to make a returning buyer whole. So the caller carries it as an obligation, and the page is priority 5. Treating it as free would be the mistake.
The vault must be Vaults v1
Morpho Vaults v2 hard-codes every max function to return 0. Morpho's own docs call it "non-conventional behavior … they always return zero."
Against a v2 vault, maxWithdraw reads as none every time, so every release would drain the buffer and page while the money sat fully available. The liquidity signal the design rests on would be silently inverted.
So deploy() reads maxDeposit before any money moves and refuses on 0 with VaultShapeError. On v1 that value is real cap headroom. On v2 it is always 0. Either way a zero means a deposit would fail, so refusing on 0 is right. The message names both, so the operator checks the right thing.
Rejected: a Blue market with our receivables as collateral
Funded by our own vault, it would fail three independent ways, each fatal:
Circularity. Our vault supplies the USDC, and the collateral is a claim on our own escrow, so the refund buffer and the loan collateral are the same pot. A return makes us owe a refund exactly when the collateral is worth less.
Oracle. Blue prices collateral in loan-token terms. A receivable is worth face × P(no return) × P(LP pays). Nobody quotes that, so we would write the feed for our own paper, in a market we fund, against loans we issue.
Liquidation. Blue's solvency depends on permissionless liquidators wanting the collateral at a discount. Nobody outside wants a receivable only we can redeem, so the market's core risk control is decorative.
Blue assumes liquid, externally-priced, transferable collateral, and our paper is none of these. The same three failures broke several RWA lending setups.
The answer to "why didn't you build a market?"
We looked. Liquidation does not fire on a claim only we can redeem, so the market's main safety check would never run.
What would have to change
Revisit a Blue market when the collateral is something a stranger wants after liquidating it. A listed gift card is the first candidate here: transferable, with a face value the merchant honours, so a liquidator could sell it. See the roadmap's Layer C.