TBW - Christopher Grilhault des Fontaines (Dfns): "In times of war, a data center is an irresistible target"

Starting July 1, European players without a MiCA licence will no longer be able to operate. Dfns registered as a DASP with France's AMF for the custody component back in 2023. Was that a defensive bet?

Absolutely. We see ourselves as a technology provider, not a financial services firm. That distinction is nothing new. In traditional finance, there has always been a coexistence between companies that build technology and those that deliver regulated financial services.

The debate was raised in the French parliament around the Ledger case: if holding cryptographic keys makes you a custodian, then AWS or Google become financial custodians. That is absurd. The AMF had issued a memo in June 2021 with a rather business-friendly position that was quite unique globally at the time: you could interact remotely with a key via API and still be deemed a custodian, provided certain conditions were met.

As a precaution, we created a subsidiary registered as a DASP solely for custody. The logic was simple: if the regulator changed its mind, we could migrate our clients there. But we never had to use it.

You are not pursuing a full licence though?

No. We do not want to send mixed signals or compete with our own clients. Picture this: you are in the lobby of a bank to sign a technology contract and you bump into your client pitching the same regulated service right next door. That does not work. We remain a pure-play technology provider.

"The number-one risk factor is protecting users from themselves"

Your approach to custody is very different from the rest of the market. How do you explain that?

You need to distinguish two things. Custody in the legal sense — recourse, contracts, the ability to sue — is fundamentally a matter of law. Then there is technical custody: the physical control of keys. That second dimension is where our passion lies. We entered the market with a simple observation: according to Chainalysis, roughly 20% of all bitcoins have been lost because people misplaced their private keys. Clarisse Hagège, my co-CEO, who has been a banker for ten years, and I, coming from consumer apps, had the same reaction: the number-one risk factor is the user themselves.

We came in with a fully unapologetic stance, going against the "not your keys, not your coins" mantra. We chose MPC — multi-party computation — with a 3-of-5 scheme: five key shares distributed across two AWS data centers in Frankfurt and Paris.

And crucially, unlike virtually all of our competitors, we do not place any private key fragment on users' phones. Users receive authentication keys. If they lose their phone, recovery is always possible. This model is not designed for people who want to become pariahs of the financial system. It is designed for people who live in society and want their assets protected.

How has the offering evolved since then?

It has become far more modular, driven by pressure from banks. Initially, everything ran in our AWS infrastructure under a 3-of-5 scheme. Then banks told us: "We have our own engineers, our own standards, our own regulations — adapt."

First step: we enabled the distribution of key shares within the client's own environment — their AWS account, Azure, whatever — with mixed threshold schemes.

Second step: some banks use HSMs and have no interest in MPC. So we made it possible for them to plug in their own HSM. The signature is generated inside their device, injected into a transaction that we build and broadcast to the blockchain. The key never passes through our perimeter.

Third step, driven by IBM, with whom we now work closely: full on-premise deployment. A client can install and run all services on its own machines, in its own environment. This summer, our entire application layer — policies, permissions, broadcasting — will be deployable entirely at the client's site. We have moved from a monolithic product to a composable, cloud-agnostic architecture. Regulations have shifted, been refined, and reversed course so many times that we were forced to stay flexible.

"Dfns versus Fireblocks is increasingly HubSpot versus Salesforce"

Banks are all moving into digital assets, but they tend to want end-to-end control over their custody infrastructure. How do you fit into that?

We offer them a clear choice: buy our technology, take it in-house with the licence, the source code, all the way to a code escrow in case we go under. They leapfrog five years overnight. But the same question always comes up: how to integrate this new platform with legacy systems. And even when our technology is the right fit, many prefer to handle the bridge internally.

I think three profiles will emerge. Banks that buy everything turnkey. Banks that buy a foundation and build on top. And banks like Citi, with their CIDAP platform (Citi Integrated Digital Assets Platform), who have been building almost everything in-house for two years and will only take minor components. Our strategy is to win over the undecided middle. And to wait patiently for those who built everything internally to realise, five or ten years from now, that they have lost speed.

>> Benchmark: digital asset adoption by French banks

The comparison with Fireblocks is inevitable. How do you differentiate?

It is increasingly HubSpot versus Salesforce. Three major structural differences persist. First, we started as an API; they started as a UI. You feel it everywhere in the product. We have 150 APIs they do not have, but they have a more complete interface than ours. If you are a CFO moving funds with a mouse, Fireblocks will be more comfortable. If you are a developer who wants to automate everything, you will find more tools with us.

Second, thanks to IBM, we can deploy the entire platform on-premise. Fireblocks operates largely as SaaS: the keys can go on-prem, but the rest of the application logic cannot. Yet some regulators require exactly that. Third, pricing. It is not so much that we are cheaper — we can be very expensive if we want to — but our logic is different. We do not want an infrastructure provider making money before its client's application does. That makes no sense. We would rather our clients take off first. We have time, we are patient.

The European banking consortium Qivalis chose Fireblocks for its euro stablecoin. How do you read that decision?

You need to separate two things. Qivalis as a company chose Fireblocks to store and issue its stablecoin, and the founding banks of the consortium — ING, Danske Bank and a few others — were brought into that setup. But many banks that joined the consortium subsequently use other solutions, and that is perfectly accepted. This is not a club where you must use Fireblocks to get in.

Our reading is that the initial choice is primarily short-term and crypto-native: distribute a euro stablecoin quickly on existing DeFi rails, as a liquidity instrument for traders looking to reduce their dollar exposure. For that purpose, Fireblocks is a practical choice. But that should not be confused with a medium- to long-term banking infrastructure decision.

