ODATANO Interview

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.