Rescu

EBT for disasters, on Solana. Aid lands 0.93s after the storm hits, spendable only at verified local stores. Grok does the shopping, an ML oracle shuts down price gougers on chain.

Comment

Inspiration

Hurricane Helene hit Georgia on September 26, 2024. Georgia's disaster food stamps didn't open until October 21, almost a month later. You had to apply in person with an ID, and some counties waited about seven weeks. FEMA's emergency payment was around $750, and that came later too.

The slow part isn't sending money. It's figuring out who needs it, and making sure it actually gets spent on water, food and medicine instead of getting resold or eaten up by price gouging. After Katrina, the GAO estimated $600M to $1.4B in improper or fraudulent FEMA aid. After Helene, Georgia's Attorney General got around 400 price gouging complaints.

This year's HackGT theme was Seaside Market, so I built a market for the coast after a storm. Aid lands in seconds, it can only be spent where it should be, and something is watching the prices.

What it does

Rescu is a disaster relief market built on Solana. Aid airdropped in seconds.

  1. Figures out who needs help. A model looks at the storm itself (wind, rain flooding, storm surge, mobile homes and how vulnerable each neighborhood is) and decides who gets how much, right at landfall. No paperwork, no waiting.
  2. Airdrops the aid. An official clicks Declare disaster & fund, and "Relief Dollars" go out on Solana as the storm moves. Each neighborhood gets paid the moment the winds reach it. The median time from the storm hitting a home to money in the wallet was 0.93 seconds.
  3. Puts the rules inside the money. Every payment is checked on-chain: registered stores only, inside the disaster zone, max $200 per order, max $300 per 24 hours, no sending it to another resident. If you break a rule, the payment just fails, with the reason right in the logs.
  4. Shops for you with Grok. You tell Grok what you need ("storm hit, 4 of us with young kids, no water or food, no power"). It checks live store shelves nearby and builds a basket. Nothing gets paid until you tap Confirm, and Grok can only spend up to an on-chain limit you set. Even a jailbroken AI can't overspend.
  5. Catches gouging and fraud. An anomaly detection oracle watches every store's prices and every wallet. If a store jacks up the price of water, a case opens in under a second, Grok explains it in plain English, and one click suspends the store on-chain. The next payment to that store gets refused by the chain itself.
  6. Cleans up on Day 30. Unspent aid automatically goes back to the treasury (like EBT benefits expiring). Stores keep what they earned, and the books balance to the cent.

All of it plays out live on a 3D map: the hurricane moving in, aid rising behind it, purchases flying from homes to local stores, and blocked payments flashing red.

There are four pages:

  • Command Center: the live map, treasury, transaction feed, and a "Try to break it" panel with 13 real attacks you can fire at the chain.
  • Resident app (/aid): scan a QR on your phone, get aid, shop with Grok, or pay at a store's counter. You never need crypto, and fees are covered for you.
  • Merchant terminal: ring people up and change prices.
  • Oracle console: see flagged cases, the evidence, and take action.

How I built it

The model. I trained it on 23 real US hurricanes (2004 to 2024) and graded it against what FEMA actually paid out. It uses NOAA storm tracks, PRISM rainfall, USGS flood measurements, 83,241 Census tracts and the CDC Social Vulnerability Index. For each neighborhood:

$$\text{need} = 1 - e^{-h}, \qquad h = \text{wind} \cdot (1 + \text{mobile homes}) + \text{rain} + \text{surge} + \text{wind on soaked ground}$$

and each household's payout is:

$$\text{aid}_i = \text{clamp}\left(\lambda \cdot \text{need}_i \cdot \text{vulnerability}_i,\ \$250,\ \$2{,}000\right)$$

where $$\lambda$$ is solved so the whole budget gets spent and the average comes out to exactly $1,000.

One thing I didn't expect: FEMA's data is biased. It pays wealthier, insured areas differently than vulnerable ones, so I modeled that bias to keep it out of the model, then added vulnerability back as a clear policy choice (0.7x to 1.3x).

