In this interview, Maximilian, creator of ODATANO, shares how his background in SAP development and interest in decentralized systems led him to explore how Cardano could fit into the enterprise world. He explains how ODATANO makes Cardano accessible through OData, a standard SAP developers already know, removing much of the blockchain complexity that can make integration difficult. Max also takes us through projects like TRACE and QUANTIX, which puts Cardano to work in areas such as supply chains, procurement, and financial data. Along the way, he shares why he believes Cardano is well suited for enterprise use, what still needs to improve, and what it could take to get blockchain from a developer's laptop into real business systems. Sounds interesting? Well, let's dive right in.

Hello Maximilian, it's great to connect with you. To start, could you please introduce yourself, share your journey from the enterprise SAP world into Cardano, and tell us how you came to build ODATANO?

Hello, thank you for inviting me to this interview. My name is Max, and I’m from Frankfurt, Germany. I’ve been working in the SAP sector for almost 10 years now, across all sorts of areas, particularly in developing interfaces to and from SAP systems, as well as in logistics, sales, and manufacturing and distribution of all kinds of products.

Also, I’ve been interested in highly distributed/decentralized systems and cryptography ever since my university days. And that is why I have always been on the lookout for ways to improve processes in ERP systems, where trust and accuracy play a major role.

When I discovered Cardano some years ago, it eventually dawned on me that it was exactly the kind of foundation where such trust issues between different parties can be resolved on a public settlement layer with the determinism, strength, and robustness that enterprise systems demand, but also open and permissionless in a way an SAP landscape never can be. So I wondered how SAP and Cardano could be connected. The answer became ODATANO.

For community members who may not be familiar with the SAP ecosystem, could you give us a sense of the scale we are talking about? How deeply embedded is SAP in global industry, and why does that matter for a project like ODATANO?

It's hard to estimate, to be honest. SAP's own figure is that around 77% of the world's transaction revenue touches an SAP system, and 98 of the top 100 global brands run on it. So whenever you fill up your car, buy groceries, or pick up a prescription, an SAP system almost certainly handled a procurement order or billing document behind the scenes. So it’s probably one of the most widely used and distributed business software in the world.

For those who are completely new to the concept of OData, could you explain what it is, why it became such a foundational standard inside the enterprise world, and what it actually looks like in practice when a developer uses it?

OData, which is short for Open Data Protocol, is a REST-based protocol, originally from Microsoft and now an OASIS/ISO standard, for building and consuming queryable APIs in a uniform way.

The reason it became foundational in the enterprise, and especially in the SAP world, is that it standardizes the boring-but-critical parts of data extraction and use: how you filter, sort, page, expand related entities, and describe your entire data model through metadata.

In practice, a developer does not hand-write bespoke endpoints. They define entities, and the protocol provides a self-describing service that you query with plain URLs. A consumer can discover the entire model from the $metadata document and automatically generate a typed client.

That uniformity is exactly why it is the right envelope for blockchain data: an SAP developer already knows how to consume it, so ODATANO just makes Cardano look like another OData service he can use in his business logic.

Before ODATANO existed, what would the journey have actually looked like for an SAP developer at, say, a logistics company who wanted to connect their supply chain processes to the Cardano blockchain? What kind of knowledge, time, and resources would that have required?

Honestly, it would have been a multi-month project before a single transaction could ever hit the chain. They would have to learn the UTxO model from scratch, pick and understand a serialization library, work out CBOR transaction building, fee calculation, collateral, min-ADA requirements, and key management, none of which maps to anything in their SAP experience.

Then they would stand up an indexer or sign up for a provider like Blockfrost, write a custom Node or Java service to bridge SAP and that provider, handle retries and failover, and somehow bolt authentication and an audit trail onto it so it survives an enterprise security review.

Realistically, that is a specialist hire or an external agency, weeks of ramp-up, and a bespoke integration that only one developer in the building actually understands. The blockchain knowledge barrier alone filters out the vast majority of enterprise teams.

ODATANO collapses that to npm install @odatano/core @odatano/core and a few lines of config, so the Blockchain integration becomes just a plugin rather than a standalone project.

Cardano's UTxO model is one of its most distinctive technical characteristics, but it can also be one of the more challenging concepts for developers coming from traditional systems. How do you typically explain UTxO to someone with no blockchain background, and why does it create friction for enterprise integration specifically?

That is actually one of my favorite features of Cardano, as it reflects reality much more accurately than a global account model ever could.

Imagine you have a purse containing coins and notes. When you buy something, you always pay with whole units – you can’t spend just part of a coin or a note, only the whole thing. This means you always spend a certain number of your coins to pay for something and receive new coins in return. That’s exactly how it works with the UTXO model: in every transaction, you have inputs that are spent according to certain rules, and outputs that reflect the state after the transaction. And the best bit is that, just like in real life, it only affects your coins – and not some global ledger where all transactions and balances have to be reconciled with one another.

