The problem CEMI solves

The traditional Buy Now, Pay Later (BNPL) industry is a multi-billion dollar market, but it is fundamentally incompatible with the ethos of Web3. To bridge this gap, we built a decentralized, closed-loop credit economy that solves the biggest friction points for both consumers and merchants.

1. The "Overcollateralized" Web3 Lending Trap

The Problem: DeFi lending currently requires users to overcollateralize (e.g., locking up $150 to borrow $100). This makes uncollateralized credit—the backbone of the real-world economy—impossible for standard crypto users without doxxing their real-world identity to a centralized entity.

The Solution: We utilize zkTLS (Reclaim Protocol) to securely verify off-chain financial data (like Web2 bank statements or credit scores). This allows users to prove they are creditworthy to our smart contracts without revealing their actual identity, bank account number, or raw data.

2. Merchant On-Chain Privacy & Corporate Espionage

The Problem: If a Web2 merchant adopts crypto payments on a public ledger, their entire cash flow becomes public. Competitors, suppliers, and the public can trace exactly how much revenue they are making and who their suppliers are. This lack of financial privacy is a massive blocker for B2B crypto adoption.

The Solution: Our protocol introduces Zero-Knowledge B2B Privacy Pools secured by BitGo MPC wallets. When a user makes a downpayment or pays an EMI, the funds are routed through a shielded pool. This completely breaks the on-chain link between the consumer's wallet and the merchant's final treasury, giving merchants enterprise-grade settlement privacy.

3. Inefficient Capital & Idle Merchant Liquidity

The Problem: In traditional BNPL, merchants have to wait weeks or months to receive their full EMI payments, meaning that capital sits idle and loses out against inflation.

The Solution: We built automated Aave Yield Routing directly into the protocol's escrow smart contracts. While the merchant waits for the user to finish paying their EMIs, the locked downpayments and partial repayments are deployed into Aave. This generates continuous, risk-minimized yield for the merchant, turning a standard payment gateway into a passive income stream.

4. The Lack of Verifiable Web3 Reputation

The Problem: Web3 wallets are disposable. If a user defaults on a loan, they can simply abandon the wallet and create a new one, making sybil attacks rampant.

The Solution: We leverage the Namespace API and dynamic ENS subnames to create an on-chain credit bureau. As users interact with the protocol, their wallet is tied to a visually dynamic, protocol-issued identity (e.g., trusted.protocol.eth or indebt.protocol.eth). This gamifies repayment, builds a portable Web3 credit score, and visually warns other protocols if a user is currently carrying bad debt.

Challenges I ran into

1. BitGo SDK Support for Base Sepolia

The Challenge: We hit a major roadblock when we realized the standard BitGo SDK didn't have out-of-the-box, streamlined support for the specific Base Sepolia (TBASEETH) network we were building on. Our treasury routing was failing because the SDK couldn't resolve the chain ID correctly.

The Solution: Instead of pivoting, I went directly to the BitGo booth at the hackathon. I sat down with their developers, explained our architecture, and worked through the configuration requirements. By manually overriding the network provider settings and getting direct feedback from their team, we successfully integrated their MPC-secured vaults for our B2B privacy pools.

2. ENS Wildcard Resolution (EIP-3668 / CCIP-Read)

The Challenge: I wanted a "gasless" identity system where user profiles could update their debt status without a MetaMask popup every time. However, standard ENS resolvers only look for on-chain data.

The Solution: We implemented Wildcard Resolution. By updating our parent name (sunil.eth) to a custom resolver that supports CCIP-Read, we successfully bridged the gap between the Ethereum blockchain and our off-chain Namespace database. This allows our frontend to query "Trusted" or "In Debt" status instantly and for free.

3. TypeScript Strictness with Wagmi/Viem

The Challenge: Moving from standard JavaScript to strict TypeScript for blockchain interactions led to numerous "BigInt" and "Hex String" mismatches, especially when handling dynamic user addresses that could be undefined during the initial hook load.

The Solution: I implemented strict type-guarding and casting (e.g., address as 0x${string}) and utilized the enabled query property in Wagmi hooks to ensure the app never attempted a blockchain call until the user's wallet was fully resolved and validated.