Sagewise Announces Alpha Release of Ethereum Smart Contract SDK To Combat the More than Half a Billion Dollars Lost in Smart Contracts in 2017

Today, we are proud to announce the alpha release of the Sagewise smart contract SDK. Built on the Ethereum blockchain, the SDK is a core component of Sagewise’s toolkit for unforeseen errors and disputes in smart contracts and marks a key milestone in its overall development. Before getting into the details of today’s launch, let me start with a little background on what we hope to accomplish at Sagewise.

Modern day smart contracts started with the launch of Ethereum in 2015 and, in a lot of ways, represented the dawn of fully programmable money. From the outset, one of the biggest concerns of the community was that combining human-created code with instant money transfer could frequently and unexpectedly result in the loss of user funds. Because less than one percent of the earth’s population can program or read code, cryptocurrency-related transactions–including smart contracts do not represent an area where we can reasonably tell a person to “DYOR” (do your own research), as often stated in the cryptocurrency community. Instead, smart contracts represent something very similar to traditional paper contracts in that they cannot be adequately understood or audited by ordinary people. While anyone can attempt to read acontract, if they lack a background in programming or law, respectively, it is highly unlikely they  will be able to catch all the nuances and find all the holes. As an example, someone with no programming background cannot be expected to be aware of all the possible obfuscated bugs that may exist in a smart contract.

Which is where we find ourselves today. More than a half a billion dollars was lost to smart contract coding bugs in 2017. The initial fears and predictions are now reality, and it’s time to figure out how to fix it. Many people are working on this issue through two different approaches:

  1. Making smart contract code better through better coding, tools, and audits
  2. Resolving issues that arise through mediation and dispute resolution

At Sagewise, we are focused on the latter. We are bringing transactional confidence to smart contracts by building infrastructure that acts as a safety net for unforeseen circumstances, whether that be coding errors, security vulnerabilities, changes in circumstances, or disputes. We chose to focus on this because not all issues related to smart contracts can be foreseen–even with the most careful, thoughtful coding. Smart contracts can get bad data from an oracle, or a situation can occur that was never considered. While code is static, human situations are not–we live in a world where volcanoes can halt air travel, strikes can delay commerce, and seemingly unlikely human actions can result in situations no one thought possible. Code cannot be aware of every future possibility. The question is, how do you put a safety net around a smart contract without completely damaging the immutability and decentralization?

Our release today provides a peek at our approach and can be summarized by the following features:

  • All functions in the contract can be frozen;
  • Contracting parties do not have any special control aside from the ability to start a dispute, which freezes execution of the smart contract;
  • Dispute resolution vendors are given complete access to the contract via ‘Administrator Mode’, but this only is available when a dispute has been initiated by one of the contracting parties. This allows contracting parties to fix any issues that may have occurred.

In coming months, we plan to add several more features to the SDK to improve its robustness and usability. Alongside the Sagewise ContractCanary–a smart contract email monitoring and notification system available to licensees– the Sagewise SDK prevents unforeseen execution of a smart contract. Sagewise also  plans to release other support tools as part of its infrastructure that will help bring the entire transactional process together, from documentation of smart contract intent to dispute resolution process handling.

We welcome feedback and engagement by community members, who can sign up for updates at sagewise.io and engage via our Telegram channel at t.me/sagewise.

Our alpha SDK repository can be found here.

How Parity Wallet Failure #2 Demonstrates that Smart Contracts Are Not Invulnerable

As you’ve probably heard, on Nov. 6, Parity encountered yet another failure, and the result? Some $150M-$300M dollars worth of Ether is locked down (there are conflicting reports as to the exact amount), and we’re hearing talk about an Ethereum hard fork, yet again. (How many times can Ethereum hard fork before it’s not a decentralized or immutable?)

As much as we’d like to throw shade on Parity, there’s a bigger picture problem here—Parity is not alone. Parity hack 1, Parity “accidental code deletion” 2, and The DAO hack are all part of a larger systemic issue around smart contracts and code.

An Explainer About This Latest “Accident”

Parity is a smart contract-based Ethereum wallet meant to provide improved security for Ether holders using something called multi-signature. A multi-signature wallet can be explained as a wallet that requires multiple keys turned at once to unlock funds. Parity and multi-signature are considered state of the art for protecting funds, and many high-profile projects use Parity wallet to hold a large amount of Ether.

On July 20th, after the first hack, the Parity multi-signature wallet software was upgraded. The upgrade included some structural changes to the project. Namely, the project was separated into individual contract code that would be published to the blockchain by each user, and a library of functions that would now only need to be published once by Parity. The idea was that since users must spend money to publish their wallet to the blockchain, this shared library would reduce the size of the code that each user needed to publish while their individual code could call into this shared code library that would already be published at a hardcoded address.

