Language Matters: Thank You for Calling them Smart Contracts, Vitalik

Smart contracts are small, independent applications running on blockchains, like Ethereum, that support them.  The term “smart contract” came from Nick Szabo’s papers, including Smart Contracts: Building Blocks for Digital Markets. For example:

The basic idea of smart contracts is that many kinds of contractual clauses (such as liens, bonding, delineation of property rights, etc.) can be embedded in the hardware and software we deal with, in such a way as to make breach of contract expensive (if desired, sometimes prohibitively so) for the breacher. . . . A broad statement of the key idea of smart contracts, then, is to say that contracts should be embedded in the world.

Ethereum and Smart Contracts

Later, when Ethereum was created, Vitalik Buterin adopted Szabo’s term, smart contracts, to describe the code running on the Ethereum Virtual Machine (“EVM”).  As Ethereum and blockchain has grown, however, the term has has created confusion from non-technical commentators who assume there is a legal or contractual element to them.

Perhaps because of the swirl that followed, Vitalik very recently mentioned he regrets using the term:


Vitalik would have used a more technical, “boring” term, like “persistent scripts.”

Language Matters

Who can know for sure, but I suspect if Vitalik actually used the term “persistent scripts” instead of smart contracts I’m pretty sure it wouldn’t have captured the broad-based attention beyond the computer science industry, especially from the legal academy, as it has.

For example, when I first heard about smart contract back in about 2014 or ’15, they were described to me as something that would completely replace the need for lawyers and courts.

Today I have lawyers who approach me and ask, “What are these smart contract things?” Had they been named differently, I’m pretty sure they wouldn’t approach me in the first place, let alone ask, “What are these persistent script things?”

Now I have lawyers who come up to me and say, “What are these smart contract things?” Pretty sure they wouldn’t say, “What are these persistent script things?”

And for me, the skills and need for legal engineering is strongly expressed in the blockchain industry, and I believe it’s largely because of Szabo and Buterin’s word choice.

So I’m glad you did it, Vitalik. Thank you!

Had a Great Time at the UCI Blockathon – What I Learned from the Front and the Back of the Room

UCI Blockathon Picture 1
This is Sid and the leadership team. UC Irvine October 2018

I was lucky enough to have an opportunity to present Solidity programming to about 150 people at the University of California, Irvine Blockchain association (UCI Blockchain), mostly to computer science students. Thought I’d share a few notes about what I heard and what I saw.

Fortunately for me, I was on after USC Professor Bhaskar Krishnamachari who presented a comprehensive overview of blockchain in a way that resonates with computer science students and, key for me, in a way that I couldn’t do!

What I Learned From the Front of the Room

UCI Blockathon Picture 2
UC Irvine October 2018 (That’s not actually me at the front of the room in this picture.)

When it was my turn, I walked them through a step by step build up of a Solidity smart contract locally using Truffle and Ganache. Then we deployed the contract on Rinkeby and had about eight of the students interact with it using MetaMast. It was very close to what I did at Desert Code Camp a few weeks ago.

During my session, a few issues came up that you might find interesting if you’re out there evangelizing on smart contract development. First, I probably started too fast and glossed over what a smart contract is in the first instance. It’s a key concept, and it takes a minute and a few iterations to soak in—even for a bunch of super smart students.

Second, you might need to spend a little more time on the protocol itself. When I showed them how to interact with the contract using Pragma or through Truffle, they missed some of the fundamentals so there were quite a few questions about who would interact with the contract under what terms, which is basic protocol stuff.

What I Learned from the Back of the Room

UCI Blockathon Picture 4
UCI Blockathon – UC Irvine October 2018

While there was a heavy emphasis on learning and training at the UCI Blockathon, some of the students stayed and hacked all night. (I’m at an age now where, if I tried that, I’d be paying for it all the way to Wednesday.)

Since I wasn’t mentoring them all night, I was ok with judging the teams. I’m glad I did because I was blown away with what they created overnight (after three very long training sessions).

First, I noticed that five of the seven teams chose to develop on Ethereum using almost exactly the tech stack and workflow I showed them, which I’ll take as a win.

