The problem FLIPT solves

FLIPT bridges the gap between Web2 e-commerce giants and Web3 liquidity by allowing users to instantly tokenize and crowdfund high-value items directly from eBay listings.

The Core Problem:
High-value real-world assets (RWAs) like vintage watches, graded trading cards, or luxury sneakers are often illiquid and inaccessible to the average retail investor due to high price points. Furthermore, bringing these assets on-chain usually requires complex oracle setups or manual verification processes.

Our Solution:
FLIPT creates an automated, trust-minimized "Click-to-Deploy" infrastructure on Base.

Instant RWA Deployment: Users simply paste an eBay URL. The system scrapes the metadata, validates the listing (ensuring it is "Buy It Now" and in stock), and automatically deploys a specific Smart Contract (RWAPool) on Base Sepolia representing that specific item.

Democratized Ownership: Instead of one person paying $10,000 for a collectible, 100 people can contribute $100 USDC via the smart contract.
Wallet Abstraction: We solve the onboarding friction by generating server-side wallets (using Viem and Supabase) for users who sign up with email. This allows web2-native users to interact with the blockchain seamlessly while retaining the security of on-chain settlement.

It makes the task of pooling capital for real-world acquisitions transparent, auditable via the blockchain, and accessible via a familiar e-commerce interface.

Challenges I ran into

1. Secure Server-Side Wallet Management
One of the biggest hurdles was creating a seamless "Web2-like" experience where the application handles transactions on behalf of the user without custodying plain-text private keys.

The Hurdle: We needed to generate wallets for users (via api/wallet/create) and sign transactions (like contributing to a pool) without exposing keys or requiring a browser extension popup for every action.

The Fix: I implemented an encryption system using crypto (AES-256-GCM) to store encrypted private keys and IVs in Supabase. When a user initiates a contribution, the server retrieves the encrypted key, decrypts it in memory for milliseconds to sign the transaction using Viem, and then discards it.

2. Handling ERC-20 Approvals in a "Headless" Flow
The smart contract logic requires an ERC-20 approve transaction before a deposit can occur.

The Hurdle: In a standard dApp, the user approves via MetaMask. Since our server controls the user's interaction wallet, managing the asynchronous nature of waiting for the Approval block confirmation before triggering the Deposit transaction caused race conditions.

The Fix: I wrote a robust handler in api/listing/contribute that checks the allowance first. If insufficient, it broadcasts an Infinite Approval transaction, awaits the transaction receipt explicitly using client.waitForTransactionReceipt, and only then executes the deposit function.

3. Validating eBay Data for Smart Contracts
Not all eBay items are suitable for crowdfunding (e.g., Auctions with dynamic ending times).

The Fix: I built a validation layer (api/validate-item) that interacts with the eBay Browse API. It parses the URL for the Legacy ID and strictly enforces that items must be FIXED_PRICE (Buy It Now) before allowing the UI to proceed to the smart contract deployment stage.