Nonetheless, whether innovative or cautious most of the projects share a common trait: the tokenization features only apply to the instrument sold into the capital markets. The underlying collateral assets are typically not tokenized. Instead, those base-level assets usually retain the time-honored, paper-bound forms that old-school TradFi lawyers like me know and love.

That’s not universally the case, of course. Some projects do tokenize the underlying collateral as well as the issued security. Figure Markets and Centrifuge are two long-standing examples. Intain and FIS more recently rolled out their tokenized loan platform for community banks. There are certainly others. But projects that tokenize assets at the underlying collateral level, rather than only at the issued security level, still seem the exception rather than the rule.

As a result, I’m always on the lookout for new entrants to the tokenized-collateral club. So it is that my eye was caught a few days ago by a press release from Forum Markets, in which they announced a new loan warehouse facility for tokenized auto loans.

The arrangement described in release involves the automation of loan applications at the dealer level, and the use of AI to deliver credit decisions within minutes. But in addition to those features, the release describes the project’s integration of blockchain infrastructure at the point of origination and dealer funding. The release says that Forum uses the blockchain-based rails of Liquidity.io’s alternative trading system to enable 24/7/365 settlement for a “real-time blockchain-native issuance framework.”

Now, from the public details in the press release I can’t really be sure that these auto loans are tokenized from inception—although it sure sounds like it. (I’d be eager to understand the Forum structure better.)

But in my UCC lawyer’s brain, the very concept of tokenizing underlying receivables collateral triggers one big, flashing idea.

Tokenized receivables are simply better collateral.

The reason hearkens to the recent 2022 amendments to the UCC. One of the most important—and, I think, least appreciated—aspects of those recent amendments is how they give certain tokenized receivables superpowers.

Everyone’s familiar with the usual way to perfect a pledge against traditional receivables: you run a UCC search and file a financing statement. For certain receivables, if your structure involves buying rather than merely pledging, you might get automatic perfection without filing. And in either case your perfection is solid—so long as you’re first to file or perfect. Under the pre-amendment UCC you couldn’t perfect your security interest in garden-variety receivables (i.e., accounts or payment intangibles) by taking control of them—there was no such concept.

Under the amended UCC, though, things can be different. If an account or payment intangible is evidenced by a crypto token—or in UCC parlance, a “controllable electronic record” (CER)[1]—and the obligor on the receivable agrees to pay the person who controls the token, that receivable might be something new: a “controllable account” or a “controllable payment intangible.” And security interests in controllable accounts and controllable payment intangibles can be perfected by control.

If a secured party takes control of the token evidencing such a receivable, that secured party’s interest can not only be perfected through such control, but it can be prior to other, non-control-perfected security interests—even ones that were perfected by financing statements filed earlier in time.

Not only that, if a secured party or other purchaser takes its interest in such controllable accounts and controllable payment intangibles for value, in good faith, and without notice of a claim of a property right, the amended UCC lets that secured party or purchaser take the receivable free of other competing property interests. Those other property interests are actually cut off. That’s true even if the person granting the interest didn’t actually have a good property interest in the collateral to begin with—as might be the case if (to take a totally random and not-at-all-timely example) a debtor were to double-pledge its receivables. A secured party that takes control of receivables that are properly tokenized so that they constitute controllable accounts or controllable payment intangibles should win in a contest with other security interests and property claims, as long as the controlling secured party is pure of heart.[2]

The UCC-astute among you will no doubt point out that auto loans, like those in the Forum warehouse facility, are presumptively chattel paper under the UCC, not accounts or payment intangibles. They would therefore fall outside the scope of “controllable accounts” and “controllable payment intangibles” under the amended UCC. True enough. But changes under those same UCC amendments can also render tokenized chattel paper better collateral than non-tokenized chattel paper.

The pre-amendment UCC encompassed electronic, as well as tangible, chattel paper. For this discussion we can leave aside the tangible type. The pre-amendment UCC did permit perfection of a security interest in electronic chattel paper to be achieved by control. But under the pre-amendment statute’s safe harbor, such control generally required that the chattel paper be locked into a system that permitted only a single authoritative copy of the chattel paper. Further, the pre-amendment statute specified certain technological details required of an acceptable system, like requirements that copies of the authoritative record be noted as copies, or that amendments to the record be identifiable as such.

Those legacy systems are perfectly workable, as far as they go, and still work under the amended UCC. But those systems often take the form of electronic vaulting platforms that immobilize the chattel paper onto a centralized server. Transacting with such controlled chattel paper is therefore a function of that centralized server: if the guy who needs to push a button on the server hasn’t made it into the office yet, your transaction isn’t going through until he does.

The UCC amendments, however, expanded the concept of control for electronic chattel paper to include tokenization-friendly concepts. First, multiple authoritative copies are now permitted—as would be the case in a blockchain ledger distributed over many nodes. Second, a purchaser may identify itself by any means, including by cryptographic key. Third, the amended UCC language ports in many of the same phrasings used in the control provisions relating to CERs. Those terms focus less on details of a particular technological system and more on the powers of the control person to control modifications and transfers.

In addition, the UCC amendments also imported certain other CER-related language into the chattel paper provisions: terms about when control is “exclusive” or not, and how control can be shared. As a result, wallets that are set up for control of crypto could potentially also work to give UCC control of tokenized chattel paper.

While the amendments to the UCC don’t extend new take-free rights to tokenized chattel paper, like for controllable accounts and controllable payment intangibles, they do make control perfection and enhanced priority available. No longer does electronic chattel paper have to be tied down to a single, immobilized authoritative copy. Now tokenized chattel paper—with all its open-ended features of programmability, composability, efficiency and always-on transactability—can also benefit from that control perfection and non-temporal priority.

In a word, tokenized chattel paper is also now better collateral.

I’ll stop there, although the UCC analysis can go much deeper. Even these few points give some important things to think about. And, of course, there are many reasons besides the UCC why it might make sense to tokenize a deal’s underlying collateral, and not just the top-level security.

It will be interesting to see whether innovations like the Forum, Figure and Intain projects that tokenize underlying assets continue to be the exception—or whether they herald a coming wave of more complete, top-to-bottom tokenization structures.

[1] Actually, a CER isn’t necessarily identical with a “token.” Whether any particular digital token in fact constitutes a CER under the UCC requires a somewhat complicated inquiry into how its tech stacks up against the Article 12 definition of “control.” But, since in general most typical crypto tokens should fall under the rubric of CER, we can leave that complexity aside.