Next, I noticed a few teams struggled to articulate whether their project was appropriate for blockchain. For example, one team sought to build a supply chain project. Supply chain is a great use case for blockchain, but may not be necessary where a simple B2B transactional system would suffice.

Three of the teams nailed the use case almost perfectly, however. The winner created a complete, end to end Dapp for transferring rights in artists works. The next up has a great use case to put academic records on chain. The third was a using blockchain to track real world payments to charities for transparency.

Finally, the leadership team at UCI Blockchain was fantastic. If they keep operating at high levels like that, I’m expecting great things out of their careers!

Thanks for having me!

UCI Blockathon Picture 3
UC Irvine October 2018

StandardToken.sol deleted? How to move to OpenZeppelin 2.0 for your ERC-20 token

Today I was playing around with some ERC-20 stuff and, because things are moving really fast in the blockchain, smart contract, and Ethereum space, I hit some serious speed bumps.

Ether as a cryptocurrency and digital asset is one key aspect of the Ethereum world computer, but a lot of the most interesting things are happening through tokens, whether it’s ICOs, STOs, utility tokens, or some of the fascinating economic engineering going on behind them.

Tokens follow the ERC-20 standard, which is pretty simple (if you keep it that way).  And, for the most part, new developers are likely to lean on the OpenZepplin library.  There are many blogs, Medium posts, StackOveflow questions, and more giving you code snippets to use based on early versions of OpenZepplin.

It’s so easy.  You’re probably going to do something like:

npm i openzeppelin-solidity

The problem is you’re going to download the new OpenZepplin library (version 2.0) and basically nothing you read will help you anymore.  Let me try.

Forget about StandardToken.sol or manipulating the tokenSupply or any of that.  Just create a new token with the following:


That’s going to start a new token contract with a supply of 100000000000 and transfer all of them, initially, to whoever created the contract.

That should get you going.  Good luck out there legal engineers!


Everything the Internet Knows About Legal Engineering – A Bibliography So Far

There isn’t much written about legal engineering yet. The following is what the internet has said so far with my thoughts sprinkled into it.

They say it started with Richard Susskind’s use of the term “legal knowledge engineer” in 2010’s The End of Lawyers, which I was careful not to read considering I had just graduated from law school! Amazon

Monax says that legal engineering is a “combination of legal design and software engineering.” Part of the role is focused on automating rights and obligations into smart contracts and other automated systems. “Drafting the rules of commercial interactions is traditionally the job of a lawyer. In a data-driven ecosystem, it’s the job of legal engineers.” (Emphasis added.)

I particularly like that last line, and I really only have two critiques of the write up. First, I feel like “legal design” may not be very actionable for those wanting to enter the field. And second, it seems to me that legal engineers are needed in more than commercial settings.

Wavelength defines a legal engineer as “a person that sits at the interface of technology, law and data, and who is trained and skilled in the construction of designed legal solutions.” Drew Winlaw later argues there are many different types of legal engineers but if you have a combination of legal training, empathy, impatience with the status quo, bravery to experiment, imagination about technology’s application, and pragmatism then you may have the skills you need to be a legal engineer.

Stuart Barr, following Susskind’s lead, focuses on the legal engineer role within law firms (I tend to focus on the role in any software engineering environment). He says that a legal engineer could come from either a legal or tech background but a legal engineer must “have a deep understanding of both technology and legal practice and an appetite to drive innovation, efficiency, process improvement and client engagement.”

Perhaps most impactful, he hammers on the idea that “technology itself is not the differentiator. It’s about how you apply it. That’s why legal engineers are so important. They have the creativity to come up with technological solutions to very specific problems, and this is where the competitive advantage comes in.” (Emphasis added – emphatically.)

Jake Goldenfein and Andrea Leiter focus the legal engineer role on the evolving field of blockchain engineering and smart contract programming. They draw an interesting relationship between from modern day automated smart contracts to medieval writ system. They seemingly suggest and the legal engineer might be one who translates the facts of a dispute or contract into the correct form of writ, or smart contract. It’s interesting, but I don’t think it’s actually workable in practice.

The IAPP has a number of unique perspectives given that privacy lawyers and privacy engineers also work at the intersection of law and technology. Here is one such article.

I probably missed something. Let me know!

“Want to solve the problems computer science is creating in the world?”

