The challenge
In a conventional financial system, the operator’s database is the only account of what happened. If a record is questioned, the answer comes from the same party whose behaviour is in question. Most of the time that is fine, because regulation and audit provide the check.
This product needed something stronger: a transaction history a user could verify without trusting the operator at all, and without the operator being able to revise the past quietly.
That is a narrow requirement, and it is worth being precise about what it does and does not mean. It does not mean the platform runs on a blockchain. It means each transaction is anchored to one, so that any later claim about what a record contained can be checked against evidence that the operator cannot alter after the fact.
Approach
The chain holds proof, not data. Personal and financial details stay in the platform database. What goes on-chain is a cryptographic commitment to the transaction, which is enough to prove that a given record existed in a given state at a given time.
This split matters for two reasons. Putting personal data on an immutable public ledger is irreconcilable with the right to erasure under GDPR, so it is not an option for a product with European users. It is also unnecessary: a hash proves integrity without disclosing content.
Anchoring is asynchronous, verification is not. A user transaction cannot wait on chain confirmation, which is measured in a timescale entirely unrelated to what a payment interface can tolerate. Transactions commit to the platform database immediately and are anchored shortly afterwards, with the transaction carrying a clear state: recorded, anchoring, or anchored.
Being explicit about that state in the interface is more honest than hiding it, and it avoids the failure mode where a user believes something is settled that is still pending.
Anchoring is idempotent and batched. Chain writes fail, time out, and occasionally succeed without the confirmation arriving. Every anchoring operation is keyed so that a retry cannot produce a second commitment for the same transaction, and batching keeps the cost proportionate to volume rather than to individual transactions.
Verification is a feature, not an export. The proof is only useful if someone can actually check it, so verification is built into the product rather than left as a technical possibility. A user can take a transaction and confirm independently that the record matches what was committed, without relying on the platform to perform the check.
The ledger remains authoritative for balances. The blockchain is an integrity layer, not the accounting system. Balances are derived from a double-entry ledger in the platform database, with the same append-only discipline and audit trail any financial system needs. The chain proves that ledger has not been rewritten. It does not replace it.
Results
The platform serves 75,000 users at around 1,000 transactions per day, with every transaction independently verifiable against its on-chain commitment.
The volume is worth reading correctly. At 1,000 transactions a day this is not a throughput problem, and treating it as one would have produced the wrong architecture. The engineering difficulty sits in correctness and in the integration boundary: making anchoring reliable despite an external system that fails in unfamiliar ways, keeping personal data off an immutable ledger while still proving integrity, and presenting verification in a form a non-technical user can actually use.