The case against contracts being smart
Are smart contracts the right idea for building a financial system on a blockchain? I suggest that maybe they are not, and we should consider using on-chain dumb contracts instead. What is the distinction?
A smart contract’s rules are enforced by code. As long as the chain is working as intended, the smart contract’s rules will definitely be satisfied (even if those rules do not reflect the intent of the authors). The on-chain code *is* the contract.
A dumb contract’s rules are not enforced by code. The chain records the fact that the parties entered into the contract, without any contract enforcement mechanism in the chain.
A contract specifies that some asset transfers should occur which satisfy its rules. A simple example is a trade, where two parties swap some assets that they respectively own. A trade is a contract which is executed typically as soon as it is entered into. On a blockchain, a trade can be executed as a single atomic transaction which debits and credits the accounts of both parties in order to fulfill the trade.
A more complex example of a contract is a loan. The creditor pays the principal to the debtor at the beginning of the contract. To fulfill the contract, the debtor must make payments on some schedule. The payments must amount to the principal plus the interest, plus any penalties for late payments.
A loan contract (here we are not considering flash loans) cannot be fulfilled in a single atomic transaction. A loan contract is typically not enforceable by a blockchain.
Matthew Doty’s risk-free loan contracts can be guaranteed by a blockchain. However, a risk-free lending protocol does not capture all use cases for lending. Debtors often want to use their money in ways which present some credit risk; debtors are often going into debt in order to leverage their position. Creditors, on the other hand, often want to make loans which carry some default risk, because they may want to collect interest, and they may collect more interest in a loan with a greater default risk. In Doty’s risk-free loans, the lender pays the debtor to issue the loan, which is opposite to how loans usually work. The idea is that the lender should receive something else from the debtor which compensates them for the opportunity cost of issuing the loan.
The next closest thing to a loan contract enforceable by a blockchain is a loan which is fully collateralized, or more typically, overcollateralized, to compensate for risk that the collateral will decline in value relative to the loan. The chain cannot enforce that the debtor can pay back the loan. The chain can enforce that the creditor receives the debtor’s collateral in the event of default.
Collateralized DeFi lending works for some use cases. A person may for example hold a lot of ETH, and they may want to spend USDC without selling their ETH for USDC at market rate. Collateralized DeFi lending doesn’t work for use cases where the collateral is a physical object, such as a car or a house, or for unsecured loans. It is an obvious point that oftentimes the reason a person wants a loan is that they don’t have money with which to pay for something, and if they had the money to take out a fully collateralized loan to make the purchase, then they could instead use that money to make the purchase outright.
There is a conceptual tension between the notion of contracts in traditional finance, and the notion of smart contracts. They are such different animals that they seem to deserve different names. A contract in traditional finance is a set of commitments. The commitments are promises, which people are able to choose to keep or not keep. (Set aside for the moment that there are consequences to breaking promises.) A smart contract is a piece of code which controls the behavior of a blockchain. By design, market participants cannot cause the rules of a smart contract to be violated.
A smart contract is something different from a promise; it is more like a law of nature. Humans can choose to break promises, but we cannot choose not to be pulled down by gravity when we are close to the Earth. Breaking a financial contract is against the law. In that statement “law” refers to human laws, i.e., laws made by humans. All human laws are made to govern only humans, and every human law is such that humans are able to choose not to follow it.
We can draw the conclusion that smart contracts and financial contracts are such different animals that they are disjoint sets: no smart contract is or can be a financial contract, and no financial contract is or can be a smart contract. Financial contracts are promises governing the behavior of humans. Smart contracts are rules governing the behavior of money.
A smart contract may in some instances enforce a financial contract. It is not the case that market participants promise to abide by the rules of smart contracts when they use those services. It is the case on a correctly implemented blockchain that all cash flows satisfy the rules of all applicable smart contracts. It is not the case that there can exist a mechanism for guaranteeing that all debtors pay their creditors back.
Clearly, the notion of smart contracts is not sufficient to capture the notion of financial contracts. What about on-chain dumb contracts? What I mean by on-chain dumb contracts is the practice of recording contracts entered into by market participants on a blockchain, without any enforcement mechanism for those contracts existing in the blockchain itself.
We can include in our blockchain a notion of cash flows associated to a contract. For the case of a loan, the cash flows consist of the initial lending of the principal, and the repayments. A single debtor may owe multiple debts to the same creditor. For this reason, it is not enough to record on the blockchain the contract and the raw cash flows. It is also necessary to associate cash flows to contracts, such as so we can know which debt a debtor intended to make a payment on when one debtor owes multiple debts to one creditor (which may have different payment schedules, interest rates, and penalties).
An interesting thing about a loan is that potentially any set of cash flows from the debtor is a valid response by that debtor to that loan. Due to circumstances beyond their control, a debtor may be unable to pay back a loan in full on the payment schedule. If they pay late, or if they underpay, that may be the best they can do at the time, under the circumstances. If a debtor pays ahead of schedule, they may or may not reduce their interest payments by doing so, but it is valid to do so. If a debtor pays more on a loan than they owe, that can be considered a gift.
A blockchain allows for trustless execution of transactions which move multiple assets at once, such as trades. By constructing and all signing a trade, two or more market participants may trustlessly execute trades on a blockchain, knowing that either they will receive what they agreed to receive (in the case the transaction clears) or they will not pay what they agreed to pay (in the case the transaction does not clear).
A trade is different from a loan in that a trade is a contract which can be executed at one time, or in one transaction, whereas a loan (other than a flash loan) is a contract which cannot be executed at one time or in one transaction, due to the time delay between lending and repayment.
I hypothesize that whereas blockchains can enforce traditional financial contracts which can be executed at one time, they cannot enforce traditional financial contracts which cannot be executed at one time. When a contract specifies future asset flows to occur between the parties, then inherently there is uncertainty as to whether the parties will be able to fulfill the contract. If it cannot be guaranteed that the contract will be possible to fulfill, then in particular, a blockchain cannot guarantee that the contract will be fulfilled.
This, then, makes the idea of smart contracts seem almost completely orthogonal and not ancillary to the idea of financial contracts. If a financial contract is to be executed at one time, then a system of smart contracts is not needed to enforce it. The problem can be solved on the client side. Client software generates a transaction satisfying the contract, and verifies that the transaction does indeed satisfy the contract. The participants in the contract inspect and sign the transaction, and the last signer posts the transaction to the blockchain. It is not necessary in these cases for the blockchain to verify that the transaction satisfies the contract, because the parties to the contract already know that the transaction will fulfill the contract.
Therefore I submit that in most of the cases where smart contracts can enforce financial contracts, they are not needed to do so. Most of the cases where smart contracts can enforce financial contracts are the cases where all cash flows specified by the contract occur at once. Doty’s risk-free lending protocol is another example of where a smart contract can enforce a financial contract; in this scheme, repayment cash flows are pre-ordained and the rules of the chain are such that everyone always has a position which will allow them to fulfill their future obligations. Yet if we look just at traditional financial contracts, we find that the generalization holds.
Let us therefore look to other means of representing financial contracts on chain. Let us consider dumb contracts. What does this approach consist of? We represent the contracts on chain, with each contract recorded in a transaction signed by all participants. We record on the chain which asset flows are associated with each contract, and which part of the contract lifecycle each asset flow is associated with. We record on the chain all ancillary data needed to interpret a contract, such as prices posted by specific markets at specific times. Anyone inspecting the cleartext of the chain can then see what contracts participants are in, and determine whether or not those contracts are fulfilled and what state they are in if they are not fulfilled. The chain’s role in the system of contracts is purely informational; it is not in an enforcement role for contracts.
We can of course have both smart contracts and dumb contracts in the same system. Is this the right idea? Do smart contracts fulfill use cases that dumb contracts do not, just as dumb contracts fulfill use cases that smart contracts do not?
Let’s consider some use cases of smart contracts, beginning with minting. Minting of new asset classes on a blockchain is done using smart contracts in the existing designs I’m aware of. A simple alternative to this would be to let each wallet address mint any number of new asset classes, each associated to that particular wallet address. Let’s call this alternative “dumb asset classes.”
We could allow for both open-ended and closed-ended dumb asset classes. An open-ended asset class allows for the possibility that more will exist in the future, and the asset class creator can create more of them in any quantity, and at any time. A share class in a company would be an example of an open-ended asset class. A closed-ended asset class does not allow for the possibility that more will exist in the future after the initial transaction minting the asset class.
Smart contracts allow for the more general concept of minting policies. Minting policies can define open-ended and closed-ended asset classes. They can also define asset classes such that more of them can be created only under specific conditions, and such that they can be destroyed under specific conditions. With dumb asset classes, they can effectively be destroyed by sending them to a void address, one which cannot correspond to any private key.
Minting policies allow for sophisticated use cases such as algorithmic stablecoins. Let’s consider overcollateralized algorithmic stablecoins for the sake of argument. The general idea here is that the minting policy allows people to mint stablecoins by depositing an amount of crypto worth a multiple of those stablecoins according to an on-chain price index. They can then redeem the stablecoin with the minting contract to get back their collateral. If the price of the stablecoin rises relative to the collateral, then the stablecoin minter may need to add more collateral, or else their position may be liquidated, which oddly enough doesn’t seem to reduce the number of stablecoins in circulation. The hope seems to be that the stablecoin minters will be both strongly incentivized and able to add more collateral to keep the stablecoin overcollateralized by the funds locked in the stablecoin minting contract. Otherwise, the stablecoin may de-peg from its price index once market participants see that stablecoin minters are unable or unwilling to post enough collateral to keep the stablecoin overcollateralized.
Algorithmic stablecoins are hoping to achieve, in a decentralized fashion, using an algorithm, something which is impossible to guarantee: that they hold in reserve enough of currency A to keep redeeming stablecoins for their market price in currency A, while the price of stablecoins in currency A is free-floating.
It seems like the goal of algorithmic stablecoins is to achieve, in a trustless and decentralized fashion, something which has been achieved in a centralized and trust-based fashion: namely, stablecoins, that is, tokens pegged to commodities or fiat currency.
A centralized entity can maintain a peg between a stablecoin and, let’s say, a commodity, by holding one to one reserves of the commodity to back all the stablecoins, selling the stablecoins at the spot price of the commodity, and offering to redeem all stablecoins for the commodity. Of course, it costs money to store a commodity and provide the service of minting stablecoins and redeeming them for the commodity, and there must be fees along the way for users of the stablecoin in order to make the scheme sustainable. This is a way to maintain a peg between a stablecoin and a commodity. The stablecoin plus the efforts required to redeem it are equal in value to having the commodity in hand, and an efficient market will price such a commodity-backed stablecoin accordingly.
The concept of stablecoins has been proven for fiat currency through fiat-backed stablecoins. It makes economic sense that one can maintain a peg between a fiat currency or a commodity and a stablecoin in this manner. What is less clear is whether this can be done in a way that is decentralized and trustless.
At this point it is worth asking the question, are algorithmic backed stablecoins a decentralized and trustless system for pegging a stablecoin? We can grant that they are decentralized, and that one is not trusting any one individual. One is rather trusting that things will not work out in a way where the stablecoin depegs; one is trusting that the stablecoin will not rise in price relative to the reserve currency to such an extent that the stablecoin minters cannot or will not add enough collateral to keep the stablecoin overcollateralized. This seems like maybe a lot to trust.
Due to its high importance, this use case of stablecoins is worth examining in detail with respect to the comparison between smart contracts and dumb contracts. Smart contracts offer a decentralized system for managing a stablecoin’s peg, but you still have to trust that system, and it’s not clear that we can trust those systems. Stablecoins backed by the asset they’re pegged to are more economically rational and could be very reliable, but it’s not clear that they can be set up in a decentralized and trustless way.
Maybe at best we can hope for reducing the trust we place on stablecoin pegging organizations, by demanding that they prove their reserves. We could etch QR codes in gold bars and have the gold stablecoin minters post NFTs of those QR codes to their wallets, denoting the gold they have in reserve. Some of us could go to their vaults and scan the QR codes on all the gold bars to check that they are there. Some of us could check that their claimed gold reserves on the blockchain are one to one with the stablecoins they have minted and not burned.
It is worth noting that fiat-backed and commodity-backed stablecoins can be minted as dumb asset classes. There is no way in any case that a blockchain can govern the minting of these stablecoins, because a blockchain has no way to enforce that the backing assets are there. A blockchain cannot stop a thief from going into the vault and stealing the gold bars.
Are there any convincing use cases for smart contracts? Let’s explore. Let’s turn to DEXes. A decentralized exchange (DEX) can be built using a liquidity pool and a smart contract. The smart contract locks up liquidity in the pool and uses the liquidity to act as a counterparty to trades. It sets the prices by solving an equation designed to maintain some invariant, such as a certain ratio of assets being present in the liquidity pool. This is an approach to solving the problem which works well within the constraints of smart contracts.
Let’s contrast this approach with how traditional financial exchanges work. They use a central limit order book. A central limit order book records all the open limit orders: that is, the quantity of open buy or sell orders at each price point. Matching orders are closed out and do not appear in the order book as it’s reported by the exchange.
Let’s imagine: can we create a central limit order book DEX without smart contracts? Yes, we can, with a major caveat. Here’s how it could work. People post orders to the blockchain: A for B at price X and quantity Y. An off-chain order matching service creates trades (transactions) which can fulfill some of those orders. These order matching services contact the clients of the traders with proposed transactions. In the event that all of the clients sign a proposed transaction, then it gets posted to the blockchain by the last client to sign the transaction.
Now the major caveat. For a limit order to be filled, on this approach, the client of the market participant who placed the order must be live, so that it can sign a transaction. With smart contract DEXes, limit orders could get filled after the fact given that the person placing the order has already signed a transaction to place such an order. What’s good about the dumb contract approach is that the client has the opportunity to look at the price the order is proposed to be filled at and to reject it if it is unfavorably different from the latest market price.
What’s arguably better about the smart contract approach is that the contract could guarantee that each order is filled at the latest market price, without the clients of the people placing the limit orders needing to be online. What’s not clear to me is why this would be better than the client of each party to a trade having verified that each order is being filled at the latest market price, if that’s something that they want to be true.
In the dumb contract approach to DEXes, who runs the order matching service and what is their incentive to do so? Not clear; maybe one of the traders runs the order matching service and their incentive is to get their order matched. What incentive exists for the order matching service to give everyone a good price? Maybe so that the proposed transactions get signed.
In the two use cases we looked at, stablecoins and DEXes, there is no apparent use for smart contracts for stablecoins, and there is a notable benefit to smart contracts for DEXes, which is the ability to fill limit orders when the client of the person placing the order is offline.
Let’s now look at the cost side of the equation. What are the costs of smart contracts? They cost a lot in terms of blockchain complexity, computational complexity of running a blockchain, and the complexity of verifying that it is working as intended. Are the costs worth the benefits? It’s not clear to me that they are.
Here is a modest proposal. Let’s build a blockchain which has no smart contracts, which has only dumb contracts, and let’s try building financial services on that. We can solve all the core problems of scalability and decentralization in this context, and they will be easier in this context. Smart contracts seem to be a distraction from the core goal of building financial services on blockchains. They have nothing to do with financial contracts. They don’t seem to be essential even for their most touted use cases. Supporting smart contracts seems to be putting a lot of dead weight on blockchain projects which are still trying to meet their core goals of providing scalable, reliable, decentralized financial services. I suppose they are intended to help meet those core goals, but it’s not clear to me how they benefit those goals enough to justify their existence.