I advocate that the industry should consider including the legal engineering role in some development teams. A recent tweet crossed my feed earlier this week reminding me why.

Then the first reply gets to my rationale behind the new legal engineer role (somewhat orthogonally):

Let me explain.

Computer science is agnostic about the subject matter. Whether you’re building a game, a social network, a supply chain management system, a self driving car, or a new token-based economy, computer science helps us design it correctly and efficiently.

But as the products of computer scientists reached massive global adoption over the past decade, we’ve witnessed all kinds of problems popping up… societal, political, ethics, legal, racism, and much more. As software has entered most of our daily lives, every human problem has has also manifested itself in the products built by computer scientists. These are problems they don’t teach solutions for in core computer science curriculum.

Thus my strong belief, based on years of experience with dozens and dozens of teams, is that a software engineering team needs a diversity of skills and considerations; and the legal engineer may be a critically important one for some teams.

The Legal Engineer’s Core Teamwork Skills

On Monday I was writing about my trip to Oregon. I didn’t mention much about what happened on the ground (can’t) but I can summarize by saying their problems aren’t technical — they’re just a dysfunctional team.

Software, especially software engineering as a discipline, is not a solo endeavor. To be truly successful in today’s market, your product team is going to have to be just that — a team, ideally with diverse experiences and viewpoints.

Now it’s Friday. Since Oregon, I’ve been involved in at least three or four different teams in different organizations. Some are dynamic and high performing, some are slow and methodical, and some are just straight up toxic. Even got into a verbal fight in one such toxic environment just yesterday.

A Lawyer’s Transition to Team Player

It got me thinking about lawyers who want to make the jump to the legal engineer role and be a member of technical teams. It might be a hard transition to navigate.

For context, maybe I should level set with my own experiences. I came to law after about ten years of writing code in small and large companies. Never did actually work for a firm full-time after law school, but I did clerk pert-time for four different law firms while in school and then worked full-time for a federal judge for almost two years.

I admired many of the professionals working in those firms and learned a lot from them. However, the political and organizational skills demonstrated by the lawyers in those environments was very, very different from the skills I see in small, successful software engineering teams.

A Legal Engineer’s Core Teamwork Skills

In this post, I want to highlight a handful of the skills I think are critical for legal engineers, targeted primarily at lawyers making the transition.

Creating Safety

One of the first things a new legal engineer may notice is that they’re deeply embedded with a group of other people, sometimes shoulder to shoulder, day after day. There are rarely doors to close where software is being developed.

In these teams of software engineers, product managers, UX designers, and etc., there’s little status within the team, which may be a hard switch for someone coming from a high status profession like law. Here you’re going to be just one of the team, roughly equal to everyone else, except that you may feel intimidated if you’re just coming up to speed on the technology side.

Thus you may find yourself trying to assert your status or value to the team through any number of behaviors. You might be tempted to get defensive, be quick to correct other team members, project an air of superiority, be overly guarded, or, worse of all, become critical of other team members, the project, or the company. Oh sorry, I didn’t mean you, but maybe you know someone from the legal profession who might act like that from time to time when feeling out of place.

Your team is only going to be successful if everyone on the team feels safe to offer ideas, to take risks, and to try things without worrying whether they’ll be called out. “There’s no team without trust,” leads a popular HBR article on the topic of team safety.

Protecting team safety is everyone’s responsibility, not just management’s. That’s because anyone on the team can damage safety within the team. Any “provocation by a boss, competitive coworker, or dismissive subordinate” gets interpreted by our lizard brains as a fight or flight moment,destroying our ability to bring our creativity to the team.

So, as a new entrant to the software industry in this valuable new role, I beg you please, make preserving team safety your first objective.

And if you find yourself in a team where safety is low, lead from the front and be a safe team member.

Openness, Transparency, Vulnerability

If you’re on a safe team, then everyone, including you as a new legal engineer, is free to be open, transparent, and vulnerable.

Unfortunately, these aren’t traits highly prized in the legal profession. Indeed, if you’re a litigator they may actually work against your effectiveness.

Put another way, just because you’re free to begin to embrace these traits, which we all have if we choose to use them, doesn’t mean you’re going to open right up.

So take baby steps.

