We’ve launched QantrumScan: from now on, anyone can verify the blockchain proofs behind BlockBen transactions without exposing a single piece of customer data — or any other sensitive information.
There is a sentence from the blockchain world that I particularly like:
Don't trust. Verify.
The original promise of blockchain was never simply to create another database, or to move arbitrary tokens from one place to another. Its truly valuable property is that the occurrence of an event, the existence of a transaction, or the integrity of a dataset can be proven cryptographically. Something is not true because someone says it is, but because it can be mathematically verified.
Blockchain is the digitalization of trust.
In the financial world, however, this immediately comes with a second requirement: verifiability cannot mean making customer data public.
On a public blockchain, this question does not really arise. You open an explorer, enter a transaction ID, and see which address sent what to which address, how much, and when. In a regulated financial system, however, this is exactly what we do not want. We do not want anyone to be able to see who the customer is, how much their balance is, what they purchased, who they sent an asset to, or which internal accounts and business processes are connected to a particular transaction.
What we do want is for anyone to be able to verify the authenticity of a transaction.
At first, this sounds contradictory. How can you show something without actually showing it?
This is precisely what one of Qantrum’s most important properties is built around. And from now on, this is no longer something only we and a small group of people can verify. You can verify it too. Anyone can, publicly.
QantrumScan is live
QantrumScan is the public blockchain explorer and transaction verification interface for Qantrum and, consequently, for the BlockBen blockchain. It is now live at:
This is an important milestone for us. Qantrum, which powers BlockBen’s services, is a proprietary hybrid blockchain/ledger infrastructure, previously known as Natrix, that we have been building for years. A key layer of this system is now visible and verifiable to everyone.
What can you do with it?
With QantrumScan, you can:
- view Qantrum blocks,
- inspect the data and proofs associated with blocks,
- search for transactions,
- verify that a transaction exists on the blockchain,
- validate the cryptographic proofs associated with it,
and do all of this without exposing sensitive customer financial data.
That last point is the key. We did not want to simply replicate a traditional block explorer. We wanted to build an explorer that works according to the requirements of a regulated financial system.
Try it with your own BlockBen transaction
The easiest way to understand what we are talking about is to try it yourself.
When you open the details of a transaction in the BlockBen mobile app, you will find several technical fields. One of them is the Signed Data Hash. At first glance, it is not particularly user-friendly. You might see something like this:
9657c3f33eeb62a872cdb72f8ee1064d9c11994a368bd90512ed955df24ca41a9c1fcec5e19473619a287cb9f0f5440da476c6f5dee8c7af10be2cd7da5439bc
This is the Signed Data Hash of one of my own transactions. It is 128 hexadecimal characters long, which is not particularly informative to a human. And that is exactly the point, because it is a proof.
The process is simple:
- Open the BlockBen app.
- Select one of your transactions and open its details.
- Copy the Signed Data Hash.
- Open the QantrumScan Verifier.
- Paste it in and press the Verify button.
The verifier checks whether the proof associated with that transaction can be found on the Qantrum blockchain. Or, more simply: you can verify that what the BlockBen app says about your transaction has a corresponding cryptographic proof on the blockchain.
It is not a screenshot, not a PDF, and not the result of a database query. It is not true because we say it is, but because there is a cryptographic proof behind it.
The basics: hash, signature, proof
To understand why QantrumScan matters, it is worth clarifying three concepts in a few paragraphs.
What is a hash?
A hash function takes data of arbitrary size and produces a fixed-format digital fingerprint. Imagine a transaction containing many different pieces of data. The system generates a cryptographic fingerprint from that information. If even a single bit of the original content changes, the fingerprint changes completely. This is what makes hashes so useful for checking data integrity.
There is one important thing to clarify, however: a hash is not the transaction itself. You cannot read the original data back from a hash in the same way you would unpack a ZIP file. This is an important and desirable property.
Imagine a 100-page document from which we create a mathematical fingerprint. Later, someone presents a document and claims that it is exactly the same one. We do not have to compare all 100 pages from memory. We simply generate the fingerprint again, and if it matches the original, we have extremely strong evidence that the data has not changed.
This is one of the fundamental building blocks of blockchain technology.
A digital signature takes it one step further
A hash answers the question of data integrity. In financial systems, however, another question is just as important: who authorized the operation?
This is where the digital signature comes in. A user or system component has a key pair: the private key is used to sign, while the public key allows anyone to verify the signature. The signature proves that the data originated from a specific cryptographic identity and that it has not been modified since it was signed.
The Signed Data Hash is therefore not interesting simply because it is long and looks technical. It matters because it is one element in a cryptographic verification chain, one link, so to speak.
What does it mean for a transaction to be “provable”?
A significant part of traditional financial IT is built around a trust model. The bank or financial service provider’s database says that a transaction happened. The customer accepts that statement. If a dispute arises, database records, log files, audit logs and archived documents are brought forward.
These are all extremely important, and Qantrum does not exist to replace traditional controls. Blockchain, however, adds a new dimension. The question is no longer only “What does the database say?”, but also can we cryptographically prove that this event actually happened in that particular system state?
It may sound like a small distinction, but it is a significant one. During a traditional audit, a system provides evidence about itself. Cryptographic proofs make it possible for another party to mathematically verify certain claims.
This brings us closer to a model where “trust me” is replaced by “verify me.”
Why not simply make the entire blockchain public?
It is a fair question. If we can see everything on Ethereum, why not do the same here?
Because a regulated financial infrastructure operates in a completely different environment. On a fully public blockchain, addresses, amounts and metadata can be analyzed by anyone over the long term. In the context of Ethereum, this is an accepted property. For a financial service provider, however, imagine what would happen if someone managed to link a blockchain address to a specific BlockBen customer. From that point on, their entire transaction history, asset holdings, purchasing patterns and financial relationships with other customers could potentially become analyzable.
That is not an acceptable model for us. The goal is therefore clear: preserve blockchain integrity while avoiding public access to customer data. These are two completely different things.
Transparency ≠ making all data public
“Transparency” is one of the most misunderstood concepts in the blockchain industry. Transparency does not mean that everyone gets to see everything. In a financial system, that would actually be a bad thing.
Good transparency means: what needs to be verified should be verifiable, but the person performing the verification should not need access to information they have no reason to see. This is essentially the cryptographic equivalent of the need-to-know principle.
If someone only needs to know whether a transaction exists, why should we show them the customer’s name, account information, balance or entire transaction history? We should not. If the claim is that “this transaction existed in this state and was included in the blockchain,” then that is exactly the claim that should be proven. Nothing more, nothing less.
Different participants need to see different things
A good financial infrastructure does not provide everyone with the same view. The customer needs to see their own transaction. The compliance system needs to see significantly more data. The auditor needs different information, and the back office needs something else again. A public explorer user, however, may only need to know one thing: does the proof exist?
This is role-based information sharing. And one of the most exciting properties of cryptography is that this does not have to be solved solely through permission tables: in certain cases, the information available to a verifying party can be mathematically limited.
This leads us to Zero-Knowledge thinking.
Zero-Knowledge: proving without revealing
What is a Zero-Knowledge Proof?
The name may sound like science fiction at first, but the basic idea is beautifully simple. A Zero-Knowledge Proof is a cryptographic construction in which the proving party convinces the verifying party that a statement is true without revealing any additional information beyond the fact that the statement is true.
The three classic properties are:
- Completeness: if the statement is true and the parties act correctly, the proof succeeds.
- Soundness: a false statement cannot be accepted as valid except with negligible probability.
- Zero-Knowledge: the verifier learns nothing beyond the truth of the statement.
The mathematics behind this is, of course, considerably more complex. But the intuition is what matters.
A simple example
Imagine a closed room with two doors. Inside the room, a wall separates the two doors, and there is a secret passage through that wall. I claim that I have the key that opens the passage connecting the two doors. You do not want to take the key from me, you do not want to copy it, and you do not want to know how it works. You simply want to determine: do I actually have the key?
I enter through one of the doors. From outside, you randomly tell me which door I should exit through. If I do not have the key, I can only complete the challenge successfully half of the time. If we repeat the process many times and I successfully exit through the correct door every time, you gain increasing confidence that I really possess the secret, while I never reveal the secret itself.
Modern Zero-Knowledge systems do not work with doors. They rely on sophisticated mathematics, elliptic curves, commitment schemes and different proof systems. But the idea is the same: prove without revealing the secret data used to produce the proof.
Why does this matter in a financial system?
Because a significant part of finance is ultimately about verifying claims. Does a transaction exist? Was it authorized? Is it recorded in the ledger? Has the data changed? Does it meet a specific condition? Is someone authorized to perform an operation?
Most of these questions can be answered without handing over all the underlying data. I believe part of the future of financial infrastructure will be about exactly this: transferring as little data as possible while making as many claims as possible verifiable. That may sound paradoxical at first, but from a data protection perspective, it is one of the most interesting directions in the field.
Where blockchain meets GDPR
For a long time, discussions about blockchain and GDPR made it sound as though two fundamentally incompatible worlds were colliding. Blockchain’s core property is immutability, while GDPR requires data minimization, purpose limitation, appropriate data security and limited retention.
That makes one question particularly important: what actually goes onto the blockchain?
One possible architectural answer is to ensure that personal data does not go directly onto the ledger. Personal data remains in appropriately protected systems, while the blockchain contains a cryptographic proof that can later be used to verify integrity or a specific claim.
This is precisely the philosophy we follow with Qantrum. The goal is not to turn the blockchain into a gigantic public database, but to provide a proof and integrity layer underneath the financial system.
Data minimisation: don't give away what isn't needed
Data minimization is one of the core principles of GDPR. From a technology perspective, I like it because it says the same thing a good system architect would say: if a component does not need a piece of data, don't give it that data.
Not everything needs to know everything. Not every system needs access to a customer’s complete profile. And, most importantly, a public verifier does not need to know the business content of a transaction in order to verify certain cryptographic properties of that transaction.
Privacy by design: don't add it afterwards
Another technologically interesting GDPR principle is data protection by design and by default: privacy safeguards should be built into the system during the design stage, not added later.
This is particularly important for blockchain systems. If we build an architecture where all personal and financial data is stored immutably and publicly on-chain, it will be very difficult to say later: “Now let's make it GDPR-compliant.”
The right decisions need to be made from the beginning:
- What should be on-chain, and what should be off-chain?
- What should be encrypted, and what should be hashed?
- Who should be able to see what?
- Which claims need to be provable?
- And which data should never need to be shown to the verifier?
These are not frontend questions. They are architectural questions.
A hash is not a magic GDPR solution
Let's clarify a common technical misconception. You often hear: “We don't store personal data, only its hash, so GDPR doesn't apply.” That is not necessarily true.
Pseudonymization and anonymization are not the same thing. If data can still be linked to a specific natural person using additional information, it may still qualify as personal data in pseudonymized form.
In a serious system, it is therefore not enough to say that “hash = GDPR solved”. The entire architecture needs to be considered: what did we hash, which algorithm did we use, how predictable is the original dataset, is a dictionary attack possible, do we use a cryptographic salt, what other data sources could be used to correlate the information, and who possesses the linking information?
This is real security engineering. And this is precisely why Qantrum is so interesting to us: we did not want to put a buzzword on top of a database, but to build a system whose data protection model follows from the architecture itself.
And what about banking secrecy?
BlockBen is a crypto-asset service provider under MiCA, not a traditional commercial bank, so from a legal and technical perspective, the term “banking secrecy” is not accurate for every type of customer data. The everyday principle, however, remains the same: a regulated financial service provider’s customer financial data should not become public simply because the underlying infrastructure uses blockchain technology.
In fact, I believe this is exactly where blockchain technology needs to mature. Financial blockchains cannot simply be public networks operating under the principle that “everything is public because it is blockchain”. The system needs to provide integrity, auditability, confidentiality and verifiability at the same time. That is a much harder problem, and technologically, a much more interesting one.
Why QantrumScan is more than an explorer
At first glance, QantrumScan is naturally a blockchain explorer: blocks, identifiers, hashes, proofs and technical data. But its more important meaning is not that.
QantrumScan is a window into BlockBen’s proof layer. We are saying: you do not need access to our internal database, you do not need to trust a screenshot, you do not need to know our customers’ personal information, and you do not need to see the confidential content of a transaction — but you can verify certain things.
That is the difference between transparency and uncontrolled data disclosure.
Explorer or verifier?
A traditional public blockchain explorer is primarily a reading interface: it shows you the contents of the ledger. A regulated, privacy-oriented financial blockchain explorer, in our view, should instead be a verification interface. Its purpose is not to reveal every secret, but to make the necessary proof verifiable.
Explorer: “I show you the data.”
Verifier: “I prove the claim.”
We believe the second direction is more interesting.
What happens in the background when you verify?
From the user's perspective, the process is deliberately simple: you open the app, copy the Signed Data Hash, paste it into the Verifier, and check the result. A lot more happens in the background, but the user does not need to be a cryptographer.
This is a general principle of technology: complexity should be the system’s problem, not the customer’s. Zero-Knowledge cryptography can be mathematically extremely complex. The user experience can still be:
Copy → Paste → Verify.
This is why Qantrum is hybrid
“Hybrid blockchain” sometimes appears as a marketing term. For us, it has a very specific reason.
Fully public blockchains have incredible properties. Permissioned systems have their own strengths as well. Financial infrastructure needs something from both worlds. We need cryptographic integrity, immutable transaction chains, proofs and auditability. At the same time, we need data protection, access management, compliance controls, financial confidentiality, regulatory cooperation and controlled infrastructure.
That is why we did not believe the answer was simply “put everything on a public chain”. But neither did we believe that the only thing worth keeping from blockchain technology was the word “blockchain” in a database name. We wanted to preserve the technological value at every level.
Blockchain and audit: proof instead of disclosure
The world of auditing has traditionally revolved around documents, reports, database extracts and controls. A cryptographic ledger introduces a new tool.
Imagine a future audit process where the answer to certain questions is not an Excel file, but: proof valid or proof invalid.
Of course, this does not replace the professional work of an auditor. It does not tell you whether a transaction was commercially correct, whether it complied with every applicable law, or whether someone made a good decision. But it can provide a very strong answer to a question such as: does the data under review appear unchanged and verifiably present in the appropriate system state?
The audit of the future may ask for proofs instead of data.
This is partly speculative, but technologically it is one of the directions I find most exciting.
The traditional audit process has a significant challenge: huge amounts of data often have to be moved in order to verify a relatively small number of specific claims. We create exports, transfer files, grant access and generate test data. The auditor gets access to a large amount of information in order to verify a few specific statements.
What if we reversed that process in certain cases? The auditor would not receive the entire dataset. Instead, they would define the claim that needs to be verified, and the system would provide the proof. Proof instead of disclosure. This will not work for every problem, but where it does, it could create an entirely new security model.
Less data can sometimes mean more security
There is a very simple information security principle: what you don't give away is harder to steal.
Even the most sophisticated access-control system can experience a configuration error, permission error, credential leak, insider incident or application vulnerability. That is why access control matters. But there is an even stronger approach: if a component does not need the information, don't give it the information in the first place.
The Zero-Knowledge approach takes this idea one step further through cryptography. Don't only regulate who can read the data. Ask whether the data needs to be transferred at all in order to prove the claim. If it does not, don't transfer it.
Public verification. Private information.
If I had to summarize what we want to achieve with QantrumScan in a single sentence, it would be this: public verification, private information.
The two are not opposites. One of the most important tasks of modern cryptography is precisely to make it possible to achieve both at the same time. GDPR does not say that verifiable systems cannot be built. Blockchain does not say that all personal data must become public. It is the job of good system design to bring the two together.
Why does this matter to the average BlockBen customer?
Most of our customers will probably never read a paper about Zero-Knowledge protocols. And they don't need to. They may only click on QantrumScan once. But that does not make its existence any less important.
Think of an airplane. Most passengers never look at the redundant avionics systems operating behind the cockpit. But they still want those systems to be there.
Technological trust in a financial system works in a similar way. The goal is not to turn every customer into a cryptographer. The goal is to ensure that anyone who wants to verify something can do so.
Why now?
Over the past period, we have spent a great deal of time working on parts of BlockBen's infrastructure that are not particularly visible from the outside. Not new buttons, not new animations, not developments whose complexity can be understood from a screenshot. These are the things that fundamentally determine what kind of financial infrastructure we are building.
QantrumScan is the first externally visible result of this work. We do not simply want to say that BlockBen services use blockchain technology. We want that technology to have a tangible and verifiable consequence for the customer as well.
Blockchain is not blockchain because we put the word on a website. The value of blockchain emerges when the technology provides a new form of assurance. In the case of QantrumScan, that assurance is: verifiability.
For years, we have talked about BlockBen's proprietary blockchain infrastructure as more than a simple token network — as an auditable, secure, privacy-oriented and cryptographically verifiable financial ledger. QantrumScan now provides a direct view into one important layer of that system.
We are not making confidential data public. We are making the proof accessible.
Try it
If you are a BlockBen user, open the app, find a transaction, open its details, locate the Signed Data Hash field, copy it, and paste it into the QantrumScan Verifier:
If you are simply curious and want to try it quickly, you can use one of my own transactions:
9657c3f33eeb62a872cdb72f8ee1064d9c11994a368bd90512ed955df24ca41a9c1fcec5e19473619a287cb9f0f5440da476c6f5dee8c7af10be2cd7da5439bc
Paste it in. Press Verify. And see for yourself.
Don't trust us
Trust has always been one of the foundations of financial services. I believe the next era will go further than that. Trust should not be eliminated, but strengthened with evidence. Digitalized trust.
A regulated financial service provider will, of course, continue to be responsible for its operations. Regulation, supervision, compliance, audits, information security, processes and human accountability will all remain necessary.
Cryptography does not replace these things. But it adds something that we previously had only limited ability to provide: independent technical verifiability.
That is why I like this sentence so much:
Don't trust. Verify.
QantrumScan is live. Public verification. Private information.
