FlowVault
Empowering businesses with innovation
About
The problem it solves Flow vault is a decentralized platform that lets small businesses tokenize their unpaid invoices and get immediate liquidity by selling them to their community. It makes invoice financing faster, safer, and more inclusive — without relying on banks or traditional credit checks. ✅ For Small Businesses (Borrowers) What they can do: Tokenize unpaid invoices as NFTs. Sell them to investors for upfront cash. Get endorsed by customers, suppliers, or friends. ✅ For Investors (Lenders) How it helps: 🔍 Each invoice has AI risk scores and community endorsements. 🔐 Chainlink Functions verify invoice authenticity off-chain. 💸 On-chain repayment guarantees transparency and automation. ✅ For Endorsers (Community Supporters) What they can do: Stake tokens to endorse a business or invoice. Build on-chain reputation by backing trustworthy entities. Why it matters: 🏦 Replaces legacy factoring with a decentralized, community-first solution. 🧾 Turns real-world invoices into liquid, tradable digital assets (RWAs). 🤖 Uses Chainlink + AI (ElizaOS) for trusted off-chain risk analysis. 💼 Makes credit accessible to the unbanked and underbanked. 🔐 How It Makes Existing Tasks Smarter and Safer Traditional Task Web3 Improvement via This Platform Getting short-term loans Tokenize and sell invoices for instant liquidity Verifying invoice authenticity Chainlink Functions + IPFS hash validation Assessing trustworthiness Social endorsements + AI risk scores Handling repayments Automated enforcement via smart contracts Trusting unknown businesses On-chain reputation and transparent  payment history
How it's made
Challenges we ran into 1. 🔗 Verifying Invoices via Chainlink Functions Integrating Chainlink Functions to validate invoice authenticity off-chain was one of the trickiest parts. We needed to fetch invoice metadata from IPFS and cross-check it with records in a MongoDB database — all within the resource-constrained runtime of Chainlink Functions. How we solved it: We exposed a lightweight Express/Next.js API that Chainlink Functions could query. We structured invoice metadata in a clean, hash-verifiable format. We carefully optimized the Chainlink Functions JavaScript code to avoid timeouts. 2. 📁 Mapping IPFS CIDs to Business Users IPFS is decentralized and public, so there's no built-in way to query data by user. We needed to show businesses their own uploaded invoices in a dashboard. How we solved it: We created an on-chain mapping from business address → minted invoice token IDs. The frontend queries the contract to retrieve the invoice CIDs owned by the connected wallet. 3. 🏗 OpenZeppelin Versioning Conflicts We initially faced issues using newer features of OpenZeppelin's contracts. The Counters.sol utility had been removed in v5+, breaking our imports. How we solved it: We updated the smart contract logic to use simple state variables instead of relying on the Counters utility. We switched to OpenZeppelin v5.3.0 and adjusted imports accordingly. 4. 🧠 Designing the Reputation + Endorsement Mechanism Balancing simplicity and security in the social endorsement system was a big design challenge. We had to decide between using: A trustless, slashing-based system for failed repayments Or an insurance-pool fallback How we solved it: We implemented a lightweight endorsement mechanism tied to wallet reputation and staked support. We documented an insurance pool as a future upgrade path based on user traction.