[2] As for whether the secured party can be “empty of head” as well as “pure of heart,” note that New York’s enactment of the UCC amendments retains its non-uniform subjective standard for “good faith.” See https://www.cadwalader.com/fin-news/index.php?eid=1005&nid=142#:~:text=New%20York's%20definition%20of%20QP%20would%20pull,dealing%E2%80%9D%20included%20in%20the%20uniform%20UCC%20text.

TL;DR

·                  Whether pledges of tokens to DeFi vaults really work depends on how well their smart contract functions synch up with the Uniform Commercial Code (“UCC”).[2]

·                  Vault smart contracts are not UCC persons and therefore cannot, in themselves, be secured parties. Vault users need to identify who the “persons” actually are in the vault structure to establish UCC security interests.

·                  Whether the remedial functions of vault smart contracts (such as liquidation of collateral) are compliant with the UCC depends on the facts—such as whether the markets where collateral is traded are “recognized markets,” and what types of UCC assets the collateral tokens constitute.

Anyone watching the digital assets space over the last few years can tell you that financial markets are inexorably moving onto blockchains. But what might financial transactions look like when they make the shift? That’s not so clear.

It seems to me that traditional off-chain transactions will not simply be the same menagerie of beasts, except mapped point-for-point onto on-chain twins. Instead, I suspect that as they move on-chain, traditional transactions will evolve into wholly new life forms.

And, I also suspect that at the center of many of those new transaction structures will reside DeFi vault systems.

To an old-school lawyer like me, vaults feel oddly familiar. Trying to understand a vault—like trying to understand a traditional deal—requires a piece of paper, a pencil, and lots of boxes and arrows. But the writer’s cramp is worth it. The possible applications of DeFi vault technology to complex tokenized transactions are irresistible.

Many aspects of DeFi vaults chime with traditional off-chain finance. For example, yield vaults (like those compliant with the common ERC-4626 standard[3]) commonly issue “share” tokens to users, kind of like interests in traditional special purpose vehicles. Supplied assets might be deployed into strategies developed by curators, like traditional fund managers. On-chain vault structures provide for share accounting, collateral valuation and yield distribution—again like their off-chain fund cousins.

Even more intriguing to a UCC lawyer like me, though, is that the tokens deposited to a vault smart contract might be usable as “collateral” for borrowing other tokens—and if a borrower fails to maintain adequate collateral coverage, that deposited collateral might be liquidated to repay the borrowing. It sounds like traditional seizure and disposition of collateral—except that vaults use smart contracts to automate these borrowing, collateral and liquidation processes.

And that automation piques my interest. Do the mechanisms embedded in vault computer code really pass muster, UCC-wise? Or might they not survive legal challenge under the UCC?

In this article I’ll take a look at a few of the issues these questions pose.

*                                *                             *

In broad terms, security interests under the UCC have three aspects: creation, perfection and remedies. Creation of a security interest refers to the steps by which a security interest comes to exist between pledgor and secured party. Perfection refers to the steps that protect the secured party’s interest against, not just the pledgor, but the rest of the world. And remedies describe what happens when the pledgor defaults—how does the secured party use the collateral to pay itself back?

The UCC has rules covering all three of these areas. But nowhere does the statutory language mention DeFi, vaults or smart contracts.

So, how well do the UCC rules map onto the secured lending functions of a DeFi vault? I’ll use the Aave V3 Earn Vaults[4] as my model for this exercise—not to pick on Aave, but because it is a well-known platform and has extensive public documentation.

*                                *                             *

Creation.

To create a security interest that is enforceable—or, in UCC jargon, to “attach”—three things must occur. First, value must be given. Second, the debtor must have rights in the collateral (or the power to transfer rights). And, third, either the debtor must sign a security agreement describing the collateral, or another action that the UCC allows to substitute for a security agreement must occur. One of those substitute actions is for the secured party to have “control” over the collateral under specified UCC sections defining control, “pursuant to the debtor’s security agreement.”[5]

To those familiar to traditional secured lending, a security agreement is intuitive enough. It’s an agreement whereby the pledgor says straight up, “I hereby grant to the secured party a security interest” (or words to that effect) in the collateral described in it, and then the pledgor signs.

In the Aave vault system, the supply and withdraw functions of the Pool.sol contract (the main user-facing contract handling most user interactions) provide the mechanism for providing collateral. The supply function governs the underlying asset being supplied in exchange for a vault share token (“aToken”), and the withdraw function governs the withdrawal of the underlying asset from the vault and the burning of the related aTokens. The withdraw function, however, only permits withdrawals to the extent that they would not result in the user’s “health factor” (a measure of leverage and collateral) being less than 1. This effectively “locks” the underlying token into the Pool.sol contract to back the borrowed amount.[6]

However, if you look at the code in the smart contracts, you won’t find a specific security interest grant. Perhaps this is not surprising. The purpose of a smart contract (despite its name) is not to record the terms of a traditional legal contract in the traditional legal way, but to cause a computer to take defined actions. Although in connection with the Aave contracts the pledgor presumably does “sign” electronically (e.g., to trigger an allowance for the pool contract to provide aTokens to the pledgor’s address), what the pledgor signs via the smart contract is not the “I hereby grant” clause of a traditional security agreement.

Could a written security agreement be hiding somewhere else?

The Aave platform has terms of service[7] on its website (“Terms of Service”), which is in the form of an off-chain legal contract. The Terms of Service cover a number of topics, and provide that by using the “Services” described the user is entering a binding agreement. Those Services include not only the Aave websites, but also any applications or services that are linked—whether accessed through the website or otherwise. In other words, even if a user interacted with the smart contracts directly, and bypassed the Aave front end website housing the Terms of Service, the terms would still purport to apply.

Scanning through the Terms of Service, you’ll come across this language:

“You agree to the automated collection and disbursement of proceeds by smart contracts.

You acknowledge and agree that all transactions accessed through the blockchain-based networks will be automatically processed using one or more smart contracts. By engaging in transactions using the Services, you acknowledge and consent to the automatic processing of all transactions in connection with using the Services. You further acknowledge and agree that the applicable smart contract will dictate how the funds of a transaction and ownership of cryptoassets are distributed.”

Can we squint our eyes and see in this wording a security agreement sufficient for UCC §9-203(b)?

The language certainly says that the user agrees to the way that the smart contract functions work, presumably including the withdraw function’s locking mechanism, so you could argue that it might effectively “create or provide” a security interest, as per the definition of “security agreement” in the UCC.[8] As for describing the collateral, the UCC requires it to be “reasonably identifie[d]” and permits a security agreement to describe collateral by category or by any other method if the identity of the collateral is “objectively determinable.”[9] Do the references in the Terms of Service to “funds of a transaction” and “cryptoassets” cut it? Maybe.[10]

