# Programmable Charity: How Rules Can Guide Digital Giving

> Learn how programmable charity may use smart contracts, what the code can and cannot prove, and which governance checks donors and charities still need.

Published: 2026-03-03  |  Updated: 2026-11-04  |  Author: MRHB Team

Canonical: https://mrhb.network/blogs/what-is-programmable-charity/
See also: https://mrhb.network/llms.txt

---

> **Important:** Programmable charity is a design idea, not a guarantee of impact, transparency, legal compliance or Shariah compliance. Code can apply written rules. People still choose the rules, verify outside facts, control access and handle exceptions.

## Quick answer

**Programmable charity** means using software rules to guide how a donation is received, held, released or reported.

A smart contract might release funds in stages, require several approvals or return unused funds under defined conditions. A digital credential might help show who issued an eligibility claim. A public ledger might show that a transfer happened.

None of these tools can prove by itself that a family needed help, a clinic was built well or a programme improved lives. Good giving still needs clear purpose, responsible people, financial controls, privacy protection and a way to correct mistakes.

## What makes a donation “programmable”?

A normal digital donation already uses software. A payment page checks an amount, processes a card or bank transfer and creates a receipt.

The word **programmable** usually means that more of the giving policy is expressed as rules. For example:

- release 20% after an approved verifier signs a milestone;
- require two people to approve a payment;
- accept funds only for a named programme;
- match eligible donations up to a fixed limit;
- send a set amount on a schedule;
- pause future payments after a risk alert; or
- return remaining funds if a clearly defined condition is met.

These rules may run in a normal database, a payment platform or a blockchain smart contract. Blockchain is one possible tool, not part of the definition.

## A simple programmable-giving flow

1. **A donor chooses a purpose.** The terms should say what the gift supports and whether it is restricted.
2. **The organisation records the gift.** It identifies the asset, amount, date, fees and any conversion.
3. **Rules control the next action.** Software may require a date, approval, limit or outside signal.
4. **A person or system supplies evidence.** This might be a signed report, invoice, inspection or credential.
5. **The payment is approved and delivered.** Someone must still manage signers, keys, providers and recipients.
6. **Results are checked separately.** Transaction evidence and programme impact are not the same thing.
7. **Exceptions are handled.** The design needs pause, correction, dispute and closure procedures.

The flow is only as reliable as its weakest link.

## What can a smart contract actually do?

Ethereum describes a smart contract as code and data stored at a blockchain address. Users send transactions that call its functions, and the code runs under the network's rules.

For charity, that code may:

- keep a balance associated with a programme;
- check whether an authorised address approved a step;
- apply a spending limit;
- split a payment using fixed percentages;
- record a state such as “funded,” “paused” or “completed”; or
- send funds when defined conditions are met.

The contract knows blockchain data. It does not see the physical world.

If a release depends on rainfall, identity, delivery or construction progress, an **oracle** or human verifier must report that fact. The contract can process the report exactly as programmed even when the report is late, incomplete, dishonest or wrong.

## Four questions that must stay separate

| Question | What may answer it | What remains uncertain |
|---|---|---|
| Was a transaction recorded? | Bank, payment provider or blockchain record | Whether the purpose was appropriate |
| Did the rule trigger? | Application log or smart contract state | Whether the input was true |
| Did the intended recipient receive usable value? | Receipt, provider record and recipient confirmation | Fees, access, conversion and coercion |
| Did the programme create the intended result? | Monitoring, evaluation and community feedback | Attribution and longer-term effects |

A transaction hash answers only the first question. Calling it “proof of impact” skips the other three.

## Where programmable rules may help

### Staged funding

A programme can divide a budget into parts and release each part after review. This may limit how much is exposed at one time.

But milestones can reward what is easy to measure instead of what people need. A school is not successful merely because a wall was photographed. A good design allows justified changes when reality differs from the plan.

### Multiple approvals

Several authorised people can be required to approve a transfer. This can reduce the risk of one person controlling all funds.

