DorkFi updates: unlocking real composability in lending

DorkFi has been nudging toward what it is supposed to be: not just a lending protocol, but a system where liquidity, collateral, and execution actually compose.

The last few updates are not surface UI tweaks. They change how assets move.

The bet: if routing and representation live behind a clean interface, users get one action where they used to need a chain of hops. That is composability you can feel, not a slide about composability.

1. 🧭 Folks-backed pools: D markets with receipt assets

We shipped support for receipt-based assets, including fALGO and fUSDC, with D markets in motion. The bigger change is the path in.

Before: the normal way in was a loop. Go to Folks, mint the receipt, come to DorkFi, supply. You owned every hop in the right order.

Now: you can land in the same end position without that round trip. DorkFi routes; you do not need to hit Folks first.

What is actually happening

You supply USDC into a D market. Under the hood:

• The system routes your deposit to Folks
• Mints fUSDC
• Supplies that into DorkFi

What you used to juggle:
USDC → go to Folks → mint fUSDC → go to DorkFi → supply

What you do: USDC → supply → done

Example: USDC to fUSDC, then borrow

• Deposit 1,000 USDC; the system converts to fUSDC and supplies into the D market
• Earn about ~5.5% APY on supply
• Borrow up to about ~80% of the position, on the order of ~800 USDC

Why this matters

• Cuts the multi-step friction
• You do not need a receipts mental model to get yield and collateral at the same time
• One position can work as supplied liquidity in the book as intended

What this unlocks

• Composability the user does not have to see
• Higher capital efficiency in one pass
• A real base for automation on top, because the joins live in the system

2. 🔀 Unified deposit: mint and supply in one action

Covered: ALGO, tALGO, fALGO, and xALGO. You express supply; routing picks the right leg.

Before: you often had to go to Tinyman or Folks, mint the right representation, return, then supply. Every extra surface is a place to pick the wrong pool, wrong size, or wrong time.

Now: you supply ALGO and the system routes. Same intent, different representation when it is better to do so.

Example: ALGO and the spread between markets

• tALGO ~9.98%
• xALGO ~9.95%
• fALGO ~2.17%
• ALGO ~1.59%

What you see: you still supply ALGO. What the system does: it sends you toward the better option the integration supports, instead of you opening four UIs to chase the same spread.

Interchangeability: what the user still touches

If you land in something like tALGO under the hood:

• Withdraw → ALGO
• Borrow → ALGO

You are not left managing three different tickers in the portfolio just to have one mental model. The product keeps ALGO on the label when you leave or borrow.

Why this matters

• Stops the protocol-hopping day job
• Less asset fragmentation in how you think about a single deposit intent
• A better default on yield when routing can reach a higher number
• Pairs with automation, because the route is in the product, not in a one-off user script

What this unlocks

• A default that feels like a protocol default, not like you became the router

3. 🧩 Adapter-based architecture: one set of verbs

Every new asset class plugs in with the same four operations: deposit, withdraw, borrow, repay.

Native, LP, and yield-bearing assets all go through the same adapter surface, not a rewrite of the core for each new line item.

The builder take: the core can stay about accounts and the book; the one-off details live in adapters. That is how a lending stack stays extensible when new receipt or pool types show up, instead of a fresh fork of the middle of the system every time.

Why you should care without reading the adapter table: the next asset should add a surface at the edge, not a new tangle in the middle. That is the line between a stack that composes and a stack that restarts the story for every integration.

4. ✨ State, portfolio, and repay interest

I tightened state sync and the UI so the numbers you read are closer to what the chain would enforce.

What changed:

• Supply and borrow toggling that is easier to use without fighting the form
• A cleaner portfolio view
• Less mismatch between displayed debt and the real position
• A repay control for only accrued interest (pay the carry, not a full principal paydown in the same stroke)

Why this matters

• Less second-guessing which number is the real one
• Direct control, including interest-only when you want to trim carry without a full unwind
• A cleaner readout for state driven from the outside, agents included, because the product tracks the position more honestly

5. 💡 Why the arc matters: from deposit-borrow to deposit-route-reuse

DorkFi is not aiming at “another lending app.” The direction in the work:

• Composable collateral, including receipts and routed yield where the user is not the router
• Execution-first design, so a multi-step or cross-venue path can look like one product action
• Cross-protocol efficiency where you do not have to be a power user to get a fair default

In one line:

• From: deposit, then borrow, as a thin two-step habit
• To: deposit, route, reuse, automate, as a single system story

The point: if liquidity, collateral, and the paths between venues are first-class in the product, the next layer, human or agent, does not rebuild the same graph from zero. It calls into the same surface the UI uses.

6. 🔭 What is next

• More D markets
• Cross-chain collateral
• Agent execution
• Improved interest models

Roadmap directions, not a dated ship list. Sections 1 to 4 describe the work this post covers.

7. 📝 Notable changes

• Folks-backed D market pools, including fALGO and fUSDC paths
• Unified ALGO-family supply (ALGO, tALGO, fALGO, xALGO)
• Adapter system for deposit, withdraw, borrow, repay (native, LP, yield-bearing)
• UI improvements, plus repay interest only

8. 🛠️ ETHGlobal Open Agents Async

Built during ETHGlobal Open Agents Async. The same bet as this routing work: agent-driven execution and programmable liquidity, in a product where the moves are in the system, not only in the user’s head.

9. Closing: infrastructure, not a one-off

DorkFi has to read as infrastructure, not only a product. I shipped the routing, the adapters, and the state work so the book and the interface line up. The next phase is to widen where that model applies.

I built the plumbing so the model and the face of the app match. Composability and abstraction are the levers, not the buzzwords on a slide.

Disclaimer

This is not financial advice. APY figures, borrow limits in examples, and any numbers in this post are illustrative, not a forecast or a recommendation. Markets and protocol parameters change. Do your own research (DYOR), size your own risk, and check what applies in your jurisdiction.