And know there’s a big reward waiting for you if you can work in a safe team where everyone is open, transparent, and vulnerable. It would feel almost like family, wouldn’t it? And most importantly, the team wouldn’t have to waste much time on office politics and could focus on creativity and getting awesome stuff done.

Baby steps.

Resilience to Try, Fail, Learn, and Start Again

The legal profession is famously risk averse — for a reason. Lawyers have to get it right the first time when they’re drafting a major corporate merger agreement, someone’s last will and testament, or filing a points and authorities memo with the court. When litigators make arguments in court, they don’t get many chances to change course or walk back a mistake.

In today’s highly agile software industry, we approach it exactly the other way around. We don’t try to get it right from the beginning.

In the software industry we take a lot of chances. We try things. They fail. We learn what worked and what didn’t. We try again, and probably fail again. But we keep iterating until we get it right.

You’ll shed a lot of anxiety, and it’s a lot of fun when you embrace it.

Where are the lawyers?

I’m at an undisclosed airport in the Pacific Northwest as I write this. Was working with an organization that deals with lots and lots of money in a highly, highly regulated way.

We’re thinking through how to modernize their core, legacy software to be more responsive to stakeholders’ and regulators’ shifting demands.

When this monolithic app was being designed, nobody was mashing the word legal and engineer together. It’s a shame they weren’t because there’s a whole lot of law and regulation embedded in this codebase, and it would’ve been nice to have a lawyer who understands software design and architecture show up from time to time while it was being built.

Most of this legacy system’s design was left to the accountants, or, more catastrophically, poorly trained and lightly experienced “business analysts” who struggled to understand the legal and policy implications of what they were doing, let alone the technology.

I strongly believe that some of their confusion led to poor software design choices that have been layered on over the decades.

Accountants Were the Early Movers in the Professional Services / Tech Space

I was in college at Arizona State back in the mid 1990s, when my client’s software was being written. I was in the “accounting information systems” department, which was endowed by Andersen Consulting (remember them?).

Many of my professors were former Andersen consultants (some sporting AC tattoos). They knew the future of accounting wasn’t in managing double entry ledgers or even being CPAs but in managing accounting software and systems — so they helped drive this new degree program called AIS at Arizona State.

Aside from the dot-com boom, there were two accounting slash regulatory upheavals driving a huge amount of software professional services in the late 1990s and early 2000s: the Y2K issue and, 200s post-dotcom crash, SOX 404. The first was clearly an accounting glitch — nobody expected those old accounting systems to run past the year 2000. The second was a reaction to, ironically, Arthur Andersen, Andersen Consulting, and Enron.

The accountants ran away with the professional services market.

So Where Are the Lawyers?

It’s interesting, isn’t it, that accountants are free not only to advise on regulatory requirements but also be the business and technology consultancy for implementing those requirements. They freely advise on both technology and regulatory requirements (whether it’s self imposed, like FASB; regulatory, like SEC regs; or even statutory, like the Sarbanes Oxley Act § 404).

But where are the lawyers? In all the corporate meeting rooms (really, my natural habitat), only once did I see lawyers present and dealing with fairly low level technical issues with technologists — and the lawyers looked pretty ill at ease.

Maybe it’s historical. Maybe, because accountants and auditors have traditionally been deeply embedded in the day to day systems within organizations, they had a unique spot on the playing field.

Maybe it’s the nature of their work; lawyers aren’t, as a whole, known for their math and accounting skills (ask celeb lawyer Michael Avenatti).

Maybe it’s the fact that auditors are requires to dive into the low level systems of corporations

Whatever it is, the Big Four and their associated consulting firms have captured a huge share of enterprise tech and business advisory consulting, to the tune of hundreds of billions of dollars a year. Just ask Deloitte or Accenture or IBM Global Services.

But, having gone through a years of SOX 404 work and legacy codebases like what I saw in the Pacific Northwest today, I know the accountants and their management consulting practices don’t always get it right when interpreting statutory and regulatory provisions. But they show up. They’re there in the dingy meeting room deep in Corporate America and they’re speaking with some authority. When they talk people listen.

Just like accountants made a strategic choice to get deep in the weeds with technology to expand their trade, lawyers should too.