ARUSKITA: Autonomous Humanitarian Logistics & Trust Layer

Inspiration

Witnessing recurring natural disasters across Indonesia, we realized that the critical first 72 hours (the "Golden Hour") often fail not due to a lack of public empathy or donations, but because of systemic operational failure. Traditional humanitarian aid is heavily supply-driven and plagued by a financial "blackbox." Donors send money without ever knowing where it ends up, while frontline volunteers receive irrelevant surplus goods (like excess instant noodles instead of clean water or baby formula) and face debilitating bureaucratic delays just to secure cash. Furthermore, local grocery stores in disaster zones are often paralyzed or asked to extend credit to volunteers without payment certainty. We were inspired to build ARUSKITA: a trustless, demand-driven ecosystem that eliminates donation opacity, revives affected local economies, and ensures every single rupiah is transformed into lifesaving logistics in real time.

What it does

ARUSKITA is an autonomous, Web2.5 humanitarian logistics platform that synchronizes five key stakeholders (Donors, Field Posko Admins, Local Partner Stores, Courier Volunteers, and Survivors) into a closed, tamper-proof loop. Donors deposit fiat into a community balance and set strict filtering rules, such as allocating funds only for earthquakes in Sumatra with a maximum limit of Rp50,000 per day. When a verified Field Admin inside a geofenced crisis zone submits an emergency supply request, the system instantly debits matching donors proportionally, cutting fundraising time from days to milliseconds. Instead of shipping supplies from distant cities, ARUSKITA broadcasts supply requests to verified local merchants near the red zone. Stores compete for orders via a ride-hailing style bidding interface, securing guaranteed bulk sales that immediately revive the local economy. To protect volunteers from accusations of theft and eliminate lost inventory, physical supply transfers from Store to Courier and finally to Posko are locked using a dynamic, 30-second rotating QR code handshake. To close the loop, Field Admins must verify delivery using an in-app Forced Camera that blocks gallery uploads, applies liveness detection, and embeds real-time GPS coordinates and timestamps. This single photo autonomously triggers an API call that instantly disburses fiat cash directly into the local store's bank account, publishes an immutable audit trail to the public dashboard, and rewards participating donors with commercial loyalty coins.

How we built it

We engineered ARUSKITA using a pragmatic Web2.5 Hybrid Architecture, marrying the high-speed concurrency of modern web frameworks with the cryptographic integrity of immutable ledgers, completely bypassing the high gas fees and latency of traditional public blockchains. We built the client interface using Next.js and Tailwind CSS, deployed as a Progressive Web App (PWA). We implemented strict offline-first caching and Service Workers, allowing frontline volunteers to continue executing QR handshakes and capturing verification photos even when cellular networks degrade during disasters. We powered our backend REST APIs with Golang using the Gin Framework and GORM. Leveraging Goroutines, our server effortlessly handles concurrent proportional balance deductions across thousands of donor accounts and broadcasts real-time bidding orders to merchants in milliseconds without server latency. Instead of a slow Web3 chain, we utilized MariaDB configured with Spatial Indexing for GPS geofence validation and strict Append-Only Tables, revoking all UPDATE and DELETE privileges. Every logistics movement generates a new SHA-256 Hash chained to the previous transaction, and we implemented Lamport Logical Timestamps to safely resolve offline data synchronization conflicts once devices reconnect to the network. Furthermore, we integrated the Mapbox API for real-time geospatial crisis mapping and triage, alongside Xendit and Midtrans Payment Gateways to execute automated, real-time outbound fiat disbursements directly to partner merchants' bank accounts the second a delivery is visually verified.

Challenges we ran into

