DeQRypt
Scan, Pay, and Grow with AI
About
The problem it solves DeFi is powerful, but it's still too hard for the average person. New users are often overwhelmed by complex interfaces, the fear of sending money to the wrong 0x... address, and the confusion of choosing where to invest their assets. DeQRypt bridges the gap between Web2 usability and Web3 power on the Base network. It solves these critical friction points: 1. Eliminates "Address Anxiety": Instead of copy-pasting long, error-prone wallet addresses, users simply scan a QR code to pay—mimicking the familiar experience of Web2 payment apps (like QRIS/Venmo). 2. Democratizes Financial Intelligence: Most users don't know which lending pool (Aave, Moonwell) offers the best safety or APY. Our AI Agent acts as a personal financial copilot, analyzing market rates in real-time and guiding users to the best yield opportunities. 3. Removes Idle Capital: Money sitting in a wallet loses value against inflation. DeQRypt makes it effortless to move funds from a checking account into Yield-Generating Protocols with a single chat command or
How it's made
Challenges we ran into 1. **Understanding payment flow vs. asset flow (Treasury confusion)** One of the first hurdles was properly separating payment settlement logic from asset custody logic. Initially, it was unclear whether the treasury wallet would need to manually approve transactions when funds passed through it. This caused confusion about who “controls” the funds during a payment. **How we solved it** We restructured the flow so that: 1. The router contract is the only executor of transfers. 2. The treasury wallet is a passive receiver of funds. 3. All transfers happen atomically inside a single smart contract call. 2. **Swap complexity and testnet liquidity limitations** Implementing a real on-chain swap on Base Sepolia turned out to be risky due to low liquidity and high slippage potential during the demo. **How we solved it** We implemented a simulated swap layer (V2) where the Router accepts USDC, transfers it to treasury, and mints IDRX to the merchant at a fixed oracle rate. This keeps the architecture DeFi-ready while making the demo stable. 3. **Transaction Finality & "Silent Failures" (Backend)** We encountered a critical bug where the Backend API returned "Success" immediately after broadcasting a transaction, but the transaction would later revert on-chain. This led to data inconsistency where the database showed a deposit that never actually happened. **How we solved it** We implemented a strict transaction receipt validation in the Python backend. The system now broadcasts the hash and pauses to wait for the block confirmation (receipt.status == 1). If the chain reverts, the backend catches the error and prevents the database write, ensuring 100% data integrity. 4. **Single-Asset vs. Multi-Asset Pool Architecture** While integrating the AI Agent, we found that depositing mUSDC would constantly fail. We realized our initial Mock Lending Pool was hardcoded as a "Single Asset Vault" (only accepting mIDRX), but the backend treated it like a generic pool. **How we solved it** We refactored the smart contract to a Multi-Asset Pool pattern (similar to Aave). We updated the backend logic to dynamically pass the token_address into the smart contract call, allowing the Agent to manage multiple assets (ETH, mUSDC, mIDRX) through a single contract interface. 5. **Frontend integration clarity** Another hurdle was ensuring the frontend team clearly understood which addresses were fixed (router) vs user-provided, and the correct sequence of approve -> pay. **How we solved it** We created a detailed integration brief covering minimal ABIs, token decimals, and event-based receipt parsing. This allowed frontend development to proceed independently without blockchain-side changes.