But there is a different problem with the Terms of Service as a security agreement: who is the secured party? Although the Terms of Service are brought to you by Aave Labs (who are defined as the “we” and “us” in that document), Aave Labs is careful not to put itself in the middle of the user’s transactions with the protocol. They are not intermediaries, agents, advisors or custodians, and they do not take possession of cryptoassets or funds. In fact, the Terms of Service expressly say that Aave Labs does not control or operate the Aave Protocol, and is not a party to any transaction on the blockchain networks underlying the Aave Protocol.[11]

If Aave Labs is not a party to the transactions, it presumably also does not hold any security interest created under those transactions. To find a secured party to be party to a security agreement under the Terms of Service, you’d need to find some other person.

Let’s put that question aside for the moment and assume that the Terms of Service don’t add up to a security agreement. What about the other basis for creation of a security interest noted above: the secured party obtaining “control” of the collateral?

Control.

If we are talking about cryptocurrency tokens, under the UCC such tokens are likely to be characterized as controllable electronic records (“CERs”).[12] For CERs, control is a basis for both the creation of a security interest under UCC §9-203(b)(3)(D), and for the perfection of that security interest under UCC §9-314(a). Further, to create the security interest, such control would also have to be obtained “pursuant to the debtor's security agreement.”

“Control” in the context of CERs has a specific meaning under the UCC. We’d need to line up the functionality of the Aave smart contracts against that meaning.

UCC §12-105 defines control of a CER. Generally, a person has control of a CER if the CER, a record attached or logically associated with the CER, or the system in which the CER is recorded gives the control person three powers: (a) the power to avail itself of substantially all the benefit of the CER, (b) the exclusive power to prevent others from availing themselves of substantially all the benefit of the CER, and (c) the exclusive power to transfer control of the CER.[13]

Can you argue that the functions of the Pool.sol contract gives this kind of control to the Aave vault?

As noted already, the withdraw function prevents the withdrawal of the underlying token from the vault when the health factor is too low. You could take the view that locking the tokens in the contract gives the vault the power to avail itself of the benefit of the tokens (i.e., their value), and that the withdraw function gives it the exclusive power to prevent others from availing themselves of the benefit of the tokens.

Further, another function in Pool.sol called liquidationCall[14] permits an outside actor (a “liquidator”) to call that function when the pledgor’s health factor is below 1, to repay a portion of the associated borrowing and to have a discounted amount of the underlying cryptoassets transferred to the liquidator (plus a bonus). Liquidators do not have to be externally owned accounts (“EOAs”) associated with natural persons or legal entities; the function call can be made by bots, AI agents or other smart contracts.

You could argue that the liquidationCall function gives the Pool.sol contract the exclusive power to transfer the assets. You could further argue that this is so despite the limited way that the Pool.sol contract permits the transfer—after all, while they are locked in the contract, there is no other way to move the tokens (except returning them to pledgor when the loan is repaid).

In addition, as already noted you would also need to find that this control is “pursuant to the debtor's security agreement”—an awkward phrase which means, not that the parties have signed a security agreement, but that the secured party’s control is pursuant to the pledgor’s agreement in connection with the creation of a security interest.[15]

Here, you might look to the language of the Terms of Service quoted above, as evidence that the pledgor’s agreement to the smart contract control functions locking tokens and permitting liquidations was intended by the pledgor to be in connection with the creation of a security interest.

These may all seem strained, but not impossible, arguments for asserting UCC §12-105 control for purposes of creation and perfection of a security interest in tokens supplied as collateral pursuant to the Aave Pool.sol contract. But we run into the same problem as with our discussion of the security agreement: where is the “person” who is the secured party?

Perfection by control of a CER requires that a “secured party” have control under UCC §12-105.[16] A “secured party,” in turn, is defined[17] by reference to certain persons. Under the UCC, a “person” may be an individual or certain legal or commercial entities.[18] But computer programs like the Aave smart contracts are not on the list—and indeed are not entities. DeFi vaults, in and of themselves, are not UCC persons.

So if we want to create and perfect our security interest in the tokens locked in the vault by control, we have to identify a “person” to whom the security interest is granted. And who that might be is not obvious.

It’s not the vault smart contract itself—the contract’s not a person.

It is certainly not Aave Labs—the Terms of Service make that clear.

The only other possibility that I see is, perhaps, that the other participants in the vault collectively might stand in the position of secured party. This makes some intuitive sense. If the purpose of the collateral is to secure the vault against pledgor’s failure to repay its loan, then it is the other vault participants who benefit.

And even though, at any given time, the blockchain addresses participating in the vault might include addresses of other smart contracts rather than exclusively person-owned EOAs, each such smart contract address must ultimately link up to an EOA that set it in motion—even if the links go up a long chain of smart contracts. You can find persons in the vault, whether directly or indirectly, and you could argue that together they are the secured party.

In reality, though, just finding the persons wouldn’t be enough. In the real world, they’d somehow have to work together. The governance relationship among those vault participants would play a key role in establishing how their shared security interest might be administered or enforced, and whether such arrangements are compliant with UCC §12-105’s rules on control sharing—failing which, the whole security interest creation and perfection scheme might fail.[19]

Resolving those complexities fall to the developers who design vault architectures—with guidance from their UCC boffins.

Remedies.

But what I really wanted to talk about is UCC remedies.

When a debtor doesn’t pay its obligations to the secured party, the secured party must have the ability to take the collateral and apply it to pay itself back. That’s the whole point of collateral.

And legal systems have rules about how that process can take place. Those rules vary depending on the kind of collateral. If the collateral is real estate, for example, those rules might live in state real estate foreclosure procedures. And if the collateral is UCC collateral, those rules live in Part 6 of UCC Article 9.

I should hasten to add that Part 6 in not an exclusive set of secured party rights. Other regimes, such as certificate of title statutes for vehicles or the Federal Copyright Act for registered copyrights, might also come into play. And Part 6 rules sometimes just do not apply, like if the transaction is a sale of accounts, chattel paper or payment intangibles (likely including the tokenized RWA versions of those assets).[20]

But in general, a secured party has the rights in Part 6, together with (subject to some limits) the rights provided by agreement of the parties.

In our Aave example, there is a Terms of Service document that might or might not constitute a security agreement by the pledgor. Those Terms of Service, however, don’t contain the kind of lawyered-up remedies provisions common in traditional security agreements. (Of course it could—and many projects employing similar vault systems use off-chain legal documents that, presumably, are much closer to traditional finance documents.)

