In Part One of this article, we considered how there must be a legal bridge between real world asset and token for the RWA to be robustly tokenized—to solve the “hard problem” of tokenization.

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.