DIN Logo

Cloud Crypto Land: A Response

Post by Topper Bowers

A recent Zk Capital newsletter links to a paper by Edmund-Philipp Schuster .

Edmund and I had quite a pleasant back and forth discussing this over email. I thought I’d make some of my thoughts here public as there tends to be a sentiment in the crypto space that real-world assets don’t work on DLT systems. You might have heard of this as “the oracle problem.” I couldn’t disagree more.

First: something I agree with! I agree that most of the improvements we see from blockchain tech in the non-currency applications are from, as the paper states: “the large-scale and coordinated redesign of existing market and IT infrastructure, and the ensuing improvements in interoperability.” In fact, I think that’s the *purpose* of blockchain tech.

In the end DLT is a trust machine.

It allows for a trustable digital record of “who said what when.” Using that primitive you can build up all sorts of interesting applications in currency, real-world, and digital interaction. Trust is a new building block that is really difficult to attain in existing IT structures. DLT makes trust easier and that’s DLT’s super power. Everything else stems from this simple function: “who said what when” (even currency).

Overall I think my critique of the paper boils down to a few things:

1) It takes an idealized view of Special Purpose Vehicles (SPVs)

2) It takes an idealized view of database tech

3) It fails to take into consideration the increasing interconnectedness of all things (to quote Douglas Adams).

Let me start with one anecdote. There is a bond-issuer here in Germany that is using Ethereum to custody their bonds.The BAFIN has approved. After their talk I asked them: “What’s better about your solution than say a spreadsheet?” The answer was: “for users, not much.”


before the Ethereum approval, bond custody had to happen in Clearstream. Clearstream costs about €600k per €10M issuance. Ethereum costs a few hundred Euro. Clearstream is an example of the SPV/Database combination you describe as “just as good” in your paper. In the real world, these monopolies end up being non-ideal for a variety of reasons, cost being one.

Now let me move to one of my favorite quotes in this space, from Jagrut Kosti of Porsche Digital Labs:

“If you can get everyone into the same room to discuss technology, you don’t need a blockchain.” 

Taken one way, this seems to support the paper, but if looked at differently it shows the power of DLT. What Jagrut is summing up in that quote is that supply “chains” are so drastically different today then they were, even 10 years ago. Supply systems no longer resemble chains, but are instead supply clouds. Even large manufacturers like Porsche are no longer in the center of their supply chains. Porsche might not even be a top 100 purchaser of some of their critical materials, but they are still responsible from a legal and efficiency standpoint to track and understand the origins of all of their parts and partners. It used to be that one or two large players could dictate to the supply chain what software and integration systems to use, that process is immensely more complicated now days. DLT allows for eventual standardization without agreement. It allows trust to build gradually and network effects to move companies towards better interoperability. 

DLT allows ecosystems to slowly build rather than requiring command-and-control structures to be decided up front. The requirement for up front planning is one of the big reasons we don’t have digital integration today and one of the key things that DLT is enabling. 

Trust is a necessary element in so many applications it’s mind boggling and, today, we’re forced to keep re-inventing the wheel. Take for example a ride-hailing application. Clearly the platform needs a lot of digital trust. Some quick examples: “is this driver in two places at once, or just the one place?” “Is this driver certified?” “Can this rider pay for the ride?” There’s a lot more there, but trying to illustrate the point. Right now the best way the platform can provide that trust is to have all of its digital requests go through its own systems. That costs a lot: Lyft spends over $100mm/yr at Amazon Web Services. That trust really has nothing to do with its core competency of providing a marketplace and making sure rides are enjoyable and not dangerous. If it could externalize the trust provider, it could save millions per year by allowing transactions to happen off of its own network. 

In the paper’s model, the ride-hailing company would have to get together with many other software providers, determine a centralized database for “who said what when” and then they would all pay their dues and use this externalized trust. Or, they do what they do now and don’t interoperate and provide the trust themselves at enormous expense. 

In some ways, many companies are going through a process of choosing an external provider and interoperating: they are choosing DLT as the provider.  DLT has no contracts, no monthly fees, and you can explore it at a project level and then expand. DLT (especially Tupelo) scales with your business and there is little counter-party risk because, at worst, you can keep running the network yourself.

Let me use one more example: a supply chain from a small supplier to a large retailer. In a system proposed in paper I guess there would already be some central party offering a system of truth for “supply chains” and the smaller player would just plug in? In practice that’s really difficult and leads to the current fragmentation we see today. So in actual practice, the large retailer probably has their own SAP integration and the smaller supplier is left choosing to integrate with SAP or to go with some other smaller SaaS based provider with significant counter-party risk. If there was some global record of truth, they could all easily plug into that record with minimal integration costs, no contracts, no search costs, etc.

In general, I think I agree with the notion presented that most of these corporate systems would be better run by some ideal trustworthy central party with super great cybersecurity practices and razor thin profits. The question becomes: who can provide those services? The sheer number of data breaches every year shows: no one.

In the legal areas, the paper proposes a government run database, but in our increasingly global systems: which government?

In certain business consortiums maybe creating an SPV and database could make sense, but, increasingly, silohed businesses (or even industries) don’t really exist. Then the “group of semi-trusted actors” becomes an increasingly large number of players. If you were to design a trusted digital system around that paradigm, it would look a lot like: a DLT platform.

And, I think this is the crux of my thinking… taking isolated examples can lead you to think: “maybe a database is better” but when you zoom out and see the macro problems with actual implementation, DLT starts to look like an excellent combination of both technical and political maneuvering that actually allows businesses to interact.

DLT is a trust machine.

The legal system sometimes acts as a trust machine and can sometimes revert real-world state. It’s just slow and a system of last resort. That doesn’t mean the legal system can’t interact with the objects on a DLT (it doesn’t have to actually manipulate them, but rather simply give its opinion). The applications that can (and will) be built on a trust machine are enormous, DLT is about redefining what it means for businesses and individuals to interact. 

Tupelo is purpose-built for these kinds of applications. Go explore our docs and get building the future!