Inspiration
In Chile, wildfires, floods, earthquakes, and prolonged outages can disrupt communications exactly when reliable information matters most. During the first hours of an emergency, communities may know what is happening on the ground, but responders often lack a structured and trustworthy way to receive that information. Municipalities, NGOs, and Chile’s Disaster Risk Management Committees (COGRID) can be forced to coordinate aid with incomplete or delayed data. VACA (*Vaquita de Ayuda y Coordinación Activa*) was born from a simple idea: **on Day 0, information can be as valuable as any physical resource**. A phone in the field should be able to preserve a verifiable emergency signal—with or without internet—and deliver it when connectivity returns. ## What it does VACA is an offline-first mobile application that allows neighbors and volunteers to report what is happening during an emergency. - **Offline incident capture:** a four-step flow records the incident category, optional location, essential details, number of affected people, and optional photographic evidence. - **Local-first persistence:** the signal is stored in Drift/SQLite before any network operation. Optional photographs are protected with SHA-256 hashes, and timestamps andGPS data are included when available. - **Store-and-forward delivery:** each signal is encoded as CBOR, encrypted with AES-256-GCM, signed by the device with Ed25519, and placed in a durable outbox. Delivery isretried automatically when connectivity returns. - **Verifiable server receipts:** the Supabase backend validates and atomically accepts the bundle, then returns a signed receipt that the app verifies locally. This provestechnical reception without falsely promising institutional response. - **Optional identity verification:** Didit KYC runs in sandbox through a fail-closed adapter. Identity verification is never required to capture urgent signals. - **Stellar Testnet aid loop:** VACA creates a self-custodied Stellar wallet for the user. A donor can fund a signal, the system creates a Claimable Balance for the reporter, and the beneficiary can claim the Testnet funds from the mobile app. - **Proof of Aid:** a non-transferable, NFT-shaped Soroban record links the beneficiary, incident hash, claim transaction, image hash, and ledger timestamp. The image is currently bundled locally and bound by SHA-256; we do not claim IPFS or decentralized media storage. - **Responsible monetization:** advertising is restricted to the informational “About VACA” screen. RevenueCat is used only as an ad-measurement boundary, with no purchasesor paywalls, and incident data is never used for advertising. ## How we built it The mobile application is built with Flutter, Riverpod, and clean architecture. Drift/SQLite manages the incident lifecycle, append-only event history, durable outbox, attachments, and signed receipts. The backend uses Supabase Postgres, Storage, migrations, and Edge Functions including `bundle-ingest`, `attachment-authorize`, KYC boundaries, public signal feeds, voting, and administrative promotion. Bundles use CBOR encoding, AES-256-GCM encryption, X25519 recipient keys, Ed25519 device signatures, request nonces, atomic acceptance, and idempotent replay protection. The Stellar layer uses real Testnet transactions for donations, Claimable Balance emission, beneficiary claims, and community ballots. The Proof of Aid contract is written in Rust with the Soroban SDK.
A companion Next.js web application provides the donor, community-voting, curation, and public-verification surfaces.
Our current automated verification includes:
- 69 Flutter tests.
- 16 deterministic visual-regression scenarios.
- Accessibility checks at 200% text scaling.
- 8 Playwright E2E tests.
- Production-bound Stellar transaction contract tests.
- A real opt-in Testnet smoke test covering donation → Claimable Balance → claim.
- 3 Soroban contract tests for authorization, uniqueness, and image-hash binding.
Challenges
The hardest challenge was making synchronization honest.
A locally stored signal must never be presented as received by a server. A receipt must be cryptographically verifiable and bound to the exact bytes delivered. During implementation, we resolved CBOR decoding differences, a subtle Ed25519 signature-length mismatch, replay idempotency, independent attachment retries, and drift between the client’s public trust roots and the keys deployed on the backend.
Field testing also exposed an important offline weakness: high-accuracy GPS and CameraX initialization currently need explicit timeouts and stronger lifecycle handling in degraded indoor environments. VACA can still preserve a signal without GPS or a photo, but this behavior must be made faster and clearer.
Distribution was another non-technical challenge. Publishing under Fundación Camada requires a Google Play organization account and a D-U-N-S number. The verification timeline did not fit the competition window, so the signed APK is available for review but is not yet publicly listed on Google Play.
What we learned
Offline-first is not a caching feature—it is a trust protocol.
A local save is different from a server receipt. A server receipt is different from institutional acknowledgment. Emergency capture must remain available without connectivity, sign-in, KYC, biometrics, advertising, or payment.
We also learned that blockchain is most useful here when it makes a specific event independently verifiable: who could claim the aid, which transaction delivered it, and what incident evidence it was bound to.
What’s next
Our next priorities are to:
- Add bounded GPS and camera timeouts with honest degraded-mode fallbacks.
- Complete the physical-device walkthrough that joins offline capture, Supabase receipt, donation, Claimable Balance, mobile claim, and Proof of Aid.
- Publish through Fundación Camada’s verified Google Play organization account once the D-U-N-S process is complete.
- Continue institutional validation with municipalities and emergency-response organizations.
- Keep all financial activity on Stellar Testnet until legal, security, recovery, and pilot requirements are ready for production.
Built With
- flutter
- stellar
Log in or sign up for Devpost to join the conversation.