Hey everyone,
I’ve been thinking a lot about one of the missing links between the crypto and fiat worlds — and I’d like to build something that could help bridge that gap in a private, secure, and open way.
It was initially related to this product that I’m building but I realised it can be much bigger and useful.
The Core Idea
Imagine a canister (or open protocol) that allows crypto dapps to verify that a fiat transaction has occurred, without exposing any personal or sensitive information. That means no usernames, no bank account details, no IBANs in plaintext — just anonymous, verifiable proof that a fiat payment happened.
This would work by publishing hashed, minimal representations of fiat transactions to the canister, for example:
A hashed identifier (e.g., hash of FROM + TO + salt)
Timestamp
Currency
Amount
A unique transaction reference
Then, apps that need to confirm a fiat transfer (say, for releasing crypto funds in a smart contract) would compute the same hash locally using known inputs and check if it exists. If it matches, they can safely proceed.
This would make peer-to-peer crypto-fiat swaps or non-custodial fiat off-ramps possible — without requiring the fintech platform to handle crypto directly. And since canisters can already safely and programmatically handle crypto funds, the only thing missing is a reliable, privacy-preserving signal that a fiat transfer was made.
Why This Could Matter
If even one major fintech company (like Revolut, Monzo, Wise, or N26) integrated this protocol — it could become the go-to fiat bridge for crypto, while preserving user privacy and giving users full control and consent over what gets published.
The blockchain that enables this first would have a serious advantage — it would be the first to bring verifiable fiat transaction settlement on-chain, even if only in an anonymized form.
This could unlock:
Safer P2P crypto-fiat exchanges
Anonymous donation verification
Crypto-native remittance platforms
Use cases we haven’t even thought of yet
How It Might Work (Technical High-Level)
At the core of the protocol is the idea of indexing transactions by anonymized bank account identifiers — not by user identity, and not by name — just per bank account, represented by opaque, irreversible identifiers.
Bank Account Identifier Hashing
Each bank account (e.g., Revolut tag, IBAN, SWIFT+Account, etc.) gets converted into a hashed identifier, which acts as the index key for sending and receiving transactions.
This identifier could be:
A SHA-256 hash of a normalized string such as:
“REVOLUT:@johnsmith” or “IBAN:DE44500105175407324931”
Or optionally, we could explore more advanced one-way encoding schemes (e.g., HMACs, key-stretched hashes like scrypt, or even elliptic curve-based PRFs) to offer additional resistance to dictionary attacks if we believe attackers might guess common tags.
The key is: this hash is irreversible. No personal or bank details are revealed.
What the Canister Stores
Each fiat transaction is recorded on-chain with the following fields:
sender_hash – hashed identifier of the sending bank account
receiver_hash – hashed identifier of the receiving bank account
amount – numeric value of the fiat transaction
currency – currency code (e.g., USD, EUR, GBP)
timestamp – when the transaction was executed
So it might look like:
{
“from”: “hash(SWIFT:BOFAUS3N1234567890)”,
“to”: “hash(REVOLUT:@alice93)”,
“amount”: 150.00,
“currency”: “USD”,
“timestamp”: “2025-04-12T09:33:00Z”
}
No names, no plaintext bank details, no user identifiers.
Accessing the Data
To protect user privacy, transaction data isn’t exposed publicly by default. Instead, the canister could provide methods like:
transaction_exists(from_hash, to_hash, amount, currency, timestamp) → bool
Only if both the sender and receiver hashes are provided can the protocol check for the existence of that transaction.
This design assumes the calling application already knows:
Who the sender and receiver are (e.g., both parties went through KYC on the platform)
The exact bank details of both accounts (to compute the correct hashes)
The transaction parameters
This makes it a great fit for peer-to-peer crypto-fiat apps, where both parties operate within the same dapp or platform, and the platform already has access to bank details in a consented and private way.
By using irreversible hashing, the system remains safe and private — even if the full canister state were somehow exposed, it wouldn’t reveal anything meaningful about the users or their accounts.
Call to Action
I plan to build this as an open-source protocol: a canister, plus lightweight SDKs to integrate it from both crypto dapps and fiat publishers.
But I’d love help from the community:
If this sounds interesting, I’d appreciate your feedback and input.
If anyone would like to collaborate or co-develop, let’s talk!
If you know a better way to convince fintech companies to adopt this other than begging, I’d love your ideas.
Otherwise, yes — I’m happy to go and beg Revolut, Monzo, or whoever is willing to listen. I’ll offer to do the integration on their side for free, if that’s what it takes.
Because if this works — it could be a huge unlock for crypto-fiat interactions, and could even be the foundation for the first truly decentralized off-ramp system.
Let me know what you think — I’m open to any feedback, and I’m serious about building this.