The problem OctantVault solves

Octant vault solves a key problem in web3 and open-source ecosystems: the lack of sustainable, transparent funding for contributors to nonprofits and open-source projects.

The Problem It Solves:
Funding Insecurity: Many open-source and nonprofit Web3 projects depend on donations, grants, or irregular payments, which are unsustainable for long-term contributors.

Manual Payment Hassles: Organizers must manually distribute funds, track payments, and manage records; this is inefficient and prone to errors.

Lack of Transparency: Contributors often don’t know how funds are allocated or the impact of their work—undermining trust and collaboration.

Siloed Funding: Traditional funding only supports fixed causes, with little adaptability or direct incentives for ongoing work.

What People Can Use It For & How It Makes Tasks Easier:
Automated Salary/Payment Streams: Contributors to qualifying projects get regular “salary” payments funded by DeFi yield, without manual accounting. Funds are streamed automatically via smart contracts.

Transparent Impact: Contributors and the public can see how much yield has funded which projects/people, plus the impact (e.g., lines of code, number of issues closed, features shipped).

Permissionless Setup: Any community, DAO, or organization can deploy their own vault, automate payments, and customize how contributors are chosen (via voting, merit, or application).

Sustainable Funding: Donated principal stays in the vault, while only generated yield is distributed as payments. This means funds don’t run out—true sustainability.

Flexibility & Choice: Communities can vote on who receives payments or automate based on contribution tracking. This incentivizes real work over popularity contests.

Cross-Project and Cross-Chain: Vaults can be designed to cover multiple projects, or accept deposits from different chains and DeFi protocols for wider support and utility.

Streamlined Admin: Removes the need for spreadsheets, payment processors, and manual reporting—everything happens on-chain with clear, real-time metrics.

Challenges I ran into

The most persistent hurdles I encountered were related to data synchronization, wallet interaction, and contract interface reliability.

1. Integration and Data Mismatch Hurdles
   This category encompasses the most common bugs I found where different parts of the stack didn't agree on data or execution.

Problem: Contract Interface Mismatch Errors (Backend/Contracts)

My backend often called smart contract functions with incorrect signatures (e.g., calling getVoting() when the function was a public mapping votings()). This resulted in vague Ethers.js errors like missing revert data.

Similarly, type mismatches in return values (e.g., expecting a single address[] but receiving a tuple (address[], Contributor[])) would cause my backend parsing to fail silently or crash.

How I Overcame It: I established a strict protocol for contract interaction: I always verified the ABI against the deployed contract and used explicit .toString() on any BigNumber value retrieved from the blockchain before storing it in MongoDB or sending it to the frontend. I heavily relied on TypeChain to generate TypeScript interfaces for my contracts, catching many signature errors at compile time.

Problem: Backend-Frontend Data Mismatch (Integration)

My frontend frequently displayed stale data because the backend's event indexer hadn't yet processed a recent transaction (like a new vault creation or a vote).

How I Overcame It: On the backend, I prioritized event deduplication and retry logic in the eventIndexer.ts service to ensure reliable processing. On the frontend, I aggressively used React Query's invalidation mechanism (queryClient.invalidateQueries(...)) immediately after a successful smart contract write transaction, forcing a data refetch and ensuring a seamless, up-to-date user experience.

3. Operational and Infrastructure Challenges
   These issues were core to the deployment and configuration of the project across all environments.

Problem: Environment Variable and Network Mismatches (All)

I frequently ran into configuration errors where required environment variables (like RPC_URL or VAULT_FACTORY_ADDRESS) were missing, leading to deployment failures or runtime errors. Furthermore, running the backend on Base Sepolia while the frontend was mistakenly configured for Ethereum Mainnet would cause immediate connectivity issues.

How I Overcame It: I created a comprehensive .env.example file and integrated an initial startup check to validate all critical environment variables before the server or application launched. This "fail-fast" approach ensured that configuration issues were caught immediately rather than manifesting as obscure runtime errors. I also ensured the Chain ID was treated as a primary, non-negotiable environment variable, enforcing consistency across all services.