But let’s posit that our Aave ERC-4626 vault system does not supplement the UCC with otherwise-agreed remedies. What remedies does the secured party have, then, based on the UCC alone?

Quite a lot, really.

Section 9-601(a) generally permits a secured party to enforce its security interest “by any available judicial procedure,” bringing in procedures like foreclosure, replevin, and levy. A secured party might use self-help to seize collateral without judicial process, so long as it doesn’t breach the peace (no wrenches, please).[21] A secured party may collect proceeds on the collateral (such as yield and staking rewards on the underlying supplied tokens) and notify a person obligated on collateral to make payment to the secured party.[22]

But it’s UCC §9-610 that provides the remedy we all tend to think of: the right to dispose of the collateral.

The general constraint on selling collateral is that every aspect of the disposition must be “commercially reasonable.”[23] That doesn’t mean that the only way to sell collateral is to run an auction on the courthouse steps. There’s more flexibility than that—the statute expressly says that collateral can be disposed of in public or private proceedings, by one or more contracts, as a unit or in parcels, at any time and place and on any terms. Just as long as it’s commercially reasonable.

And as part of that disposition procedure, the statute provides a general rule that the secured party must provide a reasonable prior notification to, among other persons, the debtor, any secondary obligors, and any persons who within 10 days prior to the secured party’s notice of disposition have told the secured party of their interest in the collateral. A “safe harbor” provision assures secured party’s compliance if the secured party runs a UCC search not later than 20 days or earlier than 30 days before its notice of disposition and sends its notice to persons who have financing statements covering the collateral.[24]

I’m fairly sure that most ERC-4626 smart contract liquidation functions aren’t requesting lien searches or sending notices of disposition. But luckily, there is another section that DeFi vault liquidation processes might look to for compliance.

Section 9-611(d) provides a critical exception to the notice requirement for three types of collateral: collateral that is perishable, collateral that threatens to decline speedily in value, or collateral that is of a type customarily sold on a recognized market.

Cryptoassets may be many things but they aren’t perishable the way fish sitting on a dock is—so the first leg probably wouldn’t apply. However, perhaps the other legs might.

Crypto is famously volatile, and moment to moment may indeed threaten to decline speedily in value—so a pretty good argument might be made on that score. But perhaps more promising is that there are markets of various kinds where many types of crypto are bought and sold—centralized exchanges, decentralized exchanges, liquidity pools and other sources of price quotes on crypto. But are these “recognized markets?”

The UCC Official Comments contain discussion of what the drafters had in mind with the recognized markets exceptions.[25] The Official Comment explains that recognized markets involve fungible assets where sales produce market prices that are not lower than those that might be expected from other commercially reasonable dispositions, including those involving notifications. Recognized markets might involve matched book arrangements where buyers and sellers do not enter into individual negotiations. OTC markets where parties engage in bilateral bargaining are likely not to be recognized markets. Regulatory supervision of markets, like stock and commodities exchanges, is a factor supporting the markets being recognized markets.

Where that leaves crypto markets is complicated. The Official Comment cautions that new trading platforms and new technologies should be taken into consideration, and that the touchstone is functional: whether a market produces reliable price data. But applying such concepts in the wild is hard. Cases at the extremes might be easier—a large CEX’s very liquid matched-book market for a widely-held cryptocurrency might readily be deemed a recognized market under the UCC, whereas a small AMM-powered liquidity pool for a thinly traded memecoin might clearly not be a recognized market. But in between the extremes lies an expanse of gray.

It’s notable that the Aave smart contracts do not just dump the crypto collateral onto a CEX or DEX. Rather, they orchestrate an auction for the collateral, albeit an auction that doesn’t neatly map onto the UCC §9-611 notice safe harbor. If the assets are widely quoted on platforms that are likely to be recognized markets (like bitcoin or ether), maybe that’s okay (assuming the rest of the Part 6 requirements are met).

But if the liquidated assets are cryptocurrencies without wide price quotes, or illiquid tokenized RWAs such as tokenized private loans or tokenized commercial receivables, then whether that process satisfies the UCC looks a lot less certain. Indeed, tokenized RWAs deployed to yield vaults may in general require special handling in structuring the remedial functions.

One parting shot: the secured party in all these remedy processes needs to be alert to the ramifications of failure to comply with the requirements of Part 6. Not following the rules can result in painful sanctions. The secured party might be liable for damages for the loss caused by its failure to comply. Further, if the collateral ends up being insufficient, the debtor’s deficiency obligation might end up being reduced or eliminated.[26]

And there’s a special headache in the crypto space: if the collateral is CERs, controllable accounts, or controllable payment intangibles, the fact that a secured party doesn’t know the actual identity of the pledgor under the vault doesn’t absolve it of its duties to that unknown pledgor—unlike the rule to the contrary for other UCC assets. Why? Well, the law takes the view that a secured party taking crypto collateral knew going in that pseudonymous blockchain markets might not provide identity information about pledgors. In other words, that’s your problem.[27]

*                                *                             *

The above discussion only scratches the surface of the UCC issues that could arise when you implement secured transactions via DeFi vaults. And it ignores lots of other legal factors—not least of which is whether conflicts of law analysis would apply the UCC to the vaults at all.[28]

But even this high level run-through hints at how much complexity can arise. CERs may be the easy case; when other UCC assets are involved, the complexity likely increases.

And the UCC is not, of course, the end of the discussion. A complex vault-structured deal would need to thread UCC analysis with all the other usual suspects: bankruptcy, tax, capital treatment, securities law, and so forth.

But DeFi vaults like ERC-4626 vaults hold great promise as key features in the increasingly sophisticated structures needed to bring institutional tokenized RWA transactions on-chain. And UCC analysis is a critical part of structuring those transactions to optimize outcomes, and to make the tech work with the law.

[1] Senior Counsel, Cadwalader, Wickersham & Taft LLP.

The views set forth in this article are mine alone, and not those of my firm or partners. This article is for educational purposes only and is not legal, accounting, financial, investment or tax advice.

[2] References to the UCC in this article are to the UCC as promulgated by the Uniform Law Commission, which reflect the digital assets-focused 2022 Amendments to the UCC. Note that not all states have adopted the 2022 Amendments. See https://www.uniformlaws.org/committees/community-home?communitykey=1457c422-ddb7-40b0-8c76-39a1991651ac

