WE BUILT SOMETHING FOR THE PEOPLE LEFT BEHIND

PATRICIO: SOLUTION ARCHITECT

The Problem With Aid

Disaster relief has a trust problem. Billions of dollars flow toward humanitarian crises every year. The problem is not the money. The problem is what happens after it moves.

Funds get diverted before they reach the field. Aid gets captured by intermediaries who were never meant to hold it. Donors have no visibility into whether their contribution reached a single person it was meant for. And the people most in need have no recourse when the system fails them, because the system was never designed with their recourse in mind.

But the trust problem is only part of it. The other half is a tangle of legal and regulatory requirements that, while well-intentioned, actively slow down distribution when speed matters most. IRS 501(c)(3) compliance requires charities to maintain rigorous records for every person receiving aid, including names, addresses, and selection criteria. That documentation burden often exceeds a charity’s staffing capacity mid-crisis. The Payment Integrity Information Act forces agencies to implement complex risk management and verification systems that can delay immediate cash assistance by weeks. Federal approvals for individual expenditures over $100,000 create bottlenecks on large-scale recovery projects. The Filing Relief for Natural Disasters Act adds layers of legal review for international aid.

These regulations exist for good reasons. Fraud in disaster relief is real. The problem is that the current compliance architecture treats speed and security as a tradeoff. You can move fast, or you can move carefully. The people waiting for help are collateral damage in that choice.

There is also a verification problem at the intersection of privacy and eligibility. Charities need to confirm that a recipient actually needs the aid. But unlike government agencies, they have no legal access to income or asset data. So they either distribute broadly and accept the fraud risk, or they collect sensitive personal data they are not equipped to secure. Neither option is good.

“The question was not ‘can blockchain fix aid?’ It was: what would a system look like where verification, compliance, and fraud prevention happen at the same time, in seconds, without exposing anyone’s private data?”

That question led us to build a transparent disbursement platform for humanitarian organizations, powered by Instruxi, Chainlink CRE, and Privy. Any relief org worldwide can deploy this, fund a USDC treasury, and run tamper-proof payouts with every step publicly auditable onchain. The disaster has to be verified by real external data before a dollar moves. Recipient eligibility has to be validated by policy, not by an admin’s judgment. And every financial movement produces a cryptographic attestation that anyone can inspect.

JULIA: MARKETING LEAD

Who This Is For

Most of the technology I work with at Instruxi is aimed at institutions. Investors. People who already have wallets and the kind of access that lets them participate in what we are building. That makes sense. Institutional adoption is how this industry matures, and a lot of genuinely important work is happening there.

This project is aimed somewhere different. Disasters do not discriminate by income bracket or geography. The people who need emergency aid fastest are just as likely to be in Louisiana after a hurricane as anywhere else in the world. What they have in common is not where they are from. It is that in the immediate aftermath of a disaster, the systems built to help them tend to move slowly, inconsistently, and with very little visibility into what is actually happening to the money.

The charity trying to help faces a real problem: to verify that someone qualifies for aid, you need to know something about their situation. But collecting that data requires legal authority most charities do not have, infrastructure to secure it most cannot afford, and staff to process it that nobody has mid-crisis. So verification either gets skipped and fraud gets in, or it becomes a bottleneck that holds up distribution for weeks.

“This was the first project where I looked at what we built and thought: this is for someone the system has already failed once.”

Disaster victims do not get much say in how aid reaches them. The gap between what donors intend and what recipients receive is large and mostly invisible. We built something that does not ask anyone to be more trustworthy. It makes trust irrelevant to the outcome.

PATRICIO: SOLUTION ARCHITECT

How We Removed the Human From the Trust Chain

The core design principle was straightforward: the parts of the system most vulnerable to corruption had to be controlled by code, not people. That means three things specifically: disaster verification, recipient eligibility, and financial attestation. Every other design decision followed from that.

We built four Chainlink CRE pipelines, each handling one piece of the trust chain.

Pipeline 1 verifies the disaster itself. Before a single dollar can move, Chainlink’s DON queries three independent live data sources: GDACS global red alerts, NASA EONET natural events, and the USGS earthquake catalog. Two of three must confirm the event. The contract transitions from Pending to Active automatically when CRE returns that consensus. There is no manual activation step and no admin override. If the data does not confirm the event, the contract does not open. What used to require manual review and take days now happens in seconds, with a public audit trail that satisfies downstream compliance requirements automatically.

Pipeline 2 handles recipient eligibility. The admin submits a batch of candidate information. Instruxi’s API provisions each recipient their wallet and categorizes them into their respective eligibility groups based on the batch. This batch, or roster, is anchored on-chain as a hash, allowing approved individuals or auditors to compare the live roster file with the definitive version posted on-chain. That extra layer of security proves the data was not tampered with between ingestion and payout. CRE then runs each recipient wallet through OPA policy validation inside the Chainlink DON and writes only the approved recipients back to the smart contract. The admin cannot approve a recipient directly. They cannot bypass the policy check. Eligibility is written once, by the DON, and it is permanent. Critically, the recipient’s underlying personal data never touches the charity’s systems. The Instruxi Enforcer holds encrypted profile data and validates group membership. The charity gets a yes or no. They never see the income data, the asset data, or anything else that would create legal exposure.

Pipelines 3 and 4 close the audit loop. Every disbursement and every deposit automatically triggers a TrustSync attestation through the Instruxi RWA Gateway, cryptographically signed, EIP-712 formatted, and published to the public record. Auditors can verify every financial movement without needing admin access. Regulators get an instant audit trail. Donors get real-time proof of impact.

