Cycles: Respect the Graph

In 2008, a new whitepaper was released: “Bitcoin: a peer-to-peer electronic cash system.”

Today, in 2024, a new whitepaper is released: “Cycles: a peer-to-peer electronic clearing system.”

Since Bitcoin, blockchain communities have been promising a revolution in money, payments, and finance. Today, Bitcoin has taken its seat at the table of international money, but it feels something is fundamentally missing still. The cryptocurrency community, in its theory and its practice, has overemphasized on the Store of Value function of money, and on the asset side of the balance sheet. Heed the rallying cry: to build permissionless, counterparty free assets. Important, no doubt, for securing a fundamental human right to transact. But not sufficient to take on the larger problems of modern money and finance.

Much of the power of banking comes not from the assets but from the liability side of the balance sheet. Specifically, from the coordinated settlement of liabilities through clearing. A peer-to-peer electronic cash system is thus a necessary but not a sufficient basis to re architect finance. What we need is a peer-to-peer electronic clearing system. As we’ll see, we can design a clearing system as a superset or generalization of a cash system.

For centuries, banks have formed closed clearing clubs to settle huge volumes of debt with little or even no money at all. This results in massive liquidity savings for them. But you and I aren’t privy to those clubs. The rest of us are systematically excluded from the power of clearing and issuance, forced to settle in cold, hard cash. The opportunities for us to perform clearing abound, and yet, we have not the institutional support nor the technology to access them.

Until now. With Cycles, anyone can clear their debts in a private, secure, and accessible way, using any type of currency or credit that works for them. The core insight of Cycles is to take a network view of the graph of liabilities between people, and to operate multilaterally (across multiple individuals at once). This is in contrast to the more standard transactional, individualistic, and bilateral view of payments. The network view opens tremendous opportunities for everyday people and businesses to save liquidity: save on cash flow stress, working capital costs, late payments, and so on.

Cycles is made uniquely possible by a core property enabled by blockchains: atomic multilateral settlement. This means we can easily run a settlement operation across many people at once, in an all or nothing way, reducing debts and transferring assets across a group of strangers in a way that optimizes to clear the most debt with the least money for all. Blockchains are uniquely good at this, and with modern techniques, can even do it all privately.

Atomic multilateral settlement is used across blockchains today in the form of asset pools, like those backing automated market makers and lending protocols. But what is the purpose of assets, exchanges, and lending markets if not ultimately to facilitate people making payments? Hence, we need to start from the basics of payment systems.

Payment Systems

So much of finance is actually built on top of or around payments. A most fundamental kind of finance is the simple extension of trade credit itself: I send you goods, you owe me money, in 30 days. These kinds of obligations are fundamental to the monetary and payment systems, and so much of banking arose to enable deferred payments like this to flow. Payments are thus fundamental to what money is. We like to say: “money is where the payments are.”

The design of Cycles is motivated by a brief critique of modern money, payments, and finance. In the whitepaper, we sketch the critique as six key points, indicating how Cycles addresses each. To summarize, a critique of modern finance:

Not designed from first principles, but cobbled together over centuries in response to liquidity crises. Cycles is designed from first principles by asking “how do we clear the most debt for the most people with the least money.”
Reactive risk management via Central Bank lender-of-last resort compounds moral hazard and systemic risk. Cycles takes a proactive risk-management approach using the network structure of the graph to reduce risk.
Over emphasis on transfer and exchange of assets at the expense of the underlying liabilities that ultimately need to be settled. Cycles makes the liabilities a first class primitive and emphasizes settlement of real world debts.
Counterparty substitution and contract novation (securitization, factoring, etc.) transmutate risk in hard to understand ways. Cycles aims to settle debt using existing credit relationships before deferring to more complex risk transmutations.
Fragile dependence on market making dealer intermediaries that extract wealth through liquidity provisioning. Cycles focuses on liquidity saving over the graph with minimal or no intermediaries.
Problems of issuance between and across central and commercial banks. Cycles formalizes the problem of issuance in terms of acceptance, and opens new ways to connect issuance to working capital needs and graph structure.

TL;DR: Respect the Graph.

One of the major goals of Cycles is to provide a clearer conception of how to think about money. As we’ve said, Money is where the Payments Are. Money is fundamentally for payments - for denominating and discharging debt. The three functions of money (Unit of Account, Medium of Exchange, Store of Value) can then be understood simply:

The Store of Value function is obviously important, but not the whole story. The essential problem of payments is actually this. Armed with a Unit of Account, we can denominate unlimited amounts of debt. But how do we know there is enough Medium of Exchange available to settle it all? This is the very question that invokes anxiety in people who are concerned that fractional reserve banking might be a ponzi scheme. If banks create money by making loans with interest, how do they know there’s enough money out there to pay back all the loans and interest? Perhaps there isn’t, and hence why modern banking systems periodically seize up in liquidity crises that require Central Banks to issue more exchange media.

This is what liquidity is all about: the ability to settle a debt when it’s due. This is what it means to take on a liability and to face the liquidity constraint: some day the liability will be due, and you’ll have to actually pay it. This is what spawns the myriad problems of cash flow, grid lock, and late payments that create so much stress, increased working capital costs, and in the worst cases, bankruptcy. As they say, “you can be insolvent for a long time, but liquidity kills you quick.”

Thus Cycles is motivated by a fundamental goal that responds to the perennial liquidity constraint that bears down on all economic actors:

How do we clear the most debt, for the most people, with the least money?

Design

How? We start from first principles, introducing basic primitives from which we can express more complex cases. At the heart of Cycles is a simple System of Intents, containing two kinds of input primitives (obligations and acceptances) and one kind of output primitive (settlement records):

