We need to fundamentally change how smart contracts operate

Smart contracts should be viewed as “proof-of-concept” rather than as critical for universal adoption. That may mean exploring alternatives.

Smart contracts have reshaped the possibilities of what blockchain and crypto can achieve, and we can all acknowledge that. That doesn’t mean they’re the be-all-end-all solution to widespread adoption.

Being overzealous about any kind of innovation can also contribute to its stalling, or even failure if other factors don’t align. The mentality of assuming new technology is perfect and wondering why everyone hasn’t caught up to its genius is outdated. Not only does it create an adversarial relationship when inevitabilities, such as regulation, arise, but it also diminishes the motivation to improve on new applications to maximize their value.

Smart contracts and companies building their products around their implementation are now nearing this impasse. So, what can be done to close these gaps and potentially set the stage for an alternative?

The gaps

Mainstream smart contract adoption is already kneecapped by a lack of Bitcoin (BTC) support. Sure, the Ethereum network has become an industry heavyweight that hosts many of the world’s blockchain applications, but Bitcoin is still seen as being in a league of its own by practically every metric. And as BlackRock, the top dog of traditional institutions, looks to break the Securities and Exchange Commission’s Bitcoin exchange-traded fund (ETF) glass ceiling, that glaring gap will only become more apparent as others follow suit.

We can’t ignore ETF filings or recent developments in Bitcoin-driven finance, so saying smart contract aversion stalls Bitcoin’s interoperable potential or decentralized app integration is short-sighted.

The other elephant in the room is fiat. Hundreds of projects are working to make cross-ecosystem compatibility a reality, but there is no streamlined way to connect crypto and fiat through a smart contract framework.

Yes, you can introduce centralized intermediaries to foster fiat-to-crypto exchanges, but that opaque, trust-maximized, expensive solution defeats crypto’s intended purpose altogether. And that’s before touching on the security issues that inherently follow their implementation.

Smart contracts may be (and usually are) controlled by the team that develops them. The inspiring, deceptively logical mottos of “verify, don’t trust” and “code is the law” are great in theory, but no one really reads the code before executing a smart contract.

Creating an implicit trust assumption is where hackers commonly emerge and exploit loopholes, code vulnerabilities and improper key management to crack smart contracts and steal funds.

Regulators are already well aware of smart contract vulnerabilities. Part of the reason why the European Union’s Data Act garnered such divisive reactions stemmed from its “kill switch” mandate for any company using smart contracts. While the mandate may seem harsh, it illustrates an inherent technological risk that regulators aren’t likely to ignore as more international blockchain regulation moves forward.

Necessary changes

If companies and institutions actually want an alternative to smart contracts, making that a reality requires a few major steps. Or, if an alternative seems out of reach at this point, smart contracts need severe alterations to seal up attack vectors when it comes to holding funds.

Again, smart contracts are great to enrich an application layer and amplify generic functionality, but they’re not necessarily needed or well-suited to hold funds indefinitely. This is why beloved comparisons likening smart contracts to vending machines fall a bit flat.

To the average person, using a smart contract could make it seem like the equivalent of a stranger watching over you every time you access an ATM. And just because you might trust a smart contract doesn’t mean you can necessarily trust the team that made it. In this case, it’s imperative to code smart contracts correctly to maximize security, with some developers even proposing new smart contract languages or implementing a “fact check” software into the code.

“Right to be forgotten” data privacy regulations, such as those in the European Union’s General Data Protection Regulation, also complicate things. In countries where citizens have the legal right to demand their personal data be erased, that can’t exactly happen if they’re bound to a digital legal agreement.

Getting smart contracts to cooperate with traditional financial institutions and fiat requires fundamentally altering how they operate. But since that kind of seismic change is impractical and completely unnecessary to consider at this stage, institutional onboarding requires urgently mitigating the security and privacy risks.

Smart contracts have many practical uses, but they may need to be viewed as a “proof-of-concept” rather than the key to universal adoption. Crypto’s future requires a consistent dialogue with traditional finance in terms of fiat interoperability and ease of access. This can only happen by prioritizing that kind of development and addressing the obstacles preventing it from happening. If that involves steering away from complete reliance on smart contracts and exploring other options or primitives, so be it.

Eitan Katz is the CEO and co-founder of Kima. Prior to Kima, he served in leadership roles with the Israel Defense Forces (Intelligence/8200) and at Hewlett Packard and BMC. He helped to build HP’s Global Innovation and Incubation program, leading HPE’s Enterprise Mobile platform. He was also a founding member of the MPC-based Bitcoin wallet Aegis.

The opinions expressed are the author’s alone and do not necessarily reflect the views of Cointelegraph. This article is for general information purposes and is not intended to be and should not be taken as legal or investment advice.