The [smart-contract-wallet guide](https://mrhb.network/blogs/smart-contract-wallets/) explains why signers, recovery, modules and upgrade powers must be mapped before money is held.

### Restricted spending

Rules may limit which accounts, merchants or categories can receive funds. That can support a defined programme, but it can also prevent a recipient from buying what is actually needed.

Charities must still account for restricted funds according to their governing documents and local law. Software labels do not replace that duty.

### Matching and recurring giving

Software can match eligible donations or schedule repeated transfers. The design should state the limit, end date, cancellation process, fees and what happens after a failed payment.

### Signed claims and credentials

A verifiable credential can help a verifier check which issuer made a claim and whether it was altered. For example, an authorised organisation might issue a signed eligibility statement.

That does not prove the issuer investigated correctly. The charity must decide which issuers it trusts, what evidence they need and how a person can challenge a decision.

## What a public ledger does not prove

A public ledger can make a transfer history easier to inspect. It does not automatically reveal:

- who controls an address;
- why a payment was made;
- what happened after conversion to cash;
- whether a supplier delivered the right goods;
- whether the recipient was pressured;
- whether personal data was handled lawfully; or
- whether the programme met its purpose.

Transparency also has a cost. Public addresses and transaction patterns may expose recipients, staff or communities. Humanitarian data can create safety risks when identities, locations or needs become linkable.

Publish the minimum information needed for accountability. Keep sensitive beneficiary data off a public chain and obtain jurisdiction-specific privacy advice.

## What can go wrong?

### The rule is too rigid

A flood route changes, a supplier fails or a recipient needs something different. A rigid rule can lock funds when a responsible human decision is needed.

Define who may pause or amend the process, which changes require approval and how all parties are informed.

### The evidence is wrong

An oracle, inspector or credential issuer can make a mistake. Use more than one source where the risk justifies it, record conflicts and provide an appeal path.

### Keys or accounts are lost

The organisation may lose access or a signer may leave. Document backup, recovery, staff exits, emergency access and transaction review.

### Code contains a bug

A contract can execute exactly as written and still produce a harmful result. Testing and review reduce uncertainty but do not guarantee safety. Start with low limits, monitoring and a response plan.

### Fees or conversion reduce the gift

Network, payment, exchange, custody, tax and withdrawal costs can appear at different stages. Show donors and recipients which amount was given, converted, charged and delivered.

### People are excluded

A recipient may lack a phone, document, connection, wallet or safe way to convert an asset. Always offer an accessible support path and test the process with intended users.

### The legal structure is unclear

Digital assets and charity duties differ by country. The UK Charity Commission, for example, tells charities in England and Wales to understand cryptoasset risks, keep accurate records, adopt suitable policies and manage restricted funds. Other jurisdictions have different rules.

## Zakat, sadaqah and waqf need different rules

Islamic giving is not one interchangeable category.

- **Zakat** has eligibility, calculation, timing and distribution questions.
- **Sadaqah** is voluntary giving, but the donor's purpose and the charity's responsibilities still matter.
- **Waqf** involves a dedicated asset and governance structure; it is not simply another donation wallet.

Software cannot decide whether a structure is valid under Islamic jurisprudence. The [halal-fintech guide](https://mrhb.network/blogs/what-is-halal-fintech/) explains the broader principle: technology is a tool, while permissibility depends on the activity, contract, assets and governance.

An actual programme needs review by qualified Shariah scholars and by legal, charity, tax and privacy specialists in the relevant jurisdictions. This article does not give a fatwa.

## Checklist for a donor

Before giving, ask:

1. Who is the legal recipient of the donation?
2. Is the gift restricted, and what happens if the purpose cannot be completed?
3. What asset will the organisation receive and hold?
4. Which fees and conversions may reduce the amount?
5. Who controls the contract, wallet, pause and upgrade powers?
6. Who verifies milestones or recipient eligibility?
7. What does the public record prove—and what does it not prove?
8. How can an error, dispute or refund request be handled?
9. How is recipient privacy protected?
10. Where can programme and financial reports be checked?

## Checklist for a charity

Before launching, document:

- the charitable purpose and legal basis;
- donation-acceptance and asset-conversion policies;
- restricted-fund and accounting treatment;
- donor, partner and recipient checks required by law;
- signers, limits, recovery and staff-exit controls;
- code owners, administrators, upgrades and emergency powers;
- evidence sources and conflict-resolution rules;
- fees, custody, tax and reporting responsibilities;
- privacy, accessibility and non-digital alternatives;
- incident response, communication and system closure; and
- independent Shariah review for any Islamic-giving claim.

If the team cannot explain these points without technical language, the programme is not ready for donors.

## Frequently asked questions

### Does programmable charity require a blockchain?

No. A normal application can apply donation rules. A blockchain may be considered when several independent parties need a shared record or programmable asset, but it adds its own costs and risks.

### Does a smart contract remove the charity?

No. People still define purpose, choose recipients, verify evidence, manage keys, meet legal duties and respond to harm.

### Can every donor track where every unit went?

Not automatically. A ledger may show transfers between addresses. It may not identify the people, final goods, off-chain payments or programme results.

### Are smart-contract donations refundable?

Only if the rules, available funds, controlling permissions and applicable law allow it. Irreversible transfers cannot be assumed to return automatically.

### Is programmable charity Shariah-compliant?

There is no blanket answer. The giving type, source of funds, contract, recipients, fees, custody and governance all require qualified review.

### Is crypto required?

No. The most suitable payment rail depends on the charity, donor, recipient, law, cost and access needs.

## Final takeaway

Programmable charity can make some giving rules visible and consistent. It cannot turn a difficult human programme into a trust-free machine.

Use code for tasks it can perform: limits, approvals, schedules and records. Use responsible governance for tasks it cannot perform: judging need, protecting people, correcting mistakes and measuring impact.