Each storm was tested with a model that never saw it:

  • Rescu's split of aid across counties matched FEMA's real payouts way better than a simple wind rule (0.64 vs 0.38 overlap), and won on 22 of 23 storms.
  • The counties Rescu picks at landfall cover about 95% of the households FEMA ended up helping weeks later.
  • For Helene, the biggest payouts go to Asheville, Valdosta and the same places FEMA's data shows were hit hardest. A wind-only model misses Asheville completely, because Helene's damage there was from flooding.

The blockchain. One Anchor program in Rust handles the store registry, the treasury and the rules. The rules live in a Token-2022 transfer hook, which means they run on every single payment and nobody can skip them. The 24 hour cap is truly rolling, so you can't spend $300 at 11:59 PM and another $300 at 12:01 AM. The same program is also deployed on Solana devnet, with real failed transactions showing each rule working.

The simulation. A Node server runs 20,000 households and 500 local stores through a full 30-day recovery on my own Solana validator, hosted on Vultr in Atlanta. About 1% of residents and 2% of stores are planted bad actors, so the oracle has real fraud to catch.

Tiger Data. Every payment streams into TimescaleDB, and the live dashboard reads from continuous aggregates. You can drag the timeline back and the whole dashboard rebuilds itself as of that moment.

Grok. Grok powers the shopping agent and writes the fraud case summaries. The whole project cost about 30 cents in credits.

The map. Next.js, MapLibre and deck.gl, with ~15,000 animated hexagons and a custom GPU hurricane, running at 60 fps.

The numbers (one full Helene run on Vultr)

  • 20,000 households and 500 stores set up on-chain in 30 seconds
  • $19,997,202.94 in aid delivered, median 0.93 s after the storm arrived, 0 failed
  • 136,645 purchases ($10.14M), confirmed in about 0.4 s each
  • 423 rule-breaking payments blocked by the chain
  • $9,853,260.92 returned on Day 30, with spent + returned matching to the cent
  • Live dashboard queries in 28 ms (median) while ingesting almost 3,000 rows a second
  • Oracle precision 0.99, recall 0.87, and it caught all 10 price gougers

Challenges I ran into

  • The obvious approach was wrong. "Pay everyone who got tropical-storm winds" turned Helene into 23 million households across 12 states, while Asheville (where Helene was deadliest) only got moderate wind. It was a flood disaster. That's why I rebuilt the model around multiple hazards and trained it on real FEMA outcomes.
  • My code was the bottleneck, not Solana. I was capped at around 150 payments a second because of slow JavaScript signing. Caching and switching to Node's native crypto got me a 9x speedup.
  • Keeping time on-chain. The demo runs 30 days in about 8 minutes, so the chain's clock runs thousands of times faster than real time. When the validator's clock slipped by a few seconds under load, that turned into almost a full day, and suddenly every payment bounced as "expired." I added a guard that checks the clock every second and fixes it before anything breaks.
  • Grok promising stuff that sold out. Other shoppers kept buying while Grok was thinking, so it would suggest items that were already gone. Now every basket gets checked against the live shelf before it's shown.
  • Every store closed at once. My first version shut down every store in the storm's path, so nobody could buy anything right after getting aid. Now closures depend on how bad the storm was in that spot, like real towns where some stores stay open on generators.
  • Devnet rate limits. Public devnet blocked the venue WiFi in the middle of my deploy, so I had to deploy from the Vultr server instead.

Accomplishments that I'm proud of

  • Built solo in 36 hours, and it was my first time building on-chain.
  • A model that's actually tested against 23 real storms, not just a guess.
  • It's live at rescu.tech. Judges can scan a QR, get aid on their phone in under a second, and try to break the rules themselves.
  • After 136,645 purchases, the books still balance to the cent.

What I learned

  • Solana and Token-2022 from scratch: transfer hooks, program accounts, all of it.
  • Deciding who gets aid is a data problem more than a payments problem, and even FEMA's data has biases you have to work around.
  • Always measure on the real server. My laptop was so overloaded it made aid look like it took 40 seconds. On Vultr it was under 1.

Limitations

The model can't predict things like a levee failing (New Orleans in 2005). Stores are simulated with made-up names, identity checks are mocked, and delivery is out of scope. The money stays in local stores that are open.

Built With

Share this project:

Updates

Submission history