DorkFi
Self-Executing Credit Markets.
About
The problem it solves **DorkFi is a modular, cross-chain lending protocol designed to make DeFi safer and more automated.** Today, users must manually manage borrowing positions, rely on off-chain keepers, and navigate fragmented liquidity across chains — exposing them to liquidation risk and infrastructure failures. DorkFi enables overcollateralized borrowing and stablecoin minting (WAD) with deterministic risk models and protocol-native automation. By integrating scheduled on-chain execution and layered architecture, it removes reliance on centralized bots while improving capital efficiency. DorkFi transforms lending from a manual, fragile process into programmable, self-executing financial infrastructure. Use of AI tools and agents ## Use of AI Tools and Agents AI tools were used during development to accelerate UI creation, debugging, and frontend iteration. However, there are currently **no live AI agents embedded in the deployed protocol**. All lending logic, settlement, and automation are deterministic and executed directly through smart contracts. The system leverages **x402 scheduling primitives** for guaranteed future execution, enabling network-level automation without centralized keepers. Looking ahead, the architecture supports a **User-Controlled Protocol (UCP)** model where AI agents could operate as advisory or automation layers within user-defined permissions. In this design, AI would analyze risk or optimization opportunities, prepare transactions, and optionally schedule them via x402 — while smart contracts enforce final rules and custody remains fully on-chain. This approach preserves decentralization today while enabling intelligent automation in future iterations.
How it's made
Challenges we ran into ## Hedera Schedule Service and Forge script: non-contract at 0x16B This project is a Hedera-native lending pool that uses Hedera’s Schedule Service (HIP-1215) so a **keeper** runs on-chain at fixed intervals without an off-chain bot. The pool extends a base lending design with a Hedera-specific contract that calls the Schedule Service precompile at 0x16B to reschedule itself (e.g. for interest accrual or maintenance). Starting the keeper from Foundry failed with “call to non-contract address 0x16B” because Forge still runs the script in a local VM that doesn’t have Hedera’s precompiles; we fixed it by sending the start transaction with cast send so execution happens only on Hedera. The result is a self-scheduling keeper that relies on Hedera’s native scheduling instead of external infrastructure.