Where it creates friction for the enterprise is that SAP systems are built on the opposite, a kind of account-style model: A record has a balance, you update it in place, and you read the current value. With UTxO and Cardano, there is no current-balance field at all; you derive it by summing unspent outputs. You have to perform coin selection, watch for concurrent output consumption, handle contention when two processes attempt to access the same UTxO, and manage collateral and change.

For a developer who has spent ten years thinking in mutable database rows, that inversion is genuinely disorienting, and it is exactly the part ODATANO abstracts away so the SAP side just sees clean OData entities.

Enterprise companies, especially those operating in regulated industries like pharmaceuticals or financial services, have strict requirements around how cryptographic keys are handled. Could you walk us through what a Hardware Security Module is, why key management is such a critical concern in this space, and how ODATANO was designed to address it?

A Hardware Security Module is a dedicated, tamper-resistant device, sometimes a USB token, sometimes a network appliance, sometimes a cloud service, whose entire job is to generate and hold cryptographic keys and perform signing operations without ever letting the key material leave the device.

You do not read the key out and sign in your application; you send the data to the HSM, and it returns a signature. In regulated industries like pharma and financial services, this is not optional. Auditors and frameworks effectively require that signing keys live in certified hardware with strict access control, because a private key that controls on-chain value is exactly the kind of thing you can never afford to leak. So I designed ODATANO around one principle: the server never handles, stores, or has access to private keys, and all signing is external.

The build service produces an unsigned transaction in CBOR format, along with a body hash. Signing then happens somewhere isolated, a CIP-30 browser wallet, a hardware wallet, the CLI, or an HSM, and only the signed witness comes back.

The server then verifies the signature cryptographically against the expected body hash before it submits anything.

So even if someone fully compromised the application server, there are simply no keys to steal there. And because every step, build, signing request, verification, submission, is written to OData-queryable audit entities, you also get the full evidence trail an enterprise security review wants to see.

So with all of that context in place, what exactly is ODATANO, and what was the core insight that led you to build it as a SAP CAP plugin rather than a standalone API or a custom SDK?

At its core, ODATANO is a SAP CAP service that exposes the Cardano blockchain as a standard OData V4 API, currently 31 entities plus read, transaction-building, and signing actions. You can query blocks, addresses, UTxOs, assets, and protocol parameters, build, sign, and submit transactions, and have it all come back as OData that any SAP tool already knows how to consume.

ODATANO runs perfectly well standalone; it's a complete CAP service with its own endpoint, so the plugin decision was never about capability. It was about distribution. An SDK pushes integration glue onto every consumer. A standalone API means another service to run and secure with its own auth story. Both work, but both add friction right where adoption happens or doesn't.

CAP is the standard framework on SAP BTP, and it ships with a plugin mechanism: drop a plugin in your package, and CAP auto-detects it at startup. So I published the same service as a plugin on npm @odatano/core. A developer just runs “npm install @odatano/core”, adds a few lines of config, and Cardano entities and actions appear inside their existing CAP model, inheriting the authentication, roles, and audit setup they already have.

Same code, two form factors. Run it standalone for an isolated gateway, or embed it as a plugin to get Cardano natively inside a project you've already built.

You built four reference applications on top of the core library: TRACE for pharmaceutical supply chain tracking, QUANTIX for B2B raw material settlement, FINCA for financial data anchoring, and x402 for HTTP payment gating. Could you walk us through one of them in some detail? Which one do you feel best demonstrates what this integration layer makes possible?

Of course, starting with TRACE because it came first. I started building it primarily to learn what a consuming use case app actually needs from the core service: which entities it reaches for, which actions it calls, where the OData model fits, and where it doesn't. So much of the current core design came out of building TRACE against it and fixing what didn't work.

But my first proper proof of concept was Quantix, which I built in just 78 hours during the Charlie3 hackathon. A complete CAP application that enables B2B sales of raw materials on Cardano. So QUANTIX best demonstrates the integration layer by tying oracles, smart contracts, and procurement into a single flow.

ODATANO is used for every blockchain operation running in the background on these Applications, allowing me to really focus much more on the app's actual business logic on which things should happen, rather than the blockchain complexity behind the scenes to make things happen.

QUANTIX won the grand prize at the Charli3 Oracle Hackathon 2026. Can you tell us a bit about what that project does and what it meant for the team to be recognised in that way?

Yes, QUANTIX won the grand prize at the Charli3 Oracle Hackathon 2026.

As I shortly mentioned, it's oracle-gated procurement: a B2B settlement that executes only when a real-world price condition is met, with live Charli3 feeds and a custom Plutus V3 validator handling the on-chain logic.

The recognition meant a lot, mostly because QUANTIX wasn't built as a standalone hackathon entry. It's a reference app on top of ODATANO, so the win was really a validation of the whole approach. That exposing Cardano as native OData lets you build something with real on-chain depth, oracles, custom Plutus validators, concurrency handling, and still have it consumable as a clean enterprise integration.