Designing a system for disaster zones meant assuming total cellular network degradation. We faced critical data synchronization conflicts when a Courier scanned a QR code offline at a store, delivered supplies, and the Posko Admin verified delivery while remaining offline. We overcame this by implementing Lamport Logical Timestamps and an event-sourcing queue in Golang, ensuring that when connectivity was restored, our backend processed events in strict logical chronological order and held the Xendit disbursement API until the entire handshake chain was 100% validated. When we restricted image uploads to our in-app camera, we quickly realized that technically savvy bad actors could bypass this using virtual cameras by photographing old receipts on another screen or using GPS mocking apps. We solved this by integrating lightweight Edge-AI Liveness Detection to analyze screen reflection anomalies and adding telemetry validation checks to verify operating system developer settings and local cell tower or Wi-Fi BSSID consistency. Our initial impulse was to build on a public blockchain, but high gas fees and block confirmation latencies made it unfeasible for real-time disaster response. Building an append-only, SHA-256 chained Mock-Ledger in MariaDB required deep architectural discipline, specifically revoking root-level UPDATE and DELETE database privileges and designing an automated daily Merkle Tree Root Hash anchoring mechanism to prove data immutability to third-party auditors. Additionally, we recognized that grocery store owners in crisis zones would be too panicked or technologically overwhelmed to download a new app during the Golden Hour. To solve this business friction, we shifted our strategy to pre-disaster mitigation onboarding through local FMCG distribution networks, while building a lightweight WhatsApp Bot fallback interface so merchants could accept orders and generate QR codes over basic 2G or 3G chat connections.

Accomplishments that we're proud of

We successfully engineered a closed-loop financial automation system where donor fiat money is held securely in escrow and released to local merchant bank accounts in seconds via API, triggered entirely by validated visual proof-of-delivery, which eliminates 100% of cash-handling risks and corruption bottlenecks in the field. We are also immensely proud of designing an intuitive, multi-tenant Progressive Web App (PWA) that seamlessly serves five distinct user journeys (Donor, Posko Admin, Store Partner, Courier, and Survivor) within a single codebase, without requiring users to understand cryptography or possess crypto wallets. In terms of backend performance, we built a concurrent smart-debit engine in Golang that can instantly match a Posko's geospatial supply request against thousands of user preference filters, dividing the funding load proportionally by debiting small amounts like Rp10,000 across 250 matching donors simultaneously to achieve instant order funding without triggering donor fatigue. Most importantly, we proved that humanitarian tech can be financially self-sustaining. By framing our 1.5% merchant convenience fee as a Guaranteed Bulk Buyout Insurance for local stores facing crisis uncertainty, we created a win-win B2B model that preserves 100% of public donations for actual relief supplies while keeping the platform cash-flow positive.

What we learned

We learned that any disaster response platform that relies on continuous cloud access is doomed to fail, proving that edge computing, local device caching, and asynchronous background synchronization are not optional features, but mandatory survival requirements for field operations. Through our user journey mapping, we discovered that donors do not suffer from a lack of empathy; rather, they suffer from a lack of transparency and control. Providing granular preference filters, such as choosing specific disaster types and provinces, paired with a 2-hour opt-out notification window drastically increases user trust and willingness to maintain an active deposit balance. Furthermore, we learned that shipping logistics from centralized government warehouses in distant cities is often the root cause of the 72-hour delay. Empowering surviving local grocery stores and MSMEs as decentralized emergency warehouses is the fastest, cheapest, and most dignified way to deploy immediate relief.

What's next for ARUSKITA

We are preparing to execute a live pilot project by signing an MoU with regional Disaster Management Agencies (BPBD) and onboarding 50+ wholesale suppliers in high-risk hydrometeorological zones across East Java. Once the immediate 72-hour crisis window stabilizes and communication infrastructure is restored, ARUSKITA will open its API bridge to push validated geospatial triage and survivor needs data directly into official government registries, such as BNPB's InaRISK and the Integrated Social Welfare Data (DTKS), ensuring a smooth transition from emergency relief to long-term state rehabilitation. We will also launch a dedicated white-label Corporate Dashboard, allowing large enterprises to deploy CSR emergency funds through ARUSKITA to automatically receive real-time impact reporting, transparent audit trails, and legally compliant tax-deductible receipts. To further solidify our trust layer without sacrificing transaction speed, we will implement an automated cron job that pushes our MariaDB SHA-256 Merkle Root Hashes to a public Layer-2 blockchain, such as Polygon or Arbitrum, every 24 hours, allowing independent auditors and watchdog institutions to mathematically verify that our historical disaster logs have never been tampered with.

View more

Deck: https://canva.link/4ignots2z5clpjh

Our website: https://aruskita.sabiagency.biz.id/

Built With

• bcrypt
• docker
• figma
• gin
• go
• gorm
• jwt
• leaflet.js
• mariadb
• midtrans
• next.js
• supabase
• tailwind
• typescript