Highlights

Smart contracts aren’t “persons” under the UCC, but can own assets and execute transactions.

UCC transactions contemplate interactions between UCC-defined “persons,” and parties transacting with smart contracts face challenges identifying the UCC “persons” involved.

DeFi protocols could consider deploying mechanisms with their smart contracts such as springing collateral agents to alleviate such challenges.

A smart contract isn’t a “person” in the everyday sense. That seems pretty clear.

You can’t shake a smart contract’s hand. You can’t look one in the eye and gauge its mood. You can’t buy one a cup of coffee and share a joke.

So then, what is a smart contract? Well, Gavin Wood (one of the founders of Ethereum) and Andreas Antonopoulos define Ethereum smart contracts as:

“immutable computer programs that run deterministically in the context of an Ethereum Virtual Machine as part of the Ethereum network protocol.”

A bit of a mouthful, maybe, but the takeaway is that a smart contract is made of computer code. We think of an ordinary person as being made of...well, something else. Or at least, of more than just lines of code.

Yet, like an ordinary person, a smart contract can send, receive and hold assets. Further, a smart contract can engage in transactions.

If you think that these asset-owning and transaction-making attributes of “non-person” smart contracts might pique the mind of a UCC nerd, you’d be right—because the UCC is replete with references to “persons.”

But if smart contracts are not “persons” in the everyday sense, are they “persons” in the UCC sense? And, how should the answer to that question affect the way we should think about engaging with smart contracts in UCC transactions?

These are the questions I’ll look at in this post. In Part 1, I will look at some background concepts and one hypothetical situation. In Part 2, I will look at a second hypothetical, and consider some ramifications.

 *                                 *                                  *

To start with, let’s look at how the UCC defines a “person.” That definition focuses on entities:

“Person” means an individual, corporation, business trust, statutory trust, estate, trust, partnership, limited liability company, association, joint venture, government, governmental subdivision, agency, or instrumentality, any other legal or commercial entity, or any series of any of the foregoing.

While the 2022 Amendments to the UCC do modify the definition of “person”, those revisions don’t change the key concept that a “person” must be an entity of some sort—whether an individual (a squishy organic creature like you or me) or a juridical person (an artificial being created, and imbued with personhood, by law).

Smart contracts aren’t entities like that. They are computer programs. Their scripts can be complex, and can have intricate logic and functionality. But since they’re still just lines of computer code, they’re not entities in any meaningful sense. And therefore they just don’t fit into the UCC definition of “person”.

Nor, interestingly enough, can we look through the computer code to any “owner” of a smart contract so as to find a “person” who somehow embodies the smart contract.

The externally-owned accounts (“EOAs”) that an off-chain individual or entity might create on Ethereum-style blockchains have private keys, which the off-chain individual or entity uses to control the EOA. A smart contract’s blockchain account, however, does not have private keys and isn’t controlled by any off-chain keyholder. The smart contract account looks only to control by the logic of its code.

Indeed, once deployed, an immutable smart contract can’t even be controlled by its own creator. There is no one who stands as an owner of a smart contract. As Antonopoulos and Wood put it, “... we can say that smart contract accounts own themselves.”

That’s kind of a breathtaking statement.

Taken at face value, these characteristics make it hard to know just what a smart contract actually is. Should we regard a smart contract like a natural monument or piece of public infrastructure—a mountain, say, or a Roman aqueduct? An object that stands serenely, waiting for a an external function call to put it into play?

(In a similar vein, a federal court recently wrestled with whether an immutable smart contract is “property” for OFAC purposes, and it concluded nope—not property either.)

A smart contract may be a thing of some kind, but it’s not a “person” in either the everyday sense or the UCC sense. It’s just there.

This would all just be an entertaining philosophical conundrum if the UCC didn’t speak in terms of “persons” all over the place. The concept of a “person” is implicated in the UCC in myriad ways: for characterizing assets, for ordering transactions, for defining duties, rights and remedies, and more—probably too many ways to count. (In fact, while researching this I had the bright idea of going through the UCC, and collecting all the places where the term “person” is used as well as all the other terms defined to incorporate the term “person.” Took me about five minutes to drop the idea.)

So for purposes of this post, let’s focus on just two situations: lending transactions secured by digital assets (covered in this Part 1), and security entitlements for digital assets with securities intermediaries (to be covered in Part 2). Although I’m sure other questions of UCC “personhood” will come up in future posts.

Digital Asset Secured Lending.

So let’s start with a simple situation. A lender (let’s say a bank) makes a peer-to-peer loan to a borrower (let’s say an LLC), and the borrower pledges digital assets as collateral for the loan. Secured lending brings Article 9 of the UCC into play—the familiar dance of attachment and perfection of security interests.

The basic rules for attachment of security interests are three-fold. A security interest attaches when it becomes enforceable against a debtor (our borrower), and enforceability requires:

(1) that value be given,

(2) that the debtor has rights in the collateral or the power to transfer rights in the collateral to a secured party, and

