What to Know Before You Regulate Crypto
Table of Contents
- Introduction
- Layer 1s: Computation, Storage, Read Access
- Node Privilege
- The Trilemma
- Selling the Right to Make Blocks
- Access to Blocks (RPCs)
- Building Transactions (Front-ends)
- Web2 vs Crypto: A Fundamental Difference
- Proposed Schedules for Apps
- Protocols
- Fungible Tokens
- Non-Fungible Tokens
- DAOs: The Social Layer
- Conclusion
Introduction
Before ‘regulating crypto’, it is critical to understand each layer of the blockchain stack and the unique nuanced differences in information, privileges, and ultimately choices available to participants in each layer of the stack.
No specific regulation is proposed here. Instead, each layer of the stack is explained, separating out information asymmetries, related privileges, and ultimately the choices to be made into defined schedules. These schedules allow for grouping of participants at different layers of the stack which can then form the foundation of more nuanced regulation that incentivizes desirable choices over undesirable ones as defined by relevant regulators and their goals for public access, fairness, and use of this technology and its related protocols and products.
Layer 1s: Computation, Storage, Read Access
Layer 1 blockchains are generally comprised of: [computation environment] [storage] [read access] which may or may not be combined. For example, the Ethereum blockchain stores a history of ‘state transitions’ (historical updates to the ledger), which result from transactions bundled into blocks.
Transactions can be simple:
- Lower my ETH balance
- Raise Bob’s ETH balance
Or complex:
- Call the ETH_PRICE function from this specific Chainlink Oracle contract
- IF 1 ETH >= $1500: Call the TRADE function from this specific Uniswap Exchange contract using the following parameters: [I] [SELL] [5] [ETH] for at least [7,500] [USDC]. If I don’t get at least that amount, revert the trade.
- ELSE IF 1 ETH < $1500: Do nothing.
In either instance computation occurs (here, at a minimum, is the number bigger or smaller than 1500) and if the trade happens storage of the transaction. For transactions to be included in blocks, a ‘node’ must propose its inclusion into a block and that block must reach consensus with other nodes. After some time period (known as time to finality), the block is ‘final’ and the transaction(s) is forever included in the history of the ledger.
Computer software, often called ‘clients’, perform the variety of tasks related to computation, storage, and access of these blocks of transactions. The (human) operators of these clients maintain uptime and receive income for performing their tasks correctly. Because operators can maintain multiple copies of the same client in parallel, each copy is typically called a ‘node’. Often, blockchain specific phrases like ‘miner’ (e.g., Bitcoin proof of work consensus nodes) or ‘validator’ (e.g., Ethereum proof of stake consensus nodes) are used.
Node Privilege
A variety of privileges arise from the power nodes have relative to the users of the blockchain (i.e., submitters of transactions). Some include:
- Knowing about transactions that are available to be placed into future blocks; often called ‘transactions in the mempool’ (memory pool).
- Choosing which transactions to bundle into a block they add to the chain.
- Choosing the order of transactions within a block they add to the chain.
- Inserting their own transactions strategically into the blocks they add to the chain.
Due literally to the laws of physics, different nodes will have different information about the mempool in any specific instant. Transactions are submitted to a node and that node then propagates that available transaction to other nodes in a peer-to-peer fashion. That information is subject to the speed of internet access and even with advanced fiber optic cables and satellite internet the speed of light.
When a node gets a turn to make a block, it does so with only the information it has available. If blocks are made at a high speed (e.g., every few seconds) it is possible available transactions take multiple blocks to even be considered for inclusion because the node making the block doesn’t know about it!
This adds another privilege and a caveat:
- Users can strategically submit transactions to certain nodes
- Nodes can strategically not propagate transactions to other nodes.
This is often referred to as a “private mempool”. Inversely, a node can censor transactions from certain users and refuse to incorporate them into blocks they build or even refuse (or delay) to propagate them to other nodes that would include them.
The Trilemma
If it is desirable for all available transactions to actually be available to every node before blocks get made, you must do 1 of 2 things: reduce the number of nodes to reduce communication distance or expand the time between blocks to give transactions more time to propagate.
Both of these options affect what is called the trilemma: Decentralization, Security, Scale.
Decentralization is the idea that more nodes is generally good because it reduces the benefits of the privilege nodes have, reduces censorship risks, and increases competition among nodes.
Security is the idea that doing bad things (faking transactions, splintering the blockchain, spamming the blockchain etc.) should be expensive and/or punished. Relatedly, that there should be redundancies in the block creation process.
Scale is the idea that more capacity for transactions in both number and speed to finality are good because it improves the user’s experience and the market for blockchain.
Proposed Schedule (Layer 1s)
| Schedule | Description |
|---|---|
| 1 | A blockchain with few nodes, one or few clients, high censorship risk, and low transparency in available transactions. |
| 2 | A blockchain with many nodes, one or few clients, low or medium censorship risk, and low transparency in available transactions. |
| 3 | A blockchain with many nodes, multiple clients, low censorship risk, and high transparency in available transactions. |
Selling the Right to Make Blocks
It is possible nodes outsource their block creation to a market of ‘block proposers’. This is called Proposer-Builder Separation. The key difference between Schedule 2 and Schedule 3 is access to the mempool by those not running nodes.
This is important not only in Proposer-Builder Separation (where non-node block proposers need to see the mempool to make blocks) but also for users. Users that can see available transactions are better able to defend against the information asymmetry that nodes inherently have.
A simple example: how much should I be paying for this transaction? To avoid over-paying, it is critical to know what are other people willing to pay and then putting yourself in line at a price you find acceptable.
Access to Blocks (RPCs)
To submit a transaction to a blockchain requires (A) you run a node and propagate it yourself to other nodes; or (B) you submit the transaction to a node and they propagate it for you.
Submitting a transaction typically requires a remote-procedure-call (RPC). You write your transaction in a pre-specified format (often JSON) and send it over HTTP.
For the vast majority of users, they install a ‘wallet’ software, e.g., MetaMask, often as an extension to an internet browser. This wallet software will have a ‘default RPC receiver’—a specific node or network of nodes that receive transactions from the wallet.
This is where the previously discussed privileges of nodes come into play. Users can choose which nodes to submit transactions to, e.g., purposefully sending them to nodes that don’t propagate them (private mempools). Or if a node is censoring them, they can submit their transactions to a different node.
Proposed Schedule (Nodes)
| Schedule | Description |
|---|---|
| 1 | A node receives only RPCs from specific users, i.e., with bias or censorship; and selectively propagates it. |
| 2 | A node accepts almost all valid RPC sent to it, with rare, prespecified exception, and propagates it in a standardized, consistent way. |
| 3 | A node accepts any valid RPC sent to it, without bias or censorship, and propagates it neutrally to other nodes. |
Proposed Schedule (Block-Builders)
| Schedule | Description |
|---|---|
| 1 | A node curates its own blocks, inserting its own transactions and/or ordering transactions as it sees fit to maximize its revenue; or purchases proposed blocks that maximize revenue which may include censorship. |
| 2 | A node curates its own blocks under constraints that sufficiently reduce privilege from information asymmetry. |
| 3 | A node that curates its own blocks using a prespecified publicly known neutral formula for inclusion and ordering with little to no inserted transactions that maximize revenue. |
Not All Block Builders Are Equal
This is not to imply anything about one Schedule being worse or better than others. A professional organization dealing exclusively in Schedule 1 nodes may warrant regulation that an individual running an open-source block building software would not warrant.
There is real value in keeping choice, profitability—and even private transactions as options in this technology.
Example: Imagine your wallet key was hacked and you wanted to transfer your money safely to a new wallet. If the hacker is running a node and receives your transfer request in the public mempool, they could copy your attempt and finish the hack. Private transactions have already been used to save people from these incidents!
Building Transactions (Front-end Websites and Wallets)
Users don’t routinely format their blockchain transactions in JSON format and send it over HTTP themselves. The wallet creates the JSON using a mix of user inputs and website inputs.
For example, if I want to trade ETH for USDC I can go to Uniswap’s website and input:
- Trade [ETH] for [USDC]
- Amount: [5] ETH
The website will do some calculations and tell me my expected amount of USDC along with a suggested minimum amount to accept.
The website does not take my ETH and give me USDC.
It formats my JSON request (including a to address of the Exchange Protocol Contract) and gives that JSON to my wallet software. I can then review the request and confirm that my wallet should send the JSON request (over http) to a node to propagate the transaction until it’s included in a block.
I don’t need the website at all. I could format the JSON myself using available documentation, reading the code, or using a different unrelated website.
It is closer to accurate to think of the website as spellcheck than to think of it as a broker or custodian of my money.
Web2 vs Crypto: A Fundamental Difference
Banks, E-Commerce websites, and numerous other professional organizations have cybersecurity employees monitoring their websites. Some very important differences between those companies and blockchain products:
1. Companies maintain usernames, passwords, and sensitive data on their users.
This makes their own systems highly valuable for hackers. Blockchain products almost never maintain this kind of sensitive data.
2. Companies monopolize how their users access their assets.
I cannot access my Bank of America checking account using my Wells Fargo credentials. My Bank of America money exists entirely under their control (i.e., custody). Blockchain product websites don’t control access to user funds.
3. Companies monopolize user history.
My gmail uses SMTP to send email messages. I use gmail because it keeps track of my past emails for me. But this comes at the price of centralization.
The Crypto Difference
We demand banks be careful with data, because they collect it. We demand their websites be safe because they are the only way to access our money that they hold.
Blockchain transaction histories are public. It is our choice of wallet that sends JSON requests that we format to RPCs that we select. Those wallets are not the only way to access our money—we maintain control via the “private key.”
While we may use a website to help format our requests correctly, those websites don’t collect the primary history of our requests; nor do they hold (custody) our money; nor do they monopolize our access to protocol.
Proposed Schedules for Apps
Schedule I
| Schedule | Description |
|---|---|
| 1 | An app that monopolizes how users access their assets including taking custody and/or forbidding access outside of itself; and/or retains private keys without the ability to transfer and purge. |
| 2 | An app that, due to important “off-chain” information or inherent complexity, cannot reasonably have the required JSON request formatted by an individual or 3rd party and/or interpreted by a ‘reasonable person’. |
| 3 | An app that interfaces with an associated protocol in a way that is easily formatted, readable, and reviewed by a reasonable person and/or easily mimicked by a 3rd party. |
Schedule II
| Schedule | Description |
|---|---|
| 1 | Central Exchanges and Custody Apps that act effectively like crypto banks; they hold your assets and/or you can’t get your assets without them. |
| 2 | Websites associated with complex products where important information is not easily accessible elsewhere, making the website a de facto monopoly on interacting with the product(s). |
| 3 | A website with little to no important information required to use the product correctly; core functionality is copy-able with reasonable effort. |
Specific Examples
Robinhood is Schedule 1. It holds users’ funds, including crypto assets. These assets must be accessed via their app using credentials they control.
OpenSea is Schedule 2. While users retain ownership of their NFTs, important information for interacting with the marketplace accurately (assets listed, bids) rely on OpenSea’s monopolized database. At any time, OpenSea can censor or refuse access to this information.
Uniswap is Schedule 3. Everything happens permissionlessly. All relevant information (prices, amounts, expected returns) is available at no cost by asking the smart contract. The website is easily copied, has no monopoly on important information, never takes custody, nor collects any data on its users.
Protocols
The easiest dividing line between protocols and websites/applications is on-chain code—the instructions that nodes store and implement when they include valid transactions in blocks.
Key Questions for Protocols
1. Does the protocol replicate a regulated financial product?
There are protocols openly offering large amounts of leverage, tokenized commodities, unregulated fundraising, and shorting with little to no oversight over users.
2. Does the protocol rely on important off-chain information?
AAVE, for example, is a “pawn shop” protocol. To borrow one asset against a different asset requires price information. AAVE uses Chainlink Oracles for this purpose.
3. Does the protocol serve as critical infrastructure?
Chainlink brings off-chain information on-chain. Bridges coordinate transfer of value between chains. The tokens amassed in bridge contracts are extremely valuable to hackers—$100Ms of bridge hacks have occurred.
4. How much value is in the protocol and are risks disclosed?
Contracts responsible for $100,000,000+ deserve more scrutiny than contracts responsible for $10,000. Disclosure of audits and data on amounts at risk is already nearly universally practiced in crypto.
5. Can the protocol be changed without user input or awareness?
Blockchains often have Turing Complete programming languages. This means you can write “upgradeable proxy contracts” that can be changed. Who can change protocols and how are important.
Proposed Schedule (Protocols)
| Schedule | Description |
|---|---|
| 1 | Protocols replicating complex/regulated financial products; requiring off-chain information; and/or holding significant value with ability to move it without user notice/consent. |
| 2 | Protocols relying on little important off-chain information; with any potential changes not significantly altering functioning without user notice/consent. |
| 3 | Immutable protocols with no reliance on off-chain information such that a reasonable person can interact with them. |
Fungible Tokens
Fungible tokens (often ERC20) are tokens that are indistinguishable from one another in the same grouping. There is no ETH #5 or ETH #3250. There are just millions of ETH and they are all equivalent.
Tokens can:
- Act as a unit of account, representing ownership of something
- Act as a medium of exchange, being transferable
- Have direct use as payment for services
- Have custom functionality triggered upon transfer
Example: ETH
The ETH token is used to pay for computation and storage on Ethereum. The market price is irrelevant for this use case. The price for computation is determined by a free market of users submitting transactions with a willingness to pay per unit of computation (“gas”).
Example: LINK
The LINK token is used to pay for Chainlink Oracle services. It’s a modified ERC20 (ERC677) that allows including data inside its transfer() function.
Example: xSUSHI
The xSUSHI token accrues revenue from the Sushiswap protocol. Holders stake SUSHI in exchange for xSUSHI. 0.05% of all Sushiswap trading fees goes to xSUSHI holders—similar to dividends via stock buy-backs, but significantly more decentralized and automated.
Proposed Schedule (Fungible Tokens)
| Schedule | Description |
|---|---|
| 1 | Tokens acting as complex/regulated financial products requiring off-chain information; representing rights to external property requiring intermediary performance. |
| 2 | Tokens with use outside crypto ecosystem and/or representing rights to off-chain property requiring intermediary performance. |
| 3 | Tokens with defined supply verifiable on-chain with direct use within the crypto ecosystem, not requiring intermediary performance. |
Non-Fungible Tokens
NFTs (often ERC721 or ERC1155) are tokens not interchangeable within a grouping. Each is numbered—you don’t own ‘Bored Ape Yacht Club’, you own id #5,300 of Bored Ape Yacht Club.
Why do people buy NFTs? Because they know which ones are real!
The official Bored Ape Yacht Club NFT contract address on Ethereum is 0xbc4ca0eda7647a8ab7c2061c2e118a18a936f13d. Any NFT within this contract is legit. Any other NFT claiming to be BAYC, even with identical metadata, is a fraud because it has a different address.
There are more crypto addresses than atoms in the universe, so replicating an exact address is mathematically impossible.
This is powerful: blockchains have devised a mechanism to enforce digital scarcity—a prerequisite to truly digital property.
The Dark Side
Throughout 2020-2022, NFTs were used to extract $100,000,000s from naive “investors.” Organizations promised profit to unsophisticated buyers who trusted individuals to manage, promote, and develop products. Unfortunately many took the money and ran (“rugging”).
Proposed Schedule (NFTs)
| Schedule | Description |
|---|---|
| 1 | Tokens acting as complex/regulated financial products requiring off-chain information; representing rights to external property or future profit requiring intermediary performance. |
| 2 | Tokens with use outside crypto ecosystem; representing rights to off-chain property requiring intermediary performance. |
| 3 | Tokens with defined supply/characteristics on-chain; including digital collectibles with no premised utility requiring intermediary performance. |
DAOs: The Social Layer
Decentralized Autonomous Organizations are groups of individuals reaching some form of consensus such that the ‘group’ acts separate from the individuals as it relates to crypto decisions. A common joke is that DAOs are groupchats with a treasury.
In practice today, DAOs overlap in the following ways:
- A group of individuals communicate using Discord, Telegram, Twitter, etc.
- A crypto address exists (often “multi-signature wallets”) holding on-chain assets
- Individuals may or may not have property rights to the assets held
- Individuals come to consensus on how the DAO entity should operate, often using “governance” tokens to represent voting power
- Individuals may or may not be compensated for participation
DAOs often serve as the social counterpart to blockchain Layer 1s. There’s [capacity][culture][history] in the place of Layer 1’s [computation][storage][read access].
The Ship of Theseus
Is it the same DAO if every single member is replaced? Documentation allows for a collective history that directly influences capacity and culture.
Proposed Schedule (DAOs)
| Schedule | Description |
|---|---|
| 1 | DAOs operating/managing protocols or treasuries that replicate complex/regulated financial products; required to meet documentation/reporting requirements; may have tokenized property rights. |
| 2 | DAOs operating/managing protocols or treasuries where governance tokens incentivize individual investment; operating a de facto monopolized front-end. |
| 3 | DAOs operating/managing protocols or treasuries; may include governance tokens; managing a Schedule 3 front-end. |
Conclusion: The Lines Are Blurry
The lines between DAOs, Protocols, and Front-Ends is messy. Users may not understand that the website they use to access a DAO incentivized investment opportunity is not the same as the on-chain protocol.
The website could go down and while their assets may not be custodied (i.e., they’re still retrievable with the right JSON) no website is available to help them spellcheck the JSON.
When judging DAOs it’s critical to contextualize:
- The goal
- The sophistication of the participants
- The honesty of the marketing
- The availability of history
- Accessibility of key information
- The power the DAO holds over an associated protocol
Can the protocol be changed without user input or awareness? How much value does the protocol hold and at what risk is that value; is that risk disclosed in a way a reasonable person would understand?