by Chris McDermott[1]

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.

by Chris McDermott[1]

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.