The problem RELIEFCHAIN solves

**## 🌍 The Problem It Solves

When disaster strikes, people donate fast — but accountability moves slowly.

Traditional disaster-relief funding relies on banks, crowdfunding platforms, organizations, spreadsheets, and centralized databases. Donors often have no way to independently verify:

• Where their money went
• Who received it
• What it was spent on
• Whether the reported relief actually happened

This creates a fundamental problem:

You can trust the intention of a donation without being able to verify its journey.

ReliefChain changes that by turning disaster relief into a transparent, programmable, and auditable on-chain process.

🚨 What ReliefChain Enables

For Donors

Donate directly through Sui and follow the movement of funds on-chain — from the campaign treasury to verified relief milestones.

For Relief Organizations

Create structured campaigns with defined funding milestones such as:

Emergency Supplies → Medical Aid → Food Distribution → Reconstruction

Funds are managed by Move smart contracts rather than being immediately handed to a campaign creator.

For Verifiers

Authorized verifiers can review submitted relief evidence and approve milestone-based fund releases, creating an additional accountability layer between donations and spending.

For Auditors & the Public

Every important financial action can be independently inspected on-chain, creating a permanent and transparent audit trail.

🔐 Making Disaster Relief Safer

⚡ The Core Idea

ReliefChain separates trust from transparency.

Instead of asking donors to simply believe that their donation reached the right place, the protocol makes the financial journey cryptographically verifiable.

Donate → Verify → Release → Audit

The result is a disaster-relief system designed to make humanitarian funding more transparent, accountable, and programmable.

Don't just donate. Know where your relief goes.**

Challenges we ran into

🛠️ Challenges We Ran Into

Building ReliefChain as a genuinely Web3-native disaster-relief protocol came with several challenges — especially around making on-chain funds, verification logic, and decentralized evidence work together reliably.

1. Designing Non-Custodial Fund Management

One of our biggest challenges was ensuring that donated funds were not simply transferred to a campaign creator's wallet.

We redesigned the flow around a Move smart-contract treasury where donations remain controlled by the protocol. Instead of relying on the frontend to enforce rules, the Move contract becomes the source of truth for:

Donation → Campaign Treasury → Milestone Verification → Fund Release

This forced us to think carefully about authorization, object ownership, treasury accounting, and preventing unauthorized withdrawals.

2. Connecting On-Chain State With the Frontend

Another hurdle was keeping the frontend synchronized with blockchain state.

Initially, some UI state could become stale after transactions or page refreshes. We moved toward treating Sui as the source of truth, fetching campaign and transaction state from the blockchain rather than relying on temporary frontend state.

This was especially important for ensuring that campaigns and donation history remain verifiable after a refresh.

3. Wallet & Transaction Handling

Wallet integration introduced another layer of complexity.

Transaction signing, gas management, network configuration, wallet connection state, and transaction confirmation all had to work together. A transaction could be successfully submitted while the frontend was still waiting for confirmation or displaying stale information.

We addressed this by improving transaction lifecycle handling:

Connect → Build Transaction → Sign → Execute → Confirm → Refresh On-Chain State

This made the application much more resilient to delayed confirmations and RPC responses.

4. Making Relief Evidence Verifiable

Disaster-relief evidence can include large files such as photographs, invoices, delivery manifests, and reports. Storing everything directly on-chain would be inefficient and expensive.

We therefore separated the architecture into two layers:

Sui = Financial & Verification Layer
Decentralized Storage = Evidence Layer

Instead of putting large files on-chain, the system stores the evidence off-chain in decentralized storage and anchors its identifier/hash to the corresponding on-chain milestone.

This gives us the scalability of decentralized storage while preserving a verifiable connection between evidence and fund releases.

5. Designing for Real-World Failure

A disaster-relief application cannot assume that every transaction, upload, RPC request, or verification step will succeed.

We added explicit handling for failed transactions, rejected wallet signatures, missing evidence, invalid campaign states, and incomplete milestone flows.

The result is a system where failures are treated as expected protocol states rather than silent frontend errors.

💡 Biggest Lesson

The hardest part wasn't simply putting a donation button on a blockchain.

It was designing the system so that money, evidence, permissions, and verification all share the same source of truth.

That led us to our core design principle:

The frontend can display the truth — but the smart contract must enforce it.