GigPay Indonesia

Demo

About

The problem it solves # GigPay **A Network Payout & Treasury Coordination Layer** # 1. Problem Modern digital businesses operate in a world that legacy payout infrastructure was never designed to handle. ## A. Cross-border settlement is slow and expensive Traditional bank rails (SWIFT, correspondent banking, ACH) introduce: * **T+1 to T+5 settlement delays** * **3-7% total cost** in cross-border corridors (FX spreads + intermediary fees) * Weekday cutoffs and timezone friction * Opaque FX spreads layered on top of transfer fees According to the **World Bank Remittance Prices Worldwide database**, global average cross-border remittance costs remain around **6%** ([World Bank, 2023](https://remittanceprices.worldbank.org/)). While B2B flows differ from remittances, correspondent banking layers and FX spreads create comparable multi-percentage costs. The **Bank for International Settlements (BIS)** and SWIFT documentation show that cross-border payments still rely heavily on multi-hop correspondent networks, where funds can take **1-5 business days** depending on corridor complexity and compliance checks ([BIS CPMI – Cross-border payments](https://www.bis.org/cpmi/publ/d193.htm); [SWIFT GPI Overview](https://www.swift.com/our-solutions/swift-gpi)). By contrast, blockchain settlement can clear within minutes, with transaction costs often measured in cents to low dollars depending on network conditions ([Ethereum Gas Tracker – Etherscan](https://etherscan.io/gastracker); [L2 Fee Analytics](https://l2fees.info/)). For platforms operating at scale, even a 2-4% efficiency gain across millions in volume translates into substantial margin recovery. ## B. Working capital is trapped in payout operations Finance teams today must: * Pre-fund multiple accounts across tools * Hold excess liquidity “just in case” * Manually reconcile batches and balances This creates: * **Idle float that earns little to no return** * Fragmented treasury visibility * Operational overhead in reconciliation The **BIS Committee on Payments and Market Infrastructures (CPMI)** highlights that cross-border frictions create “liquidity inefficiencies” and capital fragmentation across correspondent chains ([BIS Cross-border Payments – Stage 3 Roadmap](https://www.bis.org/cpmi/publ/d205.htm)). Research from the **Federal Reserve Bank of New York** and BIS further discusses liquidity and capital inefficiencies in correspondent banking networks ([BIS Quarterly Review – Correspondent Banking](https://www.bis.org/publ/qtrpdf/r_qt1603e.htm)). Meanwhile, US Treasury yields ranged between **4-5% in 2023–2024**, illustrating the opportunity cost of idle capital ([Federal Reserve Economic Data – 3M Treasury](https://fred.stlouisfed.org/series/DGS3MO)). Yet most businesses cannot safely deploy float into yield without breaking accounting boundaries or payout availability guarantees. ## C. Complex payout logic lives off-chain Real-world payment workflows involve: * Milestone-based releases * Multi-sign approvals * Refunds and disputes * Revenue splits * Cross-currency preferences Today, these conditions exist in: * Spreadsheets * Slack threads * Email approvals Banks only see the final debit. There is no enforceable state machine representing the payout lifecycle. The **BIS report on Distributed Ledger Technology in payment systems** notes that programmable settlement and atomic transactions can reduce reconciliation complexity and operational overhead ([BIS DLT in Payment Systems](https://www.bis.org/cpmi/publ/d157.htm)). Traditional ERP reconciliation cycles require manual stitching of: * Approval logs * Invoices * Bank statements * FX confirmations The absence of a unified intent ledger increases dispute frequency and audit complexity. ## D. Market scale The total addressable market is substantial: * Global payment flows exceed **$190 trillion annually** ([BIS Red Book Statistics](https://www.bis.org/statistics/payment_stats.htm)). * Global B2B payments exceed **$150 trillion annually** (McKinsey Global Payments Report) ([McKinsey Global Payments Report](https://www.mckinsey.com/industries/financial-services/our-insights/global-payments-report)). * Stablecoin transfer volume exceeded **$10 trillion annually** in 2023–2024 ([Chainalysis Crypto Adoption Report](https://www.chainalysis.com/reports/crypto-adoption-report/)). * Stablecoin circulating supply exceeds **$150B market capitalization** ([CoinGecko Stablecoin Data](https://www.coingecko.com/en/categories/stablecoins)).

