On-chain philanthropy with the Swiss Zakat Foundation

CipherPhi separates the key that moves money from the key that decides who receives it, and gives neither party the other's capability.

Nothing is deployed. The design is public at Revision 2 in the project repository,¹ the SCF #45 Build Award submission sits in panel review on the Open Track, and funded contract development begins at grant kickoff. Every control below is a design commitment the delivered code can be checked against, rather than a property of running software. The system moves zakat for the Swiss Zakat Foundation, a federally supervised Swiss foundation collecting and redistributing zakat since its founding deed of 6 July 2021, audited annually.² The institution works. What is being built is the rail underneath it.

One contract holds funds

One contract holds funds. The other two are consulted by it and can never move anything.

The alternative was a single binary with three modules and a promise to split it later. That loses on upgrade granularity. The two components most likely to change are a refinement to the Shariah parameters and a change to the eligibility scheme, and in a single binary each of those redeploys the thing holding donor money. Split as below, refining the administration cap redeploys policy, changing the attestation scheme redeploys attestation, and custody is untouched by either.

THE SPLIT LINE IS VALUE, NOT TIDINESS. A DEFECT IN POLICY OR ATTESTATION PRODUCES A WRONG ANSWER RATHER THAN A LOSS, WHICH IS THE WHOLE RETURN ON THE SEPARATION.

The cost is a wider audit scope, three Wasm binaries rather than one, and a cross-contract call is a place where a wrong answer can enter. It is paid by treating both callees as untrusted input. An allocation is rejected unless the returned vector has exactly eight elements, every element is zero or positive, and they sum exactly to the amount received. Checking only the sum would not be enough. A split of the shape [amount + x, -x, 0, ...] sums correctly, passes checked arithmetic, and leaves total custody intact while silently crediting one category from another's beneficiaries. Neither callee holds an address that lets it call back into the pool, so no defect in either reaches the money.

The attestation is what separates this from a treasury multisig

A treasury multisig lets one quorum both approve a payment and send it.

Access control ranks first in the OWASP Smart Contract Top 10 for 2026, derived from 122 deduplicated smart contract incidents recorded during 2025 and totalling approximately USD 905.4 million in losses.³ The category covers privilege concentration and insufficient separation of duties, so separation is the control worth paying for, and paying for it means enforcing it in the contract rather than in a policy document.

distribute accepts a signed attestation and verifies it before any transfer. The signature binds recipient, asset, category, amount, the pool's distribution sequence, the pool's contract address, and the network passphrase. The distributor key cannot produce that signature. The attestation quorum holds no key that can call the contract.

THE DESIGN ASSUMES ONE KEY IS EVENTUALLY COMPROMISED. A COMPROMISED DISTRIBUTOR PRODUCES FAILED TRANSACTIONS, AND A COMPROMISED ATTESTATION QUORUM PRODUCES SIGNATURES NOBODY EXECUTES.

Severity here is argued through the precondition. Theft by the distributor requires a forgeable attestation, which the scheme does not provide. Theft by the attestation quorum requires a key that can call distribute, which it does not hold. Neither precondition is available to a single compromised party.

Sequence binding carries a cost worth stating before a reviewer finds it. A valid signature executes exactly once, with no stored list of used signatures, but attestations then execute in the order they were signed. One abandoned at sequence N strands every attestation signed after it until they are reissued. At pilot cadence, a handful of distributions to one partner organisation, serial execution is the behaviour you want. At scale it is a throughput constraint.

Rotation is redeployment, not a setter

The attestation contract has no setter for its key set.

authority is fixed at construction, so changing the quorum means deploying a new attestation contract and repointing the pool at it, under the same delay and the same events as every other governance change. The in-place setter lost on one point: it would be an instant path to a quorum of governance's choosing, which defeats the delay sitting beside it. Removing it also removes a setter from the audit surface, and the mainnet attestation contract is then constructed with the final 2-of-3 set rather than migrating into it.

Custody goes further. A Soroban contract is mutable only if it compiles in an upgrade entry point, so a contract omitting update_current_contract_wasm is immutable by construction.⁴ zakat_pool omits it, because code that can be silently replaced over donor funds is an admin key by another name. The cost is that a custody defect cannot be patched in place, paid by a new deployment with a published address and a migration a donor can watch, and by entering independent review well before mainnet rather than alongside it.

What waits seven days, and what does not

Two things are deliberately instant.

EACH DELAYED CHANGE EMITS AN EVENT AT PROPOSAL, AT EXECUTION AND AT CANCELLATION. INSTANT REVOCATION COSTS NOTHING THE DELAY WAS PROTECTING, BECAUSE A DISABLED DISTRIBUTOR STILL CANNOT MOVE FUNDS WITHOUT AN ATTESTATION.

The floor

What remains is collusion between the Foundation and the delivery team, through governance repointing attestation at a permissive contract.

That is the floor rather than an oversight: two organisations, two key sets, and no way to reduce it further without a third party holding neither. Three things constrain it. The pilot runs with capped amounts, bounding the window between a visible proposal and a possible loss. A named party monitors the proposal, execution and cancellation events with an off-chain escalation path, because a timelock nobody observes is a delay rather than a control. And one invariant governs the seats: delivery-team seats stay below the governance quorum threshold, otherwise the floor is one organisation plus a seven-day wait.

The same reasoning keeps the delivery team out of the attestation quorum, whose three seats are the Foundation's Executive Director, the Shariah authority, and an independent seat appointed by the Foundation. With a delivery seat, the delivery team plus any one other signer would produce a valid attestation and execute it in the same transaction, instantly and with no timelock. That is a strictly easier path than the collusion above, which is why the exclusion is a design constraint rather than an accident of staffing.

What a donor can check

A donor can verify that their category was distributed to a recipient whose eligibility was signed before the funds moved.

They cannot verify that their individual coins reached a named person. Zakat is pooled by construction, and the eight-category split is what the methodology operates on, so per-donor tracing to an individual recipient would be a fiction dressed as cryptography. Category-level delivery with a verifiable attestation on every disbursement is the strongest true claim available.

Every figure a donor sees resolves to a ledger event carrying the transaction hash that produced it. The pool moves USDC through the Stellar Asset Contract, which implements the SEP-41 token interface, so asset movements surface as standardised transfer events whether they originate from a payment operation or a contract call.⁵ The interface reading those events can go down, and if it does the donor flow goes down with it. It cannot go wrong quietly, because the record it renders is not a record it holds.

What this does not cover

The next checkable thing is the first commit of contract source against the architecture published at Revision 2. Until then every claim above is a design commitment, and that document is the one a reviewer should hold it to.

Sources

Footnotes

1. CIPHERPHI ARCHITECTURE, REVISION 2. github.com

2. SWISS ZAKAT FOUNDATION. zakat.ch

3. OWASP SMART CONTRACT TOP 10 FOR 2026. scs.owasp.org

4. STELLAR DEVELOPER DOCS, UPGRADING CONTRACTS. developers.stellar.org

5. STELLAR DEVELOPER DOCS, STELLAR ASSET CONTRACT AND SEP-41. developers.stellar.org

6. SOROBAN SECURITY AUDIT BANK. stellar.org

7. SCF HANDBOOK, AUDIT BANK OFFICIAL RULES. stellar.gitbook.io

8. STELLAR DEVELOPER DOCS, FUZZING SOROBAN CONTRACTS. developers.stellar.org

9. STELLAR DISBURSEMENT PLATFORM. developers.stellar.org