TaniFi
"Bringing On-Chain Finance to the Offline Farmer."
About
The problem it solves # TaniFi: Bringing On-Chain Finance to the Offline Farmer 🌾⛓️ **TaniFi** is a decentralized, Sharia-compliant agricultural finance protocol built on **Lisk Layer 2**. It bridges the digital divide by allowing unbanked farmers to access global DeFi liquidity using simple **USSD (2G) technology**, without needing internet access or smartphones. --- ## 🚩 The Problem It Solves Agriculture contributes significantly to the economy of emerging markets, yet smallholder farmers remain trapped in poverty due to a structural **"Agricultural Trilemma"**: 1. **The Digital Divide (Accessibility):** * **Reality:** 40% of rural areas in Indonesia are internet "blank spots". * **Issue:** Most modern DeFi and Fintech apps require 4G smartphones and data plans, excluding millions of farmers who only possess feature phones (Nokia-style devices). 2. **Predatory Financing (Fairness):** * **Reality:** Formal banks reject farmers due to lack of land certificates (collateral). * **Issue:** Farmers are forced to rely on "Tengkulak" (loan sharks) with interest rates as high as **20% per month**, trapping them in a cycle of debt. 3. **The Trust Deficit (Transparency):** * **Reality:** Previous centralized agritech platforms (e.g., the TaniFund & eFishery cases) suffered from internal fraud and data manipulation ("double bookkeeping"). * **Issue:** Global investors lost trust in funding agriculture because they cannot verify if the money actually reached the farmer or was used for planting. --- ## 💡 What Can People Use It For? TaniFi serves three distinct user groups within the ecosystem: ### 1. For Unbanked Farmers (The Borrowers) * **Access Capital Offline:** Dial a simple short code (e.g., `*777#`) to request funding for fertilizer or seeds without needing a bank account or internet. * **Build Digital Reputation:** Every repayment creates an on-chain credit score (Soulbound Token), allowing them to access larger capital in the future based on performance, not assets. * **Fair Profit Sharing:** Instead of paying fixed interest (Riba), farmers share a percentage of their harvest profit. If the harvest fails due to floods (verified by weather data), they are not crushed by debt. ### 2. For Global Investors (The Lenders) * **Fund Real-World Assets (RWA):** Directly fund specific agricultural cycles (e.g., "Banyumas Coconut Sugar Export Batch #42") using stablecoins (USDC/IDRX). * **Track Impact:** View transparent, real-time data on how funds are disbursed and utilized via the blockchain ledger. ### 3. For Cooperatives (The Off-Takers) * **Supply Chain Financing:** Get instant liquidity to pay farmers immediately upon harvest collection, rather than waiting 30-60 days for export payments. * **Digital Administration:** replace manual logbooks with an immutable digital ledger that tracks every kilogram of harvest from farm to table. --- ## 🛡️ How It Makes Tasks Easier & Safer TaniFi innovates by combining **Low-Tech interfaces** with **High-Tech security**. ### Making Financing **Easier** (UX Innovation) * **No Internet Required:** Uses USSD (GSM protocol), accessible on 99% of mobile phones globally. * **Gasless Transactions:** Farmers don't need to buy ETH or LSK to pay for gas fees. TaniFi uses **Account Abstraction (ERC-4337)** Paymasters to sponsor transaction costs, creating a seamless experience. * **Instant Disbursement:** Funds are sent as digital vouchers to local partner stores, ensuring farmers get what they need (fertilizer/seeds) instantly without waiting for bank approvals. ### Making Investing **Safer** (Security Innovation) * **Triple-Entry Accounting:** Unlike centralized servers that can be manipulated, every transaction is recorded on the **Lisk Layer 2 Blockchain**. This creates a "Single Source of Truth" that cannot be altered by the platform owners. * **Smart Contract Enforcement:** The "Musyarakah Vault" automatically splits harvest revenue between the investor and farmer according to the pre-agreed ratio. No one can run away with the profits. * **Automated Risk Mitigation:** Integration with **Chainlink Functions** allows the smart contract to read weather data (BMKG). If a flood occurs, the contract can automatically trigger insurance protocols or restructure the loan, removing human bias and fraud. ---
How it's made
Challenges we ran into # Challenges I Ran Into Building **TaniFi** within a hackathon timeline was far from smooth. Below are the real technical hurdles I faced during development, and how I solved them. --- ## 1. Environment & Tooling Setup (WSL + Docker + Foundry) ### The Challenge At the very beginning, the development environment itself became a blocker: - Docker was installed but the daemon could not start - WSL was outdated and incompatible with Docker Desktop - Ubuntu installation via Microsoft Store repeatedly failed - Disk space constraints on the system drive caused additional friction These issues prevented even basic services (PostgreSQL, Redis, NestJS) from running. ### How I Solved It - Updated WSL manually using `wsl --update --web-download` - Migrated development fully into **WSL2 (Ubuntu)** instead of mixing Windows + Linux tooling - Reconfigured Docker Desktop to use WSL backend - Carefully chose a **non-destructive storage strategy** (avoiding data loss on external SSDs) **Lesson learned:** A “broken” environment can look like a code problem. Fixing infra early saved massive time later. --- ## 2. Prisma ORM Breaking Changes (Prisma v7) ### The Challenge Prisma introduced breaking changes in version 7: - `datasource.url` is no longer allowed in `schema.prisma` - Connection configuration moved to `prisma.config.ts` - `PrismaClient` must now be constructed with explicit options This caused multiple runtime and compile-time errors such as: - `P1012: datasource property 'url' is no longer supported` - `PrismaClientInitializationError` ### How I Solved It - Carefully read updated Prisma documentation - Migrated DB config to `prisma.config.ts` - Refactored `PrismaService` to properly extend `PrismaClient` - Regenerated Prisma Client and re-ran migrations **Lesson learned:** Using “latest” tech gives advantages, but only if you are ready to adapt to breaking changes. --- ## 3. USSD State Management & Stateless HTTP ### The Challenge USSD flows are **stateful**, but HTTP requests are **stateless**. Problems encountered: - Session resets on every request - User inputs like `2*5000000` not parsed correctly - Back / Exit logic (`0`, `00`) behaving inconsistently - Edge cases causing unexpected session termination ### How I Solved It - Introduced **Redis** as a session store with TTL - Implemented an explicit **finite state machine**: - `START` - `AWAIT_AMOUNT` - Normalized USSD input parsing using `text.split('*')` - Carefully handled `Back` and `Exit` flows per state **Lesson learned:** USSD is deceptively simple. Treat it like a protocol, not just input text. --- ## 4. Audit Logging vs Database Schema Drift ### The Challenge While adding audit logging (`UssdAudit`), the backend crashed with: ``` The table `public.UssdAudit` does not exist ``` The Prisma client expected the model, but the database schema had not been migrated. ### How I Solved It - Verified Prisma schema vs actual database tables - Added the missing model - Ran `prisma migrate dev` to sync schema - Confirmed audit rows were being written correctly **Lesson learned:** Schema drift is silent but deadly. Migrations are not optional. --- ## 5. Lisk Sepolia Gas & Token Confusion ### The Challenge After receiving funds from faucet: - Blockscout showed **0.1 LSK** - MetaMask showed balance - Foundry (`cast balance`) returned **0** This caused deployment failures with: ``` insufficient funds for gas * price + value ``` ### How I Solved It - Learned that **Lisk Sepolia gas is paid in ETH**, not LSK - Realized I had received tokens, but **no gas currency** - Adjusted funding strategy accordingly - Confirmed gas requirements via RPC and Foundry output **Lesson learned:** Not all L2s use the same native gas semantics. Always verify what pays gas. --- ## 6. Smart Contract Verification on Blockscout ### The Challenge Contract deployment succeeded, but verification repeatedly failed with: - `Fail - Unable to verify` - `missing field sources` - Partial mismatches between compiler metadata ### How I Solved It - Confirmed on-chain bytecode using `cast code` - Identified that Blockscout requires **Standard JSON Input** - Used Foundry’s `--show-standard-json-input` - Uploaded the correct JSON via Blockscout’s UI - Successfully achieved **Verified (Partial Match)** status **Lesson learned:** Verification is not automatic. Tooling literacy matters as much as Solidity. --- ## Final Reflection Most challenges in this project were not about writing code, but about: - Tooling maturity - Protocol understanding - Infrastructure debugging - Reading documentation carefully under time pressure Overcoming these issues significantly strengthened both the technical robustness of TaniFi and my confidence as a builder. ```