Highlights
Securities intermediaries must be UCC “persons,” so smart contracts in themselves cannot be securities intermediaries.
Complex smart contract implementations such as smart contract wallets may make identifying the UCC “person” more complicated, or may result in no person fulfilling the role of securities intermediary.
Protocols and their users should consider the legal evidentiary requirements in establishing the UCC “persons” involved in transactions intermediated by smart contracts.
Part 1 of this post considered how (or if) smart contracts work under the UCC. They don’t fit under the UCC’s definition of “person”—and therefore also don’t fit into the terms “debtor” and “secured party”—but they can nonetheless own assets and execute transactions. I ran through a hypothetical digital asset secured loan transaction to illustrate the issue.
This Part will continue the discussion, consider a second hypothetical, and then provide a few thoughts on where these questions lead.
* * *
Security Entitlements for Digital Assets.
Our first hypothetical involved a loan directly secured by digital assets. But other common situations in digital asset secured transactions might involve the indirect holding system under UCC Article 8.
Contributing digital assets into a securities account and making an election to treat them as “financial assets” can offer parties peace of mind in a couple ways. First, given the flamboyant recent implosions of digital asset platforms such as FTX, Celsius and Blockfi, both borrowers and lenders may be reassured that Article 8 generally removes financial assets held by a securities intermediary on behalf of its entitlement holders from its bankruptcy estate, were the securities intermediary to become a debtor in bankruptcy.
Second, Article 8 solutions follow well-trodden paths—they’re tried and true. Lenders are familiar with securities account control agreements, and the 2022 Amendments to the UCC make clear that parties can elect to treat digital assets such as controllable electronic records (“CERs”) as financial assets.
But what about new Article 12 to the UCC—isn’t it purpose-built to deal with digital assets, including perfecting security interests by control?
Well, yes. And in many ways Article 12 improves on existing UCC methods, permitting lenders to take control of CERs, controllable accounts and controllable payment intangibles in new ways with superior rights. But given the novelty of Article 12 and the market’s lack of experience with it, some parties may not have the appetite to break new ground with Article 12 quite yet.
So let’s tweak the hypothetical discussed in Part 1 (which was a peer-to-pool loan secured by digital tokens). Let’s say that the lender will make its loan peer-to-peer to the borrower (no DeFi pool), and that the borrower holds the tokens which will be collateral for the loan with a centralized exchange (“CEX”). The CEX maintains the borrower’s tokens in a commingled custodial wallet together with other customers’ tokens. Further, let’s say (1) that the CEX is a “securities intermediary” because in the ordinary course it maintains securities accounts for its customers (including maintaining a securities account for the borrower), and (2) that the CEX has expressly agreed to treat the borrower’s tokens as financial assets.
What the borrower then has under the UCC—and what it is pledging to the lender—are not the tokens directly but security entitlements to the tokens—indirect interests in the tokens under Article 8.
And finally, let’s say that the lender has obtained “control” of the security entitlements under Article 8 (we can ignore exactly which prong of that section the lender used to get control). That control would perfect the lender’s security interest in the security entitlements.
Once again, so far, so simple.
But now let’s say that, one fine day, the borrower and lender get a notice from the CEX about a change. Good news! The CEX is rolling out an upgrade to its custodial wallet which will enhance security, simplify recovery, reduce gas, and permit more complex and customized functionality! The CEX wallet holding the borrower’s tokens will now be a “smart contract wallet”!
The basic idea of a smart contract wallet is to move (or as the cool kids say, “abstract”) blockchain operations away from direct interaction with the user. With a regular wallet the user controls an externally owned account (“EOA”) and the funds held in it through the user’s private key. With a smart contract wallet, however, a smart contract account holds the funds and enters transactions; what the user’s EOA now controls is that smart contract. The user, in effect, has its own personal smart contract to manage the wallet—and because smart contract logic is infinitely variable, the smart contract wallet’s functionality can likewise be infinitely complex and customizable.
Although new technology and new standards (such as ERC-4337) have made account abstraction and smart contract wallets headline topics of crypto media, smart contract wallets aren’t particularly new. And there are various types of smart contract wallets out there.
The familiar multisig wallet, for example, is a kind of smart contract wallet. In a multisig, the signing parties hold private keys to their own EOAs and can sign their approval of a transaction—but their approval goes to the account of a smart contract running the multisig. It’s the smart contract account, not the EOAs, that actually executes the transaction when the requisite signers approve.
Smart contract wallets can vary in their technical approaches. Some use third party relayers, some use native abstraction built into L-2s, some employ the UserOps, alternative mempool, bundlers, EntryPoint contract and paymaster features of the ERC-4337 standard. (Please don’t ask me what this all means; the words boggle my non-tech mind.) But in all cases, a key feature of smart contract wallets is that it is the wallet’s smart contract (not an EOA) that owns the funds, and executes outward-facing transactions.
Getting back to our UCC discussion, the CEX’s insertion of a smart contract wallet into the scheme brings us back to our original issue: are we transacting with a UCC “person” when we deal with that smart contract wallet?
As you may have guessed, in order to be a securities intermediary, the UCC also requires you to be a “person”:
(14) “Securities intermediary” means:
(i) a clearing corporation; or
(ii) a person, including a bank or broker, that in the ordinary course of its business maintains securities accounts for others and is acting in that capacity.
As discussed in Part 1, a smart contract, in itself, isn’t a UCC “person.” Therefore it’s ineligible to be a “securities intermediary.”
So returning to our hypothetical, where does this leave our lender and its security interest in the borrower’s security entitlements? Well, if the CEX is telling the borrower and the lender that the securities accounts are now being maintained in the smart contract ledger of the new custodial smart contract account, the borrower and lender will want to go on a hunt for a UCC “person” who pulls the strings of the smart contract, and who can qualify as a securities intermediary. Without a UCC “person,” there’s no securities account, no security entitlements, and the lender’s Article 8 solution cannot be implemented (at least in the same way as before).
The borrower and lender might reasonably hope that the CEX’s wallet upgrade makes it clear that the CEX is still the person maintaining the securities account as securities intermediary and that the smart contract in the new wallet is just a methodology used by the CEX for its maintaining securities accounts—and is not itself purporting to be the actual party acting as securities intermediary.
But because the structure of a smart contract wallet can be complex, the hunt for a UCC “person” who is clearly the securities intermediary might not be so simple. The smart wallet functionality might abstract away the CEX’s direct interaction with the wallet, and other parties might be involved in various processes. At what point of abstraction does the CEX itself cease to “maintain” securities accounts for customers and cease to “act in the capacity” of a securities intermediary? Could there be bells and whistles built into the smart contract wallet code that raise questions about which persons—if any—are in fact undertaking the duties of the securities intermediary under Article 8, or about whether the account of the borrower still fits within the description of a “securities account” under Part 5 of Article 8?
The more complexity built into the smart contract wallet, the more fraught it may be to reach good legal conclusions. For the lender and borrower the analysis may involve getting their heads around technical facts about the smart contract wallet structure—and that might require a heavy computer code lift that the lender and borrower didn’t sign up for.
But if the lender and borrower ultimately cannot be confident that they have ticked all the UCC boxes on these questions, then they might feel the need to go back to the UCC drawing board. They might reassess the UCC characterization of their interests in the tokens, and how the lender would go about obtaining a perfected security interest in them.
And if the road to an Article 8 solution proves more complicated than they hoped, perhaps they might consider pursuing an Article 12 solution after all.
The Problem of Evidence.
One more thing before wrapping up our hypotheticals: what happens when deals go bad?
In either of our hypotheticals, if there arose a dispute and parties found themselves in a lawsuit, tracing through the smart contracts to the relationships of UCC “persons” who are the transaction parties could be critical to demonstrating how the deal fits under relevant UCC provisions.
But it’s not just a matter of understanding the UCC relationships—it’s also a matter of getting the computer code and decentralized platforms to produce legally sufficient evidence to prove those relationships.
While blockchains are by design transparent, the records they generate are not terribly accessible—at least, not to those of us with less technological proficiency. The parties to a dispute would need evidence that can satisfy the Best Evidence Rule and other applicable evidentiary standards—and displaying a bunch of bytecode on your laptop screen to the judge is not likely to suffice.
Borrowers and lenders (and their lawyers) should spare a thought to how they would acquire that legal evidence if the chips were down. And protocol developers (and their lawyers) should consider how the design of smart contracts and associated features might make such tracing exercises and production of evidence as convenient and legally sufficient as possible.
* * *
Stepping back, it’s important to remember that there are always persons involved in blockchain transactions, somewhere, somehow. Smart contracts can’t initiate their own logic; they sleep until awakened by a function call originated by an EOA—even if that EOA only initiates the first in a cascade of smart contract transactions. From a UCC standpoint, a major problem in transacting with smart contracts is finding the “persons.” New innovations in onchain identifiability and privacy continue to accumulate and make the ultimate persons ever more elusive—developments such as autonomous AI agents, soulbound tokens, privacy coins and all the proliferating variants of zero-knowledge proofs. As such innovations increase, so do the challenges facing lawyers in squaring the UCC’s requirements of “persons” with the technology.
But blockchain and digital asset technology doesn’t exist for its own sake. It exists to improve the lives of people—ahem, of persons. And when we approach the UCC issues of smart contracts in digital asset transactions, remember that somewhere, somehow, there had to be a person who started the ball rolling.
The views expressed in this post are solely those of the author. This material does not constitute legal, financial or other advice.
Article 12 Man