Being recognized by people who really know Cardano and oracle integration, the Charli3 team, plus other Cardano experts on the judging panel, was a strong signal that the engineering underneath held up fine.

There is a long history in blockchain of enterprise integrations that get announced but never make it into production. In your honest assessment, what would it actually take for ODATANO to move from an open-source library to something running inside a real SAP environment at a real company?

The honest answer is that the open-source library is the easy part. Getting it into production at a real company is a different category of problem, and most blockchain enterprise integrations die in exactly that gap.

For me, this depends mainly on two issues. First, the technical integration, second the real added value from blockchain for specific processes.

One thing I was definitely able to achieve with ODATANO was an improvement on the technical side. ODATANO already runs on BTP, already does XSUAA authentication, already isolates keys and writes an audit trail, so the engineering can drop it into a real landscape that is measured in weeks, not quarters.

The hard part is everything around the code: finding a process where Cardano genuinely beats the boring alternative, an internal sponsor willing to own it, security and compliance sign-off, and a procurement cycle that can outlast the build itself.

What it really takes is one company with a real problem, a compliance mandate, or a multi-party process where nobody fully trusts a shared database, and where selective, verifiable on-chain data is the cheapest, most credible solution.

Regulation is where I see this tipping first, because it removes the "why bother" question entirely. The EU battery passport, for example, under Regulation 2023/1542, is one of the clearest near-term cases, a legally required, tamper-evident record of a product's origin and lifecycle.

Cardano is deeply focused on real-world utility, but enterprise adoption has historically been a slow-moving space. In your view, what are Cardano's genuine strengths when it comes to making a case to enterprise decision-makers, and where does the ecosystem still have work to do?

What's genuinely outstanding is that Cardano's determinism is a real selling point for enterprise decision-makers: the eUTxO model lets you know a transaction's outcome and fee before you submit.

That's exactly the predictability finance and audit functions want, and it's something probabilistic, gas-auction chains struggle to offer. The resilience around the protocol, the formal methods, the peer review, the methodical upgrade process, reads very differently to a risk officer than move-fast-and-break-things does. And the ecosystem's focus on real-world utility means it's at least pointed at the right problems.

But there's still a lot of work to be done. Crypto in general is still too often seen as a speculative instrument rather than a technology, and Cardano is sadly no exception. The hype comes still to often from price swings, not technological progress, if you ask me. That's exactly what makes it hard to bring new solutions to established companies. Given those reservations, they tend to prefer the conventional option over betting on emerging technology. It's especially true when a volatile token has to be held just to pay transaction fees

ODATANO was funded through Catalyst Fund 14. For builders in the community who are considering Catalyst for the first time, what was your experience of working within that framework, and what would you recommend to anyone thinking about going down that path?

My experience with Catalyst was positive, and I would recommend it to everyone to try it when it's back. ODATANO went through Fund 14 as a four-milestone project, and all four were completed and approved, in my case, with zero refusals.

The framework is genuinely good discipline: you commit to milestones up front, you have to show evidence of acceptance for each one, and that structure forces you to actually ship rather than drift. For a solo builder, it is also a rare combination, non-dilutive funding plus a public commitment that keeps you honest.

The advice I would give a first-timer is to scope your milestones smaller and more concretely than feels natural, and to define done in a way you can really prove with an artifact, a release, a test report, a demo, and not a vibe. Reviewers want evidence, so build the evidence trail as you go instead of scrambling it together at the end. And also try to treat the proposal as a contract with your future self: the clarity you put in up front is exactly what saves you when you are deep in the build six months later to complete the project

One number that stands out in your project documentation is 1,285 automated tests with 99% statement coverage, delivered solo in under six months. What drove that level of commitment to quality, and how do you think about the relationship between test coverage and the trust that enterprise clients need to have in a tool like this?

This figure was never intended to be a vanity metric; it came straight out of who the tool is for. If you are asking a pharma or finance company to route any part of a regulated process through your code, trust me, not tested is not an answer they can accept. Tests are how you make quality legible to someone who will never read your source or cannot understand it. And it's also a claim a reviewer can verify in CI without taking my word for anything. There is also a very practical reason for a solo builder. Tests are how one person safely moves fast. Across every refactor of the backends, the transaction builder, and the signing module, I could make sweeping changes and know within seconds whether I had broken a contract elsewhere. This also matters more, not less, given how code is written today. A lot of modern development, mine included, is AI-assisted, and AI-generated code is fast but not automatically correct. It produces something plausible that has to be proven right. The test suite is exactly what turns "plausible" into "verified": every line an AI helps me write has to pass the same contracts as everything else, or it doesn't ship. High coverage is what lets me move at AI speed without inheriting AI's failure mode of confident, untested code. The tests are the ground truth against which the generation is held.