[3] ERC-4626 is an extension of the ERC-20 fungible token standard which creates a standard, composable interface for tokenized vaults. This avoids the previous need for vaults to develop individual special interfaces to interact. See J. Santoro, Jet Jadeja, Alberto Cuesta Cañada, Señor Doggo, “ERC-4626: Tokenized Vaults: Tokenized Vaults with a single underlying EIP-20 token,” Dec. 12, 2022. https://eips.ethereum.org/EIPS/eip-4626

[4] See generally Aave Documentation, Aave Earn https://aave.com/docs/aave-v3/vaults/overview#aave-earn (accessed 2/1/2026).

[5] UCC §9-203(b).

[6] See Aave documentation, Aave V3, Smart Contracts – Pool https://aave.com/docs/aave-v3/smart-contracts/pool#write-methods-withdraw . The withdraw function calls internally to SupplyLogic.executeWithdraw, which in turn validates the withdrawal against the health factor via a call to ValidationLogic.validateWithdraw. See https://github.com/aave-dao/aave-v3-origin/blob/main/src/contracts/protocol/libraries/logic/SupplyLogic.sol ; https://github.com/aave/aave-v3-core/blob/29ff9b9f89af7cd8255231bc5faf26c3ce0fb7ce/contracts/protocol/libraries/logic/LiquidationLogic.sol )

[7] Aave.com, Terms of Service (Updated January 6, 2026) https://aave.com/terms-of-service

[8] UCC §9-102(a)(74).

[9] UCC §9-108.

[10] I didn’t try to research the question for this article, but I suspect finding crypto-related UCC cases clearly on point may be challenging.

[11] Terms of Service, 1. Welcome to Aave.com and the Interface!, 2. Services.

[12] This assumption is an oversimplification and shouldn’t be taken at face value. In fact, many tokenized assets (particularly RWAs) are likely to be other kinds of UCC assets, or be comprised of both CERs and some other UCC asset.

[13] UCC §12-105(a). Note that the person must also be able to identify itself as the person having such powers, although the statute permits such identification to be made “in any way,” including by cryptographic key.

[14] Aave Docs, https://aave.com/docs/aave-v3/smart-contracts/pool#write-methods-liquidationcall

[15] See UCC §9-203 Official Comment 4.

[16] UCC §9-107A.

[17] UCC §9-102(a)(73).

[18] UCC 1-201(b)(27). “ ‘Person’ means an individual, corporation, business trust, estate, trust, partnership, limited liability company, association, joint venture, government, governmental subdivision, agency, or instrumentality, or any other legal or commercial entity.”

[19] See §UCC 12-105(b)(2), (c). Control sharing can be complex, and is a rabbit hole beyond the scope of this article.

[20] See UCC §9-601(g). Commercial reasonableness is still required, though.

[21] See §UCC 9-609(b)(2).

[22] UCC §9-602(a)(1), (2). Whether a secured party is required to apply those yield proceeds to debtor obligations or subordinate obligations pursuant to UCC §§9-608 and 9-207(c)(2) may turn on whether those proceeds are characterized as “money,” “funds” or “cash proceeds.” Many crypto assets—even stablecoins that function like on-chain money—are not “money” under the UCC but might be cash proceeds. This is another rabbit hole that is beyond the scope of this article.

[23] UCC §9-610(b).

[24] UCC §9-611(b), (c), (e).

[25] UCC §9-610, Official Comment 9.

Note that exceptions for dispositions via recognized markets occur, not only in UCC §9-611(d) regarding notices but also in UCC §9-610(c)(2) (secured party may purchase collateral in private disposition if it is customarily sold on a recognized market) and UCC §9-627 (sales on recognized markets are commercially reasonable).

[26] UCC §§9-625(b), 9-626(a)

[27] UCC 9-605(b), 9-628(f).

[28] For example, the Aave Terms of Service are governed by Caymans law.

We then took a hypothetical, and considered how we might tokenize some stuff in a warehouse, using a special purpose vehicle (an LLC) to hold the stuff.

Our first approach was to tokenize the LLC’s equity interests. But there are more ways to solve the hard problem of tokenization for our tokenized stuff.

Let’s jump back in.

2. Tokenize a Payment Obligation of the LLC.

Tokenizing the equity of our special purpose LLC is a decent proxy for value of the stuff it owns, because, as an SPV, it is not supposed to have any other debts. But while an SPV should be free of other claims, we know that in the real world things can go awry. Despite best intentions, claims might arise against our LLC that might be senior to the LLC equity interests.

So what if we want to move up the capital stack, and tokenize our stuff using a debt claim rather than an equity interest? If the tokens were to represent payment obligations owed from the LLC to the token holders—loans, in other words—the tokens could have a better seniority than LLC equity interests:

An obligation by the LLC to pay token holders in relation to the stuff’s value seems intuitive enough. It’s debt. (For simplicity let’s ignore how the debt arose, and whether the payment obligation is for “money” or for a non-money proxy like a stablecoin.)

But even in this “simple” case, when we scratch deeper we still find that tricky issues arise. Namely:

a. Where Does the Contract Live? A payment obligation is a contract, and contracts are generally subject to ancient rules like the Statute of Frauds, requiring them to be in writing. Newer statutes like the Uniform Electronic Transactions Act empower parties to form contracts using electronic records and give them the same effect as written contracts. Digital tokens and the smart contracts that generate them are certainly electronic records. So that’s a promising start.

But does a smart contract—despite the word “contract” in the name—really create a legal contract? For a contract to be formed at law certain classic elements need to be present, elements like offer, acceptance, consideration, intent to form a contract. In addition, there must be a clear and unambiguous expression of the contractual terms.

For our example, let’s assume that our smart contract arrangement satisfies the initial elements. What about the last—can a smart contract clearly and unambiguously express the terms of a legal contract?

Smart contracts are expressed in high-level programming languages such as Solidity (the most common language for Ethereum-based smart contracts). While programming languages are indisputably languages of a sort, they exist to create bytecode to instruct a computer—not to be intuitive to an untrained human reader.

Okay then. I wrote the following English-language sentence, which expresses the obligation for our LLC to pay an amount to a token holder:

“LLC promises to pay Holder x value on y date.”

Because my coding skills are hopeless, I then asked ChatGPT to express the same wording as a Solidity code snippet.

The output was rather different from my natural language version:

The two expressions are simultaneously similar and dissimilar. Both provide for the LLC to make payment to the Holder in the set amount at the set time. But while the natural language expression, with its evocative word “promises,” conveys intimations of honor and trustworthiness (and possible reprisal if the promise is broken), the Solidity expression is purely mechanical: it’s basically just a payable function to provide a mechanism for the LLC to pay Holder.