In the whitepaper, we develop a graphical model and a language for describing this system. Let’s start with an obligation. If you owe me, that’s an obligation. Notice it’s your liability, but it’s my asset. If you sent me money on a blockchain, we’d see an asset transfer, but the blockchain doesn’t record what the underlying liability is that’s being settled. Cycles makes the underlying liabilities (the obligations) a first class citizen of the system. And of course, obligations don’t exist in bilateral silos. They form a complex multilateral graph:

What can you do with a graph of obligations? The first thing you can do is set-off, where obligations in a cycle can be netted off against each other:

This is what most people first understand when they think about Cycles. With a set of obligations in a cycle like this, Cycles can produce a settlement record for each obligation that reduces them all, going from Before to After in the figure. But it goes further than this. We can add acceptances.

The simplest way to understand acceptances is as a willingness to accept a currency for payment. For instance, if Alice has money in the bank, and Alice owes Bob, and Bob is willing to accept bank money. We can actually draw this out as well:

Notice Alice’s money in the bank is represented as an obligation from the bank. But Bob’s acceptance of bank money is shown explicitly as an acceptance intent - a dashed line - from Bob to the bank. And notice this makes a cycle. Which means every single payment is actually a cycle in the graph!

When an acceptance is settled, it becomes an obligation going the other way. Bob accepts bank money, so once he has money in the bank, the bank owes him. Of course, we can replace the Bank here with Bitcoin or USDC or any other cryptocurrency, and thus represent any asset as a liability from its issuer. By including the issuer as a node in the graph, the graph can natively include many different sources of liquidity.

But we can also use acceptances to represent a willingness to lend. Specifically, a credit line. If Alice doesn’t have money in the bank (no obligation from the bank), but the bank will lend to her, we can represent that as an acceptance from the bank:

Finally, we show an example where Alice owes Bob and Bob owes Carol. Alice doesn’t have money, but Carol is actually willing to be owed by Alice instead of Bob:

Again, the whole cycle clears, but in this case, no money was needed at all, and Alice just owes Carol. We can express all kinds of graphs using these simple primitives, and the whitepaper offers some further analysis of these four different ways for Alice to settle her debt to Bob. When combined together, we get complex graph structures that we can then optimize over to find the cycles that clear the most debt for the most people with the least money.

The core of Cycles is thus a neutral settlement layer above which users and communities can define various optimization strategies for how they clear their debts. We can even combine many kinds of currency types in a single graph, allowing more and more people to benefit, even if they don’t use or accept that currency!

Ultimately, Cycles allows more debt to be cleared for more people with less money, reducing risk, late payments, and working capital costs across the board.

So, how do we build it?

Protocol

At a technical level, the Cycles Protocol must provide atomic multilateral settlement of private intents in an extensible credit environment. This means:

all settlements execute simultaneously across many parties at once
all debts remain private, including both the amount of the debt and the specific counterparties (who owes who)
All kinds of liquidity sources, currency types, and lending protocols can be integrated into the graph

The architecture of the Cycles Protocol is what we call a ZK-TEE sidecar. It uses a Trusted Execution Environment (TEE) for private off-chain compute, and it uses Zero Knowledge (ZK) proofs to ensure the computation was correct and to reduce the dependence on trusted hardware. The high level architecture looks like this:

Essentially, users encrypt their intents and submit them to the blockchain. At some frequency, the encrypted intents are retrieved by the ZK-TEE sidecar where they are decrypted into a graph. The TEE then runs the graph solver to produce a settlement solution. The solution is encrypted, and a ZK proof is produced attesting to its correctness. Everything is then submitted back to the chain to be verified, before the user sees the final results.

We have implemented this architecture as an open source framework called Quartz, that anyone can use for secure communication with TEEs.

Note the importance of the TEE here. When using ZK proofs alone, there is no privacy from the ZK prover, who must have access to all the input data necessary to produce a proof. This is fine for simple asset transfer protocols like ZCash, Penumbra, or Namada, where the prover is the end user operating only on their own data. But in Cycles, we run a multilateral graph algorithm across many users, where no single user has all the data. The most effective way to do that today is via a TEE. At least until Multi Party Computation and Fully Homomorphic Encryption are further advanced. And what about the vulnerabilities of TEEs? There have been numerous vulnerabilities and security issues over the years. But there have also been many improvements. And we can actually use clever protocol design and blockchains themselves to improve TEE security. Specifically, by running a blockchain light client within the TEE, we can significantly reduce the attack surface area and mitigate many possible vulnerabilities. See the talk from our founder Ethan Buchman, on How to Win Friends and TEE-fluence People.

Finally, the Cycles Protocol must support an extensible credit environment. It defines an account model where every node in the graph is a smart contract account that also corresponds to a balance sheet. This makes every node a liquidity source, and every liquidity source a node. Thus, in Cycles, every account is a lending protocol. This creates an innovative new environment for experimenting with new risk-reduced stablecoins and lending protocols.

Cycles enables countless use cases, from simple trade credit payments and clearing to more advanced financial relationships. Auto repayment of loans, data-based lending and stablecoins, private funding of SMEs, p2p loans with and without capital, mutual credit, Circles UBI, discount ladders for p2p factoring, batched exchanges, and more!

The Cycles Whitepaper is just the first step in our bringing these powerful new ideas to the world. Our ultimate goal is to build a universal payments and finance engine to clear the most debt for the most people with the least money.

2024-11-21

Announcing the Cycles Whitepaper

Table of Contents

Payment Systems

Design

Protocol