About Vanguard

💡 What Inspired Us

It started with a conversation none of us expected to have at a hackathon.

One of our teammates grew up watching his father run a small textile manufacturing unit in Tiruppur. The factory had consistent orders from large retail buyers - real contracts, real revenue. But every quarter, the family would scramble to pay workers and restock materials because buyers took 60–90 days to release payment. Banks wouldn't help. The invoices - legally binding documents worth lakhs of rupees - meant nothing to a loan officer who wanted land as collateral.

That story isn't unique. It's the operating reality for an estimated 600 million SMEs worldwide.

When we came across the statistic that the global SME funding gap stands at \$5.7 trillion, it clicked. This wasn't a niche fintech problem. It was a structural failure of how capital moves - and blockchain, for the first time, offered a genuine solution that didn't require trusting a bank.

The question we asked ourselves was simple:

"If a Walmart purchase order is legally as good as cash - why can't it behave like cash?"

Vanguard is our answer.


🏗️ How We Built It

We structured the project as three independent layers that compose into a single protocol.

Layer 1 - Smart Contracts (/contracts)

The foundation is a set of Solidity contracts deployed on EVM. The core primitive is the InvoiceNFT, an ERC-721 token where each token represents a single verified invoice. The token's on-chain metadata encodes:

$$ \text{NFT Metadata} = { \text{invoiceId},\ \text{buyerAddress},\ \text{faceValue},\ \text{dueDate},\ \text{ipfsHash} } $$

The LiquidityPool contract manages the capital allocation across two tranches. The Senior Tranche gets priority repayment; the Junior Tranche absorbs first-loss and earns higher yield. The yield split is governed by:

APY_junior = APY_base × (1 + Risk Premium / Junior TVL)

The ZKVerifier contract accepts a ZK proof and verifies it on-chain without exposing any underlying business financials - only a boolean creditworthiness signal passes through to the minting pipeline.

Layer 2 - Backend (/backend)

A Node.js + TypeScript API server handles everything off-chain:

  • Invoice ingestion - parsing uploads from QuickBooks/SAP integrations
  • ZK proof generation - running the business verification circuit off-chain, producing a proof to be submitted on-chain
  • IPFS pinning - anchoring the original invoice document to decentralized storage
  • Oracle listener - a Chainlink Functions subscriber that monitors payment events and triggers on-chain settlement

Layer 3 - Frontend (/vanguard-finance)

A Next.js dashboard with two distinct user flows - one for SMEs uploading invoices, one for investors managing pool positions. Wallet connection is handled via ethers.js, and all contract interactions are abstracted behind clean React hooks.


📚 What We Learned

Real-World Asset tokenization is harder than it sounds

Minting an NFT is trivial. Making that NFT legally meaningful is not. We spent significant time thinking through what it actually means for a token to "represent" an invoice — the off-chain legal enforceability, the need for immutable document storage via IPFS, and the metadata schema that keeps the token auditable years later.

Zero-Knowledge Proofs have a steep learning curve

Implementing ZK-KYB was the most intellectually demanding part of the project. We learned that a ZK proof for a statement like:

$$ \text{Prove: } \text{Revenue} > R_{\min} \text{ AND } \text{DebtRatio} < D_{\max} $$

...without revealing the actual values of Revenue or DebtRatio requires writing an arithmetic circuit in a ZK DSL (we used Circom), compiling it to a proving key, and wiring the on-chain verifier to a Groth16 or PLONK proof. The gap between "ZK exists" and "ZK works in your product" is enormous — and humbling.

Structured finance is a DeFi superpower

The Senior/Junior tranche model isn't just a risk management tool - it's a liquidity bootstrapping mechanism. We learned this from studying how traditional CLOs (Collateralized Loan Obligations) are structured and realised the same mechanics can be implemented transparently on-chain. The math of risk tranching - where the Junior tranche's loss absorption capacity determines the Senior tranche's safety rating - is genuinely elegant:

$$ \text{Senior Safety} = 1 - \frac{\text{Expected Default Rate} \times \text{Pool Size}}{\text{Junior TVL}} $$

The higher the Junior TVL, the safer the Senior tranche — creating a self-reinforcing incentive structure.

Chainlink Oracles are the real bridge

On-chain contracts can't natively read a bank's payment API. Chainlink Functions is what makes the real-world connection possible. Building the oracle listener taught us that the security of the entire settlement mechanism depends on the trustworthiness of this bridge - it's the single point where off-chain reality and on-chain state must agree.


🧱 Challenges We Faced

The Oracle Trust Problem

How do you trustlessly verify that Walmart paid a supplier? We can't. Not fully - not without Walmart itself publishing a signed transaction on-chain. Our current implementation uses Chainlink to monitor stablecoin transfers and permissioned banking API endpoints, but we acknowledge this is a trust assumption. A fully trustless RWA settlement remains an open research problem in the space.

ZK Circuit Complexity vs. Time Constraints

Building a production-grade ZK-KYB circuit with full business data verification was beyond our hackathon timeline. We implemented a simplified version that proves a binary threshold condition. A real deployment would require formal verification of the circuit itself - a weeks-long process. We treat our current ZK implementation as a proof of concept that demonstrates the architecture is sound.

Smart Contract Security

DeFi protocols that touch real money are targets. We didn't have time for a formal audit, so we focused on two principles: minimal contract surface area and explicit state machine transitions for each NFT:

$$ \text{NFT State} \in { \texttt{PENDING},\ \texttt{ACTIVE},\ \texttt{SETTLED},\ \texttt{DEFAULTED} } $$

Each state transition is guarded, irreversible, and emits an on-chain event. This makes the contract behaviour auditable even without a formal audit.

The Legal Layer

The hardest challenge wasn't technical - it was realising that a token is only as good as the legal system that enforces the underlying claim. In a default scenario, can the DAO actually sue the buyer? Can the NFT holder appear in court? These are unsolved questions in most jurisdictions. We've designed the protocol to be legally agnostic at the MVP stage, but real-world deployment would require jurisdiction-specific legal wrappers - a significant future workstream.


🔭 What's Next

Vanguard is an MVP. The core protocol works - invoices can be minted, pools can be funded, and settlement logic is wired. But the roadmap to production is long:

  • Formal ZK circuit audit and production-grade proof generation
  • Legal wrapper framework for cross-border invoice enforceability
  • Integration with national business registries (MCA in India, Companies House in the UK)
  • Multi-chain deployment (Polygon, Arbitrum) for lower transaction costs
  • Governance token for protocol parameter control (tranche ratios, fee structure)

We built Vanguard because we believe the next frontier of DeFi isn't more tokens - it's real commerce on-chain. Every dollar of working capital unlocked for an SME is a worker paid, a contract fulfilled, and an economy that functions the way it should.


Vanguard - capital should flow where work happens.

Built With

Share this project:

Updates