It’s not that one is better than the other; they’re just different.

And while, in an appropriate situation, a token smart contract might very well fully express the parties’ contractual agreement, it’s more likely to be the case that some things in the contractual deal will be appropriate to be handled by a smart contract, and some things will not.

A tokenized legal contract is likely to have multiple parts and to live in multiple places, partly on-chain and partly off. The different parts of the tokenized legal contract would likely need to cross-reference each other somehow—by the natural language contract including the blockchain address of the related smart contract, perhaps, and by the smart contract encoding a link or resource identifier pointing to the off-chain contract.

Such cross-reference slots might permit the payment obligation in our example to be embedded in a legal contract that travels with the token—a contract comprised of both the smart contract code and the logically-related traditional contract—and in that sense, the payment obligation would be truly “tokenized.”

The technical implementation of the tokenized contract matters, however, and it can significantly affect how fully it solved the hard problem of tokenization. For example, we might consider that a solution that provides for the use of wallet addresses and digital signatures to form and assign the contract more fully tokenizes the payment obligation, than a solution that relies on manual execution and re-execution of off-chain paper contracts with each new instance or assignment of the token.

b. Can the Contract be a Controllable Payment Intangible? Under the 2022 Amendments to the UCC, certain payment obligations are given superpowers. One such payment obligation is the “controllable payment intangible” (CPI).

CPIs benefit from negotiability—the right of certain good-faith purchasers to take them free of other claims—and of secured parties to perfect a higher-priority security interest in them by control. Neither right was available to payment intangibles before the 2022 Amendments. Establishing our payment obligation as a CPI would make our tokenization solution significantly more robust.

So how would we do that?

The 2022 Amendments define a CPI as:

“a payment intangible evidenced by a controllable electronic record that provides that the account debtor undertakes to pay the person that has control under Section 12-105 of the controllable electronic record.”

Assuming that in our example the digital token is the relevant controllable electronic record (CER), what does it mean for the token to “evidence” the payment intangible, or “provide” for payment to the control person? Must our token’s smart contract directly include a payment obligation, like our AI-generated snippet? Must we literally embed in the token’s code our LLC’s undertaking to make payment to the control person of the token? Or, would it be sufficient for the smart contract to cross-reference a natural language document located elsewhere?

The Official Comments to the 2022 Amendments say that, well, it’s kind of both.

Despite the statutory language that the CER “evidence” the payment intangible and “provide that” the account debtor undertake to pay the control person, the comments acknowledge that, in reality, the promise to pay would normally be evidenced apart from the CER. That pulls in favor of a smart contract that identifies (but doesn’t directly encode) provisions of an off-chain document.

However, the comments continue, the CER (or an associated record) should “indicate in some fashion” both the account debtor’s obligation to pay the control person, and that the CER evidences the payment intangible. That pulls the other way—in favor of coding it all into the smart contract directly.

So then, how should we build our tokenized payment obligation to be confident that it’s a CPI?

While some or all of the promise to pay might reside in an off-chain instrument that points to the token, it would be prudent to put into the smart contract coded elements that clearly tie back to the CPI definition. One way might be to code in an event which, upon transfer of the token, emits a string literal that reads something like:

“This token evidences the payment intangible referenced in [_], the obligor of which has undertaken to make payment to the person in control of this token.”

Couldn’t hurt—and it would make a better case for this being a CPI and thereby a more robust solution to the hard problem of tokenization.

c. What About Getting a Security Interest? Absolutely—great idea! Taking direct collateral on the stuff to secure the tokenized payment obligation can only bring the tokenized asset closer to the underlying value, and enhance our tokenization solution.

We would face the same issues of deciding which contractual provisions of the security instrument to code directly into the smart contract and which to express off-chain. The security interest here would be on the stuff—actual goods in the real world—so the new Article 12 digital assets concepts wouldn’t apply. We’d follow the old-school security interest “classic” approach: lien search, security agreement, financing statement.

In addition, we would likely need some person to hold the security interest on behalf of the token holders. The smart contract can’t be a secured party itself (it’s not a “person”). And while you could run the security interest to the holders of the tokens collectively, just thinking about the intercreditor complexities gives me a headache. Whether we provide for it in the smart contract or in an off-chain contract—we’d get a collateral agent.

3. Tokenize a Negotiable Warehouse Receipt for the Stuff.

But what if we think that tokenized interests in SPV equity or tokenized payment obligations are still too far removed from our stuff? What if we want to tie our tokens directly to the stuff itself?

In our example the stuff is held in a warehouse, and the warehouse probably issued a warehouse receipt for it. What if we tokenize that warehouse receipt?

A warehouse receipt is a kind of document of title. A document of title under the UCC is a record that evidences that the person in control of the document has the right to receive, control, hold, and dispose of the both the record and the goods that the record covers.

Through the magic of the law, a document of title effectively embeds within itself—i.e., “reifies”—the goods themselves.

A warehouse receipt can be paper or electronic. The 2022 Amendments to the UCC added new control language intended to accommodate blockchain-type platforms for electronic documents of title, modeled on the provisions included in Article 12 for control of CERs like digital tokens.

A warehouse receipt can be negotiable, which allows a person who takes it by “due negotiation” to have full title to the covered goods free of claims by the warehouse (other than items included in the receipt, like the warehouse’s lien for storage costs and insurance). And while a warehouse receipt does not need to follow any particular form, Article 7 provides for terms typically included in a warehouse receipt that could give rise to liability if they’re not included.

Those terms (such as location of the warehouse, a unique identification code of the receipt, description of goods, storage charges) and the other typical characteristics of documents of title (such as delivery and due negotiation) seem well suited for smart contract implementation. A smart contract could even automate payment of warehouse charges, to keep those pesky warehouseman’s liens off.

Of course, if we wished to tokenize our stuff as a tokenized warehouse receipt, we would need get a third party—the warehouse—to be on board and engaged with the project. (The warehouse, which could stand to cut expenses and delays, might well be proponent of such a blockchain solution.) And, while a tokenized warehouse receipt would pose many of the same issues noted above for evidencing a payment obligation in a digital token, the issues would seem just as solvable for a warehouse receipt as for other contracts.

However we handle these issues, the benefits of a tokenized warehouse receipt—its negotiability and its reification of rights to the goods—may make it the most direct solution to the hard problem of tokenizing our stuff that we’ve seen.

*     *     *

As the examples above show, there are a lot of ways to tokenize assets. These examples are by no means comprehensive. But they do demonstrate that different approaches to the hard problem of tokenization can result in a range of different legal effects.