(3) that the debtor has signed a security agreement describing the collateral—or another of the listed substitutes for a security agreement is present. Notably for our digital assets situation one of those substitutes is, for controllable electronic records (“CERs”), controllable accounts, controllable payment intangibles and electronic money, the secured party having control of those digital assets pursuant to the debtor’s security agreement.

Let’s further assume that the digital asset collateral in our hypothetical consists of crypto tokens that would constitute CERs under Article 12, and that the secured party (our lender) has obtained control of the CERs under the new rules of UCC § 12-105. That control (assuming that the borrower’s agreed to create the security interest) would suffice both for the attachment of the lender’s security interest and its perfection.

So far, so simple—at least, if both sides of the loan transaction are UCC “persons.” The “person” requirement here lurks in the UCC definitions of “debtor” and “secured party.” A “debtor” under the UCC is defined (in relevant part) as:

“a person having an interest, other than a security interest or other lien, in the collateral, whether or not the person is an obligor...”,

and a “secured party” is likewise defined (in relevant part) as:

“a person in whose favor a security interest is created or provided for under a security agreement, whether or not any obligation to be secured is outstanding...”

Since we assumed that both our debtor and our secured party are entities (the lender a bank and the borrower an LLC), they should both be UCC “persons” that can fit into these definitions and the follow-on UCC provisions—even if they are transacting with each other via blockchain accounts.

But what if at one end of the lending transaction there is a smart contract, instead of an entity or individual?

Consider, for example, if our borrower transacted with a generic DeFi peer-to-pool lending pool instead of with a bank. In that case, the borrower would typically supply tokens of one kind to the pool as collateral by locking them into the protocol, and then would borrow the loan in a different kind of tokens from the lending pool against its supplied collateral.

However, the lending pool protocol is comprised of smart contracts (and let’s say that the smart contracts are immutable—that is, they cannot be modified once deployed). Those smart contracts would embed the logic that locks the collateral tokens into the pool, monitors the loan-to-value of the borrower’s loan and liquidates the collateral if the loan-to-value drops below an established threshold. In making the loan transaction, the borrower’s EOA would have interfaced with the blockchain contract account of the lending pool’s smart contracts.

But as we’ve seen, a “secured party” under the UCC must be a “person,” and our lending pool smart contracts don’t qualify—they don’t add up to a “person” in themselves. If that’s true, though, then where is our secured party? Who holds the secured party’s rights under Part 6 of Article 9 to dispose of collateral after default and apply the proceeds to its claim? And who does the borrower sue if it believes that the disposition of collateral was commercially unreasonable, or that the proceeds of liquidation were not properly credited to its loan?

If the only things on the scene are the smart contracts, then is there a secured party at all? (If there isn’t, our transaction would seem to have big UCC problems.)

However, there are typically other parties involved in DeFi lending pools. There might be oracles that transmit pricing and other data to the pool, there might be liquidators which liquidate collateral upon default. There is likely to be a DAO that provides governance. Most importantly, there are the liquidity providers (LPs) who supply the crypto tokens to the pool from which borrowers draw loans, and who receive the interest paid by borrowers on those loans.

If the protocol smart contacts can’t be a “secured party,” then it seems logical that the LPs—who are the true lenders here—should be the “secured parties.” It’s from their assets that our borrower’s loan was made, and it’s to secure the repayment of their assets that the borrower’s locked tokens stand as collateral. This is the case even though the borrower never directly dealt with any specific LPs, and may not even know who they are.

In the world of traditional finance, a multi-lender loan would typically have some kind of entity sitting between the lender group and the borrower as administrative or collateral agent. That agent would hold the security interest, coordinate the lender group, and take remedial actions on behalf of the lenders upon default. The UCC specifically provides that such an agent can be a UCC “secured party.”

But the whole point of decentralized finance is to expunge centralized intermediaries like collateral agents. A DeFi lending pool trusts in the immutable logic of its smart contracts to substitute for the functions of intermediaries. And that innovation can be hugely compelling in many ways, improving speed, cost and efficiency compared to traditional structures.

But for UCC purposes, that decentralization also probably means that the secured parties in our hypothetical are the LPs—and if there were to arise a dispute involving the security interest, remedies or other UCC matters, the borrower and LPs/secured parties would need to thread their way to each other through the smart contracts’ code and metadata and the records of block explorers, in order to find the UCC “persons” who can pull the necessary UCC levers, and then to get those persons organized enough to actually pull those levers.

And that doesn’t look easy. Our hypothetical suggests that lending protocols might consider implementing solutions like having springing arrangements to appoint a collateral agent embedded in pre-approved legal documents. Such back-up agent arrangements could be reflected in the protocols’ terms and conditions, and come into effect via the smart contracts for those LP wallets that have supplied liquidity balances at the time of the borrower default. They could provide agreed-upon mechanisms for the agent to hold the security interest, coordinate amongst the LP lenders and prosecute remedies. It would be centralization, yes—but only as and to the extent needed.

Oh, and you’d definitely want to make sure that your agent is a “person” and not a smart contract.

The views expressed in this post are solely those of the author. This material does not constitute legal, financial or other advice.