Wie ich autonomes unterbesichertes Lending gebaut habe
Hashstack Finance · Founder & Product Lead · 2020–2026
Überblick
Ich gründete Hashstack Finance, ein DeFi-Lending-Protokoll auf Starknet L2, das unterbesichertes Borrowing ohne Kreditkomitees, Whitelists oder institutionelles Gatekeeping ermöglichte. Das Protokoll steuerte Risiko autonom über Smart-Contract-Constraints — eine Kategorie, in der alle anderen auf menschliche Kreditprüfung setzten.
Zwei Produktinnovationen — Degen Mode (One-Click-Hebelausführung) und DIAL (Custom-Zinsalgorithmus) — zeigten originales Produktdenken in einem vollen Markt. Ich führte das Protokoll von der Gründung bis zum strukturierten Wind-down 2026. Nutzerfonds wurden zurückgegeben und bleiben abziehbar; die Protokolloberfläche liegt auf GitHub Pages, damit Abhebungen mit nahezu null Betriebskosten verfügbar bleiben.
1. Branchenkontext: DeFi-Lending 2020
Dezentrales Lending ist einer der größten DeFi-Sektoren. Nutzer hinterlegen Krypto als Collateral, leihen dagegen und zahlen Zinsen — wie ein Bankkredit, aber ohne Bank per Smart Contract.
Die dominanten Protokolle — Aave, Compound, MakerDAO — verlangen Überbesicherung. Um $75 zu leihen, muss man $100 hinterlegen. Das schützt das Protokoll, schafft aber ein Kapitaleffizienzproblem.
Bis 2020 erreichte dieses Modelll $10B+ TVL. Es funktionierte, band aber enormes Kapital in unproduktiven Collateral-Positionen.
| Cluster | Protokolle | Kapitaleffizienz | Risikomodell |
|---|---|---|---|
| Konservativ | Aave, Compound, Maker | Niedrig | Überbesichert |
| Mitte | TrueFi, Maple | Mittel | Kreditgeprüft |
| Hashstack | Hashstack | Hoch | Algorithmisch gesteuert |
2. These: Autonomes unterbesichertes Lending
Mehrere Protokolle versuchten unterbesichertes Lending vor Hashstack. Der Unterschied lag im Risikomanagement.
| Protokoll | Modell | Gatekeeper | Kreditnehmer | Kapitalbeschränkung |
|---|---|---|---|---|
| TrueFi | Kreditgeprüft | Menschliches Kreditkomitee | Nur Institutionen | Keine — frei abziehbar |
| Maple | Kreditgeprüft | Menschliche Pool-Delegierte | Nur Institutionen | Keine — frei abziehbar |
| Goldfinch | Kreditgeprüft | Menschliche Auditoren | Realwirtschaftliche Unternehmen | Off-Chain-Nutzung |
| Hashstack | Autonom | Smart Contract | Jeder (permissionless) | Nur On-Protokoll-Deployment |
Meine These: Unterbesichertes Lending funktioniert ohne menschliches Gatekeeping, wenn geliehenes Kapital auf genehmigte Deployment-Kanäle im integrierten Ökosystem beschränkt ist. Der Smart Contract erzwang Solvenz — kein Kreditkomitee, keine Whitelist, kein Institutions-only-Zugang.
Das ist derselbe Collateral-vs-Access-Trade-off allen Lending: Wie viel Freiheit gibt man dem Kreditnehmer bei Schutz des Lenders? Hashstacks Antwort: maximaler Hebel, minimale Abhebung.
3. Produktevolution: V1 zu V2
Das Protokoll lieferte zwei Versionen mit unterschiedlicher Risikokalibrierung.
| Dimension | V1 (Initial) | V2 / Degen Mode (Final) |
|---|---|---|
| Maximaler Hebel | 3× Collateral | 5× Collateral |
| Kapitalabhebung | Bis 70% des Collateral-Werts | Null — vollständig beschränkt |
| Kreditbetrag | Variabel | Fix $5,000 |
| Risikophilosophie | Konservativ — Markt testen | Kühn — engere Eindämmung, mehr Zugang |
Das V1-Modelll erlaubte bis $300 Kredit bei $100 Collateral, davon $70 abziehbar und $230 als In-Platform-Trading-Kapital.
V2 erhöhte den Hebel von 3× auf 5× und entfernte Abhebungen völlig — mehr Kapital zum Deployen, keine Escape-Hatch ohne Nutzerwert. Extra Supply über dem $1,000-Minimum senkte den Hebel automatisch (z. B. $2,500 Einlage → 2.5× statt 5×).
Einsicht: Hebel lockern und Eindämmung straffen kann zusammengehen. Die Constraint ist das Produkt.
4. Degen Mode: One-Click gehebelter Yield
Das Problem
Manueller gehebelter Yield in DeFi erfordert Poolwahl, Ratio-Berechnung, Borrow, Swap und LP — jeder Schritt mit Gas, Slippage und Fehlerrisiko. Den meisten Nutzern fehlen Expertise oder Geduld.
Die Produktentscheidung
Degen Mode abstrahierte die ganze Sequenz auf einen Klick: gerankte Strategien (Returns, APR, Tiefe), wählen, Execute — das Protokoll erledigt den Rest atomar.
User-Flow
- $1,000+ in einem Asset liefern
- Degen-Tab öffnen — Strategien mit geschätztem APR und Risiko
- Strategie wählen, Execute klicken
- Protokoll leiht $5,000 automatisch und deployt in einer Transaktion
- Ergebnisse unter Your Borrow verfolgen
| Entscheidung | Geprüfte Optionen | Wahl | Begründung |
|---|---|---|---|
| Mindest-Supply | $100 / $500 / $1,000 | $1,000 | Darunter überwiegt Hebelrisiko den Nutzen |
| Kreditbetrag | Variabel / Fixed | Fix $5,000 | Standardisiert Risiko; vorhersagbare Strategiepreise |
| Strategiewahl | Nutzerkonfiguriert / Protokoll-kuratiert | Protokoll-kuratiert | Weniger Fehler; Protokoll besitzt die Risikofläche |
| Kapitalbeschränkung | Teilabhebung / Vollsperre | Vollsperre | Solvenz braucht Eindämmung |
| Extra-Supply | Erhöht Borrow / Senkt Hebel | Senkt Hebel | Selbst-Derisk ohne Nutzerschulung |
Dasselbe Abstraktionsmuster — Mehrschritt-Finance in ein Ergebnis — gilt weit über DeFi hinaus.
5. Zinsdesign: Ambitioniert bauen, einfach shippen
Aave und Compound nutzen einen floating Rate pro Asset aus instantaner Utilization. Hashstack brauchte Commitment-Perioden (2 Wochen, 1 Monat, 3 Monate) mit höherem APR bei längeren Lockups — ein fundamental anderes Zinsmodell.
DIAL: Die R&D-Version
Ich entwarf DIAL (Dynamic Interest Algorithm for Lending) mit Term-Structure-Pricing, begrenzten Rates, keccak256-basiertem Anti-Manipulation-Sampling und Multi-Tranche-Accounting. Es explorierte den gesamten Designraum eines Commitment-basierten Zinsmodells.
Was Produktionskontakt nicht überlebte: nicht-deterministische Rates schadeten Integratoren, Admin-Updates waren bei Liquiditätsengpässen zu langsam, Multi-Tranche-Randomisierung trieb Auditkosten über das vom TVL gerechtfertigte Maß.
Die Produktionsentscheidung
Für das V1-Testnet (Juli 2023) entwickelte ich das Modelll zu einer kinked Utilization-Kurve — DIALs Kerninsights behalten, Komplexität schneiden.
| Dimension | DIAL (R&D) | Production Kink |
|---|---|---|
| Zins-Updates | Admin-getriggert, periodisch | Kontinuierlich, deterministisch |
| Krisenreaktion | Langsam (Admin-Takt) | Sofort (steile Post-Kink-Steigung) |
| Auditierbarkeit | Niedriger (komplexer Solver) | Höher (Standardkurve) |
| Optimale Utilization | Band-basiert | 90% |
Quellen: DIAL (Wayback) · Production IRM · V1 testnet.
Was von DIAL blieb: Term-Premium-Konzept, Bounded-Rate-Philosophie, Supply/Borrow-Cashflow-Identität, Anti-Manipulation-Intent.
Was entfiel: Pseudozufalls-Sampling, Multi-Tranche-Solver, Admin-Updates, harte Rate-Caps.
Produktionsparameter: Base 2% bei 0% Utilization; 20% bei 90%; 100% bei voller Utilization.
6. Protokollmetriken
| Kapital aufgenommen | $1M Seed + zusätzliches Private Funding |
|---|---|
| On-Chain-Nutzer | 36,000* |
| Kosten pro Nutzer | $55* (Benchmark: die meisten DeFi-Protokolle liegen bei $200–500+) |
| Durchschnittliche Asset-Utilization | 61%* (Benchmark: Aave-Klasse typisch 30–50%) |
| Ertragsjahr-1 | $56K+* |
| Engineering-Team | 16* (unter den größeren Starknet-Teams) |
| Starkware grants | 250K STRK (Catalyst); 140K STRK (Early Adopter); $10K migration* |
| Harmony grant | $50K* |
| Protokoll-Integrationen | 7 — Aave, Chainlink, Herodotus, ZKLend, Myswap, Jediswap, Chainstack |
| Sicherheit | CertiK-auditiert — report |
| Standards | Authored proposed EIP-5299 |
| Token | Gelistet auf Uniswap (Ethereum) + Ekubo (Starknet) |
| TVL | Getrackt auf DefiLlama |
* Operator-Metriken (intern) — nicht unabhängig auditiert.
7. Die Plattform-Wette: Starknet
Ich migrierte Hashstack im August 2022 nach Starknet wegen ZK-Proof-Kostenvorteilen, Cairos Formal-Verification für Liquidationslogik und Ökosystem-Grants.
Die technische These validierte sich — das Protokoll lief auf Starknet, CertiK bestand, Utilization lag über Branchenbenchmarks. Cairos Formal-Verification war ein echter Vorteil für Liquidation. Die Herausforderung war Hashstack-spezifisch: ein schlankes Team managte volle Cairo-Migration und Produktiteration gleichzeitig — mit begrenzter Runway für beides.
Source: Starknet-Migrationsankündigung.
- 2020 Hashstack gegründet
- 2022 Nach Starknet migriert · Token 2049 · Authored proposed EIP-5299
- 2023 V1-Testnet (DIAL → Kink-Modelll) · CertiK-Audit · Ökosystem-Grants
- 2024 Degen Mode · Operativer Peak
- 2025 Cairo-1.0-Deprecation · Base-Testnet (EVM-Portabilitätsnachweis)
- 2026 Negativer Migrations-ROI → Strukturierter Wind-down
8. Die Wind-Down-Entscheidung
Trigger: Cairo-1.0-Deprecation erforderte volle Migration oder Exit.
| Faktor | Auf Starknet bleiben | Nach Base/EVM migrieren |
|---|---|---|
| Engineering-Kosten | Volle Cairo-Migration | Moderat (Solidity-Port) |
| Teamkapazität | Schlankes Team über Migration + Produkt gestreckt | Gleiche Constraint, anderer Stack |
| Time-to-Market | 6–9 Monate Migration | Hinter etablierten Protokollen |
| Runway-Realität | Migrationskosten überstiegen Rest-Runway | Späteinstieg in einen vollen Markt |
| Urteil | Ressourcen-, nicht Plattform-Constraint | Fenster geschlossen |
Entscheidung: Strukturierter Wind-down. Nutzerfonds wurden zurückgegeben und bleiben abziehbar. Website/Interface liegt auf GitHub Pages und bleibt so lange nötig mit nahezu null Overhead funktional.
Ein von null gebautes Protokoll abzuschalten ist ein härterer Product Call als der Launch. Die Runway trug Migration und Wachstum nicht gleichzeitig — und ich würde Kapital oder Nutzervertrauen nicht verbrennen, indem ich das Gegenteil vortäusche.
9. Was ich anders machen würde
Vor einer großen Migration mehr kapitalisieren. Cairo-Migration war technisch richtig, aber wir trafen sie mit Team/Runway für Produktiteration, nicht Full Rewrite. Ich würde dediziertes Migrationskapital vorab sichern.
Kink-Modelll ab Tag eins shippen. DIAL war wertvolle R&D, verzögerte aber das tatsächlich funktionierende Zinsmodell. Lehre: Designraum in Simulation explorieren, nicht in Produktionsarchitektur.
Team für Paralleltracks ressourcen. Hashstacks Produktthese validierte sich — Utilization, Nutzer und autonomes Modelll funktionierten. Die Lücke: Migration, Iteration und Wachstum gleichzeitig auf schlankem Team. Mit richtiger Ressourcenlage hätte das Ergebnis anders sein können.