This is not to say that any one way of approaching the hard problem of tokenization is better than another. The optimal approach depends on the goals of the project. Practical market considerations, regulatory constraints, the costs of creating that incrementally-more-perfect smart contract—all such factors go into decisions about how to approach tokenization. There is not a one-size-fits-all legal solution.

Further, as tokenization markets mature, tokenized assets themselves will be tokenized—think of a tokenized asset-backed security which is secured by a pool of tokenized loans, which themselves hold as collateral tokenized real estate. The hard problem of tokenization then becomes a game of multi-level chess.

But whether the situation is simple or complex, it just doesn’t work to gloss over the knotty questions posed by the hard problem of tokenization. The legal effects matter. If your tokenized asset finds itself in court, you don’t want it to be legally illusory.

Digging deeper and engaging clear-eyed with the range of technological and legal alternatives, we can get closer to the optimal solutions to the hard problem of tokenization.

When brain scientists study the human mind, they refer to something they call the “hard problem of consciousness.” By this they mean (and I’m radically simplifying): how does a technical engine, like the human central nervous system, give rise to subjective experience? How does the one thing link up to the other thing?

The tokenization of real world assets (RWAs) has a “hard problem” too.

Just as brain scientists try to relate a tech stack (the brain) to a valuable system output (consciousness), so asset tokenization must relate a technological object (the token) to its associated valuable asset (the RWA).

But while the hard problem of consciousness bends toward matters philosophical, the hard problem of tokenization is—in major part—a legal problem.

And for asset tokenization, this legal problem is an urgent problem—perhaps the urgent problem. Because if a token is supposed to give you some rights attached to an asset ahead of the rest of the world, you need to know what kind of legal thing that token is. Is it a contract? A right in property? An interest in a company? Or, is it none of the above?

Solve this legal problem well, and your token may have true substance. Fail to solve it, and, legally, your token may be a handful of nothing.

*     *     *

To see what I mean, let’s start by defining tokenization (or trying to). Different people define it in different ways. Here are three non-lawyer definitions I pulled more or less at random from around the Internet:

“Asset tokenization is the process by which an issuer creates digital tokens on a blockchain or other form of distributed ledger to represent digital or physical assets.”
- Hedera

“Digital asset tokenization is the process whereby ownership rights of an asset are represented as digital tokens and stored on a blockchain.”
- Chainlink

“Tokenization is the process of creating a digital representation of a real thing.”
- McKinsey

It sounds straightforward enough. But it can play tricks on you.

Let’s consider a simple homely example. Let’s say a five-year-old drew a picture of his grandfather’s boat on an iPad (light mode, please!):

This picture is a “representation” in digital form of an asset that exists in the real world. Let’s go further—let’s say that the child’s mom or dad is blockchain-proficient, and just for fun they decided to embed the picture into an on-chain digital token, like an NFT. Now it’s a digital representation of a real world asset stored in a token on a blockchain. It seems to fit the above definitions.

Nevertheless, I think we’d all agree that the grandfather’s boat has not been “tokenized.”

The issue is not that the digital picture and token lack intrinsic value. (Indeed, the grandfather would say the picture is priceless.)

Nor is the issue that the quality of the data making up the representation is crude. We could fix that crudeness—by adding photos, asset information, data feeds, and so on.

But it’s still not enough.

The problem with our boat-picture token is that it doesn’t transmit the value of the real-world boat to the token in any reliable way. To transmit such value would require the establishment of some relation between the boat and the token that enforceably gives the token’s holder some kind of rights to the boat (or its value). This token doesn’t do that. It doesn’t solve the hard problem of tokenization.

This issue isn’t confined to our whimsical example.

Think of all the marketing diagrams you’ve seen from tokenization projects, outlining the process of asset tokenization. They’re common enough. Such a diagram might look something like this:

But if you zoom in on that middle bit... :

Magic, indeed.

*     *     *

Because what is most exciting about blockchain is the sexy new technology, it’s tempting to assume that the solution to the hard problem of tokenization resides solely in that same technology. But it does not.

Rather, the solution resides in something more mundane: the legal relation between token and asset. And that legal magic is too often glided over with fuzzy words that let us off the hook from doing the hard thinking needed to make tokenization work.

Look back again at those definitions above. Notice how much heavy lifting is being done by the word “represents,” and how little that word really tells us. If we don’t grapple with the question of how a token legally represents an asset, our attempts to solve the hard problem of tokenization will be off-target and suboptimal. They might even be little more than magical thinking.

2. TYPES OF TOKENIZED RWAs.

So then, what should the legal relation between asset and token be? It depends on what kind of tokenized RWA you’re aiming for.

You could sort tokenized assets into a couple different types:

Directly Tokenized Assets. A token might actually “be” an interest in the underlying thing you’re tokenizing. This could be the case, for example, if the underlying asset were itself digital- or blockchain-native. Think of a real world asset that consists of licensing rights to a software package that was born on a blockchain and lives on a blockchain. It should be technologically straightforward to create a token on the same blockchain that would transfer direct shares in those licensing rights to the token holder. Such a token could be described as a direct tokenization of the software.

Further, there are some future-oriented jurisdictions that are putting title records to traditional physical assets on blockchain ledgers as well (e.g., land, vehicles), opening the possibility that those assets could be directly tokenized, too.

Indirectly Tokenized Assets. A token’s legal relation to the value of the underlying asset might be indirect in some fashion. Because most RWAs natively exist somewhere other than blockchains, the process of creating a legal relation between such assets and a token requires some kind of legal “bridge.” The fact of that bridge makes the relation between asset and token inherently indirect. But these indirect bridges can vary widely, and the quality and efficacy of the tokenization that these bridges provide accordingly can produce widely various results.

Derivative Tokenized Assets. A token may have a legal relation, not to the underlying asset itself, but to other separate assets on a derivative basis. For example, imagine if tokens were issued relating to a pool of cryptocurrency, where the participants in the pool enter into swaps designed so that the tokens reflect changes in value of a different reference asset, such as shares of a publicly traded stock. You could say that the stock has been “tokenized”—even though the token doesn’t provide any ownership right in actual shares of that stock, but instead links to the proxy assets in the pool.

Mirror Tokens. Finally, a token itself might have no legal bridge to its underlying asset at all. For example, a token might be designed such that the token ledger tracks an off-chain ownership record of an underlying asset. The tokens might reflect information about the underlying asset. There might be separate, off-chain contracts that do connect to the asset—but not to the token. Unless the token has some further legal relation bridging it to the underlying asset, such a mirror token—in and of itself—may be a mere abstraction without substantive rights to the asset.