Beyond work, what do you enjoy outside of tech and blockchain? What keeps you grounded?

Away from the screen, the thing that resets me most is getting off-grid. I have a camper van, and a dog, and disappearing somewhere with no SAP system and no block explorer in sight is the best context switch I know. So I think nature in general helps me recharge my battery.

I’ve also been fascinated by running since I was a child. Until now, a 110 km Ultra-Marathon has been my longest run so far, and running has always helped me to keep a clear head and stay focused on whatever I’m doing

If you could go back to the very beginning of the ODATANO journey, knowing what you know now, what is the one piece of advice you would give yourself?

I mainly designed the core first, and when I started building TRACE on top of it, it immediately revealed everything the abstract design had slightly overlooked. Which entities a real process actually reaches for, where the OData model felt natural, and where it fought me. A lot of the early core looked clean in isolation and only revealed its rough edges once something real had to consume it.

If I'd started from an actual use case and let the library grow out of what that use case genuinely needed, I'd have skipped a fair amount of rework.

So the honest version of the advice is: don't design the abstraction in a vacuum. Build the thing that has to use it first, and let the real requirements shape the layer underneath. The use cases often know more than your design instinct does

Thank you so much for the conversation, Maximilian. To wrap up, where can people follow your work, explore ODATANO, or get in touch if they want to build on top of it?

The best place for developers to start is the repo at github.com/ODATANO/ODATANO. It is open source under Apache 2.0, the core is on npm as @odatano/core, and the README will get you running it locally in about five minutes, whether you want it as a CAP plugin or standalone. If you would rather understand its shape first, the docs folder includes guides on the architecture, transaction workflow, and security model.

Also, the homepage on odatano.dev shows some first details and links to the Repos If you have any questions or want to integrate or use ODATANO somehow, just reach out to me on X @maxalexweber or by email at info@odatano.dev.

Thank you for sharing your story. To wrap up, can you tell us a bit about your team? Who’s behind ODATANO, and where can readers follow your progress or get involved?

Thanks to you for the opportunity to share my work & story here. At the moment, it's just me, trying to improve things on the enterprise layer for and with Cardano.

For anything direct, collaboration, questions, or building on top of it, reach me at info@odatano.dev, on x, or on GitHub or LinkedIn.

I am always happy to hear from anyone in the SAP or Cardano world who wants to connect the two or has ideas for improving things.

The second quarter of 2026 picked up right where the previous quarter left off. From major releases and interoperability progress to governance enhancements and developer tooling upgrades, teams across the ecosystem continued to ship at pace. With consistent improvements across infrastructure, analytics, and developer experience, the momentum remains strong. Check out the highlights below to see what’s been delivered.

Reeve​

cardano-foundation/reeve

April:

• Released versions v1.5 and v1.6
• Improved the reconciliation experience with dual-status displays
• Enhanced reporting controls with manual transaction exclusion and template search and filtering
• Optimized batch-statistics performance and improved stability across reconciliation workflows
• Continued developing the Intersect proof of concept

May:

• Enhanced report-template ordering and persistence from the UI
• Improved transaction-sorting consistency
• Improved IPFS parsing support
• Successfully delivered and deployed the Intersect proof of concept

June:

• Released version v1.5.1
• Added Event-First backend endpoints
• Introduced milestone CRUD functionality
• Improved publishing workflows and reporting performance

Cardano IBC Incubator​

cardano-foundation/cardano-ibc-incubator

April:

• Introduced the CIP-67/68 voucher metadata pattern and ICQ-based message exchange
• Advanced the Caribic architecture with a process layer, lifecycle registry, and asynchronous workflows
• Decoupled dApps from the gateway and expanded cross-chain capabilities between Cosmos and Cardano
• Added a CI/CD pipeline and improved deployment metadata and observability

May:

• Submitted pull requests to Injective and Osmosis to integrate the Cardano light client
• Implemented Cardano IBC delay periods
• Added a probabilistic light-client architecture and finality policies
• Deprecated the Mithril-based light client in favor of newer approaches
• Introduced npm package publishing and automated release pipelines
• Added deployment lifecycle management and strengthened bridge deployment
• Continued to improve Caribic, gateway services, relayer integration, and the IBC dApp user experience
• Published security, threat-model, and unsupported-feature documentation
• Expanded test coverage, fuzz testing, and CI quality gates

June:

• Improved probabilistic light-client stability
• Enhanced gateway transaction reliability
• Fixed Injective compatibility issues
• Improved local node setup and build reliability

Cardano Rosetta Java​

cardano-foundation/cardano-rosetta-java

April:

• Released version v2.1.2, including stability and synchronization improvements through a Yaci upgrade and CBOR and block-handling fixes
• Enhanced validation, error handling, and observability across endpoints
• Added liveness and readiness probes and improved Kubernetes and Helm support
• Progressed hard fork readiness by integrating Cardano Node 10.7.1, pending the final Yaci Store releases for the 1.x and 2.x branches
• Continued modernization and maintenance work, including JDK 25 migration, release tooling, quality improvements, and the Python indexer merge
• Began exploring integration with the Yaci Store Asset Store Extension module for the future architecture