What is telling, incidentally, is that this announcement was mostly amplified by Fireblocks. That is not insignificant. In banking RFPs, where the real decisions are made, they are losing ground to providers better suited to the integration, governance and control requirements of large institutions.

Does the question of a US licence arise, to be more competitive in that market? Your competitor BitGo, for example, won the Robinhood contract partly for that reason…

Some people on our team push us to consider it. There is business to be done with a banking licence. But every time we follow that reasoning through — compliance, hiring, internal culture shift — the conclusion is usually the same: that is not what we do. There is room in this market, as long as you stay true to what you are. We are here to build highways. That takes time, and you have to settle into that mindset.

"No blockchain has proven it can operate at Visa scale"

Dfns has become a Canton validator. How do you view this network?

Canton is interesting because its architecture of private chains with a public coordinator — the Global Synchronizer, managed by the Linux Foundation — offers a credible answer to the privacy problem. You can conduct private activity and settle publicly whenever you choose. The best of both worlds. Today, the challenge is getting enough counterparties that already trade with each other in the real world to set up private chains on Canton. The public chain is still underused.

But I would note that since Canton gained traction, there has been a major privacy wave across the industry: Hedera Hashgraph, Solana relaunching confidential balances, Zama on Ethereum, and so on. Canton is dominating that narrative right now. Its CEO Yuval Rooz is one of the smartest people I know in this industry.

That said, we remain agnostic: Polygon and Ethereum are still the most used chains by our clients, but we are watching everything.

>> Simon Letort (Digital Asset): "Ethereum is years ahead on retail, Canton on institutional"

>> Canton Network: analysis of the blockchain designed for institutions

More broadly, has any blockchain proven it can operate at institutional scale?

No. We ran tests with Visa on Solana, which is presented as one of the fastest blockchains. When you strip out validator vote signatures — which account for roughly 2,000 of Solana's 3,000 transactions per second — you are left with about a thousand actual financial transactions. From Visa's perspective, that is nowhere near enough.

We are in 2026 and no blockchain has truly proven itself capable of running in production, at scale, with the constraints of a Visa, an IBM or an Oracle. The sheer volume of corporate prerequisites — policies, certifications, audits — is enormous. That is why there is still so much excitement around projects that promise progress. And that is why we stay agnostic.

"In the UAE, after recent bombings, we got clients back on their feet within a day"

You have said recently that data centers become targets in wartime, as we have seen in the Middle East. That is an unusual statement from an infrastructure provider…

I have been saying it internally for a long time, just not publicly. A data center in wartime is an irresistible target. Look at AWS availability zones in the UAE: one in Abu Dhabi, one in Dubai. They are an hour's drive apart. If one zone is hit, the cascade risk is real.

Why does MPC offer an advantage in that specific context?

Thanks to threshold cryptography, you can refresh a private key without changing the public key. If you have five key shares distributed across Bahrain, Abu Dhabi and a third site, and two of them are compromised, you can regenerate the shares elsewhere. A traditional HSM cannot do that — the key is generated as a unique object inside a physical device. Backups exist, but they are heavier, less agile.

In the UAE recently, after bombings, we were able to get clients back on their feet within a day, relocated elsewhere. Those using HSMs were not restored as quickly. That is a fact. But saving the key is not enough. The platform itself needs to be able to run somewhere else.

We are developing an active-active architecture: our code runs simultaneously in multiple environments, and if one goes down, the other takes over. The ideal setup is multi-cloud — Google with Azure, Azure with AWS, and so on. It is complex, but essential in turbulent times.

Do you advise clients to move away from Middle Eastern data centers?

It is not that straightforward. Local regulators often require infrastructure to be on national soil, seizable by local authorities. In many countries, there is no AWS or Google — there are certified private data centers. What we have done with IBM is make every component of our platform agnostic: open-source code that is compatible with any environment, including IBM Cloud.

In Europe, there is DORA. In the United States, there is FISMA, which dates back to 2002. The underlying trend is the same everywhere: every component deemed critical must have a Plan B, and ideally a Plan C. That is heavy, painstaking work. We are not perfect at it. Our competitors are even less so.

"We are about to publish the fourth paper worldwide on post-quantum threshold signatures"

Google made waves by suggesting quantum computing may arrive sooner than expected. Is post-quantum already an operational concern for you?

We are working with École Polytechnique on a post-quantum threshold signature paper — post-quantum TSS. It will be the fourth paper worldwide on the subject. We are planning a first implementation this year. We started before Google even published its own paper. We take this very seriously. And blockchains must do the same: prepare for migration, every single one of them. If they do not move fast enough, new blockchains will emerge to replace them.

>> Charles Guillemet (Ledger): "Trust in cryptography is eroding — blockchains need to migrate now"

Does AI pose a threat to the security of your infrastructure?

Of course. But we fight with AI too. We have been using Almanax for a year and a half to scan open-source code, dependencies and vulnerabilities. AI is both the threat and the weapon of defence. As for formal verification, which is sometimes presented as the ultimate solution, the real limitation is well known: everything depends on the quality of your initial assumptions. If your assumptions are wrong, all your calculations are too. It is just like physics. But we will get there. And beyond security, AI is going to transform the way we produce and test code. We are going to ship at an unprecedented pace. Our security team is a bit more nervous — they want guardrails everywhere. That is a genuine balancing act.

Any final message?

I am calling on regulators to invite technology providers to the table directly, not just through their financial clients. Today, each bank presents its infrastructure provider — us, Fireblocks, Taurus — in its own way to the regulator. There is significant information loss. There is a level of technical detail that our clients do not master as well as we do. When I hear that certain American companies claim they have the ear of France's AMF, while we, a European player, do not have that direct access… something needs fixing. Regulators would be more effective if they heard directly from the engineers who build these systems.

‍