*     *     *

Honestly, though, this nomenclature of “direct,” “indirect,” “derivative” and “mirror” is really not terribly clarifying. Most tokenized RWAs fall somewhere on a spectrum across these types, and where they fall depends on how their legal structure is implemented. There are often many possible implementations of a tokenized solution for a RWA, each with different legal effects—effects derived from legal treatment under a range of legal areas: the Uniform Commercial Code (UCC), corporate and company law, contract law and property law, to name just a few. And, as solutions to the hard problem of tokenization, such structures may be more robust or less robust.

3. LET’S TOKENIZE SOME STUFF.

One way to illustrate these intricacies is to take deep dive into another example.

Imagine for this example that we have some real-world stuff sitting in a warehouse that we want to tokenize. One common approach to tokenization is to use a “legal wrapper”—a special-purpose vehicle (SPV) that holds the underlying assets—in order to effect some kind of indirect tokenization.

SPVs are useful for structures like this because they are set up to be bankruptcy-remote. By design they isolate their assets from the risk of being dragged into a bankruptcy of the assets’ originator. They are barred from incurring other debt or liens, so the assets they hold stay free of other claims. In addition, among other requirements SPVs must act in a way that’s truly separate from the originator’s business, they are required to maintain their solvency, and before they can file Chapter 11 they must get the vote of a disinterested manager.

So, let’s say that we create a special-purpose limited liability company, transfer the stuff into the LLC, and tokenize away:

Our stuff is now safely owned by the SPV LLC, ready to be represented by tokens.

But the existence of the legal wrapper doesn’t by itself solve the hard problem of tokenization. There’s more thinking to be done.

There are a few alternative approaches we might apply:

1. Tokenize the LLC Interests.

Since the legal wrapper is an SPV and there should be no other claims on the stuff, we might view the equity interests in the LLC as a good proxy for the stuff itself. We might therefore decide that our tokens should represent the LLC interests in our legal wrapper:

But how should the tokens “represent” the LLC interests? That question, in turn, sends us down a cascade of new rabbit holes to explore:

a. The Tokens Could “Mirror” the LLC Interests. Let’s say that the LLC mints tokens into the wallets of its equity owners, and those tokens track a separate “official” record of LLC interests that the LLC maintains off-chain. That is, whenever the holder of an LLC interest transfers its interest in the off-chain record, the LLC calls a function of the token smart contract to make a corresponding update to the token ledger.

Without more, this doesn’t create a legal relationship between the LLC interests and the tokens. The LLC interests themselves really only exist off-chain; the token is a just a tracker.

To create an actual legal relationship, we would need further legal infrastructure. We might create a separate matrix of traditional contracts between the LLC and the token holders in order to establish the token holders’ rights to the LLC interests. But in that case, have we really “tokenized” the stuff? The more we create such legal infrastructure away from the tokens, the less the tokens in and of themselves really carry the value of the stuff.

Nonetheless, in a given circumstance and depending on the project’s goals, this approach might be a perfectly valid solution to the hard problem of tokenization. But we should recognize that the link between token and asset in such a case is weak.

b. The Tokens Could be Instructions for the Transfer of LLC Interests. Another approach would be to give the on-chain tokens a direct functionality with respect to the off-chain record of LLC interests.

In this case let’s assume that the LLC interests are UCC “uncertificated securities”—for example, the LLC has opted for its interests to be covered by the securities provisions of the UCC (Article 8). Let’s also say that under the LLC’s operating agreement, the exclusive method for triggering a transfer of the LLC interests is for a token holder to transfer its token. Upon such a token transfer, the token smart contract would cause a notice to be sent to the LLC (or its transfer agent), directing them to record the transfer of the associated LLC interest in the official off-chain LLC records to match the token ledger.

This arrangement would render the token transfer an “instruction” under the UCC and would give the token a real substance. Holding the token would be like holding the key to a house’s front door.

And the key to the house is a valuable thing to have!

But it’s not the same as having the house itself.

In our case, the token would still be a separate thing from the underlying LLC interest, and our “indirectly tokenized” stuff would in fact consist of two parts: the on-chain token and the off-chain LLC interest. In UCC terms, the token would likely be an Article 12 “controllable electronic record” (CER) under the 2022 Amendments to the UCC, and the LLC interest would be a distinct Article 8 uncertificated security.

Why is this important? For one thing, consider the perspective of a secured party seeking to take this tokenized LLC interest as collateral. The secured party would not be satisfied with control of the token alone, any more than a mortgage lender would be satisfied to only have a lien on the door key to a house. Rather; that secured party would want to obtain both control of the token under Article 12, and control of the underlying LLC interest under Article 8. A savvy project using this approach to tokenize the stuff might even build such pledge functionality into its smart contract natively.

It’s fair to say that this solution to the hard problem of tokenization is more robust than the previous one.

c. The Tokens Could Directly “Be” the Equity Interests in the LLC. Is it possible to push the legal relationship between the token and the LLC interest even closer? Let’s change the facts a little bit more.

Say that, once again, the LLC has opted into Article 8 so that its LLC interests are uncertificated securities, and that it plans to issue tokens to represent its LLC interests. But in this scenario, let’s posit that the relevant state organic law and the LLC’s formation documents permit the LLC to adopt blockchain records as its “official” record of LLC interests. Further, let’s say that our LLC’s operating agreement does indeed designate the ledger in the token smart contract to be the LLC’s official record of its LLC interests. Finally, let’s also assume that the smart contract, the front end and the relevant wallet are designed to be compliant with any other statutory requirements (such as the ability to retrieve a paper copy of the ledger if requested).

Now, when the LLC mints tokens to represent LLC interests and the smart contract records them in its token balance mapping, the legal import of that “representation” changes radically. There is no longer a separation between off-chain LLC interests and on-chain tokens. The tokens themselves are now the LLC interests and the Article 8 uncertificated securities. The LLC interests live on the blockchain. Transfers of the LLC interests would be made directly by transfer of the tokens in the smart contract. In this scenario, a secured party seeking to take the tokenized LLC interests as collateral would need look no further than the tokens, and would perfect against the tokens directly as uncertificated securities.

This arrangement creates an even more robust solution to the hard problem of tokenization.

*     *     *

That’s already a lot to think about in our tokenized stuff example. But we’re not done.

In Part Two of this article, we’ll continue the discussion of our tokenized stuff with some more ways to solve the hard problem of tokenization.

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.

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.