How it's made

Challenges we ran into ## Postmortem (What happened -> Why -> Fix -> Prevention) ### 1) Vercel deployments crashed (Prisma not initialized / outdated client) - **What happened**: The API intermittently failed on Vercel with “Database client not initialized” and Prisma errors about Vercel caching causing an outdated Prisma Client. - **Why**: Serverless builds cached dependencies; Prisma Client generation didn’t reliably run. DB env var naming also differed across providers/prefixes. - **Fix**: Ran `prisma generate` during build, expanded DB URL resolution across multiple env keys, and returned a clear 503 instead of crashing when Prisma couldn’t initialize. - **Prevention**: Keep Prisma generation as part of the build pipeline; validate env presence at startup; fail fast with actionable errors. ### 2) Migrations blocked by a failed migration (P3009) - **What happened**: `prisma migrate deploy` refused to apply new migrations due to a prior failed migration recorded in the database. - **Why**: Prisma protects production DBs by stopping migration application when a migration is marked failed. - **Fix**: Made the failing migration idempotent and added a “heal and retry” path using `prisma migrate resolve --rolled-back` followed by re-running deploy. - **Prevention**: Make production migrations idempotent where possible; monitor migration status; avoid leaving partially applied migrations in shared DBs. ### 3) RPC outages broke indexing and made balances look like zero - **What happened**: Treasury balances and history went blank; backend event sync threw 503/429 RPC errors. - **Why**: Public Base Sepolia RPC endpoints were unstable/rate-limited. - **Fix**: Added multi-RPC fallback on the frontend and defensive RPC handling on the backend (skip/return defaults instead of crashing). - **Prevention**: Always use fallback RPCs, cache key reads, and treat RPC as a flaky dependency with graceful degradation. ### 4) BigInt JSON serialization errors broke API responses - **What happened**: Endpoints returned `{"error":"Do not know how to serialize a BigInt"}`. - **Why**: `JSON.stringify` cannot serialize `BigInt`, and some Prisma/RPC outputs include BigInts. - **Fix**: Added a JSON-safe response helper that converts BigInts to strings consistently. - **Prevention**: Normalize numeric types at the boundary (API responses); enforce serialization-safe schemas. ### 5) Payment “Confirm” flow was inconsistent (disabled, stuck, duplicate submits) - **What happened**: Users couldn’t confirm escrow creation reliably; sometimes Confirm was disabled without clear reason, sometimes it triggered multiple times, and sometimes the UI crashed. - **Why**: - Confirm was gated by strict conditions (wrong chain, swap route missing, token not eligible, yield strategy not allowed). - Receipt-handling effects could re-run and re-trigger follow-on actions without idempotency guards. - Some UI assumed state fields existed (swap) when older drafts didn’t include them. - **Fix**: - Added network gating with a “Switch to Base Sepolia” CTA. - Added idempotency guards (process a txHash once). - Added defensive defaults to prevent crashes. - Added an eligibility checklist + auto-fallback rules to keep the flow actionable. - **Prevention**: Treat the confirm path like a state machine with explicit transitions; enforce “exactly-once” handling; always show the user why a CTA is blocked and what the app will do next. ### 6) Explore didn’t show the real “Step 1-4” context - **What happened**: Jobs appeared in Explore but didn’t reflect the meaningful details users entered. - **Why**: The UI wasn’t leveraging the backend job/recipient relations and some display fields were hardcoded. - **Fix**: Updated Explore/ExploreJob mapping to show recipient identity, assets, and flags; removed hardcoded assumptions. - **Prevention**: Define a stable “public job view model” and render directly from it; avoid duplicating business logic between screens.