May:

• Released version v2.2.0
• Added hard fork readiness for Protocol Version 11
• Continued parallel development across quality improvements, maintenance fixes, and Java-native index application
• Added Kubernetes liveness and readiness support
• Continued modernization efforts, including migration to JDK 25

June:

• Introduced native index application
• Improved Token Registry integration
• Enhanced Blockfrost compatibility
• Strengthened transaction validation and payload handling
• Improved operational resilience and testing

Token Metadata Registry​

cardano-foundation/cardano-token-registry

April:

• Released version v1.5.0, adding Kubernetes support through liveness and readiness probes alongside maintenance improvements
• Released version v1.5.1, adding native image support to reduce RAM usage by approximately threefold and lower operational costs
• Advanced CIP-113 integration, including testing on Preview and Preprod and approval of the REST API, pending the audit
• Introduced the Asset Store Extension approach, moving towards a lightweight registry wrapper

May:

• Released version v1.6.0
• Added hard fork readiness for Protocol Version 11
• Improved deployment reliability through Docker, DNS, and health-check enhancements
• Expanded regression testing and validation coverage for CIP-26 and CIP-68 functionality

CIP-113 Programmable Tokens​

cardano-foundation/cip113

April:

• Advanced the SDK and architecture, including the on-chain and off-chain separation
• Improved minting proofs, composability, and the overall codebase structure
• Continued the auditing process

May:

• Addressed multiple audit findings and protocol-hardening recommendations
• Continued working towards completion of the final audit and related fixes ahead of a broader rollout
• Developed a candidate BaFin/CMTAT-compliant Security Substandard

June:

• Completed the first round of security audits
• Added updatability for substandard scripts

Cardano Connect with Wallet​

cardano-foundation/cardano-connect-with-wallet

May:

• Added a CIP-45 PeerJS implementation, replacing the WebTorrent tracker-based approach
• Added CIP-58 support for mobile connections on the same device, such as connecting from Chrome to the native VESPR wallet
• Improved wallet connectivity across devices and mobile environments

Cardano Client Lib​

bloxbean/cardano-client-lib

April:

• Added CIP-95 support
• Enhanced MPF reliability through RocksDB fixes and property testing
• Improved protocol-parameter handling, including raw cost models, and expanded backend compatibility

May:

• Released version v0.7.2, including quality improvements and maintenance fixes
• Improved protocol-parameter handling and Conway-era compatibility
• Upgraded the build infrastructure to Gradle 8.14

June:

• Added CIP-102 support
• Modernized the Plutus annotation processor for the latest Aiken releases

Yaci DevKit​

bloxbean/yaci-devkit

April:

• Continued improving Yaci Viewer through UI enhancements and usability fixes

May:

• Introduced Yano-backed node modes
• Expanded SDK testing coverage
• Improved Yaci Viewer usability and the block-exploration experience

June:

• Released Yaci DevKit v0.12.0-beta5, with support for Protocol Version 11 and Cardano Node 11.0.1
• Added Yano, a lightweight Cardano DevNet node for fast PV11 network bootstrapping
• Added CIP-30 Wallet SDK support
• Adopted Scalus as the default transaction evaluator, with optional Ogmios support
• Introduced MCP-based DevNet control
• Added packaged examples for easier onboarding
• Improved npm publishing, CI workflows, Docker builds, native wallet signing, and DevNet tooling
• Continued to improve Yaci Viewer and its documentation

Yaci​

bloxbean/yaci

April:

• Fixed CBOR parsing issues affecting large Preview blocks containing more than 23 transactions
• Improved node modularization

May:

• Added hard fork readiness for Protocol Version 11
• Improved Preview governance-query support
• Enhanced DNS reconnection and network failover handling
• Improved multithreaded state visibility and networking reliability

Yaci Store​

bloxbean/yaci-store

April:

• Released version v2.1.0-pre3, introducing Analytics Store with DuckDB and Parquet exports for analytics and MCP
• Enhanced governance rules, including committee checks, voting correctness, and abstain handling
• Advanced the development of Blockfrost-compatible APIs to approximately 95% completion
• Added raw cost-model support
• Resolved critical synchronization and adaptor-consistency issues

May:

• Released Yaci Store v2.0.1
• Added hard fork readiness for Protocol Version 11
• Added Blockfrost-compatible APIs
• Introduced DB Sync comparison tooling
• Added Scalus-backed transaction evaluation
• Improved multi-instance deployment support
• Enhanced epoch nonce calculation

June:

• Released version v3.0.0-beta3, with a strong focus on Analytics Store—powering integrations such as Dune Analytics—expanded Blockfrost compatibility, governance enhancements, and Protocol Version 11 readiness
• Introduced the new Analytics Store module for exporting blockchain data to Parquet files for high-performance analytics
• Expanded Blockfrost-compatible APIs across epochs, addresses, assets, blocks, transactions, accounts, metadata, and scripts
• Improved governance and ledger-state handling for PV11 readiness
• Added epoch nonce calculation support
• Introduced Scalus-backed transaction evaluation
• Added an API for retrieving withdrawable rewards from indexed data
• Exposed raw cost models in protocol parameters
• Added a generic admin CLI command for applying indexes
• Continued to improve native image support, developer tooling, and documentation

ADA Handle Resolver​

cardano-foundation/ada-handle-resolver

June:

• Added Van Rossem hard fork readiness
• Introduced ZPG deployment support

Java Rewards Calculation​

cardano-foundation/java-rewards-calculation

June:

• Released version v1.0.2
• Migrated publishing to the Maven Central Portal
• Improved reward-calculation precision

Thank you to everyone who contributed throughout Q2!​

Your continued work strengthens the Cardano developer ecosystem. Let’s keep building.

In this interview, Raul De Benedittis, CEO and co-founder of Nuvola Digital and Vola Network, shares how his background in aerospace, naval, and medical quality assurance led him to the world of blockchain and decentralized infrastructure. Raul explains how Nuvola is building decentralized storage and compute solutions that prioritize privacy, security, and data ownership, while making the underlying technology invisible to everyday users. He also discusses why the team chose Cardano as their settlement and security layer, how encrypted data is distributed across a global network, and why they believe DePIN can bring meaningful real-world utility to the ecosystem. Curious to learn how Nuvola is approaching decentralized cloud infrastructure and what role Cardano plays in that vision? Let's dive in!.

Hello Raul, it’s great to connect with you. To start, your profile highlights over a decade of experience in quality engineering in the aerospace, medical and naval industries before entering Web3. Could you please introduce yourself and share what specific inefficiency you saw in that "heavy iron" legacy infrastructure that made you realize, "We need to rebuild this on a blockchain"?

My name is Raul De Benedittis, CEO & Cofounder at Nuvola Digital & Vola Network. My background is in engineering in the aerospace, naval, and medical industries, specifically in quality control and assurance. I always dealt with global supply chain logistics and services, which are all interconnected.

The one industry within blockchain that really sat with me over the last few years was Decentralized Physical Infrastructure (DePIN) and Real-World Assets (RWAs). It involves the actual physicality of a business merging with blockchain elements. Coming from a heavy auditing and quality assurance background, I saw immense opportunity because there is so much room for improvement in those legacy systems as a whole. I carry that high standard into everything we do at Nuvola.

On a personal level, what motivates you to keep building in the Cardano ecosystem specifically, and when you step away from the screens and server racks, how do you decompress?

I'm a long-standing member of the Cardano community since 2018. I started as just an investor and worked my way up to a project founder. The growth thus far for Cardano has been an incredible journey to watch, and helping contribute to its success is something I take pride in.

To decompress from the stress of the job, I love the gym. I played football my whole life and have always stuck with fitness, it starts in the mind and the body follows. Outside of that, I’m an avid motorcycle rider, and right now I’m back in my hometown in southern Italy, so spending time on the beaches here is my ultimate decompression routine.

We hear the term "Decentralized Physical Infrastructure" thrown around constantly. Let’s strip away the buzzwords for our readers. If I save a photo to a decentralized cloud versus (a centralized) Google Drive, what physically happens to that data, and why is that architecture safer?

Privacy, encryption, sharding, and file distribution are the main differences in the handling of the file. In a traditional system like Google, you upload it, it is encrypted, but they hold the encryption keys. Your data is essentially only as safe as their centralized servers.

At Nuvola, a photo is encrypted on your device before it is uploaded to Nuvola Drive. That encryption is instantly broken into smaller pieces called shards, and those shards are distributed across our blind node architecture on the Vola Network. Even in the highly unlikely event a hacker cracks a node, all they get is a piece of cipher text. They don't know where the other pieces are, and you can't decrypt a single shard. We don’t hold the keys, they sit on the client's hardware.

There is often a distinction made in the industry between Physical Resource Networks (like wireless coverage) and Digital Resource Networks (like storage). Could you break down that difference for us, and explain where you see the biggest immediate opportunity for disruption?

One is much more physically based. A physical resource network is restricted to a location, you physically have to have something somewhere. We're talking about hardware: grid sensors, servers that run energy grids, generators, things like that. Those are essentially your physical resource networks. They provide power and resources to everything, but they're difficult to scale rapidly because there's a massive physical demand to actually build something, turn it on, and manage it.

Digital resource networks, on the other hand, are essentially the software that runs on top of those physical networks, think storage, compute, and bandwidth. The key difference is that digital resource networks can run through distributed resources globally. Imagine a thousand laptops across the world plugged into the Volola network. That is essentially a digital resource network where those laptops can contribute their unused storage capacity to the network to be utilized.

