The problem FlowVault 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

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.