“The roster CSV is never stored onchain. Its SHA-256 hash is anchored at processing time. Anyone can hash the original file and verify it was not tampered with after the fact.”

Once CRE writes eligibility onchain, recipients claim directly from the frontend. The contract checks eligibility and transfers. No approval queue. No admin bottleneck. No round-trip back to an offchain system at claim time. The speed-security tradeoff that defines traditional aid distribution disappears. The system is fast because the security work already happened upstream, enforced by the DON before anyone could claim.

JULIA: MARKETING LEAD

Good Intentions Don’t Show Up in an Audit

Most aid workers are doing their best. This is not an indictment of the people working in humanitarian relief. The problem is structural.

Good intentions do not show up in an audit. They do not stop a middleman from skimming. They do not tell a donor whether their money reached the person it was sent for. Traditional aid runs as a black box at every layer. The accountability mechanism is a report published months after the fact. If something went wrong, you might find out in the next annual audit. You might not.

There is a privacy problem here that does not get much attention. To verify someone’s need, you have to know something about their situation. But the moment a charity starts collecting income or asset data, they have taken on a legal and security burden most of them cannot carry. So they skip verification and accept the fraud risk, or they build slow manual processes that hold up distribution. Either way, the people waiting for help pay the price.

“What we built does not require the relief org to be honest. It requires them to be correct: submit the right roster, register the real event. The system handles the rest.”

We are not replacing bad actors with good ones. We are building a system where the outcome is enforced by the contract regardless of anyone’s intentions. A trustworthy org and a compromised one produce the same result: the contract pays who it was told to pay, nothing more, and every transaction is on the public record.

PATRICIO: SOLUTION ARCHITECT

Where This Version Falls Short

We are clear-eyed about the limitations of this build. The current implementation trusts the Instruxi Enforcer pipeline for eligibility. A compromised Instruxi API could theoretically approve an ineligible recipient. Per-event caps and the double-payment guard limit how much damage that could cause, but the trust assumption is real and worth naming.

V2 addresses this directly. The plan is an on-chain Merkle proof: the roster hash is committed at anchor time, and recipients submit a Merkle proof at claim time. Eligibility is then verified entirely on-chain with no off-chain dependency at all. That closes the remaining trust gap in the eligibility pipeline.

There is also a single admin key risk in the current deployment. One compromised key can register events and submit eligibility batches. For production deployments, this gets replaced with a multi-sig wallet. No single person should be able to act unilaterally on a treasury holding real funds.

It is also worth being direct about the roster itself. The system enforces everything downstream of ingestion with cryptographic certainty. The SHA-256 hash anchored on-chain proves the roster was not altered after submission. The OPA policy check proves only eligible wallets were approved. The TrustSync attestations prove every dollar moved where the contract said it would. None of that can be falsified after the fact.

What it cannot enforce is what happens before the roster arrives. A bad actor with admin access could submit a roster that includes fraudulent recipients before the system ever sees it. At that point, the system would process them correctly according to the rules it was given. The cryptographic guarantees apply to the integrity of execution, not the integrity of the input data. That distinction matters, and any honest deployment of this platform needs to account for it through access controls, partner vetting, and governance around who can submit a roster in the first place.

This is not a flaw unique to this build. It is the fundamental challenge of any system that bridges off-chain data to on-chain logic. The onchain half can be made trustless. The offchain half cannot. What this implementation does is compress the attack surface as far as it can go: once data is onchain, it is permanent, public, and verifiable by anyone. The window for manipulation is narrow and well-defined. That is a significant improvement over a system where the entire process happens behind closed doors.

Even with those limitations, the platform enforces invariants that most humanitarian organizations cannot match with their current infrastructure. No payout unless the event is verified Active by external data. No payout without CRE-written eligibility. No double payment. No payout after the claim window closes. Every one of those checks runs on every transfer, enforced by the contract.

“The architecture is real, the contracts are deployed on Sepolia, and the problem it is solving is not going away.”

We submitted this as a hackathon project. It is a working proof of concept with a clear path to production hardening. The core design holds up. The trust chain from donor to recipient is the most tamper-resistant version of this system we know how to build right now.

JULIA: MARKETING LEAD

The Plain English Version

A charity cannot fake a disaster to unlock funds. Once the roster is on-chain, a corrupt official cannot alter who gets aid or redirect payments. Every dollar that moves is permanently recorded. A recipient can claim directly, without a form, without a phone call, without waiting for someone to process their case.

The honest caveat is that right now, we are trusting the roster is legitimate when it arrives. Whoever submits it has to be acting in good faith. That is a real limitation, and Patricio lays out exactly what it means and what V2 does to address it. But in the current system, every step is a black box. There is no hash. There is no onchain record. There is no cryptographic proof of anything. This platform does not eliminate the possibility of fraud at the input stage. It eliminates it everywhere else and makes the input stage auditable enough that operating undetected becomes significantly harder.

The compliance work happens automatically. The fraud prevention happens before anyone can claim. Recipient data stays private by design. None of those things were true at the same time before this.

The use case explains itself. There is money. There are people who need it. The rules for who gets it are written in code, locked at registration, and enforced on every transaction. Every movement is public. The audit trail exists whether anyone asks for it or not.

A system that holds regardless of whether anyone feels like holding it. That is what we were trying to build.

The contracts are live on Sepolia.

Contracts deployed on Sepolia. ReliefTreasury: 0x5e588C93FAcb105fCf8b391D534D61064236EbC7 · Built at Chainlink Convergence Hackathon, March 2026

Instruxi: instruxi.io · RWA Federation: therwaf.io · Chainlink CRE: chain.link/chainlink-runtime-environment