Donation seal | Barakah Wakaf Tenaga

#	Covers seals up to	Status	Sent	Files
1	#1544 3de7e5e914cefe01…	Awaiting Bitcoin	16 Oct 2026	.txt .ots

Why there is a seal

A wakaf is a trust. Donors give once and expect their gift to be recorded exactly as it was made, for as long as the mosque's solar system runs. The seal makes that promise checkable: if anyone, inside or outside Barakah, ever changed a donation record, it would show.

What is sealed, and what is not

Sealed: each paid wakaf, and each refund of a paid wakaf. Nothing else.
For a payment the seal covers the reference, certificate number, campaign, donor name as entered, amount, lot numbers, payment method, payment reference and the time of payment.
For a refund the seal covers the reference, the amount, the time of the refund and the reason given.
Not sealed: pending (unpaid) checkouts, mosques, campaigns, claims, payments to installers, users and settings. These keep working exactly as before, with the audit trail recording changes.
Email and phone are not part of the seal, and are never published.

How a seal is made

The payment clears. In the same database transaction that marks it paid, Barakah writes the donation's facts as a fixed-format record.
It takes the fingerprint of the previous seal and works out a new fingerprint (a SHA-256 hash, 64 characters) from that and the record.
The new seal is saved with its number, the previous fingerprint and its own. The seals form one chain, oldest to newest.
Because each fingerprint includes the one before it, changing any record, even one letter or one sen, changes its fingerprint and breaks every seal after it.
The database itself refuses to edit or delete a seal. Not even an admin screen can do it, because there is no such screen.

The Bitcoin timestamp

Every night at 23:50 the newest fingerprint (the "chain head") is timestamped on the Bitcoin blockchain through OpenTimestamps, a free, public timestamping service.
Only a fingerprint is sent. No names, amounts or references leave Barakah. Bitcoin never holds the donations themselves.
A new timestamp shows Awaiting Bitcoin at first. Barakah collects the confirmation every 6 hours; it usually arrives within a few hours, then the row shows the Bitcoin block number.
One timestamp covers every seal up to the head it names. A donation paid at 10 am is covered by that night's timestamp.
If no donations were paid since the last timestamp, no new one is made, because the head has not changed.
Why it matters: Barakah controls its own server, so the server alone could in theory rewrite the whole chain. Once the head is on Bitcoin, nobody can rewrite the chain before that point without the public proof showing it.

Check a Bitcoin timestamp yourself

Open the Donation seal page (link in the footer, or /donation-seal).
In Bitcoin timestamps, find a row that shows a Bitcoin block number.
Download the .txt statement and the .ots proof.
Open the statement: it names the programme, the seal number and the chain head fingerprint it covers.
Go to opentimestamps.org, drop the .ots file, then drop the .txt file when asked. It shows the date and Bitcoin block that prove the statement existed then.
Technical users can run ots verify statement.txt.ots instead.

For donors: your certificate

When the payment clears, the receipt e-mail arrives with the wakaf certificate attached as a PDF. Keep it safe or print it.
The certificate prints the seal number and the donation's fingerprint (split over two lines). The receipt e-mail shows the full fingerprint too.
Your copy is your own evidence. It is outside Barakah's control, so if the record were ever altered, it would no longer match what you hold.
A copy can be downloaded again from My Barakah at any time, but the one you kept from the day you gave is the strongest evidence.
Lost the e-mail? Sign in to My Barakah with the same email and download it again.

Reading the verify page

The verify link on the certificate opens the public check. It shows the certificate details, then a Donation seal box:

Donation seal intact (green): every check below passed.
Record: whether today's donation record still matches what was sealed when it was paid.
Chain: whether every seal from the first one up to this donation still links correctly.
Your certificate: whether the fingerprint printed on the certificate (carried in its link) matches. Shown only when opened from the certificate's link.
Bitcoin: the block it was timestamped in; or "sent for timestamping" while awaiting Bitcoin; or "will be included in today's Bitcoin timestamp" for a donation made today.
Donation seal does not match (red): one of the checks failed. Contact the programme. The trustee has also been alerted by the daily check.

Refunds and corrections

Donations have no edit screen. A paid donation is never changed.
A refund is sealed as a new event that points at the original donation. The original payment seal stays in the chain, so the history shows the gift and then the refund, never a gap.
To correct a mistake (wrong amount, wrong name on a paid donation), Finance refunds it with a clear reason and the donor gives again, or a new contribution is recorded. Both events are sealed.
After a refund the certificate is no longer valid: its verify link shows No valid certificate found, and its lots are free for others. The payment and the refund both stay in the sealed chain.

For admins and finance: the daily check

At 23:40 any paid donation or refund still without a seal is sealed (a safety net; normally they are sealed at the moment of payment).
At 23:45 the whole chain is checked: every seal against the one before it, every sealed donation against today's record, every paid donation has a seal, and every Bitcoin timestamp still matches the chain.
The result is shown as Last integrity check on the Donation seal page.
If anything fails, every admin gets a red notification, and the problems are written to the audit trail as seal.check_failed.
At 23:50 the chain head is sent for its Bitcoin timestamp; every 6 hours confirmations are collected.

When the check fails: what to do

Do not try to "fix" the record so it matches. That would hide the problem; the seal is doing its job by showing it.
Open the notification and the Audit trail entry seal.check_failed. It lists each problem: which donation or seal, and what kind.
Read the kind of problem: "has been changed since it was sealed" means a donation record was altered; "has been altered" or "does not follow" means a seal itself was tampered with; "paid but has no seal" means a seal was missed; "anchor no longer matches" means the chain was rewritten after it was timestamped.
For "paid but has no seal", run donations:seal-missing (or wait for 23:40) and check again with donations:verify.
For anything else, inform the trustee and the programme lead at once, record what you find, and compare against the donors' certificates and the Bitcoin proofs, which cannot be changed.
Keep the database backup from before the problem. Do not delete or restore anything until the trustee agrees.

Commands (for the technical admin)

donations:verify: check the whole chain now, update Last integrity check, and alert on a failure.
donations:seal-missing: seal paid donations and refunds that have no seal yet.
donations:anchor: timestamp the chain head on Bitcoin now.
donations:upgrade-anchors: collect Bitcoin confirmations for pending timestamps.
All four run on the schedule, which needs the server's cron to run php artisan schedule:run every minute. On MySQL the seal lock needs log_bin_trust_function_creators=1 when binary logging is on.

What to say, and what not to say

Say: "Every donation is sealed and timestamped on Bitcoin, so nobody can quietly change it."
Say: "Only a fingerprint goes to Bitcoin. Your name and amount stay private."
Do not say "your donation is on the blockchain". It is not; only a fingerprint is.
Do not say the seal stops mistakes. It makes changes visible; corrections are made openly with a refund.

By role

0 guest

1 contributor

2 admin

3 finance

The donation seal

How it works

Bitcoin timestamps