RentRWA

Demo

About

The problem it solves # What RentRWA Can Do For You ## 🏠 **For Landlords: Unlock Rental Income Liquidity** ### **Traditional Problems** - 💸 Rental income locked in monthly payments, need immediate liquidity - 🏦 Bank loans require extensive paperwork and weeks of processing - 📋 High barriers: minimum amounts, strict requirements ### **RentRWA Solution** #### **🚀 Instant Liquidity (30 Seconds)** ``` Before: Wait 30+ days for bank approval After: "My address is 0x123..., RWA key is ABC123, help me get liquidity" → Get USDC in 30 seconds ``` #### **🛡️ Legal Protection & Better Terms** - Real contracts signed at physical stores - Your rental contract is your collateral - Blockchain audit trail, competitive DeFi rates ## 💼 **For USDC Investors: Earn Stable Returns** ### **Traditional Problems** - 📉 Low bank yields, volatile crypto/stocks - 🔒 High minimums, illiquid investments ### **RentRWA Solution** - **Asset-Backed**: Secured by real rental properties - **Flexible**: Start with any USDC amount vs $10K+ traditional minimum - **Transparent**: On-chain records, automated smart contract protection ## 🏢 **For Property Managers: Scale Your Business** - **New Revenue**: Offer instant liquidity services to clients - **Tech Integration**: Become fintech-enabled vs traditional competitors - **Automation**: Smart contracts replace paperwork-heavy processes ## 🌐 **For DeFi Users: Bridge Traditional Assets** ### **DeFi Problems** - 🎭 Speculation focus, high volatility, limited real-world connection ### **RentRWA Solution** ``` Traditional DeFi: Stake ETH → Earn more ETH RentRWA: Stake USDC → Earn from real rental income ``` - **Stable Returns**: Real estate less volatile than crypto - **AI-Enhanced UX**: Natural language vs complex DeFi interfaces ## 🔧 **Making Tasks Easier & Safer** ### **Before vs After** | Task | Traditional | With RentRWA | |------|-------------|--------------| | **Property Loan** | 30+ days, paperwork | 30 seconds, one sentence | | **Real Estate Investment** | $100K+ minimum | Any USDC amount | | **Data Verification** | Manual checks | Chainlink oracles | | **Lending Management** | Banks, lawyers | Smart contracts | ### **Safety Improvements** - **🔐 Enhanced Security**: Smart contracts vs human error - **🏛️ Compliance**: Real contracts + blockchain audit trail - **💡 Risk Reduction**: Diversification + transparency ## 🎯 **Real-World Use Cases** ### **Emergency Liquidity** Sarah needs $15,000 for medical bills. Uses RentRWA to get instant USDC against her $2,000/month rental income. ### **Investment Opportunity** Mike sees a great property deal. Gets liquidity in 30 seconds vs missing opportunity waiting for bank approval. ### **Portfolio Diversification** Lisa has $50,000 in crypto, wants real-world exposure. Provides USDC liquidity to rental properties vs expensive REITs. ### **Property Management Growth** ABC Property Management becomes fintech-enabled vs limited to rent collection. ## 🚀 **The Future of Real Estate Finance** RentRWA makes real estate finance: - **🤖 AI-Powered**: Natural language vs complex interfaces - **⚡ Instant**: 30-second transactions vs 30-day processes - **🔗 Connected**: Bridge traditional assets with DeFi innovation - **🛡️ Secure**: Blockchain transparency + legal compliance **Ready to transform real estate finance? Start with a simple conversation.**

How it's made

Challenges we ran into # Bugs and Hurdles in RentRWA Development ## 🚨 **Major Issue: Chainlink Functions Gas Limit Exceeded** ### **The Problem** Our **Chainlink Functions callback was consuming 350,000+ gas**, exceeding the 300,000 limit and causing contract execution failures. This blocked our core tokenization functionality. ### **Root Cause Analysis** Using Chainlink platform's transaction explorer, we identified issues in our `fulfillRequest()` callback: 1. **Complex Data Processing**: Too many operations in single function 2. **Inefficient Storage**: Multiple storage writes per transaction 3. **Redundant Calculations**: Unnecessary computations during callback #### **Problematic Code** ```solidity function fulfillRequest(bytes32 requestId, bytes memory response, bytes memory err) internal override { // ❌ Too many operations: decode + validate + mint + emit (uint256 deadline, uint256 price, string memory proof) = abi.decode(response, (uint256, uint256, string)); s_issuesInProgress[requestId].deadline = deadline; // Multiple storage writes require(deadline > block.timestamp, "Invalid deadline"); // Complex validation uint256 tokenId = s_nextTokenId++; i_realRentToken.mint(s_issuesInProgress[requestId].to, tokenId, price, "", proof); emit RequestFulfilled(requestId, deadline, price, proof, tokenId); } ``` ## 🔧 **Solution: Two-Phase Execution Model** ### **Phase 1: Minimal Callback** ```solidity function fulfillRequest(bytes32 requestId, bytes memory response, bytes memory err) internal override { // ✅ Minimal processing: just store response s_lastResponse = response; s_lastRequestId = bytes32(0); emit ResponseReceived(requestId, response); } ``` ### **Phase 2: Separate Minting** ```solidity function RentTokenMint(bytes32 requestId) external returns (uint256) { // ✅ Decode and mint in separate transaction (uint256 deadline, uint256 price, string memory proof) = abi.decode(s_lastResponse, (uint256, uint256, string)); uint256 tokenId = s_nextTokenId++; i_realRentToken.mint(fractionalizedNft.to, tokenId, price, "", proof); return tokenId; } ``` ### **Key Optimizations** - **Reduced Storage**: Combined multiple writes into single operations - **Simplified Validation**: Moved complex logic to frontend - **Event Optimization**: Minimal event parameters ## 🛠️ **Implementation Process** 1. **Gas Analysis**: Used Chainlink transaction explorer to identify bottlenecks 2. **Code Refactoring**: Separated callback from business logic 3. **Testing**: Validated gas consumption improvements **Results**: 350,000+ gas → 180,000 (callback) + 120,000 (minting) = 300,000 total ✅ ## 📊 **Results** | Operation | Before | After | Status | |-----------|--------|-------|--------| | **Callback** | 350,000+ gas | 180,000 gas | ✅ Success | | **Minting** | Included | 120,000 gas | ✅ Separated | | **Total** | Failed | 300,000 gas | ✅ Within limit | **Benefits**: Reliable execution, predictable costs, better scalability ## 🎯 **Lessons Learned** ### **Chainlink Functions Best Practices** - Keep callbacks minimal - only store essential data - Separate complex logic into additional transactions - Monitor gas usage with realistic data testing ### **Smart Contract Optimization** - Minimize storage write operations - Split complex operations across transactions - Balance event logging with gas costs ## 🔄 **Other Issues Resolved** ### **ElizaOS Integration** - **Issue**: TypeScript compatibility with Viem library - **Solution**: Updated type definitions and proper casting ### **Twitter Rate Limiting** - **Issue**: API limits during testing - **Solution**: Exponential backoff and request queuing ### **Supabase Authentication** - **Issue**: API key exposure in Functions - **Solution**: DON encrypted secrets storage ## 🚀 **Impact** This gas challenge improved our architecture: - **Better separation**: Clear callback vs business logic distinction - **Enhanced UX**: Predictable gas costs - **Improved scalability**: Optimized foundation - **Stronger testing**: Robust gas monitoring **Key Takeaway**: The 300,000 gas constraint pushed us to create a more modular, efficient architecture that serves the project well as it scales.