Here is where we get to the problem that occurred: A user on github named devops199 discovered that the shared library code was not properly secured because the owner was not yet assigned. Devops199 added themselves as the owner of the contract/shared library code and then directed the blockchain to “kill” the contract. The kill call permanently deleted the shared library from the Ethereum blockchain. This means that all the other multi-signature wallets that reference this shared code library can no longer call into it at all. Without this shared library code, there is no way to transfer funds out of the wallets. Thus, any wallet created with Parity multi-signature wallet after July 20 is currently frozen with all funds sitting visibly inside, but inaccessible.

Smart Contracts Aren’t So Smart

The term “smart contract” might be a misnomer, because oftentimes, they’re not so smart. In fact, smart contracts are full of vulnerabilities. Just as the best lawyers cannot always write perfect, indisputable traditional contracts, developers cannot always write perfect, error and vulnerability-free, disputeless smart contracts. Sure, we can use bug bounties, formal verification, and code audits to get close to perfection, but what happens when even those fail? Parity Wallet Failure 2 is just another one of many smart contract failures as of late, to add to a prominent list of other smart contract failures including The DAO hack, Parity Wallet 1.

Smart contracts have potential for a host of good. (I (Amy) personally think they present a wonderful opportunity to reduce the size of the $12.2B debt collections industry). But to truly maximize the potential of smart contracts, we must first understand their flaws and limitations (and resolve them):

  • smart contracts may contain coding errors (and many developers write code using a fail fast and iterate mentality)
  • smart contracts may contains vulnerabilities easily exploited by hackers
  • smart contracts may not accurately reflect the intent of parties
  • contracting parties may change their mind and wish to amend, modify, or terminate the contract due to misrepresentation, mistake, duress, impossibility, or a change in circumstance
  • external data sources, such as other contracts or oracles may provide incorrect data

Many industry experts, understanding these limitations, have been calling on solutions for a while. We’re experiencing the early days of a nascent industry, much like the early days of the internet. I think we’ll get there, but it’ll take a while.

Meanwhile, until smart contracts allow users confidence in their transactions, the use of smart contracts is more akin to playing roulette—you’re not quite sure what you’ll end up with. The lack of a safety net in smart contacts currently inhibits smart contract adoption, and dampens transactional certainty. Further, the logistical and cultural hurdles of even disputing a smart contract in the current traditional legal ecosystem presents several challenges. Our team at Sagecoin is developing such a solution, which involves a smart contract “freeze button” and a dispute resolution marketplace, all atop a borderless, digital jurisdiction. This solution, alongside several others—including identity verification services, security audit solutions, etc. will help to bring more stability to the smart contract ecosystem.

With regard to Party Failure #2, we believe that our solution could have been employed to stop this issue from occurring using a number of measures that our SDK offers:

1. Time Locked Dispute Resolution points could have been employed around key functions in the shared library such as functions that kill the contract — this would have provided ample notice that the contract was going to be killed before it actually happened and allowed the opportunity to disable the kill call.

2. Immediate Dispute Resolution Points could have been used as checks in the code to send the shared library to dispute as soon as it was clear that the contract had no owner or that someone had become owner that should not have been.

3. Every single wallet contract created with this shared library system could have included its own dispute resolution parameters local to that wallet using the Sagecoin Base SDK. If implemented at the lowest level, this could have been used to dispute individual wallet contracts even if the shared library was deleted. In other words, there may have been a secondary and localized way to unfreeze the funds if the shared code was deleted.

Amy Wan, Esq.CIPP/US, is a Senior Contributor to Crowdfund Insider. Amy is founder and Chief Legal Hacker at Sagecoin, a Bootstrap Legal legaltech blockchain project, and is a consultant with ICOinvestor.tv. She has authored many legal publications, including the upcoming Bloomberg Law ICO offering practice guide. Amy was previously Partner at a law firm that specialized in crowdfunding and syndication law, and was the General Counsel of a real estate crowdfunding platform. She has been named one of ten women to watch in legal technology by the American Bar Association Journal in 2014 and was Finalist for the Corporate Counsel of the Year Award 2015 by LA Business Journal. She is the founder and co-organizer of Legal Hackers LA.

Daniel Rice is a veteran software engineer, leader, speaker, and writer with expertise in blockchain and finance. Daniel’s most recent role was as CTO for Totum Risk which provides portfolio analytics software. Totum was selected for YNext incubator in 2016, which was awarded “top accelerator” honors by Finance Magazine. Daniel has helped launch over 20 products, and as an entrepreneur his personal apps have racked up over 5 million downloads. He has previously consulted on blockchain projects for a blockchain escrow company and blockchain real estate title transfer and records company. In 2014 Daniel founded Bitcoin Developers Los Angeles to focus on building a developer community around blockchain technology. He has also consulted as CTO for several early blockchain startups and published a whitepaper on managing price volatility of cryptocurrencies. Daniel is also the founder and organizer of the Orange County CTO Forum. He holds a BS degree in Computer Engineering from Cal Poly, San Luis Obispo.