When it comes to disruption, the difference between the two really lies in the rapid scale at which digital networks can grow. I do want to add a slight nuance to that, though: digital resource networks ultimately depend on physical resource networks, because the physical hardware still has to be present somewhere for the software to run properly. But because of the nature of a distributed model, you no longer need to build centralized data centers with massive server racks. The scaling can happen without some of the heavy physical elements typically required for resource networks. I know that was a lot to take in, but hopefully, that makes sense!

The elephant in the room with decentralized networks is always reliability. "What if the guy/girl running the node in his basement turns off his WiFi?" How does the industry solve this to compete with Amazon's 99.9% uptime, and how does Nuvola's approach to "Robust Node Infrastructure" mentioned on your website address this?

We solve this through sharding, Reed-Solomon erasure coding, shard distribution, and fault tolerencing.

To put it simply, if we use a 4/8 model, a file is broken down and replicated into eight shards. Our system only needs to recover four of those eight components to reconstruct the file perfectly. This means 50% of the nodes holding your data could go offline simultaneously, and we can still recover 100% of the file. For clients needing more redundancy, like the military or pharma, they can pay for additional storage to increase that fault tolerencing up to 80% or 90%.

Your website explicitly states that Nuvola's mission is "Democratizing Decentralized Physical Infrastructure" through a "Crowd-Share model". Could you explain how this model works in practice? How does it allow a non-technical user to participate in the infrastructure economy without needing to buy and manage their own server rack?

This answer actually has two legs to it. We approach it from both sides, starting with the super non-technical side, which is actually the origin story of Nuvola. I started out as the non-technical guy; I didn't know how to run servers or nodes. That's how I met my co-founder, Syed. That’s all he does, he’s a technical mastermind. We essentially brought our two sides together to solve a very real problem in the market.

The first leg is for those non-technical users. If they don't have the capacity, the knowledge, or the resources to run your own servers, they can participate through our NVL token.

The second leg is on the cloud compute network side. The crowdshare model exists there, too, and we are democratizing it through our software. A user can spin up nodes using their own hardware at home, like a laptop; there is no need for a massive server rack. If someone prefers, they could even just rent a server somewhere else without physically buying one, and then seamlessly plug into our network to start providing compute power.

On the Nuvola Digital homepage, you emphasize operating a "Global Server Network" (Global Presence) with servers in Europe, North America, and Asia. Why was it important for Nuvola to own and manage its own hardware rather than just building software on top of AWS, and how does this relate to GDPR compliance?

When we started, we were renting from big data centers, but we quickly realized the dangers of hyperscaler dependency. Between Amazon and Microsoft, there have been major global outages and hacks repeatedly over the last few years.

Europe explicitly wants to break away from these hyperscalers. Having our own infrastructure has been the perfect testing ground to figure out how to scale efficiently and cost-effectively. We even acquired a small ISP in India servicing roughly 15,000 users as a live environment to test our applications directly with households. Ultimately, owning our hardware removes single-point-of-failure reliance on AWS and prepares us for the massive scale and compliance requirements requested by enterprise and government entities.

I’d like to zoom out to your infrastructure choice. In a landscape with high-speed chains like Solana or established giants like Ethereum, why did you specifically choose to build Nuvola on Cardano? Was there a specific technical aspect, such as the eUTxO model or native tokens, that made it the right fit for physical infrastructure?

Cardano's security is simply second to none. I think they still have 100% uptime over eight years, and there have been no hacks. Just the whole model, how it functions, and the way signatures work, it's a safe place. I go on some of these other chains and borderline get a panic attack every time I have to sign something, constantly double-checking to make sure I'm not accidentally giving my permissions away. On Cardano, it just feels safe all around. It's proven, it's battle-tested, and it's tried and true.

With the partner chain model that we've built for our Volan network, we get to tap into that unparalleled Cardano security while still being able to scale on our own chain. We essentially allow ourselves to leverage the robustness, privacy, and security of Cardano, while managing rapid scaling and heavy on-chain data independently without bogging down the main network.

If you're handling tens of thousands to millions of files on a daily or monthly basis, you simply cannot run everything through the main chain. It would be a disaster, uploading a single photo could take 20 minutes. So, by handling the heavy data loads on our chain while pushing subscriptions and financial settlements back to the Cardano chain, we get the perfect combination of security and speed to do everything properly.

Turning that around, how does Nuvola benefit the Cardano ecosystem? We often hear about DeFi or NFTs, but does bringing Decentralized Physical Infrastructure to the chain offer a specific utility, transaction volume, or real-world use case that the network is currently missing?

We bring massive, real-world utility and transaction volume. While Vola Network does the heavy lifting of sharding, downloading, and file reconstruction, the actual financial layer, the paid subscriptions for all these storage services, settles on Cardano. Even at scale, Cardano is going to see millions of transactions flying through us every month purely for payment settlements of a real-world, highly demanded product.

I‘d also like to touch on the "Nuvola Drive" product. In your Medium article "Introducing Vola Network" you mention that Drive will provide a "unified aggregation solution" for Web2 and Web3 storage. What does this mean, and how does this simplify the experience for a typical user? Also, will users be able to seamlessly switch between different storage providers depending on their needs for speed or privacy?

Our approach to that actually evolved through some trial and error. Originally, Nuvola Drive was going to be a multi-store solution where users could choose between different subscriptions from various third-party providers. But we quickly realized that exposed us, and our users, to way too much third-party risk. If a provider had security issues or poor audits, we couldn't absorb that liability.

So, we pivoted to using our own internal Volola network cloud compute and storage model. By acting as the storage provider ourselves, we are 100% in control. If something goes wrong, we can fix it on the spot instead of waiting on a third party's support ticket.

Because of this, our "aggregation" is now more about a seamless migration from Web2 to Web3. Nuvola Drive acts exactly like Google Drive or Dropbox. You would never even realize it's being powered by the blockchain. There are no wallets to set up, no seed phrases, and you don't have to buy tokens on a DEX to activate a subscription. You just log in, pay for your subscription, and it works. All the blockchain magic, the sharding, the distribution, the file reconstruction, happens completely outside of the user's line of sight. We even have tools in place so people can migrate their files directly from Google Drive over to Nuvola Drive.

To answer your question about switching providers: down the road, we do still want to offer an aggregation feature as an additional backup or mirroring layer, like letting you replicate your files onto Filecoin, for example. But we will only bring in third parties once we have extremely strict compliance, audits, and legal contracts in place to manage that risk properly.

In that same article, you introduced Vola as a separate "Partner Chain." For our readers who may not be familiar with the terminology “partner chain”, can you briefly explain what that is ? Also, from a technical perspective, why was it necessary to build a dedicated chain for this? And lastly, what specific role does the Vola Network play in aggregating resources that couldn't be done on the main layer?

Yep. So, for those who don't know, the partner chain model is exactly what it sounds like, it's a partner to a main chain. A lot of Layer 1 blockchains get stressed, bogged down, or slow when too many transactions hit them simultaneously. I'm not the most technically layered guy, but I understand the high-level functionality. Essentially, the problem a partner chain solves is taking specific workloads off the main chain.

Let's use Cardano as an example. We talked about it briefly before: there is massive trust, and it's almost impossible to hack in any way, shape, or form. There has never been an outage, and there has never been a hack; it's impenetrable. But with that level of security comes a trade-off in speed. If too many transactions hit the chain, it slows down immensely. We saw this a lot in the early days with decentralized exchanges (DEXs) and swaps, and it was a nightmare.

The partner chain model takes some of that workload off the main chain while still absorbing its underlying security and core functionality. In the case of the Volola network, it was critical for us to build a cloud compute partner chain because we expect tens of thousands, and eventually millions, of files to be uploaded simultaneously throughout the day.

As we scale, all of those transactions need to be recorded on a chain because they are blockchain-based, this is essentially on-chain proof of storage. Pushing all of that data directly to Cardano would be a disaster; it would take an hour just to upload a photo, which is insane. So, our partner chain takes on the heavy lifting of file transfers, file sharing, and file creation on the side. What it actually pushes back to the main chain is the financial layer, which is where that top-tier security is absolutely essential.

Looking ahead to late 2026 and beyond, how do you envision the user experience evolving? Have we reached a point where the underlying decentralized infrastructure is invisible, and users just enjoy high level of privacy?

The best technology is the technology you don’t even know exists. Think of a combustion engine: you turn a key, and it just works to make your life easier despite its immense internal complexity.

Blockchain has historically been burdened with complexity that scares people off. The whole point of Nuvola Drive is that the decentralized infrastructure is invisible. You upload a file, and in the blink of an eye, it encrypts, shards, distributes, and reconstructs without you ever seeing the backend process. If a solution doesn't make a user's life easier, they won't use it. Simplicity has to be at the forefront.

If you could go back to day one of Nuvola Digital, knowing what you know now, what advice or insight would you give yourself about building physical infrastructure on a blockchain?

If I were to do it all over again, I would prioritize building the Vola Network from the start, rather than trying to rely on aggregating third-party services. Experience showed us the liability of that approach, so we immediately shifted to developing our own backend solution. As a result, I'm confident in saying that we are now positioned to offer the most competitive cloud compute service within the blockchain space.

Thank you for sharing your story. To wrap up, can you tell us who’s behind Nuvola Digital, and where can readers follow your progress or get involved?

• Raul De Benedittis (CEO & Cofounder at Nuvola Digital & Vola Network) - @NuvolaDigital
• Syed Abdul A. (CTO at Nuvola Digital) - @iamSyedLanka
• Website: https://vola.network