# Paradigm > Paradigm is a research-driven technology investment firm focused on crypto, blockchain, AI, and frontier technologies. ## https://www.paradigm.xyz/writing/paradigm-comments-on-sec-and-cftc-s-joint-reporting-and-definition-requests # Paradigm Comments on SEC and CFTC’s Joint Reporting and Definition Requests > Paradigm encourages holistic review and agency alignment between CFTC and SEC regarding swaps. Last week, Paradigm filed comment letters responding to the CFTC and the SEC’s joint requests for comment, one on swap and security-based swap data reporting and the other on the definition of “swap” and “security-based swap.” These rules matter because they strike at something important: how to bring the last generation of our financial system onchain. The two requests for comment come down to a simple choice between giving effect to the statutory text or elevating formality over function. In each case, we urge the Commissions to choose the former, and to update their rules to take advantage of technology that already delivers what those statutes require. **Reporting.** Three core themes should guide the agencies’ overall approach: - Technological neutrality: Reporting rules should specify the desired regulatory outcome, not the mechanism for achieving it. An on-chain swap is transparent, immutable, timestamped, and publicly auditable at execution. We therefore ask the Commissions to recognize an alternative pathway under which credible public blockchain data satisfies the reporting obligation and to bring the framework onchain, which will facilitate price transparency while ensuring that counterparty identity remains confidential. - Harmonization: While alignment should not be pursued for its own sake, it is a worthy goal where different frameworks do nothing but increase regulatory burden and costs for firms active in both markets. Where a specification is workable for both agencies it should be identical, and we encourage the SEC to codify its alignment with the CFTC’s rules before the 2019 Compliance Statement expires in 2029. We also support harmonized requirements for platform-executed uncleared trades, materiality thresholds for correcting errors, and machine-readable rule structures, which pair naturally with on-chain reporting. - Decentralized finance: Reporting obligations have always attached to responsible persons and intermediaries, not to software code, protocol developers, validators, or node operators that exercise no custody, control, or discretion. Where a transaction runs through genuinely non-custodial infrastructure and no traditional reporting party exists, the obligation should run to the participants, not to the software itself. **Definitions.** Our second letter answers two separate questions, each of which concern different products but both of which present the choice between form and function in its sharpest form. On Question 8, we encourage the agencies to recognize that an event contract is an option “on” a security when, and only when, its payout is determined by the price of a security. We ask the Commissions to confirm both halves of that reading: A contract with a payout determined by reference to where a stock closes is a securities option, while contracts that reference another indicator that may have some incidental effect on stock price–such as an election, macroeconomic release, or operating metric–is a swap. The critical question, in other words, is *how* a contract pays, not what determines *whether* it pays. On Question 11, we make clear that we support the CFTC’s decision to find that “future delivery” is satisfied for a BTC perpetual, and encourage the agencies to find the same terms for other forms of perpetuals, including those on equities. These contracts easily satisfy the hallmarks of a futures contract–they are standardized, fungible, traded multilaterally under transparent rules, and tethered to spot by a rules-based convergence mechanism–and the Commissions are correct to recognize as much. The Commissions deserve credit for taking these difficult questions up jointly and on principled criteria. We look forward to continued engagement, and you can read our full reporting comment [here](https://assets.ctfassets.net/vb2n37v5ldjn/55OPdqQ2wU6qjBvpoieUgf/50ac250aa62b6f8bc95cb67401b5ca5f/Paradigm_-_Reporting_Comment__08.24_.pdf) and our definitions comment [here](https://assets.ctfassets.net/vb2n37v5ldjn/1OBSG9blg4zKpYXsfSJKZ8/9cef05fa49524fb4fb753c06e426714b/Paradigm_-_Definitions_Comment__08.24_.pdf). ## https://www.paradigm.xyz/writing/gpu-world # GPU World > GPU World: A story competition from Neal Stephenson, Gwern, and Matt Huang. What if the world had one GPU per person? $100K in total prizes. GPU World: A story competition from Neal Stephenson, Gwern, and me. The AI future is unevenly distributed. What would the world look like with AI broadly diffused, such as if we had one GPU per person? 1000-5000 words, fiction or non-fiction. $100K in total prizes.  [gpuworld.org ](https://www.gpuworld.org/) *GPU World* ## https://www.paradigm.xyz/writing/joining-paradigm-calvin-zeng # Joining Paradigm > Calvin Zeng Joins Paradigm I’m excited to announce that I’ve joined Paradigm as a Partner, focusing on AI, robotics, energy, space, reindustrialization, fintech, and other frontiers. I grew up playing StarCraft, a game with a fractal strategy space. Each expansion added units and buildings, opening new branches of the tech tree. But whether any particular build was viable came down to the underlying numbers - cost, build time, range, damage - and how everything interacted. The metagame emerged as players tested that possibility space. I loved theorycrafting, but only playing revealed what worked. The technological frontier is fractal in much the same way. A breakthrough like AI opens a new tree of possibilities, but technical and economic variables determine which branches become viable. As builders and researchers explore that possibility space, progress along a working branch can compound much faster than linear extrapolation would suggest. I started my career at Vista and TPG, large private equity firms where investing meant working inside-out - management access, data rooms, and models built from years of operating data. Later, at Altimeter, public markets demanded the opposite - work outside-in with far less information. You still had to understand the business deeply, but that alone created no edge; you had to find what others were missing. I then joined Patrick Fu on Dandelion’s founding team just as AI opened the first major technical frontier of my investing career. There, I learned from researchers and builders whose jagged insights changed my priors about which technical paths might become viable. Investing at the frontier meant synthesizing those insights with the disciplines I had learned before: understand a business deeply and find what others were missing. I began asking what a firm built around that combination could look like. When I met Matt and Alana, I was struck by how much thought they had given to the same question. They had built a world-class firm where investors, researchers, and builders work together and learn from one another. Paradigm refined this model in crypto, where technical depth was essential. I believe it translates naturally to the broader frontier. Several technological frontiers are now advancing at once, each opening new branches in the others. As those advances interact, progress can compound far faster than it would within any one field alone. The fractals of the future are vast and inspiring. I’m particularly interested in technologies that do more than improve the world as it exists - technologies that make a different world possible. If you are building along one of these paths - or one that does not yet have a name, I’m reachable via DM on [X](https://x.com/zirppls) and by email at calvin@paradigm.xyz. ## https://www.paradigm.xyz/writing/rsi-simulator # RSI Simulator > An interactive web game and model explorer from Paradigm that demonstrates the economics of recursive self-improvement and AI R&D. We created a [web game](https://paradigm.xyz/research/rsi/game) to demonstrate the economics of AI research and development. You play an AI lab working to bootstrap an artificial superintelligence from scratch, investing labor, compute, and data into R&D until you are able to achieve self-sustaining acceleration. The game is inspired by a recent paper, [The Economics of Recursive Self-Improvement](https://elasticity.institute/rsi-paper.pdf), as well as other foundational research papers from economics and computer science. The game is built on the actual economic models from those papers, but is not meant to be a realistic forecast. The models depend heavily on their parameterization, and in the game, the parameters are calibrated for pedagogy rather than predictive accuracy. To understand how the course of the future could depend on some of the relevant parameters, we created an [explorer](https://paradigm.xyz/research/rsi/explorer) to dig deeper into the underlying models. AI development is complex, fast-moving, and hard to predict, but it has obeyed some statistical laws (particularly the scaling laws governing model training) with surprising fidelity. We are excited about the potential for games and simulators to help us find and understand new useful models for the trajectory of AI research. ### Background Understanding the trajectory of AI capabilities is one of the most important questions for predicting the future. In particular, understanding how AI itself accelerates AI research—often called *recursive self-improvement*—might be the most important component to understand, since it could lead to sharp inflection points in the rate of improvement. We are interested in ways to quantify recursive self-improvement and predict its trajectory, and are particularly excited about the [Economics of Recursive Self-Improvement](https://elasticity.institute/rsi-paper.pdf) paper, which came from a recently-formed group of economists (including Tom Cunningham at [METR](https://metr.org/)) called the [Elasticity Institute](https://elasticity.institute/). We’re excited about their approach, and created the game and explorer to help understand the model and some of its implications more intuitively. The explorer provides an interface for visualizing and interacting with all of the models in the paper. The game draws on ideas from the paper to create a dynamic model that also incorporates ideas from [compute-optimal training](https://arxiv.org/abs/2203.15556), [R&D-based models of growth](https://www-leland.stanford.edu/~chadj/JonesJPE95.pdf), [scale-dependent algorithmic progress](https://arxiv.org/abs/2511.21622), and [weak-links in automation](https://web.stanford.edu/~chadj/JonesTonetti_Automation.pdf). ### Takeaways The game and explorer are tools that can be helpful for understanding the inputs and constraints of recursive self-improvement. Here we share a few insights gained from engaging with the work mentioned above and developing these tools: *Weak links dominate.* AI research uses complementary inputs: human researchers, compute, and data. If intelligence is plentiful, other factors may still bottleneck progress. Recursive self-improvement may be compute- or data-constrained. This could particularly be true if algorithmic progress continues to be dependent on increasing scale, as observed in [Gundlach et al. (2025)](https://arxiv.org/abs/2511.21622) (another model incorporated into the game). Even if you could build an AI that is better than any human AI researcher, it would still be limited as a researcher by its access to compute for experiments and training, as well as by data (at least as long as the current paradigm holds). *Recursive self-improvement may come in spurts.* It is possible for AI to experience self-sustaining acceleration for a period, and then stop long before reaching the physical limits of intelligence. In fact, this seems likely if compute remains a bottleneck. *We might have a "narrow" intelligence explosion first.* We might achieve recursive self-improvement first through "narrow" capabilities (specific to AI research or optimization) that don't fully generalize. *Predictions depend on parameterization.* The economic model outputs depend on parameters called *elasticities*, which tell you how much a quantity increases in response to an increase in a given input. The critical elasticity powering recursive self-improvement is the elasticity of the rate of discovery to current model capabilities. It is the product of other elasticities and dependent on other inputs, and may change over time. This makes tracking up-to-date metrics for these values important. ### Conclusion The future may look very different depending on how the speed of AI progress changes. To better predict where we are headed, it is important to understand this progress. Early work has provided economic models for measuring recursive self-improvement. However, there are many questions related to the pace of progress that are still difficult to answer. In these cases, metrics and models can provide important information that helps calibrate responses. We are interested in work that pushes the frontier on modeling recursive self-improvement, and hope that our game and simulator make recursive self-improvement dynamics more intuitive. Please reach out to [jw@paradigm.xyz](mailto:jw@paradigm.xyz) and [dan@paradigm.xyz](mailto:dan@paradigm.xyz) if you are working on similar topics! *Thank you to Tom Cunningham, Basil Halperin, Nate Rush, Will Robinson, Kevin Liu, Chris Tonetti, Hart Lambur, transmissions11, and Dave White for feedback.* ## https://www.paradigm.xyz/writing/centaur-2-0-permissions-context-and-mcp # Centaur 2.0: Permissions, Context, and MCP > We’re launching Centaur 2.0 with better permissions, broader tool access, and a faster, more reliable foundation. AI models change quickly, but a company’s tools, data, permissions, and shared history shouldn’t have to change with them. To address that, today we're announcing Centaur 2.0, giving every agent the same permissioned access to a company's tools and context, wherever people choose to work. Centaur 2.0 introduces: - Company-wide context archival, so that your Centaur can quickly search across all configured data sources including Gmail, Granola, Slack and more. - Granular permissions, so that you can configure who has access to what resources, allowing you to give Centaur access to sensitive data without worrying about unauthorized access from its users. - MCP, so that you can query Centaur from your local agent, whether it is Amp, Claude Code, Codex, or your custom harness. Two months ago, [we open-sourced Centaur](https://www.paradigm.xyz/writing/open-sourcing-centaur-multiplayer-self-hosted-secure-agents), our self-hosted runtime for secure, multiplayer agents. We believed agents would become shared infrastructure: present where decisions happen, equipped with a team's tools, and able to build context across an organization. That thesis is playing out. More than 80% of Centaur sessions now happen in shared channels rather than DMs, and questions that once meant digging through years of messages, notes, emails, and databases get answered in minutes. Putting an agent in a shared channel was the easy part. But making it useful inside a real organization requires access to sensitive systems, an understanding of company context, and the ability to carry those capabilities across models and interfaces. 2.0 ships the permissions and MCP support today, on a smaller, more reliable Rust core. # Permissions that follow the conversation The previous version of Centaur assumed one organization-wide set of credentials. Companies don't work that way. Teams have shared systems, and access changes depending on where a conversation happens. Centaur 2.0 derives access from the context in which it's invoked. A DM can use a person's connected accounts; a shared channel gets only the credentials and data sources granted to that team. Each sandbox receives its own identity, and grants are enforced at the network boundary without ever exposing credentials to the agent. You can now connect systems that would be unsafe to place behind a single organization-wide credential. We use this ourselves: in a DM, Centaur can query your personal Granola notes and email; tagged into a channel, the same agent switches to the documents shared with that team. An engineer never sees a partner's meeting notes. The same rules apply to workflows, which receive only the access appropriate to their context. # Use Centaur’s tools anywhere Switching models or clients shouldn't mean leaving your tools, permissions, and context behind. MCP support ships today. You can use Centaur's tools and context from Claude, ChatGPT, or any other MCP client, under the same identities and grants used inside Centaur. We can ask Claude about a portfolio company, and it will pull the same meeting notes and documents Centaur would surface in Slack. MCP support also lays the groundwork for cross-client handoff, which should ship in the coming weeks. Start a task in Claude, send it to Centaur, then close your laptop while the work continues. Long-running tasks will no longer depend on one device or client, and you can resume them without losing context or progress. The same principle applies to Centaur itself. Claude Code, Amp, Codex, and nanocodex all run behind one harness interface. Slack remains Centaur's primary multiplayer interface, but teams have also contributed integrations for Linear, GitHub, Discord, and Microsoft Teams. We're also building a richer web console for persistent workspaces, files, traces, approvals, and long-running executions that don't fit inside a chat thread. These are different ways to inspect and steer the same underlying work, not separate products with separate context and permission models. # Organizational context that compounds The next step is helping agents understand not only what is stored in company systems, but how it all fits together. We've shipped permission-aware organizational memory internally. Centaur can retain prior decisions, relationships, and projects while respecting the boundaries between a person, a channel, a team, and the company. We'll open-source it once we're confident in its guarantees and retrieval quality. Longer term, we want to index the entire company under the same permission model. Workflows will ingest context from wherever work lives, while classifiers categorize what comes in, extract metadata, and connect related artifacts. At Paradigm, that can mean recognizing a meeting as a new investment opportunity or a portfolio catch-up, extracting the company's stage, and linking the note to its data room and any prior conversations. Every organization will classify its work differently; what's common is the infrastructure that turns scattered artifacts into connected context and makes it available to agents without bypassing the permissions of the underlying systems. Centaur already indexes Slack, Granola, Google Drive, Google Calendar, Linear, and Attio, with more integrations on the way. # A smaller Rust control plane Building these capabilities exposed a problem. Centaur's original API had accumulated everything from sandbox management to Slack rendering, and each new feature added more ways to fail. We rewrote it in Rust as `api-rs`, a control plane that exposes only four operations: create or reuse a session, append a message, execute a turn, and stream events. The rewrite matters practically: Fewer responsibilities mean fewer failures, and a simpler API means we can more rapidly develop new integrations. Since the 2.0 rollout, over 99% of daily Centaur sessions complete successfully. # Get started Models will change quickly. A company's tools, data, permissions, and shared history shouldn't have to change with them. Centaur 2.0 is available today at [github.com/paradigmxyz/centaur](https://github.com/paradigmxyz/centaur). If you're new to Centaur, the quickest path is [centaur.run](https://centaur.run); if you're upgrading from 1.0, start with the [migration guide](https://github.com/paradigmxyz/centaur/blob/main/contrib/MIGRATING_TO_RS.md). # Come build with us We're hiring engineers to work on Centaur full-time: - [Infrastructure Engineer, Applied AI](https://jobs.ashbyhq.com/Paradigm/c18c1fb4-9ad7-4657-8366-bc0f5078d3ca) - [Product Engineer, Applied AI](https://jobs.ashbyhq.com/Paradigm/b85b9094-2467-4f49-9a36-ca93da34a3f5) The work spans distributed systems, agent runtimes, security, developer tools, and product. Apply through the postings above, or if you'd be an asset to the team in a role that isn't listed, email [mslipper@paradigm.xyz](mailto:mslipper@paradigm.xyz). ## https://www.paradigm.xyz/writing/joining-paradigm-justin-wang # Joining Paradigm > Justin Wang joins Paradigm as a Research Partner I’m thrilled to share that I’ve joined Paradigm as a Research Partner. My respect for Paradigm dates back to when I was in high school – logging onto Twitter and seeing this small, legendary team consistently put out impactful open source code and research that shaped the frontier of technology. When I started working on [EVMbench](https://openai.com/index/introducing-evmbench/) at OpenAI, years later, it was Paradigm’s open source tooling – [Forge, Cast, and Anvil](https://github.com/foundry-rs/foundry) – that I used as a foundation. And when we needed more domain-specific expertise, Paradigm was the obvious partner. This past year, working closely with [Alpin](https://www.paradigm.xyz/team/alpin-yukseloglu) on EVMbench and spending time with the rest of the team, I’ve been able to experience more of the magic that drives this organization. Paradigm’s technical depth, long-term orientation, and commitment to open source work that benefits the public – under the leadership of Matt and Alana – made it an easy decision for me to join. I’ll initially be focusing on the measurement and evaluation of AI models. In the near term, I’m particularly interested in understanding recursive self-improvement, metrics that can inform better policy decisions, and powerful cybersecurity and crypto capabilities. In general, I’m interested in frontier research that can help put humanity on a path to a better future. If you want to collaborate, I’d love to hear from you. You can reach me at [jw@paradigm.xyz](mailto:jw@paradigm.xyz) or on [X](https://x.com/justinwangx). *Thank you to the people who believed in me early. In particular, thanks to Eric Joraskie, Jaclyn Chan, and Andy Zou. And thanks to my friends and family as well, for supporting me. You have given me a lot to pay forward.* ## https://www.paradigm.xyz/writing/paradigm-files-comment-letter-on-binary-kpi-options-proposal # Paradigm Files Comment Letter on Binary KPI Options Proposal > Paradigm urges SEC to complete holistic review process with CFTC before making decision on binary KPI options proposal Today, Paradigm filed a comment letter with the SEC regarding a proposal to list binary options on company-reported performance metrics. These are contracts that pay a fixed dollar amount based on a company's reported numbers (for example, quarterly revenue or production figures), and there's an open question about whether they should be regulated as options on securities by the SEC or as event contracts by the CFTC. In June, the SEC and CFTC [jointly](https://www.sec.gov/newsroom/press-releases/2026-57-sec-cftc-seek-public-comment-further-clarify-harmonize-derivatives-product-definitions) asked the public how to draw clearer regulatory lines for innovative products that touch both agencies' markets, including the very question this proposal presents: how to classify event contracts that reference public company performance metrics. Our letter asks the SEC to let that joint process actually finish before deciding on this proposal, using the generous review schedule Congress built into the Exchange Act for exactly this kind of situation. It’s imperative that the agencies get this right. A foot fault on process will lead to questions about this decision’s durability, and could trigger an unnecessary and lengthy second rulemaking process or litigation because one regulator started running before the starting gun sounded. But there is something deeper at play too: the Commissions’ joint process is evidence of how multiple agencies can work together to tackle a complex regulatory process. Lines drawn jointly, on a broad public record, tend to be principled and durable; lines drawn piecemeal tend to be relitigated forever. We look forward to submitting a substantive response on these definitional questions in our comments on the joint request later this month, and thank the SEC and CFTC for engaging in this thoughtful and timely process. In the interim, you can read our letter to the SEC [here](https://assets.ctfassets.net/vb2n37v5ldjn/1DHywygP0fH5YnIQqW0Gq0/c1a32ca7b9567969da41becdc7a67fe9/Paradigm_Comment_Letter_on_Cboe_Proposal.pdf). ## https://www.paradigm.xyz/writing/paradigm-files-comment-letter-on-the-cftc-s-prediction-markets-nprm # Paradigm Files Comment Letter on the CFTC’s Prediction Markets NPRM > Paradigm supports gaming framework; encourages additional clarifications Today, Paradigm filed a comment letter with the Commodity Futures Trading Commission on its Notice of Proposed Rulemaking regarding prediction markets, which represents the agency’s most significant proposal for prediction market regulatory clarity. Simply put, this is the broad regulatory proposal many of us have been waiting for and calling for. Happily, the NPRM gets the big calls right. It adopts a plain-meaning definition of “gaming” that encompasses sports-related contracts. It builds a genuine multi-factor public interest inquiry instead of categorical bans. And it puts the burden on the Commission to affirmatively show a contract is contrary to the public interest rather than on exchanges to prove a negative. Our letter encourages the Commission to keep charging forward in those directions, but we also flag a few places where the Commission needs to tread carefully. Our letter focuses on three areas: - First, on the definition of “gaming,” we support the Commission’s ordinary-meaning approach. Words matter and, when possible, the best move for regulators is to simply rely on the plain meaning of words instead of engaging in bespoke contortions to reach a desired result. To that end, the Commission is smart to reject the alternative, more philosophical test floated in the NPRM, which would be a recipe for inconsistent results and regulatory fog for market participants and users. We do ask the Commission to sharpen the line between “gaming” events and nongaming “contests,” since the current examples (a Cy Young Award is a contest; most strikeouts in a season is gaming) arguably drive in different directions. - Second, on the public interest inquiry, we support the Commission’s multifactor approach and its recognition that gaming contracts are not presumptively contrary to the public interest. As we note in the comment, this is a position squarely entrenched within the powers granted to the Commission by Congress: it is the CFTC’s call on when something is or is not in the public interest under the Commodity Exchange Act. But there are a few deft moves the CFTC can make here. The Commission should more firmly enunciate that it lacks authority under the CEA to force a prediction market to halt trading while a review is pending. Additionally, the CFTC should explicitly state that sports leagues’ input on whether contracts are in the public interest is important but not binding. The CEA does not give any stakeholders, be it sports leagues, investors, tribes, former regulators, or individual senior members of Congress, a veto on the CFTC’s public interest determinations. That power remains exclusively in the hands of the CFTC. - Third, on exemptive authority, we urge the Commission to exempt well-understood categories of event contracts, like season-long aggregate-outcome contracts, from requiring individual re-review. There is no need to make well-worn contract types all run the individualized review gauntlet every time like some parody of professional sports training camps. We instead suggest a simple, evidence-based way to grow that list: once a contract design clears review without being prohibited, it should be treated as cleared going forward rather than re-litigated contract by contract. Prediction markets work because they are markets: they aggregate information, they let people hedge real risk, and their prices tend to beat expert forecasts. A rule that gives exchanges a predictable, workable standard for which event contracts can list is good for the industry and good for the public that relies on the information these markets produce. We appreciate the Commission’s continued engagement on these issues and look forward to a final rule that builds on the NPRM’s foundation. You can read Paradigm’s full comment letter [here](https://assets.ctfassets.net/vb2n37v5ldjn/45EFMN74Vupgqn7roNNGFZ/1d9335ed8887732b0f107ed1fe470839/CFTC_Prediction_Market_Comment__07.27_.pdf). ## https://www.paradigm.xyz/writing/solidus # Formally Verifying a Compiler Using Automated Research > We formally verified a compiler using Lean and are launching two new challenges to improve it, as an experiment in collaborative research. Agents can do extraordinary things through automated research loops. Communities of automated researchers can achieve even more through competitions, like the ones we host on [Paradigm Puzzles](https://www.paradigm.xyz/puzzles). But how do we know that what they produce is correct? Formal verification with languages like [Lean](https://lean-lang.org/) turns out to be beautifully complementary to automated research. It can prove that an agent’s output correctly solved a presented problem, or that an optimized program preserves properties of an unoptimized one. While these proofs are incredibly tedious to construct, the solution is the same as the problem: automated research. You can automate the creation of Lean proofs using AI, thanks to increasingly capable models like GPT-5.6 and Claude Fable 5 and specialized tools like [Aristotle](https://aristotle.harmonic.fun/). And they allow collaboration by untrusted contributors, since contributions can be proven correct. We’re introducing [Solidus](https://github.com/paradigmxyz/solidus): a collaborative automated research project to build a formally verified [Solidity](https://www.soliditylang.org/) compiler in Lean. We are kicking off this project with two new optimization puzzles: one to pin down a frozen source semantics of the Solidity language, and the other to optimize the already-proven backend of the compiler (while preserving the proof). The Solidus project already includes a full formally verified backend that compiles from Yul (the intermediate representation used by the Solidity compiler) to EVM, as well as a new proposed formal semantics for Solidity. We plan to use automated research to finalize the Solidity semantics, build the frontend of the compiler, and optimize the implementation to make it not only the most secure Solidity compiler, but also the most efficient. Solidus has already been a major automated research undertaking. It took **over 1,700 hours (~10 weeks)** of total [Codex](https://chatgpt.com/codex/) /goal time, with extra-high effort, in fast mode (~$150,000 at API rates). But we think that is nothing compared to the improvements that could come from opening it up to public contribution. This is a pre-alpha project. The code has not been audited and is not production-ready. And it will likely be possible for submissions to take advantage of subtle gaps in the formal verification to game the score or introduce undetected problems. But we hope that these challenges can pressure-test some of those gaps, and help pave the way for even more ambitious projects in the future. ## Why Formally Verify a Compiler? Compilers are an essential part of the modern computing toolchain, but they are complex and open-ended pieces of software that are very difficult to test exhaustively. Formal verification of compilers protects against compiler bugs, like the one that led to a [$50+ million smart contract hack in July 2023](https://www.halborn.com/blog/post/explained-the-vyper-bug-hack-july-2023). It also makes formal verification of individual programs easier, since it lets developers prove statements about a high-level structured language, rather than low-level bytecode. But perhaps most importantly, it allows us to fully set automated research loose on improving trusted codebases like compilers. It can enable more collaboration on secure codebases, since contributions can come with a certificate that they satisfy the properties required. It also allows extremely aggressive, trustless *optimization* of the compiler. Lean-based projects can potentially be automatically optimized much more aggressively than normal projects. ## What Is Solidus? Solidus is a planned compiler from Solidity (the most popular smart contract language) to the EVM, implemented in Lean. - Lean is a language and proof assistant for formal verification. While it is best known for its application to math, it is also a powerful and increasingly popular language for formal verification of computer programs. We implemented our compiler itself in Lean, to make it even more amenable to formal verification. - Solidity is the most popular smart contract language, and the EVM (Ethereum Virtual Machine) is the most popular blockchain virtual machine (used by chains like Ethereum, Tempo, and Monad). The backend of Solidus (a compiler from Solidity’s intermediate representation, [Yul](https://docs.soliditylang.org/en/latest/yul.html), to the EVM) is built and formally verified. We use a [slightly modified fork](https://github.com/paradigmxyz/evmyullean) of the [Yul and EVM semantics](https://github.com/NethermindEth/EVMYulLean) created by Nethermind, and prove that every program produced by our compiler has identical outputs for all inputs as the Yul program given to it (other than EVM-specific details like gas and memory layout). Our semantics only model the state of the individual contract being compiled, but the compiler fully supports external calls—the proof is parametric over all possible external worlds, as long as they are deterministic. (This backend is similar to the [yul-compiler](https://powdr.org/blog/yul-compiler) project released recently by the Powdr team.) The frontend for the compiler (from Solidity to Yul) is not yet built, in part because no formal semantics for Solidity exists. To begin to rectify that, we built a [formal semantics for Solidity](https://github.com/paradigmxyz/solidity-lean/) to act as a source language for the compiler. This semantics likely still has some gaps, and one of the goals of the [Solidus challenges](https://www.paradigm.xyz/puzzles/spec-hunt) is to find those gaps and harden it. ## How We Built Solidus Solidus was only possible because LLMs are now strong enough to take on extremely heavy research and engineering projects. The star contributor was GPT-5.6 and Codex, but we also made significant use of Harmonic’s [Aristotle](https://aristotle.harmonic.fun/) for some of the most complex proofs, and used Claude Fable 5 for some of the final steps. No human read or wrote a single line of code for Solidus, but it was still nowhere close to a fully automated effort. We don’t think agents are good enough yet to solve this kind of task with a single /goal loop, although we suspect they will be good enough soon—probably by the end of the year. One reason is that the spec for the compiler had to evolve as part of the proving process; until we were deep into the proving process, it wasn’t clear exactly what statement we could or would be proving about the compiler. This required some human judgment about which spec edits were acceptable, and which would violate the spirit of the compiler. Outsourcing such judgment to agents tends to result in drift or reward-hacking. Another reason is that some human creativity was required for some of the higher-level architecture of the proof. For example, agents burned days attempting to prove that the source and target programs would be equivalent in all possible states that a concrete external world could have, before we suggested pivoting to prove the claim (much *stronger*, but ironically, easier to prove) that they would be equivalent regardless of how the external world worked, as long as the same external call by each program returned the same result. We’ve [open-sourced the Codex skill](https://github.com/paradigmxyz/solidus/blob/main/skills/verifiable-compiler/SKILL.md) we used to build the compiler backend. ## The Solidus Challenges We think that challenges are an ideal way to organize collective autoresearch projects like these. We created two challenges to start: [Spec Hunt](https://www.paradigm.xyz/puzzles/spec-hunt): One tricky problem in formal verification is ensuring that the proven spec for the problem actually matches the desired behavior. Solidity is a complex language, with no formal specification other than the solc compiler. We wrote [solidity-lean](https://github.com/paradigmxyz/solidity-lean) as an attempted formal semantics of Solidity 0.8.35, but we expect there are still many undetected divergences in it. This challenge allows users to score points by finding these divergences and submitting a proof-of-concept for them. These divergences are automatically tested using [Foundry](https://www.getfoundry.sh/), and then reviewed by an AI agent, which fixes it by merging a change to the solidity-lean repo (or escalating to human review if needed). [Compiler Optimization](https://www.paradigm.xyz/puzzles/verified-compiler): Another problem with formally verified codebases produced by agents is that, by default, they might be less efficient than ordinary codebases. On our test suite, our Yul-to-EVM compiler currently produces programs with almost 3x as much bytecode as solc. But automated research excels at optimization, particularly when correctness is verifiable. We created a challenge to optimize the Yul-to-EVM backend of the Solidus compiler. Submissions have to improve on the performance of the existing compiler, *while proving the same theorem about its correctness*. (Note that the current compiler only guarantees soundness; completeness and performance are currently verified heuristically with a holdout test suite.) We hope these challenges will help advance the Solidus project, and also serve as a prototype for other productive automated research projects in the future! ## https://www.paradigm.xyz/writing/paradigm-files-comment-letter-on-the-ncuas-genius-act-stablecoin-rulemaking # Paradigm Files Comment Letter on the NCUA’s GENIUS Act Stablecoin Rulemaking > Paradigm raises key issues for credit union-affiliated stablecoin issuers Today, Paradigm filed a comment letter with the National Credit Union Administration in response to the agency’s proposed rule implementing the GENIUS Act for stablecoin issuers. We support much of the proposed framework, but our letter also flags several areas where the proposal, as drafted, would impose unnecessary burdens on early-stage issuers, introduce legal uncertainty at odds with the Act’s text, and leave credit unions’ unique share-account structure without adequate protection. Several of our concerns track what we’ve already raised with the OCC and the FDIC. We urge NCUA to decline to extend the GENIUS Act’s yield prohibition to related third parties or indirect arrangements, to preserve issuers’ ability to operate more than one stablecoin brand, and to adopt a monthly cadence tethered to defined reporting categories. We also support the NCUA’s proposal to read the exclusion of deposits from the definition of payment stablecoin to reach tokenized shares, so that a credit union’s tokenized share account isn’t swept into the payment-stablecoin regime merely because it lives on a ledger. We think that’s the right reading based on the pure text of the Act, and we urge NCUA to remove any doubt by codifying that equivalence directly in the final rule. Clarity is not just a word for market structure; it must also be a guiding star in how the government structures all regulations. That same technology-neutral principle should carry over to how NCUA treats reserves. We were glad to see NCUA propose that share insurance remain technology-neutral, and the same concept should apply to reserves. A reserve asset’s risk depends on the asset itself, not the ledger it happens to sit on. We therefore asked NCUA to extend that recognition to every eligible reserve category and to avoid imposing a quantitative cap on tokenized reserves, which would restrict issuers’ choices for reasons unrelated to actual risk. You can read Paradigm’s full comment letter [here](https://assets.ctfassets.net/vb2n37v5ldjn/5yc6kTMgN3KLgNpgMtSS0M/1b12b15e6d967e20eeb7fe9d75af4548/Paradigm_Operations_LP_-_Comment_Letter_-_RIN_3133-AG10.pdf). ## https://www.paradigm.xyz/writing/paradigm-backs-michael-lewellen-on-appeal-to-the-fifth-circuit # Paradigm Backs Michael Lewellen on Appeal to the Fifth Circuit > Paradigm pushes back on threats to non-custodial software developers Paradigm filed an amicus brief with the Fifth Circuit in *Lewellen v. Blanche*, urging the court to reverse a decision that let the government dodge judicial review of its overaggressive use of money transmission laws against non-custodial software developers under 18 U.S.C. § 1960. This is our second time weighing in on this case, but the facts and our argument are unchanged: DOJ’s overreach is a threat to all non-custodial software developers. Last summer, we [opposed](https://www.paradigm.xyz/writing/paradigm-files-amicus-in-lewellen-v-bondi) the government’s motion to dismiss Michael Lewellen’s suit, which challenges DOJ’s theory that publishing non-custodial software can make a developer an unlicensed “money transmitter.” Our current brief makes two points. First, a non-binding policy memo that DOJ can revoke (or ignore) at any time doesn’t erase the risk created by a legal theory the government is still actively pursuing, as DOJ’s continued prosecution of developers—including its push for a retrial after a hung jury in the Storm case—makes clear. Second, publishing code is speech, and Lewellen doesn’t have to wait to be indicted before challenging a rule that discourages him from publishing his software. Courts have long held that a credible threat of prosecution is itself an injury, especially where, as here, the government has already prosecuted the exact conduct at issue. The stakes in this case go beyond one plaintiff. If developers can find out whether their code is legal only by risking a felony prosecution, the rule of law has failed them. And the effects are already visible: Developers are shelving projects, moving overseas, or blocking U.S. users altogether rather than risk the same fate as the developers DOJ continues to attack. Our brief is available [here](https://assets.ctfassets.net/vb2n37v5ldjn/1SRzBq5uIEprS1YMiVGKsk/27fd0d2146cdec7f6d4666b7bc2328a0/Lewellen_-_Amicus_Brief__2026.07.08__file-stamped.pdf). ## https://www.paradigm.xyz/writing/announcing-our-fourth-fund # Announcing Our Fourth Fund > Paradigm has raised our fourth fund: $1.2B to back the most ambitious builders at the frontier of technology. Paradigm has raised our fourth fund: $1.2B to back the most ambitious builders at the frontier of technology. We started Paradigm in 2018 with a simple belief: to invest at the frontier, you have to live on it. Our approach is to stay close to the metal – researching, building, and investing alongside founders, first in crypto, and now across AI, robotics, and other frontiers. We back founders at every stage, including in teams pushing the bounds of autonomous drone delivery (Zipline), reimagining rapid manufacturing (SendCutSend), advancing orbital space defense (True Anomaly), and keeping AI open (Nous Research, makers of Hermes Agent). We continue investing in crypto and the reinvention of markets and the financial system, for example, in Hyperliquid, where an open ecosystem of builders like Trade\[XYZ\] enables new financial products; in Tempo, an incubation we co-founded with Stripe that’s building a stablecoin and agent-friendly blockchain; and in Kalshi, as they build the leading prediction markets exchange. We'll continue to research and build where it accelerates the industry, from blockchain tools (Foundry, Reth) to agent tools (Centaur) to security work (EVMbench, a collaboration with OpenAI). Sufficiently steep exponentials are indistinguishable from magic, and we see more global scale exponentials at work than ever before. This era favors those open-minded enough to throw out existing playbooks and recompute new views of reality frequently. It’s a mindset we share with the founders we back.   If you’re building something ambitious at the frontier, come build with us. [Paradigm's Fourth Fund](https://youtu.be/ExcFrzsQln0?si=U2zOr6Dkf-u6GDXo) ## https://www.paradigm.xyz/writing/paradigm-backs-kalshi-in-latest-prediction-market-challenge # Paradigm Backs Kalshi in Latest Prediction Market Challenge > Paradigm files Sixth Circuit amicus brief against Tennessee overreach Today, Paradigm filed an amicus brief with the Sixth Circuit in *KalshiEX LLC v. Orgel*, urging the court to reject Tennessee’s attempt to regulate Kalshi’s federally licensed exchange. Tennessee is the latest state to claim authority over prediction markets but, as we make clear in our brief, it runs headlong into the same reality as those who came before it: a decades-long trail of evidence that Congress expressly designed the Commodity Exchange Act to prevent state-by-state regulation of these national exchanges. The pattern here will be familiar to anyone who has followed this litigation. Tennessee argues that Kalshi’s sports-event contracts are gambling, not federally regulated derivatives, and that its sports wagering law can therefore shut Kalshi out of the state. The trial court disagreed, and Tennessee has now appealed to the Sixth Circuit. Much like Tennessee’s modern-day complaints about sports contracts, states have been arguing for more than a century that commodity trading amounts to nothing more than “gambling in grain.” That argument was wrong then, and it is wrong now. The text of the CEA, backed by a detailed and one-sided legislative record, makes clear that Congress recognized the value of these markets and that it intentionally gave the CFTC exclusive jurisdiction over them. The Third Circuit confirmed as much when it became the first (and only) federal appeals court to address this question earlier this year, and the Sixth Circuit should reach the same result. And while each case puts a new twist on the arguments, the same statutory text, legislative history, and agency record continues to support preemption. Here, Tennessee argues that Kalshi’s contracts depend on a sports “outcome,” not an “occurrence,” and that reading federal law to cover those contracts makes other provisions of the statute meaningless. But as our brief makes clear, Congress deliberately wrote those provisions broadly to prevent exactly this type of state interference, and treating them otherwise gets the law exactly backwards. Just as we did in New Jersey, Maryland, Nevada, California, and Massachusetts, we’ll keep fighting (and filing) to defend prediction markets from state actors who see political advantage in targeting these federally regulated exchanges. Our brief is available [**here**](https://assets.ctfassets.net/vb2n37v5ldjn/1abZMdaNk0DjkzbGHq9OS0/a7edec18ce10dbfb53eeef888c25b5ff/Paradigm_Amicus_Brief_-_Kalshi_v._Orgel__No._26-5235___2026.06.24_.pdf). ## https://www.paradigm.xyz/writing/kryptos # Project Kryptos > Paradigm is now the steward of the solution to Kryptos, one of the last great cryptography puzzles — but it's a secret, even to us. Now we’re looking for more people to try to find the solution. Kryptos is one of the most famous cryptographic mysteries of our time. Since its unveiling at CIA headquarters in 1990, [Jim Sanborn's sculpture](https://en.wikipedia.org/wiki/Kryptos) has taunted the world's best codebreakers and puzzle enthusiasts. The NSA solved three of the four passages of its encrypted message. So did Jim Gillogly, a California cryptographer, working alone in 1999. But the fourth passage, K4, has remained unsolved for more than three decades. When Jim put his private Kryptos archive up for [auction](https://www.google.com/url?q=https://www.nytimes.com/2025/08/14/science/kryptos-sculpture-cia-solution-auction.html&sa=D&source=docs&ust=1781277322618044&usg=AOvVaw0mT5PzMugdQXppujreumD9) in November of last year, we knew we wanted to play a part in protecting this unique piece of cryptographic history. We’re honored to announce that we are the new stewards of the Kryptos secret. And in keeping with our love of puzzles, we decided not to ruin the mystery even for ourselves: We worked with Jim and used modern cryptography to set up an automated system to verify submissions without us ever seeing the answer. We also want to encourage the development of more sophisticated techniques for solving the puzzle. So, in addition to unveiling [a new site for K4](https://paradigm.xyz/kryptos/), we’re hosting an ongoing [capture-the-flag-style challenge](https://paradigm.xyz/kryptos-ctf/) featuring 10 new puzzles we created, each with a $1,000 prize. [YouTube](https://www.youtube.com/watch?v=EqXjS2l53QE) ## Securing Kryptos from everyone — even ourselves Cryptography makes digital trust possible. It's why you can send a message only one person can read, and why digital money works without banks. It's also puzzle-solving at its purest. For Kryptos, we’re keeping K4’s answer secret from ourselves, while preserving our ability to verify if submissions are correct. We used one-way cryptographic functions and secure hardware to lock Jim's answer in a system that confirms correct solutions without anyone (including us) ever seeing what he wrote. You can see the answers to K1, K2 and K3 on our new site, and when you think you've solved K4, you can submit your answer there as well. The verifier checks it against a solution that Sanborn provided. To prevent brute forcing the solution, there’s a $1 fee to submit an answer. Sanborn also provided the ciphertext for another 97-character puzzle, known as K5, that he created at the same time. We plan to release K5 in the future. Kryptos has endured for more than 13,000 days. Thousands have tried to crack it. CIA employees walk past it every day. It's been featured in novels, analyzed in academic papers, and debated in forums worldwide. But it's still unsolved. The clues are out there. The tools are better than ever. And now there's an automated system that verifies your solution instantly. It’s your turn to try to solve K4. ## Q&A ### What is the capture-the-flag challenge? We want to encourage the development of tools to better attack problems like K4. There has been an explosion in AI-assisted attempts on Kryptos, but none have succeeded yet. One possible reason is that there is no feedback loop that solvers can use to test if their tools are getting better at attacking these kinds of problems. Our virtual capture-the-flag challenge features 10 new Kryptos-style puzzles of increasing difficulty. Anyone can participate. The challenge is live now and there will be cash prizes of $1,000 for the first solver of each puzzle. The puzzles and leaderboard will remain open until the puzzles are solved. Official rules can be found [here](https://paradigm.xyz/kryptos-ctf/official-rules). ### How does your technical solution for K4 verification work? We set up a new computer with a terminal for Jim to enter the plaintext solution to K4. On that device, a program ran the plaintext through a one-way function (a SHA256 hash). It sent the hash to Google’s Cloud Key Management Service, which generated a unique verification tag (a hash-based message authentication code, or HMAC) that can only be reproduced by sending a SHA256 hash of the plaintext to the same cloud-based key. The plaintext never left the device, and we wiped the laptop afterward. ### What do I get if I solve K4? The answer. *Special acknowledgment to *[*Dave White*](https://x.com/_Dave__White_)* and *[*samczsun*](https://x.com/samczsun)* for their partnership and help throughout this project. * *Kryptos Gallery* ## https://www.paradigm.xyz/writing/paradigm-files-comment-letter-on-fincen-and-ofacs-genius-act-rulemaking # Paradigm Files Comment Letter on FinCEN and OFAC’s GENIUS Act Rulemaking > Paradigm urges tailored sanctions compliance framework Today, joined by the Hyperliquid Policy Center, Paradigm filed a comment letter in response to FinCEN and OFAC’s proposed anti-money laundering, counterterrorism, and sanctions framework for stablecoin issuers under the GENIUS Act. We support much of the framework, including FinCEN’s decision to draw a hard line between primary and secondary market obligations and to refrain from imposing mandatory SAR requirements on secondary market transfers. But our letter addresses several areas where the proposal, as drafted, creates legal uncertainty for protocol developers and imposes obligations beyond what the GENIUS Act permits. In particular, it is critical that FinCEN and OFAC not overly extend regulatory requirements to entities that do not themselves have control or custody of assets. That means that FinCEN’s decision not to require SARs on secondary market transfers correctly accommodates the realities of permissionless blockchains, and we strongly urge FinCEN not to revisit that decision. But it also means that FinCEN has a responsibility to reflect those realities in other contexts, including the “conducted through” safe harbor and the Travel Rule. It means FinCEN should confirm that smart-contract-based controls like programmable blacklists and transfer restrictions enforced at the token level satisfy the block/freeze/reject technical capability requirement, and not require that additional processes be unnecessarily and duplicatively added. It means FinCEN should clarify that lawful order compliance obligations run only to the PPSI and not to validators, chain operators, or other participants Congress expressly excluded from the GENIUS Act’s regulatory perimeter. Finally, and perhaps most importantly, it means OFAC should reconsider its position that merely developing a smart contract constitutes providing a service to every person who interacts with it on the secondary market, which conflicts both with FinCEN and court precedent, and would chill USD-denominated stablecoin deployment. Regulation of crypto to protect against misuse by criminals and terrorists is important, but we cannot place undue burdens on law-abiding developers, firms, and ordinary users out of excess caution or fear. To fail to protect people’s legal rights against encroachment by the government would go against the very ethos and raison d’etre of crypto, and we will always speak against and resist such efforts. You can read Paradigm and HPC’s full comment letter [here](https://assets.ctfassets.net/vb2n37v5ldjn/78gWkqijqzl7jFMDufpAKU/6b28ca4428aa72d512571d33fcd948b1/Paradigm_HPC_FinCEN_OFAC_Comment__06.09_.pdf). ## https://www.paradigm.xyz/writing/paradigm-files-comment-letter-on-the-fdics-genius-act-stablecoin-rulemaking # Paradigm Files Comment Letter on the FDIC’s GENIUS Act Stablecoin Rulemaking > Paradigm raises key issues on the FDIC’s framework for stablecoin issuers. Today, Paradigm filed a comment letter with the FDIC in response to the agency’s proposed rule for stablecoin issuers under the GENIUS Act. We support much of the proposed framework, including 1:1 reserve backing, monthly public reporting, and the authorization to offer custody and exchange. But we submitted a comment letter that addresses several areas where the proposal, as drafted, would impose unnecessary burdens on early-stage issuers, generate legal uncertainty that undermines the Act’s pro-competitive objectives, and fragment the stablecoin regulatory landscape: 1. Nothing in the GENIUS Act permits the FDIC to either prohibit third parties from paying yield or to create a rebuttable presumption that such payments violate the Act. On the contrary, the legislative record confirms Congress expressly rejected the very proposals that the FDIC now advances. The FDIC should withdraw these impermissible expansions of the Act or, at minimum, incorporate the same limits proposed by the OCC and NCUA and design an enforcement cure period that protects good-faith issuers from agency overreach. 2. The proposal requires issuers running multiple stablecoin brands to construct and maintain separate reserve pools, custodial accounts, internal controls, and supervisory infrastructure for each brand. This is unnecessarily duplicative and will increase fixed costs for early-stage issuers they cannot readily absorb. The FDIC should instead permit issuers to satisfy any per-brand identification requirement through subledgering. Doing so will align the FDIC’s rule with the OCC’s approach, ensuring both agencies are in compliance with the GENIUS Act’s interagency coordination directive. 3. The FDIC should recognize tokenized forms of eligible reserve assets. The OCC has already proposed to recognize such assets as acceptable, as required by the text of the GENIUS Act. The FDIC should follow suit. 4. The FDIC should reduce its proposed weekly supervisory reporting requirement to a monthly cadence and codify the reporting categories in the rule text itself. It is always better to have regular oversight requirements laid out in the rule itself rather than guidance that can be changed in the wink of a regulator’s eye without public notice and comment. 5. The FDIC should clarify the appropriate resolution authority for issuers organized as national trust banks. As drafted, neither the FDIC’s proposal nor the GENIUS Act make clear how a trust bank would be resolved if it failed, a gap that persists even on a close reading of both texts. Until this is clear, institutional counterparties and foreign regulators cannot answer basic questions about which insolvency regime governs a given issuer’s failure. The days and hours surrounding a wind-down of a trust are among the most fraught moments any financial entity will face. It is imperative that these moments of crisis not be exacerbated by lawyers and executives having to debate what the law requires them to do. You can read Paradigm’s full comment letter [here](https://assets.ctfassets.net/vb2n37v5ldjn/48KnFeEhIoUDOFzQFL0b1c/f76e5e0e7e77e98923fd6b25cad849fe/Paradigm_-_FDIC_Comment_Letter__06.09_.pdf). ## https://www.paradigm.xyz/writing/the-political-number-weve-been-missing # The Political Number We’ve Been Missing > Kalshi’s American Power Index (KPOW) finally provides an easy way to know in real time which way the wind is blowing in American politics. Since 1952, the[ University of Michigan Consumer Sentiment Index](https://www.sca.isr.umich.edu/) has been read like a talisman. Whether you’re familiar with it or not, that number shapes your life – businesses consider it in hiring at scale, and the Fed even watches it before setting rates. This week Kalshi released the v1 of a political equivalent, which could be useful in the future in similar ways. The [American Power Index (KPOW)](https://kalshi.com/indices/kpow) measures, on a scale from +50 Democratic to +50 Republican, how much political power each party holds right now and where the market thinks that power is headed. In short, just as a single market crystallizes conventional wisdom about one event into a percentage, a basket of markets can be compiled into a single composite number. It’s an interesting attempt to show one legible number tracking a complicated underlying reality. Like those indices and algorithms, the secret sauce of KPOW is how various markets are weighted as well as what other information is included in the index. Per Kalshi, the index weights the objective facts of the current government against forward-looking prediction market signals about future elections and adjusts for risks like a government shutdown that weaken a governing coalition’s effective power. It’s reweighted weekly. When shutdown odds spike on Kalshi, KPOW should drop for the GOP. When a midterms contract moves toward Democrats, that means the KPOW will too. Goldman Sachs, Bridgewater, and Point72 have entire teams of analysts who pore over numbers like this to divine trends and scratch out an edge. KPOW is the beginning of that sort of intelligence being available to small businesses too. In our view, the comparison to polling is what makes this type of tool interesting. Polling is the instrument we’ve relied on for decades to understand political reality, but it’s increasingly unreliable noise (response rates are low, pollsters keep weighting poorly, etc.). On the other hand, KPOW is based not on what people say they believe or how a pollster weighed a certain demographic, but instead on where they are willing to stake real money. Every student of politics remembers Truman versus Dewey. But polling failures are not ancient history. The polls grossly missed out on the Trump trend of 2016. In 2020, national polls had Biden ahead by an average of more than seven points, but his margin turned out to be about four and a half. Pollsters also missed the scale of Trump’s 2024 victory. And the problem is definitely not getting better; response rates for telephone polls have cratered from[ 36% in 1997](https://www.pewresearch.org/short-reads/2019/02/27/response-rates-in-telephone-surveys-have-resumed-their-decline/) to single digits today. The industry is working to respond to this through more panel-based polls and better modeling, but this has not been a panacea. Prediction markets don’t have this problem, because if the market price is wrong, someone can profit by correcting it, while no such incentive exists in a survey. As economists Justin Wolfers and Eric Zitzewitz [have written](http://aeaweb.org/articles?id=10.1257/0895330041371321), this matters enormously. But KPOW goes beyond any single election prediction. It answers the sprawling, messy question that no individual market can: which way is the wind blowing in American politics, right now, today? American politics is awash in populist sentiment. Last year,[ 80% of Americans](https://yougov.com/en-us/articles/53800-distrust-elites-experts-establishment-widespread-among-americans-december-26-29-2025-economist-yougov-poll) said that “political institutions have been captured by the rich and powerful,” and[ 75% said](https://yougov.com/en-us/articles/53800-distrust-elites-experts-establishment-widespread-among-americans-december-26-29-2025-economist-yougov-poll) “most important decisions in politics happen behind closed doors, without public accountability.” This distrust has metastasized despite the sea of data that now exists in politics, possibly because the existence of data alone is not what matters. What matters is that data is visible, accessible, and understandable by the many, not just the few. When something is poorly understood, the human default is to assume it’s rigged. A single understandable number is a civic primitive. By way of analogy, the stock index made markets legible to ordinary investors. The weather forecast made meteorology legible to anyone planning a picnic. Neither solved the underlying complexity, but they made it easy to understand. KPOW is an attempt to do the same for political power: to take the omnipresent, invisible force that shapes our lives and give everyone a shared, accessible measure of which way it’s moving. And this number is one that comes up from the people rather than down from elites. For decades, even centuries, news about politics has come from a few established gatekeepers in the press, wizened institutions like the New York Times, CBS, and the Times of London. While that information flow from top to bottom may have been a necessary function given logistical and technological constraints, that does not mean it was free of bias. The views and mores of elites were inherently laden within its reports on politics. By deriving its information from mass markets, KPOW reversed that flow. It lets ordinary people’s views actually ascend up the waterfall and influence even the views and actions of elites. KPOW is a battering ram against elite gatekeeping. While this may seem purely academic, it’s very practically usable. If you run a healthcare company watching whether the Affordable Care Act will be overturned by SCOTUS, a defense contractor guessing who will be in power, an energy sector employee waiting to see where the wind will blow on clean energy, a university student trying to anticipate federal funding decisions, or just a regular person, the balance of power in Washington actually does affect your daily life. We are swimming in political information but starving for political clarity. KPOW won’t solve that entirely. But one clean number, built on value rather than vibes, available to everyone rather than just the privileged few, is a heartening development. ## https://www.paradigm.xyz/writing/stablecoins-are-global-paradigms-response-to-fca-26-13 # Stablecoins are Global - Paradigm’s Response to FCA 26/13 > The FCA’s latest crypto perimeter guidance is intended to bring clarity to the U.K.’s digital asset regime. We explain how parts of the proposal could fragment global markets and how the FCA can avoid it. The U.K. has made it clear that they want to be a global hub for digital assets. HM Treasury, the Financial Conduct Authority (FCA), and the Bank of England have all begun developing rules to protect consumers without slowing down innovation in the sector. However, parts of the FCA’s latest consultation paper on cryptoasset perimeter guidance, CP 26/13, make it harder for global firms to operate in the U.K. **1. The guidance fragments global firms rather than bring them onshore. ** CP 26/13 removes the overseas persons exclusion for cryptoasset activities and broadens what must occur onshore in the U.K. As a result, global firms may need to create a separate infrastructure and establish local legal entities, even if U.K. activity is only a small portion of the firms' overall volume. Crypto markets require a globally integrated infrastructure to truly flourish, whereas this guidance suggests going against how crypto markets fundamentally operate. Far more crypto companies seeking to operate in the U.K. will be from abroad than local, contrary to this proposal's assumptions. The current proposal is a recipe for chaos and fragmentation, breaking the promise of global crypto markets. Fragmenting markets makes the U.K. a less competitive jurisdiction for global cryptoasset firms due to the eventual increases in costs and liquidity reduction. Under the new guidance, firms that are already regulated under similar regimes like MiCA or the GENIUS Act should be able to rely on those regulatory structures for U.K. perimeter purposes.  **2. The exemption for stablecoin settlement is too narrow.** HM Treasury provides an exemption for qualifying U.K.-issued stablecoins from the dealing and arranging perimeter. Unfortunately, this excludes all USD-pegged stablecoins that make up a majority of cross-border settlements since they are issued offshore. The exemption discourages the U.K. from participating in global liquidity pools and makes it much harder for the U.K. to become a global hub for cross-border cryptoasset activities. The guidance should be updated to reflect that overseas-issued stablecoins used for back-end settlement, should meet the exemption requirements for “dealing”. **3. The definition of “arranging” is too broad and could impact open-source software. ** CP 26/13 treats firms that provide only “part of the facilities” for a transaction as carrying on arranging activity. Inadvertently, non-custodial wallets, interfaces, APIs, white-label front ends, and other related software tools could be regulated despite the fact that they don’t hold customer assets nor control execution. This is akin to arguing that anyone who rides on a plane needs the training that pilots need for their license; it is overkill. This interpretation goes beyond what the Treasury’s statute clearly requires and risks creating a significant chilling effect on software development in the U.K., both for crypto and broader internet-native financial infrastructure. Providing access to a protocol in and of itself doesn’t constitute arranging activity. **What Comes Next** The U.K. still has a real opportunity to position itself as a gateway market for global crypto firms entering Europe. Most major crypto companies remain U.S.-incorporated, and initiatives like the U.K.-U.S. Transatlantic Taskforce for the Future of Markets can help build workable approaches to substitute compliance and mutual recognition ahead of the September authorization window. But the clock is ticking; the U.K. should act with alacrity to seize this moment and become the financial corridor for crypto between the new world and the old. Read our full response to the FCA[ here](https://assets.ctfassets.net/vb2n37v5ldjn/1uMxgyIVdGFws4Hlq03TUC/df0d331ec0b7c202d60681ea668c0ff2/Paradigm_-_Response_to_FCA_perimeter_guidance__CP26_13___Jun26___1_.pdf). ## https://www.paradigm.xyz/writing/paradigm-files-comment-letter-on-treasurys-genius-state-pathway-rulemaking # Paradigm Files Comment Letter on Treasury’s GENIUS State Pathway Rulemaking > Paradigm raises critical issues on pivotal stablecoin rulemaking Today, Paradigm filed a comment letter with the Department of the Treasury in response to the agency’s proposed rule regarding whether state stablecoin regimes are “substantially similar” to the federal regulatory framework under the GENIUS Act. Treasury’s rulemaking is, in many ways, the linchpin of the GENIUS Act’s dual federal-state design: without a workable certification pathway, the state regulatory pathway Congress created exists as a formal matter but operates as a dead letter. Treasury’s proposal offers a reasonable starting framework, and we support its core architecture. But there are four places where the proposal, left unchanged, would make the state pathway genuinely unavailable to the issuers it was designed to serve. - *First,* Treasury’s proposal anchors the federal framework to OCC regulations that are still proposed and unsettled. Asking states and issuers to plan against a baseline that has not yet been finalized is a direct impediment to market entry. Treasury should not finalize its rule before the OCC’s implementing regulations are final. - *Second*, under the rule, the heads of Treasury, the Fed, and the FDIC must unanimously agree to certify a state regime. But the proposed rule imposes no timeline for decisions, no standard for what a meaningful denial explanation looks like, and no mechanism to prevent a single SCRC member from blocking certification indefinitely. Our letter recommends a 180-day decision deadline, a defined cure-and-resubmission process for incomplete submissions, and particularized denial explanations specific enough to actually tell a state what it needs to fix. - *Third*, the rule proposes requiring state regimes to mandate a 12-month operating expense operational backstop. This is potentially exclusionary for the early-stage issuers the state pathway was specifically designed to serve. Our letter recommends that Treasury instead allow states to calibrate backstop requirements to issuer size and risk profile, consistent with the Act’s own tailoring mandate. - *Fourth,* we are concerned that the proposal does not adequately preempt hostile actions by individual states. A state regime that expands the yield prohibition or that inhibits state-to-state operations would put state issuers at a competitive disadvantage that Congress did not authorize and federalism does not allow. This loophole for state mischief must be closed. A quick note on our process: We used this comment letter and blog to test whether we could generate workable drafts of technical legal arguments with AI. Humans were in the loop at every step–identifying the points we wanted to make, prompting like you would a junior lawyer, and reviewing and iterating on drafts–but AI took the laboring oar in the first instance. The result? A competent base we could build on, and a model that could make commenting more accessible to the public at a fraction of the cost of a filing drafted by a law firm. It won’t be our approach to every comment, but as new technology moves the world in new directions, we (and the government) need to move with it. You can read Paradigm’s full comment letter [here](https://assets.ctfassets.net/vb2n37v5ldjn/1Mb1cVp85u757bHKJ7qVjN/b5d4f52142fc00187e23d7bbd1192c8b/Paradigm_-_Treasury_NPRM_Comment__06.02_.pdf). ## https://www.paradigm.xyz/writing/open-sourcing-centaur-multiplayer-self-hosted-secure-agents # Open Sourcing Centaur: Multiplayer, self-hosted, secure agents > Paradigm and Tempo open source Centaur, a Slack-native multiplayer, self-hosted and secure agent for investing, building, and researching. Today we’re open sourcing [Centaur](https://centaur.run), the self-hosted runtime from Paradigm and Tempo for multiplayer, secure AI agents. We have been using Centaur since January and it has transformed how we work across a wide spectrum of tasks including investing, engineering, design, recruiting, events, customer support and more. Centaur is a shared agent that can use tools, run for hours or days, survive restarts, and operate with real credentials without ever seeing the raw secrets. You can talk to it in Slack or over an API. You can add a tool once and every agent can use it. You can drop in a workflow once and the whole organization gets that capability immediately. At the end of every day, it reflects on how it did and self improves. Beyond open sourcing the [code](http://github.com/paradigmxyz/centaur), and template repositories for [extending](http://github.com/paradigmxyz/centaur-acme) and [operating](http://github.com/paradigmxyz/centaur-acme-infra) Centaur, we also deep dive on the architecture of the system, the interfaces between services, the security boundaries, and the execution model. Those are the pieces we think are worth copying, adapting, and reimplementing. Let’s dive in. # The problem with personal agents. Most agent stacks are still built for one user on one machine. The moment you try to make a collaborative workflow, a different set of requirements appear: - The agent has to continue working even after you close your laptop (we all know that person who walks around with an open laptop because their agent is still running). - It has to be reachable where collaboration happens, e.g. in Slack. - It has to survive crashes, deploys, disconnects, and partial failures. - It must be safe enough to trust it with real systems without handing it raw API keys. - It has to be observable and auditable for security review and optimization. Most systems solve parts of the above requirements. Some are good coding agents. Some are good browser agents. Some are good workflow engines. Few are designed as shared infrastructure for a team. And they all cost a lot, and lock you into a provider whose roadmap you’re downstream of. We think that organizations should be empowered to own their stack, move at the speed they need and use AI in collaborative not isolated settings. This is the gap Centaur is built for. # How do I use Centaur? Think of Centaur as a virtual employee. The Slack thread is the interface. You tag Centaur like you would any other employee, and Centaur replies. Depending on the task, Centaur will run for seconds, minutes or hours+, and will invoke a series of integrated [SKILL.md](http://skill.md)’s or tools. It knows which Slack thread it’s summoned in, and reliably replies on that relevant topic and ask, instead of assembling random context from all over your knowledge bases. Centaur out of the box can interact with spreadsheets, docs, slide decks, docsends, PDFs, and any other kind of file attachment you can think about. It can search Slack, the web, use Github, generate images and charts, create or update Google Docs, Slides and/or Sheets, interactive demos and more. The Centaur codebase is still relatively young and we continue to work through enhancements and improvements. But it really is incredible to experience, and we think it's transformed how our organization functions. We strongly recommend creating a company-wide #ai-agent Slack channel where you invite everyone to join. In that channel it’s important that: - Leaders of the firm use it, and lead by example. - People are empowered to ask questions without fear of looking dumb. - People that are more AI-fluent nudge other people in existing threads on “Here’s how you could’ve used AI to get unblocked”. # How does Centaur work? We tried to be thoughtful about two things, in particular, when designing Centaur: - **One Slack thread = one isolated agent session.** When you tag Centaur in a thread, the system assigns a dedicated sandbox container to that conversation. Inside the container, a full Linux environment runs the AI harness of your choice: Amp, Claude Code, Codex, or any CLI-based agent. The container has Node.js, Python, Rust, and git pre-installed, so the agent can git clone, cargo build, run tests, and write real code in a real environment. - **Every session has access to organization-wide tools and skills.** Agents love data, so if you give them connections and tools they’ll figure out how to do what you want them to do. A tool is a small Python class that wraps an API e.g. Slack, GitHub, Google Sheets. Drop the file in tools/, and every agent can call it immediately. Skills work the same way: a SKILL.md file that teaches the agent a workflow or set of instructions, available to every conversation the moment it's added. Under the hood, Centaur is a service-based architecture where all state lives in Postgres and every service is stateless. This means the system survives restarts, deploys, and crashes without losing work. Here’s how every component talks to each other: ![How it Works](https://images.ctfassets.net/vb2n37v5ldjn/4Quio5WuSJwslrr5dVx4co/fee1b0cf2241ec53df9024059a98936c/How_it_works.png) Here’s a deep dive of each of the services: 1. **Slackbot**: A thin Next.js webhook listener. When someone tags Centaur in Slack, the slackbot receives the event and calls the API's durable protocol: spawn a runtime, persist the message, and execute the turn. 2. **API**: The FastAPI control plane that orchestrates everything. It manages the lifecycle of agent sessions (spawn → message → execute), serves auto-generated REST endpoints for every tool plugin, runs the durable workflow engine, and streams execution events back to clients. The durable workflow engine is heavily inspired by [Absurd](https://github.com/earendil-works/absurd), more below. 3. **Postgres**: The single source of truth. Thread assignments, execution state, workflow checkpoints, API keys, audit logs, everything durable lives here. Because every service is stateless, you can restart any service without losing context. 4. **Sandbox**: Each conversation gets its own sandboxed container on an internal-only network. The agent runs inside this container and calls back to the API for tool access over REST. Containers can be resource-limited and host filesystems are mounted read-only. A warm pool of pre-spawned containers eliminates cold-start latency. 5. **Firewall**: An [iron-proxy](https://iron.sh) pod sits between each sandbox and the outside world. The agent or the user never holds real API keys. Instead, the proxy intercepts all egress traffic and, given the traffic doesn’t violate any firewall rules, injects the correct credentials in-flight, matched to the target host and source tool. A request using the Linear tool to api.linear.app gets the Linear key, while using gsuite injects the Google OAuth credentials. 6. **Observability**: Every service writes structured JSON logs to stdout. We empower users to choose their own observability stack and write tools for Centaur to discover its own metrics, logs and traces. By default, Centaur ships with tools for VictoriaLogs/VictoriaMetrics. ## Company specific overlays Extensibility is a first class citizen in Centaur - each company (including Tempo and Paradigm) uses different tools, stores data in different sources and has company-specific knowledge that can be distilled into skills. ![Centaur-components](https://images.ctfassets.net/vb2n37v5ldjn/6NGmKmuykl45PHiFDC8J6k/846601e9860029fcee71c15ceb70a8cc/Centaur-components.png) The framework supports “overlaying” - mounting a Docker image on top of the core Centaur services and providing the API/sandboxes access to tools, skills, and workflows specifically built for you. ## Shared Skills Skills are Markdown files (.agents/skills/\*/SKILL.md) that teach the agent how to perform a specific task, e.g. a recruiting pipeline, a compliance check, a QA workflow. Add a skill file, and every agent session inherits that knowledge. This is already well established in teams but instead of having skills passed around, you just add your skill to Centaur’s .agent/skills directory and your whole team gets access to it. ## Extensible Tools Tools are the simplest extension point. A tool is a Python class in a directory with a client.py and a pyproject.toml. The API auto-discovers it on startup, generates REST endpoints at /tools/{name}/{method}, and hot-reloads on file changes. Here’s an example of a tool: ```Python # tools/my-tool/client.py — this is the entire file import httpx class MyToolClient: def search(self, query: str, limit: int = 10) -> dict: """Search for something.""" return httpx.get(f"https://api.example.com/search?q={query}&limit={limit}").json() def _client(): return MyToolClient() ``` Drop that file in tools/my-tool/, and within seconds every agent conversation in your organization can call it. The tool declares which API hosts and secret keys it needs in its pyproject.toml so that the firewall can handle credential injection. ## Extensible Workflows A workflow is a single Python file that exports a name and a handler function. Drop it in workflows/, and it's available via cron, triggerable via API, or composable with other workflows. ```Python # workflows/daily_digest.py — drop this file in and it's live WORKFLOW_NAME = "daily_digest" async def handler(inp, ctx): data = await ctx.step("fetch", lambda: fetch_metrics()) await ctx.sleep("wait", timedelta(hours=24)) await ctx.run_agent("summarize", text=f"Summarize: {data}") ``` The workflow engine checkpoints every step to Postgres. If the process crashes mid-workflow, it resumes exactly where it left off, no duplicate work, no lost state. Sleeping for 24 hours between steps costs nothing; the workflow suspends and the engine wakes it up when it's time. For the observant reader, this is a Durable Workflow pattern that is increasing in popularity. This design was inspired by Absurd’s Postgres-driven architecture. # How secure is Centaur? Most agent frameworks handle secrets the same way you would on your laptop: dump API keys into environment variables and hope the agent doesn't leak them. This works for personal use. It doesn't work when you're handing an agent credentials to your company's Slack, GitHub, cloud infrastructure, and financial systems. Centaur takes a different approach: The agent never holds your secrets. Not in environment variables, not on disk, not in memory. Instead, credentials exist only inside an isolated secrets manager, and a network-level firewall injects them into outbound requests in-flight, after the request leaves the sandbox, before it hits the external API. Here's what that looks like concretely: 1. A tool declares in its pyproject.toml that it needs, say, SLACK_BOT_TOKEN and talks to [api.slack.com](http://api.slack.com). 2. On sandbox startup, the Iron proxy builds a mapping: api.slack.com to SLACK_BOT_TOKEN. 3. When the agent calls Slack, the request passes through the firewall. The firewall sees the target host, looks up the correct secret from your secrets manager, and injects it into the request header. 4. The agent sees a successful response, but never saw the token. This means a compromised agent or a prompt injection attack cannot exfiltrate your credentials. It can make authenticated requests through the proxy (it has to, that's how it works), but it cannot extract the raw key values, send them to a different host, or smuggle them out in a response. This security is enforced through network policies, such that no container can access: 1. The secret service directly 2. The web without first going through the firewall. This means that all secrets are protected, and every request on the way out and back in goes through the firewall. In addition to that, every outbound request from every sandbox is logged by the firewall and response bodies from LLM APIs are scanned for leaked secret values and redacted in real-time. This level of observability enables us to detect leaks and malfunctions quickly and fix them even quicker, letting Centaur be its own AI SRE. # What’s next for Centaur? Centaur's architecture deliberately separates a small, auditable core from a wide-open extension surface: - Kernel: The core (the API, the firewall, the secrets manager) - Userspace: Tools, workflows, and skills. This separation is what let us recently introduce self-improvement via nightly reflection: The agent reviews its own performance, identifies gaps, and ships fixes to its own skills and tools without touching the kernel. We can let the system evolve itself because the blast radius is structurally bounded. Today's release is the kernel we've been running in production at Paradigm and Tempo since January. Next up is making the userspace more powerful. We think workflows will evolve into full application containers, i.e. long-running services that leverage the rest of the system for tool access, secrets, and observability, but run their own logic. You can extend Centaur’s userspace with your own tools and workflows without having to fork the repository. See our docs here. Centaur is [open source](http://github.com/paradigmxyz/centaur) under Apache 2.0. It has transformed how we work, and we hope it does the same for you. Get started: [https://centaur.run](https://centaur.run). If you're a cracked AI engineer and want to help maintain and evolve Centaur in the open or work on Paradigm's proprietary AI tooling, reach out to [georgios@paradigm.xyz](mailto:georgios@paradigm.xyz). ## https://www.paradigm.xyz/writing/paradigm-files-comment-letter-on-the-occ-s-genius-rulemaking # Paradigm Files Comment Letter on the OCC’s GENIUS Rulemaking > Paradigm raises critical issues on pivotal stablecoin rulemaking Today, Paradigm filed a comment letter with the Office of the Comptroller of the Currency in response to the agency’s proposed rule implementing the GENIUS Act. The OCC has put forward a thorough proposal about how payment stablecoin issuers should be licensed, supervised, and structured. That kind of careful engagement with the rule-writing task deserves recognition. But there are real issues with this proposal that, if not addressed, would damage Congress’s design for stablecoins. Our biggest concern is the OCC’s treatment of the GENIUS Act’s yield provisions. The Act prohibits permitted payment stablecoin *issuers* from paying holders interest or yield *solely* in connection with the use or holding of a payment stablecoin. The OCC’s proposal stretches that narrow prohibition into a broad blanket that threatens to cover much of the industry. This expansion goes beyond what Congress authorized in two significant ways. - First, the proposed rule would apply the prohibition not just to issuers but to “related third parties” that are neither issuers nor under common ownership or control of an issuer. Congress drew this line deliberately: it knew how to capture indirect arrangements when it wanted to (and did so elsewhere in the Act), and its decision to limit the yield prohibition to issuers should not be overridden through rulemaking. - Second, the OCC’s proposed rebuttable presumption, under which certain arrangements involving affiliates or third parties are assumed to involve the paying of yield, departs from the statutory text without adequate justification. We urge the OCC to withdraw the extension to third parties and to substantially narrow and clarify the rebuttable presumption. After mooring the proposed rule to the statutory text, we also recommend that the Final Rule codify meaningful safe harbors for independently-initiated reward programs, flat non-yield-linked payments, and arrangements that merely consider stablecoin holding as one factor among several. All of these interactions are in keeping with the statute’s own “solely” qualifier, which was Congress’s direction. Finally, we propose that the Final Rule include procedural protections for issuers who structure their programs in good faith reliance on the OCC’s regulations and guidance, including a 90-day cure period before civil money penalties can be assessed. Without these guardrails, the OCC’s broad discretion creates risk of weaponization by future administrations hostile to stablecoin innovation. Our letter also raises three additional issues. First, on white-labeling, we recommend the OCC decline to restrict issuers to a single stablecoin brand, which the Act does not authorize and which isn’t necessary to address the OCC’s proffered concerns. Second, on reporting, we recommend replacing an onerous weekly cadence across eight underdefined data categories with a monthly reporting model aligned with the Act’s existing disclosure requirements. And third, on multi-chain operations, we recommend that the OCC clarify that cross-chain transfer mechanisms are treated as routine payment activity rather than new issuances. The OCC’s rulemaking is one of the most consequential pieces of GENIUS Act implementation, and getting it right matters for the long-term health and competitiveness of the U.S. stablecoin market. We’re grateful for the agency’s engagement and look forward to continued dialogue as the Final Rule takes shape. But it is important that the OCC gets this rulemaking right. Stablecoin adoption sits at a moment of inflection. If we get the rules right over the next two and a half years, American firms could dominate this space for the next twenty-five. The OCC should address these issues so that the space can run expeditiously to greater and safer adoption in line with the goals of GENIUS. You can read Paradigm’s full comment letter [here](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-7de66845c2/0f50f2d0850a5174467257e99f7dc94c/asset-https-cdn-sanity-io-files-dgybcd83-p-7de66845c2.pdf). ## https://www.paradigm.xyz/writing/pacts-protecting-your-bitcoin-from-a-quantum-sunset # PACTs: Protecting Your Bitcoin From a Quantum Sunset > A possible way for Bitcoin holders to protect themselves from having their funds frozen in an emergency post-quantum hard fork—without having to publicly move their coins. An attacker with a powerful enough quantum computer could steal hundreds of billions of dollars of Bitcoin. To prevent that, the Bitcoin community may someday choose to upgrade the protocol to sunset the ability to spend from addresses with exposed public keys. Such an upgrade would be controversial, in part because Bitcoin values the rights of dormant holders—including Satoshi Nakamoto himself, who is estimated to hold around $75 billion of Bitcoin in vulnerable addresses—to remain inactive onchain. If an upgrade sunsets support for those addresses, these dormant holders will be forced to publicly move their coins or let them be frozen. But if quantum computers are coming and we don’t sunset those addresses, those holders will be forced to move those coins or let them be *stolen*. Either path seems to force long-time holders to give up some of their privacy by publicly moving their funds. This post proposes a way out of that dilemma, by letting Bitcoin holders protect themselves from any eventual sunset costlessly and silently, without having to publicly move their coins. The key is that holders can use Bitcoin itself to secretly *timestamp *their knowledge of their private keys. A future protocol upgrade could then accept zero-knowledge proofs of these Provable Address-Control Timestamps (PACTs) as an alternative path for spending from a sunsetted address. This protocol could protect the privacy and security of existing Bitcoin holders better than the alternatives. And adopting a standard for these proofs now would help give holders as much time as possible to secure their coins against an emergency sunset, while allowing us to leave the more difficult decisions—including whether a sunset is necessary or desirable—until later. ### Background [Recent advances](https://scottaaronson.blog/?p=9665) raise the question of whether cryptographically relevant quantum computers (CRQCs) could come sooner than most people had hoped. There are many difficult questions about quantum preparedness going forward, but the elephant in the room is what to do about the hundreds of billions of dollars of Bitcoin stored in addresses with exposed public keys, and thus vulnerable to theft by CRQCs. The Bitcoin community has been divided on what to do about this risk. Neha Narula recently wrote a [helpful summary](https://nehanarula.org/2026/04/20/bitcoin-and-quantum-a-roadmap.html) of the debate. #### Doing Nothing The default path is to do nothing. This will prove to be the right one if cryptographically relevant quantum computers never arrive, which is a legitimate reason to hold off on the most extreme measures. The rest of this post addresses the other possible worlds—in which we someday hit a point where CRQCs are clearly inevitable, and need to decide whether to undergo an emergency fork. If CRQCs do arrive before the protocol upgrades, then up to hundreds of billions of dollars of Bitcoin might end up in the hands of attackers. Even if the Bitcoin community were willing to stomach the theft and its effect on the market, the quantities involved would be geopolitically significant, and—particularly if the attacker was a criminal or a hostile nation-state—it could lead to a cataclysmic regulatory blowback on Bitcoin. #### Sunset Another option is a soft fork that eventually sunsets the ability to spend from addresses with exposed public keys, as proposed in the draft of [BIP-361](https://github.com/bitcoin/bips/blob/master/bip-0361.mediawiki). This path is controversial because it violates an important principle—that people should be able to leave their Bitcoin in cold storage for decades without fear of losing access. But in the scenario where CRQCs are imminent, *there is no path where holders who are entirely offline can be assured of keeping their Bitcoin*, because their funds are at risk of theft. However, a sunset poses some significant inconvenience on holders: - First, it would force offline holders to move their coins, which is an expensive and public onchain action. They would have to pay fees, reveal that they are still active, and potentially leak other information about themselves, such as timing patterns, links between their wallets, and even their IP address. For an early holder like Satoshi, this would be a massive revelation—they would have to tell the world that they are alive and still in possession of their keys. - Second, there may only be a limited amount of time for an upgrade. Bitcoin does not yet support post-quantum addresses, and may not adopt them until the quantum threat is clearer. If progress on quantum computers is fast enough, we may end up in a situation where the gap between post-quantum addresses being supported and being *mandated* is uncomfortably brief. #### Rescue Protocols For the above reasons, it is likely that many holders will fail to upgrade before the sunset date. Will there be a way for them to prove to the protocol that they are the rightful owners of their addresses? For some addresses, the answer is already yes. For example, if a private key was derived from a parent key (as in the [BIP-32](https://en.bitcoin.it/wiki/BIP_0032) standard), the holder may be able to provide a zero-knowledge proof that they knew that parent key, which is something a quantum attacker could not have. This kind of “rescue protocol” is discussed in [BIP-361](https://github.com/bitcoin/bips/blob/master/bip-0361.mediawiki), and a prototype prover has even been [implemented](https://groups.google.com/g/bitcoindev/c/Q06piCEJhkI/m/Ly9J23FlAwAJ). There may even be ways to delay the implementation of the specific rescue rules until a subsequent fork. #### The Satoshi Problem Those are promising escape hatches, but they can’t save the earliest Bitcoin addresses. There are millions of bitcoins that have exposed public keys and predate BIP-32 (and which therefore could not be rescued using the above path). Most notoriously, wallets believed to belong to Satoshi Nakamoto hold around 1.1 million BTC, worth over $75 billion today. This post describes an escape hatch for sunsetting that can potentially provide the best achievable protection for those offline holders—a self-protective measure they could take today, with no changes to Bitcoin and no onchain action, in a way that could maintain their ability to spend after a sunset while still achieving the safety sunsetting would provide from a quantum attacker. ### PACTs Suppose we’re in the year 2040, and Satoshi has decided to fund his retirement by finally selling some of his Bitcoin. Cryptographically relevant quantum computers arrived in 2030, and deriving Satoshi’s private keys is now a standard homework assignment for MIT freshmen. Luckily for Satoshi, the protocol sunsetted the ability to spend from ECDSA keys in an emergency soft fork in 2029. [^1] Satoshi wants to prove, in a post-quantum and algorithmically verifiable way, that he knew his private key before CRQCs could derive it. What can he do? If he has to generate that proof from scratch today, he is out of luck. Since everyone now knows his private keys, and since he didn’t derive them using BIP-32 or any other deterministic scheme, the keys don’t give him any asymmetric private information he can use for a cryptographic proof. However, if he can cryptographically prove that he knew those keys before CRQCs could have derived them, then the protocol could let him take the coins. If he had the foresight back in 2026, he could have used a cryptographic timestamping service to timestamp a signature, establishing that he knew the private key before CRQCs existed. Conveniently, he had already invented a trustless way to timestamp proofs of knowledge back in 2008. The [Bitcoin whitepaper](https://bitcoin.org/bitcoin.pdf) described the Bitcoin network as a “distributed timestamp server.” Developers have long recognized that while it was primarily designed for timestamping transactions, it could easily be used to timestamp any hash—and that since hashes can be aggregated efficiently, it is cheap to run a service that provides such timestamps for free. [OpenTimestamps](https://opentimestamps.org/) is an open-source protocol that allows anyone to timestamp arbitrary hashes on the Bitcoin blockchain, by including them in a Merkle tree within an OP_RETURN output. If Satoshi had timestamped a salted commitment to a standardized address-control proof before CRQCs using OpenTimestamps, then he could provide a post-quantum-secure [STARK](https://starkware.co/stark/) proof of that timestamp to the Bitcoin protocol. A Provable Address-Control Timestamp, or PACT, is just such a timestamped commitment. ##### **Step 1: Commit** The below description is an illustrative example of how the PACT protocol could be designed, rather than a formal proposal. It will require significant input from experts and the community, and feedback is encouraged. To create a PACT, the holder generates a 256-bit secret salt and uses BIP-322 full message signing to prove control of the scriptPubKey for the vulnerable unspent transaction output (UTXO). The BIP-322 message should commit to the PACT purpose, Bitcoin network, vulnerable scriptPubKey, and salt: ```python PACT/v1: Bitcoin quantum-sunset proof of address control network=bitcoin-mainnet scriptPubKey= salt=<32 random bytes> ``` Let: ```python salt = random(32 bytes) msg = Encode("PACT/v1", "bitcoin-mainnet", scriptPubKey, salt) control_proof = BIP322_FULL_SIGN(scriptPubKey, msg) commitment = SHA256("PACT/v1 commitment" || salt || SHA256(control_proof)) ``` The holder then timestamps commitment using OpenTimestamps. They store the salt, the BIP-322 control proof, and the OTS proof file in a secure location. This requires no Bitcoin transaction by the holder and is off-chain. The timestamp reveals nothing about the control proof, salt, public key, address, or which coins the holder owns, though privacy-conscious holders should still protect network metadata when interacting with timestamping services. #### **Step 2: Rescue** If Bitcoin later sunsets spending from UTXOs with exposed public keys, that fork could also define a rescue protocol for PACTs. To spend a sunsetted UTXO, the claimant would provide a post-quantum-secure proof (such as a [STARK](https://starkware.co/stark/)) that: - they know a secret salt and a BIP-322 full message proof `(control_proof)`; - `SHA256("PACT/v1 commitment" || salt || SHA256(control_proof))` equals a commitment timestamped before the PACT cutoff, where that cutoff is set before CRQCs are believed to be able to derive private keys from exposed public keys; - `control_proof` is a valid BIP-322 full message proof for the scriptPubKey controlling the frozen UTXO over the PACT message containing that salt; - the rescue proof is bound to the specific rescue transaction, so it cannot be copied and reused to redirect the coins. The salt and BIP-322 control proof themselves would not be revealed. The timestamp proves that the holder had the ability to produce that control proof before the cutoff. The transaction binding proves that the holder is authorizing this particular rescue spend. At a high level, the eventual consensus proof would need to show a complete anchor chain: the hidden salt and BIP-322 control proof hash to the public PACT commitment; the OpenTimestamps attestation carries that commitment through its hash operations into a calendar Merkle root; that root appears in an OP_RETURN output of a Bitcoin transaction; the transaction is included in a block by a transaction Merkle proof; and that block is recognized by the rescue rules as part of the active Bitcoin chain before the PACT cutoff. A practical design would have to specify how the proof, which is verified in the context of a transaction, is anchored to the history of the chain (likely via a recent block hash). This does not require Bitcoin to decide today whether a sunset is necessary. It only gives holders a silent, no-onchain-cost way to preserve evidence that may become useful if such a sunset is ever adopted. #### Benefits - No fork required today. Holders don’t have to wait for Bitcoin to adopt quantum-secure addresses or to decide what to do about insecure UTXOs. As soon as we agree on a standardized format for PACTs, holders can begin timestamping them. - Note that while the commitment protocol for PACTs is relatively simple and makes use of well-established primitives like OpenTimestamps, the protocol for eventually verifying them will not be. Verifying a STARK to allow spending from sunsetted UTXOs will require substantial new plumbing in the Bitcoin protocol. - Silent. Nobody other than the holder knows that the holder made the commitment. Even when the holder spends the coin, they may not have to reveal when they timestamped it—the protocol could require only a zero-knowledge proof that it was early enough. - No onchain cost to commit. OpenTimestamps is free to use and can batch many commitments into a single Bitcoin transaction. - Low risk. While the protocol requires the holder to produce a BIP-322 control proof with their key—which poses some risk—neither the proof nor the salt is broadcast or shared with OpenTimestamps; only an opaque commitment is revealed. The holder does, however, need to protect the salt, proof, and OTS file as a recovery artifact. #### Risks and Downsides - The holder has no guarantee that this rescue hatch will ever be implemented. It is possible that Bitcoin will never sunset quantum-unsafe keys (either because CRQCs never arrive, or because Bitcoin decides to bite the bullet on them). Even if it does, it may not implement this specific rescue path. A holder should not solely rely on PACTs for protection until the rescue protocol is adopted into the protocol. But given the low cost of making the commitment, it might still be worth it for a long-term holder to create a PACT as soon as a standard is agreed-upon. - Not universal. While this protocol should work for many single-key wallets and can be generalized using a BIP-322-style proof format, multisig, complex scripts, custodial wallets, and hardware-wallet support would need careful standardization. Additionally, PACTs assume that the ability to produce a valid [BIP-322](https://github.com/bitcoin/bips/blob/master/bip-0322.mediawiki) proof on a very specific message corresponds to the ability to control the coin. That is the same practical assumption behind message-signing proofs, but as discussed in BIP-322, the power to sign messages from an address is not necessarily identical to the power to sign transactions from that address. #### Prior Work Jeremy Rubin has [proposed](https://delvingbitcoin.org/t/commit-reveal-for-pq-migration/2419) a similar design on the Delving Bitcoin forum. ### Conclusion Cryptographically relevant quantum computing may not threaten Bitcoin for a long time, or it might never happen. Users might never need to do anything. But Bitcoin is about preparing for the long term, hedging for tail risks, and self-reliance. If there is a way to plant a seed now that will give us an advantage over cryptographic attackers in a possible future, then long-term holders should take it. And protocol developers should think about the privacy interests of large, long-term, dormant holders—including, possibly, the very largest, longest-term, and most dormant holder—when deciding how to implement a possible quantum sunset. *Acknowledgments: Eli Ben-Sasson, Avihu Levy, Abdelhamid Bakhta, Jameson Lopp, Neha Narula, Nic Carter, Arjun Balaji.* [^1]: As discussed in earlier drafts of BIP-361, consensus deployment of these phases is subtle. If Phase B permanently declared all legacy-key spends invalid forever, a later rescue path that made some of them valid again would be a hard fork, which has never been done in modern Bitcoin history and is generally considered unacceptable by the Bitcoin community. For this reason, BIP-361 currently proposes including the rescue path as part of Phase B. One possible alternative would be to design Phase B as a temporary freeze with an explicit expiry (after which UTXOs would be spendable again), so a later Phase C soft fork could either extend the freeze permanently or introduce new rescue rules ## https://www.paradigm.xyz/writing/paradigm-files-comment-letter-on-the-cftc-s-prediction-markets-rulemaking # Paradigm Files Comment Letter on the CFTC’s Prediction Markets Rulemaking > Paradigm supports CFTC’s engagement and urges additional clarity Today, Paradigm filed a comment letter with the Commodity Futures Trading Commission in response to the agency’s advance notice of proposed rulemaking regarding prediction markets. For years, we have been calling for clear, principles-based regulations on prediction markets that will allow them to grow in America in a responsible manner. After years of wishes cast to the heavens, the CFTC has heard our prayers. The CFTC’s ANPRM reflects exactly the kind of flexible, principles-based approach that Congress intended when it modernized the CEA and gave the CFTC exclusive authority to regulate these markets. Of course, this action is not the first move this CFTC has made on this subject. The agency was right to withdraw its 2024 proposal to revive an economic purpose test that was designed for traditional agricultural futures. Bringing back that test to modern event contracts would risk entire categories of contracts used for hedging and informational purposes, and would improperly substitute the CFTC’s judgment for investors’ own decisions about how to manage their exposure. But our letter urges the Commission to go a step further and formally repeal Rule 40.11(a), which still provides significant discretion for the CFTC to designate broad classes of event contracts as contrary to the public interest. The ANPRM is a strong signal that the CFTC understands Rule 40.11(a) should be updated, and we support the agency following that signal. Our letter also addresses three more targeted issues: - First, on margin trading, we recommend the CFTC allow prediction market customers to trade event contracts on margin, with appropriate guardrails, just as they can with other futures contracts. Pre-funding disadvantages both customers and markets, particularly for long-term contracts where liquidity matters most. Investor protection measures like margin limits and disclosure requirements can be easily addressed through future rulemaking, but we encourage the CFTC not to foreclose the option entirely. - Second, on insider trading, we support reasonable restrictions where a single individual controls the outcome, and Core Principle 3 is a natural fit for implementing those restrictions. But the manipulation risk in those types of contracts is qualitatively different from a contract on a team’s or player’s aggregate performance, and the agency should recognize that difference when crafting its rules. - Third, on blockchain-based prediction markets, we support technological innovation but not regulatory arbitrage. The Commission’s rulemaking can leave room for responsible on-chain innovation while ensuring that off-shore architecture doesn’t become a mechanism for escaping CFTC oversight. Prediction markets are genuinely valuable information aggregators and hedging tools, and they are proof positive that markets can serve a much wider range of needs than traditional derivatives have historically covered. The CFTC’s willingness to engage on how to regulate them is exactly what this moment calls for. We look forward to continued engagement as the Commission moves toward a final rule. You can read Paradigm’s full comment letter [here](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-267c5629ff/800b1527e246d4ded1d01bb1f27a66e7/asset-https-cdn-sanity-io-files-dgybcd83-p-267c5629ff.pdf). ## https://www.paradigm.xyz/writing/paradigm-backs-kalshi-in-latest-state-overreach # Paradigm Backs Kalshi in Latest State Overreach > Paradigm files amicus brief in support of Kalshi in Commonwealth of Massachusetts v. KalshiEX LLC Today, Paradigm filed an amicus brief with the Massachusetts Supreme Judicial Court, urging it to vacate a lower court injunction barring Kalshi from offering sports-event contracts to Massachusetts residents. This filing, in *Commonwealth of Massachusetts v. KalshiEX LLC*, is our latest in a long-running effort to defend federally regulated prediction markets against state overreach. The Massachusetts case follows a now-familiar pattern. The Commonwealth sued Kalshi, arguing that sports-event contracts violate the state’s sports wagering law. The Superior Court agreed and entered a preliminary injunction. Kalshi appealed to the Supreme Judicial Court, which granted direct review after an intermediate appellate court stayed the injunction pending appeal. In its brief filed last month, Kalshi made clear what the Superior Court got wrong. We agree wholeheartedly with Kalshi. The core legal question is not a close one. The Commodity Exchange Act gives the CFTC “exclusive jurisdiction” over trading on designated contract markets like Kalshi, and expressly “supersedes” and “limits” state regulatory authority over such transactions. This wasn’t an accident, and the legislative record, which we detail in our brief, is explicit: Congress’s goal was to “preempt the field.” In fact, and as we make clear, the specific problem Congress was solving for with its 1974 legislation was states treating derivatives trading as gambling and trying to regulate or ban it. Courts have uniformly agreed ever since that the CFTC, not state regulators, governs trading on federally licensed exchanges. The stakes are national. If Massachusetts can deploy its gaming laws to cut Kalshi off from its residents, Kalshi would face 50 separate regulatory regimes for a nationwide, federally-regulated exchange. This patchwork system of different states demanding control over national markets is precisely the “total chaos” Congress designed the CEA to prevent. We’ve been in this fight since the beginning, filing amicus briefs in cases out of [New Jersey](https://www.paradigm.xyz/2025/07/paradigm-files-amicus-brief-to-oppose-state-encroachment-on-federal-regulation), [Maryland](https://www.paradigm.xyz/2025/10/paradigm-files-another-amicus-brief), [Nevada](https://www.paradigm.xyz/2026/01/paradigm-files-ninth-circuit-amicus-brief-to-oppose-state-encroachment-on-federal-regulation), and [California](https://www.paradigm.xyz/2026/03/paradigm-files-ninth-circuit-amicus-in-new-front-of-prediction-market-battle) on the same fundamental principle: the CFTC sets the rules for these markets, not any state or tribal regulator. The legal foundation for that principle keeps getting stronger. There will be more challenges; there always are when an innovation threatens entrenched incumbents. But as long as states keep inventing theories to fragment federal oversight of prediction markets, we’ll keep showing up to make sure courts apply the law as Congress wrote it. Our full brief is available [here](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-aa1093e014/fa97c0c2c88233c19eb90bf1481ffc13/asset-https-cdn-sanity-io-files-dgybcd83-p-aa1093e014.pdf). ## https://www.paradigm.xyz/writing/introducing-the-2026-paradigm-fellowship # Introducing the 2026 Paradigm Fellowship > Applications are open for the 2026 Paradigm Fellowship. Four days, ~30 people, Northern California. August 12–15. [Apply Now](https://paradigm.xyz/fellowship-2026) Applications are open for the 2026 Paradigm Fellowship. Four days, ~30 people, Northern California. August 12–15. Apply [here.](https://paradigm.xyz/fellowship-2026) For our fourth year, we're expanding to welcome builders across every frontier — crypto, AI, robotics, energy, bio, prediction markets, or something we haven't thought of. Last year's cohort came from 10 countries. Some were undergrads, some were dropouts, some came from OpenAI, SpaceX, Citadel, and Kalshi. What they had in common was being obsessively good at something technical. The format is simple: firesides, whiteboarding sessions, and time to hack. What makes it work is what happens in between, and after. Fellows have met cofounders, started companies, joined the Paradigm research team, and gone on to raise from Paradigm and others. Every fellowship is different by design. Here’s a look inside last year’s. *Autoplay video* We value slope over intercept. You don’t need to be a founder, either, you just need to love building - in whatever form that means the most to you. If you're early in your career, deeply technical, and looking for the other people who think like you do — apply. Paradigm covers travel, lodging, and meals. Apply by June 8th. ## https://www.paradigm.xyz/writing/paradigm-files-comment-letter-on-ncua-s-genius-rulemaking # Paradigm Files Comment Letter on NCUA’s GENIUS Rulemaking > Paradigm weighs in on opening GENIUS proposal for credit unions Today, Paradigm filed a comment letter with the National Credit Union Administration in response to the first half of the agency’s proposal to implement the GENIUS Act. The NCUA deserves real credit for crafting a thoughtful, detailed proposal for licensing and supervising payment stablecoin issuers. Our letter broadly supports this good effort. But, this good effort can be made greater. We have two improvements that we believe will make this rule and the entire GENIUS regime better for issuers, consumers, and the stablecoin ecosystem. *First*, our letter raises concerns about proposed Section 706.112, which would restrict federally insured credit unions (FICUs) from investing in payment stablecoin issuers (PPSIs) that are licensed by a *different* regulator—say, the OCC or the Fed—rather than the NCUA. We don’t think either of the rationales offered by NCUA support this restriction: - First, the NCUA suggests that this type of outbound investment might cause confusion about which regulator has primary oversight responsibility. But multi-regulator coordination isn’t novel in banking: State banking regulators, the FDIC, and Federal Reserve already operate under a well-tested protocol for coordinating responsibility across jurisdictions, and a similar approach can work here. - Second, the NCUA suggests that its existing interpretations of federal law might not permit investment in entities that don’t “primarily serve” credit unions. But the GENIUS Act clearly allows FICUs to invest in PPSIs that provide services to them, and the Board effectively acknowledges that its historical interpretation may be due for revision in any event. In other words, we’re just asking the Board not to hold stablecoins to an interpretation it may no longer believe in and which GENIUS doesn’t require. Even more to the point, the proposed rule takes the right approach to *inbound* investment, permitting non-FICU investors to put unlimited money into NCUA-licensed PPSIs. The logic behind that decision applies with equal force in the other direction, and the Board should apply its own reasoning symmetrically. *Second*, we believe the proposal needs to have additional processes in place when there are unexpected and involuntary shifts in ownership; call it another safety net for when things go wrong. Specifically, the Proposed Rule establishes a 60-day notice process for ordinary change-of-control transactions involving PPSIs, but doesn’t address what happens when ownership shifts suddenly and involuntarily through bankruptcy, insolvency, or other corporate distress. In those situations, the 60-day pre-notice window isn’t workable and the absence of any framework creates uncertainty for everyone: the PPSI, its counterparties, the NCUA, and the stablecoin holders. Accordingly, we recommend the Board adopt a 90-day *post*-event transition window for these involuntary scenarios, modeled directly on the FDIC’s existing approach to similar situations, during which the affected party would be required to file notice or a rebuttal to the presumption of control. This approach provides clarity without creating new burdens for ordinary transactions. The NCUA comment period is in many ways the starting gun to GENIUS Act implementation, and will be followed by substantive proposals from other agencies (as well as a second round of rulemaking from the NCUA itself). Our goal throughout will remain the same: a stablecoin regulatory framework that is genuinely pro-competition, protects consumers, spurs investment and market dynamism, and gives the industry clear rules to build upon. We’re grateful to the NCUA for moving quickly and thoughtfully, and we look forward to continued engagement as this framework takes shape. You can read Paradigm’s full comment letter [here](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-b7a7acf043/970aa3f5f9f96406dfc5f9d21c808766/asset-https-cdn-sanity-io-files-dgybcd83-p-b7a7acf043.pdf). ## https://www.paradigm.xyz/writing/releasing-reth-2-0 # Releasing Reth 2.0! > Reth is now faster, smaller, and ready for the next frontier of crypto infrastructure. Reth 1.0 established that a [node-as-a-library](https://www.paradigm.xyz/2024/06/reth-prod) approach could meet the stability and feature completeness requirements for Ethereum, as well as support the extensibility required for Layer 2 networks. With Reth 2.0, we shifted our focus to the next frontier of performance and storage efficiency. Reth 2.0 achieves **1.7 Gigagas/s** performance [^1] while maintaining a significantly reduced disk footprint of approximately **240 GB** (or a ~170 GB snapshot download). These metrics are being validated in real-time on our production nodes - Ethereum mainnet and [**Tempo**](https://tempo.xyz/) mainnet which is our high-performance chain designed to reach the physical limits of network throughput. [Download a snapshot](https://snapshots.reth.rs) and see for yourself, or check the [ethPandaOps Lab Dashboard](https://lab.ethpandaops.io/ethereum/execution/timings?range=24hours) for a third-party comparison against other Ethereum clients. Below is Reth’s historical “winrate” graph from the ethPandaOps lab dashboard, measuring what proportion of blocks Reth validated the fastest compared to other clients: ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--1d5784248e/66ef0b7341242975392658213ed9cd96/asset-https-cdn-sanity-io-images-dgybcd83--1d5784248e.png) ## **A New Architecture: Pipelined Execution and Tiered Storage** To reach these speeds, we have overhauled how Reth processes block data and interacts with the disk. ### **Optimising Parallel State Calculation** The "state root" is a single hash representing the entire state of the network. Historically, calculating this was a sequential bottleneck because the node had to wait for transaction execution to finish in order to calculate the resulting state root. Reth already parallelised this with [**Sparse Trie**](https://github.com/paradigmxyz/reth/releases/tag/v1.11.0) by updating the state root in the background while executing transactions. Reth 2.0 introduces [**Sparse Trie Cache**](https://github.com/paradigmxyz/reth/blob/0031445779745d97a665f233a662b4ab44eda85f/crates/engine/tree/src/tree/payload_processor/sparse_trie.rs#L40), an in-memory representation of the state trie that survives across blocks. Previously, the state root task had to rebuild its working view of the trie for every block. By keeping this structure in memory, Reth 2.0 reduces the time spent calculating the final state root at the end of each mainnet block to just 1–2ms. ### **Reducing Data Redundancy** When a transaction updates an account, Reth must have that account and a Merkle proof for it loaded into the sparse trie cache. Previously, this involved fetching large, redundant sets of data from the disk for every update. Reth 2.0 introduces [**Partial Proofs**](https://github.com/paradigmxyz/reth/blob/0031445779745d97a665f233a662b4ab44eda85f/crates/trie/trie/src/proof_v2/mod.rs#L48). Instead of fetching a full path (aka a proof) for every change, Reth now only retrieves the unique portions of the trie that haven't been cached. This eliminates redundant disk lookups and cuts the number of proof requests per block in half, significantly lowering I/O. Here's what that looks like in practice, measured with [reth-bench](https://github.com/paradigmxyz/reth/tree/main/bin/reth-bench) [^1] on Ethereum Mainnet: ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--11e7f58838/195862554a12c8bd8941dcefc6ab9cbc/asset-https-cdn-sanity-io-images-dgybcd83--11e7f58838.png) ### **Tiered Storage (Hot/Cold Database Split)** Database size is one of the most difficult challenges in scaling. Reth 2.0 addresses this in a few ways: 1. We now only store hashed state on MDBX, dropping the plain state tables. 2. We have moved over historical account and storage changesets to Static Files, our specialized append-only datastore, and our indices for fast access to RocksDB. This has two implications: 1. Smaller database size, which also translates to lower read latency. 2. Faster persistence time, which lets us process more transactions with less memory. Saving a standard block now only takes an average of **40ms**, and even a massive "Gigagas-sized" block now persists in just **400ms**. On Reth storage v1, a block of this size would take 8.4s to persist, giving us a roughly 20x speedup on persistence for storage v2. This also has a great side-effect: You can now seamlessly go from full node to archive node and back, just mount the corresponding static files! ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--b0a35b1dea/04c841a9773ab4cc9e640280b7e322f6/asset-https-cdn-sanity-io-images-dgybcd83--b0a35b1dea.png) ### **Minimal Mode** This architecture enables **Minimal mode**, a configuration for Reth that omits a significant amount of history and index data from the node. Reth stores only the hashed state tables and trie data required for validation. A Reth mainnet node can sync with <300GB disk now! Need more than the minimum? You can opt in to any combination of extra data through your pruning configuration — headers, transactions, receipts, changesets (and their corresponding RocksDB indices). You choose exactly the data your use case requires, nothing more. ### **Snapshots: Get Running in 10 Minutes** ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--e7c648bc70/a855c29f4bd3918be63b9324d9e8b465/asset-https-cdn-sanity-io-images-dgybcd83--e7c648bc70.png) A smaller database means faster snapshots. You can grab a snapshot and sync a minimal node: ```bash reth download -y && reth node ``` That's it. The new modular snapshot tool lets you pick exactly the components you need, with parallel streams, automatic resume, and config generation out of the box. See [snapshots.reth.rs](https://snapshots.reth.rs) for details. ## **What’s Next for Reth?** In the coming months we will be accelerating Reth with even more performance optimizations, including AOT/JIT execution via [revmc](https://github.com/paradigmxyz/revmc), which we recently started working on again, since the state root computation is no longer a bottleneck for us. We will also implement full parallel execution, enabled by BALs in the upcoming [Glamsterdam hardfork](https://forkcast.org/upgrade/glamsterdam). Go run Reth, join our [community](https://t.me/paradigm_reth), or reach out directly to [georgios@paradigm.xyz](mailto:georgios@paradigm.xyz) if you want to work together; we're [hiring cracked full-time Rust engineers](https://tempo.xyz/careers). See you on [GitHub](https://github.com/paradigmxyz/reth). *Written by The Reth Team* [^1]: Hardware Specs CPU: AMD EPYC 4585PX (16c/32t) @ 4.3 GHz (5.7 GHz Boost) RAM: 128 GB 3600 MHz Storage: 2×960 GB NVMe SSD + 2×1.92 TB NVMe SSD (Software RAID) ## https://www.paradigm.xyz/writing/an-interactive-guide-to-genius-implementation # An Interactive Guide to GENIUS Implementation > The GENIUS Act is law. We built a real-time tracker for what comes next. Last summer, the GENIUS Act became the first federal law to establish a framework for payment stablecoins in the United States. It was a historic moment. But the day it was signed wasn’t the finish line; it was the starting gun. What happens next is what actually determines how the GENIUS Act reshapes the financial system: the rulemaking process. This is where agencies translate Congress’s mandate into the binding rules that will govern how stablecoins are issued, reserved, and overseen. That’s why we built the [GENIUS Act Tracker](https://paradigm.xyz/genius). It started as an internal tool for the Paradigm Policy team, a way to keep tabs on which agencies were doing what and when. Then, we kept hearing the same questions from founders, lawyers, Hill staffers, and policy watchers across the space. So: we’re making it public. ## **How rulemaking works** When Congress passes a law, it grants agencies broad authority rather than explicit instructions. The binding rules come later through a process governed by the Administrative Procedure Act (APA). This requires agencies to publish proposed rules, accept public comment, and formally respond before anything in the law takes effect. The process is designed to ensure transparency and participation, but can take months to years to complete. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--5b212daff6/0d4d74e00f140c900c13c2ec75d3660e/asset-https-cdn-sanity-io-images-dgybcd83--5b212daff6.png) There are up to three stages. Some agencies begin with an Advance Notice of Proposed Rulemaking (ANPRM), an early request for input before a formal proposal is even drafted. Many skip it entirely. The core step is the Notice of Proposed Rulemaking (NPRM), which puts a specific proposed rule out for public comment, typically for 30 to 60 days. Anyone – companies, universities, retail users, lawmakers – can weigh in, and agencies are legally required to consider what they say. The Final Rule follows, (sometimes months later, sometimes years) and includes an effective date that sets when the finalized requirements kick in. The problem is there is no central place tracking all of this for any given law. That’s the gap our tracker fills. ## **What’s in the tracker** The GENIUS Act requires 21 rulemakings from agencies spanning the Treasury and the prudential regulators: the OCC, the NCUA, the FDIC, and the FRB. Not all of them carry the same weight. The rulemakings to watch closely are those touching reserve requirements and permissible backing reserve assets. The OCC's rules around federal non-bank charters are equally consequential: how broadly or narrowly the agency defines eligibility will shape who can issue in the first place. And then the most politically fraught subject matter is the ability of intermediaries to share stablecoin backing reserve yield with users and ecosystem participants. The tracker lists all rulemakings, sortable by agency, publication status, and type. Each entry includes the relevant bill section, the responsible agency, whether the rule is required or discretionary, Paradigm’s commentary on rules with which we engaged, a full progress timeline from ANPRM through effective date, and public comments submitted on each rulemaking. ## **A note on timing** Federal agencies have one year from enactment (until July 18, 2026) to complete most required rulemakings, with full implementation taking effect 18 months after enactment (January 18, 2027). While the regulators have expressed their commitment to completing the GENIUS rulemakings on time, the timeline is an *official* one, but probably not the *real* one. The reason being: there are no real consequences for agencies that miss this “soft” deadline, and Washington has a long track record of running late. For example, the Dodd-Frank Act, signed in 2010, mandated over 400 rulemakings. As of today, dozens remained incomplete, and a handful of significant rules have never been finalized at all. The GENIUS Act is a fraction of that scale, but the dynamic is the same: Congressional deadlines for rulemakings are important, but frequently aspirational. The process is just getting started. We’ll keep the tracker updated as rulemakings progress. If you’re building in this space and have questions, reach out. ## https://www.paradigm.xyz/writing/paradigm-files-ninth-circuit-amicus-in-new-front-of-prediction-market-battle # Paradigm Files Ninth Circuit Amicus in New Front of Prediction Market Battle > Paradigm Files Amicus Brief Opposing New Front of Attacks on Federal Regulation of Prediction Markets Yesterday, Paradigm filed an amicus brief in *Blue Lake Rancheria v. Kalshi*, a Ninth Circuit appeal of yet another lawsuit attacking federally licensed and regulated prediction markets. We’ve been in this fight from the beginning, standing lock-step with Kalshi against state regulatory grabs in [New Jersey](https://www.paradigm.xyz/2025/07/paradigm-files-amicus-brief-to-oppose-state-encroachment-on-federal-regulation), [Maryland](https://www.paradigm.xyz/2025/10/paradigm-files-another-amicus-brief), and [Nevada](https://www.paradigm.xyz/2026/01/paradigm-files-ninth-circuit-amicus-brief-to-oppose-state-encroachment-on-federal-regulation). And while the challengers here (three California Indian tribes seeking to protect their gambling monopolies) are different, and the legal question here (whether the Indian Gaming Regulatory Act, IGRA, silently unwound Congress’s grant of exclusive authority over contract markets to federal regulators) is novel, the answer remains the same: the CFTC, not any state or tribal regulator, sets the rules for these markets. The district court got it right when it [denied](https://storage.courtlistener.com/recap/gov.uscourts.cand.453216/gov.uscourts.cand.453216.71.0_1.pdf) the tribes a preliminary injunction, and the Ninth Circuit should affirm. While Kalshi and other prediction markets continue to fight these ill-advised actions on multiple fronts, this case would be the first to force an appellate court to consider the IGRA in this context. But just because an argument is novel does not make it good. It should not be surprising that the challengers in these actions would turn to untested theories; as Paradigm has repeatedly argued, and as the CFTC has now backed in its own amicus filing in a similar Ninth Circuit case, the Commodity Exchange Act (CEA) plainly confers on the CFTC sole regulatory authority over “designated contract markets” like Kalshi. What is surprising is that these challengers resort to the Unlawful Internet Gaming Enforcement Act, UIGEA, to argue that Kalshi’s exchange-traded event contracts should be treated as gaming occurring on Indian lands. The UIGEA expressly excludes from its definition of prohibited gambling “any transaction conducted on or subject to the rules of a registered entity or exempt board of trade under the Commodity Exchange Act.” As we explain in our brief, this is a feature, not a bug, of UIGEA: “These exclusions emphasize that Congress … sought to ensure the preeminence of the CFTC regulatory scheme for derivatives over other federal and state regulation.” Kalshi’s event contracts are traded on a CFTC designated contract market. The exclusion applies. End of story. Unable to argue with that plain language, the tribes instead want this case governed by the IGRA. But the IGRA regulates gambling *only on Indian lands*. It says nothing about the internet. Building on the strong foundation laid by Kalshi’s brief, our amicus brief makes clear that “Congress legislated in two distinct areas. In one, Congress created a structure to bring derivatives markets under one federal umbrella. In the other, it created a layered approach under which the IGRA grants tribes power to control gambling on ‘Indian lands’ and the UIGEA addresses enforcement and jurisdictional problems arising from the interstate nature of internet gambling.” In other words, these statutes operate in different lanes: the IGRA governs on-reservation gambling, the UIGEA governs interstate internet gambling, and the CEA governs federally regulated derivatives on prediction markets. The regimes governing gambling (IGRA and UIGEA) and derivatives trading (CEA) are cleaved from one another by law; the tribes cannot pick and choose which pieces of each law to use whenever it suits their fancy. Our legal regime here is not a buffet. The battle over prediction markets isn’t ending anytime soon. But the legal principles at stake are clear and, so long as rent-seeking challengers continue inventing self-serving loopholes to avoid those principles, we’ll keep showing up to ensure courts apply them as Congress intended. The Ninth Circuit should affirm the district court and confirm that the CFTC exclusively regulates prediction markets, and no state or tribal gaming authority legal argument can change that. The full brief is available [here](https://downloads.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-7a519f48f0/60f04bf7001f9cbf34eb993a1db41124/asset-https-cdn-sanity-io-files-dgybcd83-p-7a519f48f0.pdf). ## https://www.paradigm.xyz/writing/paradigm-february-2026-poll-on-prediction-markets # Paradigm February 2026 Poll on Prediction Markets > Over a third of Americans are using prediction markets in some way. Our new poll delves into what is driving the growth of this space and how Americans feel about the rise of prediction markets. Over one-third of voters already use prediction markets, whether it's to check the forecasts or trade. That’s the top finding of our new poll on prediction markets, and yes, this was a surprise even to us. To be clear, prediction markets have already proven themselves to be a meaningful part of how Americans understand [politics](https://www.ap.org/media-center/press-releases/2026/ap-to-provide-kalshi-its-gold-standard-elections-data-ahead-of-primaries/), [sports](https://x.com/masonnystrom/status/2021333973838987594?s=20), and the [economy](https://www.nytimes.com/2026/02/11/business/economy/forecasts-prediction-markets-economy.html). From the way they are being used to monitor political campaigns and the economy in real time to the increasing intensity of debate over how to regulate them, prediction markets have proven themselves as one of the most significant developments in financial markets this century. But while the political debate over prediction markets grows louder by the week, one critical question has gone unanswered: What does the public actually think? We decided to find out. TLDR: Tens of millions of Americans use prediction markets, Americans want prediction markets regulated but not banned, and Americans’ views of them are still up for grabs. For this poll, we worked with Echelon Insights to poll 1000 U.S. Likely voters between February 13th and 18th, with the poll entering the field a few days after the Super Bowl to give the electorate time to digest any ads and commentary on these markets around the game. A more detailed methodology summary can be found below. 1)** 36% of voters already use prediction markets, and that number should change the entire regulatory conversation.** When asked what best described their personal experience with prediction markets, 11% of respondents said they put money on outcomes with them, and 19% said they browse the odds for information but don’t put money down, and 6% say they do both. This is far higher usage than we expected. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--27627ce224/11ec42d45abe01de1f9f439fa282e4df/asset-https-cdn-sanity-io-images-dgybcd83--27627ce224.jpg) 2)** Usage of prediction markets differs by age. **While 38% of those 18-34 and 28% of those 35-49 have put money down via prediction markets, just 3% of those 65 or older have. This represents an age chase even larger than crypto and dwarfs all other demographic divisions. Additionally, persons of color are far more likely to utilize prediction markets than white people, with 68% of white voters saying they never use prediction markets, compared to 53% of black voters and 42% of Hispanic voters. Men are also more likely to use prediction markets, with 46% of men saying they have used them versus 31% of women. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--17308d2b1c/e6dcbd58f9df25ab8e049a28562781b0/asset-https-cdn-sanity-io-images-dgybcd83--17308d2b1c.jpg) ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--d8697b09cf/19afb4bc742d0a7b5b7bd15660e7d0b0/asset-https-cdn-sanity-io-images-dgybcd83--d8697b09cf.jpg) 3)** Most Americans want prediction markets to be legal but regulated. **35% of respondents felt prediction markets should be legal. A plurality of respondents had mixed views, with 24% saying they should be legal in some instances and 15% saying they should be prohibited in some instances, such as for war and terror contracts. But respondents are more supportive of prediction markets than short selling, which 20% of respondents say should be generally prohibited, but just 29% say should be generally legal. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--eb6a9ad99e/3a45783b08f08d553e61e5b56afa3e3f/asset-https-cdn-sanity-io-images-dgybcd83--eb6a9ad99e.png) 4\) **Voters are still formulating opinions on prediction markets**. Overall, prediction markets are viewed as 32% favorable and 20% unfavorable among the 95% of respondents who have heard of prediction markets, with 48% stating they have no opinion. There is a big opportunity for prediction markets to tell their story to the American public over the next few months. The claims that voters have decided they dislike these markets are absolutely false, however. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--cc0188fcfa/5795e0be10661897460890988a6f1f68/asset-https-cdn-sanity-io-images-dgybcd83--cc0188fcfa.png) 5\) **The idea that Americans are consistently being bombarded with information about prediction markets is an elite phenomenon**. In the last 12 months, only 39% of respondents say they have heard, seen, or read something about prediction markets, while 51% said they have not. This figure is lower than we expected and speaks to the degree that prediction markets are still in their introductory phase to the electorate. Accordingly, just 11% said they were very familiar with prediction markets, with 29% stating they were somewhat familiar, 29% saying they were not very familiar, 20% saying they were not at all familiar, and 11% saying they had never heard of prediction markets. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--6a3ac63ad3/d51ca54ac3b2084b5ffe6a51167634dd/asset-https-cdn-sanity-io-images-dgybcd83--6a3ac63ad3.png) 6)** Prediction market users are more socially active than non-users**. Prediction market users are substantially more socially active than non-users. 87% of prediction market users talk to their family members weekly, while just 77% of non-users do. 46% of prediction market users play sports or games with others weekly, while just 11% of non-users do. And 19% of prediction market users host people at their house at least once a week, while just 7% of non-users do. Even as society is experiencing fears of reduced social interaction, prediction market users are proving to be a bulwark against those trends. Prediction market users also did not have a substantially different number of close friends than the general population. Overall, 51% people reported having just 1-3 close friends, with just 10% reporting having 8 or more close friends. Of those who personally put money on prediction markets, 53% reported having 1-3 close friends, and 8% reported having 8 or more close friends. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--ce0fd9b6a0/aa203eeb72729d0c35da38902fecdd87/asset-https-cdn-sanity-io-images-dgybcd83--ce0fd9b6a0.jpg) ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--936e0defdd/4d44da363c52a9f51cf4712a81a844cd/asset-https-cdn-sanity-io-images-dgybcd83--936e0defdd.jpg) **Conclusion** Americans want clear rules that protect participants while preserving the information value these markets provide. The takeaway for policymakers is clear: Americans aren't asking whether prediction markets should exist; they're already using them. The question now is whether regulation will catch up intelligently, or whether outdated frameworks will push a mainstream financial tool into regulatory limbo. The window to shape this market and public perception of it, is open, but it won't stay open forever. **Methodology** Echelon Insights conducted a survey on behalf of Paradigm to study voter views on prediction markets, fielded online from February 13-18, 2026 in English among a sample of N=1,008 registered voters in the Likely Electorate (LE) nationwide. The sample is a non-probability sample drawn from the Lucid sample exchange based on demographic quotas for registered voters in the likely electorate nationwide, and matched to the L2 voter file to verify respondents’ voter registration status. Measures taken to ensure data quality included measures to prevent duplicate responses, questions designed to disqualify inattentive respondents, and the removal of respondents from the data file who answered more than one-third of the questions they were asked in less than one-third of the median response time per question. The sample was weighted to reflect modeled turnout and demographic characteristics of the population of voters in the 2026 likely electorate based on a probabilistic model that incorporates data from the US Census Bureau's American Community Survey and Current Population Survey Voting and Registration Supplement, as well as L2 voter file data. Weighting dimensions included gender, age, race/ethnicity, education, region, party, and voting history. Calculated the way it would be for a random sample and adjusted to incorporate the effect of weighting, the margin of sampling error is +/- 3.5 percentage point. ## https://www.paradigm.xyz/writing/evmbench # Introducing EVMbench > Paradigm and OpenAI build EVMbench as an open evaluation framework that tests AI agents across detecting, patching, and exploiting vulnerabilities. There are routinely $100B+ in assets sitting in open source crypto contracts. As LLMs rapidly improve at finding exploits, it is important that we have visibility into and influence over the risks they could create for crypto. Together with OpenAI, we built EVMbench to measure exactly that. EVMbench is an open evaluation framework that tests AI agents across detecting, patching, and exploiting vulnerabilities. The benchmark uses real vulnerabilities from open code audits as well as custom tasks from unreleased contracts, containerized per-task so agents operate in realistic environments. We include an “answer key” for each task to verify the benchmark itself is solvable. We’ve also extended the benchmark harness into an auditing agent that can be found at [https://paradigm.xyz/evmbench](https://paradigm.xyz/evmbench). When we started working on this project, top models were only able to exploit less than 20% of the critical, fund-draining Code4rena bugs. Today, GPT-5.3-Codex exploits over 70%. The rate of improvement is incredible. It’s now clear to us that a growing portion of audits in the future will be done by agents. Hopefully this benchmark, harness, and agent serve both as a preview and an accelerant towards that future. *(also, thank you to OtterSec for significant support with implementing the frontend!)* For more details, read OpenAI's [research summary](https://openai.com/index/introducing-evmbench/) and our [joint academic paper](https://cdn.openai.com/evmbench/evmbench.pdf). ## https://www.paradigm.xyz/writing/clarifying-misconceptions-about-bitcoin-mining # Green Mining, Stable Grids: Clarifying Misconceptions about Bitcoin Mining > Bitcoin mining uses abundant, often renewable, and off-peak electricity to stabilize the grid and lower costs. Policymakers should treat it as an energy asset, not an energy threat. One of the top narratives swirling around politics at the moment is that AI and its attendant data centers are driving up energy prices for Americans. Americans are [protesting](https://www.npr.org/2026/01/25/nx-s1-5684321/trump-ai) data center permitting meetings or the centers themselves across the country. Politicians are announcing oversight investigations into how data centers may be driving up prices. Nonprofit group [videos](https://www.youtube.com/watch?v=wLX_w0TtBpY) on the subject are wracking up millions of views. And politicians of both parties are now [scrambling](https://www.nytimes.com/2026/01/15/business/energy-environment/data-center-energy-electricity-costs.html) to draft legislation that raises taxes on data centers or finds ways to reduce their impact on consumers’ energy bills. Too often, however, the role of data centers in changing energy prices is being unfairly mixed together with another nascent technology: Bitcoin mining. Yet, this connection fails upon even a cursory glance. There is a difference between using electricity that is abundant and electricity that is scarce. One does not constrain resources or significantly impact electricity prices, while the other can cause blackouts and make just keeping the lights on unaffordable. Bitcoin is the former. The misconception that Bitcoin is an energy hog is not just a few from a few voices in the policy space, but expressed by luminaries in Congress and at nonprofits. Senate Democrats have on [multiple](https://cryptonews.com/news/us-senate-democrats-draft-bill-to-curb-crypto-mining-emissions/?utm_source=chatgpt.com) occasions in the last few months expressed anxiety about crypto mining as being a major contributor to high energy prices, especially Bitcoin, even to the point of asking for federal [agencies](https://www.quiverquant.com/news/Press%2BRelease%3A%2BSenator%2BMarkey%2BUrges%2BFERC%2Bto%2BAddress%2BPotential%2BEnergy%2BCost%2BHikes%2Bfrom%2BData%2BCenters?utm_source=chatgpt.com) to take action. This negative view of energy usage of crypto is echoed in even stronger words by various non-profits, such as [Earthjustice](https://reinventalbany.org/wp-content/uploads/2025/10/2025.09.25-Env-Org-Comments-DGEIS.pdf?utm_source=chatgpt.com). Earthjustice even stated that the state government “shows that the vast majority of PoW \[mining\] in the state are powered by fossil fuels.” The narrative is only amplified by the mainstream media, which take these organizations and political leaders’ statements at face value without digging deeper. “Cryptocurrency mining uses huge amounts of power — and can be as destructive as the real thing,” climate columnist Elizabeth Kolbert [wrote](https://www.newyorker.com/news/daily-comment/why-bitcoin-is-bad-for-the-environment) in the New Yorker, drawing on severely flawed yet oft-repeated research which compared Bitcoin mining’s energy consumption per transaction to that of American households. “Bitcoin mines cash in on electricity — by devouring it, selling it, even turning it off — and they cause immense pollution,” [reads](https://www.nytimes.com/2023/04/09/business/bitcoin-mining-electricity-pollution.html) an investigation from the New York Times, making similarly flawed comparisons. And just last month the AP, without noting any supporting data, [attributed](https://apnews.com/article/carbon-pollution-trump-winter-data-centers-ai-680bbad6bab9a9e98421a48cb929d389) an unspecified portion of the 2.4% increase in U.S. greenhouse gas emissions that occurred during 2025 to the purported fact that “cryptocurrency mining meant more power plants producing energy.” But Bitcoin’s energy usage does not make it a menace. Bitcoin mining is naturally driven towards cheap, abundant, and renewable electricity. Often, this is energy that would otherwise go to waste, or which sees very low demand, and which is generated at off-peak times. This means that by its very nature, Bitcoin mining counter-balances the bulk of the average community’s energy consumption, bringing equilibrium to the grid — not strain. It is, in a word, bringing balance to our energy force. We spent five weeks combing through public and private data to better understand Bitcoin’s impact on the grid. Below are our key findings, as well as policy recommendations to ensure Bitcoin mining continues to have a positive impact (read more in this [presentation](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-e097c85e27/a8c4a13da7b9287d4c6e3b10e9f60fc8/asset-https-cdn-sanity-io-files-dgybcd83-p-e097c85e27.pdf) about our findings and recommendations). - Bitcoin mining is energy intensive, but less so than you might think - Bitcoin mining is driven towards cheap electricity - Bitcoin mining often uses more renewable energy - Hedges and ancillary assets programs amplify grid stabilization *In short, policymakers should use bitcoin mining as a tool, not a threat.* And if you’re worried about crypto having a bad impact on energy usage, these aren’t the droids you’re looking for. ***Bitcoin Mining is Energy Intensive, But Less So Than You Might Think*** Bitcoin mining is energy intensive by design. It uses a “proof of work” consensus mechanism, which involves servers around the world competing to find a number between 0 and $2^{32}$ [^1]. If any one entity controls 51% or more of the work that goes into guessing the correct number, they could derail the network. Thus, by requiring substantial energy to mine bitcoin, Satoshi Nakamoto made the Bitcoin network more secure. [^2] However, the amount of energy that Bitcoin mining consumes has been overblown, largely because studies estimating its energy consumption have used faulty methods. The [World Economic Forum](https://www.weforum.org/stories/2017/12/bitcoin-consume-more-power-than-world-2020/) claimed that Bitcoin would consume more energy in 2020 than the entire planet did in 2017, for example, when it ultimately only consumed [0.046%](https://coinshares.com/en/d/insights/research-data/the-bitcoin-mining-network/) of the world’s electricity that year. Another [popular study](https://www.nature.com/articles/s41558-018-0321-8) claims that Bitcoin mining alone will raise global temperatures 2 degrees in the next three decades. That study is still frequently cited, despite the fact that it has been [thoroughly](https://www.nature.com/articles/s41558-019-0533-6) [debunked](https://www.nature.com/articles/s41558-019-0534-5) in peer reviewed journals. That the past estimates have proven so faulty should be a sign to observers that their future estimates may also be faulty. But somehow, like a recurring prophecy of doomsday that never comes year after year, the Nostradamuses of Bitcoin energy usage still have a healthy flock of devotees. The most common methodological flaw in studies evaluating the impact of Bitcoin mining is that they estimate energy usage for Bitcoin by transaction. Bitcoin mining is effectively a competition between powerful computers to guess a specific number, called a nonce, whereby the winner is rewarded in Bitcoin. Bitcoin mining’s energy usage is therefore determined by the work it takes to find a nonce, not by the frequency or amount of transactions. Even the amount of energy used to find a nonce decreases 50% every few years, which often goes unaccounted for. Other times studies assume that energy production is limitless, and, therefore, that the amount of Bitcoin mining is uncapped, or mistakenly expect Bitcoin miners to continue operating even if their operations are unprofitable. In reality, Bitcoin mining uses about 0.23% of global energy at present, and is responsible for 0.08% of the world’s carbon emissions. Further, these percentages are set to decrease. Such are the hard mathematical constraints of a network with a fixed supply. This was predictable to those with the eyes to look and the ears to listen. ***Bitcoin Mining is Driven Towards Cheap Electricity*** One major reason Bitcoin’s impact on the environment is set to decrease is that Bitcoin mining is driven towards cheap energy, and cheap energy is often generated from renewable sources. It’s simple economics: Bitcoin miners profits are determined mainly by the price of the Bitcoin they mine, less the cost of the electricity to mine it. Every Bitcoin miner knows their “break even price” — i.e., the energy price above which their operations become unprofitable. For many miners today, that number is between $100 and $150 megawatts per hour. Electricity prices tend to peak in the morning before people leave for work, dipping in the afternoons, and then peak again in the evening when people come home. This trend is often referred to as the “duck curve,” because when you plot it on a graph, it roughly follows the shape of a duck. It is far more profitable for Bitcoin miners to operate when there is less demand, in the valleys of the duck curve, than in the peaks, when they might not make any money at all. In fact, many miners turn off completely during the peaks of the duck graph, because otherwise they’d operate at a loss. This trend is what makes Bitcoin good for the grid. We don’t expect a surge in power usage in the middle of the day for any reason absent a snow day, an earthquake, or some other manmade natural disaster — one that would surely make the news. Bitcoin miners can therefore map to this general trend, changing their mining on the fly if there are strange events in the power demand levels on a given day. In effect, Bitcoin flattens the duck’s back, but also provides a counterforce of demand to these patterns. That is grid stabilization quacking in action. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--3a2c39c00e/54812c483ecca54d03f7974be2a60a90/asset-https-cdn-sanity-io-images-dgybcd83--3a2c39c00e.jpg) ***Bitcoin Mining Often Uses More Renewable Energy*** It’s for that same reason that Bitcoin mining is increasingly fueled by renewably generated electricity. Wind and solar, the two renewable energy technologies that are operating at scale in markets where there’s a lot of Bitcoin mining, like Texas, generate the bulk of their energy at midday. This is also when the duck curve is at its low point, or when there is the least electricity demand. Because it is very difficult to store that electricity, or transmit it very far, a lot of that electricity goes to waste if it’s not used. Bitcoin miners, however, love to make use of this cheap, renewable energy — minting Bitcoin without putting pressure on the electrical grid. This also means free revenue for the green energy generating companies, bolstering their balance sheets and creating more money for further expansion. It would not be too much to say that ‘Bitcoin is powering the green transition.’ ***Hedges and Ancillary Assets Programs Amplify Grid Stabilization*** In some states, Bitcoin miners are allowed to hedge their bets on electricity prices by entering purchase agreements with energy suppliers where they buy electricity for a long period of time at a flat rate. This may sound like it disincentivizes Bitcoin miners from using electricity at off-peak times, but it doesn’t. Typically, this fixed rate is designed so that the company is overpaying for electricity the majority of the time in exchange for the ability to lock-in operating costs. In the rare times where electricity prices rise above the hedged rate they pay, Bitcoin miners can sell their electricity back into the market — increasing supply when there isn’t enough, and leveling out prices for other consumers. ![Electricity Price Comparison](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--3a40c3ddaf/124a410da559b8c3ecf5bda6c1389774/asset-https-cdn-sanity-io-images-dgybcd83--3a40c3ddaf.png) *85% of the time, prices look like this.* ![Electricity Price Comparison: Hedge vs. Market Opportunity](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--f037a9eb89/27af26382b19d3c910068c6a54797b9b/asset-https-cdn-sanity-io-images-dgybcd83--f037a9eb89.png) *15% of the time, a Bitcoin miner who has hedged their electricity costs can sell the electricity it pre-purchased back into the market.* The same goes for ancillary assets programs, whereby the grid operator can turn down or turn up a Bitcoin miner’s operations in return for paying them a flat fee. If the grid is seeing too much demand, agencies can turn down Bitcoin miners’ operations like a dimmer switch, restoring equilibrium. While it might sound odd to pay companies to not operate, ancillary services end up saving ratepayers more than it costs. The price of procuring ancillary services for ratepayers in Texas dropped by 74% from 2023 to 2024, for example, in large part because of the participation of Bitcoin miners. ***Policymakers Should Use Bitcoin Mining as a Tool, Not See It As a Threat*** Several states are considering laws that incentivize or disincentivize the growth of Bitcoin mining. We encourage lawmakers to examine closely the studies from which they draw their conclusions about Bitcoin mining’s energy consumption. As this research study makes clear, the narrative that Bitcoin mining unnecessarily taxes the grid and raises energy prices is at best misinformed, and at worst misinformation. Bitcoin mining is a tool for stabilizing the grid, and policies aimed at creating lower electricity prices should incentivize the industry’s growth. Bitcoin miners who use energy that would otherwise go to waste, or who participate in state-led programs to give energy control agencies more control over the grid, should be rewarded for their good behavior. Laws and regulations which amplify Bitcoin mining’s benefits are one of the easiest ways to make sure that electricity prices are kept low and energy generation is made more sustainable for communities across the United States. Bitcoin mining is not a hindrance to a balanced grid — it’s an asset. Smart policy will embrace this innovative technology to keep the lights on and power prices low, for everyone. [^1]: 4,294,967,296 [^2]: Even now, let us not lose our ability to be impressed by the OG token’s design ## https://www.paradigm.xyz/writing/paradigms--response-to-the-fca-and-bank-of-england # Getting the Details Right: Paradigm’s Response to the FCA and Bank of England > The Bank of England and FCA need to fix key design flaws in their crypto framework. Paradigm's response identifies where rigid rules risk leaving the U.K. behind. Governments worldwide are moving quickly to shape the future of stablecoins and cryptoassets. With the GENIUS Act passed in the U.S. and MiCA under implementation in Europe, the U.K. needs its own framework to stay competitive. With the Bank of England’s [consultation paper](https://www.bankofengland.co.uk/paper/2025/cp/proposed-regulatory-regime-for-sterling-denominated-systemic-stablecoins) on systemic stablecoins and the Financial Conduct Authority’s (FCA) [consultation paper](https://www.fca.org.uk/publications/consultation-papers/cp25-40-regulating-cryptoasset-activities) on cryptoassets activities, the U.K. is taking a significant step toward a comprehensive framework. Despite these steps, several regulatory decisions risk the U.K. falling behind. Paradigm submitted our response to both the Bank’s and FCA’s consultation. We support the U.K.’s ambition to become a global center for digital assets. The Chancellor is right that crypto can play a role in economic growth – the question is whether the regulatory details will match the rhetoric. Both regulators need to provide greater clarity to ensure the framework works as intended and remains compatible with other major regulatory regimes. Here’s where the Bank and FCA can improve their framework: 1. **Global firms shouldn’t have to split their operations.** Overly restrictive location requirements could force firms to separate their U.K. operations from their global trading activity. Not only would costs increase for U.K. customers, but jurisdictions with integrated cross-border operations would receive an advantage over U.K.-based firms. The rules should clarify that a U.K. branch can connect to global order books to avoid creating a separate trading system for the U.K. market. The Bank will need to lay out how its rules will work alongside MiCA and the GENIUS Act, focusing on foreign-issued stablecoins used by U.K. firms. Without clear rules, firms could face duplicative regulatory measures from the Bank. 2\. **The FCA needs to provide a clear test for decentralization.** Applying regulatory requirements when an identifiable entity exercises control is a realistic starting point for regulating DeFi. To do this, the FCA will have to define control and decentralization. This means using objective, technical indicators such as whether a protocol has privileged administrator keys, how it makes governance decisions, and how widely it distributes validation responsibilities. Wholesale and institutional DeFi shouldn’t be unintentionally caught in outdated rules, given that smart-contract protocols can support liquidity provision, collateral management, and post-trade processing. 3\. **60% falls short – The Bank should allow 80-90% backing in short-term gilts.** The latest proposal allows for up to 60% of backing assets in short-term U.K. government debt, which is an improvement compared to the originally suggested 100% central bank deposits. Major stablecoin issuers currently [hold](https://www.brookings.edu/wp-content/uploads/2025/10/The_Rise_of_Stablecoins_and_Implications_for_Treasury_Markets_Davidovic_Ghani_Moszoro.pdf) between 80 and 90% of their reserves in government securities. Requiring issuers to forgo yield without making reserves meaningfully safer would weaken the commercial case for operating in the U.K. Short-term gilts and central bank deposits share very similar credit profiles and liquidity characteristics – both are safe and liquid, and the rules should reflect that. A model that prioritizes cash over government securities sacrifices issuer viability without a commensurate reduction in systemic risk; it’s the financial equivalent of the security theater we do at airports of making people take their shoes off. We encourage the Bank to consider evidence from international equivalents on whether a higher proportion, up to 80-90%, would provide sufficient liquidity resilience without compromising par redemption. We also encourage the Bank to consider replacing a fixed 60:40 ratio with a flexible, risk-adjusted range determined on a case-by-case basis. This would allow the Bank to mitigate risks associated with issuer liquidity management and redemption delays while demonstrating openness to competitive commercial models. We do not generally apply one-size-fits-all models to other parts of fiscal regulation, especially when it comes to payment instruments; we should not similarly flatten regulations on stablecoins. **4. Holding limits are a solution in search of a problem.** The proposed per-coin holding limits, £20,000 for individuals, £10 million for businesses, risk constraining innovation before it even starts. This is a product for payments. How would Tesco, a supermarket that was the third-largest in the world in 2011 and had $69 billion in revenue in 2025, stay within these limits? Comparable constructs already exist without these caps. Money market funds, narrow banks, and payment firms all hold short-term, liquid assets that match their liabilities at par value. None face fixed ex-ante holding caps. The risks to monetary stability are best mitigated through robust liquidity and capital regulation, not arbitrary balance restrictions. The Bank's concern of potential deposit flight from the banking system echoes earlier debates around money market funds, where experience shows that liquidity management tools and supervisory monitoring proved more effective than arbitrary limits. At its worst, limits risk signaling instability to users, contradicting the Bank's objective of building trust between new and traditional forms of money. We urge the Bank to treat holding limits as a discretionary contingency deployable under defined stress conditions, not a permanent design feature. **5. The FCA should clearly define what it means to truly be decentralized.** We welcome the FCA's decision to avoid a separate DeFi perimeter and instead apply outcomes-based standards wherever there's a responsible controlling entity. But to drive clarity, the FCA should articulate what "decentralization" actually means using objective, technical criteria: no privileged admin keys, transparent on-chain governance, auditable upgrade mechanisms, and sufficiently distributed validators. The biggest opportunity for the U.K. may lie in wholesale and institutional DeFi—smart-contract protocols for liquidity provision, collateral management, and post-trade processes. The FCA should ensure these use cases aren't inadvertently constrained by a framework designed for retail. **What Comes Next** The U.K.-U.S. Transatlantic Taskforce provides an ideal forum to align standards before both regimes are finalized. We recommend the FCA and Bank of England draw on industry expertise, explore a transatlantic sandbox for crypto activities, and seek a path toward mutual equivalence with the U.S. Get these details right, and the U.K. becomes a serious destination for crypto firms. Get them wrong, and London watches this market develop from the outside. Read our full response to the Bank of England [here](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-6145819791/f9e0726ced1a6f42fbeaaa96d5b5e462/asset-https-cdn-sanity-io-files-dgybcd83-p-6145819791.pdf) and to the FCA [here](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-e742a6377a/aad331850f10627cb40c1cc44eca2a22/asset-https-cdn-sanity-io-files-dgybcd83-p-e742a6377a.pdf). ## https://www.paradigm.xyz/writing/introducing-paradigm-predictions # Introducing Paradigm Predictions > Paradigm Predictions is a tool for exploring the landscape of prediction markets. We aim to make prediction market data intuitive, accessible, and easy to explore. Today we’re releasing a preview of our new tool for exploring prediction market data. Check it out at [predictions.paradigm.xyz](https://predictions.paradigm.xyz). Prediction markets are a powerful technology that allows for financializing any belief about the future. This has led to the emergence of many new market categories: you can now trade on the weather. You can trade on Spotify leaderboards. You can trade on scientific discoveries. But prediction markets are so vast and novel that it can still be hard to see the big picture. The goal of this new tool is twofold: 1. Create a tool that makes it easier to explore prediction market data 2. Make these markets intuitive and accessible to a much wider audience *Embed* The core of this new tool is a browsable, zoomable, filterable map of the prediction market landscape. It has many features that make the data easy to explore: - You can zoom into market topics and subtopics like branches on a tree. The relative sizes show how active each of these different topics are. - Buttons at the top allow you to filter by different platforms and activity metrics. This allows you to do things like compare Kalshi to Polymarket. - The time slider at the bottom shows you how the markets evolve over time. You can do this over days, months, or the entire history of these platforms. We believe that 2026 will be a breakout year for prediction markets. There will be many high-profile events such as the World Cup, the Winter Olympics, and many elections around the world including Germany, Brazil, and the USA. Additionally, we are seeing prediction markets integrated directly into many large institutions such as [CNN](https://news.kalshi.com/p/kalshi-cnn-prediction-market-partnership) or the [Dow Jones](https://www.wsj.com/finance/stocks/polymarket-dow-jones-partner-to-display-prediction-markets-data-in-dow-jones-content-453605ed?gaa_at=eafs&gaa_n=AWEtsqdjQUaV1J0UVxH1WiIbU9u0UmANeQLbgoHcPa-AuDfQ-At4LguY82WEV-NAuKg%3D&gaa_ts=6966a756&gaa_sig=gy97i_n4mQLzzLXqMWsGAljWRYVj2LZFY67b9qxr4QjP6J8jFkkPiFY8TIIFp-VDeuByUcp0m60lleLAzBVnBA%3D%3D). These factors make it especially important to have powerful tools for understanding how these markets work. Today is the first iteration of the dashboard, but more features are on the way. Give us your feedback about things you love, hate, or would like to see (reach out to [@notnotstorm](https://x.com/notnotstorm/) on X). *Paradigm is an investor in Kalshi, a prediction market platform.* ## https://www.paradigm.xyz/writing/paradigm-files-ninth-circuit-amicus-brief-to-oppose-state-encroachment-on-federal-regulation # Paradigm Files Ninth Circuit Amicus Brief to Oppose State Encroachment on Federal Regulation > The Ninth Circuit should follow the clear statutory text and historical record. Federal law governs these markets, full stop. Allowing states to override that judgment would undermine regulatory certainty, stifle innovation, and unravel a system Congress carefully constructed. This month, Paradigm filed amicus briefs in[ KalshiEX LLC v. Hendrick](https://downloads.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-978c7f13c4/77bb4073a17810bcfea6f8dd384095ac/asset-https-cdn-sanity-io-files-dgybcd83-p-978c7f13c4.pdf) and[ Crypto.com v. Hendrick](https://downloads.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-7fab116f01/a95c2a4fce74aa6a51c0f0ef56e7da81/asset-https-cdn-sanity-io-files-dgybcd83-p-7fab116f01.pdf), two Ninth Circuit cases regarding Nevada’s efforts to treat federally regulated swaps as gambling. As we explained in our[ Third Circuit](https://www.paradigm.xyz/2025/07/paradigm-files-amicus-brief-to-oppose-state-encroachment-on-federal-regulation) (New Jersey) and[ Fourth Circuit](https://www.paradigm.xyz/2025/10/paradigm-files-another-amicus-brief) (Maryland) briefs, Congress decided decades ago that the CFTC, not fifty different states, sets the rules for these markets. Nevada’s position ignores that history, and the Ninth Circuit should not be similarly tempted by the Silver State’s false gloss on history. Beginning with the Commodity Exchange Act and culminating in the creation of the CFTC in 1974, Congress has consistently established and defended a uniform federal framework for derivatives markets, making clear that this framework preempts conflicting state law to ensure a comprehensive national rule base. This benefits consumers, regulated parties, and rule of law. As we argue in our brief, the contracts here fall squarely within the CFTC’s exclusive jurisdiction. Nevada’s attempt to regulate swaps under state gaming laws under a legal argument that amounts to not much more than “well, it quacks like a duck” would resurrect exactly the kind of fragmented regulation Congress affirmatively eliminated. New technology does not mean any state can make up new rules. We urge the Ninth Circuit to follow statutory text in this case, which is clear and unambiguous. ## https://www.paradigm.xyz/writing/joining-paradigm-rama-somayajula # Joining Paradigm as Head of Trading > Rama Somayajula joins Paradigm as Head of Trading I’m excited to share that I’ve joined Paradigm as the Head of Trading. I became interested in markets long before I knew trading was a career. In grade school, I spent hours unknowingly making markets on the Grand Exchange in RuneScape. I’d buy in-game items, repost them higher, and manage my inventory. At times, I’d get stuck holding something nobody wanted. Before then, I traded Pokémon cards, basketball cards, and anything else with perceived value on the playground. None of it felt like finance or markets at the time. It was simply a game of figuring out what something was worth, and how to trade it into something better. Lucky for me, I eventually realized I could make a career out of that curiosity. I started by trading U.S. equities at Citadel Securities, working in the most developed and competitive market structure in the world. I learned to think quantitatively about execution and risk, and how prices form when everyone reacts to the same information. Margins were razor thin and mistakes were unforgiving. Crypto was different. At Blockchain.com, I helped build and operate global market infrastructure at scale. At FalconX, I focused on derivatives, portfolio risk management, and liquidity across some of the most volatile and fragmented markets in existence. In traditional markets, you largely operate inside systems that have developed over decades. In crypto, you trade while also watching the same market constantly evolve. Regardless, the underlying challenges are similar: pricing risk, managing exposures, and building systems that work when markets get disorderly. That’s partly what drew me to Paradigm. While investors back the best founders, researchers work on interesting problems, and builders turn ideas into products, trading can bring another perspective: what happens when those systems meet capital, liquidity, and risk. As Head of Trading, I’ll be focused on our market infrastructure: how we execute, hedge, manage risk, and deploy capital across the portfolio. I’ll also spend time on questions that sit between trading, investing, and research: how liquidity develops around new asset classes, how incentives shape market behavior, and what changes as markets move onchain. I’ve spent my career so far in highly developed markets, and then in markets that were still taking shape. At Paradigm, I have the opportunity to work on both. If you’re a market maker, researcher, founder, or builder thinking about market structure, mechanism design, or how capital moves onchain, I’m reachable at rama@paradigm.xyz. ## https://www.paradigm.xyz/writing/paradigm-files-comment-with-banking-regulations-on-safety-and-soundness-standards # Paradigm Files Comment with Banking Regulators on Safety and Soundness Standards > Regulators should look to the statutory text and not subsequent commentary when defining what is a safe and sound practice. Banking regulators must uphold their mission of maintaining a safe and sound financial system while avoiding a retreat into outdated practices simply because they feel familiar. Our [comment letter](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-82e0304181/241ca66e8ccdc2d77681549afab36f9f/asset-https-cdn-sanity-io-files-dgybcd83-p-82e0304181.pdf) to the OCC and FDIC last month speaks directly to this point. Specifically, we address whether regulators should use “generally accepted standards of prudent operations” when making safety and soundness decisions. As we note in the letter, even the concept of “generally accepted standards of prudent operations” is a concept that is not grounded in statute and frankly a stalking horse for stasis. It is good that there are standards for how to engage in safe banking. As the laws that govern the OCC and FDIC make clear, ensuring our banking system is safe and secure is the overarching goal of our entire system of banking regulation for nearly a century. But the idea that all standards of safety and soundness are those which are generally accepted is not found in our statutes at all. Instead, it comes to us from thirty years after the FDIC was founded, via the testimony of a 1960s Federal Home Loan Bank Board Chairman. We do not apply the concept of adverse possession to our federal financial regulation regime. Just because everyone assumes something is part of a statutory regime does not make it so. We therefore recommend that the OCC and FDIC restore the original vision of safety and soundness as it was first established in text, where the regulators consider novel approaches on the merits. It is in everyone’s interest that the banking system is safe and sound, including those of us in the crypto, fintech, AI, or prediction markets spaces. But to have a safe and sound banking system means neither abandoning all past practices nor refusing to change. As was famously said by a former U.S. President, “those who make reform impossible make revolution inevitable.” Only by having the ability to constantly innovate and consider how new innovations are able to improve our system can we ensure our banking system remains safe, sound, dynamic, and growing. ## https://www.paradigm.xyz/writing/data-banishes-fear # Data Banishes Fear > A new report on how stablecoins interact with the banking system and credit creation suggests stablecoins will be positive for the banking system and credit provision on net. Over the last few years, there has been an explosion of commentary about stablecoins. For those of us who believe in the fundamental potential of truly digital dollars to revolutionize our financial system, stablecoins represent a profound opportunity. They promise to reshape our financial system, from enabling multibillion-dollar transactions to settle instantly, to helping a young immigrant send a few dollars from his weekly paycheck to his abuela at a fraction of today’s cost. For the skeptics of stablecoins, the inverse is true. We frequently see overwrought predictions that stablecoins will lead to the destruction of the banking system. And many critics have predicted that stablecoin legitimization will lead to a financial crisis worse than 2008. These dueling narratives have, frankly, put crypto at a disadvantage. Policymakers tend to fixate on fear and risk rather than opportunity and innovation, especially when echoes of 2008 are invoked. Now, with GENIUS moving into implementation and regulators facing difficult decisions on how to finalize stablecoin rules, the need for rigorous data and robust modeling has never been more urgent. To that end, Dr. Lin William Cong of Cornell University conducted a [robust analysis of the impact of stablecoins on the banking system](https://cornell.box.com/s/njs6ovw8mvtyj06slrlzlcrwjij7a0y1), with a special focus on how stablecoins will influence deposit growth in the banking system and its ability to support the credit creation process for the broader economy. The analysis, supported by Paradigm, Coinbase, PayPal and Stripe, is predictive but also based on how deposit growth has operated in the recent past. Dr. Cong developed two models, with one model assuming that current regulatory and structural incentives for banks persist following GENIUS and the other model assuming those incentives dramatically change. Put more plainly: Model one assumes that banks operate much as they do at present but with stablecoins simply added into the financial system’s bloodstream. The second assumes banks operate differently, potentially because they are allowed to issue stablecoins directly. Both assume high levels of stablecoin adoption. **The takeaway: Both models found that stablecoin adoption should be neutral *****or help *****credit creation and bank deposits.** Under the first model, depicted below, the impact of high stablecoin adoption on both deposits and bank lending will be largely neutral unless and until stablecoin yields cross the 4% mark. [^1] If stablecoin yields increase above this level, to roughly 6%, then the impact on both bank deposits and loans is positive. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--98da3fae75/c799d33f83da383c88465da2ad494b50/asset-https-cdn-sanity-io-images-dgybcd83--98da3fae75.png) To repeat: If stablecoins have yields of between 4-6%, high stablecoin adoption will actually INCREASE bank deposits and bank loans. The reason for this perhaps surprising conclusion is simple: competition. At those yield levels, stablecoins are competitive with the money large institutions and retail investors can make with good savings accounts. [^2]To avoid having those deposits leave banks for stablecoins, banks will have to take steps to improve their deposit rates and also expand credit intermediation. This is the long vaunted competition that many observers have asked exists against banks, and the result is banks taking money out of their profits to provide better returns to their customers. For the second model, Dr. Cong was able to engage in an illustrative analysis of the impact of stablecoins on bank deposits and loans. Citing recent scholarship on distributional effects of stablecoin growth, he estimated that impacts are unlikely to be uniform across banking. Deposits may well in this scenario migrate from “rate-insensitive, branch-based institutions towards rate-sensitive digital banks and stablecoin exchange platforms offering similar convenience and liquidity advantage.” This single directional flow does not mean there will be a uniform trend of stablecoins pulling deposits out of banks like some financial tractor beam. In this scenario, digital banks would be well-positioned to benefit from this trend, in part because their funding models already use market-based pricing and they have more flexible balance sheets. As tokenization grows, it is also these digital banks that are “likely to have the digital infrastructure to integrate stablecoins or tokenized deposits.” In this way, the stablecoin flows should not lead out of banks entirely but rather from the more traditional and illiberal banks towards those seeking to grow and change. Even those institutions which face the risk of flight may not suffer in the medium term. As the report notes, “Competition from stablecoin issuers and rate-responsive banks can erode the “convenience premium” traditionally captured by incumbents, narrowing deposit-lending spreads and increasing the pass-through of market rates to consumers.” Such trends tend to force incumbents to build better businesses and increase credit intermediation operations. While deposits could be redistributed within the banking system, it may ultimately benefit banking customers through higher returns and better, cheaper financial services. Additionally, much of the capital that supports and fundamentally comprises the stablecoin ecosystem, such as T-Bills, could well remain within the banking system in the form of short-term securities and custodial reserves. The financial assets form may shift within the system like ice cubes in a glass warming into water, but the amount of liquid would remain largely unchanged. It is true that some banks may face harder times, but the consumers of the banking system should benefit, and ultimately it is the users of the banking system and the system as a whole we care about, not each individual bank. To require that no technological or financial change could occur that does not make a single bank worse off is neither a worthy goal or something that is achievable in this or any reality, but the stuff of pure rhetorical fantasy. Looking at both models holistically, one thing is clear: There is good reason, backed by data, to think that stablecoins will not harm the deposit and loans provided by the banking system. Instead, stablecoins seem likely to make the system more, in a word, stable. As we enter the new year, the hard work of actually implementing the GENIUS Act will begin in earnest. Let us all resolve that the best way to promulgate regulations on stablecoins is not to fall prey to vague anxieties and attenuated fears but to focus as much as possible on data-driven policy-discussion. In the face of fear, data and modeling are our best light. [^1]: Which is the current rough yield available for USDC on Aave [^2]: If yields do go above 6%, then there is expected to be a reduction in bank deposits and loans. This conclusion also makes sense. At a certain point, there is no additional money in the till for banks to find to compete against stablecoins. Of course, such high yields would also entail either yield-farming that is much riskier and thus not serving the same function as bank deposits or federal interest rates higher than any we have seen this millennium. Both scenarios appear extremely unlikely ## https://www.paradigm.xyz/writing/polymarket-volume-is-being-double-counted # Polymarket Volume Is Being Double-Counted > After analyzing Polymarket’s market structure, event data, and smart contracts, we discovered that most Polymarket analyses and dashboards have been mistakenly double-counting volume. After analyzing Polymarket’s market structure, event data, and smart contracts, we discovered that most Polymarket analyses and dashboards have been mistakenly double-counting volume. Polymarket’s onchain data is quite complex, and this has led to widespread adoption of flawed accounting methods. However, this data becomes easy to work with using the principles explained below. This article contains the following sections: ** 1. Anatomy of a Polymarket Trade** How do Polymarket trades manifest in onchain data? **2. Not All Matches Are Swaps** How do prediction market matching engines work? **3. Prediction Market Volume Metrics** What is the right way to measure volume? Main Claims: 1. The common approach of summing Polymarket’s `OrderFilled` events leads to double counting volume. This approach double counts both the number of contracts traded and USD cash flow. For example, a simple [sale](https://polygonscan.com/tx/0xbf47fbf1bc113a7ec50a1103921265ba5d8fbe6dfb4d12a1c78c61c8fdb195bf) of `YES` tokens for $4.13 gets recorded as $8.26 worth of volume. This is because there are separate `OrderFilled` events representing the maker side and taker side of the trade. 2. Volume on prediction markets should be measured using a **one-sided **volume metric, such as taker-side volume or maker-side volume. There are multiple valid ways to measure prediction market volume, but summing up all `OrderFilled` events is not one of them. This article is unrelated to wash trading or other types of volume classification. We are simply describing how to measure the total raw volume occurring on Polymarket, especially in a manner that enables apples-to-apples comparisons to other prediction market platforms. ## Anatomy of a Polymarket Trade We will begin by describing the onchain data associated with each Polymarket trade. Polymarket trade transactions all follow a rigid template: - There is **at most one** group of matched Polymarket orders per Polygon transaction. - Each set of matched orders has **exactly one** taker and **at least one** maker. - Trade transactions are submitted by ~50 Polymarket-affiliated EOA’s. ### Event Structure Polymarket uses 2 EVM events to track trades: `OrderFilled` and `OrdersMatched`. Both events have these fields: 1. `makerAssetID`: either 0 (for USDC), or the `YES` token id, or the `NO` token id 2. `takerAssetID`: either 0 (for USDC), or the `YES` token id, or the `NO` token id 3. `makerAmountFilled`: amount of `maker` tokens 4. `takerAmountFilled`: amount of `taker` tokens The `OrderFilled` event also has a `maker` field and `taker` field that we describe below. ### Event Sequence Each Polymarket trade transaction has the same sequence of events: 1. There is **at least one** “maker-focused” `OrderFilled` event 2. one of these events is emitted for each `maker` involved in the transaction 3. the `maker` values of these events are usually (but not always) distinct 4. all of these events have the same `taker`, which is the overall taker of transaction 5. neither the `maker` nor `taker` of these events are Polymarket exchange contracts 6. Then there is **exactly one** “taker-focused” `OrderFilled` event 7. its `maker` is the transaction’s overall taker 8. its `taker` is a Polymarket exchange contract (CTF or NegRisk) 9. Finally there is **exactly one** `OrdersMatched` event 10. it has the same `makerAmountFilled`` `and `takerAmountFilled` as the “taker-focused” **OrderFilled** event of (2) Critically, item (2) is *redundant* with item (1). This final `OrderFilled` is a second representation of the same trades, rather than an additional trade between the taker and Polymarket exchange. It does not represent additional economic activity, nor does it represent any additional transfer of risk between market participants. Furthermore, a common point of confusion is that the total token volume recorded by `OrderFilled` events is roughly 2x the total token volume recorded by `OrdersMatched` events. This discrepancy is resolved by realizing that each transaction contains two sets of `OrderFilled` events that both represent the same trades. An additional point of confusion is that these two sets of `OrderFilled` events, corresponding to makers and takers, can measure different amounts of volume for an individual trade. This is resolved by realizing that makers and takers can experience different amounts of volume during split trades and merge trades. But aggregated over many trades, on the timescales of days or months, the amount of maker volume and taker volume tend to converge to the same value. We elaborate on this in a later section. ### Smart Contract Structure Polymarket’s event sequence is further clarified by looking at the Polymarket exchange contracts. Each trade is facilitated by one of two exchange contracts, [CTF](https://vscode.blockscan.com/137/0x4bfb41d5b3570defd03c39a9a4d8de6bd8b8982e) or [NegRisk CTF](https://vscode.blockscan.com/137/0xc5d563a36ae78145c45a50134d48a1215220f80a). The portion of code that emits `OrderFilled` and `OrdersMatched` is shown in **Figure 1**. This code is the same in both contracts. *Figure 1: Event-emitting portion of Polymarket exchange smart contracts. The number labels correspond to the items in the “Event sequence” section above.* Each Polymarket trade follows the same sequence: 1. Enter the contract via the `matchOrders()` function,
which simply calls `_matchOrders()` 2. Transfer taker’s tokens from the taker to the exchange contract 3. `_fillMakerOrders()` loops through the makers. For each one: 4. Compute fees to the maker 5. Perform split/merge operations if necessary
(see next section) 6. Transfer maker tokens from the maker to the exchange contract 7. Transfer taker tokens from the exchange contract to the maker 8. Transfer maker fees from exchange contract to fee collector 9. Emit an `OrderFilled` event describing the portion of the taker’s trade filled by the maker 10. Transfer makers’ tokens from the exchange contract to taker 11. Transfer taker fees from the exchange contract to fee collector 12. Emit an **OrderFilled** event describing the entire set of fills 13. Emit an **OrdersMatched** event describing the entire set of fills In this design the exchange contract acts as a router. It is either the sender or receiver of each token transfer. Critically though, the exchange takes no positions, it provides no funds, it assumes no risk, and it is not the counterparty to any trade. The only trades that occur are between the taker and each of the makers. Thus, the two types of `OrderFilled` events are two representations of the same trades and they should not be added together. It should be noted that none of the `OrderFilled` events contain incorrect information. There are many reasons why a smart contract might be designed to emit extra events (e.g. it might make it easier to report each user’s history on the frontend). Incorrect information only enters the picture when someone attempts to compute volume by summing up all of the `OrderFilled` events. ## Not All Matches Are Swaps Beyond the redundant `OrderFilled` emission, Polymarket transactions can also be confusing because the matching engine can match orders across the `YES` and `NO` orderbooks within the same multileg trade. These are not conventional swaps, and at first glance they can appear to produce accounting that seems arbitrary or imbalanced. Take [this Polymarket trade ](https://polygonscan.com/tx/0x4fce56dff16a86e8c55e04ebb9406026553e11f5236e7210b7b51803f093dc76)for example, with Polygonscan representation shown in **Figure 2**`.` *Figure 2: Example of a “confusing” Polymarket trade* Polygonscan summarizes this transaction as “Place Bet of $28.41”. It was an active market that had not yet resolved. So why is there a party that nets out $6780? What actually happened here: - The taker `0x0c45` sold $90 of YES shares in a market order - This taker order was filled by matching with two market makers - The first market maker `0xd9A5` bought $28 of `YES` - The second market maker `0x8E8C` sold $6780 of `NO` To understand the last bullet, it is necessary to understand the `YES-NO` Split-Merges ### YES-NO Split-Merges Polymarket represents positions using the dual assets of `YES` tokens and `NO` tokens. In the main [smart contract](https://polygonscan.com/address/0x4d97dcd97ec945f40cf65f87097ace5ea0476045) controlling these tokens, the only way to interconvert between these `YES` and `NO` are split and merge operations: 1. **Split:** Exchange $1 for (1 `YES` token + 1 `NO` token) 2. **Merge:** Exchange (1 `YES` token + 1 `NO` token) for $1 Prior to the transaction above, second market maker `0x8E8C` had opened sell orders for their `NO` tokens. The matching engine figured out that some of the `YES` tokens being sold by taker `0x0c45 `could be merged with some of the `NO` tokens being sold by maker `0x8E8C`, which would produce sufficient USDC to partially fill both orders. Then to execute the trade, the exchange contract 1) gathers the `YES` and `NO` tokens from both parties, 2) merges them, and 3) then distributes the proceeds pro rata according to the trade’s execution price. ### Token Accounting Here is the sequence of token transfers in the transaction (**Figure 3A**), along with the associated net balance changes (**Figure 3B**). The exchange is the sender or receiver of each of these transfers. The vault is the “Conditional Tokens” contract that stores all of the USDC backing the `YES-NO` token pairs. *Gallery (2 images)* ### Market Structure of Splits and Merges Versus Swaps The market structure can be described as follows: Polymarket’s matching engine matches makers and takers. Some of these matches are conventional swaps, where one market participant transfers their risk exposure to another market participant in exchange for USDC. This works similarly to spot exchanges like Uniswap or Binance. But the `YES-NO` structure of prediction markets also allows another type of match using a split or merge. In these special matches: - The maker and taker are either both sending or both receiving USDC (instead of there being one sender and one receiver). - The buyer and seller mutually agree to take opposite sides of a market, either to create new open interest or to close existing open interest. The open interest in the system increases or decreases (instead of remaining constant as in a spot swap). - The maker and taker are usually sending or receiving different amounts of value (instead of the buyer’s USD delta being approximately the same size to the seller’s USD delta). **Split trades** are matches where maker and taker agree to both exchange their USDC for shares, and then one party receives the `YES` exposure and the other receives the `NO` exposure. **Merge trades** are matches where maker and taker agree to exchange their opposing `YES` and `NO` shares for USDC. With these principles in mind we can describe the [example trade](https://polygonscan.com/tx/0x4fce56dff16a86e8c55e04ebb9406026553e11f5236e7210b7b51803f093dc76) from above in more precise terms. It was a two-leg trade, where the first leg was a swap, and the second leg was a merge. - In the swap leg, the taker exchanged `3,157.02 YES` tokens for $28.41, and the maker exchanged $28.41 for `3,157.02 YES` tokens. Both maker and taker experienced the same amount of cash flow volume, $28.41. They also experienced the same amount of contract volume, `3,157.02`. - In the merge leg, the taker exchanged their `6,842.98 YES `tokens for $61.59, and the maker exchanged `6,842.98 NO `tokens for $6781.39. The taker and maker experienced the same amount of contract volume `6,842.98,` but different amounts of cash flow volume. - Summing the `OrderFilled` event report simply adds the maker volume to the taker volume, as there are separate `OrderFilled` events representing the maker side and taker side of the trade. - It reports a total contract volume of `3,157.02 + 3,157.02 + 6,842.98 + 6,842.98 = 20,000` - It reports a total USDC volume of `28.41 + 28.41 + 61.59 + 6781.39 = $6899.80` As explained in the next section, there are multiple valid ways to interpret how much volume occurred in the second leg of the trade, but adding up maker and taker is not one of them. This sum is a form of double counting that produces a volume number that is not comparable to volume metrics of other prediction market trading venues. ## Prediction Market Volume Metrics There are multiple valid ways to compute volume on prediction markets. However, all of these approaches roughly agree on a volume value around 50% of the Polymarket’s `OrderFilled` sum. For a complete accounting, we will start with the 8 types of simple trades that occur on Polymarket: 1. Taker buys `YES`, maker sells `YES` (swap) 2. Taker buys `NO`, maker sells `NO` (swap) 3. Taker sells `YES`, maker buys `YES` (swap) 4. Taker sells `NO`, maker buys `NO` (swap) 5. Taker buys `YES`, maker buys `NO` (split) 6. Taker sells `NO`, maker sells `YES` (merge) 7. Taker sells `NO`, maker sells `YES` (merge) 8. Taker sells `YES`, maker sells `NO` (merge) We built a [simulator](https://docs.google.com/spreadsheets/d/1oqqb7J-rb6-kw4rKBK-H-SWtJfOLV7PuYcCPZpgkPv8/edit?gid=0#gid=0) that illustrates how various trading metrics behave under each of these 8 trade types. For each trade type, the simulator computes 1) maker/taker balance changes, 2) open interest change, and 3) a variety of volume metrics. An example output is shown in **Figure 4.** *Figure 4: Polymarket volume simulator spreadsheet* The only two inputs needed for the simulation are 1) the `YES` price and 2) the number of contracts traded. You can make a copy of the spreadsheet and change these parameters to perform your own simulations. For simplicity, we assume zero fees and (`NO` price) equals exactly $1 - (`YES` price). We will now go through each item in the simulator output. ### Account Deltas and Open Interest Changes The first few columns in the simulator track how much the open interest and maker/taker balances change during each trade. Take note of a few invariants: - For each trade type, the taker and maker always take opposite positions. One is long `YES` resolution, and the other is short `YES` resolution. - The taker and maker `YES` and `NO` deltas always have the same absolute value. This is different from their USDC deltas, which can have different absolute values. - Split trades always increase open interest, merge trades always decrease open interest, and swap trades always leave open interest unchanged. ### Volume Metrics There are two categories of prediction market volume metrics in common use: 1. ***Notional Volume:*** number of contracts traded 2. ***Cash Flow Volume:*** the amount of USD exchanged at time of trade Computing these metrics for *swap trades* is straightforward. The** notional volume **is simply the number of contracts traded. The **cash flow volume** is the number of contracts traded multiplied by the share price. For both of these volume metrics, Polymarket’s `OrderFilled` sum gives a value that is 2x the correct value. Computing these metrics for *split trades* and *merge trades* is more complicated because they are not swaps in the conventional sense (see the **Splits and merges versus swaps** section). In a conventional swap, the maker and taker experience the same amount of volume. But in a split trade or merge trade, the maker and the taker can experience different amounts of volume. We are not opinionated about whether to measure the maker’s volume, the taker’s volume, or something in between. However, simply adding the two together is double counting, just as it would be with a swap trade. With these considerations in mind, computing the *notional volume* for split trades and merge trades becomes straightforward. It is simply the number of contracts that are split or merged. Computing the *cash flow volume* for split trades and merge trades is the most complicated case. As mentioned above, the maker and taker will experience different amounts of cash flow. Whether to focus on the maker’s cash flow, the taker’s cash flow, the maker taker mean, or some other approximation (like share-priced volume) can depend on the context. These metrics can each produce different volume values for an individual trade. However, these metrics all produce about the same volume numbers when aggregated over longer timescales of days or months (see **Figure 5 **below). Thus, the exact choice of cash flow metric is often unimportant. The only important note is that summing up `OrderFlow` events does not agree with these volume metrics, and it instead produces a value about 2x as large due to double counting (see **Figure 5** below). ### Polymarket USDC Volume Metrics ![Figure 5: Monthly Polymarket volume under different metrics. The Taker-side volume, Maker-side volume, and share-priced volume are each around half of the OrderFilled sum. One indicator that a Polymarket volume chart might be using OrderFilled sums is checking whether monthly volume for 2024-10 and 2024-11 is around $2.5B.](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--d3f46a8b05/ad4f7a43059cd2ece866cc183ac4d910/asset-https-cdn-sanity-io-images-dgybcd83--d3f46a8b05.png) *Figure 5: Monthly Polymarket volume under different metrics. The Taker-side volume, Maker-side volume, and share-priced volume are each around half of the OrderFilled sum. One indicator that a Polymarket volume chart might be using OrderFilled sums is checking whether monthly volume for 2024-10 and 2024-11 is around $2.5B.* ### Realworld Examples The final columns of the spreadsheet provide 4 examples of historical transactions for each of the 8 trade types. The price and size parameters of each example can be input into cells A1 and A2 of the spreadsheet to simulate the sum of each transaction’s `OrderFilled` events. ![Figure 6: The spreadsheet contains 4 examples of realworld trades for each of the 8 trade types](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--2bf45177db/18b97d2b9d11dc6d97aebb8a4f3c44f9/asset-https-cdn-sanity-io-images-dgybcd83--2bf45177db.png) *Figure 6: The spreadsheet contains 4 examples of realworld trades for each of the 8 trade types* A view of these examples is shown in **Figure 6**. Note also that these examples are drawn from both the Polymarket CTF Exchange and the Polymarket Negrisk exchange, and each exchange has identical `OrderFilled` emissions. One of the difficulties of analyzing Polymarket data has been the large number of trade types. Even with knowledge of the 8 trade types, it is not easy to find or identify specific trade types using a block explorer. These 32 example trades should be a useful resource for anyone trying to learn more about Polymarket data. ### Which Metrics To Use? Here is a comparison of the metrics mentioned in a single view: *Figure 7: Comparison of prediction market volume metrics* For notional volume, measurement is straightforward. Simply measure the number of contracts traded. For cash flow volume there are multiple possibilities. Can use the cash flow of the maker, or the cash flow of the taker, or an average of the two. Each of these can be derived from Polymarket’s onchain data, and each produces similar volume numbers when aggregated over days or months (**Figure 5**). Taker-side volume can be obtained by filtering and summing `OrderFilled` events where the taker field is equal to one of the two exchange contracts (CTF 0x4bfb41d5b3570defd03c39a9a4d8de6bd8b8982e and NegRisk 0xc5d563a36ae78145c45a50134d48a1215220f80a). Maker-side volume can be computed by filtering and summing `OrderFilled` events where the `taker` field is not equal to either of these exchange contracts. ## Conclusion Prediction markets are rapidly evolving into a critical financial sector. As the category matures, the industry should converge on consistent, transparent, and objective reporting standards. This is particularly important for comparing activity across platforms, as well as assessing the growing role of prediction markets in everyday life. In our investigation into this topic, we discovered that most Polymarket analyses and dashboards have been unintentionally double-counting volume. The confusion results from interacting layers of complexity: 1. Swap matches and split/merge matches lead to 8 possible types of single-leg trades, and an even larger variety of multi-leg trades. 2. Each type of trade leads to slightly different event emissions from Polymarket contracts. 3. Although no single Polymarket event contains incorrect information, the event stream contains redundant representations of the maker side and taker side of each trade. Simple summation of these events leads to double counting. These factors are mostly undocumented, and standard tools like block explorers are not sufficient for untangling the complexity. A more precise account of this data only emerges when examining multiple lines of evidence (market structure, event emissions, and smart contract architecture). But taken together, these lines of evidence paint a clear and consistent view of how prediction market trades can be measured and compared. * Massive thanks to *[*dash*](https://x.com/datadashboards)*, *[*Allium*](https://x.com/AlliumLabs)*, *[*Dan Smith*](https://x.com/smyyguy)*, *[*Chaos Labs*](https://x.com/chaoslabs)*, *[*Ricardo de Arruda*](https://x.com/notawizard)*, *[*Ciamac Moallemi*](https://x.com/ciamac)*, *[*Dan Robinson*](https://x.com/danrobinson)*, and *[*frankie*](https://x.com/FrankieIsLost)* for feedback + conversations that helped untangle this data* *Disclosure: Paradigm is an investor in Kalshi, a competitor to Polymarket.* ## Appendix: Examples in the Wild Compare the charts below to **Figure 5**. Note that a value of ~$2.5B monthly volume in the months of 2024-10 and 2025-11 generally indicates that a dashboard is computing volume by summing up all `OrderFilled` events. We have validated this information with multiple dashboard creators and data analysts. DefiLlama, Allium, Blockworks, and others are now updating their dashboards to remove the double-counting. ![Allium](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--cc6ed0c66a/9212aaf1b031c1afc8e9e800db0140dd/asset-https-cdn-sanity-io-images-dgybcd83--cc6ed0c66a.png) ![Blockworks](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--b2771968a6/f6ca0f41f13b42900c58c7de7be55f25/asset-https-cdn-sanity-io-images-dgybcd83--b2771968a6.png) ![Defillama](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--e926407233/382bbb014656ddf5cb0d7b2cf0237810/asset-https-cdn-sanity-io-images-dgybcd83--e926407233.png) ![Dune 1](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--62732280d8/8fae7e83f27c7a7b3a152f1526257432/asset-https-cdn-sanity-io-images-dgybcd83--62732280d8.png) ![Dune 2](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--552588d461/dcd5c0d99f92157433fbe9ca7d6bcd0a/asset-https-cdn-sanity-io-images-dgybcd83--552588d461.png) ![Dune 3](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--62692657a8/15ffcf6aa0caa20fb9b80526322032a6/asset-https-cdn-sanity-io-images-dgybcd83--62692657a8.png) ![Dune #4](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--c227437f3e/027483a812c2af8944954a7346c64140/asset-https-cdn-sanity-io-images-dgybcd83--c227437f3e.png) ![Dune #5](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--c1ddb0e688/cc2661a7d3737aaa0a0a9c5eb5afbff2/asset-https-cdn-sanity-io-images-dgybcd83--c1ddb0e688.png) ![Token Terminal](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--37155b5a93/1a98890f6ae02efb7d5002fb889e0250/asset-https-cdn-sanity-io-images-dgybcd83--37155b5a93.png) ## https://www.paradigm.xyz/writing/bridging-the-gap-how-crypto-expands-financial-access-for-america-s-underbanked # Bridging the Gap: How Crypto Expands Financial Access for America’s Underbanked > No group stands to gain more from crypto access than the unbanked and underbanked. No group stands to gain more from crypto access than the unbanked and underbanked. Crypto has always aimed to fix the errors of traditional banking, and few failures are bigger than leaving billions shut out of the system. Globally, 1.4 billion adults remain unbanked. In the U.S., 6% of households lack reliable access to traditional financial services, and those are disproportionally low income, Black and Hispanic, and disabled. Policymakers should take note. Regulatory clarity is a key unlock. The GENIUS Act was an important first step, but Congress must now follow through with market structure legislation. *Source: Federal Reserve Board* This is not just theoretical. Over the course of six weeks, we spoke with 11 people in this demographic to better understand the stories behind the numbers. Their testimonies reveal just how vital crypto has become. This group is not simply dabbling in crypto — they’re using digital assets for peer-to-peer payments, essential purchases, even to collect their paychecks. Many describe it as safer, faster, and cheaper than banks, and some are already using it to build significant wealth. ![Pseudonym: Simon Age: Mid 20s Country Of Residence: USA Immigrant: Yes Education Level: Undergraduate Political Ideology: Moderate](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--9a4268161d/a70ad1cd1cb1688ab1433d85fc473b5d/asset-https-cdn-sanity-io-images-dgybcd83--9a4268161d.png) *Pseudonym: Simon Age: Mid 20s Country Of Residence: USA Immigrant: Yes Education Level: Undergraduate Political Ideology: Moderate* ## Crypto as a Tool for Wealth Generation The unbanked are disproportionately young and low-income. According to The Federal Reserve Board, 13% of adults aged 18-29 are unbanked, compared with only 2% of those over the age of 60. 22% of adults with an income below $25,000 are unbanked, while that number shrinks to just 1% of adults with an income of $100,000 or more. For interviewees, crypto filled a gap in wealth-building opportunities. Because they had full control over their assets, rather than trusting an intermediary, the people we interviewed were more interested in learning how to grow and save their wealth. Crypto “motivates me to save money, so I can let it sit in my wallet and let it increase,” Simon, a 27-year old immigrant living in the United States, explained. “It helps me have this better investing and savings mindset.” *It helps me have this better investing and savings mindset.* ## Changing Perceptions of Trust and Safety Nearly all of the interviewees said that the main reason they used crypto was because they found it more trustworthy and safe than traditional finance. They doubted banks would process transactions reliably, keep accounts open, or avoid freezing funds without cause. This perspective is reflected in federal data: *Source: FDIC* When asked about scams or technical difficulties, those who had bad experiences blamed themselves, rather than blaming the technology itself. Simon, who had once sent his crypto to a bad address, for example, put it this way: “It wasn’t about it being crypto. It was because I made a mistake, because I didn’t know how it worked…But banks — I don’t trust banks at all actually. I don’t even mess with relying on them.” ![Pseudonym: Elijah Age: Mid 20s Country Of Residence: USA Immigrant: No Education Level: Undergraduate Political Ideology: Moderate](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--84877ce8c3/634aff3d8d7ec01c8f134faa7e7fff4d/asset-https-cdn-sanity-io-images-dgybcd83--84877ce8c3.png) *Pseudonym: Elijah Age: Mid 20s Country Of Residence: USA Immigrant: No Education Level: Undergraduate Political Ideology: Moderate* ## The Pursuit of Efficiency Users interviewed found transacting with crypto to be significantly faster and cheaper than traditional financial transactions. In fact, the word numerous interviewees used to describe sending crypto transactions was “seamless.” Interviewees spoke fondly about how they could send payments to friends, or people with whom they were doing business, and watch the payment arrive in the recipient's wallet within a few minutes. Elijah, a 25-year-old U.S. citizen, described how crypto’s speed and efficiency made it easier for him to collect vital payments from his clients. He works in graphics and social media, managing the accounts of several people who live in other countries. When wire transfers work, they take several days, and they often are delayed for triggering fraud or anti-money laundering concerns. Crypto solved his cross-border payments headaches. “I didn’t have to go to a bank, or wait three days, like other payments. It was stress-free because everything happened within minutes,” he said. ## A Better Way to Send Money Abroad The U.S. is a hub for crypto remittances: nearly 20% of the world’s outgoing digital money flows originated here in September 2024, worth $33.34 billion, per the Cambridge Digital Money Dashboard. ![Pseudonym: London Age: Late 20s Country Of Residence: USA Immigrant: Yes Education Level: Undergraduate Political Ideology: Conservative](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--739b477797/8b24b5b82f33364c67df070fa6b076f6/asset-https-cdn-sanity-io-images-dgybcd83--739b477797.png) *Pseudonym: London Age: Late 20s Country Of Residence: USA Immigrant: Yes Education Level: Undergraduate Political Ideology: Conservative* People interviewed said that they preferred crypto because it was significantly less expensive and faster than companies through which they would traditionally send international remittances. London, a 28-year-old immigrant from West Africa, explained to us that being able to send money to his family abroad was sometimes a matter of life and death. When his grandmother fell ill and needed to be sent money in order to cover emergency care, traditional remittances weren’t fast enough. But when London taught his family back home to use crypto, he was able to send the funds that were needed for his grandmother’s care within a few minutes. “Crypto made her better,” he said. ## A Financial Future for All These stories reveal crypto’s tangible impact: faster payments, cheaper remittances, new savings tools, and a sense of empowerment over personal finances. For the unbanked and underbanked, crypto is not an abstract innovation, but a lifeline. It is crucial that lawmakers keep this in mind as they work on market structure legislation. Unfortunately, discussions have been starkly partisan in the Senate, with politics superseding what should be a united goal: increasing financial access, for everyone. We hope that this report helps those Members of Congress not lose sight of the benefits crypto could have for many of their constituents. Read the full report [here](https://downloads.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-bfd8186690/4bcd1b179b88e0895e05fc28510cb363/asset-https-cdn-sanity-io-files-dgybcd83-p-bfd8186690.pdf). ## A Note About Methodology In order to find these stories, we interviewed a diverse group. Of the interviewees, six lived in the U.S., three in developing economies, and two in non-U.S. developed economies. Two were digital nomads. Eight were people of color. Three identified as liberal, six as moderate, and two as conservative. To protect privacy and encourage candor, pseudonyms were used. Interviews, which each ran 40 minutes to an hour, were audio recorded for internal record keeping. Each interviewee was asked to sign a consent form verifying that they would tell the truth to the extent of their knowledge. ## https://www.paradigm.xyz/writing/treasury-when-implementing-genius-follow-congress-direction # Treasury: When Implementing GENIUS, Follow Congress’s Direction > Congress has already spoken on allowing affiliates to issue yield; regulatory agencies cannot alter that decision. To ensure laws are implemented well requires constant vigilance. Today, Paradigm is filing a comment with the Treasury Department in response to its Advanced Notice of Proposed Rulemaking (ANPRM) from Sep. 19, regarding the implementation of the GENIUS Act. This matter carries profound significance. At its core, the question is whether the Treasury will honor Congress’s clear intent or allow the GENIUS Act to be reshaped into something it was never meant to be. The law must be implemented exactly as written, faithfully, and in full accordance with the text enacted by Congress. Today, there is a real danger that the GENIUS Act, as implemented, could become a grotesque distortion of the law -- a warped imitation of what Congress actually enacted. Just as we would not hang a scrawled facsimile of the Mona Lisa in the Louvre, we cannot allow a twisted version of the GENIUS Act to stand in place of the paragon Congress intended. [A fierce fight](https://www.forbes.com/sites/beccabratcher/2025/09/19/banks-push-to-block-stablecoin-yields/) has emerged over one aspect of the GENIUS Act: whether affiliates of stablecoin issuers or others may pay yield or interest to holders. But this is not a new battle. It is an attempt to relitigate, through rulemaking, an issue Congress already settled when it enacted the law. As our comment details, Congress considered this very question and resolved it decisively. The law prohibits stablecoin issuers from directly paying yield or interest to holders, but it places no such restriction on other entities – including affiliates. That judgment is embedded in the statute itself. No administrative agency has the power to rewrite Congress’s choice through regulation. More importantly, altering the law’s boundaries would undermine the GENIUS Act’s purpose. Payment stablecoins are neither banks nor money market mutual funds; they are something new. Allowing affiliates to pay rewards or interest to users strengthens this system, delivering tangible benefits to stablecoin holders rather than inflating corporate profits. At a time when many households are searching for ways to make ends meet (and when traditional financial institutions are cutting back on interest payments) affiliate interest programs create healthy competitive pressure on incumbents to share more value with consumers. Interest payments from affiliates are a pro-consumer innovation, precisely the kind of development policymakers should encourage, not constrain. Opponents of stablecoin issuers paying interest are relying more on speculation than evidence. As we detail, these claims rely on thin research and speculative models that lack real-world support. Agencies should not base regulatory decisions on conjecture. Caution against altering a core feature of the GENIUS Act is especially warranted given the real-world evidence already available. For several years, digital asset platforms have offered rewards programs without any observable impact on bank deposit levels. [^1] Likewise, jurisdictions with established stablecoin regimes, including in Japan and the European Union, have seen no measurable [drops](https://fred.stlouisfed.org/series/DPSACBW027SBOG) [in](https://www.ceicdata.com/en/indicator/european-union/total-deposits) [deposits](https://www.ceicdata.com/en/indicator/japan/total-deposits). Deposit flight isn’t just a dog that hasn’t barked, it’s a dog that hasn’t even stirred. Beyond preserving affiliates’ ability to pay interest, our comment also advances another key point: payment stablecoins should be treated as cash equivalents for all retail and consumer transactions. Federal statute and common usage already define “cash” to include its equivalents, including checks. Payment stablecoins meet this definition because they are (i) intended to be used as payment and (ii) redeemable for legal tender under a regulatory structure that provides at least as much protection for payees as traditional cash equivalents like checks or commercial bank money. Additionally, stablecoins are, under GENIUS, regulated more stringently than many financial instruments already being treated as cash today. For example, under GENIUS, payment stablecoins are required to be backed 1:1 with various extremely low-risk reserve assets, such as U.S. currency. Conversely, banks are permitted reserve requirements far lower than the 1-to-1 reserve required of payment stablecoins. In fact, Regulation D no longer requires member banks to maintain reserves on transaction accounts or savings accounts. [^2] As the saying goes in Washington, the real fight begins *after *the law is passed. But we are committed to making sure the regulatory regime reflects the law as written, not some hollow, lobbyist-influenced imitation of it. GENIUS Act Implementation Comments [here](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-c676f745c6/2dc482ced092bbec043bd9ff2229c01d/asset-https-cdn-sanity-io-files-dgybcd83-p-c676f745c6.pdf). [^1]: See Board of Governors of the Federal Reserve System (US), Deposits, All Commercial Banks, retrieved from FRED, Federal Reserve Bank of St. Louis, available at https://fred.stlouisfed.org/series/DPSACBW027SBOG [^2]: See 12 U.S.C. § 1821; 12 C.F.R. § 204.4(f); see also Board of Governors of the Federal Reserve System, Reserve Requirements, https://www.federalreserve.gov/monetarypolicy/reservereq.htm ## https://www.paradigm.xyz/writing/execution-matters-paradigm-s-response-to-fca-cp25-25 # Execution Matters: Paradigm's Response to FCA CP25/25 > Paradigm responds to the FCA on key priorities for applying their Handbook to cryptoassets, emphasizing that execution of regulatory details will determine U.K.'s crypto leadership success. Ambition is easy. *Execution* is what matters. The U.K. has stated its crypto leadership goals; the FCA's Handbook application will determine if they're achievable. Paradigm submitted our response to the FCA's Consultation Paper 25/25 on applying its Handbook to cryptoasset activities. The Chancellor has made clear that digital assets are part of the U.K.'s economic growth strategy to showcase its strengths in fintech and financial markets. But turning that vision into reality requires the FCA to get the details right. Given the breadth of issues this consultation covers, we focused our response on three areas where regulatory clarity would have the most impact: DeFi, stablecoins, and permissionless infrastructure. **1. The FCA should define what "sufficient decentralization" means using clear, technical criteria. ** According to our [research](https://www.paradigm.xyz/2025/03/tradfi-tomorrow-defi-and-the-rise-of-extensible-finance), 52% of traditional financial firms cite regulatory uncertainty as the main barrier to adopting DeFi. That’s true not just in America, but globally. DeFi remains in a regulatory fog as vast as the Atlantic Ocean. The FCA should establish objective standards: absence of privileged admin keys, transparent on-chain governance, auditable upgrade mechanisms, decentralized validator nodes. As the CFTC's Technology Advisory Committee noted in their research [report](https://share.google/umnwvCHQPblJ09slL), decentralization exists on “a multi-level spectrum varying along each of the functional and technical dimensions”. The U.K. should adopt a flexible, principles-based approach that recognizes protocols can meet decentralization thresholds without achieving some theoretical perfect state. Clear standards create certainty. Certainty unlocks innovation. **2. Stablecoin regulation should be proportionate to actual risk.** Stablecoins are becoming a part of the global settlement infrastructure. With the U.S. GENIUS Act now law, international frameworks matter even more for cross-border interoperability and competitiveness. Major currency-backed stablecoins pose no greater risk than traditional electronic money. Yet applying the FCA Handbook, built for traditional finance, without adaptation could impose impractical burdens. Rules around "fair value" assessment, custodial liability, and distribution oversight need tailoring for decentralized activity, not wholesale transplantation. The FCA has made smart moves by excluding stablecoin issuers from “[common platform](https://www.fca.org.uk/publication/consultation/cp25-25.pdf)” designation and exempting overseas branches from certain operational resilience rules. That direction should continue. Give the sector room to mature without compliance obligations designed for a different financial architecture. **3. Permissionless blockchain infrastructure requires base-layer neutrality.** The FCA rightly acknowledges that firms can't be held responsible for the operational resilience of permissionless blockchains. This isn't a loophole, it's recognition that permissionless infrastructure operates differently than centralized systems. It enables transparency, global participation, and trust through code rather than intermediaries. Regulation should respect that architecture, not attempt to retrofit it into traditional frameworks. **The Transatlantic Opportunity** Beyond these three priorities, the newly announced U.K.-U.S. Transatlantic Taskforce for the Future of Markets represents a real opportunity for coordination. To maximize its impact, we recommend the Taskforce draw on industry expertise when developing shared decentralization standards ahead of March 2026, establish a transatlantic sandbox for crypto activities, and work toward mutual equivalence between U.S. and U.K. regimes. Done right, this collaboration could provide valuable clarity for firms operating across both markets. Clear DeFi standards, proportionate oversight of stablecoins, and understanding permissionless infrastructure are the building blocks of a competitive regulatory framework. The stated ambition is clear. Execution of these details will make the difference. Paradigm looks forward to continued engagement with the FCA as this framework develops. Read our full response to the FCA [here.](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-8023bde1c0/0aa11e2a8794eddc6884b4bcff18ed6a/asset-https-cdn-sanity-io-files-dgybcd83-p-8023bde1c0.pdf) ## https://www.paradigm.xyz/writing/paradigm-files-another-amicus-brief # Paradigm Files (Another) Amicus Brief to Oppose State Encroachment on Federal Regulation > Yesterday, Paradigm filed an amicus brief in KalshiEX LLC v. Martin, a Fourth Circuit case about Maryland’s effort to treat federally regulated swaps as gambling. This isn’t a close call. Yesterday, Paradigm filed an amicus brief in *KalshiEX LLC v. Martin*, a Fourth Circuit case about Maryland’s effort to treat federally regulated swaps as gambling. This isn’t a close call. As we explained in our [Third Circuit amicus](https://www.paradigm.xyz/2025/07/paradigm-files-amicus-brief-to-oppose-state-encroachment-on-federal-regulation) addressing a similar power grab by New Jersey, Congress decided long ago that the CFTC, not fifty different states, sets the rules for these markets. Maryland’s position ignores that history, and the Fourth Circuit should put an end to it. ## ***Same Old, Same Old*** Maryland’s argument – that a futures contract is really just a “bet” – would fit right in at a 1905 statehouse debate. Back then, when farmers first started using grain futures to hedge prices, states passed “bucket shop” laws to ban trades that didn’t involve physical delivery. Legislators saw something unfamiliar and thought, “hmm, that must be gambling.” The Supreme Court eventually corrected the states’ overreach. Justice Oliver Wendell Holmes explained that futures serve “a legitimate and useful purpose” of letting producers and investors hedge risk and allocate capital more efficiently. Congress followed suit, enacting the Grain Futures Act in 1922, then the Commodity Exchange Act in 1936, each time pushing financial markets toward national regulation and away from a patchwork of state interest group power exercises. ## ***The Meaning of “Exclusive”*** The real turning point came with the [Commodity Futures Trading Commission Act of 1974](https://www.cftc.gov/About/HistoryoftheCFTC/history_1970s.html). Congress created the CFTC and gave it *exclusive jurisdiction* over contracts traded on federally designated exchanges. That phrase wasn’t decorative. Congress had watched courts and state regulators spend decades confusing hedging with wagering, and it decided to end the argument once and for all. When Congress revisited the issue a few years later, state regulators begged for their power back. The answer was “immediately no.” The Senate report confirmed that the CFTC’s jurisdiction “supersedes State as well as Federal agencies.” Later, in 2010, the Dodd-Frank Act extended that same preemptive structure to a newer class of instruments called “swaps,” explicitly putting them on the same exclusive jurisdictional footing as other derivatives. This law is the final word for courts; [as a former CFTC GC says](https://x.com/formercftcgc/status/1978845461801800113?s=46), event contracts are swaps. Kalshi’s event contracts fall squarely within that framework. They’re traded on a CFTC-designated exchange, governed by federal law, and subject to federal supervision. The statute’s text, history, and structure all point in one direction: the CFTC regulates them, not Maryland (or New Jersey, or Nevada, or any other state). ## ***The Stakes*** At bottom, this case isn’t about whether Maryland dislikes prediction markets. It’s about whether any state can override a federal regulator and call something “gambling” just because it involves risk. If that logic held, states could ban commodity futures, regular equities trading, weather derivatives, or even airline fuel hedges – all of which are, at heart, “bets” on future outcomes. Allowing Maryland’s approach to stand would resurrect the very chaos the CFTC was created to end. Consumers would suffer from a janky patchwork. Every exchange would have to vet its products against fifty different sets of state laws, turning the national derivatives market into a compliance nightmare. The result would be chaos. Federalism has a critical place in law – but not here, where “the Supreme Law of the Land” has displaced state laws. The Court should abide by Congress’s wisdom. The full brief is [available here](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-03188ea87a/8857b2f561efa10cbb776135c1602539/asset-https-cdn-sanity-io-files-dgybcd83-p-03188ea87a.pdf). ## https://www.paradigm.xyz/writing/paradigm-joins-def-and-spi-in-comment # Paradigm joins DEF and SPI in comment to Treasury on how innovative crypto practices can prevent and combat illicit finance > The solution to problems associated with illicit finance will be found within crypto itself. The best way to fight illicit finance in crypto is with crypto. In August, the Treasury Department issued another [request for comment](https://home.treasury.gov/news/press-releases/sb0228) regarding the implementation of the GENIUS Act, this time on “innovative or novel methods, techniques, or strategies that regulated financial institutions use, or could potentially use, to detect illicit activity involving digital assets.” At present, illicit finance in crypto remains uncommon, with illicit transactions accounting for between 0.014 and 0.4% of overall crypto volume in 2024 according to [TRM Labs](https://www.trmlabs.com/reports-and-whitepapers/2025-crypto-crime-report) and [Chainalysis](https://www.chainalysis.com/blog/2025-crypto-crime-report-introduction), far below the 2-5% of global GDP that money laundering in the traditional economy accounts for. Even as crypto volumes have grown, illicit finance volumes in crypto are shrinking, with Chainalysis finding that illicit volumes [shrunk](https://www.trmlabs.com/reports-and-whitepapers/2025-crypto-crime-report) by 51% between 2023 and 2024. As crypto continues to grow, it is important that the share of illicit finance in crypto not grow alongside it. Crypto is too varied, fast-moving, and decentralized for there to be one solution to illicit finance. Instead, the best way to combat illicit finance in crypto is via a group of interlocking tools and strategies, a concept in cybersecurity known as “[defense in depth.](https://csrc.nist.gov/glossary/term/defense_in_depth)” Specifically, we propose that the best way to combat illicit finance is using multiple, redundant defenses and approaches such that there is no single point of failure. In particular, we focus on three different types of innovative defensive solutions. First, there are risk assessment and defensive blocking tools, which serve as intelligence gathering of and heightened barriers against threats. The former involves evaluating potential threats via reputational due diligence, such as analyzing wallet history and token legitimacy, yielding quantifiable risk scores that users can use to make more informed decisions. The latter is more classically defensive in nature, providing proactive barriers that stop the execution of harmful acts, such as by screening transactions in real time or detecting and halting bots and exploits. Second, there are proactive user-protection tools, which allow for the simulation of blockchain transactions before they are actually executed on-chain. Think of these tools as akin to seeing a model of how a video game character in a tactical RPG will move under a set of specific instructions, and how they will interact in their environment or other characters, before they actually are ordered to act in-game. The user can experiment with different versions of possible on-chain transactions before doing so, thereby seeing which versions of an action trigger such traps as infinite wallet drains or an encounter with a phishing contract. These tools allow users to not just make educated guesses of how transactions will work, but do rigorous pre-execution modeling and testing of different options, thereby empowering ordinary users. Finally, there are threat information coordination solutions. Simply put, these are ways to reduce risks by sharing greater information among ecosystem actors. Such solutions involve “real-time collaboration and intelligence sharing among the digital asset ecosystem, law enforcement, security researchers, and other stakeholders to combat digital asset crimes.” One of the best examples of threat information coordination is the [Security Alliance (SEAL)](https://www.securityalliance.org/). SEAL is a nonprofit center for “crypto threat intelligence sharing, emergency response, and industry security standards development that focuses on rapid response to exploits and threat information dissemination through SEAL 911, a free service supported by industry contributors.” Optimal threat coordination is both forward-looking for possible threats and rapid response for present ones; we have to both put out fires already blazing and work to prevent them from starting.Ultimately, the native tools of crypto are the best way to solve problems within this space. We hope that Treasury and all policymakers find ways to encourage the use of innovative tools and analytical abilities in crypto to combat illicit finance. The comment letter can be found [here](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-8ee784e2c3/ba64b59ab60f87d089d7d9aaa2acb8eb/asset-https-cdn-sanity-io-files-dgybcd83-p-8ee784e2c3.pdf). ## https://www.paradigm.xyz/writing/ithaca-x-tempo # Ithaca x Tempo > The Ithaca team is joining Tempo to build the infra needed for Tempo to scale, meet real-world demand, and remain open to everyone. In 2021 Paradigm released our first open-source project, [Foundry](https://www.paradigm.xyz/2021/12/introducing-the-foundry-ethereum-development-toolbox), to empower smart contract developers to build secure and efficient financial code faster. What began as an experiment evolved over the years into multiple widely used open source projects, including [Reth](https://www.paradigm.xyz/2024/06/reth-prod), [Alloy](https://www.paradigm.xyz/2025/05/introducing-alloy-v1-0) and [Solar](https://www.paradigm.xyz/2024/11/solar). Through that journey, we learned that small global teams of open source engineers could have outsized impact on advancing the technical frontier. In 2024, we brought the core team behind our open source projects into [Ithaca](https://www.paradigm.xyz/2024/10/ithaca), to accelerate the crypto industry, starting with [Porto](https://ithaca.xyz/updates/porto-production-ready), a next-generation open source wallet. Today, that team is joining [Tempo](https://tempo.xyz/) with the same commitment to help crypto succeed by building the infrastructure it needs to scale and meet real-world demand. I’ll be leading Tempo’s engineering, while continuing my existing role at Paradigm. Tempo is built using Reth SDK as a library, not by forking Reth, and may carry its own downstream changes to optimize for its specific workloads. These will live outside the main Reth codebase. Reth will continue to be developed by a mix of core contributors from Paradigm, Tempo/Ithaca, and more at paradigmxyz/reth, as a neutral and unopinionated SDK for building EVM-core chains, including Tempo, Ethereum L1, OP Stack, other L1s, and L2s. The Reth team will continue to be involved in Ethereum core development and [accelerate progress in Ethereum](https://www.paradigm.xyz/2025/01/ethereum-acceleration-1). We expect that Tempo’s global scale payments environment will stress test Reth, Foundry, Porto and the rest of the stack to be even more robust and feature-rich for the entire ecosystem. Learnings from Tempo will continue to flow back into our open source stack, which will continue to be actively maintained and remain neutral building blocks for developers everywhere. To our community, thank you for trusting & contributing to our codebases! This is just the start! ## https://www.paradigm.xyz/writing/congress-passed-genius-market-structure-is-next-but-skipping-crypto-tax-would-be-a-mistake # Congress Passed GENIUS. Market Structure Is Next. But Skipping Crypto Tax Would Be a Mistake. > Unless Congress acts to clarify crypto tax rules, upside from GENIUS and market structure will be capped. Congress has delivered on stablecoins with the GENIUS Act, and is advancing serious legislation on crypto market structure. These are big wins for U.S. competitiveness. But unless Congress and the IRS act on crypto tax, upside from this legislative progress will be capped. Because of uncertainty in U.S. tax law, a large share of crypto activity (staking, trading, lending, even infrastructure build-out) has already moved overseas. Foreign jurisdictions have been quick to provide clarity missing in the U.S. If we want to onshore liquidity, investment, and jobs, Congress must swiftly update and clarify the rules, and the IRS must do its part. The Senate Finance Committee under Chairman Mike Crapo (R-ID) held a [hearing](https://www.finance.senate.gov/hearings/examining-the-taxation-of-digital-assets) yesterday, Oct. 1, to examine digital asset taxation. This builds on Crapo and then-Chairman Ron Wyden’s [bipartisan 2023 RFI](https://www.finance.senate.gov/chairmans-news/wyden-crapo-solicit-policy-input-on-taxation-of-digital-assets) on crypto tax, and Senator Lummis’ crypto tax [discussion draft](https://www.lummis.senate.gov/press-releases/lummis-unveils-digital-asset-tax-legislation/) from July. In the House, House Ways & Means Committee Chairman Jason Smith has already held one [hearing](https://waysandmeans.house.gov/2025/07/21/four-key-moments-hearing-on-making-america-the-crypto-capital-of-the-world/) on crypto tax in July, and Rep. Max Miller is working on a [draft proposal](https://www.politico.com/live-updates/2025/07/16/congress/max-miller-plans-to-lead-comprehensive-tax-overhaul-for-crypto-00456141). The momentum is there – this is the window to get crypto tax done. Here are the most urgent priorities, divided between what requires Congressional action and what can be clarified through IRS guidance. Many of these priorities were included in the President’s Digital Asset Working Group’s [180 Day Report](https://docs.google.com/document/d/1uWt9BnA2tC77j5r0Z-fWBsWXzd7j6tZo_Smfen4O8WM/edit?pli=1&tab=t.0) ([Paradigm analysis](https://www.paradigm.xyz/2025/08/a-blueprint-for-american-crypto-leadership-breaking-down-the-white-house-s-180-day-report)). ## **Where Congressional Action Is Needed** 1. **Tax staking and mining rewards solely upon disposition **Today, under [flawed 2023 IRS guidance](https://www.irs.gov/pub/irs-drop/rr-23-14.pdf), the IRS suggests staking and mining rewards should be taxed when they’re “received,” regardless of whether the tokens can be sold or not (e.g. when staking ETH or SOL, a user must un-bond any rewards, which can take days or even weeks, before those new assets are saleable) – and then again upon disposition. This creates phantom income and discourages U.S. participation in core network activity. Rewards should be credited to a taxpayer at zero basis and then taxed as gains only when sold, consistent with economic substance. A useful parallel: Extracting oil from a well is not a taxable event; selling it and recognizing revenue is. (See: Proof of Stake Alliance’s [work](https://www.proofofstakealliance.org/key-issues/#taxation) on this subject.) Rep. was Drew Ferguson (R-GA) and Rep. Wiley Nickel (D-NC) introduced [legislation](https://www.coincenter.org/new-legislation-proposes-clear-tax-guidelines-for-crypto-block-rewards/) in the last Congress that would have addressed this issue. Further Congressional action on this front would be made easier with a rescission of the IRS’s 2023 erroneous guidance. 2. **Establish a trading safe harbor for digital assets** Foreign investors trading stocks, securities and commodities on U.S. exchanges are shielded from U.S. taxation under the trading safe harbor ((IRC) Section 864(b)(2)). Digital assets should be no different. Without clarity, foreign investors route trades elsewhere and choose validator infrastructure offshore. A crypto trading safe harbor would bring liquidity back to U.S. markets and strengthen domestic exchanges. 3. **Source staking income to the taxpayer’s residence **Right now, without clear rules to the contrary, many tax advisors assess staking income as sourced to wherever the staking infrastructure is located ([similar](https://www.grantthornton.com/insights/alerts/tax/2025/flash/irs-provides-important-clarity-for-cloud-transactions?utm_source=chatgpt.com) to cloud service infrastructure), which could result in 30% withholding tax on foreign investors who stake through U.S. service providers. That uncertainty penalizes U.S.-based infrastructure and pushes validation abroad. Congress should source staking income to the residence of the taxpayer, just as it does for derivatives and foreign currency. This simple fix would onshore staking activity. 4. **Expand IRC §1058 to cover digital asset loans **Market liquidity – in crypto and traditional markets – depends on lending and credit availability. Current rules give securities loans nonrecognition treatment but leave digital asset loans in limbo. Extending §1058 would ensure that lending tokens, whether via traditional contracts or smart contracts, doesn’t create a taxable event, strengthening market liquidity. 5. **Enumerate staking rewards in UBTI exemptions **Nonprofits, endowments, and pension funds should be able to stake without fear of triggering unrelated business taxable income. Congress should make this explicit, opening the door for greater institutional participation. 6. **Treat stablecoins as cash equivalents **Stablecoins function as digital cash. But under current tax law, taxpayers who use stablecoins are taxed on fractional pennies of gain and loss each time, and custodians often have to send them information returns for every transaction. Treating stablecoins like cash for tax purposes would greater-enable their use in everyday business activities like payroll and consumer purchases; in addition, it would treat stablecoin-denominated loans as debt for tax purposes, which would align the tax accounting of those loans with their economic substance. 7. **Eliminate Section 6050I from the Infrastructure Investment and Jobs Act **The 2021 Infrastructure law extended antiquated “cash-reporting” rules to crypto, requiring businesses to report the receipt of over $10,000 in crypto to the IRS, including their counterparty’s tax ID number. In practice, this is unworkable, as wallet addresses are not “identifiable persons,” and raises serious constitutional concerns. Repealing §6050I would remove a chilling provision that discourages peer-to-peer transactions on threat of felony prosecution. Coin Center has been a [consistent voice](https://www.coincenter.org/six-months-of-crypto-policy-the-good-the-bad-and-the-lingering-questions/) regarding the flaws in this statute. 8. **Exercise caution applying wash-sale rules to digital assets** Extending wash-sale rules to digital assets could potentially be one of the main “pay-fors” in any tax package. However, there is a good reason the wash sale rules currently do not apply to other commodities, like foreign currency: when someone regularly (e.g., monthly) acquires commodities and then uses them in everyday, non-tax-motivated transactions, denying them capital losses on those transactions is punitive and unadministrable. If Congress moves forward with a wash sale provision for crypto, it should exempt non-tax-motivated transactions. One possible way to do so would be to give crypto “investors” an ability to elect out of the wash sale rules and into a “mark-to-market” taxation regime instead. ## **Where IRS Guidance Is Sufficient** 1. **Confirm that bridging, wrapping/unwrapping, and cross-chain burn/mint (e.g. Circle CCTP) are nonrecognition events **These technical operations don’t create economic gain or change ownership. IRS guidance should make clear they are not taxable events. 2. **Clarify treatment of airdrops, forks, and rebase events **When networks fork or protocols issue new tokens, it is unclear whether income arises immediately or only when tokens are sold. The IRS should issue bright-line guidance to prevent phantom income and align taxation with economic reality. 3. **Clarify rules for collateral, liquidations, and forced sales **Using tokens as collateral or experiencing an automated liquidation in DeFi can raise uncertainty. IRS guidance should confirm that pledging collateral is not a taxable event and provide clear rules for liquidations. 4. **Update charitable giving rules for digital assets** Crypto donations should be treated like donations of publicly traded securities: “readily valued property” exempt from costly appraisal requirements. This would streamline crypto philanthropy and align treatment with traditional assets. 5. **Exempt unrealized crypto gains from corporate alternative minimum tax** Section 55 of the tax code imposes a corporate alternative minimum tax (CAMT) on large corporations’ “book income,” which includes unrealized gains. Taxing unrealized gains and losses from crypto holdings may whipsaw corporate book income, creating mismatches with cashflow and tax liability. Treasury should exempt the application of section 55 to crypto. ## **Conclusion** Congress has shown it can legislate responsibly on stablecoins and market structure. But without action on tax, the opportunity from those victories is constrained. The U.S. cannot fully unlock the benefits of digital assets until it provides a tax framework that matches economic reality. Much of this activity is already offshore. The question is whether we can bring it back. Congress and the IRS should act now—before it’s too late. Let’s bring crypto home. —-------- Acknowledgements: Jason Schwartz; Abe Sutherland; Mario Sabatés ## https://www.paradigm.xyz/writing/paradigm-s-response-to-cftc-request-for-comment # Paradigm’s Response to CFTC Request for Comment > The importance of the CFTC providing targeted regulatory clarity on event contracts and perpetuals with all deliberate speed. Prioritization is everything in policy. In August, the CFTC issued a broad [request for comment](https://www.cftc.gov/PressRoom/PressReleases/9109-25) on a host of matters related to crypto and how recommendations of the President’s Working Group on Digital Assets’ [180 Day Reports](https://www.whitehouse.gov/wp-content/uploads/2025/07/Digital-Assets-Report-EO14178.pdf) (“the PWG Report”) should be implemented. Given the wide sweep of questions facing the CFTC on crypto policy at this time, it’s wise of the CFTC to seek open-ended comment from stakeholders. While many of the issues in this request piqued our attention, we’re focusing our [response](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-c838236a06/cb7df811c2f097fc22093761dbaf416b/asset-https-cdn-sanity-io-files-dgybcd83-p-c838236a06.pdf) on the three areas we think are especially important. First, we ask the Commission to provide tailored exemptive relief for trading perpetuals on DeFi protocols by the end of the year. The idea of bringing perpetuals into US markets is something we’ve recommended in the past, both to provide additional options for American investors and to bring more liquidity onshore. Yet, to only allow perpetual contracts to be traded on CeFi is to deliberately hobble this product, akin to creating a new streaming network but requiring it be connected through an Ethernet cable instead of WiFi. The CFTC should embrace the cutting edge of perpetuals and allow them to be traded, with reasonable limits, via DeFi. Second, we urge the Commission to codify a clear standard for what it means for an event contract to “involve” gaming and thus be subject to potential prohibition. Prediction markets represent a huge opportunity for American investors, policymakers, and ordinary citizens with their ability to provide fast, useful information about the state of the world. That said, there are aspects of prediction markets that do lie closer to gaming than investing. Until the line is drawn between these two topics, prediction markets as a whole will be under a cloud. Happily, U.S. District Court Judge for the District of Columbia Jia Cobb, a judge nominated by former President Biden, recently provided a definition for what qualifies as gaming under the Commodity Exchange Act. The CFTC should codify this decision via notice and comment regulation. Finally, consistent with the PWG Report’s recommendations for jurisdictional clarity, we ask the Commission to coordinate with the Securities and Exchange Commission (“SEC”) to issue a clear test for which agency oversees which event contracts based on corporate events that solidifies the CFTC’s role as primary regulator of prediction markets. Divining the jurisdictional lines in crypto between the SEC and CFTC has baffled observers across the ideological and political spectrums. It would be a mistake to repeat that mistake for prediction markets. The CFTC should obviate this danger immediately rather than allow it to fester and burst into another multi-year legal battle across the country’s courtrooms. While these issues are not the only ones that are important to crypto, we believe it would behoove the Commission for action on these topics to be taken with all deliberate speed. Read our comment submission [here](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-c838236a06/cb7df811c2f097fc22093761dbaf416b/asset-https-cdn-sanity-io-files-dgybcd83-p-c838236a06.pdf). ## https://www.paradigm.xyz/writing/sec-cftc-coordination # Why Close SEC–CFTC Coordination Is Key to Unlocking U.S. Market Innovation > The SEC and CFTC are holding a roundtable to harmonize their rules. We discuss the potential opportunity at hand for financial markets. The SEC and CFTC issued a [joint statement](https://www.sec.gov/newsroom/press-releases/2025-112-sec-cftc-issue-joint-statement-regulatory-harmonization-efforts-will-co-host-roundtable-sept-29) on Sep. 5 announcing new regulatory harmonization efforts along with a [roundtable on Sep. 29](https://www.sec.gov/newsroom/press-releases/2025-124-sec-announces-agenda-panelists-sec-cftc-roundtable-regulatory-harmonization-efforts) to discuss priorities such as aligning capital and margin frameworks, syncing product definitions, and exploring coordinated innovation exemptions. This is a watershed moment for cooperation that can have outsized benefits for innovation, efficiency, and investor protection. The question at hand is whether the inherent remit overlap between the SEC and CFTC will remain a blocker to progress, or become a potential unlock for novel products and companies. Historically, the SEC and CFTC typically find themselves in fierce competition over jurisdictional matters, fighting over regulatory power for different projects like two referees clamoring to officiate the same football game but with different rulebooks. Effective coordination between the SEC and CFTC is essential for building consistent, modern rules that allow innovative products to come to market in the U.S, especially in a space like crypto that criss-crosses many existing jurisdictional lines and rubrics. The prerequisite for such coordination is simple: The chairs of both agencies must share a vision for forward progress, aligned on the importance of regulatory streamlining, innovation, and competitiveness. **Why Coordination Matters** The SEC and CFTC regulate overlapping parts of the U.S. markets, especially in areas like swaps or equity futures where both agencies have a reasonable and demonstrated interest in regulatory oversight. When the two agencies act in isolation, market participants often must navigate duplicative requirements and lingering jurisdictional uncertainty. Fragmentation raises compliance costs and creates inefficiencies as firms spend time and money navigating regulatory contradictions. That capital should be deployed to create new products that benefit investors and the broader economy, rather than wasted on unclear rules.  Conversely, the benefits are immediate and significant when agencies coordinate. Aligned definitions and consistent compliance expectations reduce the opportunity for regulatory arbitrage. Market participants can operate and build with confidence without dealing with conflicting standards. On the regulators’ side, this level of clarity avoids wasting taxpayer dollars filing amicus briefs against its sister regulator. Joint rulemakings post-Dodd-Frank, cross-border swaps guidance, and data-sharing agreements all show that collaboration is possible, even if it's imperfect. Agency coordination and innovation go hand-in-hand. Cutting-edge products, especially those that involve digital assets, straddle the line between securities and derivatives. Without joint oversight, these products [risk falling into a gray area](https://www.cadwalader.com/fin-news/index.php?nid=84&eid=660) that deters development. With coordinated efforts, regulators can keep innovators onshore by establishing clear guardrails that let innovation flourish. **What’s Possible If the SEC and CFTC Work Together** A coordinated SEC-CFTC agenda could unlock several long-discussed innovations that straddle jurisdictional boundaries. For example: **Equity Perpetuals** Contracts that track the price of equities but roll indefinitely rather than expiring after a set amount of time, as typical futures or options do, which allows for far greater capital efficiency. First seen in crypto, the idea of the perpetual contract can be applied to traditional finance products as well. Today, however, these sit in regulatory limbo. With harmonized rules, investors could access a transparent, well-regulated market for equity exposure in perp form. (The CFTC is already working on the facilitation of crypto perpetuals.) **IPO Pricing Contracts** Prediction markets on whether an IPO will price above or below an expected range. If an investor in the equity of a private company invests at a substantial premium to the stocks of comparable companies that are publicly traded, they may choose to hedge risk (where not prohibited), against an eventual IPO underpricing their current position. In addition, issuers can seek guidance on market pricing through pre-IPO prediction markets or pre-IPO equity perpetuals. **Markets on Shareholder Vote Outcomes / Decision Markets** Prediction markets on corporate governance: “Will XYZ company’s shareholders approve the CEO’s new compensation package?” These could enhance transparency in contested votes. A further extension of this would be the application of [futarchy](https://blog.ethereum.org/2014/08/21/introduction-futarchy) to the decision-making of public companies; the clearing price of a decision market would determine the outcome: the shareholders’ decision in a shareholder vote. Investors typically express opinions on the value of a merger or the potential impact of a board ousting a CEO via buying or selling that company’s stock. Decision markets would price this possible value (or value destruction) into the decision itself. **Markets on Corporate Bond Default / Restructuring Outcomes** Prediction contracts on whether a distressed issuer misses an interest payment, gets downgraded, or restructures, which could serve as a lightweight alternative to Credit Default Swap (CDS) markets, which have many layers of embedded complexity and risk. **Side-by-Side Listings of Securities and Non-Securities** Imagine a trading platform where tokenized equities, crypto commodities, event contracts, and other instruments trade together under a unified compliance framework. Instead of siloed venues, investors could access both types of assets with consistent disclosures and protections. Liquidity pools are deeper, spreads are tighter, and intermediaries face renewed competition. This would likely require a harmonized dual registration framework, assigning each agency responsibilities that match its risk expertise, while ensuring registrants don’t face duplicative requirements. SEC Chair Paul Atkins has discussed this, calling the potential regulations “Reg SuperApp.”‎ **Shared Margin Accounts** Today, traders often need to post separate collateral for securities and derivatives positions. Coordination could allow unified margining, freeing up capital and improving liquidity. For example, a trader long equities and short futures could net those exposures in one account, reducing redundant collateral requirements. This also improves firms' recordkeeping and reduces the risk of accidental rehypothecation. **Security-Based Swaps** This market has struggled with inconsistent jurisdictional boundaries. Dating back to Dodd-Frank, the CFTC has jurisdiction over most swaps while the SEC has jurisdiction over security-based swaps, albeit with some involvement from the CFTC. As a result, this asset class is a desert, with just ~$3B in daily volume. A coordinated framework could make products like total return swaps on equities easier to launch and manage, with clear rules for disclosure, reporting, and margin. **Enhanced Data Sharing** If the SEC and CFTC seamlessly exchanged trade and position data, regulators would have a fuller picture of systemic risk. That would make it easier to identify stress across correlated exposures, whether in equities, swaps, or digital assets. This would be a massive improvement from the current muted data-sharing, not to mention interoperability issues of the long-troubled Consolidated Audit Trail and Swap Data Repositories. Each of these examples is tangible and actionable, even in the short term of the next year. But rapid change is possible only if the two agencies work together under aligned leadership. The payoff of strong SEC-CFTC coordination is broader than smoother rulemaking. It unlocks economic activity by lowering the cost of compliance and barriers to entry for new market entrants. It increases the pace of technological advancement, as founders are able to focus on building innovative new products, rather than spending time and financial resources trying to resolve which regulator is their primary overseer. It even provides comfort and confidence that the agency will be able to identify the good actors from the bad, giving founders confidence to throw their whole body and soul into their projects. Ultimately, a simplified ruleset and widespread technological creativity bolsters the attractiveness of US markets. In short, when the agencies coordinate, the President’s agenda for growth and innovation becomes easier to deliver. **Conclusion** The SEC and CFTC will always have some jurisdictional overlap. The choice for us is whether that overlap creates friction or fosters innovation. For harmonization to succeed, the whole of each agency must coordinate. For that coordination to be real and lasting, the Chairs themselves must be aligned and committed to working together. For crypto specifically, the stakes are high. Tokenized assets, stablecoins, and crypto trading platforms cut across securities and commodities law. Without coordination, the U.S. risks driving this innovation overseas. With coordination, it can lead. ## https://www.paradigm.xyz/writing/paradigm-files-amicus-brief-defending-innovation-in-defi # Paradigm Files Amicus Brief Defending Innovation in DeFi > Paradigm backs Uniswap, all DeFi developers against patent abuse Yesterday, Paradigm filed an amicus brief in *BProtocol Foundation v. Uniswap Labs *(SDNY). The case involves patents that seek to monopolize the basic economic concept of using a mathematical formula to set exchange rates for currency trading, something that existed for centuries before blockchains or crypto. Our brief explains why these claims are invalid under settled patent law, and why allowing them to stand would harm innovation in DeFi. At its core, this lawsuit isn’t really about Uniswap or even about a single patent. It’s about whether anyone should be able to claim ownership over the centuries-old concept of market making, simply because they describe it with an equation and implement it on a blockchain. Market makers have existed since the earliest stock exchanges: they provide liquidity, stand ready to buy and sell, and make sure markets function smoothly. Letting one party ringfence them is like granting someone a patent on long division or compound interest. DeFi has the potential to make financial markets more transparent, more accessible, and more resilient. As we discussed in our[ March study](https://www.paradigm.xyz/2025/03/tradfi-tomorrow-defi-and-the-rise-of-extensible-finance) on the importance of DeFi, even large traditional financial institutions are preparing for a world where decentralized finance plays a central role in core business functions. They see the writing on the wall: open protocols lower costs, reduce counterparty risk, and enable innovation at internet speed. This view has now been echoed by no less a figure than SEC Chair Atkins, making clear DeFi is no backwater experiment – it’s the future of finance. The patents asserted in this case point in the opposite direction. They seek to wall off shared building blocks and undermine the openness that makes DeFi and open-source technology thrive. Put bluntly, BProtocol’s attempt to cash in on an abstract idea they did not even invent risks choking off one of the most promising developments of our financial system, which is sorely in need of a technological update. To endorse the plaintiffs’ claim would be an ahistoric reading of past precedent that would fatally damage this burst of innovation, like a May frost over a blossoming field. The Court should put an end to this case before it goes any further. Paradigm invests in and supports open, decentralized technologies because we believe they expand what’s possible in financial markets. We filed this brief because outdated, overbroad, and rent-seeking patent claims shouldn’t be allowed to derail that progress. The law is clear that abstract ideas and mathematical formulas are not patentable. Upholding that principle is essential if we want to see continued growth, creativity, and competition. The full amicus brief is available [here](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-898805464f/6448a50bb1def13d626b22931331bf87/asset-https-cdn-sanity-io-files-dgybcd83-p-898805464f.pdf) ## https://www.paradigm.xyz/writing/tempo-payments-first-blockchain # Tempo: The Blockchain Designed for Payments > The payments-first blockchain incubated by Stripe and Paradigm We just [announced](https://x.com/matthuang/status/1963633379284587017) Tempo: a payments-first blockchain incubated by Stripe and Paradigm. As stablecoins go mainstream, there’s a growing need for optimized infrastructure. Much of today’s crypto stack either explicitly or implicitly caters to trading (a highly valuable use case in its own right) but is comparatively underoptimized for payments. [Tempo](https://tempo.xyz) is purpose-built for stablecoins and real-world payments, born from Stripe’s experience in global payments and Paradigm’s expertise in crypto tech. We are building the chain with design input from global leaders in AI, e-commerce, and financial services: Anthropic, Coupang, Deutsche Bank, DoorDash, Lead Bank, Mercury, Nubank, OpenAI, Revolut, Shopify, Standard Chartered, Visa, and more. We are excited to further crypto’s ability to tackle real-world use cases including global payments and payroll, remittances, tokenized deposits for 24/7 settlement, embedded financial accounts, microtransactions, agentic payments, and more. Paradigm was founded with a mission to advance the frontier of crypto, and we do this through a mix of investing, building, and researching. This helps us understand friction points and opportunities, and keeps us close to the edge of what’s possible. Tempo is an extension of this ethos. It is a new company with its own full-time team, jointly incubated by Stripe and Paradigm. I’ll be leading Tempo, while continuing my existing role leading Paradigm alongside Alana. At Paradigm, we expect opportunities to incubate companies like Tempo to be rare. In this case, we are excited for Tempo to help the crypto industry meet this moment of stablecoin adoption. We believe Tempo will complement existing crypto infrastructure and be a conduit for many large enterprises to come onchain, increasing adoption of crypto tools and infrastructure. If you want to get involved or collaborate during this deployment phase of crypto and stablecoins, reach out: [partners@tempo.xyz](mailto:partners@tempo.xyz). ## https://www.paradigm.xyz/writing/public-stocks-on-public-blockchains # Public Stocks on Public Blockchains: How Do We Get There? > Paradigm Files Comment with the SEC Crypto Task Force on Equity Market Tokenization Tokenization is the most significant opportunity for equities markets in decades. While the economy has largely transitioned from its pre-internet analog structures and moved online, financial markets remain woefully stuck in a time warp. That U.S. markets are the deepest and most liquid in the world despite being held back by ancient technology underscores the opportunity that moving markets onchain presents. Part of the reason for this slothful transition is regulatory; for years now, the SEC has hindered, harried, or even blocked efforts to tokenize securities. A new day is now dawning, however, as SEC Chair Atkins laid out last month in his [speech on Project Crypto](https://www.sec.gov/newsroom/speeches-statements/atkins-digital-finance-revolution-073125), an “initiative to modernize the securities rules and regulations to enable America’s financial markets to move on-chain.” A key part of Project Crypto is supporting the tokenization of the equities markets. Only by harnessing technological advancements, while preserving the securities laws’ foundational principles, can we ensure that the United States will remain the preeminent jurisdiction for capital markets. With that in mind, Paradigm yesterday filed a comment letter with the SEC on how the opportunities posed by tokenization can be fully realized. I want to highlight two of the most important suggestions in the letter. First, we lay out three principles for modernizing securities regulations for tokenization: any regulatory changes should be targeted, updates should be technology neutral regarding the assets themselves, and the updates must take into account the unique characteristics and technical capabilities of crypto. We agree with Commissioner Hester Peirce that “[tokenized securities are still securities](https://www.sec.gov/newsroom/speeches-statements/peirce-statement-tokenized-securities-070925).” Putting a share of Apple stock on the blockchain does not instantly transform that stock into a non-security. At the same time, technology does matter. As Europe’s regulators often say, different technology does require different regulations and you cannot flatten all new technological innovations into an existing box. Juggling all three of these principles is difficult, but we believe it is critical if tokenization is to truly benefit America’s consumers and investors. Second, we propose ways to allow for IPOs to occur onchain. If we are going to embrace tokenization, there is no reason to exclude the process that onboards stocks to the public markets from tokenization. To do otherwise would be akin to requiring people ride horses to the end of their driveways, after which point they may enter their car. To allow for onchain IPOs, however, a few regulatory actions are necessary. Beyond the fact that the SEC should affirm that a tokenized security is still a security under federal law, there should also be changes to how transfer agents are regulated. At present, transfer agents are required as a matter of recordkeeping, but the chain can serve this role as well if not better. Thus, the SEC should either allow issuers to be their own transfer agents, create a new class of registrations for transfer agents on the blockchain, or eliminate any superfluous regulatory requirements for transfer agents onchain. What matters here is less the exact road taken towards onchain IPOs, however, but instead the end goal: that onchain IPOs are well-regulated, safe, accessible, and broadly available. Of course, we recognize that this comment, like tokenization itself, is not without its detractors. Per [Reuters](https://www.reuters.com/sustainability/boards-policy-regulation/stock-exchanges-urge-regulators-crack-down-tokenised-stocks-2025-08-25/), “A group representing the world's biggest stock exchanges has called on securities regulators to clamp down on so-called tokenised stocks, arguing that the blockchain-based tokens create new risks for investors and could harm market integrity.” This fear is misplaced. Putting equities on the blockchain will allow for greater transparency, better recordkeeping, faster settlement, and additional competition to these existing exchanges. We understand that change can be frightening, especially to large incumbents. But we believe the benefits of tokenized stocks will accrue to not merely the vast majority of market participants, but the vast majority of Americans. To delay the transition to tokenized stocks would ultimately harm the very consumers and investors the SEC is most duty-bound to protect. We will keep advocating for the SEC and all regulators to embrace the promises of crypto and find new ways to bring competition, liquidity, new choices, and new technologies to consumers and investors. Read our full comment letter [here](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-3101bb820e/e7a03f33488f897ffeb437b92238e6fb/asset-https-cdn-sanity-io-files-dgybcd83-p-3101bb820e.pdf). ## https://www.paradigm.xyz/writing/paradigm-urges-cftc-to-embrace-defi-in-spot-crypto-trading-rules # Paradigm Urges CFTC to Embrace DeFi in Spot Crypto Trading Rules > Paradigm files comment to CFTC stressing that any spot crypto trading regime must not disadvantage DeFi. Today, Paradigm submitted a comment letter to the Commodity Futures Trading Commission (CFTC) responding to its request for input on the listing of spot crypto assets on designated contract markets (DCMs). While the proposal focuses on allowing these assets to trade on centralized futures exchanges, our letter calls on the CFTC to ensure that any new rules also protect and enable trading over DeFi protocols. The CFTC’s noble goal is to bring spot crypto trading into well-regulated environments that protect market integrity, prevent fraud, and foster innovation. We agree with that mission. But, as we explain in our letter, blockchain technology has already moved the market beyond the 19th-century DCM model. Today, much of the most innovative and transparent trading happens over DeFi, where users retain custody of their assets, trade peer-to-peer, and benefit from open, auditable blockchain records. These protocols advance every single core objective of the Commodity Exchange Act, especially those focused on supporting the ultimate class of people protected by the CEA: regular traders and Americans. - Users can place their orders straight through to the protocol using passive software that preserves full user control over their trading and assets. As a result, users do not face the front-running, misappropriation, and similar conduct risks present when trading through an intermediary. DeFi is one of the best technologies we have for empowering ordinary users. - Protocols typically operate on a permissionless and autonomous basis. No person or group of commonly controlled persons can block or censor access or trading or otherwise exercise discretion over how the protocol operates. These characteristics natively ensure impartial access and mitigate conflicts of interest. They also create new forms of competition for existing markets and are a hotbed of innovation in trading. - Protocols deployed on public ledgers provide users and the general public with freely available information about prices and trading, which promotes price discovery and more efficient and transparent markets. Such transparency helps confirm the sanctity and honesty of our markets and increases trust in our financial markets among users and the American people. The President’s Working Group on Digital Asset Markets has made clear that supporting DeFi is an Administration priority, urging regulators to “embrace decentralized finance” to position the United States as a global leader. The CFTC does not need to wait for Congress to act; existing authority under Section 4(c) of the CEA allows the agency to exempt DeFi trading from outdated intermediation requirements when doing so promotes innovation and fair competition. We urge the CFTC to use that authority to allow retail users to trade spot crypto, including leveraged or margined trades, alongside any new DCMs. Such actions should not disadvantage the ability of users to trade over DeFi protocols.This approach expands consumer choice, keeps cutting-edge markets in America, and advances the CEA’s goals better than a “one size fits all” rigid framework. Paradigm looks forward to working with the CFTC and the broader policy community to create clear, forward-looking rules for crypto markets. Our full letter is available [here](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-fd1b6baad0/fafb7fa612084955588e3b9a2ae55aa4/asset-https-cdn-sanity-io-files-dgybcd83-p-fd1b6baad0.pdf). ## https://www.paradigm.xyz/writing/opportunity-markets # Opportunity Markets > Introducing opportunity markets, private prediction markets where those who spot opportunities get paid by those who can act on them
Animation by Dave Whyte
# Introduction Imagine you spot an unsigned band destined for massive success. Instead of cold-calling labels, what if you could bet on them yourself? This paper introduces opportunity markets: private prediction markets where those who find opportunities get paid by those who act on them. Music labels, research labs, and VCs all want to find the next big thing before the competition. But the people who first spot opportunities often have no institutional connections. Historically, there hasn’t been a clean way for these parties to find each other and transact. Prediction markets use skin in the game to distill signal from distributed participants. But for someone to make $1M betting XYZ will be huge, someone else needs to bet $1M it won’t. Nobody wants to bet against thousands of opportunities they’ve never even heard of. The natural counterparties for a market like this would be those who could act: labels, employers, funds, etc. But if they were to provide liquidity in a public prediction market, they’d just be subsidizing information their competitors could use just as easily. Opportunity markets address this problem by keeping market prices private from everyone but their sponsor. A label might provide $25,000 of liquidity against “We will sign artist XYZ in 2025,” providing $25,000 of dumb money scouts can win if they’re early. When the label sees the price going up, it’s an early signal to investigate the artist. Prices and positions only become public after an “opportunity window” of e.g. two weeks. It’s like a decentralized scout program where anyone in the world can get skin in the game. There are real challenges: traders operate blind without prices or position feedback for significant periods, and the self-dealing risks are obvious. Nevertheless, we think there is something interesting to unlock here, and the design space is Wide. # Intuition ## Motivation Consider a music fan who discovers an unsigned artist destined for stardom. The fan has valuable information but no record label. The labels that could sign the artist have no idea they exist. Or a researcher who recognizes that an obscure paper contains a breakthrough relevant to self-driving cars. They lack the resources to commercialize it, while companies spending billions on R&D miss it entirely. This pattern repeats across domains: shop owners spot trends before the major brands, local suppliers spot successful businesses before investors, fans identify athletic talent before it’s obvious. In each case, someone with deep contextual expertise close to where something exciting is happening has information that would be valuable to someone far away with resources to act on it. But there’s no mechanism to connect them. The person with information can’t monetize their insight, and the person with resources misses the opportunity. For this paper, we are focusing especially on opportunities that take significant resources both to evaluate and to act on, and have some competitive and time-limited nature to them, such that knowing about them before others who can act on them confers significant benefits. ## Existing Mechanisms A scout program is one type of solution to the situation described above. They give selected individuals with contextual knowledge a small stake in opportunities they identify. But these programs are limited by trust requirements and evaluation costs. The institution cannot scale beyond its ability to vet both scouts and their recommendations. Prediction markets are one proven way to aggregate information from abroad and decentralized group of people. But, there’s an incentive problem: for someone to profit significantly by betting that an artist will succeed, others must lose an offsetting amount. It doesn’t make sense for a market maker to bet a large amount of money against the success of an artist they’ve never heard of. Even if institutions subsidized liquidity on these markets to benefit from the information, prediction markets as they are usually deployed today offer their information as a public good. Competitors could free-ride on the same signals, eliminating the advantage. This is the core leak opportunity markets seek to Address. # Mechanism ## Example This concept is easiest to explain by example. Imagine a record label that wants to take advantage of opportunity markets to create a decentralized scouting Program. They create a family of private prediction markets asking “Will we sign Artist X in 2025?” for any artist X. Anyone can create a new market for any artist not yet listed and add it to the family. The markets are private in the sense that only the sponsor knows the market price at any given time. We discuss some of the challenges involved with this below. The label acts as market maker, providing, say, up to $25,000 of liquidity per market. They could either promise to provide this amount of liquidity, or prove that they are by, for example, running an AMM in a TEE. This is the “dumb money” that scouts can win if they’re early. As scouts gain conviction in an opportunity, they buy more shares, driving the price up on the market. As prices for a given opportunity rise, the sponsor label will take notice and investigate the opportunity, potentially leading to a signing. If they do ultimately sign the artist, the shares will pay out, and the label has effectively paid a decentralized scouting incentive of up to $25,000. ## Privacy For opportunity markets to work, only the sponsor can see current prices. If traders could see their fills immediately, they could reconstruct market prices by Trading. But traders need to know their positions eventually. The solution is an opportunity window—perhaps two weeks—after which traders learn whether their orders filled. This gives sponsors time to investigate promising opportunities before the information becomes public. After the window closes, there are various design choices: reveal all prices and positions, reveal only positions to individual traders, have different rules for large versus small orders, etc. More sophisticated systems might allow sell-to-close or buy-to-close limit orders before positions are revealed, or even allow trading agents that operate without revealing current positions. ## Market Design Details ### Liquidity Provision Markets could use either an automated market maker or order book. In either case, liquidity will likely be concentrated within certain bounds. For example, the sponsor might provide liquidity starting around 1% probability, below which the information isn’t useful, and stop providing above 30%, where additional market signal isn’t especially helpful. ### Unlimited Markets vs. First N For most types of opportunities, like artist signings, there are only a limited number that the sponsor can act on in a given time period. Accordingly, if traders are willing to trust the label to pay out, they can simply promise to pay out on an unlimited number of markets for “Will we sign Artist X in 2025?” and ensure they are never providing so much liquidity across all markets that they won’t be able to pay out if they sign too many artists. For a more permissionless approach, markets can be fully collateralized using a “First N” structure. For example, markets of the form “Will XYZ be among the first 10 artists we sign in 2025?” would require collateralizing each market with 10x the max liquidity since only 10 of them can pay off. ## Limiting Exploitation Sponsors have both special information about the market state at any given time, and special knowledge about their own process, which opens the risk of exploitative behavior such as hinting they will take advantage of opportunity X while aggressively selling into that market. It is challenging to address this from a mechanism design standpoint, and we largely have to rely on trust and reputational effects. At the end of the day, market participants will only participate in markets sponsored by a given sponsor if they prove to be fair over a period of time. Some guidelines sponsors might do well to follow include: - Committing never to actively sell into any of their own markets (although buying, or perhaps removing sell liquidity, is likely fine once they make the decision to sign or even investigate an opportunity) - Committing to use any profits from opportunity market trading either to refund traders who participated or as additional liquidity for future markets. Running opportunity markets in a TEE and sharing all trades once the market has resolved can also offer some transparency and mitigation. # Conclusion We’re excited to see how Opportunity Markets develop over time. If you’re interested in working on them or other information finance ideas, we’d love to hear from you. ## https://www.paradigm.xyz/writing/market-structure-rfi-response # The Senate Market Structure Approach Is the Best Path Forward > Paradigm’s responses to the Senate Banking Committee’s RFI on market structure legislation. The most important characteristic of a market structure law is clarity. We’ve written and spoken about the need for clarity in crypto regulations for years, and it’s been heartening to see first the House and now the Senate take up the cause of drafting and passing comprehensive crypto legislation. But the details of market structure legislation matter. As we noted in our [Principles on Market Structure Legislation](https://www.paradigm.xyz/2025/04/market-structure-principles), not all legislation is created equal. Market structure legislation must adequately protect DeFi, establish a clear test for which assets are securities, and recognize that “crypto assets are native digital assets imbued with property rights.” These principles underscore our belief that most crypto assets are generally distinct from securities because they have different attributes and key characteristics, including that they don’t derive their value from legal rights. With that in mind, we have co-signed two comment letters in response to the Senate Banking Committee’s recent Discussion Draft on market structure legislation. The [first](https://x.com/fund_defi/status/1951389606454476992), drafted by the DeFi Education Fund, stresses the importance of protecting DeFi. As Dan said in his [Senate testimony](https://www.banking.senate.gov/imo/media/doc/robinson_testimony_7-9-25.pdf) in July, it is essential that crypto market structure regulation not crush the decentralized trading protocols that make up an increasing share of crypto volume and constitute one of the foundational contributions of the industry. The [letter](https://www.defieducationfund.org/_files/ugd/84ba66_fe9e31549b3443d09840438f38421a16.pdf) by the DeFi Education Fund drills down on these points, arguing that there is a “fundamental distinction” between centralized intermediaries and software developers creating permissionless software. Additionally, the letter argues that blockchain technology should be treated as purely neutral infrastructure like the internet itself and not shoehorned into regulatory or compliance obligations that are ill-suited to it. The free and permissionless nature of the internet is core to its operation and to its design; we must provide the same protection and sanctity to permissionless blockchains. The [second](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-897d9d25e7/85eb4a4dd8b24b778617abf6df7dac30/asset-https-cdn-sanity-io-files-dgybcd83-p-897d9d25e7.pdf) letter focuses on four primary topics: token classification, investor protection, supporting innovation, and federal preemption of state securities laws. While all these topics are important, the letter’s focus is the first. Notably, the approach to token classification in the Senate discussion draft is different from the approach taken by the CLARITY Act passed by the House. CLARITY is built around a “mature blockchain” test for determining when crypto assets fully move beyond the securities laws. The Senate discussion draft instead focuses on the idea of ancillary assets, which distinguishes the typical crypto asset from securities due to its innate nature. While there is no perfect way to provide regulatory clarity for crypto, we argue in our letter that the ancillary asset concept is the most practical. As we note in our submission, “The ancillary asset concept is elegant in its simplicity: it defines an ancillary asset as an intangible asset sold in connection with an investment contract and clarifies (i) the ancillary asset itself is not a security, and (ii) secondary transactions in an ancillary asset are not securities transactions. Excluded from the definition are assets sold in connection with an investment contract that provides the owner of the asset with certain financial rights.” This is the basis of a standard in market structure legislation that is easily understandable to entrepreneurs, readily operationalized by policymakers, and clear to ordinary investors and users. Our reasoning rests on two points: first, that the *Howey* test is a flawed tool for determining crypto jurisdiction; and second, that crypto assets lack the legal rights that define securities. The *Howey* test, which was the linchpin of the Gensler SEC’s approach to crypto regulation, was universally unpopular among the investors it was meant to protect. One reason is that the *Howey* test is notoriously difficult to apply, and to predict. *Howey *was not created by Congress, but instead emerged as a judicial test, long-standing as a legal no-man’s-land. Only recently, with the rise of crypto, have we seen efforts to retrofit *Howey* into a jurisdictional framework for regulating an entire industry. The result has been confusion, with even judges calling the case-by-case application maddening. Additionally, the *Howey* test, and the way it was enforced, created perverse incentives in the crypto industry that undermined the goals of investor protection. The test hinges critically on whether an issuer puts in any post-sale “efforts” to make a network valuable. When combined with the catastrophically punitive consequences of a securities classification for a token, and the difficulty of predicting how *Howey* would be applied, this had a predictable consequence: projects that launched a token for a network were discouraged from putting in further effort into the network. The ancillary assets approach taken by the Senate bill takes advantage, in part, of a clearer and more predictable distinction: whether the asset comes with legal rights. [^1] Most securities – stocks, bonds, options, notes – derive their value from legal or contractual obligations, whereas crypto assets derive their value from code, and from the role they play in their protocols. Some have raised concerns that this could undermine the traditional securities markets. But the notion that securities issuers could choose to simply remove all legal obligations from their instruments is farfetched. Imagine a bond issuer asking its investors to forego the clauses that require the issuer to repay its debt. Then imagine them explaining their rationale—that they are doing so in order to deprive the investor of their rights under the securities laws. Without legal rights, stocks, bonds and similar instruments would be worthless, and no traditional securities investor would accept that tradeoff. Crypto assets, by contrast, can and do have value independent of such rights. We believe the ancillary asset concept is preferable to the corresponding provisions of the CLARITY Act. While the CLARITY Act’s control-based test is a significant improvement on *Howey*’s efforts-based test, it introduces significant complexities of its own, and could perversely incentivize builders to limit the functionality of their protocols in order to check a regulatory box, in ways that do not serve the actual interests of investor protection. Enacting crypto legislation is no small task, and we appreciate the efforts of many in Congress to craft market structure laws that balance the often competing needs of industry participants, stakeholders, and critics. We’re grateful for the opportunity to offer input to help improve this legislation. As Congress moves forward, we urge it to be guided by the principle that legislation should support the safe, sustainable growth of the industry, protect users and investors, serve the national interest, and remain workable for both companies and regulators. A law that demands millions of dollars and a team of elite lawyers to navigate would be a counterproductive outcome. The full submission is available [here](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-897d9d25e7/85eb4a4dd8b24b778617abf6df7dac30/asset-https-cdn-sanity-io-files-dgybcd83-p-897d9d25e7.pdf). [^1]: The discussion draft uses the term "rights." Based on the context as well as the examples enumerated in the section, we interpret this to refer to legal rights, but in the letter, we make the recommendation that this language should be changed to avoid any ambiguity ## https://www.paradigm.xyz/writing/a-blueprint-for-american-crypto-leadership-breaking-down-the-white-house-s-180-day-report # A Blueprint for American Crypto Leadership: Breaking Down the White House’s 180-Day Report > The White House laid out comprehensive steps to spur growth and unlock crypto’s potential in the United States. The [Presidential Working Group on Digital Assets 180-Day Report](https://www.whitehouse.gov/wp-content/uploads/2025/07/Digital-Assets-Report-EO14178.pdf) (“the report”), released last week, is a landmark roadmap for the future of digital assets. Commissioned by President Trump’s January 23, 2025 Executive Order on Strengthening American Leadership in Digital Financial Technology, the report outlines bold, detailed steps to establish the United States as the global leader in crypto innovation. The report doesn’t just lay out ideas; it aligns stakeholders in the legislative and executive branches in pursuit of establishing regulatory clarity for crypto as quickly as possible. Though agencies and legislators aren’t legally bound to act on its suggestions, there’s reason to believe they will: Treasury Secretary Scott Bessent and his team, bank regulators at the OCC, Federal Reserve Board, and FDIC, and the leadership of the SEC and CFTC all contributed substantial input to this manifesto. Additionally, the White House has remained in close contact with Congress as it has passed crypto legislation, and the President’s involvement has already proven to have significant influence in getting bills like the GENIUS Act over the finish line. If the reports’ recommendations take hold, the U.S. stands to cement its position as both a financial technology trailblazer and a responsible regulator. By setting out a clear vision for what American crypto leadership looks like all in one document, disparate actors across the government now have a shared directive upon which to execute. Policymakers have their blueprint for accelerating growth and unlocking crypto’s full potential. The next move is theirs. ## **DeFi is Different** The report frames decentralized finance (DeFi) as fundamentally different from traditional, centralized finance, pointing to several key factors. Decentralized protocols, per the report, primarily provide services like lending and trading on a peer-to-peer basis, rather than through a central intermediary which has control and custody over customer assets, and total control over platform upgrades and use. Regulatory compliance therefore must be such that DeFi developers are not subject to the same requirements as are the operators of centralized platforms. This distinction is anything but technical: it bucks a trend in the federal government over the past several years of forcing DeFi into a traditional finance-shaped box. This trend has resulted in the misguided prosecutions of developers and baseless enforcement actions against growing ecosystems. Its reversal in the White House report is momentous. *Why it matters: *A one-size-fits-all model doesn’t work for DeFi. Recognizing DeFi’s unique attributes preserves innovation, ensures regulatory effectiveness, and supports the ongoing growth and security of decentralized financial infrastructure. *What comes next*: Regulators have the option to provide no action relief for DeFi at any time. Legislators can and should also amend legislation or introduce new legislation to include protections for DeFi users. ## **Modernizing the Bank Secrecy Act** The current Bank Secrecy Act (BSA) framework was built for centralized institutions and falls short when applied to decentralized platforms with little or no control over user funds. For example, prosecutors have twisted the law to [prosecute developers](https://www.paradigm.xyz/2025/04/southern-district-stand-down-prosecuting-code-is-not-justice) of neutral tools. The report, in contrast, calls on Congress to codify principles regarding how control over an asset impacts BSA obligations. Specifically, the states that a software provider that does not maintain total independent control over value should not be considered as engaged in money transmission for purposes of the BSA. *Why it matters: *Aligning BSA rules with the realities of decentralized technology reduces compliance uncertainty and prevents unnecessary burdens upon developers. *What comes next*: Regulators should issue rulemaking that gives the crypto industry a clear path to comply with the Bank Secrecy Act without disrupting innovation, such as reiterating or updating the [2019 FinCEN guidance](https://www.paradigm.xyz/2025/06/paradigm-files-amicus-brief-supporting-roman-storm). Congress could also codify changes to the BSA’s Section 18 USC 1960 as part of the National Defense Authorization Act (NDAA), crypto market structure legislation, or other legislation. ## **Creating a Clear Digital Asset Taxonomy** A detailed taxonomy outlined in the document classifies digital assets into categories such as security tokens, tokenized securities, and digital commodities. This long-awaited clarity sets the stage for applying regulations consistently across different asset types. Under the last administration, Chairman Gary Gensler would frequently [invent, mix, and match](https://x.com/iampaulgrewal/status/1834447203680825809) terms in different enforcement actions — even ones filed within days of each other. That era is now over. *Why it matters:* Clearly defined terminology for digital assets eliminates regulatory confusion, streamlines compliance, and reduces legal risks. This clarity also bolsters market confidence, drives capital into American companies, and fosters the development of new financial products. *What comes next:* Several pieces of market structure legislation introduced over the past several years have included definitions for key terms, though none align fully with the definitions laid out in the White House report. Both chambers of Congress will now ideally work to refine key terms to align with this report before any final market structure bill makes it to the President’s desk. ## **Drawing a Line Between CFTC and SEC Responsibilities** Another series of recommendations seek to assign explicit authority over non-security digital asset markets to the Commodity Futures Trading Commission (CFTC) while narrowing the Securities and Exchange Commission’s (SEC) jurisdiction to digital securities. This clearly distinguishes each agency’s role and streamlines collaboration between them. SEC Chair Paul Atkins underscored this commitment to clarifying digital asset jurisidxtion in his [speech](https://www.sec.gov/newsroom/speeches-statements/atkins-digital-finance-revolution-073125?utm_medium=email&utm_source=govdelivery) announcing “Project Crypto” on July 31st, in which he plainly stated that “most crypto assets are not securities.” *Why it matters:* Clear boundaries between regulatory agencies reduce inefficiencies and regulatory arbitrage. Businesses benefit from simpler compliance and lower costs, founders can know where they stand without hiring an army of lawyers, and investors gain the certainty needed to participate confidently in the market. *What comes next:* Ultimately, defining the boundary between the CFTC and SEC is the core of any market structure legislation, whether that be the CLARITY Act or a new Senate bill. That means this decision is in the hands of Congress, which must determine whether to follow the White House’s recommendation. ## **Reforming Crypto Tax Rules** The report proposes detailed crypto-specific tax guidance, explicitly outlining which issues require legislation versus which can be alleviated by the IRS and Treasury. Some of the specific recommendations include: - Publishing updated IRS guidance clarifying at what time income from mining and staking rewards should be taxed, and whether staking should be taxed as a trade or business activity - Publishing updated IRS guidance explaining whether NFTs can be taxed as collectibles - Publishing updated IRS guidance which clarifies whether trusts which hold staked assets can qualify as investment trusts treated as a grantor trust - Congress passing additional stablecoin legislation to define how stablecoins should be characterized for the purpose of federal income taxes - Congress amending wash sale rules so that digital assets receive similar trading tax treatment to other assets - Congress passing legislation to amend Section 1058, which exempts most securities loans from gain or loss reporting, to explicitly state that it also applies to the lending of fungible digital assets *Why it matters:* Resolving long-standing ambiguities in crypto taxation simplifies compliance and reduces uncertainty for institutions and individual investors alike. Clear rules make markets more efficient and encourage broad-based adoption of digital assets. *What comes next*: Congress may consider a tax bill later this year or fold some of the recommended changes into a new budget reconciliation package. Many proposals, however, like guidance on staking and NFT classification, can be addressed by the IRS under its existing authority. The report outlines which issues it believes the IRS can quickly resolve on its own, and which require congressional action. ## **Freeing Banks to Engage with Crypto** The administration explicitly calls for supporting innovation in banking technologies in the report, enabling banks to safely engage with digital assets. This marks a shift away from overly restrictive measures that previously limited banks' ability to interact with crypto markets, proposing clear standards that maintain safety and soundness while eliminating unreasonable barriers for banks to service crypto companies and manage digital assets. *Why it matters:* Enabling banks to innovate and actively participate in the digital asset space increases market access and financial inclusion. Meanwhile, the emphasis on safety and soundness ensures that innovation does not compromise the stability of the broader financial system. Operation Choke Point 2.0 is well and truly over. *What comes next*: Regardless of a shift in approach between the Biden and Trump administrations, the White House report’s recommendations must be codified in law or at the very least explicitly stated in guidance from bank regulators like the OCC, Federal Reserve Board, and the FDIC. These regulators have already begun to take steps in the right direction — the Federal Reserve Board [withdrew supervisory guidance](https://www.chapman.com/publication-bank-prudential-regulators-now-in-alignment-after-federal-reserve-rescission-of-past-crypto-related-guidance)) which required banks to seek pre-approval or non-objection letters in May, for example, following similar reversals from the FDIC and OCC. However, there is still more to be done. ## **Clear Rules, Bold Future** Rules are often seen as the enemy of innovation. They’re framed as restrictions on what builders* can’t* do, rather than guidance on what they *can.* But in crypto, the reality is the opposite. This is an industry so dynamic and transformative that it outgrew existing rules on day one, and has been penalized for that ever since. For crypto, new rules made to accommodate its innovations don’t stifle progress, but help forge a path forward. The 180-day report marks a turning point because it lays out that path, not just for the coming months, but potentially for years ahead. It’s a comprehensive roadmap spanning Congress, financial and banking regulators, the IRS, the DOJ, and more. On critical questions, such as dividing oversight between the SEC and CFTC, the report removes ambiguity and signals where the White House stands. On other issues, like tax reform, it goes even further, offering not just policy positions but clear, procedural steps for implementation. The White House’s position on these various policy issues is explained in detail, leaving little room for confusion amongst the relevant stakeholders. It is now on lawmakers and regulators to put the White House’s plans into action. ## https://www.paradigm.xyz/writing/paradigm-files-amicus-brief-to-oppose-state-encroachment-on-federal-regulation # Paradigm Files Amicus Brief to Oppose State Encroachment on Federal Regulation > Paradigm files amicus brief in support of Kalshi in KalshiEX LLC v. Flaherty Yesterday, Paradigm filed an amicus brief in *KalshiEX LLC v. Flaherty*, urging the U.S. Court of Appeals for the Third Circuit to preserve the CFTC’s exclusive jurisdiction over a broad range of predictive financial instruments. New Jersey’s effort to sidestep Congress’s clear mandate is little more than old wine in a new bottle – an argument courts have rejected time and again. As Paradigm has [noted before](https://www.paradigm.xyz/2024/11/amicus-brief-kalshi), prediction markets translate collective insight into tradable prices, which helps businesses and regular citizens plan for the future. They help Americans anticipate whether inflation will persist. They signal whether AI breakthroughs will arrive sooner than expected. They even indicate whether a particular candidate will capture the White House or New York’s Gracie Mansion. From weather and commodity prices to elections and sports outcomes, Congress long ago recognized that these contracts belong under one federal umbrella. That’s why it established the CFTC and granted it “exclusive jurisdiction” over “a wide swath of predictive financial instruments.” As we lay out in our brief, there is a trail of evidence decades long that Congress intended to preempt 50-state regulation of these contracts. That decision was, and remains, eminently sensible. In complex interstate markets, entrusting oversight to a single well-resourced regulator is sound policy. More importantly, it is *Congress’s *judgment to make, not New Jersey’s. Over the past century, states have repeatedly tried to encroach on federal financial regulatory turf, only to be rebuffed by Congress and, when necessary, the courts. Early 20th-century state “bucket-shop” laws illustrate the point: they lumped risk-management trades together with illicit gambling, criminalizing any deal that didn’t end with a wagonload of wheat or a bale of cotton physically changing hands. Congress put an end to the chaos in 1974 with the Commodity Futures Trading Commission Act, which preempted all state gambling codes and imposed a single nationwide regime for contracts traded on CFTC-designated exchanges. The legislative record is unmistakable: hearing after hearing, report after report, lawmakers stressed the need to place all exchanges, and everyone who participates in them, under one coherent federal rulebook. Congress has reaffirmed its choice repeatedly and unequivocally. The 1978 amendments to the CFTC Act declared that the agency “preempt\[s\] the field insofar as futures regulation is concerned,” leaving states only general anti-fraud tools. More recently, Dodd-Frank extended the same federal shield to swaps, reinforcing preemption rather than retreating from it despite an obvious opportunity. The message could not be clearer: Congress will not tolerate an ugly patchwork of state laws in an inherently national financial arena. Kalshi’s event contracts fit comfortably inside Congress’s federal ringfence. New Jersey tries to dodge that reality by insisting that a “swap” must reference something “inherently” financial, a phrase Congress never wrote. The statute covers swaps “associated with” a financial consequence, a broader framing that covers everything from the Super Bowl to rainfall indexes to elections. With ready access to a dictionary, Congress could have taken the states’ side, and *chose not to*. Allowing each state to slap its gambling label on federally regulated event contracts would revive the very chaos Congress expressly stamped out. Quite simply, Kalshi’s event contracts are traded on Kalshi’s CFTC‑designated exchange. Under federal law, the inquiry begins and ends there. The full amicus brief is available [here](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-79dfe7389f/fc2bbd59d2dff0e40b6e917d0c714a3d/asset-https-cdn-sanity-io-files-dgybcd83-p-79dfe7389f.pdf). ## https://www.paradigm.xyz/writing/the-genius-act-passed-now-the-real-work-begins # The GENIUS Act Passed - Now the Real Work Begins > The GENIUS Act is now law. What steps do regulators need to take to implement its stablecoin regime? On July 18, President Trump signed the Guiding and Establishing National Innovation for U.S. Stablecoins Act of 2025 (GENIUS Act), the nation’s first major crypto law. This success is a testament to the leadership of the White House and Senator Bill Hagerty, and proof that Washington is finally serious about modernizing the financial system. The bill erects a clear, first‑of‑its‑kind framework for stablecoins, recognizing the power of dollar‑pegged tokens to make transactions faster and cheaper, and their importance for global dollar dominance. Issuers can now choose between federal or state supervision and get straightforward guardrails on reserves, redemption, audits, and more. But what matters most isn’t just the bill signing; it's what happens next. GENIUS gives regulators just *one year* to implement its provisions, and the clock is already ticking. The next 100 days are pivotal. New OCC chief Jonathan Gould must release joint proposed rules with the other banking agencies, coordinate with state regulators overseeing smaller stablecoin issuers, and prepare for a surge of applications from both new and existing issuers. Handled well, this rollout will cement American leadership in next‑gen payments; stumble or get mired in governmental infighting, and we risk surrendering the field. And with the U.S. moving with speed and clarity, it won’t just gain a competitive edge – it will help establish the global infrastructure crypto needs to grow, giving builders everywhere a reliable foundation for innovation. ## Federal and State Alignment GENIUS empowers stablecoin issuers to choose between federal or state oversight depending on the value of their tokens in circulation. Issuers with tokens under a $10 billion market cap can opt to be regulated by states, provided that the Stablecoin Certification Review Committee, a new body chaired by the Treasury Secretary, deems the state regime “substantially similar” to the federal framework. Once a state-regulated stablecoin surpasses $10 billion, its issuer must transition to federal oversight unless granted a waiver. Crypto-native issuers are already applying for federal charters, and the OCC could soon face a backlog, especially given that a quarter of its staff is expected to depart by year end. This alone is a daunting task for the OCC. To avoid delays, the Treasury Department must quickly set the “broad-based principles” GENIUS requires for determining when a state regime is sufficient. States will also need to align their standards with new requirements under GENIUS, several of which touch on hot button issues that could drive or hinder stablecoin adoption. For example, they’ll need to comply with rules on token-native yield, while protecting popular rewards programs. Banks will lobby hard against these programs because they often offer better returns than traditional bank deposits. Regulators will have to hold firm against bank arguments that ultimately hurt consumers. To succeed, federal and state regulators must: - Develop clear waiver standards for state-regulated issuers exceeding $10 billion; - Engage in comprehensive information sharing; and - Align regulatory and supervisory expectations on rewards programs, capital, wind-down plans, and examinations. ## Global Coordination Payment stablecoins are global products designed for fungibility and unrestricted movement across borders. But to ensure their successful implementation without undue burden on issuers, they require coordinated efforts between the United States and foreign governments. Under GENIUS, the Treasury Department has the power to authorize foreign-registered entities to issue payment stablecoins in the United States so long as those foreign regimes are “comparable” to domestic standards. To do so, the Treasury Secretary must consult with the Stablecoin Certification Review Committee. To avoid regulatory arbitrage, it’s critical that there are clear, public rules defining how foreign regulatory regimes are assessed. Core standards around reserves and attestations should be identical. Rulemaking must also clarify how issuers can support a single, fully fungible stablecoin that is issued both from the U.S. and foreign jurisdictions. Specifically, Treasury should: - Develop clear, rigorous rules for foreign issuers requesting to issue stablecoins within the U.S; and - Explore reciprocal arrangements with foreign countries for cross-border, fully fungible stablecoins. ## Enforcement GENIUS is explicit: only federally or state-authorized issuers may issue payment stablecoins in the United States. Enforcement authority spans across Treasury, the OCC, other federal regulators, and the states. Regulators can take action against issuers in violation of the requirements, revoke their authorizations, or subject them to civil or criminal penalties, depending on the type of violation. Treasury, in particular, can impose civil monetary penalties on digital asset service providers using noncompliant foreign issuers. In order to ensure that enforcement is fair and just, regulators must: - Have the DOJ establish processes for accepting criminal referrals on unauthorized issuance; - Revise banking examination and enforcement procedures under GENIUS; and - Define Treasury’s process for designating noncompliant foreign issuers and enforcing violations by digital asset service providers. # White House Support Leadership from Crypto & AI Czar David Sacks and White House Crypto Council Executive Director Bo Hines will be a force multiplier in the GENIUS rollout. Active White House involvement will be needed to address interagency squabbles and coordination of resources. Sacks and Hines played an instrumental role in getting GENIUS across the finish line, and now they must keep regulators focused, timelines tight, and innovation top of mind. Outside of rulemaking, the White House can also monitor whether federal regulators are faithfully implementing the Trump administration’s policy of ensuring that fair access to banking services extends to stablecoin issuers. The Fed has a years-long record of treating crypto firms unfairly and has previously made it nearly impossible for nonbank stablecoin issuers in particular to obtain direct access to Fed services. With GENIUS passed, the Fed’s discrimination against crypto needs to end. The Fed must now establish even-handed standards for granting master account and payment system access to new classes of stablecoin issuers. If necessary, the White House must use its authority over the Fed’s bank regulatory functions to ensure that it does. The White House should prioritize: - Recruiting qualified talent at the OCC to support its rulemaking; - Coordination between the OCC, Fed, FDIC, and other agencies that need to participate in the rulemaking process; and - Ensuring that the Fed ceases disproportionate treatment of crypto companies, and clarifying the standards for stablecoin issuer master account access. ## Conclusion The passage of the GENIUS Act is not the finish line. It’s the starting gun. The global race for stablecoin leadership is already underway. If the US government acts decisively in the next 100 days, it can anchor a secure, transparent, and innovation-friendly stablecoin ecosystem, catapulting America ahead of the rest of the world in this transformational upgrade to its financial infrastructure. ## https://www.paradigm.xyz/writing/joining-paradigm-ricardo-de-arruda # Joining Paradigm > Ricardo de Arruda joins Paradigm as an Investment and Research partner. I'm thrilled to share that I've joined Paradigm as an Investment and Research Partner to help Matt, Alana, and the rest of the team push the frontier of crypto forward. I started using crypto in 2017. As a 14-year-old reselling sneakers in Brazil, I couldn’t create a bank account because of my age, so I turned to crypto for payments – the idea of "permissionless" systems immediately resonated with my teenage self who didn’t like asking for permission. Years later, while working in traditional finance and exploring crypto on nights and weekends, I became captivated by the research problems being explored by teams like Paradigm, and this inspired me to move into crypto full-time. Subsequently, I got to know the team more deeply through the [Paradigm Fellowship](http://fellowship.paradigm.xyz). I was consistently impressed by their intellectual rigor, principled thinking, and unwavering optimism about crypto’s future. It’s an honor to now get to work alongside them. Data is one of the most powerful tools we have to make sense of the world, and of crypto. It tells us what’s working, what’s new, and who stands to benefit. In my professional career, I’ve focused on answering those questions: designing more accurate [industry metrics](https://visaonchainanalytics.com/transactions#adjusted-transaction-methodology), creating [infrastructure](https://www.allium.so/post/announcing-public-preview-of-delta-sharing-with-cloudflare-r2-integration) to handle petabytes of blockchain data, and helping [protocols](https://wormhole.com/blog/from-eligibility-to-sybil-detection-a-deep-dive-into-wormholes-multichain) [distribute](https://x.com/jito_sol/status/1734611018977063168) [over](https://zk.email/blog/jupiter-and-soft-kyc-at-scale) [$5 billion](https://www.drift.trade/governance/drift-partners-with-allium) [in](https://x.com/bulletxyz_/status/1803731981814890623) [airdrops](https://x.com/9yointern/status/1736033854551674940). At Paradigm, I’ll keep exploring these threads to help inform the investment process, with a focus on separating organic from inorganic activity and researching new ecosystems. I’m especially excited about partnering with teams to design smarter user acquisition and retention programs. Every year, billions of dollars are spent on token incentives, but we still lack reliable frameworks to answer fundamental questions. Who are the real users versus sybils? How do we ensure incentives lead to sustained engagement instead of fleeting attention? I'm eager to dive deep into these problem spaces, incorporating on-chain data analysis, applied ZK, and novel distribution mechanisms. If you're working at the frontier, I'd love to jam on the ideas and problems keeping you up at night. You can reach me anytime via [X DMs](http://x.com/0xdoing) or ricardo@paradigm.xyz. ## https://www.paradigm.xyz/writing/paradigm-files-amicus-in-lewellen-v-bondi # Paradigm Files Amicus in Lewellen v. Bondi > Paradigm files amicus brief supporting Michael Lewellen's lawsuit challenging the DOJ's increasingly aggressive use of 18 U.S.C. § 1960 against software developers Yesterday, Paradigm filed an amicus brief in *Lewellen v. Bondi*, a federal case challenging the DOJ’s attack on software developers publishing open-source code. We joined forces in this case with our allies at the DeFi Education Fund, alongside the Blockchain Association, Crypto Council for Innovation, the Digital Chamber, the Solana Policy Institute, the Bitcoin Policy Institute, and the Uniswap Foundation, to support the plaintiff, Michael Lewellen, a developer who created a non-custodial crypto protocol and wants to make it publicly available. The case challenges the Justice Department’s increasingly aggressive use of a criminal statute aimed at unlicensed money transmitters (18 U.S.C. § 1960), to prosecute mere developers of software who *are not money transmitters*. We filed the brief because the government’s position is not just wrong on the law; it threatens the future of neutral crypto infrastructure in the United States and will send innovation fleeing overseas. ### **Our Amicus Brief** As our brief explains, Section 1960 makes it a crime to operate an unlicensed money transmitting business. But for decades, courts and regulators have agreed that “transmitting” money means *taking custody of someone’s funds and then sending them to someone else*. Read more in our blog post [here](https://www.paradigm.xyz/2025/06/paradigm-files-amicus-brief-supporting-roman-storm). Lewellen, like the developers in the Tornado Cash and Samourai Wallet prosecutions, isn’t proposing to do that. He merely wrote open-source software that other people could use to transfer their own funds directly. That’s not money transmission; it’s publishing code. ### **Why it Matters** The government’s new theory flips all existing caselaw on its head. In *United States v. Storm*, SDNY prosecutors now argue that just writing open-source code that “causes” a transfer is enough to count as transmitting money, with no custody or control required. That interpretation would make all kinds of neutral tools suspect: routers, USB drives, even iPhones. Would you prosecute Ford when a bank robber drives a Mustang getaway car? The DOJ’s approach flatly contradicts years of Treasury Department guidance under both Presidents Obama and Trump that said custody and control are the key to determining whether money transmission is implicated. And it’s also laughably unworkable. Just like any other publisher, developers of immutable smart contracts often don’t (and can’t) know who is using their code or for what purpose. We’re seeing practical fallout already. Developers who followed the rules, consulted lawyers, and relied on government guidance now find themselves at risk of indictment–or are already facing trial, in the case of Roman Storm. Understandably, the reaction of the developer community is to stop innovating and to lose faith that the law in the United States means what it says. Some are leaving the country altogether. Without a change, the next generation of DeFi will be built* outside *the United States, far away from our influence and values. This chilling effect doesn’t just hurt crypto innovation; it erodes the rule of law. It goes without saying that criminal statutes need to give fair warning. If publishing lawful, non-custodial software today might unexpectedly land you in prison tomorrow, something has gone deeply wrong. That’s why we’re asking the court to reject the government’s motion to dismiss. The law should be clarified *before* more people are prosecuted, not after. Developers shouldn’t have to risk prison just to find out if their work is legal. We believe the Constitution demands better, and that the court should say so now. The full amicus brief is available [here.](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-8d16b4a9d5/fdea917e27a054c543dea5423f7e7366/asset-https-cdn-sanity-io-files-dgybcd83-p-8d16b4a9d5.pdf) ## https://www.paradigm.xyz/writing/paradigm-policy-market-mapping-exercise-spring-2025 # Paradigm Policy Market Mapping Exercise Spring 2025 > Crypto ownership is more than an investment—it’s a signal. Paradigm’s new market mapping exercise explores the voters behind the movement, offering fresh insight into how and why crypto is shaping American politics. Who is the crypto user? Crypto is undoubtedly having a political moment. Policymakers finally understand its global impact: Visa [notes](https://visaonchainanalytics.com/transactions) that stablecoins have seen $4 trillion in onchain transaction volume over the last 30 days. More than [two-thirds](https://www.paradigm.xyz/2025/03/tradfi-tomorrow-defi-and-the-rise-of-extensible-finance) of TradFi firms are looking at DeFi. And earlier this month, Bitcoin ETFs [hit](https://x.com/AltCryptoGems/status/1937156347658690886?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Etweet) a cumulative trading volume of over $1 trillion, a milestone achieved in less than 18 months. And we are making substantial progress toward regulatory clarity. The Senate passed the GENIUS Act by a supermajority, moving us closer to a regulatory regime for payment stablecoins. The House is deep in the process of marking up a market structure bill, the CLARITY Act, with likely passage by the fall. And regulatory agencies from the CFTC to Treasury are providing real clarity on how firms can access, issue, and trade crypto products. But political progress is downstream of regular Americans demanding change, which they did en masse in the last election through groups like Stand with Crypto. Who are they? Why do they own crypto? How important is crypto to them? To answer these questions, we conducted an extensive market mapping survey, surveying *only *crypto users in the United States to dive deep into their politics, consumer preferences, opinions, and anxiety about the world. What we found was both expected and unexpected: crypto owners are more active than ever. They voraciously read the news and pay attention to developments around the world. They were deliberate and thoughtful in their decision to buy crypto, and they are ready to make their voices heard. (See [below](https://docs.google.com/document/d/1xK1MiEAGv3zSULhrWMkBKbFXY67HoRbRqpsilMte5fM/edit?tab=t.0) for methodology.) **Crypto owners are diverse and cross the political spectrum in surprising ways** Crypto owners defy political stereotypes. - In terms of party affiliation, 37% are GOP and 36% are Democrats, with 24% considering themselves independents. - 31% identify as liberal, 29% identify as conservative, and 37% identify as moderate. - 64% of owners are men, and 36% are women. 62% of owners are white, 19% are black, 21% are Hispanic, 7% are Asian, and 4% are Native American, Hawaiian, or Alaskan *(Respondents were able to choose multiple races and ethnicities).* ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--34f2264403/a236ae05bd2040d77793b5fa4e9dd25d/asset-https-cdn-sanity-io-images-dgybcd83--34f2264403.jpg) ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--b2844c918b/f72fdd0ea75d9ab84c7aa629f9efab05/asset-https-cdn-sanity-io-images-dgybcd83--b2844c918b.png) **Owning crypto is significant to many owners’ identities; this is a culture as much as it is an industry** Crypto is key to people’s identity in surprising ways. This is not a group that is shy about their interest in this industry, though many hesitate to discuss crypto unless they're confident the other person is genuinely interested in the topic. - Of those surveyed, 28% stated that the crypto assets they own or have owned says a lot about who they are, while 31% said that their crypto assets say a little about who they are (collectively 59%). Just 34% said the crypto assets they own don’t say much about them. As a comparison, 67% said the jewelry or watch they wear said a lot or a little about who they are, and 72% said the car they drive said a little or a lot about who they are. - Among respondents, 29% said that “being someone who owns crypto is important to me” was a major reason they owned crypto. - 24% of owners are happy to bring up crypto in conversations, with another 16% saying they “enjoy explaining crypto” when someone else brings it up, and 23% saying they discuss it with people who show genuine interest. - Among those who say crypto says a lot about who they are, 45% of crypto users report that they are happy to bring up crypto in conversation. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--a587f6a8fe/173c9a51a4bef76cf31cbd64b849eaf4/asset-https-cdn-sanity-io-images-dgybcd83--a587f6a8fe.jpg) **Crypto owners are highly diverse in their media consumption** Crypto owners consume media from a broad array of sources. - A majority of owners, 56%, say they typically encounter news or information about crypto from social media, and 50% say they encounter such news from YouTube. These numbers are consistent for conservatives, liberals, and moderates, but vary greatly by age: 66% of those 18-22 say they get their crypto news from social media, but just 33% of those 61 and older do. - 35% of crypto owners typically get news or information from crypto industry news outlets (such as CoinDesk or Bankless). This figure rises to 40% for Republicans but falls to 29% for independents. For Democratic crypto owners, 35% typically get news from crypto industry outlets. - 30% of crypto owners get their news from mainstream news outlets online or in print. This figure is consistent for all ideologies, with 32% of liberals, 31% of conservatives, and 29% of moderate owners marking this response. - 27% of crypto owners typically encounter crypto news or information from podcasts. This figure rises to 29% for conservatives, but is 26% for moderates and 25% for liberals. - Just 20% of crypto owners say they typically get crypto news and information from financial advisors, but 22% get it from AI platforms like ChatGPT, 27% from family and friends whose opinions they value, and 42% from search engines like Google. - 22% of crypto owners typically get crypto news or information from group chats or servers like Discord and Telegram. This number rises to 27% of college graduate owners and 31% of those who hold a graduate degree, but amounts to just 19% of those who didn’t graduate from college. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--7d79f308f7/f73f0ef1eaf4577760d2edf10061185a/asset-https-cdn-sanity-io-images-dgybcd83--7d79f308f7.png) **Crypto owners are optimistic risk-takers** Crypto owners are at base optimistic risk takers. In owning crypto, they are protecting themselves from market risk, inflation, and even from government overreach. - 69% of crypto owners said they strongly (31%) or somewhat (37%) agreed with the statement that “I am someone who doesn’t mind a big risk.” - This carries over to respondents’ view of crypto. 62% of respondents said they were either extremely optimistic (33%) or very optimistic (29%) that crypto will contribute to a positive future for the world. 10% said they were either not very optimistic or not at all optimistic, with 4% of respondents choosing the latter. - Notably, there was less optimism about the idea that blockchain technology will contribute to a positive future for the world, with 48% saying they were extremely optimistic or very optimistic, and 14% saying they were not very optimistic or not at all optimistic. - Users also worry about overregulation of crypto, with 62% very or somewhat concerned. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--afcf905961/4149e23c02158c06e09c418918ccb9c5/asset-https-cdn-sanity-io-images-dgybcd83--afcf905961.png) **Most crypto owners hold a substantial amount of crypto, and for some it represents a notable percentage of their net worth** Crypto owners are all-in. 33% of crypto owners have 25% or more of their net worth in crypto. 46% of crypto owners own more than $5000 in crypto. - Of those surveyed who currently own crypto, 56% have more than 10% of their net worth in crypto, with 17% having more than 50% of their net worth in crypto. - Among men and women under 40, 18-19% have more than half of their net worth in crypto. - Among liberals, 19% had more than half of their net worth in crypto; among conservatives, 20% had more than half of their net worth in crypto; and among moderates, 13% had more than half of their net worth in crypto. - Among Harris voters, 30% had more than a quarter of their total net worth in crypto. Among Trump voters, 37% had more than a quarter of their total net worth in crypto. - In this poll, about 46% of those surveyed voted for Trump in 2024, with 33% voting for Harris. - Among those who voted, 42% said crypto policy was extremely or very important when deciding who to vote for: 20% said crypto policy was “extremely important” when deciding who to vote for in 2024, 22% said it was very important, and 21% said it was somewhat important, with 20% saying it was not at all important. - Trump won the voters who said crypto policy was “extremely important” 48-34%. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--c622cab3a3/9364e0359b5594087bb482faa298d61b/asset-https-cdn-sanity-io-images-dgybcd83--c622cab3a3.png) ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--5cc5b5c0e4/9c041970ae56495cb2a14121d4b300ba/asset-https-cdn-sanity-io-images-dgybcd83--5cc5b5c0e4.jpg) **Most crypto owners are just Bitcoin or Ether owners** Many crypto owners only own BTC and/or ETH, but a decent minority own memecoins. Notably, the biggest year for people first buying crypto was 2020, but interest has remained higher than pre-pandemic ever since. And yes, the example of the American who got a crypto account before they got a bank account is real. - 79% of those who currently or previously own crypto have bought Bitcoin, while 42% have bought Ethereum, and 30% have bought USDC. All other tokens are owned by less than 20% of respondents, including Tether and Solana (both at 17%). - 37% of crypto owners have only bought Bitcoin and Ethereum, and 54% of owners have only both BTC, ETH, and/or stablecoins. - This skews heavily by age: 63% of respondents aged 61 and older own crypto exclusively in the form of Bitcoin, Ethereum, or stablecoins, compared to just 50% of those aged 23 to 28. - Despite most people not owning them, 56% of crypto owners have a very positive (24%) or somewhat positive view of memecoins like Dogecoin. 15% have a very negative (5%) or somewhat negative (9%) view of memecoins. 20% of crypto owners have heard of memcoins but say they have no opinion of them. - 20% of crypto owners first bought in 2020, including 20% of men and 21% of women owners. - We asked whether respondents first had a checking or savings account, a Venmo or PayPal account, or crypto. 10% said they had crypto first, including 12% of those 18-22. 72% said they had a checking or savings account first, and 17% said they had a Venmo or PayPal Account first. - 42% of respondents said they had used crypto to make a payment for goods and services, with this figure rising to 48% of male respondents under 40. - Since then, each year has seen significant new crypto owners, with 11% of owners buying in 2021, 13% in 2022, 12% in 2023, 10% in 2024, and 3% so far in 2025. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--dd0cf89052/73a4545c145c65145df3289c171b3768/asset-https-cdn-sanity-io-images-dgybcd83--dd0cf89052.png) ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--46648c4685/8df94f8485fce3b152b6199854f0c419/asset-https-cdn-sanity-io-images-dgybcd83--46648c4685.png) ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--8752aeeee9/7af1f1c42f7578548c72c89454d58146/asset-https-cdn-sanity-io-images-dgybcd83--8752aeeee9.jpg) **Other notable facts regarding crypto owners** - Crypto owners are avid gamers, with 88% playing video games at least monthly and a majority (52%) gaming at least once a day. - Crypto users spend significant time in-person with their family and friends. 69% report spending time in-person with their parents at least once a month, and 63% spend time in-person with their close friends at least once a week. - Crypto owners also attend religious services with some regularity, with 46% attending religious services at least monthly and 34% attending at least weekly and 5% attending daily. - The vast majority (83%) of crypto owners exercise or go to the gym at least monthly, with 31% doing so at least once a day. - A majority of crypto owners (57%) meditate at least once a week, with 71% doing so at least once a month. - In terms of highest educational attainment, 33% either finished high school or did not complete it, 17% had some college attendance but did not gain a degree, 11% have an associate degree, 24% have a bachelor’s degree, and 14% have a graduate degree. - 68% are currently employed full-time and 8% are employed part-time. Another 3% are in freelance or temporary work, and 1% are in “gig economy” work like ride shares, food delivery, or dogwalking. 3% are a stay-at-home parent or caregiver, 5% are retired, 2% are full-time students, and 7% are unemployed and looking for work. - 95% of crypto owners in the survey were born in the United States, 1% were born in a U.S. territory or abroad to citizen parents, and 4% were born in a foreign country. - 77% of crypto owners have a pet, 77% of crypto owners own a gaming console, 86% of crypto owners own a car, and 32% of crypto owners own a gun. - A majority either strongly agree (23%) or somewhat agree (28%) with the statement that “the economy is rigged against people like me.” Approximately a quarter strongly disagree (10%) or somewhat disagree (14%). - While approximately six in ten strongly agree (26%) or somewhat agree (33%) that “government regulation does more harm than good,” over seven in ten also strongly agree (42%) or somewhat agree (29%) that “the wealthy should have to pay a lot more in taxes.” ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--add1ef7825/1a2724e3318cb3064a0f0ca235eb8288/asset-https-cdn-sanity-io-images-dgybcd83--add1ef7825.png) Note on methodology: The survey was fielded online by Echelon from May 7–28, 2025 in English among a sample of 4,000 crypto users using non-probability sampling, and the margin of error was 1.7%. The sample was weighted to reflect demographic characteristics of the population of crypto users based on Echelon Insight’s Consumer Omnibus surveys from 2024 and 2025, which ask U.S. adults about current or past crypto use. Among a U.S. adult sample size of N=6,108, a subset of N=1,282 were Crypto Users. Weighting dimensions derived from this subset included gender, age, race/ethnicity, education, region, party, and income. ## https://www.paradigm.xyz/writing/the-l1-dilemma # The L1 Dilemma > How to win as a new L1. New L1s succeed by exploiting the dogma of incumbents. Ethereum succeeded by exploiting Bitcoin's resistance to programmability. Solana succeeded by exploiting Ethereum's devotion to home stakers. Hyperliquid is succeeding by exploiting Solana's unwillingness to specialize their protocol. The reality is that all great L1s are born as cults. As these ecosystems grow, the dogma that once fueled them starts to tighten, creating space for competition. If they aren't careful, the crusade that got them where they are can distract them from credible competitive threats. Of course, exploiting an incumbent L1's dogma does not guarantee success – after all, Bitcoin is still king. But this is what buys you the headroom to compete. Fortunately for new entrants, today's incumbents are [mired](https://x.com/0xalpo/status/1920231012086214799) in [dogma](https://x.com/0xalpo/status/1920231250364690547). This dynamic is the crypto equivalent of the Innovator's Dilemma – the L1 Dilemma. What are today's L1s dogmatic about? Here are a few candidates: - Geographic decentralization is important - BFT consensus is prerequisite (e.g. optimistic or whitelist-based are untouchable) - Becoming a validator should be permissionless - Deploying smart contracts should be permissionless - Sharding is bad - All apps should be treated the same by the chain - All transactions should be subject to the same notion of finality - One token as the staking token - Faster is better (24h block times?) - Chain upgrades should be manual (automate with decision markets?) If you’re interested in or currently working on any of the above (or have ideas on alternatives), please reach out! *Special thanks to Matt Huang, Storm Slivkoff, Dan Robinson, Frankie, Arjun Balaji for discussion and feedback.* ## https://www.paradigm.xyz/writing/paradigm-files-amicus-brief-supporting-roman-storm # Paradigm Files Amicus Brief Supporting Roman Storm > Paradigm files amicus brief supporting Storm’s proposed jury instructions in United States v. Storm. Paradigm filed an amicus brief in *United States v. Roman Storm*, a case that could dictate the future of software development in the United States. In *Storm*, the U.S. Attorney’s Office in the Southern District of New York has argued that the mere creation of software enabling peer-to-peer cryptocurrency transactions constitutes “money transmitting” under 18 U.S.C. §1960 – contrary to the plain text of the law, clear FinCEN guidance, and decades of case law. **Why It Matters** The irrationality and unfairness of these charges cannot be overstated. The Treasury Department has long recognized that developers who publish software are not money transmitters. In 2014, the Obama Treasury Department [explained](https://www.fincen.gov/sites/default/files/shared/FIN-2014-R002.pdf) that “the production and distribution of software, in and of itself, does not constitute acceptance and transmission of value.” In 2019, Treasury [further explained](https://www.fincen.gov/sites/default/files/2019-05/FinCEN%20Guidance%20CVC%20FINAL%20508.pdf) that “total independent control” over users’ crypto was a key factor in determining whether an intermediary is a money transmitter under the Bank Secrecy Act. Like any American, Storm should have been able to rely on this clear written guidance by the federal regulator of money transmitters – not be prosecuted in a case of first impression. The practical consequence of the SDNY’s position is that any developer of neutral code could be held criminally liable for how that code is used or abused. This is as absurd as prosecuting a television manufacturer for the sharing of state secrets on-air, leather wallet craftsmen for wallets holding stolen cash, or Apple for conspiracies formed through iPhone conversations. Understanding this, in April the Department of Justice issued a [policy memo](https://www.justice.gov/dag/media/1395781/dl?inline) repudiating the very kind of prosecutorial overreach Storm is being subjected to. The memo ended the Biden DOJ’s campaign of “regulation by prosecution.” Crucially, the memo bars prosecutions under Section 1960’s registration prongs (a charge SDNY has now dropped) unless prosecutors can show the defendant knew of the registration violation and willfully violated it. In doing so, the DOJ correctly recognized that pursuing criminal charges against an individual for neutral activity lacking criminal intent based on supposed regulatory violations is deeply problematic when the regulatory requirements are, at best, unclear. Unfortunately, SDNY has continued to charge Storm under a different Section 1960 provision, using a potential loophole in the DOJ memo to continue to pursue their position that software developers who never take custody or control of funds can be criminally prosecuted as money transmitters. Allowing this charge to persist risks letting unelected prosecutors change the plain meaning of criminal statutes–and threaten everyday citizens with imprisonment even if they are following widely-disseminated and accepted regulatory guidance. **Our Amicus Brief** As Paradigm argues in our brief, given SDNY’s failure to dismiss the 1960 charges fully, the Court must at least appropriately cabin jury instructions to confine its reach to persons who fully understand what it means, as a factual matter, to operate a money transmitting business. In other words, the jury must be required to find beyond a reasonable doubt that Storm knowingly operated a recurring, fee-charging, money-transmitting business, knowingly transmitted funds on behalf of the public, and knowingly handled the specific proceeds alleged to be criminal. The jury should also be charged that Storm must knowingly have had custody or control of the funds being transmitted or transferred. We believe that the prosecution’s view that one does not need custody or control of funds in order to be a money transmitter is not just contrary to the plain language of the statute and regulatory guidance, but also inconsistent with factual reality. You cannot transfer funds unless you have custody or control of those funds. Absent that, at a minimum, the jury must be charged that to be found guilty, Storm must have *known* he was operating a money transmitting business even though that business did not have custody or control of the funds being transferred via the Tornado Cash protocol. The stakes of this matter are high: an unfair result could chill not just software development and innovation in crypto and fintech, but have ripple effects on the broader open source, AI, and technology communities alike. Between the Southern District of New York and the Court itself, we urge common sense, due process, and fairness. The full amicus brief is available [here](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-aed25f5fdb/aa7ce870499fcf6e437518ef7d11cf73/asset-https-cdn-sanity-io-files-dgybcd83-p-aed25f5fdb.pdf). ## https://www.paradigm.xyz/writing/uk-crypto-regulation-must-embrace-defi-paradigm-responds-to-the-fca # UK Crypto Regulation Must Embrace DeFi: Paradigm Responds to the FCA > Paradigm responds to the Financial Conduct Authority on the importance of embracing DeFi. Crypto is global. Even as America moves closer to legislation on stablecoins and market structure, the rest of the world is also charging ahead. Embracing DeFi is not optional; it's a prerequisite for remaining competitive in the future of global finance. The UK has, over[ multiple](https://www.gov.uk/government/news/government-sets-out-plan-to-make-uk-a-global-cryptoasset-technology-hub)[ administrations](https://www.theblock.co/post/303562/uk-elections-labour-crypto), expressed its ambition to be a global hub for digital asset innovation. This dream will manifest or dissipate depending on how the Financial Conduct Authority (FCA) approaches decentralized finance (DeFi). Last week, Paradigm submitted a response on the FCA’s[ Discussion Paper 25/1](https://www.fca.org.uk/publications/discussion-papers/dp25-1-regulating-cryptoasset-activities) on regulating cryptoasset activities, highlighting crucial steps to ensure DeFi can flourish in the United Kingdom. We believe in the immense potential for DeFi to transform traditional financial (TradFi) markets by reducing costs, streamlining operational efficiency, and bolstering transparency. The data speaks for itself: our recent[ research](https://www.paradigm.xyz/2025/03/tradfi-tomorrow-defi-and-the-rise-of-extensible-finance) shows over two-thirds of TradFi firms are exploring DeFi solutions to overcome their existing inefficiencies. Despite this clear opportunity to streamline market operations, ambiguous or overly restrictive regulations continue to hold TradFi back from further engaging with DeFi. For a country like the United Kingdom that is seeking increased productivity and economic gains from crypto, there is a golden chance to set an example. Our feedback to the FCA emphasized two ways to foster a competitive and innovation-friendly environment for DeFi: 1.      Clearer Regulatory Boundaries Around Decentralization We believe clearer guidance is needed on what constitutes sufficient decentralization. A precise framework, reflective of global regulatory developments, would provide much-needed certainty for innovators and investors alike. Decentralization should be assessed by: - Absence of privileged access or administrative keys. - Transparent, onchain governance decisions. - Clear controls on smart contract upgrades - Broad, decentralized validator nodes. Instead of punitive measures for edge cases, the FCA should adopt an inquisitive approach, seeking to learn and adapt regulatory guidance jointly with industry stakeholders. 2\. Leverage Public-Private Partnerships for Improved Policy Development Regulating DeFi effectively requires a flexible and inclusive approach. Paradigm recommends that the FCA establish working groups that include industry leaders, such as TradFi institutions, centralized exchanges, and DeFi protocols. These groups should focus on developing: - A practical set of standards to determine decentralization - Accountability measures that encourage companies to be transparent, such as self-certification, and open-source compliance tools. Proactive measures created through these working groups would ensure adaptive regulations that foster innovation and prioritize consumer protection. By embracing DeFi thoughtfully and in partnership with the private sector, the FCA can set the stage for substantial growth in both the crypto and TradFi sectors. More importantly, they can be for the world what has been missing thus far on DeFi: a guiding light for how countries can support DeFi’s tremendous potential through policy. Paradigm looks forward to continuing our engagement with the FCA and supporting the growth of the UK's thriving crypto ecosystem. Read our full response to the FCA[ here](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-885d29cd7c/1348b67f7213b876ef0827cca9fda6ca/asset-https-cdn-sanity-io-files-dgybcd83-p-885d29cd7c.pdf). ## https://www.paradigm.xyz/writing/introducing-the-2025-paradigm-fellowship # Introducing the 2025 Paradigm Fellowship > We’re excited to announce our third annual Paradigm Fellowship: a program for students, recent grads, and dropouts who are curious techno-optimists – drawn to markets, incentive design, and shaping how money moves online. Trillions of dollars in stablecoins now flow onchain, where markets run 24/7 and adversarial MEV wars play out by the second. Protocols are created, forked, exploited, and iterated on in the open. With crypto, new financial systems and internet-native economies are being built and battle-tested live. The frontier is evolving faster than ever – and we’re looking for the people who want to explore it up close. We’re excited to announce our third annual Paradigm Fellowship: a program for students, recent grads, and dropouts who are curious techno-optimists – drawn to markets, incentive design, and shaping how money moves online. Fellows tend to thrive in fast feedback loops, high-stakes environments, and open-ended experimentation. Over a two-day retreat on the beautiful Northern California coast, you’ll join 30 other obsessive, deeply technical builders – some already immersed in crypto, others coming from AI, math, economics, trading, or other related fields at the frontier. Together with the Paradigm team and other Fellows, you’ll explore whatever problem space feels most compelling: mechanism design, distributed systems, agentic commerce, applications, developer tooling, and more. Past Fellows have met cofounders, collaborators, and lifelong friends through the program. Many have gone on to build companies (some funded by Paradigm), join high-growth startups, and pursue advanced research. Today, alumni work full-time in crypto or adjacent fields at places like Paradigm, Circle, Privy, OpenAI, Citadel, Uniswap, Succinct, and more. The 2025 Paradigm Fellowship runs from September 24th - 26th. Applications will be open until July 25th. [**Apply now →**](https://fellowship.paradigm.xyz/) ## https://www.paradigm.xyz/writing/quantum-markets # Quantum Markets > A capital efficient mechanism for scaling futarchy.
Animation by Dave Whyte
## Background Today's decision markets can only evaluate a single proposal for each decision. As a result, every new proposal for a decision requires fresh liquidity from traders, leading to a significant capital efficiency problem. For example, take the following decision: “Which EIP should Ethereum implement next?” There are 700+ active EIPs that could be considered. Let's say you're a trader with $1M of capital and you have an opinion on all of these proposals. In the standard approach for decision markets, you would need to spread your $1M across all 700+ proposals. This would give you on average less than $1,500 per market to trade. With quantum markets, you would be able to trade the full amount on each proposal. ## Core Mechanism Let's step through an example of a quantum market that has the goal of finding the best EIP to implement to increase the price of ETH. To those who have heard of–or used–[MetaDAO](https://docs.metadao.fi/) this may seem familiar. In both systems, we take a DAO token (ETH in this case) and allow it to be traded in parallel across different worlds. However, in the quantum market case we start with a question (”Which EIP should ETH implement next?”) and allow anyone to permissionlessly create (tradable) proposals. With MetaDAO today, we would need to bootstrap new liquidity for each proposal we consider for this decision. In a quantum market, traders would be able to deposit funds into the system and get an equivalent amount of tradable credits on every current and future proposal for the decision. As they trade these markets, a predicted ETH price would emerge for each proposal. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--dd8f5dbad0/dddb11898aa0d96ca380a7758502fd46/asset-https-cdn-sanity-io-images-dgybcd83--dd8f5dbad0.jpg) As time goes on, the market for EIP 2 predicts much higher growth in value for ETH than EIP 1 or 3. When the settlement time is reached, the quantum market triggers a "wave function collapse" by observing the predicted values and selecting the proposal that predicts the highest ETH price. Since traders were issued their full deposit amount in each market, if a user did not trade in the passing proposal they retain their principal and their PnL is identical to if they had simply held ETH and USDC outside of QM. ### Step-by-Step Breakdown Below we break down a much more granular walkthrough of the EIP example. Quantum market created with decision criteria: - Select the EIP that maximizes ETH price The following three proposal markets are created by market participants: 1. EIP 1 2. EIP 2 3. EIP 3 These markets get traded on until they predict an ETH price of $3200, $3000, and $100 respectively. Alice opens the markets and notices that the ETH-EIP-2 and ETH-EIP-3 are both underpriced. **Status Quo Path:** 1. Alice, starting with $1M (500k USDC, $500k in ETH) in the bank, starts depositing funds into the EIP-2 market until the price is $3500. However, the market is liquid enough for these trades to consume all of Alice’s $1M. 2. Alice does not have enough funds to correct the inefficiency in the proposal 3 market. **Quantum Market Path:** 1. Alice deposits $1M and gets $1M in trading credits in *both* proposal markets that she’s interested in trading. 2. She uses her $1M in the EIP 2 market to bring it to $3500, and her $1M in the EIP 3 market to bring it to $3000 (or as close as her $1M will get her). 3. She leaves the EIP 1 untouched, as she believes it is fairly priced. **End State:** - EIP 2 passes because it predicts a higher ETH price ($3500 > $3200). - Proposal markets 1 & 3 are fully aborted/reverted since they didn’t pass. Any trade that happened in those proposal markets is essentially a no-op. - The proposal market for EIP 2 settles an hour after it goes live. The price is $3500. - Alice makes money on this trade since she bought up from $3000 to $3500. ### Example 2: Token Launchpad Today's token launchpads lack any form of accountability. This is especially true in memecoin focused ones that have a notion of "graduating" tokens once they reach a specific market cap. The problem with this approach is that it incentivizes blind sniping, which ultimately muddies the waters. A second problem is that the space of possible tokens to launch is too large. When you have 100,000+ tokens launching per day, it becomes prohibitively capital-expensive to trade on all of them. With quantum markets a launchpad can set some cadence with which token launches happen (e.g. one per hour) and let anyone propose an arbitrary number of tokens for each launch. For each new proposed token, all existing traders can trade on its expected outcome (i.e. “Will this token reach $50m market cap within a week?”) without putting up any new capital. It's difficult to overstate how scalable such a system can get. A QM-based token launchpad can plausibly evaluate millions of tokens for each launch without adding any additional capital overhead to traders. If launch throughput becomes an issue, these markets can be run in parallel batches to accommodate more actual launches. ### Proposal Market Flexibility One important property of quantum markets is that the underlying virtual proposal markets can have any construction as long as markets are directly comparable to each other on some predicted metric. They can be binary or continuous prediction markets, [AMM-based](https://www.paradigm.xyz/2024/11/pm-amm), spot, or even [distribution market-based](https://www.paradigm.xyz/2024/12/distribution-markets). For example, the EIP example above could have been based on continuous prediction markets for the impressions of a potential tweet. The one that would ultimately pass in this case would be the tweet that has the highest percentage likelihood of `YES`. ### Static vs. Dynamic Decision Markets Status quo decision markets are static by construction. It is not possible for anyone to contribute a proposal to an ongoing decision market – the only option is to create an entirely new one. Quantum markets, on the other hand, can be dynamic. Anyone can propose an improved idea into the market while it is active. This is critical for two reasons: 1. It allows for increased dynamic participation by humans 2. It allows for unbounded participation by AI agents The second point is discussed in greater detail in a later section, but it is an incredibly important unlock. AI agents can be much more generative than current decision markets can accommodate, and quantum markets unlocks them to fully express their preferences on-chain. Since this is a more involved discussion, it is unpacked at the end of this post to not distract from the core mechanism. ## Use Cases The reality is that most important decisions require (or would at least benefit from) an efficient way to evaluate multiple proposals. Many candidate options need to be considered. These use cases are sidelined from using decision markets due to classical markets providing insufficient scale: **it is simply too expensive to require fresh liquidity on the long tail of proposals.** Let’s take a small sampling of use cases to demonstrate just how vast the design space unlocked by quantum markets might be: 1. What should my agent tweet? (Goal: highest expected like/follower count) 2. What trade should my on-chain vault make? (Goal: highest expected vault token price (proxy for AUM)) 3. Which EIP should Ethereum roll out next? (Goal: highest long-run token price) Each of these decisions has to take into consideration a large set of options. With the status quo approach, these decisions are confined to only considering a tiny sliver of the option space. ## AI Agents and Quantum Markets AI agents are becoming increasingly capable of making human-level decisions. As a result, there is growing interest in offloading important decisions to agentic AI systems. Today, most attempts at doing the above have involved hard-coding a specific AI agent as the decision-maker. This model has a number of issues: 1. Counterparty risk due to centralization from whoever hosts the agent 2. Agent is prone to mistakes or manipulation that humans wouldn't make 3. New frontier agents need to manually be switched to (fork or redeployment) Decision markets are a natural substrate to resolve the issues above: 1. The best agents make more of the decisions over time as they accumulate capital 2. [Proposals by humans](https://vitalik.eth.limo/general/2025/02/28/aihumans.html) can still be considered as a guardrail to AI-proposed ones 3. Frontier agents can automatically participate, even before they are publicly known about or open sourced The issue with decision markets in this context is that they are impractical. Even frontier agents can create proposals at an inference cost that is rapidly approaching $0. As a result, participation in on-chain decision making by AI agents is constrained primarily by the capital efficiency of the decision market mechanism that they are interacting with. Since quantum markets have no marginal cost of liquidity for each new proposal, AI agents can run on them at the cost of inference. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--3626734c9d/59e85733fb419982d166e0f2961006d9/asset-https-cdn-sanity-io-images-dgybcd83--3626734c9d.png) For example, a given decision might receive 100,000 proposals from various AI agents, and have each proposal traded on by the handful of frontier agents that can predict proposal performance. ## Code We’ve included starter repos for quantum markets in both [Solidity](https://github.com/Sofianel5/quantum-markets/tree/master) (more in-depth) and [Solana/SVM](https://github.com/Sofianel5/quantum-markets-svm/tree/master). Our Solidity implementation takes advantage of Uniswap V4 hooks to efficiently handle core functionality. **Disclaimer:** these repos are reference implementations and should not be used in a production environment. ## Conclusion Quantum markets demonstrate that the design space of decision markets is still vastly under-explored. If you're interested in working on this mechanism or have related ideas, please reach out on Twitter/X! ## Acknowledgements [Dan Robinson](https://x.com/danrobinson), [Dave White](https://twitter.com/_Dave__White_), [Siong Ong](https://x.com/sssionggg), [Zaki Manian](https://x.com/zmanian), [Proph3t](https://x.com/metaproph3t), [Dev Ojha](https://x.com/valardragon), [Tina Zhen](https://x.com/tzhen?lang=en), [Vitalik Buterin](https://x.com/VitalikButerin), [Alana Palmedo](https://twitter.com/alanapalmedo) ## https://www.paradigm.xyz/writing/orbital # Orbital > The future holds a million stablecoins. Today's infrastructure isn't ready. This paper introduces Orbital, an automated market maker for pools of 2, 3, or 10,000 stablecoins. Orbital unlocks capital efficiency by bringing concentrated liquidity to unlimited dimensions.
Animation by Dave Whyte
# Introduction The future holds a million stablecoins. Today's infrastructure isn't ready. This paper introduces Orbital, an automated market maker for pools of 2, 3, or 10,000 stablecoins. Orbital unlocks capital efficiency by bringing concentrated liquidity to higher dimensions. # Overview This is a graph of the reserves of an automated market maker (AMM) between USDC and USDT. When traders add USDT, they get USDC in return. In the middle, where reserves are equal, the coins have the same price. At the edges, one is worthless compared to the other. [Uniswap V3](https://app.uniswap.org/whitepaper-v3.pdf) pioneered the concept of concentrated liquidity. It creates and consolidates mini-AMMs, called ticks, that support more trading with less capital by restricting themselves to only a specified price range. Uniswap v3 allows liquidity providers to create positions between any two tick boundaries, and efficiently aggregates their liquidity so that traders can interact with it as if it were a single pool. However, it only supports pools between two assets. [Curve](https://berkeley-defi.github.io/assets/material/StableSwap.pdf) created an invariant-based AMM that allows trading of N stablecoins in a single pool. It focuses liquidity around the price of 1. However, Curve uses a uniform strategy for each pool, meaning all liquidity providers in the same pool have the same liquidity profile. Orbital extends customizable concentrated liquidity to pools of three or more stables by drawing tick boundaries as orbits around the $1 equal price point. Unlike in 2D concentrated liquidity, even if one stablecoin depegs to 0, an Orbital tick can still trade the others at fair prices. Smaller ticks closer to the equal $1 price point don't need to hold capital in reserve to give out in case one of the coins depegs. This lets LPs focus their resources where normal trading actually happens, unlocking significant capital efficiency gains. The full Orbital AMM combines ticks of different sizes so LPs can customize their exposures. Some might choose to focus narrowly around the $1 point for maximum efficiency, while others might provide wider coverage to earn fees during times of volatility. Under the hood, Orbital ticks are $n$-dimensional spherical caps. Thanks to symmetry, we can orbit some around the others to obtain a single toroid (donut-like) shape. This lets us compute trades efficiently onchain regardless of the number of different coins in the pool. # Intuition The math below gets pretty dense, but it's just trying to formalize a relatively simple visual intuition. In the 3D case, depicted above, the base Orbital AMM is a sphere. We only show 1/8th of the sphere in the animation because it's the only relevant part assuming prices stay non-negative. The Orbital *tick* in the diagram refers to the part of the sphere inside the red circle. The red circle itself forms the *boundary* of the tick. Note that, unlike in Uniswap V3, Orbital ticks actually overlap, so that larger ones fully contain smaller ones. We can see from the animation that a Orbital tick can be in one of two states. If prices for all the stablecoins are sufficiently close to the equal $1 price point, then the reserves will be somewhere on the interior tick. But once prices have diverged enough, the tick's reserves will become pinned to its boundary. Now, imagine we have hundreds or thousands of ticks. Each one of them will either be an "interior tick" or a "boundary tick." Locally, all interior ticks behave like spheres. Since they are geometrically similar, we can consolidate them all and treat them like a single sphere. Similarly, all boundary ticks behave locally like circles (in general, in $n$ dimensions, they behave like $n-1$-dimensional spheres. Since they are geometrically similar, we can again consolidate them all and treat them like a single circle. Logically speaking, we are now dealing with one spherical AMM and one circular AMM. By rotating the sphere around the circle, we obtain a single torus, or donut shape. The equation of this torus is simple enough that we can compute trades across its surface efficiently onchain. To compute larger trades, we update the equation every time a tick changes from boundary to interior or vice versa. Luckily, all of this stays true in high-dimensional space, and the rest of the paper goes into the details of how that works. # Mechanism ## The Sphere AMM ### Formula Orbital is built on top of the Sphere AMM $$||\\vec{r}-\\vec{x}||^2=\\sum_{i=1}^n (r-x_i)^2 = r^2$$ where $x_i$ is AMM's reserve of asset $i$. To see that the minimum reserve of any asset is $0$, note that the sphere is centered at $\\vec{r} = (r, r, \\dots, r)$, and the farthest a point on the sphere can be from the center in any dimension is the radius $r$. As long as asset prices are positive, no-arbitrage implies we should never have reserves $x_i > r$ for any $i$, since if $x_i=r+d$ for some $d>0$, then $$(r-x_i)^2 = d^2 = (r-(r-d))^2 = (r-(x_i-2d))^2$$ and some trader could remove $2d$ of asset $i$ for free without affecting the AMM's constant function constraint, and by assumption it would have positive value. Therefore we won't add an explicit contraint for $x_i \\leq r$ to the AMM, but can assume that $x_i \\leq r$ for all $i$ in normal circumstances. ## Token Prices on the Sphere Let's say a trader wants to give the AMM some token $X_i$ and take out some token $X_j$ while staying on the surface $$F(\\vec{x})=||\\vec{r}-\\vec{x}||^2=r^2$$ In this case, we must have $$\\frac{\\delta F}{\\delta x_i}\\delta x_i + \\frac{\\delta F}{\\delta x_j} \\delta x_j = 0$$ so, abusing notation a bit, we can express the instantaneous price of one unit of $x_j$ as $$\\frac{\\delta x_i}{\\delta x_j} = -\\frac{\\delta F}{\\delta x_j}/\\frac{\\delta F}{\\delta x_i} = \\frac{r-x_j}{r-x_i}$$ Intuitively we can verify that if the AMM has high reserves of $X_j$ and low reserves of $X_i$, this fraction will be small, meaning you don't get much $X_i$ per unit of $X_j$, and vice versa. ## The Equal Price Point The most important point on the surface of our AMM is the point where all reserves are equal, so that, by symmetry, all prices are equal. This should be the the normal state for stablecoins, because under normal conditions they should all worth the value they are pegged to, e.g. $1. Let's denote this point $$\\vec{q}=(q,q,\\ldots,q)$$ By our sphere constraint, we have $$r^2 = \\|\\vec{r} - \\vec{q}\\|^2 = \\sum_{i=1}^n (r - q)^2 = n(r - q)^2$$ So then $$(r-q)^2=\\frac{r^2}{n}\\Rightarrow r - q = \\frac{r}{\\sqrt{n}}$$ so $$q = r\\left(1 - \\sqrt{\\frac{1}{n}}\\right)$$ and we have $$\\vec{q} = r\\left(1 - \\sqrt{\\frac{1}{n}}\\right)(1, 1, \\dots, 1)$$ Since they're all multiples of $(1,1,\\dots,1)$, there's a line from the origin, through the equal price point, and to the center of the AMM. We can represent its direction with the unit vector $$ \\vec{v} = \\frac{1}{\\sqrt{n}} (1, 1, \\dots, 1)$$ In terms of trading, we can think of $\\vec{v}$ as a portfolio of $\\frac{1}{\\sqrt{n}}$ of each of the coins in the AMM. ## Polar Reserve Decomposition This section introduces a concept and notation we'll be using to work with ticks through the rest of the paper. Given any valid reserve state $\\vec{x}$ on the surface of the AMM, linear algebra tells us we can decompose it into a vector parallel to $\\vec{v}$ and a vector $\\vec{w}$ orthogonal to $\\vec{v}$, the vector from the origin to the equal price point. In other words, for any reserve state $\\vec{x}$, we have $$\\vec{x} = \\alpha\\vec{v} + \\vec{w} \\quad \\text{where} \\quad \\vec{v} \\perp \\vec{w}$$ Note that because $\\vec{v}$ is a unit vector, we can calculate $\\alpha$ directly as $\\vec{x} \\cdot \\vec{v}$, which mechanically equals $\\frac{1}{\\sqrt{n}}\\sum_{i=1}^n x_i$ — $\\frac{1}{\\sqrt{n}}$ times the sum of all reserves in $\\vec{x}$. Viewed through the lens of this decomposition, our AMM constraint becomes $$r^2 = \\|\\vec{x} - r\\|^2 = \\|(\\alpha \\vec{v} + \\vec{w}) - r \\cdot \\vec{1}\\|^2 = \\|(\\alpha \\vec{v} + \\vec{w}) - r \\sqrt{n} \\cdot \\vec{v}\\|^2 = \\|(\\alpha - r \\sqrt{n}) \\vec{v} + \\vec{w}\\|^2$$ Since $\\vec{v} \\perp \\vec{w}$ by definition, we can use the Pythagorean theorem to simplify this to $$r^2 = (\\alpha - r\\sqrt{n})^2 + \\|\\vec{w}\\|^2$$ or, rearranging, $$\\|\\vec{w}\\|^2 = r^2 - (\\alpha - r\\sqrt{n})^2$$ From this, we can see that if we hold the component of reserves parallel to $\\vec{v}$ constant, our AMM acts as a lower-dimensional spherical AMM in the subspace orthogonal to $\\vec{v}$ with radius $$s = \\sqrt{r^2 - (\\alpha - r\\sqrt{n})^2}$$ ## Tick Definition ### Notes In the interest of simplicity, for the rest of the paper we will act as if each tick has only one liquidity provider. Of course, in practice, we would allow multiple LPs to pool their liquidity into the same tick, just like in Uniswap V3. As a reminder, ticks in Orbital are nested. Each is centered at the equal price point, and larger ticks fully overlap with smaller ticks. This is in contrast to Uniswap V3, where ticks are fully disjoint. ### Geometric Intuition We can think of a tick geometrically as all the points on the sphere's surface that are within some fixed geodesic distance from the equal-price point. In the 3D case visualized above, it's possible to intuit that we can construct the boundary of such a tick by slicing the sphere with a plane orthogonal to the vector $\\vec{v}$ from the equal price point to the sphere's center. We formalize this construction for higher dimensions below. ### Tick Boundary Geometry Any plane normal to $\\vec{v} = \\left( \\frac{1}{\\sqrt{n}}, \\frac{1}{\\sqrt{n}}, \\dots, \\frac{1}{\\sqrt{n}} \\right) \\in \\mathbb{R}^n$ has the form $$\\vec{x} \\cdot \\vec{v} = k$$ This is another way of saying that the plane consists precisely of all points whose projection on $\\vec{v}$ is $k$ -- i.e. the points of the form $k\\vec{v}+\\vec{w}$ for some $\\vec{w}\\perp\\vec{v}$, which you get by starting from $k\\vec{v}$ and adding some vector orthogonal to $\\vec{v}$. From the polar reserve decomposition section above, we can see that when reserves lie on this boundary, since the component of reserves parallel to $\\vec{v}$ is constant at $k\\vec{v}$, the tick AMM functions as a spherical AMM in the $n-1$-dimensional subspace orthogonal to $\\vec{v}$ with radius $s = \\sqrt{r^2 - (k - r\\sqrt{n})^2}$ and center $(k - r\\sqrt{n})\\vec{v}$. By symmetry, every point on this boundary will have an equal geodesic distance from the equal price point. ## Tick Size Bounds This section is relatively technical and defines the sizes of the smallest and largest ticks that make sense. ### The Minimal Tick The minimal tick boundary would be the equal price point itself, which we derived above as the point $\\vec{q}$ where $$x_i = r\\left(1 - \\sqrt{\\frac{1}{n}}\\right)$$ for all $i$. In that case $\\vec{x} \\cdot \\vec{1} = r(n-\\sqrt{n})$, and since $\\vec{v}=\\frac{1}{\\sqrt{n}}\\vec{1}$, we can define this tick using the plane constant $$k_{\\text{min}} = \\vec{x} \\cdot \\vec{v} = \\frac{\\vec{x} \\cdot \\vec{1}}{\\sqrt{n}} = r(\\sqrt{n} - 1)$$ ### The Maximal Tick The maximal tick's boundary is defined by the plane that lets us achieve the highest possible value of $\\vec{x}\\cdot\\vec{v}$ that doesn't require any reserve $x_i$ to go above $r$. This happens when one reserve $x_j$ reaches its minimum value of 0 while all other reserves are at the maximum, $r$. For example, consider $x_1=0$ and $x_2=x_3=\\cdots=x_n=r$. It's still on the sphere because $$\\sum_{i=1}^n (r - x_i)^2 = r^2 + \\sum_{i=2}^n (r - r)^2 = r^2$$ and we have $$k_{\\text{max}} = \\vec{x} \\cdot \\vec{v} = \\frac{0 + (n - 1)r}{\\sqrt{n}} = r \\frac{n - 1}{\\sqrt{n}}$$ To see that this is indeed the maximal tick boundary, note that the reserves of all tokens but $X_1$ are already at their maximum of $r$ assuming positive prices. So, the only way we might be able to increase $\\vec{x}\\cdot\\vec{v}$ further would be to increase the reserves of $X_1$ while decreasing the other reserves by a lesser amount so that we don't violate the AMM constant. But note that the gradient of $\\|\\vec{r} - \\vec{x}\\|^2$ is $$2(\\vec{r}-\\vec{x}) = (r, 0, \\ldots, 0)$$ at this point. So if the AMM reduces its $x_2$ reserves infinitesimally, because of the 0 gradient we won't decrease the value of the AMM constant $\\|\\vec{x} - r\\|^2$ at all. That means so we can't increase $x_1$ to compensate, and this indeed is the maximum tick boundary. ## Tick Reserve Bounds and Virtual Reserves This section explores how tick boundaries affect the minimum and maximum token reserves a tick can hold, and the implications that has for capital efficiency. ### Minimum Reserves Consider an Orbital tick with a plane constraint of $$\\vec{x}\\cdot\\vec{v}=k$$ Let's derive the minimum possible reserves of any one of the coins, which we'll denote as $X_{\\text{min}}$. By symmetry, the reserves of all the other $X_{\\text{other}}$ must be equal to one another at that point. Our sphere constraint then becomes $$(r - x_{\\text{min}})^2 + (n - 1)(r - x_{\\text{other}})^2 = r^2$$ and our plane invariant becomes $$\\frac{1}{\\sqrt{n}} \\left( (n - 1)x_{\\text{other}} + x_{\\text{min}} \\right) = k$$ so that $$x_{\\text{other}} = \\frac{\\sqrt{n}k - x_{\\text{min}}}{n - 1}$$ Solving the resulting quadratic equation for $x_{\\text{min}}$ we get $$x_{\\text{min}} = \\frac{k\\sqrt{n} - \\sqrt{k^2 n - n\\left((n - 1)r - k\\sqrt{n}\\right)^2}}{n}$$ In terms of trading, this will usually represent the situation where all coins but one depeg to a low value, causing traders to remove as much of that still-stable coin as they can from the AMM. ### Virtual Reserves No matter what traders do, they cannot force the reserves of any token $X_i$ to fall below $x_{\\text{min}}$. This means the liquidity provider creating the tick can act as if they have "virtual reserves" of $x_{\\text{min}}$ of each of the stablecoins the tick trades and don't actually need to provide those $x_{\\text{min}}$ tokens when creating the tick. As in Uniswap V3, this is what allows for the capital efficiency we will discuss below. ### Maximum Token Reserves We can repeat the above derivation but flip the sign of the square root to find the *maximum* quantity of any given coin in the tick assuming both constraints are binding. Since, if prices are positive, no coin balance will go above $r$, we can then define $$x_{\\text{max}} = \\min\\left(r, \\frac{k\\sqrt{n} + \\sqrt{k^2 n - n\\left((n - 1)r - k\\sqrt{n}\\right)^2}}{n}\\right)$$ and $$x_{\\text{other}} = \\frac{\\sqrt{n}k - x_{\\text{max}}}{n - 1}$$ In terms of trading, this will normally represent the situation where one single coin loses its peg and falls in value, while the other coins remain stable, causing traders to give the AMM as much of that one coin as they can. We call this a single-depeg event. ## Interpreting k If we assume that the most common way things will "go wrong" is a single depeg event of the type described in the section immediately above, then for small enough $k$ we are concentrating liquidity where no coin has yet depegged down to a certain threshold -- for example, the area where no coin has depegged to below 99 cents. Assuming only one coin depegs and the rest stay constant, and that $k$ is small enough that the plane constaint is binding, the depegged coin will have reserves of $$x_{\\text{depeg}} = \\frac{k\\sqrt{n} + \\sqrt{k^2 n - n\\left((n - 1)r - k\\sqrt{n}\\right)^2}}{n}$$ and $$x_{\\text{other}} = \\frac{k\\sqrt{n} - x_{\\text{depeg}}}{n - 1}$$ Recall from the section on pricing that the instantaneous price of token $X_j$ with respect to token $X_i$ is $$\\frac{\\delta x_i}{\\delta x_j} = -\\frac{\\delta F}{\\delta x_j} \\bigg/ \\frac{\\delta F}{\\delta x_i} = \\frac{r - x_j}{r - x_i}$$ In that case, the tick boundary corresponds to the single token depegging to $$p_{\\text{depeg}} = \\frac{r - x_{\\text{depeg}}}{r - x_{\\text{other}}}$$ We can then invert this to obtain, for a given $p_{\\text{depeg}}$, the $k$ such that the boundary kicks in exactly at that depeg price: $$k_{\\text{depeg}}(p_{\\text{depeg}}) = r\\sqrt{n} - \\frac{r(p_{\\text{depeg}} + n - 1)}{\\sqrt{n(p_{\\text{depeg}}^2 + n - 1)}}$$ Note that for large-enough $k$, such as $k_{\\text{max}}$, the tick will remain fully in-range as multiple coins depeg all the way to 0, so this interpretation won't be relevant there and we are better of thinking about metrics like maximum portfolio loss assuming all coins but one depeg. ## Capital Efficiency As we derived above, given a plane constant $k$, the LP of a given tick gets to take advantage of virtual reserves $$x_{\\text{min}}(k) = \\frac{k\\sqrt{n} - \\sqrt{k^2 n - n\\left((n - 1)r - k\\sqrt{n}\\right)^2}}{n}$$ for each of the $n$ assets. If we assume they create the AMM when reserves are at the equal price point $\\vec{q}$, the reserves they would need to provide for each coin in the spherical AMM would be $$x_{\\text{base}} = r\\left(1 - \\sqrt{\\frac{1}{n}}\\right)$$ So, assuming prices never diverge enough to push reserves past the boundary of the tick, there is a capital efficiency gain of $$\\frac{x_{\\text{base}}}{x_{\\text{base}} - x_{\\text{min}}(k)}$$ Using the depeg price formula from the prior section, we can compute how much capital efficiency you get by picking a boundary corresponding to a max depeg price of $p$: $$c_{\\text{efficiency}}(p) = \\frac{x_{\\text{base}}}{x_{\\text{base}} - x_{\\text{min}}(k_{\\text{depeg}}(p))}$$ ![log Capital Efficiency Ratio vs. Depeg Price for n=5](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--84ecf52e05/51f10f37a1cedd9715a6c061eb79efeb/asset-https-cdn-sanity-io-images-dgybcd83--84ecf52e05.png) *log Capital Efficiency Ratio vs. Depeg Price for n=5* For example, in the 5-asset case, a depeg limit of $0.90 corresponds to around a 15x capital efficiency increase, while a limit of $0.99 corresponds to around a 150x capital efficiency increase. You can view the interactive graph on Desmos [here](https://www.desmos.com/calculator/gtyh2pr4fa). ## Tick Consolidation ### Overview A full Orbital AMM consists of multiple Orbital ticks with different $k$ values. In this section, we discuss situations in which multiple ticks can be treated as one for the purposes of trade calculations. This will set us up to construct a global trade invariant for the overall orbital AMM in the next section. As a reminder, for the sake of simplicity we will assume each tick has only a single LP. ### Consolidation Math Imagine we have 2 ticks, $T_a$ and $T_b$ with reserves $\\vec{x}_a$ and $\\vec{x}_b$ and parameters* $(r_a, k_a)$* and $(r_{b}, k_{b})$ respectively. #### Case 1: Both Reserves Interior The simplest case is that both reserves vectors begin and end the trade "interior" to their respective ticks, which is to say, not on the tick boundary -- i.e. $$ \\vec{x}_a \\cdot \\vec{v} < k_a \\quad \\text{and} \\quad \\vec{x}_b \\cdot \\vec{v} < k_b $$ In this case, both ticks behave locally like normal spherical AMMs, and it must be that $\\vec{r}_a-\\vec{x}_a$ is parallel to $\\vec{r}_b-\\vec{x}_b$, since otherwise at least one of the $x_i$ would have a different price relative to some $x_j$ on the two AMMs, allowing for an arbitrage. Since by definition $\\vec{r}_a=r_a\\sqrt{n}\\vec{v}$ and $\\vec{r}_b=r_b\\sqrt{n}\\vec{v}$, we can see that $\\vec{r}_a-\\vec{x}_a$ is parallel to $\\vec{r}_b-\\vec{x}_b$ if and only if $$\\vec{x}_a=\\frac{r_a}{r_b}\\vec{x}_b$$ This means the combined reserves of the two AMMs are equal to $$\\vec{x}_a + \\vec{x}_b = \\left(1 + \\frac{r_a}{r_b}\\right) \\vec{x}_b = (r_a + r_b) \\frac{\\vec{x}_b}{\\|\\vec{x}_b\\|}$$ Since our AMM constant is $\\|\\vec{x}\\| = r$, we can see that reserves scale with the AMM's radius, and so locally we can treat the two ticks as a single spherical AMM with $$r_c = r_a + r_b$$ As soon as one of the reserve vectors hits the boundary of its tick, we can no longer treat the two ticks as a single spherical AMM, and must move on to one of the later cases. #### Case 2: Both Reserves on Boundary Let's say that both ticks start with reserves that are on their boundaries as defined by their plane constants. Now imagine that they execute a trade $\\vec{\\Delta}$ such that their reserves move from $\\vec{x}$ to $\\vec{x}'=\\vec{x}+\\vec{\\Delta}$ after which they are still on their boundaries. In this case for tick $A$ we have $$\\vec{x}_a \\cdot \\vec{v} = k_a \\quad \\text{and} \\quad \\vec{x}'_a \\cdot \\vec{v} = (\\vec{x}_a + \\vec{\\Delta}_a) \\cdot \\vec{v} = k_a + \\vec{\\Delta}_a \\cdot \\vec{v} = k_a \\Rightarrow \\vec{\\Delta}_a \\cdot \\vec{v} = 0$$ This means the trade vector $\\vec{\\Delta}_a$ must be orthogonal to $\\vec{v}$ if tick reserves both start and end on the boundary, and the same must be true for $\\vec{\\Delta}_b$. In other words, this trade is entirely within the subspace orthogonal to $\\vec{v}$. As we discussed in the section on tick boundary geometry, ticks on their boundaries behave like spherical AMMs in the subspace orthogonal to $\\vec{v}$. Because both AMMs have centers parallel to $\\vec{v}$, which is orthogonal to every vector in that subspace, we can treat this subspace AMM as having a center of $0$, and by similar logic to case 1 it has a radius of $$s_c = s_a + s_b$$ where from the section on tick boundary geometry we have e.g. $$s_a=\\sqrt{r_a^2 - (k_a - r_a\\sqrt{n})^2}$$ ## Global Trade Invariant This section describes how we can locally compute trades using all of our ticks simultaneously. It is extremely dense. Your favorite LLM may be of some assistance if you are wanting to parse it. ### Setup First, note that the tick consolidation section above shows we can consolidate all currently interior ticks into a single spherical tick in $\\mathbb{R}^n$, and all currently boundary ticks into another spherical tick in the subspace of $\\mathbb{R}^n$ orthogonal to $\\vec{v}$. So, for the rest of this section, we will assume we have precisely two ticks, one interior and one boundary. We call the total reserve vector of our combined Orbital AMM $\\vec{x}_{\\text{total}}$. As described in the section on polar reserve decomposition, we can break this down into components parallel and orthogonal to $\\vec{v}=\\frac{1}{\\sqrt{n}} (1, 1, \\dots, 1)$, so $$\\vec{x}_{\\text{total}} = \\alpha_{\\text{total}} \\vec{v} + \\vec{w}_{\\text{total}}$$ for some $\\vec{w}_{\\text{total}} \\perp \\vec{v}$. We do the same for our consolidated and boundary ticks: $$\\vec{x}_{\\text{int}} = \\alpha_{\\text{int}} \\vec{v} + \\vec{w}_{\\text{int}}$$ $$\\vec{x}_{\\text{bound}} = \\alpha_{\\text{bound}} \\vec{v} + \\vec{w}_{\\text{bound}}$$ and because $x_{\\text{total}} = x_{\\text{int}} + x_{\\text{bound}}$, we must have $$\\alpha_{\\text{total}} = \\alpha_{\\text{int}} + \\alpha_{\\text{bound}}$$ $$\\vec{w}_{\\text{total}} = \\vec{w}_{\\text{int}} + \\vec{w}_{\\text{bound}}$$ ### Finding alpha_bound and alpha_int We know that the boundary reserves $\\vec{x}_{\\text{bound}}$ must satisfy $$\\vec{x}_{\\text{bound}} \\cdot \\vec{v} = k_{\\text{bound}}$$ by definition, since a boundary AMM always has its reserves on the boundary as defined by its plane constraint. By the polar reserve decomposition, we also have $$\\vec{x}_{\\text{bound}} \\cdot \\vec{v} = (\\alpha_{\\text{bound}} \\vec{v} + \\vec{w}_{\\text{bound}}) \\cdot \\vec{v} = \\alpha_{\\text{bound}}$$ so that $$\\alpha_{\\text{bound}} = k_{\\text{bound}}$$ Since $$\\alpha_{\\text{total}} = \\alpha_{\\text{int}} + \\alpha_{\\text{bound}}$$ we then have that $$\\alpha_{\\text{int}} = \\alpha_{\\text{total}} - \\alpha_{\\text{bound}} = \\vec{x}_{\\text{total}} \\cdot \\vec{v} - k_{\\text{bound}}$$ ### Showing w_int and w_bound are parallel Construct an orthonormal basis $\\vec{z}_1, \\ldots, \\vec{z}_{n-1}$ for the subspace orthogonal to $\\vec{v}$. Together with $\\vec{v}$, this constitutes an orthonormal basis for our entire reserve space, where each basis element represents some basket of the constitutent stablecoins in different proportions. Since this is just a rotation of the axes, our interior tick is still a spherical AMM between all of these new basis vectors, and our boundary tick, being a spherical AMM in the subspace orthogonal to $\\vec{v}$, is a spherical AMM between all the basis vectors of that subspace, $\\vec{z}_1, \\ldots, \\vec{z}_{n-1}$. From this, we can see that the interior tick and boundary tick must hold the $\\vec{z}_i$ in equal proportions, since otherwise there would be some $i$ and $j$ for which the price of the bundle $\\vec{z}_i$ was different to the price of the bundle $\\vec{z}_j$ on the boundary and interior ticks, which would present an arbitrage opportunity. Since the $\\vec{z}_i$ form a complete basis for the subspace of reserve space orthogonal to* $\\vec{v}$, *this implies that* $\\vec{w}_{\\text{int}}$* must in fact be parallel to $\\vec{w}_{\\text{bound}}$. ### Finding ||w_int|| Recall from the section on tick boundary geometry that $$\\|\\vec{w}_{\\text{bound}}\\|^2 = s_{\\text{bound}}^2 = r_{\\text{bound}}^2 - (k_{\\text{bound}} - r_{\\text{bound}} \\sqrt{n})^2$$ Since, as we showed in the previous subsection, $\\vec{w}_{\\text{int}}$ is parallel to* $\\vec{w}_{\\text{bound}}$*, the length of their sum is simply the sum of their lengths, so $$\\|\\vec{w}_{\\text{total}}\\| = \\|\\vec{w}_{\\text{int}}\\| + \\|\\vec{w}_{\\text{bound}}\\|$$ Substituting in, we then obtain $$\\|\\vec{w}_{\\text{int}}\\| = \\|\\vec{w}_{\\text{total}}\\| - \\|\\vec{w}_{\\text{bound}}\\| = \\|\\vec{x}_{\\text{total}} - (\\vec{x}_{\\text{total}} \\cdot \\vec{v}) \\vec{v}\\| - \\sqrt{r_{\\text{bound}}^2 - (k_{\\text{bound}} - r_{\\text{bound}} \\sqrt{n})^2}$$ ### The Full Invariant Our interior tick's sphere invariant is $$r_{\\text{int}}^2 = \\|\\vec{r}_{\\text{int}} - \\vec{x}_{\\text{int}}\\|^2$$ by the Pythagorean theorem, this implies $$r_{\\text{int}}^2 = \\|\\vec{r}_{\\text{int}} - \\alpha_{\\text{int}} \\vec{v}\\|^2 + \\|\\vec{w}_{\\text{int}}\\|^2 = (\\alpha_{\\text{int}} - r_{\\text{int}} \\sqrt{n})^2 \\|\\vec{v}\\|^2 + \\|\\vec{w}_{\\text{int}}\\|^2$$ Substituting in our results from the previous sections and simplifying, we then obtain our full invariant $$r_{\\text{int}}^2 = \\left((\\vec{x}_{\\text{total}} \\cdot \\vec{v} - k_{\\text{bound}}) - r_{\\text{int}} \\sqrt{n}\\right)^2 + \\left(\\|\\vec{x}_{\\text{total}} - (\\vec{x}_{\\text{total}} \\cdot \\vec{v}) \\vec{v}\\| - \\sqrt{r_{\\text{bound}}^2 - (k_{\\text{bound}} - r_{\\text{bound}} \\sqrt{n})^2}\\right)^2$$ Note this is equivalent to the formula for a generalized torus, a higher-dimensional extension of the familiar donut shape. Intuitively, this is because we are "adding together" the liquidity from the interior tick, a full sphere, with the liquidity from the boundary tick, a lower-dimensional sphere in a subspace, just the same way as a donut is construced by centering a sphere over every point on a circle. ### Computation We can directly compute this invariant as $$r_{\\text{int}}^2 = \\left( \\frac{1}{\\sqrt{n}} \\sum_{i=1}^n x_{\\text{int}i} - k_{\\text{bound}} - r_{\\text{int}} \\sqrt{n} \\right)^2 + \\left( \\sqrt{ \\sum_{i=1}^n x_{\\text{total}i}^2 - \\frac{1}{n} \\left( \\sum_{i=1}^n x_{\\text{total}i} \\right)^2 } - \\sqrt{ r_{\\text{bound}}^2 - (k_{\\text{bound}} - r_{\\text{bound}} \\sqrt{n})^2 } \\right)^2$$ Implementations of orbital should keep track of the sums of reserves and squared reserves that appear in that expression. Since trades of one token for another affect only two of terms in those sums, we can compute the invariant for trades in constant time regardless of the number of dimensions $n$. ## Trading Within Tick Boundaries ### Logic Now that we have the global trade invariant, it is straightforward to compute trades. Let's say a user provides $d$ units of asset $i$ to the AMM and wants to exchange it for as much of asset $j$ as they can get. Starting from some valid reserve state $\\vec{x}_{\\text{total}}$, we simply update the value of $x_i$ to $x_i+d$ and then solve for the $x_j$ that satisfies the global invariant while leaving all other asset balances the same. If there are multiple solutions, we choose the one that leaves the ending balances of $x_j$ below the centers of both the interior and boundary ticks. This is a quartic equation in $x_j$, which we can solve easily onchain using Newton's method. As mentioned above, if we explicitly track sums in the AMM, the complexity of the equation remains constant time regardless of the number of dimensions in the AMM. ## Crossing Ticks The global trade invariant we derived in the previous section assumes that ticks maintain their status as either "interior" or "boundary." However, during trades, the system's state can change in a way that causes a previously interior tick's reserves to become pinned at its boundary (or vice versa). In that case, we need to remove the tick from the consolidated boundary (interior) tick, and add it to the consolidated interior (boundary) tick, and then update the torus formula accordingly. In this section, we'll explain how to detect when these crossings happen and how to handle them by breaking the trades that cause them into segments. ### Intuition Imagine we have several ticks of different sizes, each one a sphere intersected by a plane determined by that tick's plane constant. These spheres might be different sizes depending on their respective radii, but we could imagine "zooming in" or "zooming out" on the spheres so that they all appeared to be the same size, perhaps represented by a radius of 1. If we were to do this, we would see something interesting: all of the ticks that are currently "interior," i.e. all the ticks whose reserves are not precisely on their plane boundary, would appear to have their reserves at exactly the same point on the sphere. Geometrically, we can say this is because the spheres are *similar*. In terms of trading, we can say, as above, that this is because otherwise there would be an arbitrage opportunity between the ticks. Furthermore, ticks have their reserves trapped on their plane boundary and become boundary ticks precisely when this common reserve point strays farther from the equal price point than that tick's plane boundary. So, in order to trade across ticks, we just compute the trade assuming no ticks have moved from interior to boundary as described in the section on within-tick trades. Then we check the new common interior reserve point and see if it has crossed over the plane boundary of either the closest interior tick or the closest boundary tick. If it has, we compute the trade exactly up to that boundary point, update the type of the tick that was crossed, and compute the rest of the trade. ### Normalization We use normalized quantities to compare ticks of different sizes by dividing through by the tick radius. The *normalized position* is $x^{\\text{norm}} = \\vec{x} / r$ The *normalized projection* is $\\alpha^{\\text{norm}} = \\vec{x}^{\\text{norm}} \\cdot \\vec{v} = \\frac{\\vec{x} \\cdot \\vec{v}}{r}$ The *normalized boundary* is $k^{\\text{norm}} = \\frac{k}{r}$ Note that if $\\alpha^{\\text{norm}} = k^{\\text{norm}}$ for a given tick, we can multiply both sides by $r$ to remove the normalization and see that the tick is at its boundary. Suppose that for a given tick we have $\\alpha^{\\text{norm}} < k^{\\text{norm}}$, so that it is an interior tick. By no-arbitrage, its reserve vector $\\vec{x}$ will be parallel to the reserve vectors of all other interior ticks, and so its normalized reserve vector $\\vec{x}^{\\text{norm}}$ will be precisely equal to the normalized reserve vector of all interior ticks, which we will call $\\vec{x}^{\\text{norm}}_{\\text{int}}$. This interior normalized reserve vector has a projection $$\\alpha^{\\text{norm}}_{\\text{int}} = \\vec{x}^{\\text{norm}}_{\\text{int}} \\cdot \\vec{v}$$ A given tick $i$ is interior if and only if $k^{\\text{norm}}_i > \\alpha^{\\text{norm}}_{\\text{int}}$. To see why, first assume $i$ is interior. Then by definition $k^{\\text{norm}}_i > \\alpha^{\\text{norm}}_i = \\alpha^{\\text{norm}}_{\\text{int}}$. For the other direction, assume $k^{\\text{norm}}_i > \\alpha^{\\text{norm}}_{\\text{int}}$. Then if this tick were to have the same normalized position as an interior tick, it would not hit its plane constraint, implying that by no-arbitrage it must in fact have this normalized position, making it an interior tick. ### Trade Segmentation Process At any given time, the AMM's location in tick space is demarcated by $k_{\\text{int}}^{\\text{min}}$, the minimum normalized $k$ of a currently interior tick, which will be the next tick to become trapped at its boundary if the overall reserves continue to move away from the equal price point. Similarly, $k_{\\text{bound}}^{\\text{max}}$ is the maximum normalized $k$ of a currently boundary tick, which will be the first tick to become interior again as AMM reserves return to the equal price point. Let's say we are trying to compute a trade $\\vec{\\Delta}_{\\text{total}}$ where the user putting in some quantity $d_i^{\\text{total}}$ of asset $X_i$ to remove some of asset $X_j$. The steps to segment the trade are as follows: **Calculate Assuming No Tick Boundary Crossing:** Assume all currently interior ticks stay interior and all currently boundary ticks stay boundary and compute the potential final AMM state $\\vec{x}_{\\text{potential}}$ and the corresponding interior tick normalized projection* $\\alpha_{\\text{int}}^{\\text{norm}}$* using the global trade invariant method above. **Boundary Crossing Check:** If our assumptions were correct and no ticks changed from interior to boundary or vice versa, then we will have $k_{\\text{bound}}^{\\text{max}} \\leq \\alpha_{\\text{int}}^{\\text{norm}} \\leq k_{\\text{int}}^{\\text{min}}$ -- i.e. our new interior tick point separates all the interior tick boundaries from all the boundary tick boundaries. If that's the case, we're done. Otherwise, we need to segment the trade. **Segmentation (If Crossing Detected)** We know the normalized boundary being crossed from the prior step, which we'll call $k_{\\text{cross}}^{\\text{norm}}$. This crossover is going to occur when $\\alpha_{\\text{int}}^{\\text{norm}} = k_{\\text{cross}}^{\\text{norm}} \\Rightarrow \\alpha_{\\text{int}} = r_{\\text{int}} k_{\\text{cross}}^{\\text{norm}}$. So then at the crossover point, we have $$\\alpha_{\\text{crossover}} = \\vec{x} \\cdot \\vec{v} = \\vec{x}_{\\text{int}} \\cdot \\vec{v} + \\vec{x}_{\\text{bound}} \\cdot \\vec{v} = \\alpha_{\\text{int}} + k_{\\text{bound}}^{\\text{total}} = r_{\\text{int}} k_{\\text{crossover}}^{\\text{norm}} + x_{\\text{bound}}^{\\text{total}}$$ where $k_{\\text{bound}}^{\\text{total}}$ is the sum of the $k$ values of all currently boundary ticks. **Find Intersection Trade $\\vec{\\Delta}_{\\text{crossover}}$** We want to find the trade $$\\vec{\\Delta}_{\\text{crossover}} = (0, \\ldots, d_i^{\\text{crossover}}, 0, \\ldots, -d_j^{\\text{crossover}}, 0, \\ldots)$$ between $i$ and $j$ that respects the global invariant while taking us precisely to the crossover point $\\vec{x}_{\\text{crossover}} = \\vec{x} + \\vec{\\Delta}_{\\text{crossover}}$ where we have $$\\alpha_{\\text{crossover}} = \\vec{x}_{\\text{crossover}} \\cdot \\vec{v} = (\\vec{x} + \\vec{\\Delta}_{\\text{crossover}}) \\cdot \\vec{v} = \\alpha_{\\text{total}} + \\vec{\\Delta}_{\\text{crossover}} \\cdot \\vec{v} \\\\ = \\alpha_{\\text{total}} + \\frac{1}{\\sqrt{n}}(d_i^{\\text{crossover}} - d_j^{\\text{crossover}})$$ so that we see $$d_j^\\text{crossover}=\\sqrt{n}(\\alpha_\\text{total}-\\alpha_\\text{crossover}) + d_i^\\text{crossover}$$ Substituting that in to the global invariant formula from above yields a quadratic equation in $d_i^{\\text{crossover}}$ which we can simply solve using the quadratic formula. Once we find the crossover point, we can execute the trade up to there, adjust the crossed tick from interior to boundary or vice versa, and proceed with the rest of the trade, re-segmenting if necessary. # Conclusion Today, Orbital is just a design, but we're excited to see how it might change the stablecoin liquidity landscape. If you're interested in exploring with us, we'd love to hear from you. # Acknowledgements [Joey Santoro](https://x.com/0xJoeysantoro), [Jordi Alexander](https://x.com/gametheorizing), [Will Price](https://x.com/will__price), [Alan Niemerg](https://x.com/niemerg), [Mahmoud Lababidi](https://x.com/lababidi) ## https://www.paradigm.xyz/writing/defi-perps-deserve-a-path-forward # DeFi Perps Deserve a Path Forward in the US: Paradigm Responds to the CFTC’s Perpetual Derivatives Request for Comment > Paradigm Files Comment Letter on Perpetual Derivatives Last week, Paradigm filed a comment letter with the Commodity Futures Trading Commission regarding the trading and clearing of perpetual derivatives. The request’s focus on perpetuals certified by registered entities is a reasonable place to start, but it is just that: a start. Perpetuals are *the* dominant crypto derivative, accounting for 93 percent of all crypto derivatives volume in 2025. And most of that trading happens on DeFi protocols, on which the request is conspicuously silent. In our view, any durable framework for perpetuals must include DeFi. Onchain perpetuals are a superior product on every axis, providing unparalleled transparency, composability, and counterparty risk management. That said, we understand this is a big lift, so our letter asks the CFTC to create a Perpetuals Special Advisory Committee, composed of those with both rose-colored glasses and gimlet eyes for perpetuals, and to give it 90 days to report on how DeFi perpetuals can operate in tech-neutral U.S. regime. Three areas deserve particular attention from this new committee: - **A public interest exemption:** Forcing DeFi protocols into the SEF or DCM core principles is an impractical solution to a problem that could be solved in ways that also increase the Commission’s control over this emerging market. The CEA allows the CFTC to exempt transactions and persons on stated terms and for stated periods, and the Commission should use this authority to adopt a time-limited, conditional exemption that imposes real guardrails. - **A fit-for-purpose compliance framework:** Existing CFTC obligations should be evaluated and allocated to operators in a way that accounts for the decentralized nature of crypto. Different levels of the crypto stack—from front ends to development teams to end users—need different rules, but they all need a regulator who understands what they can (and cannot) do. - **A path for retail:** Retail participation in these markets is a clock that cannot be unwound. Users know the value that these markets provide, and shutting off a U.S. pathway will not stop retail from participating; it will just force them off U.S. exchanges. The Commission should avoid an impulse towards paternalism that would do nothing but protect potential beneficiaries out of the market. The Commission should be commended for ending the regulation by enforcement that characterized its posture for too long, but building something durable is a different task. The CFTC has repeatedly shown that it is up to the challenge—it did, after all, set standards for Bitcoin futures that built the deepest, most liquid, and best regulated markets in the world—and we are confident that it will meet the moment here as well. We appreciate the Commission taking these questions up, and you can read our full comment [here](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-eba531333d/c9ffa3c40d2a3c102b7cbef4fff96d75/asset-https-cdn-sanity-io-files-dgybcd83-p-eba531333d.pdf). ## https://www.paradigm.xyz/writing/introducing-alloy-v1-0 # Introducing Alloy v1.0: The simplest, fastest Rust toolkit for the EVM > We’re excited to release Alloy v1.0, our first stable release, reaffirming our commitment to performance, stability, and great developer experience. Alloy is a complete re-write of ethers-rs and builds on years of experience on shipping successful tooling for the Rust Ethereum ecosystem. In June 2024, we [released Alloy 0.1](https://www.paradigm.xyz/2024/06/alloy-release) as the successor to `ethers-rs` to offer a robust, high-performance Rust toolkit for Ethereum development. Since then, Alloy has grown to become the [backbone across the tooling](https://sourcegraph.com/search?q=context:global+file:Cargo.toml+alloy+-repo:alloy-rs+-repo:foundry-rs+-repo:paradigmxyz&patternType=standard&sm=1&groupBy=repo) and infrastructure spectrum, with projects such as [Reth](https://github.com/paradigmxyz/reth), [Foundry](https://github.com/foundry-rs/foundry), [Revm](https://github.com/bluealloy/revm), and [SP1 zkVM](https://github.com/succinctlabs/sp1) using it as a core dependency. Today, we’re excited to release [Alloy v1.0](https://github.com/alloy-rs/alloy/releases/tag/v1.0.0), our first stable release, reaffirming our commitment to performance, stability, and great developer experience. Alloy is a complete re-write of `ethers-rs` and builds on years of experience on shipping successful tooling for the Rust Ethereum ecosystem. Read on to learn why the best teams in the industry are using alloy. ![https://x.com/gakonst/status/1905661358739521792](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--0b0bc378be/40974af506ec462d050dfb4cdc323697/asset-https-cdn-sanity-io-images-dgybcd83--0b0bc378be.png) *https://x.com/gakonst/status/1905661358739521792* ## Try Alloy v1.0 today `cargo add alloy` Check out our polished [docs](https://alloy.rs/) and the [examples repository](https://github.com/alloy-rs/examples) for inspiration. ### Revamped Docs Writing performant and state of the art code is not enough. Documentation should be equally good. In lieu of this we have completely revamped the [alloy docs](http://alloy.rs) by dropping the mdbook for [vocs](http://vocs.dev). ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--2013bd525d/6d9ef4670dd8e618a81633f56e93b92d/asset-https-cdn-sanity-io-images-dgybcd83--2013bd525d.png) Resources on all things alloy: - [Docs](https://alloy.rs): Get started with alloy and explainer for high level concepts - [Examples](https://github.com/alloy-rs/examples): Extensive examples covering each feature of alloy - [Best Practices](https://alloy.rs/guides/rpc-provider-abstraction/): Highlights the best of alloy and how to use it - [Migration Guide](https://alloy.rs/migrating-to-core-1.0/README): List of breaking changes in 1.0 and how to address them Please open issues for anything we’re missing. ## Stability and Reliability With v1.0, we're committing to a stable and reliable, ready for production use API that you can rely on for long-term projects. Alloy is *the* Rust toolkit for building high-performance applications on Ethereum and other EVM chains. For upcoming protocol upgrades like new EIPs, we’ll continue to ship updates as specs evolve. These will follow semver and may include breaking changes where needed to stay aligned with core protocol changes. This ensures that Alloy always reflects the latest network behavior, without falling behind. ## Why should you use Alloy? - **Intuitive Contract Interaction:** Interacting with smart contracts is easy with Alloy. The `sol!` macro lets you write Solidity in Rust and generate bindings to interact with the contract. - **Blazing fast primitive types**: Alloy offers significant performance improvements over `ethers-rs`, with up to 60% faster U256 arithmetic operations and 10x faster ABI encoding. - **Simplified RPC Provider Usage:** Alloy’s RPC provider makes it easy to connect to any EVM node, broadcast transactions, and build modular, testable abstractions. - **Better UX with Multicall**: Alloy offers first-class Multicall support which lets developers batch multiple calls into a single RPC request and thereby improving performance and delivering a smoother user experience. - **Stability & Reliability:** With our v1.0 release, we mark a milestone towards stable releases for long-term reliability even as the ecosystem evolves. If you are still using `ethers-rs`, migrate today following– our [migration guide](https://alloy.rs/migrating-to-core-1.0/README). ## Intuitive Smart Contract Interaction With Alloy v1.0, interacting with Solidity smart contracts is easier, faster, and safer than ever. At the center of this is the `sol!` macro, a compile-time Solidity parser that generates type-safe Rust bindings from Solidity code or artifacts. This enables seamless contract interaction with strong typing and removes the need for manual ABI handling. We’ve overhauled the `sol!` bindings for better Rust representation and ease of use. This revamp involves improvements targeted to both high-level contract interactions and usage of low-level bindings. Previously, developers often had to use the `._0` notation to access the actual result of a function call, which made simple contract interactions less intuitive. With this update, the need for `._0` has been eliminated. See an example of the improved user experience below. The `sol!` macro supports Solidity syntax directly in Rust, Solidity files, or JSON ABI artifacts. This lets you bring verified contract interfaces into your codebase with one macro call. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--121af3bb96/a47ad8e4b0b112c56f83a1b408fa191a/asset-https-cdn-sanity-io-images-dgybcd83--121af3bb96.png) You can call any function on the contract with native Rust types, and Alloy handles the ABI encoding and decoding internally. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--0974d48b4b/f97b329ccaeeab7fc94a3689fb567845/asset-https-cdn-sanity-io-images-dgybcd83--0974d48b4b.png) Whether you’re deploying contracts or simulating low-level calldata, the sol! macro makes smart contract interaction fast and reliable. ## Blazingly Fast Primitive Types Alloy ships with a set of primitive types including `U256`, `I256`, `Address`, and `Bytes` — that are faster and more ergonomic than their equivalents in ethers-rs. These types are foundational across the stack: they're used for balance math, calldata encoding, transaction simulation, and more. If you're building bots, indexers, or any compute-heavy service, switching to Alloy’s primitives can yield immediate performance wins. ### Faster U256 Arithmetic Alloy’s `U256` is built on top of the `ruint` crate, delivering 35–60% faster arithmetic in common DeFi calculations like AMM math and arbitrage. We benchmarked two core methods from a UniswapV2 arbitrage bot `get_amount_in` and `get_amount_out` to compare both ethers-rs and Alloy types: ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--ecc748f5a3/fa34386b35aa137090b4fcb9a5167133/asset-https-cdn-sanity-io-images-dgybcd83--ecc748f5a3.png) These methods are used in MEV bots to calculate optimal input amounts for arbitrage swaps. If you want to learn more about how to build fast MEV bots with Alloy’s Primitive types, [read our guide.](https://alloy.rs/guides/speed-up-using-u256) ### 10x faster ABI Encoding Alloy generates Rust types that encode Solidity calls directly. This removes the need for runtime JSON ABI parsing and avoids encoding bugs. Static ABI encoding is up to 10x faster in Alloy, while dynamic ABI encoding sees around 10% improvement. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--35dabad59b/9e0d84bfc72c327e1b4718be308d6b56/asset-https-cdn-sanity-io-images-dgybcd83--35dabad59b.png) In cases where ABI information is only available at runtime (e.g. wallet frontends or ABI fetchers), Alloy provides dynamic ABI encoding via DynSolValue. You can read more about dynamic ABI encoding [in our docs](https://alloy.rs/guides/static-dynamic-abi-in-alloy#how-to-use-dynamic-abi-encoding). ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--c2f3351c7c/b8fb7274746864a85d1149a6b5e52f0c/asset-https-cdn-sanity-io-images-dgybcd83--c2f3351c7c.png) ## Simplified RPC Provider Usage Alloy’s RPC provider offers a clean, modular abstraction over Ethereum RPC endpoints with built-in support for HTTP, WebSockets, and IPC, along with advanced patterns like provider layering, transport wrapping, and middleware composition. Our goal is to eliminate boilerplate and let developers connect to the chain in just a few lines of code. At its core is the `ProviderBuilder`, which simplifies connection setup and hides the complexity of underlying transports: ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--3600438a4d/900d71ccdb2083d1ee6c304c62a83528/asset-https-cdn-sanity-io-images-dgybcd83--3600438a4d.png) Alloy makes it easy to build higher-level abstractions by wrapping providers in your own types. This helps isolate logic, reduce repetition, and create intuitive workflows for specific tasks like deployment, data fetching, or transaction simulation. There are two primary ways to wrap a provider, depending on whether you want to preserve type information or prioritize simplicity. ### Using Generics (P: Provider) Use generics when you want static dispatch, full type safety, and optimal runtime performance. This is ideal for library code or scenarios where you want to preserve exact type information. This has been enabled with the [removal of the ](https://github.com/alloy-rs/alloy/pull/1859)[`T: Transport`](https://github.com/alloy-rs/alloy/pull/1859) generic from the provider. These changes have also been propagated to the `sol!` macro bindings making it easier to work with types that wrap the provider. You can now wrap providers without wrestling with complex generic types: ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--c2c01d4c4c/ac5388c032bbe17ecebf80a1ebe81de2/asset-https-cdn-sanity-io-images-dgybcd83--c2c01d4c4c.png) This approach lets you construct tightly-coupled components that are easy to test and optimize, while keeping the interface generic over different transports or layers. ### Using DynProvider (Type Erasure) Use `DynProvider` when you want to simplify types and avoid dealing with generics — especially useful in applications, scripts, or dynamic settings. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--dbb804017b/e42f5d216e3b4697c7e183f8aa565ce2/asset-https-cdn-sanity-io-images-dgybcd83--dbb804017b.png) `DynProvider` erases the concrete type of the provider while preserving full functionality, including layering and middleware. This simplifies signatures and reduces binary size at the cost of a small runtime overhead. Use this when working with heterogeneous providers or when you want faster compile times and cleaner interfaces in high-level code. You can read more about the best practices of wrapping a provider in the [docs](https://alloy.rs/guides/rpc-provider-abstraction/). ## Network Abstraction Alloy’s provider is designed for the multi-chain world by being generic over the `Network` trait. The `Network` trait defines the structures of the network and its RPC types which are used by the provider. By default the `ProviderBuilder` creates a provider for the `Ethereum` network. One can use the `.network()` method to change that. For example, we can use the `Optimism` network type from [op-alloy](https://github.com/alloy-rs/op-alloy) to instantiate a provider for interacting with OP-stack chains such as Base. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--b7d303e46d/7adf0bd2fbbca45b696d168f61a5fd8c/asset-https-cdn-sanity-io-images-dgybcd83--b7d303e46d.png) This enables the provider to deserialize the OP specific types such as the [Deposit](https://github.com/alloy-rs/op-alloy/blob/main/crates/consensus/src/transaction/deposit.rs)[ transaction](https://github.com/alloy-rs/op-alloy/blob/main/crates/consensus/src/transaction/deposit.rs). ## Better UX with Multicall Alloy makes it easy to batch multiple read-only contract calls using **Multicall,** a smart contract and design pattern for aggregating calls into a single RPC request. Multicall aggregates contract reads and writes. This is useful for reducing the number of RPC requests you’re making and execute calls atomically by guaranteeing that the numerous state reads/writes are in the same block. Alloy provides first class support to leverage [Multicall3](https://www.multicall3.com/) in two ways: 1. **Multicall Builder** : manually construct batched calls 2. **Multicall Batching Layer** — passively groups calls made in parallel ### Multicall Builder The `.multicall()` method on the provider gives you full control over which calls are batched together. It works directly with contract bindings generated by the `sol!` macro to provide an intuitive and simple API to batch and execute calls while also handling decoding of the response. A simple multicall looks like: ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--b9abdbc4f7/23c6fc03bb6c714230509ce990d2dcd7/asset-https-cdn-sanity-io-images-dgybcd83--b9abdbc4f7.png) Use this approach when you want to explicitly group related calls, fetch state from multiple contracts, or control call ordering and deduplication. ### Multicall Batch Layer For a more seamless experience, you can enable the `CallBatchLayer` to automatically group `eth_call` requests that are made in parallel. The [`CallBatchLayer`](https://docs.rs/alloy-provider/latest/alloy_provider/layers/struct.CallBatchLayer.html) is a [`ProviderLayer`](https://docs.rs/alloy-provider/latest/alloy_provider/trait.ProviderLayer.html) that spawns a background task aggregating `eth_call` requests made using `provider.call(tx)` . This is extremely useful for reducing the number of RPC requests and automatically enable batching while using the provider as usual. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--41d50e5cef/60fd5ff06129fa699b848e327acf4ec6/asset-https-cdn-sanity-io-images-dgybcd83--41d50e5cef.png) This approach is ideal when you want automatic batching for parallel calls without touching existing logic, especially when your app already uses concurrent tasks. ## Acknowledgements We want to thank the vibrant community of contributors who have helped shape Alloy's development. Thank you to [James Prestwich](https://x.com/_prestwich) for co-developing many of the exciting features in this release, and [Remco Bloemen](https://x.com/recmo) for building [Ruint](https://github.com/recmo/uint). We're grateful to the thousands of developers building with Alloy and pushing the boundaries of what's possible in Ethereum development with Rust. ## Conclusion Alloy 1.0 brings unmatched developer experience to the Rust Ethereum ecosystem. From turbocharged primitives and intuitive contract interfaces to modular provider architecture, this release sets a new standard for blockchain development tooling. Explore the documentation at [alloy.rs](https://alloy.rs) and get started today. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--20ec7914f2/bd71c3f25d94f6d13a474022346ba5e1/asset-https-cdn-sanity-io-images-dgybcd83--20ec7914f2.png) **We’re hiring across all our open source projects, including Reth, Foundry and Alloy. Reach out with your Github and resume to **[georgios@paradigm.xyz](mailto:georgios@paradigm.xyz)**.** ## https://www.paradigm.xyz/writing/multiverse-finance # Multiverse Finance > Addressing capital efficiency in prediction markets by splitting the financial system into parallel universes.
Animation by Dave Whyte
# Introduction Prediction markets let you bet on outcomes, but so much more is possible. This paper introduces Multiverse Finance, which splits the financial system into parallel universes so you can short the market today only if your favorite candidate is going to lose the next election. # Intuition ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--ebb831ba28/32e9fbc7aa23193ca7c1335b007428eb/asset-https-cdn-sanity-io-images-dgybcd83--ebb831ba28.png) Consider a prediction market on whether Jerome Powell will be fired in 2025. If you think he won't be, you can buy a notFiredUSD token for 89 cents which will be worth $1 in 2026 if he isn't fired. But that's a long time to wait, and in the meantime you can't use your notFiredUSD as collateral in most financial systems -- if Powell were suddenly fired, the token's value could drop to 0 faster than the system could liquidate your debt. However, there is no problem when using notFiredUSD as collateral to borrow, say notFiredETH. If Powell is suddenly fired, both your collateral and the asset you borrowed become worthless simultaneously, so there is no liquidation issue. This idea is what makes Multiverse Finance possible. The simplest version of Multiverse Finance could be implemented today on mainnet by allowing conditional tokens for the same outcomes (like firedEth and firedUSD) to be borrowed and lent against each other on an Aave-like protocol. Further expansions are possible, including (liquidity issues aside) complete financial ecosystems with limitless chains of composibility -- you could take your firedUSD, borrow firedETH against it, provide liquidity on firedSwap to earn firedSwap tokens, stake those in firedFarm, and so on. Like prediction markets or futarchies of the type implemented by [MetaDAO](https://metadao.fi/), in addition to allowing participants new opportunities to express financial views or hedge exposure, Multiverse Finance produces useful information about the world as a positive externality. # Mechanism ### Verses A "verse" is a parallel universe where some event we care about has happened or will happen at some point in the future. Mathematically, verses correspond to [events](https://en.wikipedia.org/wiki/Event_(probability_theory) in probability theory, which are sets of outcomes (possible states of the world) with the following structure: - Any verse has a **complement** verse such that the two combine to cover all possible states of the world (e.g., "Powell fired by 2026" and "Powell not fired by 2026") - Verses can be combined through countable **unions** to form new verses (e.g., "Powell fired by 2026 OR recession by 2026" is a verse where one of the two, or both, happen) - The **intersection** of a countable set of verses forms a new verse (e.g., "Powell fired by 2026 AND recession by 2026" is a verse) Today's universe, where the regular financial system exists, corresponds to the event containing the whole sample space. We call a verse a "parent" to another verse if the child verse is a subset of the parent, meaning every outcome in the child verse is also in the parent verse. So, for example, "Powell fired by 2026" and "recession by 2026" are both parents of "Powell fired by 2026 AND recession by 2026." Today's universe is a parent to all verses (although some verses, such as "Powell Fired by May 2025" become empty of possible outcomes as time goes on). We call a set of child verses a **partition** of their parent verse if the child verses are disjoint (non-overlapping) and their union makes up the entire parent verse. For example, "Powell fired by 2026" and "Powell not fired by 2026" form a partition of today's universe. ### Ownership Intuition The high-level intuition when working with verses in Multiverse Finance is that owners can choose to push ownership down to a partition, or pull it up from a partition. In other words, let's say we have a verse $V$ and some partition $P_1,P_2,P_3$ of $V$. If I own 1 unit of a given token $T$ in $V$, I can choose to "push down" my ownership to the partition, meaning I give up my ownership of $T$ in $V$ and instead now own 1 unit of $T$ in each of $P_1,P_2$ and $P_3$. This is equivalent to how you can always take $1 and mint one YES and one NO token for a given prediction market. Conversely, if I own 1 of token $T$ in each of $P_1,P_2$, and $P_3$, I can choose to "pull up" my ownership of $T$ to $V$, losing my ownership of it in each of those partition verses. This is equivalent to how you can take a YES and a NO token for a given prediction market and get back $1. ### Verse Resolution Verses, like prediction markets, rely on some underlying oracle for resolution. This paper is agnostic to which type of oracle you might use. At the time of resolution, any verse that does not contain the observed outcome reported by the oracle immediately disappears, together with all of its state. If we had some partition $P_1,P_2,\\ldots,P_N$ of a parent verse $A$, and a resolution evaporates all but one of them, such that only a single verse $P_i$ remains, $P_i$ now forms a complete partition of $A$ in and of itself, and we can pull up ownership of any given assets from $P_i$ directly to $A$. For example, if I owned 1 USD in the "Powell not fired by 2026" verse and it's now Jan 1, 2026 and Powell has not been fired, the "Powell fired by 2026" verse disappears and "Powell not fired by 2026" partitions the full outcome space by itself, so I can pull my $1 up to the present day universe and withdraw it from the system. In this case, this is identical to normal prediction market resolution. ### Multiverse Maps The ownership behavior described above is somewhat conceptual and could be implemented in many possible ways. We'll provide one example method here: the **multiverse map**. This is a map (a.k.a. dictionary) datatype with two keys: verse ID and owner address. The multiverse map is governed by two rules: one for splitting, and one for combining. We'll describe an **additive**, **non-negative** multiverse map with a single unsigned integer value. - **Splitting**: The user controlling the owner address of a map entry for a given parent verse can subtract some quantity $x$ from the entry's value that leaves the entry non-negative, and then add $x$ to their balance in each of a set of verses that form a partition of the parent verse. - **Combining**: The user controlling the owner address of a given map entry in each of a group of verses can subtract some quantity $x$ from the entry's values in each of those verses that leaves them all nonnegative, and then add $x$ to their balance in some parent verse that that group of verses form a partition of. As mentioned above, if the parent verse is the complete universe, this serves as a way for users to withdraw funds after event resolution. ### Multiverse Aware Applications This primitive could be used to construct, say, a wrapper contract to make standard ERC20 tokens multiverse-ready. Developers can also build more custom multiverse-aware applications using data structures like the multiverse map. A lending protocol like the one discussed above might, for example, specify that only assets from the same verse may be borrowed and lent against one another. Designed properly, these protocols should be readily composable with one another as long as they are in the same verse. Again, the core insight is that developers don't need to worry about a token like notFiredEth disappearing suddenly and breaking a chain of composability, because every token in the verse should disappear simultaneously. # Future Work We're curious what *multiverse native* applications this concept might unlock. If you have ideas, we'd love to hear from you. ***Acknowledgements*** Alpin Yukseloglu, Arjun Balaji, Dan Robinson, David Swain, Frankie, Matt Huang, Storm Slivkoff, Will Price, Jordi Alexander, Fozzy Diablo, Ella Papanek, Matt Liston, Serge Ravitch, Cristian Strat, Czar102, jdougy, Liam Zebedee, Mewny ## https://www.paradigm.xyz/writing/across-prime # Across Prime > Across Prime introduces a new "bonded" model for trustless cross-chain bridging, which can be more gas and capital efficient than current "escrowed" models. ### Introduction This paper introduces Across Prime, a design for a capital efficient trustless fast bridge. Solving interoperability for Ethereum and other blockchains requires “fast” bridging—bridges that can move assets and actions between chains at faster-than-finality speeds. Intent-based bridge designs, like what Across protocol offers today, are the leading design to solve this problem. Fast bridges depend on third party relayers (aka solvers) to fill a user’s “intent” on a destination chain in exchange for a payment on the origin chain. Most such bridges—like Across—use an “escrowed” model where payment is escrowed until the intent is verified as “filled”. This escrowed design introduces capital costs as relayers must wait before being repaid; relayers effectively act as short-term lenders to fill user intents. Across Prime introduces a “bonded” model where the relayer puts down a collateralized bond to secure a particular path from an origin chain to a destination chain. This allows the user to send money directly to the relayer on the origin chain. The bonded model is significantly more capital efficient than the escrowed model while maintaining most of the security and decentralization benefits. ### Mechanism Across Prime is an evolution of the fast bridge design. In a fast bridge, a user has some *intent* about what they want to happen on the destination chain (such as receiving an asset, sending an asset to someone else, or taking an action on some application). The user makes a *payment* on an origin chain to some third-party *relayer* in return for them filling that intent. One key question in designing intent-based bridges is how to solve the problem of fair exchange. What prevents the relayer from taking the user’s payment without filling their intent? #### Trusted The simplest version of an intent-based bridge solves the fair exchange problem using a trusted relayer. This is the version implemented by applications like [Relay](https://docs.relay.link/what-is-relay) today. In the trusted bridge model, the user pays the relayer on the origin chain, and the relayer fulfills the intent on the destination chain. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--cdefdb8802/bee5d027d2c2159b778819e352ee2de1/asset-https-cdn-sanity-io-images-dgybcd83--cdefdb8802.png) If the relayer is honest, this model can be very efficient. However, it does not protect the user against a malicious relayer. Additionally, the need to trust the relayer makes it difficult to have multiple independent relayers, which limits competition and scalability. The trusted model may also be exposed to custodial or regulatory risks. #### Escrowed When there is some way of sending messages from the destination chain to the origin chain (a “settlement oracle”), other designs for fast bridges become possible. One is the “escrowed” model. This is the model used in [Across today](https://docs.across.to/concepts/intents-architecture-in-across), as well as the design contemplated for [crosschain UniswapX](https://app.uniswap.org/whitepaper-uniswapx.pdf). In this design, the user makes their payment not to the relayer, but into escrow on an origin chain smart contract. The relayer fills the intent on the destination chain with their own capital, then uses the oracle to prove fulfillment before user funds are released back to the relayer. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--f91bcfc846/64ac4c20394c3f637763afba8615e28c/asset-https-cdn-sanity-io-images-dgybcd83--f91bcfc846.png) This escrow system is well described by the [ERC-7683 standard](https://www.erc7683.org/) for crosschain intents, where the escrow contract and settlement oracle are abstracted into a “settlement system”. The [Open Intents Framework](https://www.openintents.xyz/) builds on this standard with reference implementations for ERC-7683 compatible relayers and modularized settlement systems. If the oracle is slow or expensive, there is a simple “optimistic” variation of this design, where the relayer puts down a deposit, and the intent is assumed to be fulfilled unless someone challenges the fill within a certain challenge period. In all versions of the escrowed model, the payment on the origin chain is stuck in escrow until intent fulfillment is verified, creating a capital cost for relayers. Depending on the oracle and the security assumptions of the challenge period, this may be as long as a few hours. The bonded model is a way to reduce or eliminate this capital inefficiency. #### Bonded Across Prime introduces a different kind of trustless fast bridge: “bonded” bridging. In this model, the relayer receives the payment on the origin chain immediately. The user’s safety is guaranteed by a security deposit provided by the relayer, with the bond determining the maximum amount that the relayer can have “in flight” at any given time. If the relayer fails to complete any of the actions they were paid for, the user can claim a refund from that security deposit. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--6ed854d333/b8a09ba67aa315c1aa278d0a3b9937b2/asset-https-cdn-sanity-io-images-dgybcd83--6ed854d333.png) This is much more capital efficient than the escrowed model, particularly if the settlement oracle is slow. For example, suppose a relayer has a bond of $1,000, the origin and destination chains each produce one block every two seconds, and the settlement oracle takes one hour to finalize: Using the bonded model, users can make up to $1,000 in payments every four seconds. (As discussed below, users need to wait two blocks between payments in order to confirm that the relayer completes the desired action from the previous payment on the destination chain.) This results in a total hourly bandwidth of up to $900,000. In the escrowed model, each payment would need to be locked up for an hour to wait for the settlement oracle to finalize, so making $900,000 in payments would require locking up a total of $900,000 in capital for one hour—making it up to 900 times less capital efficient than the bonded model (given the assumptions of this example). The bonded model is more capital efficient since bonds are “reusable” as soon as the intent is completed on the destination chain, even if the settlement oracle takes much longer to finalize. This quality makes it practical to use much slower (and more secure or more decentralized) settlement oracles—such as the one-week canonical bridge to exit from an optimistic L2—since the capital cost is no longer proportional to the latency of the settlement oracle. At first glance, the bonded design appears to present an unfortunate tradeoff: the relayer will only be able to support large payments if they keep a large bond locked up at all times. This suggests the design could be incompatible with a market structure where users occasionally need to send large transfers that overwhelm the relayer’s bond requirements. But we can tweak the bonded model to fix this—in the case where the bond is insufficient to cover the user’s desired payment, we can immediately add the user’s funds directly to the relayer’s bond, increasing the bond size “just-in-time”. This tweak essentially allows the bonded model to “fall back” to the escrowed design when the bond is not large enough, but with an added bonus: the escrow “bond” can immediately be reused to secure payments of other users. ### Protocol Here is a simple version of a bonded protocol for bridging ETH across chains (though it could easily be generalized to fulfilling arbitrary intents). It includes some important logic to handle edge cases, including “contention” (the risk that multiple users will attempt to send payments to a relayer at the same time, causing the total amount in flight to exceed the security deposit). As the first step, suppose Bob wants to become a relayer for a particular route, where a route is defined as the path from a specific origin chain to a specific destination chain. Bob puts down some amount of ETH, **securityDeposit**, on the origin chain (say, Arbitrum), and specifies which destination chain they will support (say, Base). The origin chain has a “turnstile contract,” which tracks a value, **cumulativePayments**, for the cumulative amount of payments made to Bob for that route, as well as a Merkle root of all intents filled through it (where each new root is **keccak256(oldRoot, order)**). Every time a payment is made to Bob for that route, the **cumulativePayments **value is incremented, the Merkle root is updated, and a **payment** event is emitted with the new Merkle root and new value for **cumulativePayments**. The destination chain has a “fulfillment contract,” which also tracks the intents filled through the route. It has a Merkle root that corresponds to the one on the origin chain, so that when all intents on that route have been fulfilled, the Merkle roots match. A user, Alice, wants to send ETH from Arbitrum to Base. She consults a list or API for relayers that support that path, and picks Bob. She checks Bob’s Merkle root on the destination chain, and looks at recent **payment** events on the origin chain until she finds a matching root, noting the **cumulativePayments** value from that event as **confirmedCumulativePayments**. She confirms that Bob’s relayer bond is large enough to refund the payments on all currently unfulfilled intents, plus her own. She signs an ERC-7683 GaslessCrossChainOrder, with the following information in the **orderData** field: - **payment**: the amount of ETH Alice is willing to pay to Bob (the relayer) on Arbitrum - **confirmedCumulativePayments**: The value that Alice computed for the total cumulative payments that have been fulfilled. As discussed below, this number helps the turnstile contract enforce that Bob’s security deposit will be sufficient to reimburse Alice. - **destinationAmount, destinationAddress**: the amount of ETH that Alice wants to receive on the destination chain, and the address she wants to receive it at. This could easily be replaced with arbitrary intents, as long as it can be enforced by the fulfillment contract. Alice gives this intent to Bob (the relayer), who submits it to the turnstile contract on the origin chain. The turnstile contract checks that the intent is being submitted by Bob, and that **securityDeposit** is greater than **cumulativePayments + payment -** **confirmedCumulativePayments**. It then adds the **payment** amount to **cumulativePayments**, hashes the order into the Merkle chain, and transfers **payment** directly from Alice to Bob. Bob can also specify that he wants to deposit some of the payment into his bond, instead of receiving it immediately. This could be helpful if Bob does not currently have enough in his bond to cover Alice’s payment. The turnstile contract fires an event that includes the hash of the order, the new **cumulativePayments**, the destination chain ID, and the new Merkle root. Bob now fills the user on the destination chain, passing their order through the fulfillment contract. The fulfillment contract verifies that the order has been fulfilled, hashes it, and adds it to the Merkle chain. It also fires an event noting the new Merkle root. If Bob did not fill some intent, then after a challenge period, anyone could challenge Bob on the origin chain. Pending challenges prevent Bob from withdrawing his bond until he has proven that the order was fulfilled on the destination chain (by using the slow message bridge to prove that the Merkle roots match). If there are multiple pending challenges, whichever order was included first in the Merkle chain takes precedence. ### Extensions #### Arbitrary Bond Collateral In the example given above, the payment currency is the same as the bond currency. It would be inefficient for each relayer to bond in each currency. The model can be extended to support arbitrary bond collateral provided that the user (Alice) signs off on a minimum exchange rate she’ll accept for the duration of her order. Alice’s **payment** amount (which locks up Bob’s bond) will then be “padded” with her conservative exchange rate, protecting Alice from changes in the relative value of her payment currency versus Bob’s bond currency during her order. Since Alice’s order should get filled very quickly (in seconds), the actual padding required can be quite modest while still fully protecting Alice. #### Multiple Destinations In the simplified version of the bonded model described above, there is a security bond required by each relayer for each route. In the example above, Bob (the relayer) deposited a bond on Arbitrum specifically allocated to the Arbitrum→Base route. If Bob needs to deposit a bond for each and every route, the bonds required would reduce the capital efficiency of the system. To mitigate this, each origin chain bond could be used to cover many destination chains. This puts some additional burden on the user, who now must check each destination chain in the set to verify which unfilled intents are outstanding. The user must also trust the sequencers or pre-confirmations for each destination chain. If the user prefers isolated trust assumptions, they could require the relayer to have separate bonds dedicated to each path. ### Discussion #### Gas Efficiency As discussed above, the bonded model can be dramatically more capital efficient than the escrowed model. It can also offer a meaningful improvement in gas efficiency, since in the happy case, it only requires two transactions (one on the origin chain and one on the destination chain), while the escrowed model requires a third transaction on the origin chain for settlement. #### ERC-7683 Compatibility Across and Uniswap have proposed [ERC-7683](https://www.erc7683.org/), a broadly supported standard for crosschain intents. This standard was authored with the escrowed intent model in mind, however it is generally compatible with Across Prime’s bonded design. Following the ERC-7683 spec, **originSettler** can be set to Across Prime’s turnstile contract, and **destinationSettler** is simply the Across Prime fulfillment contract on the destination chain. The **orderData** and event structures proposed by the standard remain unchanged. #### Mint-and-Burn Bridge Compatibility In the bonded model relayers receive the user’s payment on the origin chain before they must fill the user on the destination chain. This means that if the payment currency is a mint-and-burn token (like Circle’s USDC, Hyperlane’s Warp Tokens, LayerZero’s OFTs, Wormhole’s NTTs, etc), the relayer does not need to have any inventory on the destination chain to support the flow, albeit with slower fills times. In these situations, the user could trade modestly slower fill times in exchange for cheaper fills. One example flow: (i) user publishes their intent with a longer fill time (e.g. 3 minutes) and sends mint-and-burn tokens to relayer; (ii) relayer uses the mint-and-burn bridge to move these tokens to the destination chain; (iii) after the mint-and-burn bridge completes, relayer fills user. In this structure, Across Prime functions as a superset of all available bridging methods: if an instant fill is available (because the relayer holds inventory on the destination chain), the user will receive an instant fill; if inventory is not available, the user will receive a fill at the approximate speed and cost of the underlying mint-and-burn bridge. ### Prior work There has been much prior work on intent-based crosschain protocols, including many escrow-based designs, as well as some architectures that bear a closer resemblance to Across Prime’s bonded model. #### Across [Across](https://docs.across.to/) originated the escrowed intent design, combining it with optimizations for “batch settlement”. In Across, users deposit funds into escrow on the origin chain before relayers race to fill the user on the destination chain. Every period (approximately 1 hour), all completed fills are summarized into a Merklized bundle that “batch repays” each relayer for all refunds owed on each chain. This bundle is optimistically verified on Ethereum mainnet before funds are released. This design intelligently minimizes gas costs via batch repayments, but requires relayer capital to be locked for ~1hr, creating significant capital costs. #### Orbiter Protocol [Orbiter’s](https://docs.orbiter.finance/welcome/bridge-protocol) design goals share some qualities that resemble Across Prime. Like Across Prime, Orbiter requires relayers (called makers) to post a bond before asking users to send funds directly to the relayer (aka maker). This bond must be larger than the funds being sent to the relayer. Orbiter’s design, however, doesn’t handle contention; the protocol cannot prevent two or more users from mistakenly sending a relayer more funds than the bond can cover. Across Prime prevents contention and enforces proper margining via the turnstile contract. #### UniswapX (Crosschain) Crosschain [UniswapX](https://app.uniswap.org/whitepaper-uniswapx.pdf) is not yet implemented. It follows a similar design to Across without batch settlement. For each bridge transaction, user funds are escrowed on the origin chain; relayers then fill users on the destination chain. Funds are only released from escrow after an optimistic challenge period has passed. Across Prime bypasses the costs associated with the individual escrow and verification of each bridge transaction. #### Relay Protocol Relay protocol is currently implemented as a centralized, trusted relayer. Relay has [shared designs](https://docs.relay.link/how-it-works/relay-protocol) to decentralize their implementation with a separate “settlement chain” where relayers must escrow funds before receiving deposits directly from users. This settlement chain requires individual escrow and settlement of each transaction before the relayer receives their escrowed funds. Across Prime saves on uncertainty, gas costs, complexity by sidestepping the entire need for per-transaction escrow or settlement. Users simply have to verify that a relayer is properly bonded. ### Further Work Current fast bridges often rely on escrow models, which hinder capital efficiency by locking relayer funds during settlement delays. This paper introduced Across Prime, a fast bridge design employing a "bonded" model. This bond can be reused almost immediately, decoupling capital velocity from settlement latency and vastly improving both gas and capital efficiency. If you are interested in developing Across Prime, or working on related intent based bridge designs, reach out to this paper’s authors or the Across team. ## https://www.paradigm.xyz/writing/timing-advantages-in-onchain-auctions # Timing Advantages in Onchain Auctions > This paper studies and quantifies one of the fundamental limits to reducing MEV: latency advantages. Onchain auctions would be a huge unlock for many decentralized applications—NFT launches, liquidation engines, DEX routers, even wallets. If they were possible, then applications or users could use them to capture most of the maximal extractable value (MEV) they create. But in a decentralized protocol, such auctions are very difficult to implement. As [previous research](https://www.paradigm.xyz/2024/06/priority-is-all-you-need) has discussed, the ability of block proposers to reorder, censor, or peek at transactions gives them unique power to capture MEV from onchain auctions. While there are many proposed technical solutions to reduce the block proposer’s ability to extract this value, there is one advantage that is particularly difficult to eliminate: **latency**. Because timing delays can arise naturally in a decentralized setting, one party may be able to submit or cancel transactions later than anyone else. Previous work has shown that if a block proposer can [censor](https://arxiv.org/abs/2301.13321) or [peek at](https://arxiv.org/abs/2311.09083) transactions, they can capture up to 100% of the value of a single-block auction. Is the same true of a block proposer who only has a timing advantage? In our [new paper](https://arxiv.org/abs/2504.02077), we find that while such a block proposer can extract some value from the auction, these auctions do not degenerate in the same way—they can still be competitive enough to capture some value for the seller. We quantify the profit that a proposer can extract from their timing advantage. We also derive the “timing pressure” on this auction (akin to the incentive for a block proposer to delay their block using [timing games](https://arxiv.org/abs/2305.09032)). This paper preserves some hope that despite the inevitability of timing advantages, competitive decentralized auctions are still possible and can preserve some value for users. It also motivates work (like [multiple concurrent proposers](https://arxiv.org/abs/2301.13321), [FOCIL](https://ethresear.ch/t/fork-choice-enforced-inclusion-lists-focil-a-simple-committee-based-inclusion-list-proposal/19870), and [threshold encryption](https://www.paradigm.xyz/2024/10/removing-the-relays)) that could add censorship-resistance and privacy to decentralized auctions, as well as work (like [leaderless auctions](https://www.paradigm.xyz/2024/02/leaderless-auctions)) that tries to reduce timing advantages as much as possible. ### Details To see how our results work in a little more detail, consider two bidders, Alice and Bob, bidding to fill a UniswapX order. The price of the tokens (and therefore the value of filling the order) evolves in real time. One bidder (Alice) submits a bid early. The other bidder (Bob) moves later and has more up-to-date information (but cannot see Alice’s bid). We show that Bob’s advantage translates into a **strictly positive expected profit**, even though he doesn’t know Alice’s bid. Alice, despite bidding strategically, earns zero profit in expectation. Importantly, the auction doesn’t completely collapse—value still accrues to the seller—but Bob is able to extract a significant surplus due to his timing edge. How much? Well, let's consider two cases. If the UniswapX order has no reserve price, there’s a straightforward **option-theoretic interpretation**. Bob’s profit, in expectation, looks exactly like the payoff from a financial derivative: specifically, an *exchange option* that lets you trade one asset for another. If instead the order does have a reserve, the answer is slightly richer—Bob’s payoff becomes a portfolio of exotic options (which include range options and binary calls). This lens allows us to apply tools from financial mathematics—particularly the Black-Scholes model—to quantify how Bob’s edge depends on the volatility of the underlying asset and his latency advantage. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--f71f6037b6/bf88b332d35ed0b8ebd574956ee4efd5/asset-https-cdn-sanity-io-images-dgybcd83--f71f6037b6.png) As we described earlier, a particular interest in our paper is to understand this in the context of Multiple Concurrent Proposer (MPC) style blockchain constructions, and how these mitigate/ exacerbate timing pressure relative to current single leader blockchains. To this end, we compare with the case that Bob is a monopolist. When the reserve is **zero**, Bob’s expected profit in the competitive setting equals the value of an **exchange option**—he wins when his observed value exceeds the maximum of a random draw (Alice's bid proxy). In contrast, a monopolist Bob—who faces no competition—effectively always wins and earns the entire value of the item, making his profit constant and **independent of timing**. Thus, in the zero reserve case, only the competitive setting creates **timing pressure**, which in option-greek terms is the “theta” of the exchange option. However, when the reserve price is **positive**, the story changes. Now, even the monopolist's profit depends on timing: he only profits if the realized value exceeds the reserve, so waiting longer increases profitability. In this case, **both** competitive and monopolist Bob benefit from delay, but the competitive Bob still faces stronger timing incentives. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--6a28c3834a/bb9dcda86d090c3fba1ca44303e8a9ad/asset-https-cdn-sanity-io-images-dgybcd83--6a28c3834a.png) Read the full paper [here](https://arxiv.org/abs/2504.02077). ## https://www.paradigm.xyz/writing/joining-paradigm-alpin-yukseloglu # Joining Paradigm > Alpin Yukseloglu joins Paradigm as an Investment and Research Partner. I’m thrilled to announce that I’m joining Paradigm as an Investment and Research Partner to help Matt, Alana, and the rest of the team build the best crypto-native investment firm. Paradigm has been an important part of my life for the past several years. Paradigm was the lead investor in the first company I worked at (Osmosis), introduced me to many close friends through the first Paradigm Fellowship, and has inspired me in ways the team probably still doesn’t fully realize. When I decided I wanted to leave Osmosis to focus on the intersection of research, building, and investing, there was no other place I would have rather gone. I spend a lot of my time thinking about protocol design, with a recent focus on protocols that take strong tradeoffs to improve on a core product or maximize performance. My work at Osmosis consisted in large part of pushing this technical frontier, with the core focus of weaving many different parts of the stack into consensus logic in service of user needs. I believe that the boundaries of this tradeoff space are going to become increasingly important for the future of crypto, and I’d love to meet anyone working on pushing them. For example, what can you unlock if you take weak subjectivity to the limit? On the investment side, I like to partner with founders who have strong instincts about the future and the courage to follow them. If you’re a builder or researcher, please reach out! Whether you want to jam on {protocol, market, mechanism} design or talk about a project you're working on, my [DMs](https://x.com/0xalpo) and inbox (alpin@paradigm.xyz) are always open. ## https://www.paradigm.xyz/writing/southern-district-stand-down-prosecuting-code-is-not-justice # Southern District, Stand Down: Prosecuting Code Is Not Justice > Until the Storm case is dropped, all of crypto and every software developer are at risk. Roman Storm is facing up to forty-five years in federal prison. His offense? Writing open-source code. Storm helped build Tornado Cash, a tool that lets users engage in private transactions on the Ethereum blockchain. There are many reasons a user may need privacy when they send money to another party: avoiding publicity, reducing risk of a hack, making a contribution to a politically unpopular cause, or ensuring safety for human rights activists or journalists. Storm himself is a political refugee; after protesting the Russian invasion of Georgia in 2008, he was [persecuted by the Russian Federal Security Service](https://storage.courtlistener.com/recap/gov.uscourts.nysd.604937/gov.uscourts.nysd.604937.30.0.pdf#page=13) before fleeing to the United States and becoming a citizen. But it turns out his trouble with the government was only just beginning. The Tornado Cash tool is not administered by any central authority. Roman Storm has no control over the code or the assets running through it. Yet prosecutors in the Southern District of New York claim that merely developing this tool to allow others to engage in peer-to-peer transactions amounts to a criminal conspiracy to operate an “unlicensed money transmitting business.” That’s like attempting to criminalize building Fords because someone *might *drive a Mustang in a bank robbery. The government’s case doesn’t just stretch the law, it breaks it. The criminal law at issue, 18 USC § 1960, was enacted over thirty years ago to regulate financial institutions that actually transmit money by receiving funds from one party and passing them along to another. But Tornado Cash and its developers are not financial institutions: unlike a bank, *they don’t ever receive funds or control a third party’s transaction at all*. To the contrary, Tornado Cash is autonomous code that allows transactions directly from one party to another without any intermediaries. For years, the Treasury Department has recognized that developers who publish software are not money transmitters. In 2014, the Obama Treasury Department [explained](https://www.fincen.gov/sites/default/files/shared/FIN-2014-R002.pdf) that “the production and distribution of software, in and of itself, does not constitute acceptance and transmission of value.” In 2019, Treasury further [explained](https://www.fincen.gov/sites/default/files/2019-05/FinCEN%20Guidance%20CVC%20FINAL%20508.pdf) that “total independent control” over users’ crypto was a key factor in determining whether an intermediary is a money transmitter under the Bank Secrecy Act. Providers of noncustodial “mixers” like Tornado Cash are not money transmitters if they are simply “suppliers of software” that do not “accept… and retransmit” crypto. Courts, too, typically assumed “control” over transmitted assets as a practical threshold. In every federal Section 1960 case until this one, that element was present. But not here. As Senators Wyden (D-OR) and Lummis (R-WY) argued in a bipartisan condemnation [letter last year](https://www.lummis.senate.gov/wp-content/uploads/Lummis-Wyden-Letter-on-Non-Custodial-Crypto-Asset-Software.pdf), “It is very concerning that DOJ would adopt an interpretation of this registration requirement that is contrary to another Federal agency. This makes it difficult for ordinary Americans to determine what their legal obligations are.” What caused the government’s monumental shift? In 2021, the Biden Administration commenced its Elizabeth Warren-directed “war on crypto,” with every tentacle of government employing its own powers to strangle a nascent industry. The SDNY’s actions should be viewed as part of this larger strategy, including SEC Chair Gary Gensler’s unfounded enforcement actions (since walked back by the new SEC), the OCC/FDIC orchestration of Project Chokepoint 2.0 (since walked back by new Trump appointees), the nonsensical IRS DeFi broker rule (since overturned by Congress and President Trump), and even the sanctioning of Tornado Cash itself (since rejected by the Fifth Circuit and reversed by the Trump Treasury Department). Doing its part to enforce the government’s anti-crypto strategy, but faced with a stack of unfavorable case law, SDNY prosecutors pivoted: if Storm didn’t violate the statute himself, maybe they could still nab him for conspiring to violate it. And here’s where it gets fully Orwellian: In court, the SDNY prosecutors repeatedly argued that their charges against Storm required mere “general intent” to facilitate criminal transactions by people using Tornado Cash, without showing Storm specifically intended to facilitate or cooperate with any particular crime or criminal. But in December 2024, the Biden DOJ [quietly asked Congress in a letter](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-a968fc56cb/2caa5b0a31337c28ef7a8c0d4c93754c/asset-https-cdn-sanity-io-files-dgybcd83-p-a968fc56cb.pdf) to “clarify” the statute to support the interpretation they argued was clear. Unlike similar letters of such weighty effect, the DOJ did not upload this one to [its website](https://www.justice.gov/ola/resources#correspondence), leaving crypto advocates to stumble upon it in the cobwebs of the Congressional Record several months later. Needless to say, if the law had already imposed this rule, clarification wouldn’t be needed. But the SDNY wanted to convict Storm under a new interpretation of the law while lobbying Congress to retroactively amend the law to validate that approach. This is not justice; it’s a bait and switch. The irrationality of the prosecution became even more pronounced earlier this month, when the Department of Justice issued a [sweeping policy memo](https://www.justice.gov/dag/media/1395781/dl?inline) repudiating the very kind of regulatory overreach Storm is being subjected to. The memo ended the Biden DOJ’s campaign of “regulatory weaponization” against digital assets, shut down the National Cryptocurrency Enforcement Team, and directed DOJ prosecutors to stop “superimposing regulatory frameworks” on the space. Crucially, the memo bars prosecutions under Section 1960’s registration prong (one of the central charges being used against Storm) unless prosecutors can show a knowing, willful violation of the registration requirement. The memo couldn’t be clearer: “The Department of Justice is not a digital assets regulator.” And yet, the Southern District of New York didn’t get the message. As of this writing, the case against Roman Storm still has not been dropped. ***Until it is, all of crypto and every software developer are at risk.*** Storm is not a banker, a broker, or a criminal mastermind. He’s a software developer. Charging him with running a money-laundering enterprise is as absurd as arresting Tim Cook, the CEO of Apple, for one of the likely thousands of crimes committed each day on iPhones. Criminal law demands more than clever theories; it requires fair notice, due process, and actual culpability. Prosecutors are not permitted to peer at a previously-clear federal law and conjure an indictment from between the lines. In the physical world, questions of liability such as these have been resolved for centuries. As the DeFi Education Fund wrote in its [excellent amicus brief](https://www.defieducationfund.org/_files/ugd/84ba66_063f9d1fd563466cadfa3f5434f918e9.pdf) filed in Storm’s case, “In general, automobile manufacturers are not liable for drivers who use their vehicles as weapons; construction companies are not liable for businesses that use their office buildings to perpetrate fraud.” Otherwise, inventors wouldn’t dare invent, and manufacturers wouldn’t dare sell their goods if they could be responsible for every crime committed by people using them. The same concept applies to crypto, open source, and AI, all critical drivers of human flourishing. These technologies would never reach their potential if our legal system established boundless liability for third-party use and abuse. Storm’s prosecution is not an isolated edge case – it’s not even a case “just” about crypto. By pressing their unfounded theories, the SDNY could unwind America’s role as a global technological powerhouse. To be clear: we support the president’s laudable goal of eliminating Transnational Criminal Organizations. ***Actual*** money laundering, especially in support of organized crime and terrorism, should be investigated and prosecuted to the fullest extent of the law. But the government has many effective, legitimate tools at its disposal; inventing new definitions of “money transmission” is not one of them. The White House has declared the War on Crypto over, and the DOJ agrees. But that message hasn’t yet reached the Southern District of New York. Like the last soldier on a forgotten island, this independent outpost of the DOJ continues fighting a war everyone else has abandoned. It’s time for them to stand down. ## https://www.paradigm.xyz/writing/the-key-neutrality-of-baselayer-markets # The Key Neutrality of Baselayer Markets > Paradigm responds to the SEC Crypto Task Force’s questions regarding MEV. PDF Version [here](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-ac605ea81b/24844c974091580a1b1779e26fa1cb99/asset-https-cdn-sanity-io-files-dgybcd83-p-ac605ea81b.pdf) # Summary SEC Commissioner Hester Peirce recently released 48 questions on which the SEC Crypto Task Force has sought clarity. Paradigm seeks to provide helpful context on MEV – a native, economically rational feature of Ethereum’s decentralized architecture that supports efficient blockspace allocation and market stability. While certain mechanics of MEV can create negative externalities, we seek to demonstrate that the market is already addressing these challenges through technical innovation. We also examine why MEV activity on its own does not satisfy the legal elements of securities fraud, insider trading, or best execution violations under U.S. law. Paradigm argues that any regulatory intervention would risk disrupting a still-maturing but self-correcting market structure, and we encourage the Commission to take a tech-neutral, flexible approach that preserves decentralization and fosters innovation. # I. Introduction We thank Commissioner Peirce and the Crypto Task Force for posing important questions regarding how the Commission and its registrants should think about MEV and any potential regulatory response. [^1] In this paper we will first provide background on MEV, describe its rapid and continuing evolution, and disambiguate between the different types of MEV that currently exist. We will then show how the development of MEV infrastructure generally has had a net positive impact on crypto markets and its participants. While certain types of MEV in their current implementation can create negative externalities, we argue that ongoing technological development will address these externalities and ultimately achieve the Commission’s policy goals better than regulatory impositions could. Therefore, the Commission should defer to this continued technological development and avoid relying on overly-prescriptive guidance or rulemakings that would stymie such development or undermine its benefits. In the second part of this paper, we will address certain criticisms that have been levied against current forms of MEV, including claims that it amounts to market manipulation, insider trading, or that MEV is inconsistent with the principles of best execution. We will show that, even if MEV were to take place in transactions subject to the securities laws, it would not meet the legal stands of market manipulation or insider trading. In fact, MEV can be consistent with the principles of best execution. While MEV is a phenomenon across all of crypto, Ethereum has one of the most-studied and developed MEV ecosystems, so we will focus this paper on Ethereum as a case study for understanding MEV and its relevant regulatory considerations. # II. What is “MEV”? ## A. Origin and Evolution of the Term “MEV” The concept of “MEV” was first identified in the context of Ethereum’s proof-of-work (PoW) network as “Miner Extractable Value.” Researchers in 2019 coined this term to describe the profit that a miner could make by optimally ordering, including, or censoring transactions in a block [^2]. In essence, miners could capture extra value (beyond the standard block reward and fees) by including certain trades in a profitable sequence, or excluding and inserting transactions to capitalize on price discrepancies. Following Ethereum’s transition from proof-of-work to proof-of-stake (PoS) in the 2022 “Merge,” the terminology shifted to “Maximal Extractable Value.” [^3] The acronym remains MEV, but now emphasizes that the MEV phenomenon extends beyond miners to other “base layer” actors (be it a miner, validator, or sequencer on layer-2 chains). ## B. Ethereum’s PoS Block Production Supply Chain Ethereum’s block production supply chain has evolved and matured over many years, now involving separation among different specialized actors: - **Searchers:** Independent, specialized actors who scan the blockchain as well as transaction pools or “waiting rooms” called “mempools” for MEV opportunities. Searchers typically run bots that look for arbitrage opportunities, liquidations, and other profit scenarios. When they detect an opportunity, they formulate a sequence of transactions (sometimes including user transactions plus their own transactions) to capitalize on it. This sequence is packaged as a “bundle” and submitted to block builders, with a fee (or “tip”) attached to incentivize inclusion. [^4] Searchers typically do *not* produce blocks or have protocol-level authority; rather, they compete to influence ordering by offering profit to those who do have that authority. - **Block Builders:** Entities in the post-Merge Ethereum that specialize in constructing entire blocks. Instead of validators individually picking transactions, most validators outsource this task to builders. Builders aggregate transactions from the public mempool and bundles from private searchers to assemble an optimal block – i.e. the block that yields the highest fees or MEV profit. They take into account gas fees and any extra tip from searcher bundles, creating a proposed block that maximizes payoff. Builders then bid this block to the validator (proposer) by offering a portion of the profit (e.g. a direct payment to the validator). In practice, multiple builders compete for each block, each submitting an execution payload and a bid (in ETH) to the proposer. This competition is essentially an auction for the right to build the block. - **Block Proposers (Validators):** In PoS Ethereum, validators take turns proposing blocks (each 12-second slot has a randomly chosen proposer). Under the “proposer-builder separation” (“PBS”) model, a proposer no longer needs to determine the block’s contents; instead the proposer’s role is to choose the best block from builders. “Best” typically means the block that pays the highest fee to the proposer (while still being valid). The proposer receives bids (via a relay system) from various builders and will almost always select the block containing the most value (since that maximizes the proposer’s own reward and increases the resilience of the network). The proposer then signs this block and it gets finalized in the blockchain. The division of labor in PBS emerged as a solution to earlier problems where validators had to choose between establishing sophisticated operations or lower block rewards. This choice placed the neutrality of validators, the centralization of stake, and the barrier to entry to home stakers at odds, causing harm to the economic security of the network. Now searchers compete to find MEV, builders compete to package MEV into blocks, and validators select the highest-paying result. This separation *democratizes* access to MEV revenue and streamlines block production. Even though PBS was not “enshrined” in the first version of the Merge, it is implemented in practice through off-chain coordination (e.g. the MEV-Boost system). [^5] [^6] In the MEV-Boost pipeline (the de-facto PBS mechanism since the Merge), the steps are as follows: ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--432014c656/038c3a522b876b27f06acc01f8ce8792/asset-https-cdn-sanity-io-images-dgybcd83--432014c656.png) 1. **Bundles & Transactions:** Users and searchers submit transactions. This can happen through the public mempool or through private channels. Searchers often send their bundled transactions directly to builders rather than exposing them publicly. 2. **Block Assembly:** Competing block builders take the available transactions and bundles to construct a candidate block (an execution payload) optimizing for profit. The builder will set its own address as the coinbase (to collect block rewards, priority fees, and MEV profits) and typically include a special transaction paying the proposer’s fee (the bid for that block) at the end of the block. 3. **Block Auction via Relays:** The builders transmit a block header (without revealing the full contents) and bid to the network of relays (e.g. Flashbots relay) which facilitate the auction. The relays check that the bids are real (e.g. the offered payment to the proposer is as stated) and forward these block proposals to the validator’s MEV-Boost software. MEV-Boost then selects the most valuable block header (the one with the highest proposer payment) and passes it to the validator. 4. **Proposal and Sealing:** The validator (proposer) signs the chosen block header, effectively sealing that block for the given slot. The signed block is returned to the relay, which then releases the full block (with all transactions) to the network. At this point, the block is official on the blockchain, and the proposer collects the bid, while the builder and any included searchers collect the remaining MEV profits. This whole process takes place within a fraction of a second before each block is published on the Ethereum blockchain. It’s a parallel, low-latency auction for blockspace that repeats every block. To an outside observer, Ethereum blocks just appear one after another with sets of transactions. But within each 12-second slot there is intense competition among block builders. Builders simulate potential blocks using sophisticated algorithms to identify the most profitable block sequence. These simulations are sent to relays and the simulations continue up to and through the close of the auction, ensuring that all potential transactions and bundles submitted within a block time are considered for inclusion. From the validator’s perspective, these bids arrive nearly simultaneously, and the validator picks the highest bid in the real-time auction. The short interval before block inclusion is a battleground of speed and strategy – but it’s an *open battleground*. Anyone with the technical savvy can participate as a searcher. The outcome (the block order) is ultimately constrained by who bid the most or found the most efficient combo of transactions. This system is beneficial for the whole ecosystem since it leads to the most efficient allocation of blockspace. ## C. Transaction Ordering: Auctions vs First-Come-First-Served A crucial difference between transaction ordering in Ethereum as compared to the traditional financial markets with which the Commission is more familiar is how the priority of transactions is determined. In traditional financial markets (like stock exchanges), orders are usually executed in the exact sequence they are received (“first-in-time” priority), or by strict price-time priority rules. An equity trade cannot usually cut in front of a prior trade unless, perhaps, it offers a better price – and even then, certain fairness rules apply. In distributed systems, such as the Ethereum network, each node in the network maintains its own list of pending transactions (each node maintains its own mempool, there is not one canonical mempool). Therefore it is technically infeasible to establish a first-in-time priority on Ethereum. If Alice and Bob send transactions to the Ethereum network separated by one second, nodes in different parts of the world will log those transactions at different times depending on their geographic and latency relationship to Alice and Bob’s locations. Establishing a first-in-time ordering policy for Ethereum would break the inherent value of using a distributed system. A first-in-time ordering policy would necessitate a single canonical node to establish time-based ordering. This would lead to all systems in Ethereum co-locating infrastructure to that node, breaking the decentralization of the network and creating a single centralized infrastructure network. [^7] Block builders are therefore not reordering transactions. In fact, the protocol *incentivizes* miners/validators to pick the highest-fee transactions first (that’s how users compete for inclusion). By outsourcing the block production role to block builders, the validator network is made more resilient and the validator set more decentralized. As the Bank for International Settlements noted, in traditional markets orders are sequenced by time by a central intermediary, but in a blockchain, block production is a competitive process – who gets to make the block is random or stake-based, and that winner can include transactions in whatever order yields the best reward. [^8] This, a functional market for block building, is what allows for block ordering without any central authority. Crucially, nothing in this process violates the protocol’s rules or consensus. All transactions still have to be valid and pay the required fees; no one is stealing funds or forging transactions. MEV extraction is permissionless – a form of competition enabled by the network’s transparency and the fact that multiple transactions are in flight at once. One might say *MEV is a side-effect of Ethereum’s decentralization*: no single clock or gatekeeper orders transactions, so economic incentives fill that gap. This is why MEV does not inherently amount to an exploit or manipulation, but rather a form of latency arbitrage native to blockchains. ## D. MEV’s Role in Efficient Blockspace Allocation and Mitigating Congestion and Fee Volatility One way to view MEV is as a mechanism for price discovery and allocation of scarce blockspace. Each Ethereum block has limited space for transactions. When demand is high and each slot in a block is contested, there must be a way to decide who gets in and who waits. Prior to the current MEV-auction infrastructure, users spammed (i.e. submitted a massive number of transactions in a short timeframe) high-fee transactions to the public mempool. That led to inefficient outcomes – massive congestion, lots of failed or canceled transactions, and volatile gas prices. [^9] For instance, during the “DeFi Summer” of 2020, gas prices would skyrocket due to bots constantly outbidding each other to be first in line for lucrative trades, often reaching hundreds of Gwei and causing regular users’ transactions to stall. This made transaction inclusion very unpredictable – a user might set a fee they thought was high, only to see the target gas price double in seconds as two arbitrage bots battled. With the introduction of off-chain MEV auctions, much of this competition moved off the network. Instead of bidding up the *public* gas price in the mempool, searchers started bidding through private auctions and directly to builders. The result was a notable drop in spam and more stable fees for users. A Flashbots report highlighted that these private orderflow auctions eliminated many failed transactions and artificially inflated fees, leading to a smoother user experience. [^10] Essentially, MEV infrastructure turned a chaotic, implicit competition into an explicit, organized market. By extracting MEV, block producers are creating an efficient market for blockspace where every bit of block capacity finds the highest bidder. [^11] Under-provisioned blockspace (where demand far exceeds supply) inherently causes high fees; MEV doesn’t eliminate that, but it ensures that whoever values the space most gets it. From the network perspective, by removing spam and wasted transactions, more of each block is filled with useful transactions. In periods of high DeFi activity, this prevents situations where a valuable liquidation or arbitrage is missed (which could have knock-on effects like unbalanced prices or insolvent loans). Moreover, MEV revenue (the payments from searchers to proposers) gets distributed to validators, which strengthens the incentive to participate in securing the network. # III. Types of MEV There are many different types of activities that can be categorized as MEV. Most of the actions make the ecosystem more robust and prices more accurate, benefiting market participants. While certain types of MEV in their current implementation create negative externalities, we highlight various technological advances which we believe will mitigate these externalities. ## A. Arbitrage, or Loss-vs-Rebalancing Unlike US securities exchanges like the New York Stock Exchange, where liquidity is effectively orphaned on-exchange, and trading happens predominantly during trading hours on weekdays – crypto markets are global, and trade 24/7, with liquidity spread across innumerable centralized and decentralized venues. Further, the decentralized exchanges that power most of this activity generally do not use Central Limit Order Books the way a traditional securities exchange would – instead, Automated Market Makers, or AMMs, enable users to swap between pools of assets based off each pool’s mathematical relation to the other (e.g. when a user wants to swap $15 of USDC for ETH, the user deposits USDC in the smart contract comprising the USDC pool, and then is able to withdraw an amount of ETH from the corresponding ETH pool based on the relative balances held by the AMM). Anyone can contribute their own assets to these pools. In other words, “trading” on AMMs is really just rebalancing of asset pools, governed by self-executing code, without any intermediaries or direct counterparties. Given their decentralized design, and emphasis on incentives to drive distributed network coordination, crypto markets rely on market makers and arbitrageurs to resolve dislocations between asset prices on centralized and decentralized trading venues, buying on one venue and selling on another, to capture the spread. In doing so, there is effectively a “global best bid and offer” on crypto assets as a result of raw economics and market forces. This arbitrage can be between centralized and decentralized exchanges (CEX-DEX), between two or more decentralized exchanges (DEX-DEX) or even between two or more pools in the same decentralized exchange. The value that market makers are willing to pay block producers to include their transactions in blocks swiftly enough to capture these spreads is one of the most common forms of MEV. CEX-DEX arbitrage remains the most valuable source of MEV for blockbuilding on Ethereum by a significant margin. [^12] When a searcher arbitrages a price difference between decentralized exchanges, they are forcing the prices to realign, which benefits everyone trading after them (the markets sync up closer to fair value). While some arbitrage-based MEV is inevitable and useful for the functioning of these markets, researchers and market participants agree that it would be valuable to reduce the costs imposed by it. This is an active area of research. ## B. Liquidations Decentralized lending protocols such as Compound and Aave enable users to lend and borrow digital assets through autonomous smart contracts, eliminating the need for traditional financial intermediaries. Lenders contribute assets like ETH or stablecoins into liquidity pools and, in return, receive receipt tokens that represent their liquidity pool positions (which they can then later return, and “burn”, to retrieve their pooled assets). Borrowers, by contrast, must provide collateral (some other digital asset valued at greater than the value of their loan) to secure loans. Should the value of their collateral fall below a specified threshold, the position becomes subject to liquidation—a foundational safeguard designed to preserve the solvency of the protocol and protect depositors from loss. MEV is critical in enabling timely and efficient liquidations. When a borrower’s position becomes undercollateralized—typically due to price volatility or accrued interest—external actors, often automated bots, are incentivized to repay the outstanding debt in exchange for a portion of the collateral at a discount. MEV strategies allow these participants to compete for liquidation opportunities by bidding for transaction priority within blocks. This competitive process ensures that distressed positions are resolved within seconds of becoming at-risk, thereby preventing the accrual of bad debt and maintaining the protocol’s financial integrity. MEV in this context plays a constructive and stabilizing role, leveraging market incentives to uphold the health, transparency, and resilience of decentralized financial infrastructure. ## C. Transaction MEV On the other end of the spectrum is the form of MEV described in the canonical [Ethereum is a Dark Forest](https://www.paradigm.xyz/2020/08/ethereum-is-a-dark-forest) by Dan Robinson and Georgios Konstantopoulos. [^13] Searchers scan the public mempool (as discussed earlier, effectively the transaction “waiting room”, where transactions queue up for inclusion in blocks) for MEV opportunities. For example, a buy order on a DEX in a low-liquidity pool presents an opportunity for a "sandwich attack”; whereby a transaction to buy that asset *before *the targeted transaction (the “frontrun”) and a transaction to immediately sell that asset *after *the targeted transaction (the “backrun”), paying sufficient priority fee to ensure that their transactions are prioritized appropriately to execute their desired intent. As a result, the searcher can capture some of the value from the price dislocation caused by the trading strategy at the expense of the trader. And then there is “backrunning”, a third type of transaction MEV: backrunning involves inserting a transaction behind a large order that has moved the price substantially (typically on an AMM), profiting by moving the price back in line with a global equilibrium. Frontrunning and sandwiches can implicate execution below the quoted price for traders and enable sophisticated actors to profit from the transparent nature of the network to extract value. [^14] Conversely, backrunning can be used as a mechanism for users to re-capture value that might otherwise be leaked to other MEV actors. As discussed above, given that transactions submitted to the mempool lack an explicit order until they are arranged in a block and proposed, this is using economic forces to influence the *ordering* of transactions, rather than *re*-ordering transactions. And, critically, where a problem exists, the market provides a solution – or, in this case, many solutions. [^15] As with all things, competition breeds better outcomes for users. - **Protective Tools:** Two of the most popular MEV protection tools are Flashbots Protect and MEV Blocker. These tools optimize the transaction experience for DEX users by protecting their pre-trade information and providing gas refunds and MEV rebates. DEXs, frontends, wallets, and individual users can set their RPCs to submit transactions through these tools. Tools such as Flashbots Protect share a public end point for searchers that reveals only enough information for arbitrage opportunities, increasing execution predictability for users, but not enough information for sandwich bots to frontrun the transaction. Ultimately, these tools are designed to make MEV searchers compete to return as much value as possible to the user. The result? Up to 90% of the arbitrage opportunity is shared back to the user following inclusion. - **Direct Validator/Builder Submissions:** Some sophisticated users or protocols form direct links to block builders or validators. For example, a trader executing a multi-million dollar transaction might coordinate with a builder to include it in the next block for a predetermined fee, ensuring it is not front-run. This can be done via the MEV-Boost relay network or even by running one’s own builder. The Builder API that Ethereum clients support (via MEV-Boost) allows anyone to submit a payload for consideration. While regular users don’t usually submit entire blocks, some are experimenting with user-driven block building (especially on L2s with proposer ordering rules). The net effect is a richer landscape of orderflow auctions – not just one public auction (the mempool) but many private ones. - **MEV Dashboards and Monitoring:** Transparency has improved with tools that let anyone observe MEV activity in real time. For instance, Sorella Labs provides a real-time MEV dashboard that classifies each Ethereum block’s extracted MEV. [^16] Their backend, called Brontes, analyzes blocks to detect common MEV strategies (arbitrages, sandwich attacks, liquidations, etc.) and streams this info live. [^17] A user or researcher can look at such a dashboard to see, for example, which builder won the latest block, how much MEV was in it, and what types of strategies were executed. Other platforms and community dashboards (on Dune Analytics, etc.) track metrics like the percentage of blocks sourced from Flashbots, the total MEV extracted per day, and how many transactions bypassed the public mempool. All these give legal and technical observers insight into the MEV market as it unfolds. - **Decentralizing Builders: **While MEV-Boost market structure has successfully alleviated network congestion issues and centralizing forces on the validators set, over time certain blockbuilders have begun to win a disproportionate number of block inclusion auctions. The market has responded to this trend and introduced a technological innovation to addresses growing concerns of centralization. Flashbots, together with Beaverbuild (a large blockbuilder) and Nethermind (an Ethereum research and engineering organization and supporter of the Nethermind Ethereum node implementation), recently developed BuilderNet, a decentralized network of blockbuilders. [^18] BuilderNet leverages advances in Trusted Execution Environments (TEEs) – encrypted enclaves where execution occurs, but is cryptographically verifiable by third parties – and introduces a multioperator system where multiple parties can operate the same blockbuilder by running instances of that open source builder in a TEE, which apps and users can then route their transactions to. Thus, there is joint simultaneous operation of a single blockbuilder. Ultimately, the objective is to have an efficient and fully decentralized blockbuilding landscape. These developments indicate a maturing ecosystem where MEV is competitive but also cooperative: users, searchers, builders, and validators are finding arrangements that share value and reduce harm. In effect, this ecosystem provides balance and improved outcomes despite or even because of the existence of many competing traders and differing trading strategies. It is a microcosm of how decentralization makes things both stronger and better. This steady, constructive evolution in block production market structure is the very reason that flexibility in approach is required for these technical solutions to continue to develop. # IV. Legal Analysis Some of the policy discussions about MEV have compared certain MEV strategies to behaviors that could be unlawful in traditional securities markets, such as front-running client orders. Below, we examine why MEV on Ethereum does not amount to securities fraud or insider trading under U.S. federal securities laws. We also evaluate MEV in light of U.S. best execution obligations. ## A. MEV and Securities Fraud The Bank for International Settlements (the “**BIS**”), the International Organization of Securities Commissions (“**IOSCO**”), the International Monetary Fund (the “**IMF**”) and the Financial Stability Board (the “**FSB**”) have all broadly analogized MEV extraction to *market manipulation or abuse* in conventional markets. [^19] For example, a BIS bulletin observed that Ethereum validators “open\[\] the door to front-running and other forms of market manipulation,” noting that in most jurisdictions such front-running is illegal. [^8] However, as discussed in this section, these analyses are fundamentally flawed because they fail to account for the critical differences between traditional finance and crypto markets, including the different systems for determining transaction priority. When analyzing specific claims, it's clear that MEV does not meet the required elements of securities fraud or insider trading. ### 1. Applicable statutes, rules and elements of a claim Section 10(b) of the Securities Exchange Act [^20] and SEC Rule 10b-5 [^21] broadly prohibit the use of “any manipulative or deceptive device or contrivance” in connection with the purchase or sale of securities. To successfully find that a defendant is liable for fraud in violation of Rule 10b-5, a plaintiff must plead and prove: 1. The defendant engaged in a **manipulative** or **deceptive** act. [^22] To state a claim that a defendant engaged in market manipulation under Rule 10b-5, the plaintiff must show that the activity was intended to deceive investors about how other market participants value a security. [^23] 1. **Scienter**, which is defendant's knowledge that an act or conduct is wrongful and the defendant’s intent to act despite this knowledge. [^24] In market manipulation cases, scienter is often the only factor that distinguishes legitimate trading activity from improper manipulation. 1. **Reliance** by the investors on the manipulative or deceptive act when making investment decisions. [^25] 2. **Economic loss** suffered by investors. [^26] Insider trading is one type of "device, scheme, or artifice to defraud" enforced under Section 10(b) and SEC Rule 10b-5. The law emerged from the principle that violating the relationship of trust and confidence that exists "between the shareholders of a corporation and those insiders who have obtained confidential information by reason of their position with that corporation" amounts to fraud. [^27]Insider trading violations may also involve securities trading by individuals who misappropriate material nonpublic information. [^28] In the context of an insider trading claim under Section 10(b) of the Exchange Act and Rule 10b-5, a plaintiff must plead and prove: 1. A breach of a **fiduciary duty** or other relationship of trust and confidence. As discussed above, the two broad theories that define the types of duty that, when breached, can lead to insider trading violations are: (A) the *classical theory* of insider trading, which states that liability arises for corporate officers or insiders who owe a fiduciary duty to the company and its shareholders; [^29] and (B) the *misappropriation theory* which rests on a duty of trust and confidence that the person making the trade owes to the source of the confidential information. [^30] 2. The use or possession of **material, nonpublic information** in connection with the purchase or sale of securities. 3. **Scienter**. 4. A **personal benefit**, for cases where corporate insiders (tippers) pass or "tip" material nonpublic information to outsiders (tippees) who trade based on that information. In addition, Section 9 of the Exchange Act [^31] provides a more targeted prohibition against specific manipulative trading practices. These deceptive schemes are designed to create a false impression of market activity and ultimately influence the price of a security. Classic examples include pump and dump schemes, [^32]matched trades, [^33] or wash sales. [^34] To establish a Section 9 violation, the plaintiff must plead and prove: 1. **Manipulative** activity. 2. **Scienter**. 3. Purposeful **inducement**, meaning that the manipulative activity was conducted specifically to induce others to buy or sell the security. 4. **Reliance**. 5. **Effect on the price**, meaning that the manipulative affected the price at which the plaintiff bought or sold the security. [^35] ### 2. Analysis Suppose, for the sake of argument, we assume that the MEV transactions in question involve the trading of securities and satisfy the requisite jurisdictional means. Notwithstanding, we argue that the MEV activity we describe above would not violate Section 10(b) of the Exchange Act, Rule 10b-5 or Section 9 of the Exchange Act. ### a) MEV does not involve the scienter required for claims under Section 10(b), Rule 10b-5 or Section 9 As described above, any claim under Section 10(b) of the Exchange Act, Rule 10b-5 or Section 9 of the Exchange Act would require a showing that the relevant MEV participant employed manipulative or deceptive acts and did so with scienter. However, the MEV activity we describe above does not meet this standard. Consider for example a searcher that implements a “sandwich attack.” This searcher operates using public information in the mempool, exploiting transparency and speed to “frontrun” a market moving transaction, and profit with a “backrun”. However, the searcher is not intentionally creating a false impression of market activity. [^36] To identify conduct that is “unrelated to the natural forces of supply and demand,” [^37] courts assess whether the subject transactions convey “a false pricing signal to the market.” [^38] Here, the searcher is not deceiving others with falsities (including the trader that got sandwiched) or creating the appearance of a false trading activity like spoofing or wash trading: they are submitting real economic transactions. Or consider a blockbuilder that is assembling transactions from the public mempool and private searcher bundles for maximum profit. As discussed above, blockchain transaction ordering does not operate under the same assumptions as traditional markets, and behavior that is manipulative in a first-in-time, order-protected market is not so in Ethereum. Unlike on an exchange with time-priority rules, Ethereum has no inherent rule promising that earlier-submitted transactions execute first. The protocol explicitly allows a blockbuilder to prioritize transactions that pay a larger tip over transactions that were submitted first to the mempool. In that sense, what looks like manipulation (jumping the queue) might be considered a built-in feature of the system’s design (a fee auction for blockspace). [^39] ### b) MEV does not involve a breach of fiduciary duty or misappropriation of material nonpublic information required for an insider trading claim Nor does MEV activity inherently meet the standard of insider trading since it does not involve a duty under either the classical or misappropriation theory, nor any nonpublic information. MEV actors do not have any explicit fiduciary duty to network users broadcasting transactions. MEV actors like searchers or blockbuilders are also not in a position to take advantage of agency relationships or information asymmetries such that a court would impose an implicit fiduciary duty. MEV actors such as searchers or blockbuilders are also not misappropriating any confidential information that violates a duty of trust. In fact, Ethereum’s public mempool means that pending transaction information is openly available to anyone monitoring the network. If a searcher bot sees a user’s Uniswap trade in the mempool and decides to execute a sandwich, the information (the trade size, asset, etc.) was publicly visible. It’s not “insider” information in the legal sense; there is no breach of confidence, because the trader voluntarily broadcast the transaction to a public network. Absent a duty of confidentiality, merely possessing information (even if it gives a trading edge) is not illegal. As the Supreme Court made clear in *Dirks* and *United States v. O’Hagan*, insider trading liability hinges on misappropriating information or breaching a fiduciary-like duty. [^40] In short, the typical MEV scenario – exploiting publicly available mempool data – does not fall under the classical definition of insider trading, because the information used (pending orders) is not nonpublic. It’s akin to high-frequency traders in equities who glean cues from public order flow; that might raise fairness concerns, but it isn’t insider trading since they didn’t steal or improperly obtain the information. ## B. MEV and Best Execution ### 1.Applicable statutes, rules and elements of a claim The duty of best execution is a foundational principle under federal securities law that reflects the broader investor protection goals of the U.S. securities laws. The obligation is derived from a combination of Financial Industry Regulatory Authority (FINRA) rules, SEC oversight and longstanding common law fiduciary duties. At its core, the best execution requirement mandates that broker-dealers use reasonable diligence to ensure that customer orders are executed under the most favorable terms reasonably available, considering price, speed, and other relevant factors at the time of execution. The primary rule governing best execution in the U.S. is FINRA Rule 5310, which explicitly requires broker-dealers to seek the best market for a customer’s order and to execute that order so the resulting price is as favorable as possible under prevailing market conditions. [^41] This rule outlines several factors broker-dealers must consider, including the character of the market, order size, and the number of markets checked. Importantly, best execution does not require always obtaining the lowest price, but rather making a diligent effort to evaluate and access the most advantageous execution based on a range of criteria. Broker-dealers are also expected to regularly review their execution quality and order routing practices to ensure continued compliance. In addition to FINRA rules, SEC regulations such as Regulation NMS (National Market System) reinforce best execution principles. Rule 611, [^42] the Order Protection Rule, prevents “trade-throughs” by requiring that trades be executed at the best displayed price across all national exchanges. Further, SEC Rule 606 [^43] imposes public disclosure requirements on broker-dealers regarding their order routing practices and any receipt of payment for order flow (PFOF), a practice that can create potential conflicts of interest. Broker-dealers must ensure that such conflicts do not compromise their duty to seek best execution for their customers. Finally, a broker-dealer's obligation to obtain best execution of a customer's order in any security is based, in part, on the common law agency duty of loyalty, which obligates an agent to act exclusively in the customer's best interest. That’s why behavior like a broker trading ahead of a client (“front-running”) or secretly adding a markup is forbidden: it deprives the client of the best price available. ### 2. Analysis In the current DeFi landscape, users often transact without any intermediary owing them a fiduciary or best execution duty. For example, a searcher that “frontruns” a large transaction in the public mempool does not owe the party that broadcasted that transaction a best execution duty. While regulators, including the SEC, have previously hinted that certain DeFi front-ends and wallets could be deemed to be broker-dealers (and thus be subject to a best execution duty), courts have so far held that noncustodial products do not meet the definition of broker-dealers. [^44] In other words, best execution is a concept tied to intermediaries who owe duties to investors; decentralized and noncustodial infrastructure is not subject to best execution duty. However, an SEC registered broker-dealer that facilitates customer trades in tokenized securities via a DEX on Ethereum would still owe a duty of best execution. Therefore, it would need to assess the execution quality on the DEX, including the likelihood of slippage and risk that its transactions may be “sandwiched” by a searcher. For instance, if a retail broker-dealer allowed a client’s order to be systematically sandwiched on an exchange when alternatives existed, regulators may find a failure of best execution. The best execution duty compels intermediaries to consider factors like price improvement and market impact; knowingly sending orders into a public mempool where it's likely to be sandwiched by an MEV bot could violate that duty if better options are reasonably available. However, there is nothing inherent in the block production supply chain or MEV that would prevent the broker from meeting its obligations. For example, the broker might use MEV mitigation techniques, including splitting orders, using a private mempool, or seeking out trading venues that utilize forms of MEV protection – whether that is a venue with native protection, such as CoW Swap, or other DeFi frontends that have embedded solutions like Flashbots Protect. In other words, a regulated broker can’t simply ignore MEV, but the dynamic nature of market structure and trading technology continues to shape the scope of this obligation, requiring firms to adapt their practices accordingly. # V. Conclusion The market continues to provide solutions for each successive issue around efficiency or execution, and regulators should thus be judicious in how they choose to address MEV and the blockbuilding supply chain. For one, the Commission could consider opt-in disclosure guidelines for DeFi frontends (user interfaces that are webhosted by development companies, rather than the self-executing protocols themselves) that wish to attract the trading activity of Commission registrants, describing what technical approaches or third-party software that venue uses to mitigate MEV. In so doing, registrants can make informed decisions that will best suit their best execution duties to their clients. Additionally, to encourage that these networks continue to trend towards decentralization, the Commission may consider whether guidance should be issued around whether entities registered with the Commission as exchanges (whether currently, or under some future market structure legislative framework) are also allowed to operate blockbuilders on Layer 1 networks, to avoid centralizing forces and any potential conflicts of interest. Ultimately, these baselayer markets are still quite nascent, with significant research and risk capital invested in making them increasingly more efficient. While the Commission has a duty to protect investors and consumers, its duty to promote capital formation and foster innovation must take precedence here, and any guidance the Commission might choose to issue should take a “first, do no harm” approach, and trend towards flexible principles, rather than ossifying requirements. Continued neutrality of the baselayer is imperative for the further development of these decentralized protocols, and egalitarian access by their users. ### Acknowledgments *Thank you to *[*Reid Yager*](https://x.com/0xYager)*, *[*Dan Robinson*](https://www.paradigm.xyz/team/dan-robinson)*, *[*Katie Biber*](https://www.paradigm.xyz/team/katie-biber)*, *[*Justin Slaughter*](https://www.paradigm.xyz/team/justin-slaughter)*, and *[*Gina Moon*](https://www.paradigm.xyz/team/gina-moon)* for review and feedback.* [^1]: Peirce, Hester, There Must Be Some Way Out of Here, February 21, 2025, available here: https://www.sec.gov/newsroom/speeches-statements/peirce-statement-rfi-022125. [^2]: Daian et al., Flash Boys 2.0: Frontrunning, Transaction Reordering, and Consensus Instability in Decentralized Exchanges, April 10, 2019, available here: https://arxiv.org/pdf/1904.05234.pdf [^3]: See, Salas, Alejo, Quantifying Realized Extractable Value, March 19, 2021, available here: https://hackmd.io/@flashbots/quantifying-REV [^4]: See, e.g., Varunx, Ethereum Block Building: The Hidden Economy Behind Every Transaction, March 24, 2025, available here: https://hackernoon.com/ethereum-block-building-the-hidden-economy-behind-every-transaction [^5]: See Flashbots, MEV-Boost, available here: https://docs.flashbots.net/flashbots-mev-boost/introduction [^6]: Flashbots, an Ethereum research group, is a Paradigm portfolio company. [^7]: See, Daian, Phil, Decentralized Crypto Needs You to Be a Geographical Decentralization Maxi, March 2023, available here: https://collective.flashbots.net/t/decentralized-crypto-needs-you-to-be-a-geographical-decentralization-maxi/1385 [^8]: Raphael Auer, Jon Frost and Jose Maria Vidal Pastor, Miners as intermediaries: extractable value and market manipulation in crypto and DeFi, June 16, 2022, available here: https://www.bis.org/publ/bisbull58.pdf [^9]: See, Chris Maree, Unbundling MEV Supply Chain Part 1: History and Evolution, March 7, 2024, available here: https://blog.hack.vc/unbundling-mev-supplychain-part-1-history-and-evolution/ [^10]: https://docs.flashbots.net/flashbots-auction/overview [^11]: For example, suppose there’s an arbitrage opportunity that will net $1,000 profit. A searcher is willing to pay, say, $900 in fees for it (keeping $100 profit). If that arbitrage transaction fits in the block, it will outbid other transactions for gas space, but it also creates value by arbitraging markets (potentially bringing prices back in line across exchanges). The block builder who includes it gets $900 that blockspace wouldn’t have otherwise yielded. If the builder didn’t include it (say out of a notion of fairness to time ordering), the opportunity might go to waste – or be picked up in a later block by someone else. Either way, not including it would mean the block earned less in fees. [^12]: https://libmev.com/ [^13]: Robinson, Dan and Georgios Konstantopolous, Ethereum is a Dark Forest, Paradigm blog (8.28.2020), available here: https://www.paradigm.xyz/2020/08/ethereum-is-a-dark-forest [^14]: All transactions take place within the range of a user’s market order, also known as their set “slippage”. All sandwiches are in the range of slippage set by users. A transaction would not land onchain if it were to execute outside the user-set slippage of their market order. [^15]: Interestingly, many Layer 2 networks lack mempools, and thus do not have prevalent sandwich activity. [^16]: Sorella Labs is a Paradigm portfolio company. [^17]: See, Sorella Labs Dashboard, available here: https://sorellalabs.xyz/dashboard [^18]: See, “Introducing Buildernet,” available here: https://buildernet.org/blog/introducing-buildernet [^19]: Tom Momberg & Angela Angelovska-Wilson, Regulating the Unseen: Limiting the Potential for Negative Externalities from MEV Realization, October 22, 2024, available here: https://dlxlaw.com/leaderships_blog/regulating-the-unseen-limiting-the-potential-for-negative-externalities-from-mev-realization/ [^20]: 15 U.S.C. § 78j(b). [^21]: 17 C.F.R. § 240.10b-5. [^22]: 485 U.S. 224, 232 (1988) (quoting , 426 U.S. 438, 449 (1976)). [^23]: Prohibited activities include illegitimate, sham, or inherently deceptive conduct where a defendant aims to create a false appearance of market activity, such as: [^24]: See, Aaron v. SEC, 446 U.S. 680 (1980); Ernst & Ernst v. Hochfelder, 425 U.S. 185 (1976). [^25]: See, e.g., In re Garrett Motion Inc. Sec. Litig., 2022 WL 976269, at *17 (S.D.N.Y. Mar. 2022). [^26]: See, e.g., Fezzani v. Bear, Stearns & Co. Inc., 716 F.3d 18, 22-23 (2d Cir. 2013). [^27]: United States v. O'Hagan, 521 U.S. 642, 651-52 (1997) [^28]: Insider trading claims most commonly are based on alleged violations of Section 10(b) of Exchange Act, 15 U.S.C. § 78j(b), and its implementing regulation, Rule 10b-5, 17 C.F.R. § 240.10b-5. However, these types of claims also can be pursued under other Exchange Act provisions as well as other statutes, including: Rule 14e-3 under the Exchange Act, 17 C.F.R. § 240.14e-3a, Section 20(a) of the Exchange Act, 15 U.S.C. § 78t(a). Federal prosecutors have brought insider trading claims under criminal statutes prohibiting mail, wire, and securities fraud. (see 18 U.S.C. §§ 1341, 1343, 1348. [^29]: Chiarella v. United States, 445 U.S. 222, 228-29 (1980). [^30]: United States v. O’Hagan, 521 U.S. 642, 652 (1997) [^31]: 15 U.S.C. § 78i. [^32]: These schemes involve artificially inflating the price of a security through artificial trading activity of buying the security while disseminating false or misleading statements or promotional campaigns to the public. This manipulative activity creates a false impression of market activity which allows the manipulator to then sell the security at the inflated price to unsuspecting investors. See, e.g., SEC v. Stubos, 634 F. Supp. 3d 174, 202-03 (S.D.N.Y. 2022). [^33]: Matched trades involve placing pre-arranged buy and sell orders for a security of substantially the same size, time, price in the same security on a national securities exchange. The coordinated trading activity is designed to artificially inflate or depress the stock price. See, e.g., SEC v. Fiore, 416 F. Supp. 3d 306, 316 (S.D.N.Y. 2019). [^34]: Wash sales involve an investor simultaneously buying and selling the same security with no change in beneficial ownership. This trading activity is designed to create the illusion of trading activity stock. It can also be used to generate artificial losses for tax purposes, allowing the investor to claim deductions they otherwise would not be entitled to take. See, e.g., SEC v. Masri, 523 F. Supp. 2d 361, 366-67 (S.D.N.Y. 2007). [^35]: See, e.g., Dekalb Cnty. Pension Fund v. Transocean Ltd., 817 F.3d 393, 403 (2d Cir. 2016); AnchorBank, FSB v. Hoefer, 649 F.3d 610, 616-17 (7th Cir. 2011). [^36]: See, e.g., ATSI Communications, Inc. v. The Shaar Fund, Ltd., 493 F.3d 87 (2d Cir. 2007); Pagel, Inc. v. SEC, 803 F.2d 942 (8th Cir. 1986); Markowski v. SEC, 274 F.3d 525 (D.C. Cir. 2001). [^37]: Mobil Corp. v. Marathon Oil, Corp., 669 F.2d 366, 274 (6th Cir. 1981). [^38]: ATSI Communications, Inc. v. The Shaar Fund, Ltd., 493 F.3d 87 (2d Cir. 2007) [^39]: It's important to distinguish the actions of MEV actors such as searchers or block builders from the alleged actions of the defendants in United States v. PERAIRE-BUENO, 1:24-cr-00293, where the defendants were changed with conspiracy to commit wire fraud, wire fraud, and conspiracy to commit money laundering. According to the indictment, the defendants exploited a vulnerability in the MEV-Boost software allowing them to access and alter pending private transactions. In contrast, searchers or block builders are operating according to the understood protocol rules. [^40]: Dirks v. SEC, 463 U.S. 646 (1983); United States v. O'Hagan, 521 U.S. 642 (1997). [^41]: “(a)(1) In any transaction for or with a customer or a customer of another broker-dealer, a member and persons associated with a member shall use reasonable diligence to ascertain the best market for the subject security and buy or sell in such market so that the resultant price to the customer is as favorable as possible under prevailing market conditions. Among the factors that will be considered in determining whether a member has used "reasonable diligence" are: [^42]: 17 CFR § 242.611. [^43]: 17 CFR § 242.606. [^44]: SEC v. Coinbase, No. 1:23-cv-04738 (SDNY) at 82-83 (“The SEC does not allege that Coinbase performs any key trading functions on behalf of its users . . . Coinbase has no control over a user’s crypto-assets or transactions via Wallet . . . while Wallet helps users discover pricing on decentralized exchanges, providing pricing comparisons does not rise to the level of routing or making investment recommendations.”). ## https://www.paradigm.xyz/writing/market-structure-principles # Market Structure Legislation Principles > Our proposed principles for market structure legislation aim to explicitly protect DeFi and early-stage innovators. As Capitol Hill advances its work on market structure legislation, the industry has an important moment to ensure any framework reflects its core values and explicitly protects DeFi and open innovation. Just as important is advocating for ideas that have yet to be created, and startups in their earliest stages whose voices might be overlooked. We've developed these proposed principles for market structure legislation to articulate in plain English how DeFi might be defined in legislation. They're designed to bridge the gap between the crypto community and policymakers, and we're opening them to community input to strengthen their accuracy and impact. Your perspective matters – use this [form](https://forms.gle/j5xogEaJTTnYFLiN7) to tell us what works and what we might have missed in our approach. ## **Summary:** Any market structure legislation that seeks to protect DeFi should: - Provide a baseline spot commodity regulatory regime that largely excludes the SEC, including having most tokens be treated as digital commodities but letting the SEC keep jurisdiction over tokenized stocks, without giving the CFTC additional power to regulate spot physical commodities. - Exempt DeFi from all major CeFi regulatory regimes, including by making clear that DeFi protocols will not be required to be registered. ## **Background:** In policymaking, a term sheet details the core components and objectives of a proposed law to help guide the legislative drafting process. The principles outlined in this document were developed using the 2023 version of the [Lummis-Gillibrand Responsible Financial Innovation Act](https://www.lummis.senate.gov/wp-content/uploads/Lummis-Gillibrand-2023-Section-by-Section-Final.pdf) as our analytical foundation. We selected this bill because of its clear division of tokens between securities and commodities. That legislation also established regulatory requirements for centralized crypto exchanges (under both CFTC and SEC regulation), protections for consumers, and coordination between agencies on crypto regulation. ## **Term Sheet of Principles for Legislation:** 1. Crypto assets are native digital assets that are imbued with property rights. 2. Distributed ledger technology means a ledger shared across distributed nodes within a network, synchronized between the nodes, that is publicly accessible, and is appended to via some kind of cryptographic consensus. 3. Smart contracts are computer code deployed to distributed ledger technology that execute instructions based on occurrence or nonoccurrence of conditions. 4. Crypto assets are commodities, except for those that have all the forms and aspects of a security which are also on a decentralized ledger (e.g. Apple stock on a blockchain). 5. A Crypto Asset Exchange is a custodial trading facility that lists at least one crypto asset. 6. A Decentralized Crypto Asset Exchange is 7. public, permissionless code on a distributed ledger that lets users or groups of users create pools for crypto asset trading that 8. no person or group of persons can universally control, block, or approve the transactions on the exchange and 9. is non-custodial in nature 10. CFTC registrants that hold crypto for others should have to follow normal CFTC reporting and recordkeeping requirements. 11. The CFTC should have exclusive jurisdiction over transactions on centralized crypto asset exchanges as well as transactions on decentralized crypto asset exchanges. CFTC does not have the power to issue regulations on spot commodity transactions, however. 12. The CFTC should not have jurisdiction over crypto assets that are securities. 13. The CFTC should not have jurisdiction over NFTs or other non-fungible tokens. 14. CFTC registrants that hold crypto for others should hold their customer assets in a safe manner, including using a separate custodian, segregating funds, and holding customer assets in Treasuries and other financial products allowed by the CFTC. 15. Customers can choose to opt out of these protections. 16. Decentralized crypto asset exchanges should not be asked to register with the CFTC or SEC; DEXs can be used to trade both digital assets commodities and digital asset securities. 17. Any custodial trading facility that offers a market in crypto assets should register as a crypto asset exchange and follow basic core principles, such as recordkeeping; not allowing manipulation; having rules on conflicts of interests; segregating user funds; and having appropriate cybersecurity protections. 18. CFTC civil enforcement penalties should apply to crypto assets under CFTC jurisdiction. 19. The CFTC shall have adequate authority to set regulatory requirements for manipulative trading of crypto assets. 20. Crypto assets should receive the same protections in bankruptcy as cash, commodities, securities, and other property. 21. No national government should be allowed to prohibit trading of crypto assets on DeFi protocols globally. ## https://www.paradigm.xyz/writing/demystifying-the-north-korean-threat # Demystifying the North Korean Threat > There’s more to the DPRK than just Lazarus Group. One fateful morning in February, the SEAL 911 group lit up as we watched in confusion while Bybit withdrew over 1B USD of tokens from their cold wallet into a brand new address, only to promptly begin liquidating over 200M USD of LSTs. Within minutes, we had confirmation from both the Bybit team, as well as independent analysis (the multisig, which previously was using a publicly verified implementation of Safe{Wallet}, was now using a newly deployed unverified contract), that this was in fact not routine maintenance. Someone had pulled off the biggest hack in cryptocurrency history, and we had a front-row seat. While part of the team (along with the wider sleuthing community) got to work tracing the funds and sending out notifications to partnered exchanges, the rest of the team was trying to figure out what exactly happened, and whether any other funds were at risk. Fortunately, identifying the perpetrator was easy. Over the past few years, only one known threat actor had successfully stolen billions of dollars from cryptocurrency exchanges: North Korea, also known as the DPRK. However, beyond that, we had very little to work with. Not only would identifying the root cause of the compromise be challenging due to the sophistication of the DPRK hackers and how well they clean up after themselves, but even knowing which specific team within the DPRK was responsible was challenging. All we had to rely on was existing intelligence, which suggested that DPRK really liked compromising cryptocurrency exchanges via social engineering, so we considered it likely that DPRK had compromised the Bybit multisig signers and then deployed some malware to interfere with the signing process. This couldn’t have been further from the truth. As we found out a few days later, DPRK had actually compromised the infrastructure of Safe{Wallet} itself, and had deployed a malicious payload specifically targeting Bybit. This was a level of sophistication that no one had considered or been prepared for, and it was a major update to many of our threat models. DPRK hackers are an ever-growing threat against our industry, and we can’t defeat an enemy that we don’t know or understand. There are plenty of documented incidents and writeups of the various facets of DPRK cyber operations, but they’re difficult to piece together. I hope that this overview can provide a more comprehensive understanding of how the DPRK operates and what their tactics and procedures are, which in turn will make it easier to implement the correct mitigations. ## **Organizational Structure** Perhaps the biggest misconception to address is simply how to classify and name the vast range of DPRK cyberactivity. While using the term “Lazarus Group” colloquially is acceptable, it helps to be more rigorous when discussing the DPRK in detail. To start, it helps to have an understanding of the North Korean “org chart”. At the top is the ruling (and only) party of North Korea, the Workers’ Party of Korea (WPK), under which all North Korean government institutions operate. These include the Korean People’s Army (KPA) as well as the Central Committee. Within the KPA is the General Staff Department (GSD), home to the Reconnaissance General Bureau (RGB). Under the Central Committee is the Munitions Industry Department (MID). The RGB is responsible for almost all North Korean cyber warfare, including nearly all North Korean activity observed in the cryptocurrency industry. In addition to the infamous Lazarus Group, other threat actors that have emerged from the RGB include AppleJeus, APT38, DangerousPassword, and TraderTraitor. On the other hand, the MID is responsible for North Korea’s nuclear missiles program, and is the primary source of North Korean IT workers, tracked within the intelligence community as Contagious Interview and Wagemole. ## **Lazarus Group** Lazarus Group is a highly sophisticated hacking group to whom cybersecurity experts have attributed some of the largest and most devastating hacks in history. Lazarus Group was first identified by Novetta in 2016 during their analysis of the Sony Pictures Entertainment (Sony) hack [^1]. In 2014, Sony had been in the process of producing *The Interview*, an action comedy film whose central plot point was the humiliation and subsequent assassination of Kim Jong Un. Understandably, this was not well received by the regime, which retaliated by hacking into Sony’s network, stealing terabytes of data, leaking hundreds of gigabytes of confidential or otherwise sensitive information, and deleting the original copies [^2]. As then-CEO Michael Lynton put it, “the folks who did this didn’t just steal practically everything from the house; they burned the house down [^3]”. Ultimately, the attack cost Sony at least 15MM USD in investigation and remediation [^4], and presumably more in damages. Then, in 2016, a threat actor with remarkable degrees of similarity to Lazarus Group hacked the Bank of Bangladesh with the goal of stealing almost 1B USD [^5]. Over the course of a year, the threat actors worked to social engineer employees at the Bank of Bangladesh, ultimately securing remote access and pivoting within the bank’s internal network until arriving at the computers responsible for interfacing with the SWIFT network. From there, they waited for the perfect opportunity to strike: the Bank of Bangladesh closes for the weekend on Thursday, but the New York Federal Reserve closes for the weekend on Friday. On Thursday evening, Bangladesh local time, the threat actor used their access to the SWIFT network to send 36 separate transfer requests to the New York Federal Reserve, where it was Thursday morning, local time. Over the next 24 hours, the New York Fed forwarded these transfers to the Rizal Commercial Banking Corporation (RCBC) in the Philippines, which began actioning them. Then, when the Bank of Bangladesh reopened to discover the hack, they attempted to notify RCBC to halt the transactions in progress only to find that RCBC had closed for the long weekend due to the Chinese New Year. Finally, in 2017, the massive WannaCry 2.0 ransomware attack, which devastated industries around the world, was attributed in part to Lazarus Group [^6]. Estimated to cause billions of dollars in damages, WannaCry exploited a 0day in Microsoft Windows originally developed by the NSA in order to not only encrypt the local device but also spread itself to other reachable devices, ultimately infecting hundreds of thousands of devices around the world. Fortunately, the damage was limited due to the kill switch which was discovered and activated within eight hours by security researcher Marcus Hutchins [^7]. Throughout Lazarus Group’s history, they’ve demonstrated a high degree of technical competence and ability to execute on their goals, one of which is to generate revenue for the North Korean regime. Therefore, it was only a matter of time before they turned their attention to the cryptocurrency industry. ## **Spinout** Over time, as Lazarus Group became a catch-all term preferred by media when describing DPRK cyberactivity, the cybersecurity industry created more precise designations for specific activity out of Lazarus Group and the DPRK. Such is the case with APT38, which spun out of Lazarus Group in around 2016 in order to focus on financial crimes, targeting banks (such as the Bank of Bangladesh) first, then cryptocurrency later. Later, in 2018, a new threat designated as AppleJeus was identified to be spreading malware targeted towards cryptocurrency users [^8]. Finally, North Koreans posing as IT workers have permeated the tech industry since as early as 2018, when OFAC first announced sanctions against two front companies used by the North Koreans [^9]. ## **North Korean IT Workers** Although the earliest documented reference to North Korean IT workers comes from the 2018 OFAC sanctions, the 2023 report from Unit 42 goes into more detail and identifies two distinct threat actors: Contagious Interview and Wagemole [^10]. Contagious Interview is known to pose as recruiters for well known companies in order to ensnare developers into a fake interview process. From there, prospective candidates are instructed to clone a repository for local debugging, ostensibly as a coding challenge, but in reality the repository contains a backdoor which, when executed, gives over control of the affected machine to the attackers. This campaign has been ongoing and has been documented as recently as August 2024 [^11]. On the other hand, the primary goal of Wagemole operatives isn’t to hire potential victims, but rather be hired into companies instead, where they simply work as normal, although perhaps less-than-effective, engineers. That being said, there have been documented incidents of IT workers leveraging their access offensively, such as in the Munchables incident, where an employee with links to DPRK activity leveraged their privileged access to the smart contracts in order to steal all the assets. Wagemole operatives can range in degrees of sophistication, from cookie-cutter resume templates and an unwillingness to participate in video calls to highly tailored resumes, deepfake video interviews, and identifying documents such as drivers licenses and utility bills. In some cases, operatives remained embedded within victim organizations for up to a year before leveraging their access to compromise additional systems and/or cash out entirely. ## **AppleJeus** AppleJeus is primarily focused on distributing malware and specializes in complex supply chain attacks. In 2023, the 3CX supply chain attack allowed attackers to potentially infect the more than 12 million users of the 3CX VoIP software [^12], but it was later discovered that 3CX themselves had been compromised through a supply chain attack affecting one of their upstream vendors, Trading Technologies 13. [^13] Within the cryptocurrency industry, AppleJeus started out by distributing malware packaged as legitimate looking software, such as trading software or cryptocurrency wallets. However, over time, their tactics evolved. In October 2024, Radiant Capital was compromised through malware delivered over Telegram from a threat actor impersonating a trusted contractor, which Mandiant attributed to AppleJeus [^14]. ## **Dangerous Password** Dangerous Password is responsible for low-sophistication social engineering based attacks within the cryptocurrency industry. As early as 2019, Dangerous Password was documented by JPCERT/CC to be sending phishing emails with enticing attachments for users to download [^15]. In previous years, Dangerous Password was responsible for phishing emails impersonating prominent figures within the industry with subject lines such as “Huge Risk of Stablecoins and Crypto Asset” [^16]. Today, Dangerous Password continues to send phishing emails, but has also evolved to other platforms. For example, Radiant Capital reported that they were compromised through a phishing message via Telegram from someone impersonating a security researcher distributing a file called “Penpie_Hacking_Analysis_Report.zip” [^14]. Additionally, users report being contacted by individuals impersonating journalists and investors who ask to schedule a call using an obscure video conferencing app. Like Zoom, these apps will download a one-time installer, except that upon running, malware will be installed on the device. ## **TraderTraitor** TraderTraitor is the most sophisticated DPRK threat actor targeting the cryptocurrency industry, and was responsible for the hacks against Axie Infinity and Rain.com, among others 18. [^17] TraderTraitor almost exclusively targets exchanges and other companies with large reserves and does not deploy 0-days against its targets, but rather employs highly sophisticated spearphishing techniques against its victims. In the case of the Axie Infinity hack, TraderTraitor reached out to a senior engineer via LinkedIn and successfully convinced them to go through a series of interviews before sending an “offer” which delivered the malware [^18]. Then, in the WazirX hack, TraderTraitor operatives compromised an yet-to-be-identified component of the signing pipeline, then caused WazirX engineers to conduct a cold-to-hot wallet rebalance by depleting the exchange’s hot wallet through repeated deposits and withdrawals [^19]. When the WazirX engineers attempted to sign the transaction to transfer funds, they were instead tricked into signing a transaction that transferred control of their cold wallet over to TraderTraitor. This mirrors closely the exploit against Bybit from February 2025, where TraderTraitor first compromised the Safe{Wallet} infrastructure through a social engineering attack before deploying malicious JavaScript to the Safe{Wallet} frontend designed specifically to target Bybit’s cold wallet 21. [^20] When Bybit went to rebalance their wallets, the malicious code activated and instead caused the Bybit engineers to sign a transaction that handed over control of their cold wallet. ## **Staying Safe** North Korea has demonstrated the ability to deploy 0-days against its adversaries, but there have been no recorded or known incidents of North Korea deploying 0-days against the cryptocurrency industry. As such, for almost all DPRK threat actors, the typical security advice applies. For individuals, use common sense and be wary of social engineering tactics. For example, if someone claims to have some highly confidential information that they’re willing to share with you, be cautious. Alternatively, if someone is applying time pressure against you to download and run some software, consider whether they’re trying to put you in a position where you’re not thinking logically. For organizations, apply the Principle of Least Privilege where possible. Minimize the number of people with access to sensitive systems, and ensure that they are using a password manager and 2FA. Maintain separate personal and work devices, and install Mobile Device Management (MDM) and Endpoint Detection and Response (EDR) software on the work devices for security pre-hack, and visibility post-hack. Unfortunately, for large exchanges or other high-value targets, TraderTraitor defies expectations and norms even without the need for 0-days. As such, additional precautions must be taken to ensure that no single point of failure exists such that a single compromise can cause total loss of funds. However, even when all else fails, there may be hope still. The FBI has a unit dedicated to tracking and preventing DPRK intrusions, and has been conducting victim notifications for years now [^21], and recently I’ve had the pleasure of helping connect agents from that unit with potential DPRK targets. As such, to prepare for the worst, make sure you either have publicly available contact information, or that you’re connected with sufficient people within the ecosystem (such as SEAL 911) so that a message traversing the social graph will find its way to you with minimal delay. [^1]: https://www.usna.edu/CyberCenter/_files/documents/Operation-Blockbuster-Report.pdf [^2]: https://apps.dtic.mil/sti/pdfs/AD1046744.pdf [^3]: https://hbr.org/2015/07/they-burned-the-house-down [^4]: https://www.sony.com/en/SonyInfo/IR/library/presen/er/150204_sony.pdf [^5]: https://nsarchive.gwu.edu/news/cyber-vault/2019-02-20/tainted-trove [^6]: https://www.justice.gov/archives/opa/pr/north-korean-regime-backed-programmer-charged-conspiracy-conduct-multiple-cyber-attacks-and [^7]: https://www.cloudflare.com/learning/security/ransomware/wannacry-ransomware/ [^8]: https://www.cisa.gov/news-events/cybersecurity-advisories/aa21-048a [^9]: https://home.treasury.gov/news/press-releases/sm481 [^10]: https://unit42.paloaltonetworks.com/two-campaigns-by-north-korea-bad-actors-target-job-hunters/ [^11]: https://blog.phylum.io/north-korea-still-attacking-developers-via-npm/ [^12]: https://krebsonsecurity.com/2023/04/3cx-breach-was-a-double-supply-chain-compromise/ [^13]: https://cloud.google.com/blog/topics/threat-intelligence/3cx-software-supply-chain-compromise [^14]: https://medium.com/@RadiantCapital/radiant-capital-incident-update-e56d8c23829e [^15]: https://blogs.jpcert.or.jp/en/2019/07/spear-phishing-against-cryptocurrency-businesses.html [^16]: https://blog.casa.io/security-briefing-how-to-spot-a-phishing-email/ [^17]: https://www.fbi.gov/news/press-releases/fbi-identifies-cryptocurrency-funds-stolen-by-dprk [^18]: https://www.theblock.co/post/156038/how-a-fake-job-offer-took-down-the-worlds-most-popular-crypto-game [^19]: https://2021-2025.state.gov/office-of-the-spokesperson/releases/2025/01/joint-statement-on-cryptocurrency-thefts-by-the-democratic-peoples-republic-of-korea-and-public-private-collaboration [^20]: https://x.com/safe/status/1897663514975649938 [^21]: https://x.com/AlexMasmej/status/1731446788136292833 ## https://www.paradigm.xyz/writing/tradfi-tomorrow-defi-and-the-rise-of-extensible-finance # TradFi Tomorrow: DeFi and the Rise of Extensible Finance > Our survey of over 300 TradFi participants showed that a majority are excited about DeFi and want regulatory clarity for the space. We surveyed 300 TradFi professionals—spanning institutions, roles, and regions—and the verdict was near-unanimous: today’s financial system is bogged down by inefficiencies that stifle economic growth and drain resources. The stakes are high, and the cost of inaction is higher. Many see DeFi as a transformative fix—a way to cut the fat and unlock real value. Our survey report makes the case: DeFi isn’t just an alternative; it’s the future TradFi is set to embrace. And that starts with supporting policies that let it thrive. The full report can be accessed [here](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-e228995b7a/e69380b4d4d05793ccb0f1eeada93c74/asset-https-cdn-sanity-io-files-dgybcd83-p-e228995b7a.pdf). ## Finding 1: More than two-thirds of TradFi firms are currently looking at DeFi The current technology infrastructure and systems TradFi uses are labor intensive and require a significant amount of manual intervention. As a result, TradFi firms have been exploring the frontier. They are actively looking for ways to leverage technology to drive down costs, improve risk management, and streamline operational efficiency. Crypto is increasingly embedded in their strategies: - TradFi firms see DeFi as a solution to operational efficiency problems. - Almost nine out of every ten are actively investing in or researching ways to leverage the benefits of public blockchains. TradFi is embracing its own disruption because it knows how much there is to gain from moving to DeFi-powered infrastructure. ## Finding 2. TradFi firms think it’s inevitable that DeFi will eventually be critically important to most core businesses. The data show plainly that TradFi thinks DeFi will eventually be of critical importance to their core products and business lines. This is all downstream of TradFi’s belief that DeFi will bring about actual improvements to the financial system. We have come a long way from skeptics arguing DeFi will never be relevant outside of crypto. Now, TradFi believes DeFi is not only an inevitability but an opportunity. ## Finding 3. TradFi rejects the notion that private blockchains are as valuable as public, permissionless blockchains. Earlier last year we published [research](https://www.paradigm.xyz/2024/04/Cryptos-Biggest-Skeptics-are-EVM-pilled) showing that central banks were abandoning proprietary blockchains and increasingly looking toward open-source software and public networks. Now, our survey data shows that most of the TradFi community believes that public, permissionless blockchains are critical for leveraging the benefits of things like smart contracts and tokenization. It is critically important that such systems remain protected, and there needs to be strong incentives for developing and maintaining open, public infrastructure. ## Finding 4. Today, TradFi is most interested in stablecoins, tokenized assets, and DEXs. We see the most interest from TradFi in stablecoins, tokenized assets, and decentralized exchanges (DEXs), which correlates with increasing onchain volumes in those verticals. These three “pillars” are necessary to turbocharge markets, as we now have (1) a settlement asset, (2) a generalized way to represent other assets, and (3) extensible protocols that can be used composably to effect financial transactions onchain. In the next few years, we expect these charts to continue to go up and to the right. ## Finding 5. The biggest headwind preventing DeFi from unlocking real economic efficiencies in the short term is the regulatory environment. Policymakers have a generational opportunity to accelerate. TradFi understands both that DeFi is inevitable and that it represents an improvement over most of their current systems. In this way, they share the same basic view as much of crypto, which has fought to protect the open systems of DeFi so that this innovation is not chopped down before it reaches full flower. The primary obstacle to TradFi embracing crypto is not the need for more robust infrastructure or the absence of utility, but that many banking and market regulators are blocking TradFi firms, banks, exchanges, and funds, from accessing DeFi. The time for watchful patience has come to an end. We are now four years removed from DeFi summer and have experienced a host of market events globally and in crypto that have shown DeFi’s anti-fragility. It is time for regulators to begin to open the sluicegates that have separated TradFi from DeFi and start allowing TradFi firms to embrace the possibility of this innovative technology. ## https://www.paradigm.xyz/writing/stateless-reth-nodes # Ress: Scaling Ethereum with Stateless Reth Nodes > Ress is a Stateless Ethereum node implementation in <4K LoC using the Reth SDK. ## Intro We are excited to announce Ress (shorthand for: Reth Stateless), a fully validating stateless Ethereum Execution Layer with 14GB disk requirements. Stateless nodes matter not only for improving Ethereum’s decentralization, but also to scale the L1 gas limit, scaling optimistic L2s, and for [implementing Native Rollups](https://ethresear.ch/t/native-rollups-superpowers-from-l1-execution/21517) to improve the L2 ecosystem’s security & interoperability. Ress illustrates that we can run Ethereum nodes with 70x lower disk requirements today, without any hard forks needed. For our proof of concept, we successfully ran [Ress-backed Ethereum stakers](https://holesky.beaconcha.in/dashboard?validators=1919380,1919381,1919382,1919383,1919384,1919385,1919386,1919387,1919388,1919389#validators-table) on the Holesky testnet and correctly attested to block validity. We are excited for further protocol improvements which can make this work even more performant. Ress is built on Reth in <4K lines of code including tests, further demonstrating Reth’s flexibility as an SDK for bleeding-edge EVM-core infrastructure. ## What is stateless Ethereum? *Dankrad Feist wrote the *[*canonical explainer on this topic in 2021*](https://dankradfeist.de/ethereum/2021/02/14/why-stateless.html)*, which we recommend reading as a companion to this post.* “Stateless” means a node does not need to hold the entire state (i.e. account balances, and smart contract storage) to process a block. Instead of having to check its local database, a node receives the state accessed from other nodes, verifies that it matches the last block’s state commitment using merkle proofs (or other similar methods), and proceeds to execute all transactions in that block. This skips a lot of the internal details, but captures the essence of it. Statelessness is useful because it enables running nodes at lower cost, which should theoretically improve a network’s decentralization/censorship resistance. This process comes at a cost, trading off storage for bandwidth, because transmitting storage values & merkle proofs for each block can be expensive. However, in 2024 we observed that [state growth is unlikely to be a bottleneck](https://www.paradigm.xyz/2024/03/how-to-raise-the-gas-limit-1) for decentralization in the near-term, which made many node developers less excited about statelessness in the short-term. Maybe there is a fresh way to see things? ## Stateless nodes can help scale Ethereum. Traditionally, statelessness is described as a “defensive” feature, but we think there is also ways to utilize it for “offense”, in particular: 1. Scaling the L1 Gas Limit: The largest bottleneck in Ethereum node performance is the overhead that comes from calculating the state root per block, a process which requires random Disk I/O that gets more expensive the larger the state. Stateless nodes can do this process completely in-memory. 2. Scaling Optimistic L2s: Optimistic L2s require a network of verifiers to re-execute transactions at ~the same speed as the sequencer, to ensure that they can post a fault proof if the sequencer misbehaves. Stateless L2 nodes can help by only verifying a subset of the sequencer’s actions, effectively “sharding” an L2’s validation, enabling that L2 to go even faster, lowering its withdrawal period, without compromising the fault proof’s security. 3. Implementing Native Rollups: The fastest path to implementing [Native Rollups](https://ethresear.ch/t/native-rollups-superpowers-from-l1-execution/21517) (more secure/interoperable rollups that tightly integrate with Ethereum) involves re-execution of each rollup block on the L1 node. This can be prohibitively expensive both storage space wise and IO/memory-wise. Stateless re-execution fixes this. ## How does Ress work? Ress is Stateless Reth. It works today without any protocol changes. We demonstrated Ress being able to follow the tip of the chain & attest to its validity in Holesky, [with P99 validation time of <1 second per block.](https://holesky.beaconcha.in/validator/8d3814973e01b56870e57aa68a42cb53b16e50ecdbc6f49a977d4b2a9f491c0e273b1eef175b5832f301a6e12a8c1da8#attestations) Stateless nodes have been thought to be previously impractical in the past because of [the worst case size](https://hackmd.io/-7lIFKGERS6a9UUvOe30AA) of the “witness” (the merkle proofs required to verify the validity of accessed contract storage/accounts against the last block’s header). **We reduced the size of the witness to practical values by excluding contract bytecodes from the witness and assuming that the stateless node can store the contracts in its local database, which is about 10GB today for Ethereum mainnet, a value we think is acceptable.** Ress is built using Reth SDK in <4K lines of code, by reusing Reth’s P2P networking stack & via a “witnessed” EVM executor (similar to how zkEVMs work). We have implemented a [RLPx subprotocol dedicated to Ress](https://github.com/paradigmxyz/reth/tree/main/crates/ress/protocol), an optional extension for Reth stateful nodes to provide necessary state data (witness, block, bytecodes) to stateless Ethereum peers. ![Ress is powered by a custom RLPx P2P subprotocol enabling nodes to fetch all the information needed to statelessly validate a block.](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--502eb33454/92cfe1dccbd96060ab3d119274ab8669/asset-https-cdn-sanity-io-images-dgybcd83--502eb33454.png) *Ress is powered by a custom RLPx P2P subprotocol enabling nodes to fetch all the information needed to statelessly validate a block.* Ress downloads and **fully** verifies all blocks since the last finalized block. Block verification is done in 3 steps: Fetch state witness, fetch and persist any missing bytecodes, verify the payload & calculate the new state root in memory. Live sync works like any other stateful EL node - it is advanced via CL requests through the Engine API. ![Ress Sequence Diagram](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--f4e78018e2/a8be64938e4a2a433c91cc500e896c3a/asset-https-cdn-sanity-io-images-dgybcd83--f4e78018e2.png) *Ress queries stateful Reth peers for state witnesses and executes blocks without needing to hold the entire state locally.* We have tested Ress with [Hive](https://github.com/ethereum/hive/), and it passes most tests in the `ethereum/engine` test suite. The testing has been done using the [ress hive adapter](https://github.com/ithacaxyz/reth-stateless/tree/main/bin/adapter) which sets up a stateful reth and a stateless ress node and proxies Engine API requests to both. Only the stateful reth node is used for the block building. ## Native Support In Reth Reth now [supports](https://github.com/paradigmxyz/reth/commit/c0e848a29bd3a37ffe5c6ab8a65b0d7ef09f8b3d) `ress` RLPx subprotocol natively as of `v1.3.1`. You can enable it by passing `--ress.enable` argument. We've hosted several public nodes that you can peer with if you don't have an ability to run a Reth node yourself by adding them as peers manually. Find more in the [README](https://github.com/paradigmxyz/ress?tab=readme-ov-file#run). ## What is the future of Ress? We release the Ress Proof of Concept today to share our research progress on reducing L1 node requirements and scaling L1s & L2s. We look forward to collaborating with the community to push the boundaries of what’s possible for execution clients. Make sure to star the [Ress repository on Github](https://github.com/ithacaxyz/reth-stateless/)! If you’re interested in stateless nodes, working on Reth, or any of our other Rust open source tooling, reach out to [georgios@paradigm.xyz](mailto:georgios@paradigm.xyz). See you in the issue tracker! ## Acknowledgments Huge thanks to [piapark](https://x.com/0xpiapark) for getting the project off the ground, [joshie](https://x.com/joshie_sh) for implementing hive adapter and [storm](https://x.com/notnotstorm) for gathering the bytecode data. ## https://www.paradigm.xyz/writing/paradigm-policy-anchors # Paradigm Policy Anchors > Paradigm’s Policy Anchors guide how we engage on policy matters globally on behalf of our portfolio companies and all of crypto. These Anchors guide our engagement on most matters relating to public policy and regulatory affairs. They are designed to be general enough to apply to a wide range of policy issues while also giving us a set of guardrails that keep us aligned with what’s best for crypto in the long term. We expect to update them periodically based on feedback from the community and from our experiences working with policymakers around the world. *Good crypto policy…* **Supports crypto’s core value proposition of openness and neutrality.** - Crypto’s fundamental value proposition is its universal accessibility and censorship resistance. - Crypto policy should recognize and enable these features, including by allowing for the validation process and operation of protocols on public blockchains to remain neutral and unencumbered. **Does not preclude crypto applications that have not yet been invented.** - Crypto is an ever-evolving space where most of the “killer” applications haven't yet been invented. - To avoid stifling future innovation, we should *always* ask how a given policy will impact crypto beyond its advertised or intended target and avoid policies that are prematurely specific. **Focuses on prosecuting illegal activities and mitigating systemic risk, not restricting general purpose technology.** - Actors responsible for fraud, scams, and other illegal activities should be punished following due process of law. - However, regulation should not prohibit general-purpose technology that has many lawful uses. - Instead of relying on registration or other *ex ante* tools, regulation should rely on *ex post* enforcement of fraudulent activity. **Recognizes there are different layers of the crypto stack — and different segments within each layer.** - It is imperative that crypto’s base layer remains credibly neutral, even if some crypto apps and services (particularly centralized, custodial ones) have more onerous regulatory obligations. - Within a given layer, one-size-fits-all approaches are often a nonstarter. For example, how policies treat wallets should differ depending on whether the wallets are self-hosted or custodial. **Focuses on the specific activities in question.** - Crypto policy should not be over-indexed to one specific use case or type of service. **Carefully consider regulatory tradeoffs.** - Pulling crypto into the regulatory perimeter *could* increase mainstream adoption by providing regulatory/legal clarity for builders and entrepreneurs. - However, regulation can also hamper innovation by creating additional costs for businesses and by arbitrarily limiting the scope of “approved” activities. - The timing and substance of regulation should be weighed against its impact on crypto adoption, and ensure it does not hinder crypto’s core value proposition. **Allows entrants to compete with incumbents on a level playing field.** - Policies should be fair and should not be overly accommodating to incumbent companies (crypto or “traditional”) at the expense of new entrants. - Competition and evolution are virtues, and we should be wary of anything that further entrenches the status quo. **Does not disadvantage any crypto ecosystem relative to others.** - Whether Bitcoin, Ethereum, or Solana, crypto innovation is not limited to any one ecosystem, and any regulatory framework must ensure maximum developer creative freedom across networks. *Liability and responsibility* **Developing neutral technology should not be a crime, even if neutral technology is later used for illicit purposes.** - Developers of general-purpose technology should not be liable for specific illegal uses or implementations of that technology by third parties. **Crypto provides for trustless structures that can obviate some traditional notions of liability and responsibility, but create others.** - Traditional notions of liability such as fiduciary duties that arise in the context of agency and custodial relationships are obviated by decentralized systems. - However, crypto can create other areas of risk and liability, including smart contract risk, governance / collusion attacks, etc. **Crypto policy should respect privacy rights by default.** - Privacy is a fundamental human right that should be protected by crypto policy and technology. - Privacy protections can coexist with national security goals. *How Paradigm Policy operates* **We focus solely on what is best for crypto; we do not compromise, pick favorites or have a partisan agenda.** - We are guided by our dedication to doing what is best for crypto: we support policies that fully align with our principles and do not compromise. - We believe we can be more impactful if we use our influence sparingly on only the most important policy battles. - We believe that anyone can be a champion of crypto, regardless of political party or affiliation. **We help achieve better policy outcomes by leveraging our deep crypto nativity.** - Good crypto policy will require a technical understanding of the technology, a firm grasp of the sociocultural dynamics of the crypto ecosystem, and deep integration in the crypto community. **We don’t support legislation that represents any compromise of first principles.** - We only support crypto legislation in the event that doing so is widely viewed, internally and externally, as necessary to maintain or accelerate open crypto’s progress. We will not, however, compromise on crypto’s core ethos in doing this. Legislation that compromises open crypto we will oppose. **We are committed to collaboration and community engagement.** - There are numerous stakeholders in crypto that have a variety of worldviews and perspectives. We will do our best to incorporate the community’s views in trying to understand what will best support crypto in the long term. - In engaging with other stakeholders, we will assume good faith as a default and always punch up. ## https://www.paradigm.xyz/writing/anchors-council-additions # Introducing Paradigm’s Policy Anchors and New Policy Council Additions > Paradigm Policy releases its Policy Anchors, and adds six new members to its Policy Council. Crypto is on a path to powering one of the most important global economic and financial shifts of this century. For the first time ever, crypto voters played a key role in the last election, and their message was unambiguous: crypto is here for good. ## Paradigm Policy Anchors Following President Trump’s [Executive Order on Crypto](https://www.whitehouse.gov/presidential-actions/2025/01/strengthening-american-leadership-in-digital-financial-technology/), and as the new Congress begins work on crypto legislation, we thought it would be a good time to share the [Policy Anchors](https://www.paradigm.xyz/2025/02/paradigm-policy-anchors) that have guided our firm’s advocacy over the past several years. We believe that the heart of crypto is its openness and neutrality – its ability to provide universal access and resist censorship. Our Policy Anchors emphasize the importance of protecting these attributes, ensuring that public blockchains remain neutral and unencumbered. Regulatory objectives, such as countering fraud or systemic risk, can be addressed in ways that still foster innovation and accessibility for all. Crypto is also an inherently forward-looking technology. While it’s already made an immeasurable impact on the financial system in the U.S. and globally, many of its most impactful applications have yet to be invented or even conceived. Premature or overly restrictive regulations risk stifling the creative potential of this space, cutting off possibilities before they even emerge. We cannot hobble this revolutionary technology as it takes its first steps. Guided by our Policy Anchors, Paradigm advocates for policies that balance regulatory clarity with flexibility, enabling mainstream adoption while leaving room for experimentation and long-term innovation. ## Paradigm Policy Council We are also taking this opportunity to add six new leaders and thinkers to our Policy Council, a group with deep expertise across a range of key issues. We are fortunate to have their expertise as we work to help put the misguided era of anti-crypto policy firmly in the rearview mirror. ### Ambassador Robert C. O’Brien *27th U.S. National Security Advisor* Robert C. O’Brien is the co-founder and Chairman of American Global Strategies, a geopolitical advisory firm. He currently sits on the President’s Intelligence Advisory Board (PIAB). Ambassador O’Brien was the National Security Advisor to President Donald J. Trump from 2019 - 2021, where he served as the President’s principal advisor on foreign policy and national security affairs. Prior to serving as NSA, O’Brien was the Special Presidential Envoy for Hostage Affairs. O’Brien has had a distinguished career in public service in national security and foreign policy, and a notable career in private law. O’Brien is partner emeritus at Larson LLP in Los Angeles, a nationally recognized litigation boutique that he co-founded in 2016. Image from URL ### Johnny DeStefano *Former Counselor to President Donald J. Trump and Director of Presidential Personnel; Principal, Utility Strategic Advisors* Johnny DeStefano is a highly-respected Republican operative, whose experience serving in senior positions in both Congress and the White House gives him a unique perspective into today's political landscape. DeStefano most recently served in the Trump Administration, first as Assistant to the President and Director of Presidential Personnel (PPO), and later as an Assistant to the President and Counselor to the President. As Counselor to the President, DeStefano oversaw the Offices of Intergovernmental Affairs, Public Liaison, and Political Affairs, in addition to PPO. Prior to the White House, DeStefano was the President and CEO of Data Trust, the national Republican voter database and technology platform, and served as Senior Advisor for Speaker of the House John Boehner (R-OH). Image from URL ### Alexander B. Gray *Chief Executive Officer of American Global Strategies; former Deputy Assistant Secretary to President Donald J. Trump and Chief of Staff of the National Security Council* Alexander B. Gray is the Chief Executive Officer of American Global Strategies, a national security and international affairs strategic advisory firm. Gray served as Deputy Assistant to the President and Chief of Staff of the National Security Council during the first Trump Administration, as well as Special Assistant to the President for the Defense Industrial Base at the National Economic Council. Gray was a member of the 2016 Presidential Transition Team at the US Department of State, and a Senior Advisor to former US Congressman Randy Forbes (R-VA). Image from URL ### Jen Brown *Vice President, BGR Group; Former Banking Counsel to Senate Minority Leader Chuck Schumer* Jen Brown serves as Vice President at political advisory firm BGR Group. She previously served as Banking Counsel to Senate Majority Leader Chuck Schumer (D-NY), where she advised the Majority Leader on all matters of financial policy, and represented him in negotiations between House and Senate Leadership and the White House on all financial legislation. Previously, Brown served as Tax and Economic Policy Counsel to senior Members of the Senate Finance Committee and House Financial Services Committee. Prior to Capitol Hill, Brown led financial policy at UnidosUS, the nation’s largest Hispanic rights and civic advocacy organization. ### Van Jones *CNN Host, Founder of DreamMachine.org and Author of the Van Jones Substack* Van Jones is a U.S. media personality, entrepreneur and world-class changemaker who has a rare track record of bringing people together to do hard things – in areas as diverse as clean energy solutions, criminal justice reform and racial inclusion in the tech sector. In 2007, Van was the primary champion of the Green Jobs Act, signed into law by President George W. Bush, and in 2009, he worked in the Obama White House as the Special Advisor for Green Jobs. In 2018, he helped pass the FIRST STEP Act, signed into law by President Donald J. Trump, which the New York Times calls the most substantial breakthrough in criminal justice in a generation. In 2021, Jones was the first recipient of Jeff Bezos' Courage & Civility Award and has since founded Dream Machine Innovation Lab and launched RAPPORT.co, which uses A.I. to increase firms' EQ. A Yale Law School graduate, Van is a CNN host and an Emmy Award-winning producer. He is also a 3X New York Times best-selling author and the creator of the Van Jones Substack. ### Kyle Layman *President of Oasis Strategies; Former Senior Advisor to the Democratic Congressional Campaign Committee* Kyle Layman is president of Oasis Strategies, a California-based political advisory firm, where he advises Democratic Members of Congress, candidates, and political efforts. Previously, he served as Senior Advisor to the Democratic Congressional Campaign Committee. During the 2024 political cycle, Kyle served as Executive Director of a Super PAC supporting Rep. Adam Schiff’s Senate candidacy, and a Super PAC aligned with the New Democrat Coalition. ## Conclusion Crypto represents a unique opportunity to build systems aligned with self-sovereignty, privacy, and economic freedom – values that resonate deeply with our country’s democratic ideals. By prioritizing openness, we can ensure this transformative technology thrives in a way that benefits everyone. Crypto in the United States is at a key inflection point, and getting policy right over the coming months will set the foundation for extraordinary technological and economic growth in the decades to come. Paradigm Policy is proud to work alongside founders, industry partners, and federal policymakers from both parties in charting a path to a prosperous, abundant future. Let’s get to work. ## https://www.paradigm.xyz/writing/what-comes-after-ethereums-pectra-hard-fork # What comes after Ethereum’s Pectra hard fork? > The Reth team’s view on what should happen in Fusaka, Ethereum’s next hard fork after Pectra. *The views below represent the Reth team's current view, and not necessarily the broader Paradigm team.* **We think it is necessary for Ethereum to ship Fusaka in Q3 2025 and focus its scope on scaling L2s. We also ask every EL team to promptly publish their official view on what should go in Fusaka.** Dos: - PeerDAS & increase blobs to [at least 12](https://hackmd.io/@jimmygchen/H1EskpDRA?utm_source=preview-mode&utm_medium=rec) (if not [higher](https://x.com/fradamt/status/1880389727041515981)), to enable L2s to scale [2x from Pectra](https://blog.sigmaprime.io/peerdas-distributed-blob-building.html). This must be the top priority for this upgrade, alongside any EL changes needed to support that (e.g. on the[ transaction pool](https://hackmd.io/@fradamt/mempool-change)). - EOF, to make the EVM faster, easier to use and future proof. It is a desired EVM upgrade that is already implemented, tested, and integrated in clients and tooling. There are also multi-client EOF devnets running stable. - [EIP7883](https://eips.ethereum.org/EIPS/eip-7883) aka ModExp repricing is important to avoid DoS on the L1 (we also think high throughput L2s should implement this). - RIP7212 to make Ethereum easier to use by making verification of secure enclave signatures cheaper. It is already widely deployed on L2s and other L1s. Dont’s: - Large “system-wide” changes which are disconnected from the current L1 competitive landscape like ePBS, FOCIL, or statelessness. We still think these matter for the long term success of Ethereum, but not for Fusaka. - EVMMAX/SIMD doesn’t make sense to us ROI-wise, as we believe that we get most of the UX benefits of new curves already post-RIP7212. - Ossifying the EVM doesn’t make sense to us, we believe the EVM should continue evolving. We like the idea of exploring native account abstraction with EOF but we don’t love the EIP7701/7560 designs as we dislike their proximity to ERC4337 as a suboptimal account abstraction standard. - RISC-V as an alternative VM. We like RISC-V and are experimenting with it as an alternative VM via the [R55 project](https://github.com/r55-eth/r55). We don’t think the time is right yet. We think Ethereum Core Development should aspire to 1-2x hardforks/yr in the current competitive landscape. For that, we should decouple shipping, scoping & research: - Core Dev teams should be able to ship Pectra AND simultaneously decide on the Fusaka scope. - Ethereum research teams should be able to surface ideas to be added in Amsterdam (the hard fork after Fusaka) scope and not rush inclusion of ideas in Fusaka. We are open to a CL-only hardfork if that means we’d ship Fusaka in Q3 2025, but we would consider that a failure of the EL teams and have an open-minded conversation about what should the shipping bar be for a client team. Post-Fusaka, we think the research and engineering focus should continue being scale. Here are some ideas which we think are interesting that research could help with: - Further help scale L2s by upping the blob count via [blob-parameter-only](https://x.com/sammcingvale/status/1882143514714345778) hard-forks. - Scale the L1 by bumping the gas limit post EIP-4444, gas repricing & block-level warming. ## https://www.paradigm.xyz/writing/announcing-foundry-v1-0 # Announcing: Foundry v1.0 > Foundry, the leading smart contract development framework, releases v1.0. ## **Why release Foundry v1.0?** When we first announced Foundry in December 2021, we set out to create the most flexible & fastest EVM development toolkit. Over the past three years, Foundry has evolved to the go-to developer tool for smart contract developers used by anyone from independent builders to teams at leading protocols. Today, we're proud to announce Foundry v1.0, marking a major milestone in our journey to provide the most stable and performant toolkit for EVM development. We believe that in order to accelerate Ethereum, we need to provide developers with the best tooling to code, test and ship faster. This is only possible thanks to our strong open source community driving improvements through feedback and contributions. Read on to learn what’s new in [Foundry v1.0](https://github.com/foundry-rs/foundry/releases/tag/v1.0.0) and what comes next. ## **What's New in Foundry v1.0?** 1. Faster code compilation: We ran our benchmarks with leading Solidity libraries. The v1.0 release includes significantly faster compilation up to 5.2x faster than alternative tools on the market, and >2x better than Foundry v0.2. 2. Faster and deeper test coverage: Foundry v1.0 is 2x faster compared to foundry v0.2. Our benchmarks show improvements of up to **40% faster** execution time for fuzzing and coverage tests. 3. Better UX for Testing & Debugging: `forge test` comes with new flags to enhance your testing experience e.g. by enabling re-runs upon failure, improved UX of tracking test progression and invariant testing metrics. Foundry v1.0 offers better debugging capabilities with internal call tracing and state visualization, letting you debug every detail of a transaction. 4. New Cheatcodes: We’ve included new exciting cheatcodes for gas snapshots, testing & deployment and seamless integration with symbolic execution tools. 5. Support for Pectra & Fusaka: We’ve added support for future EVM related EIPs to give developers the ability to start prototyping and work on projects that rely on these new features. 6. More Stability & Reliability: We have stabilized APIs for long-term reliability, pointing `foundryup` to `stable` releases by default. The result is a mature, performant toolkit that sets a new standard for EVM development. We’ve built a strong and every-growing community of EVM builders. With 8.6k stars, 466 individual contributors and 4939 Pull Requests, Foundry is here to stay for the long term. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--a5c0ef6404/d3e02eade8bd703511a8148406ea72c3/asset-https-cdn-sanity-io-images-dgybcd83--a5c0ef6404.png) ## **Better Performance** Fast code compilation and fast running test suits translate into short feedback cycles and allows developers and teams to ship products faster. ### **Faster Code Compilation with forge build** We performed benchmarks on the leading Solidity libraries to measure the time it takes to compile all contracts in each library. Our benchmarks show that Forge compilation is consistently faster than Hardhat by a factor of 2.1x to 5.2x, depending on the amount of caching involved. ![Source: https://github.com/foundry-rs/foundry?tab=readme-ov-file#compilation-benchmarks](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--3dc9694d30/f69defb10b0cd1c663e8a327a2cde2ae/asset-https-cdn-sanity-io-images-dgybcd83--3dc9694d30.png) *Source: https://github.com/foundry-rs/foundry?tab=readme-ov-file#compilation-benchmarks* ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--744d97cb9f/4c2d2bbf36d48dbe87d90c3e0c228dfd/asset-https-cdn-sanity-io-images-dgybcd83--744d97cb9f.png) ### **Better testing performance with forge test** Faster tests means faster feedback cycles for developers. Our testing performance has seen a **2x improvement for invariant tests and unit/fuzz** **tests** compared to [v0.2](http://v0.2.0.in/). The following section on invariant tests will dive deeper into how we managed to significantly increase performance on invariant tests with v1.0. We ran benchmarks with leading smart contract repositories to measure how long it takes to run test suites, including unit tests, fuzz tests, invariant tests and integration tests. The cached integration test also shows how effective Foundry is at repeated runs of forked tests ran at the same block height due to RPC caching. ![Benchmarks were run using v1.0 vs v0.2 (nightly-de33b6af53005037b463318d2628b5cfcaf39916)](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--db862aef5e/0660f4b0dd7125fc2fb502cbd9a798a8/asset-https-cdn-sanity-io-images-dgybcd83--db862aef5e.png) *Benchmarks were run using v1.0 vs v0.2 (nightly-de33b6af53005037b463318d2628b5cfcaf39916)* ### **Better performance for Fuzzing and Coverage** Fuzzing and tracking your code coverage are both crucial for smart contract security. Fuzzing helps developers discover edge cases by randomly generated test inputs. Running these tests can be computationally expensive, therefore Foundry v1.0 offers improved performance to ensure you can run your fuzz tests fast and seamlessly. With the v1.0 release, Foundry is up to **40% faster** execution time for fuzzing and code coverage. This enables developers to run more test cases in the CI without increasing cost, achieving a faster feedback loop during collaborative development. ![Source: https://x.com/gakonst/status/1864060511253680180](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--48296f1393/55cf279234240c7b720bdbcf9aa58911/asset-https-cdn-sanity-io-images-dgybcd83--48296f1393.png) *Source: https://x.com/gakonst/status/1864060511253680180* To keep your smart contracts secure during fast-paced development, it is important to keep track which part of your codebase is covered by tests. With Foundry v1.0, `forge coverage` helps you verify and track your code coverage up 3.5x faster. A comparison of v1.0 and v0.2 execution times for code coverage can be seen in benchmarks below: ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--6de30c6fe3/90fc3effd9a1c7db0a774ea080640cbe/asset-https-cdn-sanity-io-images-dgybcd83--6de30c6fe3.png) ### **Better Performance for Invariant Testing** [Invariant testing](https://book.getfoundry.sh/forge/invariant-testing) ensures that critical assumptions of your system hold true across different states, it’s an important tool to help developers uncover logical bugs in their contracts. When invariant tests fail, often the output are complex failure cases with several steps. Shrinking is the process of reducing the original counterexample while still preserving the failure. In the v1.0 release, the shrinking algorithm was rewritten with significantly better performance than in the previous implementation. Benchmarks [from the community](https://github.com/devdacian/solidity-fuzzing-comparison) demonstrate Foundry v1.0’s significant performance improvements compared to v0.2 and Echidna, with **speed increases of up to 1000x**. Echidna still performs better in more complex test scenarios like Unstoppable, primarily due to its coverage-guided fuzzing capabilities. To address this, coverage-guided fuzzing has been added to the Foundry roadmap for this year, in order to further improve performance on invariant testing. While speed matters, what matters more is to be able to find the breaking sequence, with foundry v1.0 we’re successfully finding failing cases that v0.2 missed (such as in Unstoppable). ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--310315af14/d745311998539a5437a1c92e9584281b/asset-https-cdn-sanity-io-images-dgybcd83--310315af14.png) ## **Better Testing & Debugging UX** ### **Improved tracing** By passing the `--decode-internal` flag when debugging transactions with `cast run` or running `forge test` you can debug decoded internal calls, see state changes and track decoded event emissions to help you debug transactions more granularly. ![Example of a Uniswap V4 swap. Source: https://github.com/foundry-rs/foundry/pull/8222](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--824cc09194/e854f59fc5a27f40266503fe4722084a/asset-https-cdn-sanity-io-images-dgybcd83--824cc09194.png) *Example of a Uniswap V4 swap. Source: https://github.com/foundry-rs/foundry/pull/8222* Another useful tool in our toolbox is to run `forge test` combined with `--flamechart` or `--flamegraph` options, which visualizes expensive operations, deep call stacks and potential optimization targets. Flamecharts helps visualize the gas usage over time, when each function is called (execution order) and how much gas it consumes at each step in the timeline. ![Source: https://x.com/zerosnacks/status/1837142546436202968](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--495eda3f70/c60f8f99aedec4b38e8bee568bfb4a82/asset-https-cdn-sanity-io-images-dgybcd83--495eda3f70.png) *Source: https://x.com/zerosnacks/status/1837142546436202968* Foundry v1.0’s improved tracing includes fully decoded calldata and return values for calls to external libraries, calls to fallback functions, state diffs for storage slots, balance changes, code modifications, and event emissions, giving you more visibility into your contract's execution path and interaction with dependencies. Below you can see an example of Foundry stack trace with storage changes, where counter (storage slot `0`) is changed twice, first time by explicitly setting to `9` and then incrementing to `10`. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--b7b1acc87b/d321b6eafc71e6cc9408d4d62f9dbfc5/asset-https-cdn-sanity-io-images-dgybcd83--b7b1acc87b.png) ### **Replaying of failed tests** Foundry now automatically saves the execution context and allows you to replay any failed test deterministically. This means you can quickly reproduce and debug any test failure and fix your tests faster. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--9653ec6eb5/f80ce098e68dd13718e5542acf24be14/asset-https-cdn-sanity-io-images-dgybcd83--9653ec6eb5.png) ### **Advanced Test Reporting and real-time metrics** Foundry v1.0 hugely improves the developer experience for large smart contract codebases by providing real-time testing execution progress with `forge test --show-progress` : *Embed* ### **Invariant Testing Metrics** For effective invariant testing, developers require metrics to gain more insights into what is actually being tested. With v1.0, we introduced detailed metrics to give you confidence in your test coverage by [enabling invariant metrics](https://book.getfoundry.sh/reference/config/testing#invariant) in your `foundry.toml` to get full visibility on the successful calls, revert rates, and discarded calls. ![Source: https://x.com/lucasmanuel_eth/status/1854630498636878130](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--84b743293c/994280be70406503aec459cdac20a8d8/asset-https-cdn-sanity-io-images-dgybcd83--84b743293c.png) *Source: https://x.com/lucasmanuel_eth/status/1854630498636878130* ## **New Cheatcodes** Most of the time, simply testing your smart contracts outputs isn’t enough. Cheatcodes let you manipulate the state of the blockchain, as well as test for specific reverts and events. ### **Gas Snapshots** Gas optimization is critical for smart contract development. Our new gas snapshot cheatcodes let you measure gas usage with pinpoint accuracy, helping you identify and optimize your contract's hotspots. Gas snapshots are written to a `snapshots` directory to be checked into `.git`, allowing you to measure and evaluate the impact of your gas golfing over time. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--873077748a/239c7e06470a81fac1f5c957021b235c/asset-https-cdn-sanity-io-images-dgybcd83--873077748a.png) ### **Improved test revert handling** Sometimes the fuzzer can uncover real, but anticipated errors in the contract under testing, especially when tests are performed against stateful forks. The `assumeNoRevert` cheatcode allows to discard the current run and start a new fuzz run if the next call reverts. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--a0d1a8d48a/5c174ee6f018ad7d943204fd0e62ee4b/asset-https-cdn-sanity-io-images-dgybcd83--a0d1a8d48a.png) Foundry v1.0 enhances `expectRevert` test utility to allow checking the number of reverts expected from the upcoming calls and also to ensure a revert does not happen (expecting 0 reverts). ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--956c29b504/b2bc48d4a6c9fd96a95f3babf7bf05f0/asset-https-cdn-sanity-io-images-dgybcd83--956c29b504.png) ### **Wallet utilities** Some use cases, such as multi-chain deployments, may require advanced wallet management. Foundry v1.0 provides `rememberKeys` cheatcodes to derive and save multiple wallets in the script environment, while `getWallets` returns an array of addresses whose private keys are available in scripts: ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--02c7bcfa7d/b2edb0a3b928ad8f4553e14bd10f2a3e/asset-https-cdn-sanity-io-images-dgybcd83--02c7bcfa7d.png) ### **Code deployment** Foundry v1.0 unlocks the possibility to deploy a contract through cheatcodes by fetching the contract bytecode from the artifacts directory. This can be done with the newly introduced `deployCode` cheatcode, which can be called with the contract name or path to contract artifact. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--d0a2beafcb/199111eda54f76079bf190b4c2fb3dbf/asset-https-cdn-sanity-io-images-dgybcd83--d0a2beafcb.png) ### **Deployments and broadcasted artifacts** Foundry v1.0 comes with `getBroadcast` cheatcodes that allow accessing deployed addresses and details of prior broadcasted transactions. For example, after deploying a `Counter` contract, the transaction hash and the address of the newly created contract can be fetched easily: ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--bd95bff233/76282976788300389681f36bbe39858b/asset-https-cdn-sanity-io-images-dgybcd83--bd95bff233.png) Additionally, two new cheatcodes `getArtifactPathByCode` and`getArtifactPathByDeployedCode` help you to programmatically find artifacts that corresponds to each contract deployment: ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--92c49b5ed3/837ca4745a0893e5900e83c7e136de95/asset-https-cdn-sanity-io-images-dgybcd83--92c49b5ed3.png) ### **State diffs** For efficient testing and debugging, we developed cheatcodes for visualising the side effects of a transaction. This is done by recording state transitions using `startStateDiffRecording` and then using `getStateDiff` and `getStateDiffJson` cheatcodes to fetch the diff of the chain state from before and after transaction execution, see an example below. ![Note: in upcoming versions the output of state diffs cheatcodes will be improved to show decoded values.](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--bf70b942a3/709531eeb1fbb4563c01f31cd4ae6d67/asset-https-cdn-sanity-io-images-dgybcd83--bf70b942a3.png) *Note: in upcoming versions the output of state diffs cheatcodes will be improved to show decoded values.* ### **Symbolic execution** Symbolic execution is a powerful technique that helps find edge cases by treating input variables as mathematical expressions to explore all possible execution paths. This can help identify subtle bugs like integer overflows, reentrancy vulnerabilities, and complex mathematical edge cases without having to explicitly write test cases for each scenario. While it’s not built into Foundry v1.0, we made it easy to plug into your favourite symbolic execution tools, such as [Kontrol](https://docs.runtimeverification.com/kontrol) or [Halmos](https://github.com/a16z/halmos). Below is an example of what that looks like, using Kontrol to verify an OpenZeppelin ERC20's mint function behaves correctly for any address and any balance: ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--eb5a44b4f3/470564f8f60f1883daeb05716ad7770e/asset-https-cdn-sanity-io-images-dgybcd83--eb5a44b4f3.png) Take a look at [Cheatcodes Reference](https://book.getfoundry.sh/cheatcodes/) in the Foundry book to explore all our cheatcodes and documentation. ## Pectra The Ethereum Pectra hardfork is scheduled for March or April 2025 and will come with exciting features for the EVM such as enabling account abstraction (EIP-7702). ### **EIP-7702: Set EOA Account Code** [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702) unlocks features such as gas sponsorship, but also other use cases such as transaction bundling or granting limited permissions to a sub-key. This EIP introduces a new transaction type, allowing an Externally Owned Account (EOA) to function like a smart contract. `Forge` has supported EIP-7702 since October 2024 in order to enable developers to start prototyping with new features before they are available on the L1. To get started, just set `evm_version="prague"` in `foundry.toml` or pass `--evm-version prague` as an argument. With `cast`, a user can [sign an authorization](https://book.getfoundry.sh/reference/cli/cast/wallet/sign-auth?highlight=--auth#cast-wallet-sign-auth) that will delegate all calls to their address to the bytecode of smart contract: ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--fd07652214/81a7ff90bd0ba8aaf75c563d1d2a3e0d/asset-https-cdn-sanity-io-images-dgybcd83--fd07652214.png) With `cast send --auth` you can send the signed authorization (or have it sent by another party which e.g. subsides gas). For more information check out the [Odyssey examples](https://github.com/ithacaxyz/odyssey-examples/tree/main/chapter1/simple-7702) for EIP-7702. ### **Testing 7702** To run an EIP-7702 compatible node instance, the `prague` hardfork can be used when starting Anvil: `anvil --hardfork prague` Foundry v1.0 comes with a set of cheatcodes that can be used to sign EIP-7702 authorizations and delegate calls as EIP-7702 transactions: `signDelegation` for generating a signed authorization,`attachDelegation` for designating the next transaction as an EIP-7702 delegation and `signAndAttachDelegation` that combines both signing and attaching into a single step, simplifying the delegation process. ![Source: https://book.getfoundry.sh/cheatcodes/sign-delegation](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--32df3caf55/52d454a8f243eb2752379f37cf76edab/asset-https-cdn-sanity-io-images-dgybcd83--32df3caf55.png) *Source: https://book.getfoundry.sh/cheatcodes/sign-delegation* ### **RIP-7212: Precompile for secp256r1 Curve Support** EIP-7212 introduces a precompile for the **secp256r1** elliptic curve, a curve that is widely used in protocols like [Apple Secure Enclave](https://support.apple.com/en-au/guide/security/sec59b0b31ff/web) and [WebAuthn](https://webauthn.io/) and essentially unlocks the ability to sign a transaction with your passkey. Foundry v1.0 comes with a cheatcode `signP256` which lets you easily sign a digest with a secp256r1 private key. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--e3a423b6df/a0f9fc5a6efb2025cf0c7b6970324469/asset-https-cdn-sanity-io-images-dgybcd83--e3a423b6df.png) ## Fusaka The Ethereum hardfork following Pectra is named Fusaka and will include a new series of EIPs known as [EOF](https://eips.ethereum.org/EIPS/eip-7692). The exact schedule is yet to be defined, however Foundry already gives developers the ability to try it out. ### **EOF (Ethereum Object Format)** EOF aims to improve efficiency and security of smart contract deployment and execution. It introduces a new container format for smart contracts on the Ethereum blockchain. To compile contracts with EOF, you can simply pass the `--eof` flag. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--26c575ade3/1601a8939dbbc4c213073e29cf2df423/asset-https-cdn-sanity-io-images-dgybcd83--26c575ade3.png) Same `--eof flag` can be used for deploying the contract. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--71b26260e6/b422819aa33a650261e6548a579e663e/asset-https-cdn-sanity-io-images-dgybcd83--71b26260e6.png) To decode and inspect EOF container bytes, Foundry v1.0 comes with cast [decode-eof ](https://book.getfoundry.sh/reference/cli/cast/decode-eof)option. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--fd2eaf4899/45b3119064285c66d8270428a3272f1b/asset-https-cdn-sanity-io-images-dgybcd83--fd2eaf4899.png) The screenshot below shows how the command returns the decoded response highlighting header and code sections to help understand how the contract bytecode is organized under the new format. For a deeper dive into EOF, checkout our [EOF example](https://github.com/ithacaxyz/odyssey-examples/tree/main/chapter1/eof). ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--0c505ff318/bf252aa1ac556b0d7fa68e5fa2fc56d3/asset-https-cdn-sanity-io-images-dgybcd83--0c505ff318.png) ## **Stability & Reliability** With v1.0 we want to make Foundry's transition to a stable API with concrete guarantees for the community with regards to regular release cadence, clear timeline and migration paths and a versioned API. Our release process is structured as follows: - `master` contains nightly builds and new feature developments - `release` branches off for specific release candidates before a new stable release - `stable` accommodates stable version releases which are made available via `foundryup` ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--d005b622fb/400010ca712e248db0df3b1f0c994827/asset-https-cdn-sanity-io-images-dgybcd83--d005b622fb.png) Before any `release` we will make the version available as [release candidate ](https://github.com/foundry-rs/foundry/releases/tag/rc)and give the community the chance to test and share feedback with us. All our releases are [attested & verified](https://book.getfoundry.sh/getting-started/installation?highlight=attes#verify-integrity-and-provenance-of-binaries) using Github artifact attestations for you to verify integrity of our binaries. ## **How to Migrate to v1.0?** Migrating to v1.0 is easy with our [migration guide](https://book.getfoundry.sh/guides/v1.0-migration). ## **What’s Next?** While v1.0 represents a stable and mature toolkit, our vision for Foundry continues to evolve. We are particularly excited about the following features on our roadmap: - We will boost performance of our local development node `anvil` into `reth-anvil` , by making use of Reth and bringing even more powerful local development capabilities with reth performance and features out-of-the-box. - We will ship continued performance optimizations by [integrating Solar](https://www.paradigm.xyz/2024/11/solar)- our fast, modular and contributor friendly Solidity compiler. - We will ship performance improvements on testing including improved fuzzing parallelism. - We will add new fuzzing and testing features like coverage guided fuzzing, symbolic testing out of the box and mutation testing. - Increased modularity and flexibility through integrating the latest version of `revm`. ## Try out Foundry v1.0 today Just run the command to install `foundryup` : ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--4132dbef6b/75b40df04bafa2b623e3c6ed795b8b99/asset-https-cdn-sanity-io-images-dgybcd83--4132dbef6b.png) **We’re hiring for the Foundry team. Reach out with your Github and resume to **[**georgios@paradigm.xyz**](mailto:georgios@paradigm.xyz)**.** ## **Acknowledgements** Foundry v1.0 would not be possible without our vibrant community of contributors and thousands of developers use Foundry daily, providing valuable feedback and pushing the boundaries of Ethereum development. ## https://www.paradigm.xyz/writing/debanking-hearings # What You Should Know Before Watching the Congressional Debanking Hearings > A primer on the debanking of crypto companies and entrepreneurs in advance of the February 2025 House and Senate hearings on the subject This week, the [Senate Banking Committee](https://www.banking.senate.gov/hearings/investigating-the-real-impacts-of-debanking-in-america) and [House Financial Services Committee](https://financialservices.house.gov/calendar/eventsingle.aspx?EventID=409451) will take a hard look at a troubling issue: how regulators in the last administration pushed banks to cut crypto companies off from financial services. These hearings are critical to turning the page on the past few years and ensuring that the United States shows true leadership in digital assets and financial technology, an important goal set out in the President’s recent [Crypto Executive Order](https://www.whitehouse.gov/presidential-actions/2025/01/strengthening-american-leadership-in-digital-financial-technology/). Crypto, AI, and other frontier technologies are critical to our country's future. But if the founders building these companies are debanked, or the companies themselves can't safely and easily set up and keep a bank account, it’s not possible to do business or hire teams in the United States. This week, that starts to change. Here's what to watch for. ### **Issue 1: Accessing Basic Banking Services** In the past, many crypto companies lost (or nearly lost) access to all banking services. For example, Stellar Development Foundation’s CEO reported that the Foundation was debanked, after which they approached ten different financial institutions to gain sufficient coverage. [^1] That demeaning shuffle has been a too-common occurrence over the last few years in crypto. Without a bank account, it is presently difficult to interact with traditional financial systems or receive institutional financing. The problem is compounded if payment processors also refuse the company’s business, jeopardizing on- and off-ramps. Being debanked is not a one-time embarrassing event, but exposes a company to a dangerous cascade of risks that can capsize even a well-managed firm. Not everyone has stayed afloat after all those waves. Banks justified the debanking of crypto companies with generalized arguments that such companies present legal or financial risk. However, providing basic financial services to crypto companies is not the same as taking crypto assets as deposits or even lending to such companies. And while risk management can be a legitimate consideration, we are concerned that banks were looking for a pretext to avoid regulatory scrutiny rather than genuinely mitigate risk, especially when even rigorously-vetted companies were losing bank accounts. ### **Issue 2: Crypto Founders Personally Lost Access to Banking** Crypto founders and employees have also been debanked. [^2] For example, Hayden Adams [reported](https://x.com/haydenzadams/status/1485294362657443842) that JPMorgan Chase debanked him in 2022 without explanation. He [noted](https://x.com/haydenzadams/status/1593117537251647489) that nearly every attendee at a crypto-related dinner he attended that year had also been debanked. Even if banks see crypto companies as uniquely risky, there is no reason to expect the personal bank accounts of founders and employees to carry the same degree of legal or financial risk. Losing a personal bank account can seriously impact people’s lives, making it difficult to obtain a credit card, secure a mortgage, or engage in routine financial transactions. Often, these debanking decisions culminate in nonsensical results. For example, Austin Federa, founder of DoubleZero, [described](https://x.com/Austin_Federa/status/1847299477209510013) how after his bank tried to debank him three times, a second bank denied him a mortgage because he worked in crypto but said that if he resigned (and therefore had no income), they would lend to him. ### **Issue 3: Regulators Set the Stage for Debanking** One of the most contentious issues that will be raised in the hearings is whether federal regulators pressured banks – implicitly or explicitly – to cut off access to crypto businesses. This “Operation Chokepoint 2.0” echoes a 2014-era effort by federal banking regulators (known as “Operation Chokepoint”) to cut off banking services to various legal industries that the government disfavored, including payday lenders and firearms manufacturers. Recent FOIA requests revealed that the [FDIC sent letters to 25 banks](https://www.fdic.gov/foia/history-associates-inc-v-fdic-fdics-redacted-pause-letters-january-3-2025) in 2022 advising them to pause crypto-related activities until the agency could assess risks. Later, in January 2023, the FDIC, OCC, and Federal Reserve issued a [joint statement](https://www.fdic.gov/news/financial-institution-letters/2023/fil23001.html) to banks that business models with concentrated exposure to the crypto-asset sector posed “significant safety and soundness concerns.” This statement was [endorsed](https://web.archive.org/web/20240328231647/https://www.whitehouse.gov/nec/briefing-room/2023/01/27/the-administrations-roadmap-to-mitigate-cryptocurrencies-risks/) by the Biden White House, which encouraged federal regulators to “limit financial institutions’ exposure to the risks of digital assets.” The implied threat of increased regulatory scrutiny, additional examinations, or potential enforcement actions was enough to deter many banks from servicing the entire industry. In 2022, Senator Elizabeth Warren [praised](https://www.warren.senate.gov/newsroom/press-releases/at-hearing-warren-defends-fdic-chair-from-baseless-attacks-and-calls-on-regulators-to-keep-crypto-out-of-banking-system-after-ftx-collapse) “President Biden’s regulators,” including then-Acting Chairman of the FDIC Martin Gruenberg, for fighting “to keep crypto from becoming dangerously intertwined with our banking system.” Indeed, Travis Hill, the Acting Chairman of the FDIC, recently [acknowledged](https://www.fdic.gov/news/speeches/2025/charting-new-course-preliminary-thoughts-fdic-policy-issues) the existence of “public perception that the FDIC is closed for business if institutions are interested in anything related to blockchain or distributed ledger technology.” As noted above, the downstream effect of the bank regulators’ previous disfavor towards crypto has been the debanking of individuals in their personal capacity, which runs directly contrary to regulators’ longstanding goals of decreasing the unbanked population. [^3] ### **Issue 4: Silvergate and Signature** A narrative that should feature heavily in the hearing is that the closures of Silvergate and Signature Bank were not inevitable. Indeed, both are examples of situations where regulators let their politics get ahead of smart oversight. In March 2023, Silvergate filed for voluntary liquidation and, shortly thereafter, the New York State Department of Financial Services (NYDFS) forcibly closed Signature. Silvergate initially expressed liquidity concerns in late 2022, after experiencing a large outflow of customer deposits following the bankruptcy of FTX, but successfully averted collapse after securing loans from the Federal Reserve Bank of San Francisco and the Federal Home Loan Bank (FHLB) of San Francisco. However, in the subsequent months, Silvergate’s ability to conduct business and secure further loans was complicated by intense government scrutiny. On March 1, 2023, Silvergate [disclosed risk](https://www.sec.gov/Archives/edgar/data/1312109/000110465923027353/tm238251d1_nt10k.htm) of potential adverse financial performance due to, among other things, (i) “the safety and soundness concerns expressed by the federal banking agencies regarding banking institutions with business models that are concentrated in digital asset related activities," [^4] (ii) congressional inquiries, [^5] and (iii) investigations by the Department of Justice. Three senators, including Senator Elizabeth Warren, specifically [criticized](https://www.warren.senate.gov/imo/media/doc/2023.01.30%20Follow-up%20Letter%20to%20Silvergate%20Bank%20re%20Crypto%20Exposure%20and%20FTX%20Impropriety1.pdf) Silvergate’s reliance on the FHLB loan. The resulting crisis of confidence in Silvergate by depositors and lenders led to its filing for voluntary liquidation later that month. Not long after Silvergate collapsed, NYDFS closed Signature Bank over insolvency concerns due to outflows of customer funds from the bank. Executives at Signature were [surprised](https://www.nytimes.com/2023/03/12/business/janet-yellen-silicon-valley-bank.html) by NYDFS’s closure given their belief that the bank was solvent and well capitalized. The immediate causes of these banks’ failures were not any unique risk of the crypto industry, [^6] but instead a simultaneous outflow of customer deposits and an apparent inability to secure emergency financing (both due to their heavy concentration of customers in a single industry and government pressure). [^7] It is incorrect to suggest that siloing the crypto industry into a small number of banks decreased systemic risk; rather, the resulting concentration *increased* systemic risk. ### **Issue 5: SAB 121 and SAB 122** Although not directly related to debanking, the hearings (and surrounding media coverage) are likely to mention [SAB 121](https://www.sec.gov/regulation/staff-interpretations/accounting-bulletins/old/staff-accounting-bulletin-121), an accounting rule the SEC introduced in 2022 that made it prohibitively expensive for banks to custody crypto assets. Under this rule, financial institutions were required to treat crypto assets (including those they custodied) as liabilities on their balance sheets, necessitating offsetting capital reserves (lest bank capital holding requirements be negatively impacted). SAB 121 did not solely target crypto asset deposits at banks (where, similar to any dollar bank deposit, a bank will lend the deposit), but instead targeted assets under custody (where a bank would, similar to a custodian like Coinbase, custody the private keys to a user’s hosted wallet). Custodying crypto is like storing gold in a bank vault for safekeeping: the bank will maintain some insurance to offset risk of loss, but it is not lending the asset itself. SAB 121 made the business of crypto custody prohibitively expensive, substantially shrinking the number of custody options available to the market. [^8] SEC Commissioner Hester Peirce [noted](https://www.sec.gov/newsroom/speeches-statements/peirce-remarks-wharton-fintech-110124#_ftnref31) that SAB 121 was just one of many examples of the SEC providing a “supervisory signal” to dissuade traditional financial firms from servicing crypto clients. Underscoring the arbitrary nature of this guidance, Jim Kroeker, the former Vice Chair of the Federal Accounting Standards Board (FASB) and the SEC’s Chief Accountant from 2009 to 2012, recently stated that SAB 121 was not consistent with existing GAAP standards, and was clearly “[punitive](https://x.com/EleanorTerrett/status/1885371843667783855)” in intent. SAB 121 was [rescinded](https://www.sec.gov/rules-regulations/staff-guidance/staff-accounting-bulletins/staff-accounting-bulletin-122) by the SEC on January 23, 2025, concurrent with President Trump’s recent [executive order](https://www.whitehouse.gov/presidential-actions/2025/01/strengthening-american-leadership-in-digital-financial-technology/) on crypto. [^9] [^1]: See testimony by Denelle Dixon, Stellar Development Foundation’s CEO, before the House in December 2024 [^2]: Note that the Senate Banking Committee is also expected to investigate whether people are being debanked based on their political views [^3]: See, for example, recent reports from the FDIC (and as reaffirmed in recent comments by FDIC Acting Chairman Travis Hill) and the CFPB [^4]: Although this language can be understood generally in the context of regulatory disfavor towards crypto, the timing and wording of the statement clearly allude to the January 2023 joint statement by the FDIC, OCC, and Federal Reserve referred to above [^5]: In December 2022 and January 2023, Elizabeth Warren and other senators sent several letters to Silvergate and regulators regarding the company’s connections to FTX, financial solvency, and servicing of crypto clients. See December 2022 and January 2023 letters to Silvergate, and December 2022 letter to federal bank regulators [^6]: Note that FTX filed for bankruptcy several months before the banks collapsed, and in the immediate aftermath, Silvergate (which held FTX’s deposits) was able to maintain solvency through its loans from the Federal Reserve and FHLB [^7]: Note also that the concentration of crypto companies in Silvergate and Signature is itself partially due to regulatory pressure on the banking industry, as explained above [^8]: BNY Mellon, for example, ultimately sought a legal exception from the SEC to SAB 121 since it viewed the rule as making custodying of crypto assets prohibitively expensive [^9]: SAB 121 was rescinded through a new SEC staff accounting bulletin, SAB 122 ## https://www.paradigm.xyz/writing/ethereum-acceleration-1 # Ethereum Acceleration > Since its inception, Ethereum has been a pioneering force in crypto. Ethereum paved the way for smart contracts, DAOs, and DeFi, and continues to innovate on frontier challenges like ZK and MEV. Ethereum’s community of researchers and engineers has built a strong foundation for the next generation of decentralized applications. Since its inception, Ethereum has been a pioneering force in crypto. Ethereum paved the way for smart contracts, DAOs, and DeFi, and continues to innovate on frontier challenges like ZK and MEV. Ethereum’s community of researchers and engineers has built a strong foundation for the next generation of decentralized applications. It’s easy to forget that the first version of the Ethereum protocol shipped in less than two years—a pace that drew many of us to the project as a developer platform in the first place. But today, we think Ethereum’s core protocol could be improving much faster. There are many high-impact improvements that Ethereum can start accelerating towards today, without sacrificing its values. ## Shipping faster helps Ethereum regardless of your vision for it. There is reasonable debate about what Ethereum’s north star should be. But wherever you think Ethereum should go, surely it is better to get there faster. Investing in Ethereum’s shipping capacity is valuable regardless of which direction the protocol ends up going. When faced with a technical choice, it’s tempting to immediately jump to arguments about *values* — like whether we care more about L1s vs. L2s, decentralization vs. efficiency, or financial vs. non-financial use cases. These debates are addictive because anyone can participate in them. They can generate a lot of heat, and build a lot of clout for the debaters. But if we haven’t hit the fundamental limits, discussions about tradeoffs in values might be premature. We think Ethereum should be focused on reaching the efficient frontier of what’s possible before arguing — hypothetically — about how we would choose between our values once we’ve hit those limits. Shipping faster will help Ethereum get there. It also can dissolve many “either/or” dilemmas around prioritization, by responding to questions like “should we do X or Y first?” with “both.” Ethereum has the resources it needs — incredible researchers and engineers eager to build the future. Empowering them with a mandate to move faster, and in parallel, will enable Ethereum to solve problems faster and avoid getting bogged down in premature debates. ## How could Ethereum ship faster? Historically, Ethereum has shipped about one change per year. Ethereum can do more. Most importantly, by deciding to. The community can set more ambitious goals and work harder to meet them. One obstacle to this is inertia. But another is the somewhat common belief that the protocol should begin to ossify — that the best way to keep Ethereum decentralized is to slow down the pace of changes to the core protocol. We think ossification is too risky for Ethereum. It prevents Ethereum from staying competitive as a platform, as applications and users move toward more centralized alternatives. Ossification also poses its own centralization risks to Ethereum. The core development process is one of the main mechanisms for offchain governance by Ethereum’s social layer, and reflects input from engineers, researchers, validators, and institutions. Ossifying the core protocol would mean abandoning that governance mechanism and Ethereum’s ability to evolve in response to changes in the market structures of areas like L2s and MEV. Once we decide to move faster, there are R&D process improvements that could have a large impact. For example, client teams should have an input, not a veto. Client diversity does not need to come at the expense of shipping speed. We should have more than one client ready for every upgrade, but we shouldn’t have an N-of-N where the most conservative client dictates the speed for protocol iteration. We maintain Reth, and we want to commit to never being the bottleneck on Ethereum’s roadmap. The All Core Devs process can be improved (as Tim Beiko recently [suggested](https://github.com/ethereum/pm/issues/1258#issuecomment-2608642665) on the Consensus Layer call). We invite the community to weigh in on the [Pectra retrospective](https://ethereum-magicians.org/t/pectra-retrospective/22637) with concrete suggestions. Let’s allocate more resources to DevOps and Testing so we can confidently deliver major improvements more often — while still preserving the reliability Ethereum is known for. There are many ways to move faster beyond these initial suggestions — the high-order bit is explicitly recognizing the need for speed. ## We aren’t lacking good ideas We believe there is low-hanging fruit that the Ethereum community could put more of its energy behind. These non-controversial improvements are delayed because of slow shipping speed and the perception that only a few changes can be made per year. Instead of proactively limiting its ambition, Ethereum should aspire to do more, faster. Here are some possible examples: - Scaling and securing L2s: - Rollups need to confidently plan for what level of demand to accommodate. This requires allocating more resources on the post-EIP4844 roadmap like [PeerDAS](https://eprint.iacr.org/2024/1362) or [Blob-Parameter-Only hardforks](https://ethereum-magicians.org/t/blob-parameter-only-bpo-forks/22623). - Rollups need to inherit L1 security and censorship resistance, see [Native Rollups](https://ethresear.ch/t/native-rollups-superpowers-from-l1-execution/21517/12). - Scaling L1 without burdening node operators: - Repricing the L1’s opcodes could help scale Ethereum without modifying the block gas limit \[[1](https://ethresear.ch/t/proper-disk-i-o-gas-pricing-via-lru-cache/18146), [2](https://ethresear.ch/t/block-level-warming/21452)\]. - Increasing the L1 Execution gas limit safely is an active area of research which requires deep analysis of [history](https://www.paradigm.xyz/2024/05/how-to-raise-the-gas-limit-2) and [state](https://www.paradigm.xyz/2024/03/how-to-raise-the-gas-limit-1) growth to help decide how solutions like [history](https://eips.ethereum.org/EIPS/eip-4444) expiry and [statelessness](https://ethereum-magicians.org/t/eip-7864-ethereum-state-using-a-unified-binary-tree/22611) should work. - Improved Wallet UX & Security with Account Abstraction: - While EIP7702 started bridging the gap between EOAs and Account Abstracted wallets, we think there is room to go to further improve the UX of batched & sponsored transactions and eliminate users’ reliance on private keys. ## How are we contributing to the mission of Ethereum Acceleration? As researchers and engineers we will contribute with EIPs, data analysis, and code, with a particular focus on proposals like [EIP-7862](https://github.com/ethereum/EIPs/pull/9241/), that offer non-controversial improvements and don’t conflict with the rest of the roadmap. We have been diving deep into Ethereum’s [state](https://www.paradigm.xyz/2024/03/how-to-raise-the-gas-limit-1) and [history](https://www.paradigm.xyz/2024/05/how-to-raise-the-gas-limit-2) to inform what we can do safely with the gas limit. Reth is [production ready](https://www.paradigm.xyz/2024/06/reth-prod), and will continue to set a fast pace of shipping the milestones to unblock upcoming hardforks. We built Reth intentionally as an SDK for building “EVM-core” nodes to enable experimentation and innovation by researchers and engineers. We invite the research community to collaborate with us in prototyping new features towards improving Ethereum’s performance, censorship resistance, and future-proofing, with Reth. Finally, we will continue building and supporting foundational tooling - like Foundry, Alloy, Solar, Revm, Wagmi and Viem - to ensure that any core protocol updates get exposed effectively to users ## Outlook We think agreeing to ship faster is the most important thing Ethereum can do as a community to expand the space of what is possible and enable the protocol to deliver on its ambitious roadmap. Accelerating Ethereum development will make permissionless innovation accessible to more people, helping pave the way for a truly global, trust-minimized financial system. ## https://www.paradigm.xyz/writing/nft-amicus # Paradigm Files Amicus Supporting NFT Creators’ Lawsuit Against SEC > Paradigm files amicus brief outlining why the mere usage of blockchain technology does not turn digital creations into investment contracts. Today, Paradigm filed an [amicus brief](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-10957b35df/52d277bf885fa8c4daa397aed49c4ae8/asset-https-cdn-sanity-io-files-dgybcd83-p-10957b35df.pdf) supporting two artists’ attempt to obtain a declaratory judgment and injunctive relief from the SEC in *Mann v. Securities Exchange Commission.* Jonathan Mann is a singer, songwriter, and music producer who writes a song a day that he publishes as NFTs. Brian Frye is a law professor and artist who creates conceptual art sold as NFTs. Like many other creators, they would like to launch their NFT projects but have not done so because of the SEC’s enforcement actions in the NFT space. Professor Frye has even sought no-action letters from the SEC to no avail. For too long, the SEC’s campaign of regulation by enforcement has stifled innovation in the crypto space. As two SEC commissioners themselves noted in their [dissent](https://www.sec.gov/newsroom/speeches-statements/peirce-uyeda-statement-stonercats-091323) in the Stoner Cats case: “Were we to apply the securities laws to physical collectibles in the same way we apply them to NFTs, artists’ creativity would wither in the shadow of legal ambiguity.” Paradigm’s amicus brief outlines why the usage of blockchain technology does not magically render swaths of digital creations into investment contracts and how the economic realities of NFT market prices make clear that they are not dictated by the efforts of others and are therefore not investment contracts. ## https://www.paradigm.xyz/writing/distribution-markets # Distribution Markets > This paper introduces distribution markets, a new kind of prediction market for events whose outcomes aren't just "yes" or "no" but could be any number. Instead of betting on a particular outcome or range, traders can express how likely they think each different possibility is across the whole infinite range of outcomes. # Overview This paper introduces *distribution markets*, a new kind of prediction market for events whose outcomes aren't just "yes" or "no" but could be any number. Instead of betting on a particular outcome or range, traders can express how likely they think each different possibility is across the whole infinite range of outcomes. ![Distribution Markets landing page](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--5f42fce3a4/5e1a857db063a63855ceebd1e908c7a4/asset-https-cdn-sanity-io-images-dgybcd83--5f42fce3a4.png) *The gray curve represents the AMM's initial belief, the blue curve represents a new trader's belief, and the green and red curve represents the trader's potential profit and loss if they were to move the market to their belief. Each curve is denominated in dollars, and the blue and gray curves are scalar multiples of their underlying probability distributions.* ## Intuition Take the question "When will GPT-5 be released?" In a traditional prediction market, traders might have to choose between preset options like "Q2 2025" or "2026." Prediction competitions like [Metaculus](https://www.metaculus.com/questions/15462/when-will-gpt5-be-announced/) instead let traders express their predictions as a curves showing exactly how likely they think each possible date is. However, Metaculus is a competition, not a market, and has no way for participants to trade on their beliefs and put skin in the game by trading on their beliefs. Like Metaculus, Distribution Markets allow participants to come to consensus on the full probability distribution over all outcomes, but like traditional prediction markets they allow traders to profit by moving the shared view in the right direction. ## Mechanics The underlying mechanism is a constant function AMM over functions, with the invariant (analogous to Uniswap's *xy=k*) being a constant $l_2$ norm. When restricted to specific distributions (such as the Normal, lognormal, and so on), the math is surprisingly simple, and the resulting AMMs can be implemented efficiently onchain. # Motivation Prediction markets have entered popular consciousness in the wake of the 2024 US Presidential elections, but the technology is likely still in its infancy. Further development could be of benefit both to developers and to the [public at large.](https://vitalik.eth.limo/general/2024/11/09/infofinance.html) More specifically, today's prediction markets generally allow participants to express probability distributions over discrete outcomes, but many questions of relevance to the real world involve continuous outcomes. It's true that a perp market could elicit the expected value of a continuous variable from the market, but sometimes we would like to know more -- for example, do we know for sure a given project will take 10 years exactly, or could it perhaps be anywhere between 2 and 20? # Mechanism ## Discrete Case *This section is provided as an aid to understanding the continuous case, which is the main contribution of this paper.* We already have many options for prediction market AMMs in the *discrete case*, where the outcome is one of a finite set of options. So, the discrete case distribution market mechanism presented in this section isn't particularly useful. However, the math in the discrete case mirrors the continuous case exactly, so this section may be helpful as an aid to intuition. ### Outcome Tokens Consider some event with $N$ outcomes. We create *outcome tokens* $X_1,...,X_N$ such that if the outcome is e.g. outcome $i$, token $x_i$ will be worth \\$1, and the other tokens will be worth \\$0. (Note: we're using dollars as the payout currency for accessibility to a broader audience, but this could be any asset.) We can at any time mint or redeem a full set of these tokens for $1, because at expiry exactly one token will be worth $1 and the rest worth $0. ### AMM Invariant We’re going to create our AMM as a standard Constant Function Market Maker (CFMM), of which the most famous example is probably Uniswap, which has constant function $xy=k$. We initialize the AMM with $k$ dollars, which we split into $k$ each of the outcome tokens, so that the market can then sell up to $k$ of any of the outcome tokens in total. We denote the AMM’s vector of holdings $h$ as $$ h = k - x = (k-x_1,\ldots,k-x_n) $$ so that the $x$ vector represents how much of each outcome token the AMM has sold. We define our AMM’s constant function to be $$ ||x||_2 = \sqrt{\sum_{i=1}^N x_i^2}=k $$ Since $x=k-h$, we could also write $$ ||k-h||_2 = \sqrt{\sum_{i=1}^N (h_i-k)^2}=k $$ which means the AMM's holdings are a a translated hypersphere with radius $k$ around the point $(k,\\ldots,k)$ in $\\mathbb{R}^N$. Note that the minimum coordinate of this translated hypersphere along any dimension is $0$. From this, we can see that the AMM will always sell at most $k$ of any given outcome token, which is fortunate, since it doesn’t have any more than that to sell. ### Trading Behavior Say the true probability distribution of $X_i$ is $p=(p_1,\\ldots,p_n)$. At the time of resolution, the correct outcome token will be worth \\$1. So the expected value of the AMM’s holdings is the probability-weighted sum of its outcome token holdings, $\\sum_i p_ih_i = p\\cdot h=p\\cdot(k-x)= k - p \\cdot x$, where we say $p\\cdot k = k$ because $p$, as a probability distribution, sums to 1. If we assume the market is efficient, arbitrageurs will act to maximize the expected value of their own holdings $x$, which will minimize the value of the AMM's holdings $h$. In other words, they are solving the optimization problem $$ \min_x k - p\cdot x \,\,\,\,\text{ s.t. } ||x||_2=k $$ Since traders can’t affect $k$, this simplifies to $$ \max_x p\cdot x \,\,\,\,\text{ s.t. } ||x||_2=k $$ By the [Cauchy-Schwarz inequality](https://en.wikipedia.org/wiki/Cauchy%E2%80%93Schwarz_inequality), the vector that maximizes this dot product given the fixed norm must be linearly dependent with $p$. [This great 3b1b video on the dot product](https://www.youtube.com/watch?v=LyGKycYT2v0) offers more context). This means we must have $$ x = k\frac{p}{||p||}_2 $$ In other words, $x$, the vector of positions collectively held by the market, is directly proportional to the true probability distribution $p$, scaled so that its $l_2$ norm is $k$. By our definition above, the AMM’s holdings $h$ are determined by $$ h = k -x = k(1-\frac{p}{||p||_2}) $$ which has the nice side effect that we can read the market’s estimated distribution directly from the AMM’s reserves. In this way, the distribution market is an example of a [market scoring rule](https://mason.gmu.edu/~rhanson/mktscore.pdf). ## Continuous Case The continuous case is the main contribution of this paper, because it unlocks a new behavior: prediction-market-like trading over continuous probability distributions. The mechanism follows nearly identical logic to the discrete case, but with some additional constraints to ensure the market stays solvent. This is a general construction, but by specializing the types of distribution allowed — to, say, uniform or Gaussian distributions — the resulting AMM can be made computationally efficient to run on, for example, Ethereum mainnet. We discuss this in more detail below. ### Outcome Function Tokens Consider some event with outcomes over a continuous space, say $\\mathbb{R}$. We can imagine creating one outcome token $X$ for every point $x\\in\\mathbb{R}$ such that, if the outcome is $x$, that outcome token will be exchangeable for $1, and the others will be worth $0. The simplest way to express holdings of these tokens is as *functions *$f:\\mathbb{R}\\rightarrow\\mathbb{R}^+$ where $f(x)$ is the number of tokens the owner of $f$ holds for outcome $x$. In other words, the holder of $f$ will receive $f(x)$ if the outcome is $x$. Formally, all positions in the context of continuous prediction markets are functions. Depending on context, it may be most helpful to think of these functions either as infinite collections of outcome tokens, as curves, or just as abstract members of function-space. ### Minting and Redeeming Consider the constant function $f(x)=b$. Regardless of the outcome $x_0$, the holder of this function will receive $f(x_0)=b$ at the time of resolution. So, we at any time allow this function to be minted or redeemed for $b$ dollars. ### AMM Invariant As in the discrete case, we will initialize our AMM with a fixed amount of dollars, $b$. We denote the AMM’s holding outcome function $h$ as $$ h(x) = b - f(x) $$ The AMM can then sell up to $f(x_0)=b$ at any given point $x_0$, since it will be able to pay out $b$ once the outcome is determined. We would then have $h(x_0)=b-b=0$ at that point, indicating the AMM cannot sell any more of that outcome. ![If traders have, in aggregate, bought outcome function f(x) from the AMM…](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--824383b401/dcd5da8017947f1bb14f4bd9543b4c03/asset-https-cdn-sanity-io-images-dgybcd83--824383b401.png) *If traders have, in aggregate, bought outcome function f(x) from the AMM…* ![...the AMM’s holdings h(x) are b-f(x).](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--bbc4790676/7f91d5d2b7ebcdb8d4796121e61f1fbd/asset-https-cdn-sanity-io-images-dgybcd83--bbc4790676.png) *...the AMM’s holdings h(x) are b-f(x).* We restrict $f$ to lie in $L^2$, the space of square-integrable functions (i.e. functions whose square has a finite integral). This is an inner product space with inner product $$ f\cdot g=\int_{\mathbb{R}} f(x) g(x)dx $$ Just as in the discrete case, we will choose a constant $l^2$ norm as our constant function. In this space, that constant is expressed as $$ ||f||_2 = \sqrt{\int_{\mathbb{R}}f(x)^2dx}=k $$ Note that we’ve limited the $l^2$ norm here to a new constant $k$, not $b$, the amount of money with which we initialized our AMM. In the finite-dimensional case, no element of a vector $x$ with $l_2$ norm $k$ can have a value of greater than $k$, so our $l_2$ norm constraint was enough to ensure the AMM's solvency. In the infinite-dimensional case, this is no longer true. So we separate out the backing amount, $b$, from the $l^2$ norm constraint, $k$, and we add an additional constraint to the AMM, namely $$ \max{f}\leq b $$ ### Trading Behavior At its simplest, the AMM starts by holding some function $h(x)=b-f(x)$. A trader who wants to move the market to $g(x)$, so that the AMM now holds $b-g(x)$, will end up holding $g(x)-f(x)$, the difference of the two functions. ![Distribution Markets landing page](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--5f42fce3a4/5e1a857db063a63855ceebd1e908c7a4/asset-https-cdn-sanity-io-images-dgybcd83--5f42fce3a4.png) *The gray curve is the starting f(x), the position initially held in aggregate by all traders and a scalar multiple of the market's starting estimate of the true distribution. The blue curve is g(x), the scakar multiple of the distribution the trader is moving the market to that leads to the appropriate l_2 norm. The green and red curve is g(x)-f(x), representing the trader's position after the trade. They will make money if the outcome is in the green region and lose money in the red region. We can see they have shifted the mean down slightly and increased the variance, so that they in general make money if the outcome is outside the peaked area of the original f(x).* More formally, say the true probability distribution of the outcome in question is described by a probability density function $p(x)$ so that the expected value of the AMM’s holdings is $$ \mathbb{E}(b-f(x))=b-\mathbb{E}(f(x)) = b - \int_\mathbb{R}f(x)p(x)dx=b-f\cdot p $$ where the last equality comes from our definition of inner product on this space. If the market is efficient, arbitrageurs will act to minimize the AMM’s expected value. In other words, they are solving the optimization problem $$ \min_f b - f\cdot p \,\,\,\,\text{ s.t. } ||f||_2=k \text{ and } \max{f}\leq b $$ Since the trader can’t affect $b$, this simplifies to $$ \max_f f\cdot p \,\,\,\,\text{ s.t. } ||f||_2=k\text{ and } \max{f}\leq b $$ For a moment, assume the AMM has effectively infinite backing, so that the second constraint doesn’t matter and we simply have $$ \max_f f\cdot p \,\,\,\,\text{ s.t. } ||f||_2=k $$ Then, just as in the discrete case, the Cauchy-Schwarz inequality tells us that the vector that maximizes this dot product given a fixed norm must be linearly dependent with $p$ — in other words, we know we must have $$ f = k\frac{p}{||p||}_2 $$ In other words, $f$, the outcome function collectively held by traders, is directly proportional to the true probability distribution! This means that the AMM’s holdings $h$ are determined by $$ h = b -f = k(1-\frac{p}{||p||_2}) $$ and we can again read traders' aggregate estimated distribution directly from the AMM’s reserves. ![If the true distribution p(x) looks like this…](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--824383b401/dcd5da8017947f1bb14f4bd9543b4c03/asset-https-cdn-sanity-io-images-dgybcd83--824383b401.png) *If the true distribution p(x) looks like this…* ![In an efficient market, traders’ holdings f(x) will, in aggregate, be shaped proportionally…](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--95eb65ab69/30add77203a4c7716e3341e38bd39ab5/asset-https-cdn-sanity-io-images-dgybcd83--95eb65ab69.png) *In an efficient market, traders’ holdings f(x) will, in aggregate, be shaped proportionally…* ![…and the AMM’s holdings h(x) will be the mirror image](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--a10d06c9e0/a9c8f4aea7d3689ba36b135b918cf42f/asset-https-cdn-sanity-io-images-dgybcd83--a10d06c9e0.png) *…and the AMM’s holdings h(x) will be the mirror image* ### Handling the Backing Constraint We assumed above for convenience that the AMM’s backing $b$ would be essentially infinite, but, of course, this will often not be the case. When there are backing constraints, we have two options: The first, and simplest, is to simply not permit traders to move $f(x)$ to situations where we have $||f||_2=k$ but $\\max{f}>b$. In the normal case, as we will discuss below, this simply means forbidding traders to estimate standard deviations which are too narrow, which may be appropriate to help the market avoid getting wiped out by traders with inside information. Alternately, we can simply enforce the constraint that $f(x)\\leq b$. Let’s say a trader believes the true probability distribution is $p(x)$. We leave it as an exercise to the reader to show that the trader’s optimal position will be $$ f(x)=\min(\lambda p(x),b) $$ for whatever $\\lambda$ makes it such that $||\\min(\\lambda p(x),b)||_2=k$. We can find $\\lambda$ numerically offchain and then easily verify this property onchain for many distributions. ### Liquidity Provision The AMM allows permissionless adding of liquidity, with liquidity providers (LPs) receiving fungible LP shares, just like in Uniswap V2. Imagine for a moment we had a uniswap V2 pool containing 10,000 USDC and 1 ETH, with 10,000 LP shares outstanding. If a market participant wanted to add liquidity to this pool, they would have to add tokens that are a scalar multiple of the AMM's position, and would get a proportional share of the pool in return. So, for example, if a new liquidity provider were to double the liquidity in the pool, they could add 10,000 USDC and 1 ETH, and would receive 10,000 LP shares. Liquidity provision works just the same for the distribution AMM. A prospective liquidity provider needs to add assets proportional to the AMM's current position, and receives LP shares in return. The AMM's position is $h=b-f$. So an LP wanting to add some proportion $y$ of current liquidity needs to contribute a position $yh=yb-yf$. In return they will receive $yl$ LP shares, where $l$ is the current number of LP shares outstanding. In order to create the position $yh$, we will require the LP to mint it using $yb$ collateral. This means they will be left with a position $yb-yh=yb-(yb-yf)=yf$ that they can keep. This represents the market's position at the time they minted their LP shares. ### Collateralization The initial source of collateral to the AMM is the the first LP. If they initialize the pool with backing $b$, they need to submit $b$ collateral. They will also specify some initial $f$ for the pool, so that the pool's position is $h=b-f$ and the initial LP keeps the position $f$. The AMM's position and the position of all traders then sums to $b$, and there is $b$ collateral, so the system is fully collateralized. Similarly, when a new LP adds liquidity, they are adding $yb-yf$ to the pool and keeping $yf$ for themselves. They are then adding $yb$ to total outstanding holdings, so as long as they provide $yb$ collateral, the system will remain fully collateralized. Furthermore, if the AMM's position and all traders' positions summed to the backing amount before they added liquidity, that equality will still hold afterwards. Finally, let's assume the system is fully collateralized when a trade takes place, and that the AMM's position and the position of all traders sums to $b$. The market currently holds $h=b-f$ and a trader moves the market to $h_2=b-g$, so that this trader should now hold $g-f$. If this were the case, then because we know all other traders hold $f$ in aggregate, then all traders together would hold $f+(g-f)=g$ in aggregate, which means that all traders and the market together hold $b-g+g=b$ in aggregate, and the market would still be fully collateralized. However, in order to say the trader holds $g-f$, they must actually lose money if the outcome is $x_0$ and we have $g(x_0)-f(x_0)<0$. So the trader must collateralize this position with $-\\min_x{g(x)-f(x)}$ in collateral. We discuss how to verify this for the Normal case in that section below. ### The Normal Case Overview The normal distribution is in some ways the canonical example of a continuous probability distribution. In this section, we discuss how we can use distribution markets to create a prediction market over normal outcomes in an efficient manner onchain. ### $l_2$ Norm The Normal distribution with mean $\\mu$ and standard deviation $\\sigma$ has probability distribution function $$ p(x)=\frac{1}{\sqrt{2\pi \sigma^2}}e^{-\frac{(x-\mu)^2}{2\sigma^2}} $$ with $l^2$ norm $$ \sqrt{\int_\mathbb{R}\frac{1}{2\pi \sigma^2}e^{-\frac{(x-\mu)^2}{\sigma^2}}\,dx} = \sqrt{\frac{1}{2\sigma\sqrt{\pi}}} $$ where the latter equality comes from the closed form solution to the [Gaussian Integral](https://en.wikipedia.org/wiki/Gaussian_integral). ### AMM Behavior We can see that the $l^2$ norm is agnostic to the mean of the distribution, so our AMM is indifferent between distributions with the same standard deviation but different mean -- traders can move the market to any mean they like while keeping the same standard deviation, and will only have to provide the appropriate collateral. In later work we may explore the ability to give our AMM a *prior *which might prefer some means over others. However, distributions with lower variance have higher $l^2$ norms. This means that if the market’s estimated normal distribution has standard deviation $\\sigma$, we have $$ k=||f||_2=||\lambda p||_2=\lambda||p||_2=\lambda\sqrt{\frac{1}{2\sigma\sqrt{\pi}}} $$ and therefore $$ \lambda=k\sqrt{2\sigma\sqrt{\pi}} $$ In other words, the more peaked a trader's proposed distribution is, the less total probability mass the market will be willing to sell to them. Again, this might help the market avoid getting wiped out by traders with inside information about a specific outcome. ### Backing Constraints Remember we have $f=\\lambda p$, with $p$ being a Normal PDF. At its peak, $p$ has value $\\frac{1}{\\sqrt{2\\pi\\sigma^2}}$. As a multiple of $p$, f has maximum value $$ \max f=\frac{\lambda}{\sqrt{2\pi\sigma^2}} = k\sqrt{2\sigma\sqrt{\pi}}\frac{1}{\sqrt{2\pi\sigma^2}} =k\sqrt{\frac{1}{\sigma\sqrt{\pi}}} $$ Since we can never have $f(x)>b$, this means we must have $$ \max f = k\sqrt{\frac{1}{\sigma\sqrt{\pi}}}\leq b $$ so that $$ \sigma \geq \frac{k^2}{b^2\sqrt{\pi}} $$ As discussed in the general continuous case section above, we can simply restrict traders in the AMM from choosing standard deviations less than this. Alternately, we could allow traders to trade a *capped Gaussian* with any standard deviation they like, so that we would have $f(x)=\\min(b,\\lambda\\phi(x))$ for whatever $\\lambda$ satisfied the $l_2$ norm constraint. ![We can cap the trader's payout to b...](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--6d65325ef1/ec5578ebb4a7e296e9ba36a33c0ebd19/asset-https-cdn-sanity-io-images-dgybcd83--6d65325ef1.png) *We can cap the trader's payout to b...* ![...so that the AMM's payout is 0 at minimum.](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--6ba454ef2c/0b1f054613ef8a87d5de4c5a1154a8e8/asset-https-cdn-sanity-io-images-dgybcd83--6ba454ef2c.png) *...so that the AMM's payout is 0 at minimum.* For the remainder of this paper, however, we'll just assume we're enforcing the lower bound on $\\sigma$ for simplicity. ### Collateralization As discussed above in the collateralization section for the general continuous case, traders need to collateralize their trades with $-\\min_x{g(x)-f(x)}$ when moving the AMM from $h=b-f$ to $h_2=b-g$. Unfortunately, there is no apparent closed-form solution to $\\min_x ap-bq$, where $p$ and $q$ are Normal PDFs. However, we can compute this minimum numerically. Although there may be several local minima, it turns out that the only local minimum on the opposite side of $q$'s mean from $p$'s mean will be the global minimum (the proof that there can be only one such point is a very interesting exercise). We can then verify that the trader has provided this point onchain by checking first and second derivatives (and also ensure that the total max loss is at least some "dust" amount to avoid numerical attacks) and require they provide the corresponding collateral amount. $$ m=\frac{\lambda'}{2\sigma_q\sqrt{\pi}}-\frac{\lambda}{\sqrt{2\pi(\sigma_p^2+\sigma_q^2)}}e^{-\frac{(\mu_p-\mu_q)^2}{2(\sigma_q^2+\sigma_p^2)}} $$ ## Multiple Distributions Note that we could have a single distribution AMM capable of trading multiple distributions -- as long as the $l_2$ norm constraints and max loss constraints are obeyed, there is no reason not to let a trader switch from, say, a normal distribution to a uniform distribution in a single trade. The main point of practical difficulty would be in computing trade collateralization. This is relatively straightforward in the case of Normal -> Uniform and Uniform -> Normal distributions. We leave the calculations as an exercise to the reader. # Conclusion We hope Distribution Markets help to spark ideas for builders and researchers on the cutting edge of information finance. If that's you, we'd love to hear from you. # Acknowledgements [Dan Robinson](https://x.com/danrobinson), [Yang You](https://x.com/_yangyou), [Achal Srinivasan](https://x.com/achalvs), [Bhargav Annem](https://x.com/kean00reeves), [5/9](https://x.com/fiveoutofnine), [Sofiane Larbi](https://x.com/sofianeflarbi), [Ciamac Moallemi](https://x.com/ciamac), [Tom Dean](https://x.com/drawl), [andnasnd](https://x.com/andnasnd), [0xTomoyo](https://x.com/0xTomoyo), [Pia Park](https://x.com/piapark_eth), [Qiaochu Yuan](https://x.com/QiaochuYuan), [Connor Lurring](https://x.com/ConnorL__), [Grant Stenger](https://x.com/GrantStenger), [Santiago Lisa](https://x.com/santiago__lisa) ## https://www.paradigm.xyz/writing/amicus-brief-kalshi # Paradigm Files Amicus to Support Keeping Election Markets in the US > Paradigm files amicus in case against the CFTC to make sure Americans can access election-related prediction markets ## Kalshi’s lawsuit and win against the CFTC Kalshi is a financial technology company that operates a regulated exchange where users can buy and sell “event contracts”—an asset class whose payouts depend on whether specific future events occur. Those events can be anything from a hurricane to a change in interest rates. In 2023, Kalshi sought to list “control contracts” which would let traders take positions on which political party would control the U.S. Congress after an election. In a controversial 3-2 split decision, the CFTC blocked Kalshi from listing the control contracts, asserting it had the authority to review contracts involving “gaming” or “unlawful activity.” A federal district court disagreed. The court held that the agency had overstepped its authority, because elections involve neither gaming nor unlawful activity. The CFTC has now appealed. ## Our amicus brief on appeal U.S. Congressional elections carry immense consequences. The fates of bills, budgets, and nominees for both the executive branch and the judiciary all hang in the balance. Prediction markets like Kalshi’s serve two vital functions in this context. First, they let those with skin in the game—from business owners to investors—help protect themselves against political risks through hedging. Just as importantly, these markets harness collective wisdom to generate forecasts that help everyone, from citizens to organizations, better prepare for what’s coming. While polls can mislead, markets can cut through noise to reveal likely outcomes. Our [amicus brief ](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-68ff5da110/8e320ecdda2316b9bc4e99b04708f171/asset-https-cdn-sanity-io-files-dgybcd83-p-68ff5da110.pdf)explains that Kalshi’s control contracts serve the public interest in these ways, and that the CFTC was wrong to try to ban them. ## Why it matters This is a case about whether regulators can stretch statutory terms beyond recognition to block innovative financial products that they don’t like. If the CFTC prevails, its expansive reading of “gaming” could theoretically let the agency regulate *any* derivative contract where money is staked on future events. That would nullify Congress’s decision to eliminate across-the-board regulatory review of new contracts. And it would make U.S.-based prediction markets extremely difficult to operate. More broadly, a win for Kalshi would confirm that agencies must stay within statutory bounds even when confronting novel products. As technology continues to improve our financial markets, striking the right balance between innovation and regulation remains crucial. At Paradigm, we’ve spent significant time [researching](https://www.paradigm.xyz/2024/11/pm-amm) prediction markets and [advocating](https://www.paradigm.xyz/2024/07/prediction-market-comment) for the regulations that allow them to flourish. It is imperative that this technological primitive be allowed to reach its full potential, and we will continue to support efforts that work to bring about this future. ## https://www.paradigm.xyz/writing/the-5-levels-of-secure-hardware # The 5 Levels of Secure Hardware > Programmable cryptography enables fun, safe, and intelligent experiences. Hardware is necessary to achieve programmable cryptography at scale. How to think about the levels of secure hardware? Let’s get to Level 5. Achieving [programmable cryptography](https://0xparc.org/blog/programmable-cryptography-1) is one of the most important problems of the next decade for the next generation of intelligence and safe experiences on the web and beyond. We think that achieving that will require utilizing secure hardware which gives guarantees about the integrity and the confidentiality of the computation running on it. We see 5 levels towards secure hardware: - Level 1: Allows building basic applications like oracles or bridges. The developer experience is not great, but the performance is acceptable for these applications. Security is based on proprietary supply chains. - Level 2: The performance is slightly worse, but the developer experience is better, allowing more expressive applications such as social media account delegation like Teleport. No security improvements. - Level 3: Great developer experience, near native performance, supports GPUs. Allows testing the limits of secure hardware with applications like private or verifiable ML inference. No security improvements. We are here, **developers can build most of the exciting things that “endgame” programmable cryptography enables today.** - Level 4: Security improves by having an open manufacturing process of secure hardware, while developer experience and performance stay constant. Allows us to scale the benefits of programmable cryptography safely, without relying on proprietary manufacturers. - Level 5: Security improves by having heterogeneous open secure hardware connected to each other for redundancy. We can reliably use secure hardware at global scale for things like voting or handling sensitive medical data. Our main takeaway from this analysis: **We can build great applications with secure hardware today; the stack is ready for developers with good performance. To make things more secure, we’ll need innovation at the hardware layer.** # Programmable cryptography enables fun, safe, and intelligent experiences. Cryptography is a powerful tool which allows creating fun, safe and powerful environments for computation, communication and for browsing the web. Programmable cryptography will allow us to do more with our data. Here are some examples: - The next generation of large language models will be trained on large clusters over user data such as chat histories and medical data without violating their privacy. We will know which model was used to run every inference result, and have full provenance over the authenticity of content. - People will be able to coordinate and grant permissions over their accounts to their friends or to strangers on the internet. This is one of the most exciting things to me. As an example, [Teleport](https://teleport.best/) recently allowed anyone with a magic link to tweet from the Twitter account that issued it, as long as the tweet followed certain rules. If you thought Twitch Plays Pokemon was fun, imagine Group Chat controls 100e0 MrBeast-level TikTok accounts at the same time. - People will be able to connect safely over sensitive pieces of information. As an example, in Frontiers 2024, we collaborated with [Cursive](https://cursive.team/) and did a [safe recruiting ‘dating’ app](https://x.com/cursive_team/status/1826351016926732426) – meet people, and opt-in share that you’re looking for a job only if they match your interests and they’re also looking for candidates of a certain profile. If there’s no match, then nothing sensitive gets shared, not even with us, so you are guaranteed to be safe since nobody learned anything about your sensitive interests! # Secure Hardware is necessary to achieve programmable cryptography at scale. We can achieve some of the above with a mix of techniques such as zero-knowledge proofs (ZKP), homomorphic encryption (FHE), multi-party computation (MPC), and indistinguishability obfuscation (IO). These techniques, while pure and aesthetic, pose non-negligible barriers to deployment at scale. FHE does not address who holds the decryption key, MPC is based on non-collusion assumptions, ZK cannot handle share state, and IO does not have a feasible construction yet. In addition to that, there are high overheads in each of the above. It might not be possible to deploy such programmable cryptography at scale where performance and robustness matters. Can we do better? Secure Hardware allows for privacy-preserving computation with attested computational integrity. What this means in practice, is that you provide a program, some encrypted input, and secure hardware can evaluate the program over that encrypted output, and give you an attestation (usually from the hardware manufacturer) that it ran the program you requested correctly. This is such a powerful tool that it is already widely deployed in every modern [Apple device](https://support.apple.com/guide/security/secure-enclave-sec59b0b31ff/web), and will only continue becoming more popular; just look at [Apple’s Private Cloud Compute](https://security.apple.com/blog/private-cloud-compute/) announcement from earlier this year. Similar features are already available on the largest public clouds via Intel SGX/TDX, Amazon Nitro, AMD SEV, and more. As many readers may know, there is no shortage of vulnerabilities against secure hardware, which have been repeatedly broken by researchers. Despite that, we believe that secure hardware is the key to achieving practical programmable cryptography. # How to think about the levels of secure hardware? We think three axes matter: 1. Performance: How fast is the execution compared to “native” execution that does not have any guarantees about privacy or integrity? Here is some [recent work](https://arxiv.org/abs/2408.00443) on this. 2. Developer Experience: How easy is it to make a program run in secure hardware? Does it run as-is, or do I need to rewrite it for that target? Do I need to be aware of program idiosyncrasies which may impact confidentiality guarantees like data access patterns? 3. Security Model: What assumptions are we making about the system? What threats are we protected against given these assumptions? What are the practical ways we can realize such security models? Based on that, we produce the following table, with some use cases we feel excited about unlocking at each level. The examples we present are representative, and for a complete Systemization of Knowledge we refer readers to this [excellent research](https://arxiv.org/pdf/2205.12742). Supporting remote attestation and having hardware-level guarantees on memory isolation is table stakes to be included in our evaluation. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--36acc0b2e3/ecc6dc8a52685a753a5e285e0d1a7424/asset-https-cdn-sanity-io-images-dgybcd83--36acc0b2e3.png) We have already seen developers building fun, safe and intelligent experiences using Gramine, Intel TDX & the latest H200s, as seen above. We are missing an excellent toolkit for developing Secure Hardware-based apps, with some exciting [initial work](https://github.com/Dstack-TEE/dstack) already being done. Today, we are seemingly at Level 3, which is an amazing place for the developer community to be in, as we can start to innovate. As we keep going up the levels, the tradeoffs start to get harder - Improving the developer experience increases the [TCB](https://en.wikipedia.org/wiki/Trusted_computing_base). - Open source instruction sets may reduce performance, but improve verifiability. - Improving the TCB e.g. via the [Yocto project](https://www.yoctoproject.org/) may make deployment harder. Creating redundancy across heterogeneous Secure Hardware will reduce performance. # Let’s get to Level 5. We think that building on secure hardware in the next few years is going to go through a renaissance. Applications that we thought of as ‘weird’ or ‘impractical’ will start becoming normal and practical. Every major infrastructure provider will have wide availability of such hardware and provide cloud attestations to ensure their customers about their reliability. To go beyond coordinating fun social experiences, into creating a fair global financial system, training large models with sensitive data, and doing private identity, all at global scale, we will need to get to Level 5 – the holy grail of cryptographic compute. We think that is a really exciting future to be looking forward to. If you are working on the above and are interested in accelerating us to that future, reach out to [georgios@paradigm.xyz](mailto:georgios@paradigm.xyz). # Acknowledgements *Thanks to Phil Daian, Andrew Miller, and Quintus Kilbourn for review and feedback.* ## https://www.paradigm.xyz/writing/btc-for-the-sovereign # Bitcoin for the Sovereign > Why the game theory for sovereign adoption of BTC has changed. At the start of Paradigm in 2018, we believed deeply that BTC—then ~$4K per coin—would grow many multiples in value over the coming years, in part fueled by rising legitimacy and institutional adoption. (More on [the case for BTC](https://www.paradigm.xyz/2020/05/bitcoin-for-the-open-minded-skeptic)). But, at the time, adoption by sovereign nations still seemed improbable. Now, it seems underpriced. Multiple sovereign nations now hold BTC, the most public of which is [El Salvador](https://www.coindesk.com/markets/2024/11/12/el-salvadors-bitcoin-stash-rises-above-500m-but-bhutan-story-might-be-even-bigger/). Abu Dhabi’s sovereign wealth fund is [engaged in Bitcoin mining](https://www.coindesk.com/business/2023/05/09/marathon-digital-in-jv-for-immersion-cooling-bitcoin-mining-in-abu-dhabi/). US President-elect Donald Trump spoke about a Strategic Bitcoin Reserve [on stage at Bitcoin Nashville](https://www.wired.com/story/donald-trump-strategic-bitcoin-stockpile-bitcoin-2024/). US Senator Cynthia Lummis has [proposed draft legislation](https://www.lummis.senate.gov/press-releases/lummis-introduces-strategic-bitcoin-reserve-legislation/) for a Strategic Bitcoin Reserve. Polymarket, the prediction market platform, [estimates a ~30% likelihood](https://polymarket.com/event/will-trump-create-a-national-bitcoin-reserve-in-his-first-100-days?tid=1731602208006) of a Strategic Bitcoin Reserve. So what? As Tyler Cowen likes to say, solve for the equilibrium. The game theoretic equilibrium of BTC adoption has shifted. Sovereigns can no longer afford to dismiss BTC. From a game theoretic perspective, BTC is like gunpowder, not the iPhone. Christopher Nolan can afford not to adopt the iPhone; his intentional ludditeism may even lead to lower correlation and higher creativity. But once gunpowder was discovered, every sovereign was forced to adopt it… or else. The same is true today of AI, drones, and other key technologies. Now that the Overton window has opened for US adoption of BTC, other sovereigns will not wait. Sovereigns that build BTC reserves early will benefit from significantly better entry prices. The race to build BTC reserves is on. ## https://www.paradigm.xyz/writing/solar # Introducing Solar > A blazingly fast, modular and contributor friendly Solidity compiler, written in Rust Smart contracts empower developers to move value across the internet with few lines of code. That is really powerful, however developers are only able to iterate at the speed and safety of their tools. That motivated us in 2021 to build [Foundry](https://www.paradigm.xyz/2021/12/introducing-the-foundry-ethereum-development-toolbox), the all-in-one toolkit for smart contract developers. Today, we are excited to announce [Solar](https://github.com/paradigmxyz/solar) ☀️, and our vision for a blazing-fast, modular, and contributor-friendly implementation of the Solidity smart contract language, in Rust; licensed Apache/MIT. Solar is built for the future of smart contracts, in a world where developers seek customization, and assume great performance, safety, and developer experience. Solar is currently just a compiler frontend, and it is able to parse, lex and emit solc-compatible ABI, outperforming solc by >41x when benchmarked on that task against the popular codebase Solady. We are looking for contributors to help us ship the compiler middle-end optimizers, the backend for generating code for legacy EVM and [EVM Object Format](https://evmobjectformat.org/), and tooling for ensuring the mission-critical correctness of our generated bytecode. ## Solar is built to fix Foundry’s limitations. We built [Foundry in 2021](https://www.paradigm.xyz/2021/12/introducing-the-foundry-ethereum-development-toolbox) to empower developers to write idiomatic, safe Solidity code with unparalleled productivity. Under the hood, Foundry leverages advanced simulation infrastructure to provide extensive test coverage, fuzz testing, interactive debugging, traces and more. Developers loved that, and started porting their entire codebases to be in Solidity, which meant that new problems surfaced! Over time, we realized that testing no longer was the bottleneck. It was the compiler: 1. Compilation times started getting longer and longer as people wrote more complex smart contracts. 2. Writing tests in Solidity meant that the infamous “Stack Too Deep” error started becoming more and more prevalent. 3. Developers got better at writing Solidity and started observing that the compiler was emitting really gas suboptimal code. 4. Foundry features like forge fmt or other “solc-as-a-library” uses were too slow. The library support is particularly important to us, as we had to hand-roll our own AST visitors and implementations to achieve what we needed. 5. Innovating on the EVM layer is not effective if it cannot be exposed to developers, e.g. with new EOF versions, opcodes, or precompiles. After a long time of creating workarounds for the above problems, we decided it was time to fix these by writing our own compiler using modern compiler techniques that inspire us from no other codebase than the Rust compiler. Meet Solar ☀️. ## Solar is built for the future of smart contracts. Solar will enable EVM developers to be 10x more productive in their day to day, write safer code via clippy-style lints, and excitingly, be able to write gas efficient-by-default smart contracts without needing to drop to in-line assembly for table-stakes optimizations. Solar is not intended to support Solidity code pre-0.8. It is meant to be compatible with the Solidity language and we have no plans to diverge. In developing Solar, we will be focused on safety and robustness and differentially testing and verifying the behavior of its bytecode against Solc to ensure correctness. We think this is one of the most critical areas to get right. Today, Solar is just a frontend that parses and lexes Solidity. Our benchmarks on the compiler’s frontend are very encouraging, albeit early and preliminary: Solar outperforms Solc at [emitting ABI for Solady by 41x](https://github.com/ithacaxyz/solar/tree/main?tab=readme-ov-file#solar). We also provide a wide [benchmarking suite](https://github.com/ithacaxyz/solar/tree/main/benches) which compares solar with [solang](https://github.com/hyperledger-solang/solang), [slang](https://github.com/NomicFoundation/slang) and [solc](https://github.com/ethereum/solidity), and we outperform them in all lexing and parsing benchmarks. You can use Solar as a parsing library as seen in our [examples here](https://github.com/ithacaxyz/solar/blob/main/examples/src/parser.rs). We intend to use that in Foundry as our first integration point. Solar can also be used as a CLI compatible with solc’s format: `$ solar $(forge re) src/Contract.sol` We built Solar to be easy to extend, so that we can experiment with new bytecode formats, new precompiles, and opcodes, or other features oriented for the future of crypto like interop (e.g. what if the language had async/await or coprocessor support?). We are looking for input on what experiments people would like to see behind unstable flags. There is still a long way to go, beyond parsing and lexing, into the long journey of generating secure and efficient EVM bytecode. ## Solar is early in its roadmap and we are looking for collaborators. We are releasing Solar today to gather community feedback on our approach. Solar follows a modern compiler architecture which separates the frontend from the backend with an intermediate representation (IR) for optimization and for separating the code generation from the language’s frontend. This allows us to scale development by separating concerns. Our roadmap can be found on [Github](https://github.com/ithacaxyz/solar/issues/1), alongside the rest of our code and benchmarks. The frontend is mostly done, and we’re now moving towards the IR and codegen layer. We are excited by existing approaches like [Venom](https://github.com/vyperlang/vyper/tree/fcddb70b6a796757709fa68a36f86ce729d18f77/vyper/venom) or [Sonatina](https://github.com/fe-lang/sonatina/) and see benefits to standardizing and creating a shared middle layer for EVM languages. If you’re a great compiler engineer looking to work on Solar, please reach out to [georgios@paradigm.xyz](mailto:georgios@paradigm.xyz) or [join@ithaca.xyz](mailto:join@ithaca.xyz). ## https://www.paradigm.xyz/writing/pm-amm # pm-AMM: A Uniform AMM for Prediction Markets > Introducing pm-AMM: an automated market maker designed for prediction markets. We introduce a new methodology for deriving AMMs for particular assets, and apply it to prediction market tokens, creating an AMM that may provide more consistent liquidity and reduce the risk of losing everything. ## Introduction In this post, we introduce a new automated market maker (AMM) customized for prediction markets: the **pm-AMM.** AMMs and their predecessors, such as market scoring rules, were originally invented as a way to provide liquidity for prediction markets. They now dominate most decentralized exchange volume in crypto. But ironically, despite prediction market volumes taking off in crypto, *most of it uses orderbooks, not AMMs*. One possible reason is that existing automated market makers are a poor fit for outcome tokens (tokens that resolve to $1 if an event occurs and $0 if it does not occur). The volatility of outcome tokens is dependent on the current probability of the event and the time until the prediction market expires, meaning that the pool provides inconsistent liquidity. Liquidity providers (LPs) are also essentially guaranteed to lose all of their value once the prediction market expires. We present a new AMM optimized around these considerations. This required addressing a longstanding question in AMM research: what does it mean for an AMM to be optimized for a particular type of asset? In other words, given a model for some asset (such as an option, a bond, a stablecoin, or an outcome token), how should that affect what AMM we use for it? We present a possible answer to this question, based on the concept of loss-vs-rebalancing (LVR). ## Contributions We develop a model for the price processes of some outcome tokens, which we call **Gaussian score dynamics**. This model is a potential fit for prediction markets on whether some underlying random walk (such as the score difference of a basketball game, the vote margin in an election, or the price of some asset) will be above some value at a particular future expiration time. We use this model to derive a new invariant-based AMM for those tokens, the **static pm-AMM invariant**: $$ (y - x) \Phi\left( \frac{y - x}{L} \right) + L \phi\left( \frac{y - x}{L} \right) - y = 0, $$ where $x$ is the AMM's reserves of one outcome token, $y$ is its reserves of the opposite, complementary outcome token, $L$ is an overall liquidity or scaling factor, and $\\phi$ and $\\Phi$ are the probability density function and cumulative distribution function of the normal distribution, respectively. To derive this, we make use of the powerful concept of [loss-vs-rebalancing](https://arxiv.org/abs/2208.06046) (LVR), which can be thought of as the rate at which an AMM loses money due to arbitrage. Loss-vs-rebalancing depends on both the shape of the AMM and the price process for the underlying assets traded on it. We define a **uniform AMM** for an asset as the AMM which, if used for that asset, has LVR that is proportional to its portfolio value at an instant of time, regardless of the current price. [Milionis, et al.](https://arxiv.org/abs/2208.06046) establish that constant geometric mean market makers (like [Uniswap](https://app.uniswap.org/whitepaper.pdf) and [Balancer](https://wikibitimg.fx994.com/attach/2021/05/212595670202/WBE212595670202_14467.pdf)) are the unique uniform AMMs for assets whose prices follow geometric Brownian motion (a popular model for the price process of ordinary assets like stocks and cryptocurrencies). The static pm-AMM is a uniform AMM for assets that behave under our model of Gaussian score dynamics for outcome tokens. While the static pm-AMM has uniform LVR (as a fraction of portfolio value) for all prices, LVR will still increase as the expiration of the prediction market approaches. This is because prediction markets can be very volatile near expiry. We show how the pm-AMM can be tweaked to reduce its liquidity over time, so that the AMM’s expected LVR at all moments over the remaining time to expiration is constant. This gives us the **dynamic pm-AMM invariant**, which is dependent on the time to expiration $T - t$: $$ (y - x) \Phi\left( \frac{y - x}{L\sqrt{T - t}} \right) + L\sqrt{T - t} \phi\left( \frac{y - x}{L\sqrt{T-t}} \right) - y = 0. $$ The dynamic pm-AMM isn't magic—it prevents LVR from increasing as expiration approaches by providing a decreasing amount of liquidity. This may not necessarily be desirable on a real pool, particularly because non-arbitrage trading activity (and thus fees) may increase over time as well. But the pm-AMM provides a framework for liquidity providers to adjust their liquidity over time based on expected fees and how they want to allocate their exposure to arbitrage. These AMMs may be useful for bootstrapping passive liquidity on onchain prediction markets. The concept of uniform AMMs, and the methodology for finding them, may also be more widely applicable for decentralized exchange designers looking to customize AMMs for other types of assets whose behavior does not follow geometric Brownian motion, such as stablecoins, bonds, options, or other derivatives. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--37271da913/9f41191deab08a9800907bb2fafb09b8/asset-https-cdn-sanity-io-images-dgybcd83--37271da913.png) Figure 1 shows the invariant curves for the static and dynamic pm-AMMs, compared with other well-known invariant curves, namely for the constant product market maker (CPMM) and logarithmic market scoring rule (LMSR). Note that the reserves curve for the dynamic pm-AMM provides less liquidity over time. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--464e1b0213/5a414996ddbd2a81ac2e8fb169ef5323/asset-https-cdn-sanity-io-images-dgybcd83--464e1b0213.png) Figure 2 shows the [liquidity fingerprint](https://www.paradigm.xyz/2021/06/uniswap-v3-the-universal-amm) of the static pm-AMM, showing what it would look like if the invariant was implemented on a Uniswap v3 concentrated liquidity AMM, as compared to the CPMM and LMSR. The horizontal axis corresponds to ticks in relative price (the price of the $x$ token divided by the price of the $y$ token) on a logarithmic scale, while the vertical axis corresponds to how much liquidity each AMM places at that price level. Notice that relative to both alternatives, the pm-AMM concentrates more liquidity around a relative price of 1 (a probability of 50%, where the tokens' prices are equal at 0.50), and less liquidity at extreme relative prices (either very low or very high). ## Background ### Prediction markets Prediction markets are an increasingly popular application in crypto. [Polymarket](https://polymarket.com/) saw over $2 billion in volume in just October 2024. However, most crypto prediction market liquidity is available on orderbooks, rather than AMMs, despite AMMs being dominant for most other decentralized exchange volume across crypto. One possible reason is that outcome tokens don’t behave like ordinary assets, so AMMs designed for them don’t work very consistently. For example, imagine a prediction market on the result of a game in which someone flips a coin 1,001 times. There are two tokens corresponding to each outcome of this game: $x$ tokens resolve to $1 if there are more heads than tails, and $0 if there are more tails than heads; vice versa for *$y$* tokens. The volatility of these outcome tokens is highly dependent on both the number of flips remaining and the current score. The closer the current score is to even, and the fewer flips remain, the more volatile these tokens will be. This means that the losses of a constant product market maker, which as discussed below are dependent on volatility, will vary wildly over time. ![Figure 3 shows the volatility of the outcome token price process under Gaussian score dynamics—where the event is determined by whether a certain random walk ends up above zero—as a function of the token price and the remaining time.](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--9b5917d343/817cf176985dc4b301c7bb56dc2ae093/asset-https-cdn-sanity-io-images-dgybcd83--9b5917d343.png) *Figure 3 shows the volatility of the outcome token price process under Gaussian score dynamics—where the event is determined by whether a certain random walk ends up above zero—as a function of the token price and the remaining time.* Many popular prediction markets could loosely be thought of as similar to this coin-flipping example—a bet on whether some random walk ends above or below 0 at some future expiration time. For example: - A prediction market on the result of a live basketball game, expiring once the remaining game time hits 0. In this example, the random walk is the score difference between the teams. - A prediction market on the result of a Presidential election, expiring on Election Day. In this example, the random walk could be thought of as the difference in the number of voters who intend to vote for the candidate. - A prediction market on whether the price of an asset like Bitcoin is above a certain strike price on a future date. In this example, the random walk could be the logarithm of the current Bitcoin price minus some strike price. In this post, we define a model for the price evolution of outcome tokens—the **Gaussian score dynamics** model—inspired by examples like these. The model assumes that the prediction market price matches the probability that some underlying Brownian motion ends above 0. This model resembles the Black-Scholes model for a binary option (an instrument that pays out a fixed dollar amount if an asset's price is above some strike price, and $0 if it is not). However, in our model, there is no requirement that the underlying process corresponds to the price of a tradeable asset. We do make the simplifying assumption that the price of the outcome token matches the probability that it resolves to $1. This assumes away important features of the market, including risk and time preferences—examining how those affect this model is a subject for future study. We should also that not all prediction markets are a good fit for the Gaussian score dynamics model, which assumes that the rate at which new information comes out is predictable. For example, basketball games are likely a better fit than soccer games, since scoring is much more frequent, so the evolution of the score differential is more consistent over time. And some types of prediction markets won’t resemble this model at all, such as prediction markets on whether some one-time surprising occurrence (like an earthquake) will occur before a particular date. But this model may be a useful starting place for deriving models for those other dynamics, and can serve as a demonstration of the methodology for deriving uniform AMMs for any model. ### Loss-vs-rebalancing and uniformity After specifying this model, we derive an automated market maker that may be better optimized for these tokens than existing AMMs like the constant product market maker or LMSR. The metric we use as a guide is the rate of expected losses for liquidity providers, which can be characterized as “loss-vs-rebalancing,” or LVR. LVR captures the main adverse selection costs of an AMM: prices on an AMM are static in the absence of trade, and become stale as new information becomes known. LVR captures the costs that AMM liquidity providers suffer as these stale prices are picked off by better informed arbitrageurs who trade against the AMM at prices which are disavantageous for the AMM. Thus, LVR can be viewed as how much the AMM pays to arbitrageurs in order to have its prices corrected. Furthermore, absent trading fees, LVR is also the loss incurred by a liquidity provider who delta-hedges their LP position by separately holding a short position in the exact same quantity of the tokens owned as part of the pool reserves. In this way, LVR builds on the main insight of the famous Black-Scholes model for option pricing: just as an option is valued by delta-hedging with the underlying asset to remove market risk, LVR values an LP position in an AMM once the market risk is removed. That is, LVR isolates what is special about being a liquidity provider in an AMM, versus simply taking the market risk of holding the same tokens as the AMM reserves. We consider simple invariant-based AMMs, with no fees or MEV-recapturing mechanisms. In this context, the AMM is *guaranteed* to lose money due to arbitrage—no AMM invariant can eliminate LVR (other than one that results in no trading at all). Even “minimizing” LVR doesn’t really make sense here: reducing LVR would just mean reducing the liquidity provided. But we can make LVR more consistent, so that the percentage of the pool value that is lost does not depend on the current price of the asset. We call this property *uniformity*. One way to motivate the value of uniformity is to imagine a sponsor who is willing to provide liquidity on some zero-fee prediction market in order to learn the market's prediction about the outcome. This to lose money, but would naturally prefer to spread out their losses evenly, rather than concentrating their losses at a particular time or at particular prices. In this case, the current portfolio value of the pool can be thought of as the sponsor’s “budget.” On a uniform AMM, if the sponsor puts in $1 of liquidity at some time, their expected losses in the next timestep are independent of the current state of the pool. But uniformity is potentially relevant for profit-seeking liquidity providers as well. Even if an AMM is able to capture some of its loss-vs-rebalancing or even turn a profit (from non-zero swap fees, or through auction mechanisms like [MEV taxes](https://www.paradigm.xyz/2024/06/priority-is-all-you-need)), it still needs some strategy for how to allocate its liquidity at different prices and different times. We might think of expected losses for the zero-fee pool as one way to measure how much liquidity the strategy is allocating at a particular time, in a way that takes into account the price process of the asset. We define a **uniform AMM** for a particular asset as an AMM whose expected LVR is a constant fraction of the value of the current value of the pool, regardless of the current price of the asset. Note that whether an AMM has uniform LVR depends on the price process of the asset itself. As shown in Appendix B.2 of [Milionis, et al.](https://arxiv.org/pdf/2208.06046), if the price of an asset follows geometric Brownian motion, then the essentially unique uniform AMM between that asset and the numéraire is the weighted geometric mean market maker with invariant $x^{\\theta} y^{1 - \\theta} = L$, for $\\theta\\in (0,1)$. This is the formula used in Balancer, and the constant product market maker used in Uniswap v2 is a special case of it. But constant-geometric-mean AMMs do not have uniform LVR for tokens that follow Gaussian score dynamics. Nor does the logarithmic market score rule (LMSR), an AMM that was originally developed for prediction markets. Figure 4 shows the LVR experienced by the CPMM and LMSR when used for outcome tokens with Gaussian score dynamics at time $T - t = 1$, compared to the uniform LVR of the static pm-AMM: ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--f446b80de1/e8c8a687c88d9af62374c8ef6b198a9b/asset-https-cdn-sanity-io-images-dgybcd83--f446b80de1.png) Motivated by these concerns, we develop two AMMs that are designed for prediction markets under Gaussian score dynamics—one that has uniform LVR at any given time but increasing LVR as the prediction market's expiration approaches, and one that has uniform LVR and constant expected LVR over the remaining time horizon. As can be seen in Figure 4, the CPMM and LMSR suffer large LVR (as a fraction of pool value) when the outcome token price is at an extreme, close to zero or one. This is because, while price volatility is low around those points (cf. Figure 3), the pool value decays even faster at extreme prices. Hence, a uniform AMM should provide less liquidity at extreme prices, which is what the pm-AMM design does (cf. Figure 2). ## Prior work AMMs have their origin in the world of prediction markets and market scoring rules, such as the[ logarithmic market scoring rule (LMSR)](https://mason.gmu.edu/~rhanson/mktscore.pdf). These rules motivated the discovery of constant function market makers (CFMMs), such as [Uniswap v2](https://app.uniswap.org/whitepaper.pdf), which are often characterized by an invariant relationship between the AMM's reserves of each asset. AMMs based on this design have emerged in recent years as the dominant market mechanism for decentralized exchange on blockchains. More recently, ideas from financial economics have been applied to understand the costs of automated market making, in the form of loss-versus-rebalancing, or LVR, as discussed in [Milionis, et al.](https://arxiv.org/pdf/2208.06046) LVR captures the losses incurred by an AMM to arbitrageurs due to stale prices. That paper considers assets whose dynamics follow diffusion processes, primarily focusing on geometric Brownian motion. Prediction markets, on the other hand, have very different price dynamics because of their bounded payoffs and finite horizons. [Taleb](https://arxiv.org/pdf/1703.06351) proposes dynamics based on an underlying and observable polling process, while we develop an alternative form of dynamics, based on an underlying and observable Gaussian score process. There has been some prior applied work on designing automated market makers for non-GBM assets. One example is [StableSwap](https://docs.curve.fi/assets/pdf/stableswap-paper.pdf), an AMM designed for stablecoin pairs, which is based on the intuitive premise that AMMs between correlated and mean-reverting assets should involve concentrating liquidity closely at a single price, but its derivation does not involve modeling the assets' price processes. Another is [YieldSpace](https://yield.is/YieldSpace.pdf), an AMM designed for zero-coupon bonds. While the derivation of YieldSpace does involve a simple model for the pricing of zero-coupon bonds as a function of interest rates, it does not include a full model for the price process (since it does not model the evolution of interest rates), and the paper makes a largely arbitrary choice for how the interest rate should be inferred from the current reserves. There has also been some academic work on designing AMMs based around beliefs about how asset prices will behave. One example is [Goyal et al.](https://arxiv.org/pdf/2212.03340) Their framework is designed around maximizing the amount of liquidity that is expected to be active, rather than making expected losses uniform, and as a result sometimes reaches opposite implications from ours. For example, their paper suggests that LMSR (which, relative to the CPMM, concentrates liquidity around the price of 1) is a good fit if liquidity providers expect relative asset prices to remain around 1, whereas our framework suggests that there are reasons to concentrate liquidity around 1 if you expect prices to diverge (as with outcome tokens). ## Model **Automated market making**. We consider a prediction market on a single event of interest, and an AMM which trades two assets against each other: a risky asset (denoted by $x$) that pays one dollar if the event occurs and nothing otherwise, and another risky asset (denoted by $y$) with opposite payments. The AMM maintains an invariant $f(x,y) = L$, where $f(\\cdot,\\cdot)$ is the invariant function of the reserves $(x,y)$, and $L$ is a constant. Given a price $P$ for the $x$ asset (in terms of dollars), define the *pool value function* to be $$ \begin{array}{lll} V (P) \triangleq & \underset{(x,y)\in \mathbb{R}_{+}^{2}}{\text{minimize}} & Px+(1-P)y \\ & \text{subject to} & f(x,y)=L. \end{array} \quad\quad \tag{1} $$ This is the value of the pool when the $x$ price is $P$. Since holding one unit of the $x$ and $y$ assets each is equivalent to holding cash, we must have the price of the $y$ be $1 - P$. We assume that there is a population of arbitrageurs who, at each time $t$, can observe the price $P_t$ of the $x$ asset (and also the price $1 - P_t$ of the $y$ asset). Assuming there are no trading fees or other frictions, these arbitrageurs continuously monitor the AMM and seek to extract value from any mispricing of the AMM. When maximizing their own profits, they trade against the AMM to minimize the value of the AMM reserves. If we denote by $V_t$ the value of the reserves at time $t$ (when the price is $P_t$), then we must have $V_t = V(P_t)$. **Example 1** (Constant Product Market Maker). In the case of a constant product market maker (CPMM), where the invariant function is given by $f(x,y) ≜ \\sqrt{xy}$, the pool value function is given by $$ V(P) = 2L \sqrt{P(1-P)}. $$ **Example 2** (Logarithmic Market Scoring Rule). The [logarithmic market scoring rule](https://mason.gmu.edu/~rhanson/mktscore.pdf) (LMSR) created by Robin Hanson [can be viewed as](https://www.paradigm.xyz/2021/06/uniswap-v3-the-universal-amm#d9efe5234233) an AMM satisfying the invariant $f(x,y) ≜ 2^{-x/L} + 2^{-y/L} = 1$, in which case the pool value function is given by $$ V(P) = -L \left\{ P \log_2 P + (1 - P) \log_2 (1 - P) \right\}, $$ which is proportional to the binary entropy of the event implied by the price. Denote by $x^\*(P)$ and $y^\*(P)$ to be the optimal solution to the optimization problem (1), we assume that these exist, are unique, and are sufficiently smooth functions of the price $P$. The following is analogous to Lemma 1 of [Milionis, et al.](https://arxiv.org/pdf/2208.06046), but adapted to the present setting: **Lemma 1**. For all prices $P ≥ 0$, the pool value function satisfies: *1.* $V'(P)=x^{\*}(P) - y^\*(P).$ *2.* $V''(P)=x^{\*\\prime}(P) - y^{\*\\prime}(P)\\leq0.$ **Gaussian score dynamics**. We now describe how the risky asset prices evolve over time according to what we call *Gaussian score dynamics*. In particular, we assume there exists a stochastic process $\\{ Z_t\\}$ over the time interval $t \\in \[0,T\]$, where the event is determined by the sign of $Z_t$ at the end time of the horizon $t=T$: if $Z_T \\geq 0$, the $x$ asset pays off, otherwise if $Z_T < 0$ the $y$ asset pays off. We can interpret $Z_t$ as the score differential between two teams in a bilateral competition. Hence, we will call $Z_t$ the score process. Note that while our model assumes the existence of this score process, the score process does not need to be directly observable by the AMM. As discussed below, the AMM can infer the current value of the score from the marginal price (after being arbitraged) and the time to maturity. We assume that $Z_t$ follows a random walk. Specifically, we assume that $Z_t$ is a Brownian motion with volatity $\\sigma > 0$, i.e., $$ dZ_t = \sigma \, dB_t, $$ where $B_t$ is a standard Brownian motion. Then, it is easy to see that the price $P_t$ of the $x$ asset at time $t$ must be given by $$ P_t = \mathbb{E}\left[\left. \mathbb{I}_{\{Z_T > 0\}} \ \right| \ Z_t \right] = \Phi\left( \frac{Z_t}{\sigma \sqrt{T-t}} \right), $$ where $\\Phi(\\cdot)$ is the standard normal cumulative distribution function (CDF). Applying Itô's lemma, $P_t$ must satisfy $$ dP_t = \phi\left( \frac{Z_t}{\sigma\sqrt{T-t}} \right) \frac{dZ_t}{\sigma\sqrt{T-t}} = \frac{ \phi\left( \Phi^{-1}\left( P_t \right) \right) }{\sqrt{T-t}} \, dB_t, $$ where $\\phi(\\cdot)$ is the standard normal probability density function, and $\\Phi^{-1}(\\cdot)$ is the inverse CDF. Observe that, while the score dynamics and the conversion of a score to price or versa depend on $\\sigma$, the dynamics of price process $P_t$ in isolation do not depend on $\\sigma$. The volatility of these dynamics, as a function of price and remaining time, can be seen in Figure 3. ## Uniform AMMs **Loss-versus-rebalancing.** From the discussion above, if we denote by $V_t$ the value of the reserves at time $t$ (when the price is $P_t$), then we must have $V_t = V(P_t)$. Applying Itô’s lemma, we have that the pool value evolves according to: $$ \begin{array}{ll} dV_t & = \tfrac{1}{2} V''(P_t) \, (dP_t)^2 + V'(P_t) \, dP_t \\ & = \displaystyle \tfrac{1}{2} \frac{ \phi\left( \Phi^{-1}\left( P_t \right) \right)^2 }{T-t} V''(P_t) \, dt + \big(x^{*}(P_t) - y^{*}(P_t) \big) \, dP_t. \end{array} \quad\quad \tag{2} $$ Since the price $P_t$ is a martingale, the second term of (2) is also a martingale, and could be increasing or decreasing. However, from the concavity of $V(\\cdot)$ (cf. Lemma 1), the first term corresponds to a negative drift and hence to a decreasing process. This is the loss-versus-rebalancing process (LVR) of [Milionis, et al.](https://arxiv.org/abs/2208.06046), and it captures the value the pool loses to arbitrageurs who trade against it at disadvantageous prices. We define the instantaneous rate of this loss by $$ \mathsf{LVR}_t ≜- \tfrac{1}{2} \frac{ \phi\left( \Phi^{-1}\left( P_t \right) \right)^2 }{T-t} V''(P_t) \geq 0. \quad\quad \tag{3} $$ **Uniform AMM**. A *uniform AMM *is a pool which loses money at a constant rate proportional to it’s value, i.e., $\\text{LVR}_t = \\alpha V_t$ , for some constant $\\alpha > 0$. For example, [Milionis, et al.](https://arxiv.org/abs/2208.06046) establish that, for assets following geometric Brownian motion, essentially the only uniform AMMs are geometric mean market makers. In the case of a prediction market under Gaussian score dynamics, examining (3), a uniform LVR pool must solve the ordinary differential equation $$ - \tfrac{1}{2} \frac{ \phi\left( \Phi^{-1}\left( P \right) \right)^2 }{T-t} V''(P) = \alpha V(P). $$ This is not possible, since the left side depends on $t$, while the right side does not. The core issue here is that, unlike geometric Brownian motion, whose dynamics are invariant across time, Gaussian score dynamics are highly time dependent. To circumvent this issue, we allow $\\alpha$ to be time dependent, i.e., we set $\\alpha = \\beta / (T -t)$, for some $\\beta > 0$, and now consider a setting where $$ \mathsf{LVR}_t = \beta \frac{V_t}{T- t} $$ This is equivalent to the ODE $$ \phi\left(\Phi^{-1}(P)\right)^2 V''(P) + 2 \beta V(P) = 0, \quad\quad \tag{4} $$ for $P \\geq 0$. In addition, there are are additional requirements on $V(\\cdot)$ such that it is a valid pool value function, for example that $V''(P) \\leq 0$ (cf. Lemma 1). ## Static pm-AMM **Pool definition.** The above ODE can be simplified through the change of variables $u=\\Phi^{-1}(P)$. When $\\beta = 1/2$, there is a solution satisfying both the ODE and the additional concavity requirements, and it is given by $$ V(P) = L \phi\left( \Phi^{-1}(P) \right), $$ with reserves given by $$ x^*(P) = L \left\{ \Phi^{-1}(P) P + \phi\left( \Phi^{-1}(P) \right) - \Phi^{-1}(P) \right\}, \quad\quad \tag{5} $$ $$ y^*(P) = L \left\{ \Phi^{-1}(P) P + \phi\left( \Phi^{-1}(P) \right) \right\}. \quad\quad \tag{6} $$ Here, $L \\geq 0$ is a liquidity parameter that determines the scaling of the pool size. Observing that $y^\*(P) - x^\*(P) = L \\Phi^{-1}(P)$ and substituting that into (5), the pool reserves $(x,y)$ must satisfy the invariant $$ (y - x) \Phi\left( \frac{y - x}{L} \right) + L \phi\left( \frac{y - x}{L} \right) - y = 0. $$ This defines the *static pm-AMM*. (This name alludes to the time varying, dynamic variation of the pm-AMM we will discuss shortly.) By design, this AMM satisfies the relationship $$ \mathsf{LVR}_t = \frac{V_t}{2 (T - t)}. $$ Defining $\\bar{V}_t = \\mathbb{E}\[V_t\] $ to be the expected pool value, from (2) we have that $$ \frac{d\bar{V}_t}{dt} = - \frac{\bar{V}_t}{2(T - t)}. $$ Solving this ODE, $$ \bar{V}_t = V_0 \sqrt{\frac{T-t}{T}}. $$ In other words, in expectation, the static pm-AMM pool value decays according to the square root of the remaining time horizon. ## Dynamic pm-AMM One downside of the static pm-AMM is that, while its LVR per dollar of value is uniform over all possible *prices*, it changes over *time*. In particular, loss per dollar of value is inversely proportional to the time to maturity, so it will increase over time until losing all of its value by maturity **Dynamic liquidity**. We imagine now a dynamic, time-varying variation of the static pm-AMM design where the AMM LPs withdraw liquidity over time to mitigate their losses. In particular, assume that the pool value is given by $$ V(P,t) = L_t \phi\left( \Phi^{-1}(P) \right), $$ where $L_t$ is a deterministic, smooth function that determines how much liquidity is removed (or possibly added) over time. Applying Itô's lemma to the pool value process $V_t$, $$ \begin{array}{ll} dV_t & = \partial_t V(P_t, t) + \tfrac{1}{2} \partial_{PP} V(P_t, t) \, (dP_t)^2 + \partial_P V(P_t, t) \, dP_t \\ & \displaystyle = \left( \dot{L}_t \phi\left( \Phi^{-1}(P) \right) - \frac{L_t}{2(T-t)} \phi\left( \Phi^{-1}(P) \right) \right) \, dt \\ & \quad + \big(x^{*}(P_t) - y^{*}(P_t) \big) \, dP_t \\ & \displaystyle = \left( \frac{\dot{L}_t}{L_t} - \frac{1}{2(T-t)} \right) V_t \, dt + \big(x^{*}(P_t) - y^{*}(P_t) \big) \, dP_t. \end{array} \quad\quad \tag{7} $$ Denote by $C_t$ the cumulative dollar value of liquidity withdrawn. Then, since the pool value is linear in the liquidity $L_t$ , the dollar value of a change in $L_t$is proportional to $V_t/L_T$ . Then, we have that $$ dC_t = - \frac{\dot L_t}{L_t} V_t \, dt. $$ The AMM LPs’ total wealth $W_t$t consists of the value of the pool reserves plus the cumulative value of the liquidity withdrawn, so that $W_t = V_t + C_t$ , and this satisfies $$ dW_t = dV_t + dC_t = -\frac{1}{2(T-t)} V_t \, dt + \big(x^{*}(P_t) - y^{*}(P_t) \big) \, dP_t. $$ This implies that the expected LP wealth $\\bar{W}_t ≜ \\mathbb{E}\[W_t\] $ satisfies $$ \bar{W}_t = W_0 - \int_0^t \frac{\bar{V}_s}{2(T-s)} \, ds, \quad\quad \tag{8} $$ where $\\bar{V}_t ≜ {E}\[V_T\].$ **Constant LVR.** Now, consider the specific choice of liquidity curve given $$ L_t = L_0 \sqrt{T - t}. $$ We call the the dynamic pm-AMM. Then, from (7), the expected pool value $\\bar{V}_t = E\[V_t\]$ satisfies $$ \frac{d \bar{V}_t}{dt} = \left( \frac{\dot{L}_t}{L_t} - \frac{1}{2(T-t)} \right) \bar{V}_t = - \frac{\bar{V}_t}{T - t}. $$ Solving this ODE, we have $$ \bar{V}_t = V_0 \, \frac{T-t}{T}. $$ In other words, net of withdrawals, the expected pool value decreases linearly in the dynamic pm-AMM. Further, because it inherits the static pm-AMM value function, the rate of LVR loss per unit time is given by $$ \mathsf{LVR}_t = \frac{1}{2(T-t)} V_t. $$ Then, the expected rate of loss is $$ \mathbb{E}[\mathsf{LVR}_t] = \frac{1}{2(T-t)} \bar{V}_t = \frac{V_0}{2T}, $$ which is constant over $t$. That is, the dynamic pm-AMM loses money to arbitrageurs at a constant rate (in expectation) over time. Finally, following (8), this results in an expected wealth process $$ \bar{W}_T = W_0 - \int_0^T \frac{V_0}{2T} \, dt = W_0 - \frac{V_0}{2} = \frac{W_0}{2}, $$ so that half the initial wealth is lost by the end. ## Conclusion The pm-AMM may be useful for prediction markets driven by dynamics that resemble the Gaussian score dynamics model. Beyond this, our work suggests that uniform AMMs may be derivable for other kinds of assets, like bonds, options, and other derivatives. ## Acknowledgements The authors wish to thank Benedict Brady, Leo Lau, Allan Niemerg, Storm Slivkoff, Shouqiao Wang, Dave White, and Bill Zhang for helpful comments. ## https://www.paradigm.xyz/writing/october-polling # October 2024 Public Opinion Poll > Crypto will matter at the ballot box this November. Our October poll, the last of our election series, confirms it: a surprising percentage of American voters identify themselves as single issue crypto voters. Updated on November 21, 2024: For our final poll of this election cycle, we partnered with Public Opinion Strategies to take the public’s pulse on Election Day a few weeks ago. Here’s what we found: ### Takeaway 1: Democrats had a chance to persuade crypto owners, but failed. - 21% of crypto owners decided who to vote for in the last few days before the election - Additionally, nearly 50% of crypto owners voted on election day. - Democrats had a real opportunity to win over crypto voters into the last few days of the campaign but were not able to, likely in part due to internal division within the party over whether to be clearly pro-crypto. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--fa4fe7a613/9ec180ee853b54cdbb798c5a4f68a5ea/asset-https-cdn-sanity-io-images-dgybcd83--fa4fe7a613.png) ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--19f4e31f2b/45ce50842091467dfbe28d80b15b7a9c/asset-https-cdn-sanity-io-images-dgybcd83--19f4e31f2b.png) ### Takeaway 2: Crypto owners contributed to Trump’s popular vote victory. - 86% of voters say they are not current crypto owners - they voted for Harris 49-49 - 13% of voters say they are currently crypto owners - they voted for Trump 55-42 - Crypto owners provided Trump with more votes than the margin of difference in the popular vote in this election. - We believe that even more voters who have *previously* owned crypto added to this margin. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--e68cee329f/10ebff243ee48985b3e66cb49ed6329c/asset-https-cdn-sanity-io-images-dgybcd83--e68cee329f.png) ### Takeaway 3: Crypto owners leaned Republican this election. - Non-crypto owners split 49-49 between Democrats and Republicans for Congress - Crypto owners voted for Republicans over Democrats by 13%, 55-42 ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--e38bf752ba/f22cd295c9ad9866aab21da97481a4a5/asset-https-cdn-sanity-io-images-dgybcd83--e38bf752ba.png) *This poll of 800 voters in the 2024 general election was conducted by Public Opinion Strategies on the evening of November 5, 2024, with all respondents contacted by phone. It has a margin of error of 3.46%.* Original post from October 30, 2024 Crypto will matter at the ballot box this November. That’s the major lesson from our October 2024 poll, our last full poll of this cycle. Five percent of voters identify themselves as single-issue crypto voters, and crypto owners could easily be the margin of victory or defeat in this seemingly razor-thin election. Meanwhile, the views of crypto among the American electorate continue to expand and mature, and voters increasingly see crypto as a major part of their lives in the future. ### Takeaway 1: 1/4 of those who have bought or own crypto describe themselves as single issue crypto voters - We asked the 20% of voters who have bought crypto the following question: “Would you say you are a single-issue crypto voter, in that government policy on crypto is the most important policy you consider when selecting a candidate for office?” - ¼ of that group, 5% of all voters, describe themselves as single-issue crypto voters. - This includes 11% of voters 18-34, 8% of men, and 7% of non white voters (including 7% of black and 8% of Hispanic voters). - In an election where the [key tipping point states](https://projects.fivethirtyeight.com/polls/president-general/) like Pennsylvania, Michigan, Wisconsin, and Georgia are all likely to be decided by 1-2 points, 5% of voters is more than the margin of victory. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--e534e0975a/6f6c5c89a6b3201109b390ea4e75b898/asset-https-cdn-sanity-io-images-dgybcd83--e534e0975a.png) ### Takeaway 2: Crypto Ownership looks likely to continue to grow - As of this month, 20% of voters say they have invested in, traded, or used a cryptocurrency such as Bitcoin or Ethereum, and another 15% say they are likely to invest in crypto in the next year. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--e777a38913/75dfd857530bdc7051dc9e168be42452/asset-https-cdn-sanity-io-images-dgybcd83--e777a38913.png) - These numbers rise to 21% and 18% among independent voters. - 1% of voters say they have first invested in crypto in the last few weeks, including 3% of independent voters ## Takeaway 3: Crypto ownership continues to skew younger, nonwhite, and male. - 29% of men have bought crypto, while 12% of women have bought crypto. - Much like our March poll, 40% of men 18-54 have bought crypto, along with 16% of women 18-34 and 19% of women 35-54. - The percentage of non-white voters who have bought crypto was lower in this poll than our previous poll, at 23%, while the percentage of white voters who have bought crypto was higher than before, at 19%. - This matches the [demographic profile](https://www.cnn.com/2024/10/22/politics/changing-electorate-trump-harris-analysis/index.html) of the key [swing](https://www.npr.org/2024/10/23/nx-s1-5159881/kamala-harris-young-voters-poll) voters both the Harris and Trump campaigns say they are fighting over in the final weeks of this election. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--defd949480/f00f0d72d0586e246b54537287738324/asset-https-cdn-sanity-io-images-dgybcd83--defd949480.png) ### Takeaway 4: Crypto owners may be the decisive margin in this election - Among all voters polled, 48% are backing Vice President Kamala Harris for president, while 46% are backing former President Donald Trump. - However, these results nominally diverge between voters who have bought crypto and those who have not bought crypto. Among voters who have not bought crypto, Harris leads 48% to 45%. Among the 20% of voters who have bought crypto, the candidates are tied at 47%. These changes are within the margin of error of course. - We know that the small number of votes that may decide this election, and it is probable that the popular vote margin will be approximately 2-3% more Democratic leaning that the state worth the 270th electoral vote. - As a result, Trump performing a few points better among crypto owners could be the margin of victory in this year’s election. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--1ba2ab2dbb/caa784c735c71db6269791f14c9a9326/asset-https-cdn-sanity-io-images-dgybcd83--1ba2ab2dbb.png) ### Takeaway 5: Voters increasingly trust the Republican Party on crypto policy over the Democratic Party - In March, we asked voters “Which party do you trust more when it comes to cryptocurrency?” 25% said the Democratic Party, 24% said the Republican Party, 3% said both, and 49% said neither. - Now, over six months later, we asked that question again. 30% of voters now say they trust the Republican Party more, while 24% said they trust the Democratic Party more, with 5% saying both and 41% saying neither. - Independents remain up for grabs, with 9% saying they trust the Republican Party, 10% trusting the Democratic Party, and 72% saying they trust neither. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--870dfc90ef/c1e3ffaf24850586e21041242a956087/asset-https-cdn-sanity-io-images-dgybcd83--870dfc90ef.png) ### Takeaway 6: Americans increasingly expect crypto to be part of their daily lives in the future. - When asked whether they think cryptocurrency will be a passing fad or a major part of the economy in the long term, 46% of voters and 47% of independent voters said it would be a major part of the economy in the long term. - Given that only 20% of voters have bought crypto, these figures reveal that even tens of millions of voters who have not yet directly purchased crypto see it as a major part of American life going forward. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--0d08cbb708/d49389c6a71de2632d54f8b3662121d7/asset-https-cdn-sanity-io-images-dgybcd83--0d08cbb708.png) ### Takeaway 7: Crypto owners lean towards thinking Trump will be better for crypto. - We asked voters who have bought crypto “Who do you think would be a better President for the growth and regulation of cryptocurrency?” - 58% of voters who have bought crypto (12% of voters overall) answered that Donald Trump would be better, while 42% of voters who bought crypto (just under 9% of voters) answered that Kamala Harris would be better. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--83a188bc5a/0e0274dc863291e21911bfc2b7fb20e2/asset-https-cdn-sanity-io-images-dgybcd83--83a188bc5a.png) - Further underscoring the complexity of crypto voters, 7% of voters who have bought crypto (a little over 1% of voters overall) said they believe Trump would be better but are voting for Harris, while 2% of voters who have bought crypto (less than 1% of voters overall) said they believe Harris would be better but are voting for Trump. ### Takeaway 8: Voters’ views of the Biden Administration’s approach to crypto and tech policy generally remain negative, but voters are more positive about a Trump or Harris Administration. - We asked voters: “Thinking about the Biden administration's policies on technology and cryptocurrency, would you say the administration's policies have been good for American innovation, or been bad for American innovation?” 49% of voters said they were very good or somewhat good, while 51% of voters said they were very bad or somewhat bad. - Among independents, views were more skewed to the negative, with 54% saying they were very bad or somewhat bad. Just 11% of voters and 6% of independent voters said the policies were very good. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--b6bad2cd38/55838db258a21b21926789459e3d8f7d/asset-https-cdn-sanity-io-images-dgybcd83--b6bad2cd38.png) - We also asked how people would rate how strongly they think Donald Trump or Kamala Harris cares about American innovation on a scale of 1 to 10, with 10 being an extremely great deal. Voters estimated both Harris and Trump as rating at a 5.5 on this question, with independents rating both at a 5.1. - Taken collectively, voters appear to see both Harris and Trump as leading an administration that is more positive on tech and innovation than the Biden Administration has been. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--b5daff6aea/b1444d3ca791b702b307e46b1a1156c5/asset-https-cdn-sanity-io-images-dgybcd83--b5daff6aea.png) ### Takeaway 9: People are becoming more aware of DeFi. - We asked whether poll respondents had heard of “Decentralized Finance or DeFi,” and a majority of American voters, 53%, said they had heard of the term. - Views of DeFi are not yet firm, however. Only 10% of voters said they had a favorable opinion of DeFi, while 16% said they had an unfavorable opinion and 27% said they had no opinion. - Independent voters’ views of DeFi are nearly even more closely split, with 11% having a positive opinion of DeFi, 13% having a negative opinion, and 30% having no opinion. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--b60f1e8069/8255495feb73dfb64629e3878529d625/asset-https-cdn-sanity-io-images-dgybcd83--b60f1e8069.png) Paradigm conducted a national survey using the Dynata online panel from October 17 to 22. Quotas were set and weights were applied by age, gender, education, and ethnicity to be reflective of the likely November 2024 electorate. Trend data is from previous surveys conducted by Paradigm also using the Dynata online panel. Sample size = 1000 likely voters polled online with a margin of error of 3.53%, along with an oversample of 247 independent voters with a margin of error of 7.11%. For political observers, we found that Democrats led the generic congressional ballot 44-43, 44% of respondents self-identified as Republicans and 42% self-identified as Democrats, and President Joe Biden’s job approval is underwater at 41-59. Harris leads Trump nationally 48% to 46%; among independent voters, Harris leads 42% to 30%. ## https://www.paradigm.xyz/writing/beba-amicus # Paradigm Provides Amicus Support for DEF and Beba’s Lawsuit Against the SEC > Paradigm and other investors file amicus brief supporting DEF and Beba's lawsuit against the SEC Imagine you are an entrepreneur preparing to do a token airdrop. Amid the myriad operational and logistical questions you must consider, you are struggling on something more abstract: can a free token airdrop be considered an investment contract under *Howey*? On the one hand, the law seems clear that since *Howey* requires an investment of money, your free token airdrop doesn’t meet the requirements of an investment contract. But you might be filled with FUD given the SEC’s enforcement actions against other projects that have given something away for free. Since you know the SEC won’t provide you with clarity absent judicial intervention, you spend the time and expense on the last option available: a lawsuit demanding clarity. But instead of engaging with your arguments, the SEC argues that the lawsuit cannot proceed because there is no credible threat of enforcement against you. For a moment, you think to yourself that you may have cracked the code on obtaining regulatory clarity. If there’s no credible threat against you, then you can go ahead with the airdrop you have been planning! Wrong. You realize that somehow the SEC is arguing there is no credible threat against you so your case should be dismissed – but it also provides no assurance that your free airdrop is not an investment contract or that you are safe from enforcement. You are trapped in a bureaucratic nightmare that would seem over-the-top even for Kafka - efforts to get clarity are met with only a greater refusal by the SEC to give it. This absurdist regulatory approach to crypto is why Paradigm, along with other investors, filed an [amicus brief](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-2a86194b4d/8a646d8213daf12a5bb98b29a917d0ed/asset-https-cdn-sanity-io-files-dgybcd83-p-2a86194b4d.pdf) today supporting Beba and the DeFi Education Fund (“DEF”) in their lawsuit against the SEC. Beba is a Waco, Texas-based company that sells duffel bags, backpacks, and wallets and has previously utilized a free token airdrop to market its products. Its fear of enforcement by the SEC has prevented it from launching its next free airdrop and it seeks a declaratory judgment that it may proceed without being prosecuted. Along with DEF, Beba also argues that the SEC’s de facto rule that the vast majority of digital assets are securities violates the Administrative Procedure Act. We know from first hand experience that Beba’s experience is not unique – it is the common experience of the average crypto founder. Even where the law is clear that enforcement is not warranted, many live in fear of enforcement and even choose not to serve US customers or offer them the benefits that they offer offshore customers. Our amicus brief argues that the SEC cannot continue having it both ways, meeting good faith questions with deflection but hitting efforts to operate in crypto with repressive enforcement actions. We urge the court to let Beba and DEF’s challenge be heard on the merits. ## https://www.paradigm.xyz/writing/ithaca # Introducing Ithaca > We are excited to announce Paradigm’s $20M investment in Ithaca, a new company with the mission to accelerate crypto development across the entire stack. We are excited to announce Paradigm’s $20M investment in Ithaca, a new company with the mission to accelerate crypto development across the entire stack. See [Ithaca’s announcement](https://www.ithaca.xyz/) for more. Ithaca will help advance the crypto frontier while ensuring that great developers can continue to work on important open-source public goods within crypto. The Ithaca team will be composed of the lead contributors and maintainers of the above open-source projects. Georgios will continue his role as Paradigm’s CTO and General Partner, and lead the Ithaca team as CEO. Matt Huang will be joining as Chairman. Paradigm will continue to fund and support open-source projects, and the Ithaca team will continue to contribute to and maintain them. We believe free, open-source, public goods are important to moving the whole crypto space forward. We are tremendously excited to be a part of the mission to bring crypto forward with everyone else pushing the frontier. The odyssey to Ithaca is just starting. ## https://www.paradigm.xyz/writing/unichain # Unichain > Unichain is an optimistic rollup optimized for efficient markets by delivering fast state updates, offering a framework for applications to internalize MEV, and providing an economic finality system for quick settlement across blockchains. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--fceccce716/dcbbb4323806d375bf9fb9f8ae71ad21/asset-https-cdn-sanity-io-images-dgybcd83--fceccce716.png) Read the whitepaper here: [PDF](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-1f86517b32/1d573dde2814b35c1929de8aa3970a21/asset-https-cdn-sanity-io-files-dgybcd83-p-1f86517b32.pdf). # Abstract Unichain is an optimistic rollup optimized for efficient markets by delivering fast state updates, offering a framework for applications to internalize MEV, and providing an economic finality system for quick settlement across blockchains. ## https://www.paradigm.xyz/writing/removing-the-relays # How to Remove the Relay > MEV-Boost, the current sidecar protocol for MEV extraction in Ethereum, relies heavily on centralized actors called relays. Using a novel form of silent threshold encryption, a non-interactive construction that can leverage validators' existing BLS keypairs, we propose an alternative architecture that allows builders and proposers to communicate directly, with purely cryptographic privacy assumptions. MEV-Boost, the current sidecar protocol for MEV extraction in Ethereum, relies heavily on centralized actors called relays. We propose an alternative architecture that allows for direct, cryptographically private communication between builders and proposers. It is based on a novel, non-interactive form of "silent" threshold encryption that can use validators' existing BLS keypairs. Essentially, we piggyback on the attestation committee for privacy and data availability by threshold encrypting block proposals to a fraction of attesters for the slot. Their attestations form the decryption key; once the desired threshold has attested, the block can be decrypted. Our construction addresses privacy between builders and proposers but does not alone guarantee block validity. It can be combined with other mechanisms to fully replicate the functionalities provided by relays—both privacy and block validity. For example, proof schemes like Trusted Execution Environment (TEE) proofs or Zero-Knowledge (ZK) proofs, or cryptoeconomic mechanisms to collateralize builders. By removing the need for relays to provide builder privacy and ensure block validity, we aim to reduce latency and improve Ethereum's decentralization and censorship resistance. ## MEV-Boost and the Role of Relays MEV-Boost is a sidecar protocol that intermediates between block builders and proposers. The [main role](https://ethresear.ch/t/relays-in-a-post-epbs-world/16278#h-2-relay-roles-today-3) of the relay is to provide two guarantees: 1. **Privacy for Builders**: The relay ensures that proposers cannot see block contents and steal the MEV found by the builder. 2. **Safety for Proposers:** The relay guarantees that the builder pays the value promised to the proposer in the builder's bid and that the block is valid (e.g., all transactions pay intrinsic gas). The reliance on relays, however, introduces significant centralization. Approximately 90% of blocks on Ethereum are delivered through just a handful of relays. This poses a few risks: - **Centralization**: Builders can be latency-efficient by colocating with relays rather than reflecting the geographic distribution of proposers. This directly undermines the geographic decentralization and censorship resistance we would otherwise gain from a large, globally distributed validator set. - **Revenue**: The average end-to-end block processing latency of efficient relays is around 5-20 milliseconds. Then, there is communication latency between the proposer and builder. Skipping relays will reduce latency, lower cross-domain execution risks (e.g. CEX/DEX), and ultimately increase proposers' MEV rewards. ## TEE-Boost One of the leading proposals to replace relays is "[TEE-Boost](https://collective.flashbots.net/t/tee-boost/3741)", which relies on TEEs (Trusted Execution Environments). Note that TEEs are not essential to our scheme; it's just helpful to use TEE-Boost as a pedagogical example of the problems we aim to solve. Concretely, TEE-Boost has builders use TEEs to create proofs that demonstrate to proposers the honesty of their bids and the validity of their blocks without revealing the actual block contents to proposers. Proposers can check these proofs without running TEEs themselves on commodity hardware. However, TEE-Boost has a **data availability problem**: builders only share TEE proofs and block headers with proposers, not the actual block contents,\[1\] [^1] and may choose not to release the block contents even after the proposer signs the header (e.g., if market conditions change unfavorably). The suggested approaches to solving this DA problem are: 1. **TEE-Escrow:** A TEE-escrow gets the block from the builder before the proposer signs it and releases it once they see the signed header. 2. **Data Availability Layers**: Builders post encrypted block payloads to a Data Availability (DA) layer. Both approaches have drawbacks. The TEE-escrow solution replicates centralizing latency dynamics similar to those of existing relays.\[2\] [^2] Using an external DA layer introduces an extra-protocol assumption and bears the latency dynamics of that external protocol (which are also likely unfavorable). ## Threshold Cryptography to Achieve Builder Privacy We propose an elegant solution to TEE-Boost's DA problem: **threshold encryption to the attester committee**. Specifically, the builder threshold encrypts the block to a specified fraction of the attester committee for that slot. Once enough attestations are gathered, the block becomes decryptable and available. The core enabling technology is [Silent Threshold Encryption](https://eprint.iacr.org/2024/263). This cryptographic technique allows threshold encryption without requiring an interactive Distributed Key Generation (DKG) setup phase, which previous constructions required. Instead, the joint public key is computed deterministically from the attester's already-existing BLS public keys plus some "hints" (discussed later). This achieves direct single-hop communication between the builder and validator with cryptographic privacy. The validators are not required to run TEEs themselves or to manage any new key material. **Mechanics:** 1. The builder constructs a block and encrypts it to the attester committee. 2. The builder constructs a TEE proof demonstrating three things to the attester committee: that the bid is honest, the block is valid, and it is encrypted correctly. 3. The builder communicates the threshold encrypted block and the TEE proof (which includes the bid value) to the proposer.\[3\] [^3] 4. The proposer signs the winning builder's encrypted block and gossips this proposal to the validator set. 5. Once the specified fraction (e.g. $\\frac{n}{2}$ or $\\frac{2n}{3}$) of the $n$-attester committee for the slot attests to the block, it is decrypted. 6. The decrypted block proceeds to finalization normally. ## Considerations ### Performance The performance characteristics of Silent Threshold Encryption are pretty favorable. Here $n$ is the maximum size of the committee that we wish to support and $t$ is the threshold for decryption. Both encryption and partial decryption are constant time. With a naive implementation, encryption takes $<7$ms - and this can be parallelized. Partial decryption takes $<1$ms. The ciphertext size is a constant additive factor, 768 bytes, larger than the plaintext (for any $n$ and $t$). Aggregation of partial decryptions (i.e., decryption) depends on the size of the committee. With $n=1024$, a naive implementation takes $<200$ms. We expect that with $n=128$ (the size of the attestation committee for each slot), this will drop by a factor of 10 and that the implementation can be further optimized. Importantly, encryption time is the key performance number to compare to relay latency. This is what the builder must compute in the "critical path" of block production. It's lower than the existing relay's block processing latency and avoids multi-hop communication. ### Data Publication Silent Threshold Encryption isn't entirely free. It does require a common reference string of the form: $(g, g^\\tau, g^{\\tau^2}, \\dots, g^{\\tau^{n-t}})$, similar to what's used for the KZG polynomial commitment scheme. Additionally, every validator with a BLS public key of the form $g^\\mathsf{sk}$ publishes a set of group elements which we call "hints": $(g^{\\mathsf{sk}\\cdot \\tau}, \\dots, g^{\\mathsf{sk}\\cdot \\tau^{n-t}})$. These hints are only needed to aggregate public keys and to decrypt ciphertexts. Encryption only uses a constant-sized aggregated public key. As of writing this post, there are approximately 1 million validators. If we set $n=128$ and $t=n/2$, each validator needs to post ≈ 3 KB of hints. Thus, storing the hints of all validators requires 3 GB. This requirement will likely decrease substantially with the [activation of MaxEB](https://eips.ethereum.org/EIPS/eip-7251), which allows validators controlling >32 ETH to hold larger balances under the same keypair (rather than splitting them over multiple 32 ETH deposits). The reduction in the validator set that will be realized is up for debate. It seems possible that we could get down to ~1GB. Lastly, depending on future changes to Ethereum's consensus architecture (e.g. further reductions in the validator set size, or alternative finality pipelining) the size of the hints that must be stored could further decrease. ### Liveness Ethereum wants to remain live even under adverse network conditions. One issue with this scheme is the possibility of blocks that cannot be decrypted because the specified fraction of the committee is offline. One solution is to allow the builder to decide on the acceptable fraction (𝑡) of the committee for decryption. There is a tradeoff between privacy (the possibility of unbundling and MEV-stealing) and the likelihood of the committee threshold being online. It's revenue-maximizing for builders to get their blocks included, rather than forked out, so they should figure out an optimized threshold setting.\[4\] [^4], they should be naturally incentivized to select 𝑡 high enough that there is very low risk of unbundling and high probability of being satisfied (at least 𝑡 members of the committee being online). Some blocks would likely get forked out even under normal network conditions, but we'd note this already happens with timing games, and the liveness of the chain remains acceptable\] Additionally, usage of this encryption scheme should be opt-in. Under adverse network conditions, in which no acceptably-sized committee is available with any consistency, proposers and builders could fall back to using relays, self-building, or whatever other mechanism is preferable given the nature of the adverse environment. ### Unavailable Blocks Alternatively, the committee may be online, but a builder may be able to create a situation in which the block is either unable to be decrypted or invalid upon decryption (e.g., with fraudulent proofs). From the protocol's perspective, it's fine to fork these blocks out. The broader validator set simply could not attest to them or to any blocks that reference them. The best way of handling this kind of error is likely to make the consensus client aware of the possibility and able to fail gracefully. Further study on exactly how would be needed. ### Market Structure The winning builder knows the contents of the block before others until the threshold is reached, which could create an unfair advantage in subsequent slots. However, the attester committee is supposed to act before the end of the next slot, and the majority of block value is at the end of the slot, so the effects of this advantage should be as nearly minimal as possible. ### Purely Cryptographic Proofs In the long term, it may be possible to replace TEE proofs with Zero-Knowledge (ZK) proofs. Currently, ZK proofs are too slow, but advancements in cryptography, software, and specialized hardware (ASICs) might eventually make ZK proof generation feasible within the necessary latency constraints. Notably, ZK proofs accompanying blocks are already a [core part of Ethereum's long-term roadmap](https://x.com/VitalikButerin/status/1588669785218650112). ## Adoption With the current validator set size and growth rate, this scheme may not be worth the amount of data required to be published on L1. However, Ethereum already plans to substantially reduce the validator set count with MaxEB. The best approach would likely be an upgrade alongside or after MaxEB in which consensus clients are made aware of the possibility of encrypted block semantics and validators are encouraged to publish hints. For example, after MaxEB, it could be required that newly entering validators publish hints, and older validators could be given an incentive to upgrade. Builders would begin to use the mechanism once a sufficient fraction of the validator set adopted it to have sufficient committee sizes (i.e., both acceptable privacy and likelihood of decryption). If our approach does indeed have favorable latency relative to multi-hop relaying, the market should adopt it without the need for the protocol to enforce usage or enshrine a specific parameterization. ## Rationale Relays are one of Ethereum's most significant sources of centralization, creating opportunities to rent-seek and distorting the protocol's geographic decentralization. We need to remove relays and think this is a relatively elegant way to do so. It requires changes at the consensus layer, but no new hardware or key material is required on the part of validators. The downside is that it is a complex change to the consensus layer for a mechanism that (if opt-in, as suggested) may or may not be adopted by the market. However, many potential changes to the MEV pipeline bear similar adoption and revenue-optimality questions (e.g., [inclusion lists](https://ethresear.ch/t/fork-choice-enforced-inclusion-lists-focil-a-simple-committee-based-inclusion-list-proposal/19870)). And there may be other future use cases that depend on the validator set having threshold encryption infrastructure available. ## Acknowledgments *Thanks to *[*Dan Robinson*](https://x.com/danrobinson)*, *[*Georgios Konstantopolous*](https://x.com/gakonst)*, *[*Frankie*](https://x.com/FrankieIsLost)*, *[*Shea Ketsdever*](https://x.com/SheaKetsdever)*, *[*Quintus*](https://x.com/0xQuintus)*, and *[*Mike Neuder *](https://x.com/mikeneuder?lang=en)*for feedback and review.* [^1]: Theoretically, if proposers also had access to TEEs, the builders could encrypt their blocks to a TEE run by the proposer. The proposer's TEE would only decrypt the block after they had signed it. However, we think TEE-Boost doesn't consider this design because it would require proposers (validators) to run TEEs. We want validators to be able to run on commodity hardware [^2]: The latency dynamic can be avoided if the proposers themselves run TEE-Escrow as a colocated sidecar to their validator node. However, again, we don't want to make validators run TEEs [^3]: The effect on proposer bandwidth requirements would need to be studied. Low-bandwidth proposers could limit needs by verifying proofs before requesting the block body, or with other heuristic filtering and smart download techniques. This is an open question but seems probably no harder to solve than normal mempool gossip spam issues [^4]: The specific claim here is that it is negative EV for a builder's block to get forked out (they recieve no revenue from it), and highly negative EV to get unbundled. If you give the builder the ability to pick 𝑡 in [0,128 ## https://www.paradigm.xyz/writing/regulation-by-enforcement-isn-t-just-a-meme # Regulation by Enforcement Isn't Just a Meme > A data-driven analysis of the SEC's actions against the crypto industry under Chair Gensler. This SEC today under Chair Gensler is not the same SEC as it used to be. - It uses the courts to litigate policy issues instead of writing rules. - It preys on individuals with limited resources and incentives to establish precedent on token issuance actions. - It targets intermediaries in an effort to front-run Congress in addressing market structure, including for DeFi. The industry has long felt the anecdotal truth of the SEC’s approach, but until now, no one had collected the data to show it. This analysis aims to close that gap. ## Background Since bringing the first crypto-related enforcement action in 2015, the SEC has taken legal action against 171 projects and individuals, across three presidential administrations and three Senate-confirmed SEC chairs. Roughly half of these actions (88) took place under Chair Gensler. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--47a0097103/5387f5a0d39be143f2b154dab328ba00/asset-https-cdn-sanity-io-images-dgybcd83--47a0097103.png) September and August have been the two busiest months for Chair Gensler’s SEC; the SEC’s fiscal year ends at the end of September. Chair Gensler appears to be running his agency like a police department setting speed traps at the end of the month to meet a quota. ## Item 1: Since Chair Gensler took office on April 17, 2021, the SEC has increasingly gone to court to establish its policy positions—confirming what the industry has long known regarding regulation by enforcement. While refusing to issue clear regulations detailing how the securities regulatory framework applies to crypto, [^1] Chair Gensler has increasingly relied on the court system to attempt to establish the regulatory perimeter. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--c5ed3ddf02/d1871d8f278e790b4d1da15c632cfa68/asset-https-cdn-sanity-io-images-dgybcd83--c5ed3ddf02.png) In contrast to the two SEC Chairs that preceded him, Chair Gensler has taken action against crypto projects with lower frequency in administrative courts, and to an extent in the U.S. District Court for the Southern District of New York (SDNY), opting instead to bring cases across a much broader range of jurisdictions than before. This shift could signal the increased constitutional limits on the use of administrative courts [^2] and an attempt by the SEC to forum shop for more favorable courts in the face of the significant defeat suffered in the *Ripple* case which was heard in SDNY. [^3] In general, it should be no surprise that a closer look at legal actions involving the SEC turned up a large number of court cases. Litigation has always been one of the SEC’s primary tools for enforcement, after all. What is novel here is that the SEC is using litigation to decide policy, instead of going through the process of finalizing rules after they have gone out for public comment. We suspect a closer look at rulemaking activity under prior administrations and closer documentation of the facts associated with each case under Chair Gensler would further underscore the shift in the SEC’s approach. ## Item 2: Chair Gensler’s SEC has seen a 9 percentage-point decrease in actions against companies and a 5 percentage-point increase in actions against individuals. There’s nothing inherently wrong with the SEC going after individuals. What’s problematic is that the SEC under Chair Gensler is is pursuing a “barbell” strategy of pairing its actions against the largest and most successful companies in the industry on issues related to institutional registration (see **Item 4** below) with an increased focus on going after individuals who lack the resources and incentives to defend themselves on matters pertaining to the issuance of alleged securities. It’s obvious that the issuer of a successful token is going to be in the best place to litigate the token’s status against the government. By trying to establish that tokens are securities in orthogonal cases against individuals who are more likely to settle, the SEC is not pursuing justice as it claims. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--24fb0ce249/c0b4386c69e13b9c25da90df531acd2e/asset-https-cdn-sanity-io-images-dgybcd83--24fb0ce249.png) ## Item 3: 92% of the SEC’s actions against the crypto industry under Chair Gensler have involved registration violations, compared to roughly 87% of actions under the preceding SEC Chairs. Despite the fact that Gensler’s SEC has failed to provide a viable path to registration for token issuers or other intermediaries—as we’ve previously [documented](https://www.paradigm.xyz/2023/03/secs-path-to-registration-part-i)—the agency has continued to bring enforcement actions focused on registration violations. This data evidences that instead of policing the market for the worst violators who are defrauding investors, the SEC has chosen to target firms who in many instances have engaged in good faith efforts to comply with an impossible regime. [^4] ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--cbd061eb04/a600f63ab6fdaf1e345e8f5caa8f9149/asset-https-cdn-sanity-io-images-dgybcd83--cbd061eb04.png) ## Item 4: There has been a 12 percentage-point increase in actions under the ‘34 Act, driven by large increases in actions against crypto platforms for allegedly operating as unregistered exchanges, brokers, or clearing agencies. The first wave of enforcement was largely focused on ICO issuers that conducted large public distributions of tokens, or actors engaged in fraudulent activities. Under Chair Gensler, there has been a marked shift away from token issuers and fraudsters and an increased focus on intermediaries, which are seen by the agency as a higher point of leverage over the entire crypto ecosystem. The SEC has used this approach to take action against the largest exchanges in the industry, such as Coinbase, Kraken, and Binance, charging each of them with acting as unregistered exchanges, brokers and clearing agencies. In doing so, the SEC is attempting to maximize its leverage to bring the entire ecosystem to heel and litigating the legal status of specific tokens in the absence of the token issuers, which are the parties best positioned to defend the claims. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--b295607326/557aa184c85e898d1bba8da8971eedd0/asset-https-cdn-sanity-io-images-dgybcd83--b295607326.png) ## Summary Despite Chair Gensler and his advocates saying nothing has changed about the SEC’s approach to crypto, the empirical evidence is suggestive of the opposite. There are a number of shifts in the SEC’s approach. Overall, we continue to be concerned about the chilling effect of Chair Gensler’s approach on the development of the crypto ecosystem in the United States. And it’s too difficult to get good data on what the government is actually doing. The SEC should have to provide these data in usable form. Until then, if you’re interested in helping us clean and maintain our database, please reach out. [^1]: During Gensler’s administration, the SEC has worked on five rules that have a connection to crypto, while bringing 88 legal proceedings against the industry [^2]: In SEC v. Jarkesy, SCOTUS held that defendants charged with fraud under the Securities Act and facing civil penalties are entitled by the Constitution to a jury trial. It is not clear how broadly this ruling will apply and the extent to which it will further limit the SEC’s and other administrative agencies’ use of administrative courts [^3]: In SEC v. Ripple, the court found that programmatic sales of XRP on secondary exchanges and distributions of XRP to employees and other third parties as compensation did not constitute securities transactions [^4]: For example, Coinbase petitioned the SEC for rulemaking on how the company could register as a Securities Exchange. Instead of engaging with Coinbase in good faith, the agency resorted instead to suing the company ## https://www.paradigm.xyz/writing/looking-forward # Looking Back / Looking Forward > A personal reflection on working at the intersection of crypto and policy I have been struggling with how to engage in crypto policy as election season ramps up. So here’s a personal, apolitical reflection on why I think blockchains are the future of financial services—and just about everything else. **The days are long but the decades are short** First, some backstory. I bought my first bitcoin in 2013. In 2016, I wrote a [paper](https://www.federalreserve.gov/econres/feds/distributed-ledger-technology-in-payments-clearing-and-settlement.htm#:~:text=Distributed%20ledger%20technology%20(DLT)%20is,derivatives%20are%20cleared%20and%20settled.) with a group of colleagues at the Federal Reserve that contemplated whether blockchains would change the global financial architecture. I’ve now spent the better part of the last 8 years thinking about the same question from a number of different angles. At times, it has been a vexing journey. I’ve seen various things come in and out (…and in again) of fashion in the industry. Given a number of setbacks that I won’t list here, a lot of people in my personal and professional orbits have tried to convince me that there’s no substance in crypto, and there’s no way it’s going to change the world. But I’m still here. One conclusion I’ve come to—call it a conviction at this point—is that permissionless blockchains *already have* changed the global financial architecture. And it’s still \*so\* early. **Financial infrastructure has traditionally been costly to build, which harms consumers in the long run** My career straddles two very different worlds, having gone from the center of the financial system (the Fed) to the center of cutting-edge crypto (Paradigm). I have always been driven by an interest in money and freedom as social phenomena, and a desire to make both ideas work better for everyday people. I think of the financial system as capitalism’s middleware, and I’m fairly agnostic about the shape of the future, as long as it’s better than the past. That’s how I relate to crypto policy to this day, and I believe a lot of my former colleagues in the government share this sentiment. Working at the Fed gives you a deep appreciation for how the financial system works and how it falters. Most traditional financial infrastructures are fortified with huge moats and a core challenge for entrepreneurs and policymakers is how to build bridges between them. Conventional economic wisdom tells us that natural monopolies emerge where there are high (upfront) fixed costs and low marginal costs. Power utilities are a foundational example: it’s very costly to build a nuclear power plant and transmission infrastructure, but once everything is in place it’s almost costless to add another node to the network. Building an exchange, clearinghouse, or payment system historically has had a similar cost structure, but financial market utilities receive *even stronger* market power thanks to network effects from the concentration of participants and liquidity. If you wanted to build a traditional financial infrastructure 5 years ago that operates at scale, you would have had to, at a minimum: 1) build and maintain an on-prem data center; 2) develop the core software that records transfers from scratch; 3) create a communications network for participants; 4) integrate with a seemingly infinite number of external systems and merchants; and 5) provide a governance framework and some sort of rulebook. In a 2023 [Federal Register Notice](https://www.federalregister.gov/documents/2023/11/24/2023-25925/federal-reserve-bank-services), the Fed estimated it spent a whopping $545 million over 4 years to bring the FedNow service to market—a system that runs parallel to the Fedwire system it already operated. Intercontinental Exchange, which owns NYSE and the ICE complex of clearinghouses, spent $734 million in [2023](https://ir.theice.com/press/news-details/2024/Intercontinental-Exchange-Reports-Strong-Full-Year-2023-Results/default.aspx#:~:text=Full%20year%20exchange%20net%20revenues,the%20operating%20margin%20was%2071%25.) on technology and communications infrastructure. SWIFT traces its [origins](https://eprints.lse.ac.uk/46490/1/Origins%20and%20Development%20of.pdf) to trans-Atlantic undersea cables connecting New York and London. But innovation dies and costs rise where there isn’t competition. Without the pressure of compressing margins, rent-seeking intermediaries have very little incentive to invest in research and development that could deliver welfare-enhancing products for their end-users. They also have the market power to charge what they want… and most aren’t in the business of charity. Additionally, high recovery costs severely limit the scope of what’s commercially viable to build, which means the only markets that get served are ones that don’t require the kind of bespoke customization that don’t benefit from economies of scale. People have a hard time understanding that this point isn’t about using technology to make existing products or markets more efficient—it’s about building products and markets that *couldn’t exist previously* because the economics just didn’t work. We can bend the cost curve with public blockchains. Who doesn’t want to make it inexpensive to make products that serve the long-tail of people and businesses that are often ignored? **What if you could build a financial utility on performant, interoperable infrastructure with almost zero upfront costs?** Ethereum and Solana and \[name that L1\] are functionally globally-distributed data centers operated as privately-funded, publicly-accessible utilities. If you want to build a payment system today, you *could* build your own data center, etc., or you could just build a stablecoin. If you want to build an exchange today, you could run a CLOB and co-located infrastructure, or you could deploy a Uniswap liquidity pool. The ledger, communications network, and social graph are already *built* and you just have to pay to use them on a per-transaction basis. Better yet: everything is interoperable by default. At a time where financial infrastructure is already in need of upgrading, it’s hard to overstate what this could mean for the future of finance and of social coordination. It’s why [Vlad Tenev](https://x.com/tokenterminal/status/1822647062195732649) and [Larry Fink](https://www.youtube.com/watch?v=HTveRlW7QPo) continue to tout the virtues of building onchain and the efficiency benefits from leveraging public infrastructure. Every major bank or financial institution and every major government (US excepted) is investing in the space. I don’t know how you can ignore that. Some people like to point out that you could get these benefits without native cryptocurrencies, but that simply isn’t true. Native tokens like ETH are what power these networks and what provide incentives for people to build on them. **You don’t need a blockchain for that** It’s almost certainly true that there are sometimes efficiency costs from decentralization and that optimizing for those, as a lot of blockchains do, is importing inefficiency to products that don’t need that level of censorship resistance. I think this is quickly becoming one of the flimsiest anti-blockchain arguments, especially in finance. At some stage, it doesn’t really matter if use case XYZ *needs* to be onchain if the rest of our lives are there. You might not *need* to be able to make payments on your phone when almost every store accepts cards and cash. But when your phone is on your person 24/7 and is one of the primary ways you interact with the world, having every part of your life there as well is a big convenience. [rwa.xyz](https://app.rwa.xyz/) shows that there are roughly $5.25 billion in “real-world assets” (narrator: awful name) onchain today, up from nearly zero five years ago—and this excludes stablecoins, which add another $150+ billion to the total. This will continue to create a flywheel such that in five years, “you don’t need a blockchain for that” will sound as obtuse as, “why would you build a website for your business?” This leads me to my next point. **Blockchains aren’t monoliths (even the monolithic ones)** In our 2016 paper, we flagged a number of technical “challenges” with blockchains, including scalability/throughput, key management, and interoperability. Most of these have had notable breakthroughs in recent years and could be solved in the near future. I believe it’s vitally important for crypto’s base layer to stay credibly neutral, but it’s also reasonable for certain organizations building in crypto to need a different degree of control and visibility. Smart contracts with whitelists and L2s with centralized sequencers are enterprise-blockchain adjacent but still offer benefits over proprietary tech stacks. There’s already so much nuance in the space that you can fairly ignore most people who try to one-size-fits-all their reason for why blockchains can’t do something. Time and technology shift what people think is possible and what they’re willing to change to make it happen. **Beyond finance** The not-so-subtle theme of this piece has been about the future of finance. Of course, all of the benefits that make blockchains useful for financial applications apply equally to other areas with trust requirements where technology can be used to create digital scarcity and augment social coordination. Thus, I’m equally interested in non-financial use cases because they create a positive feedback loop for financial ones and are an experimentation ground for culture. TradFi moving onchain is a second-order effect of the rest of commerce and culture moving there. Farcaster is a great example, which co-founder Dan Romero likes to refer to as a “sufficiently decentralized” social network. It would be costly (and overkill) to store every piece of information on a blockchain. It’s *really* useful to have the social graph there, especially when paired with embedded crypto wallets that can be used for payments and to store unique digital content. Skeptics that knock crypto for having no “killer app” or too much repugnant activity are missing the point. For one, unstoppable public infrastructure *is* a killer app. Early adopters of new technology are almost always on the fringes of society. As a technology diffuses and goes mainstream, its user base eventually broadens and people build applications that are in demand for an ever growing number of people. Crypto is on this trajectory. **Fin** This brings us back to where we started. After almost a decade in this space, I’m pretty confident at this point that crypto isn’t going anywhere. In fact, we’re only going to get more projects and more applications as time progresses. One of the most basic primitives of the corporate world is the merger/acquisition, which trends toward centralization. It’s telling that in crypto governance, one of the most important “corporate” actions is the fork—where one can become many. Our laboratory of experimentation is going to get some things wrong along the way. It will be uncomfortable at times. But I would challenge people working in the space—especially those working on policy, broadly defined—to not fixate on the bad and instead imagine how we can make things better. ## https://www.paradigm.xyz/writing/Dem-polling # July 2024 Democratic Public Opinion Poll > Democratic voters are increasingly gravitating towards crypto. That’s the primary takeaway of our new poll of registered Democrats, the complement to our poll of Republicans from June. These results dovetail with recent reports that Democratic candidates for office and Members of Congress are becoming pro-crypto, indicating that political figures are following the lead of their voters. Democratic voters are increasingly gravitating towards crypto. That’s the primary takeaway of our new poll of registered Democrats, the complement to our poll of [Republicans](https://policy.paradigm.xyz/writing/GOP-Polling). from June. These results dovetail with recent reports that Democratic candidates for office and Members of Congress are becoming pro-crypto, indicating that political figures are following the lead of their voters. For this release, the poll was conducted with the research firm Mercury Analytics. Our poll was in the field from July 25th until August 1st, meaning that this data was collected in the days after President Joe Biden announced he would be stepping down as the Democratic nominee for President and Vice President Kamala Harris effectively locked up the nomination. We polled 804 self-identified Democratic registered voters for this poll, with a margin of error of 3.5%. We also oversampled Black, Hispanic, and AAPI Democrats, conducting 100 additional interviews with each of these audiences, to gain better insight into how non-white Democrats view crypto. ## Takeaway 1: Democratic crypto voters are up for grabs this November. Making inroads with crypto owners could help Vice President Harris win back some wayward Democrats and increase her likelihood of winning. As of right now, there are 1-2% of Democrats who may be leaning towards Trump due the Biden Administration’s hostility to crypto. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--04177f1248/9a3d58b2fbf7a75d5e0dce1b310fbd86/asset-https-cdn-sanity-io-images-dgybcd83--04177f1248.png) - Of the 804 Democrats we polled, 13% said they were not voting for Harris as they are either voting for Trump, a third-party candidate, or are still undecided. - Trump-supporting Democrats are far more likely to have brought cryptocurrency than the rest of those polled. 18% of non-Harris Democrats have bought crypto, and Trump-supporting Democrats have bought at two times that rate. - Additionally, 21% of non-Harris voters say that the Biden Administration has been “a little too hostile” or “much too hostile” on crypto. ## Takeaway 2: Democrats are worried about losing purchasing power and being cut off from the financial system. A core goal of crypto – giving people greater ability to maintain financial privacy – resonates with Democrats. Contrary to some suppositions, Democratic voters recognize the dangers of mass surveillance. Financial privacy is a core belief for Democratic voters. - 72% of respondents agreed that “personal financial transactions should generally be kept private, and only made available to government agencies when needed for specific purposes.” - Just 15% took the view that “personal financial transactions should generally be recorded in a place where it is easy for government agencies like the IRS to review transactions.” ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--7e45ef1944/48bdcc723155d6f09f79357a5c6f6d83/asset-https-cdn-sanity-io-images-dgybcd83--7e45ef1944.png) - Additionally, 78% of respondents said it was extremely or very important that people have a way to pay for reproductive care without making their transactions known to their state government or the federal government; only 6% of Democrats disagreed. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--d74db69de5/a9ac261f6588e1ddac6d90318f5ab02f/asset-https-cdn-sanity-io-images-dgybcd83--d74db69de5.png) Nearly all Democrats are also worried about protecting their purchasing power, matching the views of Republicans and Independents: - 80% of Democrats said it was “very important” or “extremely important” that their “money maintains its purchasing power over time.” ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--aec4eafca5/daf26ab253c4f98dc71a6f9f12f8c0d6/asset-https-cdn-sanity-io-images-dgybcd83--aec4eafca5.png) ## Takeaway 3: Crypto is most popular among Democratic voters of color. When Democrats come out as pro-crypto, they are following the lead of their own non-white base voters, who view crypto positively. Previous [Paradigm polling](https://policy.paradigm.xyz/writing/March-2024-Polling) has shown that crypto ownership and support is strongest among non-white voters, and that is also true among non-white Democrats. - 18% of Democrats have bought crypto in the past. - This number rises to 22% among Black Democrats, 25% among Hispanic Democrats, and 27% among Asian American and Pacific Islander Democrats. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--742384298d/33ffa1e9c3a3e78cac2f1a8f8d58e37f/asset-https-cdn-sanity-io-images-dgybcd83--742384298d.png) To be clear, crypto is the most popular among non-white Democrats regardless of ownership. - 28% of Black Democrats, 32% of Hispanic Democrats, and 27% of AAPI Democrats say that crypto plays a positive role in the U.S. economy. This is a massive jump compared to 13% of White Democrats who said the same. ## Takeaway 4: Crypto ownership is likely to grow among Democrats in the next 12 months. More Democratic voters are saying they plan to buy crypto in the next 12 months than have ever bought it before. If you needed additional proof that Democrats are warming to crypto, this is a fire bell in the night. - 9% of Democrats say they are very likely to invest in crypto in the next year, and another 18% of Democrats are somewhat likely to invest. - This means about 27% of Democrats who haven’t yet bought crypto are likely to buy in the next year. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--fdce8133b0/62f2ac857a318f59a54c00720032931f/asset-https-cdn-sanity-io-images-dgybcd83--fdce8133b0.png) ## Takeaway 5: Crypto ownership among Democrats is approaching parity with stock ownership and continues to grow. Based on our data, millions of Democratic voters own tens of thousands of dollars of crypto. These are significant holdings for any asset, the kind that drive voting behavior: - At present, 18% of Democrats have bought crypto, with 12% currently owning and 6% having previously bought it but no longer owning it. 33% of respondents currently own stock. - 8% of Democrats first bought crypto within the last year, with 3% having bought crypto in the past few months and 2% buying in the past few weeks. - 8% of respondents say they currently own more $1000 in crypto - 5% of respondents own more than $10,000 in crypto. - Underscoring crypto’s popularity among non-white Democrats, 10% of Hispanic Democrats polled own more than $10,000 in crypto, and 9% of AAPI Democrats own more than $10,000 in crypto. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--ee0a66c2d4/fe58c191ade63651085c8148d709a5d6/asset-https-cdn-sanity-io-images-dgybcd83--ee0a66c2d4.png) ## Takeaway 6: Much like Republican voters, Democratic voters are concerned about being cut off from the financial system, especially under a second Trump Administration. Democratic voters are open to options outside the traditional financial system, and want financial freedom as much as Republicans. The specter of another Trump Administration is creating intense pressure on Democrats to find alternative means of protecting their access to financial services. - 62% of Democratic voters are concerned that they, their family, or their business “may lose access to financial services as a result of your political views,” with just 38% not being concerned. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--7fb6729439/b9d4a4bd3f0ebcffb97fd2eabaa3e47c/asset-https-cdn-sanity-io-images-dgybcd83--7fb6729439.png) - 80% of respondents said they were concerned that a second Trump Administration would cut off their family’s access to financial services. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--d7b3055146/2ee77e5196a6ffeb4ac2afbda8eb1cf9/asset-https-cdn-sanity-io-images-dgybcd83--d7b3055146.png) ## Takeaway 7: Democrats want the United States to be a world leader in crypto. Democrats want crypto innovation in the United States: - 43% of Democrats said it was either very important or extremely important that the “United States leads the world in high-tech software innovations such as cryptocurrency and fintech,” with another 38% saying it was somewhat important. - Just 8% of Democrats said the U.S. leading the world in these innovations was “not at all important”. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--a06d7de83a/253857e37237cecb2978d336ec56fd4a/asset-https-cdn-sanity-io-images-dgybcd83--a06d7de83a.png) This is a strong sign that, contrary to actions by some Biden Administration officials, Democratic voters want crypto innovation centered here in America. It also should give Democratic Members of Congress and the Harris campaign confidence that Democratic voters want reasonable legislation passed crafting a regulatory regime for crypto. ## https://www.paradigm.xyz/writing/prediction-market-comment # Paradigm Files Comment on the CFTC’s Overbroad Proposed Rule on Political Event Contracts and Prediction Markets > Paradigm files comment letter in response to the CFTC's proposed rule on prediction markets and election contracts. America is electing a president this year, and the results of November’s election will have profound consequences for the world, the country – and especially for crypto. Everywhere we look, the press, business executives, and professional prognosticators are making predictions about November’s potential outcomes. But too often, these myriad predictions feel more like noise than signal. [Prediction markets](https://www.fastcompany.com/91004331/predictions-2024-presidential-election-taylor-swift) have recently emerged as a focal point and predictor of potential electoral outcomes. In fact, amid the churn of an especially chaotic election year, these predictions have been a rare light in the dark. Presidential candidates even [showcase prediction market readouts](https://truthsocial.com/@realDonaldTrump/112663944139358862) alongside traditional polling data. Prediction markets are clearly capturing some market wisdom; Nate Silver’s recently-released [model](https://substack.com/home/post/p-145982342) for the Presidential Election closely tracked the outcome likelihood shown at the time (June 26, 2024) on prediction market [Polymarket](https://policy.paradigm.xyz/assets/writing/polymarket-screenshot.png). (Last week, Polymarket announced that Nate Silver was joining the company as an advisor.) In the electoral rollercoaster of the last two weeks, 1) there was an assassination attempt on former President Trump, 2) Trump selected Senator JD Vance as his Vice Presidential nominee, 3) President Biden decided against running for reelection, and 4) Vice President Kamala Harris presumptively secured the Democratic nomination. The impact of each event is material to the trajectory of the race for the White House. Yet these events were too staccato to poll in real time. After all, when it comes to polling, we still are limited by time, resources, and sample size. To make sense of each event, average Americans, businesses, candidates, and the press have turned to prediction markets to separate the electoral signal from the noise. Clearly, there is value and public interest in these markets. When there is no other way to discern what is truly going on, markets are our last, best guardian of truth. Despite these benefits, the CFTC has decided to move forward with a [proposed rulemaking](https://www.cftc.gov/PressRoom/PressReleases/8907-24) that would ban political event contracts altogether – while also significantly limiting potential implementations of prediction markets more broadly. In February 2024, Paradigm filed an [amicus curiae](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-64e4102fff/a05c000dc0d4451289acb3df07f99590/asset-https-cdn-sanity-io-files-dgybcd83-p-64e4102fff.pdf) in support of [KalshiEx’s](https://kalshi.com/) lawsuit against the CFTC, which was an innovative company’s appeal to legalize political event contracts for all US participants. The CFTC, circumventing the ongoing legal process, decided to preemptively issue a rule effectively banning the practice entirely. This would be a loss not just for those who seek to use these markets, but it would reduce information available to voters and reporters about the crux of a functioning democracy: our elections. Prediction markets are an important nascent financial primitive, potentially forming the basis for new systems of [governance](https://blog.ethereum.org/2014/08/21/introduction-futarchy), hedging risk, gauging public sentiment, and forming political analyses. Regulators should be merit neutral in their approach to all new technology (such as crypto). If there are risks, regulators should write appropriately-tailored rules. Otherwise, policymakers shouldn’t regulate something out of existence just for committing the “sin” of being new and unfamiliar. As enumerated in our [comment letter](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-38c1330f7c/599977ff701145e1e053f840e7db73da/asset-https-cdn-sanity-io-files-dgybcd83-p-38c1330f7c.pdf), Paradigm has significant concerns that the Event Contracts NPRM suggests a broad and untethered ban on a wide variety of products – prediction markets – that could otherwise further the goals of the Commodity Exchange Act to promote responsible innovation. We urge the CFTC to materially alter, or scrap altogether, this ill-considered and technology-prejudiced rule. Our elections and very democracy depend on accurate, real-time info; our regulations should not lose sight of our democratic forest for a regulatory shrub. ## https://www.paradigm.xyz/writing/GOP-Polling # June 2024 Republican Public Opinion Poll > In June, Paradigm conducted a first-of-its kind poll of Republican voters to better understand how they think about crypto. The results were clear: Republicans embrace financial freedom and want the current Administration’s crypto approach to end. In June, Paradigm conducted a first-of-its kind poll of Republican voters to better understand how they think about crypto. The results were clear: Republicans embrace financial freedom. Republican candidates defending crypto – such as [Sam Brown](https://blockworks.co/news/america-financial-alternative-crypto), [Dave McCormick](https://www.washingtonexaminer.com/opinion/beltway-confidential/2936952/america-must-lead-on-cryptocurrency/), and [Bernie Moreno](https://www.standwithcrypto.org/politicians/person/bernie--moreno) – have strong support for their positions from GOP voters. Republicans sharply disagree with the Warren-Gensler worldview of centralized control: CBDCs, debanking, and forcing all financial transactions through big banks. In short, Republicans understand the appeal of crypto and support congressional action to establish clear and predictable rules. ### Takeaway 1: Republicans who own crypto are more non-white and younger than typical Republicans, exactly the votes Trump needs in this election. 28% of Republicans polled currently own or have bought crypto, higher than the 19% national average of all registered voters [we found in March 2024](https://policy.paradigm.xyz/writing/March-2024-Polling). ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--824fdd7f2e/ba5f9da2d649d556d78ef3428d143e76/asset-https-cdn-sanity-io-images-dgybcd83--824fdd7f2e.png) But the numbers are even more revealing under the surface: - 41% of non-white Republicans have bought or own crypto, only 11 points lower than the 52% who own stock. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--5d3463a405/e96f0073f4480c5baaf38bbd1f389c2a/asset-https-cdn-sanity-io-images-dgybcd83--5d3463a405.png) - 87% of crypto-owning Republicans stated an intent to buy more crypto in the next twelve months, and 13% of non-crypto-owning Republicans said they were likely to buy crypto for the first time in the next twelve months. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--f9aff1e1fa/3b82f3d2ea5daf8a98ec1c08ca77dd3e/asset-https-cdn-sanity-io-images-dgybcd83--f9aff1e1fa.png) - Crypto ownership is strongest among Republicans under the age of 40. 45% have bought or own crypto. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--dd324bf2bc/28611931ef0f0bd15ec75dc882329450/asset-https-cdn-sanity-io-images-dgybcd83--dd324bf2bc.png) - Many Republican crypto owners own a lot of crypto: - 58% percent of Republicans who own crypto own more than $1,000 of it - 40% percent of Republicans who own crypto own more than $5,000 of it ### Takeaway 2: Republicans have distrust of institutions, and seek the freedom crypto can provide. As the Biden Administration and its allies continue to weaponize banking regulations, Republican voters simply do not trust financial institutions. - 67% say they are dissatisfied with how the financial system in America works today. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--22dda8c22d/1d7ff00edfe27d2e8b94a12a9ddb2327/asset-https-cdn-sanity-io-images-dgybcd83--22dda8c22d.png) - 72% of Republican voters are at least somewhat concerned that they could lose access to financial services as a result of their political or religious views. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--e2705b1461/4a755096ab70aab4e261fc752f37062a/asset-https-cdn-sanity-io-images-dgybcd83--e2705b1461.png) - 84% of Republicans agree Americans should have the right to send money to another person without the involvement of a big bank. ### Takeaway 3: Republicans want Congress to do something about crypto regulatory unclarity. Republicans want Congress to do something about crypto regulatory unclarity, and they agree that elected representatives should take the lead in crafting crypto regulatory frameworks – rather than unelected bureaucrats. - 60% say Congress should pass legislation that establishes clear and predictable rules for cryptocurrency companies and entrepreneurs. - More Republican voters believe elected representatives in Congress should take the lead (40%) over unelected appointees at government agencies (16%) in crafting crypto regulation. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--47d84659e1/cf570d4e0f3519787b49284a9b7e69c3/asset-https-cdn-sanity-io-images-dgybcd83--47d84659e1.png) ### Takeaway 4: Republicans care about financial privacy Republicans oppose any IRS invasion of privacy or viewership of private financial transactions, which would be enabled by the pending DeFi portion of the IRS’s digital asset broker rule. They also strongly oppose the creation of a government-tracked Central Bank Digital Currency (CBDC). - 94% of Republicans say their financial transactions should remain private. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--09a68a914d/0fa2b70e7e54e5eb6b8d8176963715d1/asset-https-cdn-sanity-io-images-dgybcd83--09a68a914d.png) - Of the Republican voters who said they knew what a CBDC is, 68% oppose the creation of one. ### Takeaway 5: Crypto helps persuade Never Trump Republicans to vote for Trump, and gets Republicans more excited about him As Trump consolidates support of Republican voters and prepares for the general election, crypto is one issue that helps him with the GOP base. - 13% of Republicans not currently planning on voting for Trump say his newly-stated crypto positions make them more likely to vote for him. - 38% of non-white Republican Trump supporters said Trump’s support for crypto makes them more excited to vote for him. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--a08a06cb54/333f26ea09d50a30c554ee8564a24c21/asset-https-cdn-sanity-io-images-dgybcd83--a08a06cb54.png) ### Takeaway 6: Republicans are generally positive on crypto - More Republicans say crypto is a mostly positive force in the economy (36%) than negative (30%), with this +6 point margin widening to +12 points among men, +42 points among GOP voters under 40, and +27 points among non-white Republicans. - After learning that China is developing a digital yuan, more Republicans support (40%) the US creating a pathway for American private sector companies to build payment products, like stablecoins, to compete with the digital yuan than oppose (31%). Support for pathways to digital yuan competitors is highest among men (52%) and college educated Republicans (49%). ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--fa20c3e8a6/61012e8e1971f4c3b6dc8a6070a32b74/asset-https-cdn-sanity-io-images-dgybcd83--fa20c3e8a6.png) *The above poll was conducted by Echelon Insights. This survey was fielded online from June 11-13, 2024 in English among a sample of N=1,025 Republican voters in the Likely Electorate (LV) nationwide using non-probability sampling. The sample was drawn from the Lucid sample exchange and matched to the L2 voter file, 500 polled via text-to-web and 525 via phone. The margin of error was 3.5%.* ## https://www.paradigm.xyz/writing/amicus-brief-lejilex # Paradigm Files Amicus Brief Supporting CFAT and Lejilex’s Lawsuit Against the SEC > Paradigm has submitted an amicus brief supporting Lejilex and the Crypto Freedom Alliance of Texas's lawsuit against the SEC. Instead of engaging in the normal process of regulation out in the open by writing clear rules, the SEC has waged a guerilla war to create fear and confusion throughout the crypto industry, in the hopes of systematically weakening it. But all the legal fusillades in this strafing rely on the same flawed premise: the idea that crypto assets are “investment contracts” akin to stocks, bonds, futures, and other securities. As we detail in [our amicus brief](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-56c91e42c9/a0bcb59621e13358f78f224e539f4d3e/asset-https-cdn-sanity-io-files-dgybcd83-p-56c91e42c9.pdf), this regulation-by-enforcement campaign is unsupported by both facts and law. ### **Lejilex’s lawsuit against the SEC** Lejilex is a Texas company developing a new trading platform called Legit.Exchange that would like to allow peer-to-peer sales of tokens that the SEC has claimed are investment contracts under the federal securities laws. As a result—according to the SEC’s misguided view—Lejilex is planning to create an unregistered securities exchange. Lejilex, along with the Crypto Freedom Alliance of Texas (CFAT), sued the SEC asking it to declare that secondary-market sales of crypto assets are not sales of securities, and that the federal securities laws do not apply to Legit.Exchange. It argues that the SEC’s current war on crypto is outside the agency’s legal authority – which makes sense given that Congress created the securities laws in the 1930s to regulate investment contracts, not to govern the present-day crypto marketplace. ### **Our Amicus Brief** We have seen firsthand how much the SEC’s reflexive hostility can hurt projects and hamper markets, all based on the misguided argument that crypto assets should be treated as investment contracts. Our amicus brief today highlights for the court four key distinctions between crypto assets and securities: 1. Independence: Unlike securities, which are inextricably linked to their issuers, crypto assets can exist and retain value independently of their creators. Their value stems from their utility, or from market demand—not from the business performance of an issuing entity. 2. Obligations: Crypto creators do not have the same fiduciary obligations to asset holders as corporations do to their shareholders. Indeed, sales of crypto do not transfer these obligations at all—they transfer ownership. 3. Decentralization: Ownership of crypto assets does not confer control over the creator or the project, unlike shareholder rights in a corporation. Instead, crypto projects tend to operate on decentralized networks where decisions are made by community consensus rather than by a group of C-Suite managers or a board of directors. 4. Trading: Crypto markets operate through decentralized exchanges that use blockchain technology to facilitate direct peer-to-peer transactions. This eliminates the need for brokers, clearinghouses, and other middlemen that pervade the securities markets. These are just a few of the most prominent differences between crypto assets and securities. But they’re enough to show that the SEC’s contrary view rests on a false equivalence. ### **Why it matters** Forcing crypto into the regulatory framework for securities is not just unlawful, it also will fail to accrue any benefit to the public that the SEC is supposed to protect. Even if crypto projects could follow the SEC’s current disclosure rules (which are incompatible with decentralized protocols and projects), compliance would not help purchasers of crypto assets. The disclosure rules demand information that is irrelevant to crypto and would fail to result in the disclosure of information that would be useful to purchasers of crypto assets. And worse, the current disclosure regime would result in misleading information being provided to crypto asset purchases. This mismatch exists because the premise of the SEC’s war is fundamentally flawed – crypto assets are not investment contracts. This single misunderstanding makes this entire campaign against crypto collapse in on itself, like a political neutron star. The SEC should cease this flawed crusade and return to its core mission of regulating through traditional formal rulemakings and asking Congress for legislation on novel topics, as required by law. ## https://www.paradigm.xyz/writing/reth-prod # Releasing Reth 1.0! > Reth is now feature-complete, stable, and recommended for production usage and staking. **We are excited to announce that after almost 2 years of development and a** [**successful audit**](https://github.com/paradigmxyz/reth/blob/23d8e4e6f6871037c844558b970be2027f792b9d/audit/sigma_prime_audit_v1.pdf) **by Sigma Prime, we are finally releasing Reth 1.0, the first “prod-ready” release of our blazing-fast Ethereum execution client.** [Reth 1.0](https://github.com/paradigmxyz/reth/releases) focuses on delivering a stable Ethereum mainnet node on top of continuing our mission towards breaking through the [gigagas per second](https://www.paradigm.xyz/2024/04/reth-perf) barrier and delivering an [extensible](https://github.com/paradigmxyz/reth/tree/main/examples) and [contributor-friendly](https://github.com/paradigmxyz/reth/graphs/contributors) node (over 300!). With this release, we invite all industry players to run Reth in production and [get in touch with our team about becoming an early partner](https://7dr10b0z31d.typeform.com/to/y9Pm3aoL) so we can help you succeed with priority support and custom features. Specifically: - Professional operators can run Reth in their Ethereum mainnet production infrastructure to reduce their costs and improve their services’ performance. Get started at the [Reth book](https://reth.rs/installation/installation.html)! - Stakers can switch their stake over to Reth and support Ethereum’s client diversity by following the instructions at the [Ethereum Foundation’s staking launchpad](https://launchpad.ethereum.org/en/reth). If the above sounds exciting, read on to learn more! # Reth is ready for production. Reth 1.0’s [performance characteristic and storage footprint](https://reth.paradigm.xyz/) is as good as the [beta](https://www.paradigm.xyz/2024/03/reth-beta) versions as of June 2024 – about 50 hours to sync to the tip from genesis, ~2.25TB archive node storage, and great RPC throughput & latency in transactions, logs and tracing benchmarks. All of these numbers are state of the art and will [continue getting better](https://www.paradigm.xyz/2024/04/reth-perf). As before, the dominant factor for performance across [hardware](https://reth.rs/installation/installation.html#what-hardware-can-i-get) is the hard drive, so we recommend making sure to run Ethereum nodes on a [great SSD](https://gist.github.com/yorickdowne/f3a3e79a573bf35767cd002cc977b038). If you’re running on AWS or other cloud storage options, ensure you have >16K IOPS. We use [Latitude](https://latitude.sh/)’s bare metal servers for our benchmarks because of their great NVMe SSDs. We think the above is reason enough to try out Reth. But performance is not what we want to focus on today. What we're most excited for Reth 1.0 is its stability compared to earlier versions. **With the observed stability and steps taken to secure Reth 1.0, we’re comfortable recommending Reth for usage in production, including for Ethereum mainnet staking (see the** [**Ethereum Foundation's launchpad**](https://launchpad.ethereum.org/en/reth!) **and large RPC node operations.** ## How stable is Reth 1.0? We put extra effort into providing an operator experience which would minimize manual troubleshooting and unpredictability, based on feedback from tons of individual users, professional node operators and companies. Here are the areas we focused on: - **Fast Block Sealing at the Tip:** We've improved the block sealing flow in response to Engine API messages to ensure Reth is an attractive option for keeping up with the chain’s tip. This enhancement addresses past issues where blocks were sometimes sealed late, affecting stakers and RPC providers with missed blocks and reduced attestation performance. - **Zero Crashes:** Since releasing `reth 0.2.0-beta.6` in April 2024, there have been no crash reports, a requirement for any high uptime deployment of Reth. This is a significant improvement over previous versions that occasionally experienced crashes in reorg-related edge cases. - **Efficient Resource Usage:** We've successfully addressed memory leaks in critical components such as the network and the mempool, and optimized Reth’s resource utilization across the board. This allows Reth to run with stable and predictable resources on some of the [most consumer-friendly hardware](https://x.com/EthereumOnARM/status/1800436894418805198), while still being able to utilize high-end hardware like Latitude’s [bare metal devices](https://reth.rs/installation/installation.html#what-hardware-can-i-get). - **No performance regressions:** With our tooling improving, we’re able to confidently ship releases which consistently improve performance from previous versions. Stability means that if we hit any regression in our pre-release testing, we’re able to quickly triage and fix it. Note that while we expect Reth the node to be stable and provide you with “no surprises” infrastructure, we still reserve the right to make breaking changes and refactor internal node APIs. If you are using Reth as an SDK and want it to become more stable, [we’d love to work with you](https://7dr10b0z31d.typeform.com/to/y9Pm3aoL). ## How secure is Reth 1.0? Our security process is described in the [Alpha](https://www.paradigm.xyz/2023/06/reth-alpha#how-did-you-test-the-node-and-identify-bugs) and [Beta](https://www.paradigm.xyz/2024/03/reth-beta) releases. The codebase is extensively tested, and we use multiple tools such as [Kurtosis](https://paradigmxyz.github.io/reth/run/private-testnet.html), [Assertoor](https://github.com/ethpandaops/assertoor-test/), [Hive](https://github.com/ethereum/hive/tree/master/clients/reth), [Goevmlab](https://github.com/holiman/goevmlab/issues/113), our own fuzzers and more to automatically catch edge cases. Beyond that, we’re excited to announce the successful completion of a thorough security engagement with [Sigma Prime](https://sigmaprime.io/), developers of the [Lighthouse](https://github.com/sigp/lighthouse) Consensus client, which spanned several months and involved multiple security engineers. All reported issues have since been confirmed as fixed. The security assessment report is available [here](https://github.com/paradigmxyz/reth/blob/23d8e4e6f6871037c844558b970be2027f792b9d/audit/sigma_prime_audit_v1.pdf). We also co-funded the community audit of Revm with [Guido Vranken](https://github.com/guidovranken/). Revm is the EVM engine behind Reth, Foundry, and so much more critical Ethereum infrastructure, and we are keen to continue helping harden it for production usage. Learn more about this in Dragan’s [announcement](https://hackmd.io/G7zazTX4TtekCnj6xlgctQ). Finally, we are now part of the [Ethereum Foundation’s bug bounty program](https://ethereum.org/en/bug-bounty/), so if you find a bug, make sure to be a whitehat and report it! Also see our [SECURITY.md](https://github.com/paradigmxyz/reth/tree/main/SECURITY.md) for other information. ## OK, I’m sold! How do I install Reth? For node operators who are excited to download Reth, see our [releases page](https://github.com/paradigmxyz/reth/releases) and the [Reth Book](https://reth.rs/). We provide [signed binaries](https://reth.rs/installation/binaries.html) which are made available over popular package managers and [container registries](https://ghcr.io/paradigmxyz/reth), [DappNode](https://github.com/paradigmxyz/DappnodePackage-reth), as well as instructions on how to install from source: ```bash # MacOS brew install paradigmxyz/brew/reth # Arch pacman -S reth # or reth-git for installing from HEAD # Docker docker pull ghcr.io/paradigmxyz/reth:v1.0.0:latest # `cargo-install` RUSTFLAGS="-C target-cpu=native" cargo install https://github.com/paradigmxyz/reth --locked --profile maxperf --features=jemalloc,asm-keccak # from source git clone https://github.com/paradigmxyz/reth && cd reth && make maxperf ``` The above should be enough to get you started with running Reth via the `reth node` command! To get quickly started on Ethereum mainnet in few hours you can grab a database snapshot from [Merkle’s archive](https://snapshots.merkle.io/), or sync from [genesis yourself](https://reth.rs/run/mainnet.html#running-the-reth-node)! Here’s a simple 1-liner you can use alongside an Etherscan API key to get a locally synced Holesky network node without any consensus layer required, just Docker (note that in Docker you [need](https://stackoverflow.com/questions/32379570/how-to-reuse-the-same-volume-in-docker-when-restarting-a-container) the `-v` flag to persist the node’s database across container restarts): ```bash docker run --env ETHERSCAN_API_KEY=$ETHERSCAN_API_KEY ghcr.io/paradigmxyz/reth:latest node --debug.etherscan --chain=holesky ``` The CLI is modeled to be compatible with go-ethereum’s CLI, so once the binary or container is available, you can use Reth as a drop-in replacement for your nodes whether you’re running in a script or in Kubernetes, no additional steps needed! For observability please check the `--metrics` flag and [our documentation](https://reth.rs/run/observability.html), where we already provide a great Prometheus & Grafana setup. # Collaborate with the Reth team! We envision that in the next ten years, the most impactful crypto-infrastructure will be on Reth. We think the path to get there is clear, but we cannot do it on our own, despite our team’s quality and our large community of open source contributors. We’d like to collaborate with the ecosystem on the following two areas, among others: - Reth as a higher performance and lower-cost drop-in replacement for existing infrastructure: - RPC operations like Infura or Alchemy can run Reth to improve their RPC’s read throughput and latency, and improve their margins by operating cheaper nodes. - Staking operations like Coinbase or Figment can run Reth to improve their attestation rates and contribute to client diversity. - L2s like Optimism can run [OP-Reth](https://reth.rs/run/optimism.html?highlight=op-#running-op-reth) to improve their sequencers’ write throughput and latency, as well as contribute to L2 client diversity. - Managed Blockchain Services like AWS or GCP or Latitude can integrate Reth to offer all of the above with a 1-click deploy experience. - Reth will enable a new wave of EVM-centric infrastructure. Developers will: - Add support for more chains: Reth currently supports Ethereum and OP Stack-based networks. Developers can introduce support for their chain powered by Reth (or “Reth Inside”) using the [Node Builder](https://reth.rs/docs/reth/builder/struct.NodeBuilder.html), similar to how Binance has been doing for BSC and opBNB, to ensure a high performance low storage footprint node. This would apply for e.g. StarkWare, Polygon, Arbitrum, ZK Sync and any other EVM L1s/L2s that follow Ethereum’s account model database. We are particularly excited for developers to build new blockchains using Reth as an SDK, and innovate with novel architectures, modules, precompiles, and more. - Build Reth Execution Extensions: We'd like people to build rollups, [shared security services](https://www.paradigm.xyz/2024/06/symbiotic), and other projects on Reth which require a low latency and high context subscription to Ethereum. - Improve Reth’s internal modules: There are so many things to improve, whether it is reliably [JIT](https://www.paradigm.xyz/2024/06/revmc)'ing everything, [parallel execution](https://github.com/risechain/pevm), making the SDK easier and more general to use, benchmarking, testing, and more. We want tight feedback loops with ecosystem players, and would even train engineers from key external teams on the Reth codebase, to enable them to help their internal teams succeed. **We’re looking to bootstrap the first wave of Reth early partners. If you’re an industry player aligned with the above vision, please fill** [**in this form**](https://7dr10b0z31d.typeform.com/to/y9Pm3aoL)**. We’d love to hear from you and help you succeed with Reth.** # Where do we go from here? In the last 2 years, we have: 1. Announced the [Reth project](https://www.paradigm.xyz/2022/12/reth). 2. Released [Reth Alpha](https://www.paradigm.xyz/2023/06/reth-alpha). 3. Released [Reth Beta](https://www.paradigm.xyz/2024/03/reth-beta). 4. Announced [Reth AlphaNet](https://www.paradigm.xyz/2024/04/reth-alphanet). 5. Released [Reth Execution Extensions](https://www.paradigm.xyz/2024/05/reth-exex). 6. Announced our roadmap to [1 gigagas per second](https://www.paradigm.xyz/2024/04/reth-perf) and beyond. 7. Released [Revmc](https://www.paradigm.xyz/2024/06/revmc). 8. Released Reth 1.0 (this post). The Reth SDK is slowly but surely becoming a reality, starting with Ethereum and then with Layer 2s. We hope that you are as excited as we are to run Reth 1.0 in production. Expect soon a follow-up *Reth 1.1* release which will be focused on stable and performant support for the OP Stack via OP Reth, including detailed updated performance benchmarks. Our next major internal priorities are shipping the next Ethereum hard fork ([Pectra](https://github.com/paradigmxyz/reth/issues/7363)) and rolling out [Reth AlphaNet](https://www.paradigm.xyz/2024/04/reth-alphanet), with the goal of stress testing the limits of blockchain scalability and accelerating the rollup decentralization roadmap. Externally, we’d like to collaborate with ecosystem players building services on the Reth SDK either for supporting new EVM-based L1s/L2s or with Execution Extensions; make sure [to fill in the form we linked above](https://7dr10b0z31d.typeform.com/to/y9Pm3aoL) to collaborate with us. We’ll be talking about all this and the rest of our open source stack at [Frontiers](https://frontiers.paradigm.xyz/), on August 16-17th in San Francisco. Go apply! In the meantime, [go run Reth](https://reth.rs/), join our [community](https://t.me/paradigm_reth), or reach out directly to [georgios@paradigm.xyz](mailto:georgios@paradigm.xyz) if you want to work together. We’re also hiring cracked full-time Rust engineers, especially ones that can tech lead – let us know if that could be a fit for you. See you on [Github](https://github.com/paradigmxyz/reth). ## https://www.paradigm.xyz/writing/paradigm-fellowship-2024 # Paradigm Fellowship 2024 > We’re launching the 2024 Paradigm Fellowship, a program to gather crypto’s most formidable young engineers and researchers. Paradigm's mission is to solve the hardest problems in crypto, at all levels of the stack: consensus, execution, smart contract engineering, tooling, MEV, mechanism and market design. Today, we're launching [the 2024 Paradigm Fellowship](https://airtable.com/app51GRVQHUqlvY1S/pag0oVBYtTsSCWB6n/form), a program to gather crypto's most formidable young engineers and researchers to tackle these challenges. Fellows will work together with the Paradigm team on whatever areas are most interesting to them during an in-person San Francisco retreat September 26 - 29. The retreat is built around research discussions led by fellows, Paradigm and industry leaders. The fellowship is built for deeply technical, obsessive, and curious people early in their crypto journeys. We value slope over intercept and have no expectation that you are well-rounded - if you are world-class at something technical, we want to work with you. We anticipate most fellows will be high school or college-aged, but have no strict limits. Apply [here](https://airtable.com/app51GRVQHUqlvY1S/pag0oVBYtTsSCWB6n/form) by July 22nd. ## https://www.paradigm.xyz/writing/paradigm-files-comment-letter-on-esma-market-abuse # Paradigm Files Comment Letter on ESMA’s Market Abuse Consultation > Paradigm has filed a second comment letter regarding MiCA. On Tuesday, Paradigm filed a comment letter in response to a [consultation](https://www.esma.europa.eu/sites/default/files/2024-03/ESMA75-453128700-1002_MiCA_Consultation_Paper_-_RTS_market_abuse_and_GLs_on_investor_protection_and_operational_resilience.pdf) by the European Securities and Markets Authority (ESMA) on detection and prevention of market abuse, investor protection and operational resilience. Among other things, this consultation contemplates the application of ESMA’s Market Abuse Regulation (MAR) to crypto markets. **We believe this consultation could have significant implications for crypto’s base layer, given the way it characterizes MEV.** A copy of our comment letter can be found [here](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-c37fb1c53d/ac299925aeac9f021a2302a1af6b3b47/asset-https-cdn-sanity-io-files-dgybcd83-p-c37fb1c53d.pdf). In our letter, we make the following points: - While we support ESMA’s broad objective of ensuring that EU-based crypto markets are free of market abuse, we have concerns regarding ESMA’s proposed approach of leveraging the Market Abuse Regulations (MAR) in its application of Article 92(1) of MiCA. - Our concerns center around ESMA’s potential application of the MAR to crypto’s base layer as implied in Paragraphs 18 and 19 of the consultation, which together suggest ESMA's current understanding of blockchain technology could be outdated and lacking appropriate nuance. - Regulation that forces blockchain market microstructure into a specific architecture could thwart innovation and harm consumers in the long run, since the market is constantly changing and improving for the benefit of users. - There are some places where market abuse regulation could be particularly helpful, and where the applicability of the MAR is less fraught—just not at the base layer. As always, we appreciate the chance to provide this level of technical feedback to any policymakers around the world, including those in the US. ## https://www.paradigm.xyz/writing/revmc # Releasing Revmc > Accelerating the EVM by compiling to native code. We recently published [Reth’s high performance roadmap](https://www.paradigm.xyz/2024/04/reth-perf), calling for broader usage of “gas per second” as a performance metric in EVM blockchains, and detailing our plan to scale blockchains to 1 gigagas per second and beyond, a 1000x improvement from the status quo of Ethereum. **Today, we’re excited to open source** `revmc`**, a compiler for lowering EVM Bytecode into native code, demonstrating anywhere from 1.85x to 19x improvements in various realistic EVM benchmarks. We also** [**integrated**](https://github.com/paradigmxyz/reth/compare/main...dani/evm-compiler) `revmc` **in Reth and successfully synced the chain. Next up, we’re going to integrate** `revmc` **in OP Reth for L2 usage, where its improvements will shine in computationally heavy workloads.** Revmc is extensively tested, and will be further polished for production usage. The code is open source under the Apache/MIT license at [github.com/paradigmxyz/revmc](http://github.com/paradigmxyz/revmc). # Why build an EVM to native code compiler? The development of revmc is motivated by the desire to enhance the performance of the EVM, due to the inherent limitations of bytecode interpretation. Traditional EVM execution involves sequentially processing instructions through an interpreter, introducing significant overhead and latency because the instructions do not execute as native assembly code. By compiling EVM bytecode into optimized native machine code, the compiler enables direct execution on hardware, drastically reducing the overhead associated with virtual machine layers. Furthermore, compiling bytecode ahead of time (AOT) rather than just-in-time (JIT) during execution mitigates security risks associated with JIT compilation, such as vulnerabilities to malicious code designed to exploit the JIT process. The AOT approach allows for the highest demand contracts to be pre-compiled and stored securely, ensuring that the blockchain operates efficiently without compromising on security. These ideas have existed for a long time outside of crypto, e.g. in the case of Java or WASM’s JIT compiler, and inside of crypto for the [EVM](https://github.com/ethereum/evmjit) but also other [runtimes](https://github.com/lambdaclass/cairo_native) as well. We expect every blockchain’s runtime will have a compiled native assembly version of its runtime to provide higher performance. # How does it work? Revmc functions by compiling EVM bytecode, the set of instructions executed within the Ethereum Virtual Machine, into native machine code that the host system's processor can directly execute. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--c3e9362e32/e7417c87b457ba84c051d0b182b71c66/asset-https-cdn-sanity-io-images-dgybcd83--c3e9362e32.png) This process is done in two key steps: 1. **Analysis and Optimization**: The compiler first analyzes the bytecode to understand the control flow and data dependencies. This is implemented in our own [intermediate representation](https://github.com/paradigmxyz/revmc/blob/main/crates/revmc-builtins/src/ir.rs) (IR), which we then run custom optimizations over. 2. **Code Generation via LLVM**: We proceed to call out to LLVM via the `inkwell` crate where we pass the optimized IR, and then most of our work is done. LLVM will generate the corresponding native machine code tailored to the specific architecture of the host system. This step is crucial as it determines the efficiency of the resulting executable code. The compiler is able to work either blocking or in the background. When run in a hot-path, the compiler should be run in the background to ensure that it doesn’t hurt performance of the system while it’s running, and once compilation is done it can hot-swap the interpreted execution for native execution. For benchmarking, it’s better to compile all contracts in blocking mode first and then test against your workload. Once compiled, the native code can be stored on disk. This ensures that when the node is restarted it doesn’t spend redundant time recompiling contracts, and also allows the node operator to only run compiled contracts that they trust which have been compiled ahead of time, versus allowing any contract to be compiled at runtime. `Revmc` is [integrated into Reth](https://github.com/paradigmxyz/reth/blob/4f734fba5c52a475525ad876a65d878aa8941c33/bin/reth/src/compiler.rs#L242) via the Reth SDK’s NodeBuilder API, allowing node operators to opt-into running native code via the `--experimental.compiler` flag. We provide examples on how to [compile bytecode](https://github.com/paradigmxyz/revm-jit/blob/main/examples/compiler/src/main.rs) into native, as well as how to integrate it inside revm’s [EVM Builder](https://github.com/paradigmxyz/revm-jit/blob/main/examples/runner/src/lib.rs). We synced the node with `revmc` enabled and successfully validated the state root at the tip as of June 20th 2024. # How fast is it? We defined [criterion](https://github.com/paradigmxyz/revm-jit/blob/main/benches/benches/bench.rs) benchmarks against a some simple workloads, and present our results below: ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--65dfbfd44a/09c527f82b2f9e6e818ad464c95dd743/asset-https-cdn-sanity-io-images-dgybcd83--65dfbfd44a.png) **Fibonacci exhibits a 19x improvement**, which is representative of computationally heavy workloads. LLVM is particularly impressive here as it auto-vectorizes instructions where it can, and leverages its own native U256 type which is faster than [ruint](https://github.com/recmo/uint). LLVM is unfortunately not great at optimizing divisions, so code that’s heavy in such or similar operations may not see as great benefit. WETH and Counter are common cases of workloads we encounter in blockchains, first you read data from the host (e.g. the database), then you do some simple math, finally you write the data back into the host. Given host operations cannot be accelerated with a bytecode compiler, a 1.85x-2.77x improvement is great! We [integrated](https://github.com/paradigmxyz/reth/tree/dani/evm-compiler) and benchmarked `revmc` on Ethereum L1 via Reth’s execution stage (using `reth stage run execution`), which is the [dominant component of our historical sync](https://www.paradigm.xyz/2024/03/reth-beta). Because most of the historical sync’s workload on L1 is not compute-heavy, we saw less impressive results, O(1-10%) depending on the block range. # What is the future of Revmc? We think `revmc` will truly shine on high performance L2s with computationally-heavy workloads such as Base or OP Mainnet. To prove it out, we will roll out `revmc` in our upcoming Reth AlphaNet release. Roadmap-wise, we’d like to do a few things: - Extensively test, fuzz, benchmark it for production usage. - JIT compile code while the node is running in the background, without impacting sync time, allowing JIT bombs, or allowing remote code execution. - Implement [EOF support](https://github.com/ipsilon/eof). - Use more LLVM features and optimizations to make it faster. - Explore integrating it with other Ethereum clients over FFI. Until then, check our implementation on [Github](https://github.com/paradigmxyz/revm-jit). If you’re interested in working with us, reach out to [georgios@paradigm.xyz](mailto:georgios@paradigm.xyz) ## https://www.paradigm.xyz/writing/alloy-release # Releasing Alloy > After a year of development we're excited to release Alloy, an ecosystem of performant, well-tested and well-documented libraries for interacting with EVM-based blockchains. # The story so far One year ago, we [announced](https://www.paradigm.xyz/2023/06/alloy#what-does-alloy-include) Alloy, our full rewrite of the low-level building blocks for interacting with EVM blockchains, from the RPC types, down to the ABI encoders and primitive types. Today, we’re [releasing Alloy 0.1](https://github.com/alloy-rs/alloy/releases) ([crates](https://crates.io/crates/alloy)), the first release of the Alloy project including all the necessary utilities for interacting with an EVM-based blockchain. This release includes multiple API improvements and new features which we are excited to finally share with our users. As part of this release, we’re also officially [stopping maintenance of ethers-rs](https://github.com/gakonst/ethers-rs/issues/2667), and we’re encouraging everyone to move to [Alloy](https://www.paradigm.xyz/2024/06/alloy.rs). While we are only now releasing Alloy as the [top-level package including all JSON-RPC functionality](https://www.paradigm.xyz/2024/06/github.com/alloy-rs/alloy), the packages inside of [Alloy Core](https://github.com/alloy-rs/core/releases) with low-level type & ABI coders have been released for a few months now, and many of them have [>1 million all time downloads already](https://crates.io/search?q=alloy&sort=downloads)! To help users get up to speed with Alloy, we’re publishing the [Alloy Book](https://alloy.rs/) (including an ethers to alloy [migration guide](https://alloy.rs/migrating-from-ethers/reference.html)), the [Alloy](https://alloy-rs.github.io/alloy/) and [Alloy Core](https://docs.rs/alloy-core/latest/alloy_core/) docs, as well as [a lot of examples](https://github.com/alloy-rs/examples) showing all sorts of ways you can consume Alloy. Alloy is [already](https://sourcegraph.com/search?q=context:global+file:Cargo.toml+alloy+-repo:alloy-rs+-repo:foundry-rs+-repo:paradigmxyz&patternType=standard&sm=1&groupBy=repo) integrated in many Rust codebases, as well as all the projects we’re working on: [Revm](https://github.com/bluealloy/revm/), [Foundry](https://github.com/foundry-rs/foundry/) and [Reth](https://github.com/paradigmxyz/reth/). We’ve been using it in production ourselves for months, and we’re excited for it to be a performant and stable foundation for the Rust Ethereum ecosystem, as we envisioned in our [original announcement](https://www.paradigm.xyz/2023/06/alloy#what-does-alloy-include). With that out of the way, let’s dive in! # What are the highlights of the Alloy release? Alloy is written from the bottom-up to be performant, safe to use, and intuitive. We took our learnings from 4 years of ethers-rs development and put them all into designing a great client-side library for interacting with EVM-based blockchains. This took a lot of time, 1 year since we announced the Alloy project, but we’re proud of the result. Today we are excited to reveal some exciting new features co-architected and co-developed by our core team alongside [James Prestwich](https://twitter.com/_prestwich) who’s been maintaining Alloy with the rest of us over the last year. Big shoutout & thank you to James for pushing us to go beyond what ethers-rs allowed us before, and for being a core input to the successful delivery of today’s release. ## Reworked Provider Middleware architecture The most important abstraction in a RPC client library is the Provider, which lets you interact with the network. Users commonly want to extend basic provider operations: different gas estimations, gas escalators, alternative signing pipelines, and more. You want to do this in a modular way which empowers the developer to extend the behavior of the core library, instead of having to modify it. In ethers-rs, we had defined the [Middleware](https://docs.rs/ethers/latest/ethers/middleware/trait.Middleware.html) as the one-stop shop for modifying your RPC client’s behavior. If you wanted nonce management, it’s a middleware. Gas escalation, it’s a middleware. Signing transactions? Middleware. Flashbots bundles? Middleware. This approach worked because it gave us a lot of flexibility to override things as we wanted, but it also was too error prone, and had poor developer experience (e.g. expecting devs to `panic` when a function that’s required by the Middleware trait does not make sense to implement). Alloy redesigned that abstraction from the ground up. We split the Middleware in 3 overridable abstractions: - **Transport Layers:** The [Transport](https://alloy-rs.github.io/alloy/alloy/transports/trait.Transport.html) is the “wire” that carries over your data to the node. This now implement’s [Tower’s Service Layers](https://github.com/tower-rs/tower) which allows tapping into the [Tower Ecosystem](https://github.com/tower-rs/tower/blob/master/guides/building-a-middleware-from-scratch.md) for common middleware such as request retries, rate limits and more. - **Provider Layers:** Modeled after Tower’s Layers this allows overriding various Provider functionalities, e.g. if you wanted to hijack the `get_storage_at` method, you’d implement a [`ProviderLayer`](https://alloy-rs.github.io/alloy/alloy/providers/trait.ProviderLayer.html). - **Fillers:** This is probably the most exciting abstraction, Fillers handle everything about the transaction’s lifecycle. A user generally submits a partially populated transaction, and the provider is responsible for figuring out what data is missing and filling it in. Fillers can be installed independent of order from each other, solving a major footgun from ethers-rs. We provide the `.with_recommended_fillers()` method which aggregates commonly used Fillers via multiple [`JoinFill`](https://alloy-rs.github.io/alloy/alloy/providers/fillers/struct.JoinFill.html) ProviderLayers for convenience: - [`Wallet Filler`](https://alloy-rs.github.io/alloy/alloy/providers/fillers/struct.WalletFiller.html): Signs a transaction with a credential from a [wide suite](https://alloy-rs.github.io/alloy/alloy/signers/index.html): a local private key parsed from a hex string, a 12/24-word mnemonic, a keystore file, a hardware wallet like Trezor or Ledger, or even from a productionized key management system such as YubiHSM, AWS KMS or GCP KMS. - [`Nonce Filler`](https://alloy-rs.github.io/alloy/alloy/providers/fillers/struct.NonceFiller.html): Automatically manages nonces across all accounts. - [`Gas Filler`](https://alloy-rs.github.io/alloy/alloy/providers/fillers/struct.GasFiller.html): Handles calculating the gas price and the gas limit for each transaction. - [`ChainId Filler`](https://alloy-rs.github.io/alloy/alloy/providers/fillers/struct.ChainIdFiller.html): Embeds the correct chain ID into transactions depending on which chain is connected. Putting it all together, the stack of features we have can be seen below: ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--c6bdecab01/f4bf27b9509bf60f77029a609c48c1b5/asset-https-cdn-sanity-io-images-dgybcd83--c6bdecab01.png) This stack is bundled and exposed to the user via the [ProviderBuilder](https://alloy-rs.github.io/alloy/alloy/providers/struct.ProviderBuilder.html) which has a very ergonomic API: ```solidity // Create a signer from a random private key. let signer = PrivateKeySigner::random(); let provider = ProviderBuilder::new() // configures all the fillers .with_recommended_fillers() // sets the signer, allows configuring more than 1 signer which will be picked based on your transaction's `from` field. .wallet(EthereumWallet::from(signer)) // connects to the chain // can also use `.on_http`, `.on_ws`, or `.on_ipc` for no dyn dispatch // can also use `.on_anvil` for local testing // can also use `.on_client` for configuring auth options e.g. bearer auth. .on_builtin("ws://localhost:8545") .await?; let tx = TransactionRequest::new().with_to(...).with_value(...); let receipt = provider.send_transaction(tx).await?.get_receipt().await?; // do something with the receipt ``` Oh, we also made sure the Provider and Signers are object-safe, to make it easier to avoid generics in your code by `Box`ing them. For more on how to consume providers, see the [book](https://alloy.rs/building-with-alloy/connecting-to-a-blockchain/setting-up-a-provider.html). ## RPC Types Abstraction The world is going multichain, and that means more differences in RPC types! That was one of the most painful things in ethers-rs where we supported e.g. Celo-related fields with [a feature flag](https://github.com/gakonst/ethers-rs/blob/34ed9e372e66235aed7074bc3f5c14922b139242/ethers-core/src/types/transaction/request.rs#L63-L81). This meant that if you wanted to have a type-safe connection to both Celo and Ethereum you had to choose between importing the library twice, or expecting that the Celo fields would be None in all cases in Ethereum. This is a problem that we set out to fix. In Alloy, we define the [`Network`](https://alloy-rs.github.io/alloy/alloy/network/trait.Network.html) trait which defines the “shape” of every network for all its RPC requests and responses where each type must implement certain traits, e.g. [`Eip2718Envelope`](https://alloy-rs.github.io/alloy/alloy/network/eip2718/trait.Eip2718Envelope.html), [`TxReceipt`](https://alloy-rs.github.io/alloy/alloy/consensus/trait.TxReceipt.html), [`TransactionBuilder`](https://alloy-rs.github.io/alloy/alloy/network/trait.TransactionBuilder.html), summarized below: ```rust pub trait Network { /// The network transaction type enum. type TxType /// The network transaction envelope type. type TxEnvelope: Eip2718Envelope + Debug; /// An enum over the various transaction types. type UnsignedTx: From; /// The network receipt envelope type. type ReceiptEnvelope: Eip2718Envelope + TxReceipt; /// The network header type. type Header; /// The JSON body of a transaction request. type TransactionRequest: RpcObject + TransactionBuilder + Debug + From + From; /// The JSON body of a transaction response. type TransactionResponse: RpcObject + TransactionResponse; /// The JSON body of a transaction receipt. type ReceiptResponse: RpcObject + ReceiptResponse; /// The JSON body of a header response. type HeaderResponse: RpcObject; } ``` This allows us to import the library once without any feature flags, and depending on what network we specify we get different type abstractions. This is great! Type-safety, without redundant overhead! This is also the approach we’re taking in [Reth](https://github.com/paradigmxyz/reth/issues/7680) for allowing any developer to build a chain with custom RPC types on the server side, such as a network with native account abstraction. We provide two network implementations [`Ethereum`](https://alloy-rs.github.io/alloy/alloy/network/struct.Ethereum.html) and [`AnyNetwork`](https://alloy-rs.github.io/alloy/alloy/network/struct.AnyNetwork.html). Ethereum contains all the types you know and love. `AnyNetwork` however, wraps every RPC type with the [`WithOtherFields`](https://alloy-rs.github.io/alloy/alloy/rpc/types/struct.WithOtherFields.html) type which acts as a catch-all for any RPC response fields that do not match the Ethereum structure. A developer can choose their `Network` implementation using the [`.network::()`](https://alloy-rs.github.io/alloy/alloy/providers/struct.ProviderBuilder.html#method.network) method on the [`ProviderBuilder`](https://alloy-rs.github.io/alloy/alloy/providers/struct.ProviderBuilder.html). This allows us to support more networks than just Ethereum in a principled way, without burdening the core maintenance process. All you need to do is implement the network trait and all its associated types, import it in your code, and you’re done! Follow our work on defining the [`OpStackNetwork`](https://github.com/alloy-rs/op-alloy/issues/10) in the [`op-alloy`](https://github.com/alloy-rs/op-alloy/) crate, and reach out if you want to implement your own network! ## The sol! Macro We first talked about the sol macro in our [initial post](https://www.paradigm.xyz/2023/06/alloy#what-does-alloy-include). It is a rework of our previous [`abigen`](https://docs.rs/ethers/latest/ethers/contract/macro.abigen.html) macro, which was used to generate type-safe bindings to a contract’s ABI. The sol macro is not a compiler, but it is a complete representation of the Solidity type system in Rust, which means you can just paste Solidity in it, and it’ll codegen bindings for it, even allowing support for custom types! The sol macro also codegens JSON RPC bindings via the `#[sol(rpc)]` attribute. A deployer method is also generated if you pass it the `#[sol(bytecode = "...")]` attribute. For example, the code below would generate a `Counter::deploy` function as well as a `Counter::increment(&self)` method which you can use to increment the counter. ```solidity sol! { // solc v0.8.26; solc a.sol --via-ir --optimize --bin #[sol(rpc, bytecode="608080...")] contract Counter { uint256 public number; function increment() public { number++; } } } ``` To learn more about the sol macro, check the [page on the book](https://alloy.rs/highlights/the-sol!-procedural-macro.html) and its [detailed documentation](https://docs.rs/alloy-core/latest/alloy_core/sol_types/macro.sol.html). Interacting with a smart contract is similar to ethers-rs (note, no more `Arc`s!), with minor underlying changes in the API for fetching a transaction’s receipt. ```solidity let provider = ProviderBuilder::new().on_builtin("...").await?; // Deploy the contract. let contract = Counter::deploy(&provider).await?; println!("Deployed contract at address: {}", contract.address()); let receipt = contract.setNumber(U256::from(42)).send().await?.get_receipt().await?; println!("Receipt: {receipt}"); // Increment the number to 43 (without waiting for the receipt) let tx_hash = contract.increment().send().await?.watch().await?; println!("Incremented number: {tx_hash}"); // Retrieve the number, which should be 43. let number = contract.number().await?.number.to_string(); println!("Retrieved number: {number}"); ``` The sol macro’s functionality is also [integrated](https://github.com/foundry-rs/foundry/pull/7919) with Foundry in [`forge bind`](https://book.getfoundry.sh/reference/cli/forge/bind?highlight=bind#forge-bind) for generating type-safe bindings for all your client-side integrations. Check out the updated [Foundry Rust template](https://github.com/foundry-rs/foundry-rust-template) if that’s of interest to you! ## Extensive documentation and tests We want our users to be equipped with high-level tutorials & examples for consuming the project, as a library. To achieve that, we provide a large surface area of documentation: - [Alloy Docs](https://alloy-rs.github.io/alloy/): Rustdoc documentation for each function on the Alloy repository. - [Alloy Core Docs](https://docs.rs/alloy-core): Rustdoc documentation for each function on the Alloy Core repository. - [Alloy Examples](https://github.com/alloy-rs/examples): Wide range of code examples on how to consume Alloy in your day to day. - [Alloy Book](https://alloy.rs/): Tutorials and long form writeups about all things Alloy. Making the docs excellent is a top priority for us, please [open issues on the book](https://github.com/alloy-rs/book) with more tutorials you’d like to see. # What is next for Alloy? Today’s 0.1 release marks [Alloy](https://alloy.rs/) at feature parity with ethers-rs and beyond, while also being performant, well-tested and well-documented. We think Alloy is the tool of choice for power users, yet it is simple and intuitive enough for anyone to work with. Our next priority is the 1.0 release, which means we’ll be polishing our APIs and working towards proper stability. While we don’t offer any formal stability guarantees, most of the APIs are baked, and we do not expect large changes. To help achieve Alloy’s long term success, we’re looking to add 1 full-time staff-level engineer to the Alloy team who will help drive the day to day of the project, as well as help us grow the contributor base. If the above sounds interesting, please reach out to [georgios@paradigm.xyz](mailto:georgios@paradigm.xyz). We’re excited for every ethers-rs user to [port](https://alloy.rs/migrating-from-ethers/reference.html) their code to use Alloy, as well as new services to be built with it! Go read the docs of [alloy-core](https://docs.rs/alloy-core) and [alloy](https://alloy-rs.github.io/alloy/), the [examples](https://github.com/alloy-rs/examples/), and the [book](https://alloy.rs/)! Until then, see you on [Github](https://github.com/alloy-rs)! ## https://www.paradigm.xyz/writing/paradigms-third-fund # Announcing Paradigm's Third Fund > Paradigm has raised our third fund: an $850M venture fund focused on crypto projects at the earliest stages. Paradigm has raised our third fund: an $850M venture fund focused on crypto projects at the earliest stages. When we founded Paradigm in 2018, we believed that crypto would be one of the most important technical and economic shifts of the coming decades. Six years later, that belief has only gotten stronger. Bitcoin has monetized to $1T+. Ethereum, Solana and other blockchains are scaling. Stablecoins are being adopted globally. Frontier research speeds along. New infrastructure is enabling consumer applications. Hundreds of millions of people own crypto. And crypto is now a main character on the world’s political stage. In that time, Paradigm has been proud to be involved as early contributors to and the first outside investor in projects that have shaped the crypto landscape. Uniswap pioneered the use of AMMs for decentralized exchange. Optimism invented one of the leading models for blockchain scaling. Flashbots defined the concept of MEV and reinvented how blocks are built. This is the sort of early-stage work that we love contributing to, and it’s what we’ll be increasingly focused on going forward (including through our [EIR & incubation programs](https://www.paradigm.xyz/2023/07/collaborate-with-paradigm)). It’s more important than ever to accelerate a positive future for crypto, not just as investors but as builders. Over the past few years, we’ve launched several open source projects including [Foundry](https://github.com/foundry-rs/foundry), a popular Ethereum development tool, and [Reth](https://github.com/paradigmxyz/reth), a high performance Ethereum execution node, with the goal of pushing the crypto frontier forward. We’re excited to dedicate significant effort to such projects over the coming years. Thank you to our community of portfolio founders and collaborators, as well as to our limited partners, for their support and partnership with Paradigm. ## https://www.paradigm.xyz/writing/settling-the-unsettled # Policy Lab RH-001: Settling the Unsettled > Paradigm Policy Lab-funded research argues that public blockchains can be used to settle financial transactions, stressing the importance of developing proactive and multi-faceted solutions to settlement vulnerabilities before a “black swan” scenario occurs. Last year, the Policy Lab awarded a Research Hub grant to [Natasha Vasan](https://x.com/NatashaVasan) for research on legal issues related to settling financial transactions using public blockchains. On the heels of last week’s House Financial Services Committee Digital Assets Subcommittee hearing on tokenization, we’re excited to publish Natasha’s research as the first Policy Lab white paper. The paper can be accessed [here](https://policy.paradigm.xyz/assets/writing/RH-001_Vasan2024.pdf). Natasha’s paper argues that public blockchains can be used to settle financial transactions, even in the absence of deterministic settlement finality — showing that skeptics who argue otherwise (and point to permissioned blockchains as the only solution) are wrong. In addition to laying out some important facts on the legal underpinnings of settlement as a financial construct, the paper also walks through various scenarios where settlement issues could arise and highlights legal and market-based solutions for mitigating risk and uncertainty. The paper creates a taxonomy of settlement risks for different kinds of transactions involving public blockchains, highlighting that principal settlement risks are uniquely salient in the context of “hybrid” cross-chain or onchain-to-offchain transactions. Given the surge of projects operating at the crypto x TradFi nexus and subsequent regulator and lawmaker interest, we believe Natasha’s research is an important contribution to a growing body of work, one that helps surface real challenges that builders are working to solve. If there are topics you find interesting that have a novel policy twist, the Paradigm Policy Lab may be able to help. Reach out at [policylab@paradigm.xyz](mailto:policylab@paradigm.xyz). *Acknowledgements: Natasha thanks Mikołaj Barczentewicz and Joshua Rivera for their assistance with the paper.* ## https://www.paradigm.xyz/writing/symbiotic # From Staking to Restaking > Introducing Symbiotic, a generalized, permissionless protocol providing shared security through restaking. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--531334db97/70d136d8938ef3c37213a670eb156b6d/asset-https-cdn-sanity-io-images-dgybcd83--531334db97.png) Decentralized networks need coordination mechanisms to incentivize and hold their node operators accountable. This began with Proof of Work and later evolved with Proof of Stake, a significant development that allowed networks to source validator security through economic collateral. The next frontier of this is shared security, which expands the services node operators in PoS can provide while making use of the same underlying economic collateral. Symbiotic is a generalized, permissionless protocol providing shared security through restaking. We are investing in Symbiotic alongside [Cyber.Fund](https://cyber.fund/), a collaborator of ours on Lido and other protocols. We believe Symbiotic’s flexible and permissionless approach will be a great fit for many of the most useful consumers of shared security and, over time, could be a default option for bootstrapping a decentralized network. ## Background Lido, Ethereum’s largest liquid staking token, was founded on the insight that separating staking capital from validator infrastructure (labor) is possible without modifying Ethereum’s consensus, using a smart contract layer for routing users’ stake to operators in a decentralized way. This separation, to become “delegated,” is a natural and inherent tendency of Proof of Stake systems. Lido enabled Proof of Stake to scale on Ethereum without compromising decentralization by matching staked Ether with the highest-quality infrastructure operators. Paradigm began collaborating with Lido protocol contributors in 2021. Since then, Lido has grown from ~$800M to over $36B in staked ETH deposits and fostered the most robust ecosystem of node operators: [reputable, geographically distributed, diverse, and aligned](https://app.hex.tech/8dedcd99-17f4-49d8-944e-4857a355b90a/app/3f7d6967-3ef6-4e69-8f7b-d02d903f045b/latest). Paradigm has also long supported the Cosmos ecosystem, leading Tendermint Inc.’s original Series A and later investing in Osmosis and dYdX. Through Cosmos, we observed the challenges of recruiting validators and capital from scratch every time developers wanted to launch a new chain, which significantly limited the pace of innovation. A natural “phase two” of Ethereum staking is to repurpose stake and validator infrastructure and expertise beyond L1 consensus to secure many protocols at once. This makes it easier to stand up new protocols. Cosmos pioneered this idea as “shared security,” and EigenLayer’s “restaking” recognized that an ETH-centric approach could successfully bootstrap this validator ecosystem. This primitive is novel and powerful, but considering the risks of [overloading Ethereum’s consensus](https://vitalik.eth.limo/general/2023/05/21/dont_overload.html), it needs to be designed thoughtfully to enable useful applications safely. As we considered the market, we realized Konstantin was also interested. Through him, we met Misha and Algys, the founders of Statemind, a top auditor with a close working relationship with Lido (i.e., on their V2 audit), Curve, InstaDapp, and others. We were aligned with how they each viewed the market and jumped at the opportunity to partner. ## Introducing Symbiotic Symbiotic is a new shared security system. It is designed as a thin coordination layer that is maximally flexible, permissionless, and reliable. Symbiotic allows network developers to have complete control over specifying their (re)staking implementation and operator set. Zooming out, the long-term goal of the protocol is to provide primitives that help networks navigate the roadmap to decentralization while prioritizing safety and capital efficiency. #### Flexible Protocols built on Symbiotic can control their collateral assets, rewards, and slashing criteria. Symbiotic will initially focus on staked ETH as the largest pool of stake capital. However, the protocol is general-purpose and can accept any ERC-20 asset as collateral. In time, we expect Symbiotic will service many assets and related operator infrastructure groups. Symbiotic network developers will also have full control of their operator selection mechanics. Over time, it will be possible to maximize the number of participants, their geographic distribution, and their overlap with other protocols, reputation, and other selection criteria. #### Permissionless The core Symbiotic contracts are immutable, which removes external governance risks. Symbiotic will never have a central multisig, slashing committee, or other permissioning mechanisms for shared security services. Services built on Symbiotic will be able to support many different slashing resolution mechanisms, which we believe is critical for innovation. #### Reliable Building infrastructure operator networks is challenging, as we have learned in working with Lido. Symbiotic will ensure that restaking can scale by onboarding reputable and geographically distributed infrastructure partners and by supporting smaller operators. ### What should be built on Symbiotic? At Paradigm, we view restaking protocols as delegated staking systems at their core. Stakers are incentivized to vote their capital behind operators they believe will be honest validators. In some sense, this is how Ethereum staking (via stETH and other LSTs) already works today. Near term, we believe that the clearest and safest use case of shared delegated proof of stake security is for bootstrapping new consensus instances: - Electing the operators of new L1s (e.g. Cosmos appchains, sidechains, etc.) - Decentralized sequencing - Distributed auctions (e.g. leaderless auctions) - MPC and Threshold Decryption networks In the long term, we are also interested in L1 block production use cases, such as new types of MEV auctions, preconfirmations, and based sequencing. However, we think block production use cases may take longer to blossom: they often benefit from adoption by a greater fraction of L1 proposers and may pose more [direct security risks](https://vitalik.eth.limo/general/2023/05/21/dont_overload.html) to Ethereum L1. To help achieve that vision, we also created [Reth Execution Extensions (ExEx).](https://www.paradigm.xyz/2024/05/reth-exex) ExExes allow fast data extraction and processing from a node and enable networks/services to peer with other ExExes to agree on the state that should eventually be injected back into Ethereum. We want to make ExExes the best tool for building shared security services using Symbiotic. Of course, Symbiotic is a general system, and developers can build any protocol they want on top of it without asking for permission or using our codebases. These are just our own intuitions about the types of use cases most likely to succeed. Please [reach out](mailto:arjun@paradigm.xyz) if you are interested in collaborating with us and Symbiotic on any of these applications, or others that we have yet to imagine! ## https://www.paradigm.xyz/writing/priority-is-all-you-need # Priority Is All You Need > In this post, we introduce MEV taxes, a mechanism that arbitrary applications can use to capture their own MEV. This mechanism could be used today on OP Stack L2s like OP Mainnet, Base, and Blast, because the block proposers on those chains follow a set of rules we call competitive priority ordering. ## Introduction In this post, we introduce MEV taxes, a mechanism that arbitrary applications can use to capture their own MEV. This mechanism could be used today on OP Stack L2s like OP Mainnet, Base, and Blast, because the block proposers on those chains follow a set of rules we call *competitive priority ordering*. To implement a MEV tax on one of these chains, a smart contract charges a fee that is a function of the priority fee of the transaction. We show that if an application charges searchers a MEV tax of (say) $99 for every $1 of priority fee, it can capture 99% of the competitive MEV for that transaction. MEV taxes are a simple technique that opens up a vast design space. You can think of them as allowing any application on the chain to run its own custom MEV auction, without needing any offchain infrastructure of its own, just by hooking into a single shared auction run by the block proposer. We show how MEV taxes could be used to solve three major problems in MEV research: - Decentralized exchange (DEX) routers that optimize the price received by the swapper - Automated market makers (AMMs) that minimize the loss-vs-rebalancing (LVR) experienced by liquidity providers - Wallets that let their users capture any “backrunning” MEV created by their transactions But there’s a catch. MEV taxes only work if block proposers strictly follow the rules of competitive priority ordering, which include sorting transactions by priority fee without censoring, peeking at, or delaying any. If block proposers deviate from those rules, they can evade MEV taxes to capture the value for themselves. Today, therefore, MEV taxes depend on trusting L2 sequencers, and would likely not work at all on Ethereum L1, where block building is dominated by a [competitive builder auction](https://github.com/flashbots/mev-boost) that maximizes revenue for the proposer. Still, the power and flexibility of MEV taxes suggests that priority ordering may be the right choice for platforms that can provide it today. And the relative simplicity of competitive priority ordering suggests that there may be a viable way to enforce it in a decentralized way, without having to trust a single sequencer. We hope this post motivates further work on that problem. ## Priority ordering When someone sends a transaction on an Ethereum L1 or L2, they specify a priority fee, which they pay to the block proposer. [^1]You can imagine this is specified as `priorityFeePerGas`, a number that is multiplied by the gas used in the transaction to get `builderPriorityFee`—the total payment in ETH. [^2] There is no rule in the Ethereum protocol that transactions in a block must be ordered greedily by descending `priorityFeePerGas`. However, that is a popular way to build blocks—for example, it is the default algorithm used by sequencers of [OP Stack](https://docs.optimism.io/) chains, as well as geth and reth. Not only does priority ordering let transactors efficiently express the urgency of their transactions, it also naturally channels certain kinds of MEV to the block proposer. That happens because priority ordering turns competition for MEV into a [priority gas auction](https://arxiv.org/pdf/1904.05234). When there is an opportunity to profit from interacting with the chain, such as by arbitraging an AMM against a centralized exchange, searchers compete to claim that opportunity first. If the chain uses priority ordering to determine transaction inclusion and ordering, the searchers compete by setting high priority fees on their transactions. In a competitive scenario where risk-free profits are competed down to zero, the winning searcher should end up paying the full amount of MEV in priority fees. [^3] So if there is 100 ETH in profit to be gained from interacting with a contract, the first transaction to claim it will set a priority fee of 100 ETH. (We discuss some caveats to this in the Limitations section). ## MEV taxes Suppose a smart contract wants to capture the MEV from any transaction that interacts with it. There is a vast library of research on different application-specific ways that smart contracts could try to capture their own MEV. But in fact, we don’t necessarily have to know anything about the application. If we know that the block is being constructed through competitive priority ordering, then we have one universal signal for the amount of MEV in the transaction: the priority fee. We propose that the smart contract can look at the priority fee of the transaction and charge its own fee as some increasing function of it. For example, the contract might require whoever calls it to transfer `applicationPriorityFee = 99 * proposerPriorityFee` in ETH to the contract. [^4] This new fee is paid by the searcher sending the transaction, so it affects the behavior of that searcher. If there is 100 MEV in an opportunity, the winning transaction will now only set a priority fee of 1 ETH, since that will result in a total payment of 100 ETH (1 ETH to the block proposer, and 99 ETH to the smart contract). Any higher priority fee would make the transaction unprofitable; any lower priority fee would result in losing the opportunity to a competitor who set a higher fee. This means the smart contract has captured 99% of the MEV in the transaction. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--068f42ca63/d74b768f2f5f76dfafeeea37ca277cd5/asset-https-cdn-sanity-io-images-dgybcd83--068f42ca63.gif) We call this extra fee imposed by the smart contract a **MEV tax**. MEV taxes let an application hijack priority ordering for its own benefit, allowing it to recapture MEV for its users rather than leaking it to the block proposer. If this fee increases sufficiently fast as a function of `priorityFeePerGas`, then only a negligible amount of MEV will accrue to the proposer. Since `priorityFeePerGas` is denominated in wei (one billionth of a billionth of one ETH), we have a lot of precision to work with. For example, as long as the MEV tax is sufficiently sensitive that a `priorityFeePerGas` of 50,000 would result in a prohibitively high tax, then the total payment to the proposer would be less than $0.01. [^5] However, there is an important caveat. As discussed in the Limitations section, MEV taxes only work if block proposers follow certain rules—what we call “competitive priority ordering”—rather than deviating from those rules in order to maximize their own revenue. Enforcing these rules in a trustless way is an open problem. ## Single-application MEV capture Here we sketch out how, on a chain that is guaranteed to use competitive priority ordering for block building, MEV taxes could be used to mitigate three important problems in MEV: letting DEX interfaces improve trade execution for swappers, letting AMMs reduce losses to arbitrage for their LPs, and letting wallets reduce MEV leakage for their users by selling the right to backrun the user. ### DEX routers In intent-based DEX routing protocols like [UniswapX](https://uniswap.org/whitepaper-uniswapx.pdf) and [1inch Fusion](https://1inch.io/fusion/), a user (Alice) signs an intent to swap, and searchers compete to route or fill that intent at the best possible price for Alice. Current versions of UniswapX use two mechanisms to run that competition: a Dutch auction where Alice’s limit price changes over time until a searcher fills it, and an initial offchain request-for-quote (RFQ) auction to set the starting price of that Dutch auction. On a platform that guarantees competitive priority ordering, UniswapX could replace these with a single mechanism: a MEV tax. It could implement this by having the user sign an order that can be filled immediately by anyone, but with an execution price that is set as a function of the transaction’s priority. For example, if Alice has a UniswapX order to sell 1 ETH, she could define the execution price of the order to be `minimumPrice + ($0.01 * priorityFeePerGas)`. `minimumPrice` could be some fixed value that she expects to be significantly lower than the current price. Searchers would compete to fill Alice’s order by submitting transactions. Whichever transaction has the highest priority fee and doesn’t revert would get to fill the order, which should guarantee that the swapper gets the best price that searchers can find. (Some exceptions to this are discussed in the Limitations section.) If Alice’s minimum price is $3,000 and the current price of ETH is $3,500, `priorityFeePerGas` in the winning transaction would be about 50,000. (Observe that in a transaction that costs 200,000 gas, this will result in a payment of only about 10 billion wei—around $0.000035—to the block proposer.) This has some potential benefits over the existing mechanisms used in UniswapX. Orders that use MEV taxes could complete faster and at a better price than orders which use Dutch auctions. As discussed in [this paper](https://moallemi.com/ciamac/papers/pricing-dutch-auctions-2024.pdf), onchain Dutch auctions leak some value to MEV due to price movements between blocks, and may take many blocks to complete. In contrast, orders that use MEV taxes could typically be completed in the next block while capturing the vast majority of their MEV. Unlike an offchain RFQ, the auction to fill an order that uses MEV taxes would happen atomically with transaction execution onchain. This means that a winning bidder could be guaranteed that they are only committed to fill the order if their onchain transaction succeeds. That could make it easier for onchain liquidity like AMMs to compete with offchain liquidity, meaning UniswapX could serve as an even more effective router for multi-pool systems like Uniswap v4. ### AMMs Normally, AMMs leak value to arbitrageurs who trade against stale prices at the top of the block, as discussed in the [loss-vs-rebalancing](https://arxiv.org/pdf/2208.06046) [papers](https://web.archive.org/web/20241006155531/https://arxiv.org/pdf/2305.14604). We can use MEV taxes to have AMMs capture that MEV. To keep things simple, we’ll discuss how this might work on an AMM without concentrated liquidity. (If you’re interested in how this kind of problem could be solved with concentrated liquidity, [Sorella](https://twitter.com/SorellaLabs) will soon be publishing one solution.) An AMM can capture MEV by charging an extra fee as a function of the priority fee on the transaction, allowing it to auction off the right to trade first in the block. There are many ways to calculate and denominate that fee. We’ll discuss one arguably neutral one—denominating it in units of pool liquidity, `sqrt(xy)`. The winning transaction would be the one that increases the pool’s liquidity by the most. When executing the first transaction on a pool in a block, instead of enforcing the condition `x_end * y_end > x_start * y_start`, the pool could enforce the condition (with `a` as some constant): x_end \* y_end > (sqrt(x_start \* y_start) + a\*priorityFeePerGas)^2 This formula would incentivize the arbitrage trader to trade to the true price, and after that trade, the midpoint price on the pool should be the true price. [^6] After that first transaction, trades could work like they do on Uniswap v2, with fixed swap fees. Uninformed transactions that want to trade on the pool without paying an extra MEV tax would set a low priority fee. There are many other ways to implement MEV taxes on an AMM that would have different effects. For example, MEV taxes could be denominated in the input or output token of the swap, could affect the swap fee percentage applied by the pool, or could determine the minimum price of the user’s trade. We think this is an interesting design space to explore. ### Backrunning auctions The above descriptions show how certain applications could be designed to avoid leaking MEV. However, what if a wallet wants to try to help its users capture the MEV they create from arbitrary transactions interacting with *any* application, even ones that don’t incorporate MEV taxes? For example, when Alice makes a large transaction on an AMM, she sometimes create an arbitrage opportunity for “backrunners” to move the price back. This is normally leaked to MEV, rather than going to Alice. [MEV-Share](https://docs.flashbots.net/flashbots-protect/mev-share) and [MEVBlocker](https://mevblocker.io/) are two protocols that allow users to capture MEV from their transactions, but they rely on a complex offchain auction system. [The Orderflow Auction Design Space](https://frontier.tech/the-orderflow-auction-design-space) describes some other solutions. MEV taxes, when combined with an intent-based smart contract wallet, could allow us to construct an alternative system to capture backrunning MEV for Alice. Suppose that instead of creating a transaction that trades on the AMM, Alice signs an intent that anyone can submit to Alice’s smart contract wallet to cause it to take that action. Alice’s smart contract wallet charges whoever submits that transaction a MEV tax, which is paid to Alice. The searcher who submits Alice’s intent will have the exclusive right to backrun her, since they can do so atomically in the same transaction. As a result, if searching is competitive, all of the profit from backrunning Alice should accrue to Alice through her MEV tax. Note that this system may not necessarily protect users from attacks that involve *frontrunning* user transactions, because a transaction that frontruns a user may be able to avoid paying a MEV tax to that user. This issue (and some possible mitigations for it) is discussed in greater detail in the Limitations section below. Nevertheless, this could at least be an improvement on systems that use public mempools without any mitigations. ### Other use cases In addition to these examples, other potential uses of MEV taxes could include almost anything that currently uses an offchain or Dutch auction, such as: - Protocols for oracles to capture the oracle extractable value they create, like [Oval](https://medium.com/uma-project/announcing-oval-earn-protocol-revenue-by-capturing-oracle-mev-877192c51fe2) - Refinancing auctions in NFT-collateralized lending protocols like [Blend](https://www.paradigm.xyz/2023/05/blend) - Lending protocol liquidations that [leak less value](https://moallemi.com/ciamac/papers/pricing-dutch-auctions-2024.pdf) than Dutch auctions ## Cross-application MEV capture The above solutions are designed to capture the MEV from interacting with a single application. But sometimes it may be possible for a searcher to capture even more value by interacting with multiple applications in the same transaction. If only one of those applications has a MEV tax, then all the MEV from the transaction should go to the application with the MEV tax, regardless of how high or low that MEV tax is. But what if a searcher’s transaction interacts with two applications that use MEV taxes? For example, what if there is some MEV that can only be captured by filling one of the MEV-taxed UniswapX orders described above against a MEV-taxed AMM? In that case, the relative amount of excess MEV captured by each application is determined by how those applications set their MEV taxes. If the value `app_i` charges as a MEV tax is given by the function `tax_i(priority)`, then the priority of the winning transaction can be determined by solving for priority in this equation: tax_1(priorityPerGas) + tax_2(priorityPerGas) = total MEV (Technically, we could add a third term for `priorityPerGas * gasUsed` to account for the priority fee paid to the block proposer, but we will ignore that since, as discussed in Appendix A, it will likely be negligible under normal conditions.) In the simple case of MEV taxes that are linear in `priorityPerGas` (so `tax_1(priorityPerGas) = a_1 * priorityPerGas`), you can solve for the share of MEV received by each application: a_1 \* priorityPerGas + a_2 \* priorityPerGas = MEV priorityPerGas = MEV/(a_1 + a_2) tax_1(priorityPerGas) = (a_1/(a_1+a_2))\*MEV tax_2(priorityPerGas) = (a_2/(a_1+a_2))\*MEV When setting its own MEV tax, an application faces a tradeoff—higher taxes let it capture a greater share of cross-application MEV when it occurs, but mean it could miss out on some cross-application MEV if there are competing ways to extract it. For example, if there is an AMM that charges a MEV tax on every trade, then a MEV-tax UniswapX order might be more likely to be filled by a different AMM or an offchain filler. In many cases, there may be an equilibrium in which two applications design their MEV taxes in order to share MEV in a way that maximizes each of their welfare. For example, a MEV-tax AMM would likely want to capture value from a single informed trader near the top of the block, but then would want to provide liquidity to other traders and applications (including ones that use MEV taxes) with a low fixed fee. In that case, the AMM is likely to set a relatively low MEV tax (say, `$0.00001 * priorityFeePerGas`), so that the arbitrage transaction (if any) happens early in the block, and then charge no MEV tax on subsequent transactions in the block. Applications like UniswapX that want to interact with the AMM can set a much higher MEV tax (say `$0.01 * priorityFeePerGas`), to ensure that their transactions are included after the pool is already arbitraged. With those relative taxes, the AMM would end up arbed first even if there was only $1 of MEV on it and $50,000 of MEV in a UniswapX order. We think this is a broad design space worthy of future study. ### Incentive incompatibility MEV taxes are not incentive-compatible for a monopolistic block proposer. They only work if there is fair competition for transaction inclusion, which can only happen if the block proposer follows rules that we’ll call “competitive priority ordering,” rather than maximizing their own revenue. Informally and non-exhaustively, we suggest that these rules should include: - Priority ordering. Transactions within a block must be ordered in descending order of `priorityFeePerGas`. - Censorship-resistance. If the block proposer receives a transaction t1 during the block, and the block is either not full or includes some transaction t2 such that `t2.priorityFeePerGas < t1.priorityFeePerGas`, then the block must include transaction t1. - Pre-transaction privacy. The block proposer must accept transactions through a private endpoint and must not share such transactions with anyone else before committing to the block, or use the content of those transactions as an input in constructing its own transactions. - No last look. The block proposer must set a definite time `blockTime` before which they accept transactions from anyone, and after which they do not accept transactions from anyone. If one or more of these properties is violated, it may weaken the effectiveness of MEV taxes. A block proposer that violates censorship-resistance can avoid most MEV taxes by excluding competing transactions and submitting a zero-priority transaction that takes the opportunity for itself. A block proposer that violates pre-transaction privacy could steal MEV from other transactions or peek at their priority fees to know exactly how high it needs to set its own, while one that is able to submit transactions later than anyone else would have a free “last look” on whether to outbid others for an opportunity, either of which could create adverse selection problems that ultimately discourage competition. Unfortunately, while the first property would be easy to enforce at the protocol layer, enforcing the other properties trustlessly is an open problem. In the absence of enforcement at the protocol layer, a single sequencer who commits to these rules needs to be trusted not to deviate from them, and if proposers outsource block building to a competitive revenue-maximizing auction (such as Ethereum L1’s [MEV-Boost](https://github.com/flashbots/mev-boost)), blocks will likely not follow them. These issues can be “solved” with a single trusted sequencer who commits to use competitive priority ordering for block building. They may also be solvable with a decentralized mechanism using some combination of consensus, cryptography, and/or trusted execution environments, such as Sorella’s Angstrom, Flashbots’s SUAVE, [Leaderless Auctions](https://www.paradigm.xyz/2024/02/leaderless-auctions), or [Multiplicity](https://ethresear.ch/t/multiplicity-a-gadget-for-multiple-concurrent-block-proposers/14962). ### Full blocks One exception to the normal operation of MEV taxes happens when blocks are completely full. In that case, block proposers may have to leave out lower-priority transactions, rather than simply including them late in the block. Since transactions that interact with MEV-taxed applications are likely to have extremely low priority fees, those applications are likely to be crowded out by applications that don’t use MEV taxes, or ones that have extremely low MEV taxes. However, in a chain that uses an EIP-1559-like mechanism to set a separate basefee, it should be relatively rare for blocks to be completely full. Additionally, given that *some* transactions need to be delayed when blocks are full, delaying transactions that express lower urgency by setting higher MEV taxes may be a reasonable result. ### Reverted transactions MEV taxes effectively rely on single-block auctions in which every “bid” is a transaction. One downside of those auctions is that losing bids will generally result in reverted transactions being included onchain, paying some basefee and congesting the chain. If a sequencer can exclude failed transactions entirely, that would alleviate this issue, though that can be difficult to implement even with a centralized sequencer. (It would also not strictly obey the censorship-resistance property described above, though that definition could be adjusted.) A more sophisticated sequencer may be able to optimize this process by allowing transactions to specify which contentious auctions they are participating in, giving the sequencer enough information to skip subsequent transactions that it knows would fail. ### Leaking of user intents MEV taxes only work if there is competition among searchers, which means the opportunity needs to be somewhat widely known. For applications like AMMs, where the opportunity is visible onchain, that should happen naturally. But for applications like intent-based routing or backrunning auctions, that means the application may need to share the user’s intent with searchers. In some cases, the temporary privacy lost from broadcasting the user’s intent before it is fulfilled may leak value in a way that cannot be recaptured by a MEV tax. For example, suppose Alice wants to purchase a low-liquidity token using the backrunning auction protocol described above. She publishes a signed intent for her smart contract wallet to purchase that token on an AMM, setting some slippage tolerance. Searchers could race to push the price of that token to her slippage tolerance in a high-priority transaction, *without* filling the user’s order. The winner, Bob, could then non-competitively fill Alice’s intent by including and backrunning it in a low-priority transaction, thus sandwiching Alice’s trade and giving her a worse price while evading her MEV tax. A similar issue could happen with purchases of NFTs. Note that such an attack would be risky for Bob, since he would not be able to guarantee atomicity between buying the token and selling it to Alice. A naïve Bob could fall victim to a “sandwich ripping” trap in which Alice publishes an intent to purchase a worthless token from herself, causing Bob to purchase it in anticipation of sandwiching her trade, but Alice revokes her intent before Bob is able to complete the sandwich. Applications may also be able to mitigate this by limiting the set of searchers with which they share intents and monitoring their behavior, as many existing orderflow auctions do. It may also be possible to combine MEV taxes with privacy-aware builder features like envisioned in Flashbots’s designs for [SUAVE](https://writings.flashbots.net/mevm-suave-centauri-and-beyond). Finally, in cases where Alice decides that the costs of sharing her intent outweigh the benefit from competitive searching, she could construct a transaction herself and submit it directly into the block. As discussed above, an ideal implementation of competitive priority ordering would provide pre-transaction privacy from the block proposer. ## Discussion and prior work *Priority gas auctions*. Some of the dynamics of priority ordering in decentralized blockchains were studied in the [Flash Boys 2.0](https://arxiv.org/pdf/1904.05234) paper, which coined the term “miner extractable value.” That paper observed that Ethereum miners (when that network used proof-of-work) were already ordering transactions by priority, and that arbitrageurs were relying on that behavior to participate in “priority gas auctions” in which they bid for the right to be included first in a block, which led to much of the MEV from decentralized exchange arbitrage accruing to miners. *First come, first served*. Some attempts at MEV mitigation through transaction ordering rules, such as [Themis](https://eprint.iacr.org/2021/1465) or [Arbitrum One’s current sequencer](https://docs.arbitrum.io/learn-more/faq#does-arbitrum-have-a-mempool), [^7] have focused on enforcing a different ordering rule, *first come, first served* (sometimes called “fair ordering”) where block proposers must order transactions in the order in which they see them. Priority ordering takes a different approach—treating transactions that arrive within a given period equally, and ordering them instead by their declared priority. First come, first served is difficult to enforce or even define in a real network environment with more than one validator. It also can result in wasteful latency races and spam even with a single trusted sequencer. Finally, MEV taxes may be able to eliminate certain kinds of MEV that first-come first-served ordering cannot, such as arbitrage profits from discontinuous “jumps” in asset prices. The potential advantages of priority ordering over first-come first-served ordering are somewhat related to the advantages of discrete-time over continuous-time exchanges discussed in [Budish, Cramton, Shim (2015)](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2388265). Meanwhile, while priority ordering seems to leak value to MEV by default, this post shows how applications can be designed to recapture it. *Fee sharing*. Blast, an Ethereum L2, [shares](https://docs.blast.io/building/guides/gas-fees) a portion of both priority and base fees with the smart contracts accessed in a transaction. MEV taxes allow something similar (at least for priority fees), but can be implemented at the application layer on *any* chain that uses competitive priority ordering, without special support for fee sharing. They also allow applications to define their own taxes as custom functions of priority fee, providing more flexibility and potentially resulting in greater composeability of MEV-aware applications. *Trustless solutions*. This post focuses on the motivation for platforms to use competitive priority ordering—and ways to take advantage of platforms that do—rather than discussing how to trustlessly enforce it. There has been significant prior discussion of each of the other properties required for competitive priority ordering. For example, in [Fox, Pai, Resnick (2023)](https://arxiv.org/pdf/2301.13321), the authors discuss vulnerabilities in onchain auctions in the absence of censorship resistance, and describe a design for a censorship resistant auction using multiple concurrent proposers. However, they do not suggest a specific ordering for transactions. There has been other research on constructing mechanisms for trust-minimized block building, including Flashbots’s [SUAVE](https://writings.flashbots.net/mevm-suave-centauri-and-beyond), [Sorella](https://x.com/SorellaLabs)’s Angstrom, [Leaderless Auctions](https://www.paradigm.xyz/2024/02/leaderless-auctions), Espresso and Offchain Labs’ [decentralized Timeboost](https://medium.com/@espressosys/espresso-systems-and-offchain-labs-release-r-d-roadmap-for-decentralized-timeboost-5d0007dff66d), and [mandated public transaction inclusion](https://gist.github.com/karalabe/4313ece67b528113ea72388ac2df25d8) by Péter Szilági. ## Conclusion We hope this post encourages L2s to consider using priority ordering (as is supported by default in the OP Stack) and inspires applications to try out MEV taxes where supported. We also hope it motivates further research into protocols for trust-minimized competitive priority ordering on both L1 and L2. If you’re interested in collaborating on that problem, and are reading this before Thursday, June 6, you can still apply for a TLDR Fellowship to work on [MEV-resistant L2 sequencers](https://www.tldresear.ch/tldr/tldr-request-for-papers/mev-resistant-l2-sequencers) with Dan. Or feel free to just reach out to [dan@paradigm.xyz](mailto:dan@paradigm.xyz) and [dave@paradigm.xyz](mailto:dave@paradigm.xyz) with ideas! [^1]: In this post, we use “proposer” to refer to the actor or process that determines what transactions are included in a particular block. On Ethereum L2s, this role is typically filled by a “sequencer.” On Ethereum L1, it is filled by a specific Ethereum validator called a proposer, though often the proposer outsources the task of building the block to a competitive auction in which “relayers” and “builders” participate. The details of how these responsibilities are divided are out of scope of this post. [^2]: The priority fee per gas is not actually specified explicitly in the transaction, but can be computed in it. The transaction specifies a gas price, but Ethereum also charges a base fee, which is taken out of the gas price and burned. The base fee should be ignored for purposes of MEV taxes, since it is not under the transactor’s control. The priority fee per gas—the price for the part of the transaction fee that goes to the block proposer—can be computed in Solidity as priorityGasPrice = tx.gasprice - block.basefee . [^3]: Alternatively, we could simply define “MEV” to exclude any searcher profit and only refer to value that would go to the validator. [^4]: Note that proposerPriorityFee—equal to priorityFeePerGas times the total gas used in the transaction—cannot actually be calculated during the contract, since there’s no way to know how much gas the transaction will end up using. However, this generally won’t matter, since all we need is an upper bound for it. To be safe, you could multiply priorityFeePerGas by 30 million—the current maximum gas in an Ethereum block. Overestimating this value will simply mean that the MEV tax captures an even greater percentage of MEV. [^5]: Assuming a transaction cannot be more than 30 million gas, a priorityFeePerGas of 50,000 would result in a gas payment of 1500 gwei—about $0.006 at an ETH price of $4000. [^6]: In the case where priorityFeePerGas is set so that the arbitrageur’s profit is zero, the profit-maximizing arbitrage trade should correspond to the same trade on the function-maximizing AMM. Proving this is left as an exercise for the reader. [^7]: Arbitrum has discussed replacing this with a form of priority ordering called Timeboost, but that has not been put into production as of this writing. ## https://www.paradigm.xyz/writing/dealer-rule-amicus # Paradigm Files Amicus Brief Supporting Challenge Against the SEC’s Dealer Rule, Which Could Have Sweeping Implications for DeFi > Paradigm filed an amicus brief supporting the Blockchain Association and Crypto Freedom Alliance of Texas motion for summary judgment in their challenge to the SEC’s new Dealer Rule, which could have sweeping implications for DeFi and all of crypto. **TLDR**: Today, Paradigm filed an [amicus brief](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-0db4ae687e/613fc5a874bc6f11b82e31bebc210fd9/asset-https-cdn-sanity-io-files-dgybcd83-p-0db4ae687e.pdf) supporting the Blockchain Association and Crypto Freedom Alliance of Texas motion for summary judgment in their challenge to the SEC’s new Dealer Rule, which could have sweeping implications for DeFi and all of crypto. The rule is unwise, unclear, and unworkable. **Details**: For years, the crypto industry has been pleading with the SEC to engage in transparent rulemaking, working with the industry on a rule set that will allow innovators to build in the United States without constant fear of a knock at the door. The SEC has [steadfastly denied these pleas](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-733283bafa/a61fd1535e72fc10a4af1195df14c66b/asset-https-cdn-sanity-io-files-dgybcd83-p-733283bafa.pdf) and instead has sought to bulldoze the industry through regulation by enforcement. In its recent Dealer Rule, the SEC has widened the aperture for confusion even further. The final rule upends decades of understanding of who is a “dealer” under the Exchange Act by inserting the impossibly vague notion that anyone that has the “effect” of providing liquidity can be considered a dealer. Worse, it seeks to apply the new rule to the entirety of the digital asset industry without proper notice or any explanation of how the already vague rule could possibly apply or be complied with. This is Lewis Caroll logic, not that of a reasonable regulator. The rule also commits critical process faults. In the 194 pages of the proposed rule, the SEC mentioned digital assets only once in a footnote to assert that the rule would apply to digital assets. There was no mention, let alone any discussion, of how the rule might apply to crypto, including decentralized protocols. And despite the crypto industry submitting many questions as part of the comment process, the SEC refused to even attempt to correct any ambiguity in the final rule and simply asserted its usual litany that every determination it makes will be based on “facts and circumstances.” This is not notice and comment rulemaking as required by the Administrative Procedure Act. Paradigm’s amicus brief explains why the SEC’s hollow assurances are insufficient and worse yet, could actually be used by the SEC to impose impossible requirements on digital asset market participants - including DeFi users and software protocols. The SEC’s continued refusal to provide clarity on digital assets has forced digital asset market participants to play an unwinnable guessing game. The Dealer Rule just compounds and exacerbates existing uncertainty, and Paradigm supports the Blockchain Association and the Crypto Freedom Alliance of Texas’ challenge to the new rule. ## https://www.paradigm.xyz/writing/the-edges-of-finance # The Edges of Finance > Some parts of crypto seem alien when compared to traditional finance. They make more sense when you view them in the context of a broader shift away from banks toward digital financial services provided by a range of people and companies. Innovation in finance is moving from the core to the edges. The Bank for International Settlements (BIS) recently published a [paper](https://www.bis.org/publ/work1183.htm) on DeFi lending. It starts off with some provocative framing: *Given the need for over-collateralisation in DeFi lending (contrary to what happens in traditional banking), it is somewhat surprising that any borrowing activity takes place on these platforms at all.* We should all be excited (seriously!) that the BIS is paying its economists to study DeFi. Papers like this genuinely help legitimize the space over time, as does the experimental work the BIS Innovation Hub has undertaken (see [Project Mariana](https://www.bis.org/about/bisih/topics/cbdc/mariana.htm)). That said, we should also take a step back and offer a broader perspective when papers from outside the crypto industry are narrowly focused. Staff research from an important institution is often (understandably) interpreted as official policy. When it skews to the negative, it can have a significant impact on the willingness of others to engage. Using bank lending as a starting point for analyzing DeFi lending ignores the unique characteristics of each form of lending. It also suggests that banks have an impenetrable moat around credit intermediation without acknowledging the broader backdrop of technical and social change at the edges of the global financial architecture. ### **Collateralization is a spectrum that balances risk, liquidity, and capital efficiency** Banks are structurally risky, as we saw in [March 2023](https://paradigm.xyz/writing/2023/04/moneyness-in-the-digital-age). Maturity mismatch necessarily leads to instability, which is why central banks and prudential regulation exist in the first place. The capital efficiency we get through *uncollateralized* bank lending is socially costly and operationally difficult to control. In recent years, there has been a surge in *collateralized* borrowing in private credit markets. These products often come with covenants that allow creditors to claim assets in the case of a borrower default. (More on this below.) For example, we see what looks a lot like *overcollateralization* in the market for repurchase agreements, known as the repo market. When Alice and Bob agree to an overnight repo trade, Alice gives Bob $100 cash in exchange for $100 in treasuries. The next day, Bob pays back Alice the $100 plus some interest, and Alice returns to Bob his $100 in Treasuries. Given the need for a very high collateral-to-loan ratio in repo, it may be surprising that any borrowing happens in the repo market at all. However, the US repo market alone handles roughly [4 trillion USD](https://www.icmagroup.org/market-practice-and-regulatory-policy/repo-and-collateral-markets/icma-ercc-publications/frequently-asked-questions-on-repo/4-how-big-is-the-repo-market/#:~:text=At%20about%20the%20same%20time,as%20almost%20USD%204%20trillion.) in trading volume everyday. The numbers have increased in recent years. In fact, the Federal Reserve now runs a number of repo facilities that are always available for a subset of the financial system to use to source cash or securities. Many institutions use the repo market to obtain leverage for trading, similar to how crypto traders use crypto lending markets to fund profitable trades (this works in part because many traders experience significant capital gains, which blunts the capital impact of overcollateralization). Overcollateralization in crypto is partly due to the fact that crypto markets are volatile — but the current model works for its intended purpose. While there may be some exceptions, the target customer for DeFi lending today is not the same as bank lending. That may change in the future as the industry evolves to meet the changing needs of its users; but today, the average Aave user is not seeking an Aave loan to buy a house, much like the average repo user is not using the repo market to fund consumer purchases. ### **Financial services are increasingly shifting away from banks (regardless of what happens in crypto)** Banks are still an important part of the financial system, both literally and in terms of social perception, but the size and scope of their activities has changed significantly in the past 20 years. The rise of DeFi lending follows a well-documented trend of banks ceding ground to new entrants in a variety of verticals. Since 2008-09, there has been a dramatic increase in nonbank financial institutions – in aggregate and in share relative to banks. Much of this is a result of post-crisis regulation that disincentivizes banks from growing in size and complexity. This means that banks have had to curtail their activities and that non-banks have stepped up to fill the void. Here is a set of charts from the [New York Fed](https://libertystreeteconomics.newyorkfed.org/2023/04/enhancing-monitoring-of-nbfi-exposure-the-case-of-open-end-funds/) that show just how important nonbanks have become over the last decade. The [Financial Stability Board](https://www.fsb.org/2023/12/global-monitoring-report-on-non-bank-financial-intermediation-2023/) has also been documenting this trend in near real time. ![NBFIs vs. Banks (source: Financial Stability Board)](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--0baaa926a9/d0ae455c6444ebe89445183c41eebf20/asset-https-cdn-sanity-io-images-dgybcd83--0baaa926a9.png) Private credit is going through a particularly large boom right now. According to [estimates](https://www.federalreserve.gov/econres/notes/feds-notes/private-credit-characteristics-and-risks-20240223.html) from the Fed, direct lending via private credit has grown from almost nothing in 2008 to an $800 billion market today. These are mostly term loans, originated by nonbanks, with various degrees of collateral backing them. Private credit differs from collateralized DeFi lending in at least one important respect. While private credit avoids the duration mismatch problem that arises in bank-intermediated lending, it relies on mostly *illiquid* collateral as opposed to most DeFi lending today which is predicated on the ability to liquidate collateral as needed. The thing to underscore is that while banks are still very important, they are not the locus of innovation in finance today. After a financial crisis that roiled banks, regulators and the private sector responded by redesigning the system to push some forms of credit intermediation out of the core and into other parts of the financial system. Lending is getting [narrower](https://www.bloomberg.com/opinion/articles/2024-05-01/banks-are-still-where-the-money-isn-t?srnd=undefined), even if you strip out all of the activity happening in crypto markets. This is why it is difficult to grok some of the critiques about DeFi lending that come off as less serious about what it is and more concerned with what (or where) it is not (e.g., banks). ### **As activity moves out of the core and toward the edges, having a unified (verifiable) representation of the state of the system becomes more important** By now, most people know that [cash is ceding ground to digital payments](https://www.bis.org/statistics/payment_stats/commentary2402.pdf) as countries like the US ([FedNow](https://www.frbservices.org/financial-services/fednow) and [RTP](https://www.theclearinghouse.org/payment-systems/rtp)), Brazil ([Pix](https://www.bcb.gov.br/en/financialstability/pix_en)), and India ([UPI](https://www.npci.org.in/what-we-do/upi/product-overview)) are moving to faster/instant payments systems — all while activity is shifting out of banks. At some point, these fragmented systems, which are constantly increasing in number and capabilities, need to be able to talk to each other. The BIS acknowledges this and grants that improvements in technology warrant larger changes in how the financial system functions and interoperates. In a recent op-ed, the General Manager of the BIS [wrote](https://www.project-syndicate.org/commentary/finternet-redesign-global-financial-architecture-blockchain-innovation-by-agustin-carstens-and-nandan-nilekani-2024-05): *Financial services must catch up with the advances made in communications since the advent of the internet and smartphones. That will require taking bold action to build a seamless, interconnected network that would give all individuals and businesses full control over their financial lives.* Ethereum and other blockchains are already serving this purpose. Stablecoins and real-world assets (RWAs) on public blockchains are some of the first TradFi-legible examples of how a global state machine can be used to represent financial services. We have seen that over time, even the large institutional players are converging on a [global standard](https://policy.paradigm.xyz/writing/Cryptos-Biggest-Skeptics-are-EVM-pilled) that is anchored to the crypto community. Rapidly, many of the concerns that [policymakers once flagged](https://www.federalreserve.gov/econres/feds/distributed-ledger-technology-in-payments-clearing-and-settlement.htm) about the use of public blockchains in finance (scalability, key management, operational risk) are being resolved by technologists. It is possible that all of the moving parts of finance, across markets, entity-types, and jurisdictions come together on a closed but interconnected platform that is extensible enough to meet all of their needs. But it does not seem very likely. If you look at some of the most successful fintech companies of the last 20 years, many today are the middleware that connects disparate, non-interoperable systems. What seems more likely, at least in the short run, is that institutions and innovators meet in the middle and build on top of systems that are open and easy to use — and already live. ### **Record scratch: Crypto is about more than simply recreating existing financial primitives** This is the most-important observation of all. It is easy to get frustrated in the face of challenges to crypto and public blockchains that boil down to “it would be too risky to do this \[systemically important/socially enshrined\] activity today on a public blockchain,” but they are orthogonal to the pulse of social and technical change. Crypto is a long-term project. Part of the project involves upgrading existing systems for social coordination — including money and finance — using a new set of technologies that empower users and are open and accessible. Another part of the project involves creating *entirely new* things that might look kind of like old things but only if you squint hard enough. Pushing the frontier means products and services that seem insane until they are obvious. ## https://www.paradigm.xyz/writing/how-to-raise-the-gas-limit-2 # How to Raise the Gas Limit, Part 2: History Growth > In this post we continue our investigation of Ethereum scaling from Part 1, now turning our attention from state growth to history growth. Using high resolution datasets, our goal is to 1) build a technical understanding of Ethereum’s scaling bottlenecks, and 2) help frame the discussion around what Ethereum gas limit is optimal. **History growth is currently the biggest bottleneck for scaling Ethereum.** Somewhat unexpectedly, history growth has become a much larger problem than state growth. Within a couple years, history data will exceed the storage capacity of many Ethereum nodes. The good news is that: 1. History growth is an easier problem to solve than state growth. 2. Solutions are already under active development. 3. Solving history growth will ease the state growth problem. In this post we continue our investigation of Ethereum scaling from [Part 1](https://www.paradigm.xyz/2024/03/how-to-raise-the-gas-limit-1), now turning our attention from state growth to history growth. Using high resolution datasets, our goal is to 1) build a technical understanding of Ethereum’s scaling bottlenecks, and 2) help frame the discussion around what Ethereum gas limit is optimal. *This article is part 2 in a blogpost series about Ethereum scaling.* [*Part 1*](https://www.paradigm.xyz/2024/03/how-to-raise-the-gas-limit-1) *is about state growth, part 2 is about history growth, part 3 is about state access, and part 4 is about the gas limit.* ## What is history growth? **History** is the set of all blocks and transactions that Ethereum has executed throughout its lifetime. This is the data needed to sync the chain from the Genesis block to the current tip of the chain. **History growth** is the accumulation of new blocks and new transactions over time. **Figure 1** shows how history growth relates to various protocol metrics and Ethereum node hardware constraints. History growth is limited by a different set of hardware constraints than state growth. History growth puts stress on **Network IO**, because new blocks and transactions must be transmitted throughout the network. History growth also puts stress on a node’s **Storage Space** because every Ethereum node stores a complete copy of the history. If history grows quickly enough to exceed these hardware constraints, a node will no longer be able to achieve stable consensus with its peers. Refer to [Part 1](https://www.paradigm.xyz/2024/03/how-to-raise-the-gas-limit-1) of this article series for an overview of state growth and other scaling bottlenecks. ![Figure 1. Ethereum Scaling Bottlenecks](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--ca2d8c8254/433732bb9ffc337b960f78329e78779e/asset-https-cdn-sanity-io-images-dgybcd83--ca2d8c8254.png) *Figure 1. Ethereum Scaling Bottlenecks* Until recently, the majority of each node’s network throughput was used for transmitting history (e.g. new blocks and transactions). This situation has changed with the introduction of blobs in the [Dencun](https://blog.ethereum.org/2024/02/27/dencun-mainnet-announcement) hard fork. Blobs now occupy a significant portion of a node’s network activity. However, blobs are not considered part of history because 1) they are only stored by a node for 2 weeks before being discarded and 2) they are not needed for replaying the chain from Genesis. Thanks to (1), blobs do not significantly contribute to the storage burden of each Ethereum node. We will discuss blobs in a later section of this post. In this article we will focus on history growth and also touch on the relationship between history and state. Since state growth and history growth share some overlapping hardware constraints, they are related problems, and addressing one problem can help address the other. ## How fast is history growing? **Figure 2** shows the history growth rate over time since Ethereum’s Genesis. Each vertical bar represents one month of growth. The y-axis represents the number of gigabytes that history grew during that month. Transactions are categorized by their “to address” and sized using their [RLP](https://ethereum.org/en/developers/docs/data-structures-and-encoding/rlp/) byte representation. Contracts that could not be easily identified are categorized as “Unknown”. The “Other” category includes a long tail of small categories such as infrastructure and gaming. ![Figure 2: Ethereum history growth rate over time](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--84ed00f57f/492a518b25999192a24034ddec357147/asset-https-cdn-sanity-io-images-dgybcd83--84ed00f57f.png) A few key takeaways from this chart: - *History grows about 6x - 8x faster than state:* History growth recently peaked at 36.0 GiB/month and currently sits at 19.3 GiB/month. State growth peaked around 6.0 GiB/month and currently sits at 2.5 GiB/month. A comparison of history vs state, both in growth and cumulative size, can be found later in this post. - *Until Decun, the history growth rate was rapidly accelerating:* While state has been growing roughly linearly for many years (see [Part 1](https://www.paradigm.xyz/2024/03/how-to-raise-the-gas-limit-1)), history has been growing superlinearly. Consider that a linearly increasing growth rate leads to a quadratic overall size, and so a superlinearly increasing growth rate leads to a faster-than-quadratic overall size. This acceleration hit an abrupt stop after Dencun. This was the first time Ethereum experienced a large decline in the history growth rate. - *The majority of recent history growth has come from rollups:* Each L2 posts copies of its transactions back to mainnet. This generated a large amount of history and it has led to rollups being the most significant contributor to history over the last year. However, Dencun enabled L2’s to post their transaction data using blobs instead of history, and so rollups no longer generate the majority of Ethereum history. We examine rollups in more detail later on in this post. ## What are the biggest contributors to Ethereum history? The amount of history generated by each contract category reveals how Ethereum usage patterns have evolved over time. **Figure 3** shows the relative contributions of various contract categories. This is the same data as Figure 2, normalized to 100%. ![Figure 3: Contributions to history growth](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--5884057169/24ebda68c14fd24e3ee473f4d5f4d191/asset-https-cdn-sanity-io-images-dgybcd83--5884057169.png) This data reveals four distinct epochs of Ethereum usage patterns: 1. **The Early Era (purple):** In Ethereum’s first few years there was little onchain activity. Of these early contracts, most are difficult to identify now, and they are marked Unknown in the chart. 2. **The ERC-20 Era (green):** The [ERC20 standard](https://eips.ethereum.org/EIPS/eip-20) was finalized at the end of 2015 but it did not gain significant traction until 2017 and 2018. ERC-20 contracts became the largest history category in 2019. 3. **The DEX / DeFi Era (brown):** DEX and DeFi contracts were present onchain as early as 2016, and they began to gain traction in 2017. But it was not until [DeFi Summer](https://finematics.com/history-of-defi-explained/) in 2020 that they became the largest history category. DeFi and DEX contracts peaked at >50% of history growth in parts of 2021 and 2022. 4. **The Rollup Era (grey):** At the beginning of 2023, L2 rollups began to consistently execute [more transactions than mainnet](https://l2beat.com/scaling/activity). This coincided with their contracts generating large amounts of history, and they generated about 2/3 of all Ethereum history in the months before Dencun. **Each era represents a more complex Ethereum usage pattern than the one before it. Complexification over time can be seen as a form of Ethereum scaling that is not captured by simple metrics like transactions per second.** In the most recent month of data, April 2024, rollups are no longer generating the majority of history. It is unclear whether future history will originate from DEX’s and DeFi, or some new pattern of usage will emerge. ## What about blobs? The introduction of blobs in the Dencun hardfork significantly altered history growth dynamics by allowing rollups to post their data using cheap blobs instead of history. **Figure 4** zooms into the history growth rate around the date of the Dencun upgrade. The chart is similar to Figure 2, except each vertical bar represents one day instead of one month. ![Figure 4: Effect of Dencun on history growth](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--51a1da44d0/4a459ca19656c4c8ab662d2654af2b31/asset-https-cdn-sanity-io-images-dgybcd83--51a1da44d0.png) A couple key takeaways from this graph: - *History growth from rollups has fallen by ~2/3 since Dencun:* Most rollups have transitioned from call data to blobs, which substantially decreases the amount of history they generate. However, as of April 2024, there remain some [rollups](https://l2beat.com/scaling/data-availability) that have not switched from call data to blobs. - *Total history growth has fallen by ~1/3 since Dencun:* Dencun only reduced the history growth of rollups. Other contract categories have slightly increased their history growth. Even after Dencun, history growth remains 8x larger than state growth (see next section for details). Although blobs have reduced history growth, they are still a recent addition to Ethereum. It’s unclear where history growth will stabilize in the presence of blobs. ## How much history growth is acceptable? Raising the gas limit will increase the history growth rate. Proposals to raise the gas limit (e.g. [Pump the Gas](https://pumpthegas.org/)) must therefore account for the relationship between history growth and each node’s hardware bottlenecks. To figure out an acceptable rate of history growth, it is helpful to start by examining how long the current status quo can be maintained by modern node hardware for networking and storage. Networking hardware can probably sustain the status quo indefinitely, because the history growth rate is unlikely to return to its pre-Dencun peak until the gas limit is increased. However, the storage burden of history continually increases over time. Under current storage policies it is inevitable that each node’s storage drives eventually become filled by history. **Figure 5** shows Ethereum node’s storage burden over time, and it also projects how this storage burden may grow over the next 3 years. Projections were made using the April 2024 growth rate. It is possible that this rate may rise or fall with future changes to usage patterns or the gas limit. ![Figure 5: Size of history, state, and total full node storage burden](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--33401b43a0/a80ad03b288e816484522f8828f7843f/asset-https-cdn-sanity-io-images-dgybcd83--33401b43a0.png) A few key takeaways from this figure: - *History occupies about 3x as much storage space as state.* This difference will also increase over time because history is growing about 8x as fast as state. - *There is a critical threshold around 1.8 TiB where many nodes will be forced to upgrade their storage drives.* 2TB is a common storage drive size, which gives only 1.8TiB of usable space. Note that TB (1 trillion bytes) is a different unit than TiB (= 1024 ^ 4 bytes). The “true” critical threshold is even lower for many node operators because post-Merge validators must run a consensus client alongside the execution client. - *The critical threshold will be reached within 2 or 3 years.* Raising the gas limit by any amount will accelerate this timeline proportionately. Reaching this threshold will create a non-trivial maintenance burden for node operators and necessitate the purchase of additional hardware (e.g. a [$300 NVME drive](https://pcpartpicker.com/products/internal-hard-drive/#t=0&D=1&C=4294967296)). Unlike state data, history data is append-only and is accessed much less aggressively. Thus it is theoretically possible to store history data separately from state data on cheaper storage media. This can be done with some clients like [geth](https://geth.ethereum.org/docs/fundamentals/databases#freezerancients). Beyond storage capacity, Network IO is the other main hardware constraint on history growth. Unlike storage capacity, network IO limitations will not cause problems for nodes in the short term, but these limitations will become important for future increases to the gas limit. To know how much history growth can be supported by a typical Ethereum node’s network capacity, it is necessary to characterize the relationship between history growth and various network health metrics such as reorg rate, slot misses, finality misses, attestation misses, sync committee misses, and block submission delays. Analysis of these metrics is beyond the scope of this post, but more information can be found in previous investigations of consensus layer health [\[1\]](https://ethresear.ch/t/empirical-analysis-of-builders-behavioral-profiles-bbps/16327) [\[2\]](https://arxiv.org/abs/2306.10777) [\[3\]](https://arxiv.org/abs/2305.09032) [\[4\]](https://reorg.pics/). Additionally, the Ethereum Foundation’s [Xatu](https://notes.ethereum.org/@ethpandaops/xatu-overview) project has been building public datasets that should expedite these types of analyses. ## How can history growth be solved? History growth is an easier problem than state growth. It is solved almost entirely by the candidate proposal [EIP-4444](https://eips.ethereum.org/EIPS/eip-4444). This EIP changes each node from preserving the entire Ethereum history to just preserving one year of history. **After EIP-4444 is implemented, data storage will no longer be a bottleneck on Ethereum scaling, even in the long term with substantial gas limit increases.** EIP-4444 is necessary for the long term sustainability of the network, because otherwise the history will grow fast enough to require regular hardware updates in network nodes. **Figure 6** shows how EIP-4444 affects each node’s storage burden over the next 3 years. This is the same as Figure 4, with the added lighter lines representing storage burdens post-EIP-4444. ![Figure 6: Effect of EIP-4444 on Ethereum node storage burden](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--ea3320d5ee/b45af103c8b890281661180a96a8c55a/asset-https-cdn-sanity-io-images-dgybcd83--ea3320d5ee.png) Some key takeaways from this figure: - *EIP-4444 will cut the current storage burden in half.* The storage burden will drop from 1.2 TiB to 633 GiB. - *EIP-4444 will stabilize the history storage burden.* Assuming a constant rate of history growth, history will be discarded at the same rate that it is generated. - *After EIP-4444, it will take many years for the post-4444 storage burden to reach the storage burden of today.* This is because state growth will be the only factor growing the storage burden, and state grows more slowly than history. After EIP-4444 has been implemented, history growth will still impose some amount of storage burden because nodes will store a year’s worth of history. However, this burden will not be difficult to address, even as Ethereum reaches global scale. The year-long expiration time of EIP-4444 can likely be reduced to months, weeks, or even shorter once the history preservation approaches are shown to be reliable. ## How to preserve Ethereum's history? EIP-4444 raises the question of how history should be preserved if not by the Ethereum nodes themselves. History plays a central role in the validation, accounting, and analysis of Ethereum, and so it is vital that it be preserved. Luckily, history preservation is an easy problem that requires only 1/n honest data providers. This is in contrast to state consensus problems that require between 1/3 and 2/3 of data participants to be honest. A node operator can validate the authenticity of any history dataset by 1) replaying all of its transactions from Genesis and 2) checking whether those transasctions reproduce the same state root as the current chain tip. There are multiple approaches for preserving history. Each of these should probably be deployed in parallel to maximize the likelihood of preservation. 1. **Torrents / P2P:** [Torrents](https://en.wikipedia.org/wiki/Torrent_file) are the simplest and most robust approach. Ethereum nodes can periodically package portions of history and share as public torrent files. For example, a node might create a new history torrent file every 100,000 blocks. Node clients like erigon already perform this process to some extent in an unstandardized way. To standardize this process, all node clients must use the same data format, same parameters, and same P2P networks. Nodes would be able to choose whether or not to participate in this network depending on their storage and bandwidth capabilities. The advantage of torrents is using high-lindy open standards that are already supported by a large ecosystem of data tools. 2. **Portal Network:** The [Portal Network](https://ethereum.org/en/developers/docs/networking-layer/portal-network/) is a new network specifically designed for hosting Ethereum data. This is a similar approach to torrents, while also providing some extra functionality to make data validation easier. The advantage of the Portal Network is that these extra validation layers provide utilities for light clients to efficiently validate and query the shared datasets. 3. **Cloud hosts:** Cloud storage services like AWS’s [S3](https://aws.amazon.com/s3/) or Cloudflare’s [R2](https://developers.cloudflare.com/r2/) provide a cheap and high performance option for preserving history. However, this approach carries more legal risk and business operational risk, as it is not guaranteed that these cloud services will always remain willing and able to host cryptocurrency data. The remaining implementation challenges are more social than technical. The Ethereum community needs to coordinate around specific implementation details so that they can be directly integrated into each node client. In particular, performing a full sync from Genesis (not a snap sync) will then require retrieving the history from history providers instead of Ethereum nodes. These changes do not technically require a hard fork, and so they could be implemented sooner than Ethereum’s next hard fork, Pectra. All of these history preservation approaches could also be used by L2’s to preserve the blob data they post to mainnet. Compared to history preservation, blob preservation is 1) more difficult due to the total data size being much larger and 2) less important because blobs are not necessary for replaying mainnet history. However, blob preservation is still necessary for each L2 to replay their own history. Thus, some form of blob preservation will be important to the Ethereum ecosystem as a whole. Additionally, if L2’s develop robust blob storage infrastructure, they may also be able to easily store L1 history data. It is helpful to directly compare the datasets stored by various node configurations before and after EIP-4444. **Figure 7** shows the storage burden across Ethereum node types. **State Data** is accounts and contracts, **History Data** is blocks and transactions, and **Archive Data** is a set of optional data indices. The byte counts in this table are based off of a recent reth snapshot, but numbers for other node clients should be roughly comparable. ![Figure 7: Storage burden across Ethereum node types](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--8b187c3053/6db13fbbddac95d2aaa1b004b522ff7d/asset-https-cdn-sanity-io-images-dgybcd83--8b187c3053.png) Figure 7: Storage burden across Ethereum node types To put this into words, - An **Archive Node** stores State data and History data, along with Archive data. Archive nodes are used when someone wants to be able to easily query historical chain states. - A **Full Node** stores only the History data and State data. Most nodes today are full nodes. Full nodes have roughly half the storage burden of Archive nodes. - A **Full Node After EIP-4444** stores only the State data and the most recent year of History data. This reduces the storage burden from a node from 1.2 TiB to 633 GiB and brings the storage footprint of history data to a steady state value. - A **Stateless Node**, aka a “Light node”, does not store any of these datasets and is able to instantly validate at the chain’s tip. This node type becomes possible once [Verkle tries](https://verkle.info/) or other state commitment schemes are added to Ethereum. Finally, there are some additional EIP’s that would limit the history growth rate rather than merely accommodating the current rate. This would be helpful both in the short term for staying within network IO constraints and in the long term for staying within storage constraints. Although EIP-4444 is still necessary for the long term sustainability of the network, these other EIP’s would help Ethereum scale more efficiently in the future: - [EIP-7623](https://eips.ethereum.org/EIPS/eip-7623): Reprices call data so that certain transactions with excessive call data are more expensive. Making these usage patterns more expensive will push some of them to convert from call data to blobs. This will decrease the history growth rate. - [EIP-4488](https://eips.ethereum.org/EIPS/eip-4488): Imposes a limit on the total amount of call data that can be included in each block. This would place a tighter bound on the rate at which history can grow. These EIP’s are easier to implement than EIP-4444, so they may be useful as a short-term stopgap until EIP-4444 is ready for production. ## Closing The goal of this article is to develop a data-driven understanding of 1) how history growth works and 2) what can be done to solve it. Much of the data in this article has traditionally been difficult to access, and so we hope that making it available will offer some novel insight into the history growth problem. History growth has not received enough attention as a bottleneck on Ethereum scaling. Even without gas limit increases, Ethereum’s current conventions for preserving history will force many nodes to upgrade their hardware within a few years. Luckily, this is not a difficult problem to solve. There is already a clear solution in EIP-4444. We believe the implementation of this EIP should be expedited in order to make room for future gas limit increases. If you are excited about research in Ethereum scaling, reach out to [storm@paradigm.xyz](mailto:storm@paradigm.xyz) and [georgios@paradigm.xyz](mailto:georgios@paradigm.xyz). We’d love to hear about how you are thinking about the problem and potentially collaborate. The data and code used for this article can be found on Github [here](https://github.com/paradigmxyz/how-to-raise-the-gas-limit). # Acknowledgments Thank you to [Thomas Thiery](https://warpcast.com/soispoke), [Tim Beiko](https://warpcast.com/tim), [Toni Wahrstaetter](https://warpcast.com/toniw.eth), [Oliver Nordbjerg](https://warpcast.com/onbjerg), and [Roman Krasiuk](https://warpcast.com/rkrasiuk) for review and feedback. Thank you to [Achal Srinivasan](https://warpcast.com/achal) for the **Figure 1** and **Figure 7** graphics. ## https://www.paradigm.xyz/writing/reth-exex # Reth Execution Extensions > Execution Extensions (ExExes) are post-execution hooks for building real-time, high performance and zero-operations off-chain infrastructure on top of Reth. Reth is an all-in-one toolkit for building high performance and customizable nodes. We recently published our [performance roadmap](https://www.paradigm.xyz/2024/04/reth-perf) for improving Reth’s performance >100x, and [Reth AlphaNet](https://www.paradigm.xyz/2024/04/reth-alphanet), our testnet rollup for pushing Reth’s modularity and extensibility to the limits. **Today, we are excited to announce Reth Execution Extensions (ExEx). ExEx is a framework for building performant and complex off-chain infrastructure as post-execution hooks. Reth ExExes can be used to implement rollups, indexers, MEV bots and more with >10x less code than existing methods. With this release, we demonstrate from scratch a prod-ready reorg tracker in <20 LoC, an indexer in <250 LoC and a rollup in <1000 LoC.** ExEx was co-architected with [init4](https://twitter.com/init4tech), a research collective building next-generation Ethereum infrastructure. We look forward to continuing to collaborate with the init4 team as we make Reth the #1 platform for building crypto infrastructure! # How do we build off-chain infrastructure today? A blockchain is a clock that confirms blocks with transaction data on a regular interval. Off-chain infrastructure subscribes to these regular block updates and updates its own internal state as a response. For example, consider how an Ethereum indexer works: 1. It subscribes to Ethereum events such as blocks and logs, usually over `eth_subscribe` or by polling with `eth_getFilterChanges.` 2. On each event, it proceeds to fetch any additional data needed over JSON-RPC such as the receipts alongside the block and its transactions. 3. For each payload it ABI decodes the logs it needs based on a configuration such as the address or the topics it cares about. 4. For all decoded data, it writes them to a database such as Postgres or Sqlite. This is the standard Extract Transform Load (ETL) pattern that you see in large scale data pipelines, with companies like Fivetran owning the data extraction, Snowflake handling the loading into a data warehouse, and customers focusing on writing the transformation’s business logic. We observe that this same pattern also applies to other pieces of crypto infrastructure such as rollups, MEV searchers, or more complex data infrastructure like Shadow Logs. Using that as motivation, we identify key challenges when building ETL pipelines for Ethereum nodes: 1. Data Freshness: Chain reorganizations mean that most infrastructure is usually trailing behind the tip of the chain to avoid operating over state that might no longer be part of the canonical chain. This in practice means that building real-time crypto data products is challenging, evidenced by the proliferation of products with high latencies (on the order of multiple blocks, tens of seconds) relative to what they could be providing to their customers. We believe that this happens because nodes do not have a great developer experience for reorg-aware notification streams. 2. Performance: Moving data, transforming it and stitching it together across different systems means there are non negligible performance overheads. For example, a [Reth-based indexer](https://github.com/joshstevens19/reth-indexer) that directly plugs on Reth’s database showed 1-2 orders of magnitude improvement vs other indexers that plug on JSON-RPC, pointing at serious improvements by colocating workloads and removing intermediate layers of communication. 3. Operational Complexity: Running Ethereum nodes with high uptime is already a big challenge. Running additional infrastructure on top of them further exacerbates the problem and requires developers to think about job orchestration APIs, or running multiple services for relatively simple tasks. **There is a need for a better API for building off-chain infrastructure that depends on a node’s state changes. That API must be performant, ‘batteries-included’ and reorg-aware. We need an Airflow moment for building Ethereum ETL infrastructure and job orchestration.** # Introducing Reth Execution Extensions (ExEx) **Execution Extensions (ExExes) are post-execution hooks for building real-time, high performance and zero-operations off-chain infrastructure on top of Reth.** An Execution Extension is a task that derives its state from Reth's state. Some examples of such state derives are rollups, indexers, MEV extractors, and more. We expect that developers will build reusable ExExes that compose with each other in a standardized way, similar to how Cosmos SDK modules or Substrate Pallets work. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--15b5483244/78b53cf1a62af663102dcccc5bb4dc3c/asset-https-cdn-sanity-io-images-dgybcd83--15b5483244.png) We co-architected Execution Extensions with the [init4 team](https://twitter.com/init4tech) (follow them!), a new research collective building next-generation Ethereum infrastructure. We are excited to continue collaborating with their team as we productionize ExExes and make Reth the #1 platform for building crypto infrastructure! We are still early in the best practices of building ExExes, and we’d like to invite developers to join us in exploring this new frontier of building off-chain crypto infrastructure. Please reach out with ideas to collaborate. ## How do ExExes work? In Rust terms, an ExEx is a Future that is run indefinitely alongside Reth. ExExes are initialized using an async closure that resolves to the ExEx. Here is the expected end to end flow: 1. Reth exposes a reorg-aware stream called [`ExExNotification`](https://paradigmxyz.github.io/reth/docs/reth_exex/enum.ExExNotification.html) which [includes](https://paradigmxyz.github.io/reth/docs/reth_provider/chain/struct.Chain.html) a list of blocks committed to the chain, and all associated transactions & receipts, state changes and trie updates with them. 2. Developers are expected to consume that stream by writing ExExes as `async` functions that derive state such as a rollup block. The stream exposes a ChainCommitted variant for [appending to ExEx state](https://github.com/paradigmxyz/reth/blob/main/examples/exex/op-bridge/src/main.rs#L130) and a ChainReverted/Reorged-variant for [undoing any changes](https://github.com/paradigmxyz/reth/blob/main/examples/exex/op-bridge/src/main.rs#L98). This is what allows ExExes to be operating at native block time, while also exposing a sane API for handling reorgs safely, instead of not handling reorgs and introducing latency. 3. ExExes get orchestrated by Reth’s [`ExExManager`](https://paradigmxyz.github.io/reth/docs/reth_exex/struct.ExExManager.html) that is responsible for routing notifications from Reth to ExExes and ExEx events back to Reth, while Reth’s task executor drives ExExes to completion. 4. Each ExEx gets installed on the node via the `install_exex` API of the Node Builder. Here is how this roughly looks like from the node developer’s perspective: ```rust use futures::Future; use reth_exex::{ExExContext, ExExEvent, ExExNotification}; use reth_node_api::FullNodeComponents; use reth_node_ethereum::EthereumNode; // The `ExExContext` is available to every ExEx to interface with the rest of the node. // // pub struct ExExContext { // /// The configured provider to interact with the blockchain. // pub provider: Node::Provider, // /// The task executor of the node. // pub task_executor: TaskExecutor, // /// The transaction pool of the node. // pub pool: Node::Pool, // /// Channel to receive [`ExExNotification`]s. // pub notifications: Receiver, // // .. other useful context fields // } async fn exex(mut ctx: ExExContext) -> eyre::Result<()> { while let Some(notification) = ctx.notifications.recv().await { match ¬ification { ExExNotification::ChainCommitted { new } => { // do something } ExExNotification::ChainReorged { old, new } => { // do something } ExExNotification::ChainReverted { old } => { // do something } }; } Ok(()) } fn main() -> eyre::Result<()> { reth::cli::Cli::parse_args().run(|builder, _| async move { let handle = builder .node(EthereumNode::default()) .install_exex("Minimal", |ctx| async move { exex(ctx) } ) .launch() .await?; handle.wait_for_node_exit().await }) } ``` The above <50 LoC snippet encapsulates defining and installing an ExEx. It is extremely powerful and allows extending your Ethereum node’s functionality with zero additional pieces of infrastructure. Let’s walk through some examples now. ## Hello ExEx! The [“Hello World” of Execution Extensions](https://github.com/paradigmxyz/reth/blob/main/examples/exex/minimal/src/main.rs) is a reorg tracker. The ExEx shown in the screenshot below illustrates logging whether there was a new chain or a reorganization. One could build a reorg tracker on top of their Reth node easily just by parsing the info logs emitted by the below ExEx. In this example, the `old` and `new` chains have full access to every state change in that range of blocks, along with the trie updates and other useful information in the [`Chain`](https://paradigmxyz.github.io/reth/docs/reth_provider/chain/struct.Chain.html) struct. ```rust async fn exex(mut ctx: ExExContext) -> eyre::Result<()> { while let Some(notification) = ctx.notifications.recv().await { match ¬ification { ExExNotification::ChainCommitted { new } => { info!(committed_chain = ?new.range(), "Received commit"); } ExExNotification::ChainReorged { old, new } => { info!(from_chain = ?old.range(), to_chain = ?new.range(), "Received reorg"); } ExExNotification::ChainReverted { old } => { info!(reverted_chain = ?old.range(), "Received revert"); } }; if let Some(committed_chain) = notification.committed_chain() { ctx.events.send(ExExEvent::FinishedHeight(committed_chain.tip().number))?; } } Ok(()) } ``` ## Building an indexer for the OP Stack using ExEx Now that we have the basics of hooking on node events, let's build a more elaborate example, such as an [indexer for deposits and withdrawals in common OP Stack chains](https://github.com/paradigmxyz/reth/blob/main/examples/exex/op-bridge/src/main.rs), using SQlite as the backend. In this case: 1. We have loaded the [OP Stack's bridge contract](https://github.com/ethereum-optimism/optimism/blob/65ec61dde94ffa93342728d324fecf474d228e1f/packages/contracts-bedrock/contracts/L1/L1StandardBridge.sol) using Alloy's [`sol!`](https://docs.rs/alloy-core/latest/alloy_core/sol_types/macro.sol.html) macro to generate type-safe ABI decoders (this is an extremely powerful macro that we encourage developers to [dive deeper in](https://docs.rs/alloy-core/latest/alloy_core/sol_types/macro.sol.html)). 2. We initialize the SQLite connection and set up the database tables. 3. On each `ExExNotification` we proceed to read the logs for every committed block, decode it, and then insert it into SQLite. 4. If the `ExExNotification` is for a chain reorganization, then we remove the corresponding entries from the SQLite tables. That's it! Super simple, and probably the highest performance locally hosted real-time indexer you can build in 30 minutes. See the code below, and go through the [full example](https://github.com/paradigmxyz/reth/blob/main/examples/exex/op-bridge/src/main.rs). ```rust use alloy_sol_types::{sol, SolEventInterface}; use futures::Future; use reth_exex::{ExExContext, ExExEvent}; use reth_node_api::FullNodeComponents; use reth_node_ethereum::EthereumNode; use reth_primitives::{Log, SealedBlockWithSenders, TransactionSigned}; use reth_provider::Chain; use reth_tracing::tracing::info; use rusqlite::Connection; sol!(L1StandardBridge, "l1_standard_bridge_abi.json"); use crate::L1StandardBridge::{ETHBridgeFinalized, ETHBridgeInitiated, L1StandardBridgeEvents}; fn create_tables(connection: &mut Connection) -> rusqlite::Result<()> { connection.execute( r#" CREATE TABLE IF NOT EXISTS deposits ( id INTEGER PRIMARY KEY, block_number INTEGER NOT NULL, tx_hash TEXT NOT NULL UNIQUE, contract_address TEXT NOT NULL, "from" TEXT NOT NULL, "to" TEXT NOT NULL, amount TEXT NOT NULL ); "#, (), )?; // .. rest of db initialization Ok(()) } /// An example of ExEx that listens to ETH bridging events from OP Stack chains /// and stores deposits and withdrawals in a SQLite database. async fn op_bridge_exex( mut ctx: ExExContext, connection: Connection, ) -> eyre::Result<()> { // Process all new chain state notifications while let Some(notification) = ctx.notifications.recv().await { // Revert all deposits and withdrawals if let Some(reverted_chain) = notification.reverted_chain() { // .. } // Insert all new deposits and withdrawals if let Some(committed_chain) = notification.committed_chain() { // .. } } Ok(()) } /// Decode chain of blocks into a flattened list of receipt logs, and filter only /// [L1StandardBridgeEvents]. fn decode_chain_into_events( chain: &Chain, ) -> impl Iterator { chain // Get all blocks and receipts .blocks_and_receipts() // .. proceed with decoding them } fn main() -> eyre::Result<()> { reth::cli::Cli::parse_args().run(|builder, _| async move { let handle = builder .node(EthereumNode::default()) .install_exex("OPBridge", |ctx| async move { let connection = Connection::open("op_bridge.db")?; create_tables(&mut connection)?; Ok(op_bridge_exex(ctx, connection)) }) .launch() .await?; handle.wait_for_node_exit().await }) } ``` ## Building a Rollup using ExEx Let's do something more interesting now, and build a minimal Rollup as an ExEx, with an EVM runtime and SQLite as the backend! If you [zoom out](https://prestwich.substack.com/p/the-definitive-guide-to-sequencing), even Rollups are ETL-ish pipelines: 1. Extract the data posted on L1 and convert to an L2 payload (e.g. OP Stack derivation function). 2. Run the state transition function (e.g. EVM). 3. Write the updated state to a persistent storage. In this example, we demonstrate a simplified rollup that derives its state from RLP encoded EVM transactions posted to [Zenith](https://github.com/init4tech/zenith/blob/main/src/Zenith.sol) (a [Holesky](https://holesky.etherscan.io/address/0x74ae65DF20cB0e3BF8c022051d0Cdd79cc60890C#code) smart contract for posting our rollup's block commitments) driven by a [simple block builder](https://github.com/init4tech/zenith-rs), both built by the [init4](https://www.paradigm.xyz/2024/05/twitter.com/init4tech) team. The example specifically: 1. Configures an EVM & instantiates an SQLite database and implements the required `revm` Database traits to use SQLite as an EVM backend. 2. Filters transactions sent to the deployed rollup contract, ABI decodes the calldata, then RLP decodes that into a Rollup block which gets executed by the configured EVM. 3. Inserts the results of the EVM execution to SQLite. Again, super simple. It also works with [blobs](https://github.com/paradigmxyz/reth/blob/main/examples/exex/rollup/src/execution.rs#L135-L152)! **ExEx Rollups are extremely powerful because we can now run any number of rollups on Reth without additional infrastructure, by installing them as ExExes**. We are working on extending the example with blobs, and providing a built-in sequencer, for a more complete end to end demo. Reach out if this is something you'd like to build, as we think this has potential for introducing L2 PBS, decentralized / shared sequencers or even SGX-based sequencers and more. [Example](https://github.com/paradigmxyz/reth/blob/main/examples/exex/rollup/src/main.rs) snippets below. ```rust use alloy_rlp::Decodable; use alloy_sol_types::{sol, SolEventInterface, SolInterface}; use db::Database; use eyre::OptionExt; use once_cell::sync::Lazy; use reth_exex::{ExExContext, ExExEvent}; use reth_interfaces::executor::BlockValidationError; use reth_node_api::{ConfigureEvm, ConfigureEvmEnv, FullNodeComponents}; use reth_node_ethereum::{EthEvmConfig, EthereumNode}; use reth_primitives::{ address, constants, revm::env::fill_tx_env, revm_primitives::{CfgEnvWithHandlerCfg, EVMError, ExecutionResult, ResultAndState}, Address, Block, BlockWithSenders, Bytes, ChainSpec, ChainSpecBuilder, Genesis, Hardfork, Header, Receipt, SealedBlockWithSenders, TransactionSigned, U256, }; use reth_provider::Chain; use reth_revm::{ db::{states::bundle_state::BundleRetention, BundleState}, DatabaseCommit, StateBuilder, }; use reth_tracing::tracing::{debug, error, info}; use rusqlite::Connection; use std::sync::Arc; mod db; sol!(RollupContract, "rollup_abi.json"); use RollupContrac:{RollupContractCalls, RollupContractEvents}; const DATABASE_PATH: &str = "rollup.db"; const ROLLUP_CONTRACT_ADDRESS: Address = address!("74ae65DF20cB0e3BF8c022051d0Cdd79cc60890C"); const ROLLUP_SUBMITTER_ADDRESS: Address = address!("B01042Db06b04d3677564222010DF5Bd09C5A947"); const CHAIN_ID: u64 = 17001; static CHAIN_SPEC: Lazy> = Lazy::new(|| { Arc::new( ChainSpecBuilder::default() .chain(CHAIN_ID.into()) .genesis(Genesis::clique_genesis(CHAIN_ID, ROLLUP_SUBMITTER_ADDRESS)) .shanghai_activated() .build(), ) }); struct Rollup { ctx: ExExContext, db: Database, } impl Rollup { fn new(ctx: ExExContext, connection: Connection) -> eyre::Result { let db = Database::new(connection)?; Ok(Self { ctx, db }) } async fn start(mut self) -> eyre::Result<()> { // Process all new chain state notifications while let Some(notification) = self.ctx.notifications.recv().await { if let Some(reverted_chain) = notification.reverted_chain() { self.revert(&reverted_chain)?; } if let Some(committed_chain) = notification.committed_chain() { self.commit(&committed_chain)?; self.ctx.events.send(ExExEvent::FinishedHeight(committed_chain.tip().number))?; } } Ok(()) } /// Process a new chain commit. /// /// This function decodes all transactions to the rollup contract into events, executes the /// corresponding actions and inserts the results into the database. fn commit(&mut self, chain: &Chain) -> eyre::Result<()> { let events = decode_chain_into_rollup_events(chain); for (_, tx, event) in events { match event { // A new block is submitted to the rollup contract. // The block is executed on top of existing rollup state and committed into the // database. RollupContractEvents::BlockSubmitted(_) => { // .. } // A deposit of ETH to the rollup contract. The deposit is added to the recipient's // balance and committed into the database. RollupContractEvents::Enter(RollupContract::Enter { token, rollupRecipient, amount, }) => { // .. _ => (), } } Ok(()) } /// Process a chain revert. /// /// This function decodes all transactions to the rollup contract into events, reverts the /// corresponding actions and updates the database. fn revert(&mut self, chain: &Chain) -> eyre::Result<()> { let mut events = decode_chain_into_rollup_events(chain); // Reverse the order of events to start reverting from the tip events.reverse(); for (_, tx, event) in events { match event { // The block is reverted from the database. RollupContractEvents::BlockSubmitted(_) => { // .. } // The deposit is subtracted from the recipient's balance. RollupContractEvents::Enter(RollupContract::Enter { token, rollupRecipient, amount, }) => { // .. } _ => (), } } Ok(()) } } fn main() -> eyre::Result<()> { reth::cli::Cli::parse_args().run(|builder, _| async move { let handle = builder .node(EthereumNode::default()) .install_exex("Rollup", move |ctx| async { let connection = Connection::open(DATABASE_PATH)?; Ok(Rollup::new(ctx, connection)?.start()) }) .launch() .await?; handle.wait_for_node_exit().await }) } ``` # What can I build with Execution Extensions? This question can be reframed as “What can be modeled as a post-execution hook?”. Turns out a lot of things! We see a few valuable ExExes that should be built: 1. Rollup derivation pipelines such as [Kona](https://github.com/ethereum-optimism/kona/tree/main/crates/derive), with EVMs configured for L2 usage, similar to how [Reth Alphanet’s EVM](https://github.com/paradigmxyz/alphanet/blob/main/crates/node/src/evm.rs) is set up. We also predict that composing L2 ExExes will provide the fastest path towards Stage 2 Rollup decentralization. Expect more from us here. We cannot wait to run OP Mainnet, Base, Zora, and other rollups on Reth as ExExes. 2. Out of process ExExes tightly integrated with the node’s services using gRPC, paving the way for multi-tenancy and Reth acting as a control plane for off-chain services. 3. Alternative VM integrations (e.g. MoveVM or Arbitrum Stylus), or complex execution pipelines similar to [Artemis](https://github.com/paradigmxyz/artemis), [SGX Revm](https://github.com/gakonst/sgx-revm) or [Shadow Logs](https://shadow.xyz/). 4. Foundational infrastructure combined with re-staking such as oracles & bridges, or any other Actively Validated Services (AVS). This is possible because ExExes can peer with each other over Ethereum’s DiscV5 P2P network and have an elected set of participants with write permission to their state other than the node’s 'finalized' notifications. 5. Next-generation auxiliary infrastructure such as AI coprocessors, or decentralized/shared sequencers. # What’s next for Execution Extensions? Currently, ExExes need to be installed on the node with a custom build in your main function. We aspire to make ExExes [dynamically loaded as plugins](https://nullderef.com/series/rust-plugins/), and expose a Docker Hub-esque `reth pull` API, such that developers can distribute their ExExes over the air to node operators easily. We want to make Reth a platform that provides stability & performance on core node operations, while also being a launchpad for innovation. The Reth project is hopefully going to change how people think about building high performance off-chain infra, and ExExes are just the beginning. We are excited to continue building infrastructure on Reth, and invest in it. Reach out to [georgios@paradigm.xyz](mailto:georgios@paradigm.xyz) if you want to build an ExEx project, or [contribute](https://github.com/paradigmxyz/reth/labels/A-exex) directly on Github. ## https://www.paradigm.xyz/writing/fig # Fig: Frame Interface Guidelines > We’re excited to open source Frame Interface Guidelines (Fig), which outlines best practices for building great Farcaster Frame experiences, inspired by Apple’s Human Interface Guidelines. ### Best practices for designing great Farcaster frame experiences A few weeks ago, we announced [Frog](https://www.paradigm.xyz/2024/02/frames), a framework for building Farcaster Frames, as part of our collaboration with the Wevm team. Today, we’re excited to open source [**Frame Interface Guidelines**](https://github.com/paradigmxyz/Fig) **(Fig)**, which outlines best practices for building great frame experiences, inspired by Apple’s Human Interface Guidelines. ## Why do we need best practices? Frames turn any cast into an embedded interactive app in a Farcaster client such as [Warpcast](https://warpcast.com/), redefining how content is viewed, engaged, and shared on social media. Frames have revolutionized user interactions within Farcaster, turning static posts into interactive elements useful for ecommerce, games, and other social experiences. But they were lacking a great developer experience, so we built [Frog](https://github.com/wevm/frog) to enable developers to build great Frames. Since shipping Frog, we realized we were missing clear guidelines on what makes or breaks a frame experience. The current landscape of Frame development, although innovative, lacks consistency, leading to user confusion and a steep learning curve that hinders wider adoption. ## So what exactly is Fig? Inspired by [Apple’s Human Interface Guidelines](https://developer.apple.com/design/human-interface-guidelines) as the standard for consistent and user-friendly design, we built [Frame Interface Guidelines (Fig)](https://github.com/paradigmxyz/Fig) to establish a common design framework that encourages creativity while maintaining a cohesive user experience across different frames. ![Example styles in Fig](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--3d8d33621f/93446e88d81d45628d22f52082a19903/asset-https-cdn-sanity-io-images-dgybcd83--3d8d33621f.png) *Example styles in Fig* Fig provides comprehensive guidance on designing Frames that are not only functional but also delightful to interact with. It encompasses everything from layout and typography to more complex elements like user interactions and accessibility, ensuring that Frames not only look appealing but also function smoothly across different devices and platforms. We provide all that guidance in the repository’s [README](https://github.com/paradigmxyz/Fig/blob/main/README.md), and in a separate [Figma community file](https://www.figma.com/community/file/1367670879509913267/frame-interface-guidelines) which you can fork and play with. We strongly recommend reading through the document end to end and frequently referencing it when building Frames. ![Example templates in Fig](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--bd593c079d/9c92dbe84a8339548bef8a0fa129b105/asset-https-cdn-sanity-io-images-dgybcd83--bd593c079d.png) *Example templates in Fig* ## How do I use Fig with Frog? [Frog is our framework](https://www.paradigm.xyz/2024/02/frames) for building high quality frames, along with developer tools for debugging and testing. Recently, [Wevm built Frog UI](https://frog.fm/ui), an extension of the Frog Framework that provides type-safe layout & styling primitives to help you build extensible and consistent dynamic Frame Image interfaces. Frog makes it easy to follow the Fig through FrogUI frame primitives, familiar JSX components (SwiftUI-like) allowing you to rapidly compose layouts as well as manage color, icons, and typography in a systematic way. By default, FrogUI has built-in system tokens and icons that align with Fig — great for a hackathons or prototyping frames. In addition, FrogUI can be customized with colors, icons, and other styles to add your brand’s unique touch. Finally, FrogUI uses responsive aspect-ratio units so that if you change between 1:91:1 or 1:1, your layouts and sizes will still look great. To get started with FrogUI and learn more, head to [frog.fm/ui](https://www.paradigm.xyz/2024/05/frog.fm/ui). ![Code from FrogUI](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--d92a62efef/1521d625a5a885be6b92c5c57d92d78d/asset-https-cdn-sanity-io-images-dgybcd83--d92a62efef.png) Code from FrogUI ## How do I use Fig with Figma? We have published a file to [Figma Community](https://www.figma.com/community/file/1367670879509913267/frame-interface-guidelines) with a set of aforementioned templates, and defaults for font sizes & colors which translate neatly to FrogUI's defaults. ## What’s next for Fig? As we continue to build on the foundation that Fig has established, we look forward to enriching the guidelines with community feedback and evolving needs. Future updates will focus on enhancing interactivity and improving accessibility to further improve the quality of Farcaster Frames. We encourage developers and designers to adopt Fig in their Frame projects, contribute to its ongoing development, and help define the future of user interfaces in crypto. Visit the Fig Repository to get started with Fig, play around with the Figma. Whether you’re a developer, designer, or a Frames enthusiast, reach out if you’re interested in collaborating or have feedback. You can reach us at [achal@paradigm.xyz](mailto:achal@paradigm.xyz) or [georgios@paradigm.xyz](mailto:georgios@paradigm.xyz). You can also find us on Warpcast at [@achal](https://warpcast.com/achal), [@gakonst](https://warpcast.com/gakonst), [@awkweb](https://warpcast.com/awkweb), and [@jxom](https://warpcast.com/jxom). ## https://www.paradigm.xyz/writing/paradigm-files-comment-letter-on-esma-s-financial-instruments-consultation # Paradigm Files Comment Letter on ESMA’s Financial Instruments Consultation > Paradigm has filed a comment letter in response to a consultation as part of the EU’s landmark crypto law, known as MiCA. Paradigm has filed a comment letter in response to a [consultation](https://www.esma.europa.eu/sites/default/files/2024-01/ESMA75-453128700-52_MiCA_Consultation_Paper_-_Guidelines_on_the_qualification_of_crypto-assets_as_financial_instruments.pdf) by the European Securities and Markets Authority (ESMA) on the conditions and criteria for the qualification of crypto-assets as financial instruments. This guidance is intended to delineate whether a crypto-asset falls under the EU’s new crypto framework (Markets in Crypto Assets, known as MiCA) or under the EU’s regulatory framework for tradfi (Markets in Financial Instruments Directive, known as MiFID II). A copy of our comment letter can be found [here](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-fe32d9a2ef/fa529129a6232161d71f3b37262ced55/asset-https-cdn-sanity-io-files-dgybcd83-p-fe32d9a2ef.pdf). Paradigm appreciates the EU for its approach to soliciting feedback early in the rulemaking process. Although we may not agree with the details of every proposal, we support the technical and thoughtful manner with which the EU is engaging industry and the broader public. This is much different from the dynamic we currently experience in the US where politicization too often derails forward progress. The EU now has substantial gravitational pull in financial policy standards setting. As a first-mover in crypto regulation, the EU’s approach to regulating the space will have spillover effects beyond the jurisdictional confines of the EU member states. One of the most critical issues to get right is establishing clear guidelines for determining where/when builders are subject to a regulatory framework tailored to the unique characteristics of the crypto industry—else they be swept into a regulatory perimeter that includes institutions with much different risk profiles and cost structures, like global systemically important banks (G-SIBs). In our comment letter, we make two main points: 1. The proposed guidelines are likely to result in an overclassification of crypto-assets as financial instruments, which goes against the original intent of MiCA. 2. NFTs are out of scope of MiCA by design, but the proposed guidance from ESMA could bring most NFTs under MiCA’s regulatory purview by moving the goalposts on the definition of fungibility. As always, we welcome the chance to provide this level of technical feedback to any policymakers around the world, including those in the US. ## https://www.paradigm.xyz/writing/reth-perf # Reth’s path to 1 gigagas per second, and beyond > Reth’s performance roadmap and how we intend to scale Ethereum. We started building Reth in 2022 to provide resilience to Ethereum L1, and solve execution layer scaling on Layer 2. **Today we’re excited to share Reth’s path towards 1 gigagas per second in L2 in 2024, and our longer-term roadmap for going beyond that.** We invite the ecosystem to collaborate with us as we push the frontier of performance and rigorous benchmarking in crypto. # Are we scaled yet? There’s a very simple path for cryptocurrencies to reach global scale and escape speculation as the dominant use case: **Transactions need to be cheap and fast.** ## How do you measure performance? What does gas per second mean? Performance is typically measured by the metric "Transactions Per Second" (TPS). Particularly for Ethereum and other EVM blockchains, a more nuanced and perhaps accurate measure is "gas per second." This metric reflects the amount of computational work that the network can handle every second, where "gas" is a unit that measures the computational effort required to execute operations like transactions or smart contracts. Standardizing around gas per second as a performance metric allows for a clearer understanding of a blockchain's capacity and efficiency. It also helps in assessing the cost implications on the system, safeguarding against potential Denial of Service (DOS) attacks that could exploit less nuanced measurements. This metric helps compare the performance across different Ethereum Virtual Machine (EVM) compatible chains. **We propose to the EVM community to adopt gas per second as a standard metric, alongside incorporating** [**other dimensions of gas pricing**](https://ethresear.ch/t/draft-position-paper-on-resource-pricing/2838) **to create a comprehensive performance standard.** ## Where are we today? Gas per second is determined by dividing the target gas usage per block by the block time. Here, we showcase the current gas per second throughput and latency across various EVM chains L1s and L2s (not exhaustive): ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--760b41f4af/e530d08a03681c651cbedacf108ce8d9/asset-https-cdn-sanity-io-images-dgybcd83--760b41f4af.png) We emphasize gas per second to thoroughly assess EVM network performance, capturing both compute and storage costs. Networks like Solana, Sui, or Aptos are not included due to their distinct cost models. We encourage efforts towards harmonizing cost models across all blockchain networks to enable comprehensive and fair comparisons. We are working on a continuous benchmarking suite for Reth replicating real workload, if you want to collaborate on this, please reach out. We need a [TPC Benchmark](https://www.tpc.org/information/benchmarks5.asp) for nodes. # How will Reth get to 1 gigagas per second? Beyond that? We were partially motivated to build Reth in 2022 by the pressing need to have a client purpose-built for web-scale rollups. We think we have a promising path forward. **Reth already achieves 100-200mgas/s during live sync (including senders recovery, executing transactions, and calculating the trie on every block);** **10x from here gets us to the our short-term goal of 1 gigagas/s.** As we advance Reth's development, our scaling plan has to balance scalability with efficiency: - Vertical Scaling: Our goal here is to maximize the use of each "box" to its full potential. By optimizing how each individual system handles transactions and data, we can greatly enhance the overall performance, while also making it more efficient for individual node operators. - Horizontal Scaling: Despite the optimizations, the sheer volume of transactions at web scale exceeds what any single server can handle. To address this, we want to implement a horizontally scaled architecture, similar to a Kubernetes model for blockchain nodes. This means spreading the workload across multiple systems to ensure that no single node becomes a bottleneck. The optimizations we are exploring here do not involve solving [state growth](https://www.paradigm.xyz/2024/03/how-to-raise-the-gas-limit-1), which we are researching separately. Here’s a summary of how we intend to get there: ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--cef15a7405/7567d8941309618832b569d9f7ad6289/asset-https-cdn-sanity-io-images-dgybcd83--cef15a7405.png) Across the entire stack we are also optimizing for IO and CPU using the actor model, to allow each part of the stack to be deployed as a service with fine control over its utilization. Finally, we are actively evaluating alternative databases, but have not decided yet on a candidate. ## Reth’s vertical scaling roadmap Our goal here is to maximize the performance and efficiency of a single server or laptop running Reth. ### Just-In-Time & Ahead-of-Time EVM In blockchain environments like the Ethereum Virtual Machine (EVM), bytecode execution happens through an interpreter, which sequentially processes instructions. This method introduces overhead because it doesn't execute native assembly instructions directly, instead operating through the VM layer. Just-In-Time (JIT) compilation addresses this by converting bytecode to native machine code just before execution, thereby improving performance by bypassing the VM's interpretative process. This technique, which compiles contracts into optimized machine code ahead of time, is well-established in other VMs like Java and WebAssembly. However, JIT can be vulnerable to malicious code designed to exploit the JIT process, or may be too slow to run live during execution. Reth will Ahead-of-Time (AOT) compile the highest demand contracts and store them on disk, to avoid untrusted bytecode trying to abuse our native-code compilation step during live execution. We have been working on a JIT/AOT compiler for Revm, currently being integrated with Reth. We will open source this in the coming weeks once our benchmarking is done. About 50% of execution time is spent in the EVM interpreter on average, so this should provide a ~2x EVM execution improvement, although in some more compute heavy cases it might be even more impactful. We will be sharing our benchmarks and integration of our own JIT EVM in Reth in the coming weeks. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--c3e9362e32/e7417c87b457ba84c051d0b182b71c66/asset-https-cdn-sanity-io-images-dgybcd83--c3e9362e32.png) ### Parallel EVM The concept of a Parallel Ethereum Virtual Machine (Parallel EVM) enables simultaneous transaction processing, diverging from the traditional serial execution model of the EVM. We have 2 paths forward here: 1. Historical Sync: In historical synchronization, we can calculate the best possible parallelization schedule by analyzing past transactions and identifying all historical state conflicts. See our early attempt at this in an old branch on [Github](https://github.com/paradigmxyz/reth/tree/rkrasiuk/parallel). 2. Live Sync: For live synchronization, we can use [Block STM](https://arxiv.org/abs/2203.06871)-like techniques to speculatively execute without any additional information like access lists. This algorithm has poor performance during periods of heavy state contention, so we want to explore switching between serial and parallel execution depending on the shape of the workload, as well as statically predicting which storage slots will be accessed to improve the quality of the parallelism. See one PoC by a 3rd party team [here](https://github.com/risechain/block-stm-revm/). Based on our historical analysis, ~80% of Ethereum storage slots are accessed independently, meaning parallelism could yield up to 5x improvement in EVM execution. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--b2af7028af/c9c5c0a0a146a7de7703fc583c66c320/asset-https-cdn-sanity-io-images-dgybcd83--b2af7028af.png) ### Improving the State Commitment We [recently wrote about](https://twitter.com/gakonst/status/1777306306598089094) the impact of state root in performance and the differences between the Reth database model from other clients, as well as why it is important. In the Reth model, calculating the state root is a separate process from executing transactions ([see](https://github.com/alloy-rs/trie/) [our](https://github.com/paradigmxyz/reth/tree/main/crates/trie) [code](https://github.com/paradigmxyz/reth/tree/main/crates/trie-parallel)), enabling the usage of standard KV stores that do not need to know anything about the trie. This currently takes >75% of the end to end time to seal a block, and is a very exciting area to optimize. We identify the following 2 “easy wins” which can give us 2-3x in the state root performance, without any protocol changes: 1. Fully Parallelized State Root: Right now we only re-calculate the storage trie for changed accounts in parallel, but we can go further and also calculate the accounts trie in parallel while the storage root jobs complete in the background. 2. Pipelined State Root: Pre-fetch intermediate trie nodes from the disk during execution by notifying the state root service about storage slots and accounts touched. Going beyond that, we see a few paths forward by diverging from Ethereum L1 state root behavior: 1. Less frequent State Root: Instead of calculating the state root on every block, calculate it every T blocks. This reduces the overall % of the time spent in the state root in the entire system and could be the easiest and most effective solution. 2. Trailing State Root: Instead of having to calculate the state root at the same block, let it lag behind a few blocks. This allows execution to advance without blocking on the state root calculation. 3. Replace the RLP Encoder & Keccak256: Instead of encoding with RLP, it may be cheaper to just concatenate the bytes and use a faster hash function like Blake3. 4. Wider Trie: Increase the N-arity of the tree, to reduce the IO amplification due to the logN depth of the trie. There are a few questions here: 1. What are the second order effects of the above changes on light clients, L2s, bridges, coprocessors and other protocols that rely on frequent account & storage proofs? 2. Can we both optimize the state commitment for SNARK proving and for native execution speed? 3. What is the widest state commitment that we can get with the tools we have available to us? What second order effects are there around the witness size? ## Reth’s horizontal scaling roadmap We will execute on multiple of the above points throughout 2024 and achieve our goal of 1gigagas/sec. However, vertical scaling ultimately encounters physical and practical limits. No single machine can handle the world's computing needs. We think there are 2 paths forward here, which allow us to scale out by introducing more boxes as more load arrives: ### Multi-Rollup Reth Today’s L2 stacks require running multiple services to follow the chain: L1 CL, L1 EL, the L1 -> L2 derivation function (which may be bundled with the L2 EL), and the L2 EL. While great for modularity, this gets complicated when running multiple node stacks. Imagine having to run 100 rollups! We want to allow launching rollups in the same process as Reth and drive the operating cost of running thousands of rollups to almost zero. We are already underway with this with our [Execution Extensions projects](https://github.com/paradigmxyz/reth/labels/A-exex) ([\[1\]](https://github.com/paradigmxyz/reth/blob/main/examples/exex/op-bridge/src/main.rs), [\[2\]](https://github.com/paradigmxyz/reth/pull/7826/files)), more in the coming weeks here. ### Cloud-native Reth High performance sequencers may have enough demand on a single chain that they need to scale out to beyond a single machine. This is not possible in today’s monolithic node implementations. We want to allow running Cloud-native Reth nodes, deployed as a service stack that can autoscale with compute demand and use the seemingly infinite cloud object storage for persistence. This is a common architecture in serverless database projects such as NeonDB, CockroachDB or Amazon Aurora. See [early thoughts](https://rakita.github.io/blog/blog/zombie-nodes/) from our team on some ways we could go about this problem. # Outlook We intend to roll out this roadmap incrementally to all Reth users. Our mission is to give everyone access to 1 gigagas/s and beyond. We will be testing our optimizations out on Reth AlphaNet, and we hope people will build modified high performance nodes using Reth as an SDK. There are some questions we have not arrived at answers for yet. - How can Reth help with improving performance across the L2 ecosystem? - How do we appropriately measure worst case scenarios when some of our optimizations might be for the average case? - How do we manage the tension between L1 and L2 potentially diverging? We do not have answers to many of these questions, but we have enough initial promising leads to keep us busy for a while and hope to see these efforts bear fruit in the coming months. **We will move the needle on scaling Ethereum. If you’re excited about contributing to breaking the 1gigagas/s barrier for EVM Rollups, reach out to** [**georgios@paradigm.xyz**](mailto:georgios@paradigm.xyz)**.** ## https://www.paradigm.xyz/writing/reth-alphanet # Reth AlphaNet > Reth AlphaNet is a testnet OP Stack-compatible rollup aimed at maximizing Reth performance and enabling experimentation of bleeding edge Ethereum Research. **Today, we are excited to open source** [**Reth AlphaNet**](https://github.com/paradigmxyz/alphanet)**, an** [**OP Stack-compatible testnet rollup**](https://docs.optimism.io/stack/components) **aimed at maximizing** [**Reth**](https://github.com/paradigmxyz/reth/) **performance and enabling experimentation of bleeding edge Ethereum Research.** With this post, we hope to get developers excited to contribute and build on AlphaNet with experiments, performance optimizations, and push the frontier of Ethereum systems research, engineering and tooling with us. # What is Reth AlphaNet? [**Reth AlphaNet**](https://github.com/paradigmxyz/alphanet) is an [OP Reth](https://paradigmxyz.github.io/reth/run/optimism.html) Rollup with the following characteristics: - **Testnet**: It’s a testnet rollup, holding no assets of real value. - We may periodically reset it if we want to introduce breaking changes. - We are open to either full reset or migrating some state across resets. - **Experimentation**: It initially comes with 3 EIPs implemented and tested, which are not available in any other network at the time of writing of the post: - [EIP-3074](https://eips.ethereum.org/EIPS/eip-3074): AUTH and AUTHCALL instructions ([source](https://github.com/paradigmxyz/alphanet/blob/main/crates/instructions/src/eip3074.rs)). - [EIP-7212](https://eips.ethereum.org/EIPS/eip-7212): Precompile for secp256r1 curve support ([source](https://github.com/paradigmxyz/alphanet/blob/main/crates/precompile/src/secp256r1.rs)). - [EIP-2537](https://eips.ethereum.org/EIPS/eip-2537): Precompiles for BLS12-381 curve operations ([source](https://github.com/paradigmxyz/alphanet/blob/main/crates/precompile/src/bls12_381.rs)). - **High Performance**: It will aim to break the gigagas barrier (1 gigagas per second) and confront the [state growth](https://www.paradigm.xyz/2024/03/how-to-raise-the-gas-limit-1) problem head on. - Reth has been benchmarked at [100-200 megagas per second](https://twitter.com/megaeth_labs/status/1765606577321685291) on the [alpha.13](https://github.com/paradigmxyz/reth/releases/tag/v0.1.0-alpha.13) version (December 4th 2023) for "live sync" (incl. sender recovery, execution, hashing, and trie), and 1-3 gigagas/s for "historical sync" (only execution) on a 16-core @ 3.1GHz, 512GB RAM machine with a [fast SSD](https://gist.github.com/yorickdowne/f3a3e79a573bf35767cd002cc977b038). - We are on [beta.5](https://github.com/paradigmxyz/reth/releases/tag/v0.2.0-beta.5) (April 3rd 2024), and we've [merged](https://github.com/paradigmxyz/reth/pull/7161/files) multiple [optimizations](https://github.com/paradigmxyz/reth/pull/6903) since the original benchmark. - We invite the community to review the benchmarks and help us with further stress testing the code. Zooming in: 1. AlphaNet implements the [OP Stack standard's Ecotone Hard fork](https://docs.optimism.io/stack/components) via the [Node Optimism](https://github.com/paradigmxyz/reth/tree/main/crates/node-optimism) crate. 2. [Bridging in](https://docs.optimism.io/stack/protocol/deposit-flow) and [bridging out](https://docs.optimism.io/stack/protocol/withdrawal-flow) of the rollup will work same as stock OP Stack. The deposit and withdrawal delays will be on the lower end, optimized for developers wanting to end to end test bridge flows in wallets, block explorers, and other infrastructure. 3. We do not have a strong view on what data availability mechanism AlphaNet should use. We will start with blobs and calldata, and will eventually explore multiplexing across multiple data availability layers based on fees. We are also looking at [OP Plasma](https://github.com/ethereum-optimism/optimism/tree/develop/op-plasma). The whole codebase is <1500 lines of Rust code (LoC), *including tests*: ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--ddb85bf837/236798d4ba3b2797adb689939952a582/asset-https-cdn-sanity-io-images-dgybcd83--ddb85bf837.png) [AlphaNet is now open sourced](https://github.com/paradigmxyz/alphanet) under the Apache/MIT permissive license, for anyone to fork, modify or launch. # What is the Reth SDK? AlphaNet is built on top of Reth, rather than forking it. Our [original vision of Reth](https://www.paradigm.xyz/2023/06/reth-alpha#reth-is-also-a-new-sdk-for-building-evm-centric-infrastructure) describes it as not just a node, but a Software Development Kit (SDK), as legos for building EVM-centric infrastructure. Forking nodes is extremely brittle, it's harder to propagate updates across the ecosystem and rebasing large feature branches is hard. It also means lack of principle around where code changes happen. **The Reth SDK is a new paradigm for building nodes, specifically built for customization and for the rollup-centric roadmap.** AlphaNet implements traits provided by the Reth SDK's [Reth node builder API](https://paradigmxyz.github.io/reth/docs/reth_node_builder/index.html), allowing extreme customization without forking the node. This relates closely to the original Erigon architecture of a node that separates concerns and allows running components like the transaction pool or the RPC as separate processes. The Reth SDK takes it even further using Rust's advanced type system and clean abstractions. Here are some [example modifications](https://github.com/paradigmxyz/reth/tree/main/examples) you can do on the node: 1. [Custom RPCs](https://github.com/paradigmxyz/reth/tree/main/examples/additional-rpc-namespace-in-cli): Spinning up additional RPC methods and namespaces. 2. [Custom EVMs](https://github.com/paradigmxyz/reth/tree/main/examples/custom-evm): Overriding the EVM's precompiles, instructions, and more. 3. [Custom Block Builder](https://github.com/paradigmxyz/reth/tree/main/examples/custom-payload-builder): Building blocks with your own orderflow or with a custom mempool. We intend to share more information about how to use the Reth SDK (or Reth Core) in the coming months, as we drive it to feature completeness. We could not be more excited about this. For now, the [examples](https://github.com/paradigmxyz/reth/tree/main/examples) and the `NodeBuilder` are the [best things](https://github.com/search?q=repo%3Aparadigmxyz%2Freth%20nodebuilder&type=code) to look for in the codebase. # Why build AlphaNet? We called it AlphaNet because it is “alpha” software for experimentation, but also “alpha” because it provides edge to developers that learn how to use its “developer preview” features. AlphaNet's goals are: 1. **Enable developers to experiment with Ethereum nodes using Reth's modular architecture:** - AlphaNet can serve as a distribution channel for research ideas, and encourage Layer 2 experimentation. - AlphaNet's node extensions were chosen for their ability to enable applications that enhance the onchain user experience, and drastically reduce cost for existing applications that improve UX. - Reth exposes [Revm's](https://github.com/bluealloy/revm/) new [`EVMBuilder`](https://docs.rs/revm/latest/revm/struct.EvmBuilder.html) [API](https://docs.rs/revm/latest/revm/struct.EvmBuilder.html) ([PRs](https://github.com/search?q=repo%3Abluealloy%2Frevm+evmbuilder&type=pullrequests)) which enables developers to extend the EVM with custom opcodes, instructions, gas tokens and more. - The Reth SDK will also allow swapping out key node components like the block executor, the state root algorithm, and already supports swapping out most other components like the networking stack, the block payload builder, database, and more. 1. **Test Reth's performance at the extremes, to 1 gigagas per second and beyond.** - We hope to hit the state growth performance bottleneck, and discover ways to solve it, using research techniques already tested out on [Ethereum](https://www.paradigm.xyz/2024/03/how-to-raise-the-gas-limit-1a) and [Base](https://twitter.com/notnotstorm/status/1778803270750023813) mainnet. - We hope to experiment with state expiry, rent, compress & revive-style techniques using witnesses, and anything that lets us move the needle there. - We will also deploy other techniques we've been talking about [for](https://twitter.com/search?q=%22parallel%20evm%22%20from%3A%40gakonst&src=typed_query&f=live) a [long](https://twitter.com/search?q=reth%20parallel%20evm&src=typed_query&f=live) [time](https://twitter.com/search?q=jit%20evm%20from%3A%40gakonst&src=typed_query&f=live), such as parallel EVM (Block STM-based for live sync and by calculating the optimal schedule for historical sync), JIT/AOT EVM, alternative [state root](https://twitter.com/gakonst/status/1777306306598089094) implementations & optimizations, [multi-tenancy](https://twitter.com/search?q=multi%20tenancy%20from%3A%40gakonst&src=typed_query&f=top), and more. We already have proof of concepts for parallel EVM and JIT/AOT, and we're going to start pushing them forward more in the coming months. # What is the roadmap? Our short-term roadmap for AlphaNet is as follows: 1. Launch a hosted version of AlphaNet on [Conduit](https://conduit.xyz/), targeting 50 megagas/s, and eventually ramping up to 1 gigagas/s. If the nodes we run end up not being able to keep up with the sequencer due to state growth, we may possibly restart the experiment from zero, and try again. 2. Distribute modified [Foundry](https://github.com/foundry-rs/foundry) builds via the `foundryup --alphanet` command, so that any Foundry developer can access tooling for the node’s extensions. 3. Use [Rivet](https://www.paradigm.xyz/2023/08/rivet) as an “Experimental Developer Wallet”, in order to iterate on Wallet UX for EIP-3074, BLS signatures, and native Passkey support. We're particulary excited for EIP-3074 on AlphaNet with Foundry and Rivet, and recommend the entire ecosystem to prepare for its upcoming deployment in Ethereum L1 as of the [All Core Devs meeting on April 11th 2024](https://x.com/gakonst/status/1778445908633387304). If you want to work on EIP-3074 Invokers, help clean up our Foundry integration, or contribute to Rivet, please reach out. Medium-term: 1. We would like to try out other EIPs & RIPs like [RIP7560](https://ethereum-magicians.org/t/rip-7560-native-account-abstraction/16664) and [EOF](https://github.com/ipsilon/eof/blob/main/spec/implementation_matrix.md) (already implemented in [Revm](https://github.com/bluealloy/revm/pull/1143)). What else should we try? 2. Push hard on the Reth performance optimizations mentioned in the "Why build AlphaNet?" section above. 3. Push for the second [OP Fault Proof](https://docs.optimism.io/stack/protocol/fault-proofs/overview) implementation in Rust using Reth ([FPVM](https://docs.optimism.io/stack/protocol/fault-proofs/cannon) choice TBD, between RISCV and MIPS), accelerating the [OP Stack's Stage 2 Fault Proof roadmap](https://twitter.com/Optimism/status/1770420145917476942). **We hope that Reth will be a fundamental building block for every Layer 2's scaling strategy.** Our long-term goal is to scale Ethereum and its L2 ecosystem together with the community. We will use AlphaNet as a feedback loop for pushing the frontier and deploying the best technology in production L1s and L2s. We invite the community to share with us what they'd like us to try out, or write code with us. **AlphaNet will be launched soon after Reth 1.0, before the end of Q2.** The Reth SDK provides very powerful abstractions for building modified performant nodes, and we think this is just the beginning. In the coming weeks we will be sharing everything we have been building with the Reth SDK. We will also share optimizations and architecture improvements for breaking through the performance and feature barriers required to reach web scale cryptocurrency. We are looking for feedback and invite developers to [contribute to the codebase on Github](https://github.com/paradigmxyz/alphanet/). Please reach out to [georgios@paradigm.xyz](mailto:georgios@paradigm.xyz) if this sounds exciting. ## https://www.paradigm.xyz/writing/Cryptos-Biggest-Skeptics-are-EVM-pilled # Crypto's Biggest Skeptics are EVM-pilled > Central banks love to publicly question crypto. And yet their use of crypto technology tells a much different story: central bank future-of-finance efforts increasingly leverage crypto Open Source Software (OSS). We collected data on 63 blockchain-related experiments led by G20 central banks. We found that a substantial amount of projects (47% of our sample) across different use cases (e.g., CBDC, tokenization, DeFi, etc.) are compatible with the Ethereum Virtual Machine (“EVM,” in other words, based on [Ethereum](https://ethereum.org/en/)’s technology stack). In addition, an increasing number of projects are being launched on public blockchains, proving that public, permissionless infrastructure is not incompatible with the needs of regulated institutions. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--b44cb60ed8/060c4984c814c6c90552c5151084aea8/asset-https-cdn-sanity-io-images-dgybcd83--b44cb60ed8.png) Our findings underscore a few important things: **Innovation happens at the edges and eventually gets adopted by incumbents.** Accordingly, hampering innovation inevitably reduces the scope of technology that eventually reaches maturity. Even if central banks are skeptical of crypto ([and they are](https://www.ecb.europa.eu/press/blog/date/2024/html/ecb.blog20240222~0929f86e23.en.html)), they are still taking battle-tested tech from the permissionless world and using it in their own unique context. If the US government had killed innovation in the information communications technology (ICT) sector, [Fedwire messages might still use teletype and Morse Code](https://www.federalreservehistory.org/essays/fedwire). To that end, central banks are starting to move past basic CBDC and payments projects and are now looking into [tokenization](https://www.bis.org/about/bisih/topics/fmis/promissa.htm) and [DeFi](https://blog.uniswap.org/defi-project-mariana). The projects are getting increasingly complex, and more frequently are being deployed on public, permissionless blockchains. A couple of the most interesting projects, in our view - [Project Mariana](https://www.bis.org/publ/othp75.pdf): A cross-border FX project using tokenized central bank money and an AMM on Ethereum’s Sepolia testnet. - [Project Guardian](https://www.mas.gov.sg/-/media/mas-media-library/development/fintech/project-guardian/project-guardian-open-interoperable-network.pdf): Three sub-projects looking building liquidity pools, structured notes, and asset-backed securities for trade finance using Ethereum L2s. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--af179580b2/fc1dd6c03e9348af47c6307639e348bf/asset-https-cdn-sanity-io-images-dgybcd83--af179580b2.png) It’s too early to see how many projects will be deployed on public networks in 2024, but we suspect that “number go up” from 2023. As noted above, some of the most-innovative projects in this category were launched by the Monetary Authority of Singapore (MAS). The MAS is an undisputed leader in this space, and its work demonstrates that, among other things, deploying a project to a blockchain with a permissionless validator set is not inherently a violation of sanctions laws. **Network effects matter. **We believe this is another indication that Ethereum has the strongest developer ecosystem of major L1s today. Anecdotally, we have heard from several tradfi institutions that have ditched proprietary enterprise blockchains in favor of EVM-based blockchains due to the robustness of the developer community (e.g., dev tools, human capital, etc.). **OSS is battle tested.** [Most](https://www.zdnet.com/home-and-office/networking/can-the-internet-exist-without-linux/) of the Internet today runs on Linux-based servers. The future of finance will be no different. One underappreciated benefit of the often-adversarial nature of crypto is that projects deployed to public blockchains (and the blockchains themselves) undergo significant stress testing in the wild—both in terms of security and economic design. **The US is falling behind—but it has an opportunity to create a positive feedback loop. **In our sample, the US completed 5 public projects, while Singapore—with substantially smaller capital markets—completed 8 projects (some with additional phases we did not separately record). On the surface, this looks bad. However, to the extent that other countries continue to leverage EVM-based projects built as OSS, we think the US has an opportunity to lead by being home to many of the most ambitious builders. As US-built tech gets exported to the rest of the world, US values follow. We were particularly excited to see that the [NY Fed is already Rust-pilled](https://www.newyorkfed.org/medialibrary/media/nyic/project-cedar-phase-two-ubin-report.pdf). — This work was supported by a Policy Lab Research Hub grant awarded to [Jordan Miller](https://www.linkedin.com/in/jordanmiller5000/) who collected the data (available [here](https://github.com/brendanpmalone/evm-pilledCBs), if anyone wants to use or update). If you’re interested in applying for funding to support a policy research project, check out the Policy Lab [here](https://policy.paradigm.xyz/policylab/research-hub). ## https://www.paradigm.xyz/writing/amicus-brief-coinbase # Paradigm Files Amicus Brief Supporting Coinbase's Lawsuit vs. SEC > Paradigm filed an amicus brief supporting Coinbase’s lawsuit against the SEC, which seeks judicial review of the agency’s refusal to provide rules for crypto. **TLDR**: Today, Paradigm filed an [amicus brief](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-733283bafa/a61fd1535e72fc10a4af1195df14c66b/asset-https-cdn-sanity-io-files-dgybcd83-p-733283bafa.pdf) supporting Coinbase’s lawsuit against the SEC, which seeks judicial review of the agency’s refusal to provide rules for crypto. The SEC’s decision to engage in ad-hoc regulation by enforcement, instead of transparent rulemaking, is clearly unworkable. Paradigm supports Coinbase’s effort to seek clear rules of the road. Crypto assets differ fundamentally from securities, including by virtue of existing independent of any “issuer,” and deriving value from their utility in a decentralized network. In contrast, the securities laws are focused on requiring the “issuer” of securities to disclose information to investors, such as the issuer’s financial position and the biographies of its managers. This mismatch means that brute forcing today’s securities laws onto crypto will fail to achieve the main policy goal of providing material information to purchasers, because the current required disclosures focus on the irrelevant or unavailable information. In addition, the litany of projects that were required to register as part of an SEC settlement action, or attempted to qualify a Reg. A exempt offering, have generally failed–proving that the current framework is unworkable. Repeatedly trying to smash the dodecahedron peg of crypto into the square hole of securities regulation has not, will not, and cannot work. Recognizing the obsolescence of the current regulatory framework, Coinbase petitioned the SEC to issue applicable rules. To be clear: the SEC has the ability to tailor its disclosure regime as it has done in the past for the energy and banking industries. The SEC also has the duty to engage in transparent rulemaking, to put the crypto industry on notice and allow individuals to conform their conduct to the law. By abdicating its responsibility, the SEC is paralyzing a major and growing industry and hurting America’s prospects. Hopefully, this lawsuit will bring the SEC to do the simplest thing it could do: issue regulations appropriate and fit-for-purpose for this new and novel industry. ## https://www.paradigm.xyz/writing/March-2024-Polling # March 2024 Public Opinion Poll > Key findings about American voters use of crypto and the importance of this growing voting bloc. Voters care about crypto. While the mainstream media focuses primarily on the November general election horse race, more important structural trends are forming below the surface. One is that American voters increasingly understand the importance of crypto. They’re buying it, they’re holding it, and they understand its value. Below, we share the results of a recent poll of 1000 registered voters Paradigm conducted a few weeks ago. As you’ll see, policymakers looking toward the future should be learning about crypto. Crypto is increasingly not just a part of our technology ecosystem but of our financial system, our economy, and our politics. Large numbers of voters are looking for policymakers who can boldly light a path forward on crypto policy. **Takeaway 1:** Crypto is the best option for those left behind by traditional financial institutions. In a world where **69% of Americans are dissatisfied with the current financial system**, folks are turning to other options where *they* have the power — instead of big banks. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--c3431a996e/5c7533ed6dee3e8be94f47a273a81ba8/asset-https-cdn-sanity-io-images-dgybcd83--c3431a996e.png) **Takeaway 2**: 19% of American registered voters say they’ve bought crypto. - This includes 19% of self-identified Democrats and 18% of Republicans - 24% of self-identified independent voters have bought crypto - Crypto owners are a much bigger segment of the electorate than is often appreciated among policymakers. **A fifth of the country is not a niche subgroup.** ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--30d9edf52c/96c50c8d7851895290424acf0d018efb/asset-https-cdn-sanity-io-images-dgybcd83--30d9edf52c.png) **Takeaway 3:** Ownership of crypto is even higher among communities of color and among the young. - 40% of men 18-54 have bought crypto. - 33% of African Americans and 32% of Hispanics currently own, have traded, or used cryptocurrency in 2024, compared to 20% and 22% from last year. - There has been much commentary about the shifting electoral preferences of young voters and nonwhite voters. It is clear that one thing these groups care about is how policymakers will approach crypto. **Takeaway 4:** Notably, crypto ownership is greatest among college graduates, with 26% owning crypto. - The educational group with the lowest percentage of ownership is voters with postgraduate degrees, at just 13%. - This difference may be due to the fact that postgraduate degree holders benefit the most from the current economy and financial system. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--93be705523/0a78f8aed0229541eea700abacb29869/asset-https-cdn-sanity-io-images-dgybcd83--93be705523.png) **Takeaway 5:** Millions of voters own more than a small amount of crypto - 7% of voters own more than $1000 of crypto - And 1% of voters own more than $10,000 of crypto. - Given that over [161 million Americans](https://www.statista.com/statistics/273743/number-of-registered-voters-in-the-united-states/) are registered to vote, that means that over 11 million registered voters own more than $1000 of crypto. - As a point of comparison, our poll indicates that only 32% of voters own more than $1000 in stocks, despite crypto only existing for a bit over a decade, and 57% of voters do not own any stocks ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--f94dd9dca5/2e94ee408918b0e374a8699a2f4f6fa9/asset-https-cdn-sanity-io-images-dgybcd83--f94dd9dca5.png) **Takeaway 6**: Americans have noticed the option to buy Bitcoin spot ETFs in a big way. - Since the approval of the spot Bitcoin ETFs two months ago, 6% of American voters have invested in them, and another 6% say they plan to invest in them. - Another 22% of voters say they might buy a Bitcoin spot ETF, including 26% of men and 18% of women - Spot crypto ETFs are, as expected, proving to be a major vehicle onboarding Americans into crypto, and may end up being a step to direct crypto ownership. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--e245405631/c82eba5c93aaa89c03d5b52aed499dc5/asset-https-cdn-sanity-io-images-dgybcd83--e245405631.jpg) **Takeaway 7**: Americans don’t trust either party when it comes to crypto. - 49% of voters trust neither party on crypto, including 40% of Democrats and 30% of Republicans - This trend is equally true of Biden and Trump supporters: 45% of both groups don’t trust either party on crypto. - The lack of trust voters have in either party on this subject shows that there is an opportunity for both parties electorally, if they focus their time and attention on crafting comprehensive policy proposals on crypto. **Takeaway 8:** Crypto holders make up a good percentage of the current voting bloc, and it’s time elected officials take notice. - With 19% of voters holding or using crypto and an additional 16% who are likely to invest in crypto, those numbers are sufficient to sway an election. - Overall, 45% of registered voters are planning to vote for former President Trump, while 42% of voters are planning to vote for President Biden. This data largely matches other public data on the electoral horserace, including the latest [Morning Consult poll](https://pro.morningconsult.com/trackers/2024-presidential-election-polling), which has former President Trump narrowly leading President Biden 44% to 43%. - At present, 48% of crypto owners are planning to vote for Trump, 39% are planning to vote for Biden, and 13% are undecided. - Notably, among crypto owners, 43% recall voting for President Biden in 2020 and just 39% of crypto voters recall voting for former President Trump that year. So it appears some of the voters President Biden is now losing to Trump are owners of crypto, possibly because of actions taken by some agencies in the Biden Administration. - This data collectively shows that crypto owners are themselves a swing vote demographic, one that could be decisive if the election is yet another razor-thin race. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--09665615fe/d1cec875e92e4c700536a76633cf432f/asset-https-cdn-sanity-io-images-dgybcd83--09665615fe.png) The above poll was conducted by Public Opinion Strategies. Data was collected nationally from February 28th to March 4th. Sample size = 1000 registered voters polled online with a margin of error of 3.5%. ## https://www.paradigm.xyz/writing/reth-beta # Announcing Reth Beta! > After 21 alpha releases Reth is entering beta.1 and preparing for our 1.0 “production ready” release in the next few months. In this post, we discuss the core features, performance, and stability of Reth Beta. **We are excited to announce that after** [**21 alpha releases**](https://twitter.com/search?q=reth%20alpha&src=typed_query&f=live) **since** [**July 2023**](https://twitter.com/gakonst/status/1671186635814473728)**, Reth is entering** [**beta.1**](https://github.com/paradigmxyz/reth/releases/tag/v0.2.0-beta.1) **and preparing for our 1.0 “production ready” release once audits are done in the next few months. In this post, we’ll discuss the core features, performance, and stability of Reth Beta. In the near future, we will be publishing guides on how to maximally leverage Reth in your infrastructure, and roadmaps for the future of Reth.** TL;DR - Supported Networks & HardForks: - Ethereum: Cancun - OP Stack: Ecotone - No other networks planned, please reach out with specs and ideas. - Prod-readiness: Audits are underway, out before end of Q2 - Performance (Feb 27th): - TPS: Live sync benchmarks to >1K TPS, historical sync >10K TPS. - RPC: State of the art in every call except `eth_subscribe newHeads` which we are investigating. - Sync Time: Our fastest archive sync is now at 49 hours, and we have another ~10-20% to go in the coming weeks. Non-archive sync with execution from genesis is now at 42 hours. Both state of the art. - DB Size: Our archive node database sits at just over 2TB (state of the art), and our full node at just over 1TB (geth/nethermind are better by ~100GB). Similarly, we have another 10-20% improvements to get here in the next releases. # Introduction **Last year, we** [**released**](https://www.paradigm.xyz/2023/06/reth-alpha) **Reth alpha.1, the first version of our modular, contributor-friendly, and blazing fast Ethreum execution node, written in Rust.** Our goals behind the Reth project remain the same: 1. Provide a great execution client for Ethereum mainnet’s resilience and long-term innovation. 2. Create an ecosystem of polished libraries for developers to build a new wave of EVM-centric infrastructure, including Rollups, RPCs, P2P services, Indexers, and more. **Today, we’re excited to announce Reth v0.2.0, the beginning of our Beta release cycle.** Reth Beta is Cancun-ready, syncs from genesis, keeps up with the tip, performs extremely well under heavy RPC load for both point and range queries, and has improved validator performance. Find the release [here](https://github.com/paradigmxyz/reth/releases/tag/v0.2.0-beta.1). This release includes breaking changes that are not compatible with the nodes synced on [alpha versions](https://github.com/paradigmxyz/reth/releases/tag/v0.1.0-alpha.21). Alpha versions will be released with only critical fixes. **All users are recommended to upgrade to the Beta release and resync.** Read our [docs](https://paradigmxyz.github.io/reth/run/mainnet.html) on how to do that. We are also releasing [alpha.22](https://github.com/paradigmxyz/reth/releases/tag/v0.1.0-alpha.22) as a patch release to the alpha series. All alpha node operators should update; this is not a breaking change. # Adoption Update Despite being alpha software, Reth is found in [about 2-3%](https://www.ethernets.io/) of all Ethereum nodes. We are excited for this number to grow with the beta release. Our Github repository is nearing [3000 stars](https://github.com/paradigmxyz/reth), putting us behind go-ethereum’s massive 45K stars (omitted from the chart below—a testament to go-ethereum’s massive success). Finally, the most important metric for us is the [244 unique contributors](https://github.com/paradigmxyz/reth/graphs/contributors) to Reth, as that is part of our mission of growing the number of developers intimately familiar with Ethereum Protocol implementations. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--725593ccf1/39d4f5385f89702f1fd1d4100f4c443d/asset-https-cdn-sanity-io-images-dgybcd83--725593ccf1.png) # Features & Stability Update Reth Beta comes with a lot of exciting features and stability improvements. - **Cancun Ready** - Reth is ready for Ethereum mainnet’s Cancun hardfork on [March 13th](https://x.com/gakonst/status/1755696978435232211?s=20). - Reth has participated in multiple rounds of devnets and shadow forks that have surfaced bugs related to cancun EIP implementations. Big shoutout to the Ethereum Foundation’s DevOps team—truly an amazing team to be working with. - Fun fact: Reth was used to send the first blob on holesky: [https://holesky.blobscan.com/block/894735](https://holesky.blobscan.com/block/894735). - **OP Ecotone Ready** - OP Reth is ready for the upcoming Ecotone hardfork on Base Mainnet, Zora Network & other OP Stack networks. - Reth started supporting the OP Stack [November 2023](https://twitter.com/gakonst/status/1721254692796428294) via a collaboration with the OP Labs and BASE teams. We think this is critical for supporting the Optimism Collective and the Rollup-centric roadmap. - We do not recommend updating to beta.1 yet for Ecotone as we’re still improving edge cases around the interaction between static files and op-node. OP Stack users should use alpha.21, until beta.2 is out. - OP Mainnet support is underway and expected before Reth 1.0. - **Full JSON-RPC Support** - Reth has [full JSON RPC support](https://github.com/paradigmxyz/reth/issues/3661), including the `debug_` namespace with Javascript tracers and the `trace_` namespace. See our [docs](https://paradigmxyz.github.io/reth/jsonrpc/intro.html). - We have been making incremental bug fixes here. Our top priority has been accuracy of the results, in particular around gas consumption in tracing. - **Database Breaking Changes** - We are entering V2 of our Database (`reth db version`), bringing exciting improvements, at the cost of breaking the format and requiring a resync. We do not expect more of these in the near future and we appreciate users’ patience. - We released [Static Files and ETL](https://github.com/paradigmxyz/reth/pull/6444) for better separation of mutable/immutable data and faster initial sync. - Initial sync time reduced by 4-5 hours, [getting close](https://github.com/paradigmxyz/reth/issues/6909) to the sub-48h mark. - Access speed to historical data increased by up to 2x-10x. - Disk usage for historical data reduced by up to 10%. - Ability to offload the historical static files to a separate read-only drive and serve it to multiple nodes. - We made database schema improvements: - Switch to [Roaring Bitmaps](https://github.com/paradigmxyz/reth/pull/5463) encoding for historical access indices resulted in almost 50% disk space reduction (10% of total database size) and improved querying speed. - Nicer database interface ([better table names](https://github.com/paradigmxyz/reth/pull/6787), [removal of redundant wrappers](https://github.com/paradigmxyz/reth/pull/6874)). - **Resource Usage Improvements** - We [reworked](https://github.com/paradigmxyz/reth/pull/6590) the networking interface, which has speeded up Reth's responsiveness to I/O, made it more DoS resistant, and improved the performance of the transaction pool when deleting blobs or evicting transactions. - We fixed a lot of resource leakages, such as a [memory leak](https://github.com/paradigmxyz/reth/pull/6898) in our Transaction Pool. - We addressed all our pain points around [MDBX’s freelist](https://github.com/paradigmxyz/reth/issues/5228) such as leaky and timing out long-running DB read-transactions that caused uncontrolled freelist growth. The freelist’s size also no longer affects the performance of write transactions, prioritizing the validator performance. # Performance Update We benchmark Reth (beta.1 & alpha.21), Geth (v1.14.0) and Nethermind (v1.25.4) nodes on [Latitude c3.large bare metal instances](https://www.latitude.sh/metal/pricing). We invite people to help us extend our benchmarks further to other node configurations and hardware. We are excited to share preliminary results below from our most recent benchmarking adventure. ## How much gas and transactions per second (tps) can Reth support? The MegaETH Labs team [profiled Reth alpha.13](https://x.com/ABCDELabs/status/1763121450553139290?s=20) (performance has improved since then) recently on large machines [^1], and they show an encouraging **>1-2K MGas/s (>10K TPS @ 100K gas/tx) result on historical sync in last 1M blocks (i.e. infrequent trie updates) and >100-200 MGas/s (>1K TPS) result on live sync**. For perspective, Ethereum mainnet does ~12.5 TPS, Polygon ~70 TPS, Solana ~700 TPS ([source](https://realtps.net/)). Find their full presentation from ETHDenver on this [here](https://docs.google.com/presentation/d/e/2PACX-1vRyPeKCILgLNuvaqpVW2TNcDbvOSvahFkAE5pdRaMZrWS91tp7qaryYYc8n0fjM5hfApx3-wqOCncC7/pub?start=false&loop=false&delayms=3000) for a complete picture. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--228ff8a9d8/40d592944dd542e6000a222e0660dd66/asset-https-cdn-sanity-io-images-dgybcd83--228ff8a9d8.png) We want to make it extremely clear that the historical sync numbers represent pure execution time during "backfills", not including senders recovery or merklization. While this is not representative of the load at tip, it is important for bootstrapping archive nodes quickly and for catching up to the chain between node restarts. The second diagram is produced by running the live sync logic on recent Ethereum blocks, doing senders recovery, execution and merklization. Interestingly enough, the Merkle Patricia Trie takes 80-90% of time. This means that there is still a lot of room for improvement on our performance at the tip due to the merklization overhead! It also poses an interesting question around how much we should tune Ethereum & other blockchains’ state commitments for performance. What will that overhead look like with Verkle Tries for example? We don’t know, but we are excited to find out. We acknowledge that Reth’s JSON RPC subscription latency for the block hash at the chain’s tip (`eth_subscribe` + `newHeads`) is still not state of the art. We are working on improving this in the next beta releases with [parallel/async storage root calculations](https://github.com/paradigmxyz/reth/pull/6903), as well as [faster chain head events](https://github.com/paradigmxyz/reth/issues/6286). ## How fast does it sync and how big is the database? The static files & ETL releases let us improve on both the sync time and the space required by the node. Since alpha.1, we also released support for [configurable pruning](https://paradigmxyz.github.io/reth/run/pruning.html), with the most common configuration across non-archival Ethereum nodes exposed behind the `--full` flag. This flag still stores all history (headers/transactions/receipts) but prunes any historical changesets and their corresponding indices. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--fabf791686/e2ed7111836f31724492478112c6aa7a/asset-https-cdn-sanity-io-images-dgybcd83--fabf791686.png) One notable improvement here is the reduction of the time to execute the `TransactionLookup` stage from multiple hours to 40 minutes, using the [ETL technique](https://github.com/ledgerwatch/erigon-lib/blob/main/etl/README.md) pioneered by Erigon, which minimizes write amplification. This is on bleeding edge NVMe drives, and we expect the performance improvement to be even higher in lower end hardware where `TransactionLookup` used to take >1 day. We intend to apply the same technique in other stages (e.g. [IndexStorage/AccountHistory](https://github.com/paradigmxyz/reth/issues/6909)) and expect similar improvements in the next beta releases. ## How fast is the RPC? We used [Cryo](https://twitter.com/notnotstorm/status/1677020205502074880), a high performance tool we built to ETL data out of blockchains, as a reference of what performance improvement a user of Reth would experience in their day-to-day. We benchmarked over localhost on various block ranges, illustrated in the tables below. First, we benchmarked the time required to extract blocks from a node, without their transactions (`eth_getBlock` with `full = false`). ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--dee0f301a2/870e86e4eab64fd62f332c2ba2e6f1c6/asset-https-cdn-sanity-io-images-dgybcd83--dee0f301a2.png) Then, we investigated the performance of also extracting the transactions (`eth_getBlock` with `full = true`) using both point receipt queries (`eth_getTransactionReceipt`) and batch queries (`eth_getBlockReceipts`). ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--6124ad2f97/76acbb6c60f93c485db40c28b3b75e27/asset-https-cdn-sanity-io-images-dgybcd83--6124ad2f97.png) We investigated long `eth_getLogs` range queries, as these are pertinent for all indexing use cases. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--840ca399f0/da33f45db33f041dccfd0f0a1e94c278/asset-https-cdn-sanity-io-images-dgybcd83--840ca399f0.png) Finally, we benchmarked the `debug_traceBlockByNumber` endpoint using the `preStateTracer` for the `code_reads` workload and the `callTracer` for the `geth_calls` workload: ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--8a98570cda/75d294a93baaef7cc23965ce2df33621/asset-https-cdn-sanity-io-images-dgybcd83--8a98570cda.png) At the time of the benchmark, Reth outperforms the tested clients in all RPC queries. We want to appropriately caveat that our benchmarks are representative of our experiments and may vary across hardware. We also expect other node implementations to continuously improve, so we want to be explicit about our numbers being a 'point in time' measurement. Benchmarking is hard, and we are working towards reproducible cross-client nightly benchmarks on CI. Please reach out if you'd like to work together on this. We contacted the Nethermind team regarding the tracing performance and we attributed it to their usage of the Javascript tracer instead of native implementations like in Reth and Geth. This is known and part of their backlog, and we will be updating our numbers when this is done. We did not provision Erigon nodes for this benchmark, we intend to do so in the coming weeks to stress test the performance of the `trace_` endpoints, but Erigon node operator feedback and preliminary benchmarks from a few alpha releases ago have been encouraging. The gains from the static files are remarkable in range queries, as static files were optimized for such access patterns, whereas our random access performance is ~unchanged due to usage of offset-based indices in the static files (the lacking support of which prevented us from using parquet here). We also want to give a big shoutout to the [Tokio team](https://tokio.rs/) for building a high performance and reliable substrate to build all our async infrastructure on, and is doing a lot of the heavy lifting here. We are encouraged by our performance, and are keen to keep benchmarking and uncover areas for further optimization in all Ethereum clients. # When production-ready? Reth has been undergoing rigorous battle-testing over the last months using our own security tooling, third parties running Reth in production, as well as being integrated in ecosystem tooling such as [Hive](https://github.com/ethereum/hive/tree/master/clients/reth), [goevmlab](https://github.com/holiman/goevmlab/issues/113), [Kurtosis](https://paradigmxyz.github.io/reth/run/private-testnet.html), and [assertoor](https://github.com/paradigmxyz/reth/pull/6833), among others. We are always interested in building more tools for testing and fuzzing (e.g. for networking), please reach out if you’re interested in collaborating. As a result, we actively recommend professional node operators to switch to Reth in production for performance and cost reasons in use cases where high performance with great margins is required such as Rollups, RPC, MEV, Indexing, Simulations, and P2P activities. While we are aware of parties running Reth staking nodes in production, we do not encourage usage in production staking environments by non-professionals yet, but are available to support without warranty or liability. We have contracted [Sigma Prime](https://sigmaprime.io/), the authors of [Lighthouse](https://github.com/sigp/lighthouse) (Rust Consensus Layer), to perform an audit on Reth’s critical components. We acknowledge it is hard to make security claims about Ethereum nodes, given the large surface area of the codebases. We also believe that expert reviews on the most important parts of the codebase such as the Engine API, Merkle Patricia Trie or the P2P Network are a requirement for convincing ourselves that our implementation of the Ethereum protocol is sound. The audit is underway. We also are collaborating with [Guido Vranken](https://github.com/guidovranken/), #1 on the Ethereum Bug Bounty [leaderboard](https://ethereum.org/en/bug-bounty/), on a community-driven audit of [Revm](https://github.com/bluealloy/revm/). Revm is the Rust EVM behind Reth and we view it as critical infrastructure for Ethereum. We are excited for this review to surface potential worst-case scenarios for Reth’s performance and stability, and hope that its results strengthen the entire ecosystem. The audit is underway, and there will be a separate announcement for this later in the year. **Once both audits are complete and we have addressed all the finds, we intend to release Reth 1.0 by the end of Q2, our first production-ready release which will be recommended for usage in staking operations.** Post 1.0 Reth releases will follow the [semver](https://semver.org/) convention. # What’s the future of Reth? On Layer 1, Reth is meant to contribute towards client diversity and help experiment with new technologies for the Ethereum protocol. We have executed on this so far with the Cancun upgrade, and are excited to continue this with the Prague/Electra hardfork – see [our view](https://www.paradigm.xyz/2024/01/ethereum-2024) on the EIPs considered for inclusion. But what we are most excited about is about Reth’s modularity and its proliferation in EVM-centric infrastructure. We are already seeing early signs of that with usage of Reth in the Paradigm portfolio as a way to provide faster, cheaper, more resilient services than what conventional libraries offer. We are thrilled to see Reth adoption on Layer 2s such as OP Stack, for example, companies are [already adopting Reth RPCs in production for Base](https://twitter.com/QuickNode/status/1742623573959987520). We are still early in our execution of our ambitious roadmap, and we cannot wait to share more about the future of Reth as an SDK. The L1/L2 nodes are just the first application. If this sounds exciting to you, please reach out to [georgios@paradigm.xyz](mailto:georgios@paradigm.xyz). We’re looking for the best engineers in the world to execute on this together. Until then, [see you on Github](https://github.com/paradigmxyz/reth/issues). [^1]: Intel® Xeon W5-2465X 16 core @ 3.1GHz, Samsung 512G DDR5-4800, Intel SSD D7-P5510 7.68 TB NVMe PCIe 4.0 ## https://www.paradigm.xyz/writing/everything-is-a-perp # Everything Is A Perp > Power perps are assets that target the power of an index price. It’s a fun rabbit hole to go down. The longer you think about power perps, the more you see how everything resembles a power perp. We’ve been [thinking](https://www.paradigm.xyz/2021/08/power-perpetuals/) [a](https://medium.com/opyn/squeeth-primer-a-guide-to-understanding-opyns-implementation-of-squeeth-a0f5e8b95684) [lot](https://colab.research.google.com/drive/1mrxubKiFUhlavol4a38NJYaANdSNAEun#scrollTo=OOaOjEWI0DQJ) [about](https://colab.research.google.com/drive/1HTM_2j0jmda9tzN_uskBPz9Rpma8Lp3C#scrollTo=rnaQgc7nWKSU) [power](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4317072) [perps](https://squeeth.com/). Power perps are assets that target the power of an index price, like index2 or index3. It’s a fun rabbit hole to go down. The longer you think about power perps, the more you see how *everything* resembles a power perp. Here we make three surprising claims: 1. Crypto-collateralized stablecoins (like [DAI](https://makerdao.com/en/whitepaper/) or [RAI](https://github.com/reflexer-labs/whitepapers/blob/master/English/rai-english.pdf)) are like 0-perps. 2. Margined futures (like [dYdX](https://docs.dydx.exchange/#general)) are 1-perps. 3. Constant product AMMs like [Uniswap](https://uniswap.org/faq) are a replicating portfolio for a 0.5-perp, and constant geometric-mean AMMs like [Balancer](https://balancer.fi/whitepaper.pdf) are replicating portfolios for power perps for any value between 0 and 1. This is cool because it reveals a surprisingly compact design space across three of the main primitives in DeFi. Let’s have a look at each one, but first we need a definition of perps and power perps. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--8db7f09150/c8f787ba45ad37697ca4614c0d4a44e9/asset-https-cdn-sanity-io-images-dgybcd83--8db7f09150.png) **Definition:** A *perpetual* is a contract that tracks and gives exposure to an index, and exchanges regular payments that are larger the further the traded price (mark) is away from the target price (index). (See [The Cartoon Guide to Perps](https://www.paradigm.xyz/2021/03/the-cartoon-guide-to-perps) for a more detailed explanation.) Graphically, the funding payment varies with the area between the mark and index price over a funding period (see figure). If the mark price is above the index, longs pay shorts. If the mark price is below the index, shorts pay longs. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--b6a3535b9f/56a9e9cbae2963db79a7b0a6dfe2c771/asset-https-cdn-sanity-io-images-dgybcd83--b6a3535b9f.png) There are various mechanisms to transfer funding payments (e.g., cash or in-kind payments, periodic or continuous funding, automatic or by governance, etc.), and various mechanisms to set interest rates based on prices (including proportional mechanisms like used by Squeeth and the more complex PID controller used by Reflexer). All mechanisms implement the idea that longs should pay shorts when mark is higher than index, and vice versa. **Definition:** A [*power perpetual*](https://www.paradigm.xyz/2021/08/power-perpetuals) is a perpetual with index price^p for some power p. To create a short position in a power perpetual contract, lock some collateral in a vault and mint (i.e. borrow) some power perpetual. Sell this minted power perpetual to go short. To go long, buy from whoever owns some. The mechanics are driven by the required ratio of collateral to debt: *Collateral ratio = Equity/Debt = ((collateral quantity) \* (collateral price)) / ((perpetual quantity) \* (index asset price)^p )* This ratio must be kept safely above one so there is enough collateral to cover the debt, otherwise the contract liquidates the collateral by buying enough perps to close the position. # A design space for power perpetuals A design space for power perpetuals involves the power *p*, the minimum collateral ratio *c>1*, and three asset choices: - *Collateral asset*: e.g., USD - *Index asset* (the asset whose value is being tokenized): e.g., ETH - *Numeraire asset*(the unit in which we measure the value): usually USD Now to our three claims. ## Claim 1: Stablecoins are 0-perps A stablecoin is a loan of a minted token against reliably priced collateral. The following configuration gives a USD stablecoin: - *Collateral asset*: ETH - *Index asset*: ETH - *Numeraire asset*: USD - *Collateral ratio*: 1.5 - *Power*: 0 This means that we are posting ETH collateral and minting a stablecoin token. The index is the price of ETH raised to the zeroth power, which is just one as ETH^0 = 1. If I deposit 1 ETH as collateral, and ETH is trading at 3000, I can mint up to 2000 tokens. This gives 1.5x collateral: *Collateral ratio = Equity/Debt = ((collateral quantity) \* (collateral price)) / ((perpetual quantity) \* (index asset price)^p )= 1 \* 3000/ (2000 \* 1) = 1.5* Funding is the prevailing traded price of the stablecoin in USD (mark) minus the target index price^0. *Funding = Mark - Index = Mark - price^0 = Mark - 1* The funding mechanism gives good incentives for the stablecoin to trade close to $1. If it trades materially above $1 it will be profitable to sell any stablecoin you hold, then mint and sell even more, and receive funding. If it is below $1, it pays to buy the stablecoin to earn a positive interest rate and potentially sell it at a higher price in the future. Not all stablecoins in the wild use this exact (mark - index) funding mechanism, but all collateralized stablecoins share this basic structure, minting stablecoins as a loan against good collateral. Even stablecoins with governance-set interest rates will set these at something like mark - 1 to keep their peg to $1. ## Claim 2: Margined futures are 1-perps If we modify the stablecoin in the previous section to have a power of 1, and change the collateral to USD, we get a tokenized ETH asset: - *Collateral asset*: USD - *Index asset*: ETH - *Numeraire asset*: USD - *Collateral ratio*: 1.5 - *Power*: 1 I put down 4500 in USD collateral with ETH trading at 3000 and mint one stableETH token. *Collateral ratio = Equity/Debt = ((collateral quantity) \* (collateral price)) / ((perpetual quantity) \* (index asset price)p ) = 4500 \*1 / (1 \* 30001) = 1.5* Funding for this perp is the traded price of the perp in USD (the mark price) minus the target index price^1. *Funding = Mark - Index = Mark - price^1 = Mark - ETH/USD price* The funding mechanism gives good incentives for the perp to trade close to the ETH price. If the price is substantially higher, funding will encourage arbitrageurs to buy the asset and short the perpetual. If it is substantially lower, it will encourage them to short sell the asset and buy the perpetual. There is a precise replication argument for what Mark should be based on expiring instruments that offer exposure to ETH prices (see the [paper on Everlasting Options](https://www.paradigm.xyz/static/everlasting_options.pdf)). I can sell this stableETH asset to go short the price of ETH, backed by USD collateral. ### Going from tokenized short asset to margined short perpetual The stableETH asset we have constructed is not very capital efficient. We put up $4500 in collateral to get short $3000 (or 1 ETH) worth of exposure to ETH. We can make it more capital efficient by selling the token for a USD stablecoin and then using this as collateral to mint more of the perpetual. If the minimum collateral ratio is 1.5 and ETH is 3000 we have the following sequence: - Deposit $4500 and mint 1 stableETH - Sell stableETH for $3000, deposit proceeds, and mint 1/1.5 = 0.666 stableETH - Sell stableETH for $2000, deposit proceeds, and mint (1/1.5)^2 = 0.444 stableETH - Sell stableETH for = $1333.33, deposit proceeds, and mint (1/1.5)^3 = 0.296 stableETH - etc[2](https://www.paradigm.xyz/2024/03/everything-is-a-perp#user-content-fn-2) Summing up the transactions, we end up minting and selling 3 stableETH. This is $9000 of short ETH exposure from $4500 collateral. This position is equivalent to opening a 2x leveraged short ETH/USD perp. If we have access to flash swaps or flash loans, this process is simplified. We can flash swap 3 stableEth for USD and use the proceeds as collateral to mint the stableETH to repay. If the collateral requirement was 110% we could have made a 10x position. ### Going long instead of short To go long, buy this stableETH in exchange for USD. To leverage long, borrow more USD using the stableETH collateral and use that borrowed USD to buy more stableETH, then borrow more USD and repeat the process up to 2x ETH. If flash swaps or flash loans are available, this can be done in a single transaction. All of this means that overcollateralized perpetuals backed by more than 100% collateral can be converted into undercollateralized perp futures like those traded on dYdX. ## Claim 3: Uniswap and other constant product CFMMs are (almost) a 0.5 perp A liquidity position in a Uniswap pool has a value proportional to the square root of the relative price of the two assets. For a full range LP in the ETH/USD pool the value of the LP is *V = 2 \* (k \* (eth price))^0.5* Where *k* is the product of the amount of the two tokens. The pool generates some amount of trading fees per period. Now consider the perp: - Collateral asset: USD - Index asset: ETH - Numeraire asset: USD - Collateral ratio: 1.2 - Power: 0.5 This perp will track the value of price^0.5, mirroring the payoff of the AMM. A portfolio short units of the perpetual and the LP will receive the difference between the perp funding and the AMM fees. Since this trade offsets the price risk, the 0.5 perp should trade below by exactly: *Expected Uniswap fees = Index - Mark* The extension to Uniswap v3 is [straightforward](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3898384) and left to the reader ;) This gives us a nice result that the equilibrium Uniswap fee[3](https://www.paradigm.xyz/2024/03/everything-is-a-perp#user-content-fn-3) should be the funding rate for a 0.5 perpetual. In the simplified case with zero rates this is *Equilibrium uniswap return = σ²/8* Where *σ²* is the variance of the price returns of one pool asset against the other. We also get this result purely from a Uniswap perspective (see appendix C [here](https://arxiv.org/pdf/1911.03380.pdf) for a more direct construction). We also go into detail from a power perp perspective [here](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4317072). ```text ,Collateral,Index,Numeraire,Power USD stablecoin,ETH,ETH,USD,0 Overcollateralized future,USD,ETH,USD,1 Synthetic uniswap,USD,ETH,USD,0.5 Squeeth,ETH,ETH,USD,2 ``` ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--a5fa5dc026/02c348810bb3b6eaf54c5bc169b3860b/asset-https-cdn-sanity-io-images-dgybcd83--a5fa5dc026.png) # Power perps all the way down So stablecoins (and collateralized loans more broadly), margined perpetual futures, and AMMs are all a type of power perpetual. ## What’s missing? Higher order power perpetuals — starting with quadratic power perpetuals. [Squeeth, the first quadratic power perpetual,](https://squeeth.opyn.co/) provides pure exposure to the quadratic component of price risk. We can get a good approximation of many payoffs by combining higher order power perpetuals and 1-perps (futures) with 0-perps as collateral. If we need to be more precise, we can use a portfolio of power perps with [whole number powers](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4317072) in the weights of a Taylor series to approximate any function: sin(x), ex2, log(x) – whatever you like. ## What’s next? A world that allows power perpetuals, collateral assets, and Uniswap LPs to play nicely together might be really fun. ## https://www.paradigm.xyz/writing/joining-paradigm-ciamac-moallemi # Joining Paradigm as Research Advisor > I'm excited to announce that I've joined Paradigm as a Research Advisor. I am excited to be working with Dan Robinson, Matt Huang, and the rest of the Paradigm investing I'm excited to announce that I've joined Paradigm as a Research Advisor. I am excited to be working with Dan Robinson, Matt Huang, and the rest of the Paradigm investing and research teams to advise the next generation of crypto startups. I'll be focusing on applied research in mechanism and market design, with a particular focus on decentralized finance. My academic background and training is as an engineer and applied mathematician, working in the area of dynamic programming and stochastic control -- problems where decisions are made sequentially, over time. As a [professor at Columbia Business School](https://moallemi.com/ciamac) since 2007, where I am the director of the [Briger Family Digital Finance Lab](https://business.columbia.edu/dfi/labs/briger-family-digital-finance-lab), the primary applications I've thought about are in quantitative finance. This has dovetailed with my experience as a quantitative trader, from trading bonds and interest rate derivatives as a partner in a hedge fund while an MIT undergrad, to more recently developing stat arb strategies for trading stocks. My journey into crypto started in 2016, when I started thinking about the novel economics of the Bitcoin transaction fee mechanism. This resulted in [one of the first economic analyses](https://academic.oup.com/restud/article/88/6/3011/6169547) of Bitcoin, which highlighted both its benefits -- freedom from the monopoly pricing of traditional payment systems -- and its flaws -- the necessity of significant congestion in order to generate transaction fee revenue. Since DeFi summer, I have become interested in understanding the mechanisms for decentralized trading, in particular automated market makers such as Uniswap. With my collaborators, we identified and quantified the main mechanism of adverse selection for AMM liquidity providers, [loss-versus-rebalancing](https://moallemi.com/ciamac/papers/lvr-2022.pdf) (LVR), which captures how much AMM LPs lose to DEX-CEX arbitrage, and [determined](https://moallemi.com/ciamac/papers/lvr-fee-model-2023.pdf) how it is affected by fees, block time, and volatility. The LVR paper has captured the attention of practitioners to become an important paradigm for AMM design, and many protocols have been proposed to mitigate the losses from LVR. Beyond AMMs, I am excited about the potential for blockchains to enable incredible innovation in market structure, as compared to TradFi markets such as the US equity market, which fundamentally has the same structure now as it did 20 years ago. The world of blockchain and smart contracts, on the other hand, with its culture of rapid experimentation and open-source R&D, [has spurred tremendous innovation in market mechanisms](https://moallemi.com/ciamac/papers/lob-amm-fba-2023.pdf). For me, Paradigm is the ideal place to help contribute to this revolution. As a research-driven investing firm, they blend a principled, inventive culture with a practical focus on useful applications, have attracted some of the best engineering talent in the space, and work closely with innovative founders working on the research frontier. Paradigm and their portfolio companies have been at the forefront of some of the biggest innovations in crypto and DeFi to date. I am excited to work alongside them to help solve the most challenging problems in the industry. ## https://www.paradigm.xyz/writing/how-to-raise-the-gas-limit-1 # How to Raise the Gas Limit, Part 1: State Growth > The goal of this blogpost series is to develop a scientific approach for understanding and enacting Ethereum's scaling roadmap. State growth and its relationship to Ethereum’s gas limit are widely misunderstood. It is commonly believed that state growth is Ethereum’s primary scaling bottleneck. However, discussions of state growth are often held back by imprecise terminology and a lack of detailed quantitative evidence. Embracing a data-driven approach brings significant clarity to the state growth issue. In this article we leverage high-resolution datasets to understand the size and shape of state growth. In doing so, we reach the surprising conclusion that **modern consumer hardware can sustain current rates of state growth for at least a decade. Furthermore, this runway is likely to be extended indefinitely by upcoming improvements to software and hardware.** We believe that Ethereum has a clear roadmap toward 1) complete elimination of state growth as a scaling bottleneck and 2) raising the gas limit to a level that supports a global-scale decentralized financial system. The goal of this blogpost series is to develop a scientific approach for understanding and enacting this scaling roadmap. *This article is part 1 in a blogpost series about Ethereum scaling. Part 1 is about state growth, part 2 is about history growth, part 3 is about state access, and part 4 is about the gas limit.* # What is state growth? The term “state growth” is commonly used as a catch-all for any Ethereum scaling bottleneck where data size exceeds the capacity of Ethereum node hardware. However, state growth should not be thought of in this monolithic way. There are multiple types of Ethereum data, each with its own relationship to a node’s underlying hardware components. **It is thus crucial to use precise terminology that disentangles each distinct scaling bottleneck.** **State** is the set of data necessary for building and validating new Ethereum blocks. State is composed of contract bytecode, contract storage, account balances, and account nonces. **History** is the set of data necessary for syncing a node from Genesis to the latest block. History is composed of blocks and transactions. State and history are non-overlapping datasets. From these definitions there are at least 3 distinct phenomena that put significant stress on a node’s hardware: 1. **State growth**: the accumulation of new accounts, new contract bytecode, and new contract storage. 2. **History growth**: the accumulation of new blocks and new transactions. 3. **State access**: the set of read and write operations used for building and validating blocks. Each of these bottlenecks has a unique relationship to a node’s hardware constraints. The four most relevant [^1] hardware constraints are: 1. **Network IO** is the amount of upload and download speed that a node must maintain in order to reach stable consensus with peers. 2. **Storage size** is the amount of data that a node must keep in permanent storage in order to build, validate, and distribute blocks. 3. **Memory size** is the amount of data that a node must cache in memory in order to stay synchronized with the tip of the chain. 4. **Storage IO** is the amount of read and write operations per second that a node must perform in order to stay synchronized with the tip of the chain. The relationships between these bottlenecks and hardware constraints is illustrated in **Figure 1**. ![Figure 1: Ethereum Scaling Bottlenecks](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--ca2d8c8254/433732bb9ffc337b960f78329e78779e/asset-https-cdn-sanity-io-images-dgybcd83--ca2d8c8254.png) Figure 1: Ethereum Scaling Bottlenecks Starting at the top of the diagram, every time Ethereum executes a transaction, all resources used by that transaction are priced in terms of **gas**. Ethereum’s **gas limit** is thus a single-dimensional quantity that rate-limits all forms of on chain activity [^2]. Downstream of the gas limit are **block size** and **operations per block**. The more bytes per block, the faster history will grow. The more IO operations per block, the greater the rate of state access and (usually) the greater rate of state growth. Thus, the scaling bottlenecks are connected to the node’s hardware constraints as follows [^3]: - To support large amounts of *state growth*, a node must have sufficient storage size and memory size. If the state grows too large, it will either not fit in storage, or the frequently-accessed portion of state will not fit in memory, degrading performance. - To support large amounts of *history growth*, a node must have sufficient network bandwidth to share large amounts of block data and enough storage capacity to store that data. - To support large amounts of *state access*, a node must have large amounts of memory to cache hot state and large amounts of storage IO to support sufficient read and write operations. For state growth in particular, the main challenge is ensuring that state size does not grow at a faster rate than can be sustained by ongoing improvements to consumer hardware. Node memory and storage are finite resources, and so they will eventually reach capacity unless either the state stops growing or hardware is periodically upgraded. It is fortunate that memory and storage hardware have been [improving for many years](https://ourworldindata.org/grapher/historical-cost-of-computer-memory-and-storage). Even so, the exact forecast of these improvements is not certain, and it should not be taken as a given that their rapid growth will continue indefinitely. Note that data blobs introduced by the upcoming [EIP-4844](https://www.eip4844.com/) will bring some changes to these scaling relationships. After EIP-4844, it is expected that much less history will accumulate on disk, network IO might increase significantly for transmitting large amounts of blob data. In this article we will focus mainly on the state size and state growth rate rather than memory size and state access patterns. We will investigate these or other topics in future work. # What are the largest contributors to Ethereum state? The next step in understanding state growth is examining the total size of state along with the relative size of each state contribution. Currently, Ethereum state takes up about 245.5 GiB on disk. These numbers were measured using a reth node, but the numbers for each node client are roughly comparable as shown in this [comparison spreadsheet](https://docs.google.com/spreadsheets/d/1NxyLBqPX6JVMqGqb-kVcWCN0bm8eXmxZmvrKqAS6Xw4/edit#gid=0). Accounts, contract bytecodes, and contract storage occupy 14.1%, 4.3% and 81.7% of state respectively. **Figure 2** shows how much state is occupied by various categories of smart contract protocols. In this visualization, the size of each contract category represents the number of bytes occupied by its storage slots and bytecodes. Contract categories are hierarchical and can be navigated using mouse clicks. A category is also included to represent the total amount of state taken up by account balances and nonces. *Figure 2: Distribution of Ethereum State (click it)* The numbers in **Figure 2** represent the total bytes that a node client must store on disk. This includes data used by indexes and other types of storage overhead. Numbers were taken from a reth node, but values are roughly comparable across clients. The average size to store each account and each storage slot were 133.6 bytes and 191.3 bytes respectively. There are many interesting patterns within **Figure 2**, but here are some of the most important takeaways: - *Tokens are the biggest contributor to state.* The largest contributors to Ethereum state are ERC-20 and ERC-721 tokens, occupying 27.2% and 21.6% of state respectively. The reason why tokens take up so much state is that each user balance of each token must be separately stored in its own 32 byte storage slot. **Thus, this half of Ethereum’s state scales with the total number of Ethereum users and the total number of tokens held by each user.** - *At least 7.4% of Ethereum’s state is dormant.* Some of the largest contracts in Ethereum’s state are no longer actively used. These protocols are from a time when blockspace and state space was much cheaper than it is today. This includes most of the protocols in the Game, Gambling, and Scam/Scheme categories. There are also many DEX’s that are no longer actively used, including IDEX, Etherdelta, and Oasis. Collectively these protocols compose at least 7.4% of Ethereum state. The true level of dormancy is higher, as it would also include many entries from the longtail of ERC-20, ERC-721, and Other categories. - *L2 bridges occupy less than 2% of Ethereum state.* By utilizing techniques like compression, ZK proofs, and improved encodings, L2 transactions make much more efficient use of state than mainnet. **L2’s collectively achieve ~5x more transactions per second than** [**mainnet**](https://l2beat.com/scaling/activity)**, despite occupying only 2% of mainnet state (and 10% of state growth, see next section).** # How fast is Ethereum state growing? The most important aspect of state growth is the evolution of state growth rates over time. These rates reveal the severity of the problem and whether the severity is trending upward or downward. **Figure 3** shows state growth rates since Ethereum’s inception in 2015. These rates are computed by summing the contract bytecodes and contract storage within each contract category. Subsets of these categories can be visualized by clicking and double clicking items in the figure legend. ![Embed](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--84c9a50b56/3952ab0d2b19b70f832362d41902829f/asset-https-cdn-sanity-io-images-dgybcd83--84c9a50b56.png) ![Figure 3: Ethereum state growth over time](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--1ac71ce3f3/39cb725c094eb10dc5749f5ea9e8d89f/asset-https-cdn-sanity-io-images-dgybcd83--1ac71ce3f3.png) There are many interesting patterns within **Figure 3**, but here are some of the most important takeaways: - *State currently grows around 2.62 GiB per month, down from a peak of 5.99 GiB per month.* By linear extrapolation, these numbers project the total state size to be between 396 GiB and 606 GiB in 5 years. Although one might describe the current growth rate as 12.8% per year, the absolute growth rate has been declining while the state continues to grow, so simple exponential growth may not be an appropriate model. - *Recent declines in state growth are mainly due to reduction in NFT activity.* (Hint: double click the “erc721” label on the figure legend to view this data in isolation). Although one might expect some degree of correlation between different types of network activity, there is a surprising amount of independence between individual state contributors. For example, the ERC-20 state growth rate has actually been increasing each year since 2020, despite the total state growth rate declining over the past couple years. - *State growth is the lowest it’s been since 2021.* This decline is rather surprising, but it makes sense given state is mostly proportional to the formation of new token balances. If state growth rates have been declining, some might suggest that this indicates that Ethereum is capable of supporting a higher gas limit. This may be true, but it is important to remember that 1) there’s nothing preventing a new surge in growth rate under the current gas pricing model, and 2) state is not the only type of bottleneck downstream of the gas limit. # How much state growth is acceptable? We now know the Ethereum state’s 1) size, 2) composition, and 3) growth rate. How do we determine the range of acceptable state growth values? This question is complicated because it depends on both unpredictable market forces and philosophical choices about which tradeoffs Ethereum should make. Let’s start with the simplest possible model of how long the current levels of state growth are sustainable on common consumer hardware, assuming no future hardware improvements. As shown in **Figure 3**, in recent years the state has been growing at an annualized rate somewhere between 31GiB/year to 72GiB/year. Common consumer hardware currently tops out around [4TiB](https://pcpartpicker.com/products/internal-hard-drive/#t=0&A=4000000000000,24000000000000&sort=-rating) of storage and around [64GiB](https://pcpartpicker.com/products/memory/#Z=65536001,65536002,65536004,65536008) of memory. From this we can create a simple forecast of storage and memory requirements: - **Storage**: Nodes must currently store a total of around 1TiB (due to storing both state and history). In practice this means that many nodes are using disks of size at least 2TiB. For simplicity, let us ignore future history growth, as if we were in a post-EIP-4444 world. We can compute the amount of runway as runway = (remaining storage capacity) / (state growth rate), as shown in more detail in [this spreadsheet](https://docs.google.com/spreadsheets/d/1_yuDpeOqdoDCh7i2Ik3axWJ6CT0SlXNrc1OBi2e1T98/edit#gid=0). *Thus, node storage hardware can support current rates of state growth for well over a decade without exhausting 2TiB of space. A 4TiB drive would suffice for almost half a century at current levels of state growth.* - **Memory**: Ethereum-on-arm users [report](https://discord.com/channels/822548812472123404/822548813054476350/1205402848943280139) that the minimum viable memory size for running an Ethereum node is currently around 16GiB. If we assume that memory requirements grow proportionately with state size (and this is a big assumption), then the 30GiB/year to 72GiB/year state growth rates translate into 2GiB - 4.7GiB additional memory needed per year. *Thus, at current gas rates 32GiB RAM should be sufficient for anywhere from 3 years to 8 years. 64GiB of RAM should be sufficient for 10 years to 23 years.* This is a simplified model with many assumptions. Possible extensions to this model include 1) history growth, 2) nonlinear scaling of memory requirements, 3) decreasing hardware costs, 4) increases to gas limit, 5) opcode gas repricing, and 6) future Ethereum architecture improvements. Each of these factors can interact nonlinearly and evolve over time. We will explore these model extensions in future work. **It must be emphasized that long-term sustainability is a good thing. Even if modern hardware can support many years of runway, shortening this runway should never be taken lightly. Any plan that accelerates state growth should include a significant buffer for unforeseen changes to the hardware or software landscape.** # How can state growth be solved? Many different solutions have been proposed for addressing state growth. Three improvements to Ethereum architecture stand out: **rollups**, **Verkle tries**, and **state expiry**. Taken together, these form a comprehensive roadmap for solving state growth in the short, medium, and long term. ***Short term****: Rollups do not solve state growth, but they do ease the burden.* As shown in **Figure 2** and **Figure 3**, rollups are able to use state more efficiently than mainnet. Offloading activity to L2’s does require some amount of state to be stored on mainnet in order to support user exits. However, the state footprint of L2 transactions is much lower than the footprint of transactions on mainnet. Rollups thus make it more sustainable to increase total activity in the ecosystem. The adoption of rollups is expected to grow with the upcoming EIP-4844, which will make rollups much cheaper through use of blobs. ***Medium term****: Verkle tries solve state growth for validator nodes, but not for nodes that need to build new transactions*: Verkle tries are a new data structure for Ethereum state. They enable more efficient light clients and “stateless” nodes. These nodes will be able to validate new blocks without any knowledge of existing state values. This eliminates the state growth problem for validator nodes. The building of new transactions will still require storing and accessing state, but this would still be a more sustainable situation than we have today, because transaction construction is a task that can be easily distributed across many machines. In terms of scope, Verkle tries represent a significant engineering effort that could take years to implement. ***Long term:*** *State expiry solves state growth for all nodes, but requires additional infrastructure*. State expiry allows nodes to discard inactive portions of the state, such as the dormant state shown in **Figure 2**. Note that the term “state hibernation” might be a more appropriate name, as most existing proposals allow for recovering “expired” state via proofs. With regard to concerns around expired state being lost over time, as long as the history (block and transaction data) is available then the state can be reconstructed. Thus, whatever solution is developed for the history preservation problem of EIP-4444 will also solve the state preservation problem. It is possible that state expiry might be unnecessary in a world where Verkle Tries succeed at their goals. These are not the only solutions proposed to address state growth. Others include state rent and sharding, but historically these have had concerns around UX or soundness. A combination of these solutions and others may be necessary for reaching an endgame solution in the more distant future. # Closing Although state growth is a key challenge for scaling Ethereum, we believe it is a solvable problem using known technical solutions. By our reading of the data, Ethereum can sustain current levels of state growth for many years, with a comfortable buffer for experimenting with architectural upgrades. We believe that empirical methods will be essential for engineering Ethereum’s gas limit and steering Ethereum toward endgame scaling solutions. This article is only a single step toward that goal. There are other types of data beyond state, each imposing their own scaling burdens on an Ethereum node and on the Ethereum gas limit. We hope to explore these other bottlenecks in future work. If you are excited about research in Ethereum scaling, reach out to [storm@paradigm.xyz](mailto:storm@paradigm.xyz) and [georgios@paradigm.xyz](mailto:georgios@paradigm.xyz). We’d love to hear about how you are thinking about the problem and potentially collaborate. The data and code used for this article can be found on Github [here](https://github.com/paradigmxyz/how-to-raise-the-gas-limit). # Further Reading - [Ethereum Data Structures](https://arxiv.org/pdf/2108.05513/1000.pdf) - [State size management](https://hackmd.io/@vbuterin/state_size_management) - [Statelessness and state expiry roadmap](https://notes.ethereum.org/@vbuterin/verkle_and_state_expiry_proposal) - [Why it's so important to go stateless](https://dankradfeist.de/ethereum/2021/02/14/why-stateless.html) - [Verkle Trie EIP](https://notes.ethereum.org/@vbuterin/verkle_tree_eip) - [Ethereum In Numbers](https://www.youtube.com/watch?v=Cmuz_Xn_YJw) - [The Limits to Blockchain Scalability](https://vitalik.eth.limo/general/2021/05/23/scaling.html) - [Verkle Trees for Statelessness with Guillaume Ballet](https://www.youtube.com/watch?v=uGNmG3ZpWlU) # Acknowledgments Thank you to [Tim Beiko](https://warpcast.com/tim), [Péter Szilágyi](https://twitter.com/peter_szilagyi), [Guillaume Ballet](https://twitter.com/gballet), [Banteg](https://warpcast.com/banteg), [Alex Stokes](https://twitter.com/ralexstokes), [Jesse Pollak](https://warpcast.com/jessepollak), [Toni Wahrstaetter](https://twitter.com/nero_eth), [Patrick O’Grady](https://twitter.com/_patrickogrady), [lightclient](https://twitter.com/lightclients), [Ansgar Dietrichs](https://warpcast.com/ansgar.eth), [Frankie](https://warpcast.com/frankieislost), [Dan Robinson](https://warpcast.com/danrobinson), [Matt Huang](https://warpcast.com/matthuang), [Doug Feagin](https://twitter.com/dougfeagin), and [Arjun Balaji](https://warpcast.com/arjun) for review and feedback. Thank you to [Achal Srinivasan](https://twitter.com/achalvs) for the **Figure 1** graphics. [^1]: There are additional hardware bottlenecks such as CPU. Here we focus on the four bottlenecks most relevant to Ethereum mainnet, but other hardware bottlenecks might become relevant in other contexts. [^2]: EIP-4844 will introduce a separate blob gas limit dimension for controlling the rate of Ethereum blob activity. [^3]: Note that Figure 1 only shows the primary relationships between these bottlenecks. There are secondary bottlenecks that are sometimes relevant. For example, when performing a snap sync rather than a full sync, there is a strong relationship between snap sync time, state growth, and network I/O ## https://www.paradigm.xyz/writing/amicus-brief-kraken # Paradigm Files Amicus Brief in SEC v. Kraken > Paradigm filed an amicus brief in SEC vs. Kraken that supplements the arguments made by Kraken and explains, once again, why the SEC's approach is unsupported by case law and is an unlawful attempt to grant itself new and unpermitted regulatory authority. Today, Paradigm filed an [amicus brief](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-93fb462644/af23de1dfe4089b8cdca3533ce090456/asset-https-cdn-sanity-io-files-dgybcd83-p-93fb462644.pdf) in SEC v. Kraken, the latest in the litany of SEC “regulation by enforcement” actions taken by the Commission on major U.S. crypto exchanges. As we have said on [numerous](https://paradigm.xyz/writing//2024/03/amicus-brief-coinbase ) [other](https://paradigm.xyz/writing/2023/09/paradigm-files-amicus-brief-in-sec-s-case-against-binance ) [occasions](https://paradigm.xyz/writing/2023/07/paradigm-files-amicus-brief-in-sec-vs-bittrex ), the SEC’s approach here is wrongheaded and contrary to clear legal precedent. The SEC cannot simply will that all tokens are securities simply because it wants them to be. The SEC’s legal analysis on why these tokens are securities is lacking, and this case will not absolve the SEC or the rest of the government from the need to craft a workable, comprehensive regulatory framework for crypto. What is needed more than ever is comprehensive legislation that covers all aspects of digital assets and lets this industry grow here in the U.S. The Kraken action is a distraction from that important goal. ## https://www.paradigm.xyz/writing/leaderless-auctions # Leaderless Auctions > Leaderless Auctions are decentralized auctions with no auctioneer. They address the “last look” problem that can emerge when one participant is allowed to act after all others. # Leaderless Auctions Leaderless Auctions are decentralized auctions with no auctioneer. They address the “last look” problem that can emerge when one participant is allowed to act after all others. In a leaderless auction, all participants must commit to their bids at the same time. Any violation of this commitment leads to an attributable fault. Bids are threshold encrypted to avoid information leakage. Auctions can be finalized by submitting the results to a blockchain, where they can be efficiently verified via signature aggregation. For the purposes of this paper, we will use Ethereum. The protocol, similarly to Byzantine-fault-tolerant consensus protocols, assumes a predetermined participant set of which more than two thirds are honest. It also requires that participants can reliably get messages to one another within a fixed period of time (say, two seconds). If this latter assumption is violated, for example by a network partition, some honest parties may receive a fault. However, assuming such violations are rare, we can design fault penalties so that the impact of this issue is minimal. There are several issues this design does not address. In particular, participants can still submit their bids later than others to the extent that they have lower latency. Additionally, in this version of the protocol, bids from the public are unencrypted for simplicity. This means a dishonest auction participant has a last look relative to members of the public who trust them. ## Motivation Auctions are everywhere in crypto. Timing games, last looks, and short-term censorship are starting to show up, and this protocol is an attempt to resist at least some of them. We’re exploring how this could be incorporated into Angstrom’s top-of-block and batch auction, which uses a separate consensus mechanism for MEV protection by executing orders at a common price. Variants of this auction may be applicable in other settings, such as: - Enshrining a PBS auction in an L1 like Ethereum, as [proposed](https://ethresear.ch/t/why-enshrine-proposer-builder-separation-a-viable-path-to-epbs/15710) by Mike Neuder and Justin Drake - Enforcing fairness of an orderflow auction like [UniswapX](https://uniswap.org/whitepaper-uniswapx.pdf) or [MEV-share](https://docs.flashbots.net/flashbots-protect/mev-share) - Hardening an onchain batch auction, like the one [discussed](https://dydx.exchange/blog/architecture-to-mitigate-mev) by dYdX - Decentralizing the sequencer for an L2 like [Optimism](https://docs.optimism.io/stack/protocol/overview) ## Prior Work There has been much excellent recent work on crypto auctions. See, for example: - [Censorship Resistance in On-Chain Auctions](https://arxiv.org/pdf/2301.13321.pdf) (2023) by Elijah Fox, Mallesh M. Pai, and Max Resnick - [Credible, Optimal Auctions via Blockchains](https://arxiv.org/abs/2301.12532) (2023) by Tarun Chitra, Matheus V. X. Ferreira and Kshitij Kulkarni - [A New Architecture to Mitigate MEV](https://dydx.exchange/blog/architecture-to-mitigate-mev) (2023) by dYdX - [Multiplicity](https://blog.duality.xyz/introducing-multiplicity/) (2023) by Duality - [Cicada](https://eprint.iacr.org/2023/1473) (2024) by Noemi Glaeser, István András Seres, Eötvös Loránd, Michael Zhu, and Joseph Bonneau While much of this work addresses the problem of *censorship*—the ability of a leader to exclude others’ transactions or bids—we are not aware of any work that directly addresses the problem of the *last look*—the ability of the proposer to insert or cancel their own bid a significant amount of time later than any other participant. ## Problem ### Context Zed wants to auction off one ETH every twelve seconds. He sets up a committee of his friends, Alice, Bob, Charlie, and Dan to run the auction. Each of these *participants* will collect bids from the public, and then, together, they will decide on the highest bid any of them has seen. Zed trusts the group as a whole, but thinks at most one of them might be dishonest. ### First Attempts One possibility would be to use a single-block auction in a decentralized consensus protocol like Tendermint. Each participant would collect bids from the public and submit the highest one for inclusion in the block. However, Tendermint features a block proposer who has total control over the contents of the block. This means a dishonest proposer could simply censor everyone else’s bids and win the auction with a bid of 0. To address this issue, we could change the duration of each auction from one block to two. Two different proposers would then propose a block containing the highest bid they had seen, one after the other. The overall winner of the auction would be the high bidder across those two blocks. Because at most one proposer is dishonest, at least one of those blocks would contain an honest bid. This is a big improvement! ### The Last Look Problem However, imagine that the dishonest proposer, say, Bob, is the one who gets to propose the second block. The first proposer, Alice, submits a bid of $10,000 for the Ether in her first block. Bob now has a few seconds to decide what he wants to do. He checks the price of Ether and sees it has just spiked to $11,000. He places a bid of his own for $10,001 and wins the auction, netting $999 in profit. As a dishonest participant, Bob is going to do this whenever it’s profitable – that is, any time the price of Ether is greater than the current winning bid in Alice’s block. That means anyone sending their bids to Alice will only get them filled if the current price of Ether is less than or equal to their bid price – in other words, if the trade is unprofitable for them. Even if Bob wasn’t able to see other bidders’ bids, he still would have an informational advantage thanks to his ability to submit his bid a few seconds after anyone else. If they are rational and know what is going on, bidders other than Bob will stop bidding when he is the second proposer. On the margin this will depress bids overall and result in less money for Zed. This is known as the “last look” problem, and it’s a form of MEV. Because it’s quite similar to other currently tolerated forms of MEV, even “honest” participants like Alice, Charlie, and Dan might be tempted enough to engage in it as well, putting Zed and any honest bidders remaining at a disadvantage. We’d like to prevent this from happening. ## Solution ### Problem Summary This protocol is addressed specifically at solving the last look problem in decentralized auctions – the situation where one participant gets to place or cancel their bid meaningfully later than others at no cost to themselves, giving them an unfair advantage. In particular, we want to ensure that all bids were submitted by a given wall-clock time (say, 12:00 PM) regardless of who submitted them. Most blockchain consensus protocols feature a *leader* or *proposer* who suggests a block for other participants to agree on. Because all other participants must send their bids to the leader in time for the leader to include them, the leader gets longer to decide on their own bid, giving them a free last look. ### Protocol Overview A leaderless auction arrives at auction results in three rounds, and creates an easily-validated aggregate signature verifying them in a fourth. Anybody can submit these signed results to Ethereum to finalize the auction. The protocol also specifies a set of easily provable fault conditions. Anyone can submit proof of a fault at any point, penalizing the participant responsible. ### Properties As we will prove below, this protocol solves the last look problem by satisfying the following two properties: 1. **No latecomers:** No participant can construct a bid after the wall clock time marking the end of round 1. 2. **No free option:** Any participant who preserves the optionality to cancel after round 1 has to pay for that option ahead of time. Effective penalties should make this economically unviable. It’s worth noting that some participants may have lower latency than others, and will therefore be able to act later than others in round 1. ### Assumptions We assume that out of 3f+1 participants, 2f+1 are “honest” (the same threshold required by Byzantine-fault-tolerant consensus protocols). Our synchrony assumption is that all honest participants are able to send messages to one another that are guaranteed to arrive within some fixed amount of time, say, 1 second. This assumption doesn’t need to hold for overall safety or liveness (ensuring we don’t produce conflicting auction results and that auctions eventually happen), because we’re relying on Ethereum for those properties. We discuss what happens when this assumption is violated below. We also assume participants have synchronized clocks, as in Ethereum. ### Auction **Round 1 - Sending Bids ** ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--269754bbce/57272d1a947ebfd82f6d7421f18a41a9/asset-https-cdn-sanity-io-images-dgybcd83--269754bbce.gif) Each participant sends one signed bid to each other participant. These bids are *threshold encrypted*, meaning they are encrypted using a public key that can be decrypted by any collection of f+1 or more participants (which will happen in round 3). This means that no participant is able to see the value of any other participant’s bid before submitting their own, and therefore cannot exploit knowledge of that bid. There are several ways this encryption could be implemented, but the details are outside the scope of this paper – see for example [vetKeys](https://eprint.iacr.org/2023/616). Honest participants are required to submit the highest bid they have received from a member of the public. However, because bids from the public are not encrypted in this design, a dishonest participant could opt to outbid the bids they received from the public by a small amount. Members of the public could address this by sending their bids only to one participant they trust. Cryptographic solutions are possible but would add complexity. **Round 2 - Sending Bid Sets** ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--472435bab9/4f23de823e6b0f3f937b3d59bae04303/asset-https-cdn-sanity-io-images-dgybcd83--472435bab9.gif) Each participant gossips the signed set of all the encrypted bids (a “bid set”) they received in round 1, including their own, to all other participants. All participants now have a “bid view”, or set of bid sets received from other participants. An honest participant will only include another participant’s bid in their bid set if that bid arrived before the end of round 1, as determined by the participants’ synchronized clocks. So, if a bid is included in an honest participant’s bid set, it must have been sent by the end of round 1. Since there are at most f dishonest participants, if a bid appears in f+1 or more bid sets, at least one of them was from an honest participant, and that bid must have been sent by the end of round 1. Any honest participant could use this information to resolve the auction. But, the protocol has no way of knowing which participants are honest. So, we need another round. **Round 3 - Sending Bid Views and Threshold Decryption Information ** ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--bbaa915242/6254d0a3603d6c48590b645b5e9ac401/asset-https-cdn-sanity-io-images-dgybcd83--bbaa915242.gif) Each participant gossips all bid sets they received in round 2 (their “bid view”), including their own, to all other participants. Together with their bid view, they also send out their share of the decryption information used in the threshold encryption scheme discussed above. Any collection of f+1 of these is sufficient to decrypt all of the encrypted bids. This is the most expensive step in terms of bandwidth: each participant must send O(n) bid sets of O(n) bids to O(n) participants, for a total of O(n^3) bandwidth in the worst case. However, everyone should have the same actual bids from each other participant (in the absence of a costly equivocation fault, discussed below), and the presence or absence or a bid in a given set is just a single bit. Furthermore, if everyone is honest and the network is functioning properly, all participants should have every bid in their bid set, and every participant should have a bid set from every other participant. So, if participants only send messages indicating which bids or bid sets they are *missing*, in ideal conditions they have to send only a single bit (“everything was here”) or else just a few (“set 3 was missing bid 13, everything else fine”). ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--639ae7b000/a4ba16a55053f21a2f233be0d49b3199/asset-https-cdn-sanity-io-images-dgybcd83--639ae7b000.gif) At this point, every participant should have the 2f+1 bid views from the honest participants and be able to decrypt them. With f+1 of these, they can prove they have at least one bid view from an honest participant, enough to resolve the auction. The protocol could in theory end here, with any participant able to submit f+1 bid views to the blockchain for finalization. However, due to the space complexity and cost of verification, it is impractical to submit 2f+1 bid views to Ethereum and verify them (perhaps it would be more feasible on a custom chain). Accordingly, we need one more round so that participants can certify auction results in a way that can be easily verified on-chain. **Round 4 - Verifying Bid Views ** ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--41a60b5f50/314e4b33cf990abef5fb7c125cebd69c/asset-https-cdn-sanity-io-images-dgybcd83--41a60b5f50.gif) In order to guarantee our desired properties, we want to easily verify that the winning bid of the auction was the winning bid of at least one valid bid view, and that it was greater than or equal to the winning bid of at least one honest participant’s view. Round 4 is designed to enable this. Each participant examines all of their decrypted bid views. A bid is valid in a bid view if it is present in at least f+1 of the bid sets that make it up. The winning bid of a view is the highest valid bid in that view. A participant *nominates* the winning bid of a given bid view if it is greater than or equal to the winning bid in that participant’s own bid view. Each participant constructs a [threshold signature](https://www.iacr.org/archive/pkc2003/25670031/25670031.pdf) for each bid they are nominating, and gossips the set of all of these bids and signatures to each other participant. Note this is just O(n) in space complexity (one signature per view at most) and O(n^2) in bandwidth complexity. In fact, if all participants are honest and there are no network difficulties, the same bid will win each bid view, and so each participant will nominate only that single bid. **Settlement** ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--e779ccf76e/0a61160840dcad1b9f9e7d5ae3b8315a/asset-https-cdn-sanity-io-images-dgybcd83--e779ccf76e.gif) Any bid that has been signed in this way by at least f+1 participants is *confirmed*. Note that in some cases, two or more different bids may be confirmed (though this means at least one participant must have faulted in round one, and therefore did not receive a free option). Any confirmed bid may be submitted to the Ethereum blockchain, where it can be verified by a simple signature verification. The submitter may receive a small payment from the protocol to reimburse them for gas. Only one confirmed bid will be accepted on Ethereum, allowing all participants to come to consensus on the winning bid in case multiple confirmed bids are present. It is possible that the Ethereum block proposer may censor the auction and not include it in the block. This may even happen several blocks in a row. In this case, the participant who submits the results for the current block’s auction must also submit the results for all of the missing blocks as well. We discuss how this changes fault penalties below. ### Faults **Basics** Anyone can submit fault proofs asynchronously as soon as they have the evidence to do so, most likely resulting in full or partial slashing of the offending participant’s stake. participants reporting fault proofs may receive some part of the slashed stake as a bounty for reporting. An *equivocation fault* occurs when a participant has conflicting bids present in different bid sets or different bid sets present in different bid views. Because this kind of equivocation is either intentional or at the least due to client-side issues as opposed to network problems, penalties for it can be quite severe, including full slashing. An *absence fault* occurs when a participant’s bid is absent in some collection of f+1 bid sets. This could either mean that the participant was dishonest and was attempting to back out of a bid they sent in round 1, or, hopefully rarely, that the participant was honest and the network was partitioned. The penalty for an absence fault shouldbe set to be higher than the option value of being able to cancel a bid. This needs to be balanced against the frequency of genuine network failures, and is ultimately a quantitative problem. In the worst case, having a system of escalating penalties for repeat offenses can limit the frequency with which taking this option is profitable and keep the activity to a minimum. Any system using this protocol could monitor how often these types of faults are occurring relative to verified network failures and adjust penalties accordingly. **Faults for Censored Auctions** As we will discuss further below, auction participants can preserve the optionality to cancel their bids in a later round by committing a fault in round 1. Any participant who does this can create even more optionality for themselves by bribing the Ethereum block proposer to censor the auction results of this auction from the Ethereum block, potentially several times in a row, before finally being submitted as discussed above under “settlement.” To preserve the “no free option” property, we increase the fault penalty for a given auction linearly each time it is censored, so that the original faulter must pay for the option value of each missed block. If an honest participant unintentionally faults due to network issues, somebody could use these increasing penalties to grief them, but the griefer would have to pay to censor the blocks. **Mitigating Unintentional Faults** If any participant has f+1 or more bids missing from their bid set, we know by assumption that they are missing the bid of at least one honest participant, since at most f participants are dishonest. So, we can ignore this participant’s bid set for the purposes of computing absence faults, since either they are dishonest, or there is a network partition occurring. This should reduce the number of faults generated by major network partitions. ### Proofs **i. No Latecomers: Any participant must send their bid to at least one honest participant in round 1 in order for it to be valid in any bid view and therefore have a chance of winning** Assume some participant does not send their bid to any honest participants in round 1. Because there are 2f+1 honest participants, this bid will appear in at most (3f+1)-(2f+1)=f bid sets in round 2, which is not enough for it to be valid in any bid view. If it is not valid in any bid views, it cannot be the winning bid in any bid views, and no honest participant will nominate it. Since f+1 participants must nominate a bid for it to win the auction, at least one of those participants must be honest, and this bid cannot win. **ii. In the absence of network partitions, a participant who sends their bid to all participants in round 1 will not generate a fault** Let’s say our honest participant is Alice. She sends her bid to all 3f+1 participants in round 1. Because 2f+1 of those are honest, every honest participant will send her bid in their bid set to all other honest participants. That means every honest participant will see her bid in at least 2f+1 of the bid sets they receive (including their own). Because there are at most 3f+1 bid sets, her bid will be absent in at most (3f+1)-(2f+1)=f bid sets, so it will not generate a fault. **iii. In the absence of network partitions, a participant who sends their bid to f+1 or more honest participants in round 1 will win the auction if it is the highest bid submitted to any honest participant in round 1** Assume Alice sends her bid to f+1 honest participants in round 1. Each of these honest participants will then include her bid in their bid set, which they send to every other participant. This means that each of the 2f+1 honest participants sees Alice’s bid in f+1 bid sets, and therefore considers her bid to be valid in their bid view. By assumption, Alice’s bid is the highest bid submitted to any honest participant in round 1. So her bid is the winning bid in every honest participant’s bid view, and every honest participant will nominate it. Furthermore, by proof (i) above, no higher bid can be valid in any bid view, so no honest participant will nominate it. This means Alice’s bid is the only one with at least f+1 nominations, and must win the auction. Note there is an edge case if two such bidders are tied with the highest bid. We can adjudicate this with randomness from the threshold decryption. **iv. Any participant must send their bid to at least f+1 honest participants in round 1 to avoid generating a fault** Assume the participant sends their bid to k<=f of the honest participants in round 1 (potentially including themselves). This bid will then appear in k of the bid sets sent by honest participants. Every honest participant will receive 2f+1 bid sets from the other honest participants (including themselves), and only k of those contain the bid in question, so that 2f+1-k>=2f+1-f=f+1 of those will not contain the bid in question, which is enough to generate a fault. Note that even if the network is partitioned, if honest participants ensure that receipt of their bid sets is acknowledged by all other participants, and re-send the sets until acknowledgement is received, a fault can be generated once the network is restored. **v. No free option** By (iii), any participant who sends their bid to f+1 or more honest participants in round 1 will win the auction if it is the highest bid sent to any honest participant in round 1, no matter what they do later. By (iv), any participant who sends their bid to fewer than f+1 participants in round 1 will receive a fault (and therefore be penalized for it). Accordingly, anyone wishing to preserve the optionality to cancel will have to pay for it. ## Conclusion Decentralized auctions have only recently begun to see widespread use, introducing many novel problems. This paper is aimed at an issue we have not seen addressed elsewhere. We hope and expect that many better solutions will emerge – ideally ones that are simpler, with fewer rounds, or have fewer assumptions around things like synchrony or number of honest participants. Still, while this design doesn’t solve every issue, it does address some of the common “last look” issues inherent in decentralized auctions. We hope it can be of some use in and of itself, help others working on similar problems, or even be improved or remixed into something better. ## Acknowledgements [Frankie](https://twitter.com/FrankieIsLost), [Joachim Neu](https://twitter.com/jneu_net), [Achal Srinivasan](https://twitter.com/achalvs), [Georgios Konstantopoulos](https://twitter.com/gakonst), [Ciamac Moallemi](https://twitter.com/ciamac), [Max Resnick](https://twitter.com/MaxResnick1), [Lefteris Kokoris-Kogias](https://twitter.com/LefKok) ## https://www.paradigm.xyz/writing/paradigm-files-amicus-brief-in-support-of-kalshiex-congressional-control-contract-case-vs-the # Paradigm Files Amicus Brief in Support of KalshiEx Congressional Control Contract Case vs. the CFTC > Paradigm filed an amicus brief in support of Kalshi's lawsuit against the CFTC, which challenges the Commission's disapproval of the listing of a prediction market on Congressional control. **Paradigm Files Amicus Brief in Support of KalshiEx Congressional Control Contract Case vs. the CFTC** Last week, Paradigm filed an [amicus brief](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-64e4102fff/a05c000dc0d4451289acb3df07f99590/asset-https-cdn-sanity-io-files-dgybcd83-p-64e4102fff.pdf) supporting [Kalshi’s](https://kalshi.com/) lawsuit against the CFTC, which stemmed from the Commission’s [disapproval](https://www.cftc.gov/PressRoom/PressReleases/8780-23) of the listing of a prediction market on the outcome of this year’s Congressional elections—specifically, on which party controls each chamber of Congress. Through our amicus program and the [Policy Lab](https://policy.paradigm.xyz/policylab), Paradigm has been an fierce industry champion on the frontlines of crypto regulation. While Kalshi isn’t a crypto company, we felt compelled to intervene in this case because we believe that prediction markets are one of the potentially revolutionary use cases for crypto. Moreover, event contracts on Congressional control would provide crypto companies with important information to guide their corporate strategies and provide them a useful tool to hedge regulatory risk. A lot rides on U.S. Congressional elections: countless pieces of legislation, spending provisions, and confirmations of executive and judicial nominees become more (or less) likely. The uncertainty of these potential outcomes creates risks for businesses and individuals. Take for example an entrepreneur who is building a crypto startup in the U.S. The likelihood that Congress will pass legislation that will impact the viability of U.S.-based crypto startups is directly affected by which party is in control of Congress, or whether the government is divided. Which party controls Congress will also have a direct impact on the confirmation of key administration officials, including the Chairs of the CFTC and SEC. A crypto entrepreneur may therefore want to buy an event contract that pays out depending on which party takes control of Congress in order to hedge its regulatory risk. Moreover, when market participants hedge substantial sums on a particular event contract, the general public—even to those who never join the market—gets valuable real-time information. For these reasons, allowing Congressional control contracts is in the public interest and the court should overrule the CFTC’s prohibition of these contracts. ## https://www.paradigm.xyz/writing/paradigm-files-comment-letter-on-fincen-s-proposed-reporting-requirements-for-mixers # Paradigm Files Comment Letter on FinCEN's Proposed Reporting Requirements for Mixers > Paradigm today filed a comment to FinCEN’s Notice of Proposed Rulemaking, which labels all “convertible virtual currency mixing”–defined broadly–as a primary money laundering concern, and seeks to impose a new reporting requirement on all related transactions. **TLDR**: Paradigm today filed a [comment](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-608e9e4e45/c1682ae0e2facd5289889813e602894d/asset-https-cdn-sanity-io-files-dgybcd83-p-608e9e4e45.pdf) to FinCEN’s [Notice of Proposed Rulemaking](https://www.federalregister.gov/documents/2023/10/23/2023-23449/proposal-of-special-measure-regarding-convertible-virtual-currency-mixing-as-a-class-of-transactions), which labels all “convertible virtual currency mixing”–defined broadly–as a primary money laundering concern, and seeks to impose a new reporting requirement on all related transactions. Paradigm shares FinCEN’s concern that crypto, like any technology, can be abused by bad actors, and supports thoughtful action to curtail that risk where appropriate. However, the Proposed Rule is not the appropriate tool to address the stated concern. Its implementation would also negatively impact the national security interests of the United States by driving the development of blockchain technology offshore. In attempting to address a legitimate risk, the Proposed Rule misses the mark by focusing on general application technology, instead of bad actors themselves. Rather than focusing reporting requirements on the bad actors that exploit otherwise legitimate technologies, the Proposed Rule focuses on a broad sway of rapidly developing technologies that, for legitimate reasons (scalability, execution optimization, etc.), can function to anonymize or mask the source, destination, or amount of a transaction. While the Proposed Rule seeks to create a broad new reporting regime, FinCEN already has the tools it needs. FinCEN’s suspicious activity report (“SAR”) regime requires financial institutions to identify and report transactions potentially linked to illicit finance and terrorism. FinCEN should withdraw or materially curtail the Proposed Rule and, instead of creating a new reporting regime applicable to a broad range of general technologies and activities, use the tools it already has to directly address bad actors. This is an opportunity for FinCEN to work with the crypto industry on targeted rules that actually deal with the problems of illicit finance. ## https://www.paradigm.xyz/writing/ethereum-2024 # What comes after Ethereum's Cancun hard fork? > Where we outline the Paradigm Reth team's current view on possible next steps for Ethereum's upgrade after Cancun, Prague. # TL;DR The goal of this post is to outline the [Paradigm Reth team’s](https://www.paradigm.xyz/2023/06/reth-alpha) view on which EIPs should be included in Prague, the next EL hard-fork after Cancun, and our general 2024 “EL Core Dev” plans. The views below are evolving and represent only the Reth team's current view, and not necessarily the broader Paradigm team. ** We think the Prague hard fork is possible on Ethereum testnets by Q3 2024 and mainnet by end of year.** It should include: - Any staking-related EIPs, such as EIP-7002 which enables re-staking & trustless staking pools. - Isolated EVM changes. - We are open to collaborating with any teams that want to further investigate any hard questions for Prague or other future EL hard forks, happy to mentor or provide guidance for where to modify the Reth codebase. **Dos:** - We think the following EIPs must be prioritized: [7002](https://eips.ethereum.org/EIPS/eip-7002), [6110](https://eips.ethereum.org/EIPS/eip-6110), [2537](https://eips.ethereum.org/EIPS/eip-2537). - We are supportive of EOF as described in the [spec](https://notes.ethereum.org/@ipsilon/mega-eof-specification), but would like scope to be finalized ASAP and a meta-EIP to be created committing to that scope. - We are open to increasing the [EIP-4844 Max Blob Gas.](https://eips.ethereum.org/EIPS/eip-4844#consensus-layer-validation) We don’t have a view on the right number, but we invite data people to work with us on investigating the subject. - We are open to shipping a version of [EIP-7547: Inclusion lists](https://eips.ethereum.org/EIPS/eip-7547) to help with base layer censorship resistance. **Don’ts:** - We are not supportive of [Verkle Tries](https://verkle.info/) in Prague, but are supportive of client teams starting to work towards it in Q2 2024, and commit to shipping it in Osaka sometime mid/late 2025. - We do not think we should increase the L1 Execution Gas Limit or contract size, but we invite data people to work with us on investigating the impact on the network. We are open to revising our take here since past testing showed that Reth nodes can handle increased load without problems. - We think that Wallet / Account Abstraction EIPs need more battle-testing against each other to understand the tradeoff space better. If they’re not mutually exclusive then we would be open to deploying multiple AA-related EIPs in the future. - We could get over the line on EIP-7212 (secp256r1), if the community is OK with the [rumored](https://security.stackexchange.com/a/256108) [NSA](https://saweis.net/posts/nist-curve-seed-origins.html) [backdoor](https://eprint.iacr.org/2015/1018.pdf). - Other Roadmap Topics: We do not have a hands-on view on CL EIPs or the coupling of CL/EL forks, but EIP [7549](https://eips.ethereum.org/EIPS/eip-7549) and [7251](https://eips.ethereum.org/EIPS/eip-7251) seem promising. We also would like to contribute to the work on PeerDAS, where possible from the EL side. We would like to avoid the introduction of SSZ roots (EIP 6404, 6465, 6466) at the moment. Finally, we observe that there is an opportunity for a long-term data archival solution for expired blobs, history and state, since neither [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) nor [EIP-4444](https://eips.ethereum.org/EIPS/eip-4444) specify that, and it’s TBD whether Ethereum wants to offer such a solution. Reasoning below. # Dos Abstractly, we are supportive of 1) further bridging the gap between CL and EL, 2) EVM modifications which can be executed as 1-person jobs and can be tested in isolation & in parallel. ## [EIP-7002](https://eips.ethereum.org/EIPS/eip-7002) This EIP unlocks trustless re-staking and staking pools, by enabling smart contracts on the EL side to control 1 or more validators on the CL side. No-brainer EIP from our perspective as at a minimum it’ll enable existing staking pools to remove a layer of centralization from the smart contracts that implement their withdrawals. Introducing the stateful precompile to the EVM is a new abstraction we need to capture in the EVM implementations, but beyond that we think this is a straightforward EIP to execute on. ## [EIP-6110](https://eips.ethereum.org/EIPS/eip-6110) This introduces deposits in the EL State, simplifying the state management that needs to be done on the CL. Implementation wise, this is similar to tracking CL Withdrawals, so overall we think this is also an easy & isolated EIP to implement. ## [EIP-2537](https://eips.ethereum.org/EIPS/eip-2537) There are multiple implementations of BLS12-381 by now in the wild, and it’s a frequently used curve in many SNARKs, BLS signing algorithms, and EIP-4844. We consider implementation complexity low, as it is merely exposing the curve’s verification algorithm over the precompile interface. It is possible we also want a Hash to BLS12-381 Curve precompile. ## [EOF](https://notes.ethereum.org/@ipsilon/mega-eof-specification) TL;DR: Supportive of a well-scoped version that Solidity & Vyper will adopt. Code format & verification adjustments that make analysis easier are a no-brainer, and we recommend anything beyond that to be carefully considered. We recommend a few EIPs below, but we are open to further trimming. The good: - EVM-only change which can be tested with ethereum/tests and implemented by 1 person. - EVM-change that Vyper and Solidity want! - Helps with performance & increases of contract size limit. - Removes the need for bytecode analysis at runtime by EVMs, which can be as much as 50% of the time when there’s no caching involved, growing with the contract size. - Enables partial code load which helps with executing smart contracts of large size. - Devex: Will allow fixing “Stack Too deep” in solidity with dupN/swapN, and other tooling improvements. - Future Proofing: Can safely introduce new features across L2s and tooling will know what is compatible. The bad: - Scope & moving targets. - No champion pushing hard for its inclusion. - Legacy code still needs to be supported - Temporary divergence between Ethereum mainnet and other EVM chains until adopted. We think the following EOF features should be deployed in 2024. We recommend finalizing the scope ASAP and committing to it. Anything else should be considered for follow-up deployments. Our recommendations: - [EIP-3540: EOF - EVM Object Format v1](https://eips.ethereum.org/EIPS/eip-3540): Introduces code and data containers and adds structure and versioning to the ethereum bytecode. - [EIP-3670: EOF - Code Validation](https://eips.ethereum.org/EIPS/eip-3670): Reject any contracts that do not follow the EOF format at deploy time. Enforce more structured code and disable invalid and undefined instructions. - [EIP-663: Unlimited SWAP and DUP instructions](https://eips.ethereum.org/EIPS/eip-663): This addresses “Stack Too Deep” in solidity, with JUMPDEST analysis as immediate value could have side-effects. Very desirable by evm langs. - [EIP-4200: EOF - Static relative jumps](https://eips.ethereum.org/EIPS/eip-4200): Better static analysis, no uncertain jumps. Better aot compilation. relative jumps are better for code reusability. - [EIP-4750: EOF - Functions](https://eips.ethereum.org/EIPS/eip-4750): Needed to address subroutines that were possible with dynamic jumps but not with static jumps. It also allows partial code load which works nicely with Verkle & increasing the contract size limit. - [EIP-5450: EOF - Stack Validation](https://eips.ethereum.org/EIPS/eip-5450): Validates code and stack requirements. Removes runtime stack underflow and overflow check for all instruction except CALLF (EIP-4750) - [EIP-7480: EOF - Data section access instructions](https://eips.ethereum.org/EIPS/eip-7480): Allow accessing the data section of the bytecode. - [EIP-7069: Revamped CALL instructions](https://eips.ethereum.org/EIPS/eip-7069): enables removing gas observability from CALLs, which enables easier gas repricing in the future. While independent of EOF, we think it’s a good opportunity to introduce it. We are less certain about [EIP-6206: EOF - JUMPF and non-returning functions](https://eips.ethereum.org/EIPS/eip-6206). While it allows for tail call optimizations in EOF functions, we still would need to see languages analyze its usefulness. If we don’t have that, we think it is fine to trim it from scope and include in follow-up EOF update. We budget the above to 1-2 months of work by 1 person, full-time. We are open to further trimming the above mentioned scope if it means keeping momentum. A note on legacy bytecode: - While we can disallow new legacy/non-EOF bytecode, there is no way to deprecate existing legacy bytecode, which effectively acts as EOF “v0”. Legacy bytecode will still require JUMPDEST analysis post-EOF, and will still require special code handling for segmenting it into chunks in Verkle Tries. - To the best of our knowledge there is no verifiable transformation from non-EOF bytecode to EOF without access to the source artifacts, but we are open to investigating mechanisms for facilitating such a transformation. - Alternatively, we are open to exploring expiry methods which would force the migration of state to EOF. ## Increasing EIP-4844 Blob Count We are open to this change, which would correspond to an increase the `MAX_BLOB_GAS_PER_BLOCK` and `TARGET_BLOB_GAS_PER_BLOCK`, for context from [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844): *> The values for TARGET_BLOB_GAS_PER_BLOCK and MAX_BLOB_GAS_PER_BLOCK are chosen to correspond to a target of 3 blobs (0.375 MB) and maximum of 6 blobs (0.75 MB) per block. These small initial limits are intended to minimize the strain on the network created by this EIP and are expected to be increased in future upgrades as the network demonstrates reliability under larger blocks.* In practice this is a small code change, we’d need to investigate the practical impacts of it in the txpool, but we think we can re-use the EIP-4844 stress testing infrastructure for this. It is possible that CLs have a harder time propagating more blobs; we defer to the CL teams’ opinion. # Don’ts ## [Verkle Tries](https://verkle.info/) TL;DR: We do not see a path towards a late 2024/early 2025 deployment of Verkle tries. We recommend teams to allocate resources on this in Q2 2024 and commit to deploying in Q2-Q3 2025 in the Osaka hard fork. The good: - Cheaper light clients via smaller storage proofs. - Stateless execution via inclusion of read pre-states in a block’s header, which may also result in performance improvements due to static state access. - Raising the contract size limit by chunking bytecode and enabling partial code loading. - State expiry becomes more palatable as the cost to “revive” state is lower. The bad: - Impact of changes & integration effort to implement & test. - Gas Accounting Changes: Verkle Tries introduce the size of the witness into the gas calculation function. We worry that changes in storage pricing have not been explored yet (e.g. What’s the cost of the top gas guzzlers going to be post Verkle)? - Application integrations: What should applications with Merkle Patricia Trie verifiers do while the Overlay transition is running? How should `eth_getProof` behave? While we understand the benefits of Verkle Tries, we think more thought needs to be given to how 3rd party tooling/contracts would need to adapt, and what impact the transition would have on e.g. layer 2 solutions. Initially we had doubts about the migration strategy, since it stipulated that the Verkle trie should be updated when state was read from the pre-existing MPT, but this does not seem to be the case anymore. As such, we are supportive of the overlay tree method as a viable migration path. The documentation for Verkle migration strategies generally seems to be outdated, as most resources still state that the Verkle trie should be updated when state is read from the MPT, even though this is not the case. We would like to see critical transition documentation updated with the latest approaches, such as [this excellent doc](https://notes.ethereum.org/@parithosh/verkle-transition). We would also like to see a draft EIP on the transition strategy. As a result we remain supportive of its rollout in 2025, but do not see a path towards deployment in Prague. ## L1 Gas Limit We think that due to induced demand upping the L1 gas limit won’t do much in practice. We also think that most clients can handle the average case load increase, but we want to remain vigilant about the worst cases, so we cannot recommend an increase in the L1 gas limit yet. We see increasing blob gas limit as a more promising solution in the short run. We invite people to collaborate with us on any research in that direction, and in general around breaking resource metering in the EVM. The [Broken Metre paper](https://www.ndss-symposium.org/ndss-paper/broken-metre-attacking-resource-metering-in-evm) is a great starting point for this line of research. ## Account Abstraction We are open to including 1 or more of these EIPs (or enshrining the ERCs), but we’d ideally like to see more UX and DevEx comparisons between each proposal to better understand the tradeoff space and effort for tool integration. We are paying attention to the following EIP/ERCs, but feel free to suggest us with more: - [EIP-3074: AUTH and AUTHCALL opcodes](https://eips.ethereum.org/EIPS/eip-3074) - [ERC-4337: Account Abstraction Using Alt Mempool](https://eips.ethereum.org/EIPS/eip-4337) - [EIP-5806: Delegate transaction](https://eips.ethereum.org/EIPS/eip-5806) - [EIP-5920: PAY opcode](https://eips.ethereum.org/EIPS/eip-5920) - [EIP-6913: SETCODE instruction](https://eips.ethereum.org/EIPS/eip-6913) - [EIP-7377: Migration Transaction](https://eips.ethereum.org/EIPS/eip-7377) - [RIP-7560: Native Account Abstraction - Core EIPs - Fellowship of Ethereum Magicians](https://ethereum-magicians.org/t/rip-7560-native-account-abstraction/16664) We'd like to caveat that in the above, "account abstraction" as in "abstracting the validation function, with the primary goals being to enable key rotation, make multisigs first-class, and give us an automatic path to quantum-resistance" (h/t VB) only applies to 4337 and 7560 above, while other proposals are the others are in two buckets, gas sponsorship and batching of operations. ## https://www.paradigm.xyz/writing/paradigm-responds-to-the-cfpb-s-proposed-larger-participants-digital-wallet-rule # Paradigm Responds to the CFPB’s Proposed “Larger Participants” Digital Wallet Rule > The Consumer Financial Protection Bureau has proposed a rule intended to regulate large centralized digital payment companies, but captures crypto wallets in the process. Paradigm urges the Bureau to appropriately narrow the scope of the rule to exclude crypto wallets, which are quite different than the rule's ostensibly intended targets. **Paradigm Responds to the CFPB’s Proposed “Larger Participants” Digital Wallet Rule** Today, Paradigm filed a comment letter with the Consumer Financial Protection Bureau on their proposed “Larger Participants Rule,” which is intended to regulate digital wallets used in consumer payments. The CFPB ostensibly intended to establish greater oversight over a handful of large centralized digital payment service providers, such as Apple, PayPal/Venmo, and Block/CashApp, [^1] but the scope of the rule would also capture Hosted and Unhosted Crypto Wallets, blockchain network financial and nonfinancial transactions, and all other manner of onchain activity – an onerous and overly-broad jurisdictional land grab. In effect, the CFPB seems to have set out to hunt large game, and instead bagged all the animals in the jungle. It needs to release the “small animals” back into the wild. The three most problematic areas within the Proposed Rule are: 1. Bitcoin and blockchain have been in active use since early 2009. The 2010 Dodd Frank Act, which authorized the CFPB, could have also granted the CFPB jurisdiction over this technology, and yet did not. As a result, the CFPB, while lacking Congressional authorization to regulate crypto, still seeks to do so under a provision designed to allow the agency to regulate student loan and automobile financing. [^2] This is an extraordinary expansion of the agency’s interpretation of the Consumer Financial Protection Act. 2. The proposed definition of “wallet functionality” is broadly worded to capture crypto wallet software service providers that do **not** custody cryptoassets on behalf of users, or otherwise intermediate transactions. This would subject software developers to supervisory regulation on par with Big Tech payment processors, and would drive many of these developers offshore given the burden of compliance – limiting options for US consumers, and increasing risk of consumer harm. 3. The CFPB failed to adequately perform a fulsome cost-benefit analysis of the proposed rule, despite clear evidence that the lack of such analyses will be [viewed dimly by federal courts](https://www.reuters.com/markets/us/us-court-tells-sec-fix-defective-share-buyback-rule-2023-11-01/). The CFPB **admits (!)** in the proposed rule that their cost-benefit analysis was of insufficient depth to adequately determine the impact the rule might have on wallet service providers or customers. [^3] At a high level, the CFPB fails to disambiguate **Cash Wallets** from **Crypto Wallets** in the course of its Digital Wallet rulemaking. “Cash Wallets,” like Venmo or CashApp, are similar to bank accounts in many ways, where the wallet provider typically custodies and maintains customer funds with the funds of other customers in an omnibus “for the benefit of”, or FBO, account. When the customer initiates a transfer of funds, the Cash Wallet provider must rely on the Automated Clearing House (ACH) or bank wire to move the funds. Meanwhile, a “Crypto Wallet” is a blockchain network address to which cryptoassets may be allocated. A Crypto Wallet user may freely transfer those assets allocated to their network address to any other Crypto Wallet directly on the blockchain – without any intermediation by the Crypto Wallet provider, any bank, or payment system – by using their Wallet to signal the network their intent, desired onchain operation, or asset ownership update. The difference is obvious and clear — while the former are more like “bank accounts on the Internet,” the latter are something more akin to technology data transfers. They are animals from different species that happen to look similar from a blurry distance. Furthermore, unlike cash deposits in a bank account, cryptoassets represent all manner of goods and services. For example, one of the world’s largest ticket vendors offers [support for concert tickets](https://business.ticketmaster.com/business-solutions/nft-token-gated-sales/) in cryptoasset format, and fine art auction houses across the globe [regularly auction precious works of art](https://www.mdpi.com/2076-0752/12/5/212) in the cryptoasset medium by the likes of [Damien Hirst](https://heni.com/nft/more-info/the-currency), [Refik Anadol](https://nft.refikanadol.com/), and [Beeple](https://www.christies.com/en/stories/monumental-collage-by-beeple-is-first-purely-digital-artwork-nft-to-come-to-auction-0463a2c0f3174b17997fba8a1fe4c865). In light of the issues raised by the potential application of this proposed rule, Paradigm strongly recommends that the CFPB consider expressly excluding Crypto Wallet providers – or, at a minimum, Unhosted Crypto Wallet providers, from the Proposed Rule at this time. The CFPB should also consider further revising the Proposed Rule to avoid potential administrative law pitfalls and adverse impacts upon the blockchain and crypto industry. While Paradigm appreciates the CFPB’s engagement on these issues, we would also respectfully suggest the Bureau engage directly with Congress, which is currently evaluating comprehensive crypto market structure legislation. In such legislation, Congress might officially designate a role for the Bureau in regulating crypto alongside the other regulatory agencies. Given the CFPB’s history of narrowly dodging legal and political challenges to its existence, the CFPB helping Congress pass much-needed comprehensive and broadly bipartisan legislation on crypto market structure might be an opportunity for its operations to be further enshrined into our system of financial regulation. Read the comment letter [here](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-1002202eb2/806ccbcc07f3c5016cc550aa599fc37d/asset-https-cdn-sanity-io-files-dgybcd83-p-1002202eb2.pdf) [^1]: Indeed, the CFPB suggests that their rulemaking only impacts 17 companies. This is clearly not the case [^2]: Consumer FInancial Protection Act, Section 1024 [^3]: CFPB lacks detailed information with which to predict the extent to which increased costs would be borne by providers or passed on to consumers, to predict how providers might respond to higher costs, or to predict how consumers might respond to increased prices.” Proposing Release at 80212 ## https://www.paradigm.xyz/writing/paradigm-files-amicus-brief-in-sec-s-lawsuit-against-ripple # Paradigm Files Amicus Brief in SEC’s Lawsuit Against Ripple > Last week, Paradigm filed an amicus brief in the SEC’s lawsuit against Ripple Labs, Inc. Our goal is to help the Court avoid the unintended consequences of casually endorsing the SEC’s position in this case, which conflates an investment scheme with the crypto asset sold in that scheme. **TLDR:** Last week, Paradigm filed an [amicus brief](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-6cf6592e26/fb298d09763ba728a2dfc5351290531b/asset-https-cdn-sanity-io-files-dgybcd83-p-6cf6592e26.pdf) in the SEC’s lawsuit against Ripple Labs, Inc. Our goal is to help the Court avoid the unintended consequences of casually endorsing the SEC’s position in this case, which conflates an investment scheme with the crypto asset sold in that scheme. Our brief is backed by a [comprehensive analysis](https://dlxlaw.com/wp-content/uploads/2022/11/The-Ineluctable-Modality-of-Securities-Law-%E2%80%93-DLx-Law-Discussion-Draft-Nov.-10-2022.pdf) of every relevant appellate and Supreme Court case to have applied the Howey test, which confirms no legal precedent exists for treating the object of an investment contract itself as a security (nor has the SEC cited any such authority). While this distinction may seem subtle, it is of monumental importance, and if ignored, it could displace Congress’s role in deciding how crypto assets will be regulated. **The orange groves in Howey were not securities, neither are tokens** Since the seminal Howey case [^1] in 1946, federal courts have found a wide range of transactions to constitute investment contracts, including examples dealing with whiskey warehouse receipts [^2], beavers [^3], cattle embryos [^4], and chinchillas [^5], among others. However, in each of those cases, the investment contract (i.e., the set of formal or informal arrangements between the issuer and purchaser) is clearly distinguishable from the object of the scheme itself (e.g., the orange groves, whiskey warehouse receipts, etc.). The same logic has been applied to transactions and schemes involving crypto assets. For example, in a carefully worded opinion, the Telegram court held that “While helpful as a shorthand reference, the security in this case is not simply the Gram, which is little more than alphanumeric cryptographic sequence… This case presents a “scheme” to be evaluated under Howey that consists of the full set of contracts, expectations, and understandings centered on the sales and distributions of the Gram.” [^6] **By claiming that digital assets themselves are securities, the SEC is attempting to bypass the role of Congress** Nevertheless, in an attempt to expand its authority past the bounds set by Congress, the SEC has repeatedly referred to the XRP token itself as a security. If the Ripple court takes the SEC’s flimsy bait, it risks straying outside the bounds of all existing appellate precedent and statutory guidance and opening their decision to potential reversal. The result would be pointless and unnecessary chaos for markets, investors, and even the government’s efforts to comprehensively address this industry. Markets for digital assets raise important investor protection and other policy concerns. But that is all the more reason for judicial restraint, particularly given Congress’ active desire to pass comprehensive legislation on crypto, including ongoing consideration of various bills intended to address this. As the Supreme Court explained just this past term, “Congress intends to make major policy decisions itself, not leave those decisions to agencies.” [^7] For these reasons, our amicus brief asks the court to decline to adopt the SEC’s unsupported position that the XRP token itself is a security and in so doing restrain the SEC from jumping ahead of Congress. [^1]: In SEC v. W.J. Howey Co., 328 U.S. 293 (1946), the Supreme Court held that an offering of units of a citrus grove development, coupled with a contract for cultivating, marketing, and remitting the net proceeds to the investor, was an offering of an “investment contract” and therefore a “security” offering within the meaning of § 2(1) of the Securities Act of 1933. The Court also set forth a four part test that looks to whether the circumstances of a given contract, transaction or scheme involves: (1) an investment of money, (2) in a common enterprise, (3) with an expectation of profits to come, (4) solely from the efforts of the promoter or a third party (opinions available here, see wikipedia for more background) [^2]: Glen-Arden Commodities, Inc. v. Costantino, 493 F.2d 1027 (2d Cir.1974) [^3]: Kemmerer v. Weaver, 445 F.2d 76 (7th Cir. 1971) [^4]: Bailey v. J.W.K. Props., Inc., 904 F.2d 918 (4th Cir. 1990) [^5]: Miller v. Cent. Chinchilla Grp., Inc., 494 F.2d 414 (8th Cir. 1974) [^6]: SEC v. Telegram Group, Inc., 448 F. Supp. 3d 352 (S.D.N.Y. 2020) at 379 [^7]: West Virginia v. EPA, 142 S. Ct. 2587 (2022) ## https://www.paradigm.xyz/writing/paradigm-files-comment-letter-on-irs-unduly-burdensome-proposed-crypto-broker-rule # Paradigm Files Comment Letter on IRS' Unduly Burdensome Proposed Crypto Broker Rule > The IRS and Treasury Department's crypto broker rule is unduly broad and burdensome, indiscriminately implicating wide swaths of the crypto industry. Paradigm's comment letter urges the IRS to substantially revise the proposed rule to ensure it is properly tailored and practically administrable. **Paradigm Files Comment Letter on IRS’ Unduly Burdensome Proposed Crypto Broker Rule** **TL;DR:** Paradigm Friday filed a comment letter responding to the IRS and Treasury Department’s unduly broad proposal to require additional reporting on digital asset transactions by wide swaths of the crypto industry. This proposal goes beyond the powers granted by Congress and will stifle innovation in the U.S.; it must be substantially changed. Taxation lies at the heart of all government power, just as decentralization stands as the beating heart of crypto. It is critical for both the crypto ecosystem and the government that the rules of crypto taxation are properly tailored and practically administrable. In 2021, Congress passed and President Biden signed the Infrastructure Investment and Jobs Act of 2021, also known as the Infrastructure Law. Tucked inside this law to improve America’s rails and roads was a provision that dealt with crypto, the first significant piece of legislation enacted on our young industry. That section, 80603, asked the IRS and Treasury Department to issue a rule that would apply the definition of “broker” to certain firms in crypto, tasking only those firms that actually ‘effectuate’ (or ‘cause’) onchain transactions to be completed with reporting tax information to the IRS. The IRS and Treasury issued that proposal this summer. The proposal is much too broad, and far exceeds the task Congress gave to the two agencies, by including within its remit crypto entities that don’t “effectuate” transactions, including non-custodial digital wallet software providers, DeFi protocols, and NFT marketplaces among them, even though such entities don’t have control of key information, or even any direct user interaction. It is the height of absurdity to task firms with reporting to the government information they do not themselves have, to say nothing of the public-private surveillance network this proposal would by definition create. We firmly believe that the IRS and Treasury Department have proposed a rule that is neither in keeping with the will of our elected officials in Congress nor is good for crypto users, the industry, or the government itself. The IRS and Treasury Department should work with the industry to pare back this proposal into something that ensures only *actual* brokers in crypto are reporting key tax information to the government, in line with the text and original spirit of the Infrastructure Law. Read Paradigm’s Comment Letter [here](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-6e07f23216/141b31fcb611e98ce78e38b39aa12e07/asset-https-cdn-sanity-io-files-dgybcd83-p-6e07f23216.pdf). ## https://www.paradigm.xyz/writing/you-cant-regulate-what-you-dont-understand-2-0 # You Can’t Regulate What You Don’t Understand (2.0) > The recent SEC Inspector General report highlighted the impact that limiting crypto ownership has had on the SEC’s hiring efficacy. In light of this, Paradigm Policy revisited and revised our suggested updates to government ethics rules. Earlier this year, Paradigm Policy [wrote](https://paradigm.xyz/writing/2023/02/ethics-rules-government-use-of-crypto) about how government ethics rules are negatively impacting sound crypto policymaking. Last week, the SEC Inspector General released a [report](https://www.sec.gov/files/inspector-generals-statement-sec-mgmt-and-perf-challenges-october-2023.pdf) noting that, despite the rapid growth of crypto markets, the SEC was encountering “challenges in recruiting specialists in crypto assets, which Enforcement considers critical to strengthening its capabilities to investigate new and emerging issues in crypto-asset markets.” Besides general competitiveness for crypto talent, the SEC was running into issues in attracting crypto specialists because “many qualified candidates hold crypto assets, which the Office of the Ethics Counsel has determined would prohibit them from working on particular matters affecting or involving crypto assets…Candidates are often unwilling to divest their crypto assets to work for the SEC.” (Editor note: shocker.) Regrettably, this problem will metastasize for the SEC as crypto becomes further integrated into the traditional financial system. Earlier this year, payments giant PayPal announced the release of their own stablecoin, PYUSD, and their intention to integrate it into their payments services, including Venmo. This promptly earned them a [subpoena](https://www.coindesk.com/policy/2023/11/02/us-sec-subpoenas-paypal-about-usd-stablecoin-company-says/) from the SEC, despite findings from the Presidential Working Group on Stablecoins, and Congressional intent in numerous bills that stablecoins should be regulated under a prudential oversight framework. Given the SEC’s desire to assert jurisdiction over stablecoins, consider this not-unlikely scenario: SEC staff will be prohibited from use of Venmo, a payment app used by 78 million Americans in 2022 to pay family, friends, or service providers. It will get worse from there. We are already seeing the rapid advancement of video games built on blockchain rails, where in-game assets (items, avatar skins, etc.) are tokenized to support gamer monetization and interoperability between games. If most video games in the future involve NFT assets the SEC is also trying to [assert](https://www.sec.gov/news/press-release/2023-163) are [securities](https://www.sec.gov/news/press-release/2023-178) – can SEC staff and other government employees no longer play video games? The life of a regulator in the future seems increasingly disconnected, walled off from 1) consumer payment apps, 2) video games, 3) airline or [credit card rewards points](https://www.coindesk.com/learn/can-cryptocurrency-replace-loyalty-points/), 4) [Starbucks customer loyalty programs](https://stories.starbucks.com/press/2022/starbucks-brewing-revolutionary-web3-experience-for-its-starbucks-rewards-members/), 5) [Nike sneakers](https://www.highsnobiety.com/p/nike-swoosh-web3-interview/), and so on. As the problems created by the government’s harsh ethics rules become even clearer, Paradigm Policy reviewed and re-evaluated our [suggested principles](https://policy.paradigm.xyz/writing/ethics-rules-government-use-of-crypto) around government crypto ownership and use from earlier this year, and stand behind our findings – though we have amended our suggestions in a few key instances. These principles are intended as a starting point, and Paradigm welcomes conversation and collaboration with policymakers who might be open to implementing a more tech-forward approach: - **Threshold**. For restricted policymakers, we proposed an exemption to ethics rules that permits ownership of cryptocurrency under a threshold amount, indexed to metrics such as inflation or blockchain gas fees. We previously suggested $1,000 as a benchmark; we now propose $5,000 for greater flexibility, and increased ability to pay gas fees enabling complex onchain transactions. Any holdings above this threshold must be divested or placed into a blind trust. (NB: assuming crypto fulfills its full potential and forms the underlying infrastructure for the financial system writ large, even this dynamic thresholding — indexed to inflation or gas fees — will likely become eventually unsustainable.) - **Stablecoins.** Stablecoins were not included in our initial recommendations, but growing adoption merits an immediate change in government ethics approach. Specifically, ownership of stablecoins should be carved out entirely from ethics rules (and thus would not factor into the above proposed threshold). Put simply, using stablecoins is no different than handling dollars, and cutting off access to this critical technology would especially stymie good regulation. In response to the SEC’s report this week, crypto commentators made clear what the problem is with every analogy in the book. Imagine FAA safety managers never touching a plane. Building inspectors never visiting a construction site. Food safety engineers never seeing a packing plant. All would be incompetent at their jobs. As we have previously emphasized, government ethics policies are helping America fall further behind on crypto. It is time for our leaders to lean into progress. ## https://www.paradigm.xyz/writing/paradigm-files-amicus-brief-in-harper-vs-irs # Paradigm Files Amicus Brief in Harper vs. IRS > Paradigm filed an amicus brief in support of James Harper’s lawsuit against the IRS, which challenges the agency’s ability to use “John Doe” summons as a dragnet to surreptitiously obtain the private records of large groups of crypto users. **TLDR**: Paradigm filed an [amicus brief](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-1e9a152730/026ee4a3120b72cd5ad639c02804ad12/asset-https-cdn-sanity-io-files-dgybcd83-p-1e9a152730.pdf) in support of James Harper’s lawsuit against the IRS, which challenges the agency’s ability to use *“John Doe”* summons as a dragnet to surreptitiously obtain the private records of large groups of crypto users. Paradigm strongly believes that, despite its nascency, crypto and blockchain technology will play an essential role in everyday life. One in five Americans have owned crypto, with the number of blockchain participants skyrocketing over the years; indeed, as of October 20, 2023, there were over 247 million [unique Ethereum addresses](https://etherscan.io/chart/address). Blockchain technology could eventually be used for ordinary, everyday affairs—a trip to the store, a visit to the doctor, or voting in an election. Yet the district court’s dismissal of James Harper’s complaint against the IRS threatens to curtail that potential. The district court erred in concluding that there is no expectation of privacy when a person transacts on a crypto exchange. As suggested by the prefix “crypto”—derived from the space’s origins in cryptography—privacy is a foundational pillar of crypto transactions. There are many valid reasons why crypto users want to maintain some privacy—a user may, for example, want to keep hidden his or her participation in social movements, such as support for Ukraine’s defense against Russian aggression. That expectation of privacy does not evaporate simply because a user chooses to transact through a centralized exchange, rather than on the blockchain itself. The district court erroneously reasoned that a crypto transaction on an exchange is like a bank transaction. But the nature and design of crypto gives rise to a more substantial expectation of privacy than that of bank records, which are often passed between intermediaries with full identifying information in view. And, as the Supreme Court clarified in [*Carpenter v. United States*](https://www.supremecourt.gov/opinions/17pdf/16-402_h315.pdf), a person does not surrender his or her expectation of privacy merely by public exposure. Moreover, the district court failed to account for the nature of the Government’s intrusion. Harper’s lawsuit arises from a so-called John Doe summons, which is intended to allow the IRS to investigate a specific taxpayer (or a group of taxpayers) whose identity is not known to the IRS. But the IRS’s summons here was not specific at all; rather, it was akin to a drag net, designed to collect a broad swath of information on more than 10,000 users, in which the plaintiff, James Harper, happened to get caught. As Congress recognized when it authorized John Doe summonses, the privacy intrusion is more severe when an agency uses its subpoena power to conduct a fishing expedition. The Fourth Amendment does not allow the Government to do so. For these reasons, this Court should reverse the district court’s decision as it relates to Harper’s Fourth Amendment claim. ## https://www.paradigm.xyz/writing/paradigm-files-amicus-brief-in-sec-s-case-against-binance # Paradigm Files Amicus Brief in SEC's Case Against Binance > Paradigm filed an amicus brief in the SEC lawsuit against Binance. Paradigm was not an investor in Binance and has no direct financial interest in the outcome of the lawsuit. However, we believe it is critical to stand against government overreach regardless of who the defendant is. **TLDR**: Paradigm filed an [*amicus*](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-525784c7d8/c34230e9fbb84546fa2674eaf62852b9/asset-https-cdn-sanity-io-files-dgybcd83-p-525784c7d8.pdf) brief in the SEC lawsuit against Binance. Paradigm was not an investor in Binance and has no direct financial interest in the outcome of the lawsuit. However, we believe it is critical to stand against government overreach regardless of who the defendant is. Here, the SEC is attempting to leverage the disturbing allegations it levies in its complaint to change the law while circumventing the rulemaking process. The SEC is plainly acting outside the scope of its authority and we oppose this gambit. The SEC’s lawsuit against Binance is one of three cases the SEC brought against crypto exchanges, through which the agency seeks to lay claim over crypto secondary markets. Chair Gary Gensler himself acknowledged in Congressional testimony that the SEC lacked the authority to regulate these same secondary markets, [noting](https://www.congress.gov/event/117th-congress/house-event/112590/text) in clear words that “the exchanges trading in these crypto assets do not have a regulatory framework.” As our brief points out, the SEC’s theory in this case would upend what we know about securities law in several critical ways. First, it would require this Court to accept the facially incredible argument that an “investment contract” does not require a “contract.” The clear statutory language and case law interpreting it makes clear that an “investment contract” requires contractual undertakings that promise the delivery of future value. A crypto asset sale, particularly one on secondary markets, promises nothing, other than the delivery of the crypto asset. The SEC cannot manifest a formal contract where none exists through clever lawyering. Second, the SEC’s theory would improperly place all sorts of ordinary asset sales within the reach of the securities laws. Courts have long held that the mere fact that an asset might appreciate in value due to market forces does not mean there is a “reasonable expectation of profits” that makes the sale of the asset an investment contract. Moreover, an asset sale cannot create a common enterprise, a necessary ingredient for an investment contract. A shared hope that an asset will appreciate in value might create a common *interest*, but that hope does not constitute a common *enterprise*—especially as there may be no relationship between the asset’s issuer and a secondary purchaser far down the line. Finally, the SEC’s attempt to regulate crypto assets through its capacious and unreasonable interpretation of “investment contract” must fail under the major questions doctrine. The regulation of crypto assets is of such economic and political significance that the SEC needs “clear congressional authorization” to engage in such regulation. A 77-year-old interpretation (*Howey*) of a 90-year-old statute (the Securities Act) hardly delivers such clarity. Regulatory gaps exist in crypto, as the Chair himself has acknowledged in the past—only Congress can and should fill those gaps, not the SEC. ## https://www.paradigm.xyz/writing/casino-on-mars # The Casino on Mars > Settling the crypto frontier begins with a speculative step. It’s useful to think of crypto as a new planet that’s being settled. Skeptics see a desolate planet without purpose. Or worse, a haven for an unsavory casino. Optimists see the planet’s potential: a blank slate on which we can build an upgraded financial system and internet platform. Early settlers are a mixed bunch. Explorers drawn to the frontier. Speculators, some rough and disreputable. Innovators and researchers, attracted to what’s newly possible. Ordinary people, especially those marginalized on Earth. Governance remains ambiguous. Some Earthly jurisdictions prohibit their citizens from visiting. Others seek a foothold in the new world. A history of speculation and hype cycles has cast a social taboo over the new planet, leaving many to wonder: what is its future? Today’s casino-like speculation is part of a bootstrapping process. Much like the gold rush of 1849 transformed San Francisco from a quaint village into a major port (and ultimately the heart of tech innovation), today’s speculative frenzy in crypto is attracting the settlers and catalyzing the infrastructure necessary to turn a barren planet into a thriving crypto civilization. ![A new crypto planet.](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--1f62d56d20/61e443182663870b6dbb4b4e2a9910e6/asset-https-cdn-sanity-io-images-dgybcd83--1f62d56d20.png) *A new crypto planet.* ## Why crypto? Settling a new planet is a lot of work. Why is it even worth doing? A new system of property rights is most needed in places where existing systems fail. Crypto-based money like BTC, ETH, and stablecoins are used worldwide, but they are most differentially adopted by ordinary people in places like Argentina, Turkey, and Ukraine. Many skeptics wonder when crypto’s “killer app” will arrive, but it turns out it’s already here. A form of first-world privilege is at play for those who can’t see it. Like the fish who asks, “What the hell is water,” crypto can be hard to appreciate when strong property rights, economic freedom, and monetary stability are taken for granted. Ask anyone in Argentina about crypto, and they don’t doubt its usefulness for a moment. Today, crypto money is useful at the low end and speculative at the high end. But it’s improving fast, and—in a classic case of Christensenian disruptive innovation—crypto is rapidly becoming more useful to more people. Money is the first killer app, but it won’t be the last. Crypto money leads naturally to crypto financial services that are transparent, programmable, and openly accessible. Many lack access to banking due to high costs. Others mistrust a banking system that’s increasingly centralized. Crypto finance offers cheaper, more convenient, and more inclusive solutions. Stablecoin payments are on the rise. Loans are accessible via code rather than an elaborate bank or brokerage process. Even systemic risk can be reduced through global tracking of collateral. Looking beyond money and finance, as crypto infrastructure scales it will enable new consumer applications. We’ll see creators taking ownership in their creativity, and users taking more control over their identities. Zooming out, the new planet is an opportunity to build anew. Crypto can do for money, finance, and digital property what the internet did for information and media. Many existing systems are brittle and sclerotic—descendants of a pre-digital era. With crypto, we’ll upgrade systems and build new systems that weren’t possible before. As importantly, crypto is a bulwark against a world that’s increasingly centralizing. People eagerly choose sides in the war between Big Media vs Big Tech, or Big Banks vs Big Government, but like the boiled frog, we have unknowingly conceded a world in which everything is “Big”. By enabling the small and the many to coordinate, crypto is a vital counterbalance against centralized power and, ultimately a force for freedom in the world. ## Speculation and crypto Although crypto may have benefits, is all this speculation necessary? It turns out that speculation is not just necessary but also productive. Speculative investment is integral to technological revolutions. From the telecom and internet boom to the rise of railroads, electricity, and automobiles, new tech breakthroughs are consistently entwined with speculation and asset bubbles on the way to mainstream adoption—a phenomenon that Carlota Perez has documented well. Speculation within crypto helps drive attention and awareness, investment dollars, talent inflows, infrastructure building, academic research, incumbent adoption, and more. But speculation and crypto also have a deeper tie: speculation is the “hello world” of digital property rights. Enable people to create scarce assets, and they’ll tend to trade them around. Just give a group of kids some Pokemon cards and watch what happens. The whole point of a new system of property rights is to reliably record property transfers, so, naturally, people will experiment with them. And if this new system doesn’t yet have broad legitimacy, then the cone of possible futures is wide, so prices will be volatile, and trading activity will look speculative. In the early days of Bitcoin, to think it would someday reach the legitimacy and value it has today seemed crazy—I remember because I was there. Early participants had fun. They mined, contributed, experimented, and even bought pizzas. Now, more than a decade later, BTC and other crypto assets like ETH are well on their way in the transition from speculative toys to global monetary commodities. Speculation has also been critical to the growth of crypto as a decentralized financial system. Many financial products have so-called “utility” on one side of the transaction but require speculation to fulfill the other side. For example, a person might need a 30-year mortgage to afford their home, but there is no natural demand to lend for 30 years against a home. Instead, our modern financial system intermediates between the utility demand for a mortgage and the more abstract financial demand for yield. In crypto, an analogous financial system is being built that includes speculative traders, exchange infrastructure providers, market makers, MEV searchers, block builders, DeFi protocols, stablecoin issuers, Uniswap arbitrageurs, and the like. This new crypto financial system requires bootstrapping an N-sided market, which isn’t easy and takes time. But with each passing year, participants become more sophisticated, liquidity increases, and the onchain financial market grows more capable. ## The casino’s dark side Much crypto skepticism is unimaginative, but some is well-earned. Although the casino is a helpful bootstrap, it can also be unsavory and counterproductive. Innovation depends on capital and labor applied to worthy experiments. Too much speculation, airdrop farming, and other shenanigans add noise to the price signal that would otherwise inform productive innovation. Even the most well-meaning entrepreneurs can be tricked by fake prices or distracted by short-term profits, ultimately slowing down the process of building what crypto actually needs. Short-term speculation is also a zero-sum game, with sophisticated traders extracting value from newcomers and possibly burning them forever. A free market admits all kinds of participants, and there’s nothing per se *wrong* with short-term traders as long as they behave legally and ethically. But if we view crypto adoption as partly a social coordination game, then choosing the optimal time horizon can be a prisoner’s dilemma. We might all reach a more inspiring endgame by collectively thinking longer term. Lastly, there are too many bad actors: scammers, rug pulls, and blackhat hackers. Imagine a roving gang of bandits who greet newcomers with a beatdown and a mugging—welcome to San Francisco crypto! Like the Wild West or the early internet, the open frontier enables innovation but also misbehavior. Good actors far outweigh the bad—for example, crypto is lucky to have some of the world’s leading whitehat security experts—but some self-regulation or regulation may be needed. ## What’s taking so long? Crypto is almost 15 years old. Shouldn’t it be mainstream already? It turns out that settling a new planet takes time, and most people won’t move to the new planet until the infrastructure is mature and it is no longer socially taboo. The tech can only advance so fast. Social diffusion of new ideas can be erratic. And the speculative nature of the asset class leads to cyclical whiplash: one moment crypto is the future of everything, the next moment crypto is dead. Building social consensus around crypto can be even more challenging than growing a network effect around a communication protocol or a social network. People immediately see the utility of WhatsApp or Instagram since they can communicate with a small number of friends they already know. A new system of property rights is about safely transacting with people you don’t already know or trust and therefore requires more generalized legitimacy. There’s a long way to go, but it’s remarkable that you can already transact with over 100 million people using BTC, ETH, or stablecoins today. ## Looking past the casino Many of the technologies we now take for granted were once considered impossible, useless, dangerous, and/or fraudulent. Today, Apple is the world’s most valuable company, but when it first went public in 1980, Massachusetts barred sales of Apple stock due to its riskiness. Andy Grove, the CEO of Intel, said in 1992 that “the idea of a personal communicator in every pocket is a pipe dream driven by greed.” A Boston newspaper said of the telephone in 1865: “It is impossible to transmit the human voice over wires… and were it possible to do so, the thing would be of no practical value.” Crypto is no different. Bitcoin has famously been proclaimed dead [every single year since 2010](https://buybitcoinworldwide.com/bitcoin-is-dead/). People frown on crypto’s perceived riskiness, volatility, and speculative nature. Skeptics argue that the technology won’t scale or is insecure; even if it worked, it would be useless. There is a strong bias in favor of the status quo and against change. Sometimes, the more disruptive the change, the stronger the skepticism. Crypto touches on profound ideas around money, value, governance, and human coordination. These are not topics that we are accustomed to reconsidering, and it is natural that some people find it absurd to try. But their foundational nature is all the more reason to be open to building something better. The presence of skepticism is not an argument against crypto, but equally, it’s not an argument for crypto. Many hyped technologies fail, and crypto may fall short of expectations. The most reliable way to figure this out is to disregard the external environment of skepticism or hype and to think independently. Try visiting the new planet. Look past the speculative activity toward what substantive builders are building and what real people are using. Crypto speculation may sometimes be distasteful, but it’s part of the bootstrapping mechanism for one of the most important technologies of our time. *Special thanks to Vitalik Buterin, Brian Armstrong, Dan Romero, Andrew Huang, and Paradigm team members Fred Ehrsam, Dan Robinson, Charlie Noyes, Georgios Konstantopolous, Arjun Balaji, Frankie, Caitlin Pintavorn, Dave White, Doug Feagin, samczsun, Jackson Dahl, Alana Palmedo, Katie Biber, transmissions11, and Brendan Malone for discussion and feedback.* ## Appendix If we think of crypto as a new planet, what implications might that have? ### Crypto Community - Crypto is an integrated ecosystem, and we should all work together. Different cities on the new planet have more in common than not. Convincing people on Earth to settle on the new planet, or protecting the planet from ill-considered Earth regulations is more important than maximalist infighting. - As Vitalik has observed, it may be important for crypto to think about building a full stack. The new planet won’t always be able to rely on Earthly infrastructure. There is the default internet stack: Google, Twitter, Github, credit cards… There is an independent Chinese internet stack: WeChat, Alipay, Weibo, DCEP… And crypto may need to build an independent crypto stack: like the Chinese stack, but instead going in the direction of more openness and self-sovereignty. - It may be healthy for a new planet to have its own culture. We may not actually want crypto to disappear into the background or for the new planet to be maximally similar to Earth. ### Builders - Building a product in crypto is both a technical question (“What can be built on the new planet?”) and a social question (“Will people on the new planet want this?”). - A good source of crypto startup ideas is to think about what early settlers on the new planet might need. The casino goers need food or lodging? Consider building that. - Another good source of crypto startup ideas is to think about how the new planet is different and what unique products might be enabled. Gravity works differently? New products may be possible as a result. - Some products are best thought of as building for settlers on the new planet (DeFi). Others are bridges between the new planet and Earth (CeFi). Still others might be building for Earth using technology from the new planet (Fintech using stablecoins). - One failure mode is to build for a mainstream user far before they are ready to move to the new planet. It is better to focus on people already native to the new planet or people on the cusp of visiting. - Conversely, another failure mode is to build too much for the early settlers and not enough for the potential waves to come. ### Incumbents - Incumbent Earth businesses have a role to play. Most naturally as a bridge between Earth and the new planet but possibly also in building native products. - Think of crypto as an emerging market. It’s as much about adopting a new technology as it is about landing on a new planet with its own culture. Like restaurants adapting menus for different countries or businesses hiring local GMs, it is helpful to adapt your team and product to the new planet’s idiosyncrasies. - One failure mode is to misunderstand the unique attributes of the new planet. For example, it was popular for a time for banks to be excited about “blockchain, but not Bitcoin”. That’s like putting up wallpaper to make your bank look more like the new planet. It’s still a bank on Earth and misses the point completely. ### Policymakers - Counterintuitively, crypto might end up being a boon to the US Dollar. USD stablecoins are one of the most popular currencies on the new planet, far more dominant than any other Earth currency. - It can be tempting to see the Wild West activity on the new planet and to take overly aggressive action, like banning travel to the new planet, or heavily restricting the activity that takes place there. But this will prevent the new planet from getting past this bootstrapping phase to the innovation that is possible in the long run. - It would be better to take a long-term view. Let there be safe harbors and permissionlessness. Punish bad actors when they commit crimes. But preserve the openness for the good actors to pursue experimentation and innovation. ## https://www.paradigm.xyz/writing/electronification-trading-crypto # Electronification, Trading, and Crypto > An analysis of the historical evolution of financial markets — and why crypto is about more than just making existing processes digital. \[[Printable version here](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-2c22d601b2/6b36f6186b5b6becd03c465014d3433c/asset-https-cdn-sanity-io-files-dgybcd83-p-2c22d601b2.pdf)\] ## 1. Introduction This paper presents a framework for thinking about the technological change of markets and the characteristics of public blockchains that enable the financial system to be reengineered to be more open, fair, and efficient. Since 2009, technologists, financiers, academics, and policymakers have speculated about whether blockchain technology is the next truly revolutionary technology to hit finance or just a “[solution in search of a problem](https://www.fastcompany.com/90764813/banking-blockchain-a-solution-in-search-of-a-problem#:~:text=Blockchain%20is%20a%20database%20that,follow%20rules%20to%20ensure%20trust.).” We think this framing misses the broader historical relationship between technology and progress. Markets are ultimately human-social phenomena. Our laws and policies influence markets in different ways to better serve their users and broader society — but this does not happen in a vacuum, nor does it happen without friction or resistance. Technology is inherently subversive, and it’s inevitable. Markets are usually resistant to change in the short term, but they are ultimately complex systems that allow for change to occur at [multiple timescales](https://aeon.co/essays/complex-systems-science-allows-us-to-see-new-paths-forward) in compounding fashion. To some, it might look like crypto has been slow to change how financial markets operate. However, more and more people and institutions from “traditional” backgrounds in finance and engineering are entering the world of crypto *everyday*. Stablecoins have found product-market fit. Treasuries are trading onchain. And central banks — once anathema to crypto’s ethos — are [forking popular DeFi protocols](https://www.bis.org/about/bisih/topics/cbdc/mariana.htm) for use in cross-border payments. Change is here, if you know where to look. In future parts of this series, we intend to dive deeper into specific markets and mechanisms to show how public blockchains are a positive force for society and how they can achieve the same or better policy outcomes as more traditional market designs. ## 2. Historical perspective on technological change The consumer computing and networking revolutions of the past decades have truly transformed financial markets and banking. Computers and the internet are now fundamental to every interaction we have with the markets. Checks, once flown around the country for physical settlement, can now be accepted and processed electronically using our smartphone cameras. The chaos of the open outcry trading pits have been replaced by the quiet hum of co-located servers sending millions of orders at sub-millisecond frequencies. The origins and impacts of these developments in electronification are difficult to parse because technological enhancements reached different markets at different times. **However, one underlying theme is clear: financial markets are often reactive, usually hesitating to embrace change or acknowledge its advantages until a crisis catalyzes — and embeds — innovation and structural change.** Absent shocks, gradual adoption of new technologies is a long and nonlinear process. We examine two pivotal periods of electronification in the US financial markets as a means to provide contextual framing to understand how and why and how financial markets evolve. This is by no means an exhaustive case study, but rather some historical staging for what we believe is the next step in the evolution of markets. *The Paperwork Crisis and Electronification of Bookkeeping* In the late 1960s, Wall Street faced a series of crises relating to its ability to record and settle trade-based transactions. This would later be termed the “[Paperwork Crisis](https://www.lexology.com/library/detail.aspx?g=1f852fff-a3f8-475b-96c2-6badec65358a),” and its effects would ultimately stand out as the first consequential push into electronification. At the time, processes around stock trade clearing and settlement were complex and manually intensive. When a stock trade occurred, the seller had to physically transfer the paper stock certificate to the buyer. This transfer first required the intermediary step of getting the certificate notarized. Once acquired, the purchaser had to physically transfer the certificate to the issuing company’s transfer agent to manually record the new ownership for future dividend payments. The transaction was only considered complete once the transfer agent issued a new certificate in the buyer’s name. Brokers facilitated these trades on behalf of their clients and had to manage these intensive processes. Some of these processes required more than 60 individual steps, and any error could invalidate the trade or incorrectly log it. While these processes were adequate for much of the 1950s, a sharp rise in daily trading volumes from 4 million in 1960 to over 12 million by 1968 led to a backlog of paperwork. This culminated in the “[Paperwork Crunch](https://www.jstor.org/stable/3116692),” which saw stock exchanges like the NYSE close every Wednesday to give everyone an opportunity to address the week’s backlog of paperwork. Although some brokers used mainframe computers, they were prohibitively expensive and offered minimal help in the most cumbersome parts of the process — the physical stock certificate transfer. Under pressure and stress, the number of erroneous trades logged by brokerage clerks skyrocketed. In one now-infamous example, Lehman Brothers discovered “in May 1968 that it had [$473 million](https://www.jstor.org/stable/3116692) in securities whose owners it could not locate, and that it owed clients $219 million in securities that it could not find.” The period forced one of the most consequential reevaluations of securities trade clearing and settlement systems and the technology they relied on. In 1971, the world would see the launch of the “first electronic stock market”— the NASDAQ. In 1973, the Depository Trust Company (DTC), was founded to immobilize certificate transfers by custodying them in a single depository and simplify settlement with a unified accounting ledger. *Sept 11th and the Electronification of Check and Securities Settlement* Exogenous events also played a significant role in the adoption of innovation. Despite the consumer computing revolution in the 1990s, electronification was slow to come to the clearing of physical checks only until after 9/11. When the U.S. government grounded air travel, paper checks could not be transported around the country to facilitate clearing and reconciliation (the requirement at the time was that checks had to be returned to the paying bank). It was not until the passage of the Check Clearing for the 21st Century Act ([Check 21](https://www.clevelandfed.org/en/publications/economic-commentary/2009/ec-20090609-the-check-is-dead-long-live-the-check-a-check-21-update)) that the market was able to leverage technological improvements to speed and efficiency by making it legally permissible to clear images of paper checks instead of the paper copy itself. Similarly, in 2012, the move to dematerialize (e.g., make electronic representations of paper certificates) securities was turbocharged after the DTCC, which houses the majority of U.S. stocks and bonds, found one of its securities vaults [flooded](https://www.reuters.com/article/us-storm-sandy-securities/dtcc-finds-1-3-million-soaked-securities-in-sandy-flooded-ny-vault-idUSBRE8AE02G20121115) during Hurricane Sandy. In total, nearly 1.7 million security certificates stored in a lower Manhattan skyscraper had been damaged. ## 3. Decomposing the trading stack Technology and market structure are intertwined. **In many cases, technological adoption conforms to an existing market structure. In other cases, new technologies allow for new actors to disrupt a market’s existing structure, radically altering the underlying organization of the market and the actors that trade in it.** This makes it difficult to parse the effect of market changes that derived purely from technological changes, on the margin. Unpacking the independent components of technology and market structure design that make trading possible — the “trading stack” — is one way to analyze the impacts of technological changes. [^1] So, what makes up the trading stack? - **Network.** The collection of people, relationships, and technology that allow for the exchange of information between multiple parties in a financial transaction. - *Examples: phones, face-to-face, electronic messaging, etc.* - **Custody and settlement.** The technologies or media that allow for the recording, transfer, and custody of assets. - *Examples: paper ledgers, paper bearer instruments, digital ledgers, tokens, etc.* - **Coordination and process.** The set of rules, norms, or business logic that describe — and enforce — how a transaction occurs. - *Examples: norms, enforced rules/regs, business logic, smart contracts, etc.* - **Price discovery.** The form and mechanism that allow for assets to be priced. - *Examples: form (electronic vs. analog) and mechanism (RFQ, CLOB, AMM)* This is obviously an imperfect and (mostly) theoretical exercise. Depending on the specific instantiation of the trading stack it can be almost impossible to cleanly disaggregate overlapping and often codependent components. However, we believe there is still value from an analytical perspective in having the ability to “toggle” different technological and organizational assumptions at different layers of the stack and assess the implications on the overall system. We therefore use this framework for thinking through the past, present, and future of trading with a particular focus on recent market designs made possible thanks to public, permissionless blockchains. ## 4. Real-world RFQ trading stack (c. 1700) Imagine a remote-trading system that uses an RFQ mechanism to price securities issued to fund frontier exploration projects. The system is accessible to traders across Europe, who use it regularly to buy and sell securities. This sounds like some bond-trading platforms that are currently used today. However, in our hypothetical example, it is 1700 and computers, the Internet, and phones have not yet been invented. The trading stack is as follows: - **Network.** An exchange in Amsterdam with traders in Amsterdam, London, and Paris. Assume for the sake of the example that the fastest and most-reliable form of communication between London, Paris, and Amsterdam is by homing pigeon. Pigeons can fly roughly [60 mph across a distance of up to 600 miles](https://archive.aramcoworld.com/issue/201102/cairo.s.fancy.fliers.htm). - **Custody and settlement.** Paper certificates held in self-custody by traders. These are too large to fly by homing pigeon, so physical settlement of trades occurs 14 days after trade execution. - **Coordination and process.** The Amsterdam Stock Exchange (ASE), which is open from 9:30am - 4:30pm CET, Monday through Friday. Once a trade is submitted, that trade is valid until a subsequent trade is received from the same trader or the end of the day, whichever happens first. - **Price discovery.** Analog system using the RFQ mechanism where prices are manually submitted to the exchange, where they are matched and routed accordingly. This system is arbitrarily inefficient. If a trader in London wants to execute a trade, they first have to send a homing pigeon to Amsterdam. At 223 miles straight-line distance, it would take the pigeon roughly 3 hours and 45 minutes to reach the ASE. Upon arrival, the ASE will manually match the trader with Amsterdam-based market makers who can provide a quote for the trade the trader is looking to execute. Additional back-and-forth communication (w/ standard pigeon-message latency) is required for the trader to receive and conditionally accept a quote, which again requires additional communication for trade settlement and reconciliation. You can see from this example how market structure and technology are mutually reinforcing. With a single trader and multiple market makers centrally located at the ASE, it is already difficult to imagine this system working in practice. There are numerous places where the technologies used circumscribe the market structure possibilities and introduce inefficiencies and risk (e.g., what if a pigeon goes down over the English Channel?). That said, the underlying price-discovery mechanism (i.e., RFQ) requires relatively little in the way of complicated infrastructure. The ASE serves as a central routing hub for matching traders to market makers, but it does not need to maintain an order book or keep track of trader/dealer inventories. How would technological improvements change these dynamics? Electronification of the **Network** layer would reduce latency in message routing, but without attendant electronification of the **Custody and settlement** layer of the stack, paper certificates would still need to change hands 14 days after trade execution. Digital databases coupled with electronic messaging would improve pre-trade and post-trade activities, but may not be enough to structurally alter the design of the market: due to the [double-spend problem](https://csrc.nist.gov/glossary/term/double_spend_problem#:~:text=Definitions%3A,networks%20are%20designed%20to%20prevent.), a centralized entity, such as the ASE, is still required to facilitate asset transfer, even if settlement itself is as simple as updated electronic records in a database. This is more or less how the first wave of electronification unfolded in the fixed-income securities space (as described above) with electronic trading venues offering a better way to coordinate at the pre-trade and execution levels, while custody and settlement remained centralized and paper-based. ASE could conceivably use a CLOB or CFMM to calculate prices without any additional changes to technology or market structure. Of course, this heavily constrains subsequent market structure designs (i.e. requires institutional intermediation) and places a high degree of responsibility on ASE. - ASE is required to manage technical infrastructure, including physical hardware and exchange software, which requires significant upfront capex. Any automation or interoperability between ASE systems and external systems depends on ASE making them compatible, and physical proximity to ASE’s systems has implications for latency and trade execution. - Market participants need to trust that ASE will operate the market in a predictable manner in accordance with predefined rules, which likely allow significant management discretion. - Market participants are exposed to counterparty risk as a result of the role that ASE plays as custodian. **Much of the story of electronification to date has involved making existing processes digital but not dramatically altering the shape of the trading stack.** This limits the subsequent market structure design space due to its continued heavy reliance on intermediation (of assets, technology, and communications) by specific institutions. ## 5. Enter: blockchain trading stack Permissionless blockchains enable new structures not previously possible with the traditional trading stack. To grok this point, imagine trying to implement an AMM like Uniswap v3 using homing pigeons in the 1700s and the market layout described in the previous section. De-electronifican by analogy. Conceptually, you have the modular components necessary to make it work in a narrow sense, but it would not be efficient or extensible. **One technological advantage of public blockchains comes from the fact that the entire trading stack is integrated into a single cohesive system that is participant agnostic.** Anyone can make a market for any asset, because the entire trading stack is public infrastructure that is not owned or controlled by any one person: - **Network.** Nodes running blockchain protocol client software, which lets them communicate with each other and the underlying data structures. - **Custody and settlement.** Tokens representing digital assets that can be transferred between users and held in custody by users and smart contracts. - **Coordination and process.** The blockchain protocol, which forms the base layer for communication and coordination, and the smart contract protocol that executes the basic business logic of the exchange mechanism. - **Price discovery.** A simple formula (e.g., xy=k) that leverages the smart contract logic and underlying pool of tokens held in smart contracts. Let’s go back to our previous example of the homing pigeon-based market structure. To point to a specific market structure improvement enabled by technology, we will highlight a feature that is fundamental to the blockchain space. A problem (just one of many) with the pigeon-based market structure is that an adversarial market maker can send pigeons to the ASE imitating their competition’s orders (spoofing). In blockchain-based markets, the nodes ensure that the transaction came from the specified user by using various cryptographic protocols. For example, Ethereum validators use signatures based on [Elliptic Curve Digital Signature Algorithm](https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm) (ECDSA). To ensure that this trade was not spoofed by an adversarial market maker, the homing pigeons could transport ECDSA-compliant signatures between London and Amsterdam. However, even with a team of trained abacus users, it would take multiple days to calculate the signature, which would be invalid with any error. The calculations needed are far from trivial as well. On the other side, ASE abacus users must also verify the signature before any action can be taken, which also extends the time until the market actions can be confirmed. Technological improvements enable these signatures to be generated and verified to be correct nearly instantly inside your browser. Creating and verifying these signatures are the bedrock of the blockchain-based markets because they obviate the need for multiple layers of institutional intermediation. Additional utility comes from the fact that the protocol can, on its own, execute complex business logic, such as calculating (in near real-time) the price of an asset. This shift is not without consequences. Blockchain-based markets must charge for the amount of compute that is used, which is a dramatic shift from how traditional finance markets have evolved. This has led to the general acceptance of automated market makers, which attempt to maximize market efficiency for relatively small levels of compute. Of course, this is just one application of permissionless blockchains to market design and does not even consider the benefits that stem from having embedded clearing and settlement infrastructure. ## 6. Conclusions and potential areas of future exploration We are still in the early days of blockchain-enabled financial innovation, but it is clear (to us) the coming wave of change will transform markets in profound ways. Today, most financial markets operate in a suboptimal equilibrium, having arrived at their current structure through a series of organic processes as opposed to thoughtful, deliberate engineering. Regulation and competitive dynamics play a significant role in the ability and willingness of market participants to change their practices, but so too does the availability and applicability of existing technologies. The U.S. Treasury market is one such example. Putting the U.S. Treasury market on a blockchain would not solve all of the market’s woes, but it would open a new design space by making it possible to create a single market that retains the modular interoperability necessary for customization for specific segments and use cases. **The same pool of tokenized securities can be used across a wide range of market participants and protocols.** For example, the U.S. Treasury market is often described as the most important financial market in the world. However, the U.S. Treasury market is not functionally a single market, but rather a complicated collection of multiple sub-markets that serve different users and employ different technologies. Government officials [have proposed](https://www.newyorkfed.org/medialibrary/media/research/staff_reports/sr1036.pdf?sc_lang=en) a number of reforms that would reduce fragmentation in the market, which could improve market functioning by reducing the need for trade intermediation. Of course, this is not without challenges. Depending on the market segment, trade execution happens via anonymous RFQ, CLOB, match auctions, or by streaming quotes. Clearing and settlement may involve any number of entities, including the Federal Reserve, the DTCC, or the Bank of New York Mellon. Integrating the market into a single trading stack is a tall task, both in terms of technology and coordinating challenges — but it is made easier by the blockchain stack. The opportunities become even more apparent when you consider the benefits of composability. **A payment stablecoin can be used as the cash-leg of a repo transaction with a DeFi protocol and a tokenized Treasury security, and neither the issuer of the stablecoin, developer of the protocol, tokenizer of the Treasury, nor the network validators need to coordinate with (or trust) each other in order for the transaction to work.** This would be a sea change in both digitization, interactivity, and customization. We would go from markets that most users must accept as they find them to ones where everyone can begin customizing their tech stack. The market structure shifts enabled by blockchains is something that we will delve into more deeply in coming posts. Through this lens we can begin to ask a number of questions related to the design of better markets. For example: - What does settlement look like in a world where it can be fine-tuned, so it no longer has to conform to market conventions around specific times or intervals? Is it possible to build primitives that let you choose settlement time, and what implications would such designs have on market functioning? - What systems could we build if we started from scratch with modern technology, as opposed to the skeuomorphic adoption process that currently dominates the world? Should we bring blockchains to markets that do not currently use them? Should we combine blockchains with more traditional market designs to leverage the benefits of both? - How might blockchains enable a move from price-time priority markets to markets based on fees and competition, and what might that mean for market structure (and consumers)? If these questions excite you, please let us know. Efficient market structure and design is of critical importance to capital formation and international competitiveness and is an important component of effective public policy. ## Acknowledgements [Mary-Catherine Lader](https://x.com/Mclader), [Dan Robinson](https://x.com/danrobinson), [Maude Wilson](https://x.com/maudesilwil), [Marco Machiavelli](https://sites.google.com/view/marco-macchiavelli-webpage) [^1]: Note: This framing uses the term “trading” in a general sense to mean “any activity that facilitates the exchange of goods or value from one person or entity to another.” It covers the entire trading life-cycle, inclusive of the pre-trade, execution, and post-trade stages. And it is asset-class agnostic and can be applied across cash, commodities, securities, derivatives, tokens, and more ## https://www.paradigm.xyz/writing/rivet # Introducing Rivet > Rivet is a developer wallet & tools, akin to React DevTools. It enables developers to inspect, debug, modify, and manipulate the state of Ethereum. **We are excited to announce the alpha release of Rivet, a free, open-source developer wallet & tools for EVM-based chains.** We built Rivet to improve the frontend development experience, and to unlock new productivity frontiers for developers. Find out more below. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--8fa2bf1d52/b41032b06223d44be2593c1d1f30a539/asset-https-cdn-sanity-io-images-dgybcd83--8fa2bf1d52.png) ## What is Rivet? Rivet is a developer-focused wallet & DevTools for Ethereum - a browser extension that enables developers to inspect, debug, modify, and manipulate the state of a local Ethereum node. Centered around common workflows of frontend Ethereum development, it is compatible with any Ethereum DApp, and comes with many advanced features out-of-the-box. Rivet is MIT-licensed, and free for anyone to contribute, use, or fork. We are excited for the community to build Rivet with us, so feel free to reach out if you’re interested in contributing! Rivet is a browser extension that allows users to connect to any Ethereum app and has all the table-stakes features one would expect in a wallet, i.e. manage multiple addresses, sign and submit transactions or messages, and view your transaction history. ## Why build a developer wallet? We built Rivet for 2 core reasons: - Developing against a local Ethereum node is a pain with consumer wallets as they simply aren’t designed for it. Constant state changes (and restarts) on a local Ethereum node cause these wallets to become out-of-sync and generally have poor reactivity (e.g. on some consumer wallets, you have to remove and re-add your account to reset the nonce, as most wallets do not react to nonce resets) - Other developers debug against testnets or even worse, mainnet. Developing against a testnet can work as you can easily fund yourself with a faucet and test transaction flows easily; however comes with the trade-off of not being able to replicate mainnet network conditions & state. Developing against mainnet can also work as you can develop against live network conditions & state; however comes with the obvious trade-off that you are spending real money on fees. Both of these methods are not an ideal approach to debugging & testing end-to-end flows. By building a developer-first wallet, we can encourage developers to follow the best practice of introspection, testing, debugging against a local (forked) Ethereum node. Rivet is an enabler to working with a local node end-to-end, tapping on functionality not accessible by widespread consumer wallets. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--ed6c894ded/58df75f0c8210cb6292178e2e5ed49f2/asset-https-cdn-sanity-io-images-dgybcd83--ed6c894ded.gif) ## What makes Rivet special? Rivet is special because of its tight integration with Foundry’s Anvil. This allows for deep testing, debugging, and modifications in DApps. Rivet is “DevTools for Ethereum”; to put it as an analogy, it is similar to “React DevTools” or “Developer Tools (⌥⌘I) for the browser”. Here are some of Rivet’s differentiators to other wallets: - Large real estate on the side of the browser instead of a small popup, allowing rich information display about the state of Ethereum. - Automatic node sync & auto-adjusting nonces/accounts depending on the network you are connected to (no more reset nonces on every network change!) - Forking mainnet, allowing “sandbox” interactions on the live network, is especially useful when testing your DApp’s integration against live applications. - Configurable interval for block production, click-to-mine, and overriding block fees. - Account Impersonation allows you to browse and interact with any DApp as any address! - Account Overriding allows you to edit the nonce or balance of any account. Storage Slot overriding coming soon! - Listing all blocks, drilling into mined transactions, viewing pending transactions in the mempool in between blocks / when block mining is paused – almost like a mini-block explorer. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--3c7e8ae372/be1b087433313470f422c5a045602f93/asset-https-cdn-sanity-io-images-dgybcd83--3c7e8ae372.png) ## What is next for Rivet? Rivet is still in early development, and we are looking for contributors both in the implementation, but also in idea space. If you are a frontend developer who is excited about building this with us, please reach out. Some things we are excited about: 1. Improving the UI/UX of using Rivet 2. Time Travel for undoing 1 or more actions (instead of resetting!) 3. Reading & writing token (ERC20/721 etc.) balances, or other storage slots 4. ABI-decoded calldata, logs, state changes and traces 5. Tighter integration with Forge build artifacts 6. Keyboard shortcuts 7. ..and more! If all of this sounds exciting, please reach out to [georgios@paradigm.xyz](mailto:georgios@paradigm.xyz) or [achal@paradigm.xyz](mailto:achal@paradigm.xyz), reach out to [Tom](https://twitter.com/awkweb) & [Jake](https://twitter.com/jakemoxey), and read the [Contributing Guidelines](https://github.com/paradigmxyz/rivet/blob/main/.github/CONTRIBUTING.md)! See you on [Github](https://github.com/paradigmxyz/rivet). ## https://www.paradigm.xyz/writing/the-open-problems-of-onchain-games # The Open Problems of Onchain Games > Or: why put games on a blockchain? The intersection of games and crypto feels rich with possibility. Vitalik was famously inspired to create Ethereum after Blizzard [nerfed his WoW class](https://about.me/vitalikbuterin). Warcraft was not “critical infrastructure,” but we expect virtual worlds to emerge that are: housing trillions of assets and millions of jobs. It is difficult to imagine them existing under the thumb of centralized platforms. Of course, decentralized applications sound good in theory. The most compelling in practice are those uniquely enabled by crypto: applications that could *only* have emerged onchain. Despite a lot of narrative momentum, it turns out to be difficult to identify precisely what onchain games uniquely enable. *Why put games on a blockchain?* This post reflects the state of our thinking on the question. ## Designing for Emergence Some games achieve long enduring engagement by giving creative users the tools to generate new content (“UGC”) themselves. Two of the richest sources of UGC - mods and open economies - are the attack vectors where we see a plausible case for onchain games. ### Mods Mods allow third-party developers to implement content beyond what was envisioned by a game’s original developer. Several genre-defining games (e.g. DoTA, LoL, PUBG) have their roots in modded versions of other games. Others, like Roblox, have transitioned from being games into being mod developer platforms. While game studios usually focus on production value, engaged modder communities bring diversity and novelty: Netflix vs. YouTube. Minecraft is an excellent concrete example. Simple game mechanics are conducive to tinkering. Mods that extend those mechanics can be recombined into functionally new experiences. Many popular Minecraft servers feel nothing like the original (prison escapes, battle royales, etc.). However, even Minecraft has a limitation: players can’t contribute new mods to existing servers. They have to start a new server to introduce changes. As a result, the Minecraft “universe” is fractured across many parallel, mostly non-interacting private servers. There are good reasons that most modern games implement mods like Minecraft, through instancing (of new servers) rather than scripting (of existing ones). It is hard to ensure that player-contributed code is compatible with native rulesets (exploits are particularly challenging). Ruleset updates may break the mods built on top of them. Limited compute resources need to be rationed intelligently. Still, instancing leads to fragmentation. Every mod that spawns a new server is in competition with all the other servers for players’ attention. Modders can’t just ask what additions to a world are interesting, they have to ask whether a change is worth starting a new server around. Consider that many potential mods may only make sense *in context* - adding to a world that already exists. For example, say you run a restaurant in some Minecraft server and want to add a new item to the menu. It doesn’t make sense to start a new server to do so, because you’d need to convince all your customers to move to it too, and they probably won’t because they have their own customers and commitments in the existing server. Game worlds that fragment lose the ability to incrementally expand. ### Open Economies In-game economies are another dimension with almost limitless potential for player creativity. We’ll use EVE, the first game to hire full-time economists on staff, as an instructive example. Across an informal combination of in-game systems and external infrastructure, EVE players manufacture and trade goods; claim, lease and contest territory; and organize everything from industrial collectives to warmongering pirate gangs. Tasks as simple as hauling resources have [full player-run corporations](http://www.pushx.net/) dedicated to their fulfillment - complete with customer service, SLAs and employee benefits. Players have come to EVE for 2+ decades not because of new content from the developer, but because of the rich emergent social and economic world driven by the other players. However, even EVE’s economy has some significant limitations: 1. **Limited In-Game Primitives.** Any transactions that fall outside the set of primitives enshrined by the developers (e.g. lending agreements) have to rely on informal, unenforceable trust networks. That trust limits the complexity and scale of emergent economic structures. 2. **Regulatory Constraints.** Due to the compliance headache, the vast majority of games (including EVE) simply block players from off-ramping any assets or exchanging in-game goods or services for fiat. Those that do allow it only do so on onerous terms and have to maintain large compliance departments. ## Onchain Games There are many different potential forms of crypto-native games. Our focus is the most crypto-native end of the spectrum: *fully onchain* games, whose state and logic live entirely on open smart contract platforms. It’s also important that onchain game mods can be permissionlessly deployed as their own contracts alongside the base game logic. And that users opt-in to mods by choosing which their clients will interpret (rather than an admin deciding for them). So, *why put games on a blockchain?* We think the strongest case rests on two points: 1. **Composable modding.** Players can add mods to onchain games without asking for permission or fragmenting their state. Onchain infrastructure and smart contract developers are conditioned for the challenges of allowing players to permissionlessly upload code: security audits, access control, resource metering, etc. Traditional games are not adapted to this environment and are unlikely to restructure themselves around supporting composable modding. 2. **Permissionless open economies.** Rather than being limited to the set of in-game primitives defined by a game’s developer or having to rely on informal and unenforceable agreements, players can use smart contracts to create a game’s economy. Moreover, sovereign player custody of game assets obviates compliance overhead. Rather than being “uniquely enabled” by onchain games, composable modding could be a path-dependent innovation. While traditional games could theoretically support composable modding, they currently don’t and have no incentive to change that. The model will only get explored by necessity (i.e., in crypto). The combination of composable modding and permissionless economies is what could yield large emergent onchain game worlds. Modders will take simple ruleset substrates and expand them with new mod content. They’ll have access to real money, proximity to DeFi markets, and freedom to experiment. The resulting economies could be highly complex and reflexively incentivize the creation of accumulating content. Once it’s legible that there is money to be made, activity could explode, in the same speculation-experimentation cycle that birthed other crypto application ecosystems. Most onchain games discourse zooms into that optimistic future at higher resolutions. We are more interested in getting specific about what stands in the way: the open problems that need to be addressed before it’s plausible for large-scale game worlds to emerge. ## Open Problems ### Technical constraints limit game design. The standard reasoning for why no onchain game has broken out yet is that the technical infrastructure isn’t ready, and thus most games get stuck at the proof-of-concept stage: simple gameplay, buggy clients, limited engagement from players and mod developers. Existing infrastructure and developer tooling is limiting. In particular, the EVM is slow and clunky, existing Solidity data models are not conducive to complex game development, and no mainnet chain is a viable deployment target for games (given high costs and low scale). Fortunately, we have line of sight on solving most of these problems. Rollup scalability and cost reduction progress is already legible to most of the crypto community. There are also many teams working on games-specific infrastructure. For example, [Lattice](https://lattice.xyz/) is developing a Solidity framework and compatible tooling (indexing, state sync, etc.) that could simplify EVM game development. Others, like [Dojo](https://t.co/sazrMbJJgP), [Argus](https://argus.gg/) and [Curio](https://github.com/curio-research/keystone) are also working on infrastructure platforms. Other problems feel more fundamental to the nature of onchain games. In particular, certain properties of permissionless blockchains prevent support for mainstay game design mechanics: - **Incomplete Information:** a crucial mechanic in many games. Existing solutions have unacceptable drawbacks (e.g. DarkForest’s [cryptographic fog of war](https://dev-guides.zkga.me/mining/what-is-mining) devolves into a hardware mining race). - **Automation & Collusion:** fundamentally cannot be prevented. Bots can’t be distinguished from real players, and players can’t be guaranteed unique. Developers must build games that aren’t broken by bot metas or by Sybil collusion. - **Ticking:** blockchains are driven by asynchronous transactions. Most traditional games are built around tick-based game loops independent of player interaction. It’s possible these constraints breed creativity and game types we’ve never seen before, similar to how MakerDAO and Uniswap emerged from DeFi without skeuomorphic TradFi analogs. However, traditional games are less technically and legally constrained than TradFi - they’ve already been able to explore more of the map - so it feels less likely that a novel onchain game will emerge from uncharted territory. We think progress likely needs to be made on the limitations to give onchain games a fighting chance at breakout success. #### Research Directions 1. **TEEs.** Although very heavy-handed for the task, Trusted Execution Environments (TEEs) are the only practical option for permissionless private computing on public blockchains. 2. **MACI.** A mechanism [originally designed by Vitalik Buterin to improve the collusion resistance of on-chain voting systems](https://ethresear.ch/t/minimal-anti-collusion-infrastructure/5413), MACI, could be adapted to onchain games and potentially improved upon through tight integration into relevant game systems. 3. **Custom Rollups.** It seems feasible to get some form of traditional ticking game loops onchain by modifying rollups to include global ticks as part of their state transition function (with no gas cost). Other games-specific modifications might be interesting as well. Using ZKPs to enable private state is another existing research direction. However, we’re skeptical that the non-programmable privacy they enable is sufficient to unlock meaningful game mechanics. The current difficulty of writing circuits also limits their usefulness. ### Composability is inherently financializing. *In a system that is open for the whole world to interact with, incentives are not just a suggestion. An incentive is more like a physical law such as gravity or entropy. If there is some aspect of the system that is not incentive-compatible, it is only a matter of time until it is exploited.* — Nikolai Mushegian, [bank.dev/principles](https://bank.dev/principles) Smart contract blockchains are highly adversarial, financializing environments. This is not a path-dependent artifact of degen culture: it is a mechanistic consequence of permissionless composability. As applications *primarily premised* on composability, onchain games will be exposed to these incentives at a primitive level. In a vacuum, before considering the impact of mods, onchain game developers will need to contend with the inescapability of real-money markets, MEV (frontrunning incentives), and economic exploits. The bar to design an incentive-compatible onchain game is likely quite high; potentially equivalent to designing a secure DeFi product. The second-order problem is even trickier. Onchain games are designed to be modded, and mods will carry their own emergent incentives. Even a developer that deftly manages core game incentives doesn’t know what will get built on top of it - or what incentives will be introduced. (Enabling such unpredictable emergence is in fact their goal.) To draw another analogy to DeFi, consider an oracle. The oracle might be economically secure (unprofitable to manipulate) in a vacuum. However, the oracle can’t predict what applications will integrate or compose with it. If a lending protocol uses the oracle to trigger liquidations, the oracle inherits the manipulation incentive - frequently fatally. Similarly, when a Minecraft mod introduces a MEV incentive to mine a block first, it will affect the gameplay of all players, even those whose clients don't interpret the mod. This is a tough problem to fix. Attempting to permission or otherwise constrain who can develop mods for an onchain game is directly at odds with maximizing emergence (the reason to build onchain in the first place). We suspect that incentive compatibility will be a defining challenge of onchain game design. Some traditional games avoid real-world money markets because of the compliance headache; many more simply think they *aren’t fun*. Onchain games will need to figure out how to leverage financialization pressures without being consumed by them. #### Research Directions 1. **Antifragile Design.** Core game mechanics can influence, but not dictate, what mods emerge on top of them. The degree to which onchain games can encourage pro social mods is an open question, as well as what types of game designs are least susceptible to corruption by N-th order incentives. 2. **Permissioning.** A direct attack on financialization is simply to control who can play an onchain game, and who can deploy new code to it. There is an obvious tradeoff with emergence, but it may be necessary to at least experiment with games in a walled garden before exposing them to harsh permissionlessness. And we can get clever about how we permission (beyond simple whitelists). 3. **Orderflow Auctions.** Instead of trying to prevent emergent incentives, we could try to harness them. For example, by forcing all game transactions through an orderflow auction that remits its proceeds to the game’s economic faucets. Any value created by mods would be pumped back into the game’s economy (e.g., by repurchasing scarce commodities). The downside is that the underlying behaviors could still hurt gameplay (i.e. players are mining coal to fund solar). ### Metagames tend towards stagnation. Onchain games will necessarily have longer release cycles than traditional games. They want to maximize emergence, and frequent breaking updates disincentivize creators from investing in worlds. Updates will also require new audits. And many onchain games builders view permissionless “autonomy” - no admin keys, no updates, infinite persistence - as a goal in and of itself. So, for technical and philosophical reasons, onchain games will sit somewhere on the spectrum of autonomy between “never updated” and “infrequently updated.” The moonshot case for a maximally autonomous onchain game is that the right ruleset substrate can spark an engaged modder community and endless new emergent experiences. Even experiences that may only be possible with decades to percolate untouched. However, most games are managed to prevent metagame stagnation. Players are already very good at figuring out optimal strategies for traditional games; now MEV will provide an additional, explicit incentive. These strategies tend to be static and uninteresting. A truly autonomous world loses the ability to control the metagame at any level - Vitalik was perhaps worried about the wrong issue with his Warlock. Rather than an innate design goal, we suspect the crucial question will be: to what degree can successful onchain games be autonomous? #### Research Directions 1. **Seasonality.** Many traditional games deploy upgrades on a cadence of months to years (like WoW expansions). The main trade-off is disincentivizing players from building complex mods which could become broken in future seasons. We think this is one of the more promising approaches to iterative experimentation. 2. **Automated Feedback.** Just as Bitcoin automatically adjusts its difficulty in response to hashrate, onchain games could build anti-stagnation retargeting into the core game mechanics. This is not specific to onchain games - centralized games’ ability to do it is strictly more powerful - but they could innovate by necessity. 3. **Novel Governance Mechanisms.** Although we are generally [governance minimalists](https://fehrsam.xyz/blog/governance-minimization), there could be an interesting space of non-token-based systems to explore. The ability to create new rules could even be a part of core game loops (e.g., [Mao](https://en.wikipedia.org/wiki/Mao_(card_game))). Some early attempts already exist; for instance, Topology [tightly integrated a bespoke governance system into their onchain game Isaac](https://topology.substack.com/p/topology-presents-isaac). ## Should Games be Fully Onchain? There might be accessible onchain game designs that leverage permissionless composability elegantly. These worlds could flourish as open economic incentives continuously drive new content, and persist indefinitely on censorship-resistant and credibly neutral blockchains. However, it’s also possible that there isn’t enough unique enablement to justify threading the needle through the open problems (which are not trivial). Again, in contrast to traditional finance, games have always been highly experimental. So, the standard onchain games must meet to prove their existence worthy feels ironically higher than DeFi - which addressed a previously closed market. If fully onchain games are not a viable approach, the reasons to be excited about them could get expressed in less “onchain” ways. The games that work may use smart contracts minimally, or not at all. Offchain game infrastructure with NFT assets and interoperability with DeFi could be the right practical setpoint. Especially if elements of an offchain game are controlled by onchain assets, smart contract-based coordination around just the assets could still be powerful. Finally, whether or not games end up fully onchain, the patterns they explore - especially composable modding - could drive innovations in traditional game design. Traditional studios may see the potential and be willing to dedicate significant resources to redesigning offchain engines around supporting composable mods. Potentially coexisting with, outcompeting, or spiritually succeeding onchain games. ## Conclusion We see a lot of hard problems, but still have an intuitive sense that onchain games could leverage blockchains to create weird, novel outcomes. We're excited to explore all the frontiers of crypto-native games with other builders. We’re also more interested in building games than infrastructure - games that we would play ourselves. If this sounds exciting to you, reach out: [{charlie,doug}@paradigm.xyz](mailto:charlie@paradigm.xyz,doug@paradigm.xyz) ## Acknowledgments Thanks to our colleague [t11s](https://twitter.com/transmissions11) for many hours of input on this piece, as well as [Matt Huang](https://twitter.com/matthuang), [Dan Robinson](https://twitter.com/danrobinson), [Dave White](https://twitter.com/_Dave__White_), and [Frankie](https://twitter.com/FrankieIsLost) for discussion and review. Thanks also to [Will Robinson](https://twitter.com/DangerWillRobin), [GuiltyGyzoa](https://twitter.com/guiltygyoza), [Rafael Morado](https://twitter.com/nagual_ape), [Scott Sunarto](https://twitter.com/smsunarto), [Robert Miller](https://twitter.com/bertcmiller), and [0xhank](https://twitter.com/0xhank) for their feedback and [Ludens](https://twitter.com/l_udens), [Phil Daian](https://twitter.com/phildaian), [John Guibas](https://twitter.com/jtguibas), [Arthur Roeing Bear](https://twitter.com/ArthurRoingBaer), and [Hilmar Veigar Pétursson](https://twitter.com/hilmarveigar) for discussion. ## https://www.paradigm.xyz/writing/paradigm-and-a16z-file-joint-amicus-brief-in-sec-v-coinbase # Paradigm and a16z File Joint Amicus Brief in SEC v. Coinbase > Paradigm and a16z filed a joint amicus brief in SEC vs. Coinbase that supplements the arguments made by Coinbase in its filing last week and demonstrates why the SEC's approach is unsupported by case law and represents a significant and problematic expansion of its regulatory authority. **TLDR**: Paradigm and a16z filed a joint [amicus brief](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-fa25b9bbd8/6b38f5954d8b4650be849f76b5dbadf2/asset-https-cdn-sanity-io-files-dgybcd83-p-fa25b9bbd8.pdf) in *SEC vs. Coinbase* that supplements the arguments made by Coinbase in its filing last week and demonstrates why the SEC’s approach is unsupported by case law and represents a significant and problematic expansion of its regulatory authority. Our amicus brief agrees with Coinbase’s fundamental submission: Supreme Court precedent supports the requirement of a contractual obligation to find an “investment *contract*.” Since the SEC’s complaint fails to plead any such contract, it should be dismissed. In addition, the brief makes three supplementary points: *First*, the test for an investment contract established in *Howey*, even if understood to extend beyond contractual arrangements, does not justify the SEC’s unprecedented claims against Coinbase. The SEC attempts to exert jurisdiction over secondary market transactions of digital assets by relying on the word “scheme” in the trilogy of words in *Howey* describing an investment contract (“contract, transaction or scheme”). Whatever breadth the word “scheme” might have, the SEC has failed to allege the existence of any relationship between the original developers of digital assets and the independent and unrelated market participants who engaged in exchange-based transactions. Nor do the secondary market transactions of digital assets satisfy the “common enterprise” element of the *Howey* test, since the SEC has failed to allege any identifiable legal or business relationship between digital asset developers and the parties involved in secondary market transactions. *Second*, taken to its logical conclusion, the SEC’s position would sweep into the agency’s jurisdiction ordinary transactions in a range of commodities, collectibles, and other assets that the securities laws have never reached. Sales of commodities like oil, collectibles like art, or even a Tesla would, under the SEC’s boundless theories, suddenly become subject to the securities laws. This dramatic expansion of the SEC’s jurisdiction is not only unwarranted, but would also have a destabilizing effect on large swaths of the economy. *Finally*, the law, correctly interpreted, forecloses the SEC’s claims— but if any doubt remains, the major questions doctrine prevents the SEC from unilaterally expanding its authority and jeopardizing the development of a critical technology in the United States. Instead, Congress must craft the appropriate rules. Regulation is essential to address the novel questions raised by blockchain technology and digital assets, which were unforeseeable when Congress enacted the securities laws nearly a century ago. But allowing the SEC to generate new rules through ad hoc expansion of the securities laws creates an unpredictable legal environment that harms entrepreneurs and consumers alike. ## https://www.paradigm.xyz/writing/the-future-of-payments-includes-stablecoins # The Future of Payments Includes Stablecoins > Any legislation on stablecoins should promote openness and competition while recognizing that stablecoins are inherently different from bank deposits and MMFs. # 1. Summary Stablecoins present a generational opportunity to upgrade and meaningfully expand the payment system for the digital age. However, some recent regulatory actions and aspects of current legislative proposals would shoehorn crypto payment instruments into existing banking and securities frameworks — despite technological advancement around the world and continuing customer demand in today’s digital economy — and would be a step back. Instead, if legislative efforts in this area continue to move forward they should track three key objectives: - **To address risks to users of U.S. dollar-pegged stablecoins**, legislation could require centralized issuers of U.S. dollar-pegged stablecoins to meet appropriate risk-management standards. For fiat-backed stablecoins, where the issuer makes claims about guaranteed redemption at par, this may include the holding of reserve assets, including attestation that they match the balance of stablecoins outstanding one-to-one, consist of central bank liabilities or short-dated Treasuries, are segregated from the issuer’s own-assets, are protected from creditor process, and are subject to assessments or audits. Importantly, these issuers do not need to be banks, nor be subject to the full panoply of bank-like oversight. - **To foster growth and competitiveness**, legislation could prioritize orderly and effective competition among stablecoins and related services — as well as with incumbent banks. This includes setting clear guardrails to ensure that the stablecoin regulatory framework, as well as traditional payment infrastructure regulations, have objective, risk-based, and publicly-disclosed eligibility for licensure, which permit fair and open access — for both banks and regulated nonbank entities at both the state and federal levels. Access for end-users, whether businesses or individuals, should also be open. - **To encourage responsible stablecoin innovation,** legislation could enable a broad range of payments and related services to be available to consumers and businesses, while meeting baseline safety requirements. Instead of prescribing that all stablecoins must be pegged to the U.S. dollar or broadly prohibiting algorithmic stablecoins or stablecoins that are overcollateralized with on-chain collateral, regulation should explicitly permit experimentation and innovation within baseline consumer protections and additional rules commensurate with the level of risk, complexity, and scale of the stablecoin. # 2. Background While recent U.S. Congressional proposals on stablecoins allow for issuance beyond banks, the ongoing policy discussions around appropriate guardrails tend to be generally keyed to traditional safety and soundness principles of bank supervision and regulation, such as capital requirements, or risk management frameworks associated with securities such as money market funds (MMFs). But given unique risks and current use cases for stablecoins, traditional banking and securities law frameworks are a poor model for stablecoin regulation. **If policymakers are going to seize the opportunity to craft regulation that meets the moment, they should do so by promoting openness and competition more than current banking or securities frameworks.** Specifically, while it is critical to ensure that prudential risk and market risk are addressed, we believe the regulatory framework must also allow payment stablecoins to function and thrive. Regulatory guardrails can help preserve confidence in stablecoins as a form of money — and ensure that the power to dictate our system of money does not fall into the hands of a few market participants. # 3. What are stablecoins? Stablecoins are digital dollars issued on public, permissionless blockchains. They enable dramatic improvements to the digital payments ecosystem, thanks to specific characteristics of blockchains. - **Reliable, shared infrastructure.** Public blockchains are data and network infrastructures with more open access and high uptime that require very limited upfront capex for use in payments and tokenization. - **Programmability.** Thanks to smart contracts, programmability is native to most public blockchains where complex code can be transparently executed according to arbitrary conditions set by users, and tailored to their preferences. - **Composability.** Applications and protocols built on public blockchains can be combined and used interoperably to create new functionality. These features make it possible to design electronic payment systems that significantly reduce intermediation by bank balance sheets and create new paths for payments to efficiently flow. [^1] Stablecoins that use a different mechanism for maintaining stability, such as on-chain collateral mechanisms, feature even less reliance on the banking system and balance sheet intermediation. At the same time, trust and confidence are essential features of money. For these reasons, a regulatory infrastructure that ensures trust and confidence in stablecoins could help stablecoins thrive. **However, if stablecoins are shoehorned into the ill-fitting regulatory framework for banks or MMFs, they will end up looking like banks or MMFs and will, by extension, have the same inefficiencies as existing financial services.** ### 4. Stablecoins are not bank deposits in terms of risk Banks serve a central role in the financial system and broader economy: they hold on their books the savings of households and businesses around the country. Beyond taking deposits, they also lend to individuals, businesses, government entities, and a range of other customers. [^2] If businesses were limited to finance themselves or individuals could use only their cash on hand to, for example, purchase a home or a car, then commercial activity would be quite constrained. The business of banking can also be highly risky. Banks take deposits from customers, which can be withdrawn by a customer at any time, and make loans or invest in bonds or other assets which tend to be long-term (engaging in so-called maturity transformation) and may be susceptible to losses from poor judgment. If all customers of a bank try to withdraw their deposits at once, the bank may not have sufficient assets immediately on hand. This can lead to panics, bank runs, and fire sales. If a bank is mismanaged and suffers losses from bad loans or poor investment choices, this also can impact its ability to pay back customers if they all try to withdraw their deposits. Even the perception of this can create run risk. [^3] Stablecoins do not inherently pose these same risks. Issuers of U.S. dollar-pegged stablecoins that, by their terms, are redeemable at par on demand, might hold a reserve of assets to back up their redemption promises. These reserve assets might match the stablecoins outstanding one-to-one, consist of central bank liabilities or short-dated Treasuries, are segregated from the issuer’s own-assets, are protected from creditor process, and are subject to assessments or audits. [^4] Federal regulation implemented under new legislation can require specific safeguards. If so, then unlike bank deposits, there would be no duration mismatch between short-term liabilities (a stablecoin holder can redeem at any time at par on demand) and long-term or risky assets. More generally, even for stablecoins that are not pegged to the U.S. dollar or do not promise redemption at par, issuers are not inherently engaging in maturity transformation as banks are. Here, safeguards can also be put in place to ensure that consumers are protected and financial stability is maintained. These guardrails might include required disclosures, third-party audits, or even baseline consumer protection rules around liability and educational resources for centralized service providers that choose to offer or promote such stablecoins to their customers. **In essence, the risk management framework applicable to stablecoins should be designed to manage the unique risks associated with stablecoins, which are different from those that arise in traditional banking.** ## 5. Stablecoins are different from MMFs in practice Certain regulators, including representatives of the SEC, have stated that some stablecoins resemble money market funds (MMFs), particularly when they hold a variety of assets like government securities, cash, and other investments as reserves to support their stable value, and thus should be regulated as MMFs. [^5] We do not believe this is an appropriate form of regulation, because it is inconsistent with the actual market usage of stablecoins. MMFs are open-end management investment companies that are subject to the securities laws. They invest in high-quality, short-term debt instruments, such as commercial paper, Treasury bills, and repurchase agreements. They pay dividends that reflect prevailing short-term interest rates, are redeemable on demand, and are required under SEC rules to maintain a stable net asset value per share (or “NAV”), typically $1.00 per share. [^6] Like other mutual funds, they are registered with the SEC and regulated under the Investment Company Act of 1940. Interests in MMFs are publicly listed investments that are purchased and traded through securities intermediaries (e.g., a broker or bank accessing an exchange). Over the years, a variety of types of MMFs have been introduced to meet the different needs of investors with varying investment goals and tolerances for risk. As the SEC cataloged almost ten years ago, most investors have invested in prime MMFs, which generally hold a variety of short-term obligations issued by corporations and banks, as well as repurchase agreements and asset-backed commercial paper. [^7] In contrast, government MMFs principally hold obligations of the U.S. government, including obligations of the U.S. Treasury, as well as repurchase agreements collateralized by government securities [^7] Compared to prime funds, government MMFs generally offer greater safety of principal but historically have paid lower yields. The combination of principal stability, liquidity, and short-term yields offered by MMFs bears some resemblance to U.S. dollar-pegged stablecoins. Importantly, though, stablecoins are used for very different purposes in practice from MMFs, and most stablecoins would lose their utility if they are regulated as MMFs. In practice, stablecoins are primarily used as a means to pay the U.S. dollar leg in a crypto transaction, rather than as an investment option or a cash management vehicle. For the largest U.S. dollar-pegged stablecoins, holders do not receive any return based on the reserves. Rather, the stablecoins are used as the equivalent of cash itself. A holder of a U.S. dollar-pegged stablecoin generally would not seek to redeem the value of their stablecoin holdings from the issuer and then use the proceeds in a crypto transaction. They would simply transfer the stablecoin itself as the U.S. dollar payment leg in the crypto transaction. This would not be possible or pragmatic if the holder is required to sell through a broker or a bank, should stablecoins be regulated as MMFs. We believe it would be a mistake to force-fit stablecoins into the MMF regulatory framework, particularly where there is an opportunity for legislation to create a framework more tailored to the risks posed by stablecoins and the actual market behaviors around them. Indeed, where a comprehensive legal framework governing the use of an arrangement such as a bank deposit or pension plan is already in place, the Supreme Court has declined to extend the scope of SEC authority to such instruments. [^8] is not the type of instrument that comes to mind when the term “security” is used, and does not fall within “the ordinary concept of a security.”); Teamsters v. Daniel, 439 US 551, 570 (1979) (finding that the Securities Act and the Securities Exchange Act do not apply to a noncontributory, compulsory pension plan)\] In other words, just as MMFs are regulated differently from other investment companies because they have a different structure and purpose, stablecoins should be regulated in a way that is consistent with their unique structure and purpose. ### 6. Conclusion We believe that an over-fixation on existing banking and securities law frameworks for stablecoins would also overlook critical payment system principles, particularly those regarding fair and open access. Unique to payment systems are the dynamics of network effects, where a user’s benefit from a system increases as the number of other users on the system grows. [^9] Together with barriers to entry, including in the form of unduly burdensome and strict bank-like oversight of stablecoin issuers, these factors tend to limit competition and confer concentrated market power on a few dominant parties. Left unchecked, this could lead to lower levels of service to customers, higher prices, or under-investment in risk management systems. [^10] This concentration of power would also be anathema to crypto’s freedom of choice and decentralization. A stablecoin issuer or service provider with concentrated market power could potentially make governance decisions for a public blockchain, and also have discretion to affect the competitive balance among other participants. It could choose to disadvantage some participants (and their customers) by throttling or otherwise limiting access to its services and reward other favored crypto service providers with preferential treatment, reinforcing its market power. For these reasons, we urge Congress to act promptly to enact legislation to address risks arising from stablecoin arrangements while still allowing payment stablecoins to function and innovation to continue. Under these principles, such legislation would address key concerns while still allowing the stablecoin’s workability: - protecting users of stablecoins by setting reasonable risk-management requirements for centralized providers; - prioritizing competition by ensuring there is a viable pathway for nonbank issuers at the federal and state level; and - promoting innovation by making it possible for stablecoins to take on a variety of forms as long as baseline consumer protections are met and risks are appropriately managed. *Acknowledgements: Special thanks to *[*Jess Cheng*](https://www.wsgr.com/en/people/jess-cheng.html)* for assistance with this piece.* [^1]: Adams, Austin and Lader, Mary-Catherine and Liao, Gordon and Puth, David and Wan, Xin, On-Chain Foreign Exchange and Cross-Border Payments (January 18, 2023), available at SSRN: https://ssrn.com/abstract=4328948 or http://dx.doi.org/10.2139/ssrn.4328948 [^2]: 12 U.S.C. § 24 (providing corporate powers of national banking associations); NationsBank of North Carolina, N.A. v. Variable Life Assurance Annuity Co., 513 US 251 (1995) (noting that the National Bank Act gives banks “all such incidental powers as shall be necessary to carry on the business of banking…”) [^3]: Review of the Federal Reserve’s Supervision and Regulation of Silicon Valley Bank, Board of Governors of the Federal Reserve System, Letter and report dated April 28, 2023, available at https://www.federalreserve.gov/publications/files/svb-review-20230428.pdf (noting that “the combination of social media, a highly networked and concentrated depositor base, and technology may have fundamentally changed the speed of bank runs.”) [^4]: See, e.g., Sommer, Joseph H., Special Deposits, 76 Bus. Law. 841 (2020-21) [^5]: Securities and Exchange Commission, Prepared Remarks of Gary Gensler On Crypto Markets at Penn Law Capital Markets Association Annual Conference (April 4, 2022), available at https://www.sec.gov/news/speech/gensler-remarks-crypto-markets-040422 (“Stablecoins, though, in offering features similar to and potentially competing with bank deposits and money market funds, raise three important sets of policy issues. First, stablecoins raise public policy considerations around financial stability and monetary policy. Such policy considerations underlie regulations that banking regulators have with respect to deposits and that we at the SEC have with respect to money market funds and other types of securities.”); Former SEC Chairman Jay Clayton: “A stablecoin that promises $1 back to you, in exchange for the coin, and is backed by cash is one item. Such a coin that is backed by commercial paper, whether it’s 30, 60 or 90 days, sure looks like a money market mutual fund to me. So the second element really looks like a security. We have decided that a pooled vehicle of commercial paper that you use for daily liquidity is a money market mutual fund and should be regulated as such.” See Steven Ehrlich, “Exclusive: Former SEC Chairman Jay Clayton On Stablecoins, DeFi, And Bitcoin ETFs” (Oct. 6, 2021), available at https://www.forbes.com/sites/stevenehrlich/2021/10/06/exclusive-former-sec-chairman-jay-clayton-on-stablecoins-defi-and-bitcoin-etfs/?sh=77b07b8661b1. Federal Reserve Chair Jerome Powell: “Stablecoins are like money market funds, are like bank deposits, but they’re to some extent outside the regulatory perimeter and it’s appropriate that they be regulated. Same activity, same regulation.” See Matthew Fox, “The Fed has ‘no intention’ to ban cryptocurrencies, Jerome Powell tells Congress” (Sept. 30, 2021), available at https://finance.yahoo.com/news/fed-no-intention-ban-cryptocurrencies-193120137.html [^6]: Securities and Exchange Commission, Money Market Fund Reform; Amendments to Form PF, 79 FR 47735 (Aug. 14, 2014) [^7]: Id [^8]: Marine Bank v. Weaver, 455 US 550, 559 (1982) (“Congress intended the securities laws to cover those instruments ordinarily and commonly considered to be securities in the commercial world, but the agreement [for certificate of deposit [^9]: Cheng, Jess, and Joseph Torregrossa (2022). “A Lawyer’s Perspective on U.S. Payment System Evolution and Money in the Digital Age,” FEDS Notes. Washington: Board of Governors of the Federal Reserve System, February 04, 2022, https://doi.org/10.17016/2380-7172.2964 [^10]: Bank for International Settlements, Principles for Financial Market Infrastructures at 11; 101 (April 2012), available at https://www.bis.org/cpmi/publ/d101a.pdf ## https://www.paradigm.xyz/writing/collaborate-with-paradigm # Collaborate with Paradigm > Paradigm is a group of builders that supports other builders. Some of our most fruitful collaborations involve deep work with entrepreneurial teams to solve important business and research problems. Paradigm is a group of builders that supports other builders. Some of our most fruitful collaborations involve deep work with entrepreneurial teams to solve important business and research problems. Sometimes an entrepreneur brings the idea, other times we do. Either way, we love the process of mind melding and bringing a project to life. A few examples: - [**Uniswap**](https://uniswap.org/) had only recently launched when Hayden Adams came to pitch Paradigm in 2019. We were fortunate to lead Uniswap’s seed round, and Dan Robinson has dedicated a large chunk of his brain to thinking about Uniswap ever since, including contributing to Uniswap [v2](https://uniswap.org/whitepaper.pdf), [v3](https://uniswap.org/whitepaper-v3.pdf), [v4](https://github.com/Uniswap/v4-core/blob/main/whitepaper-v4-draft.pdf), and [UniswapX](https://uniswap.org/whitepaper-uniswapx.pdf). - [**Flashbots**](https://flashbots.net/) began as a group chat with eventual cofounders Scott Bigelow, Phil Daian, Stephane Gosselin, Alex Obadia, and Tina Zhen, along with a loose collection of MEV-curious crypto folks including Charlie Noyes, Georgios Konstantopoulos, and samczsun from the Paradigm team. The group chat evolved into a company, and Paradigm was glad to help the Flashbots team [form and fund their plans](https://medium.com/flashbots/frontrunning-the-mev-crisis-40629a613752#). It’s been a fascinating journey through the [dark forest](https://www.paradigm.xyz/2020/08/ethereum-is-a-dark-forest). - [**Conduit**](https://conduit.xyz/) evolved out of a collaboration between a [Paradigm entrepreneur-in-residence, Andrew Huang](https://mirror.xyz/0x16af2C8f41C9ce2e3c897587f5225d68ca6C4525/_V-Bn8Gi7ykNJIiWDfOXAy_jGujwPm-F5GqneRavGxI), and Georgios Konstantopoulos. Georgios and others on the Paradigm team had been thinking about infrastructure to support a rollup-centric, multi-chain world. Meanwhile, Andrew had been thinking about ways to apply his web2 infrastructure experiences to crypto. A few months into Andrew’s residency with Paradigm, [Conduit was born](https://conduit.xyz/blog/introducing-conduit). There’s no shortage of great people working in crypto, and we’d like to collaborate with more of them. - We currently have the bandwidth to take on **3 to 5** new, deep collaborations. - You’ll get to work closely with the Paradigm investing and research teams, in addition to support from our talent, legal/policy, design, go-to-market, and data teams. - You can be pre-idea (as an entrepreneur-in-residence) or further along at the seed or series A stage. - You can bring your own idea, or collaborate on one of ours. A few areas we’ve been exploring: - **Intent-centric protocols and infra** - **Hooks on top of Uniswap v4** (especially ones that focus on LP profitability and loss-vs-rebalancing) - **Infra for a rollup-centric, multi-chain world** - **Shared sequencers** - **Onchain games** (something we would enjoy playing) - **Crypto-native social apps** - **Prediction markets** (creating markets with real liquidity) - **Stablecoin payments/fintech** (as stablecoins mature and banking becomes more troublesome) - **Onchain treasuries** (a natural step after stablecoins and before other real world assets) - **ZKP apps** (there is a ZKP capability overhang: science is ahead of applied research, which is ahead of applications) ## Interested? Please tell us about yourself or your project by filling out the form below. This will be a rolling process, so get in touch anytime. We’ll read every submission, but may not be able to respond to all of them. [Submit an Application](https://airtable.com/appO4TfDxeW6JIS8g/shrffTcxQfLk0nOUc) *Acknowledgments: Thanks to *[*Frankie*](https://paradigm.xyz/team/frankie)*, *[*Charlie*](https://paradigm.xyz/team/charlienoyes)*, *[*Fred*](https://paradigm.xyz/team/fredehrsam)*, *[*Dave*](https://paradigm.xyz/team/davewhite)*, and the rest of the Paradigm team for feedback. Special thanks to *[*Yang*](https://paradigm.xyz/team/yangyou)* for the graphics.* ## https://www.paradigm.xyz/writing/joining-paradigm-alex-grieve # Joining Paradigm > Alex Grieve joins Paradigm as Government Affairs Lead. ## Alex Grieve, Government Affairs Lead I’ve spent the last decade in Washington, DC at the intersection of politics and financial policy. After beginning my career with Speaker of the House John Boehner, I spent four years as part of the government relations team of the Depository Trust and Clearing Corporation (DTCC), the financial market infrastructure that clears and settles the trades of the US equity markets. It was here that I found crypto: The more I learned about our financial system’s inner workings, the more I felt that its technology was hopelessly outdated compared to the rest of our economy. I bought my first BTC and ETH on Coinbase in 2017, and never looked back. And as DTCC explored blockchain-based settlement, I was one of the earliest in DC to work with Hill staffers to explain blockchains and digital assets. For the past two years, I’ve helped build the crypto practice at leading regulatory advisory firm Tiger Hill Partners, where I was fortunate to work with such firms as Coinbase, Polygon Labs, and BitGo, trade associations such as the Proof of Stake Alliance, and members of the broader crypto policy and startup communities in DC and across the country. Now we are at a critical juncture for US crypto policy: multiple bills on Capitol Hill are tackling everything from stablecoins to market structure; activist regulators are making seemingly-qualitative judgments about the relative value of an entire industry; and countries around the world are racing ahead of the US, seeing the enormous opportunity crypto provides, and establishing their own purpose-built regulatory regimes to support it. **Given this backdrop, and the immense challenge ahead, I’m thrilled to share that I’m joining Paradigm as its Government Affairs Lead.** The incredible investment firm that [Fred Ehrsam](https://www.paradigm.xyz/team/fredehrsam) and [Matt Huang](https://www.paradigm.xyz/team/matthuang) have built leads the industry in supporting innovators and entrepreneurs – and Paradigm has the team, the expertise, the resources, the commitment, and the *will* to promote crypto’s policy priorities in Washington. I couldn’t be more excited to join Paradigm, and the finest team in crypto policy: [Rodrigo Seira](https://www.paradigm.xyz/team/rodrigoseira), who files a [new](https://policy.paradigm.xyz/writing/bittrex-amicus-brief) [amicus](https://policy.paradigm.xyz/writing/tornado-ii-amicus-blog-post) [brief](https://policy.paradigm.xyz/writing/kucoin-amicus-blog-post) [or](https://policy.paradigm.xyz/writing/coinbase-amicus-blog-post) [comment](https://policy.paradigm.xyz/writing/3b-16commentletter) [letter](https://policy.paradigm.xyz/writing/Custody-Comment-Letter) on behalf of the crypto community seemingly every week, while taking quick breaks to [debate](https://www.youtube.com/watch?v=z5Yj5o6ycgM) critics on podcasts; [Dominique Little](https://www.paradigm.xyz/team/dominiquelittle), whose relationships with key policymakers are unparalleled; [Brendan Malone](https://www.paradigm.xyz/team/brendanmalone), [technology](https://policy.paradigm.xyz/writing/using-on-chain-data-for-policy-research-part-1) and [monetary](https://policy.paradigm.xyz/writing/using-on-chain-data-for-policy-research-part-2) [policy](https://policy.paradigm.xyz/writing/using-on-chain-data-for-policy-research-part-3) and theory [gigabrain](https://policy.paradigm.xyz/writing/moneyness-in-the-digital-age); [Justin Slaughter](https://www.paradigm.xyz/team/justinslaughter), whose deep and multidisciplinary experience in law, financial policy, legislative strategy, and financial regulation manifests on Twitter as a crypto policy [threadoooor](https://twitter.com/JBSDC/status/1664791786038935552?s=20) non pareil; and [Katie Biber](https://www.paradigm.xyz/team/katiebiber), Paradigm’s Chief Legal Officer, one of the most experienced and respected leaders anywhere in fintech and crypto, and a veteran of hard-fought presidential campaigns. While I have long been a staunch advocate of crypto in Washington – it’s time to join the best team in the business and help lead the fight. ## https://www.paradigm.xyz/writing/paradigm-files-amicus-brief-in-sec-vs-bittrex # Paradigm Files Amicus Brief in SEC vs. Bittrex > Paradigm filed an amicus brief rejecting the SEC's unsupported attempt to expand its jurisdiction to secondary market trading of crypto assets. **TLDR**: Paradigm filed an [amicus brief](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-366f99bf60/c972a3758c4538cdedc925384ef19b71/asset-https-cdn-sanity-io-files-dgybcd83-p-366f99bf60.pdf) in *SEC vs. Bittrex* that rejects the SEC’s unsupported attempt to expand its jurisdiction over crypto secondary markets. The SEC’s lawsuit against Bittrex is the first of three cases that the SEC has brought in rapid succession against crypto exchanges. Through these actions, the SEC is wrongfully attempting to lay claim over crypto secondary markets. Gary Gensler acknowledged in Congressional testimony shortly after he became SEC Chair that the agency lacked the authority to regulate these same secondary markets, [noting](https://www.congress.gov/event/117th-congress/house-event/112590/text) in clear words that “the exchanges trading in these crypto assets do not have a regulatory framework.” The law has not changed since Gensler made those statements in 2021. However, the SEC now claims to have discovered the same authority Gensler acknowledged was missing and is seeking to impose retroactive penalties on companies for failing to comply with it. As our brief lays out, the SEC lacks the authority to regulate secondary markets for crypto assets because they do not involve “investment contracts” and are therefore not securities transactions under the agency’s remit. The SEC’s claims against Bittrex and the other crypto exchanges are fundamentally different from its many prior cases against token sellers. In those prior cases, the SEC exercised its authority to regulate *fundraising* schemes under the *Howey* test. But in the recent cases targeting crypto exchanges, the SEC is attempting to expand its authority past the initial fundraising transactions, to encompass downstream sales of crypto assets. However, even if a crypto asset was first sold in a fundraising transaction, the SEC has no legal basis to argue that the asset itself embodies an investment contract, or that secondary market transactions in that asset are investment contract transactions. A [comprehensive review](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4282385) of every federal appellate case to address *Howey* confirms that no court has ever held that an asset that is the object of an investment contract transaction is itself a security, nor that a subsequent transfer of that asset in a secondary market is a securities transaction. The SEC’s theories are thus completely unprecedented. The court should dismiss this case and the SEC should join Congress in working on crypto legislation that supports innovation and protects investors. ## https://www.paradigm.xyz/writing/alloy # Introducing Alloy: Fast, battle-tested and well-documented building blocks for Ethereum, in Rust > Alloy is a Rust interface to Ethereum. It is a rewrite of the popular ethers-rs crate, using our learnings from the last 4 years of Rust Ethereum engineering, to create stable and useful foundations for the next 5 years. # Introduction In 2020, we saw a shortfall in the performance and reliability of off-chain Ethereum infrastructure. To address this, we ([gakonst](https://github.com/gakonst/) & [prestwich](https://github.com/prestwich/)) started building in the [Rust Ethereum ecosystem](https://twitter.com/gakonst/status/1271809323744792577?s=20). At the time, most Ethereum off-chain actors were written in Python or Javascript. These actors included MEV bots for liquidation and arbitrage (sandwiches were not that popular back then) and indexers for ETLing Ethereum events into structured data. Most codebases (open source or not) were at best PoC-level mature and could not provide the scale or reliability that crypto deserves. We’ve come a long way since then. Using Parity’s [Ethereum Types](https://crates.io/crates/ethereum-types) and [Ethabi](https://crates.io/crates/ethabi), we built [ethers-rs](https://github.com/gakonst/ethers-rs/), a Rust re-interpretation of the popular [ethers.js](https://github.com/ethers-io/ethers.js/) library. Today, ethers-rs is the premier Rust tooling for the entire EVM ecosystem. It has a core team of dedicated maintainers, [over 200 contributors](https://github.com/gakonst/ethers-rs/graphs/contributors), and covers [everything from RPC to the Solidity compiler](https://docs.rs/ethers/latest/ethers/). Ethers-rs is now is a staple in Rust Ethereum codebases, used by: - Paradigm-driven tools & infrastructure: [Reth](https://www.paradigm.xyz/2023/06/reth-alpha), [Foundry](https://github.com/foundry-rs/foundry) and [Artemis](https://github.com/paradigmxyz/artemis/) - Industry players: - [Uniswap](https://sourcegraph.com/github.com/Uniswap/ethers-rs-mobile) - [The Ethereum Foundation](https://github.com/ethereum/kzg-ceremony-sequencer) - [ENS](https://github.com/ensdomains/ethers-ccip-read/) - [SpruceId](https://github.com/spruceid/siwe-rs/) - Popular ecosystem MEV bots: - [rusty-sando](https://github.com/mouseless-eth/rusty-sando/) - [subway-rs](https://github.com/refcell/subway-rs/) - [cfmm-rs](https://github.com/0xKitsune/cfmms-rs) - [WolfGameMEV](https://github.com/0xAlcibiades/WolfGameMEV) - Open Source infrastructure & experiments: - Nascent’s [Pyrometer](https://github.com/nascentxyz/pyrometer/) - A16z's [Magi](https://github.com/a16z/magi) - PSE’s zkEVM [Circuits](https://github.com/privacy-scaling-explorations/zkevm-circuits) & [Chain](https://github.com/privacy-scaling-explorations/zkevm-chain) - LeoAlt’s [Fusion](https://github.com/leonardoalt/fusion/) ZK Rollup - Jon Becker’s [Heimdall](https://github.com/Jon-Becker/heimdall-rs) - ..and more (we’re building a showcase, reach out!) For the last 3 years, ethers-rs has provided strongly-typed, well-documented, tested and efficient abstractions for submitting transactions, subscribing and transforming chain data, and interacting with smart contracts. The Rust Ethereum community flourished over this time period, and we are proud of the work we’ve done to enable that. Ethers-rs far outgrew our expectations. However, like all software, maintenance is a constant battle. Ethers-rs was our first foray into Rust in production, and it has been a learning experience for everyone involved. Over time, we merged code we should have been more thoughtful about, accumulated tech debt, and entrenched suboptimal abstractions in many codebases due to our mistakes. We recently started a concentrated effort to address these growing pains. In this post we will share our progress so far, as well as our plans for the Rust Ethereum ecosystem for the rest of this year. # ethers-rs is now alloy Firstly, we are rebranding. **Ethers is now called Alloy and lives under a new Github Organization:** [**github.com/alloy-rs**](https://github.com/alloy-rs). Current versions of ethers will continue to live in [gakonst/ethers-rs](https://github.com/gakonst/ethers-rs/), and be otherwise in maintenance mode for v2. Future major versions will use the new name and organization. Ethers-rs was built for stability, to be used as a well-tested and robust foundation of composable pieces to build powerful applications. We believe that Alloy communicates that well. The project has grown enough that we felt the need to have a unique identity, which communicates our values, and allows us to be consistent about them, while also avoiding brand confusion with ricmoo’s popular ethers.js, which we’re thankful for the inspiration in the early iterations of ethers-rs. # What does Alloy include? We also rewrote our stack from scratch. Today, **we’re excited to announce** [**alloy-rs/core**](https://github.com/alloy-rs/core)**, a rewrite of the popular** [**ethers-core**](https://docs.rs/ethers-core) **package and the** [**ethabi**](https://docs.rs/ethabi/latest/ethabi/) **crate**. Core offers: - [**Alloy Primitives**](https://docs.rs/alloy-primitives/latest/alloy_primitives/): We provide new fundamental types for hashes, fixed-byte arrays, and signed and unsigned integers (built on [Remco’s uint library](https://github.com/recmo/uint)). These types implement common traits sanely (no more truncated hashes like “0x1234…5678”), aim for no_std compatibility, and provide common helper functions for usage in applications. - [**Alloy RLP**](https://docs.rs/alloy-rlp/latest/alloy_rlp/): A canonical RLP implementation. - [**Alloy RPC Types**](https://github.com/alloy-rs/core/pull/51): All the RPC types when talking to a chain are available using our newly defined types. - [**Syn Solidity**](https://docs.rs/syn_solidity/latest/syn_solidity/): A `syn`-powered Solidity parser, specifically designed for Rust procedural macros. It aims to mimic the behavior of the official Solidity compiler (Solc) when it comes to parsing valid Solidity code. This is a powerful abstraction which we leverage for building performant compile-time functionalities, like static ABI coders (see below). - [**Alloy Solidity Types**](https://docs.rs/alloy_sol_types/latest/alloy_sol_types/): A compile-time representation of Ethereum's type system with ABI and EIP-712 support. This allows for clean UX and high encoding/decoding speed without redundant layers of abstraction. This static abi encoder is built on a robust representation of Solidity’s type system in Rust. Users access it via the sol! procedural macro, which parses Solidity snippets to generate native Rust code. **The static encoder benches at 2-3x faster (!!) than current Rust implementations which are 1+ order of magnitude faster than other languages.** Here is a low-level example of how you can use these new primitives: ```rust use alloy_primitives::Address; use alloy_sol_types::{sol, SolType}; // Type definition: generates a new struct that implements `SolType` sol! { type MyType is uint256; } // Type aliases type B32 = sol! { bytes32 }; // This is equivalent to the following: // type B32 = alloy_sol_types::sol_data::Bytes<32>; type SolArrayOf = sol! { T[] }; type SolTuple = sol! { tuple(address, bytes, string) }; let _ = ::encode_single(&true); let _ = B32::encode_single(&[0; 32]); let _ = SolArrayOf::::encode_single(&vec![true, false]); let _ = SolTuple::encode_single(&(Address::ZERO, vec![0; 32], "hello".to_string())); ``` Here's a higher-level example, showing a roundtrip ABI encoding of an ERC20 transfer: ```rust use alloy_primitives::{Address, U256}; use alloy_sol_types::{sol, SolCall}; use hex_literal::hex; sol! { #[derive(Debug, PartialEq)] interface IERC20 { function transfer(address to, uint256 amount) external returns (bool); } } // random mainnet ERC20 transfer // https://etherscan.io/tx/0x947332ff624b5092fb92e8f02cdbb8a50314e861a4b39c29a286b3b75432165e let data = hex!( "a9059cbb" "0000000000000000000000008bc47be1e3abbaba182069c89d08a61fa6c2b292" "0000000000000000000000000000000000000000000000000000000253c51700" ); let expected = IERC20::transferCall { to: Address::from(hex!("8bc47be1e3abbaba182069c89d08a61fa6c2b292")), amount: U256::from(9995360000_u64), }; assert_eq!(data[..4], IERC20::transferCall::SELECTOR); let decoded = IERC20::IERC20Calls::decode(&data, true).unwrap(); assert_eq!(decoded, IERC20::IERC20Calls::transfer(expected)); assert_eq!(decoded.encode(), data); ``` Alloy is really powerful! These crates will act as the solid foundation we’ve always wanted for Ethereum in Rust, informed by the lessons from our last 3 years of Rust Ethereum engineering. The code for these crates is under [active development on github](https://github.com/alloy-rs/core). We love new contributors. The pre-1.0.0 version of these crates are available on [crates.io](https://crates.io/crates/alloy-primitives), and [docs.rs](https://docs.rs/alloy_sol_types/latest/alloy_sol_types/). # Refactoring the Rust Ethereum ecosystem In 2020 with ethers-rs, we made a decision to re-use Parity’s existing type libraries. These types are deeply embedded in the codebase and exposed to dependencies via U256, H256, and other commonly-used structs. Over time Rust has improved faster than Parity’s implementations could keep up. Reth and Revm did not use Parity types, choosing modern Rust equivalents instead. Other Paradigm-supported projects like Foundry or Artemis have not migrated yet. Reth and revm are incompatible by default with Foundry and ethers-rs. This creates a gap in the ecosystem, requiring extreme amounts of type conversion at the boundary. To address this, we will be migrating the Rust Ethereum ecosystem built on our libraries to shared types. These types will live in [alloy-rs/core](https://github.com/alloy-rs/core), and will reuse the excellent work in Remco’s [ruint](https://github.com/recmo/uint/) library. We will phase out the Parity types. The alloy-types library will be the root of the Rust Ethereum ecosystem. This migration will take place over the next 6 months. Going forward, [alloy-rs/core](https://github.com/alloy-rs/core) will form the shared base for all our Rust Ethereum projects. To be clear, **there is no action needed from developers right now**. Ethers-rs will continue to be available under the same great name in the same [great repo](https://github.com/gakonst/ethers-rs) for the foreseeable future. We will publish migration plans in advance. Until we have more integrations in the rest of the ecosystem, we encourage developers to try out alloy in their low-level projects and share their feedback on the abstractions, documentation and performance. # Conclusion Using our learnings from the last 3 years of building in the Rust Ethereum ecosystem, we are excited to [release Alloy, our rewrite of ethers-rs](https://github.com/alloy-rs/core/releases/tag/v0.2.0) with exciting new features, documentation, and a new brand. As part of that, we are excited to be also formalizing maintainership of ethers-rs/alloy as [James Prestwich](https://github.com/prestwich/), [Georgios Konstantopoulos](https://github.com/gakonst) and [DaniPopes](https://github.com/DaniPopes). These upgrades will pay down a lot of tech debt, remove weird type conversions, improve performance across the board, and overall set us up for the next 5 years of high-assurance Rust Ethereum engineering. If you are excited about contributing, please reach out to [georgios@paradigm.xyz](mailto:georgios@parardigm.xyz) or [james@prestwi.ch](mailto:james@prestwi.ch). You can find links to all the support and development chatrooms in the [Alloy Core README](https://github.com/alloy-rs/core). *Authors' note: Would like to take a moment to shout out* [*Dani*](https://github.com/DaniPopes) *for his extremely high quality work on this project. We have been talking about rewriting ethers-rs for a long time, and they drove big parts of the project from beginning to where we are today. Big kudos.* See you on [Github](https://github.com/alloy-rs). ## https://www.paradigm.xyz/writing/reth-alpha # Releasing Reth > Reth is a new Ethereum execution node written in Rust that is modular, contributor-friendly and blazing-fast. Reth is now entering public alpha and we’re excited to invite node operators and developers to try it out. # Introduction [Last year](https://www.paradigm.xyz/2022/12/reth), we set out to build [**Reth**](https://github.com/paradigmxyz/reth/)**, a new Ethereum execution node written in Rust that is modular, contributor-friendly and blazing-fast.** Our goals behind Reth are to: - Contribute to Ethereum’s stability and improve client diversity. - Lower the barrier to entry for contributing to Ethereum’s ambitious roadmap. - Build a performant and inclusive ecosystem of tools for EVM developers and users. Reth is built by a [Paradigm-funded core team of 8](https://www.paradigm.xyz/oss), along with over [90 other contributors](https://github.com/paradigmxyz/reth/graphs/contributors). In building Reth, we focused on performance and testing, using the same principles and lessons from building [Foundry](https://www.paradigm.xyz/oss/foundry). At the same time, one of the core tenets of our culture is making our codebases accessible and inclusive to new developers, so we paid a lot of attention to our abstractions and documentation. **Today, we’re excited to announce that Reth is entering its alpha with version 0.1.0 under the permissive Apache/MIT license. We are inviting node operators and users to run nodes and use Reth’s crates to build exciting EVM-centric infrastructure.** TL;DR – What is included in today’s alpha release? - **A new Ethereum Execution Layer, in Rust, using the Apache/MIT license.** - Best in class performance: - **Storage:** <2TB database size at block 17.4M. - **Syncing Speed:** Bootstrapping the chain from genesis to block 17.4M in 50 hours. - **Robustness:** Reliably tracks the tip without falling behind under heavy RPC load. - **Querying the chain:** State of the art RPC throughput and latency. - Tested in-depth using standardized EF-maintained test suites, fuzz-testing/profiling best practices, and custom benchmarking infrastructure. - Feature-complete up to Shanghai, with Cancun up next. - Ethereum JSON-RPC support, including blazing-fast live & historical tracing, using Geth’s `debug_*` module (incl. JS Tracers) and Parity’s `trace_*` module. - **A new SDK for building EVM-centric infrastructure** such as: - MEV Builders - P2P Sentries - Indexers - ERC4337 UserOp mempools - ..and other exciting applications. If this sounds interesting, read on to learn more. # Performance Reth achieves state of the art archive node performance on the most important areas when evaluating a node: - **Storage:** <2TB database size at block 17.4M. - **Syncing Speed:** Bootstrapping the chain from genesis to block 17.4M in 50 hours. - **Robustness:** Reliably tracks the tip without falling behind under heavy RPC load. - **Querying the chain:** State of the art RPC throughput and latency. We provide a brief comparison between Reth and other popular node implementations below: ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--ee87bad18c/8996833a84650bf7b678df004c53a29e/asset-https-cdn-sanity-io-images-dgybcd83--ee87bad18c.png) While these are still early days, Reth already shows promising performance characteristics, which we’re excited to further improve in the future. We would also like to make our benchmarking methodology more robust and reproducible by third parties. If you are curious about how we collected these benchmarks and our philosophy behind profiling and testing, see the FAQ, or reach out to contribute. **By running Reth, you can improve your nodes’ performance and reduce your cost while also contributing to client diversity. Read** [**The Book**](https://paradigmxyz.github.io/reth/run/mainnet.html) **for instructions on setting a node up.** # What is included in this release? Today’s release includes an archive node, which enables efficiently querying historical Ethereum data. This is a very important component for Ethereum ecosystem stakeholders such as searchers, block explorers, indexers, and RPC providers. **Our thesis is that Reth will create quantitative and qualitative improvements to crypto infrastructure’s robustness and performance, while also providing hardware and cloud cost savings.** Reth can sync any Ethereum-like network (Mainnet, Sepolia, Goerli etc.), up to Shanghai, and follows the Ethereum JSON-RPC spec. Importantly, we provide new performant implementations of the `debug_*` (including Geth-style Javascript tracers) and `trace_*` JSON-RPC namespaces (featuring “top of next block” simulations, instead of “end of current block”, using the `pending` block tag, a common feature requested by searchers during `trace_call` and `trace_callMany`). You can learn more about [JSON-RPC support in the Reth Book](https://paradigmxyz.github.io/reth/jsonrpc/intro.html). # Reth is also a new SDK for building EVM-centric infrastructure. **Reth is an ecosystem of high-quality abstractions for building EVM infrastructure. One can think of Reth as an SDK, with the node being just the first application.** We provide performant & documented modules and abstractions for complex operations like [block building](https://paradigmxyz.github.io/reth/docs/reth_payload_builder/index.html), [simulating transactions](https://paradigmxyz.github.io/reth/docs/reth_revm_inspectors/index.html), [building mempools](https://paradigmxyz.github.io/reth/docs/reth_transaction_pool/index.html), [indexing the chain](https://paradigmxyz.github.io/reth/docs/reth_db/index.html), [P2P networking](https://paradigmxyz.github.io/reth/docs/reth_network/index.html), [RPC interfaces](https://paradigmxyz.github.io/reth/docs/reth_rpc/index.html), and more. All our packages are licensed under the Apache/MIT license, for free, permissive use by everyone. You can import Reth’s various components as a library by adding the following to your `Cargo.toml` (replace `reth-db` with your favorite package, see here for a [complete list](https://github.com/paradigmxyz/reth/blob/main/docs/repo/layout.md)): We intend to provide versioned releases for the libraries in the future; for now, we ask developers to import Reth in their Cargo projects via git-based paths. **Start building by importing Reth as a library and browsing the docs!** # The future of Reth **Reth today is a performant Ethereum archive node implementation and toolkit for building EVM-centric infrastructure. We are excited to continue shipping blazing-fast, well-tested and contributor-friendly code, and contribute to the Ethereum ecosystem’s long-term success.** The core Reth team is going to be focusing on: 1. Shipping the Ethereum roadmap, with Cancun & EIP-4844 as our top priority, and contributing to the Core Development process. 2. Improving stability of the existing feature set. 3. Shipping key node quality of life features like non-archive sync and snapshots. We will continue expanding documentation and testing of the codebase, to improve robustness and make integrations easier. **We invite developers and node operators to try out Reth and let us know what they think. Like with Foundry, our culture remains developer-first, devoted to tight feedback loops with a high bar. We cannot wait to see what you will build with Reth.** If all of this is exciting, please join the Telegram group in the repository’s [README](https://github.com/paradigmxyz/reth/blob/main/README.md), or reach out to [georgios@paradigm.xyz](mailto:georgios@paradigm.xyz). See you on [Github](https://github.com/paradigmxyz/reth). *Author’s note: None of this would have been possible without the beyond excellent team working on Reth with me, since we started this project late 2022. Working with* [*Aleksey Shekhirin*](https://github.com/shekhirin)*,* [*Dan Cline*](https://github.com/rjected)*,* [*Dragan Rakita*](https://github.com/rakita)*,* [*joshieDo*](https://github.com/joshiedo)*,* [*Matthias Seitz*](https://github.com/mattsse)*,* [*Oliver Nordbjerg*](https://github.com/onbjerg) *and* [*Roman Krasiuk*](https://www.paradigm.xyz/2023/06/rkrasiuk) *has been one of the greatest privileges of my software engineering career and I feel lucky to have such people around me, hopefully for a long time in the future.* # Reth FAQ ### Is Reth production-ready? Reth is currently unaudited software, early in its testing lifecycle, and it’s provided as-is without warranty. We intend to transition it to beta and then “1.0” as more testing happens and parts of the codebase get audited. We are excited for the first wave of testers to share their feedback around Reth’s production-readiness. Run a node, and let us know what is needed for Reth to meet the production-readiness bar for you! ### Are people running nodes? There [already](https://ethernodes.org/) some synced Reth nodes in public! You can try out ours by querying [http://45.250.253.77:8545](http://45.250.253.77:8545/) directly, or via Foundry: `cast block-number --rpc-url http://45.250.253.77:8545` . The node is not behind any rate limiter or firewall at the moment, so we are only temporarily opening up access to JSON-RPC and intend to gradually close off the publicly exposed port 8545 in the coming weeks. ### What projects are “Built with Reth” already? Here are some ecosystem projects from early adopters, using Reth as a library: - [Vid201/aa-bundler](https://github.com/Vid201/aa-bundler): An ERC4337 bundler, using Reth’s Database bindings. - [SorellaLabs/ethers-reth](https://github.com/SorellaLabs/ethers-reth): A ether-rs middleware for reth that bypasses JSON-RPC allowing for 2-3x faster forking tests over local HTTP/IPC, using Reth’s Database bindings. - [ethereum/trin](https://github.com/ethereum/trin/): A Portal Network client, using Reth’s IPC bindings. - [mouseless-eth/rusty-sando](https://github.com/mouseless-eth/rusty-sando): An MEV bot, using Reth’s Access List inspectors. - [Will-Smith11/reconnaissance](https://github.com/Will-Smith11/reconnaissance) and [jonasbostoen/reth-p2p-showcase](http://github.com/jonasbostoen/reth-p2p-showcase): P2P sentry nodes using Reth’s P2P implementation. - [kkrt-labs/kakarot-rpc](https://github.com/kkrt-labs/kakarot-rpc): A Cairo ZK EVM JSON RPC proxy using Reth’s JSON-RPC API. - [trianglesphere/rnode](https://github.com/trianglesphere/rnode): An experimental Optimism fault proof program using Reth’s primitive types. - Private Block Builders by MEV traders using Reth’s [PayloadBuilder](https://paradigmxyz.github.io/reth/docs/reth_payload_builder/index.html) abstraction. ### What chains does Reth support? Reth currently supports Ethereum-based chains such as Ethereum mainnet, Goerli, Sepolia, the Ethereum Foundation’s testnets etc. Reth does not support other chains like BSC, Polygon or Fantom, but we are interested in learning more about it. We intend to explore supporting OP Stack in the near future, see [here for some preliminary work](https://github.com/paradigmxyz/reth/pull/1569/files). If you are interested in building that out, please reach out. ### What sync modes are provided? Reth currently only provides archive sync. We intend to provide more granular storage and syncing options in the near future (like full node & snapshots), which you can track on [Github](https://github.com/paradigmxyz/reth/issues/2629). Our ultimate goal is to allow running a node with the minimal storage requirements needed for your needs. Please reach out if you have feedback or ideas you think we should incorporate here. ### What are the hardware requirements for a Reth archive node? For best performance, our hardware recommendations are: - At least 2TB NVMe SSD drive. We expect the 2TB threshold for archive sync to be crossed soon, so we recommend getting extra disk space. - At least 8GB of RAM: While Reth is memory efficient, we did not benchmark with smaller memory boxes. - Higher clockspeed CPUs (over higher threads) as most of the time is spent on serial execution operations. - 24MBit network connection ### What about non-NVMe disks? Syncing an Ethereum node is bottlenecked on disk reads and writes. As a result, it’s usually recommended to run a node using an NVMe drive. These are not always available, so we explored the time to sync on cheaper, consumer hardware. On non-NVMe drives provided by GCP (“Persistent SSD”) Reth took approximately 9 days to sync in our most recent benchmark. Third-party node operators have reported ~4 days to sync on a dual-SATA RAID-0 disk setup. We are excited for Reth to lower the barrier to entry Ethereum nodes on consumer hardware. If you are a node operator who can help us test Reth on a variety of hardware & software configurations (e.g. consumer disks, ARM devices, niche OSes) please reach out. ### What methodology did you use for your syncing benchmarks? We used bare metal hardware on Latitude.sh. Specifically, we synced an Erigon and Reth node on a a c3.large.x86 machine (Debian, 2TB NVMe SSD, 256GB RAM, 10Gbit bandwidth, AMD 2.85GHz 24 cores), and measured the time they took from genesis to following the chain’s tip. In both cases, the default node configuration was used. ### What methodology did you use for your RPC benchmarks? Large infrastructure players seek high RPC performance across a variety of calls, under heavy load. This can get resource intensive on cloud hardware, especially as customer needs grow. Measuring RPC performance is nuanced as it requires understanding throughput & latency of each RPC method under increasing loads, while also making sure the requests being sent to the node resemble real load. To address that, we developed [Flood](https://www.paradigm.xyz/2023/06/flood), a benchmarking tool for RPC nodes which produces detailed [reports](https://datasets.paradigm.xyz/notebooks/flood/example_report.html) about the error rate, throughput and latency of various RPC calls. Equipped with that information, we improved Reth’s performance characteristic for each RPC method. We caveat that while our results are encouraging, Flood is a synthetic benchmark and might be prone to measurement mistakes. We are excited to produce more benchmarks, especially around tracing, so please reach out if you have tracing loads you would be interested in benchmarking Reth with. ### How is this so fast and compact? There is not one “trick” which we implemented that made the node fast and small. Some of the key factors are: - Erigon-style staged sync to maximize batch processing during historical sync and optimizing around the bottlenecks of each process. - [Flat database format](https://github.com/paradigmxyz/reth/blob/77d5216192edabc0669b18ef9e03e71ca76300dd/docs/design/database.md#table-design) for efficient DB queries. - Optimized database footprint using a bespoke encoding for Ethereum datatypes and `zstd` compression trained on historical data. - Heavy usage of custom-written futures/streams/background jobs for saturating resources at all times. - Revm, a blazing-fast EVM which separates DB calls from the interpreter, also used in Foundry and other performant infrastructure. - Rust, for careful resource management and performant code in the resulting binary. We also profile node internals using Prometheus/Grafana & structured log tracing, while utilizing popular systems tools like perf, flamegraphs and heaptrack. Finally, we built [Flood](https://www.paradigm.xyz/2023/06/flood), a differential testing & benchmarking tool to ensure RPC responses across node implementations match & improve performance. ### How did you test the node and identify bugs? We took a multi-layered approach to testing & profiling Reth. Here are some of the processes we follow: - We frequently re-sync Reth from genesis on Etheruem mainnet & testnets, which acts as the ultimate end-to-end test. In parallel, we are working on an automated framework for running nodes from genesis to quickly detect correctness or performance regressions. - We run the Hive testing suite nightly on Github Actions; Hive is the table-stakes testing suite for any Ethereum node implementation. - We document the whole codebase extensively, disallowing publicly exposed code that is undocumented. In some critical cases like the Engine API, [we go as far](https://github.com/paradigmxyz/reth/blob/b19e12341d5f9986baec30e849d96bedb0a01d89/crates/consensus/beacon/src/engine/mod.rs#L716) as document parts of the Execution Layer specs in the codebase. - Bluealloy runs the EVM state tests on every Revm PR to ensure their implementation remains sound. - We run the forking tests of popular Foundry repositories, to ensure the ecosystem around Reth works as expected. - We fuzz-test sensitive parts of the code, to ensure edge cases are covered. - We extensively unit test the entire codebase, to ensure correctness and avoid regressions. *Acknowledgments: Thanks to Matt Huang, Dan Robinson, Dave White, Storm Slivkoff, Tim Beiko, Danny Ryan, and Mike Neuder for reviews on earlier drafts of this post. Thanks to the many early node testers who have given us invaluable feedback towards improving Reth so far. Thanks to Achal Srinivasan for the graphics.* ## https://www.paradigm.xyz/writing/paradigm-comments-on-the-sec-s-proposed-redefinition-of-exchange # Paradigm Comments on the SEC's Proposed Redefinition of Exchange > Through this haphazard rulemaking, the SEC inappropriately attempts to bring crypto trading platforms, including DEXs, under its remit and regulate them as securities exchanges. It thus appears that after suing Coinbase for failing to do the impossible—registering as a securities exchange when it was incapable of doing so—the Commission now intends to force DEXs into the same Hobson’s choice. **TLDR**: Today, Paradigm [commented](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-0a2123070e/0a711c96c3b772711fb5e9e4d0892d26/asset-https-cdn-sanity-io-files-dgybcd83-p-0a2123070e.pdf) on the SEC’s [proposed redefinition](https://www.sec.gov/rules/proposed/2022/34-94062.pdf) of “exchange.” Through this haphazard rulemaking, the SEC inappropriately attempts to bring crypto trading platforms, including DEXs, under its remit and regulate them as securities exchanges. It thus appears that after suing Coinbase for failing to do the impossible—registering as a securities exchange when it was incapable of doing so—the Commission now intends to force DEXs into the same Hobson’s choice. As our comment letter highlights, the SEC’s rulemaking proposal veers far outside the SEC’s statutory jurisdiction and violates the Administrative Procedure Act, a key law that protects the American public against autocracy and bureaucratic whim—it should therefore be promptly withdraw. Although the acronym “DEX” includes the word “exchange,” DEXs differ from traditional “exchanges” in several fundamental respects, which makes treating them alike incoherent. The “exchanges” the SEC has authority to regulate: 1) serve as intermediaries in securities transactions; AND 2) are run by some specific entity capable of collective action. These features are plainly set forth in the Exchange Act’s own definition of “exchange.” 15 U.S.C. § 78c(a)(1). They are also crucial components of the Act’s history and purpose. But DEXs lack both of these critical features. A DEX, particularly one using automated market maker mechanisms, involves no person intermediating transactions between buyers and sellers—instead, it uses an algorithm to balance pools of crypto assets that potential buyers or sellers can freely access. Nor is a DEX run by any entity capable of collective action, but rather relies on self-executing code that in many instances cannot be changed or upgraded. No matter how you jostle or squint at them, DEXs are not “exchanges” as contemplated by the Act, and the SEC’s proposal to treat them as such is beyond its statutory jurisdiction. The SEC’s proposal also draws arbitrary and capricious distinctions amongst developing technologies and replaces well-understood terms with novel, vague, and ambiguous ones. The result is that the agency’s newfound definition of “exchange” is so far-reaching that it would facially encompass entities that are plainly nothing like exchanges, such as Bloomberg’s messaging service. The SEC purports to solve this problem by simply carving those messaging services out of the definition by blunt force, but that move is itself arbitrary and capricious. Finally, the SEC’s haphazard proposal also violates the rulemaking procedures of the Administrative Procedure Act. The SEC first surfaced its revolutionary new definition in a March 18, 2022 notice, which failed to mention DeFi and suffered from a far-too-short, 30-day comment period and a total absence of cost-benefit analysis. The SEC effectively acknowledged these shortfalls by reopening the comment period, first in May of 2022 and again in April of 2023. But these make-up comment periods do not solve the procedural flaws inherent in the original notice. To the contrary, by the time the SEC actually stated its intent to regulate DEXs in the April 2023 notice, the notice made clear that its mind had been closed on the matter—a clear violation of the APA’s requirement of a fair opportunity for public comment. The SEC’s admission of its own errors does not resolve them; there is no “get out of jail free” card under the APA. In short, the proposed rules are fatally flawed on the merits and procedural grounds. They should promptly be withdrawn. ## https://www.paradigm.xyz/writing/flood # Introducing flood: a load testing tool for benchmarking EVM nodes > Load testing is a critical step in the development of resilient, high-performing data systems. Nevertheless, load testing has not been widely applied in the development of cryptocurrency infrastructure. We're thrilled to bridge this gap with the introduction of flood, a benchmarking tool specifically designed for performance analysis of RPC endpoints. # Introduction Load testing is a critical step in the development of resilient, high-performing data systems. Nevertheless, load testing has not been widely applied in the development of cryptocurrency infrastructure. We're thrilled to bridge this gap with the introduction of `flood`, a benchmarking tool specifically designed for performance analysis of RPC endpoints. We initially built `flood` as a tool to optimize [Reth](https://www.paradigm.xyz/2022/12/reth) and understand its [latency and throughput](https://www.paradigm.xyz/2022/07/consensus-throughput) tradeoffs under various loads. However, we believe `flood` has significant utility beyond Reth for optimizing the performance of many types of crypto infrastructure. We are excited to open source `flood` under the Apache/MIT license as free, open-source software. Its code and installation instructions can be found in the Github [repository](https://github.com/paradigmxyz/flood). `flood` can be used either from the command line or as a python library. There is also a [Docker image](https://github.com/paradigmxyz/flood/blob/main/Dockerfile) of `flood` for easy integration into CI/CD and other types of pipelines. Let’s dive in. # What is load testing and why does it matter? *Load testing* refers to measuring how the performance characteristics of a system are affected by different types of workloads. The key insight behind this approach is that performance metrics such as throughput, latency, and error rate typically degrade when a system is placed under increasing amounts of load. **Therefore, observing a system under different controlled loads can reveal insights into the bottlenecks, failure modes, and ultimate performance capacity of the system**. The information obtained by load testing can be leveraged in numerous ways. When a system is under active development, load testing highlights whatever system bottlenecks are most in need of improvement. When comparing two systems, load testing can reveal which system is more performant or reliable. As a special case of this, load testing can compare two different hardware or software configurations of a single system. In each case, **load testing enables the development of highly optimized systems.** ## How to load test blockchain nodes? Our focus is on *RPC*, which is the communication protocol typically used for extracting data from blockchain nodes. Currently, the most common approach for measuring RPC performance is not load testing, but *latency testing*: you send an RPC node a request, and measure how long it takes to obtain a response. Latency testing for a variety of RPC providers can be found [on](https://rpclist.com/) [various](https://chainlist.org/chain/1) [websites](https://www.comparenodes.com/). Unfortunately, this type of testing offers a limited view of node performance because it reveals almost nothing about how the system behaves under load (see our post on measuring [latency and throughput](https://www.paradigm.xyz/2022/07/consensus-throughput) for details). In the context of blockchains, workloads can vary in two important ways. The classic variable is size. A load of 10,000 requests per second will put more stress on a system than a load of 100 requests per second. The other load variable is the RPC method. There is a different RPC method for each type of data that you pull from a blockchain node. For example, blocks vs transactions vs logs vs traces. Each RPC method puts a different type of load on the system. Some RPC methods are bound by storage IO whereas others are bound by CPU. # What is flood? With these principles in mind, we developed a load testing tool called `flood`. `flood` offers an unprecedented view into the performance characteristics of a RPC endpoint by 1) embracing load testing instead of latency testing and 2) expanding test coverage to all relevant RPC methods. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--e4f9e62cff/6e2e979c4fbe8fb474c9ac2ed54bdb83/asset-https-cdn-sanity-io-images-dgybcd83--e4f9e62cff.png) `flood` consists of 3 basic components: 1. Call generation engine: `flood` generates large parameterized sets of RPC calls, randomly sampled with distributions that resemble different types of blockchain workloads. `flood` leverages [Paradigm Data Portal](https://data.paradigm.xyz/) datasets to ensure full coverage of blockchain history. 2. Load testing engine: `flood` then orchestrates [Vegeta](https://github.com/tsenart/vegeta) (a high performance load testing tool written by [@tsenart](https://github.com/tsenart) in Go) to use these calls for load tests against RPC endpoints. 3. Reporting engine: After performing tests, `flood` summarizes the results with various charts, tables, and reports. These summaries are easy to integrate into scripts and data pipelines. Each of these components is highly configurable, enabling `flood` to cover a wide range of test scenarios and environments. ## What can flood do? During the typical operation of `flood`, a user specifies the RPC methods they would like to test along with a list of RPC endpoints. For example, you might want to test the performance of `eth_getLogs` for two versions of Reth. `flood` will then run different controlled loads against those RPC endpoints. For example, it might run `eth_getLogs` at 1,000, 2,000, 4,000, and 8,000 requests per second. `flood` will then display tables and charts that summarize how the performance metrics vary as a function of load. The output will look something like this: ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--f609d25fe2/10ad138617c9d244ae63f11f3420a3eb/asset-https-cdn-sanity-io-images-dgybcd83--f609d25fe2.png) See example of a real `flood` report [here](https://datasets.paradigm.xyz/notebooks/flood/example_report.html). The particular way in which performance metrics degrade under load offers a rich set of insights into the bottlenecks and ultimate performance capacity of a system. For details on interpreting and leveraging load testing data, we recommend Chapter 15 of Cesarini's [Designing for Scalability with Erlang/OTP](https://www.oreilly.com/library/view/designing-for-scalability/9781449361556). Beyond this simple mode of operation, `flood` also provides advanced features to accommodate various types of power users: - `flood` can use different load testing schedules, including: “stress testing” (gradually increasing load over time), “spike testing” (a large sudden load followed by small load), and “soak testing” (running a load for a long period of time). - `flood` can orchestrate load tests to run in a local mode on each RPC node to eliminate noise caused by network bottlenecks. - `flood` has an “equality” testing mode that checks whether each RPC endpoint is returning identical responses. ## Why did you build flood? At Paradigm we are developing a new node implementation called [Reth](https://paradigmxyz.github.io/reth/) with performance standing as one of its primary objectives. We developed `flood` in order to characterize Reth’s performance in a detailed way. We have already used `flood` to uncover numerous Reth performance bottlenecks appearing under various workloads and system configurations. These bottlenecks were then rectified. With `flood` we have created a tight feedback loop where the Reth developers have high visibility into how any codebase changes translate into end-to-end system performance. Beyond Reth, we believe `flood` wil be able to help resolve many unanswered questions related to RPC nodes in general: - Which hardware specs matter most when running a node? What is the relative importance of storage IO vs RAM speed vs RAM capacity vs CPU speed? Is RAID worth it? - What is the effective rate limit of each RPC method for each 3rd party RPC provider? - Which node client offers the best performance for different types of workloads? # Conclusion In this post we introduced `flood`, a load testing tool that offers an unprecedented view into the performance characteristics of blockchain nodes. Although we originally built `flood` to optimize the development of Reth, we believe it will be a huge unlock for the development of other types of high performance crypto infrastructure. We look forward to seeing how others might use `flood` to build their own performant and reliable systems. If you are interested in using `flood`, or want to contribute to `flood`, please check the [Issue Tracker on Github](https://github.com/paradigmxyz/flood/), or reach out to [storm@paradigm.xyz](mailto:storm@paradigm.xyz) or [georgios@paradigm.xyz](mailto:georgios@paradigm.xyz). *Thanks to* [*Achal Srinivasan*](https://www.paradigm.xyz/team/achalsrinivasan) *for the graphics.* ## https://www.paradigm.xyz/writing/paradigm-files-amicus-brief-in-coin-center-lawsuit-over-tornado-cash-sanctions # Paradigm Files Amicus Brief in Coin Center Lawsuit over Tornado Cash Sanctions > Paradigm filed an amicus brief in the lawsuit that Coin Center and others brought in Florida to challenge the government’s sanctioning of the Tornado Cash open-source code. **TLDR**: Paradigm filed an [amicus brief](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-3559056eef/70cbbb29f9d5a73cbd8a86990c2938f2/asset-https-cdn-sanity-io-files-dgybcd83-p-3559056eef.pdf) in the [lawsuit](https://www.coincenter.org/coin-center-is-suing-ofac-over-its-tornado-cash-sanction/) that Coin Center and others brought in Florida to challenge the government’s sanctioning of the Tornado Cash open-source code. Our brief reiterates the simple point we [previously made](https://paradigm.xyz/writing/2023/04/paradigm-files-van-loon-amicus-brief) in the *Van Loon* litigation in Texas: OFAC is authorized to sanction only “people” or “entities,” and their “property.” Tornado Cash fits none of those definitions—it is merely open-source [code](https://github.com/tornadocash/tornado-core). As we have [previously](https://paradigm.xyz/writing/2023/04/paradigm-files-van-loon-amicus-brief) outlined in more detail, OFAC’s sanctions rest on the theory that Tornado Cash is an “entity” composed of two loosely affiliated groups that, when joined together, give life to a new Frankenstein-like legal “person.” According to OFAC, the first half of the Tornado Cash “entity” is supposedly composed of the unnamed founders and “associated developers,” which in the context of open-source development, is a highly ambiguous term that could include developers who indirectly contributed to Tornado Cash code. The second half of the “entity” is allegedly the “Tornado Cash DAO,” made up of *every* TORN token holder. As our *amicus* brief argues, OFAC’s theory that Tornado Cash is an unincorporated entity is wrong on the law. None of the developers or tokenholders expressed intent to work towards a common purpose, which is required for the creation of an unincorporated association. Moreover, in the ongoing *Van Loon* litigation, OFAC has also previewed a new part of their theory for sanctioning Tornado Cash, which we address for the first time in our latest brief. According to OFAC’s novel argument, the fact that certain registered relayers pay fees to the DAO treasury, means that Tornado Cash has a property interest in the smart contracts. However, relayers are an optional service that is run by third parties (see transaction flow below). In fact, anyone, including Paradigm, could run a relayer by deploying the publicly available open-source code, and these relayers are not required to pay a fee. The flaw in OFAC’s novel theory is evident when you consider no purported entity can have a property interest in transactions that it will not receive anything from. ![Tornado Cash Transaction Flow](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--e8a3f4a158/e984554ef5db904c0d598c1f4dfc9704/asset-https-cdn-sanity-io-images-dgybcd83--e8a3f4a158.png) *Tornado Cash Transaction Flow* ## https://www.paradigm.xyz/writing/intents # Intent-Based Architecture and Their Risks > The road to centralisation is paved with good intents. # Introduction Recently, discussion around “intents” and their application have been a dominant topic in the Ethereum community. If a transaction explicitly refers to “how” an action should be performed, an intent refers to “what” the desired outcome of that action should be. If a transaction says *“do A then B, pay exactly C to get X back”*, an intent says *“I want X and I’m willing to pay up to C”*. This [declarative paradigm](https://twitter.com/CannnGurel/status/1663292583550803969) unlocks exciting improvements in UX and efficiency. With intents, users are able to simply express a desired outcome while outsourcing the task of best achieving that outcome to sophisticated third parties. The notion of intents contrasts with today’s imperative paradigm of transacting where every parameter is explicitly specified by the user. While the promise of these improvements presents a much-needed step for the ecosystem, intent-based designs on Ethereum can also have significant ramifications for off-chain infrastructure. In particular, there are important connections to MEV-related activities and market control. This post seeks to provide a brief definition of intents and their benefits, an exploration of the risks involved with their implementation and some discussion of potential mitigations. # What Are Intents? The current standard method through which users interact with Ethereum is to craft and sign **transactions**, messages in a specific format that provide all of the necessary information for the Ethereum Virtual Machine (EVM) to execute a state transition. However, creating transactions can be a complicated affair. Creating transactions requires reasoning about a vast web of smart contracts and details like nonce management while holding a specific asset to pay gas fees. This complexity leads to suboptimal UX and lost efficiency due to users being forced to make decisions without sufficient access to information or sophisticated execution strategies. Intents arose to alleviate the user of these burdens. Informally, **an intent is signed a set of declarative constraints which allow a user to outsource transaction creation to a third party without relinquishing full control to the transacting party.** In the standard transaction-based flow, a transaction signature permits the validator to follow exactly one computational path against a certain state while a tip incentivises the validator to do so. On the other hand, an intent does not specify exactly what computational path must be taken, but rather allows for any which satisfy certain constraints. **By signing and sharing an intent, a user is effectively granting permission to recipients to choose a computational path on their behalf** (see figure below). This distinction allows a slightly more rigorous definition of intents as **signed messages which allow for a set of state transitions from a given starting state, a special case of which is a transaction which allows for a unique transition**. That being said, we will continue to refer to “intents” as distinct from transactions. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--99fe944ab7/360256652a1859974283ba54da21f92a/asset-https-cdn-sanity-io-images-dgybcd83--99fe944ab7.png) Importantly, many intents can be included in a single transaction, allowing for matching overlapping intents, increasing gas and economic efficiency, e.g. in a [builder-maintained orderbook](https://jumpcrypto.com/writing/searcher-limit-order-book) where two orders can be netted against each other before going to a market. Other applications include cross-domain intents - signing one message instead of multiple transactions on different domains - using [different replay resistance](https://nmohnblatt.github.io/zk-jargon-decoder/definitions/nullifier.html) schemes, and more flexible user gas payments like allowing 3rd parties to sponsor gas or for payments in different tokens. ## The Past and Future is Intents Intents have been created for the outsourcing of the complexities of interacting with the blockchain while permitting users to maintain custody of their assets and cryptographic identity. You may notice that many of these ideas correspond to systems that have been in operation for several years: 1. **Limit Orders**: 100 X may be taken from my account if I receive at least 200 Y. 2. **CowSwap-style Auctions**: same as above, but rely on a third-party or mechanism to match many orders to maximise execution quality. 3. **Gas Sponsorship**: Pay gas in USDC instead of ETH. The intent can only be fulfilled with a matching intent which pays ETH in fees. 4. **Delegation**: Only allow interacting with certain accounts in certain pre-authorized ways. The intent can only be fulfilled if the final transaction respects the access control list specified in the intent. 5. **Transaction Batching**: Allow batching of intents for gas efficiencies. 6. **Aggregators**: Only use “best” price/yield for an action. The intent can be fulfilled by showing a proof that an aggregation over multiple venues was executed and the optimal path was taken. Looking forward, intents are seeing renewed excitement in the context of cross-chain MEV (e.g. SUAVE), [ERC4337](https://eips.ethereum.org/EIPS/eip-4337)-style account abstraction, or even [Seaport Orders](https://github.com/jameswenzel/the-circus/)! While ERC4337 is moving full steam ahead, other novel applications like [cross-domain intents](https://www.youtube.com/watch?v=G0nFyq9DDPw&feature=youtu.be) still require further research. Further discussion of intents and their applications can be found in [this talk](https://www.youtube.com/watch?v=zxTPIvtYaUc). **Critically, across all old and new intent-based applications there needs to be at least one other party who is aware of the intent, incentivised to execute the intent and able to do so in a timely manner**. The questions of *who* these parties are, *how* execution takes place and what their *incentives* are, must be asked to determine the efficacy, trust assumptions and broader-impact of an intent-driven system. ## The Middlemen & Their Mempools The most obvious channel for an intent to find its way into the hands of a willing middleman is the Ethereum mempool. Unfortunately, the current design does not support the propagation of intents. Concerns around DoS attacks may mean that generic support for fully general intents in the Ethereum mempool is out of the question even in the long term. As we will see below, the open and permissionless nature of the Ethereum mempool poses additional obstacles to adoption for intents. In the absence of the Ethereum mempool, intent system designers are now faced with some design questions. One high-level decision is whether intents will be propagated to a permissioned set or be available in a permissionless manner so that any party can execute the intent. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--6da00d9646/a5de79b165ab53a394b56e0f3352da0d/asset-https-cdn-sanity-io-images-dgybcd83--6da00d9646.png) ### Permissionless Mempools One design one might strive for is a decentralised API that allows for the gossipping of intents across various nodes in a system, providing permissionless access to executors. This has been done before. For example, in 0x protocol relayers gossip limit orders among each other and put them on-chain when there is a match. The idea is also [being explored in the context of a shared ERC4337 mempool](https://notes.ethereum.org/@yoav/unified-erc-4337-mempool) to combat centralization and censorship risk. However, the design of such permissionless “intentpools” faces some significant challenges: - **DoS resistance**: one might have to limit the functionality of intents to avoid attack vectors (see the [ERC4337 proposal](https://notes.ethereum.org/@yoav/unified-erc-4337-mempool) for further discussion) - **Propagation incentives**: for many applications, executing an intent is a profitable activity. Thus, nodes operating the intentpool have an incentive not to propagate, to reduce competition in executing the intent. - **MEV**: intents, which rely on good behaviour of off-chain actors for execution quality, may face difficulty using a public, permissionless intentpool. If poor execution is profitable, permissionless intentpools are likely to lead to this outcome. This is similar to sandwiching in the Ethereum mempool today and is anticipated to be a widespread problem for DeFi-related intents. A possible path forward here might be permissionless, but encrypted intentpools. ### Permissioned “Mempools” A trusted centralised API is much more DoS resistant and does not need to propagate intents. The trusted model also provides some foothold against MEV concerns. As long as the trust assumptions hold, execution quality should be as guaranteed. Trusted middlemen may also have reputations associated with them, providing some incentive to provide good execution. Because of this, permissioned intentpools are attractive to intent-based application developers in the short term. However, as we are all well aware, strong trust assumptions have shortcomings and are somewhat antithetical to much of the blockchain ethos. These issues will be touched on below. ### Hybrid Solutions There are solutions which are mixtures of the above. For example, one could have permissioned propagation, but permissionless execution (assuming trust assumptions hold) or vice versa. A common example of a hybrid solution is [order flow auctions](https://writings.flashbots.net/order-flow-auctions-and-centralisation-II/). The high-level idea of these designs is that users who need a counterparty may need to differentiate between better and worse counterparties (e.g. to take the other side of a trade at a favourable price). The design flow usually includes a trusted party who receives the intents (or transactions) from the user and facilitates the auction on their behalf. Participation in the auction is (sometimes) permissionless. These kinds of designs have their own shortcomings and are likely subject to many of the concerns around permissioned intentpools, but there are some important differences that will become apparent later. **Bottom line: Intent-based applications involve more than just a new message format for interacting with smart contracts, they also involve propagation and counterparty discovery mechanisms in the form of alternative mempools. It is not trivial to design a mechanism for intent discovery and matching which is incentive-compatible and not centralizing at the same time.** # What Can Go Wrong? While intents are an exciting new paradigm for transacting, their widespread adoption may imply an acceleration of a larger trend of user activity shifting to alternative mempools. If improperly managed, this shift risks centralisation and entrenchment of rent-seeking middlemen. ## Order Flow *If intent execution is permissioned and the permissioned set is not chosen with care, the migration out of the public mempool threatens to centralise block production on Ethereum.* The vast majority of block production on Ethereum currently happens via MEV-Boost, an out-of-protocol implementation of [proposer-builder separation (PBS)](https://notes.ethereum.org/@vbuterin/pbs_censorship_resistance) and current roadmaps show no indication that this interface will change any time soon. PBS relies on the presence of a competitive market of block builders to channel [MEV](https://arxiv.org/abs/1904.05234) to the validator set. One major concern in PBS is that a block builder is able to acquire exclusive access to the raw materials required to produce valuable blocks - transactions and intents, AKA “order flow”. In the language of PBS, permissioned access to intents would be known as “exclusive order flow” (EOF). As discussed in [this article](https://writings.flashbots.net/order-flow-auctions-and-centralisation), EOF in the hands of the wrong party threatens the market structure upon which PBS hinges as the exclusivity of order flow implies a moat against competitive forces. A block builder (or a partnered entity) with control over a large share of Ethereum’s order flow would be in a position to produce the majority of mainnet blocks, opening a vector for censorship. As the network relies on competition between builders to channel value to validators (or to be [burned in future](https://ethresear.ch/t/burning-mev-through-block-proposer-auctions/14029)), the dominance of a single builder would constitute a shift of value from Ethereum to the builder. Rent-seeking and censorship are certainly important threats to the protocol. ## Trust *As many solutions require trust in intermediaries, development of new intent-based architectures is hampered by high barriers to entry, implying lower rates of innovation and competition to ensure execution quality.* In the worst case, a user finds themself in the position in which there is a single party executing intents, such as the monopolist block builder from the section above. In such a world, the monopolist block builder would be able to *extract rents* and any new proposal for how intents should be processed would be *denied traction* if not adopted by the builder. In the face of a monopolist, individual users lose negotiating power - an effect which is exacerbated when users use intents to give additional degrees of freedom to middlemen. Unfortunately, market stagnation due to centralised infrastructure is not contained to concerns over the builder market. Even for non-block building operations, high barriers to entry can place middlemen in a powerful position as they face little competition. Consider for example, the state of the current order flow auction market. Several entities like Flashbots and CoWswap receive the majority of the order flow destined for OFAs. The distribution of order flow is in no small part due to the fact that these entities have existed for years or are associated with reputable entities, meaning they have successfully captured a degree of public trust. If a new OFA design were to attempt to enter the market, whoever was operating the new OFA would have to spend a lot of time convincing users and wallets that they are reputable and would not abuse their position. The necessity of such a campaign to win trust certainly constitutes a substantial barrier to entry. The order flow auction market has only recently begun to pick up attention and it remains to see how competition will develop, but the market does provide an illustrative example of a setting in which permissioned, trusted mempools could enshrine a handful of powerful actors, undermining users’ best interests. The EIP4337 intent format provides another example of where we are at risk of enshrining a certain kind of mechanism. Consider a world in which trusted architecture has been put in place to support 4337 intents. If another intent format - perhaps serving additional use cases like cross-domain functionality - is proposed, but the established trusted middlemen do not adopt this new format (after all, it doesn’t have much adoption and competes with their business model), the implementation of the new format would require establishing trust in new entities. Again, we find ourselves in the position where innovating and challenging the status quo is met with trust-based barriers to entry. ## Opacity *As many intent architectures entail the user surrendering some control over their on-chain assets and permissioned mempools imply a degree of impenetrability from the outside, we risk building an opaque system in which it is unclear how or whether users’ expectations are met and threats to the ecosystem remain undetected.* The sections above pertain to the risk that power imbalances in the order flow market pose to users and the protocol. A related concern is that the ecosystem of middlewares and mempools that is developing between the user and the blockchain becomes opaque even to astute observers. This concern is particularly pertinent for intent-based applications which seek to allow the user to outsource important decisions like order routing. The occasions on which MEV negatively impacts user execution generally arise due to high degrees of freedom that transactions give up to their executors (e.g. slippage limits). It is thus no great leap in logic to assert that intent-based applications which surrender greater degrees of freedom should design their systems for execution with greater caution. The worst-case outcome in this regard is a world in which using an intent-based application entails signing an intent that disappears (into the dark forest, if you will) and then somehow materialises as a transaction(s) with no clarity on how or by whom the transaction was created. Of course, the ability to monitor such an ecosystem relates to concerns around EOF and trust-based entrenchment as well. How is the Ethereum community supposed to monitor for threats to the health of its block production ecosystem if this ecosystem is obscure even to the most astute observers? # Mitigating Risks The Ethereum mempool is limited. For some applications, this is due to its lack of privacy (sandwiching) and for others, it is due to its inability to support broader message formats. This leaves wallets and application developers in a difficult position as they must find some way to connect users to the blockchain while avoiding the dangers highlighted above. In examining the issues above, we can extrapolate some properties of an ideal system. Such a system should be **permissionless** so that anyone can match and execute intents while not trading off much **execution quality**; **general** so that deploying new applications doesn’t require standing up new mempools; and **transparent** so that the process by which intents are executed is reported publicly and data for execution quality auditing is made available, when privacy guarantees allow. While teams like Flashbots and Anoma are working towards general-purpose solutions that satisfy the requirements above by marrying privacy and permissionlessness, the ideal system will likely not be ready in the near term. As such, different solutions making their own tradeoffs may serve different applications best. Although mechanisms like [crlists](https://notes.ethereum.org/@fradamt/forward-inclusion-lists) that came as a response to many of the same concerns around transaction-based applications may not be available for intents, small tools, like allowing users to fall back to transactions where possible, may do well to improve worst-case scenarios. In a similar vein, applications looking to launch intentpools, would do well to seek generality if permissionless and select middlemen cautiously if permissioned. Speaking broadly, we ask that intent-based application designers consider thoroughly the off-chain implications of their applications as these may touch the broader community, not just their user base, and we ask that the broader community maintains a watchful eye over the developments of the off-chain ecosystem surrounding Ethereum. # Conclusion The adoption of intents represents a shift from an imperative to a declarative paradigm, which promises to improve UX and efficiency loss due to MEV leakage significantly. The demand for these applications is clear and many intent-based applications have been used widely for several years. A growing adoption of intents, partly driven by ERC4337, is likely accelerating a move from the Ethereum mempool to new venues. Whereas this move is justified and inevitable, intent-based application designers have strong reason to be cautious in designing the off-chain components of their systems while robust infrastructure is in development. There is still plenty of research and engineering to do in this nascent transacting paradigm and areas we didn’t cover in this post such as designing an [intent-expression language that allows for privacy](https://docs.juvix.org/0.3.3/). If you find this or other intent-related research subjects enticing, please reach out to [0xquintus](https://twitter.com/0xquintus) [georgios@paradigm.xyz](mailto:georgios@paradigm.xyz). Many thanks to [Dan Robinson](https://twitter.com/danrobinson), [Charlie Noyes](https://twitter.com/_charlienoyes), [Matt Huang](https://twitter.com/matthuang), [John Guibas](https://twitter.com/jtguibas), [Xinyuan Sun](https://twitter.com/sxysun) and [Elijah Fox](https://twitter.com/PossibltyResult) for their feedback on this article and [Achal Srinivasan](https://twitter.com/achalvs) for designing the figures. ## https://www.paradigm.xyz/writing/paradigm-files-amicus-brief-in-ny-ag-s-case-against-kucoin-pushing-back-against-allegation-that # Paradigm Files Amicus Brief in NY AG's Case Against KuCoin Pushing Back Against Allegation that ETH is a Security > Paradigm filed an amicus brief in the lawsuit that the NY AG brought against KuCoin, in which the OAG alleged that certain tokens traded by KuCoin, including ETH, are securities. Our brief highlights the unfairness of the OAG’s tactics, which deprive the most affected parties an opportunity to defend themselves in court. **TLDR**: Paradigm filed an [amicus brief](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-3749ee06ac/b3e1dfc012840d4d3561694255aaeaee/asset-https-cdn-sanity-io-files-dgybcd83-p-3749ee06ac.pdf) in the lawsuit that the NY AG (the “OAG”) brought against KuCoin, in which the OAG alleged that certain tokens traded by KuCoin, including ETH, are securities. Our brief highlights the unfairness of the OAG’s tactics, which deprive the most affected parties an opportunity to defend themselves in court. Unless courts put a stop to it, this tactic risks becoming a hallmark of crypto regulation in the US. Our hope is this court will see through the government’s attempt to circumvent due process and avoid making any determination about the security status of ETH. To support the claim that KuCoin violated NY securities laws by failing to register as a securities broker or dealer, the OAG alleged in its Petition that various tokens sold and purchased by KuCoin, including ETH, are securities. ETH has been circulating publicly since 2014, and there has never been any prior finding that ETH is a security. Yet the OAG is trying the due process side door: alleging that the world’s second most valuable token is a security in an action against an unrelated third party who is unlikely to argue otherwise. The OAG’s allegations about ETH directly contradict the statements of many regulators: - The former director of the SEC’s Division of Corporation Finance asserted in a [speech](https://www.sec.gov/news/speech/speech-hinman-061418) that ETH was not a security. - Former SEC Chairman Jay Clayton approvingly cited that speech [multiple](https://www.coincenter.org/app/uploads/2020/05/clayton-token-response.pdf) [times](https://financialservices.house.gov/uploadedfiles/hhrg-115-ba00-wstate-jclayton-20180621.pdf). - Even current SEC Chair Gary Gensler, who recently opined that the “vast majority” of tokens are securities, previously [stated](https://www.nytimes.com/2018/04/22/technology/gensler-mit-blockchain.html?mtrref=t.co) that ETH could be “off the hook.” - The CFTC has [stated](https://cointelegraph.com/news/cftc-declares-ether-as-a-commodity-again-in-court-filing) several times that ETH is a commodity. - New York’s Department of Financial Services (“DFS”) [placed](https://www.dfs.ny.gov/virtual_currency_businesses#top) ETH on its “Greenlist” of tokens that can be transacted by entities that possess a “Bitlicense,” but are not necessarily securities intermediaries, thus demonstrating that DFS believes that ETH is not a security. Finally, the legal analysis underpinning the OAG’s allegations about ETH is deeply flawed. The OAG conflates ETH tokens themselves, which are merely software, with the alleged investment contracts pursuant to which those tokens were sold. Rather than analyzing each individual transaction on its own, as is required under the law, the OAG paints ETH with a broad brush, asserting that all ETH tokens are securities. The OAG pays no heed to the transaction in which each token was acquired, or what they are used for. ## https://www.paradigm.xyz/writing/paradigm-files-amicus-brief-supporting-coinbase-s-writ-of-mandamus # Paradigm Files Amicus Brief Supporting Coinbase’s Writ of Mandamus > Today Paradigm filed an amicus brief in support of Coinbase’s lawsuit that seeks to compel the SEC to respond to the company’s pending rulemaking petition. **TLDR**: Today Paradigm filed an [amicus brief](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-e0b48a2656/ce0e3297fcbfb33b311ec693275f5dbf/asset-https-cdn-sanity-io-files-dgybcd83-p-e0b48a2656.pdf) in support of Coinbase’s [lawsuit](https://www.coinbase.com/blog/coinbase-takes-another-formal-step-to-seek-regulatory-clarity-from-sec-for) that seeks to compel the SEC to respond to the company’s pending [rulemaking petition](https://www.sec.gov/rules/petitions/2022/petn4-789.pdf). As we’ve stated [before](https://paradigm.xyz/writing/2023/03/secs-path-to-registration-part-i), unless the SEC first issues practical guidance, Chair Gensler’s refrain that crypto projects, including digital asset exchanges, should just “come in and register” is an insincere admonition that is impossible to comply with. The SEC has a legal obligation to put the crypto industry on notice, allow individuals to conform their conduct to the law, and subject its views to the crucible of judicial review. By refusing to do so, the agency effectively paralyzes a major and growing industry. Last summer, Coinbase submitted a [petition](https://www.sec.gov/rules/petitions/2022/petn4-789.pdf) to the SEC asking the agency to “propose and adopt rules to govern the regulation of securities that are offered and traded via digitally native methods, including potential rules to identify which digital assets are securities.” The petition is part of Coinbase’s extensive efforts to engage with regulators and lays out with technical detail various issues that must be clarified in order to provide a practical regulatory framework for crypto. However, instead of engaging in good faith with Coinbase and the crypto industry, the SEC is flouting the bedrock principles of administrative law by refusing to formally tell both the digital-assets industry and the federal judiciary what it thinks the law requires of digital-asset trading platforms. Instead, the SEC has chosen to regulate through press releases, “office hour” videos posted on Twitter, cherry-picked enforcement actions, and thinly veiled threats. For example, SEC Chair Gary Gensler has testified to Congress that “\[t\]he crypto exchanges should come in and register” and “work with the SEC”—without explaining how or why. But until the SEC engages in the rulemaking Coinbase has requested, the digital-assets industry is stuck in limbo, simultaneously told to “come in and register” yet having no effective means of doing so. That is not how administrative law is supposed to work. As Coinbase’s petition demonstrates, century-old securities laws do not provide an obvious fit for digital assets and their exchanges. If the SEC wants companies to “come in and register,” then it must explain, subject to judicial review, how it thinks laws passed in the 1930s apply to digital assets today. ## https://www.paradigm.xyz/writing/paradigm-files-comment-letter-in-response-to-proposed-amendments-to-the-custody-rule # Paradigm Files Comment Letter in Response to Proposed Amendments to the Custody Rule > Paradigm submitted a comment letter to the SEC regarding the Commission’s proposed amendments and redesignation of rule 206(4)-2 (better known as the Custody Rule). TLDR: Today Paradigm submitted a comment letter to the SEC regarding the Commission’s [proposed amendments and redesignation of rule 206(4)-2](https://www.sec.gov/rules/proposed/2023/ia-6240.pdf) (better known as the Custody Rule). The SEC has characterized these potential changes as an attempt to enhance the protections of customer assets managed by registered investment advisers. However, this argument is flawed. In reality, the Proposed Rule would expand the application of the custody requirements far beyond what Congress intended and effectively prohibit (or significantly curtail) investment advisers from investing in many crypto assets on behalf of their clients. In other words, the Proposed Rule would attempt to make investors “safer” by blocking their access to the asset class, an action that is in contravention to the Advisers Act of 1940 itself. In addition, the Proposed Rule would hurt competition in a nascent industry. By limiting the number of crypto custodians, the rule would result in concentration of service providers, contrary to the explicit pro-competition goals of the Biden Administration. With the Proposed Rule, the SEC is fighting the Administration’s own efforts to increase competition and doing so in one of the most nascent and dynamic sectors of the economy. To more appropriately meet the articulated goals, Paradigm has provided recommendations and alternative considerations including tailoring the Proposed Rule to more appropriately suit the unique characteristics of crypto assets. Specifically, - Consider expanding the exception currently in place for privately offered securities and physical assets subject to heightened controls, - Permit flexibility for other custodial solutions including using MPC technology subject to additional controls, - Permit transaction execution via nonqualified affiliates of qualified custodians subject to certain conditions, - Engage with the crypto community, nonprofits, financial regulators to more robustly consider implications, and - Offer more guidance on areas including how to safeguard assets when they cannot be reduced to traditional custody, how to handle bans on commingling assets when necessary, etc. A full copy of Paradigm’s comments is available [here](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-a983528fd8/20b649169b1e66f8494042cfab55ff47/asset-https-cdn-sanity-io-files-dgybcd83-p-a983528fd8.pdf). ## https://www.paradigm.xyz/writing/artemis # Artemis: An Open-Source MEV Bot Framework > We're excited to open source Artemis, a framework for writing MEV bots in Rust. Artemis is designed to be simple, modular, and fast. We're excited to announce we are open-sourcing [Artemis](https://github.com/paradigmxyz/artemis), a framework for writing MEV bots in Rust. Artemis is designed to be simple, modular, and fast. # Why Build Artemis? MEV remains one of the strongest centralizing forces on Ethereum today. We believe that building open source tooling for MEV research and extraction is a clear avenue to combat this centralizing pressure. Currently, there are many obstacles for new entrants in the MEV market: - As a new searcher, it is difficult to get started: there is little incentive for bot operators to share their code, so new searchers often have to rewrite the same components, and rebuild similar infrastructure, resulting in wasted effort. - As a new protocol, it is difficult to find searchers to run keepers: until your protocol reaches scale, it’s difficult to get attention from searchers. We hope Artemis will alleviate some of these issues by providing flexible and reusable components for writing MEV bots, and by serving as a repository for contributing strategies and keepers. # What Is Artemis? Artemis is a library for writing bots, and a repository of strategies. We’ve designed the project with some of the following goals in mind: - **Simplicity:** Artemis is architected as a simple event engine, meaning it’s flexible enough to support a wide range of strategies while avoiding unnecessary complexity. - **Modularity:** Artemis provides commonly-used bot components out-of-the-box. These components can be mixed and matched to write strategies, allowing searchers to focus on implementing the core logic for each opportunity. - **Performance:** We want Artemis to be performant, so the framework is written in Rust, leveraging an extensive ecosystem of best-in-class Ethereum tooling. - **Batteries Included:** Artemis includes tooling to make it easy to run in production, like dockerized deployments, as well as monitoring and alerting using Prometheus and Grafana. # Artemis Architecture At it’s core, the library is architected as an event processing pipeline, with three main components: 1. **Collectors**: Collectors take in external events (such as pending transactions, new blocks, off-chain orders, etc.) and turn them into an internal event representation. 2. **Strategies**: Strategies contain the core logic required for each MEV opportunity. They take in events as inputs, and compute whether any opportunities are available (for example, a strategy might listen to a stream of marketplace orders to see if there are any cross-exchange arbs). Strategies produce actions. 3. **Executors**: Executors process actions, and are responsible for executing them across domains (for example, submitting transactions to the public mempool, submitting flashbots bundles, or placing off-chain orders). Additionally, we’re open sourcing a cross-market NFT arbitrage [strategy](https://github.com/paradigmxyz/artemis/tree/main/crates/strategies/opensea-sudo-arb), with more strategies coming soon. # Next Steps You can try out Artemis today by visiting the [project repo](https://github.com/paradigmxyz/artemis). If you are a developer interested in building open-source MEV tooling, a protocol interested in open-sourcing a keeper, or a searcher interested in integrating Artemis, please reach out. If you’d like to contribute code and don’t know where to start, please take a look at our [issue tracker](https://github.com/paradigmxyz/artemis/issues). See you in the mempool! ## https://www.paradigm.xyz/writing/blend # Blend: Perpetual Lending With NFT Collateral > Blend is a peer-to-peer perpetual lending protocol that enables lending against arbitrary collateral with no oracle dependencies. # Overview This paper introduces Blend: a peer-to-peer perpetual lending protocol that supports arbitrary collateral, including NFTs. Blend has no oracle dependencies and no expiries, allowing borrowing positions to remain open indefinitely until liquidated, with market-determined interest rates. Blend matches users who want to borrow against their non-fungible collateral with whatever lender is willing to offer the most competitive rate, using a sophisticated off-chain offer protocol. By default, Blend loans have fixed rates and never expire. Borrowers can repay at any time, while lenders can exit their positions by triggering a Dutch auction to find a new lender at a new rate. If that auction fails, the borrower is liquidated and the lender takes possession of the collateral. Blend has been implemented by [Blur](https://twitter.com/blur_io) Core Contributors. In their implementation, some protocol parameters, such as protocol fees, are controlled by BLUR governance, as described [below](https://www.paradigm.xyz/2023/05/blend#governance-considerations). # Motivation There has been a significant amount of prior work done on NFT-backed lending. Popular models include perp-like protocols (such as [Floor Perps](https://www.paradigm.xyz/2021/08/floor-perps) and papr), pooled lending protocols (such as BendDAO and Astaria), and peer-to-peer protocols (such as NFTfi and Backed). Blend most resembles the peer-to-peer model, but has some important differences to improve borrower experience. Rather than exhaustively examining the details of all NFT-backed lending protocols, we will describe some common design decisions and how Blend differs. ## No Oracles Some of these protocols require an oracle, either to determine when a position should be liquidated or to determine an interest rate. But individual NFT prices are very difficult to measure objectively. Even floor prices tend to be difficult to measure on-chain. Solutions often either involve a trusted party, or could be manipulated with trading strategies. Blend avoids any oracle dependencies in the core protocol. Interest rates and loan-to-value ratios are determined by whatever terms lenders are willing to offer. Liquidations are triggered by the failure of a Dutch auction. ## No Expiries Some protocols only support expiring debt positions. This is inconvenient for borrowers, who need to remember to close or roll their positions before expiry (or risk harsh penalties such as confiscation of their NFT). The process of manually rolling positions also costs gas, which cuts into the yield from lending. Blend automatically rolls a borrowing position for as long as some lender is willing to lend that amount against the collateral. On-chain transactions are only needed when interest rates change or one of the parties wants to exit the position. ## Liquidatable Some protocols do not support liquidations before expiry. This is convenient for borrowers, and makes sense for many use cases. But because this effectively gives borrowers a put option, lenders need to demand short expirations, high interest rates and/or low loan-to-value ratios to compensate for the risk that a position may become insolvent. In Blend, an NFT may be liquidated whenever a lender triggers a refinancing auction and nobody is willing to take over the debt at any interest rate. ## Peer-To-Peer Some protocols pool lenders' funds together and attempt to manage risk for them. This often means leaning heavily on on-chain governance or centralized administrators to set parameters. It also makes it difficult to permissionlessly support long-tail collateral. Blend uses a peer-to-peer model where each loan is matched individually. Instead of optimizing for ease-of-use on the lending side, Blend assumes the existence of more sophisticated lenders capable of participating in complex on- and off-chain protocols, evaluating risks, and using their own capital. # Mechanism In this section, we construct the protocol step by step, starting with a simple peer-to-peer fixed-rate lending protocol and gradually adding adaptations to allow gas-efficient rolling and market discovery of floating rates. ## Fixed-Term Borrowing First, let us imagine how our protocol might work if it had expiring rather than perpetual loans. We start with the lender. A lender signs an off-chain offer to lend some principal amount of ETH with a particular interest rate and expiration time, against any NFT of a specified collection. They make it publicly available (say, by posting it to an off-chain repository of offers). A borrower has an NFT they want to borrow against. They browse the available off-chain offers and choose a compatible one that matches the terms they're interested in. They then create an on-chain transaction that fulfills the lender's offer, put their NFT in a vault with a lien on it, and transfer the principal from the lender to themselves. Before the expiration time, the borrower can pay the repayment amount (calculated as the loan amount plus interest) to the lender, which closes their position and lets them withdraw their collateral. After the expiration time, if the loan has not been repaid, the lender can take the collateral. Note that the borrower may choose not to repay the loan if the value of the NFT has fallen below the repayment amount. ## Refinancing Auction In the above mechanism, if the borrower forgets to repay the loan before expiration, they lose their NFT, even if the NFT is worth much more than the repayment amount. This seems harsh. In many cases, someone else might have been willing to pay the lender the full repayment amount in order to take over the loan until a later expiration time, though possibly with a higher rate of interest. So, instead of simply giving the collateral to the lender, the protocol can run a competitive process to extend the loan, using a *Dutch auction in interest rate space*. At the expiration time, if the borrower has not repaid the debt, a refinancing auction begins at 0%, with a steadily rising rate. Once the auction hits an interest rate at which a new lender is interested in lending, the new lender can accept it by submitting their offer on-chain. The new lender pays the full repayment amount to the old lender, calculated as of the moment the auction completes, and takes over the loan until the new expiration time (which could be calculated as the current expiration time plus some protocol-specified loan period), using the interest rate at which the auction resolved. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--2140473463/700e7b0e624650aa40325770facc9a2b/asset-https-cdn-sanity-io-images-dgybcd83--2140473463.png) ## Liquidation It is possible that this Dutch auction may not be able to find a willing lender, especially if the value of the collateral has dropped close to or below the value of the debt. Once the auction hits some defined max rate (like 1000%) without any new lender stepping in, the protocol infers that the position is insolvent or otherwise non-viable, and liquidates the borrower. The existing lender can then send a transaction to take possession of the collateral. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--98a938bf0a/c5cc93eb7b74134c8a44600904d25902/asset-https-cdn-sanity-io-images-dgybcd83--98a938bf0a.png) ## Optimistic Auctions In some cases, the same lender might be happy to continue the same loan at the same terms, and the borrower may too. We might even consider that the default scenario. In that case, it would be wasteful to run the auction. Instead, we could design our protocol to optimistically renew the loan. At each expiration time, borrowers and lenders, by default, extend the expiration time by some predetermined loan period, with the same terms. The above-described auction would only occur if the lender seeks to terminate the loan. ## Continuous Loans One issue with the above protocol is that during a loan period, if the price of the collateral falls dangerously close to the price of the repayment amount, there is no way to liquidate it until the expiration time. This is less of an issue if the loan period is very short, since if the lender is concerned about the safety of the collateral, they can trigger a refinancing auction at the next expiry. We could imagine shortening the loan period until it is infinitesimal. If, at any moment, the lender becomes concerned about the safety of the collateral, they could trigger a refinancing auction. This lets us drop the concept of expiration times and loan periods. By default, loans continue indefinitely until some user interacts with the contract. Interest is accumulated continuously, and the repayment amount is calculated on the fly whenever needed. A borrower can repay at any time. If a borrower wants to change the amount they have borrowed or get a better interest rate, they can atomically take out a new loan against the collateral and use the new principal to repay the old loan. If a lender wants to get out of a loan, they can trigger a refinancing auction, as discussed [above](https://www.paradigm.xyz/2023/05/blend#refinancing-auction). All timelines and deadlines during refinancing events can be defined relative to the time the refinancing was initiated. Alternatively, if there is a compatible offer available from another lender, the current lender can skip the auction by submitting the other lender's offer to the vault to get out of their loan. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--37d0f881d6/8d6b05acfb25d4e12bcc84942793dbc4/asset-https-cdn-sanity-io-images-dgybcd83--37d0f881d6.png) # Governance Considerations The protocol does not depend on governance for valuing collateral or setting acceptable loan-to-value ratios, thus reducing the need for extensive on-chain governance or centralized administrators. However, there may still be situations where adjustments to certain parameters could enhance the protocol's functionality. These parameters include: - Fees: Borrower and lender fees collected by the protocol. - Maximum interest rate: The highest interest rate a loan auction must reach before liquidation occurs. - Auction formula: The equation governing the offered interest rate for a loan during an auction, as the auction progresses. In Blur's implementation of Blend, after a 180-day waiting period, these parameters can be managed by BLUR governance to ensure optimal performance and adapt to changing market conditions in a decentralized way. # Conclusion Blend is a flexible and permissionless floating-rate lending protocol that can support arbitrary collateral with no oracle dependencies, and allows whatever interest rates and loan-to-value ratios the market will bear. We're excited to see how people use it! *Acknowledgments: *[*Dave White*](https://twitter.com/_Dave__White_) *Graphics By: *[*Achal Srinivasan*](https://www.paradigm.xyz/team/achalsrinivasan)*, Kirby* ## https://www.paradigm.xyz/writing/mev-boost-ethereum-consensus # Time, slots, and the ordering of events in Ethereum Proof-of-Stake > Introduction On April 2nd, a malicious Ethereum network participant stole $20M from a MEV searcher by exploiting a vulnerability in the mev-boost-relay (see Flashbots’ post-mortem). In the following days, developers addressed # Introduction On April 2nd, a malicious Ethereum network participant stole $20M from a [MEV](https://www.paradigm.xyz/2021/02/mev-and-me) searcher by exploiting a vulnerability in the [`mev-boost-relay`](https://github.com/flashbots/mev-boost-relay) (see Flashbots’ [post-mortem](https://collective.flashbots.net/t/post-mortem-april-3rd-2023-mev-boost-relay-incident-and-related-timing-issue/1540)). In the following days, developers addressed the bug by releasing five patches to the broader `mev-boost` ecosystem. These patches, alongside existing network latencies and validator strategies, resulted in a brief period of instability in the Ethereum network due to an increased rate of [reorged](https://www.paradigm.xyz/2021/07/ethereum-reorgs-after-the-merge) blocks on April 6th. Reorgs are bad for network health because they decrease the rate of block production and reduce [settlement assurances](https://medium.com/@nic__carter/its-the-settlement-assurances-stupid-5dcd1c3f4e41). In this post, motivated by the attack against the searcher and the temporary instability of the network, we explore the interplay between `mev-boost` & consensus, unpack subtleties of Ethereum’s Proof-of-Stake mechanism, and enumerate some of the possible paths forward. # What is mev-boost & why is it important? `mev-boost` is a protocol designed by Flashbots and the community to mitigate the negative effects of Maximal Extractable Value (MEV) on the Ethereum network. There are 3 actors in `mev-boost`: 1. *Relays* – mutually-trusted auctioneers that connect proposers to block builders. 2. *Builders* – sophisticated entities who construct blocks in order to maximize MEV for themselves and the proposers. 3. *Proposers* – Ethereum Proof-of-Stake validators. The rough sequence of events per-block is: 1. A builder creates a block by receiving transactions from users, searchers, or other (private or public) orderflow. 2. The builder submits the block to a relay. 3. The relay validates that the block is valid and calculates how much it pays the proposer. 4. The relay sends a “blinded” header and a payment value to the proposer of the current slot. 5. The proposer evaluates all the bids they’ve received and signs the blinded header associated with the highest payment. 6. The proposer sends this signed header back to the relay. 7. The block gets published by the relay using their local beacon nodes and returned to the proposer. The rewards are distributed to the builder & proposer through transactions in the block and the block reward. The relay is a mutually-trusted party that facilitates the fair exchange of block space (from the proposer) and transaction sequencing for MEV extraction (from the builder). The relay protects builders from MEV stealing, in which proposers copy builder transactions to take MEV for themselves instead of allocating it to the searcher/builder who discovered it. The relay protects proposers by (a) confirming the validity of the builder blocks, (b) processing hundreds of blocks per-slot on behalf of the proposer, and (c) ensuring the accuracy of the proposer payment. `mev-boost` is critical protocol infrastructure because it enables democratic access to MEV for all proposers without requiring trusted relationships with builders or searchers, which contributes to Ethereum’s long-term decentralization. # Ethereum’s Fork-Choice Rule & mev-boost Before we dive into the attack and responses, we examine Ethereum's Proof-of-Stake (PoS) mechanism and the associated fork-choice rule. A fork-choice rule allows the network to reach consensus about the head of the chain. From [Ethereum Reorgs After The Merge](https://www.paradigm.xyz/2021/07/ethereum-reorgs-after-the-merge): *A fork choice rule is a function, evaluated by the client, that takes as input the set of blocks and other messages that have been seen, and outputs to the client what the "canonical chain" is. Fork choice rules are required because there may be multiple valid chains to choose from (eg. if two competing blocks with the same parent get published at the same time).* A lesser-known aspect of the fork-choice rule is its relationship to time, which has major implications for block production. ### Slots & sub-slot periods In Ethereum PoS, time is partitioned in 12 second increments called `slots`. The PoS algorithm randomly assigns a validator the permission to `propose` a block for that slot; this validator is referred to as the proposer. In the same slot, other validators are assigned the task of `attesting` (voting) for the block that is the head of the chain according to their local view by applying the fork-choice rule. The 12 second slot is subdivided into three phases, each consuming 4 seconds. The events that take place in a slot are listed below using `t=0` to denote the beginning of the slot. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--b2d49eea70/20f4a27a19d7bb2fb39bfbb25ccafc41/asset-https-cdn-sanity-io-images-dgybcd83--b2d49eea70.png) The most critical moment in a slot is the `attestation deadline` at `t=4`. If an attesting validator has not seen a block by the attestation deadline, they will instead vote for the previously accepted head of the chain (according to the fork-choice rule). The earlier a block is proposed, the more time it has to propagate, and thus the more attestations it accumulates (because more validators see it by the attestation deadline). From the network-health perspective, the best time for a block to be published is `t=0` (as dictated by the spec). However, since the value of the block increases monotonically with time, proposers have the incentive to delay the publication of their blocks to allow more MEV to accumulate. See [Timing games in Proof-of-Stake](https://ethresear.ch/t/timing-games-in-proof-of-stake/13980) and [this discussion](https://github.com/flashbots/mev-boost/issues/111) for further details. Historically, a proposer could publish a block well after the attestation deadline (even close to the end of the slot), as long as the next validator observed the block before they built their block for the subsequent slot. This is a result of the child block inheriting the weight of the parent block and the fork-choice rule terminating at a leaf node. Thus there was no downside to delaying block publication. In order to help push rational behavior (delaying the block publication) towards honest behavior (on-time publishing), “honest reorgs” were implemented. ### Proposer boost & honest reorgs Two new concepts were introduced into the consensus clients that have critical implications for the attestation deadline. 1. `proposer boost` ([PR](https://github.com/ethereum/consensus-specs/pull/2730)) – attempts to minimize reorg [balancing-attacks](https://arxiv.org/abs/2009.04987) by granting the proposer a fork-choice “boost” equivalent to [40%](https://github.com/ethereum/consensus-specs/blob/faec3d1663e59d24a60ef5749b65d191cb1468d8/configs/mainnet.yaml#L88) of the full attestation weight. *Importantly, this boost only lasts for the duration of the slot.* 2. `honest reorgs` ([PR](https://github.com/ethereum/consensus-specs/pull/3034)) – takes proposer boost and allows honest proposers to use it to forcibly reorg blocks that have attestation weight below 20%. This is implemented in [Lighthouse](https://github.com/sigp/lighthouse/pull/2860) and [Prysm](https://github.com/prysmaticlabs/prysm/pull/12075) (as of v4.0 – the Capella release). This change is optional because it is a local decision made by the proposer, and does not impact the attesting validators’ behavior. As a result, there was no coordinated effort to roll it out in all clients simultaneously, nor was it associated to any specific hard-fork. Note that honest reorgs are avoided in some special cases: 1. during epoch boundary blocks 2. if the chain is not finalizing 3. if the head of the chain is not from the slot prior to the reorged block Condition 3 ensures that honest reorgs only ever remove a single block from the chain, which acts as a circuit breaker to allow the chain to continue producing blocks during periods of extreme network latency. This also reflects the proposer's reduced confidence in their view of the network, because they can no longer be certain that their proposer-boosted block will be seen as canonical. The diagram below demonstrates how honest behavior changes to implement the reorg strategy. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--10b3a9e75c/96d69a62254be939a0df1033cecc53da/asset-https-cdn-sanity-io-images-dgybcd83--10b3a9e75c.png) In this scenario, let `b1` represent a late block. Due to the lateness, `b1` only has 19% of the attesting weight for slot `n`. The remaining 81% of the attesting weight is allocated to the parent block `HEAD`, because many attesters did not see `b1` by the attestation deadline. Without honest reorgs, the proposer for slot `n+1` sees `b1` as the head of the chain and builds a child block `b2`. The proposer makes no effort to reorg `b1`, despite it only having 19% attesting weight. During slot `n+1`, `b2` has proposer boost, and assuming it was delivered on-time, `b2` will become canonical by accumulating a majority of the attestations for that slot. With honest reorgs, the situation is much different. Now the proposer of slot `n+1` sees that the 19% attestation weight on `b1` is below the reorg threshold, so they build a block with `HEAD` as the parent of `b2`, and forcibly reorg `b1`. When we reach the attestation deadline of slot `n+1`, honest attesters will compare the relative weights of `b1` (19%) vs `b2` (40% from proposer boost). All the clients implement proposer boost, thus `b2` will be seen as the head of the chain and will accumulate the slot `n+1` attestations. ### Relay & beacon node fixes in response to the unbundling attack During the April 2nd unbundling attack, the proposer exploited a relay bug by sending an invalid signed header back to the relay. During the following days, the relay and the core-dev teams released a number of software patches to mitigate the risk of a repeat attack. The five major changes were the following: 1. Relay changes: 2. Check the DB for known malicious proposers (only ever used in prod by the [ultra sound relay](https://www.paradigm.xyz/2023/04/relay.ultrasound.money), and has since been removed). 3. Check if the relay has already delivered a full block to the p2p network during that slot. 4. Introduce a uniform random delay in the range 0-500ms before the publication of the block (removed from all relays). 5. Beacon node changes (only for relay beacon nodes): 6. Validate the beacon block *before* broadcasting it. 7. Check the network for equivocations before publishing a block. The combination of these changes led to consensus instability that was exacerbated by the fact that a large percentage of validators are now using the honest reorg strategy described above. ### Unforeseen consequences Each of the 5 changes mentioned above introduced latency into the hot path of relay block publication, which increased the probability that relay blocks would be broadcast after the attestation deadline. The figure below shows the five checks in sequence and how the introduced latency could cause the block publication to exceed the attestation deadline. Before these checks were implemented, a signed header arriving substantially later than `t=0`, e.g. `t=3`, would typically present no issues. The relay had a very low overhead, and thus would publish the block well before the attestation deadline at `t=4`. However, with the introduction of the latency from the five patches, the relay could now be partially responsible for a late broadcast. Let’s look at a hypothetical block publication below. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--8a926237bb/c8b860942f05b44bd25e6edb4ad81528/asset-https-cdn-sanity-io-images-dgybcd83--8a926237bb.png) The relay receives the signed header from the proposer at `t=3`. By `t=4`, the relay is still executing checks and thus the broadcast happens after the attestation deadline. In this case, the combination of the proposer sending the signed header late and the relay introducing some additional latency resulted in the missed attestation deadline. *Without honest reorgs, these blocks would have very likely made it on chain*. The honest proposers for the subsequent slot would not intentionally reorg the block for being late as we saw in Figure 2. With honest reorgs however, missing the attestation deadline means this block will be reorged by the next proposer. As a result, in the days following the attack, the number of forked blocks increased dramatically. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--971f9a8d58/88f0fa4f443a92077f72c9fae37a3d65/asset-https-cdn-sanity-io-images-dgybcd83--971f9a8d58.png) The [Metrika](https://app.metrika.co/ethereum/dashboard/consensus-performance?tr=2w) 2 week data shows that in the worst case, 13 blocks (4.3%) were reorged in an hour, which was ~5x more than normal. As the relays rolled out various changes, the sharp increase in the number of forked blocks became clear. Thanks to a great community effort from relay operators and the core-devs, once the impact was understood, many of the changes were rolled back and the network returned to a healthy state. As of today, the most useful changes were the beacon node block validation and equivocation checks that take place before broadcasting. Malicious proposers can no longer execute the attack by sending an invalid header to the relay and also must ensure that the relay beacon nodes do not see the equivocating block before publishing. Despite this, the relay remains exposed to the more general equivocation attack as presented in [Equivocation attacks in mev-boost and ePBS](https://ethresear.ch/t/equivocation-attacks-in-mev-boost-and-epbs/15338). # So what should we do? In this post we highlighted how `mev-boost` works and how critical it is for Ethereum consensus. We also double-clicked on some of the lesser-known aspects of Ethereum’s fork-choice rule surrounding timing. Using the unbundling attack and the developers’ response as a case study, we underscore the potential fragility of the timing-related aspects of the fork-choice rule, and its impact on the network’s stability. Given that, the research community should evaluate what is an “acceptable” amount of reorgs and consider the exposure to equivocation attacks more generally to determine if mitigations should be implemented. Additionally, there are multiple future directions being actively explored: 1. Implementing “[headlock](https://ethresear.ch/t/equivocation-attacks-in-mev-boost-and-epbs/15338)” to protect `mev-boost` against equivocation. This would also require changes in the consensus client software and likely a spec change to extend the attestation deadline. 2. Increasing the number and visibility of bug bounty programs for the `mev-boost` software. 3. Expanding simulation software to explore how sub-slot timings can impact network stability. This could be used to evaluate how adjusting the attestation deadline could reduce reorgs. 4. Optimizing the block publication path on the relay to reduce unnecessary latency. This is already being explored. 5. Recognizing that `mev-boost` is core-protocol functionality and absorbing it into the consensus clients, aka enshrined-PBS (ePBS). Two-slot ePBS is vulnerable to equivocation attacks, so implementing “headlock” remains an option. 6. Adding more hive and/or spec tests informed by issues around latency and the attestation deadline. 7. Encouraging relay client diversity by building additional implementations of the relay spec. 8. Considering an adjustment to the slashing penalties for equivocation, while keeping in mind that even a full 32 ETH slashing may not be enough to dissuade malicious behavior in the presence of extremely large MEV opportunities. 9. Revisiting the sub-slot timings and considering and adjustment of the block propagation phase (e.g. moving the attestation deadline from `t=4` to `t=6`). Overall, we are excited by the renewed energy around MEV and the `mev-boost` ecosystem. Through the unbundling attack and mitigations, we have come to understand the critical relationship between latency, `mev-boost`, and the consensus mechanism; we hope that the protocol continues to harden in response. If these topics are exciting and interesting to you, please reach out to [Georgios](https://twitter.com/gakonst) ([email](mailto:georgios@paradigm.xyz)) or [Mike](https://twitter.com/mikeneuder) ([email](mailto:michael.neuder@ethereum.org)). *Many thanks to *[*Bert Miller*](https://twitter.com/bertcmiller)*, *[*Danny Ryan*](https://twitter.com/dannyryan)*, *[*Alex Stokes*](https://twitter.com/ralexstokes)*, *[*Francesco D’Amato*](https://twitter.com/fradamt)*, *[*Michael Sproul*](https://twitter.com/sproulM_)*, *[*Terence Tsao*](https://twitter.com/terencechain)*, *[*Frankie*](https://twitter.com/FrankieIsLost)*, *[*Joachim Neu*](https://twitter.com/jneu_net)*, *[*Chris Hager*](https://twitter.com/metachris)*, *[*Matt Garnett*](https://twitter.com/lightclients)*, *[*Charlie Noyes*](https://twitter.com/_charlienoyes)*, and *[*samczsun*](https://twitter.com/samczsun)* for their feedback on this article and *[*Achal Srinivasan*](https://twitter.com/achalvs)* for designing the figures.* ## https://www.paradigm.xyz/writing/moneyness-in-the-digital-age # Moneyness In the Digital Age > The recent events surrounding Silicon Valley Bank (SVB) provide a lens for reexamining age-old questions about the relationship between money and credit — and crypto’s important role in the future. ## 1. Introduction Crisis decision-making in the wake of the Silicon Valley Bank (SVB) run has called into question the status of banking as a public-private partnership, as the government is now implicitly providing an infinite public backstop for private credit monies. This is an awkward way to address age-old issues related to the relationship between money and credit. The events surrounding SVB involved a very specific and narrow set of circumstances unrelated to crypto, but they set a backdrop for a nuanced public discussion regarding moneyness in the digital age — and crypto’s vital role in the future. ## 2. Money is deeply hierarchical At the top of the [hierarchy](https://sites.bu.edu/perry/files/2019/01/Lec-02-The-Natural-Hierarchy-of-Money.pdf) is money — a means of *final* settlement. At the bottom of the hierarchy is credit — a *promise* to pay, or to “settle” using a higher-order form of money at a later point in time. “Moneyness” is the degree to which a given instrument is near the top of the hierarchy, which itself has many layers. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--c33679a531/e87fa5d58a33a7f9c6905c3743d6ff30/asset-https-cdn-sanity-io-images-dgybcd83--c33679a531.png) Today, liabilities issued by central banks are often treated as the ultimate form of money. These come in two main subsets: cash (a physical liability accessible to everyone) and central bank reserves (a digital liability accessible mainly to banks and nation states). Both are a claim on the asset side of the central bank’s balance sheet. In the case of the U.S. Federal Reserve, the assets are mostly U.S. government bonds. In practice, nobody tries to exercise these claims by “redeeming” their cash or reserves for Treasury securities because cash and reserves are widely accepted as a medium of exchange, unit of account, and store of value on their own. They have a high “moneyness” score today. [^1] Below cash and reserves in the hierarchy sits deposits issued by commercial banks. Commercial bank money is a promise to pay higher-order money — namely cash or reserves. From the perspective of most users, it *is* considered money and not credit thanks to deposit insurance, bank supervision, and the central bank as a lender of last resort. But, at the end of the day, commercial bank deposits are just liabilities issued by a commercial bank. They are a *claim* on the commercial bank’s assets, where depositors are effectively loaning money to the commercial bank — and exposed to credit risk as a result. If the bank’s assets are not worth more than its liabilities, the money it issues may not be worth what people think it is. There are additional forms of credit-based money below deposits in the hierarchy, such as securities, which are an even more attenuated promise to pay a higher-order form of money on the hierarchy. Certain types of securities form the basis of the [shadow-banking](https://www.newyorkfed.org/medialibrary/media/research/epr/2013/0713adri.pdf) sector. ## 3. Societal notions of moneyness are constantly evolving, as is the relationship between money and the state The monetary hierarchy has changed dramatically over time and space. Even at a single point in time there are many different hierarchies that represent an accurate relationship between money and credit, depending on a person’s perspective. In effect, a person’s relationship to other people and the economy as a whole can change how they rank the “stack” in the hierarchy. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--45644803c8/c3ae51ea564380f7de085d5fcacb10fb/asset-https-cdn-sanity-io-images-dgybcd83--45644803c8.png) ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--cf1cf71635/23aaa16a23d89b22a73d7c8d00d7f522/asset-https-cdn-sanity-io-images-dgybcd83--cf1cf71635.png) For a long time, gold was widely considered to be at the top of the moneyness chart due to its limited supply making it a useful store of value. Cash and central bank reserves used to be a legal promise to pay the holder a certain fixed amount of gold. During WWI and the immediate years following, the U.K. and other European countries went off the gold standard (weakened the promise to pay gold) while the U.S. kept it, resulting in massive flows of gold into the U.S. (and out of London) as a result. Although the U.S. temporarily abandoned the gold standard during the Great Depression, the prior moves had already set the stage for USD dominance through WW2 and the onset of the Bretton Woods System. Monetary regime decisions often have geopolitical implications. The gold standard was abandoned in the 1970s due to constraints it placed on the ability of governments to respond to economic conditions. When money supply is inelastic (due to limits on the availability of gold), policymakers have limited tools for adjusting the price of credit to respond to economic expansions or contractions. Gold also has limited industrial uses, which makes its value almost entirely derived from its scarcity and a belief that it has value. The current system where money is backed by the government’s ability to issue debt and collect tax revenue — a nontrivial assumption in the broader historical context — is inherently more credit-based by design. It lets the state define and control moneyness, which has both benefits and drawbacks. ## 4. Commercial bank money, today Throughout most of our lifetimes, banking has existed as a public-private partnership. Banks operate in the private sphere with privileged public guarantees. Such guarantees enhance the safety and efficiency of money, but they also create a false sense of security and “oneness” of money. As standard practice, most people do not consider the creditworthiness of their commercial banks. Same with many large, non-bank financial institutions — sometimes with catastrophic implications. For many, the run on SVB was a collective awakening to the notions that: 1) commercial bank deposits carry credit risk, and 2) that credit risk is nonzero. If the story had ended with SVB and Signature failing absent emergency actions by the U.S. government, we would be back at the status quo having learned a painful but in some ways unoriginal lesson. However, by stepping in and using emergency powers to guarantee all uninsured deposits, the U.S. government loosened over a century of norms and legal guardrails. During the Great Financial Crisis (GFC), the deposit insurance limit was temporarily raised from $100k to $250k (before the change was made permanent in law), but uninsured depositors did lose money in the aftermath when banks, such as IndyMac, failed. The new policy of the U.S. seems to be, in practice, drifting towards one where individuals and businesses are not exposed to commercial bank credit risk — that broad access to a higher level of “moneyness” may be socially optimal. If that is indeed the new direction of policy for money and banking, it should be implemented in a more transparent and deliberate manner. ## 5. Moneyness in the digital age Too often the social media discourse around moneyness and crypto can devolve into a binary purity test: crypto is good, and fiat is bad. We think this framing misses a lot of nuance. Credit-based money has brought a certain level of prosperity and has given governments more flexibility for manipulating financial conditions to control economic growth and pursue geopolitical objectives. We also acknowledge that this is a privileged perspective coming from a liberal democracy with unmatched global power, however, and there have been some unhappy [consequences](https://twitter.com/michaelxpettis/status/1640209357488140289?s=20) of this regime. [^2] At the same time, there are numerous examples of how the world is changing around us. - China’s geopolitical ascension and Russia’s invasion of Ukraine (and subsequent removal from the USD system) have had profound implications for international finance. The end of dollar dominance is far from guaranteed, but in all likelihood *some* stealth erosion of the USD’s share of international trade will lead to a more multipolar world — meaning that the USD and USD-denominated assets may not be as widely accepted as the ultimate form of money in the future. - The rise of AI will substantially change the nature of economic growth and productivity. It is not hard to imagine a world where autonomous agents engage in economic activity and need a digitally-native form of money they can access *without* having to analyze complex and often opaque chains of credit intermediation. In addition, development of AR/VR and the growth of digital worlds means more activity takes place in digital environments. - Fiscal and monetary policy in the years following the GFC and COVID-19 created numerous distortions in the hierarchy of money. The supply of money-like securities (e.g., U.S. government securities) grew dramatically, as did the scope of implicit and explicit guarantees backing such securities and leading to further growth in the shadow-banking sector. Today, much of trade and finance relies on extensive credit intermediation via shadow banking. - Ubiquitous connectivity and low barriers to sharing information via social media have exacerbated the speed and magnitude of financial volatility, as evidenced by the Gamestop and SVB sagas. Transparency of financial solvency is more vital now than ever. Determining what has value has never been more challenging, nor has it ever been more important. Being thoughtful about the future of digital moneyness is critical for human progress and for states that support freedom from authoritarianism. ## 7. Crypto is hard, digital money Much has been written about the volatility of crypto and how its volatility and “lack of intrinsic value” makes it a poor form of money. These takes are usually written with a specific conclusion in mind and often miss context of the current moment. They are also wrong. Crypto has intrinsic value. Bitcoin has been around for more than 10 years and is actively used as a global settlement layer for censorship-resistant transactions. Ether powers the Ethereum network, a globally-distributed computer on top of which thousands of products and services have been built. If oil and coal powered the industrial revolution, ether and other native cryptocurrencies may power the next 100 years of innovation. On top of these facts sits an even more important truth. Crypto is hard, digital money, by design. By this we mean that what crypto may lack in stability, it makes up for in being verifiably *free of credit risk* depending how it is held. Maybe it’s time to “[replace creditworthiness with collateralworthiness](https://www.crisesnotes.com/the-night-they-reread-pozsar-in-his-absence/),” since time and time again people and institutions seem unable to manage counterparty credit risk when it comes to pricing their “dollars”. Crypto collateral can be volatile, but it’s easier to mark-to-market your collateral when its price is based on liquid market prices (on- and off-chain) and not obscured by an invisible balance sheet. For many applications, this could be an improvement over the status quo. It’s equally important that people (and machines) continue to have access to digital money — free of credit risk and free of censorship — in the future. Crypto has already delivered this, and arguments about volatility and lack of a compelling use case are entirely missing the point. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--01adef1179/2cce1a805095518d9f5c81eba159eef8/asset-https-cdn-sanity-io-images-dgybcd83--01adef1179.png) ## 8. Stablecoins For many uses today, there is a need for a safe version of digital dollars. After the SVB/Signature incident there have been numerous proposals for permanently expanding individuals’ access to money with a higher moneyness factor, including unlimited deposit insurance and CBDC. These options, if considered, should be done so in a fair and public process. In the short term, a clear improvement over the current state would be developing a clear and reasonable framework for fiat-backed stablecoins, which are already used today to provide functional digital money on top of credible collateral. Well-designed stablecoins could give retail users and businesses a meaningful asset for managing payments (both domestic and cross-border) and storing value without exposing them to commercial bank credit risk. The MMF industry serves a similar set of purposes today, but nobody treats MMFs as money because they are not functionally built to serve as payments instruments. Effectively-designed stablecoins could serve a purpose similar to CBDC, but would retain the current relationship between individuals’ economic activity and visibility from the government in addition to carrying less operational and execution risk. Other jurisdictions, such as the U.K. and Europe, are already along this path, and it is time for the U.S. to step to the plate. Although many details still need to be sorted, it is encouraging to see Congress considering legislation that would solidify the role of stablecoins in the digital economy. ## 9. Conclusion For most Internet-native people, SVB was the first bank failure with significant resonance, and the first major event that spotlighted the role of private credit in underpinning our current system of money. As revealed by decisions made following the events that led to SVB’s deposit outflows, there is a renewed public focus on the potential need to reduce both the role of credit in money creation *and* the lack of transparency around credit-based monies. Crypto and stablecoins are limited in their reliance on credit, which makes them an attractive option for many applications in today’s interconnected digital world. [^1]: U.S. government debt is conceptually a claim on future government cash flows vis-a-vis collected tax revenue. The riskiness of government debt is predicated on the government’s ability to collect taxes in the future and the assumption that the purchasing power of the dollar in real terms will not erode over time. Testing these assumptions is beyond the scope of this paper [^2]: For example, the current model of USD dominance requires the U.S. to run persistent current account deficits, which requires large amounts of fiscal and household debt and has the downstream effect of eroding the U.S. manufacturing base and bargaining power of workers ## https://www.paradigm.xyz/writing/paradigm-files-amicus-brief-in-sec-vs-terra # Paradigm Files Amicus Brief in SEC vs Terra > Paradigm was not an investor in the Terra ecosystem and our brief was filed in support of neither party’s motion—our only interest was to push back against the SEC’s continued attempts to expand their jurisdiction over crypto. **TLDR**: On Friday, Paradigm filed an [amicus brief](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-e1071295c9/d4115aa5df80a3a1a0b46a3b9dc946ba/asset-https-cdn-sanity-io-files-dgybcd83-p-e1071295c9.pdf) in the SEC lawsuit against Terraform Labs and Do Kwon. Paradigm was not an investor in the Terra ecosystem and our brief was filed in support of neither party’s motion—our only interest was to push back against the SEC’s continued attempts to expand their jurisdiction over crypto. Through its enforcement action against Terra, the SEC attempts to bring stablecoins under its remit by advancing the boundless theory that if any instrument can be exchanged for a so-called “crypto asset security,” the instrument itself becomes a “crypto asset security.” This theory contradicts decades of guidance from federal courts and would result in any barterable good becoming a “security.” On February 16, 2023, more than eight months after the collapse of terraUSD (“UST”) and its companion token LUNA, the SEC sued Terraform Labs PTE LTD and Do Kwon (together, the “Terra Defendants”) with a range of charges, including fraud. Like cavalry charging a field of beaten survivors, the SEC’s enforcement action came too late to protect any investors in Terra or contain the effects of the Terra collapse on the broader crypto market. Instead, in what has become an emblematic tactic of the SEC under Chair Gensler, the agency filed a late [complaint](https://www.sec.gov/litigation/complaints/2023/comp-pr2023-32.pdf) against an incapacitated defendant to expand the agency’s jurisdiction over crypto. To support the allegations that the Terra Defendants conducted an unregistered offering of securities, the SEC claimed in the Complaint that five different crypto assets were “crypto asset securities”: UST, LUNA, “wrapped” LUNA, MIR Tokens, and mAssets. Our brief focused on responding to the SEC’s novel theory that UST, an algorithmic stablecoin, was a security. The SEC’s theory about UST is ancillary to the central claims in the Complaint. Nonetheless, we believed it was critical that Judge Rakoff, who is overseeing the case, avoid inadvertently endorsing this unsupported theory, which the SEC could seek to apply broadly to other stablecoins. According to the SEC, a type of crypto asset that is profitless by design a—*stablecoin*—becomes a “crypto asset security” because it can be exchanged for another crypto asset that is alleged to be a security. But the Supreme Court has already cautioned that an asset’s classification as a security should not be based on “speculative” uses, *i.e.*, what *could be done* with an asset. *United Hous. Found. Inc. v. Forman*, 421 U.S. 837 at 865 (rejecting as “too speculative and insubstantial” the notion that co-op shares could be securities because the co-op had commercial facilities that could be leased out at a net profit). Moreover, by the SEC’s reasoning, virtually every good or property in the world can be a security merely because that good or property can be used to buy a security. While the Securities Laws are broad and flexible, they do not allow the SEC to turn any barterable good into a security. ## https://www.paradigm.xyz/writing/secs-path-to-registration-part-iii # The Current SEC Disclosure Framework Is Unfit for Crypto > The grand bargain of the US securities laws is that any issuer selling securities to the general public must provide the public with a set of disclosures approved by the SEC. These laws are intended to address information asymmetry and ensure that the investing public has the material information necessary to make informed investment decisions. The securities laws are not intended to turn the SEC into a gatekeeper or “merit regulator” that itself decides which projects are investable and which are not. Congress meant for discretion to remain solidly in the hands of individual investors. ## 1. Introduction In Part III of our series on SEC registration, we explain why Chair Gensler’s attempt to brute force crypto assets that may not even constitute “securities” into an ill-fitting disclosure framework is bad policy: it fails to provide crypto asset users and investors with the information they need, while also denying crypto entrepreneurs a viable path to compliance. [^1] As we note in Section 2 below, the current SEC disclosure framework was established in the 1930s and designed to regulate the securities issued by centralized companies for fundraising. However, as discussed in Section 3, crypto asset markets differ from securities markets in fundamental ways. Unsurprisingly, without major changes to the SEC’s current disclosure regime, the SEC is unable to effectively regulate crypto asset markets. Section 4 discusses two key issues that need to be clarified to determine whether transactions involving the sale of crypto assets are required to be registered in the first place. Section 5 then highlights how the current disclosures required by [Form S-1](https://www.sec.gov/files/forms-1.pdf), one of the most widely used registration forms, do not provide the right mix of information to crypto asset users or investors. [^2] This is not to say that developers of crypto projects should be exempt from having to make any disclosures when they fundraise through the sales of crypto assets. Rather, our point is to highlight why regulators need to be more thoughtful about developing a viable framework that gives tokenholders the information they need and deserve. [^3]oday’s Commission tells entrepreneurs trying to do new things in our markets to come in and register. When entrepreneurs find they cannot, the Commission dismisses the possibility of making practical adjustments to our registration framework to help entrepreneurs register, and instead rewards their good faith with an enforcement action.” (Hester M. Peirce, Commissioner, SEC, “Rendering Innovation Kaput: Statement on Amending the Definition of Exchange” (Apr. 14, 2023) (statement), available here\] ## 2. Current SEC disclosure regime was developed for securities issued by centralized companies Securities such as stocks and bonds represent a legal claim against, or interest in, the assets and profits of a specific legal entity. Those legal entities are controlled by company management and a group of “insiders” who have access to non-public information that can affect the value of the company’s securities and can be exploited to the detriment of the public and the market. As discussed in Part II, federal securities laws address information asymmetries by requiring issuers of securities to register and publicly disclose material information to enable investors to make informed investment decisions. While the Securities Act of 1933 (the “1933 Act”) is the principal federal statute governing public offerings of securities, it is supplemented by various rules and regulations promulgated by the SEC that include additional requirements for public offerings of securities, including Regulation C, [^4] Regulation S-K [^5] and Regulation S-X. [^6] In addition, most issuers of registered securities are required to keep these disclosures current by filing quarterly and annual reports, as well as disclosing material events as they arise. Critically, the SEC disclosure framework is entirely dependent on the existence of a centralized legal entity that issues the securities - i.e., the framework presumes that there is an entity, the “issuer”, which creates a legal relationship with investors by distributing an instrument that represents that legal relationship (e.g., stocks or bonds). It is this legal entity, this issuer, that of necessity is the driver of the value to investors in securities. Accordingly, when a company registers an offering of securities on the SEC’s [Form S-1](https://www.sec.gov/files/forms-1.pdf), it is required to provide a number of disclosures about the company’s history, operations, financial statements, leadership, risks it may face, and other information about its business. While these disclosures are clearly relevant for investors trading securities issued by centralized legal entities, they fail to adequately inform crypto asset users and investors because, as shown in the next section, the disclosures do not reflect crypto assets’ unique qualities. ## 3. Markets for crypto assets differ fundamentally from securities markets Crypto asset markets differ in meaningful ways from securities markets. As a result crypto requires a different regulatory framework with disclosures tailored to the unique nature of crypto assets and market regulation that reflects the “stack” on which crypto assets trade. As explained below, an adequate disclosure framework for crypto assets that are sold in investment contract transactions must, at a minimum (a) distinguish between the legal rights against issuers that define securities and the technological abilities in protocols that define many crypto assets; (b) reflect that, unlike securities, crypto assets exist independent of the entity that initially sold these assets in fundraising transactions; (c) reflect that crypto assets can accrue value differently than securities; and finally (d) reflect that crypto assets operate, trade and settle on a very different technology “stack” than that used for the trading of securities. ### a. Most crypto assets do not provide legal rights against an identifiable “issuer,” but rather provide technological abilities enforced by a blockchain-based protocol As compared to stocks or bonds, crypto assets typically do not represent ownership of an interest in a legal entity, nor any type of legal claim against one. [^7] Even when crypto assets are originally “minted” by a development company, they generally do not make the token holders part owners of that company, nor do they provide any legal rights to dividends or other income generated by that company. Crypto assets also do not typically provide any governance rights applicable to a company, such as the right to elect the board of directors or to vote on other matters directly affecting the company. Instead, owners of crypto assets are endowed with certain technological abilities within a protocol that are enabled by smart contract code. While these technological abilities are sometimes referred to using terminology borrowed from corporate law (e.g., “governance rights”), they are completely different from traditional corporate legal rights. The code associated with crypto assets can provide token owners with abilities that are enforced ex-ante through technological permissioning. The specific technological abilities of crypto assets is publicly verifiable by sophisticated actors. Importantly, a crypto asset’s technological abilities can also be outside of the control of the individual or entity that originally deployed the code that created the crypto assets and related protocol. [^8] In stark contrast, securities rely on legal rights against a centralized entity, like a shareholder’s right to receive a dividend from a company or vote to elect its board. These legal rights need to be enforced through an ex-post adjudication by a judicial or similar proceeding. As discussed further in Section 5(a), an appropriate disclosure regime needs to recognize and address this critical difference between legal rights and technological abilities if it is to provide adequate information to tokenholders. Current securities regulations simply do not accomplish this. ### b. Crypto assets can exist independent of the existence of an “issuer” Crypto assets are also fundamentally different from securities because they can exist and function as intended independent of the ongoing existence of the legal entity that created them. In some instances, crypto assets may even be created programmatically through a process that does not involve any legal entity that could be classified as the “issuer” of the assets. Securities of necessity depend on their issuer—the legal entity that created them—for their continued existence. For example, if a company dissolves, its shares cease to exist in any meaningful way, becoming at best a useless paper memento of strictly historical interest. However, crypto assets lack this dependence on an “issuer” and can continue to exist notwithstanding the dissolution of the company that created or “minted” them. [^9] Crypto assets created using an immutable protocol deployed on a public blockchain will retain their full on-chain functionality despite the dissolution of the entity that created them. This is because, as we discussed above, crypto assets do not depend on legal claims against a corporate entity, but rather on technological abilities provided by smart contract code deployed on a distributed protocol. This results in an arrangement that can be much more resilient in the face of extraneous or endogenous factors that may affect the going concern value of the issuer of securities or its ability to meet contractual promises contained in instruments it issued. In addition, some crypto assets are created programmatically in a process that does not require the actions of a legal entity (or individual) at all. For example, the Ethereum blockchain programmatically distributes new ether tokens to validator node operators that stake existing ether tokens to be able to validate transactions on the network. Those new ether tokens are not “issued” by a corporate entity for capital formation purposes, but rather automatically distributed to validators pursuant to the network’s consensus mechanism as a reward for confirming transactions and contributing to the security of the network. Other protocols also enable the programmatic creation of new crypto assets as “wrappers” for other crypto assets, like wrapped versions of a token otherwise residing on one blockchain network on another network. There is a similar “issuerless” process for creating liquid staking tokens. [^10] Therefore, the current disclosure regime’s myopic focus on the concept of an issuer, wholly appropriate when looking at securities, is at odds with the nature of crypto assets which exist independent of any issuers. ### c. Crypto assets accrue value differently than securities Another key difference between crypto assets and securities is how each of them accrues value. It is basic financial dogma that the price of a company’s shares reflects the markets’ expectations of that company’s future financial performance (“discounted cash flow”). However, the value of many crypto assets is not tied to the financial performance of any centralized entity. This is most evident when looking at the markets for the most widely adopted and decentralized crypto assets like BTC or ETH which, like other commodities markets, are largely driven by general market forces and expectations of the future demand for use of the related protocol. [^11] But even in the context of nascent crypto projects that were launched by a development company, the value of crypto assets is often largely driven by factors other than the financial performance of the development company. [^12] People obtain crypto assets to use them within blockchain networks and applications or to hold them in anticipation of increased future demand for such use, as opposed to securities which are only ever passively held. A crypto asset’s utility as well as the underlying protocol’s mechanism design can therefore influence the value of the crypto asset more than the financial performance of the entity that created them. Moreover, given the open-source nature of most crypto asset-based projects, many crypto assets also accrue value from the contributions of a diverse group of developers outside of the development company or “founding team,” some of whom may remain pseudonymous. It is not uncommon for a development company to write the initial codebase for a new network or application, mint a native crypto asset, and subsequently seek to decentralize control of the project. For example, the development company may opt to transfer the permission to upgrade the smart contracts related to a specific network or application to crypto asset holders or a DAO so that future upgrades are decided by consensus. The developers can also transfer the permissions to a “burn” address, ensuring that no one is able to make any future changes. [^13] Further, such networks and applications may even be subject to “forks” and upgrades that are not supported or anticipated by the original developer. For example, the current Ethereum network is actually a fork of the original Ethereum network created in 2016 and now known as “Ethereum Classic”. As more applications emerge that build upon an original network or application and the original creators of the crypto asset have less and less control and influence over the project, purchasers of the crypto asset are less likely to rely upon the “efforts” of the original creator. It is also likely the creator will no longer have better information about the value proposition of the network or application relative to the broader decentralized community. ### d. Crypto assets operate on a fundamentally different “stack” than securities Crypto assets are also unique because they are traded on a fundamentally different technology “stack” than that used in the markets for securities. The shares of public companies, in particular, are traded, settled and custodied using a relatively archaic system that provides opportunities for numerous rent-seeking intermediaries. Therefore, while Chair Gensler may like to refer to his brokerage account as containing “digital assets,” these assets operate fundamentally differently than crypto assets. [^14] Publicly offered securities are typically issued using a paper certificate or are “dematerialized” (i.e., “certificateless”). The certificate or electronic record for a dematerialized security typically includes information about the security, such as the name of the issuer, the name of the holder and details regarding transfer restrictions. It is common for a security to be registered in “street name,” or in the name of the purchaser’s broker-dealer, rather than in the name of the purchaser. Many broker-dealers are members of The Depository Trust Company (or “DTC”), which is a not-for-profit SEC-registered clearing agency that custodies stock certificates and manages records of dematerialized securities. National securities exchanges require retail investors to purchase and sell securities on the exchange via intermediation by a broker-dealer that is a member of the exchange and such transactions are settled by a clearing agency, such as the DTC. In contrast to stock and bond certificates, crypto assets can trade and settle peer-to-peer on a 24/7 basis and be custodied directly by their owner, all without the need for any intermediaries. In addition, public permissionless blockchains rely on independent and unaffiliated entities to operate the nodes that process transactions, secure the network, and approve software implementations, which means, among other things, that major changes to the network require adoption by independent parties. The current regulatory framework for securities reflects the legacy market structure of the securities market. Forcing the trading of crypto assets into this framework would significantly hobble the development of the technology in the US by requiring it to run on the very rails it seeks to replace. ## 4. Clarity is needed to determine whether registration is required Despite Chair Gensler’s repeated claims that there is regulatory clarity for crypto projects, due to the SEC’s failure to provide actionable guidance on (a) when transactions involving crypto assets are securities transactions, and (b) if they are securities transactions, what type they are, it is impossible for projects to conclusively determine the fundamental question of when registration would be required and how such registration should be effected. ### a. When are crypto assets securities At this point, there is a general consensus that at least some crypto assets, in particular, BTC and its various forks or variations, are not securities. In addition, while Chair Genlser has been [unable to convey](https://www.coindesk.com/policy/2023/04/19/sec-chair-gensler-declines-to-say-if-ether-is-a-security-in-contentious-congressional-hearing/) a concrete view on this subject, most thoughtful commentators have concluded that ETH is also not a security—certainly, the CFTC has reached this conclusion. [^15] However, there is no clear agreement as to how the judicially mandated Howey and Reves tests would apply to most other crypto assets. [^16] As a result of the inherent complexities of these legal tests and the SEC’s unwillingness to meaningfully clarify their views as to how these tests should be applied to crypto assets, [^17] projects are incapable of making a definitive determination as to the status of most crypto assets. Both the Howey and Reves tests call for an assessment of the specific facts and circumstances associated with a given transaction to determine whether the federal securities laws apply. The tests are typically applied remedially, after a transaction has already occurred and a dispute has arisen which the parties are seeking to resolve in court. The “20/20 hindsight” and heavily fact-dependent nature of the analyses called for by these precedents can make it challenging for projects distributing crypto assets to apply these tests prospectively. The entity selling tokens must consider the totality of the facts and circumstances surrounding the transaction in advance and then speculate about how a court would view the arrangement in hindsight. Further, even where an initial fundraising sale of crypto assets can be safely categorized as a securities transaction, the treatment of the assets themselves is often much less clear. For example, it appears that the SEC’s view is that events that occur after the crypto assets have been initially sold (e.g., reliance on future efforts to upgrade a network or application, responses to an exploit, etc.) could impact whether the asset itself should be treated as a security, at least temporarily. The securities analysis of tokens has been further complicated by the SEC staff’s suggestion that a token’s status can “morph” from being a security to a non-security (and potentially even back again!). [^18] Projects like Hiro, discussed in Part II, and more recently Web3 Foundation (in respect of the Polkadot network’s native token, DOT), have publicly taken the position that their tokens were once investment contracts and therefore a security but are no longer. [^19] However, as previously discussed, there is currently no clarity as to when, if ever, it is appropriate to consider that a token has either become, or ceased to be, a security. ### b. If crypto assets are securities, what kind of securities are they? In addition to clarifying whether (or when) crypto assets are securities, the SEC must clarify what type of securities they are. The current SEC disclosure regime is designed for traditional corporate entities that generally issue equity and debt securities for purposes of raising capital. For example, Form S-1 requires issuers to determine whether the securities to be offered are equity or debt securities for purposes of evaluating the need to make certain disclosures. [^20] The SEC most commonly characterizes crypto assets as “investment contracts,” [^21] a term the Supreme Court defined broadly enough to encompass both equity or debt securities for registration statement purposes. Although the SEC staff has not provided formal guidance on the topic, it has indicated that some crypto assets that are investment contracts should be considered equity securities under Regulation C. [^22] However, some practitioners have pushed back on the SEC’s reasoning, arguing that the agency misreads the statutes. [^23] The distinction between equity or debt (or something else) is critical because it has many downstream effects for the entity deemed to be the issuer. For example, if the crypto assets that are investment contracts are deemed to be equity securities then the Section 12(g) registration requirements of the Securities Exchange Act of 1934 will apply. In addition, outside of the area of securities law, in the context of crypto assets that can earn a reward from staking or other activities, the distinction between equity and debt can affect the characterization of any income stream and their tax status. ## 5. Current disclosure requirements do not provide the right information about crypto assets Assuming that some crypto assets are considered securities and therefore subject to registration, the current SEC disclosure framework will need to be significantly adjusted and clarified in order to provide the market with the right mix of information about those crypto assets. ### a. What information about crypto assets is “material”? Issuers of registered securities are required to publicly disclose all “material” information related to an investment opportunity so that investors may make an informed decision. The Supreme Court has reasoned that information is “material” if such information would be reasonably viewed by an investor as significantly altering the total mix of information made available. [^24] However, since the disclosure requirements of Form S-1 and Regulation S-K are tailored for offerings of securities by centralized corporate entities seeking to raise capital to run a business enterprise and, as we explained in Section 3, crypto assets differ fundamentally from this, the current disclosure requirements do not capture material information for crypto assets. In fact, the typical information required by securities laws could be misleading to crypto asset investors, who may believe that information is material simply because the SEC mandated its disclosure, when it is not. Moreover, some of the material information that crypto asset users and investors would want to know is publicly available to technologically sophisticated participants. Despite adding controversial disclosure requirements related to topics like climate change, [^25] the SEC has not provided any guidance with respect to the types of disclosures it views as material in the context of crypto assets that are securities. As a result, the question of what information would be relevant (or “material”) to purchasers has been left to ad hoc determinations by the sellers of these crypto assets. Nor has the Commission tailored a distinct registration statement form for crypto asset security offerings, as it has done for other types of securities. [^26] The need for this guidance was even acknowledged by Chair Gensler who [noted](https://www.sec.gov/news/speech/gensler-sec-speaks-090822) that “it may be appropriate to be flexible in applying existing disclosure requirements,” and that “\[t\]ailored disclosures exist elsewhere — for example, asset-backed securities disclosure differs from that for equities.” In the subsections below, we analyze the current disclosure requirements that are inadequate with respect to crypto asset securities, as well as various missing disclosures. ### b. Current disclosure requirements are focused on information that is not material for owners of crypto assets ### i. Business and financial information Form S-1 and SEC Regulation S-K require the issuer to provide a detailed description of the issuer’s business and “revenue-generating activities, products and/or services,” along with audited financial statements. [^27] In addition, besides having to provide a full suite of audited (and, if applicable, unaudited interim) financial statements, registrants must include a highly detailed discussion of those financial statements known as “Management’s Discussion and Analysis of Financial Condition and Results of Operations” (or “MD&A”). While it may be possible for some sellers of crypto asset securities to provide such information, in many instances this information may not be particularly material and could wind up actually being misleading to purchasers. Unlike the typical initial public offering, a crypto asset security offering may be conducted by a seller with little to no operating history and no recent periods of profitable operations. Most importantly, assuming that the seller (or an affiliate) has completed the development of the crypto asset and associated blockchain network or application, the selling entity may not have any future business or revenue-generating plans that would be relevant to an initial or subsequent purchaser. Simply put, the original creators of crypto assets often have little relevance to the value of the asset being sold and only become less relevant over time. Information about the issuer’s ongoing business activities and financial statements may therefore not be material to investors on an ongoing basis. By contrast, investors will likely deem to be more material certain information about the network or application that is unrelated to the business of the selling entity and that is not contemplated by Form S-1 and associated disclosure regulations. The technical requirements of Form S-1 and Regulation S-X (as to financial statement information) may also present challenges for issuers that can result in purchasers being misled. For example, Regulation G requires issuers that present non-Generally Accepted Accounting Principles (“GAAP”) information to present the closest GAAP measure and a reconciliation. Since accounting standards like GAAP have not yet been updated to reflect the unique qualities of crypto assets, in practice this makes it very difficult to clearly present financial information that can be most relevant for disclosure. ### ii. Issuer and team information Form S-1 and Regulation S-K are tailored for securities offerings made by a single legal entity issuer with a traditional management structure. For example, the issuer is required to disclose biographical information for the executives, [^28] board of directors and certain other significant employees, [^29] along with their compensation and benefits, holdings in the company, and other information. However, as we have noted above, information related to the management of the legal entity deemed to be the “issuer” will often be less important in the context of crypto asset securities than it is for most other types of securities. Crypto assets are often launched by a distributed community that does not have a clear hierarchy or clearly defined bounds. In some extreme situations, the asset seller itself may dissolve and the team move on to do other things. In others, the original team will remain and continue working on the project, but over time purchasers may come to care more about third-party contributors who may not work on the project full time or have any formal relationship to the legal entity. It is not clear what level of disclosure would apply to these contributors. If covered by the disclosure obligations, they would not have the option of remaining anonymous, as is common today. ### iii. Use of proceeds Form S-1 requires the issuer to describe the registrant’s planned use of proceeds. However, crypto assets are often distributed in ways that do not accrue any direct proceeds to an “issuer.” For example, as mentioned above, the Ethereum blockchain programmatically distributes ether to validators that stake ether, but there is no centralized entity that receives proceeds in connection with these distributions. Additionally, it is common for crypto assets to be “air dropped” for free to users of an application or holders of a particular type of crypto asset. Moreover, the use of proceeds may not be determined by the issuer of the crypto assets and such proceeds may accrue to another person rather than the original seller, making it impossible for the seller to adequately disclose the relevant information in a registration statement. For example, it is common for a group of founders, who sometimes form development companies, to distribute a token and direct the proceeds to a community “treasury” (i.e., a blockchain address typically controlled by a “multi-sig” wallet typically by the vote of the tokenholders themselves. ### c. Missing disclosures In addition to focusing on information that is not relevant, current disclosure requirements also do not cover a number of features unique to crypto assets that would be considered material when making an investment decision. Since others have written extensively on the subject of disclosures for crypto assets, we only highlight some themes below. [^30] ### i. Governance While the current SEC disclosure framework focuses extensively on the corporate governance rights that the holders of securities have relative to an issuer, the disclosure framework completely misses the “governance abilities” that crypto assets have relative to their native protocols. As described above in Section 3(a), crypto assets largely derive their value and functionality on the basis of technological power they can exercise in a network. Understanding “governance” in the context of crypto assets therefore calls for different disclosures than in the context of securities. [^31] For example, it is critical for holders to understand the extent to which their token votes or other actions are self-executing or “on-chain,” as opposed to “off-chain”, relying on a legal or social enforcement mechanism. A tailored disclosure framework would also delve into how code upgrades can be implemented, including highlighting whether specific smart contracts are upgradeable and if so, which network addresses have the upgrade permissions and who controls those addresses. ### ii. Security While the SEC has enacted [rules](https://www.sec.gov/news/press-release/2022-39) mandating public companies to disclose information related to cybersecurity risks and incidents, it has not provided any guidance for how these apply to crypto assets. Given the severity of the cybersecurity threat in crypto, a tailored disclosure framework that focuses on the unique security issues raised by crypto assets and networks is required to protect investors and users. For example, the developers could be required to disclose any code audits provided the related software documentation and accompanying commentary. In addition, any incentives for white hat hackers to submit bug bounties or perform rescues would be material. ### iii. Network or Application Design Unlike companies that offer stock or bonds, sellers of crypto assets are typically offering an asset associated with a blockchain network or application. Although most projects publish the open-source code associated with the network or application, most purchasers of crypto assets lack the technological sophistication to read and understand the code. Accordingly, purchasers of crypto assets are likely to be particularly interested to learn more about the technical design of the network or application in making a decision to purchase the crypto asset. Indeed, the blockchain network or application may continue on well after the issuer is no longer operational. ### iv. Tokenomics The “tokenomics” of crypto assets is highly material to investors but not currently covered by the disclosure requirements. For example, information including the initial allocation of the tokens, total supply of tokens and future issuance schedule can have material impact on a crypto asset’s value. ### v. Consumptive Use / Utility Securities are by and large passive investment instruments that cannot be used or consumed in the same way as a commodity or collectible. But crypto assets are generally designed to be used within a blockchain network or application. Accordingly, purchasers of crypto assets are likely to desire information related to how the crypto assets can be used - or the crypto assets’ “utility.” ## 6. Conclusion As we have shown above, the current securities framework was tailor-made to regulate fundraising by centralized legal entities issuing securities, such as a company selling shares to the public in its “IPO.” However, crypto assets differ fundamentally from securities and therefore raise different investor disclosure considerations. Unfortunately, the current SEC Chair and staff have failed to recognize the uniqueness of crypto assets and are instead engaged in a campaign to attempt to brute force crypto into an ill-fitting disclosure regime. This campaign will ultimately harm the same public the SEC is tasked with protecting. As Nobel prize winning economist George Akerlof argued in his seminal [paper](https://viterbi-web.usc.edu/~shaddin/cs590fa13/papers/AkerlofMarketforLemons.pdf) “The Market For ‘Lemons’”, the quality of goods in markets that lack disclosure standards and exhibit information asymmetries between participants degrade over time. Applied to the market for crypto assets, Akerlof’s theory shows how the SEC’s insistence on applying an ill-fitting disclosure framework to crypto assets will result in the quality of crypto assets degrading, with direct harm to users, investors and the market generally. While the SEC Chair’s repeated catchphrase that crypto projects must “come in and register” might make for a good soundbite, it is no substitute for thoughtful policy. In order to fulfill its mission, the SEC must radically change course and work with the crypto industry to develop tailored disclosure requirements that provide crypto users and investors with the information that they need. [^1]: See Chris Brummer, Disclosure, Dapps and DeFi, Jun 29, 2022, Stanford Journal of Blockchain Law & Policy, available here, for the first published analysis of the ambiguities in the securities disclosure framework as applied to DeFi and Chris Brummer, Trevor Kiviat, Jai R. Massari, What Should be Disclosued in an Initial Coin Offering?, Dec. 17, 2018, available here, for the first published analysis of securities disclosures as applied to ICOs. These seminal pieces should be consulted by anyone interested in these topics [^2]: There are of course many other registration forms, including S-2 and S-3, F-1,F-2, F-3 and others. While our analysis below focuses solely on Form S-1, we believe the same arguments would apply to the rest of the registration forms, which share Form S-1’s general structure [^3]: SEC Commissioner Hester Peirce recently expressed her frustration with the SEC’s approach, noting that “[t [^4]: Regulation C establishes the general requirements for the filing of a registration statement, including requirements related to proper form, incorporation by reference, confidential treatment, and submission to the SEC. 17 C.F.R. Part 230 [^5]: Regulation S-K details the requirements for disclosing certain non-financial qualitative descriptors that issuers must include in the registration statement. 17 C.F.R. Part 229 [^6]: Regulation S-X describes the requirements for the disclosure of financial statements in the registration statement. 17 C.F.R. Part 210 [^7]: Lewis Rinaudo Cohen, Gregory Strong, Freeman Lewin, Sarah Chen, The Ineluctable Modality of Securities Law: Why Fungible Crypto Assets Are Not Securities (Nov. 10, 2022), available here [^8]: Smart contracts are immutable by default, meaning they cannot be removed or updated by anyone once deployed. It is possible for the smart contract’s developers to, prior to the smart contract’s deployment, include the ability to update its functionality. This ability to update functionality can be revoked by transferring the permissions for this ability to a “burn” Ethereum address for which there is no corresponding private key. This placeholder is known as “the zero address.” Once the ability to update a contract has been revoked, it cannot be reclaimed and the contract can no longer be changed [^9]: For example, MakerDAO, the community behind the stablecoin DAI, dissolved the foundation they relied on during the early stages of the project [^10]: See Proof of Stake Alliance, U.S. Federal Securities and Commodity Law Analysis of Liquid Staking Receipt Tokens (Feb. 21, 2023), available here [^11]: Nareg Essaghoolian, Initial Coin Offerings: Emerging Technology’s Fundraising Innovation, 66 UCLA L. Rev. 294, 304 (2019) (“Since Bitcoin is not backed by the trust of a central authority, its value is derived solely by market forces.”) [^12]: Michael Selig, What If Regulators Wrote Rules for Crypto?, CoinDesk (Jan. 23, 2023), available here (“Crypto assets are network assets. Unlike firms, networks are generative. The value of a network derives from the applications, organizations and projects built on the network by its users.”) [^13]: See FN 7 for more detail [^14]: House Financial Services Committee, Hearing Entitled: Oversight of the Securities and Exchange Commission, April 18, 2023, available here [^15]: See, e.g., CFTC Chair Rostin Behnam’s response to Senator Kirsten Gillibrand’s questions at the March 8, 2023 CFTC oversight hearing by the Senate Agriculture Committee where Chair Behnam made clear his view that ETH is not a security and that the CFTC would not have permitted a CFTC-regulated exchange to list an ETH futures product if ETH was a security. “I’ve made the argument that Ether is a commodity. It’s been listed on CFTC exchanges for quite some time and for that reason it creates a very direct jurisdictional hook for us to police obviously the derivatives market but also the underlying market as well … we would not have allowed the product, in this case the ether futures product, to be listed on a CFTC exchange if we did not feel strongly that it was a commodity asset.” [^16]: See S.E.C. v. W.J. Howey Co., 328 U.S. 293 (1946) and Reves v. Ernst & Young, 494 U.S. 56 (1990). Outside of Howey and Reves, the SEC has argued that certain crypto assets meet the definition of “security” for other reasons. For example, in SEC v. Terraform Labs PTE Ltd., Case No. 1:23-cv-01346 (S.D. NY Feb. 15, 23) (complaint), the SEC argues that UST is a security because it is a right to purchase a security and wLUNA is a security because it is a receipt for a security [^17]: Strategic Hub for Innovation and Financial Technology, Framework for “Investment Contract” Analysis of Digital Assets (Apr. 3, 2019), available here (the “FinHub Framework”). The FinHub Framework expands the four prong Howey analysis into approximately fifty non-exhaustive factors, none of which is necessarily intended to be weighted more heavily than any other or to be dispositive as to security status [^18]: As former SEC Director of Corporation Finance William Hinman noted in public remarks, it is possible for a crypto asset to initially be offered and sold as a security because it is part of an investment contract, but later no longer be part of any investment contract (e.g., as a result of decentralization of the associated network or application) [^19]: Web3 Foundation Announces Polkadot Blockchain’s Native Token (DOT) Has Morphed and Is Software, Not a Security, November 10, 2022, available here [^20]: The form requires issuers of equity securities to specify the dividend rights associated with each security and whether the issuer intends to pay cash dividends to holders (and, if the issuer has sufficient earnings to do so, the reason that the issuer does not plan to do so). Additionally, issuers of equity securities must outline the voting rights, liquidation rights, preemption rights, and sinking fund provisions associated with the securities, among other things. Importantly, the form assumes that the dividend, voting, and preemption rights are associated with the issuer legal entity rather than a blockchain network or DAO. Issuers of debt securities must provide disclosures with respect to, among other things, maturity, interest, conversion, redemption, amortization, sinking fund, and retirement [^21]: The SEC has also recently argued that certain crypto assets are securities under theories that such assets constitute a right to purchase a security, a receipt for a security and a security-based swap. (See, e.g., SEC v. Terraform Labs PTE Ltd., Case No. 1:23-cv-01346 (S.D.N.Y Feb. 16, 2023) (complaint) [^22]: See, e.g., Blockstack Token LLC, Preliminary Offering Circular (Apr. 11, 2019), available here (although issuer noted that it does not believe that the tokens are equity or debt, issuer included disclosures typical of an equity security offering); INX Limited, Form F-1 (Aug. 19, 2019), available here (issuer expressly characterized tokens as equity securities) [^23]: See Robert Rosenblum, Reading the Not-So-Subtle Tea Leaves: What the SEC is Likely to Do Next in Crypto, and How Crypto Participants Should Prepare (July 28, 2022), available here. (First, tokens that are securities because they are investment contracts under the Howey test usually lack traditional indicia of equity securities of the issuer of the tokens; the tokens generally provide the token holder with no right to dividends or other income from the issuer of the tokens, and they give the token holder no rights to vote for directors of the issuer or to vote on any other matters directly affecting the issuer. Second, most Howey tokens do not seem to come within the relevant definitions of “equity security.” Section 3(a)(11) of the Exchange Act defines the term “equity security’ to mean, in relevant part, “any stock or similar security.” Rule 3a11-1 under the Exchange Act contains a somewhat broader definition of “equity security,” including in pertinent part “any stock or similar security, certificate of interest or participation in any profit sharing agreement, preorganization certificate or subscription, transferable share, voting trust certificate or certificate of deposit for an equity security, limited partnership interest, interest in a joint venture, or certificate of interest in a business trust …” The list of instruments in Rule 3a11-1 is based on instruments described in the definition of security in Section 3(a)(10) of the Exchange Act. Notably, Rule 3a11-1 does not include in its definition of an equity security an “investment contract.” The term investment contract is, of course, listed in the definition of “security” in Section 3(a)(10), and its absence from the list of instruments in Rule 3a11-1 strongly suggests that investment contracts generally are not equity securities. Therefore, tokens that are securities solely because they are investment contracts do not appear to be equity securities under Rule 3a11-1, and the issuers of those tokens should not be subject to a Section 12(g) registration requirement with respect to those tokens.) [^24]: Basic, Inc. v. Levinson, 485 U.S. 224, 232 (1988) [^25]: See The Enhancement and Standardization of Climate-Related Disclosures for Investors, 87 Fed. Reg. 21334 (Apr. 11, 2022) [^26]: The SEC has created special disclosure “schedules” for issuances of asset-backed securities and securities by companies in the oil and gas and the banking sectors as well as special rules for sales of securities by foreign governments, among others [^27]: This includes audited balance sheets as of the end of each of the two most recent fiscal years, or, if the issuer has been in existence for less than one fiscal year, an audited balance sheet as of a date within 135 days of the date of filing the registration statement [^28]: Executive officers include the president, any vice president in charge of a principal business unit, division or function (such as sales, administration or finance), any other officer who performs a policy making function, or any other person who performs similar policy making functions for the issuer [^29]: Such significant employees include production managers, sales managers, or research scientists who are not executive officers but who make or are expected to make significant contributions to the business [^30]: Disclosure, Dapps and DeFi (3.24.2022) by Chris Brummer, LeXpunK Regulation X Proposal (4.25.2022) by Sarah Brennan, Andrew Glidden, Darren Sandler and Gabriel Shapiro and accompanying Safe Harbor X (1.8.2022) by Gabriel Shapiro, Token Safe Harbor Proposal 2.0 (4.31.2021) by SEC Commissioner Hester Pierce, What Should Be Disclosed in an Initial Coin Offering (11.29.2018) by Chris Brummer, Trevor Kiviat, Jai R. Massari [^31]: Some projects have relied on offshore legal entities with governance mechanisms that are informed by tokenholders. For example, many projects have formed ownerless foundation companies in the Cayman Islands that have adopted charters requiring the foundation’s directors to take the recommendations of tokenholders, expressed via governance voting, into account and generally act in accordance with the recommendations of tokenholders. However, the “governance rights” that these tokenholders have vis-a-vis offshore entities are significantly more limited than the rights a shareholder enjoys vis-a-vis a related corporation and tokenholder votes generally are not legally binding on a foundation’s directors in the same way that shareholder votes are binding with regard to a corporation ## https://www.paradigm.xyz/writing/paradigm-files-van-loon-amicus-brief # Paradigm Files Van Loon Amicus Brief > Paradigm filed an amicus brief in the lawsuit that six Tornado Cash users brought to challenge the government’s unprecedented sanctioning of the Tornado Cash open-source code. **TLDR**: On Friday, Paradigm filed an [amicus brief](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-c9f9ab9a1e/def8d1e0fe77881a026682bd8c60a6ec/asset-https-cdn-sanity-io-files-dgybcd83-p-c9f9ab9a1e.pdf) in the lawsuit that six Tornado Cash users brought to challenge the government’s unprecedented sanctioning of the Tornado Cash open-source code. Our argument is simple: OFAC is authorized to sanction only “people” or “entities,” and their “property.” Tornado Cash fits none of those definitions—it is merely open-source [code](https://github.com/tornadocash/tornado-core). In August 2022, the Office of Foreign Assets Control (“OFAC”) [sanctioned](https://home.treasury.gov/news/press-releases/jy0916) Tornado Cash and added a list of related blockchain addresses to the [Specially Designated Nationals List](https://ofac.treasury.gov/specially-designated-nationals-and-blocked-persons-list-sdn-human-readable-lists) (“SDN List”), including the addresses of the immutable smart contracts that enabled the Tornado Cash “pools.” As a result of this unprecedented attempt to sanction open-source code, in September 2022, six Tornado Cash users filed suit against OFAC, arguing that the designation of Tornado Cash exceeded the agency’s statutory authority because Tornado Cash was not a “person,” “entity” or their “property” and also infringed on the Tornado Cash users’ constitutional rights of free speech and due process. In October, a similar [lawsuit](https://www.coincenter.org/app/uploads/2022/10/1-Complaint-Coin-Center-10-12-22.pdf) was filed by Coin Center. We have supported their efforts. Responding to the lawsuits, in November 2022, OFAC [redesignated](https://home.treasury.gov/news/press-releases/jy1087) Tornado Cash and attempted to clarify its position [stating](https://ofac.treasury.gov/faqs/1095) that the “person” it was sanctioning was the “entity known as Tornado Cash.” According to OFAC, this “entity” was composed of two loosely affiliated groups that, when joined together, gave life to a new Frankenstein-like legal “person.” The first half of the Tornado Cash “entity” was composed of the unnamed “founders and associated developers,” which in the context of open-source development, is a highly ambitious term that could include developers who indirectly contributed to Tornado Cash code. The second half of the “entity” was the “Tornado Cash DAO,” made up of *every* TORN token holder. As our *amicus* brief argues, OFAC’s novel theory that Tornado Cash is an unincorporated entity is wrong on the law. None of the developers or tokenholders expressed intent to work towards a common purpose, and that is required for the creation of an unincorporated association. OFAC’s novel theory that “associated developers” could be conscripted into joining a legal entity by virtue of making contributions to open-source code should also be rejected because it threatens the viability of open-source development in the United States. When a developer makes a pull request on GitHub, they are not signing up to be a member of a legal entity. They are simply writing code, which is speech protected by the First Amendment. While OFAC has not sanctioned any of the individual developers or tokenholders to date, they still maintain the power to do so in the future. Critically, OFAC’s expansive theory that *all* tokenholders *plus* developers constitute a legal entity could be applied in other contexts to crypto-enabled communities, like DAOs. To date, U.S. regulators like the CFTC have argued, erroneously in [our view](https://paradigm.xyz/writing/2022/10/paradigm-files-amicus-brief-in-cftc-action-against-ooki-dao), that *voting* tokenholders constitute an unincorporated association. Here, OFAC is expanding the unincorporated association to include not only *all* tokenholders (instead of just those that voted), but critically also “associated developers.” If adopted, this theory could therefore materially expand liability for developers and tokenholders. That would be a dangerous loss for developers, tokenholders, crypto as a whole, and the U.S. itself, and we are happy to add our voice to the many crypto representatives speaking out against this case. Paradigm will keep fighting to defend blockchain users’ right to privacy. If you have ideas for matters we should get involved in, please reach out. ## https://www.paradigm.xyz/writing/march-2023-public-opinion-poll # March 2023 Public Opinion Poll > While Washington sits on the sidelines, Americans want regulatory clarity on crypto. That's the bottom line on a poll we recently conducted to better understand how Americans view crypto. While Washington sits on the sidelines, Americans want regulatory clarity on crypto. That’s the bottom line on a poll we recently conducted [^1] to better understand how Americans view crypto. Here are the key findings policymakers should note. **Takeaway 1: Americans have a strong desire for regulatory clarity around crypto but don’t have a clear preference for which party they trust more on crypto regulations.** ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--22266b4f2b/252661b4966482424c473e7e728b195b/asset-https-cdn-sanity-io-images-dgybcd83--22266b4f2b.png) 65% said crypto needs more regulation and 76% supported “establish(ing) a government-wide standard… to create regulatory clarity.” Despite the strong support for regulatory clarity, there was no consensus on which party Americans trust more. 25% trusted Republicans more with cryptocurrency, 27% trusted Democrats more, and **43% trusted neither party more**. [^2] These numbers suggest Americans don’t see crypto as a partisan issue. Neither do we. **Takeaway 2: Americans are excited about crypto’s ability to expand financial access to the underbanked and challenge the status quo of tech and finance.** ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--c8880eddfd/523c5f6bb2a51b9ad503a6b961228dad/asset-https-cdn-sanity-io-images-dgybcd83--c8880eddfd.png) The primary reasons [^3] people were most excited about crypto fell into three main categories: Increasing access to the banking system (i.e. Ukraine aid / global remittances): - 42% Crypto enables people who are not connected to the traditional banking system to transfer money securely Technical advantages over legacy finance: - 34% Crypto reduces the costs of transactions - 30% Crypto enables transactions to be stored securely across multiple sources Competition to incumbents: - 32% Crypto creates alternatives to big banks and other Wall Street power brokers - 19% Crypto creates competition with big tech companies By far, the most popular current use case for crypto was increasing access to the banking system for unbanked and underbanked populations. Hundreds of millions of people around the globe don’t have access to secure banking and the events of the last few weeks should remind all of us to never take our access to checking accounts, credit cards, etc for granted. [^1]: Paradigm worked with Public Opinion Strategies to survey a representative sample of 1,000 American citizens to gauge public sentiment on crypto from March 9 - 13, 2023 [^2]: 83% of independent voters trusted neither party more with cryptocurrency [^3]: Our poll asked respondents to rank which aspects of crypto excited them the most. The numbers listed represent the combined first and second choices of all respondents ## https://www.paradigm.xyz/writing/secs-path-to-registration-part-ii # Lessons from Crypto Projects’ Failed Attempts to Register with the SEC > As we show in a number of case studies, the projects that attempted to come into compliance with the SEC’s registration requirements expended great effort and resources yet ultimately most of them failed, and those that persist do so in a state of uncertainty and comparative disadvantage. The failure of projects that have attempted to register is due in large part to the SEC’s reluctance to provide a workable framework through rulemaking, exemptive relief, guidance and industry engagement. See Part I [here](https://paradigm.xyz/writing/2023/03/secs-path-to-registration-part-i). See Part III [here](https://paradigm.xyz/writing/2023/04/secs-path-to-registration-part-iii ). ## 1. What is SEC registration? The grand bargain of the US securities laws is that any issuer selling securities to the general public must provide the public with a set of disclosures approved by the SEC. These laws are intended to address information asymmetry and ensure that the investing public has the material information necessary to make informed investment decisions. The securities laws are not intended to turn the SEC into a gatekeeper or “merit regulator” that itself decides which projects are investable and which are not. Congress meant for discretion to remain solidly in the hands of individual investors. [^1] According to this framework, whenever a crypto project is distributing tokens in a “securities offering,” [^2] it must be either registered with the SEC or comply with an exemption from registration. Most frequently, crypto projects rely on exemptions for private offerings made only to “accredited investors” or only to non-U.S. persons. However, there are four main paths to registering or qualifying a token offering that includes non-accredited investors under the Securities Act of 1933 (the “1933 Act”): 1. a “mini-IPO” under Regulation A pursuant to [Form 1-A](https://www.sec.gov/files/form1-a.pdf) [^3]; 2. offering under Regulation Crowdfunding pursuant to [Form C](https://www.sec.gov/files/formc.pdf) [^4]; 3. a typical IPO by a domestic issuer on [Form S-1](https://www.sec.gov/files/forms-1.pdf); and 4. an IPO by a foreign issuer on [Form F-1](https://www.sec.gov/files/formf-1.pdf). In order to register or qualify an offering, the issuer needs to fill out the appropriate form and submit it to the SEC with other documents, including typically 2 years of financial statements. The SEC will review the submission and provide comments which must be sufficiently addressed through written answers and subsequent amendments of the filed forms. Only after the SEC’s comments are fully addressed and the form is “effective” or “qualified” can the issuer begin to sell the securities. [^5] Even if the token distribution is exempt from the registration requirements of the 1933 Act, if the tokens are considered “equity” securities and the project meets certain minimum asset and holder requirements, [^6] they may also be required to register under the Securities Exchange Act of 1934 (the “1934 Act” and together with the 1933 Act, the “Securities Acts”) by filing [Form 10](https://www.sec.gov/files/form10.pdf). Form 10 is automatically effective 60 days after it is filed. However, the SEC can provide comments that need to be addressed to prevent the registration from being revoked. Many crypto projects are understandably concerned that, in exercising discretion when commenting on and approving registration statements (or not), the SEC could overstep its mandate and act effectively as a merit regulator, depriving the public from their ability to choose their own investments. But the SEC’s job is to ensure adequate disclosure of securities opportunities for investors, not to decide what investors can invest in. That power remains entirely with the American people. In addition, most SEC registration forms reference yet other SEC regulations, most notably Regulation S-K and S-X, which provide for a wide variety of specialized disclosures. There are also “schedules” for registrants in certain industries, such as oil & gas and banking, to address the unique elements of those industries. There are even special rules for issuers of asset-backed securities, excepting these issuers from some requirements applicable to “traditional companies” and adding other disclosures. But has the SEC done the same for companies working on crypto projects? No. ## 2. What obligations do SEC registered projects have? Registration is not a “one and done” process. When a project registers a token it will also become a publicly-reporting company that must file annual, quarterly, and current reports, and become subject to the proxy, tender offer, Sarbanes-Oxley, and a host of other rules. [^7] Once a project has registered a token, either under the 1933 or 1934 Act, that token will only be able to trade on a National Securities Exchange, Alternative Trading System (“ATS”), or by brokers OTC. [^8] In addition, many intermediaries dealing with the token will be subject to onerous regulation. However, as stated by Coinbase in its [petition for rulemaking](https://www.sec.gov/rules/petitions/2022/petn4-789.pdf), “The U.S. does not currently have a functioning market in digital asset securities due to the lack of a clear and workable regulatory regime.” This is because tokens that register as securities would not be tradeable on existing crypto exchanges, none of which are registered as a national securities exchange. But there are also no registered national securities exchanges that can trade tokens and a limited number of ATS that effectively have no meaningful secondary liquidity. But more fundamentally, the current regulations are incompatible with disintermediated trading. On the rare occasion the SEC lets a token project legitimize through registration, that token lands in a world lacking the infrastructure necessary to trade it. Specifically, the SEC has refused to license intermediaries such as broker-dealers and exchanges. As a result, the restrictions on the secondary market trading of tokens registered as securities will severely hinder if not totally impede the operation of most crypto projects. The SEC has created a world where project founders are required to register as ice cream, while making freezers illegal. Good luck! Crypto projects seeking to register tokens or other products will also face a daunting process. Despite the substantial time and extraordinary costs incurred by the few projects that have attempted registration, these projects have [arguably](https://www-law360-com.cdn.ampproject.org/c/s/www.law360.com/amp/articles/1583975) been unable to operate their businesses while complying with the securities laws, or have operated their businesses at a significant disadvantage to others in the market who operate without registration and with no adverse regulatory consequences. In the sections that follow, we will provide an overview of the tokens that have attempted to register with the SEC. [^9] ## 3. ICO era enforcement actions The earliest attempts at registering tokens under the Securities Acts came as a result of settlements relating to SEC enforcement actions. Six projects that conducted ICOs starting in 2017 — CarrierEQ Inc. (dba ”[Airfox](https://www.sec.gov/litigation/admin/2018/33-10575.pdf)”), [Paragon Coin, Inc.](https://www.sec.gov/litigation/admin/2018/33-10574.pdf), [Gladius Network](https://www.sec.gov/litigation/admin/2019/33-10608.pdf), [Blockchain of Things, Inc.](https://www.sec.gov/litigation/admin/2019/33-10736.pdf), [Enigma MPC](https://www.sec.gov/litigation/admin/2020/33-10755.pdf) and [Salt Blockchain Inc.](https://www.sec.gov/litigation/admin/2020/33-10865.pdf) — were each charged by the SEC with undertaking an unregistered offering and sale of securities. [^10] In order to settle the changes, each of the projects agreed to repay investors, to register their respective tokens as a “class of securities” under the 1934 Act by filing Form 10 and to comply with ongoing reporting obligations. ### a. How have those projects fared? At the time, the SEC [hailed](https://www.sec.gov/news/press-release/2018-264) the settlements as “a model for companies that have issued tokens in ICOs and seek to comply with the federal securities laws” and [argued](https://www.sec.gov/news/public-statement/digital-asset-securites-issuuance-and-trading) the settlements represented “a path to compliance with the federal securities laws going forward, even where issuers have conducted an illegal unregistered offering of digital asset securities.” The SEC even declined to impose additional penalties on each of the projects to account for their respective “remedial” actions, including their commitment to register the tokens as securities. Yet one can argue the SEC’s requirement that these companies register their tokens was not meant to provide an avenue for the projects to continue operating as reporting companies – it was intended only to euthanize them. Registration was used as a tool to assist in the rescission process pursuant to which the companies had to pay back the original token purchasers. In hindsight, it’s no surprise that despite the SEC’s initial enthusiasm, out of the six projects that were required to register their token, five are no longer operating in the US or reporting to the SEC and none of the six tokens has any meaningful utility or market. These examples reveal that the SEC’s suggested “path to compliance” was really an ascent to the afterlife. And while some might dismiss this as worthy punishment for projects that conducted unregistered offerings, it reveals the impossibility of complying with the current SEC regime.A former SEC enforcement lawyer was even [quoted](https://www.wsj.com/articles/secs-settlements-with-some-cryptocurrency-firms-showing-cracks-11573729200) at the time saying the SEC’s settlement model was “impractical.” Perhaps recognizing this fact, the SEC has largely since stopped requiring projects to register as part of settlements for unregistered offerings of securities. [^11] ### Airfox Airfox was a Massachusetts-based start up that, between August and October 2017, raised $15 million through its ICO of “AirTokens.” The company entered into a [settlement](https://www.sec.gov/litigation/admin/2018/33-10575.pdf) with the SEC on Nov. 16, 2018, that included the obligation to register the AirTokens by filing a Form 10 within 90 days. Nearly 4 months later, on March 15, 2019, Airfox [filed](https://www.sec.gov/edgar/search/#/dateRange=10y&entityName=CarrierEQ) its Form 10, which became automatically effective on May 14, 2019, making AirTokens the first token to be registered with the SEC on Form 10. However, Airfox’s Form 10 had to be subsequently amended four times in order to respond to SEC comments. While Airfox initially complied with its obligation to register the AirTokens and make ongoing disclosures, the company was forced to pivot away from their token and in May 2020 was [acquired](https://www.businesswire.com/news/home/20200522005034/en/Boston-Based-Fintech-Startup-Airfox-Acquired-Brazilian-Retail) by a Brazilian retailer. In a [current report](https://www.sec.gov/Archives/edgar/data/1766352/000155335021000544/airfox_8k.htm) filed on Form 8-K, the company noted it would discontinue the development of AirTokens because “\[c\]urrent laws and regulatory regimes do not provide for the Company to utilize the AirTokens as envisioned by the Company…” Since then, the company has stopped operating in the US and the AirTokens have had no [liquidity](https://etherscan.io/token/0x27dce1ec4d3f72c3e457cc50354f1f975ddef488). The token is effectively dead. ### Paragon Paragon Coin Inc. (“Paragon”) was a Delaware company that raised $12 million from their 2017 ICO of “PRG Tokens” as part of a scheme to integrate blockchain technology to the cannabis industry. Paragon also entered into a [settlement](https://www.sec.gov/litigation/admin/2018/33-10574.pdf) with the SEC on the same date and on substantially the same terms as Airfox, including the requirement to register the PRG Tokens on Form 10 within 90 days. On March 29, 2019, more than 4 months after the settlement, Paragon Coin [filed](https://www.sec.gov/edgar/search/#/dateRange=10y&ciks=0001771087&entityName=ParagonCoin%252C%2520Ltd%2520(CIK%25200001771087)) its first and only Form 10 registration, which became automatically effective 60 days after. However, the company failed to answer an SEC letter with dozens of follow-up questions, or amend the registration or provide any additional disclosures. According to [reports](https://decrypt.co/66050/investors-paragon-12-million-cannabis-crypto-ico-will-finally-get-some-money-back), in April 2020 Paragon announced that it was filing for bankruptcy and ceasing operations, noting that its “plans were impossible to achieve due to several legal mistakes”. On March 9 of this year, the SEC officially [revoked](https://www.sec.gov/edgar/search/#/dateRange=10y&ciks=0001771087&entityName=ParagonCoin%252C%2520Ltd%2520(CIK%25200001771087)) the registration of the PRG tokens. There is also no [market](https://etherscan.io/address/0x7728dFEF5aBd468669EB7f9b48A7f70a501eD29D) in the PRG Tokens. This project is dead. ### Gladius Gladius Network LLC (“Gladius”) was a Nevada company that was developing a network that allowed participants to rent out spare bandwidth and storage space. The company raised ~$12.7 million pursuant to its 2017 ICO of “GLA Tokens.” On February 20, 2019, Gladius also entered into a settlement with the SEC that required it to register the GLA Tokens on Form 10 within 90 days. The Gladius settlement order included an additional provision stating that the company may later choose to file a [Form 15](https://www.sec.gov/files/form15.pdf) to de-register the GLA Tokens. [^12] The reference to Form 15 supports the view that a crypto asset may initially be offered and sold as part of an investment contract but later (e.g., as a result of sufficient decentralization) no longer be part of any investment contract. However in Gladius’ case, the company didn’t even file any Form 10 registration statement as agreed to in the SEC settlement, nor did it [reportedly](https://www.coindesk.com/markets/2019/11/25/unregistered-ico-issuer-gladius-shuts-down-9-months-after-sec-settlement/) pay back any of the tokenholders, opting to dissolve instead. This project is dead. ### Blockchain of Things, Inc. Blockchain of Things, Inc. (“BCOT”) was a NY-based corporation that, from December 2017 through July 2018, raised more than $12 million from its sales of “BCOT Tokens.” On December 18, 2019, the company entered into a [settlement](https://www.sec.gov/litigation/admin/2019/33-10736.pdf) with the SEC pursuant to which it agreed to register the BCOT Tokens under Form 10 within 120 days. In June 2020, BCOT [filed](https://www.sec.gov/edgar/search/#/ciks=0001813793&entityName=Blockchain%2520of%2520Things%252C%2520Inc.%2520(CIK%25200001813793)) its initial Form 10 registration, which it had to subsequently amend. While BCOT temporarily complied with its ongoing reporting obligations, in March of 2023, it announced that it was ceasing operations and liquidating. In connection with the wind down, the company filed a [Form 15](https://www.sec.gov/Archives/edgar/data/1813793/000166357723000099/bcot_form15.htm) to de-register the BCTO Tokens, which is the first and only time tokens have been de-registered, albeit in the contest of a dissolution not a project decentralizing. This project is dead. ### Enigma MPC Enigma MPC (“Enigma”) is a Delaware corporation that raised ~$45 million by selling “ENG Tokens” in the summer and fall of 2017. On February 19, 2020, the company entered into a [settlement](https://www.sec.gov/litigation/admin/2020/33-10755.pdf) with the SEC that required the company to register the ENG Tokens using Form 10. Like others before it, the company initially complied with the settlement obligations and [filed](https://www.sec.gov/edgar/search/#/ciks=0001816114&entityName=Enigma%2520MPC%2520(CIK%25200001816114)) a Form 10 registration statement, which it subsequently amended three times in response to SEC comments. However, the company stopped making any disclosures after May 31, 2021, and is currently in an administrative [proceeding](https://www.sec.gov/litigation/admin/2022/34-95839.pdf) for being delinquent on its reporting. The ENG Token has virtually no [liquidity](https://etherscan.io/token/0xf0ee6b27b759c9893ce4f094b49ad28fd15a23e4#tokenAnalytics). This project appears to be comatose at best. ### Salt Blockchain Inc. Salt Blockchain Inc. (“Salt”) is a Colorado based corporation that operates a lending business that allows borrowers to obtain US-denominated loans collateralized by digital assets. During a period beginning in August 2017 and ending in August 2019, Salt raised ~$47 million from its sale of “Salt Tokens.” On Sept. 30, 2020, Salt entered into a [settlement](https://www.sec.gov/litigation/admin/2020/33-10865.pdf) with the SEC that included an obligation to file a registration statement on Form 10 within 120 days. In May 2021, Salt filed its initial Form 10, which was subsequently amended four times in response to SEC comments. While Salt is an exception amongst the group given that it is still operating in the US, the Salt Token itself seems to have been largely deprecated and has almost non-existent [liquidity](https://etherscan.io/token/0x4156D3342D5c385a87D264F90653733592000581#tokenAnalytics). Despite this, the company has not filed a Form 15 to deregister the token, meaning they are subject to the burden of ongoing disclosure despite the token having no real utility. ## Reg A offerings The next wave of attempts at “compliant” token offerings were done as “mini-IPOs” under Regulation A promulgated under the 1933 Act (“Reg A”). Reg A offerings are technically exempted offerings as opposed to registered offerings, yet relevant to the discussion as they provide a potential alternative for regulated token distributions. As we will see, however, Reg A did not turn out to be a viable path either. Reg A was updated by the JOBS Act in 2012 to provide an alternative for small companies to raise from unaccredited investors using “slimmed down” disclosures as compared to a traditional IPO on Form S-1. Those wishing to conduct a Reg A offering must draft an Offering Statement including the information required on [Form 1-A](https://www.sec.gov/files/form1-a.pdf), file it with the SEC and address any comments before getting “qualified.” [^13] If the issuer is conducting an “ongoing offering,” it must continuously update the Offering Statement to ensure it always contains all material information about the company, the platform, and the tokens. In cases where there are fundamental changes to information in the qualified Offering Statement, the SEC will review and approve the amendment. As described below, this obligation to update the Offering Statement on an ongoing basis can cause significant friction for crypto projects which typically iterate on product quickly and therefore will need to constantly amend their disclosures. Reg A issuers also have ongoing reporting requirements. Although these disclosure obligations are less burdensome than those required after a fully registered offering, they nonetheless result in material ongoing costs to the token issuers. In addition, a significant challenge for Reg A token offerings is the lack of secondary markets, as the tokens must trade on SEC registered trading venues, none of which are workable options today. When the Reg A offerings of Hiro Systems PBC (f/k/a Blockstack PBC, “Hiro”) and YouNow (each described below) were qualified in 2019, some argued that Reg A was a ”[potential solution](https://www.wsgr.com/publications/PDFSearch/token-offering-1019.pdf)” to regulated token distributions. [^14] to sell bitcoin-like digital tokens, a first-of-its-kind offering that could give young cryptocurrency businesses a new fundraising template”\] However, as described in more detail below, Reg A offerings did not turn out to be a viable option, partly due to the prohibitively high costs, the restrictions with trading the tokens, and the burden of disclosure obligations. This pathway has also led to a dead-end. With four years of hindsight, the assessment from those same commentators was stark. The lead lawyer for both Hiro and YouNow recently [noted](https://www-law360-com.cdn.ampproject.org/c/s/www.law360.com/amp/articles/1583975) that “To date, the SEC still has not adopted a single rule with which to govern crypto, has not amended a single disclosure or registration form to reflect the unique aspects of crypto, and has not created a workable process by which digital asset issuers can register their tokens for public sale or trade those tokens in a liquid secondary market.” ### Hiro On July 10, 2019, the SEC qualified the first Reg A token issuance. Hiro’s $40 million offering of “Stacks Tokens” structured as a “Tier 2” Reg A offering reportedly cost the company $2.8 million in fees and took over 10 months to prepare. In addition to being the first, the most remarkable aspect of Hiro’s [Offering Circular](https://www.sec.gov/edgar/search/#/ciks=0001693656&entityName=Hiro%2520Systems%2520PBC%2520(CIK%25200001693656)) was that it laid out the company’s long-term plans for decentralization, noting that its “ultimate goal is that the evolution and development of the Blockstack network become independent of \[Hiro\].” Therefore, Hiro noted that while it was treating the Stack Tokens as securities “for the foreseeable future,” its Board would be “responsible for regularly considering and ultimately determining whether the Stacks Tokens no longer constitute securities.” In other words, Hiro had registered the Stacks Tokens as securities out of an “abundance of caution,” but from day one aspired for the tokens to “morph” into non-securities, at which point Hiro would no longer be responsible for their registration. In keeping with this framework, in January 2021, Hiro’s Board [voted](https://www.sec.gov/Archives/edgar/data/1693656/000119312521012574/d111554d1u.htm) to “no longer treat the Stacks Tokens as investment contracts that are securities under the federal securities laws.” [^15] As a result, Hiro would no longer be required to file reports pursuant to Reg A. In making this critical determination, Hiro’s management and Board relied on a legal opinion from Wilson Sonsini, a summary of which was made publicly available. Despite Hiro’s self-declaration that the Stacks Tokens were no longer securities, the SEC never formally weighed in. And it’s not clear the SEC agrees with Hiro’s position. In its latest [annual report](https://www.sec.gov/Archives/edgar/data/1693656/000119312522128944/d294978dpartii.htm), Hiro disclosed that it “is responding to an inquiry from the Division of Enforcement” related to its decision to no longer treat the Stacks Tokens as securities. While the SEC staff guidance has stated that the analysis of whether a digital asset represents an investment contract (and thus, a security) may change over time, it has failed to provide any bright line rule or further clarification as to the mechanics of tokens “morphing” from securities to non-securities. Therefore, until the SEC clarifies the point of “transformation,” other token issuers considering a Reg A token distribution will face similar uncertainty as to the status of their tokens as securities. Hiro’s Offering Circular also acknowledged the limitations on the secondary market for registered tokens, noting that “there may not be a trading market available for the Stacks Tokens, or any digital token exchange on which holders of Stacks Tokens may transfer or resell their Stacks Tokens… As a result, the tokens may initially only be traded on very limited range of venues, including US registered exchanges or regulated alternative trading systems for which a Form ATS has been properly submitted to the SEC.” The disclosure continues by noting that “As far as we are aware, there are currently no national securities exchanges or exchanges that have been approved by the \[FINRA\] or registered under Form ATS with the SEC… to support the trading of Stacks Tokens on the secondary market.” ### YouNow - Props Also in July 2019, just a few days after the qualification of Hiro’s Reg A offering, the SEC qualified the Reg A [Offering Circular](https://www.sec.gov/Archives/edgar/data/1725129/000162827919000254/younow1-aa2a.htm) of YouNow, Inc. (“YouNow”), which allowed the company to distribute up to $50 million worth of Props Tokens (“Props”) as part of its loyalty rewards program. Despite [reportedly](https://techcrunch.com/2019/07/11/props-reg-a-token/) spending over 2 years working with the SEC to get the Props offering qualified, in August 2021, YouNow [announced](https://blog.propsproject.com/a-letter-from-our-ceo-1332f6cabab1) that “given the regulatory constraints” they no longer had a “viable future.” In particular, YouNow pointed to its obligation to update disclosures on an ongoing basis and the lack of a secondary market for its tokens as the reasons it was shutting down, explaining that: “Props Tokens’ status as qualified securities significantly limits our ability to respond to changing market conditions in a commercially feasible manner. The Reg A+ continuous offering environment in which we operate requires us to make public filings and often get prior regulatory approval for product changes. As a result, we are unable to follow anything remotely like proper product development of “launch, measure, iterate” and struggle to launch new key functionalities we develop (like staking or per-app tokens). In addition, although we submitted to the regulation of Props Tokens as qualified securities, no U.S. exchange has been able to list crypto assets such as the Props Token, which has hindered holders wishing to trade them.” According to YouNow, these regulatory restrictions meant that the company had “not been able to develop Props Tokens in ways that could lead to commercial success, and there is no reasonable prospect of that happening in the future, given the regulatory framework.”As [described](https://www.coindesk.com/markets/2021/08/17/props-shutdown-throws-reg-a-funding-model-into-limbo/) by CoinDesk at the time, “The news certainly puts a damper on the viability of Reg A for token founders looking to build the next-generation web powered by crypto. ### Ceres Since the SEC’s qualification of Hiro and YouNow in the summer of 2019, there has only been one other Reg A token offering qualified by the SEC. After responding to elevent rounds of SEC comment letters and amending their [Offering Circular](https://www.sec.gov/Archives/edgar/data/1734118/000121465921002650/partiiandiii.htm) five times over a period of over two years, Ceres Coin LLC (“CERES”) had its Reg A offering qualified on March, 2021. [^16] As described in its Offering Circular, CERES intends to develop a private blockchain to enables participants in the cannabis industry to transact more efficiently. However, the company has yet to finalize the development of the private blockchain or issue any tokens and has to date recorded no revenue. ## 5. The History of Attempted Registrations Show it is Not Currently a Viable Path Recounting the history of crypto projects that have tried to register their tokens with the SEC is like taking a walk through a cemetery. As we have shown in the case studies above, the projects that attempted to come into compliance with the SEC’s registration requirements expended great effort and resources yet ultimately most of them failed, and those that persist do so in a state of uncertainty and comparative disadvantage. The failure of projects that have attempted to register is due in large part to the SEC’s reluctance to provide a workable framework through rulemaking, exemptive relief, guidance and industry engagement. Instead, the agency’s preferred approach has been to engage in a highly publicized campaign of regulation by enforcement. A prime example of the agency’s dangerous approach to the industry is their recent decision to [threaten Coinbase](https://www.coinbase.com/blog/we-asked-the-sec-for-reasonable-crypto-rules-for-americans-we-got-legal) with a wells notice, reportedly over the exchange’s failure to register. The SEC chose to take this path despite Coinbase repeatedly asking for clarity on *how* it could register, including by filing a public [rulemaking petition](https://www.sec.gov/rules/petitions/2022/petn4-789.pdf) and meeting with the staff over 30 times in the preceding nine months. In the forthcoming Part III of this series, we will further analyze why the applicable disclosure regime is not fit for purpose when applied to crypto, focusing on Form S-1. Part IV will then underscore how the SEC’s current position represents in practice a ban of the industry that exceeds the agency’s authority. Special thanks to Mike Selig for his review. [^1]: Chair Gensler has acknowledged that “We’re not a merit-based regulator primarily, we’re primarily a disclosure-based regulator and that’s the basic bargain. The public gets to decide what risk they want to take.” See A Fireside Chat with SEC Chair Gary Gensler [^2]: We believe most token offerings would not qualify as securities offerings and in the event that they do, the “investment contract” transaction should not be confused with the token, which is the underlying object of that transaction. See Lewis Cohen et at, The Ineluctable Modality of Securities Law: Why Fungible Crypto Assets Are not Securities, as well as our amicus briefs in the Ripple and Wahi cases [^3]: Reg. A offerings are technically not a registered, but an exempted, offerings. However, we include them in our analysis as they are an alternative path to offering tokens to the public [^4]: In a Regulation Crowdfunding offering, issuers will only be able to issue up to $5m worth of tokens in a twelve month period [^5]: The issuer will have limited ability to make “offers” before the registration statement is effective [^6]: $10 million of assets and has at least 500 non-accredited or 2,000 total holders of record of those equity securities [^7]: Projects that qualify an offering under Reg. A will be exempt from 1934 Act reporting requirements so long as they comply with Reg. A’s own reporting requirements, which are a similar but streamlined version [^8]: Securities issued as Reg CF offerings must trade on Crowdfunding Platform [^9]: We are limiting our discussion to crypto-native tokens that have attempted to register and not discussing the registration tokenized securities such as the INX Token or certain tokenized funds, as those offerings raise different issues [^10]: Importantly, none of the charges included allegations of fraud [^11]: See, e.g., the SEC’s settlement with Block.one, which raised $4.1 billion, which is orders of magnitude more than the ICO issuers that were required to register [^12]: Specifically, the Gladius order noted: “If Respondent plans to file a Form 15 to terminate its registration pursuant to Rule 12g-4 under the Securities Exchange Act of 1934 on the grounds that the GLA Token no longer constitutes a “class of securities” under Rule 12g-4 because the GLA Token is no longer a “security” under Section 3(a)(10) of the 1934 Act, Respondent will notify the Commission staff at least thirty (30) days prior to such filing. Upon such notification, the Commission staff may make reasonable requests for further information, and Respondent agrees to provide such information, as applicable" [^13]: There are two “tiers” of Reg A offerings: Tier 1, which is capped at $20 million in a 12-month period; and Tier 2, which is capped at $75 million in a 12-month period. Amongst other differences, issuers in Tier 2 offerings are not required to register or qualify their offerings with state securities regulators, which can provide meaningful relief for projects looking to offer their tokens to all Americans [^14]: A WSJ article at the time framed it in these terms: “The Securities and Exchange Commission on Wednesday cleared blockchain startup [Hiro [^15]: Hiro is no longer in the position of providing, and will no longer be able to provide, essential managerial services to the Stacks Blockchain. Management concluded further that if Hiro is no longer in the position of providing, and will no longer be able to provide, essential managerial services to the Stacks Blockchain, then it is no longer necessary for Hiro to treat the Stacks Tokens as investment contracts that are securities under the federal securities laws [^16]: Chair Gensler’s nomination was pending before the full Senate in March 2021, and he was confirmed by the Senate in April 2021. While there is only one SEC Chair at a time, Acting Chairs traditionally keep nominees for SEC Chair abreast of key decisions leading up to their confirmation and avoid taking major actions without the tacit approval of the incoming Chair ## https://www.paradigm.xyz/writing/secs-path-to-registration-part-i # Due to SEC Inaction, Registration is Not a Viable Path for Crypto Projects > SEC Chair Gary Gensler would like the American public to believe that it is just as simple and easy for crypto founders to register tokens or crypto products with the SEC. It’s not. See Part II [here](/2023/03/secs-path-to-registration-part-ii). See Part III [here](/2023/04/secs-path-to-registration-part-iii ). Getting a startup off the ground involves preparing and filing a lot of documents and forms, most of which are relatively easy and straightforward. For example, a founder will have to file a certificate of incorporation with the Secretary of State’s office in order to form a new corporation. They will also need to file Form SS-4 with the IRS in order to get an employee identification number (EIN). While many founders work with lawyers on this process, it’s simple enough that they could do it themselves. As a result, thousands of U.S. small businesses are formed each day. SEC Chair Gary Gensler would like the American public to believe that it is just as simple and easy for crypto founders to register tokens or crypto products with the SEC. **It’s not.** Yet in a recent nationally televised [interview](https://www.cnbc.com/2023/02/10/first-on-cnbc-cnbc-transcript-sec-chair-gary-gensler-speaks-with-cnbcs-squawk-box-today.html), Gensler admonished crypto exchange Kraken over the company’s failure to register its staking product, which resulted in a [settlement](https://www.sec.gov/news/press-release/2023-25) with the SEC pursuant to which Kraken had to pay damages and shut down the program. “These firms, Kraken knew how to register. Others know how to register, it’s just a form on our website,” he said, without providing further detail. “They know how to do it. They are just choosing not to do it,” he added later on. Gensler elaborated on his message in an [opinion piece](https://thehill.com/opinion/congress-blog/3891970-getting-crypto-firms-to-do-their-work-within-the-bounds-of-the-law/) a few days following, lamenting that “Frankly, though, crypto intermediaries aren’t exactly lining up to register with the SEC and comply with the laws enacted by Congress. Maybe it’s simply that their business models rely on being noncompliant.” And yesterday, after years of failing to provide guidance or regulatory certainty to Coinbase, the SEC [sent](https://www.coinbase.com/blog/we-asked-the-sec-for-reasonable-crypto-rules-for-americans-we-got-legal) the Company a Wells notice. According to Coinbase, the SEC threatened the company for listing tokens it considered securities (but it won’t say which ones) without registering as a securities exchange and offering an unregistered staking product (but it won’t say how to register). Chair Gensler’s public comments and actions are self-serving in two ways: they attempt to justify an unconstitutional expansion of the SEC’s jurisdiction over crypto by wrongly implying that most crypto products and tokens are securities and should therefore register with the SEC, while also painting the crypto industry as composed of willful lawbreakers who actively chose not to follow simple rules and, like boundary pushing toddlers, are deserving of punishment by the SEC. Yet, even putting aside the question of whether securities laws apply in the first place, the “forms” representing the “clear” path for crypto projects to “comply” cannot be completed on Legal Zoom or DIY’ed with free online resources. For example, Form S-1, which is used by the most mature private companies when they want to go public or conduct an “IPO,” typically takes an army of lawyers and millions of dollars to [complete](https://www.pwc.com/us/en/services/consulting/deals/library/cost-of-an-ipo.html). [Here](https://www.sec.gov/files/forms-1.pdf) it is: try making sense of it yourself. In fairness to the Chair, he never explicitly said that filing a registration form would be easy or cheap. But his suggestion that crypto companies can register by “filling out a form online” fails for a much more straightforward reason: until the SEC adapts the registration framework to the unique aspects of digital assets, it is impossible to “come in and register.” The current registration forms rely on a set of disclosures that are inadequate for crypto’s unique aspects and leave investors vulnerable. Registration also entails a host of additional regulations for the token, the reporting company, and other participants in the ecosystem that makes the functioning of most crypto protocols impossible. Indeed, the reason there are virtually no registered token offerings in the US is because the SEC has failed to provide any actionable guidance, issue a single rule or constructively engage with anyone in the crypto industry to provide a workable regulatory framework for security tokens. The example of Coinbase is illustrative. An SEC registered company itself, Coinbase submitted a [rulemaking petition](https://www.sec.gov/rules/petitions/2022/petn4-789.pdf) to the SEC in summer of 2022 that asked for clarity regarding many unresolved issues needed for a functioning market in digital assets, including registration as an exchange and staking. That petition went unanswered. Instead, yesterday the SEC continued its pattern of regulation by enforcement by sending Coinbase a Wells notice covering activities the company was actively seeking clarity on through their public rulemaking. The claim that crypto projects can “just come in and register” with the SEC today is a fabrication - much more is needed from them if the SEC genuinely wants to provide appropriate investor protection in the crypto asset space. Our hope is that building consensus on the viability of crypto projects registering with the SEC under the current regime can spur a true, honest discussion about how this industry should be regulated, with Capitol Hill as the locus of engagement. That, and only that, offers the crypto industry, crypto skeptics, policymakers, interest groups, and the American public a path to addressing/regulating crypto. [Part II](https://www.paradigm.xyz/2023/03/secs-path-to-registration-part-ii) starts with a general background on the SEC registration process and then reviews the history of the crypto projects that have attempted to register, either as part of an SEC settlement or on their own accord. Understanding the struggles and resulting failures of the majority of these projects illustrates how the “path to registration” is not currently a viable one. [Part III ](https://www.paradigm.xyz/2023/04/secs-path-to-registration-part-iii)will analyze the current SEC disclosure regime by focusing on Form S-1. We will argue that the current disclosure framework is fundamentally misaligned with most tokens, as it presumes an issuer-security relationship that does not exist in decentralized systems. We will discuss various gaps in the disclosures required by the form and places where clarity is needed to make registration a viable path and adequately inform investors. Finally, Part IV will underscore how the SEC’s current position, which claims most crypto projects need to be registered, while at the same time making the registration impossible, amounts to a regulatory ban of crypto which exceeds the SEC’s authority. Special thanks to Mike Selig for his review. ## https://www.paradigm.xyz/writing/paradigm-files-amicus-brief-in-sec-vs-wahi # Paradigm Files Amicus Brief in SEC vs Wahi > Paradigm filed an amicus brief in SEC vs. Wahi that rejects the SEC’s expansive and unsupported application of securities laws to crypto secondary markets. **TLDR:** Paradigm filed an [amicus brief](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-2fdc1048e4/b2d1b7f23eeaf6247d1b5c7d72285969/asset-https-cdn-sanity-io-files-dgybcd83-p-2fdc1048e4.pdf) in SEC vs. Wahi that rejects the SEC’s expansive and unsupported application of securities laws to crypto secondary markets. In *Wahi*, the SEC is attempting to claim jurisdiction over the defendants’ secondary trading of nine tokens by alleging that the “crypto assets were investment contracts.” This is wrong on the facts and the law. To begin, the tokens themselves do not provide the holder with any legal right or interest in a third party, as is evident from a review of the [annotated smart contract code](https://policy.paradigm.xyz/assets/writing/Paradigm-SEC-Wahi-Amicus-Exhibit-1.pdf) we included in our amicus brief. Therefore, other than potentially being sold as part of “investment contract” transactions under *Howey*, the tokens themselves cannot be said to qualify as any type of security under the Securities Acts. Further, to correctly analyze the Defendants’ transactions as “investment contracts” under *Howey*, the SEC would need to show how each transaction met all four prongs of the *Howey* test *at the time they occurred* – something that the SEC fails to do. Instead, the SEC alleges that the tokens were initially sold in fundraising schemes and then claims these fundraising schemes are “ongoing,” somehow resulting in the defendant’s secondary market transactions in the tokens being securities transactions. The SEC’s fundamental misunderstanding is their belief that because the tokens were initially sold in transactions that may have been investment contracts, the tokens themselves became – or “embody” – the investment contracts. However, this is not how *Howey* has been applied over its 75-year history. Not once, not ever. The catch-all concept in the definitions of “security” in the Securities Acts, “investment contract”, has been flexibly applied to bring fundraising transactions that elevate form over substance within the ambit of the federal securities laws. However, the concept of “investment contract” has never been extended to apply to parties not involved in those fundraising transactions, for good reason. Rather than focusing its enforcement efforts on promoters that are raising capital using tokens, the SEC instead seeks to apply the Securities Acts to the defendants, who are third-party purchasers of the tokens. This unsupported expansion of the Securities Acts shifts the burden of compliance from the persons who may have sold non-security assets to raise funds for a business without SEC registration to the third-party owners of these assets – the very persons the Securities Acts are intended to protect. Paradigm will keep fighting the Commission’s disregard for due process and existing precedent. If you have ideas for matters we should get involved in, please reach out. ## https://www.paradigm.xyz/writing/ethics-rules-government-use-of-crypto # You Can't Regulate What You Can't Understand: The Case for Modernizing Government Ethics Rules > Ethics rules effectively bar most government employees from owning crypto. Imagine designing an FAA safety protocol without ever seeing a plane, or legislating lightbulb efficiency without ever flipping a switch. It may be possible, but it certainly won’t yield sensible policy. The internet defined the past few decades of innovation, and we believe crypto will define the next few decades. This means that drafting good regulation — regulation that doesn’t stifle or drive development overseas — is among the most critical issues for American policymakers today. But to truly understand crypto, it’s almost mandatory to actually use it. ## The Rules The tl;dr is that ethics rules effectively bar most government employees from owning crypto. Here’s a breakdown for employees in Congress and key agencies. The link to the chart is available [here](https://ethicsrules.policy.paradigm.xyz/). ## Key Takeaways - Disclosure rules, while comprehensive, are burdensome. In recognition of these onerous requirements, some exemptions exist for de minimis ownership of some assets. But the Office of Government Ethics — which prevents conflicts within the Executive Branch — last August issued a Legal Advisory noting that cryptocurrency and stablecoins do not benefit from a de minimis exemption. (OGE LA-22-04). Owning crypto, when otherwise !!!permitted, could trigger recusal obligations for agency employees unless a waiver applies. (*See e.g.*, 18 U.S.C. § 208(a)). - SEC employees are prohibited from owning any crypto regulated by the agency as a security, unless they are precleared to trade. (5 C.F.R. § 4401.102). Due to a myriad of jurisdictional and regulatory issues, we do not yet know which assets are securities. So this diktat serves as a blanket ban on owning all crypto, to the detriment of an agency that wants its staff to gain expertise. - The CFTC’s primary statute and regulations broadly ban participation by CFTC employees in certain transactions of commodities. (7 U.S.C. § 13(c) and 17 C.F.R. § 140.735-2). - Federal Reserve leadership and certain staff are prohibited from owning or controlling cryptocurrency, either directly or through targeted investment funds. (Federal Reserve, “Federal Open Market Committee—Investment and Trading Policy for FOMC Officials,” (eff. May 1, 2022)). - Rules regulating Congressional members are vague; for example, House rules prohibit Members from using confidential information as a means “for making private profit,” but give little guidance on the scope of the phrase. (Code of Ethics for Government Service at ¶ 8). Rules instead grant discretion to Ethics Committees that are criticized for [erratic enforcement](https://www.businessinsider.com/congress-stock-act-violations-penalties-consequences-2021-12). - House and Senate members are prohibited from voting on questions which affect their pecuniary interest as part of a limited class. Senate Rules require Committee staffers to divest “substantial holdings” unless given permission to retain holdings. (Senate Rule 37.7). ## Rules Should Not Ban Experimentation with Crypto The origin of these rules was principled and well-intentioned; in the wake of Watergate and other scandals that rocked public trust in government, [the U.S. passed the Ethics in Government Act of 1978](https://oge.gov/Web/oge.nsf/Resources/35th+Anniversary+of+the+Ethics+in+Government+Act) to fight corruption and require senior employees of the executive branch to submit public financial disclosures. The goal was admirable; no one condones government insider trading or policymakers that fail to prioritize the public’s interest. But unlike other types of regulated technology, ethics rules as applied to crypto effectively *prohibit all use* by government employees. While crypto ownership by policymakers requires ethical boundaries, the rules should be modernized in order to empower government employees to develop good policies. This is particularly critical given: - **Following developments in crypto is uniquely difficult**. The speed of innovation in crypto is breakneck, and keeping pace with new developments requires consistent engagement. Interacting with the technology is key to understanding it. - **Crypto is new.** Unfortunately, crypto technology is *so* new that most policymakers did not have the opportunity to use Coinbase, OpenSea, or Uniswap prior to taking office. It differs from other types of technology in this way, creating a more significant learning gap once a staffer is bound by ethics prohibitions. - **Blockchain technology is inherently financialized, which unnecessarily triggers ethics rules that don’t exist in traditional tech**. Many crypto use cases incorporate a financial component that triggers ethics rules, regardless of the number of pennies involved in a transaction. While using Google does not require owning a share of Google, utilizing almost any crypto service requires holding or transacting with a satoshi, wei, or other de minimis equivalent. As a result, these activities are effectively barred by the ethics rules at key agencies like the SEC, CFTC, and Federal Reserve. To make good crypto policy, government employees need modernized ethics rules. We propose the following common sense boundaries: - **Threshold.** For restricted policymakers, we propose an exemption to ethics rules that permits ownership of cryptocurrency under a threshold amount. Each covered policymaker’s wallet’s total portfolio value in USD must not exceed a certain dollar amount (*e.g.*, $1,000). Any holdings above this threshold must be divested or placed into a blind trust. To account for outsized volatility or transaction fees, this value can also be indexed to particular metrics including inflation or gas fees (*e.g.*, $1,000 + ([Ethereum Average Gas Price](https://ycharts.com/indicators/ethereum_average_gas_price#:~:text=Ethereum%20Average%20Gas%20Price%20is,68.40%25%20from%20one%20year%20ago.) x 120) which would consider gas for ten transactions per month), calculated, and announced periodically. - **Disclosure.** Existing rules require policymakers to disclose all assets with a value exceeding $1,000 on annual personal financial disclosures. (*See e.g.*, House rule 5 U.S.C. app. §§ 101, 102). [^1] In addition, key policymakers must periodically report throughout the year any transaction exceeding $1,000. [^2] While these rules should be harmonized with our proposal, they demonstrate that robust disclosure rules already exist to ensure policymaker accountability. - **Governance Activity.** Policymakers with wallets holding governance tokens of DAOs should be prohibited from submitting, voting, or exercising related rights on governance proposals that create a conflict. These voting and governance rights can be delegated or assigned to a non-profit or educational institution. - **Enforcement.** Like any other ethics rule, violation of any crypto ownership rules would accrue liability. To make good crypto policy, government employees need modernized ethics rules. We also urge key policymakers to dedicate resources toward establishing a research or experimental wallet for their offices. Combined, these innovations could produce new understanding, better lawmaking, and a thriving American crypto economy. *Acknowledgements: *[*John Heinemann*](https://www.paradigm.xyz/team/johnheinemann)*, *[*Dominique Little*](https://www.paradigm.xyz/team/dominiquelittle)*, *[*Brendan Malone*](https://www.paradigm.xyz/team/brendanmalone)*, *[*Rodrigo Seira*](https://www.paradigm.xyz/team/rodrigoseira)*, and *[*Justin Slaughter*](https://www.paradigm.xyz/team/justinslaughter)*, Anne Kelley (Mercury Strategies), Langston Emerson (Mindset), and Charlie Schreiber (Mindset).* [^1]: See Committee on Ethics, “Specific Disclosure Requirements,” U.S. House of Representatives, (last visited, Jan. 6, 2023), available here [^2]: Stop Trading on Congressional Knowledge (“STOCK”) Act of 2012, Pub. L. 112–105, available here ## https://www.paradigm.xyz/writing/using-on-chain-data-for-policy-research-part-3 # Using On-Chain Data for Policy Research, Part 3: Mint/Burn Dashboard > Today, fiat-backed stablecoins are an important part of the crypto ecosystem and looking closely at on-chain data can surface issues that lead to better-designed stablecoins. Rather than write an academic-style report, our approach here is to make available a clean data set and deliver an interactive data dashboard to encourage more individual use and exploration of on-chain activity. ## Introduction The purpose of this series has been to demonstrate how on-chain data can be used to probe important policy issues in crypto. Today, fiat-backed stablecoins are an important part of the crypto ecosystem and looking closely at on-chain data can surface issues that lead to better-designed stablecoins. Rather than write an academic-style report, our approach here is to make available a clean data set and deliver an interactive data [dashboard](https://mint-burn.policy.paradigm.xyz/) to encourage more individual use and exploration of on-chain activity. ## Informal Observations - For most stablecoins and time periods, the majority of mint/burn activity takes place during times when U.S. markets are open (e.g., Monday through Friday, between 9am and 5pm ET). Despite the fact that tokens can circulate 24/7 on-chain, the on- and off-ramps are still very dependent on core legacy financial infrastructures, which come with their own risks and inefficiencies. (These issues are discussed at length in a [previous post](https://paradigm.xyz/writing/2022/10/using-on-chain-data-for-policy-research-part-1).) - Although the majority of on-chain minting/burning occurs during U.S.-market hours, most stablecoins maintain the ability to issue when markets are closed (e.g., overnight and on the weekends). One conjecture from this observation is that stablecoin issuers manage buffers of cash that they use to mint or burn coins when they receive requests from customers during off-hours when reserve collateral cannot be invested or sold. Otherwise, they would only be able to mint or burn stablecoins during certain times of day/week. How they size such buffers is likely to be an important focal area for policymakers and risk managers in the future. - The stablecoins included vary widely in their minting/burning practices, both in terms of size and frequency. - Times of heightened volatility are evident in the data. For example, during May 2022 when the Terra/Luna peg broke. ## Notes The clean data and the code used to generate it are available [here](https://github.com/brendanpmalone/onchain_data_blog/tree/main/code/dash%20app/data) and [here](https://github.com/brendanpmalone/onchain_data_blog/blob/main/code/stables_mb_clean.py). The code used to create the interactive dashboard is available [here](https://github.com/brendanpmalone/onchain_data_blog/tree/main/code/dash%20app). - As noted previously, it is important to keep in mind that on-chain data only represents a portion of total stablecoin activity. - Additionally, the data used in this project only show a subset of stablecoins on one blockchain during one time period. Looking at more L1s and a broader set of stablecoins (including decentralized stablecoins) may be necessary for more in-depth analyses. ## https://www.paradigm.xyz/writing/using-on-chain-data-for-policy-research-part-2 # Using On-Chain Data for Policy Research, Part 2: Stablecoin Risk Rundown > The first post in this series provided an overview of one of the many ways to access on-chain data for use in policy research. This piece builds on that work by introducing a set of policy issues relevant to stablecoins, including what can and can't be probed using on-chain data. It also covers a few practical steps related to data cleaning. It is intended for policy professionals operating at the academic-practitioner frontier. ## 1. Introduction The [first post](https://paradigm.xyz/writing/2022/10/using-on-chain-data-for-policy-research-part-1) in this series provided an overview of one of the many ways to access on-chain data for use in policy research. This piece builds on that work by introducing a set of policy issues relevant to stablecoins, including what can and can’t be probed using on-chain data. It also covers a few practical steps related to data cleaning. It is intended for policy professionals operating at the academic-practitioner frontier. ## 2. Framing the policy space ### 2.1 Risk overview Fiat-backed stablecoins act as bridges between fiat and crypto. As with intra-crypto bridges, they play a crucial role in supporting the fluid movement of assets across the ecosystem today. But they can also concentrate financial and operational risk depending on their design. Accordingly, policymakers are worried about stablecoins. Within the past few years, there have been a number of [speeches](https://www.federalreserve.gov/newsevents/speech/waller20211117a.htm), [recommendations](https://home.treasury.gov/system/files/136/StableCoinReport_Nov1_508.pdf), and [proposed laws](https://www.banking.senate.gov/imo/media/doc/the_stablecoin_trust_act.pdf) or regulations targeting the perceived risks associated with fiat-backed stablecoins. A lot of the risks concern the speed and reliability of converting between stablecoins and commercial bank deposits, and the broader impact on the financial system if things go awry. For example, if fiat-backed stablecoins are perceived as “safer” than commercial bank deposits, there could be *runs into stablecoins* during times of stress as people sell their bank deposits to buy stablecoins. [^1] This could cause instability as bank funding (*i.e.*, customer deposits that the banks use to make loans) is drawn down. On the flip side, if people are concerned about the stablecoin’s solvency, there could be mass redemptions — *runs out of stablecoins* — that are operationally destabilizing to the stablecoin and could affect collateral prices in the extreme. Additionally, regulators have raised concerns about traditional payment system risks, such as liquidity and operational risk. For instance, what happens if time-critical payments must be made with stablecoins, but the payor does not have any and the mechanisms for converting fiat to stablecoins are temporarily unavailable? This could happen off-hours when the traditional payment systems that serve as on- and off-ramps are closed. The failure of time-critical payments due to liquidity shortfalls or operational issues can transform into other risks and threaten solvency and financial stability. **Designing safe fiat-backed stablecoins means grappling with these challenges. This is something the largest fiat-backed stablecoins have been doing since launch, in a less-than perfect environment, with little regulatory clarity or access to some of the traditional safeguards that benefit and buttress incumbents.** ### 2.2 Structural mechanics When a customer purchases a fiat-backed stablecoin, one of two things usually happen: (A) an existing stablecoin is transferred to the customer, or (B) a new stablecoin is first created and *then* transferred to the end-user. Both scenarios are interesting, but scenario (B) is most illustrative for thinking about risks. What happens when $5 of stablecoins are created? The exact steps vary from stablecoin to stablecoin, but the following steps should occur in theory: 1. Customer A instructs their bank to transfer $5 to the Stablecoin Issuer’s bank. 2. Upon receipt of funds, Stablecoin Issuer purchases collateral to back issuance. 3. When collateral purchase settles, Stablecoin Issuer mints $5 of stablecoins and transfers them to Customer A. In a perfect world, the three steps would happen sequentially, with limited latency between them, and conditionally, such that a step happens *if and only if* the other two happen. In the real world, that is not always possible. Steps 1 and 2 rely largely on legacy financial infrastructures, such as ACH and card networks or the market for U.S. Treasuries. Step 3 relies on the issuer’s internal systems and the blockchain on which the stablecoins are minted. Here, there is a mismatch in control and operational resiliency and efficiency, which is a thorny risk vector for the issuer to have to manage. The [pain points](https://www.federalreserve.gov/newsevents/pressreleases/files/other20170906a1.pdf) in U.S. retail payments are well-documented. Until the U.S. has ubiquitous, reliable real-time payments, retail payments often settle with a lag that often lasts multiple days. This is in part due to technological factors, but also because of structural and regulatory reasons. Today’s financial system [bundles](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3776739) banking, money, and payments and creates dramatic inefficiencies for consumers and a windfall for large banks. Fiat-backed stablecoins present an opportunity to introduce innovation and competition to the retail payments landscape, but today they sit atop a fragmented system that has significant drawbacks. *If a customer pays an issuer in exchange for stablecoins (Step 1), when will the issuer receive the funds, and what happens if the funds-transfer does not occur as planned?* There are also difficulties on the collateral side of the equation. Risk-free assets are not always easy to come by. Most stablecoin issuers today claim to back issuance with cash or cash-like equivalents, such as short-duration Treasury Bills. While Treasury securities are close to risk-less from a market risk perspective, the Treasury market has had its own share of [issues](https://www.brookings.edu/wp-content/uploads/2020/05/WP62_Duffie_v2.pdf) due to structural factors that affect market liquidity and operational problems caused in part by outdated technology systems. [^2] Not to mention the fact that the market settles in T+2, creating a lag between when a collateral purchase is executed by the stablecoin issuer and when the issuer becomes the legal owner of the collateral. *If a stablecoin issuer attempts to purchase collateral to back issuance, will the market be open and functioning with enough liquidity to support the purchase?* In theory, these problems could be mitigated in part if issuers of fiat-backed stablecoins were allowed to have [master accounts](https://crsreports.congress.gov/product/pdf/IN/IN12031) at the Federal Reserve, which is not possible for most nonbanks in the U.S. today. [^3] Another option would be to allow or encourage stablecoins to be backed by some form of on-chain collateral, which could take the shape of a tokenized high-quality liquid assets (“HQLA”) that can be traded and settled 24/7 using an automated market maker (“AMM”), or another on-chain asset with appropriate safeguards for mitigating market risk and volatility. **Given the real challenges they face, how are stablecoins currently managing risk vis-à-vis inflows and outflows? And what can we glean from the concerns raised by policymakers?** ## 3. Data considerations ### 3.1 The power of open data A great advantage of public blockchains is their openness. This means that stablecoins that exist on public blockchains can be used by other projects or services without any special configuration or approval by the stablecoin issuer. It also means that stablecoin transactions are publicly visible, giving an unprecedented degree of transparency to payments activity on public blockchains. When someone transfers money to their Venmo account, Venmo keeps that information in a proprietary database — and restricts access. Users implicitly delegate control of their funds to Venmo in the process, and external services have to comply with Venmo’s access policy if they want their services to interoperate with the Venmo payment rail. In addition, regulators have almost zero real-time insight into such proprietary recordkeeping systems. By comparison, the simple query at the end of the [first post](https://paradigm.xyz/writing/2022/10/using-on-chain-data-for-policy-research-part-1) is an openly-accessible way to read the records in the public stablecoin database. It extracts data on *all* on-chain events for the stablecoins in scope. That includes minting and burning activity, which gives a real-time snapshot of stablecoin supply and demand, something that is not currently available from any traditional provider of money and banking services. It also includes transfer activity, which shows how the stablecoins in question are being used with other open, permissionless protocols. The current web payments tech stack is a collection of black boxes and proprietary systems that does not offer anywhere near this level of granularity and transparency. [Here](https://github.com/brendanpmalone/onchain_data_blog/blob/main/stablecoins_raw_2022-06-16.csv) is a CSV that shows all of the raw data for June 16, 2022. [^4] **It cannot be understated how valuable this information is, both as a barometer of economic activity and a mechanism for monitoring and containing risk in the financial system.** ### 3.2 Data cleaning and prep for analysis The scope of this particular tutorial is limited to minting and burning activity as it is the simplest base case for analysis. [^5] After running the query and parsing the *topics* column into separate fields for *topic0*, *topic1*, and *topic2*, a few additional steps are helpful to get the data ready for inspection. This [Jupyter Notebook](https://github.com/brendanpmalone/onchain_data_blog/blob/main/code/onchain_data_mb_clean_example.ipynb) shows each step in turn. First, it is helpful to replace the information in *topic0* — which, recall, is the hash of the function signature — with a human-readable description (*i.e.*, “mint” or “burn”), depending on the function hash referenced by *topic0*. [samczsun](https://twitter.com/samczsun) created a [helpful tool](https://sig.eth.samczsun.com/) for looking up signatures. There is some variation among the five stablecoins with respect to how function names map to the actual act of minting/burning activity, which needs to be accounted for. The tables below provide the mappings, for ease of use. [^6] ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--04e9a2c70f/73265a92f04db9345870364fe7337221/asset-https-cdn-sanity-io-images-dgybcd83--04e9a2c70f.png) When *topic1* and *topic2* include addresses, the fields contain extra padding in the form of leading zeros, which need to be removed before referencing against address records in other locations. Finally, the amounts in the *data* field need to be converted from [hexadecimal](https://en.wikipedia.org/wiki/Hexadecimal) to [decimal](https://en.wikipedia.org/wiki/Decimal) and scaled appropriately. ## 4. Concluding thoughts On-chain data provides only a snapshot into the lifecycle of stablecoins. For example, the minting and burning activity that is observable in the data is a crude measurement for total stablecoin activity, considering that it is not possible to see exactly how the stablecoin issuers are managing deposits and withdrawals — or any other activity that happens off-chain. Still, when compared with the traditional financial sector, the openness and transparency of public blockchains enables a new level of insight into stablecoin supply and demand. The next and final post in this series will use the data that was extracted and cleaned to generate graphs and run simple analyses. By combining the data with contextual information, we can begin to draw larger takeaways regarding the current functioning of the stablecoin ecosystem. With a better practical understanding of how the system works, including its fragilities, policymakers will be in a better position to create policies that encourage innovation and limit the downside risk of new technologies. [^1]: This is due to their guaranteed redemption at par, something that commercial bank deposits can only guarantee up to the FDIC deposit insurance threshold of $250,000 per insured account [^2]: There have been several notable disruptions to the Treasury market over the past 15 years, including a flash crash (2014), an operational outage (2019), and the dysfunction in the repo market (2019) [^3]: Direct access to a central bank account would let stablecoin issuers hold reserves as claims on the central bank, which carry zero credit risk. Thus, since there would be no need to further invest the collateral in fixed-income markets, reducing operational risk and principal risk. Additionally, central bank account access typically comes with access to the payments system, in the case of the U.S. the Fedwire Funds Service. Access to Fedwire Funds would provide additional efficiencies when users are transferring cash to the issuer [^4]: As this is the raw daily extract, the topics column has not yet been parsed into separate columns for topic0, topic1, and topic2 [^5]: As the transfer records show events that trigger additional smart contracts and not simple peer-to-peer transfers, interpreting them takes an additional level of care [^6]: Gemini Dollar has the same signature for both mints and burns, and when it is checked using samczsun’s tool it is mapped as a transfer, not a mint or burn. This is not a mistake. In the GCP data, Gemini mints/burns are logged as transfers. In the case of burns, the “to” address in topic2 is null; in the case of mints, the “from” address in topic1 is null ## https://www.paradigm.xyz/writing/eth-rng # Generating secure randomness on Ethereum using SNARKs > In this post, we propose designs and reference implementations that utilize SNARKs and VDFs to achieve fully secure randomness on Ethereum. # Introduction In this post, we propose designs and reference implementations that utilize SNARKs and VDFs to achieve **fully secure randomness on Ethereum**. Decentralized applications on Ethereum like [NFT mints](https://www.paradigm.xyz/2021/10/a-guide-to-designing-effective-nft-launches), lotteries, games, and more require secure randomness so their contracts are fair. State-of-the-art randomness services meet some of the requirements for secure randomness but still have flaws, such as cost, biasability, and liveness. **What makes randomness secure?** In order for a randomness source to be secure, it needs to have the following four properties: - **Unpredictable**: Random value can’t be anticipated. - **Unbiasable**: Actors contributing to randomness generation can’t meaningfully bias the result. - **Verifiable**: Any interested actor can verify the integrity of the random number’s generation. - **Live**: Randomness requests can be fulfilled at any future point in time without requiring any particular actor's participation, assuming the liveness of the base layer. Additionally, an ideal randomness source should be **inexpensive or free** for consumers in order to be useful. See our contributions in **bold** in the table below: ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--d8ccd3f693/31ea3b105b9e78cd85dc80011aae47d2/asset-https-cdn-sanity-io-images-dgybcd83--d8ccd3f693.png) # What has been done before? ## Using a Block's Hash Block hashes are a simple, zero-delay mechanism for retrieving pseudo-random values and are suitable for low-stakes environments, but are not secure. ```solidity // Use the previous block's hash as randomness. function coinflip() view external returns (bool) { return uint256(blockhash(block.number-1)) % 2 == 0; } ``` Historical block hashes are predictable since they’ve been publicly exposed to the entire network. If an attacker can predict the random value that will be used, they may be able to determine and manipulate the outcome of a specific situation, like the outcome of a randomized lottery. For this reason, secure randomness beacons commit to a future unknown value, like a future block hash, to ensure unpredictability. *For the remainder of this blog post, all randomness beacon constructions require committing to future, unknown values even when not stated explicitly.* The below unoptimized example demonstrates the concept of committing to a future block: ```solidity contract RandomnessProvider { /// Stores the block a request is committed to. mapping(bytes32 => uint256) public revealBlock; /// User requests randomness for a future block along with a request id. function commitRandomness(bytes32 _requestId, uint256 _revealBlock) external { require(_revealBlock > block.number, "Must commit to a future block"); require(revealBlock[_requestId] == 0, "Request already submitted"); revealBlock[_requestId] = _revealBlock; } /// Returns the blockhash of the block after checking that the request's target /// block has been reached. function fetchRandomness(bytes32 _requestId) public view returns (uint256) { bytes32 randomnessBlock = revealBlock[_requestId]; require(block.number > randomnessBlock, "Request not ready"); require(block.number <= randomnessBlock + 256, "Request expired"); return blockhash(randomnessBlock); } } ``` The above scheme is unpredictable and verifiable, but it is biasable because the block proposer for a given slot can directly manipulate the block’s hash by manipulating the block’s body. It also faces a liveness issue due to a limitation of the [`BLOCKHASH`](https://www.evm.codes/#40?fork=merge) opcode. The `BLOCKHASH` opcode only has access to the last 256 block hashes, which requires applications to use the committed block hash within a limited time range. ## Chainlink VRF Chainlink’s oracles provide unpredictable and verifiable random values on-chain using a Verifiable Random Function (originally proposed by [Micali et al,](https://people.csail.mit.edu/silvio/Selected%20Scientific%20Papers/Pseudo%20Randomness/Verifiable_Random_Functions.pdf) cryptography [ELI5](https://blog.chain.link/chainlink-vrf-on-chain-verifiable-randomness/)). However, biasability still exists because a Chainlink VRF operator could censor a request via omission if the generated randomness is unfavorable. The cost to bias can be increased by introducing [slashing](https://blog.chain.link/chainlink-staking-launch-details/) (to be deployed by Chainlink), but there still may exist a random value used in a system using the VRF which may make biasing a profitable strategy. Participation in the VRF operator set would ideally be permissionless, although that may also be addressed via staking/slashing. Separately, integrating with the Chainlink VRF would ideally be free/amortizable over many requests, whereas the current design incurs additional gas overheads and native fees to align the incentives of node operators. ## Beacon Chain RANDAO [RANDAO](https://eth2book.info/bellatrix/part2/building_blocks/randomness/) is an Ethereum-native pseudorandom value produced via a cryptoeconomic [commit-reveal](https://en.wikipedia.org/wiki/Commitment_scheme) game played by Ethereum’s block proposers. To explain in more detail, RANDAO is an accumulator that collects randomness from block proposers. In every block, a proposer includes a deterministic value known as the [`randao_reveal`](https://eth2book.info/bellatrix/part3/containers/blocks/#beaconblockbody) which represents their individual contribution to the overall RANDAO value. The new RANDAO value is determined by mixing the previous RANDAO value with the `randao_reveal` of the proposed block, which is showcased in the following code snippet. ```solidity def process_randao(state: BeaconState, body: BeaconBlockBody) -> None: epoch = get_current_epoch(state) # Verify RANDAO reveal proposer = state.validators[get_beacon_proposer_index(state)] signing_root = compute_signing_root(epoch, get_domain(state, DOMAIN_RANDAO)) assert bls.Verify(proposer.pubkey, signing_root, body.randao_reveal) # Mix in RANDAO reveal mix = xor(get_randao_mix(state, epoch), hash(body.randao_reveal)) state.randao_mixes[epoch % EPOCHS_PER_HISTORICAL_VECTOR] = mix ``` *Credit to* [*Ben Edgington*](https://twitter.com/benjaminion_xyz)*, code snippet taken from* [*here*](https://eth2book.info/bellatrix/part2/building_blocks/randomness/)*.* The `process_randao` function first verifies the `randao_reveal` before mixing it. The `randao_reveal` is designed to be deterministic, so block proposers cannot contribute arbitrary values that would bias the resulting RANDAO value. The `randao_reveal` for a slot must be the block proposer's signature of the epoch number for the slot they are assigned to, which commits them to a single, allowed contribution of randomness. If a block proposer creates a block with a different `randao_reveal`, that block is considered invalid and the value is not mixed. While block proposers cannot choose arbitrary `randao_reveal` values to bias the RANDAO, they can choose not to propose a block if the resulting RANDAO is unfavorable. In this case, the next block will be created by the next block proposer, which will result in a different RANDAO value due to the new block proposer's contribution of a different `randao_reveal`. This ability to omit a block gives block proposers the option to "reroll" a randomness result, which can be unfair. This is a form of bias through omission and is commonly referred to as [bits of influence](https://eth2book.info/bellatrix/part2/building_blocks/randomness/#randao-biasability) over the RANDAO. By combining RANDAO with the "commit-to-future-value" technique from the block hash example, we can create a source of randomness that is both unpredictable and verifiable while also eliminating the dependency on third-party networks like Chainlink. Additionally, this approach leads to a random value that is less susceptible to bias compared to simply using the block hash. However, it is important to note that using a future RANDAO alone is still prone to bias and presents a liveness issue. **Biasability** As previously mentioned, block proposers can choose to omit a block if the resulting RANDAO value is unfavorable. **Liveness** The RANDAO value can currently be accessed on the execution layer via the [`DIFFICULTY`](https://eips.ethereum.org/EIPS/eip-4399) opcode, which returns the RANDAO for only the block the transaction is being included in. ```solidity // Returns the RANDAO of the block this function is called in. // For example if a transaction calls this function and is included in // block 10 the RANDAO of block 10 is returned. function getRandomValue() internal returns (uint256) { return block.difficulty; } ``` This straightforward method of utilizing the RANDAO of a block directly eliminates the problem of liveness, as the RANDAO value will always be accessible. However, it still presents issues of predictability similar to those encountered when using historical block hashes. To address this predictability problem, we can commit to the RANDAO of a future block and reference it once the block is proposed and the RANDAO is made available. However, using a previously committed-to future RANDAO block introduces a liveness issue, because the `DIFFICULTY` opcode only returns the current RANDAO value. This **necessitates** a transaction to be included in the exact block that was previously committed to, which can be hard to guarantee and cannot be recovered if missed. # Can we do better ## Lifting The Same Block DIFFICULTY Opcode Constraint As previously mentioned, accessing the RANDAO through the `DIFFICULTY` opcode is not practical because transactions that consume randomness must be included in the same block they previously committed to. In this section, we will explore ways to overcome this constraint. One alternative method for accessing the RANDAO is through the `mixHash` field in a block header. A block header is a data structure that contains metadata about a block, such as its height (`number`), the hash of the previous block (`parentHash`), the RANDAO value (`mixHash`), and more. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--e890055dea/687305c0400936e81b4f94f6215de92b/asset-https-cdn-sanity-io-images-dgybcd83--e890055dea.png) Instead of relying on the `DIFFICULTY` opcode, we can create a construction that allows us to verify and reference historical RANDAO values by referencing historical block header data. To verify historical block header data, one can leverage the block hash of the relevant block. Block hashes act as commitments to the relevant block header data and are unique identifiers for a block. One can verify the integrity of a block and its contents using a block hash, as any changes to the block header data will result in a different block hash. To derive a block hash from a block header on Ethereum, you can: 1. Obtain the [block header data](https://medium.com/@eiki1212/ethereum-block-structure-explained-1893bb226bd6) for a specific block. 2. [RLP (Recursive Length Prefix) encode](https://ethereum.org/en/developers/docs/data-structures-and-encoding/rlp/) the block header data into a binary string. 3. Use Keccak256 to hash the RLP encoded block header and compute the block hash. Here's a sample function that attests to a historical RANDAO using a block header and its block hash: ```solidity function submitRANDAO(bytes memory rlpEncodedHeader) external { // Validate blockhash is a valid historical blockhash. bytes32 blockHash = keccak256(rlpEncodedHeader); if (!isValidHistoricalBlockhash(blockHash)) { revert BlockhashUnverified(blockHash); } // Decode RLP encoded block header. RLPReader.RLPItem[] memory ls = rlpEncodedHeader.toRlpItem().toList(); // Extract out mixhash (RANDAO) from block header. uint256 RANDAO = ls[13].toUint(); // Stores RANDAO value at this block number. blockNumToRANDAO[blockNum] = RANDAO; } ``` The function first hashes the inputted RLP encoded block header with Keccak256 and verifies that the computed block hash references a valid historical block. If this check were not in place, it would be possible to pass in a fake block header from the past and falsely attest to historical block header data. After validating the block header, the function then RLP decodes the encoded block header and stores the RANDAO value in storage for anyone to reference in the future. There are open-source Solidity libraries available for [RLP decoding](https://github.com/hamdiallam/Solidity-RLP) in smart contracts. However, verifying an arbitrary historical block hash as a real historical block hash on-chain is a more complex task. The simplest way to verify a historical block hash is the `BLOCKHASH` opcode which allows contracts to reference the most recent 256 block hashes. This allows us to attest to any block header data within the last 256 blocks and lifts the same block lookback limit presented by the `DIFFICULTY` opcode. While the `BLOCKHASH` opcode allows us to reference more RANDAO values than the `DIFFICULTY` opcode, it does not fully solve the issue of liveness during times of censorship or congestion. In such cases, transactions using the `BLOCKHASH` opcode may be included too far from the block for which they require a hash. To create a fully live randomness beacon, we need a construction that does not have a hard lookback limit of 256 blocks. In the remainder of this blog post, we refer to constructions that verify historical block hashes as “block hash oracles”. ## Lifting the 256 Block Hash Lookback Limit ### Block Hash Oracle Contract via BLOCKHASH Opcode One way to overcome the limited lookback range of the `BLOCKHASH` opcode is to create a contract specifically designed for storing historical block hashes while still using the `BLOCKHASH` opcode. This allows consumers to reference a wider range of historical block header data without significantly increasing complexity. ```solidity /// @notice Maps validated blockhashes to their block number. mapping(bytes32 => uint256) public blockhashToBlockNum; /// @notice Validates the block hash of the block before this tx is called. function poke() public { blockhashToBlockNum[blockhash(block.number - 1)] = blockNum; } /// @notice Validates the block hash of a specified block number using /// the blockhash opcode. The blockhash opcode is currently limited to /// 256 blocks in the past. /// @param blockNum Block number to validate. function pokeBlocknum(uint256 blockNum) public { bytes32 blockhashVal = blockhash(blockNum); if (blockhashVal == bytes32(0)) { revert PokeRangeError(); } blockhashToBlockNum[blockhashVal] = blockNum; } ``` With even just a single party fulfilling block hash requests, once they're stored in the contract any consumer can reference the value at any point in the future. However, the use of the `BLOCKHASH` opcode still imposes a limit on the number of blocks that can be referenced, making it possible for a requested block hash to miss its window and never be stored in the contract. As a result, this approach does not provide full liveness, even though it allows for greater access to block hashes. ### Block Hash Oracle Contract via SNARKs It is theoretically possible to reference blocks arbitrarily far back in history due to the inclusion of a reference to the parent block's hash in the block header. However, proving a historical block hash through sequential proofs of parent hashes grows linearly the further back in history you go, and can quickly become prohibitively expensive. One way to address this issue is to use SNARKs, which have the property of succinctness, to create a constant-sized proof for a historical block hash. Using these history proofs, it becomes feasible to create a fully live and robust block hash oracle. One example of a method for extending the `BLOCKHASH` opcode oracle is to create a SNARK that proves a merkle root represents a commitment of ordered block hashes that reference each other through the `parentHash` in their respective block's header, with the last block hash in the list being the most recent. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--e22528b42c/958f58df86538f66602f8ff56307953f/asset-https-cdn-sanity-io-images-dgybcd83--e22528b42c.png) A SNARK that proves the merkle root representing a valid, ordered list of block hashes can be generated by an off-chain prover and sent to a verifier smart contract. The contract then verifies the proof which ensures the merkle root matches the commitment scheme outlined above, and separately confirms that the last block hash in the list corresponds to an existing block hash that the contract has previously validated. Without anchoring the list to a previously validated block hash, it would be possible to attest to an arbitrary list of sequential block headers that does not accurately reflect the true state of Ethereum. If the proof and the last block in the list are confirmed to be valid, the contract cements the merkle root of block hashes in storage. Using this construction, any RANDAO value in the covered range can be fulfilled. With this method, we can conservatively attest to ~1024 block hashes (`n=10`) within a single proof, with potential to do more as proving systems continue to mature. We can feasibly look arbitrarily far back in history by repeating this process until we cover the range we want to access. Assuming these components are open sourced, any actor can plausibly keep the system live by generating and submitting a proof for large intervals of block headers. We now have a SNARK powered block hash oracle with strong liveness guarantees, but there’s still the issue of RANDAO's biasability. We address solutions in the next section. ## Removing bias with VDFs As seen in the `process_randao` code snippet above, calculating a new RANDAO value is essentially just an xor operation. RANDAO can be biased because a block proposer at their assigned slot can **quickly** calculate the result of the xor operation, predict the outcome of their contribution to the randomness generation process, and choose not to propose their block if the outcome is unfavorable. A verifiable delay function can be applied on top of RANDAO to ensure block proposers can’t know the result of their contribution within their allotted time to contribute, which means their ability to skip their slot cannot bias the randomness result. Verifiable Delay Functions (VDF), proposed by [Boneh et al](https://eprint.iacr.org/2018/601.pdf) are cryptographic functions that require a certain amount of time to compute its output (the "delay"), but can be easily verified once it is produced (the "verifiable"). Examples of VDFs are iteratively hashing an input with SHA256 or iteratively algebraically transforming it with [MinRoot](https://eprint.iacr.org/2022/1626.pdf), to compute the output. VDFs are designed to be computationally intensive and can only be performed sequentially, meaning that it is difficult for an adversary with access to parallel processing to compute the output significantly faster than an honest actor with sufficient hardware. We can combine two previous ideas, [Justin Drake’s RANDAO+VDF construction](https://ethresear.ch/t/minimal-vdf-randomness-beacon/3566) and VDFs like [VeeDo from StarkWare](https://medium.com/starkware/presenting-veedo-e4bbff77c7ae) or [Nova-powered minRoot VDF](https://github.com/microsoft/Nova/blob/main/examples/minroot.rs) to create unbiasable randomness for the execution layer. An off-chain actor runs the VDF computation using a block’s RANDAO value as input and is returned a proof of execution along with the result (`uint256`), which is used as the random value. The proof and returned random value are submitted to a verifier contract which verifies the VDF proof and stores the random value in perpetuity for anyone to reference. Crucially, *anyone* can fill the role of running the VDF, proving historical block hashes, and submitting relevant proofs on-chain. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--2d2ede786f/36446ab5a2e3bf0e075f0044037d07b1/asset-https-cdn-sanity-io-images-dgybcd83--2d2ede786f.png) While this construction theoretically grants us secure randomness, VDFs aren’t that simple in practice. It is difficult to quantify the **absolute** **minimum** time a VDF can be run, which is crucial for deploying a production, unbreakable VDF. VDFs are an [active area of research](https://www.vdfalliance.org/) and have additional implications on UX and security in Ethereum. # What did we do? ## Randomness Beacon powered by RANDAO and SNARK Block Hash Oracles ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--a0ab2e1e35/589e4d955beba901e2eda576d3ce9777/asset-https-cdn-sanity-io-images-dgybcd83--a0ab2e1e35.png) By combining SNARKs and VDFs, we developed a **simple, ETH native, VDF-compatible** randomness beacon powered by **RANDAO** and **pluggable block hash oracles**. We designed it to mimic existing randomness request flows as closely as possible. ```solidity /// @notice Interface for contracts providing randomness. interface IRandomnessProvider { /// @notice Emits a randomness request for a specific block. event RandomnessRequested(address indexed requester, uint256 indexed randomnessBlock); /// @notice Emits the fullfillment of ranndomness at a specific block. event RandomnessFulfilled(uint256 indexed fulfilledBlock, uint256 randomSeed); /// @notice Requests randomness and returns the block number tied to the request. function requestRandomness() external returns (uint256); /// @notice Requests randomness from a specific block. function requestRandomnessFromBlock(uint256 blockNum) external; /// @notice Returns >= 1 random values from a specific block. function fetchRandomness(uint256 blockNum, uint256 numberRandomValues) external view returns (uint256[] memory); } ``` We wrote a [randomness beacon interface](https://github.com/paradigmxyz/zk-eth-rng/blob/aa4604a40822abf7f1d7d4e84b0987103e4cbf13/contracts/src/IRandomnessProvider.sol), a working [RANDAO-based beacon](https://github.com/paradigmxyz/zk-eth-rng/blob/aa4604a40822abf7f1d7d4e84b0987103e4cbf13/contracts/src/RANDAOProvider.sol), and a [VDF reference implementation using StarkWare's VeeDo VDF](https://github.com/paradigmxyz/zk-eth-rng/blob/aa4604a40822abf7f1d7d4e84b0987103e4cbf13/contracts/src/VDFProvider.sol) (not production ready) available on our [Github](https://github.com/paradigmxyz/zk-eth-rng). ```solidity /// @notice Interface that all blockhash oracles must implement /// so RandomnessProvider can plug in. interface IBlockhashOracle { /// @notice Returns the nonzero, accurate block number /// if the blockhash is verified. function blockHashToNumber(bytes32 hash) external view returns (uint256); } ``` We've also written a [block hash oracle interface](https://github.com/paradigmxyz/zk-eth-rng/blob/aa4604a40822abf7f1d7d4e84b0987103e4cbf13/contracts/src/IBlockhashOracle.sol), [blockhash opcode-based block hash oracle](https://github.com/paradigmxyz/zk-eth-rng/blob/aa4604a40822abf7f1d7d4e84b0987103e4cbf13/contracts/src/BlockhashOpcodeOracle.sol), [circuit that proves historical block hashes](https://github.com/paradigmxyz/zk-eth-rng/blob/aa4604a40822abf7f1d7d4e84b0987103e4cbf13/circuits/single_block_header_zkp/singleBlockHeader.circom), and a [SNARK-based block hash oracle](https://github.com/paradigmxyz/zk-eth-rng/blob/aa4604a40822abf7f1d7d4e84b0987103e4cbf13/contracts/src/ZKBlockhashOracle.sol) that verifies proofs and attests to historical block hashes on-chain. These contracts are proof-of-concepts, but are prepared to serve as a foundation for use **once VDFs are production-ready.** *The contracts and circuits are unoptimized, unaudited, and experimental — use at your own risk! Issues and pull requests are welcome.* # Future Work There is plenty to do and many ways to contribute. Here are a few ideas we invite you to work on. - **Prover Incentives**: Design an efficient mechanism that minimizes the cost of randomness for users while incentivizing relays to fulfill requests. - **Block Hash Oracle**: Create an efficient, production block hash oracle that implements our `IBlockhashOracle` interface. - **VDF**: Write a Solidity verifier contract for a [Nova SNARK VDF](https://github.com/microsoft/Nova/blob/main/examples/minroot.rs). - [**Noir**](https://github.com/noir-lang/noir) **Libraries** (Emerging Domain Specific Language for SNARK proving systems) - RLP utilities - Implement history proof circuit (eg. block hash oracle) - Implement a VDF - [minRoot](https://eprint.iacr.org/2022/1626.pdf) - [Iterative MIMC hash](https://ethresear.ch/t/hash-based-vdfs-mimc-and-starks/2337) # Conclusion While there are a variety of flavors of randomness on Ethereum, we’ve found that many of them have subtle flaws such as biasability, liveness, unnecessary costliness, or additional trust assumptions. To address these issues, we propose potential designs uniquely enabled by SNARKs and VDFs. We also developed proof-of-concept drop-in implementations that can be easily integrated with production-ready verifiable delay functions (VDFs) to provide secure, cost-effective, and straightforward integration of randomness for Ethereum's execution layer. If you’re interested in exploring any of these topics, don’t hesitate to get in touch! You can reach us on Twitter at [@amangotchu](https://twitter.com/AmanGotchu), [@sina_eth_](https://twitter.com/sina_eth_), and [@gakonst](https://twitter.com/gakonst). *Shoutout to Yi Sun and Jonathan Wang for introducing us to the concept of viable SNARK block hash oracles.* *Acknowledgments: *[*Yi Sun*](https://twitter.com/theyisun)*, *[*Jonathan Wang*](https://twitter.com/jonathanpwang)*, *[*Dan Lee*](https://www.paradigm.xyz/team/danlee)*, *[*Transmissions11*](https://www.paradigm.xyz/team/transmissions11)*, *[*Dan Robinson*](https://www.paradigm.xyz/team/danrobinson)*, *[*Maxim Vezenov*](https://twitter.com/maximvezenov)*, *[*Kevaundray Wedderburn*](https://github.com/kevaundray)*, *[*Justin Drake*](https://twitter.com/drakefjustin) ## https://www.paradigm.xyz/writing/reth # Introducing Reth > Paradigm is excited to announce Reth, a free, open-source Ethereum execution layer client. In this post, we’ll discuss why we are making Reth and what to expect from us in the future. **We’re excited to announce** [**Reth**](https://github.com/paradigmxyz/reth)**, a free, open-source Ethereum execution layer client built by** [**Paradigm**](https://paradigm.xyz/)**.** In this post, we’ll discuss why we are making Reth and what to expect from us in the future. # What is Reth? [Reth](https://github.com/paradigmxyz/reth) (short for Rust Ethereum, [pronunciation](https://twitter.com/kelvinfichter/status/1597653609411268608)) is a new Ethereum full-node implementation focused on being user-friendly, modular, fast, and efficient. Reth is an [execution client](https://hackmd.io/@n0ble/the-merge-terminology) compatible with all Ethereum consensus client implementations that support the [Engine API](https://github.com/ethereum/execution-apis/blob/main/src/engine/specification.md). As a full Ethereum node, Reth will allow users to sync the complete Ethereum blockchain from genesis and interact with it (and its historical state, if in archive mode) once synced. We are building Reth to accommodate a broad user base, including stakers, hobbyists, RPC node operators, bridges, MEV searchers, and even L2s (e.g., Optimism/Arbitrum) or other Ethereum-adjacent projects (e.g., Polygon, BSC, Avalanche, Fantom etc.). These users often have diverse requirements (e.g., hobbyists and stakers want nodes that work on cheap hardware, while RPC node operators have access to expensive disks and cloud snapshots). Reth does not attempt to solve all requirements at once. Instead, we are committed to creating a configurable node that allows users to explore the tradeoff space based on their needs. Reth is still a work in progress and subject to frequent changes. The code has yet to be audited and should not be used in production. Nevertheless, we are open-sourcing and sharing our vision today in the interest of transparency and values alignment with Ethereum. The code is [available for free on Github under the permissive Apache/MIT license](https://github.com/paradigmxyz/reth) for anyone to use without any strings attached. We encourage the community to fork it, contribute with docs, issues, pull requests, questions, or even try to break it. We cannot wait to see what you come up with! With that said, let’s dive in. # Why is Paradigm building a new Rust Ethereum client? At Paradigm, we’re always looking to push the frontier. With [ethers-rs](https://github.com/gakonst/ethers-rs/), [Foundry](https://github.com/foundry-rs/foundry/) and [revm](https://github.com/bluealloy/revm/), we built a mature stack of tools to manipulate the EVM. So we thought, “What’s next?”. The answer was Reth. With Reth, we want to: ## Build a performant node for power users We are power users of the Ethereum stack and work with power users all the time. So we wanted a node built for performance but also expert tinkering. Reth aims to provide best-in-class performance across every vertical (CPU/Memory/Bandwidth/Disk space) or provide configurable profiles allowing users to explore the tradeoffs between each mode (disk space vs. [latency/throughput](https://www.paradigm.xyz/2022/07/consensus-throughput)). We are building Reth so each component can be used as a library in people’s tech stacks. For example, an indexing company could use blazing-fast database bindings to provide better performance for their table re-indexing. Or an [ERC4337](https://eips.ethereum.org/EIPS/eip-4337)-bundler could use the EVM and database bindings to provide simulation services to a wallet’s users. With Reth, we hope that every component of the node stack will be unbundled and re-bundled many times over, allowing power users to explore the efficient frontier of the features they need to do what they’re best at. We also hope that the design and code or [FFI](https://en.wikipedia.org/wiki/Foreign_function_interface) bindings to it (please [reach out](mailto:georgios@paradigm.xyz) if you want to build bindings from any language to Rust) from the best components will be upstreamed to other implementations. ## Contribute to Ethereum’s stability by improving client diversity The Ethereum protocol benefits from [client diversity](https://clientdiversity.org/#distribution) when no client has >66% dominance. This contributes to cross-client testing of the correctness of implementations and decentralized development of the Ethereum protocol. It also avoids scenarios such as finalizing a block in the existence of a software bug. With Reth, we hope to grow the pie of clients in the ecosystem to contribute to the network’s health while keeping our consensus-critical adoption in check. ## Give back to Ethereum by contributing to the roadmap The Ethereum protocol and the Ethereum node codebases have evolved significantly over the years and are still developing. Changes like EIP1559, The Merge, and EIP4844 have highlighted that innovation on the node level *must* happen iteratively, with testing, benchmarking, and documentation expected at the highest bar. In addition, the community expects Core Developers to maintain the network and keep it healthy. They also expect Core Developers to ship innovations that come from research directions, in tight timelines, with sometimes unclear scope or edge cases. We want the Ethereum protocol to keep innovating, and we want Ethereum nodes to remain robust, and we acknowledge that can become a tension. With Reth, we are going to be in the trenches building alongside everyone, and hope we’ll be able to alleviate some of that pressure on Core Developers. We also hope to push the frontier with new research, code, and architectures, and contribute to the upcoming essential milestones of the Ethereum roadmap. # Why is Reth a new codebase and not contributing to existing ones? As open-source developers, we looked at every client implementation in the market and considered holistically whether to contribute to or fork an existing one. Unfortunately, we could not find something that satisfied all our requirements out of the box or that could be made to fulfill them within reasonable timeframes. So we decided to build Reth from scratch with the following criteria: - **Performance:** We want Reth to provide the best-in-class performance. To achieve this, we decided to use Rust as our programming language and the [Staged Sync node Architecture](https://erigon.substack.com/p/erigon-stage-sync-and-control-flows) pioneered by the Erigon team. - **Modularity:** We want to build Reth with small, well-abstracted, well-tested, and benchmarked packages. This allows contributors to use Reth packages as libraries and makes it easy to contribute. That way, devs do not need to worry about the entire node and can contribute to small easy-to-onboard packages in hours or days, not weeks or months. - **Battle-Tested Tech Stack:** We want Reth to use our battle-tested & optimized tech stack from [Foundry](https://github.com/foundry-rs/foundry/), including [ethers-rs](https://github.com/gakonst/ethers-rs/) and [revm](https://github.com/bluealloy/revm/). - **Stability:** We want Reth to be built on robust foundations, and that starts from the language & compiler. We only use stable Rust with stable features and well-maintained crates. We also design our abstractions so that if any crate is suddenly unmaintained and we wouldn’t want to maintain it ourselves, we could switch to a new one without rearchitecting the entire node. - **Archive Node & Tracing Support:** In addition to supporting Ethereum’s post-merge checkpoint syncs, we recognize the industry’s reliance on high-assurance archive nodes and performant tracing for infrastructure peripheral to core node operations. We want Reth to provide best-in-class support for historical node access and high throughput / low latency call (`trace_call`/`trace_callMany` etc.) and opcode tracing (`debug_traceTransaction`) at the chain’s tip and historically. - **Licensing:** We want Reth to have a permissive license so third parties can use its performant and modularized components without being bound by our project’s license. The Apache/MIT license was an essential requirement for that. If a new architecture or technological stack outperforms the state-of-the-art in the future, we are open-minded to making changes. We’d like to encourage the community to come to us with ideas they’d like to see in Reth. After all, we’re tinkerers, and this is software built for tinkering. # Is this ready to use? Reth is still a work in progress, which started on September 20th, 2022. In three months, we have built the following: 1. Generic headers & block downloaders 2. Generic database and codec abstractions 3. A generic mempool 4. A new p2p stack 5. A blazing-fast EVM executor 6. The “core” syncing stages (headers/bodies/senders/execution) 7. The foundations for fuzzing and benchmarking every package We have not yet implemented fully or tested the following: 1. PoW and PoS consensus verification 2. Other Erigon-style stages (intermediate hashes and other db indexes) 3. Certain verification checks during execution (or statetests) 4. Full JSON-RPC support (we have already implemented most RPCs in Anvil including [`trace_*`](https://github.com/foundry-rs/foundry/blob/427c1b549be814b255d8a4dea8fa3c2409dddc4c/evm/src/executor/inspector/tracer.rs) so should not be a big lift) 5. Wiring up each component in the stages loop in a CLI to perform a full sync 6. Ensuring the P2P network works properly during syncing at the tip or while gossiping mempool transactions. 7. Full Ethereum test suite compliance (incl. [Hive](https://github.com/ethereum/hive/) support, using/improving [retesteth](https://github.com/ethereum/retesteth)-like software & upstreaming of our specification finds into [execution-specs](https://github.com/ethereum/execution-specs/)) **We expect to have full sync from genesis implemented sometime in early Q1 2023**. In the meantime, we're working on ensuring every repository crate is well-documented, abstracted, and tested — see [here for the project layout](https://github.com/paradigmxyz/reth/blob/main/docs/repo/layout.md). # What is the roadmap after you get to full sync? In developing the node, we learned a lot about how the Ethereum protocol works and how nodes should be built. To facilitate knowledge transfer and to make it easier for other people to learn about nodes, we will ship the [Reth Book](https://github.com/paradigmxyz/reth/tree/main/book), an educational resource on onboarding as an Ethereum node developer. We are also excited to experiment, starting with investigating the Disk I/O problem under random reads and writes. Disk I/O is effectively the least common denominator in every conversation about performance, and solving it would unlock both performance improvements and cost savings for the entire spectrum of node operators. We are still early in our exploration there, but here are some questions we want to answer for people interested in the research: 1. Can we pre-fetch data so that when we query the memmapped database, we can cache other values “for free” instead of making a new DB query? 2. Can we statically analyze a block to predict all the touched storage slots without execution? E.g., pre-warm all Uniswap-related storage slots? Should we run a historical analysis to understand what the workload looks like? 3. Can we pipeline and batch EVM operations? For example, can we detect SLOAD/SSTORE calls across multiple transactions in a “batch write” and “batch read” process and save them on DB queries? Can we make an expensive opcode execute in the background until their result is needed? 4. Can we further optimize the EVM by detecting N-sequences of opcodes and performing “block” opcode execution instead of one by one (EVMone already has made strides there)? If these are problems you can help us with, [reach out](mailto:georgios@paradigm.xyz). # Acknowledgments In developing the node, we investigated other nodes' design decisions to understand what is done well, what is not, and where we can improve the status quo. A big shoutout to the teams below: - [Geth](https://github.com/ethereum/go-ethereum/): We would like to express our heartfelt gratitude to the go-ethereum team for their outstanding contributions to Ethereum over the years. Their tireless efforts and dedication have helped to shape the Ethereum ecosystem and make it the vibrant and innovative community it is today. Thank you for your hard work and commitment to the project. - [Erigon](https://github.com/ledgerwatch/erigon) (fka Turbo-Geth): Erigon pioneered the ["Staged Sync" architecture](https://erigon.substack.com/p/erigon-stage-sync-and-control-flows) that Reth is using, as well as [introduced MDBX](https://github.com/ledgerwatch/erigon/wiki/Choice-of-storage-engine) as the database of choice. We thank Erigon for pushing state-of-the-art research on the performance limits of Ethereum nodes. - [Akula](https://github.com/akula-bft/akula/): Reth uses forks of the Apache versions of Akula's [MDBX Bindings](https://github.com/paradigmxyz/reth/pull/132), [FastRLP](https://github.com/paradigmxyz/reth/pull/63) and [ECIES](https://github.com/paradigmxyz/reth/pull/80). Given that these packages were already released under the Apache License and they implement standardized protocols without much room for improvement, we decided not to re-implement them. We thank the Akula team for their contributions to the Rust Ethereum ecosystem and for publishing these packages. We also thank the Nethermind and Besu teams for contributing to client diversity, and we hope to find ways to collaborate in the future. **Conclusion** Paradigm is building Reth, a Rust Ethereum Execution Layer. Reth is a brand-new full-node implementation of the Ethereum protocol, with an Apache/MIT license, focused on contributor friendliness, modularity, and performance. We are also excited about our codebases as an incubator for new Rust developers. Rust is a breakthrough tool for systems, databases, and network engineering. We think of Ethereum as a high-assurance operating system that needs to be resilient against the biggest adversaries. There is no better toolkit than Rust to achieve that. If you’re an existing or aspiring Rustacean, staker, hobbyist, professional node infrastructure operator, MEV Searcher, Ethereum L1/L2 developer, data analyst, or are simply excited about contribution, please reach out to georgios \[at\] paradigm \[dot\] xyz over email or join the chatroom found in the [Reth repo’s README](https://github.com/paradigmxyz/reth). We can’t wait to hear about what you’re excited to contribute and build on top of Reth’s infrastructure and libraries. Thanks to the people who have already contributed to Reth's design, documentation and code: Matt Seitz, Oliver Nordbjerg, Dan Cline, Dragan Rakita, Roman Krasiuk, joshieDo, Andrew Kirillov, Loren Siebert, 0xKitsune, team LambdaClass, and Brock Elmore. None of this would have been possible without their tireless contributions to the Rust Ethereum ecosystem of ethers-rs, revm, Foundry, and now Reth. Thanks to Achal Srinivasan for designing Reth's visuals. Finally, the biggest thank you goes to all Ethereum Core Developers for making Ethereum great; we are excited to join you on this long journey. See you on [Github](https://github.com/paradigmxyz/reth). Acknowledgments: Thanks to Alex Stokes, Danny Ryan, Justin Drake, Lev Livnev, Liam Horne, Paul Hauner, Robert Miller, snoopy_mev, and Tim Beiko for feedback on earlier drafts of this post. Disclaimer: Any portfolio companies referred to herein are mentioned for illustrative purposes only and are not representative of all investments made by Paradigm. ## https://www.paradigm.xyz/writing/paradigm-and-wagmi # Paradigm × wagmi > Paradigm is sponsoring Tom and Jake to focus full-time on building open-source libraries to accelerate web3 frontend development. We are excited to announce Paradigm is sponsoring [Tom Meagher](https://twitter.com/awkweb) and [Jake Moxey](https://twitter.com/jakemoxey) to focus full-time on [wagmi](https://wagmi.sh/), a powerful & ergonomic web3 frontend development library. Our vision is to build open-source libraries to accelerate web3 frontend development. We could not think of anyone better than Tom & Jake to make this vision a reality. **What is wagmi?** [wagmi](https://wagmi.sh/) (on [Github](https://github.com/wagmi-dev/wagmi)) is a Javascript library for web3 frontends, which provides simple hooks (e.g. [useBalance](https://wagmi.sh/docs/hooks/useBalance)) for developers to interact with Ethereum. It is high-quality, developer-friendly, and used by [hundreds of teams](https://github.com/wagmi-dev/wagmi/network/dependents?package_id=UGFja2FnZS0yOTE2MzE1Nzg3) in the space, with [~330k monthly downloads](https://www.npmjs.com/package/wagmi). wagmi has over 3,400 stars on Github, and was a finalist for “Breakthrough of the Year” at React Summit, with over 25,000 developers in attendance. You can learn more about wagmi using the [Examples](https://wagmi.sh/examples/send-transaction) and [Documentation](https://wagmi.sh/docs/getting-started). Many thanks to the [contributors](https://github.com/wagmi-dev/wagmi/graphs/contributors) and [sponsors](https://github.com/sponsors/wagmi-dev) who helped make wagmi a reality. **Who are Tom & Jake?** [Tom](https://twitter.com/awkweb) ([Github](https://github.com/tmm)) and [Jake](https://twitter.com/jakemoxey) ([Github](https://github.com/jxom)) are among the most talented frontend developers in the space. They have contributed to leading products like [Mirror](https://mirror.xyz/) and [Rainbow](https://rainbow.me/), and have extensive experience building tools for developers. Tom started building wagmi in [November 2021](https://github.com/wagmi-dev/wagmi/commit/f58ad631c6e696c40ab4915ecc472d2301a01a17). Jake began contributing to wagmi in [January 2022](https://github.com/wagmi-dev/wagmi/discussions/85) and has been key to the evolution of the architecture. **What is our vision?** We plan to create the best open-source libraries for building apps with any chain, using any frontend framework (e.g. React, Vue, etc.). These libraries will feature world-class developer experience, feature-richness, small package size, type safety, and extensive testing. We are actively focused on the following areas, with lots more to come... **wagmi** High-level framework adapters (e.g. React) for interacting with Ethereum. Explore the [examples](https://wagmi.sh/examples) to get started. **CLIs** Building around developer workflows to enable faster iteration from 0 to 1. For instance, generating React hooks from contracts and ABIs, or scaffolding a fullstack EVM project. **Multi-framework** Support for other Javascript-powered frameworks beyond React (e.g. Vue, Svelte, etc.). If you have specific requests, please flag it on [Github Discussions](https://github.com/wagmi-dev/wagmi/discussions). **Secret Project** A low-level TypeScript library that is going to reimagine the experience of building on top of Ethereum on the web. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--7238503d8f/862773f0ee3493d1db00c099f4ea7a51/asset-https-cdn-sanity-io-images-dgybcd83--7238503d8f.png) In partnering with Tom and Jake, we continue to support the development of public goods for Ethereum & the broader crypto ecosystem. We are beyond excited about the products that will be built on top of these foundations over the next few years. We would love to hear what you are building, or discuss how you can contribute towards this vision. Reach us at any time at [achal@paradigm.xyz](mailto:achal@paradigm.xyz) and [georgios@paradigm.xyz](mailto:georgios@paradigm.xyz). *Acknowledgments: Matt Huang, Dan Robinson* ## https://www.paradigm.xyz/writing/introducing-paradigm-s-policy-council # Introducing Paradigm’s Policy Council > We are excited to announce the first iteration of the Paradigm Policy Council, an impressive group of bipartisan talent with a diverse set of experiences. This team will advise Paradigm’s leadership team and help us tell the story of Web3 in Washington and around the world. We at Paradigm believe crypto is changing the world. Today’s builders will democratize finance, create a more equitable internet, and bring about tools that will help humans seamlessly exchange goods, services, and information trustlessly. In the next decade, we will see innovations in every part of our society — from consumer protection to national security, politics to sports, gaming, and more. That’s why we are excited to announce the first iteration of the Paradigm Policy Council, an impressive group of bipartisan talent with a diverse set of experiences. This team will advise Paradigm’s leadership team and help us tell the story of Web3 in Washington and around the world. We couldn’t be more excited to welcome them to the conversation. ## Senior Advisors ### Paul Ryan Former Speaker of the U.S. House of Representatives (R-WI) Paul Ryan was the 54th Speaker of the U.S. House of Representatives. Serving in this role from October 2015 to January 2019, he was the youngest speaker in nearly 150 years. During his tenure, Ryan spearheaded efforts to reform the nation’s tax code, rebuild its national defense, expand domestic energy production, and promote economic opportunity. In 2012, he was selected to serve as Governor Mitt Romney’s Vice-Presidential nominee. Currently, Ryan is Partner at Solamere Capital, Vice Chair of Teneo, adjunct Professor of Economics at the University of Notre Dame, and a Senior Fellow at the American Enterprise Institute. ### Chris Brummer Director of Georgetown University’s Institute of International Economic Law Chris Brummer is Williams Research Professor and Faculty Director of Georgetown’s Institute of International Economic Law. Professor Brummer recently concluded a three-year term as a member of the National Adjudicatory Council of FINRA, an organization empowered by Congress to regulate the securities industry, where his work was praised as making a significant contribution to advancing investor protection. He also currently serves as a Scholar in Residence and Senior Advisor to Paradigm. ## Council Members ### Marta Belcher Special Counsel at the Electronic Frontier Foundation Marta Belcher is counsel to the Electronic Frontier Foundation on a variety of matters related to civil liberties, blockchain, intellectual property, and decentralized technologies, including assisting EFF in interfacing with regulators and legislators. Marta is also the Chair and President of the Filecoin Foundation and the as General Counsel and Head of Policy at Protocol Labs. ### Deb Callahan Former President of the League of Conservation Voters Deb Callahan is an American environmental and political leader and former leader of the League of Conservation Voters, where she served as president for 10 years. She is currently the founder and president of North Star Strategy, offering strategic consulting services to campaigns and the nonprofit and foundation sectors on environmental policy, politics, advocacy, communications, and philanthropic initiatives. ### Makan Delrahim Former U.S. Assistant Attorney General for the U.S. Department of Justice Antitrust Division Makan Delrahim is a partner at Latham & Watkins LLP and former Assistant Attorney General at DOJ, where he oversaw the review and resolution of hundreds of mergers and acquisitions, as well as more than 100 criminal investigations and indictments. He is a respected thought leader on the interplay of antitrust and emerging technologies, including digital media, communications, and blockchain. ### Nicole Elam President and CEO of the National Bankers Association Nicole A. Elam, Esq. is President and CEO of the National Bankers Association, the premier trade association and voice for the nation’s minority financial institutions. She has worked in public policy and public affairs for more than 17 years, including as vice president and government relations manager at JPMorgan Chase & Co. where she led efforts on the firm’s commitment to advance racial equity and drive inclusive economic growth. ### Steve Israel Former U.S. Representative (D-NY) and former chair of the Democratic Congressional Campaign Committee Steve Israel served in the U.S. Congress between 2001-2017, including 4 years as chairman of the Democratic Congressional Campaign Committee (2011–2015). In Congress he created the House Center Aisle Caucus and was recognized as a leader on national security issues and the Middle East. He is currently the Director of the nonpartisan Institute of Politics and Global Affairs at Cornell University. In 2021, he opened a small independent bookshop, Theodore’s Books, in his historic hometown of Oyster Bay, fulfilling a lifelong dream. ### Parker Poling Partner at Harbinger Strategies and former Chief of Staff to the Chief Deputy Whip of the US. House of Representatives. Parker Poling has 20 years of senior staff experience at the highest levels of government and politics. She is the former executive director of the National Republican Congressional Committee. From 2007-2018, Poling served as Chief of Staff to Congressman Patrick McHenry (R-NC), first in his personal office and then in the Office of the Chief Deputy Whip. She has deep knowledge of the banking and financial services sector. ## https://www.paradigm.xyz/writing/paradigm-files-amicus-brief-in-cftc-action-against-ooki-dao # Paradigm Files Amicus Brief in CFTC Action Against "Ooki DAO" > Paradigm is filing an amicus brief in the case recently brought by the CFTC against “the Ooki DAO.” While we are not a party to the case, we thought it was necessary to speak up against the CFTC’s attempt to expand liability to unsuspecting technology users and impair the ability of DAOs to operate in the US. **TLDR:** Paradigm is filing an [amicus brief](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-0dc604d2c6/fa5e5257d76a69d98e6013133c6cedc6/asset-https-cdn-sanity-io-files-dgybcd83-p-0dc604d2c6.pdf) in the [case recently brought by the CFTC](https://www.cftc.gov/media/7681/enfookicomplaint092222/download) against “the Ooki DAO.” While we are not a party to the case, we thought it was necessary to speak up against the CFTC’s attempt to expand liability to unsuspecting technology users and impair the ability of DAOs to operate in the US. The American court system is built around the concept of fair notice and adversarial argument, ensuring that no one, especially the government, can win by engineering one side’s default. Yet the CFTC’s action against the DAO seems designed to go unopposed and did not provide notice to the persons it seeks to hold accountable. The CFTC is attempting to expand its power by winning a suit against a fictitious defendant that is, unsurprisingly, absent. That is fundamentally unfair. **How did we get here?** The CFTC’s complaint against “the Ooki DAO” was filed simultaneously with the Commission’s announcement that it had reached a [settlement](https://www.cftc.gov/media/7676/enfbzeroxorder092222/download) with bZeroX LLC and its two founders. In the Commission’s view, the DAO is an “unincorporated association” that took over responsibility for operating and controlling the Ooki Protocol from bZeroX and should therefore be subject to liability. This liability would extend to each of the association’s “members,” meaning that any token holder who voted on a single DAO proposal could be left holding the bag for the entire DAO’s liabilities. **The CFTC’s ill-conceived theory of liability** The CFTC’s attempt to hold any voting token holder liable is fundamentally flawed. It misunderstands the so-called “control” that token holders actually have over DeFi protocols and has no basis in law. It’s also unfair: under the Commission’s reasoning, a token holder who voted *against* a proposal that would result in violative behavior and subsequently sold their tokens would nonetheless be subject to liability for the actions of “the DAO.” A rubric where trying to prevent liability creates liability is only sound logic in the works of Lewis Carroll. **DAOs are the communities of the future, but the CFTC’s actions threaten their potential** DAOs are a technology for social coordination that could revolutionize the way people organize themselves and enable the communities of the future. Yet, by attempting to hold every token holder who voted in a governance proposal liable for the actions of an imagined legal entity, the CFTC will disrupt DAOs’ ability to coordinate and prevent the technology from reaching its full potential. ## https://www.paradigm.xyz/writing/using-on-chain-data-for-policy-research-part-1 # Using On-Chain Data for Policy Research: Part 1 > Crypto policy work rarely involves real, granular data. This is a missed opportunity, given how many tools used by the modern economics and finance community should directly translate to crypto data analysis. Crypto offers granular data, available to anyone, by design. ## 1. Introduction Crypto policy work rarely involves real, granular data. It seems like there are (at least) three broad reasons for that: 1. A lot of policy work in the emerging technology bucket is inherently theoretical/qualitative/analytical, so data is not always necessary or helpful in the early stages. 2. Despite its openness/transparency, there’s a steep learning curve to accessing on-chain data (i.e., raw data pulled directly from the blockchain), even for relatively crypto-native practitioners. 3. Blockchain “forensics” companies and data providers have a handful of data offerings, but nothing that’s flexible/customizable or that caters to the economics/finance research community. This is a missed opportunity, given how many tools used by the modern economics and finance community should directly translate to crypto data analysis. Crypto offers granular data, available to anyone, *by design*. So why do a substantial number of policy papers still rely on pre-aggregated time-series data from external sources like CoinMarketCap instead of going directly to the source? For example, with relatively little effort, it is possible to look at stablecoin issuance across the entire Ethereum ecosystem. This is roughly analogous to being able to query the balance sheets of every major bank in the U.S. and observe changes in consumer deposits on a second-by-second basis — but most policy papers that analyze stablecoins instead choose an analytical approach that talks about hypothesized events, like flights to safety, in the abstract. In this blog post, I’ll demonstrate a few things that I hope will be helpful to policy researchers looking to work with on-chain data: - Where to get on-chain data - How on-chain data is structured - A few basic tools for extracting and working with on-chain data In subsequent posts, I’ll explore how to use the data collected here to draw inferences on crypto markets. I plan on eventually posting the data and code for free use, as well. By shedding light on how to “check the chain,” I hope to show how the crypto’s transparent nature enables a novel approach to data-informed policymaking. If you work at a regulatory agency or research institution and are having difficulty accessing crypto data to work with, please don’t hesitate to [reach out](mailto:brendan@paradigm.xyz) and share your thoughts about what Paradigm can do to help. ## 2. Where do you get on-chain data? Short answer: it depends. For the sake of bounding this particular project, I chose to focus my data gathering efforts on one blockchain (Ethereum) and a subset of specific projects: major USD-denominated, fiat-backed stablecoins. Specifically, USDC, Tether, Binance USD, Pax Dollar, and Gemini Dollar. The general approach I describe here should be broadly applicable to on-chain data, even if you’re looking to create a different set of data. Block explorers like [Etherscan](https://etherscan.io/) are invaluable for viewing transaction snapshots and collecting information on specific smart contracts, but they aren’t particularly useful for generating large datasets in my experience. For collecting and working with raw data, you have essentially two options: (1) running a full node locally, or (2) querying a database that already has raw data that was written directly from the chain. Option (1) requires a considerable amount of technical skill and computational resources. You can get pretty far with Option (2) with very basic [SQL](https://towardsdatascience.com/sql-on-ethereum-how-to-work-with-all-the-data-from-a-transaction-103f94f902e5) and Python skills, so that’s the approach taken here. *Databases that already have on-chain data* [Dune](https://dune.com/home) and Google Cloud Platform’s (GCP) [BigQuery](https://console.cloud.google.com/bigquery) have up-to-date on-chain data structured in database tables that are queryable using SQL commands. Dune has a free option that is slower and somewhat limited, but it’s perfect for A/B testing queries and familiarizing yourself with the database schema, especially if you aren’t very experienced with using SQL to query relational databases. BigQuery is more flexible and faster, but Google charges for compute resources, so it can get expensive quickly. When I was first tinkering around the data, I would test queries in Dune before running in “production” in GCP to save money. For the most part, it worked well? (The one additional thing worth flagging is that Dune has at least 100x the number of crypto tables as GCP, including some pre-cleaned, user generated ones that are very valuable. By comparison, the data in GCP are mostly raw blocks/transactions. Dune also has some very handy built-in data viz tools that are probably worth the price of admission alone.) ## 3. How is on-chain data structured? To answer this question, you first need to know what you’re trying to accomplish with the data you’re seeking. For this test case, I decided I wanted to build a large data set of time-series data for major fiat-backed stablecoins looking at a few specific actions: mints (i.e., issuing stablecoins), burns (i.e., taking stablecoins out of circulation), and transfers. I chose to scope the exercise this way because it seems like policymakers and academics are most interested in fiat-backed stablecoins at the moment, so that data could be quite useful in the short term. The major USD-denominated stablecoins are implemented using the [ERC-20 Token Standard](https://ethereum.org/en/developers/docs/standards/tokens/erc-20/#top). As the name suggests, ERC-20 is a *standardized* way for creating tokens on Ethereum using a smart contract. If you conceptualize a blockchain as a giant decentralized Excel spreadsheet, smart contracts are similar to the Excel functions that let you manipulate the data in the spreadsheet’s cells. Feed the function an input, known as an argument, and it will produce a specific output using its built-in logic (e.g., MAX(number 1, \[number 2\], …) finds the largest number among the numbers included in the function’s input arguments). The relevant contracts can be located using their Ethereum addresses, which are a unique identifier in the blockchain’s data structure: - [USDC](https://etherscan.io/token/0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48) - [Tether USD](https://etherscan.io/token/0xdac17f958d2ee523a2206206994597c13d831ec7) - [Binance USD](https://etherscan.io/token/0x4fabb145d64652a948d72533023f6e7a623c7c53) - [Pax Dollar](https://etherscan.io/token/0x4fabb145d64652a948d72533023f6e7a623c7c53) - [Gemini Dollar](https://etherscan.io/token/0x056fd409e1d7a124bd7017459dfea2f387b6d5cd) Smart contracts are programs that can be used repeatedly, similar to an API. Each time a smart contract is interacted with (e.g., asked to do something programmatically), a record of that interaction is produced and logged in the blockchain by the Ethereum protocol. These logs form a powerful source of information describing a smart contract’s activities. (For a longer explanation of Ethereum event logs, look [here](https://medium.com/mycrypto/understanding-event-logs-on-the-ethereum-blockchain-f4ae7ba50378).) When a smart contract performs a specific function, such as burning ERC-20 stablecoin tokens to remove them from circulation, that function — and the arguments it is fed — are recorded on the blockchain as a transaction log receipt. [Here](https://etherscan.io/tx/0x9792ce47a9463bf46fb677c6d0cd4974e60ad5cb590321114847c299c3290b66) is a transaction where Circle, the issuer of the USDC stablecoin, burned (i.e., removed from circulation) $1,056.92 worth of USDC. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--ce77445869/7b0cd880a54afde57360c3cec9c08294/asset-https-cdn-sanity-io-images-dgybcd83--ce77445869.png) If you toggle over to the “Logs” tab, you can see the transaction event logs. The relevant fields are: - *Address*: the contract address of the smart contract. The contract address for the USDC stablecoin is [0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48](https://etherscan.io/address/0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48). - *Name*: the function executed by the smart contract, along with the parameters the function takes. In this case, the smart contract is calling the **Burn** function, which takes parameters that specify where the burned coins are sent (e.g. *burner*, which has to be an Ethereum address) and how many coins are being burned (e.g. *amount*, which has to be an unsigned integer smaller than 256 bits). The Etherscan output also shows *Topics* and *Data* fields. These contain the bulk of the relevant information we need to parse to analyze transactions. [^1] - *Topic0* is the hash of the signature of the function. Essentially, it takes the function and its arguments (i.e. the parameters) and puts them through a one-way algorithm that creates a unique hash — or fingerprint — of the function. Ethereum uses the Keccak-256 hash function. Putting the function signature (i.e. “Burn(index_topic_1 address burner, uint256 amount)”) through the Keccak-256 algorithm will always produce the same hash, so any time that hash appears in a log, you can be confident the same function was called. - *Topic1* is an indexed parameter of the **Burn** function. Here, *Topic1* is the address where the burned coins are sent. (Note: If the **Burn** function took more parameters, those would appear as additional *Topics*.) - The *Data* field here represents the amount of coins burned. Now that we understand the basics of how on-chain data is structured for our use case, we can start pulling the data from Dune and/or GCP. ## 4. Basic tools for extracting and working with on-chain data As noted previously, for this example I’ve chosen to pull on-chain data from existing databases as opposed to accessing an active node on the Ethereum network. To keep things simple, I’m extracting (mostly) raw tables from GCP using SQL, and then cleaning the data in Python using the [pandas](https://pandas.pydata.org/) library. *Extracting tables from GCP using BigQuery* [^2] BigQuery has a lot of Ethereum tables, as seen in the left-hand pane of the image below. Clicking on a table brings up the database schema, which we can see here for the `ethereum.logs` table. *Address*, *data*, and *topics* map to the log data I described above from Etherscan. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--04d93eda31/f3af53181b565fa5bd567f254662618a/asset-https-cdn-sanity-io-images-dgybcd83--04d93eda31.png) The following query will extract all of the records in the logs table that involve an interaction with the USDC, Tether USD, Binance USD, Pax Dollar, or Gemini Dollar contracts. Some additional information is useful beyond what’s available in `ethereum.logs`, so I’ve also merged in data from the `ethereum.blocks` table to include things like [gas](https://ethereum.org/en/developers/docs/gas/) (a measure of a network fee paid to Ethereum miners for validating transactions). [^3] `` SELECT eth_logs.\*, eth_blocks.number, eth_blocks.miner, eth_blocks.size, eth_blocks.gas_limit, eth_blocks.gas_used, eth_blocks.base_fee_per_gas FROM `bigquery-public-data.crypto_`ethereum.logs`` AS eth_logs LEFT JOIN `bigquery-public-data.crypto_ethereum.blocks` AS eth_blocks ON eth_logs.block_number = eth_blocks.number WHERE( eth_logs.address='0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48'-- USDC OR eth_logs.address ='0xdac17f958d2ee523a2206206994597c13d831ec7' -- USDT OR eth_logs.address ='0x4fabb145d64652a948d72533023f6e7a623c7c53' -- Binance USD OR eth_logs.address = '0x8e870d67f660d95d5be530380d0ec0bd388289e1' -- Pax Dollar OR eth_logs.address = '0x056fd409e1d7a124bd7017459dfea2f387b6d5cd' -- Gemini Dollar ) `` The resulting table can be read directly into Python as a pandas [dataframe](https://pandas.pydata.org/docs/reference/api/pandas.DataFrame.html) with the following fields: - log_index - transaction_hash - transaction_index - address - data - topics - block_timestamp - block_number - block_hash - number - miner - size - gas_limit - gas_used - base_fee_per_gas Most of these fields are ready-to-use in raw form. However, the *topics* field discussed in Section III requires some additional cleaning with Python to separate the field into multiple columns. [^4] ## 5. Conclusion This post leveraged Ethereum logs data, but the same approaches can be used to access a variety of data available on the chain. Python and SQL, tools that most economists and policymakers are familiar with, can go a long way. Crypto’s transparency, relative to traditional finance, offers a unique opportunity for researchers to use real-time data to shed light on how the financial system functions, including where risks may arise unchecked. In the next post I’ll prep the data set for a targeted analysis looking at minting and burning of fiat-backed stablecoins. In post number three, I’ll display a few charts and tables as an example of the kind of research questions that people can examine using granular on-chain data. ## 6. Caveats A few additional notes/disclaimers: - Transactions are not unique in this data set. In Ethereum, a [transaction](https://ethereum.org/en/developers/docs/transactions/) is a change in state of the [Ethereum Virtual Machine](https://ethereum.org/en/developers/docs/evm/) (EVM). Each transaction can have multiple, distinct logs that interact with the same contract address. These are indexed by the “log_index” variable, such that each observation is uniquely identified by a “log_index” and “transaction_hash” combination. - The **Transfer** function can describe a number of different scenarios, depending on the [accounts](https://ethereum.org/en/developers/docs/accounts/) that are being invoked in the function’s arguments. In some cases, it will be referring to the transfer of tokens from one externally-controlled account to another. In other cases, it could describe the transfer of tokens from one externally-controlled account to an account controlled by another smart contract, like a DeFi protocol. For now, I’ve kept the transfers in raw form and have not mapped out every account address, so keep this in mind if you are trying to draw inferences from the transfer data. The **Mint** and **Burn** functions have a more straightforward interpretation. For the other functions in the dataset… you’ll have to get more familiar with Solidity. - Being that this is on-chain data, it only shows things that happened on-chain. So, transfers of USDC between Circle customers that happen on the books of Circle (e.g., off-chain) would not be reflected in the data. [^1]: Note: the Topics and Data fields have different interpretations depending on the type of function that is being called [^2]: This post does not walk through how to set up an account for accessing BigQuery, but you can find out how to do that here [^3]: GCP has some restrictions on query size that make it difficult to run this query directly. If you look at the actual code when it is posted, you’ll see I had to deal with this issue by breaking the query into smaller pieces and looping/aggregating the results using Python and the GCP BigQuery API. More info here. There are probably less clunky ways to do this, but where’s the fun in that [^4]: The ethereum.logs table in GCP records all of the topics for a transaction log as a single string, delimited by commas. In order for this to be useful for research, I separated the topics into individual fields: topic0, topic1, and topic2 ## https://www.paradigm.xyz/writing/ethereums-new-staking-model-does-not-make-eth-a-security # Ethereum's New ‘Staking’ Model Does Not Make ETH A Security > Ethereum’s adoption of a proof-of-stake consensus mechanism does not make ETH (or even staked ETH) an investment contract, and such a finding would result in a nonsensical application of securities laws. ## 1. Introduction In the wake of Ethereum’s transition to a proof-of-stake consensus mechanism (“the Merge”), various commentators have suggested that Ethereum’s new staking model could result in its native token Ether (ETH) being deemed a security under U.S. securities laws. [^1] Some have taken the extreme position that the token in *any* proof-of-stake system is likely to be a security. However, these arguments stretch the interpretation of the *Howey* test beyond recognition and fail to recognize that the fundamental purpose of securities laws is to address information asymmetries that are not present in this context. As explained below, Ethereum’s adoption of a proof-of-stake consensus mechanism does not make ETH (or even staked ETH) an investment contract, and such a finding would result in a nonsensical application of securities laws. ## 2. Securities Laws Primer U.S. securities laws require issuers to register any offers or sales of securities with the SEC, unless an exemption is available. [^2] Registration entails mandatory disclosure that ensures material information is shared with investors to allow for informed decision-making, prevent information asymmetries, and avoid agency problems. The Securities Act of 1933 enumerates the types of instruments that constitute a “security,” which include an “investment contract.” [^3] As defined by the Supreme Court’s seminal opinion in *Howey*, an “investment contract” entails (1) an investment of money; (2) in a common enterprise; (3) with the reasonable expectation of profits; (4) derived solely from the efforts of others. [^4] In order to meet this definition, a contract, scheme, or transaction must satisfy each of the four prongs. In decisions interpreting “investment contract,” the Court has rejected a literal construction of the statute, adopting instead a flexible interpretation that focuses on the “economic realities” of the relationship between the promoter and investors. [^5] In various instances, the Court has applied the economic reality concept to limit the scope of “investment contracts” and the application of securities laws if the underlying economic relationship between the parties is not one of investor and promoter. [^6] ## 3. Application of *Howey* to Proof-of-Stake Ethereum Ethereum’s adoption of a proof-of-stake consensus mechanism has led various commentators to suggest that ETH, or more specifically the act of staking ETH, could meet the definition of an investment contract under *Howey*. [^1] The argument takes the following structure: staking ETH as a validator meets the *Howey* test because a validator is (1) “investing money” by locking up 32 ETH to stake, (2) in a “common enterprise” comprised of the various parties participating in the validation process, (3) with the expectation of receiving profits in the form of staking rewards, (4) that are derived from the efforts of other validators or other parties participating in the validation process. [^7] Putting aside whether a validator depositing ETH into a smart contract would qualify as an “investment of money,” [^8] the argument that Ethereum’s adoption of proof-of-stake results in ETH being deemed an investment contract fundamentally misinterprets the second and fourth prongs of *Howey*, and the failure of either prong is fatal. The conclusion would also result in an absurd and unnecessary application of securities laws because there is no issuer or promoter with privileged access to information who could or should be forced to make disclosures. ### 3a. Proof-of-stake does not entail a “common enterprise” #### 3ai. *Legal Standard* As the Supreme Court stated in *Howey*, an essential component of an investment contract is a “common enterprise.” [^9] While some courts have held that a common enterprise exists only when there is “horizontal commonality,” [^10] others have found “vertical commonality” sufficient to meet this prong of *Howey*. [^11] As explained below, staking ETH entails neither horizontal nor vertical commonality and thus fails to meet the common enterprise prong of *Howey*. #### 3aii. *There is no “horizontal commonality” among validators* Horizontal commonality is present when each individual investor’s fortunes are tied to the fortunes of other investors by the “pooling of assets, usually combined with the pro-rata distribution of profits.” [^12]orizontal commonality requires a sharing or pooling of funds.’” Id. (quoting Hart v. Pulte Homes of Michigan Corp., 735 F.2d 1001, 1004 (6th Cir. 1984)); Wals v. Fox Hills Dev. Corp., 24 F.3d 1016, 1019 (7th Cir. 1994) (A “pooling of profits” is also “essential to horizontal commonality.”)\] “Pooling” in turn requires an issuer or promoter to commingle investors’ funds and use them toward a common enterprise. [^13] In other words, courts have stressed that horizontal commonality requires the expected profits of an investor to be tied to other investors “*by entrepreneurial efforts of a promoter*.” [^14] ‘inextricably intertwined’ by contractual or financial arrangements.”); Curran v. Merrill Lynch, Pierce, Fenner & Smith, Inc., 622 F.2d 216, 224 (6th Cir. 1980), aff’d on other grounds, 456 U.S. 353 (1982) (“no horizontal common enterprise can exist unless there…exists between \[the investors\] themselves some relationship which ties the fortunes of each investor to the success of the overall venture.”) (emphasis added)\] Horizontal commonality therefore requires investors to give up any individualized claims to profits, in return for a participatory and pro-rata interest in the ensuing profits distributed by the promoter. [^15] Some have mistakenly argued that staking ETH implies horizontal commonality because validators deposit ETH into a single smart contract address, which allegedly entails a “pooling of assets”, [^16] or alternatively that horizontal commonality is allegedly found because there is a perceived “cooperation” amongst validators. [^17] As shown below, these arguments are conclusory, and misunderstand the mechanics of staking in Ethereum. To become a validator on the Ethereum network, one is required to deposit 32 ETH to a smart contract address (known as the “Deposit Contract”). [^18] However, the deposit of ETH to the Deposit Contract is not “pooling” since that ETH is never under the discretionary control of a promoter who can use it to drive value to a common enterprise. Instead, the purpose of staked ETH is to create an incentive mechanism that secures the network; it ensures that validators have some skin in the game so that they can be penalized or “slashed” for behaving dishonestly. Further, while each validator’s ETH is deposited in the Deposit Contract, it is not commingled and remains distinguishable. Each validator will also have the ability to withdraw its staked ETH once that functionality is implemented in a later network upgrade. Individual validators also do not have participatory rights to any pro-rata distribution of profits generated by an enterprise. As explained further below, rewards vary for different validators and are determined primarily based on each validator’s individual efforts; their fortunes do not rise and fall together based on the entrepreneurial efforts of any promoter. [^19] Therefore, in analyzing the economic realities of a staking transaction, a court should find an absence of horizontal commonality. [^20] #### 3aiii. *There is no “vertical commonality” among validators* Some courts have held that the common enterprise prong of *Howey* can also be satisfied through vertical commonality, which focuses “on the relationship between the promoter and the body of investors.” [^21] However, staking ETH does not entail vertical commonality simply because there is no promoter. In general, the Ethereum network does not rely on any key party for its success or operation; it is “sufficiently decentralized.” [^22] To ensure decentralization, Ethereum’s consensus mechanism allows validators to operate self-sufficiently without reliance on any third party. Validators come to the network freely and voluntarily, and they can choose to stop participating at their discretion. Validators can perform their role in the network without depending on anyone else. If they perform their role properly based on the rules of the network, they will receive a reward based on those rules and not on the efforts of a promoter. Focusing specifically on the economic realities of a staking transaction, it is clear that there is no promoter on which validators rely. Since vertical commonality requires that “the fortunes of investors” are “tied to the fortunes of the promoter\[,\]” [^23] the absence of a promoter ends the inquiry. ### 3b. Staking ETH does not satisfy the “efforts of others” prong of *Howey* #### 3bi. *Legal Standard* According to the Supreme Court’s original formulation in *Howey*, one of the requirements for an investment contract is that investors expect profits “*solely* from the efforts of the promoter or a third party.” [^24] This standard has been watered down by the appellate courts, which have read out “solely” and focused instead on whether the efforts of promoters are “*undeniably significant”* [^25] and “*essential managerial* efforts which affect the failure or success of the enterprise.” [^26] According to the SEC’s guidance, these efforts are typically characterized by “*expertise* and *decision-making* that impact the success of the business or enterprise through the application of *skill* and *judgment*.” [^27] Inversely, courts have focused on whether the investor had the “*ability to* *control* the profitability of his \[own\] investment.” [^28] The greater the degree to which an investor relies on their own efforts for their profit, the weaker the justification to characterize the underlying transaction as an investment contract under *Howey*. In these cases, applying securities laws or disclosure requirements is unnecessary because there is no separation of ownership and control. [^29] does not negate the existence of an investment contract.“)\] Courts have further outlined several factors (known as the *“Schaden factors”*) to test an investor’s “ability to control” [^30] (listed in order of importance): (1) the investors’ access to information, (2) the investors’ contractual powers, (3) the investors’ contribution or time and effort, (4) the adequacy of financing, (5) the nature of the business risks, and (6) the level of speculation. #### 3bii. *Application to Proof-of-Stake Ethereum* Some have argued that Ethereum’s transition from proof-of-work to proof-of-stake was also a transition from a competitive to a more “cooperative” mechanism [^31] since the validation process in proof-of-stake requires multiple parties. According to this view, when staking ETH, each validator is reasonably expecting to derive staking rewards by relying on the efforts of other validators. [^32] This argument has been supported by the low-level implementation detail that, under Ethereum’s unique proof-of-stake protocol, validators are sorted into committees. [^33] However, there are multiple other proof-of-stake protocols that do not segregate validators into committees. [^20] More significantly, this argument misunderstands the mechanics of validator rewards in Ethereum’s proof-of-stake implementation and dilutes *Howey*’s original standard requiring reliance “*solely* on the efforts of others” to an unprecedented degree. As we explain below, Ethereum’s validators cooperate no more than miners in the pre-Merge proof-of-work network and do not expect rewards from significant managerial efforts of other validators, but instead expect rewards primarily from their own efforts and funds. To understand why this is the case, it is helpful to have a base level understanding of the rewards validators can earn in Ethereum’s proof-of-stake network. #### 3bii1. Validator rewards in Ethereum’s proof-of-stake network There are many factors that enter into the calculation of rewards for validators. Under Ethereum’s proof-of-stake implementation, validators receive rewards every epoch (6.4 minutes) that are calculated as multiples of a “base reward.” [^34]The base reward is itself determined by the number of active validators on the network (the “total active stake”) and dynamically adjusted to incentivise a validator set of a desired size. [^35] The total amount of stake in the network is arguably the most impactful factor dictating rewards earned for validating transactions. [^36] Validators can earn a multiple of the base reward for attesting (or accurately voting) on (i) the correct source; (ii) the correct target; (iii) the correct head (collectively the “accuracy rewards”) of a block; and (iv) for having their attestation (their vote) included in a block (the “inclusion reward”). The inclusion reward is also split between the attesters and the validators that is chosen at random to produce a block. [^37] According to researchers, assuming a fixed base reward over time, the profits of a single validator are predominantly determined by the balance of ETH the validator has deposited in the network, which is capped at 32 ETH. [^38] Attesting with a higher balance results in larger rewards and penalties, and vice versa. [^39] On a finite timescale, a significant portion of validation rewards will also be determined by the random opportunities a validator receives to propose a block. [^38] #### 3bii2. Validators expect to earn staking rewards from their own actions, not from the “efforts of others” Analyzing the economic realities of staking ETH, a court should find that it does not meet the “efforts of others” prong of *Howey*. Staking rewards are primarily determined by a validator’s individual efforts and not dependent on any managerial efforts of a third party. As explained above, a validator’s rewards are largely determined by the amount of ETH they have staked and the random opportunities they receive to propose a block, both of which are idiosyncratic to the individual staker and do not depend on any third party. In other words, validators retain the ability to control the profitability of their investment. Applying the *Schaden test*,” [^40] a validator’s control is evidenced first by a lack of information asymmetries; rewards are distributed based on open-source protocol and transactions recorded on a public blockchain. The rewards are also determined based on the validator’s contribution of time and effort, as validators must maximize their up-time and remain connected to the network to avoid being slashed. While a validator is sometimes incentivized to have other validators join the network (*e.g.*, when it would result in an increase to the base reward), and depends on the actions of other validators to maximize rewards (*e.g.*, the requirement for an attestation to be propagated), a validator is never relying on “entrepreneurial” or “managerial” efforts requiring skill and judgment as required by *Howey*. ## 4. Conclusion As shown above, analyzing the economic realities of staking ETH on Ethereum’s proof-of-stake network, a court should find that staking fail to satisfy the *Howey* test because there is no “common enterprise” and validators are never relying on the “efforts of others”. While not the focus of this paper, there are also questions about whether depositing ETH to stake would qualify as an “investment of money.” And again, failure to meet any of the four *Howey* prongs would entail that the transaction is not an investment contract and therefore not a securities transaction. But beyond the legal analysis, applying the stringent requirements mandated by U.S. securities laws to staking would result in an ill-fitted and absurd application of the law. As we have noted, a raison d’être of securities regulation is to ameliorate information asymmetries that exist between promoters and investors through disclosure. Deeming the staking of ETH to be an investment contract would therefore entail imposing disclosure obligations on an “issuer” or “promoter.” As we stated above, no identifiable issuer or promoter exists when staking ETH. But if we accept the premise that validators play the role of a promoter or issuer, the clear unreasonableness of attending registration, reporting, and disclosure requirements becomes clear. Would securities laws mandate validators to provide *each other* with disclosure? What material information would validators be required to disclose? How would this help alleviate any information asymmetries, and how would it serve the public interest? The impracticality of answering these questions illustrates the flawed logic of applying securities laws to validators in the first place: they don’t pose the risks that disclosures are meant to address. ## Authors - Rodrigo Seira is Crypto Counsel at Paradigm. - Amy Aixi Zhang is Policy Counsel at Paradigm. - Jake Chervinsky is Head of Policy at the Blockchain Association, Advisor at Variant Fund, and Board Member at DeFi Education Fund. ## Disclosure This content is provided for informational purposes only, and should not be relied upon as legal, business, investment, or tax advice. Circumstances vary, and one should consult their own advisers and attorneys for advice. Certain information contained herein has been obtained from third-party sources. While taken from sources believed to be reliable, the authors have not independently verified such information and make no representations about the current or enduring accuracy of the information or its appropriateness for a given situation. References to any securities or digital assets are for illustrative purposes only, and do not constitute an investment recommendation or offer to provide investment advisory services. [^1]: See, e.g., Paul Kiernan and Vicky Ge Huang, “Ether’s New ‘Staking’ Model Could Draw SEC Attention,” Wall Street Journal (Sept. 15, 2022), available here [^2]: Securities Act of 1933 §5(a) [^3]: Securities Act of 1933 §2(a)(1) [^4]: SEC vs. W.J. Howey Co., 328 U.S. at 301 (1946) [^5]: See, e.g., SEC vs. W.J. Howey Co., 328 U.S. at 299 (1946) (defining the term “investment contract” to encompass “a flexible rather than a static principle, one that is capable of adaptation to meet the countless and variable schemes devised by those who seek to use the money of other on the promise of profits”) [^6]: See, e.g., United Housing Foundation, Inc. v. Forman, 421 U.S. 837 (1975) (holding that when viewed “in terms of their substance (the economic realities of the transaction)” shares of stock in a housing cooperative were not securities) and International Brotherhood of Teamsters v. Daniel, 439 U.S. 551 (1979) (holding that interests in a noncontributory, compulsory pension plan are not an investment contract and, hence, not a security) [^7]: See, e.g., Adam Levitin, Twitter (Jul. 23, 2022), available here. (“Something no one is talking about: after the Merge, there’s will be a strong case that Ether will be a security. The token in any proof of stake system is likely to be a security”) [^8]: While the SEC has argued that the first prong requiring an “investment of money” is typically satisfied (see Framework for “Investment Contract Analysis of Digital Assets” (modified Apr. 3, 2019), available here), the Supreme Court’s opinion in Howey evinces a narrower interpretation of “investment contract” that should not apply to the staking of ETH. While the Court notes that an “investment contract” is a flexible term that can apply to a variety of contracts, transactions and schemes, its purpose is to capture those “who seek the use of the money of others on the promise of profits.” When staking ETH, no investor is giving capital to any promoter or issuer because no promoter or issuer exists to use the money, or promise any profits [^9]: SEC vs. W.J. Howey Co., 328 U.S. 293 (1946). Despite the Supreme Court’s clear language in Howey, the SEC has taken the position that “common enterprise” is not a distinct element of the term “investment contract.” [^10]: See, e.g., Salcer v. Merrill Lynch, Pierce, Fenner & Smith, Inc., 682 F.2d 459 (3rd Cir. 1982); Milnarik v. M.S. Commodities, Inc., 457 F.2d 274 (7th Cir. 1972) [^11]: See, e.g., Mechigian v. Art Capital Corp., 612 F. Supp. 1421, 1427 (S.D.N.Y. 1985); Dooner v. NMI Limited, 725 F. Supp. 153, 159 (S.D.N.Y. 1989) [^12]: Revak v. SEC Realty Corp., 18 F.3d. 81, 87-88 (2d Cir. 1994). See also “‘[H [^13]: See, e.g., Howey, 328 U.S. at 300 (“The investors provide the capital and share in the earnings and profits; the promoters manage, control and operate the enterprise.”) [^14]: See, e.g., Hart v. Pulte Homes of Michigan Corp., 735 F.2d 1001, 1004 (6th Cir. 1984) (noting horizontal commonality requires “the fortunes of individual purchasers [to be [^15]: See, e.g., Hocking v. Dubois, 885 F.2d 1449, 1459 (9th Cir. 1989) (en banc) (horizontal commonality requires investors to “give up any claim to profits or losses attributable to their particular investments in return for a pro rata share of the profits of the enterprise”) [^16]: Adam Levitin, Twitter (Jul. 23, 2022), available here (“The common enterprise element is also readily met with staking: the whole validation system requires multiple parties. That’s the pooling (i.e., the more demanding interpretation of common enterprise—horizontal commonality). 4/”) [^17]: Adam Levitin, Twitter (Sept. 16, 2022), available here (“(2) Common enterprise: in PoS, the validators have to work cooperatively with other validators. A single node has to work with 127 others in a committee in ETH. That’s different than in PoW, where miners are competing, not cooperating. 3/”) [^18]: See Etherscan, “Contract 0x00000000219ab540356cBB839Cbe05303d7705Fa” (last visited Oct. 5, 2022), available here. See also, Ethereum, “Deposit Contract” (last visited Sept. 25, 2022), available here [^19]: See, e.g., Revak, 18 F.3d at 88 (holding that condominium owners using same rental agency had not pooled their funds because “rents and expenses attributable to each unit were not shared” among all owners.) [^20]: Id. [^21]: Id. at 81, 87-88 [^22]: See generally, Marc Boiron, “Sufficient Decentralization: A Playbook for web3 Builders and Lawyers,” available here [^23]: Revak, 18 F.3d at 88 [^24]: 328 U.S. at 298 (emphasis added) [^25]: Maritan v. Birmingham Props., 875 F.2d 1451, 1457 (10th Cir. 1989) [^26]: SEC v. Glenn W. Turner Enterprises, Inc., 474 F.2d 476 (9th Cir. 1973) (emphasis added); see also, SEC v. Koscot Interplanetary, Inc., 497 F.2d 473 (5th Cir. 1974) [^27]: SEC Strategic Hub for Innovation and Financial Technology, “Framework for ‘Investment Contract’ Analysis of Digital Assets,” (April 3, 2019), available here. (emphasis added) [^28]: See also Steinhardt Group, Inc. v. Citicorp, 126 F.3d 144, 152 (3rd Cir. 1997) (holding that due to limited partner’s “pervasive control over its investment in the limited partnership,” no investment contract is present); see also, Robinson v. Glynn, 349 F.3d 166 (4th Cir. 2003) (interests in limited liability company deemed not an investment contract do to investor’s active managerial input) [^29]: But see, Report of Investigation Pursuant to Section 21(a) of the Securities Exchange Act of 1934: The DAO (Exchange Act Rel. No. 81207) (July 25, 2017) (although DAO token holders had certain voting rights, they nonetheless reasonably relied on the managerial efforts of others); SEC v. Koscot Interplanetary, Inc., 497 F.2d 473, 483 n.15 (5th Cir. 1974) (“nominal or limited responsibilities to the [investor [^30]: Foxfield v. Robben 967 F.3d 1082 (10th Cir. 2020), articulating the “ability to control” Schaden factors test set forth in Avenue Capital Management II, L.P. v. Schaden, 843 F.3d 876 (10th Cir. 2016) [^31]: Adam Levitin, Twitter (Jul. 23, 2022), available here. (“The key is the switch from competition to cooperation in PoW to PoS. There’s lots of good things about that, but it has a securities regulation impact.”) [^32]: Adam Levitin, Twitter (Sept. 16, 2022), available here.(“(3) Expectation of profit from the efforts of others: in PoS the validators make or lose money based on successful (timely) validation. That requires the efforts of others in the committee. 4/”) [^33]: Vitalik Buterin et al, “Combining GHOST and Casper,” (May 20, 2020), available here. (“Committees: the validators are partitioned into committees in each epoch, with one committee per slot. In each slot, one validator from the designated committee proposes a block. Then, all the members of that committee will attest to what they see as the head of the chain (which is hopefully the block just proposed) with the fork-choice rule HLMD GHOST (a slight variation of LMD GHOST).”) [^34]: Pintail, “Beacon Chain Validator Rewards,” (last seen Sept. 23, 2022), available here [^35]: “If there aren’t many validators, the protocol needs to offer a high return, to encourage more validators to join. However if there is already a large number of validators, the protocol can afford to pay less, and save on issuance. The function which does this for the beacon chain is an inverse square root — that is, the level of the reward is divided by the square root of currently validating Ether (the reasoning for choosing an inverse square root relationship is explained in Vitalik Buterin’s design rationale document).” Id. [^36]: Ethereum Launchpad, “Validator FAQs,” (last visited Oct. 5, 2022), available here [^37]: “For every slot (a slot is 12 seconds — there are 32 slots in an epoch), one validator, chosen at random, is responsible for producing a block. The block is made up of beacon chain attestations submitted by the other validators, and the block producer is rewarded with a proportion of all the inclusion rewards from attestations in the block.” Pintail, “Beacon Chain Validator Rewards,” (last seen Sept. 23, 2022), available here [^38]: Pintail, “Beacon Chain Validator Rewards.” [^39]: Ethereum Launchpad, “Validator FAQs.” [^40]: Foxfield v. Robben 967 F.3d 1082 (10th Cir. 2020), articulating the “ability to control” Schaden test set forth in Avenue Capital Management II, L.P. v. Schaden, 843 F.3d 876 (10th Cir. 2016) ## https://www.paradigm.xyz/writing/open-sourcing-gobblers # Open Sourcing the Art Gobblers Smart Contracts > Today, we’re excited to announce that the Art Gobblers smart contracts are open source and available on our Github repo. # Introduction Today, we’re excited to announce that the [Art Gobblers](https://www.paradigm.xyz/2022/09/artgobblers) smart contracts are open source and on our [Github repo](https://github.com/artgobblers/art-gobblers). We hope the systems we’ve built will capture your imagination, and we can’t wait to see what you’ll build on top of them. # Diving into the Contracts In this post, we want to highlight a few of the interesting parts of the Art Gobblers codebase, like our custom ERC721 implementations, GOO integration, our progressive reveal system, and our approach to testing. ## Custom ERC721 Implementations ### GobblersERC721 Art Gobblers is significantly more complex than the average NFT project. Gobblers are sold using a [VRGDA](https://www.paradigm.xyz/2022/08/vrgda), and are paid for with a custom utility token (Goo). On top of this, each Gobbler is assigned an “emission multiple”, which determines the rate at which it continuously generates Goo tokens, using [GOO issuance](https://www.paradigm.xyz/2022/09/goo). Nevertheless, we wanted the gas costs of minting & transferring Gobbler NFTs to be one of the lowest in the industry. To achieve this, we built a [custom ERC721](https://github.com/artgobblers/art-gobblers/blob/master/src/utils/token/GobblersERC721.sol) implementation that makes heavy use of struct packing to remain efficient. We are able to fit all of the state associated with each gobbler and user in the mappings typically used for owner and balance information. For Gobbler state, we pack each Gobbler’s 160 bit owner address with 2 other variables: `idx` and `emissionMultiple`: ```solidity /// @notice Struct holding gobbler data. struct GobblerData { // The current owner of the gobbler. address owner; // Index of token after shuffle. uint64 idx; // Multiple on goo issuance. uint32 emissionMultiple; } ``` For owner state, we pack a 32 bit count of the gobblers owned by that user with 3 other variables related to GOO issuance: `emissionMultiple`, `lastBalance` and `lastTimestamp`: ```solidity struct UserData { // The total number of gobblers currently owned by the user. uint32 gobblersOwned; // The sum of the multiples of all gobblers the user holds. uint32 emissionMultiple; // User's goo balance at time of last checkpointing. uint128 lastBalance; // Timestamp of the last goo balance checkpoint. uint64 lastTimestamp; } ``` While under the hood all this data is packed together in one 256 bit slot, GobblersERC721 is still 100% compliant with the ERC721 interface, thanks to helper functions which expose the specific storage sections needed for `ownerOf` and `balanceOf` : ```solidity function ownerOf(uint256 id) external view returns (address owner) { require((owner = getGobblerData[id].owner) != address(0), "NOT_MINTED"); } function balanceOf(address owner) external view returns (uint256) { require(owner != address(0), "ZERO_ADDRESS"); return getUserData[owner].gobblersOwned; } ``` Additionally, GobblersERC721 also features optimizations that leverage fundamental invariants of the Art Gobblers system (no tokens will be minted to `address(0)`, the supply cap of `10,000`, etc) to remove redundant assertions. ### PagesERC721 Pages, while significantly less complex than Gobblers, also use a [modified ERC721](https://github.com/artgobblers/art-gobblers/blob/master/src/utils/token/PagesERC721.sol) implementation to improve improve gas costs and UX around feeding pages to gobblers. Primarily, Pages automatically skip approval checks when being transferred by the Gobblers contract to make gobbling a single shot process with no extra hassle. ```solidity function isApprovedForAll(address owner, address operator) public view returns (bool isApproved) { if (operator == address(artGobblers)) return true; // Skip approvals for the ArtGobblers contract. return _isApprovedForAll[owner][operator]; } ``` And, like Gobblers, Pages utilize known invariants of the Art Gobblers system to remove redundant assertions in their minting logic. ## Integrating GOO Gobblers generate Goo at a specified emission rate, which we discuss in [GOO paper](https://www.paradigm.xyz/2022/09/goo). Because Goo is generated continuously over time, goo balances need to be computed lazily. That is, a *virtual balance* is tracked which can be exchanged for a regular ERC20 balance at the user's convenience. Because this *virtual balance* is a function of the user’s total emission multiple, one has to make sure that it remains correct when transfers happen. For example, when a user transfers a gobbler away, their total emission multiple should go down (and so should their future emissions), but their current Goo balance should not change. In order to get around this, we overrode Gobbler’s transfer function to ensure that proper snapshots are taken of the user's state. ```solidity function transferFrom( address from, address to, uint256 id ) public override { ... snip ... unchecked { // Caching saves gas. uint32 emissionMultiple = getGobblerData[id].emissionMultiple; // Update the sending address's user data. getUserData[from].lastBalance = uint128(gooBalance(from)); getUserData[from].lastTimestamp = uint64(block.timestamp); getUserData[from].emissionMultiple -= emissionMultiple; getUserData[from].gobblersOwned -= 1; // Update the receiving address's user data. getUserData[to].lastBalance = uint128(gooBalance(to)); getUserData[to].lastTimestamp = uint64(block.timestamp); getUserData[to].emissionMultiple += emissionMultiple; getUserData[to].gobblersOwned += 1; } emit Transfer(from, to, id); } ``` Since virtual balances are used to keep track of Goo, we wanted to avoid purchases being a multi-transaction process. Normally, users would have to submit one transaction to turn their virtual balance into a regular ERC20 balance, one transaction to approve Gobblers as a Goo spender, and another transaction to purchase the items. To streamline this process, we modified the purchase functions in both Gobblers and Pages so that users are able to spend directly from their virtual balances, and set up permissions between contracts so that no additional approval transactions are required. ## Progressive Reveals The Art Gobblers mint and reveal process has some unique constraints. Our goal was for the process to be provably fair while remaining gas efficient. But since Gobblers will be mintable over a period of 10 years, waiting until the mint was over to do a full-collection reveal wasn't an option. In order to achieve this, we’ve implemented a highly optimized [batch reveal process](https://github.com/artgobblers/art-gobblers/blob/master/src/ArtGobblers.sol#L607) using a [Fisher-Yates Shuffle](https://en.wikipedia.org/wiki/Fisher%E2%80%93Yates_shuffle). This allow reveals to happen once per day, using Chainlink as our randomness provider. During the reveal process, this randomness is used to assign metadata to every unrevealed gobbler. This includes both a token ID as well as an emission multiplier sampled from a predefined distribution. ```solidity function revealGobblers(uint256 numGobblers) external { uint256 randomSeed = gobblerRevealsData.randomSeed; ... snip ... unchecked { for (uint256 i = 0; i < numGobblers; ++i) { ... snip ... // Randomly pick distance for swap. uint256 distance = randomSeed % remainingIds; // Select swap id, adding distance to next reveal id. uint256 swapId = currentId + distance; // Get the index of the swap id. uint64 swapIndex = getGobblerData[swapId].idx == 0 ? uint64(swapId) // Hasn't been shuffled before. : getGobblerData[swapId].idx; // Shuffled before. // Get the index of the current id. uint64 currentIndex = getGobblerData[currentId].idx == 0 ? uint64(currentId) // Hasn't been shuffled before. : getGobblerData[currentId].idx; // Shuffled before. // Swap indices getGobblerData[currentId].idx = swapIndex; getGobblerData[swapId].idx = currentIndex; ... snip ... } } ``` Thanks to some clever struct packing and various additional optimization, this process can be run in a gas efficient manner. We’ve also made our randomness provider upgradable (writing a thin [provider interface](https://github.com/artgobblers/art-gobblers/blob/master/src/utils/rand/RandProvider.sol) and [adaptors](https://github.com/artgobblers/art-gobblers/blob/master/src/utils/rand/ChainlinkV1RandProvider.sol)). This was necessary because we were unable to find a VRF provider that guaranteed service for the duration of the mint (approximately 10 years). ## Testing and Security We’ve made significant efforts to try to ensure the correctness of these smart contracts, including various forms of testings and audits. ### Testing We’ve written multiple unit tests and fuzz tests, leveraging [Foundry](https://www.paradigm.xyz/2022/03/foundry-02) as a testing framework. We’ve also made heavy use of differential fuzzing to test some of the more mathematically complex behavior. Implementations of VRGDAs and Goo have been written in python, and these implementations have been fuzzed against Solidity to ensure the outputs are equivalent: ```solidity function testFFICorrectness(uint256 timeSinceStart, uint256 numSold) public { ... snip ... // Calculate actual price from VRGDA. actualPrice = gobblers.getVRGDAPrice(toDaysWadUnsafe(timeSinceStart), numSold); // Calculate expected price from python script. uint256 expectedPrice = calculatePrice(timeSinceStart, numSold); // Equal within 1 percent. assertRelApproxEq(actualPrice, expectedPrice, 0.01e18); } function calculatePrice( uint256 timeSinceStart, uint256 numSold ) private returns (uint256) { string[] memory inputs = new string[](7); inputs[0] = "python3"; inputs[1] = "analysis/python/compute_price.py"; inputs[2] = "gobblers"; inputs[3] = "--time_since_start"; inputs[4] = timeSinceStart.toString(); inputs[5] = "--num_sold"; inputs[6] = numSold.toString(); return abi.decode(vm.ffi(inputs), (uint256)); } ``` We’ve also made use of use of advanced security tooling, like Slither for static analysis, and Z3 for automated [theorem proving](https://github.com/artgobblers/art-gobblers/blob/master/analysis/smt/goo_pooling.smt2), in order to verify some of our assumptions about the mechanism. ### Incentivized Play Testing It was also important for us to verify that Gobblers gameplay is balanced. We wanted to test whether there are any strategies that would allow players to end up with a disproportionate amount of the game’s resources (whether it’s Gobblers, Pages or Goo). In order to do this, we ran an incentivized play test, organized with some help from [Grug](https://twitter.com/CapitalGrug). We tuned the mechanism’s parameters to speed up gameplay by 30x, and invited a group of searchers and developers to play. We tasked them with trying to obtain as many Gobblers and as much Goo as they could, with Gobblers being given as prizes. ![Final standings of our incentivized play test](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--3f1c3be68a/d5cc00bd312acd675353a7b1123bc0aa/asset-https-cdn-sanity-io-images-dgybcd83--3f1c3be68a.png) *Final standings of our incentivized play test* This was an interesting experiment, and we were able to observe some [fun strategies emerge.](https://rinkeby.etherscan.io/address/0xb074b8bb11e07636dbd8d4a45b4369826886144f) We encourage developers building onchain games to include play testing as part of their development process. ### Audits and C4 Contest For audits, we underwent an internal review process by [samczsun](https://twitter.com/samczsun) and [Riley Holterhus](https://twitter.com/rileyholterhus). We also engaged Spearbit to conduct an audit of the protocol near the completion of its current development, which did not uncover any major vulnerabilities. We are also excited to announce that today, a one-week [audit contest](https://code4rena.com/contests/2022-09-art-gobblers-contest) is being kicked off with code4rena, with a $100,000 prize pool. We invite you all to participate and see what you can find. # Conclusion We are excited to share the Art Gobblers contracts with you, and are looking forward to see what you’ll build. If you have any projects in mind, we’d love to hear from you. You can reach us on twitter at [@FrankieIsLost](https://twitter.com/FrankieIsLost), [@transmissions11](https://twitter.com/transmissions11), [@_Dave__White_](https://twitter.com/_Dave__White_) and [@JustinRoiland](https://twitter.com/JustinRoiland). *Acknowledgments: *[*samczsun*](https://twitter.com/samczsun)*, *[*Riley Holterhus*](https://twitter.com/rileyholterhus)*, *[*Grug*](https://twitter.com/CapitalGrug)*, *[*Otto Suwen*](https://twitter.com/OttoSuwenNFT)*, *[*misaka*](https://twitter.com/0xmisaka)*, *[*Snoopy Mev*](https://twitter.com/snoopy_mev)*, *[*CuriousRabbit*](https://twitter.com/0xcuriousrabbit)*, *[*Will Price*](https://twitter.com/will__price)*, *[*Snarks*](https://twitter.com/0xSnarks)*, *[*Taarush*](https://twitter.com/taarushv)*, *[*Ben Leimberger*](https://twitter.com/ben_leimberger)*, *[*QTpie*](https://twitter.com/0xQTpie) [*Pluto*](https://twitter.com/homeslashpluto) *Graphics By: *[*Achal Srinivasan*](https://www.paradigm.xyz/team/achalsrinivasan) ## https://www.paradigm.xyz/writing/what-is-the-merge # What is the Merge? > The Ethereum network will soon undergo an update known as the Merge. The primary goal of the Merge is to transition Ethereum's consensus mechanism from a model known as proof-of-work (PoW) to one called proof-of-stake (PoS). **Summary** - The Ethereum network will soon undergo an update known as the Merge. - The primary goal of the Merge is to transition Ethereum’s consensus mechanism from a model known as [proof-of-work](https://ethereum.org/en/developers/docs/consensus-mechanisms/pow/) (PoW) to one called [proof-of-stake](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/) (PoS). - The move to PoS will usher in structural changes in how Ethereum transactions are processed, reduce Ethereum’s energy usage, and set a foundation for future network upgrades aimed at enhancing the blockchain’s throughput and scalability. The Merge is an extraordinary achievement in the history of crypto and open-source software development more generally. Although it took a number of years to implement PoS, the ultimate decision to change Ethereum’s consensus mechanism — and the roadmap for execution – was community driven. The fact that a decentralized group of actors worked together to manage a major upgrade of a live network is testament to the power of blockchains to incentivize trustless social coordination. **Background** Blockchains are a special type of shared database that take digital information and replicate it across multiple computers, called nodes, that make up a decentralized network. Certain nodes — called miners in PoW systems and validators in PoS systems — are responsible for maintaining the blockchain according to a fixed set of rules, known as the protocol, that define how and when the blockchain’s underlying data can be updated or changed. Since blockchains are designed to operate through code alone (*i.e.,* with no required connection to real-world identities or legal systems), there needs to be a mechanism built into the protocol that ensures that the nodes can only make legitimate updates to the blockchain’s data by adding blocks to the blockchain. This is known as the blockchain’s [consensus mechanism](https://ethereum.org/en/developers/docs/consensus-mechanisms/). *Proof-of-work consensus* [PoW](https://ethereum.org/en/developers/docs/consensus-mechanisms/pow/) consensus mechanisms require miners to expend computing resources (and, by extension, electricity) to compete against each other to solve a mathematical puzzle. The winner of the puzzle gets the right to make an update to the blockchain and is compensated with the blockchain’s native cryptocurrency through transaction fees and a block reward. [^1] Being paid in cryptocurrency provides the miners with direct monetary value and aligns the financial interests of miners with the goal of maintaining system integrity. If a miner wanted to rewrite the entire history of blockchain data, they would have to independently solve every past puzzle, which is effectively impossible using today’s computing technology. *Proof-of-stake consensus* [PoS](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/) consensus follows a different approach, but it also relies on economic incentives to ensure that validators do not behave badly. In a PoS system, validators make a refundable deposit in exchange for validation privileges. [^2] According to a fixed schedule, validators are randomly chosen to approve updates to the blockchain and are in turn compensated with cryptocurrency for their role in maintaining the network. If a validator does not faithfully fulfill its validation responsibilities, the cryptocurrency that it put at “stake” to become a validator could be slashed, causing a direct financial loss to the validator (and an additional loss of future earnings from validation that they will not participate in). *What’s in a name?* What makes the Merge so remarkable is the fact that such a large, complex, and consequential upgrade is happening on a network with zero downtime. To pull off this feat, the Ethereum community will actually combine two blockchains (which is where the name the Merge comes from): the Ethereum [Mainnet](https://ethereum.org/en/glossary/#mainnet) and the [Beacon Chain](https://ethereum.org/en/upgrades/beacon-chain/). In PoW systems, anyone with the right hardware and software can become a miner, or stop being one, whenever they please. Being selected to add a block to the blockchain is a function of randomness and computing power. PoS systems require more coordination for consensus because they need to keep track of validators’ stakes and manage the validator selection lotteries — coordination that can be managed with a separate blockchain. In anticipation of the move to PoS, the Ethereum community first created the Beacon Chain to serve as the future PoS “consensus layer” for Ethereum. Since its genesis in December 2020, the Beacon Chain has existed as a standalone blockchain running in parallel to the Mainnet. It has been going through the motions of PoS, but it has not been securing any actual transactional information from the Ethereum Mainnet. When the Mainnet reaches a predetermined point, it will automatically retire the PoW consensus mechanism and will begin using the Beacon Chain as its consensus layer for coordinating validator activity. The Mainnet will still exist as the Ethereum network’s execution layer, where transactions and any associated data are stored and updated/changed over time. Although they will be two separate blockchains, they will operate in concert as one. **Implications** The Merge has a number of implications for Ethereum and the broader crypto community. *The blockchain will become more energy efficient* PoS consensus changes Ethereum’s security model and relies on collateral to align validator incentives. As a result, the Ethereum Foundation [estimates](https://ethereum.org/en/upgrades/merge/) that Ethereum will use 99.5% less energy after the Merge. The Merge may also have implications for crypto geopolitics, as there will be less of an economic incentive to locate miners in jurisdictions with low energy costs and cool ambient temperatures. High-income countries are likely to benefit from this change in dynamics, however, the ultimate impacts are difficult to forecast with precision. One potential downside is that it could lead to a decrease in investment in renewable energy. In addition, analysts at [Morgan Stanley](https://www.coindesk.com/business/2022/06/27/morgan-stanley-gpu-demand-likely-to-slow-if-ethereum-moves-to-proof-of-stake/) have speculated that Ethereum’s move to PoS could blunt global demand for specialized computer chips used for PoW mining, known as graphics processing units (GPUs), which has further geopolitical implications related to manufacturing and industrial capacity. *It will be easier to make additional upgrades in the future aimed at further improving Ethereum’s scalability* Throughput and scalability concerns have plagued public blockchains since their introduction. As the Ethereum community grows and Ethereum projects experience broader adoption, blockspace will become increasingly important. Ethereum will need to implement scaling solutions in order to avoid network congestion and other knocks to efficiency. The Merge will put Ethereum further along its [long-term scaling plan](https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698) and will enable future scalability solutions that depend on PoS (to be covered in future Paradigm Policy posts). One set of solutions involves segmenting the blockchain into smaller pieces, called [shards](https://ethereum.org/en/upgrades/sharding/), where subsets of nodes are responsible for only a piece of the blockchain’s activity, instead of making every node verify every transaction. Another set of solutions — known as [“layer 2”](https://ethereum.org/en/layer-2/#:~:text=A%20layer%202%20is%20a%20separate%20blockchain%20that%20extends%20Ethereum.&text=A%20layer%202%20blockchain%20regularly,layer%201%20protocol%20(Ethereum).) solutions — involve moving some transaction computation off of the main Ethereum blockchain and onto separate blockchains that frequently sync back to the main blockchain for extra security. *The Ethereum development community has worked tirelessly over several years to reduce the transition risk of the Merge* For consumers holding ETH, there are no requirements to update software or hardware before the Merge. If you control an Ethereum account with ETH before the Merge, [the ETH will remain in your account](https://ethereum.org/en/upgrades/merge/#preparing-for-the-merge) after the Merge. Confusion over this point has led to a number of successful phishing schemes that have tricked users into giving away their ETH. There are, however, certain required software updates for users operating nodes. Operating a node involves running specialized software that communicates with the other nodes that maintain the blockchain. This software is typically referred to as a “client”. After the Merge, validators will need to run [both](https://ethereum.org/en/developers/docs/nodes-and-clients/) an execution layer client AND a consensus layer client in order to access the network. To mitigate the risk that faulty client software could disrupt the Merge, the Ethereum community has engaged in extensive testing and has undergone a sequential transition where client migration is phased in over time to mitigate the risk that a single error could derail the entire process. **Concluding thoughts** For policymakers, the Merge represents a novel proof of concept for a decentralized system. The Merge was the work of years by a broad community united not by corporate bonds or partisan political ends, but simply by the idea of a better system of operation. There was no CEO or Chairman of the Merge, or singular organization responsible for its success. Many doubted that such a project could be accomplished absent the structures of more traditional finance and government. Yet, the Merge has arrived. [^1]: The puzzle is difficult to solve, but once you have an answer it’s easy to prove to other people that you’ve found a valid answer, hence the name “proof-of-work” [^2]: When Ethereum switches to PoS, validators will be required to post 32 ETH in order to participate in validation ## https://www.paradigm.xyz/writing/artgobblers # Art Gobblers > Art Gobblers is a decentralized art factory owned by aliens. As artists make cool art, Gobblers gains cultural relevance, making collectors want the art more, incentivizing artists to make cooler art. It's also an on-chain game. # Introduction ## Overview Art Gobblers is a decentralized art factory owned by aliens. As artists make cool art, Gobblers gains cultural relevance, making collectors want the art more, incentivizing artists to make cooler art. It's also an on-chain game. ## Systems Art Gobblers are called Art Gobblers because they gobble art. In particular, they eat art that artists draw using our [draw tool](https://artgobblers.com/draw) and turn into 1/1 NFTs using in-game resources. All the artworks a Gobbler eats belong to it on-chain and are displayed in its belly gallery forever. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--36724793be/ebe7e2d3f156234bc2ddcd7bccbeb0fb/asset-https-cdn-sanity-io-images-dgybcd83--36724793be.png) Art Gobblers produce [Goo](https://www.paradigm.xyz/2022/09/goo) tokens, which are used to produce the blank pages needed to make art. Gobblers love the smell of their own goo, so the more Goo they have in their Goo tanks, the faster they squirt out more new Goo. The supply of Goo grows faster every day, starting at hundreds and eventually reaching billions and beyond. So, the game can't be balanced by giving items fixed prices in Goo. Instead, a mechanism called [VRGDA](https://www.paradigm.xyz/2022/08/vrgda) automatically adjusts prices over time to target a desired issuance schedule, adjusting prices up when sales are ahead of schedule, and down when sales are behind schedule. The protocol targets an initial Blank Page VRGDA issuance rate of 69 per day to foster experimentation, but eventually slows down to a constant 10 per day to ensure a high bar and focused attention from the community. The initial (free!) Gobbler mint consists of 2,000 fully animated Gobblers. Over the next 10 years, players will spend Goo to mint 8,000 more Gobblers using VRGDA. Issuance is relatively fast at first to bootstrap growth, but slows and eventually stops to preserve exclusivity. These systems can lead to some interesting gameplay, as players must decide when to trade Goo for Gobblers, changing the VRGDA price for everyone else. Legendary Gobblers, Goo-boosting 1/1s that can only be obtained by burning huge numbers of regular Gobblers, encourage large-scale collaboration. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--1beb20b156/ab8016905211819bd00a55a519820019/asset-https-cdn-sanity-io-images-dgybcd83--1beb20b156.png) ## Intentions The mechanisms making up the Art Gobblers experiment will be final at the time of mint, and no more will be built. They are intended to power a self-sustaining ecosystem capable of creating and collecting the coolest art in the universe without the need for human intervention. We hope: As artists make cool art, the cultural relevance of Art Gobblers will grow. As cultural relevance grows, Gobbler art will be in higher demand from collectors. As artists see higher collector demand, they will produce cooler art. Gobble on. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--942df1373b/075ddce35ae0f7d39c189c38db703630/asset-https-cdn-sanity-io-images-dgybcd83--942df1373b.png) # Design ## Art Art Gobblers exists to facilitate the creation and collection of the coolest art in the universe. Artists can create hand-drawn art using our [draw tool](https://artgobblers.com/draw/dad78c97-6ca9-4636-83cb-45e662b1d923), which works on desktop, iPad, or Cintiq. They’ve been making some pretty cool stuff already. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--732540eecd/32dfe34b4ad1dcf5f64bb0f8030963f1/asset-https-cdn-sanity-io-images-dgybcd83--732540eecd.png) The draw tool records the entire process of creation, and when you visit a work of art in the Art Gobblers webapp, you can play back the drawing process stroke by stroke. ## Pages Once Art Gobblers is live, artists will be able to mint their own drawings as 1/1 NFTs using in-game resources, a process we call *glamination*. These NFTs, which belong to the Art Gobblers Pages collection, are ERC721 NFTs that belong to the artist. Like any other NFT, they can be transferred or sold by the artist at will. Producing these art Pages is the main point of the Art Gobblers ecosystem. Because the number of Pages that can be created in a given period of time is limited by a [VRGDA](https://www.paradigm.xyz/2022/08/vrgda) mechanism, any art glaminated onto a Page will benefit from the cultural relevance of Art Gobblers and the attention of the Art Gobblers community, which has been seeded with some of the most accomplished collectors in the 1/1 space. In order to glaminate your drawing onto a Page, you need a *Blank Page* NFT, which can be created using *Goo.* ## Goo Goo, as described in [the GOO paper](https://www.paradigm.xyz/2022/09/goo), is an ERC20 Ethereum token emitted by Art Gobblers NFTs. Because Goo is needed to make new Blank Pages, Art Gobblers ultimately determine what art can be created in the ecosystem, and in that way serve as co-curators of a decentralized art gallery. Goo can also be used to create new Gobblers, giving players an interesting set of strategic decisions that we will discuss further in the Details section. ## Gobblers Art Gobblers themselves are fully animated ERC721 NFTs. As well as emitting Goo, they can, of course, gobble art. In particular, let’s say you own both an Art Gobbler and some cool art on a Page. If you feed that Page to your Gobbler, ownership of the Page transfers on-chain to the Art Gobblers contract, which has a mapping indicating which particular Gobbler that piece of art belongs to. That Page then becomes a permanent part of that Gobbler’s belly gallery, viewable through the Art Gobblers app. If you transfer your Gobbler, all of its gobbled works go with it. Collectors can curate their Gobblers however they choose. We can imagine a Gobbler containing only works by Justin, a Gobbler containing only pictures of dogs, a Gobbler full of autographs, a Gobbler containing a collaborative manga, and countless other possibilities. ## Collecting Without a Gobbler Given their limited supply and their in-game uses, Art Gobblers may be hard to come by. Collectors who can’t get their hands on a Gobbler will still be able to contribute to the ecosystem by collecting pages with art on them. Because Blank Pages are rare, by choosing which artists to support and even directly commissioning artists to draw on Blank Pages, even collectors without Gobblers will be able to make a serious contribution to the curation of the decentralized Gallery that is Art Gobblers. ## Legendary Gobblers The ten *Legendary Gobblers* are extravagantly rare one of one Gobblers that represent the supreme rulers of Gobbler civilization. They will arrive at specific predestined times over the next ten years, providing punctuated drama and a sense of structure over time to the game. In order to obtain a Legendary Gobbler, you must sacrifice a huge number of normal Gobblers. The first Legendary Gobbler will start at a price of 69 Gobblers, and will become cheaper using a standard Dutch Auction mechanism until it is purchased. Each successive Legendary Gobbler will start at a price in ordinary Gobblers equal to twice what the last Legendary Gobbler sold for. A new Legendary Gobbler appears each time an additional 10% of the total supply of Gobblers is issued via VRGDA, and each Legendary Auction is scheduled to end by the time the next Legendary Gobbler appears (or when all Gobblers are issued, in the case of the final Legendary). To compensate for the many Gobbler lives lost, Legendary Gobblers produce Goo at twice the rate of the combined Gobblers sacrificed to summon them. ## Roadmap There isn’t one. Art Gobblers will be launched as a finished product, designed to bootstrap a self-sustaining ecosystem. Neither Justin, nor Paradigm, nor the Art Gobblers team plan to build anything net new after the upcoming free mint. Art Gobblers is not stage one of the Gobblers metaverse. It is a whole and complete piece of alien technology that we will be unleashing upon an unsuspecting populace. What it does next, and how the inhabitants of Earth choose to aid it in its mission, is anyone’s guess. # Details ## Goo From [the GOO Paper](https://www.paradigm.xyz/2022/09/goo): Art Gobblers, from our upcoming NFT project, are NFTs that produce an Ethereum token called Goo. The more Goo a Gobbler has, the faster it generates more Goo. This means the total Goo supply will increase faster and faster every day, going from thousands to millions and beyond. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--8149f3f2c5/99831cb54c35c8a07bdd4c8b65d2b4eb/asset-https-cdn-sanity-io-images-dgybcd83--8149f3f2c5.png) Hoarding Goo tokens without owning any Gobbler NFTs is a very bad strategy, as everyone else will be generating goo and your share of the total Goo supply will rapidly dwindle to nothing. On the other hand, if you own many Gobblers but little Goo, your Goo production will lag compared to other players. But, let's say you maintain ownership of Gobbler NFTs with a combined Goo production capacity of 1% of the total and never remove your Goo. No matter how much Goo you start with, you will eventually end up with at least 1% of the total Goo supply! This ensures Goo stays in NFT holder control over the long term. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--0d74eeaade/a91909b8c5ebc860088950321675d594/asset-https-cdn-sanity-io-images-dgybcd83--0d74eeaade.png) Mathematically speaking, instantaneous Goo issuance is equal to $\\sqrt{\\texttt{mult}\\cdot\\texttt{goo in tank}}$, where a Gobbler’s $\\texttt{mult}$, or multiplier, is its base speed of squirting out Goo. We auto-compound Goo issuance over time using a differential equation, and also automatically balance Goo between gobblers if you have more than one. In this system, due to some extremely lucky math, it turns out that having many Gobblers with multipliers that add to $\\texttt{total mult}$ is the same as having a single Gobbler with a multiplier of $\\texttt{total mult}$, which means the game stays fair as some players obtain more Gobblers. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--444417a609/7341a7e2ebe01bbe05f144506c80fbcf/asset-https-cdn-sanity-io-images-dgybcd83--444417a609.png) ## VRGDA Because the Goo supply is increasing faster and faster every day, having fixed Goo prices for Gobblers or Pages would make no sense. A fair price for a Gobbler might be 69 immediately after mint, but 69,000 when the Goo supply has grown by several orders of magnitude. Instead, prices are set dynamically to make issuance of Gobblers and Pages track pre-determined schedules using a mechanism called VRGDA. From [the VRGDA paper](https://www.paradigm.xyz/2022/08/vrgda): Variable Rate GDAs (VRGDAs), designed for [Art Gobblers](http://www.artgobblers.com/) and used in [0xMonaco](https://twitter.com/transmissions11/status/1561100140160593920), let you sell tokens close to a custom schedule over time by raising prices when sales are ahead of schedule and lowering prices when sales are behind schedule — a generalization of the [GDA](https://www.paradigm.xyz/2022/04/gda) mechanism. \[…\] Imagine a simple schedule where we want to sell 10 NFTs per day. We set a starting price of 1 token for the first NFT. Suppose it is currently day 5, so we should have sold 50 NFTs. However, demand has been high, and we have sold 70. We weren’t supposed to sell 70 NFTs until day 7, so we are two days ahead of schedule. As a result, we want to charge a higher price going forward. We use an exponential curve to determine how much higher. This can vary based on parameters, but in this case, let’s say we use $2^\\text{days ahead of schedule}$, so that we increase our price by a factor $2^2=4$, so since our initial price was 1 token, the new price will be 4 tokens, making it harder to buy more NFTs. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--8ffa98de67/c778d6c2a98bef21944f3c22bc4a8141/asset-https-cdn-sanity-io-images-dgybcd83--8ffa98de67.png) Ten days later, on day 15, we should have sold 150 NFTs, but users have only bought 120, the amount they should have bought by day 12, meaning we are three days *behind* schedule. We adjust the price to $2^{-3}=0.125$, making it easier for users to buy more NFTs. Because your rate of Goo production depends on both how much Goo you have and how many Gobblers you have, spending Goo to get Gobblers presents a tradeoff. Furthermore, every time you spend your Goo to get Gobblers, you increase the Gobbler VRGDA price for every other player. This presents a complex strategy space that we saw play out on our 30x speed test net run (to be released soon). Once you add in the possibilities of DAOs and other forms of collaboration, especially as they interact with Legendary Gobblers, the scope for action becomes quite wide. ## Issuance Schedules ### Gobblers ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--196c4f9ae4/aa6f8d165d3d844d47daad906c89f344/asset-https-cdn-sanity-io-images-dgybcd83--196c4f9ae4.png) Art Gobblers themselves begin at a supply of 2,000, issued as a free mint. Of these, 300 go to the core team and the rest go to the community, a mixture of collaborators, artists, collectors, builders, contest winners, and others. Over the next ten years, an additional 8,000 Gobblers will be minted using a [logistic schedule](https://www.paradigm.xyz/2022/08/vrgda#logistic-issuance-schedule). At first, the protocol will issue roughly 200 Gobblers per month, but this will slow down over time. This pattern allows the community to grow quickly and bootstrap at first while avoiding over-inflation in the long term. Similarly to the [Nouns](https://nouns.wtf/) model, one in ten newly minted Gobblers will accrue to the team. An additional one in ten will go to a vault to be distributed to the community. ### Blank Pages ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--7d505f71a4/4265f171509b4fbbedd7f2a46c49a91b/asset-https-cdn-sanity-io-images-dgybcd83--7d505f71a4.png) No Blank Pages will exist at mint, but they can be created shortly after using Goo. The schedule calls for an initial creation rate of 69 pages per day to allow the community to experiment with art styles, memes, and more. Over the course of about 8 months, this issuance rate will slow down along a logistic curve until it hits a constant rate of 10 pages per day, which the protocol maintains forever. No Pages accrue directly to the team, but one in ten newly created pages do go to a vault to be distributed to artists in the community. ## Parameter Spreadsheet A spreadsheet containing parameters and issuance schedules can be found [here](https://docs.google.com/spreadsheets/d/1i8hYuWyAymjbwx54fA1HcEMEwfEEyluX4tPssOXoyf4/edit?usp=sharing). # Conclusion Art Gobblers is an experimental piece of alien technology. Only time will tell how the human world will react to it. But, you can begin using it and remixing it starting today. If you do, we’d love to hear from you. You can reach us on Twitter at [@transmissions11](https://twitter.com/transmissions11), [@FrankieIsLost](https://twitter.com/FrankieIsLost) and [@_Dave__White_](https://twitter.com/_Dave__White_). *Acknowledgments: *[*Matt Huang*](https://twitter.com/matthuang)*, *[*Arjun Balaji*](https://twitter.com/arjunblj)*, *[*Joanna7459*](https://twitter.com/Joanna7459)*, *[*Rodrigo Seira*](https://twitter.com/rssh273)*, *[*Reena Jashnani-Slusarz*](https://www.linkedin.com/in/reena-jashnani-slusarz-0262348)*, *[*Otto Suwen*](https://twitter.com/OttoSuwenNFT)*, *[*DCFPascal*](https://twitter.com/dcfpascal_)*, *[*0xmisaka*](https://twitter.com/0xmisaka)*, *[*johawa*](https://twitter.com/johawa1)*, *[*cygaar*](https://twitter.com/cygaar_dev)*, *[*Lib*](https://twitter.com/lib) ## https://www.paradigm.xyz/writing/goldfish # Goldfish: A Provably Secure Replacement for LMD GHOST in PoS Ethereum > The Merge: From Proof-of-Work to Proof-of-Stake The upcoming transition of Ethereum from proof-of-work (PoW) to proof-of-stake (PoS) is the culmination of years of research and development. # The Merge: From Proof-of-Work to Proof-of-Stake The upcoming transition of Ethereum from proof-of-work (PoW) to proof-of-stake (PoS) is the culmination of years of research and development. While PoS brings many potential advantages, it also means Ethereum is switching away from Satoshi Nakamoto’s longest-chain protocol---certainly one of the simplest and most elegant consensus protocols, and one that has been battle-tested for decentralized blockchains. A notoriously brittle component of Ethereum’s PoS consensus protocol has proven to be its “LMD GHOST” fork-choice rule, with multiple [recent](https://arxiv.org/abs/2110.10086) [attacks](https://arxiv.org/abs/2203.01315) [and](https://github.com/ethereum/consensus-specs/pull/2730) [patches](https://github.com/ethereum/consensus-specs/pull/2845), and no proof of its security. [In a new preprint titled “No More Attacks on Proof-of-Stake Ethereum?”](https://arxiv.org/abs/2209.03255), we propose *Goldfish*, a provably secure drop-in replacement for PoS Ethereum’s LMD GHOST fork-choice rule. We view this as just a first step towards more rigorous protocol design and analysis, with the goal of hardening Ethereum security. # Ethereum’s Proof-of-Stake Protocol Ethereum’s proof-of-stake (PoS) consensus protocol is considerably more complex than good ol’ PoW longest-chain. It is really a combination of *two* different consensus protocols: a "finality gadget" (called Casper FFG) that finalizes blocks after 6.4-minute-long epochs, and a "fork-choice rule" (called “latest message driven greedy heaviest observed sub-tree”, “LMD GHOST” for short) that governs the chain within each epoch. If you are curious “why?”, [check out this talk](https://youtu.be/2nMS-TK_tMw). The two components interact in a non-trivial way with each other, here depicted in a block diagram: ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--78675eddf8/fad84d5314c4ac4427069127e0b1e60e/asset-https-cdn-sanity-io-images-dgybcd83--78675eddf8.png) Specifically, LMD GHOST guides the block production process, and operates on a time scale of *slots* of 12 seconds and with *subsampled* committees of validators. It can thus be thought of as in charge of weaker “short-term consensus” near the tip of the PoS Ethereum blockchain. Once short-term consensus on the transaction ledger has been reached, it is handed over to Casper FFG for additional hardening, which operates on a time scale of *epochs* comprising 32 slots = 6.4 minutes and involves the *full* validator set. Thus, Casper FFG is responsible for stronger “long-term consensus” providing finality and accountable safety. Unfortunately, this complexity comes with challenges. In particular, the LMD GHOST component, and the interaction between LMD GHOST and Casper FFG, both have a history of whack-a-mole going back and forth between attacks and patches. The protocol currently set for adoption with the Merge has neither a publicly known attack, nor a formal security analysis/proof. The lack of security proof is reason for concern, but not because a proof in a simplistic academic model would necessarily be perfectly indicative of real-world security. Rather, the fact that we cannot explain conclusively why this protocol is supposedly secure, *even in a simplistic toy model*, suggests that we don’t actually *understand* the protocols, or the full scope of their consequences and interactions. # Goldfish [In a recent preprint titled “No More Attacks on Proof-of-Stake Ethereum?”](https://arxiv.org/abs/2209.03255), we provide a drop-in replacement for PoS Ethereum’s LMD GHOST fork-choice rule. This protocol, called *Goldfish*, is similar to LMD GHOST (and thus would not require a massive overhaul of the current client implementations), but comes with a security proof. To understand Goldfish better, let’s first zoom into how LMD GHOST roughly works: ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--0905ade390/c4a3225385ec0e8092ce4ba20586e738/asset-https-cdn-sanity-io-images-dgybcd83--0905ade390.png) Suppose the delay incurred by messages in our toy network model is at most a known value $\\Delta$. In LMD GHOST, time proceeds in synchronized slots of $2\\Delta$ time. For each slot, one proposer and a small committee of validators are randomly selected from the full validator set. At the beginning of each slot, the slot’s proposer runs the LMD GHOST fork-choice rule (with two modifications, \[“proposer boost”\](https://github.com/ethereum/consensus-specs/pull/2730) and \[“equivocation discounting,”\](https://github.com/ethereum/consensus-specs/pull/2845) that are patches in response to two \[earlier\](https://arxiv.org/abs/2110.10086) \[attacks\](https://arxiv.org/abs/2203.01315)) to determine a canonical blockchain tip and propose a new block. Halfway into the slot, the slot’s committee members also determine a canonical blockchain tip using the same fork-choice rule, and cast a vote in favor of this tip. LMD GHOST does not specify a confirmation rule, but leaves it up to the user to decide which blocks of the blocktree have “enough” votes to be confident that they will not leave the canonical chain. Goldfish follows this general structure closely, but introduces an additional phase for validators to synchronize their views on the vote counts, and to confirm blocks: ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--1389ce76a0/008f2a687cc19d011dcdf574c365bd76/asset-https-cdn-sanity-io-images-dgybcd83--1389ce76a0.png) At the beginning of each slot, the slot’s proposer runs the simple GHOST fork-choice rule based on votes from the previous slot, to determine where to propose a block. One-third into the slot, the slot’s committee members use the same fork-choice rule based on votes from the previous slot and votes relayed by the proposer, to determine where to cast their vote. Finally, two-thirds into the slot, all validators run a clearly defined $T$-deep confirmation rule. Goldfish is based on two key techniques, *vote buffering* and *vote expiry*, to carefully synchronize honest validators’ views: - *Vote buffering* (also known as [*view merge*](https://ethresear.ch/t/change-fork-choice-rule-to-mitigate-balancing-and-reorging-attacks/11127)) first appeared in [Highway](https://arxiv.org/abs/2101.02159). In short, buffering of votes received from the network together with carefully-timed inclusion of these votes in each validator’s local view guarantees that in slots with an honest proposer, all honest validators vote in favor of the proposer’s proposal. This leads to reorg resilience: honest proposers’ proposals are guaranteed to remain in the canonical chain. Security (i.e., safety and liveness of the output ledger) ensues. - *Vote expiry* (also known as *ephemeral votes*) means that during each time slot only votes from the immediately preceding time slot affect the protocol’s behavior. (The alleged forgetfulness of its animal namesake gives the Goldfish protocol its name.) Vote expiry keeps the set of votes small that might affect short-term future actions of honest validators. Thus, only a few protocol messages need to be buffered and merged among honest validators’ views at any point in time. *Vote expiry is thus a prerequisite for the efficiency/feasibility of vote buffering.* Vote expiry is also crucial to support fluctuating levels of validator participation, and to support running the protocol among a *smaller subsampled* committee of voters per slot, rather than across the *full* validator set. Finally, Goldfish’s confirmation rule confirms blocks if they are still on the canonical chain some time after their creation. Analysis shows that the resulting confirmation reversal probability decays exponentially in the delay between block production and block confirmation. For more details on Goldfish and its security analysis, check out [our preprint](https://arxiv.org/abs/2209.03255). # A Challenge for Goldfish: Asynchrony Goldfish is simple enough to admit a rigorous security proof. And this analysis immediately bears fruit: Remember we assumed at the outset that the network delay in our toy model would be upper-bounded by $\\Delta$. In the process of proving security, we were forced to make this and other assumptions explicit. What happens if this bound is violated, i.e., if the network is temporarily asynchronous? We can trace the steps of our security argument, and see what breaks without the assumption. We see that if the actual network delay was longer than $2\\Delta$ (i.e., 8 seconds in current PoS Ethereum), then Goldfish will not receive the decisive votes of slot t - 1 in time to build on them in slot* t*. The protocol could suffer from a reorg. Such a reorg is bad; but at least thanks to the rigorous security argument, we have better insight into what conditions the security of our system critically depends upon, and why, and how. We can make more informed decisions to ensure that these prerequisites are met. For instance, while in current peer-to-peer networking protocols an adversary can probably induce some network delay more easily, there has been renewed interest recently (also due to \[networking related challenges with data availability sampling\](https://www.paradigm.xyz/2022/08/das)) in hardened peer-to-peer gossip protocols that reuse the consensus layer’s stake distribution to guide peer selection. Such protocols are more robust and could plausibly alleviate the delay problem. Furthermore, the finality/accountability gadget (which might eventually be further sped up with \[“single slot finality”\](https://notes.ethereum.org/@vbuterin/single_slot_finality)) provides a backstop to any reorgs. # What Remains to be Done We’ve proposed the Goldfish consensus protocol, which is designed to serve as a drop-in replacement for LMD GHOST in the PoS Ethereum beacon chain. [In the preprint](https://arxiv.org/abs/2209.03255), we give a rigorous security analysis of Goldfish by itself, as well as in combination with a [finality](https://www.computer.org/csdl/proceedings-article/sp/2021/893400a768/1t0x8EdnqoM)/[accountability](https://arxiv.org/abs/2105.06075) gadget (based on another consensus protocol, such as HotStuff). Other PoS Ethereum consensus security challenges remain, e.g., from the interactions of fork-choice and finality gadget, as detailed in [Section 6.1 of our preprint](https://arxiv.org/abs/2209.03255). We look forward to seeing further consensus security improvements on these fronts for PoS Ethereum in the future! If you are working on (or interested to work on) any of these directions, we would love to hear from you! You can reach us on Twitter at [@fradamt](https://twitter.com/fradamt), [@jneu_net](https://twitter.com/jneu_net), [@ErtemTas](https://twitter.com/ErtemTas), and [@dntse](https://twitter.com/dntse). *Acknowledgments: Special thanks to Aditya Asgaonkar, Carl Beekhuizen, Vitalik Buterin, Justin Drake, Dankrad Feist, Sreeram Kannan, Georgios Konstantopoulos, Barnabé Monnot, Dan Robinson, Danny Ryan, and Caspar Schwarz-Schilling for fruitful discussions, and to Achal Srinivasan for the beautiful illustrations.* ## https://www.paradigm.xyz/writing/goo # GOO (Gradual Ownership Optimization) > GOO aligns fungible and non-fungible token incentives. # Introduction When NFT projects have a fungible token, the communities holding the NFT and the token tend to diverge over time. We created a mechanism to disincentivize this divergence, and to repair it when it happens anyway. We call it Gradual Ownership Optimization, or GOO. Art Gobblers, from our upcoming NFT project, are NFTs that produce an Ethereum token called Goo. The more Goo a Gobbler has, the faster it generates more Goo. This means the total Goo supply will increase faster and faster every day, going from thousands to millions and beyond. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--7777e677dc/271567270f3c65e2eeca2795985d65fe/asset-https-cdn-sanity-io-images-dgybcd83--7777e677dc.png) Hoarding Goo tokens without owning any Gobbler NFTs is a very bad strategy, as everyone else will be generating goo and your share of the total Goo supply will rapidly dwindle to nothing. On the other hand, if you own many Gobblers but little Goo, your Goo production will lag compared to other players. But, let's say you maintain ownership of Gobbler NFTs with a combined Goo production capacity of 1% of the total and never remove your Goo. No matter how much Goo you start with, you will eventually end up with at least 1% of the total Goo supply! This ensures Goo stays in NFT holder control over the long term. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--8abec34a5b/c4bd47dd78b8a5a1ca33427c2bbe7599/asset-https-cdn-sanity-io-images-dgybcd83--8abec34a5b.png) Mathematically speaking, instantaneous Goo issuance is equal to $\\sqrt{\\texttt{mult}\\cdot\\texttt{goo in tank}}$, where a Gobbler’s $\\texttt{mult}$, or multiplier, is its base speed of squirting out Goo. We auto-compound Goo issuance over time using a differential equation, and also automatically balance Goo between gobblers if you have more than one. In this system, due to some extremely lucky math, it turns out that having many Gobblers with multipliers that add to $\\texttt{total mult}$ is the same as having a single Gobbler with a multiplier of $\\texttt{total mult}$, which means the game stays fair as some players obtain more Gobblers. where a Gobbler’s *mult*, or multiplier, is its base speed of squirting out Goo. We auto-compound Goo issuance over time using a differential equation, and also automatically balance Goo between gobblers if you have more than one. In this system, due to some extremely lucky math, it turns out that having many Gobblers with multipliers that add to *total mult *is the same as having a single Gobbler with a multiplier of *total mult*, which means the game stays fair as some players obtain more Gobblers. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--1ea8f62b9c/2293c4550ffe36a1ed335bdb3170fe41/asset-https-cdn-sanity-io-images-dgybcd83--1ea8f62b9c.png) While designed for Art Gobblers, this mechanism is applicable to any NFT ecosystem with a fungible token. It keeps NFT and token holders aligned while ensuring the primary importance of the NFT itself. It’s also fun, especially when combined with other mechanisms like [VRGDA](https://www.paradigm.xyz/2022/08/vrgda). In this paper, we break down the details of the mechanism and provide production-ready code so you can use it in your own project. # Motivation ## Current Types of NFT Fungible Token Issuance There are currently two primary ways that NFT projects issue fungible tokens: 1. *Airdrop.* At some particular point in time, all holders of the NFT receive an amount of fungible tokens proportional to the number of NFTs they hold. 2. *Constant emission.* Each NFT emits a roughly constant number of tokens over time. One constant emission method is *staking*, where NFT holders lock their NFT in a contract and receive some constant number of tokens each day. Another approximately constant emission method is Play to Earn, where users who own or have access to a given NFT can play a game with the possibility of earning a number of tokens every day, depending on how they play. ## The Problem In both of these cases, the population of people holding the NFT can become quite different from the population of people holding the fungible token over time. In the case of an airdrop, as some users sell their NFTs without selling their tokens, and others sell their tokens without selling their NFTs, token and NFT ownership falls out of alignment, and no force exists to bring it back in line. Even with constant emission, because fungible tokens are issued at a constant rate, it can be practically impossible for NFT and fungible token ownership to come back into alignment over time: every day, new tokens issued represent a smaller and smaller percentage of the overall supply. Furthermore, no matter how much of the fungible token you have, there is no incentive to match it with a comparable amount of NFTs, and visa versa. Once the populations of NFT and token holders diverge, nothing realigns them. ## Other Requirements for a Solution We wanted to make sure that Goo was purely a utility token, and that the Art Gobblers NFTs themselves would remain the anchor of the economy. We also wanted our solution to be extremely gas efficient, easy for NFT community members to understand, and, most importantly, fun to use. # Mechanism ## Overview All the Art Gobbler NFTs belonging to a given Ethereum account squirt Goo into a Goo tank associated with that account. The owner of that address can add or remove Goo from that tank at any time. Art Gobblers squirt out Goo at a rate proportional to the square root of the Goo already in their tanks. Each gobbler has its own $\\texttt{mult}$, which describes its base rate of goo squirting. We automatically compound this instantaneous issuance using a differential equation, lazily evaluated so that compounding can occur over arbitrarily long time periods without any need to spend gas. Goo inflates quadratically over time, significantly slower than the exponential inflation common to most token staking schemes. Because Goo issuance is at its optimum when Goo is held in proportion to a user’s Gobblers, users are incentivized to hold Goo and Gobblers in proportion. Because the overall rate of Goo emission is always increasing, these incentives remain strong regardless of how much Goo has already been issued. Due to some very fortunate math, having many Gobblers whose multiplier sums to a given total is the same as having a single Gobbler whose multiplier is equal to that total, ensuring the system stays fair even if some users accumulate large numbers of Gobblers. ## Definitions $m_i$ - Gobbler $i$’s Goo emission multiple $g_i(t)$ - the amount of Goo in Gobbler $i$’s tank at time $t$ $\\texttt{initial Goo}_i$ - how much Goo Gobbler $i$ has at time 0 For convenience, we will use $g(t)$, $m$, and $\\texttt{initial Goo}$ without the subscripted $i$ when referring to only a single Gobbler. ## Goo Issuance Art Gobblers emit Goo at an instantaneous rate of $\\sqrt{mg(t)}$ . We picked square root issuance to ensure that Gobblers are more fundamental than Goo — the more Goo you add to a given Gobbler’s tank, the less each new unit of Goo increases that gobbler’s instantaneous Goo issuance. That means users cannot game the system by placing a massive amount of Goo in a single Gobbler’s tank. For example, at time 1, if $m$ is 2, and $g(1)$ is 2, then instantaneous Goo issuance would be $\\sqrt{2\\cdot2}=\\sqrt{4}=2$ Goo per day. Expressed mathematically, we have the following differential equation: $$ g'(t) = \sqrt{mg(t)} $$ [Solving](https://www.wolframalpha.com/input?i=solve+s%27%28t%29+%3Dsqrt%28m+*+s%28t%29%29+%2C+s%280%29+%3D+z) it yields $$ g(t)=\frac{1}{4}(\sqrt{m} t + 2\sqrt{\texttt{initial Goo}})^2 $$ and expanding, we get $$ g(t) =\frac{1}{4}mt^2+\texttt{initial Goo}+t\sqrt{m\cdot\texttt{initial Goo}} $$ Note we assume for convenience that time always starts at 0, while in production one must track the time elapsed since the last interaction with the contract. ## Optimizing Goo Production Across Gobblers Imagine you have 4 Goo and 2 Gobblers, one with a $\\texttt{mult}$ of 1 and one with a $\\texttt{mult}$ of 3. You want to decide how to distribute your Goo between them so as to maximize your rate of Goo production. If you had to put all of your Goo in only one Gobbler’s tank, it would obviously be better to put it in the tank of the Gobbler with the of 3, for an instantaneous production rate of $\\sqrt{3\*4}=2\\sqrt{3}\\approx3.5$. However, splitting your Goo evenly between the Gobblers is even better, for a production rate of $\\sqrt{1\\cdot2}+\\sqrt{3\\cdot2}=\\sqrt{2}+\\sqrt{6}\\approx3.9$. But it turns out we can do even better. For any group of Gobblers with multipliers $m_i$, [it turns out](https://math.stackexchange.com/questions/4143794/finding-maximum-of-sum-of-square-roots) that the optimal way to distribute Goo between them is by allocating $\\frac{m_i}{\\sum_{j=0}^n m_j}$ of the total Goo to each. In this case, we would allocate $\\frac{1}{4}\\cdot4=1$ Goo to the first Gobbler and $\\frac{3}{4}\\cdot4=3$ Goo to the second Gobbler, for a total instantaneous Goo production of $\\sqrt{1\*1}+\\sqrt{3\*3}=1+3=4$ ## Goo Stays Optimized This would be an interesting but not particularly helpful result if users had to constantly rebalance their Goo between multiple Gobblers to keep them producing optimally. Fortunately, once balanced, Gobblers stay balanced! To see why, notice that, by definition, at the time of balancing, $$ \texttt{initial Goo}_i=\frac{m_i}{\sum_j{m_j}}\texttt{total initial Goo} $$ If we introduce a new constant $c=\\frac{\\texttt{total initial Goo}}{\\sum_jm_j}$for convenience, we get $$ \texttt{initial Goo}_i=m_ic $$ And plugging that into the definition of $g_i(t)$ above, we get $$ g_i(t)=\frac{1}{4}(\sqrt{m_i} t + 2\sqrt{\texttt{initial Goo}})^2=\frac{1}{4}(\sqrt{m_i} t + 2\sqrt{m_ic})^2 $$ and, simplifying, $$ g_i(t)=\frac{m_i}{4}(t + 2\sqrt{c})^2 $$ Since this is true for all $i$ we see that regardless of the value of $t$, the Goo is distributed between gobblers proportionally to their multipliers, which is precisely the condition we need to maintain optimal Goo production. ## Goo Production from Multiple Gobblers This means we can automatically balance Goo between Gobblers for users only once, and they will stay balanced. Even so, if the resulting rate of Goo production was complicated or hard to understand, the overall system wouldn’t be especially satisfying or fun, and users might not know how to interact with it. Fortunately, that is not the case. [It turns out](https://math.stackexchange.com/questions/4143794/finding-maximum-of-sum-of-square-roots) that, when Goo is optimally balanced between Gobblers with multiples $m_i$ the total rate of Goo production is the same as the rate of Goo production from a single Gobbler with a mult of $\\sum_{j=0}^nm_j$ -- in other words, having multiple Gobblers with a $\\texttt{mult}$ sum of 100 is the same as having a single Gobbler with a $\\texttt{mult}$ of 100. Returning to our original example, we can verify manually that this is the case. When we optimally balance our 4 Goo between our two gobblers with mults 1 and 3 and achieve an instantaneous output of 4, it is the same as putting the 4 Goo in the tank of a single gobbler with a $\\texttt{mult}$ of 1+3=4 to achieve an output of $\\sqrt{4\\cdot4}=4$. We can see the same would still be true if we had four Gobblers, each with a mult of 1, for a total output of $\\sqrt{1\\cdot1}+\\sqrt{1\\cdot1}+\\sqrt{1\\cdot1}+\\sqrt{1\\cdot1}=4$. This end result — that having several Gobblers whose $\\texttt{mult}$s sum to 10 is the same as having one Gobbler with a mult of 10 — is both very intuitive and very fortunate, since otherwise users could manipulate the rate of Goo production by changing their allocations of Gobblers between wallets. ## Incentives Because Goo inflates quadratically, holding it without holding Gobblers is a grave mistake, as you will not generate any more Goo, and your proportion of the overall supply will rapidly dwindle. Furthermore, we can see from the auto-balancing section above that the optimal rate of Goo production across the ecosystem is achieved when Goo is distributed proportionally to $\\texttt{mult}$. So if you have many Gobblers but very little Goo, your production of Goo will lag behind the field’s, and you will be outcompeted. As a result, users are incentivized to keep their Goo and Gobbler holdings roughly in line. More formally, let’s say you own a collection of gobblers with a total multiplier of $M$. If you never remove any of your Goo from its collector, from the definition of $g(t)$ we can see that eventually your Goo supply will be approximately equal to $\\frac{M}{4}t^2$, the only quadratic term. Let’s say that all Gobblers combined have a total multiple of $Q$. If Goo is perfectly balanced between all the other Gobblers, eventually their Goo supply will be approximately equal to $\\frac{Q-M}{4}t^2$, so that the total Goo supply will be proportional to $\\frac{Q}{4}t^2$, and your proportion of it will be $\\frac{M}{Q}$, the proportion of total $\\texttt{mult}$ you own. If Goo is *not* perfectly balanced between the other Gobblers, your proportion of the total Goo will actually be greater than your proportion of the total $\\texttt{mult}$. Of course, this is only the case if the total $\\texttt{mult}$ is remaining constant over time, which it may not depending on how the rest of the system works. Otherwise, you may have to take action to ensure your share of the total $\\texttt{mult}$ remains constant. # Code A highly optimized, production ready, and permissively licensed (MIT) implementation of GOO can be found at [transmissions11/goo-issuance](https://github.com/transmissions11/goo-issuance). Pull requests with improvements are welcome. # Conclusion GOO was designed for Art Gobblers, but we believe it is applicable to a wide variety of NFT projects and on-chain games. If you want to issue a fungible token from an NFT while ensuring users hold the NFT and the token roughly in proportion, GOO may be for you. If you are interested in integrating GOO into your project, we’d love to hear from you. You can reach us on Twitter at [@_Dave__White_](https://twitter.com/_Dave__White_), [@FrankieIsLost](https://twitter.com/FrankieIsLost) and [@transmissions11](https://twitter.com/transmissions11). ## https://www.paradigm.xyz/writing/das # Data Availability Sampling: From Basics to Open Problems > The purpose of this blog post is to explain the basics of data availability sampling (DAS), the model upon which it rests, and challenges and open problems when it comes to implementing the technique in practice. # Introduction A core responsibility of any layer-1 blockchain is to guarantee *data availability*. This guarantee is essential for clients to be able to interpret the layer-1 blockchain itself, and also as a foundation for higher-layer applications like rollups. For this purpose, an oft-discussed technique is *random sampling for data availability verification*, as popularized by [a paper by Mustafa Al-Bassam, Alberto Sonnino, and Vitalik Buterin](https://arxiv.org/abs/1809.09044) in 2018. This technology is at the core of the Celestia blockchain, and proposed for inclusion in proof-of-stake (PoS) Ethereum with “Danksharding.” The purpose of this blog post is to explain the basics of data availability sampling (DAS), the model upon which it rests, and challenges and open problems when it comes to implementing the technique in practice. We hope that this post can “pill” researchers, attract them to the problem, and spur new ideas towards solving some of the outstanding challenges (cf. [this recent Request for Proposals of the Ethereum Foundation](https://github.com/ethereum/requests-for-proposals/blob/master/open-rfps/das.md)). # The Problem Somebody (such as a layer-1 block proposer or layer-2 sequencer) has produced a block of data. They claim to have made it “available” to the “public.” Your goal is to check the availability claim, i.e., would you actually be able to obtain the data if you needed to? Availability of data is crucial. Optimistic fraud-proof-based systems, like [Optimism](https://www.paradigm.xyz/2021/01/how-does-optimisms-rollup-really-work), require data availability for verification, and even validity-proof-based systems, like [StarkNet](https://starkware.co/starknet/) or [Aztec](https://aztec.network/), require data availability to ensure liveness (e.g., to prove asset ownership for a rollup’s escape hatch or forced transaction inclusion mechanism). For the problem formulation so far, there is an easy “naive” testing procedure, which earlier systems like Bitcoin implicitly adopt: just try to download the entire block of data. If you succeed, you know it is available; if you do not succeed, you consider it unavailable. Now, however, we want to test for data availability *without downloading too much data ourselves*, e.g., because the data is larger than we can handle, or because it seems wasteful to spend a lot of bandwidth on data we aren’t actually interested in, “only” to verify its availability. At this point we need a model to clarify what it “means” to download or withhold only “part of the data.” # The Model A common approach in computer science is to first describe a new technique in a model that has rather generous facilities; and to subsequently explain how that model can be realized. We take a similar approach with DAS, except, as we will see, interesting open R&D problems pop up when we attempt to instantiate the model. In our model, there is a bulletin board in a dark room (see comic below). First, the block producer enters the room and gets the opportunity to write some information on the bulletin board. As the block producer exits, it can give you, the validator, a tiny piece of information (of size that does not scale linearly with the original data). You enter the room with a flashlight that has a very narrow light beam and is low on battery, so you can only read the writing on very few distinct locations of the bulletin board. Your goal is to convince yourself that indeed the block producer has left enough information on the bulletin board so that if you were to turn on the light and read the complete bulletin board, you would be able to recover the file. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--3d611c2b4f/29b6b20347db208424cc3cf021829caf/asset-https-cdn-sanity-io-images-dgybcd83--3d611c2b4f.png) At first, this seems tricky: We can ask the block producer to write down the complete file on the bulletin board. Now consider two possibilities: Either the producer behaves honestly and writes down the complete file, or the producer misbehaves and leaves out some tiny chunk of the information, making the file as a whole unavailable. By inspecting the bulletin board at only a few locations, you cannot distinguish these two scenarios reliably—thus, you cannot check for data availability reliably. We need a new approach! # The (Theoretical) Solution This is where erasure correcting Reed-Solomon codes come into play. Let’s take a brief detour to recap those. On a high level, an erasure correcting code works like this: A vector of $k$ *information chunks* gets encoded into a (longer!) vector of $n$ *coded chunks*. The *rate **$R = k/n$* of the code measures the redundancy introduced by the code. Subsequently, from certain subsets of the coded chunks we can *decode* the original information chunks. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--316b6fee09/4bfe488fcac16837f68ac384f01697fd/asset-https-cdn-sanity-io-images-dgybcd83--316b6fee09.png) If the code is *maximum distance separable* (MDS), then the original $k$ information chunks can be recovered from any subset of size $k$ of coded chunks, a useful efficiency and robustness guarantee. Reed-Solomon codes are a popular family of MDS codes, and work as follows. Remember in school you probably learned that two points uniquely determine a line: ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--c7aaee13ef/c98bbb61692635a7240bfea3ac5fe47b/asset-https-cdn-sanity-io-images-dgybcd83--c7aaee13ef.gif) This is because a line can be described as a polynomial of degree 1 with two coefficients: $y = a_1 x + a_0$ (let’s assume for now that the points have distinct x-coordinates). In fact, this insight can be generalized: Any polynomial of degree $t-1$, which corresponds to the set of coefficients $\\{a_i\\}_{i=0}^{t-1}$ that describe the polynomial $f(X) = \\sum_{i=0}^{t-1} a_i X^i$, is uniquely determined by any $t$ points the polynomial passes through (with distinct x-coordinates). In other words: Once you know the polynomial’s evaluation at $t$ distinct locations, you can obtain its evaluation at any other location (by first recovering the polynomial, and then evaluating it). Reed-Solomon codes are built from this insight. For encoding, we start with the $k$ information chunks $\\{a_i\\}_{i=0}^{k-1}$, construct the associated polynomial $f(X) = \\sum_{i=0}^{k-1} a_i X^i$, and evaluate it at $n$ distinct x-coordinates, to obtain the coded chunks. Now, because of the above insight, any $k$ of these coded chunks allow us to uniquely recover the polynomial of degree $k-1$, and read off the coefficients to obtain the original information chunks. Voilà! ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--537960b249/1f169b075c16351d966b3071655cb917/asset-https-cdn-sanity-io-images-dgybcd83--537960b249.png) Going back to our data availability problem: Instead of asking the block producer to write down the raw file on the bulletin board, we now ask it to cut the file in $k$ chunks, encode them using a Reed-Solomon code of, say, rate $R=1/2$ , and write the $n=2$ coded chunks to the bulletin board. Let’s assume for now the block producer follows at least the encoding honestly—we will see later how to discharge this assumption. Consider again the two scenarios: Either the producer behaves *honestly* and writes down all the chunks, or the producer *misbehaves* and wants to keep the file unavailable. Recall that we can recover the original file from any $k$ out of $n=2k$ coded chunks. So to keep the file unavailable, the block producer can write at most $k-1$ chunks. In other words, now at least $k+1$, more than half of the $n=2k$ coded chunks, will be missing! But now these two scenarios, a bulletin board that is fully written, and a bulletin board that is half empty, are easily distinguishable: You inspect the bulletin board at a small number $r$ of randomly sampled locations, and consider the file available if each sampled location has its respective chunk, and unavailable if any of the sampled locations is empty. Note that if the file is unavailable, and consequently (more than) half of the bulletin board is empty, the probability that you erroneously consider the file available is less than $2^{-r}$, i.e., exponentially small in $r$. # The (Practical) Challenges This is beautifully simple—within the given “bulletin board in a dark room” model. Let’s think about the model: What do the components represent? Can we realize them in a real computer system, and how? In fact, to help spot the gaps between theory and practice, we have explained the problem and solution using that “strange” “bulletin board in a dark room” model, with metaphors that bear little resemblance to the real computational system. This was to encourage you to reflect about how aspects of the real and model world correspond, and how they might (not) be realized. If you are left with pieces of the model that you haven’t been able to translate into a computer/network/protocol equivalent, you know there is something left to be done—which might be either gaps in your understanding, or open research problems! ;) Here is a non-exhaustive collection of challenges, for some of which the community has found reasonable answers over the years, while others are still open research problems. **Challenge A: How to ensure that the chunks on the bulletin board were actually written by the proposer?** Think about alterations of the sampled chunks as they transit in whatever form on the network to the sampling node. This is where the small piece of information comes in that the block producer can pass to the sampling nodes as the producer leaves and the sampling node enters the dark room. In practice, this is realized as a **binding vector commitment** (think [Merkle tree](https://en.wikipedia.org/wiki/Merkle_tree)) to the original content written to the bulletin board, and it is shared for instance as part of the block header. Given the commitment, the block producer can then leave a proof with each coded chunk on the bulletin board to show that indeed the chunk was written by the block producer. The chunks cannot be altered by a third party on transit, as the commitment scheme does not allow to forge a valid proof for a modified chunk. Note that this by itself does not preclude that the block producer writes invalid/inconsistent chunks on the bulletin board, which we address next. **Challenge B: Enforce that the block producer erasure-encodes properly.** We have assumed in the above scheme that the block producer encodes the information chunks correctly, so that the guarantees of the erasure-code hold, and that consequently from enough coded chunks it is actually possible to recover the information chunks. In other words, all the block producer can do is *withhold* chunks, but not confuse us with *invalid* chunks. In practice, there are three commonly discussed approaches to rule out invalid encoding: - **Fraud proofs.** This approach relies on the fact that some sampling nodes are beefy enough to sample so many chunks that they can spot inconsistencies in the encoding of chunks and issue *invalid encoding fraud proofs* to mark the file in question as unavailable. Works in this line aim to minimize the number of chunks a node has to inspect (and forward as part of the fraud proof) to detect fraud (cf. [the original Al-Bassam/Sonnino/Buterin paper uses 2D Reed-Solomon codes for this reason](https://arxiv.org/abs/1809.09044)). - **Polynomial commitments.** This approach uses [KZG polynomial commitments](https://www.iacr.org/archive/asiacrypt2010/6477178/6477178.pdf) as the binding vector commitment included in the block header to address challenge A. The polynomial commitment allows verifying Reed-Solomon *coded* chunks directly, based on a commitment to the uncoded *information* chunks, and thus leaves no room for invalid encoding. Think of it as: vector commitment and Reed-Solomon encoding are inseparable in polynomial commitments. - **Validity proofs.** A cryptographic proof system could be used to prove correct erasure-encoding of the vector-commitment-committed coded chunks. This approach is a good pedagogical “mental model”, and generic with respect to the erasure code employed, but likely impractically inefficient for quite some time. **Challenge C: “What” and “where” is the bulletin board? How does the proposer “write” to it?** Before we get to “what” and “where” the bulletin board “is”, how the proposer “writes” to it, and how the verifier “reads”/”samples” from it, let’s review well-known shortcomings of two basic peer-to-peer networking primitives: - **Low-degree flooding-based publish-subscribe gossip networks** such as [GossipSub](https://arxiv.org/abs/2007.02754), where communication is organized into different “broadcast groups” (“topics”) that participants can join (“subscribe”) and send messages (“publish”) to: - Are not secure under arbitrary (“Byzantine”) adversarial behavior (e.g., eclipse attacks, Sybil attacks, attacks on peer discovery) - Common variants do not even provide a Sybil resistance mechanism - Privacy of a participant’s group membership from other participants is typically not guaranteed (in fact, group membership is typically communicated to peers in order to avoid them forwarding network traffic of unwanted topics) - Communication tends to become unreliable if there is a large number of topics each with few subscribers (because the sub-graph of nodes subscribed to a particular topic might no longer be connected so that flooding might fail) - **Distributed hash tables (DHTs)** such as [Kademlia](https://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia-lncs.pdf), where each participant stores a portion of the overall data stored in the hash table, and participants can quickly determine short paths to a peer that stores a particular piece of information: - Are also not Byzantine fault tolerant (e.g., inappropriate routing of honest participants’ requests, attacks on network formation/maintenance) - In fact, DHTs fare considerably worse in resilience to adversarial behavior than gossip protocols: Gossip protocols “only” require that the subgraph formed by honest nodes (and edges between honest nodes) is connected, so that information can reach from any honest node to all honest nodes. In DHTs, information is specifically routed along paths, and a query can fail whenever it reaches an adversarial node on its path. - Also do not provide a Sybil resistance mechanism - Privacy of which participant stores or requests what piece of information (from the curious eyes of other participants) is not guaranteed With this in mind, we can return to the central questions on how to implement the bulletin-board and the read/write operations on it. Where are the coded chunks stored? How do they get there? Three prominent approaches [under consideration](https://notes.ethereum.org/@djrtwo/das-building-blocks) are: - **GOSSIP: Disperse coded chunks using a gossip network.** For instance, there could be a topic per coded chunk, and nodes in charge of storing a certain chunk could subscribe to the respective topic. - **DHT: Upload coded chunks into a DHT.** The DHT would then “automatically” assign to each participant the chunks they should store. - **REPLICATE: Sample from nearby replicas.** Some nodes store a full (or partial) replica of the data, and serve chunk requests to sampling nodes. Challenges with these approaches are: - How to ensure that “there is enough space on the bulletin board” to begin with (i.e., enough participants are subscribed to each topic in **GOSSIP**, or each node can store all chunks it is required to store under **DHT**), and that all parts of the bulletin board remain online as nodes churn over time? (Ideally, to ensure scalability, we would even want that storage is used efficiently, i.e., there should not be too much redundancy among what honest nodes store.) This would be particularly tricky in a truly permissionless system where nodes come and go, and where perhaps there is no Sybil resistance mechanism, so that a large majority of nodes could be adversarial and could disappear in an instant. Luckily, in the blockchain context, some Sybil resistance mechanism (such as PoS) is usually present and could be used to establish reputation or even slashing, but many details remain to be determined on how to leverage the Sybil resistance mechanism to secure the peer-to-peer network layer. - Expanding on the preceding point, since networking underlies consensus and is thus the bedrock of what is supposed to be a Byzantine fault tolerant (BFT) system, the networking layer itself better be BFT—but as seen earlier, that is not the case for popular gossip or DHT protocols such as GossipSub or Kademlia. (Even **REPLICATE** might face this challenge, as a DHT may still be used in other parts of the network stack, e.g., for peer discovery; but at this point challenges with DHT become a general network-layer concern, not specific to data availability sampling.) - Finally, some think that in the long run, nodes are supposed to store or forward no more than a quite small fraction of a block, otherwise scalability and the possibility to support relatively “weak” participants (cf. decentralization) is limited. This is antithetical to **REPLICATE**. For **GOSSIP**, this necessitates a large number of broadcast groups (“topics”) each with a small number of subscribers, a regime in which gossip protocols tend to become less reliable. In any case, the above approaches come with overhead, e.g., in bandwidth for forwarding chunks on behalf of other nodes, that must not exceed an individual node’s budget. **Challenge D: “How” do we implement the random sampling?** This question is two-fold: how are the desired chunks located and transmitted in the network (i.e., how to “read” from the bulletin board), and how is it ensured that the sampling “remains random” with respect to the adversary, i.e., that an adversarial block producer does not have (too much) opportunity to change its strategy adaptively depending on who queries which chunks. - Certainly, sampling directly from the block producer is not a viable option, due to the high bandwidth this would require from the block producer, and the associated denial-of-service vector if the block producer’s network address was known to everyone. (Some hybrid constructions that involve pulling from the block producer can be viewed through the lense of **DHT** and **REPLICATE**.) - An alternative is to sample from “the swarm” after dispersing the chunks using one of the aforementioned methods (**GOSSIP** or **DHT**). Specifically: - After the chunks have been dispersed using either **GOSSIP** or **DHT**, a DHT might come handy to route sampling requests and randomly sampled chunks—but this comes with the challenges discussed above, most notably lack of BFT and privacy. - Alternatively, under **GOSSIP**, each node could subscribe to the topics corresponding to chunks it wants to sample—but with the challenges discussed above: besides lack of BFT and privacy, having a large number of topics with few subscribers each leads to unreliable communication. - A compromise between “sample from the block producer” and “sample from the swarm” is possible with **REPLICATE**, where chunks are sampled from full replicas of the data, and replicas are identified among network peers. Note that the above solve only sampling (“reading” from the bulletin board *now*), but not “reading” from the bulletin board *at any time in the future*. Specifically, **GOSSIP** essentially implements an *ephemeral* bulletin board (which can be read/sampled only at the time when its content is being written/dispersed), while DHT implements a *permanent* bulletin board (which can be read/sampled also much later). Typically, a permanent bulletin board is desired (with a permanence requirement ranging from “days” to “forever”, depending on the exact design), for which purpose **GOSSIP** has to be complemented with a DHT to route chunks, which comes with the aforementioned challenges. **REPLICATE** implements a permanent bulletin board right away. The following table illustrates which peer-to-peer protocols are commonly proposed to realize which functionality of the model. Specifically, the gossip-oriented approach comes in two variants, one that uses gossip to sample chunks and one that uses a DHT to sample chunks, while in both “chunks are written on the bulletin board” using gossip and “read from it” at later points in time using a DHT. In contrast, the DHT-oriented approach relies entirely on a DHT for all the operations in question. In the replication-oriented approach, each node reads/samples chunks from a full replica nearby, using a request/response protocol. It effectively uses gossip for the initial dissemination of the chunks, albeit the gossipping between two peers might technically be realized through the request/response protocol. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--9acfec3d4f/f476f59e4766ef1921311e7a89e9d673/asset-https-cdn-sanity-io-images-dgybcd83--9acfec3d4f.png) Furthermore, in all above techniques, “who samples what” is leaked (at least partially) to the adversary, so that the adversary can, through its own behavior, adaptively impair/promote the propagation of chunks sampled by certain nodes, and thus trick certain nodes into believing that the block is (un-)available. While [the earlier work shows that only few nodes can be tricked](https://arxiv.org/abs/1809.09044), this is undesirable. Alternatively, [earlier works assume anonymous network communication](https://arxiv.org/abs/1809.09044), which in practice at least comes with a considerable performance penalty, if not outright impractical. **Challenge E: How to “repair” the board’s content?** That is, if a coded chunk goes missing (for example because nodes storing that chunk have gone offline; how is that even detected?), how is it recovered? Naive repair involves decoding and re-encoding, and thus poses a considerable communication and computational burden, in particular for the common Reed-Solomon erasure-correcting codes. Who takes on this burden? How are they compensated? How is it avoided that a malicious block producer can grief sampling nodes by withholding a few coded chunks and forcing nodes to spend resources on expensive repair? What about distributed repair schemes? How are the chunks that are necessary for repair even retrieved, going back to the previous point about “reading” from the board in the future. **Challenge F: Incentives.** If sampling is free, how to prevent a denial-of-service vector? If sampling requires payment (how to implement?), how can it simultaneously be fully anonymous? How are those compensated that store (parts of) the bulletin board, route information in the peer-to-peer network, or perform maintenance tasks such as chunk repair? # The Other Model For completeness, we briefly mention a slightly different model for which DAS achieves a slightly different guarantee. Even without anonymous and reliable networking, an adversary can trick at most a certain number of honest nodes into believing that an unavailable file is available. Otherwise, it would have to release so many chunks that from the union of all chunks obtained by honest nodes the file can be recovered. The advantage of this model is that the properties required from the network are easier to achieve (in particular, when the peer-to-peer network has been subverted by the adversary). Disadvantages are that there is no concrete guarantee for an individual user (you could be among the few tricked!), and that it remains unclear how to gather all the samples obtained by honest nodes and recover the file (in particular, when the peer-to-peer network has been subverted by the adversary). # Future Research & Development Directions Based on the observations and arguments presented in this blog post, we think the following will be some interesting directions for future research and development: - It seems clear that some Sybil resistance mechanism is necessary to secure the network layer (right now, arguably, network protocols often implicitly depend on the scarcity of IP addresses for this purpose, see for instance GossipSub v1.1’s peer scoring). Conveniently, the consensus layer provides exactly that, e.g., in the form of proof-of-stake. It thus seems natural to reuse the consensus layer’s Sybil resistance mechanism on the network layer, for instance to sample one’s peers in a gossip protocol from the validator set (and thus “inherit” the power of the consensus’ honest majority assumption). While this might not immediately secure the networking of nodes that aren’t also active consensus participants, it can help build a secure “backbone” among consensus nodes (and thus strengthen consensus security), and subsequently perhaps be a stepping stone to enable better security for everyone. A logical next step on this path would be the careful analysis of the interplay of consensus and networking with such a shared Sybil resistance mechanism ([this](https://eprint.iacr.org/2022/541) is a recent first step in that direction). - Improved gossip and DHT protocols: (cf. [this survey](https://www.distributed-systems.net/my-data/papers/2011.acm-cs.pdf)) - Byzantine fault tolerance (BFT), in particular using Sybil resistance mechanisms commonly found on the consensus layer - Efficiency (in particular for BFT variants, which so far come with considerable overhead and/or low adversarial resilience) - Privacy guarantees (improved guarantees, and better efficiency/lower overhead) - Repair mechanisms: - Implementing repair in a distributed way (erasure-correcting codes with locality?) - Studying and designing the relevant incentives If you are working on (or interested to work on) any of these directions, I would love to hear from you! You can reach me on Twitter at [@jneu_net](https://twitter.com/jneu_net). ## https://www.paradigm.xyz/writing/vrgda # Variable Rate GDAs > Variable Rate GDAs (VRGDAs) enable selling tokens close to a targeted schedule by adjusting prices as sales get ahead of/behind it. # Overview This paper introduces a novel token issuance mechanism. Variable Rate GDAs (VRGDAs), designed for [Art Gobblers](http://www.artgobblers.com/) and used in [0xMonaco](https://twitter.com/transmissions11/status/1561100140160593920), let you sell tokens close to a custom schedule over time by raising prices when sales are ahead of schedule and lowering prices when sales are behind schedule — a generalization of the [GDA](https://www.paradigm.xyz/2022/04/gda) mechanism. We provide both an overview of the mechanism and a highly optimized, production-ready Solidity implementation of the core mechanism and several example schedules. # Motivation *Art Gobblers* is a digital art experiment by Justin Roiland and Paradigm. An important objective of the project was to create a self-sustaining ecosystem that could thrive on its own without human intervention for years to come. There are two core NFTs in this system, and we wanted anyone to be able to purchase either at any time. We wanted to issue both relatively quickly at first. Over time, one tops out at a fixed supply, whereas the other is issued at a slow constant rate forever. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--995acbd8e7/aca5626147b9364087c92acff9531a69/asset-https-cdn-sanity-io-images-dgybcd83--995acbd8e7.png) We sought to achieve these goals while maintaining a seamless user experience that would allow users to buy NFTs at any time, without having to, for example, wait for a scheduled auction. Our solution was VRGDAs, a generalization of [GDAs](https://www.paradigm.xyz/2022/04/gda) that allows for arbitrary scheduling of NFT issuance, as opposed to the uniform linear scheduling of standard GDAs. # Mechanism ## Building Intuition Imagine a simple schedule where we want to sell 10 NFTs per day. We set a starting price of 1 token for the first NFT. Suppose it is currently day 5, so we should have sold 50 NFTs. However, demand has been high, and we have sold 70. We weren’t supposed to sell 70 NFTs until day 7, so we are two days ahead of schedule. As a result, we want to charge a higher price going forward. We use an exponential curve to determine how much higher. This can vary based on parameters, but in this case, let’s say we use $2^\\text{days ahead of schedule}$, so that we increase our price by a factor $2^2=4$ , so since our initial price was 1 token, the new price will be 4 tokens, making it harder to buy more NFTs. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--b7c6413dd6/6db1449ee109788b9bb6258672b025aa/asset-https-cdn-sanity-io-images-dgybcd83--b7c6413dd6.png) Ten days later, on day 15, we should have sold 150 NFTs, but users have only bought 120, the amount they should have bought by day 12, meaning we are three days *behind* schedule. We adjust the price to , making it easier for users to buy more NFTs. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--b7c6413dd6/6db1449ee109788b9bb6258672b025aa/asset-https-cdn-sanity-io-images-dgybcd83--b7c6413dd6.png) Ten days later, on day 15, we should have sold 150 NFTs, but users have only bought 120, the amount they should have bought by day 12, meaning we are three days *behind* schedule. We adjust the price to $2^{-3}=0.125$, making it easier for users to buy more NFTs. ## Construction **Parameters** $p_0$ - The price an NFT would sell for if sold perfectly on pace (the *target price). **$k$** - *The percentage an NFT’s price decreases in a unit of time with no purchases. $f(t)$ - The issuance schedule: maps *t* to the number of NFTs to aim to sell by that time. **Objective** We want to issue NFTs on a particular schedule. The mechanism we will use to do this is to raise prices if NFTs are sold ahead of schedule and lower them if they are sold behind schedule. If sales are perfectly on schedule, the price to buy the next one will remain the same. **Definitions** Let’s say we want to sell NFTs at a schedule described by $f(t)$, which maps a point in time to the cumulative number of NFTs we want to have sold by that time. For example, if we want to sell one NFT every two days, we’d define $f(t)$ like so: $$ f(t) = \frac{t}{2} $$ Let’s also say we want to sell our NFTs using a separate Dutch Auction per NFT. If we set each NFT’s starting price at 1, and let this price decay by a rate of per unit of time with no sales, its price if purchased at time $t$ will be: $$ (1-k)^t $$ To give ourselves the flexibility we need to achieve our objective, we can shift the starting point of the auction in time by some $s_n$, which we will derive below, so that the price at time $t$ is: $$ (1-k)^{t-s_n} $$ If we want our target price to be different than 1, we can multiply by a constant $p_0$. We call this adjusted price $\\texttt{vrgda}_n(t)$: $$ \texttt{vrgda}_n(t) = p_0(1-k)^{t-s_n} $$ ### Determining $s_n$ According to our issuance schedule $f$, we want to sell the $n$th NFT at time $t_n$. We can define $t_n$ by inverting $f$ to get a mapping from $n$ to the time it should be sold: $$ t_n = f^{-1}(n) $$ A consequence of the VRGDA objective is that if the $n$th NFT is purchased exactly at the target time according to its issuance schedule, its price will be $p_0$. Expressed formally, this means that if we are selling at exactly the target rate, then at time $t_n$, the $n$th NFT will be priced such that: $$ p_0(1-k)^{t_n-s_n}=p_0 $$ Simplifying by dividing out $p_0$, we know that the following should always hold true: $$ (1-k)^{t_n-s_n}=1 $$ Which implies $t_n-s_n=0$ or $s_n=t_n$. Using our definition of $t_n$ from above, we know $s_n = f^{-1}(n)$. ### Final Formula By substituting this definition of $s_n$ into $\\texttt{vrgda}_n(t)$, we end up with the final formula: $$ \texttt{vrgda}_n(t) = p_0(1-k)^{t-f^{-1}(n)} $$ ## Simple Issuance Schedules Below we demonstrate deriving some simple issuance schedules to use with the VRGDA formula. ### Linear Let’s say we want to sell $r$ NFTs per day. Then $f(t) = rt$, so $f^{-1}(t) = \\frac{t}{r}$ After plugging this $f^{-1}(t)$ into the VRGDA pricing formula, we end up with the following: $$ \texttt{linear\_vrgda}_n(t) = p_0(1-k)^{t-\frac{n}{r}} $$ ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--aacb248c7d/89ed3bc06122be69dea892ea6da74c9a/asset-https-cdn-sanity-io-images-dgybcd83--aacb248c7d.png) Note this is isomorphic to a [GDA](https://www.paradigm.xyz/2022/04/gda), which is why we call VRGDA a generalization of GDA. ### Square Root Let’s say that we want to issue NFTs at a rate proportional to the square root of time — for example, to issue NFTs more quickly at first, and then more slowly over time, but without ever stopping. We can then set $f(t) = \\sqrt{t}$, so that on day 1 we have sold 1 NFT, on day 4 we have sold 2, on day 9 we have sold 3, and so on. In this case, $f^{-1}(n) = n^2$. Now we simply plug into the VRGDA pricing formula to get: $$ \texttt{sqrt\_vrgda}_n(t) = p_0(1-k)^{t-n^2} $$ ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--48b270531b/4c30f0be7fb80df85079c975082accab/asset-https-cdn-sanity-io-images-dgybcd83--48b270531b.png) ## Logistic Issuance Schedule The logistic issuance schedule is somewhat complex compared to the examples above. However, we have chosen to cover it in detail nonetheless as it provides a way to bootstrap initial growth without enforcing an infinite inflation regime. ### Motivation Let’s say we want to issue NFTs quickly at first, but then slow down until eventually some maximum number have been issued, as is the case in Art Gobblers. One clean way to model this is using the [logistic function](https://en.wikipedia.org/wiki/Logistic_function) with positive domain. ### Deriving $f$ The logistic function is an S-shaped curve. We’ll simplify it slightly and define it as: $$ l(t) =\frac{1}{1 + e^{-t}} $$ This curve approaches 0 as $t$ approaches negative infinity, and 1 as $t$ approaches infinity. For our particular application, we don’t want to use the full S curve (although it’s also possible to have a full logistic VRGDA that would start slow, speed up, and then slow down again). Instead, we want to use only the part of the curve where $t$ is positive. Because $l(0)=0.5$, but we want our schedule to indicate selling 0 NFTs at time 0, we need to shift this function down by subtracting 0.5. This new curve will go from 0 to 0.5: $$ h(t)=\frac{1}{1 + e^{-t}}-0.5 $$ We want to issue $L-1$ NFTs (we choose this for notational convenience since the function will asymptote out before it hits $L$), so we will need to scale this function by a factor of $2L$. We can also introduce a time-scaling parameter $s$ to adjust the speed at which to issue the NFTs: $$ f(t)=\frac{2L}{1 + e^{-st}}-L $$ To pick $s$, observe that: $$ \frac{f(t)}{L}=\frac{2}{1 + e^{-st}}-1 $$ Furthermore: $$ \frac{f(\frac{1}{s})}{L}=\frac{2}{1 + e^{-1}}-1\approx0.46 $$ This means we can pick $s$ by picking the time by which we want about 46% of the NFTs to be issued. For example, if we want 46% of the NFTs to be issued after 100 time units, that means $\\frac{1}{s}=100$, so that $s=\\frac{1}{100}$. ### Formula Taking the inverse of $f(t)$ from above yields: $$ f^{-1}(n) = - \frac{\text{ln}\left(\frac{2L}{L+ n} - 1\right)}{s} $$ Putting this all together, we end up with the following formula: $$ \texttt{logistic\_vrgda}_n(t) = p_0(1-k)^{t+ \frac{\text{ln}\left(\frac{2L}{L+ n} - 1\right)}{s}} $$ ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--4408bfc598/6aa0e6f6ea765bb37169d9eedeb0f73d/asset-https-cdn-sanity-io-images-dgybcd83--4408bfc598.png) # Implementation A highly optimized, production ready, and permissively licensed (MIT) implementation of VRGDAs and an assortment of issuance schedules can be found at [transmission11/VRGDAs](https://github.com/transmissions11/VRGDAs). Pull requests with improvements are welcome. # Conclusion VRGDAs provide a way to issue NFTs using nearly any schedule you would like while still allowing users to seamlessly buy them at any time. In the case of [Art Gobblers](http://www.artgobblers.com/), they allowed us to customize our community growth and UGC dynamics. In the case of [0xMonaco](https://twitter.com/transmissions11/status/1561100140160593920), it created a challenging and highly competitive game loop. We believe there many other potential applications across NFTs, on-chain gaming, DeFi, and beyond. If you’d like to explore them, we’d love to hear from you. You can reach us on Twitter at [@transmissions11](https://twitter.com/transmissions11), [@FrankieIsLost](https://twitter.com/FrankieIsLost) and [@_Dave__White_](https://twitter.com/_Dave__White_). We can’t wait to see what you build. *Acknowledgments: *[*Dan Robinson*](https://twitter.com/danrobinson)*, *[*samczsun*](https://twitter.com/samczsun)*, *[*Riley Holterhus*](https://twitter.com/rileyholterhus)*, *[*NN Blossoms*](https://twitter.com/nn_blossoms)*, *[*dcfpascal*](https://twitter.com/dcfpascal_)*, *[*kootsZhin*](https://twitter.com/kootsZhin)*, *[*Grug*](https://twitter.com/CapitalGrug)*, *[*Ben Leimberger*](https://twitter.com/ben_leimberger)*, *[*Kiran Cherukuri*](https://twitter.com/neuroswish)*, *[*Aaru*](https://twitter.com/AaruCrypto)*, *[*eva*](https://twitter.com/evayzh) *Graphics By: *[*Achal Srinivasan*](https://www.paradigm.xyz/team/achalsrinivasan) ## https://www.paradigm.xyz/writing/experiment-narwhal-bullshark-cosmos-stack # Cosmos without Tendermint: Exploring Narwhal and Bullshark > Many of us at Paradigm have been excited about the latest developments on high-throughput & low-latency consensus using directed acyclic graphs (DAGs), in particular the Narwhal mempool and the Tusk and Bullshark consensus algorithms, and beyond. As more and more blockchain systems get deployed to production, two problems are frequently encountered: 1. Achieving consensus with [high throughput and low latency](https://www.paradigm.xyz/2022/07/consensus-throughput) 2. Building a distributed application on top of that consensus One system which addresses these two problems is [Cosmos](https://www.paradigm.xyz/2021/04/a-cosmos-thesis). Cosmos uses [Tendermint](https://docs.tendermint.com/master/introduction/what-is-tendermint.html), a high-performance BFT consensus algorithm, and the [Cosmos SDK](https://v1.cosmos.network/sdk), a toolkit which enables developers to launch their own proof-of-stake blockchain on top of Tendermint. However, Tendermint was conceived years ago, and researchers have made great strides on BFT consensus since then. Many of us at Paradigm have been excited about the latest developments on high-throughput & low-latency consensus using directed acyclic graphs (DAGs), in particular [the Narwhal mempool and the Tusk](https://arxiv.org/abs/2105.11827) and [Bullshark](https://arxiv.org/abs/2201.05677) consensus algorithms, [and](https://dahliamalkhi.github.io/posts/2022/06/dag-bft/) [beyond](https://dahliamalkhi.github.io/posts/2022/07/dag-fo/). (Check out [these](https://decentralizedthoughts.github.io/2022-06-28-DAG-meets-BFT/) [blog](https://dahliamalkhi.github.io/posts/2022/06/dag-bft/) [posts](https://dahliamalkhi.github.io/posts/2022/07/dag-fo/) for a more gentle introduction to DAG-based consensus protocols.) Narwhal/Bullshark (N/B) promises higher transaction throughput, and responsiveness (meaning confirmation latency of N/B is a function of the actual network delay, rather than of the network delay upper bound ∆ assumed under eventual synchrony). In contrast, Tendermint is not responsive and consequently its latency is bottlenecked by the pessimistic delay bound ∆. Due to how the interaction between mempool (Narwhal) and consensus (Bullshark) works, N/B’s performance also does not suffer as much from faulty or malicious behavior, or from network hiccups, as other leader-based consensus protocols. Given the above advantages, we thought to ourselves: *Can we replace Tendermint with Narwhal & Bullshark (N/B), while targeting compatibility with the Cosmos SDK stack?* At a recent two-day internal hackathon, we built a proof-of-concept which achieved that! For this purpose, we attached to the N/B codebase a small shim that allows it to “speak the language” (APIs) of Cosmos clients on the one hand and Cosmos applications on the other. That was enough to port over some of the simple decentralized application code examples given in the Cosmos documentation to use N/B instead of Tendermint. You can find the proof-of-concept code here: [https://github.com/gakonst/narwhal-abci-evm](https://github.com/gakonst/narwhal-abci-evm) # How Does The Cosmos Stack Work? To understand what exactly we did, let’s take a look at the anatomy of a Cosmos node: ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--134632fcb7/bb079af67067f20c2fd8fdec2c80b582/asset-https-cdn-sanity-io-images-dgybcd83--134632fcb7.png) A Cosmos node consists of an instance of Tendermint Core (TC) for everything related to consensus, and an instance of the application consisting of the useful logic whose execution we want to decentralize. TC offers RPC endpoints to end-user clients (e.g., for submitting transactions, or for querying the application’s state). TC talks to the local instance of the application state machine via the [Application Blockchain Interface](https://docs.tendermint.com/master/spec/abci/) (ABCI). For the purposes of ABCI, TC acts as a client which initiates requests, and the application acts as a server which replies with responses. A simple request/response pair is “Query”. TC uses “Query” to forward to the application any end-user queries about the application state received via the RPC. Other important request/response pairs “deliver” the ledger of transactions that consensus has been reached upon to the application, where they are used as inputs to drive the application’s state machine. In particular, when a new block is confirmed in consensus, “BeginBlock” is called with block metadata, followed by “DeliverTx” for each transaction in the block, “EndBlock” again with block metadata, and “Commit” to persist the resulting state. Note that since all Tendermint instances reach consensus on the transaction ledger and thereby on the sequence of ABCI calls to the application, the application state machine gets replicated in lockstep across all nodes of the network. # What We Did A natural point to hook into this stack was thus to remove TC, and replace it with N/B, augmented with a shim that both provides an RPC endpoint to clients, and delivers the consensus ledger via ABCI to the application: ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--7a5e49957b/f13bb8b1201f987c2486802b60db2a71/asset-https-cdn-sanity-io-images-dgybcd83--7a5e49957b.png) Indeed, after about two days of hacking, we are able to run a simple ABCI app consisting of an EVM execution environment on top of N/B, where we could issue transactions and query their outcome via TC RPC: *Embed* The demo consensus network is run by four nodes (each running on localhost), whose RPC endpoints are reachable on TCP ports 3002, 3009, 3016, and 3023, respectively. There are three accounts, Alice (initially 1.5 ETH), Bob (initially 0 ETH), and Charlie (initially 0 ETH). Alice performs a double spend, sending 1 ETH each to Bob and Charlie in two different transactions that get input to the nodes at ports 3009 and 3016, respectively. Note that only one transaction can make it. Eventually, nodes reach consensus on which transaction gets executed in Foundry's EVM, and the application state is updated in lockstep across all nodes. The update is reflected in subsequent balance queries. # Conclusion We built a prototype Cosmos/ABCI application that used Narwhal/Bullshark as the consensus algorithm instead of Tendermint. In that process, we learned that ABCI is quite Tendermint-specific, despite its aspiration to be more generic. For instance, it assumes a simple blockchain structure, with certain metadata present in the block headers (e.g., the previous block’s state root). The latest consensus protocols, however, whether they are based on multiple parallel chains or DAGs, do not fit this simple corset anymore. To move beyond the proof-of-concept stage, more would need to be done: - **Benchmarking and optimizing performance.** While we implemented a proof of concept which successfully shows delivery and execution of EVM transactions to/in the application, we did not fully benchmark the system (i.e., to provide TPS numbers of EVM execution), or minimize overhead such as in the communication between consensus and application. We leave that as future work, looking to also support optimizations such as EVM parallelization to further improve throughput. - **A turn-key testnet/L1 with high-performance consensus, EVM execution, and Ethereum JSON-RPC.** The application we built uses just Foundry’s EVM, and does not support Ethereum JSON-RPC APIs. It’d be nice if we could instead integrate N/B with Foundry’s Anvil. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--0ea03021d1/909fc3b74706d214c278643658312d6b/asset-https-cdn-sanity-io-images-dgybcd83--0ea03021d1.png) - Specifically, an RPC shim would redirect new transactions to N/B for ordering and proxy all remaining RPC calls to Anvil’s Ethereum JSON-RPC. The sequence of ordered transactions from N/B would be fed to Anvil (for instance via ABCI’s BeginBlock/DeliverTx/EndBlock/Commit) to drive (modified-to-be-deterministic) lockstep block production in Anvil, replicating the state of Anvil and its EVM across all participants. The result could be a simple turn-key high-performance testnet/L1 featuring N/B’s powerful consensus and Anvil/Ethereum/EVM’s expressive RPC and execution. Similar to the Cosmos stack seen earlier, in this tandem, all the networking logic is provided by the consensus layer, and Anvil can just act as the EVM runtime & state persistence layer. - **Full Cosmos proof-of-concept.** We built a scoped-down ABCI app where we only support ABCI consensus messaging. To support the full Cosmos SDK and showcase a full end-to-end integration, the rest of ABCI (and probably ABCI++) would need to be implemented, necessitating extending the ABCI/RPC shim (and potentially the N/B codebase) with functionalities such as validator set reconfiguration or light client support. - **Improvements of the N/B implementation itself.** For instance, the research codebase we have used does not provide the asynchronous fallback described in the Bullshark paper. Acknowledgments: Special thanks to Zaki Manian, Lefteris Kokoris-Kogias, Matt Huang, and Dan Robinson for fruitful discussions and comments on an earlier draft of this post, and to Achal Srinivasan for the beautiful diagrams. ## https://www.paradigm.xyz/writing/lp-letter-excerpt-july-20th-2022 # LP Letter Excerpt — July 20th, 2022 > As long-term investors in crypto, we wanted to provide some additional context on recent market events. Here is an excerpt of what we recently shared with our investors: 2022 has been marked by macroeconomic uncertainty and a global selloff, which has impacted tech, crypto and other markets. Bitcoin and Ethereum have drawn down 49% and 58% YTD, respectively, with other crypto assets impacted more severely such as COIN (down 71% YTD). The selloff has exposed unhealthy leverage throughout the crypto ecosystem, triggering a daisy-chain of distress and bankruptcy. Crypto headlines and sentiment have turned decidedly negative, and although reminiscent of prior so-called bear markets in 2018 and 2015, these events are now playing out with crypto on a much larger stage. Despite the market thrash, our long-term conviction in crypto as a technology and asset class remains strong. The quality of talent coming into crypto has never been stronger. Meanwhile, the tourist investor class has thankfully decamped. We believe the next 12–24 months will be an exceptionally fruitful time for building and investing in crypto. # What Happened? A complete account of the ongoing crypto deleveraging will require the benefit of hindsight. For now, based on what we know at this point, it is clear that certain crypto entities grew into unsustainable positions on the implicit assumption that asset prices can only increase. As enthusiasm reigned in 2020–2021, companies and funds felt emboldened, risk limits became a moving target in the chase for scale and yield, and leverage both explicit and implicit was able to accumulate. The exogenous shock of a global selloff was a reality check. While the events are decidedly negative, we are optimistic that lessons learned will translate to a healthier crypto ecosystem long term. **Terra, LUNA, UST** The first domino to fall was the Terra blockchain. In short, Terra was best known for LUNA, its native blockchain asset (akin to ETH on Ethereum), and UST, a USD-pegged stablecoin built on top. The UST peg was maintained via a bidirectional redemption process against LUNA: when UST dropped below $1, you could “burn” $1 of UST to “mint” $1 worth of LUNA, and vice versa when UST grew above $1, you could “burn” $1 worth of LUNA to “mint” $1 of UST. This process would, in theory, keep UST near the $1 peg... so long as confidence in the system remained strong. Like many prior “algorithmic stablecoins,” the design of UST was subject to a potential negative spiral if faith in the value of UST and LUNA was lost, which would lead to everyone running for the exits. In fact, the issues with algorithmic stablecoin designs are so well-trodden that perhaps the most interesting question is not “why did UST break?” but instead “how did UST get so big before it broke?” This is a question that we had been asking ourselves from the sidelines throughout LUNA/UST’s meteoric rise. While a root cause is hard to pinpoint precisely, the combination of a charismatic founder (in Do Kwon), many vocal investor proponents (including the now insolvent 3AC), a too-good-to-be-true Anchor protocol offering 20% yield on UST, a flashy attempt to acquire large amounts of BTC as collateral, and many other factors fueled a frenzy of retail and institutional speculation in the underlying LUNA asset and the seemingly low-risk 20% UST yield. Rising LUNA value led to greater confidence in UST’s stability, and more UST deposits led to greater confidence in LUNA. The positive feedback loop was incredibly strong on the way up, but the negative feedback loop was even stronger on the way down. LUNA has now declined from over $100 per LUNA in April to less than $0.01 today. The UST stablecoin broke its $1 peg and is now worth close to $0. More than $18B in UST deposits and $40B in LUNA market capitalization has vanished. As the air escaped LUNA and UST, the selloff in crypto prices was likely accelerated and issues started to appear elsewhere in crypto. **3AC and the crypto lenders** Three Arrows Capital (3AC) began as a traditional FX arbitrage fund in 2012 before expanding into crypto via both arbitrage and directional strategies. With their own capital, 3AC’s founders (Su Zhu and Kyle Davies) grew <$1M in starting assets to several $B+ over the course of 10 years – by any measure, an incredible feat. Yet it was this same track record, achieved without much appreciation for risk, that arguably paved the way for 3AC’s demise. Heading into 2022, 3AC’s swelling overconfidence combined dangerously with a crypto lending ecosystem that was all too willing to extend unhealthy amounts of leverage to grow loan books in search of higher yields. Incredibly, one crypto lender, Voyager Digital, seems to have loaned as much as $350M USDC and 15,250 BTC (collectively worth $1B+ as of March 30th) to 3AC completely uncollateralized. Such a large loan extended with zero collateral is plainly indicative of bad judgment, but also hints at the intense competition among lenders to grow assets and the relative comfort they felt in working with a large and reputable fund like 3AC. Not all lenders were quite this cavalier. Celsius and Genesis loans seem to have been partially collateralized, while BlockFi loans seem to have been overcollateralized. Nevertheless, in aggregate, 3AC was able to accumulate billions of debts on top of billions of assets, which were highly levered to the continued growth of crypto asset prices. Once the market selloff and subsequent LUNA/UST collapse came, what happened next was inevitable. 3AC swung from multiple billion in net assets to over $1B in net debt, collapsing into bankruptcy and blowing large holes in the balance sheets of crypto lenders. While 3AC caused the most damage, crypto lenders also made various other mistakes. Some engaged in risky trading strategies with client assets (e.g. so-called “yield farming” across DeFi protocols). Others locked up capital in seemingly low-risk arbitrage trades (e.g. betting on the price convergence of GBTC and BTC) that implicitly assumed a long-term duration that was mismatched against the short-term nature of client deposits. For the crypto lenders that survive, it seems likely that risk management will gain new prominence internally. # Lessons Learned The crypto ecosystem is reimagining money, the financial system, and internet applications based on new technical and economic primitives. A process this fundamental and ambitious is bound to be messy. Every failure is an opportunity for learning, and we are optimistic that the crypto ecosystem will emerge smarter and more resilient. This is not crypto’s first crisis (nor will it be the last). In 2014, MtGox was the largest Bitcoin exchange processing 70+% of global trading volume, and a hack resulted in the loss of over 7% of all BTC in circulation. In 2016, a smart contract application called “The DAO” was holding almost 15% of all ETH supply in custody when it was hacked. At the time, both events seemed existential. Fear was widespread and asset prices followed. Yet, in our experience, such events ultimately do not halt the fundamental driver of progress in crypto: developers and entrepreneurs working on building the future. These crises also catalyze positive change. The decline of MtGox gave way to more secure and well-run exchanges such as Coinbase and drove the development of fully non-custodial exchanges like Uniswap. The DAO hack gave way to more focus on smart contract security. Hopefully, the LUNA/UST collapse will give way to broader understanding of the risks around algorithmic stablecoins, and the blow-up of 3AC and crypto lenders will give way to better risk management. One underreported fact has been the relative strength of performance in decentralized finance (DeFi) protocols in contrast to centralized finance (CeFi) lenders and funds. DeFi lenders such as MakerDAO, Compound, and Aave were all able to remain solvent through pre-programmed mechanisms to liquidate collateral as margin limits were reached. These systems are on-chain, transparent, with code that anyone can inspect and little opportunity for unhealthy leverage to accumulate. There is a long way to go for DeFi to match the existing financial system, but some of its fundamental advantages are starting to show. Beneath the headlines, in our day-to-day work, our optimism remains unchanged by recent events. Not a day passes where we don’t encounter a talented college student or a seasoned tech executive thinking about spending the next 5–10 years of their career building in crypto. Crypto infrastructure and developer tooling are maturing. The opportunity for new DeFi protocols, especially in the aftermath of this CeFi unwind, is immense. And we see many emerging green shoots across consumer areas such as gaming, digital art, and social networking. Progress and opportunity abound, largely unaffected by public asset prices and the ongoing deleveraging. Looking ahead, we continue to focus on the multi-decade opportunity for crypto. Our team and the entrepreneurs we support are finding it easier to focus amid a quieter environment that is long on substance and short on distraction. The tourists are gone, and valuations are starting to rationalize. Strong companies are finding it easier to hire great talent. Overall, we are optimistic that the next 12-24 months will be an exceptionally fruitful time for building and investing in crypto. ## https://www.paradigm.xyz/writing/consensus-throughput # Understanding Blockchain Latency and Throughput > How to properly measure a (blockchain) system is one of the least talked about but most significant steps in its design and evaluation. There are numerous consensus protocols and variations with various performance and scalability tradeoffs. But as of yet, there is still no universally agreed-upon, reliable method that enables apples-to-apples comparisons. In this blog post, we outline a method inspired by measurements in data-center systems and discuss common errors to avoid when evaluating a blockchain network. How to properly measure a (blockchain) system is one of the least talked about but most significant steps in its design and evaluation. There are numerous consensus protocols and variations with various performance and scalability tradeoffs. But as of yet, there is still no universally agreed-upon, reliable method that enables apples-to-apples comparisons. In this blog post, we outline a method inspired by measurements in data-center systems and discuss common errors to avoid when evaluating a blockchain network. # Key metrics and their interaction Two important metrics should be taken into account when developing a blockchain system: latency and throughput. The first thing that users are concerned with is transaction *latency*, or the amount of time between initiating a transaction or payment and receiving confirmation that it is valid (for instance, that they have enough money). In classical BFT systems (e.g. PBFT, Tendermint, Tusk & Narwhal, etc), a transaction is finalized once it gets confirmed, whereas in longest-chain consensus (e.g. Nakamoto Consensus, Solana/Ethereum PoS), a transaction may get included in a block and then reorged. As a result, we need to wait until a transaction is "k-blocks deep," resulting in a latency that is significantly greater than a single confirmation. Second, the *throughput* of the system is typically important to system designers. This is the total load that the system handles per unit of time, expressed typically in transactions per second. At first glance, these two key metrics appear to be the inverse of one another. Because throughput is measured in transactions per second and latency is measured in seconds, we would naturally expect that Throughput = Load / Latency. This, however, is not the case. This realization is difficult because many systems tend to produce graphs that display either the throughput or the latency on the y-axis with something like the number of nodes on the x-axis. Instead, a better graph to generate is that of a throughput/latency graph, which makes it apparent by not being linear. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--2b23f11ec2/3e4bd4e7289f05f12fd43b0a4772c977/asset-https-cdn-sanity-io-images-dgybcd83--2b23f11ec2.jpg) When there is little contention, latency is constant, and throughput can be varied simply by changing the load. This occurs because there is a fixed minimum cost to commit a transaction and the queue delay is zero at low contention, resulting in "whatever comes in, comes out directly." At high contention, throughput is constant, but latency can vary simply by changing the load. This is because the system is already overloaded, and adding more load causes the wait queues to grow indefinitely. Even more counterintuitively, the latency appears to vary with experiment length. This is an artifact of infinitely growing queues. All of this is visible on the classic "hockey stick graph" or "L-graph," depending on the interarrival distribution (as discussed later). **As a result, the key takeaway from this blog post is that we should measure in the hot zone, where both throughput and latency affect our benchmark, rather than at the edges, where only one or the other matters.** ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--e00a48c0a0/0167b19a2e7adb46c128f1d3f9c35779/asset-https-cdn-sanity-io-images-dgybcd83--e00a48c0a0.jpg) # Measuring Methodology When conducting an experiment, there are three main design options: ## Open vs. closed loop There are two primary methods for controlling the flow of requests to the target. An open-loop system is modeled by n = ∞ clients that send requests to the target according to a rate λ and an inter-arrival distribution, e.g., Poisson. A closed-loop system limits the number of outstanding requests at any given time. The distinction between an open and closed loop system is a characteristic of a particular deployment, and the same system can be deployed in different scenarios. For instance, a key-value store may serve thousands of application servers in an open loop deployment or just a few blocking clients in a closed loop deployment. Testing for the correct scenario is essential because, in contrast to closed-loop systems, which typically have latencies constrained by the number of potential outstanding requests, open-loop systems can produce significant queuing and, as a result, longer latencies. **Generally speaking, blockchain protocols can be used by any number of clients and are more accurately evaluated in an open-loop environment.** ## Interarrival distribution for synthetic benchmarks A natural question to ask when creating a synthetic workload is how to submit requests. Many systems preload the transactions before the measurement begins, but this biases the measurements because the system starts at the unusual state of 0. Furthermore, preloaded requests are already in main memory and thus bypass the networking stack. A slightly better approach would be to send requests at a deterministic rate (for example, 1000 TPS). This would lead to an L-shaped graph (orange) since there is optimal usage of the system’s capacity. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--280dd1ee5f/c298a5ac91432cc9ed2d7c582cadb420/asset-https-cdn-sanity-io-images-dgybcd83--280dd1ee5f.jpg) However, open systems frequently don't act in such a predictable way. They instead have periods of high and low load. To model this, we can employ a probabilistic interarrival distribution, which is typically based on the Poisson distribution. This will result in the "Hockey stick" graph (blue line) because the poisson bursts will cause some queuing delay (max capacity) even if the average rate is less than optimal. **This is beneficial to us because we can see how the system handles high load and how quickly it recovers when the load returns to normal.** ## Warm-up Phase A final point to consider is when to begin measuring. We want the pipeline to be full of transactions before we begin; otherwise, warm-up delays will be measured. This should ideally be accomplished by measuring latency during the warm-up phase until the measurements follow the expected distribution. # How to compare The final difficulty is comparing the system's various deployments on an apples-to-apples basis. Again, the difficulty is that latency and throughput are interdependent, so it may be difficult to produce a fair throughput/number of nodes chart. Instead of simply pushing each system to its maximum throughput (where latency is meaningless), the best approach is to define a Service Level Objective (SLO) and measure the throughput at this point. Drawing a horizontal line at the throughput/latency graph that intersects the Latency axis at the SLO and sampling the points there is a nice way to visualize this. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--8a72d32b03/4f64b8aa72810b9b0d6b76c15f3de2f5/asset-https-cdn-sanity-io-images-dgybcd83--8a72d32b03.jpg) ### But I have set an SLO of 5 seconds and it only takes 2 seconds. Someone might be tempted to increase the load here in order to take advantage of the marginally higher throughput available after the saturation point. But **this is dangerous**. If a system operation is underprovisioned, an unexpected burst of requests will cause the system to reach full saturation, resulting in an explosion of latency and a very rapid breach of the SLO. In essence, operating after the saturation point is an unstable equilibrium. As a result, there are two points to consider: 1. **Overprovision your system.** In essence, the system should operate **under the saturation point** so that bursts in the interarrival distribution are absorbed rather than lead to increased queueing delays. 2. If you have room under your SLO, **increase the batch size**. This will add load on the critical path of the system instead of the queuing delay and get you the higher throughput for higher latency tradeoff you are looking for. ### I am generating an enormous load. How can I measure latency? When the load is high, trying to access the local clock and add a timestamp to every transaction that arrives on the system can lead to skewed results. Instead, there are two more viable options. The first and simplest method is to sample transactions; for example, there may be a magic number in some transactions that are the only ones for which the client keeps a timer. After commit time, anyone can inspect the blockchain to determine when these transactions were committed and thus compute their latency. The main advantage of this practice is that it does not interfere with interarrival distribution. However, it may be considered "hacky" because some transactions must be modified. A more systematic approach would be to have two load generators. The first is the main load generator, which follows the Poisson distribution. The second request generator measures latency and has a much lower load; think of it as a single client in comparison to the rest of the system. Even if the system sends back replies to each and every request (as some systems do, such as a KV-store), we can easily drop all replies to the load generator and only measure the latency from the request generator. The only tricky part is that the actual interarrival distribution is the sum of the two random variables; however, the sum of two Poisson distributions is still a Poisson distribution, so the math isn't that difficult:). ## Conclusions Measuring a large-scale distributed system is crucial for recognizing bottlenecks and profiling expected behaviour under stress. We hope that by using the above methods, we can all take the first step toward a common language, which will eventually lead to blockchain systems that are better suited for the work they do and the promises they make to end users. In future work we plan to apply this methodology to existing consensus systems, if that's something of interest, please reach out on [Twitter](https://twitter.com/lefkok)! Acknowledgments: All these are lessons learned with my co-authors during the design and implementation of \[Narwhal & Tusk\](https://arxiv.org/abs/2105.11827) (Best Paper Award @ Eurosys 2022) as well as comments on earlier drafts by Marios Kogias, Joachim Neu, Georgios Konstantopoulos, and Dan Robinson. ## https://www.paradigm.xyz/writing/dao-strategy-and-legal-wrappers # DAO Strategy and Legal Wrappers > Discussion on the strategic considerations and legal structures necessary for DAOs to operate effectively and legally in the real world, addressing the complexities and options available to founders for managing legal risk and facilitating operations. One of the important features of Web3 is the way in which blockchain-based technology enables individuals to organize themselves in novel arrangements to make problem solving potentially more creative, efficient and communitarian. DAOs are a case in point. In contrast to the 20th century industrial corporation reliant on the separation of ownership by stockholders, and centralized control by managers and directors, DAOs offer a radically different template for organizational participation: one where ownership and control can merge–driven by smart contracts, fluid memberships, and transparent transactional channels [^1] 1968)\]. But building a DAO involves more than just code; it also requires skillful legal engineering to enable the DAO to operate in the real world and protect builders and contributors. Yet the range and complexity of DAO legal structures can leave the best engineers (and their lawyers) dumbfounded. So in this post, we summarize our [new white paper Legal Wrappers and DAOs](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4123737), which offers founders (and policymakers) the first comprehensive overview of legal wrappers–and pairs it with a framework for understanding how these legal elements interact with the purpose and operations of popular DAO applications. ## Strategic Considerations The spectrum of potential DAO wrappers is broader than many founders likely assume. It spans legal entities and forms commonly associated with business associations to both incorporated and unincorporated nonprofits. Yet even in this variety, we anticipate that most founders will have to engage a similar process of reasoning when it comes to choosing legal wrappers. Key considerations will include the following factors: - The scope and purpose of a DAO’s operations; - The legal risk and tax liability associated with the DAO’s operations; - The size and permanence of the DAO’s membership; - The degree of decentralized governance employed; and - The resources of the DAO. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--b2b8b29ac9/ad3c0ff8f91337b7236a6960b0398909/asset-https-cdn-sanity-io-images-dgybcd83--b2b8b29ac9.png) ### Scope of DAO’s operations The need for a legal wrapper will largely hinge on whether the DAO’s sponsors intend for the DAO to interact with the real world, and whether the DAO’s activities create potential legal and tax liabilities for its members. Although informality carries enormous benefits for DAOs in terms of speed and cost, commercial transactions off chain frequently run on legal rails. From opening a bank account and hiring lawyers and accountants to hosting IRL events, a formal legal identity is often necessary. Sponsors and founders of DAOs will have to think concretely about the scope of the DAOs operations, not only on-chain, but also off, and make an assessment as to whether out of pure practicality a legal wrapper will be necessary. Legal wrappers are also, at their core, risk reduction tools. Informality leaves members with few legal protections should the DAO or DAO members become subject to lawsuits for negligence or other failures. Founders will have to evaluate these risks–and consider whether or not the activities of their DAO, or proposed DAO, create potential scenarios for liability, and by extension exposure to DAO members and participants. While no one can predict the future, the potential liabilities of a DAO that is limited to a token-gated discord channel vary fundamentally from those of a DAO that controls a protocol with billions of dollars TVL. Sponsors of larger, more ambitious projects will have to give additional consideration to whether the DAO’s activities create any tax liabilities that if left unprepared could undermine or even threaten the financial health of the project. If a DAO is generating revenue that could be deemed taxable income – including for example from token sales, treasury diversification, or staking – founders should analyze who may be liable for tax on that income and whether forming a legal entity could result in a clearer understanding of who bears that liability and may allow for better tax treatment. ### Degree of decentralized governance employed Every type of legal wrapper involves some points of centralization and dependence on outside actors. DAOs should consider the extent to which their operations can, and are willing to, accommodate centralization, and in what ways. Notably, legal wrappers offer a broad spectrum of choices as to the degree to which governance is evenly distributed among owners, members and investors. DAOs and their advisors will have to undertake a careful internal assessment of their purpose and objectives, and carefully analyze the extent to which legal wrappers can accommodate DAO token holders directing or influencing the actions of any persons operating the legal wrappers without raising the risk that the legal entity is disregarded by a court or that control results in tax or other liability. ### Membership A DAO’s membership, both in terms of its size and its fluidity, will determine the available and adequate legal wrappers. Early on, DAOs will have to assess the long term arc of their operations. Many legal wrappers are limited in the number of members they can accommodate due to federal laws and regulations, often to numbers far smaller than the number of members of some of the most prominent DAOs [^2]. However, DAOs with large numbers of members can still leverage other types of legal wrappers, and even use traditional structure as “siloed” entities meant to isolate specific liabilities or for other purposes. The fluidity with which members will join and exit the DAO is also a consideration that will affect which legal wrappers will be most advantageous. Many legal entities require their shareholders or members to execute contracts and reveal their identities in order to legally join the entity and may not be available to DAOs that seek to have a large, decentralized and pseudonymous membership base that is determined on the basis of ownership of a freely tradable token. However, there are some legal wrappers that may accommodate more fluid memberships and other “ownerless” entities such as foundations or special purpose trusts that can serve specific purposes, such as serving as a vehicle for future grantmaking. Such wrappers, however, may be novel and carry more legal ambiguity as to how they operate in practice. ### US-related activities The extent to which a DAO’s members and activities are in the US will also affect the range of legal wrappers that are available. Some offshore legal wrappers, such as an ownerless foundation or special purpose trust, may not be available or tax efficient for projects with significant US-connections. Conversely, projects that don’t have a significant US nexus may want to avoid relying on US-based legal wrappers in order to lower tax and liability exposure in the US. DAOs should therefore design the governance mechanisms controlling their legal wrappers to ensure that they don’t inadvertently hamper the effectiveness of their legal structure. ### Resources of the DAO From a practical perspective, DAOs should consider how much of their resources they want to devote to their legal structure. As noted above, there are no perfect solutions and in order to be effective, complex DAOs will likely need a bespoke structure – and this can quickly get expensive. A potential option is to start with a simple structure which is further developed over time, as the scope of the DAO’s activities grows, and so do the resources at its disposal. ## Legal Wrappers (A Quick Overview) Once founders understand the strategic considerations applicable to their DAO, the next step is to analyze which legal wrappers might be most adequate. We provide an in depth analysis of these wrappers in our white paper, but here’s a quick, and very broad, overview: ### Unincorporated General Partnership One of the risks of operating a DAO without a legal entity is the DAO being deemed an unincorporated general partnership. While this theory has yet to be proven in a court and it has faced some criticism, it could potentially result in DAO members being liable for other members' liabilities or those of the DAO. ### Corporations The most common type of traditional legal entity can be helpful to isolate tax and legal liability for DAO projects, but has some limits in terms of its structure (e.g., it requires centralized governance in the form of a board of directors, etc.), membership and also subjects DAOs to US tax. They have been leveraged as DevCos, or as siloed entities which are affiliated to the DAO and intended to block a specific liability or other special purpose (such as a subDAO). ### LLC LLCs are also widely used in the traditional context, but offer more structural flexibility than corporations in terms of their governance. LLCs can be member-managed and allow members to waive their fiduciary duties to each other, making them more adept to decentralized governance. Some states have even passed specific DAO LLC laws that are intended to facilitate a DAO’s operations. However, DAOs with very large or fluid memberships will be limited in their ability to use LLCs and even a member-managed LLC will have certain points of centralization (e.g., a tax representative). ### Nonprofit Options DAOs with charitable missions could also look to form a nonprofit entity and have it designated as tax exempt in the US. This route provides the DAO with legal personhood and important tax benefits, but limits a DAOs range of activity and ability to distribute profits to its members. Some projects have used multi-entity structures that incorporate for-profit and nonprofit entities. ### UNA Unincorporated non-profit associations are the non-profit equivalent of an unincorporated general partnership, but in certain states can provide its members with limited liability and can also file with the IRS to be taxed as a corporation. UNAs also potentially offer a more flexible framework to facilitate a fluid membership. While UNAs are limited in distributing profits back to their members, they can engage in some for profit activities (this may, however, disqualify them from tax-exempt status). One downside to UNAs is that their implementing statutes can vary widely from state to state and there is little case law, making potential outcomes hard to determine. ### Co-Ops Co-ops are a form of legal wrapper that has a long history in the US and provides an alternative to the traditional corporate model that separates ownership and control by typically requiring all members to be both owners and direct contributors to the co-op. Certain states have passed more modern Co-op frameworks that allow for investor members and variations from the one-member one-vote standard which have led to some DAOs experimenting with this entity type. ### Ownerless Foundations Ownerless foundations are a form of legal wrapper available in certain offshore jurisdictions that acts like a trust that is controlled by a board or council which can in turn be directed by the vote of the DAO. The foundation can be used to make grants to further the development of a protocol. However, the DAO members will not be owners of the foundation or “wrapped” by that entity. There are some limits on the control that US-based projects can exercise on offshore foundations in order to maintain their tax advantages and other liability protections. ### Special Purpose Trusts This legal wrapper is a type of trust available in certain offshore jurisdictions which can be created by transferring assets to a set of Trustees which can in turn act as instructed by the vote of the DAOs token holders. The Trustees are supervised by an Enforcer who can bring suit if they act improperly. It is similar to the ownersless foundation in that it can be used as a vehicle to custody and distribute assets as well as enter into legal agreements. One perceived advantage of this structure is that it does not require any governmental filing to be formed, as it is purely a creature of contract between the person contributing the assets and those that will act as their stewards. [^1]: Adolf A. Berle and Gardiner C. Means, The Modern Corporation and Private Property (New York: Harcourt, Brace & World, [1932 [^2]: For example, to qualify as an investment club, which is how several venture DAOs have avoided the need to register as an investment company (a virtually impossible task with most DAO structures), there must be no more than 100 members. (see reference). If a DAO is leveraging a private company in the US (such as a Delaware C-corporation) as part of its structure, it should be mindful that membership thresholds can also require it to register as a reporting company (requiring costly disclosure and potentially more liability) (see reference) ## https://www.paradigm.xyz/writing/legal-options-for-daos # Legal Options for DAOs > A discussion on legal options related to DAOs. At Paradigm, we believe Web3 can revolutionize the way people interact with each other online, springing forth the next generation of internet applications and businesses that give users ownership and economic exposure to the growth of the underlying protocols, resulting in more flexible and powerful forms of human coordination. Realizing this vision requires the development of new primitives—the building block ideas, frameworks, and mechanisms that form the basis for advancement. To date, the contribution of these primitives has mostly come from researchers and engineers. We’re no stranger to that, with Paradigm team members devising open-source mechanism designs and [tools](https://www.paradigm.xyz/2021/12/introducing-the-foundry-ethereum-development-toolbox). However, the need for new Web3 primitives is not limited to the technical realm. It also includes novel legal structuring that helps the emerging online world become intelligible to offline institutions. Several people have already made [significant](https://github.com/orgs/LeXpunK-Army/repositories) [contributions](https://github.com/lex-node?tab=repositories) to creating open-source legal infrastructure. But one burgeoning area of Web3—decentralized autonomous organizations, or DAOs—has lagged in terms of having proper, well-documented legal frameworks. DAOs are experiencing a Cambrian explosion, as new use cases and communities spring up and seek to leverage blockchain technology to re-imagine how people can collectively organize. Yet as a founder it is extremely difficult to make sense of the available legal structures and their implications. To help solve this problem, we have created the DAO Legal Entity Matrix, a simple resource for comparing various legal structures used by DAOs in the US as well as a few international jurisdictions. The DAO Legal Entity Matrix is intended to be a starting point for founders and their legal counsel to better inform them about the issues as they consider potential legal structuring solutions for DAOs. To solicit the community's input and engagement and make this a living document, we are releasing the DAO Legal Entity Matrix in two parts. The first part is a [mobile-friendly page](https://daos.paradigm.xyz/) that can be easily accessed by anyone looking to get a deeper understanding of the available legal structures for DAOs. The second part is a [public Notion page](https://paradigmxyz.notion.site/DAO-Legal-Matrix-51d3d8ffd67d483a8058bc36f6bc50ad) for those that are more in the weeds and want to comment on the chart, allowing us to merge updates and revisions onto the website with the hope of providing an evergreen resource to the broader community. We encourage those with specific experiences to add their knowledge to this collective vehicle and further the discussion. At Paradigm we want to contribute to the advancement of open-source legal infrastructure and will continue to look for opportunities to do so in the future – so please reach out if you want to collaborate. [Browse the Matrix](https://daos.paradigm.xyz/) ## https://www.paradigm.xyz/writing/evaluating-web3-jobs-like-an-investor # Evaluating Web3 jobs like an investor > This piece advises treating the evaluation of Web3 job opportunities with the same diligence as an investor would, leveraging accessible on-chain quantitative metrics and qualitative aspects to make informed decisions about potential roles. Let’s say you’re a candidate with job offers from a handful of startups. Each one looks great on the surface: sleek website, successful founders, strong early team, and name-brand investors. At some point, you need to make a decision: which one will you join? The decision process is one that mirrors what an investor might go through when evaluating investment opportunities. Both decisions have a similar end goal: maximize your return, not just financially, but across several metrics that enable you to grow and be positioned for even bigger opportunities later on. To make the decision, an investor, through the process of due diligence, will look at both the qualitative and quantitative aspects of an opportunity. It stands to reason that you, as a candidate, should do the same. Some qualitative characteristics, like the team, might be evaluated the same way in Web2 as in Web3: pedigree, references, interviews, and chats with previous investors. You have to decide based on your qualitative experiences which job presents the best culture fit, where you feel you can thrive, contribute, and learn from those around you. But where things start to differ in Web3 are a candidate’s access to previously (in Web2) inaccessible quantitative metrics of early-stage opportunities. Investors have long enjoyed access to the quantitative metrics of private companies, giving them signals to understand a business’s current state and long-term potential. Prior to Web3, these generally were not accessible to a job candidate, even one with an offer in hand. These metrics were usually closely guarded secrets, except when disclosures are mandated by law or regulation. Were you, as a candidate, to ask for them, you would likely be told “no” and be asked instead to trust them. But as we said, in Web3, things are different. Even in early-stage opportunities, the quantitative metrics that might help with your decision are, by default, publicly available on-chain. Whether you’re curious about growth, revenue, transactions, or retention, with a bit of understanding, consideration of context, and the right tools, a protocol’s user activity, and core business metrics are freely available. Want to understand how many daily active wallets interact with a protocol? Search the name of the protocol on [Dune Analytics](https://dune.com/home) and pull up a dashboard or two. Want to see what a decentralized exchange’s transaction volume looks like? Use a free tool like [Coingecko](https://www.coingecko.com/en/dex). The metrics you might care about will vary from company to company and vertical to vertical, but the data is there if you want to find it. Web3 is offering the ability for you to select a job opportunity not based on trust alone, but with the open book that was previously the sole province of investors. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--8a6e58792b/c50cccdc8ee28e236bf7a512861e164f/asset-https-cdn-sanity-io-images-dgybcd83--8a6e58792b.png) *Example chart of a Web3 project that grabs public on-chain wallet data to display new and existing Daily Active Users* It’s important to note, as with anything data-related, context is everything. Sometimes metrics can be misleading. And at times a project’s nuances can be set up to incentivize unusual activity. For example, a retroactive airdrop could induce one-to-many user-to-wallets to interact with the protocol, skewing some reporting. Just like an investor would, ask yourself critical questions about why the numbers are what they are. Seek a second opinion from someone you trust, or ask the company making the offer what their take is. In many cases there are pre-built crowdsourced dashboards that can help you find this information, so even if you’re non-technical you still have access. With a little bit of SQL knowledge, you can dig a click deeper and build those dashboards yourself. On the other side of the table, if you’re a founder, consider creating resources to visualize on-chain data that might make a compelling case for candidates, and share them proactively. On that note, just as data can be a tool for job seekers, it can also be a tool and competitive advantage for founders to help land employees. Transparency makes founders’ lives easier by reducing the need for candidates to take a leap of faith. Reducing the need for blind trust and replacing it with clear data can have knock-on effects across the entire company. When candidates have access to meaningful information about company performance, they can walk in the door on their first day with high confidence in the team and the project. If you’re reading this as a founder rather than a job seeker, consider the impact you can have on your company by including transparent data and metrics as part of your recruitment practice. When the entire company, and even prospective employees, have access to data that show how the business is performing, everyone is incentivized to think about their role not merely as employees, but as owners, and investors. If you're looking for a new role in crypto/Web3, we'd love to help you find it: [talent.paradigm.xyz](https://talent.paradigm.xyz/). ## https://www.paradigm.xyz/writing/joining-paradigm-katie-biber # Joining Paradigm > Katie Biber joins Paradigm as the CLO. I’m thrilled to announce that I’m joining Paradigm as Chief Legal Officer, helping [Matt](https://www.paradigm.xyz/team/matthuang) and [Fred](https://www.paradigm.xyz/team/fredehrsam) expand the outstanding firm they founded only four years ago. I will be working alongside the best Legal and Policy teams in the industry, accelerating our hiring and further focusing our goals. I’ve worked as an in-house tech lawyer since 2013. Reid Hoffman is right – being an entrepreneur is like throwing yourself off a cliff, and I’ve had the privilege of supporting some of the very best through their toughest moments. It is because of this experience that the Paradigm ethos appealed to me instantly: founders are front and center, and VCs are fortunate to support them. I’ve been in and around crypto since 2018, when I joined Anchorage Digital, the first crypto company to receive a federal bank charter, as one of its earliest employees. I got a true baptism by fire from Nathan McCauley and Diogo Monica, gifted founders who were always patient enough to stop and explain hard concepts to a lawyer trying to learn. Since then, I joined the Anchorage Board, along with the Board of Protocol Labs, one of the companies developing the groundbreaking Filecoin distributed storage network. It will be a true privilege to work with [Alana Palmedo](https://www.paradigm.xyz/team/alanapalmedo), Paradigm’s fearless COO, who established and grew the firm’s operations from zero to today. Alana’s strategic prowess and flawless execution have been a critical part of the firm’s growth. I am looking forward to partnering with [Reena Jashnani-Slusarz](https://www.paradigm.xyz/team/reenajashnanislusarz), Paradigm’s talented General Counsel and Chief Compliance Officer. I am blown away at what Reena has accomplished since stepping into this dual role in 2021. In addition to standing up critical compliance programs, she has supported a fast-paced investment team without skipping a beat. She has been aided by Paradigm’s brilliant legal team, [Rodrigo Seira](https://www.paradigm.xyz/team/rodrigoseira) and [Josh Ephraim](https://www.paradigm.xyz/team/joshephraim). I also am excited to work with [Justin Slaughter](https://www.paradigm.xyz/team/justinslaughter), the Director of Policy. Justin is a well-known leader in the crypto space. In the months leading up to my start date at Paradigm, I’ve heard a steady drumbeat of praise about Justin from founders, policy leads, and GCs across the industry. He brings a rare combination to the role: technical policy chops and a keen strategic mind. Crypto has recently been on a roller coaster ride. But the ups and downs of BTC and ETH are just noise. The promise of web3 comes into sharper focus with every passing day. It’s no longer just a hunch – I am now confident that today’s builders will democratize finance, create a more equitable internet, and bring us tools that help humans exchange goods, services, opinions, and information trustlessly. Over the next few years, I look forward to working with the exciting, cacophonous web3 community to tell our story and definitively flatten the meme that our technology is just a solution in search of a problem (a criticism leveled against the internet in the early days, too). The future is obvious, and it’s our job to make it happen in partnership with regulators. If you are a lawyer, policy professional, compliance officer, or a technologist with a love for explaining your trade to laypersons, Paradigm is [hiring](https://www.paradigm.xyz/opportunities). :) ## https://www.paradigm.xyz/writing/paradigm-fellowship # Paradigm Fellowship > At Paradigm, we want to work with the brightest minds in crypto. The Paradigm Fellowship is for that next generation of crypto talent. Today, we’re announcing the Paradigm Fellowship: a program for young, ambitious crypto-minded talent who are looking to learn, grow, and build. At Paradigm, we want to work with the brightest minds in crypto. This has led us to hire or partner with several young engineers, researchers and entrepreneurs who have gone on to play an instrumental role in Paradigm’s contribution to crypto. We’re excited to deepen Paradigm’s role in supporting the next generation of crypto talent with the Paradigm Fellowship. The Fellowship is designed to create a small community of the best and brightest young crypto talent and connect them with all the resources that Paradigm has to offer. Fellows can come from any background. From software engineers to creatives, we want the Fellowship to combine a range of complementary perspectives on the future of crypto. Specifically, the Fellowship will include: - **Summer Retreat.** Spend a few days in the Paradigm office in San Francisco. Travel, accommodation and a small stipend for expenses to be provided by Paradigm. - **Speaker Series.** A series of fireside chats with the Paradigm team and other notable members of the crypto community, during the retreat - **Mentorship.** Receive guidance from the Paradigm team in whatever you’re pursuing - **Community.** Fun social activities with your cohort and a lifelong community in crypto Applications are open today! We will be accepting Fellows on a rolling basis (so apply early) with final applications due by June 15th. The application process will consist of an initial application followed by interviews with the Paradigm team. We look forward to reviewing your applications and speaking with you! ## https://www.paradigm.xyz/writing/joining-paradigm-caitlin-pintavorn # Joining Paradigm > Caitlin Pintavorn joins Paradigm as an Investment Associate. In 2006, I was spending my days after elementary school on Club Penguin. By 2020, I was spending the entirety of my college days on Zoom. I was born into and grew up on the internet, and have held a front-row seat in watching our collective attention increasingly shift from physical to digital spaces. When the pandemic forced the entire world to turn virtual, I wandered around the internet in search of community. I found mine in Crypto Twitter and Discord servers, where my smartest IRL and URL friends were coming together to develop DeFi primitives, design NFTs, and launch nearly constitution-acquiring DAOs. The energy and creativity around building in crypto was magnetic, and led me to meet with hundreds of founders during my time as an investor at Insight Partners. While I initially came into the space for the people, I've stayed because I believe in crypto’s long-term potential to change the way we coordinate and interact for the better. I feel fortunate to be able to continue my journey down the rabbit hole in my new role as an Investment Associate at Paradigm. Matt and Fred have built a unique culture in finding and attracting the best crypto talent from every corner of the internet. From Sam’s [on-chain investigations](https://www.paradigm.xyz/2021/08/two-rights-might-make-a-wrong), to Georgios’ [development of Foundry](https://www.paradigm.xyz/2022/03/foundry-02), to Arjun’s [explorations of crypto market structures](https://www.paradigm.xyz/2020/10/crypto-market-structure-3-0), the team has been laying the bedrock for builders to create generational companies and protocols. In many ways, Paradigm is the community I've long been searching for. At Paradigm, I'll be partnering with founders across all stages and sectors. I’m joining at an inflection point in crypto’s trajectory, as it journeys from niche to mainstream, and I hope to help founders turn their ideas into enduring realities. Whether you’re thinking about or actively building something, I'd love to meet you. You can reach me at [caitlin@paradigm.xyz](mailto:caitlin@paradigm.xyz) or on Twitter @caitlinxyz. *Thanks to those who’ve been there along the way:* [*Deven*](https://twitter.com/djparekh)*,* [*Erhan*](https://twitter.com/helloerhan)*,* [*Anna*](https://www.linkedin.com/in/anna-boffetta/)*, and* [*Megan*](https://www.linkedin.com/in/megan-p-rothney/) *for showing me how to distinguish between signal and noise;* [*Evan*](https://twitter.com/evanbfish)*,* [*Danny*](https://twitter.com/dadkins_)*,* [*Darren*](https://twitter.com/Darrenlautf)*,* [*Daryl*](https://twitter.com/Daryllautk)*, and* [*Cindy*](https://twitter.com/cindyleowtt) *for being my crypto go-to’s;* [*Mark*](https://twitter.com/Mark_Goldberg_)*,* [*Will*](https://twitter.com/willgural)*,* [*Bill*](https://twitter.com/BillCoughran)*,* [*Kais*](https://twitter.com/kaiskhimji)*, and* [*Stephen*](https://twitter.com/scho_026) *for being thoughtful sounding boards.* ## https://www.paradigm.xyz/writing/the-dominance-of-uniswap-v3-liquidity # The Dominance of Uniswap v3 Liquidity > New research published today shows that Uniswap Protocol v3 has deeper liquidity in ETH/USD, ETH/BTC and other ETH pairs than leading centralized exchanges. This research demonstrates that AMM market structure – which is largely crypto-native today – can surpass order-book exchanges and transform traditional financial market structure to be more liquid, stable, and secure. New research published today shows that Uniswap Protocol v3 has deeper liquidity in ETH/USD, ETH/BTC and other ETH pairs than leading centralized exchanges. This research demonstrates that AMM market structure – which is largely crypto-native today – can surpass order-book exchanges and transform traditional financial market structure to be more liquid, stable, and secure. The complete research report and our open-sourced methodology are [here](https://uniswap.org/blog/uniswap-v3-dominance) (and in pdf form [here](https://uniswap.org/TheDominanceofUniswapv3Liquidity.pdf)), and we are making our [code](https://github.com/Uniswap/v3-market-depth-study) and [data](https://bit.ly/v3depthdata) freely available. In summary: - For ETH/USD, Uniswap has ~2x more liquidity than both Binance and Coinbase. - For ETH/BTC, Uniswap has ~3x more liquidity than Binance and ~4.5x more liquidity than Coinbase. - For ETH/mid-cap pairs Uniswap has on average ~3x more liquidity than major centralized exchanges. **Market depth comparison for ETH/USD stables and ETH/BTC ** ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--abc32ad9e1/d60ecee713f6540fe6d11647f3e5a0c4/asset-https-cdn-sanity-io-images-dgybcd83--abc32ad9e1.jpg) *Note: The figure shows the daily average +/- 2% spot market depth in $millions for the sample period from June 2021 to March 2022 for ETH/USD and February 2022 to March 2022 for ETH/BTC. The market depth for ETH/USD is aggregated across ETH/USD (fiat), ETH/USDC, ETH/USDT, and ETH/DAI. Data on centralized exchanges is provided by Kaiko. The comparison does not include some exchanges, including FTX and Bybit, due to a lack of data.* The research also finds that many stablecoin pairs have much more liquidity on Uniswap v3 than centralized exchanges. For USDC/USDT, Uniswap v3 has about ~5.5x more liquidity than Binance. Uniswap v3 also has higher market depth across all price levels, which means it’s even more advantageous for users to execute larger trades on Uniswap v3 relative to centralized exchanges. For an ETH/dollar trade size of $5mm, for example, the savings would be around $24,000 given the expected price impact difference. (For $5mm notional, the average price impact is roughly 0.5% on Uniswap v3 and 1% on Coinbase. The fee is about 2 bps lower on Coinbase on average.) Traditional market structure is dominated by a few market makers. But easy liquidity creation (AMMs) dramatically lowers the barrier to create and participate in markets. This unlocks new and existing forms of value for communities and individuals. We look forward to sharing more research with you! ## https://www.paradigm.xyz/writing/zk-hardware # Hardware Acceleration for Zero Knowledge Proofs > Zero Knowledge cryptography is one of the most notable innovations in the last fifty years of computer science. Zero Knowledge Proofs (ZKPs) offer unique properties that make them essential components of various blockchain scaling and privacy solutions. # Introduction Zero Knowledge cryptography is one of the most notable innovations in the last fifty years of computer science. Zero Knowledge Proofs (ZKPs) offer unique properties that make them essential components of various blockchain scaling and privacy solutions, including ZK rollups like [StarkNet](https://starkware.co/starknet), private ZK rollups like [Aztec](https://aztec.network/), and Layer 1 chains like [Mina](https://minaprotocol.com/), [Filecoin](https://filecoin.io/) & [Aleo](https://aleo.org/). ZKPs are slow and expensive to produce due to a large number of expensive math operations. However, with the usage of specialized hardware like Field Programmable Gate Arrays (FPGAs) and Application Specific Integrated Circuits (ASICs), they can be accelerated by 10-1000x. As users seek more expressive, performant, and private computation, the complexity of the statements proven with ZKPs will increase. This will result in slower proof generation, necessitating the use of specialized hardware so that proofs can be produced in a timely manner. The operators of the hardware will need to be compensated for their work, similar to Bitcoin miners. Eventually, a full ZK mining and proving industry will manifest, starting with hobbyists generating proofs in their CPUs, then GPUs, then FPGAs. In contrast to Bitcoin, we anticipate that ASICs could take a long time to see adoption, if ever. # Why do Zero Knowledge Proofs matter? Zero Knowledge Proofs have two main use cases. Outsourced Verifiable Computation Assume you have some computation that is expensive or impossible to run due to constraints of the platform you are using (e.g. your laptop, a Raspberry Pi, or even Ethereum). Instead of running the computation on your platform, you must run it on a third-party service that can return to you the output of the computation quickly and cheaply (e.g. an AWS Lambda function, or an oracle service like Chainlink). Normally, you would need to trust that the computation has been executed correctly, allowing the provider to output an invalid result, with potentially catastrophic consequences. **ZKPs allow a third party provider to also output a proof of computational integrity which guarantees the output you received is correct.** Private Computation What if you have a computation that is not expensive to run locally, but you’d like to hide parts of it? For example, what if I want to show you that I know the 1000th Fibonacci number without telling you the number, or convince you I sent a payment without revealing either the amount or my identity? **ZKPs allow you to selectively hide some or all inputs around a computational statement.** Both of the above use cases have manifested in the crypto industry in multiple form factors (among others): - Layer 2 scaling: Verifiable computation with ZKPs allow L1s to outsource transaction processing to off-chain high-performance systems (aka Layer 2s). This enables blockchain scaling without compromising on security. As an example, [StarkWare](https://starkware.co/) is building a scalable smart contract platform, [StarkNet](https://starkware.co/starknet/), using a [special-purpose virtual machine](https://www.cairo-lang.org/) that runs ZK-friendly code. [Aztec](https://aztec.network/) also enables their Layer 2 programs to run privately, without leaking any information about a user’s transactions. - Private L1s: L1 chains like Aleo, Mina, and Zcash allow transactors to hide senders, receivers, or amounts using ZKPs, either by default (Aleo) or as an opt-in (Mina and Zcash). - Decentralized Storage: [Filecoin](https://filecoin.io/) uses ZKPs (running on GPUs) to prove that nodes in the network store data correctly. - Blockchain Compression: Mina and Celo use ZKPs to compress the blockchain data needed to synchronize to the latest state of the chain into a small proof. Given the above, it is safe to say that as cryptocurrency adoption increases, ZKPs will be required in order to accommodate the increased demand for performance and privacy from users, and new types of applications and protocols. **ZKPs fundamentally allow scalable and private payments and smart contract platforms to thrive but introduce non-trivial overheads which have historically hindered their adoption.** # Why are ZKPs slow and how do we make them fast? Proving a computation requires first translating it from a classical program to a ZK-friendly format. This is done either by manually rewriting your code to use a low-level library like [Arkworks](https://github.com/arkworks-rs), or by using a Domain Specific Language like [Cairo](https://www.cairo-lang.org/) or [Circom](https://iden3.io/circom) that compiles down to the necessary primitives to generate the proof. More expensive and complex operations result in longer proof generation times. It is also common that some operations are not ZK-friendly (e.g. the bitwise operations used in SHA or Keccak), resulting in long proof generation times for what might be a cheap operation on a classical computer. Once your computation is in ZK-friendly form, you choose some inputs and send it to a proof system. There are many proof systems, some named after the authors of their papers (e.g. [Groth16](https://eprint.iacr.org/2016/260.pdf), [GM17](https://eprint.iacr.org/2017/540)) and others with more creative names ([PLONK](https://eprint.iacr.org/2019/953.pdf), [Spartan](https://eprint.iacr.org/2019/550.pdf), [STARK](https://eprint.iacr.org/2018/046.pdf)). What they all have in common is that they take a computation that’s expressed in a ZK-friendly format along with some inputs and output a proof. Depending on the proof system, the proof generation process may differ, but the bottleneck always ends up being either: 1. **Multiplications** over large vectors of numbers (field or group elements), specifically [variable-base and fixed-base multi-scalar multiplications](https://youtu.be/Bl5mQA7UL2I) (MSMs); or, 2. **Fast Fourier Transforms** (FFTs) and Inverse FFTs (although [there](https://youtu.be/ffXgxvlCBvo) [are](https://eprint.iacr.org/2021/370.pdf) [techniques](https://github.com/arkworks-rs/gemini) for FFT-less proof systems). In systems where both FFTs and MSMs exist, about 70% of the time generating a proof is spent on MSMs, and the rest is dominated by FFTs. Both MSMs and FFTs are slow, but have ways of improving their performance: - MSMs are [embarrassingly parallel](https://en.wikipedia.org/wiki/Embarrassingly_parallel) and can be accelerated by running them over multiple threads. However, even on hundreds of cores, if each vector of elements is 225 long (that’s 33 million elements, a conservative complexity ballpark for an application like a [zkEVM](https://hackmd.io/@yezhang/S1_KMMbGt)), the multiplications still end up taking a lot of time. This means frequently repeating the same operations, and saturating most of the memory available on the device. In short, MSMs require a lot of memory and remain slow even when heavily parallelized. - FFTs heavily rely on the frequent shuffling of data as the algorithm runs. This makes them hard to speed up by distributing the load across a computing cluster, as shown in [DIZK](https://www.usenix.org/conference/usenixsecurity18/presentation/wu). In addition, they require a lot of bandwidth when run on hardware. The shuffling means that you need to ‘randomly’ load and unload elements from, for example, a >100GB dataset on a hardware chip with 16GB of memory or less. While operations on the hardware are very fast, the time to load and unload data over the wire ends up slowing operations significantly. In short: - MSMs have predictable memory accesses which allows for heavy parallelization, but their cost is still high because of the raw amount of compute and memory needed. - FFTs have random memory accesses which make them not friendly to hardware, on top of being naturally hard to run on distributed infrastructure. The most promising work we have seen on addressing the slowness of large MSMs and FFTs is PipeZK. In their [paper](https://www.microsoft.com/en-us/research/uploads/prod/2021/05/isca21_pizk-60a269dbb1310.pdf), the authors describe a method to make MSMs cheaper using [Pippenger’s algorithm](https://jbootle.github.io/Misc/pippenger.pdf) to skip duplicate computation. They also describe a method to “unroll” FFTs so they can be performed without significant shuffling, which allows for speed improvements on hardware due to the now-predictable memory access patterns. Assuming the above methods address the fundamental bottlenecks of each algorithm, the question then becomes: **What is the best hardware to flash with highly optimized MSM and FFT algorithms to accelerate ZKP generation?** # Hardware matters The above acceleration techniques can be implemented on multiple hardware technologies: GPUs, FPGAs, or ASICs. But which one is the best choice? To answer that, we first have to acknowledge that ZKPs are still early in their development. There is still little standardization on system parameters (e.g. FFT width or bit-size of elements) or choice of proof system. Due to these factors, there are two core properties of FPGAs which make them preferable to ASICs in the ZK context: - **“Write multiple times” vs “write once”**: The business logic on an ASIC is write-once. If any ZKP logic changes, you need to start from scratch. FPGAs can be re-flashed any amount of times in under 1 second, meaning they can re-use the same hardware across multiple chains with incompatible proof systems (e.g. because they want to extract MEV across chains), and nimbly adapt as the ZK “[meta](https://cobie.substack.com/p/trading-the-metagame)” changes. - **Healthier supply chain:** ASIC design, manufacturing, and deployment typically takes 12 to 18 months or more. On the contrary, FPGA supply chains are healthy, with leading providers like [Xilinx](https://www.xilinx.com/) allowing mass retail orders from the website (i.e. without any point of contact) which arrive within [16 weeks](https://www.xilinx.com/products/boards-and-kits/alveo/u55c.html#buy-from-xilinx). This allows an FPGA-centric operation to have a tighter feedback loop on its product, and scale up their operation by purchasing and deploying more FPGAs. We also expect FPGAs to outperform GPUs for similar reasons why they have thrived in machine learning and computer vision: - **Hardware Cost:** A top-of-class FPGA (leading process node, clock speed, energy efficiency, and memory bandwidth) is about 3x cheaper than a top-of-class GPU. The global demand for GPUs has further exacerbated this issue. - **Power Efficiency:** FPGAs can be >[10x](https://docs.xilinx.com/v/u/en-US/wp492-compute-intensive-sys) more energy efficient than GPUs, a large reason being the requirement for GPUs to be connected to a host device, which is often consuming a lot of power. Given the above, we expect that the winning players in the market will be companies that focus on FPGAs over ASICs or GPUs. If however only one or few ZK L1s or L2s end up achieving dominant scale, and ZK proof systems stabilize around a single implementation, then the likelihood of ASICs winning over FPGAs might be higher. But we are likely multiple years away from that scenario, if it ever occurs at all. # Conclusion In 2021, Bitcoin miners netted [over $15 billion](https://www.theblockcrypto.com/linked/128475/bitcoin-mining-2021-revenue) in revenue, and Ethereum miners [just exceeded $17 billion](https://www.theblockcrypto.com/data/on-chain-metrics/ethereum/ethereum-miner-revenue-monthly). It’s plausible that Zero Knowledge Proofs end up becoming the de-facto medium of computational integrity and privacy on the web. In that case, the opportunity for ZK miners/provers could be of similar size to the Proof of Work mining market. ZKPs are slow and will require hardware acceleration to be made feasible over complex computations. We believe that the technology that will matter the most for ZK hardware acceleration is FPGAs and not GPUs ([due to cost and energy efficiency](https://www.aldec.com/en/company/blog/167--fpgas-vs-gpus-for-machine-learning-applications-which-one-is-better)) or ASICs (due to their inflexibility and long iteration cycles). If you are a hardware, Rust, or cryptography expert interested in further discussing or working together on this subject, please reach out to me at [georgios@paradigm.xyz](mailto:georgios@paradigm.xyz). ## https://www.paradigm.xyz/writing/gda # Gradual Dutch Auctions > This paper introduces the Gradual Dutch Auction, or GDA, a mechanism that enables efficient sales of assets that do not have liquid markets. # Introduction This paper introduces the *Gradual Dutch Auction,* [1](https://www.paradigm.xyz/2022/04/gda#user-content-fn-1) or GDA, a mechanism that enables efficient sales of assets that do not have liquid markets. GDAs solve a similar problem to [TWAMM](https://www.paradigm.xyz/2021/07/twamm), but do not rely on the existence of liquidity providers willing to make markets on pairs of assets. GDAs work by breaking up a sale into a sequence of [Dutch auctions](https://en.wikipedia.org/wiki/Dutch_auction)—a type of auction that start with a high asking price that is gradually lowered until a buyer makes a bid. GDAs allow you to purchase multiple of these auctions at once in a gas-efficient manner. We provide an outline for both *discrete GDAs,* which are useful for selling NFTs, and *continuous GDAs,* which are useful for selling fungible tokens. We also include a [Python notebook](https://github.com/FrankieIsLost/gradual-dutch-auction/blob/master/analysis/analysis.ipynb) modeling the mechanism’s behavior, as well as a [reference Solidity implementation](https://github.com/FrankieIsLost/gradual-dutch-auction). # Discrete GDA ## Motivation Imagine Alice would like to sell a collection of 10,000 NFTs. She is unsure what a fair price for her art pieces would be, so she does not want to sell them at a fixed price. Instead, she might choose to sell them all in a single Dutch auction—starting with a high asking price, and gradually lowering it until all the NFTs are sold. However, such an auction can be suboptimal: there may not be enough interest from buyers to purchase all pieces at the same time. Instead, Alice could auction off one NFT at a time. For example, she might start a new Dutch auction every minute for a new piece in her collection. This will give the market more time to find a fair price for her art. Discrete GDAs are an extension of this idea, but support gas-efficient bulk purchases of multiple sub-auctions thanks to their mathematical properties. ## Mechanism Discrete GDAs are suitable for selling NFTs, because these have to be sold in integer quantities. They work by holding a *virtual* Dutch auction for each token being sold. These behave just like regular dutch auctions, with the ability for batches of auctions to be cleared efficiently. In a discrete GDA, every auction starts at the same time, with each successive auction having a higher starting price. The price of each auction is given by some *price function*, $p_n(t)$, where $n$ is index of the auction, and $t$ is the time since its start. Various price functions can be used with GDAs. One particular well-behaved formulation is given by: $$ p_n(t) = k \cdot \alpha^ne^{- \lambda t} $$ Here, the price for every auction decays exponentially according to some *decay constant **$\\lambda$*. The starting price of each auction increases by some fixed *scale factor **$\\alpha$*. And the starting price of the first auction is given by some *initial price **$k$**.* ### Calculating Batch Purchase Prices Given the above price function, we can efficiently compute the cost of purchasing a batch of auctions. Imagine that Bob wanted to purchase some quantity $q$ of tokens. To do this, he would purchase the $q$cheapest auctions. If $T$ seconds have passed since the auctions began, and $m$ total NFTs have been sold so far, the total price $P$ of purchasing $q$ tokens is given by: $$ P(q) = \sum_{n=m}^{m + q - 1} p_n(T) $$ For the case of the above price function, $P(q)$ can be computed efficiently. As shown in the appendix, the formula for $P(q)$ is: $$ P(q) = \frac{k \alpha^m(\alpha^{q} - 1)}{e^{\lambda T}(\alpha -1)} $$ We can plot the quantity of tokens being purchased in a single order against their cumulative price to obtain the following figure: ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--4ff5410411/6251bac552784ee6d56ad19060458ad4/asset-https-cdn-sanity-io-images-dgybcd83--4ff5410411.jpg) # Continuous GDA ## Motivation Having sold her NFTs, Alice now might want to sell some fungible tokens. One option would be for her to use the discrete GDA mechanism described above, to sell her tokens in fixed-sized lots. However, Alice might not want to make all her tokens available for sale immediately, as is the case with discrete GDAs. For example, she might be running a protocol that sells emissions at some constant rate, say, 360 tokens per day. Instead of using a discrete GDA, she could instead choose to sell her tokens in a series of standard dutch auctions. She could run one 360-token auction per day, one 15-token auctions per hour, or one 0.25-token auctions per minute. Again, there is a trade-off between price impact and gas efficiency, based on the number of auctions she holds. Continuous GDAs work by taking this process to the limit, where the time interval between auctions approaches 0. This means that sales are split into an infinite sequence of auctions, each selling an infinitesimal amount of the token. As it turns out, we can still compute the purchase price for any quantity of tokens in a gas-efficient manner. ## Mechanism Continuous GDAs work by incrementally making more of an asset available for sale, at a constant *emission rate, **$r$**. *For example, like we stated above, Alice might be interested in selling 0.25 tokens per minute. Emissions are broken up over an infinite series of *virtual* auctions. These auctions are started at an even rate over time, with each auction begining at the same price. The price of each auction is given by some *price function*, $p(t)$, where $t$ is the time since its start. Just like in discrete GDAs, many different price functions can work. One such function is: $$ p(t) = k \cdot e^{- \lambda t} $$ Like the previous example, price decays exponentially according to some *decay constant **$\\lambda$**, while **$k$* controls the starting price. ### Calculating Purchase Prices Say that Bob wanted to purchase some quantity $q$ of the token being sold by Alice. In order to buy that many tokens, he needs to purchase every auction started over a period of $\\frac{q}{r}$ seconds. Since prices decrease over time, he bids on the oldest available auctions. If the oldest available auction is $T$ seconds old, the total price $P$ of purchasing $q$ tokens is given by: $$ P(q) = \int^{T}_{T-\frac{q}{r}} p(t)dt $$ This means that we can compute the total purchase price in a gas-efficient manner as long as computing the integral of the *price function* is cheap. The total price of purchasing $q$ tokens using the above price function can be calculated efficiently on chain. As shown in the appendix, this price is given by: $$ P(q) =\frac{k}{\lambda} \cdot \frac{e^{\frac{\lambda q}{r}}-1}{e^{\lambda T}} $$ From which we obtain the following price curve: ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--b7366e5f1c/1c0809a9afd1ef39e91198a95cb5b1c1/asset-https-cdn-sanity-io-images-dgybcd83--b7366e5f1c.jpg) # Code We’ve included a [Python notebook](https://github.com/FrankieIsLost/gradual-dutch-auction/blob/master/analysis/analysis.ipynb) modeling GDAs and a [reference Solidity implementation](https://github.com/FrankieIsLost/gradual-dutch-auction). # Conclusion GDAs are a useful mechanism for selling both fungible and non-fungible tokens that do not have liquid markets. While this paper derives a few useful price functions, we believe many more could be used in different contexts. We hope GDA will be useful in a variety of applications beyond those described in this paper. If you’re a builder interested in implementing some of these concepts, please reach out to us at [@FrankieIsLost](https://twitter.com/FrankieIsLost), [@danrobinson](https://twitter.com/danrobinson), [@_Dave__White_](https://twitter.com/_Dave__White_) [@andy8052](https://twitter.com/andy8052) on Twitter. We’d be thrilled to hear from you. # Appendix ### Derivation of Discrete GDA with Exponential Price Decay $$ P(q) = \sum_{n=m}^{m + q -1} p_n(T) $$ $$ P(q) \sum_{n=m}^{m + q -1} k \cdot \alpha^ne^{- \lambda t} $$ $$ P(q) ke^{-\lambda T}\sum_{n=m}^{m + q -1} \alpha^n $$ $$ P(q) \frac{k \alpha^m(\alpha^{q} - 1)}{e^{\lambda T}(\alpha -1)} $$ ### Derivation of Continuous GDA with Exponential Price Decay $$ P(q) \int^{T}_{T-\frac{q}{r}} p(t)dt $$ $$ P(q) \int^{T}_{T-\frac{q}{r}} k \cdot e^{-\lambda t}dt $$ $$ P(q) \frac{k}{\lambda}\cdot \left( e^{-\lambda(T - \frac{q}{r})} - e^{-\lambda T} \right) $$ $$ P(q) \frac{k}{\lambda} \cdot \frac{e^{\frac{\lambda q}{r}}-1}{e^{\lambda T}} $$ ## Footnotes 1. Also known as [Australian Auctions](https://twitter.com/cobie/status/1511025769874481161). [↩](https://www.paradigm.xyz/2022/04/gda#user-content-fnref-1) ## https://www.paradigm.xyz/writing/foundry-02 # Announcing Foundry v0.2.02 > Foundry is a portable, fast, and modular toolkit for Ethereum application development, written in Rust. Foundry is built by Solidity developers for Solidity developers. # What is Foundry? Foundry is **a portable, fast, and modular toolkit for Ethereum application development, written in Rust.** Our goal with Foundry is to create the best developer experience for building secure smart contracts on EVM chains. Most importantly: **Foundry is built by Solidity developers for Solidity developers.** We [announced Foundry v0.1.0 in December 2021](https://www.paradigm.xyz/2021/12/introducing-the-foundry-ethereum-development-toolbox) as a first step towards improving the Ethereum development experience. This initial version centered on four key features: 1. Letting developers write tests in Solidity to minimize context switching; 2. Making tests and the compilation pipeline REALLY fast to keep the developer's feedback loop tight; 3. Using intuitive patterns for expanding test coverage, debugging, and testing against a live network's state; and, 4. Being easy to install and distribute across platforms. The results since December have convinced us that Foundry solves some major development pain points. On [Solmate](https://github.com/Rari-Capital/solmate) for instance, it [took down](https://twitter.com/onbjerg/status/1506722848106328071?s=20&t=FCDvJyHDos97X8nu_lvOOA) testing time **from 393s to 2.8s, a** **140x** **improvement**. Developers from top protocols like [Optimism](https://github.com/ethereum-optimism/optimistic-specs/pull/265) and [MakerDAO](https://github.com/makerdao/spells-mainnet#test-forge-without-optimizations) are using Foundry as a standalone framework, or will introduce it incrementally in their codebases to improve their build and test process. Now we're excited to announce **Foundry v0.2.0**, a major step forward for the toolkit. # What's new? TL;DR: we shipped a lot of code over the last three months. More than 400 pull requests and over 90 contributors later, we are proud to present the results: 1. **Faster Compilation and Testing**: Forge is now much faster at building your code and running your tests, 5-340x times faster than every alternative in the market. 2. **New Debugging & Gas Optimization features**: New features help you can gain insights on your code's internal execution paths, including call tracing, an interactive debugger, gas reports, and more. 3. **New Testing Features**: New cheatcodes for EVM state overrides and state-assisted fuzzing have been implemented to explore more code paths and increase confidence in your code's security. 4. **Easy Installation**: Foundry can now be installed out of the box on all platforms in seconds. No Cargo, no NPM, <15MB. This is the best UX for installing a new Ethereum development tool we've ever had. 5. **Foundry Configuration File**: We introduced `foundry.toml` so that you can specify project-specific settings without needing to write custom scripts for passing CLI parameters. We also now have the [Foundry Book](https://onbjerg.github.io/foundry-book/), our official documentation! While it's still at its early stages, it shows how to set up a Foundry project, write unit & fuzz tests, use cheatcodes, fork from a live network, and more. In this post we'll focus on the new features that were added to Forge, Foundry's testing framework. [Cast](https://onbjerg.github.io/foundry-book/cast/index.html), the Swiss Army knife for interacting with a live network, will be covered in a separate post. If all this sounds exciting, let's dive in. # Blazing-fast compilation & testing Foundry devs and users are *obsessed* with speed. We want our code to compile fast, and the tests to run even faster. As a result, we've been carefully optimizing every part of the compilation and testing pipeline. But first, let's see *how fast* it really is. ## Compilation Benchmarks We tested the time it takes to build a project with various caching scenarios. We chose to use [openzeppelin-contracts](https://github.com/OpenZeppelin/openzeppelin-contracts) and [Uniswap/v3-core](https://github.com/Uniswap/v3-core/) as our benchmark repositories. The following scenarios were checked: 1. No caching involved: We'd expect most of the time to be dominated by `solc` execution. 2. Some Caching: We compile the project, modify a file "deep" in the dependency graph, and compile again. We expect this to be somewhat faster but not a lot, given that most of the project is getting recompiled. 3. A lot of caching: Same as above, but we modify a file at the edge of the dependency graph, which will cause more cache hits, so we expect it to be faster. 4. Full cache: No file is touched, the equivalent of running the same compilation command 2 times in a row. We provide the following graphs which plot the time it took to compile for each scenario (lower is better): ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--f0877c55c6/a66f916d5d7eddb5a4d31a2a729c6ce7/asset-https-cdn-sanity-io-images-dgybcd83--f0877c55c6.png) ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--5cf499a43c/22dcd4e1b45ef15d655ceafb68dedfe6/asset-https-cdn-sanity-io-images-dgybcd83--5cf499a43c.png) **Takeaway: Forge compilation is consistently faster by a factor of 1.7-11.3x, depending on the amount of caching involved.** The above results used the same compiler settings but did not attempt to modify Hardhat's settings from the defaults. It is possible that performance can be improved by tuning the settings (e.g. disable plugins or Typescript typechecks) but we chose to benchmark against the default settings since that is what most users experience. ## Testing Benchmarks We then proceeded to benchmark performance against other frameworks. We started by comparing performance with `dapp`, Forge's "parent" which recently [passed on the torch](https://github.com/dapphub/dapptools/pull/927/files) to Foundry. Thank you DappTools! *(Note that in the above benchmarks compilation was always skipped.)* |Repository | Forge | DappTools| Speedup | -- | -- | -- | -- |[maple-finance/loans](https://github.com/maple-labs/loan) | 800ms | 268s | **335x** | [Rari-Capital/solmate](https://github.com/Rari-Capital/solmate) | 2.8s | 394s | **140x** |[reflexer-labs/geb](https://github.com/reflexer-labs/geb) | 0.4s | 23s | **57.5x** |[Rari-Capital/vaults](https://github.com/Rari-Capital/vaults) | 0.28s | 6.5s | **23x** Then, we ported some tests from [`@uniswap/v3-periphery`](https://github.com/Uniswap/v3-periphery) to use Forge, so that we could compare against Hardhat. Deploying Uniswap and running the ["exact input"](https://github.com/gakonst/v3-periphery-foundry/blob/main/test/SwapRouter.spec.ts#L139-L278) tests took **10s on Hardhat, and 600ms on Forge, a 16x improvement. ** ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--b21a862545/c56ed4f90045c612aeaa550f3b984eb8/asset-https-cdn-sanity-io-images-dgybcd83--b21a862545.png) Finally, we wanted to test performance when forking against a live network. So we used Convex Finance's shutdown functionality as a benchmark to compare not only against other frameworks, but against hosted services like Blocknative and Tenderly as well. ```text Framework,Remote RPC,Local RPC,Cached Blocknative,N/A,N/A,3.529s Dapptools,52m 17.447s,17m 34.869s,3m 25.896s Ganache,10m 5.384s,1m 2.275s,22.662s Hardhat,8m 26.483s,35.145s,7.531s Foundry,6m 59.875s,13.610s,0.537s Tenderly,N/A,N/A,17.805s ``` Check the [repository](https://github.com/mds1/convex-shutdown-simulation) for more context on how the measurements were made. **Takeaway: Forge is the fastest EVM test runner that exists, even beating hosted services in transaction simulation speeds.** How is this all possible? That is a topic for another post dear reader, as each improvement we did deserves its own post. # Debugging & Gas Optimization UX Improvements As a reminder, at the December launch we already supported Hardhat's [`console.sol`](https://github.com/brockelmore/forge-std/blob/master/src/console.sol)-style logging, and Dapptools' [`emit log`](https://github.com/dapphub/ds-test/blob/master/src/test.sol#L19-L36)-based logging which allow you to print values along your contract's execution. We also supported showing the gas cost of each test. That, however, was not enough! We cannot expect a developer to annotate all their code with logs to figure out what is happening. They also want more granularity on the gas cost of each individual call, instead of the entire test cost. ## Call Traces To provide more runtime introspection, we introduced call traces, which provide a structured output of every external call made by any contract, along with its arguments and return value. This is the output you'd get when running `forge test -vvvv`: ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--45a8b6550c/541f3b6cd2a8aab722452db0633f0125/asset-https-cdn-sanity-io-images-dgybcd83--45a8b6550c.png) Notice how successful calls are colored in green, reverts are red, and cheatcode calls are blue! More details on how calltraces work [can be found in the book](https://onbjerg.github.io/foundry-book/forge/traces.html). ## Interactive Debugger However, call traces do not give you insight on the opcode by opcode execution of your code, which you may want to view when you are doing low level optimizations or trying to debug a test and need to inspect the state of the EVM's stack and memory. To solve that, we provide an interactive debugger as part of `forge test --debug` and `forge run`. Here's how it looks like (you can navigate with keyboard buttons shown at the bottom of the screen): ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--ddf04d864b/e8064ccfb2623f77250d838e7ef43ed6/asset-https-cdn-sanity-io-images-dgybcd83--ddf04d864b.jpg) ## Gas Reports Most Ethereum developers are familiar with the gas table produced by [eth-gas-reporter](https://github.com/cgewecke/hardhat-gas-reporter). We also ported that to work with Foundry. This is how `forge test --gas-report` looks like: ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--206e548c63/45a0026a820849825afb25776e14726b/asset-https-cdn-sanity-io-images-dgybcd83--206e548c63.png) # New Testing Features We all know that smart contract security is hard. We want to make that easier, by providing functionality so that developers can test every path in their code. ## New Cheatcodes Foundry and DappTools allows overriding the state of the EVM, with a method called "cheatcodes". For example, you can use the `roll` cheatcode to set the block number, the `store` cheatcode to set an arbitrary storage slot to any value, `prank` to impersonate an arbitrary address, among others. This is quite powerful! We have introduced a variety of new cheatcodes so that developers can have *even more* control over their tests' state. See all supported cheatcodes below: ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--a1cd8c336c/4a6778942cfd20a9129171fd470fb29e/asset-https-cdn-sanity-io-images-dgybcd83--a1cd8c336c.png) For more information on how to use each cheat code, please refer to the [Cheatcodes Reference](https://onbjerg.github.io/foundry-book/forge/cheatcodes.html), and [Foundry's cheatcode unit tests](https://github.com/gakonst/foundry/tree/master/testdata). ## Fuzzer Improvements Foundry not only lets you write blazing fast configurable unit tests, it provides great UX for writing property-based tests, which we call fuzz tests. We made two big improvements to the fuzzer: 1. Biasing edges for unsigned integers: Previously we were picking numbers at random. Now, we check all the number boundaries, as well as values in the neighborhood of the boundary (e.g. 0, 1, 2, `UINT256_MAX`, `UINT256_MAX - 1` etc.) 2. State dictionary-assisted fuzzer: Every output, state modification, address, balance, and log produced during execution is now added to the fuzzer's dictionary. This allows trying out values which otherwise would never get hit if chosen randomly. The result? A fuzzer that can find even the most bespoke edge cases *very* fast. We invite you to try it out, and in the future will be benchmarking it against other industry fuzzers. # Easy Installation The most important phase when attracting a new user, is the installation phase. Previously, installing Foundry could only be done from source and required having Rust installed. That's not good enough! So we fixed it in two ways: 1. A nightly GitHub Action that cuts a release with any changes that happened in the last 24 hours and publishes it under the [Releases page on Github](https://github.com/gakonst/foundry/releases). 2. An updater script that downloads the latest nightly version and installs it under `~/.foundry/bin`, called [`foundryup`](https://github.com/gakonst/foundry/tree/master/foundryup). Installing Foundry now is as simple as seen below: ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--17a800a5c0/17a186a8df48f8f7355de2bcf5a1850c/asset-https-cdn-sanity-io-images-dgybcd83--17a800a5c0.png) Congrats! Foundry's `forge` and `cast` are now available for you to use! Notably, this works across *all* platforms, requires no extra tools installed like NPM or Cargo. We believe this is a game changing UX for onboarding on a new tool. For more information on how foundryup works, check the [docs](https://github.com/gakonst/foundry/tree/master/foundryup). # Configuration File When you create a new project via `forge init`, a `foundry.toml` file is touched at your project's root which defines basic parameters of your project like where are your contracts, your output artifacts and your libraries. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--d564b0ea99/7afb898ed49927a6f2388a6ce6aa9f62/asset-https-cdn-sanity-io-images-dgybcd83--d564b0ea99.png) Foundry.toml is *very* powerful! It lets you configure every aspect of your project, as seen below, instead of you having to pass them each time as a CLI parameter. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--5ec0b6255b/da9f8add5d850f314370dbef49af43c6/asset-https-cdn-sanity-io-images-dgybcd83--5ec0b6255b.png) Perhaps the most exciting feature of `foundry.toml` is "profiles", which let you run different "bundles" of settings depending on a single CLI parameter. As an example, when testing locally you may want to have the default fuzzer runs, whereas on CI you'd want 100000 runs. You'd do this by calling `FOUNDRY_PROFILE=ci forge test` on CI, which would use the fuzzer runs from the `ci` section of the above `foundry.toml`. Read more about how to configure your `foundry.toml` in the [docs](https://github.com/gakonst/foundry/tree/master/config). # What's next? Foundry is still in the early stages of development. While our results so far are encouraging, we find there's multiple areas for improvement: 1. **Performance**: We can improve the EVM execution and Solidity compilation speed with optimizations at the VM layer and by fine tuning the compiler. 2. **Stability**: We intend to improve testing in the codebase and do less breaking changes over time, so that developers can feel like they can trust Foundry for its soundness. 3. **New features**: We have a lot of ideas in the pipeline: A new testnet node, Solidity deployments, code coverage, auto-formatting, auto-generating docs from natspec, parameterized & invariant tests, flamegraphs, more languages support and more. # What should I do? A few options: - Start a new project using Foundry! Check out the [docs](https://onbjerg.github.io/foundry-book/) and [templates](https://github.com/abigger87/femplate)! - Port some of your existing project's tests to Foundry! Other have done it already on both [Hardhat](https://github.com/gakonst/v3-periphery-foundry/) and [Brownie](https://github.com/storming0x/veYFI/tree/feat/add-foundry)! - Get involved in Foundry development! There are [Good First Issues on Github](https://github.com/gakonst/foundry/issues), and as you see from the above roadmap, there is a lot of work ahead. If none of the above make sense for you, tell us what's missing for you to make the leap, and we'll add it! # Why is Paradigm doing all this? First and foremost, we are building Foundry because we needed better tools for internal development than were available publicly. We are proud to be builders and want our tooling to be working for us, not against us. Because we use Foundry for all our projects at Paradigm, we keep a tight feedback loop around what we are building. Second, by building Foundry, we can help projects in Paradigm’s portfolio ship faster and more safely. Our research and engineering teams spend considerable time with developers in our portfolio, but their time is, unfortunately, finite. By shipping a high-quality development framework, we can scale our efforts and help more teams. Finally, we hope Foundry can be a contribution of enduring value to Ethereum and the ecosystem that has gathered around it. We encourage everyone building developer tooling to dig into the engineering innovations we have implemented in Foundry and integrate them into their services so more people can benefit from them. # Acknowledgments We are proud to have >90 contributors to Foundry. I'd like to highlight the people that have helped us the most in this: - [Brock Elmore](https://github.com/brockelmore): Built the first version of Foundry's cutting edge testing features: tracing, debugging, fuzzing, gas reports & more. - [Matt Seitz](https://github.com/mattsse): Built [ethers-solc](https://github.com/gakonst/ethers-rs/tree/master/ethers-solc) the fastest compilation pipeline in the industry, which powers Foundry. - [Oliver Nordbjerg](https://github.com/onbjerg): Drove the [migration to Revm](https://github.com/gakonst/foundry/pull/918), built the [Foundry Github Action](https://github.com/onbjerg/foundry-toolchain) and wrote the [Foundry Book](https://onbjerg.github.io/foundry-book/). - [Matt Solomon](https://github.com/mds1/) for putting together the [Convex Simulation benchmark](https://github.com/mds1/convex-shutdown-simulation). - [Dragan Rakita](https://github.com/rakita): Built [REVM](https://github.com/bluealloy/revm/), our blazing-fast EVM backend. - [Rohit Narunkar](https://github.com/roynalnaruto): Built [svm-rs](https://github.com/roynalnaruto/svm-rs) which we use to manage our solc versions. - [Nikitas Tulpin](https://github.com/nikitastupin): Built all [`solc`](https://github.com/nikitastupin/solc/) [Linux aarch64 binaries](https://github.com/nikitastupin/solc/) for us. - The people running `foundryup` [daily](https://twitter.com/nanexcool/status/1485669064324304901) and the [Foundry](https://t.me/foundry_rs)/[Foundry Support](https://t.me/foundry_support) chatrooms who keep the feedback loop tight. Finally, we’re hiring both internally at [Paradigm and across the portfolio](https://jobs.paradigm.xyz/jobs), or reach out to me at [georgios@paradigm.xyz](mailto:georgios@paradigm.xyz). ## https://www.paradigm.xyz/writing/token-compensation-a-brief-explainer-for-job-candidates # Token compensation: a brief explainer for job candidates > An explanation on token compensation. Over the past few months, there’s been a meaningful shift in the talent marketplace toward Web3 companies. Highly capable people from Web2 tech, traditional finance, and big law firms are flooding into the space, but they often don’t fully understand the compensation structures that crypto companies usually employ. Let’s say you’re one of these people, and you’ve got a job offer with a token component attached. (Congratulations!) Before you sign (or don’t), it’s critical to understand what you’re getting in order to value it appropriately against a more “standard” compensation package. A large part of the upside in joining a Web3 startup is that, in many instances, your compensation includes **tokens**, sometimes in combination with traditional equity. Let’s be clear: tokens are not inherently traditional equity by another name, but they can have some rough similarities. Like equity, tokens can appreciate in value significantly, and they often become liquid much sooner than standard equity. Token rights may also allow employees to participate and contribute to the protocols they are building directly, adding even more incentive alignment. As a potential employee, you should think about tokens as distinct from traditional equity rights (e.g., options or RSUs) but with several similarities: - As with equity incentive grants, token incentive grants are contingent consideration—they’re intended to align the incentives of grantees towards network growth, and their value is not assured. You’ve got to earn it! - The company should structure your token grant to minimize the tax impact. Specifically, employees shouldn’t have to report a material amount of income for tokens or token rights that are not yet liquid, as this would require you to pay out of pocket for your tax obligations. - Most companies will allocate tokens to employees from a pool of reserved tokens based on the relative amount of equity each holds, so token grants typically map to equity grants. # Token value: pre-launch or post-launch A critical feature of token compensation to keep in mind is whether the token grant is pre-launch or post-launch. A pre-launch token grant would typically be structured similar to how options are structured for early-stage private company stock. Pre-launch tokens are worth very little when they’re minted, and their value is largely contingent upon some as-yet-uncertain future launch event. Like stock options, there’s also no tax burden to you upon receipt of pre-launch token grants - but they will likely incur taxes upon exercise in the way that you’d be taxed on the exercise of an NSO (non-qualified stock option). A post-launch token grant is different; it has a few attributes reminiscent of a Restricted Stock Unit (RSU). The tokens exist within a liquid market (although they may be subject to vesting and lock-ups), and the recipient is taxed immediately upon receipt. If your post-launch token grant is subject to vesting, you should consider filing an [83b election](https://www.cooleygo.com/what-is-a-section-83b-election/) to minimize the tax impact of your tokens vesting. Otherwise, you will have reportable income as the tokens vest, based on the then-current fair market value. # Vesting Most token grants will begin vesting starting on your initial date of employment, analogous to traditional equity grants’ vesting schedules. This means you will stand to forfeit a portion of the token grant if you don’t remain a service provider for the entire vesting schedule. Again, you’ve got to earn it! Token grants will also typically have a separate lock-up that will prevent you from transferring any of your vested tokens for a period of time. For example, you might get token rights to a post-launch token, but you’ll be prohibited from selling them for a year after the network launch. It’s common for the lock-up to have exemptions to allow you to stake or vote your tokens prior to the expiration of the lock-up period. While related, vesting and lockup are not the same, as vesting implies a risk of forfeiture and is intended to align incentives towards long-term growth, while a lock-up is only a transfer restriction and focused more on preventing selling pressure. # Taxes Finally, as with all compensation matters, you should consult an attorney or tax advisor, especially if your token grant involves mechanics that are uncommon in traditional equity grants (e.g., trading windows, lock-up periods that are contingent upon the company reaching a particular milestone, or the option to convert equity to tokens). If you're looking for a new role in crypto/Web3, we'd love to help you find it: [talent.paradigm.xyz](https://talent.paradigm.xyz/) ## https://www.paradigm.xyz/writing/joining-paradigm-transmissions11 # Joining Paradigm > Transmissions11 joins Paradigm as a Research Engineer. I’m absolutely thrilled to announce that I’ve joined Paradigm as a Research Engineer to help [Matt Huang](https://twitter.com/matthuang), [Fred Ehrsam](https://twitter.com/FEhrsam/), and the rest of the elite team build the world’s best crypto-native investment firm. From the moment I started my journey into the nascent Ethereum ecosystem, I noticed Paradigm at the forefront. Dan’s [cutting-edge AMM research](https://www.paradigm.xyz/2021/06/uniswap-v3-the-universal-amm/), Georgios’ [best-in-class open-source tooling](https://www.paradigm.xyz/2021/12/introducing-the-foundry-ethereum-development-toolbox), samczsun’s [record-breaking whitehats](https://www.paradigm.xyz/2021/08/two-rights-might-make-a-wrong), and Dave’s [brilliant mechanism designs](https://www.paradigm.xyz/2021/07/twamm), all made Paradigm stand out as the place where top-tier researchers and engineers go to push the boundaries of what’s possible with others at the top of their field. My primary focus will be on contributing to the thriving open-source crypto ecosystem, continuing to build out the tooling & primitives that will power the future of web3, including [Solmate](https://github.com/Rari-Capital/solmate). I’ll also be working closely with [our portfolio companies](https://www.paradigm.xyz/portfolio/) to help them ship secure, fast, and elegant code. If you’re working on something exciting, reach out at [t11s@paradigm.xyz](mailto:t11s@paradigm.xyz) or nerd-snipe me on [Twitter](https://twitter.com/transmissions11)! *Thank you to all the friends, co-workers, and crypto-twitter companions who have supported me throughout this wild journey, notably: Jai Bhavnani, Joey Santoro, Jack Lipstone, David Lucid, Jet Jadeja, Sharad Shekar, Jack Longarzo and the countless other talented Tribe DAO contributors. I loved every minute working with you all and am forever grateful.* ## https://www.paradigm.xyz/writing/joining-paradigm-justin-slaughter # Joining Paradigm > Justin Slaughter joins Paradigm as Policy Director. I’m thrilled to announce that I’m joining Paradigm as Policy Director, helping Fred, Matt, Alana, and the entire Paradigm team, as well as our portfolio companies and projects, approach the pressing policy and regulatory questions surrounding crypto. I’m joining Paradigm because I believe that crypto can be a force for growth and increased competition in the economy, and that Paradigm represents the absolute best of this movement. Too many people are locked out of a financial system dominated by a small number of firms, prevented from accessing technological innovations at the core of living in a modern economy, including more affordable ways to save and transfer money. And trust in our society is sorely lacking. Crypto represents the strongest challenge to this status quo I’ve seen in nearly a decade of public service across multiple agencies. This is a moment of change for finance and technology. From the rise of cryptocurrencies themselves to the establishment of new disruptive technologies and firms, crypto has grown from a nascent community to a new ecosystem of currencies and digital commodities, a new financial system in DeFi, and a new application platform in Web3. NFTs, gaming, and the increasing entrance of institutional and consumer participation mean the importance of crypto will probably only grow this decade and beyond. New technology can be a double-edged sword for policymakers. Innovation that allows for improved hedging of risks can also make our financial system more fragile if not used wisely. At the same time, government regulations and laws can unnecessarily prevent innovation, hurting consumers and sheltering incumbent companies and interests from competition. If it takes $5 million in legal fees to launch a new financial technology, few new firms will rise up to compete with established goliaths. What is needed more than ever is dialogue between crypto innovators, regulators, and policymakers. Even the smallest companies need to understand the global rules of the road. At the same time, regulators and policymakers need to better understand how crypto works in practice directly from the people building its future. Basically, we need more communication and engagement, especially as this industry enters its second decade. If there is one thing readers take away from this announcement, I hope it is this: Paradigm is ready and available to help explain how things work in good faith. To crypto entrepreneurs: if you have questions about how the government operates, please reach out to us. To policymakers and regulators: we are here to help you understand this emergent industry. The hardest thing to be is a light in the dark, but that is what Paradigm seeks to be in 2022 and beyond. I’m excited to join this wonderful team and pick up a little candle. ## https://www.paradigm.xyz/writing/base-layer-neutrality # Base Layer Neutrality > With this analysis, we hope to ease uncertainty plaguing industry actors and provide clarity around the scope of sanctions compliance obligations. ### Sanctions and Censorship Implications for Blockchain Infrastructure [^1] ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--cf2462720c/5774bb6c7b6e5afd3ff5866c58a78c60/asset-https-cdn-sanity-io-images-dgybcd83--cf2462720c.png) ### Executive Summary On August 8, 2022, the U.S. Treasury Department’s Office of Foreign Assets Control (OFAC) added certain Ethereum addresses associated with Tornado Cash, an open-source privacy protocol on Ethereum, to the Specially Designated Nationals and Blocked Persons List (SDN List). [^2] Since the announcement, many participants in crypto’s base layer have expressed concern that they could be required to monitor or censor [^3] blocks involving SDN List addresses to comply with sanctions, jeopardizing the neutrality of the base layer and compromising its integrity and core functionality. **However, we believe that under current OFAC guidance, base layer participants are not required to monitor or censor these addresses as part of a risk-based sanctions compliance program.** Specifically, while the application of sanctions law to decentralized blockchain systems and smart contracts presents novel legal issues, we believe the Tornado Cash sanctions and blockchain address sanctions imposed to date should not require blockchain technology infrastructure providers including builders, pool operators, relays, searchers, sequencers, and validators to monitor or censor transactions that involve blocked addresses. The issue raised by the application of primarily financial and transaction-oriented economic sanctions is whether the actions of crypto’s block-producing base layer — even when involving sanctioned addresses — amount to “facilitating” a transaction, or dealing with or “contribut\[ing\] or provi\[ding\]...funds, goods, or services by, to, or for the benefit of any” sanctioned party or “interests” of a sanctioned party. [^4] We believe that the public recording of the order of data blocks at the infrastructure layer is no more “facilitating” a transaction, or dealing with, or contributing or providing services to sanctioned parties than the existing communications infrastructure that routes financial messages daily around the world, whether through internet service providers, routers, network switches, email and chat programs, DDoS filters and other network security protocols. In our opinion, the fact that crypto’s base layer infrastructure has been decentralized by distributing basic functions to independent participants makes each actor’s actions even less likely to meet this threshold. In addition, requiring crypto’s base layer to monitor or censor blocks under threat of sanctions compliance obligations would likely cause network reorganizations and forks [^5] that threaten the viability of the ecosystem. Similar risks have long been recognized for traditional communications and internet infrastructure. The result would harm national security interests by pushing the development of blockchain technology offshore and impeding efforts to track and trace crypto transactions, a result contrary to OFAC’s stated goals [^6] and President Biden’s Executive Order issued in March. [^7] Sanctions are a tool for stopping adversarial actors, not fracturing technological infrastructure or public goods. This is as true for crypto as it is for other technologies. For example, it is widely accepted that the public switched telephone network and the switching centers that allow telephones around the globe to communicate are not expected to filter communications and exclude sanctioned persons. The same argument applies to the infrastructure of the internet, such as the Transmission Control Protocol/Internet Protocol (TCP/IP) and internet service providers (ISPs). Crypto’s base layer is no different. It is our hope that the analysis in this article will ease uncertainty plaguing industry actors and provide clarity around the scope of sanctions compliance obligations. [^8] We begin with a description of crypto’s base layer and its participants (section 1), followed by a discussion of OFAC’s legal authorities (section 2). We then discuss the reasons we believe OFAC compliance obligations to date do not require base layer participants to monitor or censor the public recording of the order of data blocks (section 3), the unintended consequences of applying sanctions compliance obligations to base layer participants (section 4), and the historical treatment by U.S. regulators of other technological infrastructure (section 5). ### 1. The “base layer” of crypto A blockchain can be viewed as a timestamping service that allows for the ordering of data in a canonical way. A fundamental feature is that anyone can submit a chunk of data to be timestamped and recorded to the blockchain. This can support a ledger for a digital asset like Bitcoin, as well as other applications including trust-free agreements that eliminate counterparty risk and new mechanisms for social coordination. Like the telephone network, crypto’s base layer is at its core a communications protocol and technology infrastructure that serves as a public good. Its key function — publicly recording the order of data blocks — is similar to the role we expect the base layer of internet infrastructure to play, to freely and accurately disseminate information to the public. To maintain its utility, crypto’s base layer must also maintain its neutrality. While blockchain’s key function is simple, the infrastructure to provide it in a distributed, scalable, and secure way has grown increasingly complex and is constantly changing as the ecosystem evolves and new technology is developed. Many blockchains have distributed the process amongst various base layer participants with specialized roles, including builders, [^9] pool operators, [^10] relays, [^11] searchers, [^12] sequencers, [^13] and validators [^14]. Each base layer participant performs a specific role in the ordering and attestation of new blocks. But as we explain further below, we do not believe the actions of these base layer participants should be interpreted as dealing with, or facilitating transactions with, sanctioned persons. As compared to traditional infrastructure like internet protocols, blockchain further decentralizes core computational functions by distributing them to actors that play specific roles. It is our opinion that decentralization makes the actions of each individual base layer actor even less likely to require censoring than traditional infrastructure. ### 2. The U.S. government has legitimate national security interests in enforcing sanctions in the digital asset space Sanctions can be a critical tool for protecting the United States. In addressing threats of adversarial actors such as the Democratic People’s Republic of Korea (DPRK), OFAC has an important mandate to enforce “economic and trade sanctions based on U.S. foreign policy and national security goals.” [^15] At the same time, OFAC’s powers are not limitless and the standard for implementation of compliance programs is that they be a reasonable “*risk-based approach*,” not that all economic activity must be shut down if there is any chance for some sanctions violation. [^16] Based on authority granted to the President under the International Emergency Economic Powers Act (IEEPA) [^17] and the National Emergencies Act (NEA), [^18] President Barack Obama in 2015 issued Executive Order 13694 (E.O. 13694). [^19] E.O. 13694 empowered the Treasury Department to address malicious cyber-enabled activities harming the United States or its allies. [^20] Pursuant to this authority, OFAC implemented the Cyber-Related Sanctions Program under which it can identify certain “persons” or “entities” on the SDN List [^21] if they are deemed to be “responsible for or complicit in” or to have “materially assisted” or “provided financial, material, or technological support for” foreign cyber-enabled activities that pose a significant threat to the national security or economy of the United States. [^22] Once a party is identified on the SDN List, “U.S. persons” [^23] are prohibited from “engaging in transactions” with it, and all of the property and interests in property of the sanctioned party that are within the “possession or control” of a U.S. person or subject to U.S. jurisdiction may not be “transferred, paid, exported, withdrawn, or otherwise dealt in” by U.S. persons. [^24] Prohibitions also forbid facilitating transactions, including the provision of “services” to any such party. [^25] OFAC has a history of enforcing sanctions in the digital asset space. OFAC first sanctioned blockchain addresses in November 2018 when OFAC included several Bitcoin addresses controlled by Iranian nationals on the SDN List. [^26] OFAC also recently sanctioned Blender.io, a centralized and custodial cryptocurrency mixing service run and controlled by several identifiable actors. [^27] However, OFAC broke new ground in August by adding to the SDN List the Ethereum address where the Tornado Cash bytecode or smart contract (a specific, widely used copy of the Tornado Cash protocol) is stored on Ethereum. [^28] Previously, the blockchain addresses added to the SDN List were wallet addresses owned or controlled by sanctioned persons or entities. [^29] Blender.io is also, as noted above, operated under centralized control. Since E.O. 13694 permits the Treasury Department to take action only against the property and interests in property of “persons” or “entities,” [^30] OFAC’s actions against a smart contract — at its core, just lines of bytecode — have been questioned by legal analysts and have been the recent subject of a lawsuit. [^31] ### 3. Sanctions law should not require participants in crypto’s base layer to censor the public recording of the order of data blocks In this section we analyze two potential sources of direct sanctions liability: (a) an enforcement action against persons subject to U.S. jurisdiction for transacting or facilitating a transaction, or dealing with a sanctioned party on the SDN List; and (b) a potential addition to the SDN List itself. We conclude that based on current OFAC guidance, a risk-based sanctions compliance program does not require crypto’s base layer to monitor or censor data blocks that may include sanctioned addresses. [^32] ### 3a. Crypto’s base layer should not be the subject of an enforcement action for publicly recording the order of data blocks involving sanctioned addresses When OFAC adds a party to the SDN List, any property or interest in property of such sanctioned party that is in the United States or comes within the “possession” or “control” of a “U.S. person” must be “blocked” and may not be “transferred, paid, exported, withdrawn, or otherwise dealt in.” [^33] IEEPA makes it unlawful to violate these prohibitions and also to “cause” another person to do so. [^34] Against this backdrop, OFAC has taken the position that “facilitating” a violation of sanctions is prohibited. [^35] This includes “the making of any contribution or provision of funds, goods, or services by, to, or for the benefit of any person whose property and interests in property are blocked.” [^36] OFAC reads these prohibitions broadly to include instances where a U.S. person “assists” or “supports” a non-U.S. person in transactions directly or indirectly involving sanctioned countries or parties. [^37] Despite OFAC’s broad authority, we believe participants in crypto’s base layer are not required to monitor or censor data blocks that may include sanctioned addresses as part of their risk-based compliance programs. At no point is any individual base layer participant in “possession or control” of property or an interest in property of a sanctioned person. [^38] These terms, which are not defined in OFAC’s implementing regulations or enforcement actions, and therefore are to be interpreted according to their plain meaning, require “holding property in one’s power” or power to “govern” or “manage” the property. [^39]he direct or indirect power to govern the management and policies of a person or entity, whether through ownership of voting securities, by contract, or otherwise; the power or authority to manage, direct, or oversee .” CONTROL, Black’s Law Dictionary (11th ed. 2019). In the context of traditional banking transactions, OFAC has explained that banks, for instance, are required to block an “opening deposit” from an SDN or a request from a customer to send money to a relative on the SDN list. U.S. Department of Treasury, “Frequently Asked Questions No. 42,” (Aug. 11, 2020), available here. In other words, “\[y\]ou might think of the analogy of a bouncing ball,” and “\[o\]nce the ball starts moving, you must stop it if it comes into your possession.” Id\] However, base layer participants lack this influence or power over the digital assets. Crypto’s base layer participants are also not able to “block” the property or interests in property of a sanctioned party. That certain participants could be forced to censor blocks does not mean they have the ability to restrict the underlying property. Censorship as applied to crypto’s base layer amounts to an inability to report a transaction; not an ability to “block” it. Whether a transaction is confirmed will depend on the broader, global network consensus regardless of the actions of any individual participant. For example, a transaction that is screened by one base layer participant could be picked up by a non-censoring participant anywhere in the world, or cause a network to fork as further discussed below. Nor is any individual base layer participant transferring blocked property by playing their role in the public recording of the order of data blocks, even if involving a sanctioned address. As OFAC’s implementing regulations clarify, the prohibition on the “*transfer*” [^40] of blocked property is intended to capture acts that transfer or alter legal rights to property and has not historically included the operations of technological infrastructure (such as the telephone network). [^41] While certain participants in crypto’s base layer like miners receive fees from users for their actions, these fees are akin to internet network fees or telephone service fees. We also believe that interpreting the actions of crypto’s base layer participants as dealing with blocked property, facilitating its transfer, or providing services to sanctioned parties is at odds with prior OFAC regulations and enforcement history. OFAC regulations have stated that “facilitating” does not include activities that are of a purely clerical or reporting nature and do not further trade or financial transactions. [^42] The core functionality of crypto’s base layer — the public and decentralized recording of the order of data blocks — should be treated the same. Furthermore, to our knowledge OFAC has generally brought enforcement actions that include a facilitation claim when the subject was also responsible for additional culpable actions like using a financial institution as an agent. [^43] For these reasons, we think that base layer participants are not required to monitor or censor data blocks involving sanctioned addresses as part of a risk-based sanctions compliance policy, and should not be the subject of a sanctions enforcement action for failing to do so. OFAC recommends in guidance that compliance programs be designed using a “risk-based approach.” [^16] OFAC has noted “there is no single compliance program or solution suitable to every circumstance or business… \[and that\] \[a\]n adequate compliance solution for members of the virtual currency industry will depend on a variety of factors, including the type of business involved, its size and sophistication, products and services offered, customers and counterparties, and geographic locations served.” [^44] Given the operational role that base layer participants play, which in most instances do not involve engagement with customers or counterparties, we believe that an appropriate risk-based compliance program does not require monitoring or censoring of data blocks involving sanctioned addresses. [^45] Although Financial Crimes Enforcement Network (FinCEN) [^46] guidance is not binding on OFAC, this view is supported by FinCEN’s determination that Bitcoin miners are not money services businesses “because these activities involve neither ‘acceptance’ nor ‘transmission’ of the convertible virtual currency and are not the transmission of funds,” [^47] and FinCEN’s finding that “a person is not a money transmitter if that person only: a) provides the delivery, communication, or network access services used by a money transmitter to support money transmission services.” [^48] Indeed, FinCEN has appropriately recognized that a miner’s function is to “verify the authenticity of a block of transactions” rather than execute transactions. [^49] ### 3b. Crypto’s base layer activities do not meet the standard to be added to the SDN List Crypto’s base layer operators should not be added to the SDN List for failing to censor data blocks that include a sanctioned address. OFAC adding base layer participants to the SDN List would require a finding that they were “persons” or “entities” that “materially assisted” or “provided financial, material, or technological support” to any persons engaged in sanctioned cyber-enabled activities. [^50] Such a finding is unlikely because, first, many base layer activities are not conducted by a “person” or an “entity” but rather by self-executing software code. In those instances, there is no basis to designate them because there is no “person” or “entity” taking any action. As recent examples demonstrate, [^51] when OFAC has historically designated parties under the “material support” provisions of various executive orders, it has designated malicious actors who were taking extreme actions such as providing sensitive technology to designated parties or covertly funneling money on their behalf. [^52] That is distinct from the function of crypto’s base layer, which is to provide neutral, open-source software to validate and post information to a blockchain. Accordingly, base layer activities are different in kind from the actions OFAC has previously found sufficient to constitute material support. ### 3c. Crypto’s base layer operators are dealing in information, which is carved out from OFAC’s jurisdiction under IEEPA There are also statutory limitations on the application of IEEPA to the importation or exportation of information that suggests the activities of crypto’s base layer are not intended to be covered by the sanctions regime. E.O. 13694 and the bulk of modern sanctions are promulgated under IEEPA, a 1970s-era federal law granting powers to the president in the event of a national emergency. IEEPA is limited in several key ways, however, including with respect to the export of “information.” In 1988 and 1994, Congress passed a series of restraints on presidential powers known as the “Berman Amendments,” which collectively provided that OFAC cannot regulate “the importation from any country, or the exportation to any country…\[of\] any information or informational materials.” [^53] This limitation of powers exists “regardless of format or medium of transmission.” [^49] While OFAC has attempted to narrow the exemptions codified by Congress, [^54] recent decisions by U.S. courts suggest that OFAC’s narrow reading of the Berman Amendments is not supported by the statute’s text. [^55] Thus, along with the points above, it can be further argued that the work of crypto’s base layer is merely dealing in information — even if that information has value — and thus is exempted from U.S. sanctions promulgated under IEEPA. ### 4. Results of imposing sanctions compliance obligations at the base layer In this section, we discuss the damaging and counterproductive consequences of forcing base layer participants to monitor and screen data blocks under the threat of sanctions compliance obligations. The degree of network censorship resulting from base layer participants screening data blocks involving sanctioned addresses will depend on important technical nuances outside of the scope of this paper. [^56] Nonetheless, abandoning the neutrality of core operational features of blockchains risks breaking blockchain’s crucial consensus mechanism. For example, if certain censoring validators take the position of refusing to attest to prior blocks that include transactions with sanctioned addresses, the network could fork. Censoring validators would disagree with non-censoring validators by denying the existence of transactions with sanctioned addresses, and the network would split into two conflicting realities. Alternatively, if users disagree with the decision of a supermajority of validators to censor transactions, users could “fork them out” by choosing not to utilize these validators. No matter its cause, a network fork would be highly disruptive and undermine the fundamental proposition of blockchain technology, which is to provide a universal record of the order of data blocks. This sanctions-driven network splintering would ultimately harm U.S. national security interests. The fear of sanctions enforcement could result in base layer participants such as validators and miners going offshore. This would limit U.S. influence over the development of the technology and have negative effects on the U.S. economy and American hegemony. These consequences run counter to goals of President Biden who stated in his March Executive Order that the “United States has an interest in ensuring that it remains at the forefront of responsible development and design of digital assets and the technology that underpins new forms of payments and capital flows in the international financial system.” [^7] Further, such a reaction would increase the difficulty of monitoring base layer participants, including those that serve as on- and off-ramps. As more activity moves offshore, regulators will have decreasing visibility into exchanges and validators because they would be subject to fewer reporting obligations, making it harder for U.S. regulators to track and trace illicit funds. These services would be driven to other jurisdictions or captured by parties that may be antagonistic to national security interests of the U.S. and its allies. Indeed, the precedent set here by the United States will likely be followed by other countries, including those whose values diverge from our own. If the United States applies censorship to the base layer, other countries may choose to do the same. This could result in foreign laws driving censorship of crypto in the United States or, alternatively, every country having its own “compliant” version of crypto that is operated by validators within that country and that is completely isolated from other countries’ versions. The present internet avoided this fate, with limited exceptions, to the benefit of us all. ### 5. The importance of maintaining the neutrality of technological infrastructure is widely recognized An obvious analogy for crypto’s base layer is the infrastructure underlying the internet. ISPs collect and send packets of information between users leveraging protocols such as TCP/IP. [^57] Just as base layer neutrality is necessary for crypto to function efficiently, [^58] allowing for the uncensored flow of information at the bottom layer of communication networks is critical. From an architectural standpoint, networks benefit from pushing discretion to the edges and keeping the core free from censorship so that information can flow freely. Therefore, maintaining network integrity is another reason to resist fracturing global communications through jurisdictional policy decisions, even if certain issues like sanctioning the DPRK have strong consensus. In the way that internet messaging functions today policy decisions have already been made to allow for balancing network integrity and national interests. In contrast, internet censorship through actions like “packet filtering” has been associated with oppressive and authoritarian regimes. [^59] For blockchain infrastructure, there are other places more appropriate to adjudicate transactions. U.S. regulators should be consistent in their approach and recognize that maintaining the neutrality of crypto’s base layer is of paramount importance. ### 6. Conclusion OFAC’s identification of blockchain addresses to the SDN List should not require any base layer participants to censor transactions that involve sanctioned addresses. OFAC regulations require the implementation of risk-based compliance programs tailored to the specific activities of the base layer participants in question. Given that the role of crypto’s base layer is fundamentally the public recording of the order of data blocks, participants should not be required to screen blocks that include sanctioned addresses. Applying sanctions compliance obligations at the base layer would also have counterproductive national security implications and push development of important technology offshore, thereby making it harder to track and trace crypto transactions core to protecting national interests. Crypto holds great promise for America and the world. Over time, we are confident that industry and regulators can, by working together, fulfill American ideals of free speech, privacy, and financial freedom. ## Acknowledgments Special thanks to Angela Angelovska-Wilson, Katie Biber, Henley Hopkinson, Linda Jeng, Emily Meyers, Michael Mosier, Georgia Quinn, Rebecca Rettig, Gabriel Shapiro, Justin Slaughter, and Sheila Warren for their review and feedback. ## Disclosure This content is provided for informational purposes only, and should not be relied upon as legal, business, investment, or tax advice. Circumstances vary, and one should consult their own advisers and attorneys for advice. Certain information contained herein has been obtained from third-party sources. While taken from sources believed to be reliable, the authors have not independently verified such information and make no representations about the current or enduring accuracy of the information or its appropriateness for a given situation. References to any securities or digital assets are for illustrative purposes only, and do not constitute an investment recommendation or offer to provide investment advisory services. [^1]: A position paper drafted by the Crypto Council for Innovation (CCI) and Paradigm. This paper should not be relied on as legal advice [^2]: This action prohibited any U.S. person without a license from sending to, or receiving crypto from, the listed addresses, including the addresses where the Tornado Cash bytecode or smart contract (a specific, widely-used program that implements the Tornado Cash protocol) is stored on Ethereum [^3]: “Censoring” by a base layer participant would entail either excluding any transactions that involve sanctioned addresses in blocks they propose, or refusing to attest to any blocks that include such transactions [^4]: To be clear, our analysis solely addresses the infrastructure layer composed of the blockchain network that underlies on-chain transactions [^5]: A “fork” occurs when the community of a particular blockchain’s protocol makes changes to the basic set of rules, such that the chain splits. This creates a new version of the blockchain that shares history with the original, but additional blocks are no longer backward-compatible with earlier rules [^6]: OFAC, “Sanctions Programs and Information,” available here (noting OFAC administers sanctions “based on US foreign policy and national security goals”) [^7]: Executive Order 14067, 87 Fed. Reg. 40881 (2022), available here [^8]: This paper is limited to analysis of U.S. sanctions laws. It does not address the applicability of other statutes, such as 18 U.S.C. §§ 1956, 1957, to base layer activities [^9]: Builders construct full blocks and send them (or their headers) to validators [^10]: Mining pool operators collect transactions into blocks and distribute the block headers to miners. Miners on some chains, including Bitcoin, typically do not choose what transactions they mine, and only see the block headers, not the individual transactions. See, e.g., Gert-Jaap Glasbergen, “Who is Monitoring Mining Pools?” (Aug. 21, 2020), available here [^11]: Relays collect bundles from searchers or builders and send them to builders or validators [^12]: Searchers collect transactions and bundle them together to submit to builders or relays [^13]: Sequencers act like builders for “rollups,” which are blockchains that are built on top of another blockchain [^14]: Validators include miners in proof-of-work blockchains and stakers in proof-of-stake blockchains [^15]: OFAC, “Sanctions Programs and Information,” (last visited Sept. 7, 2022), available here [^16]: See, e.g., Department of the Treasury, “A Framework for OFAC Compliance Commitments,” available here, and OFAC, “Sanctions Compliance Guidance for the Virtual Currency Industry,” (Oct. 2021), available here [^17]: 50 U.S.C. § 1701 et seq [^18]: 50 U.S.C. § 1601 et seq [^19]: Executive Order 13694, 80 Fed. Reg. 18077 (2015), available here [^20]: See Executive Order 13757, 82 Fed. Reg. 1 (2017), amending E.O. 13694, available here [^21]: E.O. 13694 specifically defines these terms: “the term ‘person’ means an individual or entity…the term ‘entity’ means a partnership, association, trust, joint venture, corporation, group, subgroup, or other organization.” See § 6(a)-(b) [^22]: Id., § 1(a)(ii)(A) [^23]: A U.S. person is generally defined as “any United States citizen, permanent resident alien, entity organized under the laws of the United States or any jurisdiction within the United States (including foreign branches), or any person in the United States.” See, e.g., 31 C.F.R. § 560.314 [^24]: E.O. 13694 § 1(a) [^25]: Executive Order 13694, 80 Fed. Reg. 18077 (2015), available here, as incorporated in Executive Order 13757, 82 Fed. Reg. 1 (2017) amending the E.O., available here. See also, Stefan Reisinger, The Facilitation Prohibition (Dec. 2013), available here [^26]: U.S. Department of Treasury, “Treasury Designates Iran-Based Financial Facilitators of Malicious Cyber Activity and for the First Time Identifies Associated Digital Currency Addresses,” (Nov. 28, 2018), available here [^27]: U.S. Department of the Treasury, “U.S. Treasury Issues First-Ever Sanctions on a Virtual Currency Mixer, Targets DPRK Cyber Threats,” (May 6, 2022), available here [^28]: U.S. Department of the Treasury, “Cyber-related Designation: Specially Designated Nationals List Update,” (Aug. 8, 2022), available here (listing website, ETH addresses, including smart contract addresses, USDC addresses and “Organization Established Date 2019,” although no information was provided as to “what” the organization is) [^29]: See, e.g., U.S. Department of Treasury, “Treasury Designates Iran-Based Financial Facilitators of Malicious Cyber Activity and for the First Time Identifies Associated Digital Currency Addresses,” (Nov. 28, 2018), available here; U.S. Department of Treasury, “Cyber-related Designations and Designations Updates,” (Nov. 8, 2021), available here (designating individuals and associated virtual currency addresses) [^30]: E.O. 13694, as amended [^31]: Coin Center, “Analysis: What is and what is not a sanctionable entity in the Tornado Cash case,” (Aug. 15, 2022), available here. On September 8, a group of plaintiffs filed a federal complaint against OFAC in the Western District of Texas, challenging the sanctions of the Tornado Cash smart contracts and asking the Court to remove them from the sanctions list. In a blog post announcing Coinbase’s funding of the litigation, Coinbase CEO Brian Armstrong wrote, “Sanctioning open source software is like permanently shutting down a highway because robbers used it to flee a crime scene.” Coinbase, “Defending Privacy in Crypto,” (Sept. 8, 2022), available here [^32]: This paper is limited to U.S. sanctions laws. It does not address the applicability of other statutes, such as 18 U.S.C. §§ 1956, 1957, to base layer activities [^33]: E.O., § 1(a) [^34]: 50 U.S.C. § 1705(a) [^35]: See, e.g., U.S. Department of the Treasury, “A Framework for Compliance Commitments at 9-10,” (May 2, 2019), available here (identifying a common root cause of sanctions violations as “Facilitating Transactions by Non-U.S. Persons”). See also, 31 C.F.R. § 578, effective as of Sept. 6, 2022. U.S. Department of the Treasury, “Amendment to the Cyber-Related Sanctions Regulations and Associated Administrative List Updates,” (Sep. 2, 2022), available here [^36]: Executive Order 13694, 80 Fed. Reg. 18077 (2015), available here. See also Executive Order 13757, 82 Fed. Reg. 1 (2017) amending E.O. 13694, available here [^37]: See, e.g., Stefan Reisinger, “The Facilitation Prohibition,” (Dec. 2013), available here [^38]: E.O. 13694, § 1(a) [^39]: “Possession” means “1. The fact of having or holding property in one’s power; the exercise of dominion over property. 2. The right under which one may exercise control over something to the exclusion of all others; the continuing exercise of a claim to the exclusive use of a material object.” POSSESSION, Black’s Law Dictionary (11th ed. 2019); see also Merriam-Webster Dictionary (“control of the ball or puck”), available here. “Control” means “[t [^40]: “The term ‘transfer’ means any actual or purported act or transaction, whether or not evidenced by writing, and whether or not done or performed within the United States, the purpose, intent, or effect of which is to create, surrender, release, convey, transfer, or alter, directly or indirectly, any right, remedy, power, privilege, or interest with respect to any property.” 31 C.F.R. § 578.316 [^41]: While OFAC has brought enforcement actions against companies that provided technology services to sanctioned parties, the penalized actions amounted to direct assistance to sanctioned parties as opposed to enabling the fundamental operation of a network. See, e.g., OFAC, “OFAC Settles with SAP SE for Its Potential Civil Liability for Apparent Violations of the Iranian Transactions and Sanctions Regulations,” (April 29, 2021), available here (noting that “violations arose from SAP’s exportation of software and related services from the United States to companies in third countries with knowledge or reason to know the software or services were intended specifically for Iran”) and OFAC, “Enforcement Action against Société Internationale de Télécommunications Aéronautiques SCRL,” (Feb. 26, 2020), available here (noting that SITA knowingly provided commercial services and software that benefitted specially designated global terrorists) [^42]: 31 C.F.R. § 538.407(a). We note that the Sudan sanctions are no longer in effect [^43]: See, e.g., OFAC, Enforcement Release - Sojitz (Hong Kong) Limited (Jan. 11, 2022) (finding Sojitz HK caused “multiple U.S. financial institutions to (i) engage in unauthorized financial transactions related to goods of Iranian origin in violation of § 560.206 of the ITSR and (ii) facilitate Sojitz HK’s Iran-related financial transactions that would have been prohibited if performed by a U.S. person in violation of § 560.208 of the ITSR”), available here; and OFAC, Enforcement Release - PT Bukit Muria Jaya (Jan. 14, 2021) (finding PT BMJ “caused U.S. banks to: (i) deal in the property or interests in property of a Specially Designated National or Blocked Person; (ii) export financial services to the DPRK; or (iii) otherwise facilitate export transactions that would have been prohibited if engaged in by U.S. persons in apparent violation of §§ 510.201, 510.206, and 510.211 of the NKSR”), available here [^44]: OFAC, “Sanctions Compliance Guidance for the Virtual Currency Industry,” (Oct. 2021), available here [^45]: We note that OFAC has stated in guidance that “All companies in the virtual currency industry, including technology companies, exchangers, administrators, miners, and wallet providers, as well as more traditional financial institutions that may have exposure to virtual currencies or their service providers, are encouraged to develop, implement, and routinely update, a tailored, risk based sanctions compliance program. Such compliance programs generally should include sanctions list and geographic screening and other appropriate measures as determined by the company’s unique risk profile.” OFAC, “Sanctions Compliance Guidance for the Virtual Currency Industry,” (Oct. 2021), available here. This guidance, which by its own admission does not have the force of law, overtly states that it is a summary of general guidelines to companies. It does not demand firms follow specific protocols, but merely states that firms are “encouraged” to build compliance programs, ones that “generally” should include “appropriate measures.” It would be a mistake to read this broad but brief language as requiring a specific action such as the destruction of the base layer [^46]: FinCEN, along with OFAC, is a Treasury bureau that protects the financial system from illicit use of funds and money laundering to promote national security. See FinCEN, “What We Do,” (last visited, Sept. 7, 2022), available here [^47]: FinCEN, “Application of FinCEN’s Regulations to Virtual Currency Mining Operations,” (Jan. 30, 2014), available here [^48]: FinCEN, “Application of FinCEN’s Regulations to Certain Business Models Involving Convertible Virtual Currencies,” (May 9, 2019), available her [^49]: Id [^50]: E.O. 13694, § 1(a)(ii)(B) [^51]: In October 2017, for instance, three entities were designated pursuant to E.O. 13224 for providing material support in the form of military equipment — including radar systems, missile design components, and navigation-related gyrocompasses — to designated Iranian entities. U.S. Department of the Treasury, “Treasury Designates the IRGC under Terrorism Authority and Targets IRGC and Military Supporters under Counter-Proliferation Authority,” (Oct. 13, 2017), available here. Similarly, in May 2018, OFAC designated the Chairman and Chief Executive of a bank for providing material support to the IRGC by using the bank to enable the IRGC to move funds from Tehran to Hizballah. Treasury Department, “Treasury Targets Iran’s Central Bank Governor and an Iraqi Bank Moving Millions of Dollars for IRGC-Qods Force,” (May 15, 2018), available here. And in June 2018, OFAC designated three entities under E.O. 13964 — at issue here — for (1) working on a project to increase the Russian FSB’s offensive cyber capabilities, (2) being a research institute with “extensive ties” to the FSB, and (3) procuring underwater equipment and diving systems for Russian agencies. U.S. Department of Treasury, “Treasury Sanctions Russian Federal Security Service Enablers,” (Jun. 11, 2018), available here [^52]: As of the release of new cybersecurity regulations last week, “the term ‘financial, material, or technological support,’ as used in this part, means any property, tangible or intangible, including currency, financial instruments, securities, or any other transmission of value; weapons or related material; chemical or biological agents; explosives; false documentation or identification; communications equipment; computers; electronic or other devices or equipment; technologies; lodging; safe houses; facilities; vehicles or other means of transportation; or goods. ‘Technologies’ as used in this section means specific information necessary for the development, production, or use of a product, including related technical data such as blueprints, plans, diagrams, models, formulae, tables, engineering designs and specifications, manuals, or other recorded instructions.” 31 C.F.R. § 578.306. See “Amendment to the Cyber-Related Sanctions,” (Sep. 2, 2022), available here [^53]: 50 U.S.C. § 1702(b)(3) [^54]: 31 C.F.R. § 510.213(c)(2) [^55]: TikTok Inc. v. Trump, 507 F. Supp. 3d 92, 108–09 (D.D.C. 2020), appeal dismissed sub nom. TikTok Inc. v. Biden, No. 20-5381, 2021 WL 3082803 (D.C. Cir. July 14, 2021) [^56]: See, e.g., Bitmex Research, “OFAC Sanctions & Ethereum PoS - Some Technical Nuances,” (Aug. 19. 2022), available here [^57]: Rus Shuler, “How Does the Internet Work?” (2002), available here [^58]: Wired, “The WIRED Guide to Net Neutrality,” (May 5, 2020), available here [^59]: Berkman Klein Center, “The Shifting Landscape of Global Internet Censorship,” (2017), available here (analyzing global internet content restrictions, especially state-sponsored filtering through technical means) ## https://www.paradigm.xyz/writing/constant-rate-issuance-sales-protocol # Constant Rate Issuance Sales Protocol > This paper introduces the Constant Rate Issuance Sales Protocol, or CRISP, a pricing mechanism that aims to sell NFTs at a targeted rate over time. ## Introduction This paper introduces the *Constant Rate Issuance Sales Protocol*, or CRISP, a pricing mechanism that aims to sell NFTs at a targeted rate over time. If we want to sell 100 NFTs per day but are on pace to sell only 10, CRISP will slowly decay the "buy it now" price. If we want to sell 100 NFTs per day but are on pace to sell 200, CRISP will rapidly increase the “buy it now” price with every new sell. We provide a Python notebook modeling the mechanism's behavior, as well as a reference Solidity implementation. ## Motivation Imagine you have an unlimited set of NFTs that you want to sell at a constant rate — say, 100 per day. You might design an auction system to achieve this goal. You could sell all 100 in a single auction, or perhaps hold 100 different auctions of one NFT each. However, the user experience of an auction can be quite unwieldy — auctions cost gas, and we want users to be able to buy one of these NFTs at any time, without having to wait for an auction to terminate. ## Mechanism #### Overview CRISP tracks the rate at which NFTs are being sold, and compares it to a target rate. When NFTs are being sold too quickly relative to the target rate, we want to be able to adjust prices quickly. The higher the sales rate compared to the target rate, the faster we want to raise prices. On the other hand, when NFTs are being sold too slowly relative to the target rate, we do not want to be too hasty to lower prices. After all, there had been sufficient demand to support the current price at some point in the past. As a result, we decay prices slowly over time. #### Sales Rate We measure the sales rate using an Exponential Moving Sum, or EMS. The EMS is an adaptation of the [Exponential Moving Average](https://en.wikipedia.org/wiki/Moving_average) that is commonly used in quantitative trading to measure the accumulation of some quantity over a recency-weighted window of time. It is cheap to calculate and requires little storage. The CRISP EMS in particular tracks the number of NFTs sold over a recent time period defined by `sale averaging halflife`. A `sale averaging halflife` of 100 would mean that a sale 100 blocks ago would add only $\\frac{1}{2}$ to the current EMS. The EMS at block $b$ is defined recursively as: $$ EMS_b = 2^{\frac{-1}{sale\_averaging\_halflife}}EMS_{b-1} + S_b $$ where $S_b$ is a variable indicating the number of sales that have occurred in block $b$. Given two blocks, $b_1$ and $b_2$, and assuming no sales occurred between the blocks, we have $$ EMS_{b2} = 2^{\frac{-(b_2-b_1)}{sale\_averaging_halflife}}EMS_{b1} + S{b_2} $$ We can translate a target sales rate to a target EMS using the above formula. Assuming we are targeting a rate of 1 sale every $n$ blocks, the target EMS should be $$ EMS_{target} = \frac{1}{1-2^{\frac{-n}{sale\_averaging\_halflife}}} $$ (see Appendix for proof). #### Raising Prices If the current EMS is above the target, the sales rate is by definition too high. As a result, we want to charge more for the next NFT, because that will (presumably) reduce demand, or, at the very least, increase revenue. The faster we are selling NFTs relative to the desired rate, the more quickly we should update prices. So, we define a variable $$ mismatch\_ratio = \frac{EMS_{current}}{EMS_{target}} $$ and then set $$ price = price \cdot (1 + mismatch\_ratio \cdot price\_increase\_speed) $$ where `price increase speed` controls how quickly price reacts to differences between the target and observed rates. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--7e00b44348/fce3872ebe4bd4ee54ce4cffbcfbf077/asset-https-cdn-sanity-io-images-dgybcd83--7e00b44348.png) In this example, we model CRISP over a period of 200 blocks. We are targeting one sale per 100 blocks, and using a sale halflife of 700 blocks. In the given period, we see purchases happening every 50 blocks, which is above our target. This pushes the EMS upward on every purchase, and price reacts accordingly. #### Lowering prices When the current EMS is below target, the sales rate is too low. As a result, we want to charge less for the next NFT, making it a more attractive purchase. However, we want to decay prices slowly over time, because we managed to hit the target rate at previous prices and we don’t want to drop prices more than we have to. Assuming the last sale happened on block $b_1$ at $price_{b_1}$, the price on block $b_2$ is then given by: $$ price_{b2} = price_{b1} \cdot e^{\frac{-(b_2 - b_1)}{price\_decay\_halflife}} $$ where `price decay halflife` controls the rate of decay. Because we only want to decay price when the sales rate is below the target, if the current sale is the first since the sales rate dropped below the target price, we calculate decay starting from the block when the rate dropped below the target, not from time since the last sale. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--a77052585b/66a04d4c171dcb4b2a283477cceedeeb/asset-https-cdn-sanity-io-images-dgybcd83--a77052585b.png) In this example, we model CRISP over a period of 300 blocks. Again, we target one sale every 100 blocks. In the given period, only one purchase happens, on the 200th block. We see that the current EMS slowly falls over the first 200 blocks, but price does not start falling until around the 100th block, when the current EMS falls below the target. Since after the purchase, the EMS is still below target, price does not increase. #### Full Example ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--be63dea99d/3f1a3fbb6fd4a45377ed93defca31325/asset-https-cdn-sanity-io-images-dgybcd83--be63dea99d.png) An example of CRISP over a longer time period. At first, purchase rate is too high, so price increases with every purchase. After a period with no purchases, price and purchase rate roughly stabilize. ## Code A Python notebook and Solidity implementation are available at [https://github.com/FrankieIsLost/CRISP](https://github.com/FrankieIsLost/CRISP). ## Conclusion We hope CRISP will unlock a host of cool and interesting NFT dynamics. If you spot any problems or think of any improvements, we'd love to hear from you! You can reach us at [@](https://twitter.com/_Dave__White_)[*Dave__White*](https://twitter.com/_Dave__White_), [@FrankieIsLost](https://twitter.com/FrankieIsLost), and [@justinroiland](https://twitter.com/justinroiland) on Twitter. ## Appendix #### Translating Target Sales Rate to Target EMS: Proof Assume we are targeting a sales rate of 1 sale every nth block. Then, using formula (1), the EMS on the block of the $k^{th}$ sale is: $$ EMS_k = 2^{\frac{-n}{sale\_averaging\_halflife}}EMS_{k-1} +1 $$ $$ = 2^{\frac{-2n}{sale\_averaging\_halflife}}EMS_{k-2} + 2^{\frac{-n}{sale\_averaging\_halflife}} +1 $$ $$ \vdots $$ $$ = \sum_{i=1}^{k}(2^{\frac{-n}{sale\_averaging\_halflife}})^i $$ This is a geometric series which converges to $$ \frac{1}{1-2^\frac{-n}{sale\_averaging\_halflife}} $$ Hence, we can translate between target sales rates and target EMS. *Acknowledgments: *[*Dan Robinson*](https://twitter.com/danrobinson)*, *[*Will Robinson*](https://twitter.com/DangerWillRobin)*, *[*Sam Sends*](https://twitter.com/sam_sends)*, *[*Jim Prosser*](https://twitter.com/jimprosser)*, *[*0xmons*](https://twitter.com/0xmons)*, *[*t11s*](https://twitter.com/transmissions11)*, *[*nnnnicholas*](https://twitter.com/nnnnicholas)*, *[*Grug*](https://twitter.com/CapitalGrug)*, *[*mewny*](https://twitter.com/mewn21) ## https://www.paradigm.xyz/writing/joining-paradigm-frankie # Joining Paradigm > Frankie joins Paradigm as a Research Engineer. I'm excited to announce that I've joined Paradigm as a Research Engineer, to help [Fred Ehrsam](https://twitter.com/FEhrsam), [Matt Huang](https://twitter.com/matthuang), and the rest of the team as they push the boundaries in building a crypto-native investment firm. I've had the pleasure of collaborating with the research team over the past few months, as I speed-ran the Paradigm blog, hacking together prototypes of [RICKS](https://github.com/FrankieIsLost/RICKS), [Mortys](https://github.com/FrankieIsLost/Mortys), [Smart Batched Auctions](https://github.com/FrankieIsLost/smart-batched-auction), and [TWAMM](https://github.com/FrankieIsLost/TWAMM). Talking about mechanism design with [Dave White](https://twitter.com/_Dave__White_) and [Dan Robinson](https://twitter.com/danrobinson), crypto tooling with [Georgios Konstantopoulos](https://twitter.com/gakonst), security with [samczsun](https://twitter.com/samczsun), and prototyping with [Anish Agnihotri](https://twitter.com/_anishagnihotri) all felt like rare privileges. Throughout our interactions, I was struck by their focus on pushing the crypto space forward. Paradigm has assembled a world-class team of builders, and is uniquely equipped to support those at the spearhead. I'm grateful that my focus at the firm will be continuing to build, with both the research and engineering teams, as well as with our portfolio companies. If you are also a builder, we want to hear from you. Whether you're an anon writing your first lines of Solidity, or an experienced founder, you can DM me on [Twitter](https://twitter.com/FrankieIsLost), or reach me by email at [frankie@paradigm.xyz](mailto:frankie@paradigm.xyz). There's a lot of work to be done. ## https://www.paradigm.xyz/writing/introducing-the-foundry-ethereum-development-toolbox # Introducing the Foundry Ethereum development toolbox > Foundry is a portable, fast and modular toolkit for Ethereum application development. I am excited to announce a project [we](https://github.com/gakonst/foundry/graphs/contributors) have been developing for the last few months: [Foundry](https://github.com/gakonst/foundry). **Foundry is a portable, fast and modular toolkit for Ethereum application development.** ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--d9f5a99f59/be6f406f35bc4b71ac349be5b53bbbed/asset-https-cdn-sanity-io-images-dgybcd83--d9f5a99f59.jpg) ## Why Foundry? You should use Foundry’s tools, [forge](https://github.com/gakonst/foundry/tree/master/forge) and [cast](https://github.com/gakonst/foundry/tree/master/cast), if you want the fastest & most flexible Ethereum development environment which works out of the box without configuration or third party libraries. **Acknowledgement:** Foundry is a reimplementation of the testing framework [dapptools,](https://github.com/dapphub/dapptools) written in Rust to be blazing fast, easy to install, and friendly to a wider set of contributors. While our codebase is not a fork (and has many additional features like supporting multiple solc versions), none of this would have been possible without the DappHub team's innovative work over the years. Thank you DappHub! If you agree with the below Ethereum development tips, then Foundry is for you. ### **You should be writing your tests in Solidity** Most developers still test Solidity using Javascript or Typescript, which is not great. Testing in JS requires a lot of boilerplate, large dependencies (I’m looking at you node_modules/), and config files. As an example, feel free to look at Paul Berg’s [solidity-template](https://github.com/paulrberg/solidity-template). In addition to that, Ethereum numbers in JS require using a BigNumber library such as bignumber.js, BigNumber, bn, or JS’s new native BigInt, which frequently cause incompatibility issues & productivity loss. Finally, testing in JS instead of Solidity means that you operate 1 level of abstraction away from what you actually want to test, requiring you to be familiar with Mocha and Ethers.js or Web3.js at a minimum. This increases the barrier to entry for Solidity developers. Forge lets you write your tests in Solidity, so you can focus on what matters: writing good tests. A simple Solidity test would look like this: ```solidity contract Foo { uint256 public x = 1; function set(uint256 _x) external { x = _x; } function double() external { x = 2 * x; } } contract FooTest { Foo foo; // The state of the contract gets reset before each // test is run, with the `setUp()` function being called // each time after deployment. Think of this like a JavaScript // `beforeEach` block function setUp() public { foo = new Foo(); } // A simple unit test function testDouble() public { require(foo.x() == 1); foo.double(); require(foo.x() == 2); } // A failing unit test (function name starts with `testFail`) function testFailDouble() public { require(foo.x() == 1); foo.double(); require(foo.x() == 4); } } ``` ### **You should be fuzzing your functions** Even if you unit test every single function in your code and try to get 100% test coverage, there may be edge cases you did not test for. Fuzzing lets the Solidity test runner choose the arguments for you randomly, by simply giving arguments to your Solidity test function. Here’s an example of a fuzzed test for the above smart contract: ```solidity function testDoubleWithFuzzing(uint256 x) public { foo.set(x); require(foo.x() == x); foo.double(); require(foo.x() == 2 * x); } ``` The fuzzer will automatically try this function with random values of x. If it finds an input that makes the test fail, it will return it to you, so you can create a regression test after fixing the bug: ```solidity function testDoubleWithFuzzingCounterExample(uint256 x) public { foo.set(x); require(foo.x() == x); foo.double(); require(foo.x() == 4 * x); } ``` If you ran this test, you’d get the below response in the CLI: ```solidity [FAIL. Counterexample: calldata=0x44735ef10000000000000000000000000000000000000000000000000000000000000001, args=[Uint(1)]] testDoubleWithFuzzingCounterExample (gas: [fuzztest]) ``` It also supports shrinking, so that you get a “minimal” counterexample that causes your code to fail (instead of, say, a very large number or byte string). ### **You should be able to override VM state in your tests** Have you tried testing a function that requires a certain block number? Sure, you can call the RPC method evm_mine, but what if you’re testing a Compound Governance contract, and you need to advance 40,000 blocks? Have you tried simulating a mainnet transaction and wanting to give your account a certain token balance, or write access to a permissioned function? To solve these problems (and many more), we provide VM cheatcodes, which allow modifying the VM’s state at test runtime. This is exposed to the test author via a contract that lives at a pre-configured address. The below simple example shows how to override a block’s timestamp: ```solidity address constant CHEATCODE_ADDRESS = 0x7cFA93148B0B13d88c1DcE8880bd4e175fb0DeDF; interace Vm { // Sets the block.timestamp to `x`. function warp(uint256 x) external; } contract MyTest { Vm vm = Vm(CHEATCODE_ADDRESS); function testWarp() public { vm.warp(100); require(block.timestamp == 100); } } ``` More information on the other cheatcodes can be found in the [README](https://github.com/gakonst/foundry/tree/master/forge#cheat-codes). Cheatcodes are quite powerful (e.g. store lets you override an arbitrary contract storage slot, and prank lets you make an arbitrary call from an arbitrary account). We recommend spending time using them to extend the code paths your tests explore, and encourage contributing with [new ones](https://github.com/gakonst/foundry/blob/master/evm-adapters/src/sputnik/cheatcodes/cheatcode_handler.rs#L249-L397). ### **You should be able to run your tests against a live network’s state** Like most Ethereum development tools, Forge supports “forking” against a remote network’s state by specifying a node URL (and optionally a block number if you have an archive node, for pinning your tests against a block). Just run `forge test --fork-url [--fork-block-number ]`. ### **You should be able to log debug information while running your tests** Forge supports runtime debug logging with [ds-test](https://github.com/dapphub/ds-test/blob/0a5da56b0d65960e6a994d2ec8245e6edd38c248/src/test.sol)’s `emit log_` functions, as well as Hardhat’s [`console.log`](https://hardhat.org/tutorial/debugging-with-hardhat-network.html). ## **OK I’m sold, how do I start?** Forge and Cast can be installed by running `cargo install --git https://github.com/gakonst/foundry --locked` (you can install Rust [here](https://rustup.rs/) if you haven't already). We also plan to distribute statically built binaries per-platform, and provide `brew` and `apt` packages. If you've done automatic release flows for projects before, [reach out](mailto:georgios@paradigm.xyz)! Once installed, you just need to `forge init` to create a new project (by default at the current directory) and then `forge build`. That’s it. You’re started in <2s. ## **How fast?** We have conducted benchmarks against some Dapptools repositories to compare the testing speed. Integration tests are also available [here](https://github.com/gakonst/dapptools-benchmarks). | Project | Forge | Dapp | Speedup | -- | -- | -- | -- |[guni-lev](https://github.com/hexonaut/guni-lev/) | 28.6s | 2m36s | **5.45x** |[solmate](https://github.com/transmissions11/solmate) | 6s | 46s | **7.66x** |[geb](https://github.com/reflexer-labs/geb) | 11s | 40s | **3.63x** |[vaults](https://github.com/rari-capital/vaults) | 1.4s | 5.5s | **3.9x** We also [compiled](https://twitter.com/gakonst/status/1461289225337421829) [openzeppelin-contracts](https://github.com/OpenZeppelin/openzeppelin-contracts) with Forge and Hardhat. Hardhat compilation took 15.244s, whereas Forge took 9.449s. [Another](https://twitter.com/msolomon44/status/1466198596772978689) benchmark also showed promising (and nuanced!) results. Maybe there should be a benchmarking test suite for compilation & testing frameworks? ## **What’s the vision?** In Summer 2020, we started with writing [ethers-rs](https://github.com/gakonst/ethers-rs/), a Rust port of [ethers.js](https://docs.ethers.io/v5/), with the goal of helping MEV traders build better bots. Then, we built other infrastructure like [MEV Inspect](https://github.com/flashbots/mev-inspect-rs), [Ethers Fireblocks](https://github.com/gakonst/ethers-fireblocks/), [Ethers Flashbots](https://github.com/onbjerg/ethers-flashbots/), [Ark Circom](https://github.com/gakonst/ark-circom/), [Optics](https://github.com/celo-org/optics-monorepo/tree/main/rust) [and more](https://github.com/search?q=ethers-rs&type=code). Now, we have built a flexible compilation pipeline ([ethers-solc](https://github.com/gakonst/ethers-rs/tree/master/ethers-solc) which may support [new languages](https://github.com/WilfredTA/ethers-rs/tree/feat/ethers-compile/ethers-compile/src/fe) like [Fe](https://github.com/ethereum/fe)), abstractions over the EVM ([evm-adapters](https://github.com/gakonst/foundry/tree/master/evm-adapters)) and [fast test runners](https://github.com/gakonst/foundry/tree/master/forge). ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--9a802b589b/e9a8635df84e45dc0bc65eac8d095a08/asset-https-cdn-sanity-io-images-dgybcd83--9a802b589b.png) Gradually but surely, we are creating modular, well-documented & high performance building blocks for the next 1 million Ethereum developers and entrepreneurs. For more information on how to use Foundry’s CLI, look in the [README](https://github.com/gakonst/foundry/blob/master/cli/README.md). There are still [many features we want to add](https://github.com/gakonst/foundry/tree/master/forge#future-features) (both to get to dapptools feature parity and more new exciting features). You should check out [Foundry on Github](https://github.com/gakonst/foundry). Finally, we’re hiring both internally at Paradigm and across the portfolio - check out all our open roles at [jobs.paradigm.xyz](http://jobs.paradigm.xyz/), or reach out to me at [georgios@paradigm.xyz](mailto:georgios@paradigm.xyz). ## https://www.paradigm.xyz/writing/paradigms-new-chief-technology-officer # Paradigm’s New Chief Technology Officer > Today, we are excited to announce Georgios Konstantopoulos as our new Chief Technology Officer. Like many of our best decisions at Paradigm, the decision to hire [Georgios Konstantopoulos](https://www.paradigm.xyz/team/gakonst/) in 2020 began in the spirit of experimentation. We knew that great crypto/Web3 engineering talent was scarce. And we kept noticing an insanely brilliant and productive Greek engineer showing up as a consultant across our portfolio and coming up in conversations with engineers and researchers. We always love opportunities to work with special individuals even if they may not slot into a predetermined role, so we brought Georgios onto the team as our second Research Partner to keep doing what he does best: jumping in to help crypto/Web3 projects with their toughest engineering challenges. In the time since, Georgios has become an essential member of the Paradigm team: contributing to the portfolio, publishing open source research, collaborating with the investment team to diligence and sponsor investments, building internal and open source software, tweeting about Rust/dapptools, and more. Today, we are excited to announce Georgios as our new Chief Technology Officer. He will continue to be a Research Partner, publishing industry-leading work and helping out our portfolio (don’t panic!). But Georgios will now also: - Set Paradigm’s technical vision and strategy - Help our killer in-house engineering team grow - Drive and ship great internal software Paradigm is *itself* a crypto/Web3 startup, and our technology needs are growing. Operating in a new market like crypto has required us to build a lot of proprietary software. This includes systems that help us manage our finance and operational needs, as well as crypto-native tools for trading, voting, staking, minting NFTs, and otherwise participating on-chain. When we envision how Paradigm will evolve over the next ten years, it seems obvious that technology will play a larger and larger role. We can think of nothing more appropriate than Georgios taking a leadership role in helping us build towards this future. If you are an engineer who’d like to join the technical team [at Paradigm](https://jobs.paradigm.xyz/?o=30475&j=1064993784) or somewhere in [our portfolio](https://jobs.paradigm.xyz/?j=1064993784), please reach out! ## https://www.paradigm.xyz/writing/paradigms-new-venture-fund # Paradigm’s New Venture Fund > Announcing our new venture fund to continue investing in the next generation of crypto companies and protocols. We started Paradigm in 2018 with two strongly-held beliefs. First, that despite being in the midst of a “winter,” crypto was poised to be one of the most important technical and economic shifts over the coming decades with the potential to fundamentally change money, the financial system (DeFi), and the internet more broadly (Web3). Second, that the best way for us to contribute to this revolution was to build an investment firm uniquely adapted to crypto, so that we could be the best possible partner to crypto entrepreneurs and communities. We’ve immersed ourselves in the frontier of protocol research and the culture of Web3. And we’ve built a team of domain experts around research, engineering, security, talent, communications and marketing, legal and policy, and everything else crypto entrepreneurs might need to advance their projects. Our conviction in these beliefs has only strengthened over the past three years, and we are pleased to announce a new $2.5 billion venture fund to continue investing in the next generation of crypto companies and protocols. This new fund will invest alongside our existing flagship fund across all stages and geographies. This new fund and its size are reflective of crypto being the most exciting frontier in technology. Over the past decade, crypto has come a long way. But cryptocurrencies are still owned by less than ten percent of the global population. Decentralized financial systems have grown to hold over $100 billion in cumulative assets, yet still represent a small drop in the context of the traditional financial system. Web3 applications have grown to reach tens of millions of users, yet are still a far cry from the billions of Web2 users. The journey is just beginning, and the potential of crypto has never been more clear. Our mission at Paradigm remains unchanged: to be the earliest and most helpful partner to crypto entrepreneurs and communities. We’ll continue incubating ideas. We’ll continue investing at the earliest stages when there’s just a glimmer of an idea. We’ll also partner with later-stage category leaders, and support companies at every stage in between. There has never been a more exciting time to work in crypto, and we are grateful to our limited partners for their ongoing support and to the entrepreneurs who’ve entrusted us as their partners. If you’re an entrepreneur working on the frontier, we’d love to talk! Best, Matt, Fred, and the Paradigm team ## https://www.paradigm.xyz/writing/hiding-in-plain-sight # Hiding in Plain Sight > I like challenging assumptions. I like trying to do the impossible, finding what others have missed, and blowing people's minds with things they never saw coming. I like challenging assumptions. I like trying to do the impossible, finding what others have missed, and blowing people's minds with things they never saw coming. Last year, I wrote a [challenge](https://samczsun.com/paradigm-ctf-2021-swap/) for Paradigm CTF 2021 based on a very obscure Solidity bug. While one variation had been publicly disclosed, the vulnerability I exploited had never really been discussed. As a result, almost everyone who tried the challenge was stumped by the seemingly impossible nature of it. A few weeks ago, we were discussing plans around Paradigm CTF 2022 when Georgios tweeted out a teaser tweet. I thought it would be incredibly cool to drop a teaser challenge on the same day as the kickoff call. However, it couldn't just be any old teaser challenge. I wanted something out of this world, something that no one would see coming, something that pushed the limits of what people could even imagine. I wanted to write the first Ethereum CTF challenge that exploited an 0day. *Embed* # How It's Made: 0days As security researchers, there are a few base assumptions we make in order to optimize our time. One is that the source code we're reading really did produce the contract we're analyzing. Of course, this assumption only holds if we're reading the source code from somewhere trusted, like Etherscan. Therefore, if I could figure out a way to have Etherscan verify something incorrectly, I would be able to design a really devious puzzle around it. In order to figure out how to exploit Etherscan's contract verification system, I had to verify some contracts. I deployed a few contracts to Ropsten to play around with and tried verifying them. Immediately, I was greeted with the following screen. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--8b9ab1a6d6/24719eb421a786087ad49b6184abdb17/asset-https-cdn-sanity-io-images-dgybcd83--8b9ab1a6d6.png) I selected the correct settings and moved onto the next screen. Here, I was asked to provide my contract source code. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--76b56bfac1/eab5f04400fc13a6e8ee46647ef31a97/asset-https-cdn-sanity-io-images-dgybcd83--76b56bfac1.png) I put in the source code and clicked verify. Sure enough, my source code was now attached to my contract. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--466fb65011/2c9b3155dbf7f9814782286eb203576f/asset-https-cdn-sanity-io-images-dgybcd83--466fb65011.png) Now that I knew how things worked, I could start playing around with the verification process. The first thing I tried was deploying a new contract with `foo` changed to `bar` and verifying that contract with the original source code. Unsurprisingly, Etherscan refused to verify my contract. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--fc1feddd11/536bdab2ff329fcd29d983fee690978d/asset-https-cdn-sanity-io-images-dgybcd83--fc1feddd11.png) However, when I manually compared the two bytecode outputs, I noticed something strange. Contract bytecode is supposed to be hex, but there was clearly some non-hex in there. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--6f129db7df/cec78632e05638f497a831afa759bf10/asset-https-cdn-sanity-io-images-dgybcd83--6f129db7df.png) I knew that Solidity appended [contract metadata](https://docs.soliditylang.org/en/v0.8.9/metadata.html#encoding-of-the-metadata-hash-in-the-bytecode) to the deployed bytecode, but I never really considered how it affects contract verification. Clearly, Etherscan was scanning through the bytecode for the metadata and then replacing it with a marker that said, "Anything in this region is allowed to be different, and we'll still consider it the same bytecode." This seemed like a promising lead for a potential 0day. If I could trick Etherscan into interpreting non-metadata as metadata, then I would be able to tweak my deployed bytecode in the region marked `{ipfs}` while still having it verify as the legitimate bytecode. The easiest way I could think of to include some arbitrary bytecode in the creation transaction was to encode them as constructor arguments. Solidity encodes constructor arguments by appending their ABI-encoded forms directly onto the create transaction data. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--e659eef294/8e0aa24f07a742860ef323556065e9e9/asset-https-cdn-sanity-io-images-dgybcd83--e659eef294.png) However, Etherscan was too smart, and excluded the constructor arguments from any sort of metadata sniffing. You can see that the constructor arguments are italicized, to indicate that they're separate from the code itself. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--47545cdcfc/03785b8379789830c9815425ffb2125d/asset-https-cdn-sanity-io-images-dgybcd83--47545cdcfc.png) This meant I would need to somehow trick the Solidity compiler into emitting a sequence of bytes that I controlled, so I could make it resemble the embedded metadata. However, this seemed like a nightmare of a problem to solve, since I would have almost no control over the opcodes or bytes that Solidity chooses to use without some serious compiler wrangling, after which the source code would look extremely suspicious. I considered this problem for a while, until it hit me: it was actually extremely easy to cause Solidity to emit (almost) arbitrary bytes. The following code will cause Solidity to emit 32 bytes of `0xAA`. ```python bytes32 value = 0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa; ``` Motivated, I quickly wrote a small contract which would push a series of constants in such a way that Solidity would emit bytecode which exactly resembled the embedded metadata. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--bb5f5a464c/9e3388156e754e7a327a294eb92d9e3f/asset-https-cdn-sanity-io-images-dgybcd83--bb5f5a464c.png) To my delight, Etherscan marked the presence of an IPFS hash in the middle of my contract, where no embedded metadata should ever be found. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--09da4a9852/bdb71a2d1939418b3a5394d6eedda0d9/asset-https-cdn-sanity-io-images-dgybcd83--09da4a9852.png) I quickly copied the expected bytecode and replaced the IPFS hash with some random bytes, then deployed the resulting contract. Sure enough, Etherscan considered the differing bytes business as usual, and allowed my contract to be verified. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--debde2e234/9a7ac533679b01457ccba0a9159a4a50/asset-https-cdn-sanity-io-images-dgybcd83--debde2e234.png) With this contract, the source code suggests that a simple `bytes` object should be returned when calling `example()`. However, if you actually try to call it, this happens. ```python $ seth call 0x3cd2138cabfb03c8ed9687561a0ef5c9a153923f 'example()' seth-rpc: {"id":1,"jsonrpc":"2.0","method":"eth_call","params":[{"data":"0x54353f2f","to":"0x3CD2138CAbfB03c8eD9687561a0ef5C9a153923f"},"latest"]} seth-rpc: error: code -32000 seth-rpc: error: message stack underflow (5 <=> 16) ``` I had successfully discovered an 0day within Etherscan, and now I could verify contracts which behaved completely differently from what the source code suggested. Now I just needed to design a puzzle around it. # A false start Clearly, the puzzle would revolve around the idea that the source code as seen on Etherscan was not how the contract would actually behave. I also wanted to make sure that players couldn't simply replay transactions directly, so the solution had to be unique per-address. The best way to do this was obviously to require a signature. But in what context would players be required to sign some data? My first design was a simple puzzle with a single public function. Players would call the function with a few inputs, sign the data to prove they came up with the solution, and if the inputs passed all the various checks then they would be marked as a solver. However, as I fleshed out this design over the next few hours, I quickly grew dissatisfied with how things were turning out. It was starting to become very clunky and inelegant, and I couldn't bear the idea of burning such an awesome 0day on a such a poorly designed puzzle. Resigning myself to the fact that I wouldn't be able to finish this in time for Friday, I decided to sleep on it. # Pinball I continued trying to iterate on my initial design over the weekend, but made no more progress. It was like I'd hit a wall with my current approach, and even though I didn't want to admit it, I knew that I'd likely have to start over if I wanted something I'd be satisfied with. Eventually, I found myself reexamining the problem from first principles. What I wanted was a puzzle where players had to complete a knowledge check of sorts. However, there was no requirement that completing the knowledge check itself was the win condition. Rather, it could be one of many paths that the player is allowed to take. Perhaps players could rack up points throughout the puzzle, with the exploit providing some sort of bonus. The win condition would simply be the highest score, therefore indirectly encouraging use of the exploit. I thought back to a challenge I designed last year, [Lockbox](https://github.com/paradigm-operations/paradigm-ctf-2021/blob/master/lockbox/public/contracts/Lockbox.sol), which forced players to construct a single blob of data which would meet requirements imposed by six different contracts. The contracts would apply different constraints on the same bytes, forcing players to be clever in how they constructed their payload. I realized I wanted to do something similar here, where I would require players to submit a single blob of data and I would award points based on certain sections of data meeting specific requirements. It was at this point that I realized I was basically describing [pinboooll](https://archive.ooo/c/pinboooll/376/), a challenge I worked on during the finals of DEFCON CTF 2020. The gimmick with pinboooll was that when you executed the binary, execution would bounce around the control flow graph similar to how a ball bounces around in a pinball machine. By constructing the input correctly, you would be able to hit specific sections of code and rack up points. Of course, there was an exploit involved as well, but frankly speaking I'd already forgotten what it was and I had no intention of trying to find it again. Besides, I already had my own exploit I wanted to use. Since I was handling a live 0day here, I decided that I wanted to get the puzzle out as soon as possible, even if it meant compromising on how much of someone else's work I'd be copying. In the end, I spent a few hours refreshing myself on how pinboooll worked and a few days re-implementing it in Solidity. This took care of the scaffolding of the puzzle, now I just had to integrate the exploit. # Weaponizing an 0day My approach to getting Solidity to output the right bytes had always been to just load several constants and have Solidity emit the corresponding PUSH instructions. However, such arbitrary constants would likely be a huge red flag and I wanted something that would blend in slightly better. I also had to load all the constants in a row, which would be hard to explain in actual code. Because I really only needed to hardcode two sequences of magic bytes (`0xa264...1220` and `0x6473...0033`) I decided to see if I could sandwich code between them, instead of a third constant. In the deployed contract, I would just swap out the sandwiched code with some other instructions. ```python address a = 0xa264...1220; uint x = 1 + 1 + 1 + ... + 1; address b = 0x6473...0033; ``` After some experimentation, I found it would be possible, but only if the optimizer was enabled. Otherwise, Solidity emits too much value cleanup code. This was acceptable, so I moved on to refining the code itself. I would only be able to modify the code within the two addresses, but it would be weird to see a dangling address at the end, so I decided to use them in conditionals instead. I also had to justify the need for the second conditional, so I threw in a little score bonus in the end. I made the first conditional check that the tx.origin matched a hardcoded value to give people the initial impression that there was no point pursuing this code path any further. ```python if (tx.origin != 0x13378bd7CacfCAb2909Fa2646970667358221220) return true; state.rand = 0x40; state.location = 0x60; if (msg.sender != 0x64736F6c6343A0FB380033c82951b4126BD95042) return true; state.baseScore += 1500; ``` Now that the source code was all prepared, I had to write the actual backdoor. My backdoor would need to verify that the player triggered the exploit correctly, fail silently if they didn't, and award them a bonus if they did. I wanted to make sure the exploit couldn't be easily replayed, so I decided on simply requiring the player to sign their own address and to submit the signature in the transaction. For extra fun, I decided to require the signature to be located at offset 0x44 in the transaction data, where the ball would typically begin. This would require players to understand how ABI encoding works and to manually relocate the ball data elsewhere. However, here I ran into a big problem: it's simply not possible to fit all of this logic into 31 bytes of hand-written assembly. Fortunately, after some consideration, I realized that I had another 31 bytes to play with. After all, the real embedded metadata contained another IPFS hash that Etherscan would also ignore. After some code golfing, I arrived at a working backdoor. In the first IPFS hash, I would immediately pop off the address that just got pushed, then jump to to the second IPFS hash. There, I would hash the caller and partially set up the memory/stack for a call to `ecrecover`. Then I would jump back to the first IPFS hash where I finish setting up the stack and perform the call. Finally, I set the score multiplier to be equal to `(msg.sender == ecrecover()) * 0x40 + 1`, which meant that no additional branching was needed. After code golfing the backdoor down to size, I tweeted out my Rinkeby address in order to get some testnet ETH from the faucet, and to drop a subtle hint to anyone watching Twitter that something might be coming. Then, I deployed the contract and verified it. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--285183c976/a7aaf46885e09cf0cec09a4438887264/asset-https-cdn-sanity-io-images-dgybcd83--285183c976.png) Now all that was left to do was wait for someone to [discover](https://medium.com/@kanewallmann_71759/an-untrustworthy-pinball-machine-d9dcd07882c) the backdoor that was hiding in plain sight. ## https://www.paradigm.xyz/writing/a-guide-to-designing-effective-nft-launches # A Guide to Designing Effective NFT Launches > Blockchains revolutionized fundraising for open-source software, but not everything worked right from the start. In fact, ICOs of the 2016-2018 era were often horribly broken mechanisms that allowed founders to cash out before delivering any products. Many lessons have been learned since, with today’s projects having a working product before launching a token and distributing it to incentivize usage and decentralize governance. Blockchains revolutionized fundraising for open-source software, but not everything worked right from the start. In fact, ICOs of the 2016-2018 era were often horribly broken mechanisms that allowed founders to cash out before delivering any products. Many lessons have been learned since, with today’s projects having a working product before launching a token and distributing it to incentivize usage and decentralize governance. NFTs are proving to be another clear product-market-fit for crypto, but they are experiencing their own growing pains. The life of every NFT begins in an NFT launch (also sometimes called a mint or drop). An NFT launch is where a new collection is first created, sold, and distributed to buyers, who then decide to hold or trade it in secondary markets. Like any item that goes on sale for the first time, NFT launches face the challenge of pricing something that has never had a price before. But unlike most other sales, they have the added difficulty of taking place in a highly adversarial environment full of idiosyncrasies that already alienate inexperienced users—a public blockchain. As a result, developers have to design mechanisms that are efficient and robust to exploitation. This article starts with real-world examples of launches that empirically hurt their users to identify what goals a good launch *should* satisfy. Next, we deconstruct the idea of a launch into individual steps, exploring the design space for each of them. Finally, we provide a reference implementation of what we think is one well-designed launch mechanism for the community to use and build on. ## Examples of user harm Over time, we’ve come to notice that certain design patterns in NFT launches consistently lead to poor outcomes for users. ### Exploitable fairness When a new collection launches, users can interact with its smart contract to mint an NFT with a random set of attributes. These attributes tend to be of different scarcities, making some combinations more rare and valuable than others. For example, only 9 of 10,000 CryptoPunks have the ultra-rare “Alien” attribute, with the cheapest one listed for 35,000 ETH right now. While different people participate in mints for various reasons, many enjoy the excitement of not knowing what item and rarity they will get. In that sense, NFT mints are merely a continuation of the popular [gacha mechanic](https://en.wikipedia.org/wiki/Gacha_game) in analog (e.g., booster packs for trading card games) and digital (e.g., loot boxes/crates in video games) economies for a long time. Those who participate in gacha games tend to make an important assumption: they draw from a random distribution of items and have an actual (albeit slight) chance of getting a very rare drop. Unfortunately, past NFT mints have frequently failed to satisfy this assumption and create true randomness. In practice, this has allowed highly technical and motivated parties to exploit mints and snipe the rarest items of a collection, taking them away from honest participants. With this pattern, we share two cases where NFT mints have been exploited in precisely that way. Both exploits relied on the same two-step process: 1. An exploiter extracts the collection’s metadata, allowing them to represent the relative frequency of all traits in a single rarity score. Using this score, they can then determine the highest-value NFTs of a collection. 2. The exploiter then breaks the minting contract’s randomness to mint only the rare, highest-value NFTs they want. #### Loot derivatives and the on-chain metadata exploit Recently, a project called [Loot](https://twitter.com/dhof/status/1431316631934967815) took the NFT world by storm. Seemingly simple, the project featured 8,000 loot bags made up of *chest, foot, hand, head, neck, ring, waist*, and *weapon* items of varying rarity. With all attributes for each item slot stored directly in the contract, minters received a pseudorandom bag, using the bag ID as the hash. While permanent for as long as Ethereum exists, storing metadata on-chain also exposed Loot’s pseudorandom nature to exploiters. They quickly scraped the metadata for all 8,000 bags by simulating the randomization functions locally, getting a picture (and derived rarity) of the entire collection. Equipped with that info, they only had to exploit the contract’s last remaining weakness: the ability to mint exactly the IDs they wanted and snipe only the rarest bags. However, despite the simplicity of this exploit, there is reason to believe that no one exploited the original Loot mint: ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--73e4526ef8/650fcf1fe5440d49e867347348f08c48/asset-https-cdn-sanity-io-images-dgybcd83--73e4526ef8.png) Source: https://github.com/Anish-Agnihotri/blog-effective-nft-launches-data/tree/master/01-exploitable-fairness/loot If we observe the rarity of bags up until the very end of the mint, rare items are well-distributed across the span of the mint. That indicates no standout cases of exploitation. There are two potential explanations why Loot wasn’t exploited: 1. It was a completely new contract, so people were not ready or lacked time to discover the exploit. 2. The EV of minting Loot was unclear, as the collection’s value only exploded in the secondary market over the following days. That it took 2.5 hours for the collection to sell out further supports this hypothesis. However, as the price of Loot kept increasing, a whole range of derivatives like [More Loot](https://twitter.com/dhof/status/1434180216444923923) and [Extension Loot](https://twitter.com/colingplatt/status/1433404301515370496?s=20) started popping up, most of which were simply minor forks of the original Loot contract. The new collections inherited Loot’s vulnerabilities but at a higher market value and with more eyes on them. This made all the difference to the fairness—or lack thereof— of these mints. ##### More Loot Comparing the distribution of rare items to the time of mint between More Loot and original Loot, evidence of exploitation becomes very obvious. After only a few blocks, all rare NFTs had been minted, leaving just scraps to future minters, who were mainly left unaware that sophisticated users had exploited the launch. ![Source: https://github.com/Anish-Agnihotri/blog-effective-nft-launches-data/tree/master/01-exploitable-fairness/mLoot](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--6d6ea9b400/46138e12da8cbea9fc6e59d1d9da6d17/asset-https-cdn-sanity-io-images-dgybcd83--6d6ea9b400.png) Source: https://github.com/Anish-Agnihotri/blog-effective-nft-launches-data/tree/master/01-exploitable-fairness/mLoot Below: The red line indicates when Anish made his rarity scores [public on Twitter](https://twitter.com/_anishagnihotri/status/1434220175268749320), starting a race to claim available rare bags. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--a007ba05c4/9b21f5430442592f15e8902951488f6b/asset-https-cdn-sanity-io-images-dgybcd83--a007ba05c4.png) Source: https://github.com/Anish-Agnihotri/blog-effective-nft-launches-data/tree/master/01-exploitable-fairness/mLoot Furthermore, because More Loot has an inflating supply, it is fair to expect exploiters will pre-score future available bags and race to mint them. ##### Extension Loot Similar to More Loot, Extension Loot features a single address minting five of the rarest ten bags (all mints highlighted in red). Uniquely, these mints are hidden in near plain sight, as the exploiter distributes them over time and available bags before targeting rare bags in succession. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--e412960887/3c5a7f8d0a7483d7bba19d3742bae0ba/asset-https-cdn-sanity-io-images-dgybcd83--e412960887.png) Source: https://github.com/Anish-Agnihotri/blog-effective-nft-launches-data/tree/master/01-exploitable-fairness/xLoot #### Meebits and the off-chain metadata exploit [Meebits](https://meebits.larvalabs.com/) was a highly anticipated NFT mint of 20,000 unique 3D characters from Larva Labs, the creators of CryptoPunks. Larva Labs knew savvy users could use a collection’s metadata to calculate rarity and snipe rare NFTs. To combat this, they designed their website in a way that allowed buyers to see the complete metadata of each Meebit, but only after it had been minted. While the website explicitly hid unminted Meebits, someone inspected the source code to see that LarvaLabs pulled the metadata from IPFS. Using this information, they scraped IPFS to extract the metadata of unminted Meebits anyway, identifying the most desirable ones. However, Larvalabs still didn’t make it easy on the exploiter: unlike Loot, a user couldn't mint a specific Meebit ID. Instead, on-chain randomness used as a hash (in theory still exploitable by miners) made it harder for this particular user to mint a rare Meebit. The exploiter, however, knew how to make the best of a bad situation. They [wrote a contract](https://etherscan.io/address/0x270ff2308a29099744230de56e7b41c8ced46ffb) to buy Meebits, see their ID, and then “reroll” them. Specifically, the Meebit contract was an ERC721 with a mint() function that returned a random Meebit ID. The exploiter’s contract would call mint, check the returned Meebit ID against their rarity list, and if it didn’t exceed a certain rarity score, revert the transaction ([sample code](https://github.com/Anish-Agnihotri/blog-effective-nft-launches-data/tree/master/01-exploitable-fairness/meebits)). Using this trick, they only paid about 0.03 ETH to check each ID instead of ~2.5 ETH for buying each Meebit outright. While the attacker burned through many failed transactions and hence gas fees in the process, they walked away with ~400 ETH in profit. Today, the same exploiter could send their transactions via Flashbots bundles and only pay the miner if they got one of the IDs they wanted—making reverts completely free. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--cf0b7666dd/9665ac4a0079392e9e689f404dcdd67c/asset-https-cdn-sanity-io-images-dgybcd83--cf0b7666dd.png) The attacker minted and sold Meebit #16647, which had the ultra-rare “visitor” trait. ### Gas auctions In September, the Ethereum base fee per gas surpassed 1,250 gwei over seven unique periods. Alarmingly, all seven of these occurrences were because highly-anticipated NFT launches disrupted the network. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--6228ca9e5c/dc2ba17b2724a52ee442750621b0e850/asset-https-cdn-sanity-io-images-dgybcd83--6228ca9e5c.png) From left to right: G’EVOLS, The Sevens, Sipher, Galaxy Eggs, Omnimorphs + ArtBlocks Democracity, Galactic Apes, King Frogs Most of these launches employed a fixed-price, first-come-first-served (FCFS) mechanism. With low prices and excessive demand, competition to acquire such NFTs transitioned from the contract sale to a gas auction in the mempool. One such example was [The Sevens](https://thesevensofficial.com/) NFT drop, a highly anticipated collection of 7,000 collectible profile pictures featuring dystopian characters. With an initial price of 0.07 ETH per NFT, eager participants hurried to the contract to mint. Within just 6 minutes, gas prices peaked at 12,246 gwei, with the median participant paying ~1.49 ETH per NFT and the highest 5% of individuals paying 2.44+ ETH per NFT in gas alone to mint from the contract. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--71a681bda9/e921981106e1e7c3bc9b199c9ab2a143/asset-https-cdn-sanity-io-images-dgybcd83--71a681bda9.png) Rapid escalation of block base fee for the duration of the Sevens mint The problem with gas auctions is not just that they are more challenging to use, but by “abusing” the public mempool in this way, they create negative externalities for all Ethereum users. They also force users to pay different amounts for the same NFT, resulting in thousands of failed transactions from insufficient bids, hurting users. High skill As we’ve seen before, [Ethereum is a Dark Forest](https://www.paradigm.xyz/2020/08/ethereum-is-a-dark-forest/), with advanced, adversarial actors always on the lookout. NFT mints, especially rare ones where buyers expect to pocket a premium in the secondary markets after minting, offer lucrative opportunities for technically-adept parties to outskill the average participant. These participants interact directly with the minting contracts through botting and automated strategies, often bypassing frontends and occasionally even the mempool. The TIMEPieces NFT drop showcased a prime example of this. Advanced bot operators [inspected](https://twitter.com/_anishagnihotri/status/1441072865764429825?s=20) the [nft.time.com](https://nft.time.com/) frontend source code ahead of the minting process. Through this, they were able to find deployed minting contracts on mainnet and built bots hours in advance. As a result, these bots had a significant advantage during the mint, which completely sold out in under three minutes. By the time the average participant had connected their wallet and submitted a transaction, it was too late. Furthermore, some parties [used Flashbots](https://flashbots-explorer.marto.lol/?block=13282940) to circumvent the mempool and submit direct-to-miner transactions. While the TIMEPieces contract restricted participants to minting a maximum of ten NFTs per address, bot operator 0x35...ce5 planned ahead, split funds across five wallets, and sniped 50 NFTs in a single Flashbots bundle. Even after paying a 20 ETH miner tip (bringing their average mint cost to 0.5 ETH per NFT), this bot operator stood to profit nearly 120 ETH when the NFTs began to hit the secondary market. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--becb0a21a7/8719269cc8855d8690085e85951760a8/asset-https-cdn-sanity-io-images-dgybcd83--becb0a21a7.png) This bundle included 5 mint transactions from different addresses, circumventing the per-address minting limit Additionally, because this participant used Flashbots (which reverts failing transactions at zero cost), they did not suffer from the failed transactions we described in the previous example. This is unlike the near 10,962 average-skilled participants that lost a cumulative 252.62 ETH (almost $800,000) in transaction fees, across 12,743 reverts in 100 blocks, for their attempts that were unsuccessful. ### Gas inefficiency An effective NFT minting mechanism is easy to use for all participants—ideally, with few steps and simple implementation. A common pitfall for mints that implement alternatives to the FCFS distribution model is that they introduce complexity, increasing the number of on-chain transactions a user must make. One example is the [Jay Pegs Auto Mart](https://jaypegsautomart.com/) $DONA auction on [Miso](https://miso.sushi.com/). While the mint pioneered batch auction NFT distributions and effectively showcased how fair metadata generation could look in practice, it did so at the expense of gas and transaction efficiency. To participate in the minting process, users had to make a minimum of four on-chain transactions over eight days: 1. To begin, users committed ETH to a Miso batch auction without knowing how many $DONA tokens they’d receive in exchange (depends on the final clearing price) 2. Once the auction was over, users had to claim their $DONA tokens 3. At this point, all users had either too few tokens to mint an NFT, just enough, or too many. Based on 1,363 minters who participated, we found 273 had too few, 0 had just enough, and 1,090 had too many (excess fractions of a token). 4. Users with too few tokens would have to transact to acquire the necessary surplus from Sushiswap. 5. Users with too many tokens had the option to approve the $DONA token for trading and then transact to sell their surplus via Sushiswap. 6. When users had enough $DONA to mint an NFT, they could approve the NFT contract to spend their $DONA, and then burn their $DONA to mint an NFT. 7. Finally, metadata would be assigned to NFTs in batches, with no way to reveal one’s NFT unilaterally. While this mechanism strived for fairness, it made user participation difficult and gas-inefficient. ### Exclusive minting One way that NFT collectors and enthusiasts assess the value of a collection is by the strength of its community. Commonly, this involves measuring the concentration of tokens among holders. Ideal collections tend to have low concentration, favoring individual participants over many whales. Among recent mints, though, there has been a new trend of introducing batch minting, where participants can mint more than one token, at once, in a single transaction. Via this mechanism, whale minters are incentivized with less gas overhead to mint many NFTs. An example of this in practice is the Stoner Cats drop, a collectible NFT mint to support producing animated shorts from Mila Kunis and friends that allowed minting up to 20 NFTs at once. Given this functionality, 89% of the NFTs were minted via the batch mint function, and nearly 31% of Stoner Cats were minted in batches of the maximum 20 NFTs. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--5e9ed34b8c/e798dc3807d8173a44cd525eac1c458b/asset-https-cdn-sanity-io-images-dgybcd83--5e9ed34b8c.png) Additionally, all NFTs sold with a fixed price implicitly prevent individuals from participating below the clearing price. This reduces the fairness in distribution, tipping the scales in favor of those with larger wallets, especially given how expensive minting can get. ### Trusted operators Whether implementing centralized raffling to prevent gas wars or Chainlink to improve fairness, a common trade-off is introducing trust assumptions in third parties. The more off-chain infrastructure an NFT mint must rely on, the more trust users must have in the centralized, off-chain entities. ## Goals of a good launch From looking at these launches and analyzing the problems people had with them in practice, we can now derive what we see as six desirable properties of an NFT launch. Our list has no ambition to be complete, but it‘s a start. **Unexploitable fairness:** Launches *must* have true randomness to ensure that predatory users cannot snipe the rarest items at the expense of less sophisticated users. **No race conditions:** Whenever an NFT (or any good, really) goes on sale below its fair market price, it turns into what Vitalik Buterin has called [auction-by-other-means](https://vitalik.ca/general/2021/08/22/prices.html). In practice, buyers race to get their transaction mined as fast as possible or attach large bribes to incentivize miners. Any auction-by-other-means favors people with deep knowledge about the blockchain and access to power tools like bots, private relays like Flashbots or Eden, or even direct-to-miner access. **Time-zone agnostic:** Commonly, FCFS launches are announced at a particular block height, and then sell out in a short period of time. No matter what block height is chosen, it will always disadvantage users of other time zones who are currently sleeping or at work. Therefore, launches shouldn’t be too short so people can participate without changing their daily routine. **Gas-efficiency:** Transacting on chain (especially on Ethereum) is expensive, and so a good launch should try to minimize the number of transactions that users have to make. **Inclusivity and sybil-resistance:** Often, it is in the best interest of an NFT creator to ensure the launch is open to a diverse base of holders, even if it causes the market to clear a bit lower initially. That is because a vibrant community is what ultimately drives the value of a collection in secondary markets. **Trustlessness:** Of course, all that said, the launch mechanism should work to preserve the properties of the underlying blockchain. That means it has to afford the aforementioned benefits *without* becoming custodial or requiring too many trust assumptions in the operator. ### Obscurity is no excuse for bad design Most launches have one or several of the aforementioned problems in theory, but in practice, there is insufficient demand for these problems to appear. This is an example of *security by obscurity*. For example, if a new collection has low perceived market value, there may be no race condition that leads to a bidding war in the mempool, no need to buy priority blockspace, and no incentive for predatory users to exploit it. Likewise, if a new collection has too much demand, then the collection might sell out so fast that there is no time to write custom software for it or exploit its fairness. While security from too little or too much demand is a thing, we posit that one should always design their launch to be robust across all market conditions, and especially not rely on collections selling out fast as a means of protecting them from exploitation. ## Unbundling NFT launches While we now know *what we want* in a good launch, we still don’t know *how to get there*. We can slowly reveal that path (or, as we will see, the many paths) by unbundling what actually happens under the hood. Every NFT launch consists, at its heart, of four steps: 1. **Bidding**: The sale goes live, and users submit their bids to the operator (can be a smart contract). 2. **Clearing**: The operator matches the collected bids against remaining supply, determines a clearing price, and selects winning bids. 3. **Distribution**: Winners can claim their newly-minted NFTs (or receive them from the operator). 4. **Metadata reveal**: The operator reveals the properties of the NFTs. Look at Loot, for example. Loot went live on block 13,108,877 in an FCFS sale. The collection’s creator [dom](https://twitter.com/dhof) set the sale price to zero in the smart contract, but users still had to bid with gas. Every block, miners cleared the new bids against the remaining supply, deciding who won and who didn’t. When a bid was successful, the user received the item in the same transaction. Most users learned the attributes of their item after they received it. However, in practice, a sophisticated user could have read the attributes of their item from the smart contract before minting, thereby allowing them to snipe the rarest items of the collection. This shows that whether the other steps happen sequentially or continuously, the metadata *must* be revealed only after the item has been bought and settled conclusively. Next, we will explore the options NFT developers have at each of the four steps. We discuss each choice’s effect on the desirable properties, filtering the good design choices from the bad. ### Phase 1: Bidding In this phase, the operator collects bids (i.e., purchase requests) from its users. #### Continuous vs. sequential clearing Before anything else, the operator has to decide whether they want bidding and clearing to happen continuously within the same or two non-overlapping phases. Any FCFS, fixed-price sale (which is most NFT launches to date) is an example of continuous clearing. Every block, miners look at the bids and clear them against the remaining supply. This mechanism has several problems: If the operator over-guesses the NFT’s clearing price, the items are too expensive and might not sell out. If the operator under-guesses the NFT’s clearing price, the items are too cheap, and users race each other with either speed (who has the most direct access to blockspace) or gas price (who can pay miners the most for their transaction). As discussed, this leads to massive dead-loss from failed transactions and greatly favors more skilled participants. If you must, the former can be mitigated by routing all user transactions to [Flashbots RPC](https://docs.flashbots.net/flashbots-protect/rpc/quick-start/) and letting the auction play out in an environment where failed transactions don’t have a cost. When going with the second option, bidding and clearing happen in two non-overlapping phases. In practice, the operator first collects all the bids and then matches them against the available supply, clearing the market at a fair price. This approach includes mechanisms like batched auctions or raffles. One example of this approach is [Jay Pegs Auto Mart](https://jaypegsautomart.com/), which gave users one week to submit their bids before clearing the market. The sequential approach has several benefits that are in line with our stated goals: 1. No race condition: Users have plenty of time to submit their bids, and the outcome is decided by how much users are willing to pay, not by how fast or skilled they are. 2. Timezone-agnostic: The approach respects people who work or live in other time zones. Furthermore, because there are no gas auctions, there are no negative externalities on other network users. However, this approach has downsides, such as requiring more on-chain transactions (depending on the design of the auction) or reducing the fun for participants who now have to wait longer. We recommend not letting the bidding period stretch too long to mitigate the latter concern, probably no longer than 48 hours. #### On-chain vs. off-chain bidding After deciding between continuous or sequential clearing, the next choice is whether users submit their bids on- or off-chain. As we will see, today’s launches often collect bids on-chain because it is easiest, effectively letting miners clear the winning bids and letting the rest fail. If we assume the network itself is uncensored, there is also the strong guarantee that no valid bid can be omitted from the sale. However, collecting bids off-chain is equally possible. In this process, users sign a message that contains information like their on-chain address, the number of tokens or tickets they want to buy, their maximum price, etc., with their private key. They send this message to the operator without executing it on-chain, using their signature to prove its validity. The operator can then use these bids to either clear the market off-chain or bundle the winning bids and submit them to the contract for execution on-chain. With either approach, some level of trust is necessary for the operator to execute the correct bids. This last approach combines off-chain bid collection with on-chain winner selection robust, gas-efficient, and flexible ways. The only thing users have to trust is that the operator does not omit any bids when submitting them on-chain—a relatively weak assumption to make. #### Who is allowed to bid The third decision to make is who is allowed to bid and how much. As discussed in the goal of *Inclusivity and Sybil resistance*, projects might want to ensure that a diverse set of users buys their items. To that matter, they may limit the number of items available to users with specific characteristics or reserve items specifically for holders of existing NFT communities. When the bidding happens off-chain, such KYC rules are easy to implement—you merely ask the user to prove certain information before letting them submit their signature to the server. On-chain KYC is more complex, but advances are being made by initiatives like Gitcoin’s privacy-preserving [Proof of Personhood](https://proofofpersonhood.com/#). Even if a project does not want any form of KYC, they can still take measures to ensure that one dollar buys the same amount of tokens for large and small users alike. This principle is often violated when contracts allow users to buy or claim many NFTs in the same transaction because whales get to amortize gas fees across more tokens, hence paying less per token than smaller users. To mitigate, capping the number of tokens per address or per transaction is usually a good idea. #### Bidding cost Further, the operator must decide when the user has to pay for the token—together with the bid, or after the market has cleared? In the latter case, the user merely *reserves* the token in the bidding phase, the market clears, and then they can complete the purchase within a certain time window. One project using this method, together with off-chain bidding, was [Parallel](https://parallel.life/). While it worked well in a quieter market, when demand is very high this model can turn into a race condition in which users want to reserve as many tokens as possible, given it is costless to do so. To mitigate the problem of race conditions, a cost should be associated with the bid itself. The best solution here is to let users submit bids only after locking funds in a smart contract from the same address. The operator can then decide whether to return the funds if the bid was unsuccessful (resembling a limit order on an exchange) or to keep the bid (resembling a raffle ticket that did not pay out). #### Granularity of bidding Finally, one must decide how much granularity they want users to express with their bids. When there are losing bids (because demand exceeds supply), one must further decide what it means to be a winner and a loser. Here are three viable options: **“Dumb” batched auction:** People commit an amount of ETH with no further instructions. In the clearing phase, the number of items is divided by the overall ETH committed, and everyone receives fractional tokens in the form of an ERC-20 that can later be redeemed for an ERC-721 NFT. Jay Pegs Auto Mart used this approach, and it has the benefit that there are no losing bids. However, it has the downside of requiring three extra on-chain transactions—two to sell or buy tokens to reach a useful amount (e.g., one “full” ERC-20) and one to redeem the NFT. Most importantly, this approach does not allow buyers to express the price at which they want certain quantities of tokens—a feature one has come to expect in almost every market. **“Smart” batched auction:** A similar but arguably better approach was used years earlier by [SpankChain](https://twitter.com/ameensol/status/1437474410659651586?s=20) for their ICO. Unlike Jay Peg, SpankChain collected bids that allowed specifying the quantity of tokens and price per token. After the bidding phase, they calculated a strike price off-chain and submitted it with the winning bids to a smart contract, allowing people to withdraw either SPANK if they won or their ETH if they didn’t. The downside of this approach is that the computational complexity of matching all the bids is so large that it can only be done off-chain, which requires some trust in the operator. **Raffle:** Finally, one can run a raffle or lottery in which users make bids by buying tickets or reservations. Winners are then randomly selected from the pool of all tickets. This way, users receive either a full token or none, saving the three extra transactions that Jay Peg’s $DONA needed. It is also inclusive of smaller wallets that might be unable to afford one full NFT. However, it introduces randomness into the sale, which some users may prefer and others not. ### Phase 2: Clearing In this phase, the operator (or someone on their behalf) matches the bids against the available supply, deciding who gets to buy an item and who doesn’t. #### On- vs. off-chain clearing The last major junction is who gets to select the winners from the pool of all bids. In the FCFS model, this is done by miners, which we showed is broken in several ways. In Jay Peg’s clearing mechanism, the computational complexity is just low enough to do it on-chain in a fully trustless way. In SpankChain’s model, winners are selected entirely off-chain. While bidders cannot get filled above their desired price (the smart contract ensures this), they still have to trust the operator to not push them to their maximum fill price, similar to how a sandwich attack on decentralized exchanges works. The raffle approach is the easiest to clear since all you need is a single random number (e.g., from Chainlink VRF). However, requiring randomness also introduces another trust assumption: whoever produces this randomness could favor their own bids over others. In contrast, this is not possible when the winning bids are simply the highest ones. ### Phase 3: Distribution After the market has cleared, the operator must mint the tokens, get them to the user, and return any losing bids if that was the model they went with. This step is generally all about gas efficiency and preventing race conditions. #### Instant vs. spaced settlement If the operator wants to prevent their users from claiming simultaneously, causing gas fees to spike, they can reuse the same randomness from the clearing process to let people claim in batches. This solves a collective action problem because users are better off not claiming all at the same time. Still, curiosity about learning about their metadata and being among the first to sell in the secondary markets might create a race condition anyway. That said, a spaced settlement also increases the waiting time for users. #### Claiming vs. receiving a token The only other thing to mention in distribution is whether users have to claim the token on their own or whether the operator can simply send it to them over time. The latter is a variation on the spaced settlement, but with the added benefit that users don’t need to do anything. The Parallel launch mentioned earlier used this method to good effect, simply requiring users to add a “delivery fee” when they initially paid for their NFTs. ### Phase 4: Metadata reveal Finally, once a token has been distributed, its metadata can be revealed. Of the four phases of NFT launches, this step *must* come last. It cannot be a shared last step either (e.g., by bundling payment, distribution, and reveal in the same transaction, as Meebit did) as fairness can be exploited by rerolling items with bad attributes through reverting transactions. There must be at least a one-block gap between payment and reveal to make rerolling impossible, although you may choose to increase this gap to protect against reorgs too. #### When to reveal the metadata We have now established that minting the NFT and revealing its metadata cannot happen within the same transaction, raising the question of when to reveal it instead. This is not just important for fairness, but user experience and gas efficiency play a role, too. In general, there are three options: **Full-collection reveal**: In a full collection reveal, the operator waits until all NFTs of the collection have been minted before revealing the metadata. This approach is highly gas efficient, requiring only a single random number that can then be used to shuffle metadata for ticket IDs with no further action from users. However, it has significant downsides. Namely, users have to wait until all NFTs have been minted to see metadata for their tokens. If one sets an upper bound on when to reveal the metadata (e.g., 24 hours), some users might still fail to mint in time, resulting in the collection not selling out. **Per-NFT reveal:** To improve the UX of the full-collection reveal, the operator can also allow users to reveal randomness on a per-NFT basis. This is more engaging as users can “open” their item shortly after purchasing it. It also allows “unopened” items to trade in secondary markets (which is popular in trading card games like MTG). However, this method comes with the burden of requiring users to make additional on-chain transactions, such as calling Chainlink VRF and applying a random number to their NFT. This is unavoidable even for users who don’t feel a particular urgency to reveal or who are not interested in trading unopened items. **Batched reveal:** As a potential middle-ground, we propose the concept of the batched reveal. In this method, users have an indefinite period of time to mint but can also reveal their item in the next block if they want to. Every new random number requested automatically reveals the metadata of all items minted and pending assignment, revealing them at virtually the same, constant cost. As a result, users with high time-preference have the optionality to pay for the extra on-chain transaction to reveal metadata, and this benefits all users before them. Should no user choose to reveal, the operator can also do it according to some schedule, e.g., every full hour. #### Source of Randomness After deciding when to reveal, the remaining question is where to get the randomness. The two options we suggest are using Chainlink VRF or a [commit-reveal scheme](https://en.wikipedia.org/wiki/Commitment_scheme). With the former, you can access a verifiable source of randomness on-chain, on-demand. Using any of the reveal mechanisms, you can call Chainlink to request randomness, and once fulfilled, use the randomly generated number as an input to your metadata calculation. This will ensure it is randomized for each NFT. With the latter, an operator can create one random number (for full-reveal) or several random numbers (for per-NFT or batched reveal) before the sale and pre-commit their hash. Once an NFT has been minted, the operator can reveal these numbers, allowing anyone to verify their authenticity through the hash. Still, this approach requires some trust in the operator to not exploit their privileged insight into the random numbers to mint the best NFTs. To minimize the need for trust, we recommend that some independent randomization in minting order still occur. Additionally, for off-chain metadata, instead of committing a random number, operators may instead choose to commit a hash of the complete metadata (id-to-attributes for all NFTs). This ensures that metadata is predetermined and not altered during or after the minting process. Still, independent randomization in minting order is necessary to prevent operators from exploiting their knowledge of order and attributes. ## Our reference implementation We have provided a [reference implementation](https://github.com/Anish-Agnihotri/MultiRaffle) that we consider a good balance between all properties and simple to understand and modulate. **Bidding**: In our implementation, users can bid by buying tickets to a raffle. The duration of the raffle is determined by the operator (we recommend 24-48h). The price per ticket consists of gas as well as the price per NFT, specified by the operator. The latter acts as a “security deposit” and is refunded on all losing tickets after clearing the market. Sybil resistance is created in three ways: the gas per transaction, the cost of capital on locked funds, and the maximum number of tickets per address. **Clearing**: Once the bidding period has concluded, a number of winners equal to the number of available NFTs must be drawn from the pool of all tickets. First, anyone can call \`collectEntropy()\` to get a random number from Chainlink VRF. This randomness is used in ‘shuffleEntries(),’ which implements a [Fisher-Yates Shuffle](https://en.wikipedia.org/wiki/Fisher%E2%80%93Yates_shuffle). Anyone can call this function, guaranteeing liveness and making the gas cost socializable (e.g., by whales). **Distribution**: After all the winners have been drawn, users have an indefinite period to claim an NFT from their winning tickets and get a refund on their losing tickets. Both happen within the same transaction. The operator can now start withdrawing the proceeds from winning tickets. **Metadata Reveal**: Users can reveal their NFTs metadata one block after they claim. Anyone can request a new random number that automatically reveals the metadata of all items that have been minted and are pending assignment. This allows users with a high time preference to pay to reveal immediately but benefit all users. ## Conclusion In this article, we have given real-world examples to show how poorly designed NFT launches can lead to suboptimal outcomes for users. But, when one clearly defines their goals and takes the time to deconstruct what steps a launch actually has, many designs become possible—and almost all are better than the fixed-price, first-come-first-served, network-congesting sales we are used to today. If you take nothing else away from this article, let it be these three rules: - **Unexploitable fairness is the most critical property of an NFT launch with random metadata.** Use robust randomness and never reveal the metadata of an NFT before it has been bought and settled. - **Race conditions hurt users, both those who participate in the mint and those who don’t.** Use sequential bidding and clearing (e.g., a raffle or a batched auction) to solve this problem. - **Consider cost-efficiency from minute one.** Ask if any step that currently happens on-chain could also happen off-chain to save money for your users. Off-chain steps can include bidding but also market clearing, assuming users can establish some degree of trust in the operator. Consider batching in the reveal phase. We would love to see NFT developers start experimenting with some of these ideas, leading to a better variety of launches in the wild. Finally, we want to shout out those who have been sharing their advice with the NFT community, helping improve the quality of launches: - [Vitalik](https://vitalik.ca/general/2021/08/22/prices.html)—for his explainer on the problems of FCFS fixed-price sales - [FairDrop](https://fairdrop.0xessential.com/)—for sharing their proof-of-concept design of fair raffles - [dotta](https://twitter.com/dotta/status/1420372022790483979)—for advice on building a robust frontend - [Jay Pegs Auto Mart](https://twitter.com/josephdelong/status/1437426536043454464?s=20) and [SpankChain](https://twitter.com/ameensol/status/1437474410659651586?s=20)—for demoing novel auction approaches - [Parallel](https://twitter.com/Jeremystormsky/status/1421915852727885825?s=20)—for showcasing best practices with off-chain raffling - [0xmons](https://twitter.com/0xmons/status/1409640045829447686?s=20)—for advice and tooling around designing fair launches Did we miss any other good threads, concepts, or launches? Please reach out to us on Twitter [@hasufl](https://twitter.com/hasufl) and [@_anishagnihotri](https://twitter.com/_anishagnihotri) so we can enhance this resource together. *Acknowledgments: Robert Miller (Flashbots), Dom Hofmann* ## https://www.paradigm.xyz/writing/ricks # RICKS > Introducing a new NFT fractionalization primitive: RICKS (Recurrently Issued Collectively Kept Shards) ## Introduction This paper introduces a new NFT fractionalization primitive: RICKS (Recurrently Issued Collectively Kept Shards). When you fractionalize an NFT into RICKS, the protocol mints new shards at a constant rate — say, 1% per day or 5% per month — and sells them. The proceeds are distributed to existing RICKS holders as staking rewards. This design solves the reconstitution problem, ensuring that RICKS can always be converted back to their underlying NFT, while avoiding the liquidity and coordination problems of all-or-nothing buyout auctions. ## Fractionalization Today ### The Reconstitution Problem Fractionalizing NFTs is hard because owning them can be an all-or-nothing proposition. If you want to sell 25% of a plate of eight cookies, you can sell two of the cookies. If you want to sell 25% of a business, you can sell the rights to 25% of its future cash flows. In either case, the 75% you have left is still useful to you. On the other hand, owning 75% of an in-game asset may not entitle you to use even part of that asset in a given game. If you sell 25% of such an asset to a buyer, and they refuse to sell it back, or even lose their private keys, you're in trouble. With no way to reconstitute the NFT, even if you nominally own 99.99% of it, that ownership could be worth nothing. As a result, fractionalization protocols must provide some way to reconstitute fractions back into the original NFT, a design constraint we refer to as *the reconstitution problem*. ### Buyout Auctions The most popular solution so far, pioneered by [fractional.art](http://fractional.art/), is the *buyout auction.* - **Situation:** Alice sells 25% of her NFT to Bob using a fractionalization protocol with a buyout auction mechanism. - **Buyout Auction:** A third party, Clara, could trigger a buyout auction for the fractionalized NFT at any time: whoever bids the most ETH (possibly Clara) receives the entire NFT, and the proceeds of the sale get split 75/25 between Alice and Bob. ### The Purpose of Buyout Auctions Buyout auctions exist to ensure that Alice's and Bob's fractions retain their fair market value by solving the reconstitution problem. To see why, imagine that Alice had fractionalized her NFT, representing an in-game asset, into 100 shards using a protocol that did not offer buyout auctions. Instead, only someone who owned all 100 shards could reconstitute the NFT. If someone accidentally burned one of the 100 shards, it would then become impossible for anybody to reconstitute the NFT, and the remaining shards would lose all of their value. Because of this risk, even at the time of fractionalization each of the 100 shards is worth well below 1/100 of the value of the NFT. With buyout auctions, losing one of the shards no longer destroys the value of the others. For example, if Alice lost one of her shards immediately after minting, she could initiate a buyout auction and submit the winning bid to get back the NFT, with 99% of the proceeds going to her. In this sense, buyout auctions are more of a necessary evil than a feature. They are certainly not for the benefit of potentially interested buyers like Clara, who are not stakeholders in the fractionalized NFT to begin with and therefore do not merit special consideration by the protocol. Buyout auctions are also not meant to *encourage* the reconstitution of the NFT. In order to solve the reconstitution problem, it must be somehow *possible* to reconstitute a fractionalized NFT, but Alice and Bob went to the trouble of fractionalizing their NFT in the first place and may be content to keep it fractionalized forever. ### Undesired Buyouts Unfortunately, buyouts can run into issues due to *capital constraints*: if an NFT is valuable enough, it's possible that nobody can round up enough money to pay a fair price for it once an auction is initiated. For example: - **Situation:** Alice has an NFT valued at 1,000 ETH. She fractionalizes it and sells 50% to Bob using a fractionalization protocol with a buyout auction mechanism. Suddenly, market conditions change and the fair value of the NFT jumps to 100,000 ETH. This is the value the NFT might fetch when sold under optimal conditions — say, at Christie's, after a long marketing campaign. - **Capital Constraints:** Finding a buyer willing to purchase the NFT at full valuation on short notice may be impossible. Perhaps the most the NFT could fetch at an on-chain auction within a week would be only 10,000 ETH. - **Shard Owner Disagreements:** 10,000 ETH is far below the NFT's fair value, and Alice would be strongly opposed to a sale at this price. Bob, on the other hand, does't have a strong feeling about the fair value and is willing to sell the NFT at a lower price that is still 10X from the price he originally purchased it for. That way, he can purchase other NFTs he likes more. - **Collector Opportunity:** Clara, a savvy collector, spots this opportunity and initiates a buyout for 10,000 ETH. Nobody, including Alice, is able to beat Clara's bid on short notice, and she wins possession of the NFT, which she then lists at Christie's and sells for 100,000 ETH a few months later. ### Reserve Prices To avoid situations like this, [fractional.art](http://fractional.art/) includes a [*reserve price*](https://medium.com/fractional-art/reserve-price-a-key-fractional-vault-property-to-understand-6dbaf476beb3) in its buyout auction mechanism, which specifies the minimum price at which a buyout can be initiated. In the above example, if the reserve price were set to 100,000 ETH, Clara wouldn't have been able to initiate an auction at 10,000 ETH. The difficulty comes when trying to set a reserve price. In the above example, Alice didn't want to sell the NFT for much less than its fair value of 100,000 ETH, but Bob didn't mind. Coming to agreement here can be quite difficult and contentious, especially as the parties involved may change as shards change hands. In practice, setting reserve prices requires active participation by shard owners. As a result, they are not updated frequently due to the attention demand on participants. Nobody has yet found a reserve price mechanism that solves the problem of undesired buyouts. ## Real-World Case Study: The Zombie Punk Buyout ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--5e5c604213/804fc9b305cf09be1a7d68502f42dfae/asset-https-cdn-sanity-io-images-dgybcd83--5e5c604213.png) [The Party of the Living Dead](https://www.partybid.app/party/0x2912F57F93dD69FBbF477B616D6f8C34C49bb282) was a group of NFT enthusiasts who joined up to bid on a rare Zombie [CryptoPunk](https://www.larvalabs.com/cryptopunks), which they collectively won for a price of 1,200 ETH. They then fractionalized it on [fractional.art](http://fractional.art/) and distributed its fractions to contributors in proportion to their contributions. At the time of initial fractionalization, five "whales" (owning 5% or more) collectively owned 56% of the NFT, while the remaining fractions were spread among 451 other participants. ### The Buyout Fractions of the Zombie traded on [Uniswap](https://info.uniswap.org/#/), where an anonymous collector realized they were underpriced relative to the value of other Zombie Punks. This collector bought enough fractions to increase their individual reserve price voting power, lowered the reserve price, and initiated a buyout auction. The buyout auction started at a price of 1,100 ETH, lower than the initial sale price to the Party, and ended up closing at 1,900 ETH. *NOTE: If you contributed to this PartyBid, make sure you collected your dead tokens* [*here*](https://www.partybid.app/party/0x2912F57F93dD69FBbF477B616D6f8C34C49bb282) *so that you can claim your portion of the final buyout price* [*here*](https://fractional.art/vaults/0x0C7060BF06a78AAAAB3fac76941318A52a3F4613)*.* ### Unhappy Owners Many of the non-whale owners were unhappy with the buyout, which they believed was at too low a price. Unfortunately, they found themselves essentially powerless to do anything about it. Individually, none of them could source enough liquidity to beat the bid and buy the NFT outright. Even if they had wanted to band together to buy the NFT as a single bidder, the coordination overhead and limited time available made that path unfeasible. ## RICKS ### Overview Recurrently Issued Collectively Kept Shards, or RICKS, solve the reconstitution problem while sidestepping the liquidity and coordination problems of a full buyout. Instead of one all-or-nothing buyout auction, the protocol issues new RICKS for a given NFT at a constant rate — for example, 1% per day, or 5% per month. These new RICKS are sold for ETH in an auction. The proceeds go to existing RICKS holders as staking rewards. As we will explain below, liquidity-constrained buyers who wish to increase their ownership can always trigger auctions for less than a full day's quantity of RICKS. This means that ownership of the NFT is always incrementally flowing to whoever is willing to pay the most for it, while existing owners benefit. RICKS allow a motivated buyer to obtain the extreme majority of ownership in an NFT over time. We finish solving the reconstitution problem by adding a mechanism for extreme majority owners to complete their ownership and reconstitute the NFT. ### Example - **Situation:** Alice sold 50% of her NFT to Bob using RICKS when it was worth 1,000 ETH. Now, market conditions have changed, and the NFT's fair value at an optimally executed sale is 100,000 ETH. However, it would be impossible to source that much liquidity for it on short notice. - **Shard Owner Disagreement:** A third party, Clara, would like to buy the whole NFT for 10,000 ETH. Bob is comfortable with this offer, but Alice is fiercely protective of her ownership and wants to sell for no less than the fair value. Alice and Bob both have 50 RICKS each, out of a total 100, and the issuance rate is 1%. - **Collector Opportunity:** Clara comes to the daily auction and bids at a valuation of 10,000 ETH. For 1% of the NFT, this comes out to 100 ETH total for one RICKS. - **Protecting Fair Valuation:** Alice, recognizing this bid is too low, bids at a valuation of 90,000 ETH, or 900 ETH for one RICKS. Since she owns half of the existing RICKS and will receive half of the proceeds of the auction, she only needs to put up 450 ETH to fund her bid. ### Potential Outcomes One of two things will happen: 1. If Clara does not outbid Alice, Alice will win the auction. She will pay 450 ETH to Bob and will receive one additional RICKS, so that she now owns 51/101 RICKS, or 50.5% of the supply. Alice and Bob have traded with one another at a price they both feel is advantageous. 2. If Clara does outbid Alice, say, by paying the fair price of 1,000 ETH, then Alice and Bob will receive 500 ETH each and Clara will receive one RICKS, so that she now owns 1/101 fractional shards, or just under 1%. Again, Alice, Bob, and Clara have all traded at prices they are happy with. Either way, if this activity persists over time, it will draw attention and buyer liquidity, improving the likelihood trades occur at a fair price for all parties involved. ### Completing the Buyout Let's say Clara is dedicated to owning the NFT and repeatedly bids for RICKS at a valuation of 100,000 ETH, a price nobody else is willing to match. Eventually, she owns 99% of the RICKS, perhaps after 458 days of winning the auction, since $0.99^{458}\\\\approx$$0.01$. She would now like to claim the NFT. To allow this, an additional mechanism will be needed in the protocol. One route would be to acknowledge that RICKS have some inner [Morty](https://www.paradigm.xyz/2021/09/martingale-shares/) and use a lottery. For example, if a majority owner controls 99% of the shards for an NFT, they could trigger a coin flip. If the coin comes up heads, they get the whole NFT (so they gain an additional 1%). If it comes up tails, the other owners have their positions doubled (so the majority owner loses 1%). This procedure is perfectly fair in the sense of [expected value](https://en.wikipedia.org/wiki/Expected_value). To avoid weirdness around the 99% boundary, we could allow a majority owner to trigger a coin flip at 98%, or 90%, or even 75%, with the caveat that they would receive worse odds the farther away they were from 99% ownership. ### Auction Details If the fractionalized NFT becomes expensive enough, even bidding for 1% of it might be prohibitively expensive for most. Furthermore, it is possible that, on some days, there will be no interest for an auction, so that holding an auction would be a waste of gas. As a result, instead of holding an auction every day, the RICKS protocol can implement an on-demand auction system: if it has been $t$ days since the last auction, and the issuance rate is $r$ per day, then the protocol would auction off $r^{min(t, 1)}-1$ shards. We take the minimum of the elapsed time and 1 day to avoid issuing too many RICKS all at once. For example, if the issuance rate were 1% per day, so that $r=1.01$, and it had been half a day since the last auction at the time a new one is triggered, then the protocol would issue and sell $1.01^{0.5}-1=0.498\\\\%$ of its supply as new RICKS. ## Peripheral Features ### Arbitrage Just like current fractionalized NFTs, we expect RICKS to trade on AMMs like [Uniswap](http://uniswap.info/). This provides a convenient arbitrage mechanism to ensure that RICKS auctions do not complete for too low of a price: if an auction's closing price is significantly below the RICKS price on Uniswap, an arbitrageur can profit by buying the RICKS in the auction and then immediately selling them on Uniswap. ### Auction Price Floors We could consider taking this logic a step farther and specifying that RICKS auction bids must be at a minimum of, say, 5% or 10% above the Uniswap TWAP price for those RICKS. Because a sufficiently motivated buyer would still be able to accumulate ownership of the NFT over a long-enough time frame, the reconstitution problem would still be solved. And, because the auctions would trade at a premium to Uniswap, they would likely cause minimal sell pressure. On the other hand, this modification would reduce the consistency of staking rewards for RICKS holders. It also makes reconstitution more difficult, and it is hard to tell what the market effects of that will be a priori. ### Fractional Launches RICKS offer a natural mechanism for launching new fractional shards of an NFT. Rather than having to provide shards on Uniswap and choosing a price, NFT owners can simply fractionalize using RICKS, start as 100% owners themselves, and let the automatic auctions take care of the rest. ### Claiming Auction Proceeds RICKS holders will need to stake their RICKS in order to claim auction proceeds. However, this poses challenges for composability. In particular, it is computationally infeasible to determine how many RICKS are held by each concentrated liquidity position on Uniswap V3 at all times, meaning auction proceeds cannot be given directly to Uniswap V3 liquidity providers. Instead, the RICKS protocol will keep track of the aggregate RICKS owned by all Uniswap V3 LPs, and will direct the auction proceeds due to all of them to liquidity mining rewards for the Uniswap V3 pool, as described [in this article](https://www.paradigm.xyz/2021/05/liquidity-mining-on-uniswap-v3/). In this way, market participants are incentivized to provide liquidity to the pool as efficiently as possible. There are other potential solutions to this problem, including (1) creating a wrapped RICKS token that holds both RICKS and ETH auction proceeds and (2) redirecting auction proceeds to buybacks of RICKS, but both have significant drawbacks. ## Next Steps We hope RICKS will make NFT fractionalization even more fun and useful. They also open up an entirely new design space. For example, we could let RICKS stakers automatically use their rewards to bid in future auctions. RICKS could also be pooled together into on-chain "councils" consisting of RICKS with similar attributes, like Zombie Punks or [Wizard Hat and Scarf Ocelots](https://www.paradigm.xyz/2021/09/martingale-shares/). If you're interested in exploring with us, we'd love to hear from you. You can find us [@__Dave__White__](https://twitter.com/_Dave__White_), [@andy8052](https://twitter.com/andy8052) and [@danrobinson](https://twitter.com/danrobinson). *Acknowledgments: *[*Shant*](https://twitter.com/smaroo?lang=en)*, *[*Crypto Samurai*](https://twitter.com/cryptosamurai?lang=en)*, *[*Arjun Balaji*](https://twitter.com/arjunblj)*, *[*Jim Prosser*](https://twitter.com/jimprosser)*, *[*Andrew Badr*](http://twitter.com/andrewbadr)*, *[*Gabriel Leydon*](https://twitter.com/gabrielleydon)*, *[*Hasu*](https://twitter.com/hasufl)*, *[*mewny*](https://twitter.com/mewn21)*, *[*Grug*](https://twitter.com/GrugCapital) ## https://www.paradigm.xyz/writing/martingale-shares # Martingale Shares > Introducing a new NFT primitive: Martingale shares, or "Mortys." Mortys are synthetics representing fractional ownership of classes of NFTs. ## Summary This paper introduces a new NFT primitive: Martingale shares, or "Mortys." Mortys are synthetics representing fractional ownership of classes of NFTs. They do not require buyouts or oracles, but instead rely on a random [Martingale](https://en.wikipedia.org/wiki/Martingale_(probability_theory)) settlement process. Mortys are highly speculative, and should be thought of as something between a protocol design and a thought experiment. ## Motivation ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--80e5ba37cb/3b33378014112d229b3455b5d43eb6ff/asset-https-cdn-sanity-io-images-dgybcd83--80e5ba37cb.png) Imagine Alice owns an Ocelot from the [Awful Hot Ocelots](https://www.paradigm.xyz/2021/08/floor-perps/) series. When she bought this Ocelot, it wasn't worth much. However, the project has taken off since then, and she would like to get some liquidity and reduce her price exposure. She doesn't want to sell her Ocelot outright, as she is using it as her profile picture on Twitter and is otherwise very attached to it. Ideally, she would like to sell 50% of it. ### The Challenge of Fractionalization If she wanted to sell 50% of a plate of cookies, she could just sell half of them. If she wanted to sell 50% of a business, she could sell shares representing the right to receive 50% of the cashflows it generated. Her Ocelot, however, is not naturally divisible, and does not generate any cashflows. How can it be divided in a way that makes economic sense? ### fractional [fractional.art](http://fractional.art/) would let Alice fractionalize her Ocelot by selling tokens good for a 50% cut of the proceeds from its eventual future sale. This means fractional has to ensure this future sale will be fair and will actually happen. As a result, the protocol implements a *buyout* mechanism enabling interested buyers to start an auction on the Ocelot at any time. This works very well for notable and unique NFTs that have a lot of market interest. However, for more run-of-the-mill NFTs, like Alice's Ocelot, the situation is a little tougher. Fractional shares of her Ocelot would be a brand new token, and Alice would have to spin up a new market for them somewhere like Uniswap. Because many Ocelots have already been fractionalized, she suspects it will be hard to attract enough attention to sell her shares at a reasonable price. Similarly, if someone initiates a buyout auction for her Ocelot later, it might not attract that much attention or liquidity, potentially leading to a sale at an unfavorable price for Alice. ### Floor Perps Alice could also use her Ocelot to mint some [floor perps](https://www.paradigm.xyz/2021/08/floor-perps/), synthetics that track the floor price of Ocelots using a funding rate mechanism and an oracle for the floor price. However, her Ocelot is worth significantly more than the floor because it has the comparatively sought-after Wizard Hat attribute. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--261c365ae6/4f2d79c3fc618fbe2f2cb7b37b0c7b30/asset-https-cdn-sanity-io-images-dgybcd83--261c365ae6.png) She could theoretically create a floor perp tracking the floor price of just Wizard Hat Ocelots, but that would require defining an oracle for the Wizard Hat Ocelot floor. Because there are just 200 Wizard Hat Ocelots, any such oracle would likely be inaccurate and subject to manipulation. ## Lottery Fractionalization In a recent [blog post](https://vitalik.ca/general/2021/08/22/prices.html), [Vitalik Buterin](https://twitter.com/VitalikButerin) offers one possible solution: Alice can sell fractions in the form of lottery tickets. For example, imagine Alice's Ocelot is worth 10 ETH. If she sold half of her Ocelot to Bob as a lottery ticket, he would give her 5 ETH and she would give him a 50% chance to win the Ocelot by flipping a coin. If it came up heads, Alice would get the Ocelot back. If it came up tails, Bob would get the Ocelot. Similarly, if Alice sold 10% of her Ocelot to Bob, he could give her 1 ETH and they could roll a 10-sided die. If it came up 1, Bob would get the Ocelot, and if it came up 2 through 9, Alice would get it. The advantage of this arrangement is that it is completely and totally fair: the amount of ETH Bob pays is exactly equal to the [expected value](https://en.wikipedia.org/wiki/Expected_value) of the lottery ticket he receives. There are no messy liquidity dynamics around potential buyouts, and there is no concern about oracle price validity. If Bob buys 10% of the Ocelot, he has a 10% chance of getting the Ocelot, period. However, Alice may still not be too comfortable with this deal. After all, she likes her Ocelot for more than its cash value. Here, she has a 10% chance of immediately losing it. Furthermore, lottery fractionalization does nothing to help Alice find liquidity or a fair price. In this example, we assumed Alice and Bob both agreed that her Ocelot was worth 10 ETH. In real life, this is unlikely to be true, and Alice may either have to hold an auction or negotiate with Bob privately in order to set a price. ## Martingale Fractionalization *Martingale Fractionalization* addresses these issues while keeping the perfect mathematical fairness of lottery fractionalization. Like lottery fractionalization, Martingale fractionalization depends on randomness to settle ownership: Alice sells 50% of her Ocelot in the form of *Martingale Shares*, or Mortys. Over time, her remaining ownership will shrink and grow at random in a process known as a [Martingale](https://en.wikipedia.org/wiki/Martingale_(probability_theory)), meaning it is fair at every step. The process ends when her ownership has either dropped to 0% or returned to 100%. Because this settlement takes place over time, these shares can be traded on markets like Uniswap, facilitating liquidity and price discovery. At any time, Alice may replace the Ocelot she used as collateral with any other Wizard Hat Ocelot. This means that Mortys do not represent fractions of her particular Ocelot, but rather fractions of the *cheapest to deliver*, or floor, Ocelot of their class. This feature, along with Alice's ability to buy back Wizard Hat Ocelot Mortys on the open market, allows Alice to recover her Ocelot if luck turns against her. ### Opening a Vault Alice opens up a new Wizard Hat Ocelot *vault* with her Wizard Hat Ocelot as collateral. This vault starts with a balance of 100 Wizard Hat Ocelot Martingale Shares (or Wizard Hat Ocelot Mortys). As mentioned, Alice may replace the Wizard Hat Ocelot she is using as collateral with any other Wizard Hat Ocelot at any time. ### Morty Classes Alice's vault and Mortys are of the Wizard Hat Ocelot *class*, meaning they can be created only with Wizard Hat Ocelots. All Mortys of a given class are fungible. This is analogous to the situation in Maker, where all DAI is fungible even though it has been created by different people in different vaults with different collateral. Alice could have chosen a class with stricter requirements, such as Ocelots with both a Wizard Hat and a Scarf. Or, she could have chosen a class with looser requirements, such as the floor Ocelot class, which could be created with any Ocelot at all. More complex classes are possible, such as a class of Mortys that can be minted with either one Ocelot or two Armadillos, NFTs from an entirely different project. In this case, she chose to mint Wizard Hat Ocelot Mortys because they had the best combination of price and existing liquidity on Uniswap. ### Martingale Settlement Now that Alice's vault balance is no longer at 100, the process of *Martingale Settlement* begins. Every night at midnight, the Morty protocol flips one coin per vault. If the coin comes up heads, Alice gives one of her Mortys to the buy pool. If it comes up tails, the buy pool gives one of its Mortys to Alice. So, after the first flip, either Alice will have 51 Mortys and the buy pool will have 49, or Alice will have 49 Mortys and the buy pool will have 51. This process repeats every day until Alice has either 0 Mortys or 100 Mortys. If she has 0 Mortys, she gives whatever Ocelot is currently in her vault to the buy pool. If she has 100 Mortys, she gets her Ocelot back. Either way, the process ends. ### Martingale Math Because each coin flip is fair, the process is known as a _[Martingale](https://en.wikipedia.org/wiki/Martingale_(probability*theory))\*, meaning that Alice's expected Morty balance never changes. This means that if Alice has *n* Mortys on a given day, and does nothing, she has an *n%* chance of getting her Ocelot back (see [here](https://randomdeterminism.wordpress.com/2010/07/09/gamblers-ruin-2/) for a proof). In other words, by selling 50 Mortys to the buy pool, Alice really was selling 50% of her Ocelot. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--0c2025497e/7a8997d97782b920a5e1fd6e43ee8b7b/asset-https-cdn-sanity-io-images-dgybcd83--0c2025497e.png) *See: https://colab.research.google.com/drive/1tMq0Cqa5o3T-da9m0WdBqou2CJ7QMChQ?usp=sharing* ### Seller NFT Recovery Alice has two different ways of recovering her Ocelot if luck turns against her. The first way is to replace the Ocelot in her vault with another one she values less. The second way is to mint new Wizard Hat Ocelot Mortys, or buy them on the open market, and use them to increase her vault balance, possibly all the way to 100. ### Buy Pool Settlement If a vault's balance reaches 0, ownership of whatever Ocelot is inside it reverts to the buy pool, at which point many different design choices are possible. As an example, the Ocelot might go into an NFTX-style vault where it can be redeemed by anyone for the cost of 100 Mortys, plus a fee to incentivize pool liquidity. Viewed this way, Mortys can be seen as a potential extension to protocols like NFTX. ## Incentives ### Vault Owner Incentives When Alice chooses to mint and sell Mortys using her Ocelot, she takes on the risk of losing it. Why would she ever do this? First, assuming the existence of an active market, she is able to quickly get liquidity at a fair price. Second, there is likely to be significant demand for long exposure to classes of NFTs like Wizard Hat Ocelots, especially from people who cannot afford to buy an entire Wizard Hat Ocelot themselves. Because Alice is servicing this demand, and taking on risk in doing so, she may be compensated in the form of higher prices than she could get by selling her Ocelot outright. Third, although Alice is now exposed to Martingale risk, she has laid off a good chunk of her Wizard Hat Ocelot floor price risk. Depending on the volatility of Ocelot prices, her overall risk may be significantly decreased. ### Vault Incentivization The existence of liquid Morty markets could be very useful for the ecosystems of their parent NFTs. For example, Morty prices could serve as indices for [floor perps](https://www.paradigm.xyz/2021/08/floor-perps/). Given the important role of vault owners, it might make sense to directly incentivize them. For example, a floor perp protocol might divert some of its profits to compensating Morty vault owners who use their shares to LP in the Morty market on Uniswap. ### Bad Faith Recovery The purpose of Martingale settlement is to ensure that Morty buyers have a probabilistic claim to receive NFTs. However, there is a potential attack vector that could stop this from happening. If Alice has opened 50 different vaults, on average she will lose 25 Mortys and gain 25 Mortys every flip. By moving these Mortys around between her vaults, she can stabilize their balances for a long time. In the event that this behavior becomes widespread, and has a negative impact on the perceived value or utility of Mortys, a Morty protocol could charge vault owners a fee when they add Mortys to their vaults and forward the revenue to the buy pool. An even simpler solution would be to turn off the ability to add Mortys back to a vault, since the ability to swap collateral still allows vault owners to rescue NFTs they do not want to lose. ## Buy Pool Risk Alice's risk in this system is relatively easy to understand: if her vault balance is 50 Mortys and she does nothing, she has a 50/50 chance of losing her Ocelot. The situation for buyers is a bit more complicated. ### More Vaults However, as there are more and more vaults, Bob's and Charlie's comparative risks start shrinking. Let's say there are $n$ vaults, each short an average of 50 shares, so that the buy pool consists of $50n$ Mortys. The number of flips won by the shorts every turn forms a binomial distribution with variance $\\frac{n}{4}$. If Bob and Charlie still own only 10 shares each, or $\\frac{1}{5n}$ of the total, their own variance will be $\\frac{1}{20n}$ per flip, which shrinks quickly as $n$ grows. ### Auto-Canceling Flips If there are at least two vaults, we can eliminate long variance entirely. Imagine there is an even number of vaults, say, 4. In that case, we can pair them off at random and only flip one coin per pair, such that a flip of "heads" in the first member of the pair is automatically translated into a flip of "tails" in the second member. Note that while we are reducing the number of bits of randomness in the system, each individual vault still experiences a Martingale. In this way, even though individual vault balances will change from flip to flip, the number of outstanding long Mortys will never change. We can use this method even if there is an odd number of short vaults, simply by choosing one vault at random to exclude from the current round of flips. ## Alternative Martingales We can also change the random process used for settlement as long as it is still a Martingale. The coin-flipping process described above, for example, can take quite a while to finish. What if we designed a process guaranteed to end in a fixed amount of time? Let's say Alice's vault is short $n$ Mortys on a given time step (meaning its balance is 100-$n$). Our alternative Martingale system randomly decides between giving her back all *n* Mortys and letting her walk away with her NFT, or adding one additional Morty to her short position. In order to be a Martingale, she must have a $\\frac{1}{n+1}$ chance of getting back $n$ Mortys and a chance of $\\frac{n}{n+1}$ becoming short one additional Morty. For example, if Alice has just minted and sold 2 Mortys, so that she has a balance of 98 Mortys, she would have a $\\frac{1}{3}$ chance of gaining 2 Mortys, for a total balance of 100, and a $\\frac{2}{3}$ chance of losing a Morty, for a total balance of 97. Her expected gain is $\\frac{1}{3}\\cdot 2-\\frac{2}{3}\\cdot 1=0$, as is required for the process to be a Martingale. At every time step, Alice either gets her short closed out and can recover her NFT, or gets her short position increased by one Morty. Unless she buys or mints more Mortys and adds them to her vault, the process will always end within 100 time steps. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--35cfff13db/cfd5996bc150cd4ff8a53c1be97338ff/asset-https-cdn-sanity-io-images-dgybcd83--35cfff13db.png) ## Conclusion Mortys are a strange but mathematically pure way to create fractional exposure to classes of NFTs. It is unclear how much market demand for them there may be, but they are certainly fun to think about. If they have captured your imagination, I would love to hear from you. You can email me at [dave@paradigm.xyz](mailto:dave@paradigm.xyz), or tag [@](https://twitter.com/_Dave__White_)[*Dave__White*](https://twitter.com/_Dave__White_) on Twitter. *Acknowledgments: *[*Dan Robinson*](https://twitter.com/danrobinson)*, *[*Kevin Pang*](https://twitter.com/kevinxpang)*, *[*Matt Huang*](https://twitter.com/matthuang)*, *[*Jim Prosser*](https://twitter.com/jimprosser)*, *[*Grug*](https://twitter.com/GrugCapital)*, *[*andy8052*](https://twitter.com/andy8052)*, *[*Doug Colkitt*](https://twitter.com/0xdoug)*, *[*CL*](https://twitter.com/CL207)*, *[*Mewny*](https://twitter.com/mewn21)*, *[*Andrew Badr*](http://twitter.com/andrewbadr)*, *[*Sunny Aggarwal*](https://twitter.com/sunnya97)*, *[*lsf*](https://twitter.com/lightspringfox)*, *[*Anna Carroll*](https://twitter.com/annascarroll)*, *[*Allan Niemerg*](https://twitter.com/niemerg)*, *[*0xmons*](https://twitter.com/0xmons)*, *[*Big Magic*](https://twitter.com/bigmagicdao)*, *[*miyuki*](https://twitter.com/miyuki_crypto)*, *[*ayko2718*](https://twitter.com/ayko2718)*, *[*Kamil Sadik*](https://twitter.com/kamilsadik)*, *[*nnnnicholas*](https://twitter.com/nnnnicholas)*, *[*KND*](https://twitter.com/kaosneverdied) ## https://www.paradigm.xyz/writing/the-community-garden-the-case-for-leaving-faang-companies-for-crypto # The Community Garden: The Case for Leaving FAANG Companies for Crypto > This piece discusses reasons individuals might leave FAANG companies for crypto. Software engineering culture has always leaned toward anti-authoritarianism. Many an engineer’s childhood reading list was full of books like [Snow Crash](https://en.wikipedia.org/wiki/Snow_Crash) and [Neuromancer](https://en.wikipedia.org/wiki/Neuromancer) about lone hackers fighting back against enormous corporations, and the mythos of the underdog startup founder is practically a local religion in Silicon Valley. This is with good reason; more than almost any other profession, software engineering can concentrate a huge amount of economic power in a small group of people fighting an incumbent. As an engineer at a FAANG company (Facebook, Amazon, Apple, Netflix, and Google), you work with extremely smart people on challenging, highly visible problems… but you also ship things on long time cycles, your impact on the product you’re building may be negligible, nothing you’ll work on is *truly* yours, and your projects are likely influenced by executive power struggles outside your department. That’s setting aside all of the ethical quandaries related to privacy, security, and ownership that are inherent to those companies and grating to anyone who self-identifies as anti-authoritarian on any level. So why do so many great engineers keep choosing to take jobs at the FAANGs? I can help explain because [I spent seven years convincing engineers to join Google](https://www.linkedin.com/in/dmccarthy7/). There are four major explanations. I can hear you yelling about the first one from here: 1. Compensation: Duh. 2. A lack of ideologically attractive alternatives: despite the incompatibility between FAANG companies’ business models and traditional engineering values like transparency and privacy, it’s proven difficult to run a lucrative software company at scale without also being secretive and invasive. 3. Cutting-edge research: The coolest, newest engineering projects still mostly take place within the FAANGs. 4. Immigration status: The FAANGs represent a low-risk path to American citizenship within a visa system that favors large, established companies. These are powerful arguments to join a FAANG. However, engineers’ decision-making calculus in this area is evolving dramatically, primarily because of one technology: crypto. Some of this shift relates to the alignment between traditional software engineering values and the culture of crypto projects (open-source ethos, privacy consciousness, and cross-company collaboration), and some of it relates to crypto technologies’ practical impact on the way smaller companies and projects can make money and compensate their employees. I’ll dive into how all of the FAANGs’ advantages are changing below, but the upshot is that a side effect of crypto technologies’ entry into the mainstream will be a significant decentralization of the engineering talent market. If you’re at a FAANG today and you’re working on making an application 0.5% faster or more scalable, the cost-benefit calculus of leaving to join a crypto startup has, and will likely continue to, become a lot more attractive. ### REASON 1: The existing equity compensation model drives people away from startups. Token-based compensation gives startups an additional tool to create incentive alignment with their employees, which can meaningfully change candidates’ risk/reward calculus when they’re considering joining a small company. Crypto companies have been the first to adopt this model. FAANG companies offer top-of-market compensation packages, and in geographies like the Bay Area where the cost of housing is astronomical, it’s totally rational to optimize for a 90th-percentile base salary and an equity stake that offers high predictability. In contrast, the value of startup equity has historically been extraordinarily volatile: it’s either worthless or extremely lucrative, with few outcomes in between. Even in the event a startup becomes successful, it can take a decade for stock options to reach liquidity, and many moderately profitable startups choose to stay private, leaving their early employees with little to show for it asset-wise but a deep wardrobe of logo T-shirts. If you’re a senior engineer considering a startup offer against a FAANG company, you have to factor in that time and uncertainty. Every person’s appetite for risk is different, but the upshot is that in order to be confident that a startup equity package will deliver FAANG-competitive compensation over any time period, you’ll need to believe that: - The startup will be successful as an independent public company or be acquired by another successful public company for a meaningful sum; - That outcome will translate into liquidity for you; *and* - When that happens, your windfall will be so large it’ll counterbalance not only the original deferred FAANG compensation, but also the opportunity cost of lost interest (e.g. how you could have used the excess liquid funds). The vast majority of startups can’t reasonably meet this threshold, particularly for senior engineers. When factoring in the timeline to reach liquidity, the risk/reward proposition that stock-based startup equity compensation offers is sufficiently extreme that most people who have mortgages and families can’t stomach it. Replacing stock-based equity with equity in the form of cryptographically generated tokens solves this problem. In a token-based vesting model, employees accrue an ownership stake in the company over time just like stock options, with the critical differences being that tokens: - Require no exercise cost (in comparison to typical startup equity, which can lock employees into “golden handcuffs” situations where they have to come up with tens of thousands of dollars to exercise options); - Are directly tied to the value of the company’s technology product, rather than being subject to the financing and capital structure of the business; - Are governed by a transparent, immutable smart contract; - Can be liquid from the moment they vest; and - Retain that liquidity continuously over time. This is hugely advantageous for employees. Tokens don’t guarantee a short-term payout, but they preserve employees’ optionality to get *some* cash out of their equity on a shorter time cycle while hanging onto the possibility of a lucrative exit down the road. It’s worth noting here that the complexity and inefficiency of the stock equity model isn’t entirely bad for startups. Denying employees liquidity provides an advantage to founders and investors who need workers but can’t pay them market value up front for their services. Of course, employees can sometimes sell their illiquid equity on secondary markets - but that typically requires company and investor permission, which (surprise) they usually refuse to grant. So why would startups switch to token-based equity? The short answer is that token-based equity is so much simpler than stock-based equity that over time, employee preferences will force startups to shift. When equity is governed by smart contracts, employees can be confident that they’re making informed decisions, which is not at all the case with stock option agreements. Most crypto organizations use standard, open-source vesting contracts that unlock tokens programmatically, allowing employees to understand precisely what they’re getting and when they’re getting it. This is a stark contrast to stock option models, where employees are usually given a lengthy document written by company attorneys, advised to consult an attorney of their own, and told to hope for the best. I believe most startups will eventually tokenize their equity, but crypto startups have already started to make that leap. A high-performing 25-person crypto company can now credibly claim that the compensation packages they’re offering are breaking even against Google in terms of value and liquidity after one year instead of seven or eight because they include a token component. As more startups follow suit, the risk/reward calculus of joining a startup will look very different. ### REASON 2: All our content is controlled by a handful of platform companies, which exert enormous control over what reaches eyeballs and rely on invasive tracking of user behavior to make money. Most engineers share ideological values that aren’t compatible with this model, but there hasn’t been a viable alternative for some time. Crypto can help facilitate a return to the decentralized, open web. The web sucks now. Virtually all our public discourse goes through a few products, which are subject to abstruse Terms of Service agreements and the resultant wars over who can whine loudest about being deplatformed. The original promise of the Internet, going back to the Usenet days, was the idea that people around the world could build independent communities focused on niche interests (minor league baseball, Command & Conquer games, kettlebell workouts) and share content without having to depend on central authorities for distribution and moderation. That idea is more or less dead. Communities based around specific interests still exist online, but at this point they mostly live within places like Facebook, which is less interested in improving your overhead press form and more interested in selling you workout equipment through a retargeted ad based on your browsing behavior. It’s worth considering why this centralization happened: - The only way to effectively monetize content creation on the Internet has been through ads; and - The economics of advertising only work at enormous scale and with significant compromises around privacy, making only sites like Facebook viable. People who want to work on big, difficult problems but also care about privacy and transparency are in a bind. As an engineer who recently left Google for a crypto startup told me: *We were doing some interesting technical work, but a lot of the hard problems came down to the scale of the data that was being aggregated or the number of people that had to coordinate to get something done, and a lot of the time was just spent learning proprietary technology or domain knowledge. The work either didn't feel novel (migrating some project from framework 1 to framework 2) or it was advancing a mission I didn't care about (enhancing the privacy of an advertising platform in some incremental way).* The standard startup criticism of working at Google or Facebook is that you’ll spend months working on the shading for a button. That may be true, but *a lot of people will use that button* - so many people, in fact, that you can virtually guarantee that it will be the most important product you’ll work on in your entire career. Imagining a model that competes effectively with this status quo is tough. How is it possible to build a large, highly visible enterprise that's simultaneously decentralized, transparent, and open? The alternative offered by crypto's on-chain governance systems is the **decentralized autonomous organization**, or DAO. DAOs are transparent, programmatically governed decision-making structures that coordinate large numbers of people. There are already several examples of DAOs solving hard coordination problems within finance ([Compound](https://compound.finance/), [Synthetix](https://www.synthetix.io/), and [Uniswap](https://uniswap.org/)), but the DAO concept is extensible to many other applications - including community management. A DAO is often the end state of a crypto startup. Crypto companies' growth plans during their early stages are fairly traditional (raising VC money, finding product-market fit, and scaling a team). However, their long-term plans often include a transition into a fully dissolved, community-owned protocol. Working for a DAO or protocol, or a company that plans to become one, will ultimately offer much of the same value as a large company: meaningful financial rewards on day one, equity in the project’s success, and the opportunity to work on hard problems with smart coworkers. The major difference between a DAO and a traditional private company is that the DAO’s ability to drift toward an ideological stance that its members oppose will be much more tightly constrained because the DAO is programmatically bound to decide certain things democratically. As companies run by transparent rule sets become larger and more user-friendly, they’ll be able to offer engineers work that's both visible and aligned with the values they believe in, with the extended possibility of creating communities that don’t have to answer messy ethical questions to scale. As a competitor to the “inject ads into a huge distribution platform for other people’s content” model emerges, big companies will have to return to their business model from the mid-to-late 2000s: making things people want. ### REASON 3: Engineers want to work on groundbreaking technologies with the potential for real-world impact. Over the past decade the most cutting-edge research has taken place in secretive labs within the FAANG companies… except within crypto, where research is built on open-source principles and public experimentation. For the purposes of this section, I’ll define impact as “the ability of one person to influence the direction of a project or technology.” While startups spend a lot of energy selling engineers on their ability to generate impact, a lot of the most cutting-edge research still happens within the FAANGs. Engineers generally want to work on the coolest, newest thing, even in a limited capacity. Over the past decade the FAANGs have done an excellent job of bringing new research related to, for example, virtual reality and self-driving under their respective umbrellas. This keeps their brightest people working in-house, even if they’re just applying more general engineering skills to experimental products, like doing infrastructure engineering work for Google Brain. Google in particular is extremely good at identifying a technology that’s about to tip into mainstream relevance, finding the ten best people in the world in that field, and giving them all the resources they need to attack a problem, even if Google wasn’t the first mover in the space. Conversely, research in crypto is largely done in [public forums](https://ethresear.ch/), and is often published in [blog posts](https://vitalik.ca/general/2019/11/22/progress.html) and [open access papers](https://arxiv.org/search/?query=decentralized+finance&searchtype=all&abstracts=show&order=&size=50). That openness creates tighter feedback loops. The foundational knowledge necessary to push the technology forward is available to anyone with an Internet connection, as opposed to being warehoused in a sealed-off building with its own cafeteria that nobody else within the company is allowed to use. For engineers looking to optimize their career moves for impact, crypto is much more accessible than other extensions of software engineering, and it’s less likely to be locked down by large companies. The pace at which crypto is developing also means that nobody’s an expert forever, which favors newcomers - six months of work will likely put someone in the top 1% of expertise in a given sub-discipline. As crypto projects become increasingly mainstream, the population of world-class engineers in the field will grow exponentially and the pace of innovation in crypto will fly past projects that are confined within closed shops. ### REASON 4: The FAANGs have historically enjoyed a built-in advantage with any candidates who need visa sponsorship to work in the US. This will continue to be a major challenge for all startups, crypto and otherwise, but in 2021, residence in the US is less important than ever before. The immigration issue is worth an entire post on its own, but here’s a quick summary: large numbers of highly talented people want to work in America (and stay here in the long term), and it’s in everyone’s best interest to get them here. However, once they arrive, their immigration status effectively locks them to enormous companies. China and India are the two largest sources of foreign technical talent, and the vast majority of engineers from those two countries are here on H-1B visas. Given the ridiculous backlog in the visa system, H-1B holders often have to wait five years or more for a green card... and that’s if their employers began the complex and expensive application process the day they joined the company. The final phase of the green card process by itself can also drag on for a year or more, and changing jobs during that phase can cause it to restart entirely. All this red tape creates powerful economies of scale that favor large companies with respect to visa applications. The FAANG companies have in-house lobbying arms and legal functions with expertise in immigration law, which allow them to make credible arguments to employees that staying put will guarantee their path to citizenship. Meanwhile, at a 20-person startup (crypto or otherwise), preparing an airtight visa application is often one of 30 responsibilities on an overstretched head of operations’ plate. The distributed nature of crypto projects and the rise of remote work during the ongoing pandemic have made physically being in the US less critical to career growth. Still, great engineers want to come to the US, and they want certainty that they’ll be able to stay. As long as that’s the case - and as long as the visa process is a bureaucratic nightmare - the FAANGs will have a major recruiting advantage among immigrants. **WHAT’S NEXT** For the past few months, the narrative surrounding crypto’s future has been expansive, to say the least. A growing number of people believe that blockchain-based technologies will rapidly replace portions of the existing financial system and many application platforms. That said, anyone telling you what crypto is going to do in the future with absolute certainty is lying. As with the internet in the 1990s, we’re still figuring out which applications of blockchain technology will work, and there are bound to be [false starts](https://en.wikipedia.org/wiki/Pets.com) that look ridiculous in retrospect. The highest-confidence conclusion we can draw at this point is that crypto is a lever that pushes toward decentralization. The most concrete evidence for that theory is that unlike many recent technical sea changes, this one is bottom-up: despite the limited number of crypto startups in Silicon Valley and the near-total absence of crypto projects within the FAANG companies, [more than 8% of Americans already own cryptocurrency](https://www.coininsider.com/survey-8-percent-of-americans-want-to-buy-cryptocurrency/). To jump from a FAANG to a crypto startup, you don’t necessarily have to be a crypto maximalist - you just have to believe that the landscape will shift enough for 2% of the FAANG talent base to join you. As has always been the case in Silicon Valley, when the right technology arrives, [a handful of smart people is more than enough.](https://en.wikipedia.org/wiki/Traitorous_eight) If you're looking for a new role in crypto/Web3, we'd love to help you find it: [talent.paradigm.xyz](https://talent.paradigm.xyz/) ## https://www.paradigm.xyz/writing/floor-perps # Floor Perps > Introducing the floor perpetual: a synthetic NFT that tracks the floor price of a given project and can be minted by locking up NFTs from that project. ## Overview This paper introduces the *floor perpetual*, a synthetic NFT that tracks the floor price of a given project and can be minted by locking up NFTs from that project. Floor perpetuals give NFT holders access to liquidity and protection against fluctuations in the floor price without requiring them to give up ownership of their NFTs. As full-fledged perpetual futures (see [The Cartoon Guide to Perps](https://research.paradigm.xyz/cartoon-guide-to-perps)), floor perps also provide other market participants with leveraged long and short exposure to NFT floor prices. ## Motivation ### The Problem ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--64eb10dc80/27033503a3671b7a752c6f964892ba87/asset-https-cdn-sanity-io-images-dgybcd83--64eb10dc80.png) *Ocelots by Chelsea Myers: https://twitter.com/tinyatticart* Imagine you own ten Ocelots from the extremely popular *Awful Hot Ocelots* project (which I just made up). You picked your Ocelots because you recognized in them certain aesthetic qualities not present in the other Ocelots in the project. While your Ocelots have all historically traded close to the project's minimum price, or floor, you believe their value will appreciate relative to the floor over time. Recently, the floor price has risen dramatically, and your Ocelots represent the majority of your net worth. You love them and absolutely do not want to sell them, but would like some liquidity and protection against future declines in the floor price. If you held just one extremely rare Ocelot, you could fractionalize it on [fractional.art](https://fractional.art/). But your Ocelots are not yet recognized to be that special, and you suspect you would have a hard time sourcing liquidity if you were to try to fractionalize all ten of them and sell shares of each. Besides, you believe your Ocelots are underpriced relative to the floor, and do not want to give up any of their relative upside by selling even a fraction of them. ### The Solution You decide to use your Ocelots as collateral to create and sell OCELOT floor perps. For example, let's say the Ocelot floor is currently at 20 ETH, and your Ocelots are worth an average of 25 ETH each, for a total portfolio value of 10 \* 25 = 250 ETH. You open up your web browser and navigate to a floor perp marketplace, where you lock your ten Ocelots as collateral. You then mint ten OCELOT perps, valued at 20 ETH each, and sell them to a market maker for a total of 200 ETH. The market maker will in turn sell your perps to traders who want exposure to the Awful Hot Ocelots project. If the Ocelot floor later drops to 10 ETH, you can buy back all ten perps for 100 ETH (ignoring funding) for a net credit of 100 ETH, allowing you to recover your NFTs. If your Ocelots dropped 10 ETH with the floor to an average of 15 ETH each, you would now have 100 ETH and a portfolio of NFTs worth 150 ETH in total, for a total portfolio value of 250 ETH, just as if the floor had never fallen. On the other hand, if the Ocelot floor rises to 30 ETH, you would need 300 ETH to buy back your perps and recover your NFTs, for a net debit of 100 ETH. However, if your thesis was correct and your NFTs have risen relative to the floor, say, to 65 ETH each, your total position would now have a value of 650 - 100 = 550 ETH, for a total gain of 550 - 250 = 300 ETH. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--297f697273/80651274ea2c3dc74a3c9c7b726ec274/asset-https-cdn-sanity-io-images-dgybcd83--297f697273.png) ### Funding and Liquidation Like [all perps](https://research.paradigm.xyz/cartoon-guide-to-perps), floor perps rely on *funding,* regular payments made between longs and shorts, in order to stay in line with their underlying. If more people want to go long OCELOT perps than want to go short, Ocelot holders who sell perps agains their Ocelots will actually earn yield for doing so. This may well be the case, as longs can use leverage when buying perps and might pay a liquidity premium for the ability to enter and exit positions easily. However, if more people want to go short than long, then shorts, including NFT holders, will have to make a periodic payment ("funding") to longs. Failing to pay funding is the *only* way Ocelot holders can get liquidated: because of design considerations we describe below, fluctuations in the NFT floor or the perp price will not lead to liquidation unless they cause massive funding payments, which implementers must be careful to avoid. ## Mechanism ### Overview For a basic guide to perpetual futures mechanics, see [The Cartoon Guide to Perps](https://research.paradigm.xyz/cartoon-guide-to-perps). Floor perpetuals are just standard perps that track the floor price of a given NFT project, but with a few key modifications to allow NFT collateralization and to minimize NFT liquidations. In particular: - In addition to cash, shorts can collateralize their positions using an NFT from the project the perp is tracking. - Shorts are required to pay funding in kind (see below) if they have insufficient cash balances. - Shorts are liquidated based on the index price rather than the mark price. - Long leverage requirements may be adjusted to ensure liquidity of the system. ### Trading Venue Like all perps, floor perps need a native venue. This could be an off-chain central limit order book or an on-chain AMM. As [Dan](https://twitter.com/danrobinson) and [Hasu](https://twitter.com/hasufl) like to point out, floor perps could even be implemented using a system like [Maker](https://makerdao.com/en/). ### Mark Price As always, the mark price of the perp is its price on its native exchange. ### Index Price The index price of a perp is the price of the asset it is supposed to track. In the case of floor perps, this price is the floor price for the project the perps are tracking, defined here as the highest price the market is willing to pay to get an NFT from the project without knowing which NFT they will get in advance. As a first step, we might use a protocol like [NFTX](https://nftx.org/) or [NFT20](https://nft20.io/) that issues fungible tokens representing a share in a basket of NFTs. Users can create these tokens by depositing an NFT or redeem them to withdraw an NFT. The price of these fungible tokens on a DEX, perhaps adjusted for liquidity, therefore represents a binding bid for the project floor. ### Index Reliability Illiquid floor NFT markets and volatile index prices are likely the largest barriers to making floor perps a reality, as the market for floor perps may grow to be many multiples of the size of the present market for the underlying floor NFTs. An unreliable index could increase liquidation risk, inaccurately represent collateral liquidation value, or become an attractive target for manipulation. To fix these problems, a floor perp protocol would likely have to figure out not just how to better measure floor prices, but also how to actually improve liquidity in the spot floor NFT market. One possibility for a growing floor perp exchange would be to somehow incentivize participation in a local spot floor NFT exchange. ### Funding Funding for floor perps follows the standard formulation: once per funding period, say, daily, longs must pay shorts MARK-INDEX, most likely denominated in ETH. ### NFT Collateral Most perps are collateralized using cash margin. In the case of floor perps, we allow those who are short the perp to collateralize their position with an NFT from the project instead of with cash. ### Funding in Kind for NFT-Backed Shorts In order to guarantee longs will be able to get liquidity when they close their positions, we cannot allow NFT-backed shorts to accrue cash-denominated funding debt (although a more intricate system might allow this in certain situations). Instead, if shorts must pay funding to longs and do not have a positive cash balance, the system will have them pay funding "in kind" to longs in the form of additional perps. For example, imagine MARK is 10 ETH and INDEX is 10.2 ETH at funding time, so that shorts must pay longs INDEX-MARK = 0.2 ETH. Imagine Alice is short 0.5 perps, collateralized by an NFT, and she has 0 cash balance in the system. Then, instead of lending to Alice or liquidating her, the system will mint an additional 0.01 perps (since FUNDING/MARK\*pos=0.2/10\*0.5=0.01) or her behalf, so that she is now short 0.51 perps. It will then distribute the additional long position amongst the longs in lieu of cash funding. In the example above, if Alice had been short 0.985 floor perps already and the system had to mint roughly an additional 0.01 perps on her behalf, so that she was now short 0.995 perps, she would be dangerously close to underwater and the system might liquidate her depending on its liquidation parameters. This is the only way in which NFT-backed shorts can get liquidated, as we explain below. ### Liquidation Criteria for NFT-Backed Shorts Imagine Alice has deposited an NFT as collateral and gone short $q$ perps ($0\\leq q \\leq 1$) including funding in kind as described above. If the current floor price is $m_1$, she has current liabilities of $qm_1$. For example, if she is short 0.5 perps and the current mark price is 10 ETH, she has a liability of 5 ETH. Her cash balance, $c$, includes proceeds from her perp sales, deposits, withdrawals, and cash funding. For example, if she had originally sold 0.5 perps at a mark price of 10 ETH before withdrawing 3 ETH and receiving 0.01 ETH in cash funding, her cash balance would be 5 - 3 + 0.01 = 2.01 ETH. Her collateral, the NFT, is worth the current index price $i_1$. For example, if the current index price is 5 ETH as well, her collateral of one NFT would be worth 5 ETH. In the standard perp formulation, Alice is underwater if her liabilities exceed her collateral and cash, that is, if $$ qm_1 > i_1 + c $$ In this case, Alice could be liquidated any time the mark $m_1$ spikes high enough. This is undesirable in our case, as we want NFT holders to have as little risk of losing their NFTs as possible. So, rather than liquidating Alice based on the mark price $m_1$, we use the current index price $i_1$. Then Alice is underwater if $$ qi_1 > i_1 + c \Longleftrightarrow (1-q)i_1 + c < 0 $$ As mentioned above, we never allow Alice's cash balance $c$ to go negative, so Alice can only be underwater if $q > 1$, or, as mentioned above, if funding in kind forces Alice's short position size to exceed the number of NFTs she has as collateral. Absent extreme divergence between index and mark price, which is possible depending on implementation, this should be a rare and foreseeable event, giving Alice plenty of time to recollateralize her account if necessary. Of course, there is a tradeoff involved in this design choice: if the mark is above the index price when NFT-backed shorts are liquidated, the proceeds of those liquidations, which can take place at or even below the index price, may not be sufficient to cover the shorts' obligations, which are denominated in the mark price, and longs will therefore not get all they are owed. This will present a major discrepancy only when the mark price is far above the index price, which should be a relatively uncommon occurrence in a well-implemented system. This is because, as demonstrated in the \[Everlasting Options\](https://www.paradigm.xyz/2021/05/everlasting-options/) paper, a perpetual future is equivalent via no-arbitrage to a basket of expiring futures, which are themselves equivalent via no-arbitrage to a basket of bonds and physical NFTs. Regardless, if this tradeoff presents too great a risk, this feature can be removed at the cost of increasing the risk of NFT liquidations. ### Liquidating NFT-Backed Shorts If NFT-backed shorts do have to be liquidated, their NFTs will be auctioned off, with the proceeds used to buy back their short positions and any overage going back to original holder of the NFT. A partial liquidation executed by selling a fraction of the NFT using a service like [fractional.art](http://fractional.art/) may be possible as well. ### Voluntary Liquidations In some situations, the floor price of a project may have risen so much that an NFT-backed short lacks the capital to buy back their perps and redeem the NFT. In such a case, the short may trigger a "voluntary liquidation auction," perhaps involving a fractional sale, to cover their debt and recover the overage. Since there is no risk of insolvency, such auctions may have more lenient parameters than typical liquidation auctions. ### Liquidity and Dynamic Collateralization Requirements Allowing shorts to collateralize their positions with NFTs instead of cash can expose the system to liquidity problems in certain circumstances. For example, imagine Alice sells one perp using one NFT as collateral, which Bob buys at a price of 1 ETH. The price of the perp then jumps to 6 ETH. Bob is ready to take 5 ETH of profits on his long, and Charlie would like to buy in. Now, if the protocol allowed Charlie to buy at 2X leverage, he would only need to deposit 3 ETH. However, even if Alice hadn't withdrawn any ETH from her original sale, Charlie's 3 ETH deposit plus the 1 ETH already in the system adds up to only 4 ETH, not enough for Bob to take his 5 ETH profit from his sale. As a result, whenever the system is undercapitalized, we will increase the collateral requirements for new buyers in order to ensure adequate liquidity for sellers. The most basic method would be to require buyers to fully collateralize their purchases whenever the system is undercapitalized. For example, in the situation above, this means Charlie would have to pay a full 6 ETH to open a long position, so that there would then be a total of 7 ETH in the system and Bob could claim his full 5 ETH profit. More complicated schemes are possible and might offer a better user experience. For example, the system might gradually increase collateral requirements as it becomes less capitalized instead of abruptly switching. ## Next Steps As mentioned above, the biggest problems aspiring floor perp protocols will have to solve are index reliability and spot NFT floor liquidity. Given good solutions, the possibilities are endless. For example, if we can find an appropriate index, we can create perpetual markets not just for a project's floor, but for NFTs containing a certain attribute or mix of attributes. We may even be able to split NFTs into synthetics representing their component parts and recombine them into new synthetics representing certain theses. The core liquidation mechanism can also be used for other products, such as instant NFT-backed loans. And, of course, the framework can be trivially adapted to offer [everlasting covered call options](https://www.paradigm.xyz/2021/05/everlasting-options/) on NFT floors. If you are interested in moving the conversation forward, I would love to hear from you. You can email me at [dave@paradigm.xyz](mailto:dave@paradigm.xyz) or [DM me on Twitter](https://twitter.com/messages/compose?recipient_id=1184231093576392704). *Acknowledgments: *[*Dan Robinson*](https://twitter.com/danrobinson)*, *[*Matt Huang*](https://twitter.com/matthuang)*, *[*Kevin Pang*](https://twitter.com/kevinxpang)*, *[*Georgios Konstantopoulos*](https://twitter.com/gakonst)*, *[*Sam Sun*](https://twitter.com/samczsun)*, *[*Anish Agnihotri*](https://twitter.com/_anishagnihotri)*, *[*Jim Prosser*](https://twitter.com/jimprosser)*, *[*Reena Jashnani-Slusarz*](https://www.linkedin.com/in/reena-jashnani-slusarz-0262348/)*, *[*Grug*](https://twitter.com/GrugCapital)*, *[*Lily Francus*](https://twitter.com/nope_its_lily)*, *[*WSBMod*](https://twitter.com/wsbmod)*, *[*0xSisyphus*](https://twitter.com/0xSisyphus)*, *[*Mewny*](https://twitter.com/mewn21)*, *[*FJ*](https://twitter.com/fjvdb7)*, *[*Hasu*](https://twitter.com/hasufl)*, *[*Andrew Badr*](https://twitter.com/andrewbadr)*, *[*0xbunnygirl*](https://www.paradigm.xyz/2021/05/everlasting-options/)*, *[*Omar Bohsali*](https://twitter.com/omarish)*, *[*Alex Wice*](https://twitter.com/AWice)*, *[*Bartosz Lipiński*](https://twitter.com/baalazamon)*, *[*Teo Leibowitz*](https://twitter.com/teo_leibowitz)*, *[*Tarun Chitra*](http://twitter.com/tarunchitra)*, *[*jhl*](http://twitter.com/jhl_xx)*, *[*andy8052*](https://twitter.com/andy8052)*, *[*Big Magic*](https://twitter.com/bigmagicdao)*, *[*0xElm0*](https://twitter.com/0xElm0)*, *[*Jordi Alexander*](https://twitter.com/gametheorizing)*, *[*shema*](https://twitter.com/pashayablockov)*, *[*David Lu*](https://twitter.com/davijlu) ## https://www.paradigm.xyz/writing/power-perpetuals # Power Perpetuals > Introducing a new type of derivative: the power perpetual. ## Introduction This paper introduces a new type of derivative, the *power perpetual*. If the price of ETH doubles, the ETH^2 power perp 4Xs, the ETH^3 power perp 8Xs, and the ETH^5 power perp 32Xs. Of course, this asymmetric upside doesn't come for free. Those who are long a power perpetual must regularly pay a *premium yield* to those who are short it. Power perpetuals provide global options-like exposure without the need for either strikes or expiries, giving them the potential to consolidate much of options market liquidity into a single instrument. In many ways, power perpetuals are the logical next step from [Everlasting Options](https://www.paradigm.xyz/2021/05/everlasting-options/), and they have been independently discovered at least two other times to our knowledge, by researchers [Wayne Nilsen](https://github.com/waynenilsen/zendax/blob/master/latex/PowerClaims.pdf) and [llllvvuu](https://llllvvuu.dev/blog/raw-moments). ## Mechanism ### Prerequisites Power perpetuals are a particular family of the class of perpetual derivatives introduced in the [Everlasting Options](https://www.paradigm.xyz/2021/05/everlasting-options/) paper. We will assume familiarity with both Everlasting Options and the basic mechanics of [perpetual futures](https://research.paradigm.xyz/cartoon-guide-to-perps) for the rest of this paper. ### Definition A power perpetual is a perpetual derivative indexed to a power of the price of some underlying instrument. In this paper, we will assume this underlying instrument is Ether. For any power p, the ETHp power perpetual is kept in line by means of a funding fee paid at a regular internal, say, daily. If the current price of the Power Perpetual is $MARK at the time of funding, those who are long the Power Perpetual may pay those who are short $(MARK-INDEX) = $(MARK-ETHp). In the context of power perpetuals, we call this funding fee a *premium yield* to reflect that this cost generally represents premium being paid from longs to shorts in return for options-like exposure. ### Example Consider the ETH^2 power perpetual. Assume for the sake of simplicity that ETH is trading at $3, and that the ETH^2 power perpetual is trading at $9.09 at the time funding is paid. Then the longs would have to pay the shorts $(MARK-INDEX) = $(MARK-ETH^2) = $(9.09 - 3^2) = $9.09 - $9.00 = $0.09 per contract. ## Pricing ### Overview Power perpetuals with powers greater than one have positive [convexity](https://twitter.com/_Dave__White_/status/1423740205874302976?s=20), meaning holders make money faster as prices move in their favor and lose money more slowly as prices move against them. In the language of options, we would say they have positive [gamma](https://en.wikipedia.org/wiki/Greeks_(finance)#Gamma). Just as an option generally trades at a premium to its [intrinsic value](https://en.wikipedia.org/wiki/Intrinsic_value_(finance)#Options), the ETH^p perp generally trades at a premium to the _p_th power of the price of ETH. ### Derivation Following the methodology in the [Everlasting Options paper](https://www.paradigm.xyz/2021/05/everlasting-options/), we can start by pricing an expiring power derivative, then price a portfolio of these derivatives equivalent to the desired perpetual. We will use Black-Scholes assumptions to derive our price below. These are certainly not the most appropriate assumptions, but should serve as an example of how a market-maker might go about valuing a power perpetual. Pricing an expiring power derivative under Black-Scholes assumptions is significantly simpler than pricing an option. Those curious can find a quick derivation on StackExchange [here](https://math.stackexchange.com/questions/1015926/derivatives-pricing-w-squared-and-cubed-stock-prices/3954177#3954177). The price comes out to $$ S^pe^{t\frac{p-1}{2}(2r+pv^2)} $$ where S is spot price, p is the power, t is the time to expiry, r is the drift or risk-free rate, and v is the annualized volatility. Combining that with the pricing methodology for Everlasting Options found in Appendix B of the [Everlasting Options PDF](https://www.paradigm.xyz/papers/everlasting_options.pdf) and summing the resultant geometric series, we obtain the following expression for the price of a power perpetual with funding paid once per period (assuming the series converges — see below): $$ S^p\frac{1}{2e^{-f\frac{p-1}{2}(2r+pv^2)}-1} $$ where f is the funding period in years. This can be interpreted as the index, $S^p$, times an adjustment factor, $\\frac{1}{2e^{-f\\frac{p-1}{2}(2r+pv^2)}-1}$ which accounts for the embedded optionality in the power perpetual. Note that, as the funding period approaches 0, this adjustment factor approaches 1. The premium yield (our new term for funding rate) can be calculated as $$ \text{MARK}-\text{INDEX} = S^P(\frac{1}{2e^{-f\frac{p-1}{2}(2r+pv^2)}-1}-1) $$ ### Convergence Unlike stock Everlasting Options, which we can always price, poorly formulated power perpetuals may have prices which fail to converge. In particular, we can only price a power perpetual when we have $$ \frac{e^{f\frac{p-1}{2}(2r+pv^2)}}{2} < 1 $$ Intuitively speaking, the higher the power and volatility, the more valuable longer-dated expiring power futures get, and the longer the funding period, the more of the value of the power perpetual is concentrated in longer-dated power futures. For some combinations, the equivalent portfolio can become infinitely valuable. This problem can easily be avoided in practice by choosing a sufficiently small funding period. ## Examples ### ETH^2 Power Perp ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--8975c62fdb/8a812f68900f3d27114f259e331ea598/asset-https-cdn-sanity-io-images-dgybcd83--8975c62fdb.png) *See: https://github.com/para-dave/powerperps/blob/master/power_perp_prices.ipynb* The ETH^2 power perp has a price of $S^2\\frac{1}{2e^{-f(r+v^2)}-1}$ under Black-Scholes assumptions. All else being equal, it will 16X as ETH 4Xs. It has the convenient property of having a constant gamma of $\\frac{2}{2e^{-f(r+v^2)}-1}$, meaning it offers constant optionality regardless of the price of ETH. We affectionately call it "squeeth," short for "squared ETH." ### ETH^3 Power Perp ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--0a2591e8bd/52aba7a464ce9dd92e08fdb88c758e7b/asset-https-cdn-sanity-io-images-dgybcd83--0a2591e8bd.png) *See: https://github.com/para-dave/powerperps/blob/master/power_perp_prices.ipynb* The ETH^3 power perp has a price of $S^3\\frac{1}{2e^{-f(2r+pv^2)}-1}$. All else being equal, it will 64X as ETH 4Xs. You can see clearly from the graph how the perp trades at a premium to its index, ETH^3, because of the optionality it provides to holders. ### Python Pricing Implementation You can see a Python implementation of power perpetuals pricing at [https://github.com/para-dave/powerperps/](https://github.com/para-dave/powerperps/), including a tests empirically demonstrating correctness [here](https://github.com/para-dave/powerperps/blob/master/test_pricing.py). ## Conclusion Power perpetuals are still in their infancy, but we have been studying them in depth since their [inception](https://twitter.com/snarkyzk/status/1413514817877381128?s=20) and remain extremely excited about their potential. If you are as intrigued by this new primitive as we are, we would love to hear from you. You can email [dave@paradigm.xyz](mailto:dave@paradigm.xyz) or [DM me on Twitter](https://twitter.com/messages/compose?recipient_id=1184231093576392704), or reach out to Opyn at [squeeth@opyn.co](mailto:squeeth@opyn.co). *Acknowledgments: *[*llllvvuu,*](https://twitter.com/llllvvuu) [*Wayne Nilsen,*](https://twitter.com/waynenilsen) [*Wade Prospere*](https://twitter.com/wadepros)*, *[*Grug*](https://twitter.com/GrugCapital)*, *[*Lily Francus*](https://twitter.com/nope_its_lily)*, *[*Dr. Benn Eifert*](https://twitter.com/bennpeifert)*, *[*Jeff Wang*](https://twitter.com/jeff_w1098)*, *[*Mewny*](https://twitter.com/mewn21) ## https://www.paradigm.xyz/writing/two-rights-might-make-a-wrong # Two Rights Might Make A Wrong > It only takes one vulnerability to cause serious financial damage to hundreds if not thousands of innocent users. Breaking down how I found and helped patch a vulnerability that put over 109k ETH at risk. A common misconception in building software is that if every component in a system is individually verified to be safe, the system itself is also safe. Nowhere is this belief better illustrated than in DeFi, where composability is second nature to developers. Unfortunately, while composing two components might be safe most of the time, it only takes one vulnerability to cause serious financial damage to hundreds if not thousands of innocent users. Today, I’d like to tell you about how I found and helped patch a vulnerability that put over 109k ETH (~350 million USD at today’s exchange rate) at risk. ## The Encounter *9:42 AM* I was offhandedly browsing through the LobsterDAO group on Telegram when I noticed a discussion between [@ivangbi_](https://twitter.com/ivangbi_) and [@bantg](https://twitter.com/bantg) about a new raise on SushiSwap’s MISO platform. I typically try to avoid drama in public, but I couldn’t help but do a quick Google search to see what it was all about. The results I got back weren’t particularly interesting to me, but I pressed onward, driven by a feeling there was something interesting to be found here if I just kept looking. The MISO platform operates two types of auctions: Dutch auctions and batch auctions. In this case, the raise was being held with a Dutch auction. Naturally, the first thing I did was open up the contract on [Etherscan](https://etherscan.io/address/0x4c4564a1FE775D97297F9e3Dc2e762e0Ed5Dda0e). *9:44 AM* I quickly skimmed through the DutchAuction contract per the participation agreement and checked each interesting function. The commit functions (`commitEth`, `commitTokens`, and `commitTokensFrom`) all seemed to be implemented correctly. The auction management functions (`setDocument`, `setList`, etc) also had the proper access controls. However, near the bottom I noticed that the `initMarket` function had no access controls, which was extremely concerning. Furthermore, the `initAuction` function it called also contained no access control checks. I didn’t really expect this to be a vulnerability though, since I didn’t expect the Sushi team to make such an obvious misstep. Sure enough, the `initAccessControls` function validated that the contract had not already been initialized. However, this led me to another discovery. While scrolling through all of the files, I noticed the `SafeTransfer` and `BoringBatchable` libraries. I was familiar with both of these, and I was immediately struck with the potential that the `BoringBatchable` library introduced. For those who aren’t familiar, `BoringBatchable` is a mixin library which is designed to easily introduce batch calls to any contract which imports it. It does this by performing a delegatecall on the current contract for each call data provided in the input. ```solidity function batch(bytes[] calldata calls, bool revertOnFail) external payable returns (bool[] memory successes, bytes[] memory results) { successes = new bool[](calls.length); results = new bytes[](calls.length); for (uint256 i = 0; i < calls.length; i++) { (bool success, bytes memory result) = address(this).delegatecall(calls[i]); require(success || !revertOnFail, _getRevertMsg(result)); successes[i] = success; results[i] = result; } } ``` Looking at this function, it appeared to be implemented correctly. However, something in the corner of my mind was nagging at me. That’s when I realized I had seen something very similar in the past. ## The Discovery *9:47 AM* A little over a year ago today, I was in a Zoom call with the Opyn team, trying to figure out how to recover and protect user funds after a devastating hack. The hack itself was simple but genius: it exercised multiple options using a single payment of ETH because the Opyn contracts used the `msg.value` variable in a loop. While processing token payments involved a separate `transferFrom` call for each loop iteration, processing ETH payments simply checked whether `msg.value` was sufficient. This allowed the attacker to reuse the same ETH multiple times. I realized that I was looking at the exact same vulnerability in a different form. Inside a delegatecall, `msg.sender` and `msg.value` are persisted. This meant that I should be able to batch multiple calls to `commitEth` and reuse my `msg.value` across every commitment, allowing me to bid in the auction for free. *9:52 AM* My instincts were telling me that this was the real deal, but I couldn’t be sure without verifying it. I quickly opened up Remix and wrote a proof-of-concept. To my dismay, my mainnet fork environment was completely busted. I must’ve accidentally broken it during the London hard fork. With how much money was at risk though, I didn’t have the luxury of time. I quickly threw together a poor man’s mainnet fork on the command line and tested my exploit. It worked. *10:13 AM* I pinged my colleague, [Georgios Konstantopoulos](https://twitter.com/gakonst), to get a second pair of eyes on this before reporting it. While I waited for a response, I went back to the contract to look for ways to elevate the severity. It was one thing to be able to participate in the auction for free, but it would be another to be able to *steal* all of the other bids too. I had noticed there was some refund logic during my initial scan but thought little of it. Now, it was a way to get ETH out of the contract. I quickly checked what conditions I would need to meet in order to get the contract to provide me with a refund. To my surprise (and horror), I found that a refund would be issued for any ETH sent which went over the auction’s hard cap. This applied even once the hard cap was hit, meaning that instead of rejecting the transaction altogether, the contract would simply refund all of your ETH instead. Suddenly, my little vulnerability just got a lot bigger. I wasn’t dealing with a bug that would let you outbid other participants. I was looking at a 350 million dollar bug. ## The Disclosure *10:38 AM* After verifying the bug with Georgios, I asked him and [Dan Robinson](https://twitter.com/danrobinson) to try and reach out to Joseph Delong from Sushi. Within minutes, Joseph had responded and I found myself in a Zoom call with Georgios, Joseph, Mudit, Keno, and Omakase. I quickly debriefed the participants on the vulnerability and they left to coordinate a response. The entire call lasted mere minutes. *11:10 AM* Joseph got back to Georgios and I with a Google Meet room. I joined as Georgios was in the middle of debriefing Joseph, Mudit, Keno, and Omakase, as well as Duncan and Mitchell from Immunefi. We quickly discussed next steps. We had three options: 1. Leave the contract and hope no one notices 2. Rescue the funds using the exploit, probably using Flashbots to hide the transaction 3. Rescue the funds by purchasing the remaining allocation and immediately finalizing the auction, requiring admin permissions After some quick debate, we decided that option 3 was the cleanest approach. We broke out into separate rooms in order to work on comms and ops separately. ## The Preparation *11:26 AM* Inside the ops room, Mudit, Keno, Georgios, and I were busy writing a simple rescue contract. We decided that it would be cleanest to take a flash loan, purchase up to the hard cap, finalize the auction, then repay the flash loan using proceeds from the auction itself. This would require no upfront capital, which was very nice. *12:54 PM* We ran into a problem. What was originally supposed to be a simple rescue operation had just turned into a ticking time bomb that couldn’t be defused, because there was *another* active auction. This was a batch auction, which meant that we couldn’t just buy up to the hard cap because there was no hard cap at all. Fortunately, the lack of a hard cap also meant there was no way to drain ETH from the contract because no refunds were offered. We quickly discussed the pros and cons of performing a whitehat rescue on the first contract and ultimately decided that even though the batch auction had 8 million USD committed, those 8 million USD weren’t at risk, while the 350 million USD in the original Dutch auction was very much still at risk. Even if someone was tipped off by our forced halting of the Dutch auction and found the bug in the batch auction, we would still save the majority of the money. The call to proceed was made. *1:36 PM* As we wrapped up work on the rescue contract, we discussed next steps for the batch auction. Mudit pointed out that there was a points list which could be set even while the auction was live, and it was called during each ETH commitment. We immediately realized this could be the pause function we were looking for. We brainstormed different ways to make use of this hook. Immediately reverting was an obvious solution, but we wanted something better. I considered adding a check that every origin could only make one commitment per block, but we noticed that the function was marked as view, which meant that the Solidity compiler would have used a static call opcode. Our hook wouldn’t be allowed to make any state modifications. After some more thinking, I realized that we could use the points list to verify that the auction contract had enough ETH to match the commitments being made. In other words, if someone tried to exploit this bug, then there would be more commitments than there was ETH. We could easily detect this and revert the transaction. Mudit and Keno began working on writing a test to verify. ## The Rescue *2:01 PM* The comms breakout team merged with the ops breakout team to sync on progress. They had made contact with the team performing the raise, but the team wanted to finalize the auction manually. We discussed the risks and agreed that there was minimal likelihood that an automated bot would notice the transaction or be able to do anything about it. *2:44 PM* The team performing the raise finalized the auction, neutralizing the immediate threat. We congratulated each other and went our separate ways. The batch auction would finalize later in the day to little fanfare. No one outside of the circle of trust knew what scale of crisis had just been averted. ## The Reflection *4:03 PM* The past few hours feel like a blur, almost as though no time has passed at all. I had gone from encounter to discovery in a little over half an hour, disclosure in 20 minutes, war room in another 30, and a fix in three hours. All in all, it took only five hours to protect 350 million USD from falling into the wrong hands. Even though there was no monetary damage, I’m sure that everyone involved would have much preferred to not have gone through this process in the first place. To that end, I have two main takeaways for you. First, using `msg.value` in complex systems is hard. It’s a global variable that you can’t change and persists across delegate calls. If you use `msg.value` to check that payment was received, you absolutely cannot place that logic in a loop. As a codebase grows in complexity, it’s easy to lose track of where that happens and accidentally loop something in the wrong place. Although wrapping and unwrapping of ETH is annoying and introduces extra steps, the unified interface between WETH and other ERC20 tokens might be well worth the cost if it means avoiding something like this. Second, safe components can come together to make something unsafe. I’ve preached this before in the context of composability and DeFi protocols, but this incident shows that even safe contract-level components can be mixed in a way that produces unsafe contract-level behavior. There’s no catch-all advice to apply here like “check-effect-interaction,” so you just need to be cognizant of what additional interactions new components are introducing. I’d like to thank Sushi contributors, Joseph, Mudit, Keno, and Omakase for their extremely quick response to this issue as well as my colleagues Georgios, Dan, and Jim for their help throughout this process, including reviewing this post. ## https://www.paradigm.xyz/writing/the-dangers-of-surprising-code # The Dangers of Surprising Code > If you work in software engineering, odds are you've heard of at least one software engineering principle. While I wouldn't advocate for religiously following every principle to the letter, there are a few that are really worth paying attention to. If you work in software engineering, odds are you've heard of at least one software engineering principle. While I wouldn't advocate for religiously following every principle to the letter, there are a few that are really worth paying attention to. The one I want to talk about today is the *principle of least astonishment*. It has a fancy name but is a really simple idea. All it says is that when presented with code that claims to do something, most users will make assumptions regarding how it behaves to get that thing done. As such, your job as the developer is to write your code to match those assumptions so that your users don't get a nasty surprise. This is a good principle to follow because developers like making assumptions about things. If you export a function called `calculateScore(GameState)`, a lot of people are going to rightly assume that the function will only read from the game state. If you also mutate the game state, you'll surprise a lot of very confused people trying to figure out why their game state is randomly getting corrupted. Even if you put it in the documentation, there's still no guarantee that people will see it, so it's best to just ensure your code isn't surprising in the first place. *Embed* # Safer Is Better, Right? When the ERC-721 standard was being drafted, back in the beginning of 2018, a suggestion was made to implement [transfer security](https://github.com/ethereum/EIPs/commit/74dadccc858545aa89edaf6ec1cb5857cd261083) to ensure that tokens wouldn't be stuck in recipient contracts that weren't designed to handle them. To do this, the proposal authors modified the behavior of the `transfer` function to check the recipient for whether they were capable of supporting the token transfer. They also introduced the `unsafeTransfer` function which would bypass this check, should the sender so desire. However, due to concerns about backwards compatibility, the functions were [renamed](https://github.com/ethereum/EIPs/commit/2bddd126def7c046e1e62408dc2b51bdd9e57f0f) in a subsequent commit. This made the `transfer` function behave the same for both an ERC-20 and an ERC-721 token. However, now the recipient checking needed to be moved elsewhere. As such, the `safe` class of functions was introduced: `safeTransfer` and `safeTransferFrom`. This was a solution for a legitimate problem, as there have been numerous examples of ERC-20 tokens being accidentally transferred to contracts that never expected to receive tokens (one particularly common mistake was to transfer tokens to the token contract itself, locking it forever). It's no surprise then that when the ERC-1155 standard was being drafted, it took inspiration from the ERC-721 standard by including recipient checks not only on transfer but on mint as well. These standards mostly sat dormant for the next few years while ERC-20 maintained its popularity, but recently a spike in gas costs, as well as interest in NFTs, means that the ERC-721 and ERC-1155 standards have seen a spike in developer usage. With all this renewed interest, it sure is fortunate that these standards were designed with safety in mind, right? # *Safer Is Better, Right?* Ok, but what exactly does it mean for a transfer or mint to be safe? Different parties have different interpretations of safety. For a developer, a safe function might mean that it doesn't contain any bugs or introduce additional security concerns. For a user, it could mean that it contains additional guardrails to protect them from accidentally shooting themselves in the foot. It turns out that in this case, these functions are more of the latter and less of the former. This is especially unfortunate because given the choice between `transfer` and `safeTransfer`, why wouldn't you pick the safe one? It's in the name! Well, one reason might be our old friend reentrancy, or as I've been trying my hardest to rebrand it to: unsafe external calls. Recall that any external call is potentially unsafe if the recipient is attacker-controlled because the attacker may be able to cause your contract to transition into an undefined state. By design, these "safe" functions perform an external call to the recipient of the tokens, which is often controlled by the sender during a mint or transfer. In other words, this is practically a textbook example of an unsafe external call. But, you might ask yourself, what's the worst that could happen from allowing a recipient contract to reject a transfer that they weren't able to process? Well, allow me to answer that question with two quick case studies. # Hashmasks Hashmasks are NFTs with a limited supply. Users were able to purchase up to 20 masks per transaction, although they've been sold out for months already. Here's the function to buy masks: ```solidity function mintNFT(uint256 numberOfNfts) public payable { require(totalSupply() < MAX_NFT_SUPPLY, "Sale has already ended"); require(numberOfNfts > 0, "numberOfNfts cannot be 0"); require(numberOfNfts <= 20, "You may not buy more than 20 NFTs at once"); require(totalSupply().add(numberOfNfts) <= MAX_NFT_SUPPLY, "Exceeds MAX_NFT_SUPPLY"); require(getNFTPrice().mul(numberOfNfts) == msg.value, "Ether value sent is not correct"); for (uint i = 0; i < numberOfNfts; i++) { uint mintIndex = totalSupply(); if (block.timestamp < REVEAL_TIMESTAMP) { _mintedBeforeReveal[mintIndex] = true; } _safeMint(msg.sender, mintIndex); } /** * Source of randomness. Theoretical miner withhold manipulation possible but should be sufficient in a pragmatic sense */ if (startingIndexBlock == 0 && (totalSupply() == MAX_NFT_SUPPLY || block.timestamp >= REVEAL_TIMESTAMP)) { startingIndexBlock = block.number; } } ``` If you weren't expecting it, then this function might seem perfectly reasonable. However, as you might have predicted, there's something sinister hidden inside that `_safeMint` call. Let's take a look. ```solidity function _safeMint(address to, uint256 tokenId, bytes memory _data) internal virtual { _mint(to, tokenId); require(_checkOnERC721Received(address(0), to, tokenId, _data), "ERC721: transfer to non ERC721Receiver implementer"); } ``` For *safety*, this function performs a callback to the recipient of the token to check that they're willing to accept the transfer. However, we're the recipient of the token, which means we just got a callback at which point we can do whatever we like, including calling `mintNFT` again. If we do this, we'll reenter the function after only one mask has been minted, which means we can request to mint another 19 masks. This results in a total of 39 masks being minted, even though the maximum allowable was only 20. # ENS Name Wrapper More recently, Nick Johnson from ENS reached out about taking a look at their work-in-progress name wrapper for the ENS. The name wrapper allows users to tokenize their ENS domains in a new ERC-1155 token which provides support for fine-grained permissions and a more consistent API. At a high level, in order to wrap an arbitrary ENS domain (more specifically, any domain that isn't a 2LD `.eth` domain) you must first approve the name wrapper to access your ENS domain. Then you call `wrap(bytes,address,uint96,address)` which both mints an ERC-1155 token for you and also takes custody of the underlying ENS domain. Here's the wrap function itself, it's fairly straightforward. First, we call `_wrap` which does some logic and returns the hashed domain name. Then we ensure that the transaction sender is indeed the owner of the ENS domain before taking custody of the domain. Note that if the sender does not own the underlying ENS domain, then the entire transaction should revert, undoing any changes made in `_wrap`. ```solidity function wrap( bytes calldata name, address wrappedOwner, uint96 _fuses, address resolver ) public override { bytes32 node = _wrap(name, wrappedOwner, _fuses); address owner = ens.owner(node); require( owner == msg.sender || isApprovedForAll(owner, msg.sender) || ens.isApprovedForAll(owner, msg.sender), "NameWrapper: Domain is not owned by the sender" ); ens.setOwner(node, address(this)); if (resolver != address(0)) { ens.setResolver(node, resolver); } } ``` Here's the `_wrap` function itself. Nothing special going on in here. ```solidity function _wrap( bytes memory name, address wrappedOwner, uint96 _fuses ) private returns (bytes32 node) { (bytes32 labelhash, uint256 offset) = name.readLabel(0); bytes32 parentNode = name.namehash(offset); require( parentNode != ETH_NODE, "NameWrapper: .eth domains need to use wrapETH2LD()" ); node = _makeNode(parentNode, labelhash); _mint(node, name, wrappedOwner, _fuses); emit NameWrapped(node, name, wrappedOwner, _fuses); } ``` Unfortunately, it's the `_mint` function itself where unsuspecting developers may be in for a nasty surprise. The ERC-1155 specification states that when minting a token, the recipient should be consulted for whether they're willing to accept the token. Upon digging into the library code (which is lightly modified from the OpenZeppelin base), we see that this is indeed the case. ```solidity function _mint( bytes32 node, bytes memory name, address wrappedOwner, uint96 _fuses ) internal { names[node] = name; address oldWrappedOwner = ownerOf(uint256(node)); if (oldWrappedOwner != address(0)) { // burn and unwrap old token of old owner _burn(uint256(node)); emit NameUnwrapped(node, address(0)); } _mint(node, wrappedOwner, _fuses); } function _mint( bytes32 node, address newOwner, uint96 _fuses ) internal virtual { uint256 tokenId = uint256(node); address owner = ownerOf(tokenId); require(owner == address(0), "ERC1155: mint of existing token"); require(newOwner != address(0), "ERC1155: mint to the zero address"); require( newOwner != address(this), "ERC1155: newOwner cannot be the NameWrapper contract" ); _setData(tokenId, newOwner, _fuses); emit TransferSingle(msg.sender, address(0x0), newOwner, tokenId, 1); _doSafeTransferAcceptanceCheck( msg.sender, address(0), newOwner, tokenId, 1, "" ); } ``` But what good does this do for us, exactly? Well, once again we are presented with an unsafe external call that we can use to perform reentrancy. Specifically, notice that during the callback we own the ERC-1155 token representing the ENS domain, but the name wrapper hasn't yet verified that we own the underlying ENS domain itself. This allows us to operate on the ENS domain without actually owning it in the first place. For example, we can ask the name wrapper to unwrap our domain, burning the token we just minted and getting the underlying ENS domain. ```solidity function unwrap( bytes32 parentNode, bytes32 label, address newController ) public override onlyTokenOwner(_makeNode(parentNode, label)) { require( parentNode != ETH_NODE, "NameWrapper: .eth names must be unwrapped with unwrapETH2LD()" ); _unwrap(_makeNode(parentNode, label), newController); } function _unwrap(bytes32 node, address newOwner) private { require( newOwner != address(0x0), "NameWrapper: Target owner cannot be 0x0" ); require( newOwner != address(this), "NameWrapper: Target owner cannot be the NameWrapper contract" ); require( !allFusesBurned(node, CANNOT_UNWRAP), "NameWrapper: Domain is not unwrappable" ); // burn token and fuse data _burn(uint256(node)); ens.setOwner(node, newOwner); emit NameUnwrapped(node, newOwner); } ``` Now that we have the underlying ENS domain, we can do whatever we want with it, such as register new subdomains or set the resolver. When we're done, we just exit the callback. The name wrapper will fetch the current owner of the underlying ENS domain, which is us, and complete the transaction. Just like that, we've taken temporary ownership of any ENS domain the name wrapper is approved for and made arbitrary changes to it. # Conclusion Code that's surprising may break things in catastrophic ways. In both of these cases, developers who reasonably assumed that the `safe` class of functions would be (at least as) safe to use instead inadvertently increased their attack surface. As the ERC-721 and ERC-1155 standards become more popular and widespread, it is very likely that this will become an increasingly frequent occurrence. Developers will need to consider the risks of using the `safe` class of functions and determine how the external call might interact with the code they've written. ## https://www.paradigm.xyz/writing/twamm # TWAMM > This paper introduces a new type of automated market maker, or AMM, that helps traders on Ethereum efficiently execute large orders -- The time-weighted average market maker, or TWAMM (pronounced "tee-wham"). ## Introduction This paper introduces a new type of automated market maker, or AMM, that helps traders on Ethereum efficiently execute large orders. We call it the *time-weighted average market maker*, or TWAMM (pronounced "tee-wham"). It works by breaking long-term orders into infinitely many infinitely small pieces and executing them against an embedded constant-product AMM smoothly over time. ## Summary Let's say Alice wants to buy 100 million USDC worth of ETH on-chain. An order of this size will be expensive to execute on existing AMMs like Uniswap, which must charge Alice a high price in case she knows something they don't. Today, Alice's best option is to manually break her order up into several pieces and execute them over a period of hours, giving the market time to realize she does not have inside information so it can give her a better price. If she sends a few large sub-orders, each will still have significant price impact and will be vulnerable to *sandwich attacks* by adversarial traders. On the other hand, if she sends many small sub-orders, she will have to take on all the work and risk of active trading, and will pay high costs in the form of per-transaction gas fees to miners. The TWAMM resolves this dilemma for Alice by trading on her behalf. It breaks her order into infinitely many infinitely small *virtual orders* to ensure perfectly smooth execution over time, and, using a special mathematical relationship with its embedded AMM, is able to amortize gas costs across these virtual orders. Because it processes trades *in between* blocks, it is also less susceptible to sandwich attacks. ## Market Making Basics ### Market Makers Consider a market for two financial assets, say, USDC and ETH. A *market maker* is a participant in this market who is willing, at any time, to trade either one for the other. If you have 100 million USDC and want to use it to buy ETH, you probably won't be able to find another individual who wants to do the opposite trade at the exact same time. Instead, you will most likely go to a market populated by one or more market makers and trade with them. ### Adverse Selection Market makers earn a profit from the *spread*, effectively a fee they charge on each trade. They lose money when prices *move against* them — when they buy an asset whose price then goes down, or sell an asset whose price then goes up. Unfortunately for market makers, prices tend to move against them on average. This phenomenon is known as *adverse selection.* It happens because traders with information about future price movements are more likely to trade against market makers for large size. The most dangerous orders are ones that are both *large* and *urgent*, because those are precisely the type of orders informed traders tend to make. As a result, the most basic market making tactic is to *fade* incoming orders, adjusting prices up when a large buy order comes in, and adjusting prices down when a large sell order comes in. ## Automated Market Makers In the past year, *automated market makers (AMMs)*, led by [Uniswap](https://info.uniswap.org/#/), have become hugely popular on Ethereum, handling billions of dollars of volume daily. True to their name, AMMs automate much of the market making process. ### The Constant Product Formula The *constant product formula* is a simple rule that allows anybody to spin up both a new market and a new AMM for a new pair of assets instantaneously. To create a new Constant Product AMM (CPAMM) between two assets X and Y, a user, called a *liquidity provider*, or LP, deposits *reserves* x and y of those two assets. The ratio of these assets at any given time represents the *instantaneous price* on the AMM, or the price it will charge for a very small order. For example, if a CPAMM contains 2,000 USDC and 1 ETH in its reserves, its instantaneous price for ETH will be 2,000 USDC. When traders come to trade with the AMM, it decides what price to give them based on the formula \*\*x \* y = k, where x and y are the reserve sizes and k is a constant. This means that the *product* of its reserve sizes stays the same during a trade (ignoring fees). #### Example Consider an ETH/USDC CPAMM with 2,000 USDC and 1 ETH in the reserves, so that x = 2,000, y = 1, and x \* y = k = 2,000. The instantaneous price of this AMM is 2,000 / 1 = 2,000 USDC per ETH. If a trader comes and buys 2,000 USDC worth of ETH, that means they are depositing 2,000 USDC into the X reserves, so that we will have x = 2,000 + 2,000 = 4,000. Then, since k = 2000, we must have y = k/x = 2000/4000 = 0.5 after the trade. Since y was originally 1, 1 - 0.5 = 0.5 ETH must have gone to the trader. Since the trader bought 0.5 ETH with their 2000 USDC, they paid an average price of 4,000 USDC per ETH. This high price relative to the instantaneous price reflects the large order size relative to the liquidity in the AMM. #### Price Impact and Adverse Selection In the above case, the trader had to pay 4,000 USDC per ETH for their large order when the cost for a small order would have been only 2,000 USDC per ETH. This difference in price is referred to as the *price impact* of the order. The larger the incoming order, the greater the price impact. This is how the AMM combats adverse selection: large incoming orders are more likely to be informed, and so the AMM makes them pay a high price. It is the automated equivalent of fading an order. ## Executing Large Orders on Current AMMs ### Manual Order Splitting As we can see, executing a large order on an AMM in a single transaction is expensive by design. [This excellent article](https://www.paradigm.xyz/2021/04/understanding-automated-market-makers-part-1-price-impact/) goes into the problem in depth and recommends some solutions. In short, a trader who wishes to execute a large order on an AMM should not do it in a single transaction: they are better off splitting their order into several pieces. This could involve sending orders to several AMMs at once, but these AMMs too will have limited liquidity at any given point in time. The larger the order, the more attractive splitting it up over *time* becomes. For example, let's say an investor wants to buy 100 million USDC of ETH on-chain. They don't have any short-term information about the price of ETH, and so don't mind if their order takes some time to execute. In this case, they might break their order into ten chunks of ten million USDC each and execute each chunk one hour apart, limiting the price impact of each part. ### The Sub-Order Size Tradeoff Obviously, if a very large order is split into only a few pieces, each individual sub-order will still be large, and will incur price impact accordingly. Splitting the order into even smaller pieces helps, but this introduces two new problems of its own. The first problem is *operational complexity*, meaning increased risk and work. The trader might enter the wrong trade quantity for a given trade, or the wrong direction. Or her computer could crash, preventing her from executing part of the order. Even if everything goes right, the process takes time and effort, distracting attention from more profitable endeavors. The second problem is that each trade incurs fixed *transaction costs*, such as the *gas* paid to Ethereum miners to process the transaction. If the trader splits her order into too many pieces, she can end up spending more money on fees than on actually buying ETH. ## Analogy to Traditional Finance In the world of traditional finance, if an investor or institution wanted to buy $100 million dollars of Apple stock, they would not send a $100 million market buy order directly to an exchange. Nor would they send ten such orders for $10 million each. Breaking the order into pieces much smaller than that would be impractical for most without dedicated trading staff and infrastructure. Instead, they would most likely send their large order to a broker, who would put on an [*algorithmic trade*](https://en.wikipedia.org/wiki/Algorithmic_trading) for them in exchange for a fee. The broker would execute the trade over a specified period of time, say, eight hours, at a price similar to some benchmark. The broker would have a team specialized in executing such trades safely and cheaply. ### The TWAP Order Perhaps the most basic type of algorithmic trade is the [Time-Weighted Average Price](https://en.wikipedia.org/wiki/Time-weighted_average_price), or TWAP (pronounced "tee-whap") order. A TWAP order to buy $100 million dollars of Apple stock over eight hours would, as the name suggests, get filled at a price close to the time-weighted average price of Apple stock over that period. For example, if Apple stock spent four hours priced at $100 and four hours priced at $120 over the time period, the time-weighted average price would be ($100 \* 4 + $120 \* 4)/8 = $110, and the broker would execute the TWAP order for near that price. Details vary, but the broker would most likely execute this trade by splitting it into many small pieces throughout the day and sending them to the market. Buying $100 million of Apple stock over eight hours is equivalent to buying around $350 of Apple stock every 100 milliseconds, and we might expect the broker to do more or less that. The broker has the infrastructure to reduce or eliminate the operational complexity of so many small trades, and, as they have a direct connection to the market, will likely not have to pay much in transaction costs. ## The Time-Weighted Average Market Maker The Time-Weighted Average Market Maker (TWAMM) provides the on-chain equivalent of the TWAP order. The TWAMM has specialized logic for order splitting and a direct connection to an embedded exchange, providing smooth execution for low gas cost. Arbitrageurs keep prices on the TWAMM's embedded exchange in line with market prices, ensuring execution near the time-weighted average price of the asset. ### Overview Each TWAMM instance facilitates trading between a particular pair of assets, such as ETH and USDC. The TWAMM contains an *embedded AMM*, a standard constant-product market maker for those two assets. Anyone may trade with this embedded AMM at any time, just as if it were a normal AMM. Traders can submit *long-term orders* to the TWAMM, which are orders to sell a fixed amount of one of the assets over a fixed number of blocks — say, an order to sell 100 ETH over the next 2,000 blocks. The TWAMM breaks these long-term orders into infinitely many infinitely small *virtual sub-orders*, which trade against the embedded AMM at an even rate over time. Processing transactions for each of these virtual sub-orders individually would cost infinite gas, but a closed-form mathematical formula allows us to calculate their cumulative effect only when needed. The execution of long-term orders will push the embedded AMM's price away from prices on other markets over time. When this happens, *arbitrageurs* will trade against the embedded AMM's price to bring it back in line, ensuring good execution for long-term orders. For example, if long-term sells have made ETH cheaper on the embedded AMM than it is on a particular centralized exchange, arbitrageurs will buy ETH from the embedded AMM, bringing its price back up, and sell it on the centralized exchange for a profit. ### Ethereum Refresher #### Blocks Ethereum bundles transactions into sequential groups called *blocks*, approximately one every 13 seconds. For the purposes of this post, we will number each block: block 1 is followed by block 2, which is followed by block 3, and so on. #### Miners A distributed groups of *miners* competes to process each block. Anybody with an internet connection can become a miner. This means that programs like AMMs that run on Ethereum cannot keep any secrets: everybody has to be able to calculate exactly what they will do given their inputs. #### Gas Computation on Ethereum is a scarce resource, and so users must pay miners for it in the form of *gas*. The more computation involved in a given transaction, the more gas it will consume. This gas cost is paid entirely by the person submitting the transaction. ### Basic Design #### Long-Term Orders Alice wants to buy 100 million USDC worth of ETH over the next 8 hours, or about 2,000 blocks. She enters a long-term order into the TWAMM to buy 100 million USDC worth of ETH over 2,000 blocks, or 50,000 USDC per block. As mentioned above, we don't know in advance which miners will process future transactions on the TWAMM. This means Alice's order must be visible to everyone, introducing information leakage concerns which we discuss below. #### Order Pools Bob wants to sell 500 ETH for USDC over the next 5,000 blocks, or 0.1 ETH per block. Charlie wants to sell 100 ETH for USDC over the next 2,000 blocks, or 0.05 ETH per block. Until Charlie's order expires in 2,000 blocks, Bob's and Charlie's orders will be grouped together in a *pool*. This ETH selling pool will sell ETH at a rate of 0.15 ETH per block for the next 2,000 blocks. Bob will get 0.1/0.15 ≈ 66% of the USDC the pool earns in this way. Charlie will get 0.05/0.15 ≈ 33% of the USDC the pool earns. #### Virtual Orders Every block for the next 2,000 blocks, the TWAMM has to buy 50,000 USDC worth of ETH on behalf of Alice and sell 0.15 ETH for USDC on behalf of the ETH selling pool. We can imagine that the TWAMM splits each of these two sub-orders into trillions of tiny sub-sub-orders we call *virtual orders* (in fact, it breaks them into an infinite number of infinitesimal virtual orders). The TWAMM then takes turns executing these virtual orders against its embedded AMM: first one of Alice's virtual orders, then one of the ETH selling pool's, then another of Alice's, and so on. #### Arbitrage Because Alice is buying much more ETH than the ETH pool is selling, the price of ETH on the embedded AMM will go up each block. When this price is sufficiently high relative to the prices for ETH elsewhere, *arbitrageurs* will buy that cheaper ETH on other exchanges and sell it on the embedded AMM, bringing its prices back in line with the market average and ensuring good execution for Alice. #### Order Expiry After block 2,000, Alice's order will be completely filled, as will Charlie's. Bob's order to sell ETH is still in effect for the next 3,000 blocks, and the TWAMM will continue to execute it at a rate of 0.1 ETH per block during that period. Barring any outside activity, this will push the price of ETH down on the embedded AMM over time, this time prompting arbitrageurs to bring prices back *up* once they get sufficiently out of line. #### Economics Because none of Alice, Bob, or Charlie are in a hurry to execute their orders, other market participants can infer that their orders represent less adverse selection than they otherwise would, and can provide them with low-price-impact execution. Because the TWAMM will then be the best place for people like Alice, Bob, and Charlie to trade, LPs on the TWAMM's embedded AMM are likely to interact with a high volume of uninformed flow like theirs. This helps LPs earn money from fees while reducing their relative exposure to adverse selection. ### Infinitesimal Virtual Orders We mentioned above that the TWAMM splits long-term orders into infinitely many infinitely small sub-orders. There are two reasons to do this: smoothness and efficiency. #### Smoothness The primary goal of the TWAMM is to execute its long-term orders smoothly over time so that they are executed for close to the prevailing time-weighted average price. As we decrease the size of the virtual trades, price movement on the AMM becomes less and less jagged. In the limit, with infinitely many infinitely small trades, price movement is perfectly smooth as virtual trades are executed. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--10e2a9dcdc/94d6ea01f34e8feecba6464d1213d34f/asset-https-cdn-sanity-io-images-dgybcd83--10e2a9dcdc.png) *See: https://github.com/para-dave/twamm/blob/master/splitting_exploration.ipynb* #### Efficiency Because the TWAMM is designed to be used on Ethereum, explicitly calculating transactions for multiple virtual trades per block would be prohibitively expensive. However, when we have infinitely many infinitesimal trades, we can compute the outcome for traders in a single computation, no matter how many blocks it has been since we last checked. #### Efficiency Because the TWAMM is designed to be used on Ethereum, explicitly calculating transactions for multiple virtual trades per block would be prohibitively expensive. However, when we have infinitely many infinitesimal trades, we can compute the outcome for traders in a single computation, no matter how many blocks it has been since we last checked. ## Implementation ### Lazy Evaluation The TWAMM treats virtual sub-orders as if they take place in the space *between* blocks, which is important to avoid sandwich attacks. To achieve this in a gas-efficient manner, the TWAMM uses *lazy evaluation*, computing the effect of virtual trades only when it is necessary to determine the outcome of an interaction. Every time a user interacts with the TWAMM (for example, by trading with the embedded AMM or by adding a new long-term order), the TWAMM retroactively calculates the effect of all the virtual trades that took place since the last interaction. Because these virtual trades are interacting only with the TWAMM's embedded AMM, the behavior of the TWAMM is completely deterministic between external interactions. Even if the TWAMM goes one million blocks between external interactions, the next time somebody interacts with it, it will be able to accurately calculate the results of all of the intervening virtual trades. Front-ends plugged into the TWAMM will be able to account for virtual trades that have not yet been represented on-chain by keeping track of the current block number and doing the TWAMM calculation themselves. ### Gas Optimizations #### Pooling Orders As demonstrated in the example, when we have multiple long-term orders in the same direction (i.e. selling ETH for USDC), we pool them together before splitting them into virtual orders. The TWAMM can then track balances using a version of the [billion-dollar algorithm](https://www.paradigm.xyz/2021/05/liquidity-mining-on-uniswap-v3/) used to track LP rewards in protocols like Compound and Uniswap. Technically speaking, there are always two long-term order pools per TWAMM, one for each asset: for example, the pool selling USDC and the pool selling ETH. It just might be that one or both of these pools is empty at any given time. #### Long-Term Order Expiration One complication arises when using order pooling in conjunction with lazy evaluation. Imagine Bob places an order to sell 100 ETH over the next 100 blocks, and Charlie places an order to sell 200 ETH over the next 200 blocks. Both orders are selling at a rate of 1 ETH per block. Suppose nobody interacts with the TWAMM for the next 150 blocks, at which point a new external interaction occurs. For the first 100 blocks after Bob and Charlie placed their orders, their orders were pooled into a common order selling 2 ETH per block. However, for the 50 blocks after that, Charlie's order was on its own, selling only 1 ETH per block. That means we have to do two separate trade calculations in order to find out what happened: one calculation for the results of the first 100 blocks, and one calculation for the final 50 blocks. In the worst case, if there had been orders expiring every block for the past 150 blocks, this would mean the TWAMM would have to process one trade per block, ruining gas efficiency. The simplest workaround for this is to limit the number of blocks eligible for order expiry: for example, the TWAMM could specify that orders are only eligible to expire every 250 blocks, or roughly once per hour. #### Canceling Long-Term Orders Users can cancel long-term orders at any time. In practice, this allows users to select the cancelation time for their order down to the block. This does not increase the gas burden for the system since the user who wants to cancel pays their own gas. ### Virtual Trade Math #### Definitions Assume it has been *t* blocks since the TWAMM last executed any virtual trades. For the sake of simplicity, assume that no long-term orders have expired, so that the pool selling X was selling $x_{rate}$ per block over the whole time period and the pool selling Y was selling $y_{rate}$ per block over the whole time period. Then the total amount of X sold over the period was $tx_{rate} = x_{in}$ and the total amount of Y sold over the period was $ty_{rate}=y_{in}$. Let's denote the embedded AMM reserves at the beginning of the time period as $x_{ammStart}$ and $y_{ammStart}$, respectively. #### Formulas After all virtual trades are processed the embedded AMM will have X reserves of $$ x_{ammEnd} = \sqrt{\frac{kx_{in}}{y_{in}}}\frac{e^{2\sqrt{\frac{x_{in}y_{in}}{k}}}+c}{e^{2\sqrt{\frac{x_{in}y_{in}}{k}}}-c} $$ where $$ c = \frac{\sqrt{x_{ammStart}y_{in}}-\sqrt{y_{ammStart}x_{in}}}{\sqrt{x_{ammStart}y_{in}}+\sqrt{y_{ammStart}x_{in}}} $$ From the constant product formula, we know: $$ y_{ammEnd}=\frac{x_{ammStart}y_{ammStart}}{x_{ammEnd}} $$ The pool selling X gets all of the Y that didn't end up in the embedded AMM — in other words, $$ y_{out} = y_{ammStart} + y_{in} - y_{ammEnd} $$ and similarly, $$ x_{out} = x_{ammStart} + x_{in} - x_{ammEnd} $$ ## Potential Attack Vectors #### Sandwich Attacks #### Description In a [sandwich attack](https://research.paradigm.xyz/MEV), an attacker, Atticus, sees that a trader, Trey, is about to do a trade on an AMM. Atticus sends two orders that *sandwich* Trey's, thereby extracting a profit from it. Imagine Trey sends an order to buy ETH with USDC to an AMM. Seeing this, Atticus places an order to buy ETH on the AMM before Trey does, driving the price up. Because he is paying fees to the AMM and incurring price impact, Atticus is losing money on this order. When Trey's order is filled, he buys the ETH at a higher price than he would have otherwise had to, because Atticus has pushed prices up. Trey's order drives the price up even higher. Now, Atticus sells his ETH back to the AMM. Because Trey has pushed prices on the AMM up since Trey bought, he sells for more than he bought and is able to realize a profit. This attack only makes sense for Atticus if he is able to guarantee that he will be able to sell his ETH back to the AMM immediately after Trey buys. Within a given block, this is possible if Atticus is a miner, makes a deal with one, or uses a service like [Flashbots](https://medium.com/flashbots/frontrunning-the-mev-crisis-40629a613752). #### Sandwiching and Virtual Orders At first glance, virtual orders may seem especially vulnerable to sandwich attacks because everybody knows they are coming. However, they are saved by the fact that they execute between \*\*blocks. An attacker wishing to sandwich the TWAMM's virtual orders would have to trade against the embedded AMM at the end of one block, causing the virtual orders to execute at a bad price between blocks, and then trade in the other direction to close the trade at the beginning of the *next* block. At present, there is no way for an attacker to guarantee that they will only trade at the end of a given block if they also get to trade at the beginning of the next block. When such *multi-block MEV* becomes more common, allowing traders to sandwich across multiple blocks, this may become more of an issue. ### Information Leakage The biggest tradeoff long-term traders are likely to encounter with the TWAMM is the *information leakage* they are exposed to when placing publicly visible orders, which are necessary due to the nature of Ethereum. If a trader places a sufficiently large long-term order, other traders may be tempted to *front-run* it, buying up the asset on the TWAMM's embedded AMM and elsewhere in order to sell it back to the trader later as the long-term order pushes prices up. Because users can cancel their long-term orders at any time, we expect overly aggressive front-runners to be exploited by other traders, keeping the overall impact of information leakage in check. #### Example Imagine Sally the spoofer has noticed aggressive front-running on the TWAMM. She buys one million USDC of ETH from a liquidity aggregator, pushing up prices across the market. Then she places a massive long-term order on the TWAMM to buy one hundred thousand USDC of ETH per block for the next 24 hours. Immediately, Frank the front-runner sees this order and buys one million USDC of ETH through the aggregator, pushing up prices even further. Sally sells back her ETH through the aggregator for a profit, pushing prices back down and leaving Frank with a loss. Finally, she cancels her long-term order before any of it is filled. ## Python Reference Implementation You can see a Python reference implementation of the TWAMM [here](https://github.com/para-dave/twamm). [This Jupyter notebook](https://github.com/para-dave/twamm/blob/master/twamm_demo.ipynb) demonstrates the behavior of the TWAMM with multiple offsetting long-term orders and arbitrageurs. For the sake of simplicity, this Python version does not implement gas optimizations like pooled orders or true lazy evaluation. ## Conclusion We've sketched out the design of the TWAMM, but our work is just beginning. If you are interested in working on this or similar problems, you can email [dave@paradigm.xyz](mailto:dave@paradigm.xyz) or [DM me on Twitter](https://twitter.com/messages/compose?recipient_id=1184231093576392704), or reach out to Uniswap Labs at [ideas@uniswap.org](mailto:ideas@uniswap.org). *Acknowledgments: *[*Sam Sun*](https://twitter.com/samczsun)*, *[*Georgios Konstantopoulos*](https://twitter.com/gakonst)*, *[*Michael Bently*](https://twitter.com/euler_mab)*, *[*Michael Kustermann,*](https://twitter.com/MMKustermann) [*Kevin Pang*](https://twitter.com/kevinxpang)*, *[*Hasu*](https://twitter.com/hasufl)*, *[*Sam Bankman-Fried*](https://twitter.com/SBF_Alameda)*, *[*Henry Prior*](https://twitter.com/priorupdates)*, *[*Tom Cadwell*](https://www.linkedin.com/in/tom-cadwell-404b49)*, *[*Alex Wice*](https://twitter.com/AWice)*, *[*Mewny*](https://twitter.com/mewn21)*, *[*Big Magic*](https://twitter.com/bigmagicdao)*, *[*Lily Francus*](https://twitter.com/nope_its_lily)*, Tarun Chitra, *[*Moody Salem*](https://twitter.com/sendmoodz?lang=en)*, *[*Noah Zinsmeister*](https://twitter.com/NoahZinsmeister)*, *[*Teo Leibowitz*](https://twitter.com/teo_leibowitz?lang=en) ## https://www.paradigm.xyz/writing/ethereum-reorgs-after-the-merge # Ethereum Reorgs After The Merge > There has recently been discussion about the possibility of miners adopting a hypothetical modified Ethereum client that allows them to essentially accept bribes to make a short reorg of the chain (the main use case for making such bribes being to attack DeFi protocols). There has recently been discussion about the possibility of miners adopting a hypothetical modified Ethereum client that allows them to essentially accept bribes to make a short reorg of the chain (the main use case for making such bribes being to attack DeFi protocols). In this post, we explain how this attack vector will be harder to execute post-ETH2 merge. ## What is the fork choice rule and why is it important? A **fork choice rule** [is a function](https://medium.com/@VitalikButerin/minimal-slashing-conditions-20f0b500fc6c), evaluated by the client, that takes as input the set of blocks and other messages that have been seen, and outputs to the client what the “**canonical chain**” is. Fork choice rules are required because there may be multiple valid chains to choose from (eg. if two competing blocks with the same parent get published at the same time). A **reorg** is an event where a block that was part of the canonical chain becomes no longer part of the canonical chain because a competing block beat it out. **Finality** is a situation where a fork choice rule so strongly favors a block that it is mathematically impossible (or at least economically infeasible) for that block to get reorged. In some fork choice rules (eg. Tendermint), reorgs cannot happen; the fork choice rule simply extends the existing chain by appending any blocks that have been finalized through BFT consensus. In other fork choice rules, reorgs are very frequent. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--e44afeecd9/c7ed76adc9fa2b95516e857144c2bec6/asset-https-cdn-sanity-io-images-dgybcd83--e44afeecd9.png) ## What's the status quo in Ethereum? In Proof of Work blockchains like Ethereum, we typically see the "longest chain rule" (or, more accurately, "highest-total-difficulty chain rule"). This means that when a client is shown 2 blockchains, it chooses the one with the highest total difficulty (i.e. the sum of the difficulty of all blocks in that chain). Assuming for the sake of this example that blocks can have difficulty of either 100 or 110, imagine the below scenario: ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--7caf6522b8/6ad55ab008d918bccf3699b7febecd58/asset-https-cdn-sanity-io-images-dgybcd83--7caf6522b8.png) 1. We start syncing from Block 1 with difficulty 100. 2. Block 2a and 3a arrive each with difficulty 100 and we insert them in our chain, for a fork of total difficulty 300. 3. Block 3b with difficulty 110 arrives which declares 2a as its parent, creating a fork of total difficulty 310. The fork-choice rule will notice that the "heaviest" chain is now the second fork and will switch over to it. This is 1-block reorg, since only block 3a was changed. Note that the blocks are not discarded altogether, since a new block may arrive that causes the fork-choice to switch back to the first fork. 4. Block 2b and 3c arrive, each with difficulty 110 creating a new fork of total difficulty 320! This means that the fork-choice rule will now use 2b instead of 2a and 3c instead of 3b which were the blocks that were in the last canonical chain. This is a 2-block re-org. You can see where this is going. If a new block 4a arrived declaring 3a as its parent, the fork-choice rule would switch over back to the first fork and so on. ## The impact of chain reorganizations Short reorgs happen all the time due to latency. Miner A and Miner B may find a valid block simultaneously, but due to how blocks propagate in the p2p network, a part of the network will first see A's block and another part will see B's block. If the two blocks have the same difficulty, there will be a tie, and clients either pick randomly or choose the earlier-seen block. Typically, the tie is eventually broken when some third miner C builds a block on top of either A's block or B's block, and the other block is forgotten. Occasionally, bad luck can lead to 2-5 block reorgs. Reorgs longer than that are almost always due to extreme network failure, client bugs, or malicious attacks. Short reorgs are not fatal, but they do still have some important detrimental consequences to the network: - **Node costs**: when a re-org happens there is some memory & disk overhead due to having to switch over to the new fork, possibly replaying transactions or state edits. - **User experience degradation**: the possibility of reorgs means that users need to wait longer before they can safely treat a transaction involving them as "confirmed". An important sub-case of this is businesses such as exchanges needing to wait longer before they accept a deposit. - **Transaction context uncertainty**: when a user sends a transaction, they have fewer assurances about what context that transaction will be executed in (eg. would the most recent N blocks be reverted?). Notably, this increases vulnerability of DeFi transactions to accidental failure, worse-than-expected trade results, or harmful MEV extraction. - **Increased vulnerability to 51% attacks**: in a longest-chain-rule-driven system, if the chain reorgs from B1 to B2, then the difficulty of B1 no longer contributes to securing the chain. Attackers no longer need to beat out *all honest miners*, they need to beat out *the portion of honest miners that don't get reorged*. If reorging is frequent, this makes the attacker's job significantly easier. ### The worst thing that can happen In the worst case, frequent reorgs can completely nullify a blockchain's settlement assurances and prevent it from progressing. Normally, the "incentive compatible" tactic for a block producer should be to extend the longest chain. But what happens if one particular block's post-state is exceptionally lucrative (in the sense that there are very high fees or MEV that can be extracted only by building a block directly after that block)? This issue was explored in the past in the context of [Bitcoin without the block reward](https://www.cs.princeton.edu/~arvindn/publications/mining_CCS.pdf) & [Selfish Mining](https://arxiv.org/pdf/1311.0243.pdf) and is being explored today in the context of [DeFi-related MEV in the Ethereum ecosystem](https://www.paradigm.xyz/2021/02/establishing-bounds-for-miner-revenue-in-eip-1559/). In these cases, there is a large incentive to try to "steal" the fees or MEV by competing with instead of extending the tip of the canonical chain. In the example below, block 1's post-state is exceptionally lucrative, and block 2a has already been mined. However, not 1 but 3 block producers have chosen to mine on top of block 1 instead of block 2a (in order to claim any MEV exposed after block 1), and this could extend to an arbitrary number of parties. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--4d9f55c702/4d5bb4e4ef94edfbb0d21f3be7de1ab2/asset-https-cdn-sanity-io-images-dgybcd83--4d9f55c702.png) For obvious reasons, such a pattern opens a wide door for malicious 51% attacks. We call miners engaging in such reorg-mining tactics "myopically rational" because the decision to do so can be rational in the short term. However, they have an explicit (stakers) or implicit (miners) long position on ETH (since fees and the block reward are denominated in ETH), which means that any such attacks that reduce user trust in Ethereum would be against their best interest, and thus not rational long term. ## Post-merge Ethereum with Proof of Stake In Nakamoto PoW, the blocks are solidified in the fork choice "serially". First, a block is mined, at which point a single competing block can potentially reorg it. If the block survives as part of the canonical chain, after (on average) 13 seconds some other miner builds a second block on top. At that point, a chain of two competing blocks is needed to reorg it. As more blocks get built on top, the difficulty of reorging the chain continues to increase, but slowly. The Ethereum beacon chain implements a PoS protocol called [Gasper](https://arxiv.org/abs/2003.03052) with a fork-choice rule called LMD-GHOST. Contrary to Nakamoto PoW, there are 2 roles during block production: - **Proposer**: A validator is tasked with proposing a block. - **Attesters**: A group of validators who vote on which block they consider the head of the canonical chain. Attester votes are called **attestations** and they give "weight" to a block. Controlling the attesters means controlling the fork choice rule. Every 12 seconds there is a "slot", which represents an opportunity to propose a block. For each slot, a shuffling algorithm pseudorandomly chooses a committee consisting of ~1/32 of all validators, where 1 validator in each committee is the proposer and the rest are the attesters. The attesters proceed to vote in parallel on blocks that they consider to be part of the canonical chain. Because committees are sampled pseudorandomly, attackers do not have a way to concentrate their validators into a single slot. Today, the Beacon Chain has 196k validators, meaning every slot has a committee with a size of 6125. As a result, **even single-block reorgs are extremely difficult, because an attacker controlling only a few validators has no way to beat the honest majority of thousands of attesters.** To gain some intuition on why this is true, let's see an example with 2 slots and 24 validators, where 9 of them are malicious. The validators get split into 2 committees, where due to the random shuffle, an adversary is unlikely to ever control >50% of any of the groups they get assigned to and cause a reorg. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--f2badbf168/f3b9d8bc08e0e59bfdbf0ed32a7f98f1/asset-https-cdn-sanity-io-images-dgybcd83--f2badbf168.png) More formally, the probability of a malicious actor with p% of stake controlling over 50% of an N-validator size committee follows [a binomial distribution](https://eth.wiki/sharding/Sharding-FAQs#how-is-the-randomness-for-random-sampling-generated) (where k = N/2): ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--3f2e8d135d/626eeae9856d3e483ab4900cb599a8ac/asset-https-cdn-sanity-io-images-dgybcd83--3f2e8d135d.png) Computing the probability for [various stake values](https://gist.github.com/gakonst/f7756debc09a75ce6c54eb526be14e52), we get the following table: ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--dc6fb776f5/9e89d7e21468cfd888eaa20c47091ca7/asset-https-cdn-sanity-io-images-dgybcd83--dc6fb776f5.png) We now understand that making a reorg directly requires the attacker to control close to 50% of all validators. There are more subtle attacks that are possible if an attacker has ~25-49% of attesters (see [this paper](https://econcs.pku.edu.cn/wine2020/wine2020/Workshop/GTiB20_paper_8.pdf), or [here](https://notes.ethereum.org/plgVdz-ORe-fGjK06BZ_3A#Fork-choice-by-block-slot-pair) for a quick summary). However, there are known fixes to these attacks that can be implemented unobtrusively, increasing security closer to an unconditional 50%. Finally, long reorgs are not possible because all blocks that are deeper than 2 epochs in the past are considered "finalized", i.e. it is impossible to revert past them. If an attacker caused two conflicting blocks to be finalized (e.g by controlling 67% of the stake), the system would need to fall back to social intervention to recover. ### The game theory of reorg strategy adoption Now that we've seen how reorgs work across different fork choice rules, it's worth going through a simple game-theoretic example to understand when it would make sense for a miner or validator to run software that executes reorgs to profit. We can informally describe each scenario with a payoff matrix, where "defect" means "download and use the software that implements reorgs". The payoffs are "myopic", not taking into account long-term consequences. #### Nakamoto Proof of Work In longest-chain PoW, short-range reorgs can be done probabilistically with even a small portion of the validator set. There will always occasionally be blocks with exceptionally lucrative post-states such that even a 1-10% success rate is worth trying to compete with an existing child of that block. The miner could either be a medium-sized pool banking on the possibility that they will find the next 2-3 blocks in a row, or they could send some portion of their revenue into an anyone-can-claim contract to bribe *others* running the same software to build on their chain and help it overcome the existing canonical chain. As a result, some miners may be tempted to run reorg clients. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--bd466e61d1/2e85afddf45139dc1b7e607c80a32ecb/asset-https-cdn-sanity-io-images-dgybcd83--bd466e61d1.png) #### Gasper In Gasper, reorgs of 1-64 slots are possible, but require the attacker to control a large portion of the entire validator set (because they cannot concentrate their stake in a specific slot, so they need to be large enough to have enough stake randomly selected in the slot range they want to attack). Adoption of reorg-mining software is useless unless a very large number of other validators also adopt it at the same time. Hence, if 51% of validators have even the slightest level of altruism or laziness, no one running reorg-mining software is a stable equilibrium. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--45d3db1732/1d2db959ec247c01e6f932e76fd0d75c/asset-https-cdn-sanity-io-images-dgybcd83--45d3db1732.png) #### Tendermint In Tendermint, the story is even cleaner: reorgs are impossible outright, and any violation of single-slot finality would require 1/3+ of validators to be slashed. Similar to the Gasper case, this also means that no one running reorg-mining software is a stable equilibrium. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--98d9595516/201134220bb07faf83c05bb5ea07f1ba/asset-https-cdn-sanity-io-images-dgybcd83--98d9595516.png) As we can see from the above, while adoption of "reorg geth" is possible in all cases, fork-choice rules based on some notion of parallel attestation have honest equilibria which are more stable than the equilibria in Nakamoto fork-choice. ## Takeaways The most effective prevention measure in the context of Ethereum is to further speed up work on the merge, in particular, to quickly achieve the credible capability of making an "emergency merge" which would transition the chain to PoS. Rushing the merge would have high risk and might break infrastructure, but a *credible* commitment to do it anyway if many miners start reorg-attacking the chain would align incentives against such behavior. The time close to the merge is the time of greatest risk because miners are still in charge of the system but their time horizon decreases. However, two factors mitigate this risk: 1. Ethereum miners are often at the same time (i) miners of other blockchains, and/or (ii) Ethereum community members in other capacities, so some motivations for good behavior continue to exist. 2. As the merge approaches, the difficulty, cost and risk of doing an emergency merge also decrease. Months before the merge's intended date, an emergency merge would be highly disruptive. Two weeks before the merge's intended date, it would be a parameter setting to clients that validator operators have already downloaded. Post-merge, reorg validating will become much less of a problem, because single attesters or small groups of attesters cannot reorg a block on their own. Reorg-attacking successfully requires solving the hard coordination problem of getting a large portion of validators onboard at the same time. However, some small risk remains. If it is desired to improve security further, then Ethereum can either adjust the fork choice rule further to increase reorg attack requirements to the 50% theoretical maximum or find a way to move toward single-slot-finality consensus outright. *Acknowledgments: Thanks to Dan Robinson, Anish Agnihotri, Kevin Pang, Dave White, and MEVIntern for comments on drafts of the post.* ## https://www.paradigm.xyz/writing/expanding-our-research-team # Expanding our Research Team > At Paradigm, we have always been focused on finding special people, whether it’s the entrepreneurs we back, or the people we bring onto our team. At Paradigm, we have always been focused on finding special people, whether it’s the entrepreneurs we back, or the people we bring onto [our team](https://www.paradigm.xyz/team/). We value slope over intercept, personal attributes over specific experience, and achievements over credentials. We’ve followed this philosophy when assembling our Research team, a unique group of crypto researchers and protocol developers who work with our investment team and portfolio to advance the frontier of crypto: - We invented the Research role for [Dan Robinson](https://www.paradigm.xyz/team/danrobinson/). I’ve known Dan for over 20 years, and in the early days of Paradigm, we knew we wanted his brilliant mind on the team in some way. The role we designed together was unusually unstructured for a typical investment firm, but has proven to be appropriate for the deeply technical and fast-evolving nature of crypto. - Then, we added [Georgios Konstantopoulos](https://www.paradigm.xyz/team/gakonst/). A brilliant engineer and researcher hailing from Greece, Georgios kept showing up as a star engineering consultant at many of our portfolio projects. - When a pseudonymous anime character [started](https://twitter.com/delitzer/status/1230052030950998021) [finding](https://twitter.com/RyanSAdams/status/1291085648733110274) [all](https://twitter.com/BenDiFrancesco/status/1230167830143918081) [the](https://twitter.com/scott_lew_is/status/1229981477619761153) [bugs](https://twitter.com/koeppelmann/status/1232055121300852736), we knew we had to track down the legendary [samczsun](https://www.paradigm.xyz/team/samczsun/). - When we had a Uniswap-related research question nobody at the firm could solve, we [put it out into the world](https://research.paradigm.xyz/uniswap-fees) as an open problem. [Dave White](https://www.paradigm.xyz/team/davewhite/) came to us with a solution and joined the team soon thereafter. - [Anish Agnihotri](https://www.twitter.com/_anishagnihotri), our newest researcher, grew up as a crypto-native in Toronto and had [his first crypto wallet at age 11](https://twitter.com/_anishagnihotri/status/1369854323052675074?s=21). Prior to Paradigm, Anish was [shipping](https://twitter.com/jonitzler/status/1409349887012057090?s=20) [new](https://twitter.com/jzlegion/status/1365941198599294978?s=20) [products](https://twitter.com/Iiterature/status/1355278369542254598?s=20) [faster](https://twitter.com/mikedemarais/status/1396022099786047488?s=20) [than](https://twitter.com/jordanfrankfurt/status/1405622399597432835) [most](https://twitter.com/smsunarto/status/1412587844950904833?s=20) [companies](https://twitter.com/_anishagnihotri/status/1407252425292107776?s=20). Having a research institution embedded within an investment firm began as an experiment, but it’s become a key part of our ability to contribute to our portfolio investments and the crypto community. In addition to working closely with our investment team and our portfolio on projects like Uniswap v3 and Flashbots, our Research team has a mandate to help move the crypto world forward, whether by publishing new ideas like [everlasting options](https://www.paradigm.xyz/2021/05/everlasting-options/), raising the profile of topics like [miner-extractable](https://www.paradigm.xyz/2020/08/ethereum-is-a-dark-forest/) [value](https://www.paradigm.xyz/2021/02/mev-and-me/), or advancing the state of the art in [smart](https://www.paradigm.xyz/2020/09/escaping-the-dark-forest/) [contract](https://www.paradigm.xyz/2021/04/uncovering-a-four-year-old-bug/) [security](https://www.paradigm.xyz/2021/04/paradigm-ctf-2021-swap/). Now that we’ve seen our experiment around Research prove out beyond our expectations, what should the group and its function look like three years from now? Five years? Ten? Like Paradigm itself and crypto more broadly, the answer has yet to be written and the potential excites us. Most importantly, we know we want to invest further in what’s been working and put structure in place to allow the Research team to continue to grow. As part of that structure, **we are excited to announce that Dan Robinson will be taking on an expanded role as our Head of Research**. He will be responsible for stewarding the broader vision for the research function, as well as growing the team with more world-class talent. Just as we think about Paradigm’s potential on a generational timescale, we think our Research team has the potential for a lasting legacy. If you’re a talented researcher or protocol developer building your career in the crypto industry, please reach out to Dan at [dan@paradigm.xyz](mailto:dan@paradigm.xyz). ## https://www.paradigm.xyz/writing/creators-communities-and-crypto-part-ii # Creators, Communities, and Crypto Part II > Discussion between Jesse Walden, Blake Robbins, and Fred Ehrsam about the future of Creators, Communities, and Crypto. *This post originally appeared on* [*fehrsam.xyz*](https://www.fehrsam.xyz/blog/creators-communities-and-crypto-part-ii) Almost exactly one year ago, Jesse Walden, Blake Robbins, and I speculated about the future of [Creators, Communities, and Crypto](https://www.fehrsam.xyz/blog/creators-communities-crypto). Little did we know all the last year would bring, especially with NFTs reaching the mainstream. We got together for another conversation, revisited what’s happened over the last year, and speculated on what’s yet to come. Condensed transcript below. **Listen here:** [Spotify](https://open.spotify.com/show/7u1gzOuS7DOTm4fKotk0BA) | [iTunes](https://podcasts.apple.com/us/podcast/creators-communities-and-crypto-part-ii/id1518666851?i=1000525942131) | [Overcast](https://overcast.fm/+c949c0ShA) | [Breaker](https://www.breaker.audio/fred-ehrsam/e/89394083) **Fred:** Great to see you both again. Almost exactly one year ago, we talked about how crypto might enable creators and communities. A lot has happened since then. What have been the biggest developments? **Blake:** The last time we talked, all of us were sitting here thinking what would status symbols look like if you were early to a creator or you wanted to support a creator? What could digital merch look like? And it turns out it was actually just digital art. You can take a cynical view and say, "It's pure hype, you're buying a random NFT, it'll have no utility", but as I continue to dig, there are some really cool elements around this idea that you can create economic alignment. **Jesse:** I think what happened in the last year was three big inflection points, some unique to crypto, others more general. The first is that **2021 is the year that investing became mainstream culture.** And that wasn't unique to crypto: it was WallStreetBets, GameStop, etc. I think it taught people a lot about investing, internet communities, and making money together. That paved the way for the second major inflection point: culture then became investing. With NFTs, you could now invest in culture via digital art. The next step is the complete synthesis of the two, where investing is culture and culture is investing. **Investing becomes a team sport that you play with your friends on the internet. What's exciting is people now understand crypto is the right stack for doing that.** Crypto is inherently social. The legacy financial system is not. **Fred:** Blake, how have the traditional creators looked at this whole phenomenon? How do you see them responding? **Blake:** If we've learned anything over the past year or two, it's that there’s more and more power going towards these creators. Let's use OnlyFans as an example. We've seen that blow up because it unlocked a new way of monetization. I think we're going to see that happen here with NFTs. We haven't seen a big creator really nail it yet, and I'm curious to see if and how someone will do it. Because if they do it right, there is no limit. **Jesse:** **One really cool thing that started to happen is we started to see collector DAOs form around NFTs.** Edward Snowden sold an NFT for $5 million. The purchaser was not an individual but a group of people who pooled money using a smart contract on Ethereum.  What we'll begin to see happen is groups starting to tokenize themselves. And so now you have this group of fans of a work, creating a token for that work, and that may function like a social token for the creator or for the community that's excited by the stuff that they make. One possibility to get content creators involved is that maybe they aren’t the issuers out of the gate. Maybe the fans take it into their own hands and that's how social tokens get off the ground. **Blake:** I hadn't really thought about it in that context, but you can imagine how ‘stan’ culture might play into this. For example, Beliebers might come together to form a DAO and buy the NFT of Justin Bieber's newest song. **Fred:** Jesse, do you have intuitions around other ways multiplayer investing or “investing as a team sport” might evolve? **Jesse:** If you play that idea out to its logical extreme, it puts both you and me out of a job. I think **investment clubs end up dictating what people pay attention to on the internet** because it’s no longer who has the most retweets or who has the most attention. Rather it's, who has the most skin in the game? Who invested in what? That'll expand from NFTs to internet products and services. **Fred:** We already see some examples of this today. The modern art market works like this. The economic backing of an artist tends to mean that it rises to the top in terms of cultural awareness. Crypto might create a really strong form of that economic value to cultural value feedback loop. **Blake:** I was younger at that time, but I remember there were these sites where you basically had to earn a reputation - either you uploaded a certain amount or you proved your worth in some way to get into these exclusive torrenting sites. I imagine that we will see similar dynamics here happen with DAOs. **Jesse:** **Membership in these DAOs will become more sophisticated. Right now for the most part, it's just capital. But to keep the quality bar high and these communities fun, it will have to be more than capital.** There's a number of startups that are trying to essentially help crypto communities raise the bar for their memberships, creating scavenger hunts or Easter eggs that people need to find. **Fred:** You can see this in venture investing already today. It's just not tokenized. In other words, if you're early and investing in one or two startups, then others are likely to want you to have access to invest in their startups early. **Blake:** You can imagine an artist actually choosing who they want to sell it to. For example, we want to sell it to PleasrDAO even if they aren’t the highest bid because we know there’s just a lot of value in working with them. **Fred:** **Entertainment and investing are becoming part of the same package. Sneakers started mostly as a status symbol and now are making its way towards being financialized.** The Yeezys that Kanye wore during the Grammys were purchased and now are being sliced up such that many people can invest in them. I would argue this is true of politics. You tune into an election debate and it feels like you're watching a boxing match with sports commentary as much or more than what is the substantive outcome for the future of a nation-state and its policies. **Jesse:** It's an especially potent combination in markets because whether it’s making money or losing money - **having skin in the game elicits very powerful emotions.** **Fred:** We talked about this before, where coupling economic alignment with these communities around different creators or projects just effectively turns them into highly motivated distribution. Bitcoin has shown that for 10 years now, and I think we're just starting to see that in the NFT space. **Blake:** You both have a view from deep in crypto, but I'm thinking about it from the lens of a YouTube creator, because I imagine at some point they should just mint NFTs for all the content they're producing. But do you think they'll still use centralized platforms as distribution? **Fred:** I think we know where we're going in the long-run, which is that **crypto allows creators to directly interface and own their followings independent of any platform. We're just at the beginning of NFTs. It’ll be interesting to see people build out platforms where NFTs are the basic media building blocks.** That’s where you get totally crypto-native platforms that build on NFTs as the primary building block, and we're in year 0.5 of 10+ years of that. **Jesse:** In the short term, the successful Web 2 creators are likely to do better creating NFTs that are not the original work that they're posting elsewhere, but rather thinking of NFTs from first principles, maybe as a new kind of digitally native merch that's distinct from the YouTube video. I do agree with Fred that, long run, **every single piece of media on the internet is going to be incepted as an NFT. And there will be markets for it.** I don't think we get there by YouTube just slapping on an NFT widget to their existing platform. I think it will be more bottom-up emergent. **Fred:** To take that even further, one concept embedded in this is that **blockchains will be the single source of truth in digital worlds.** So quite literally every piece of digital media will likely be minted at some point in time, whether it's because you want to see when it was originally created, who owned it, how it morphed over time. The second thing embedded in that is we're very early in the form factors of NFTs, and there will be many that work. We're mostly in a shoe-horning phase today, like the beginning of any new technology. And we're just starting to play with some of the interesting ways in which NFTs can create novel forms of media, art or otherwise. CryptoKitties breeding, you could argue, was one of the earliest versions of this novel mechanic where you take two digital assets and then you create a new unique one. I'm sure there will be others. Gaming and in-game economies seem especially likely. **Jesse:** Tim Sweeney, the founder of Epic Games, is on record talking about **the metaverse as something that can only exist once you have a truly digitally native property rights system. Blockchains are exactly that.** We're now starting to see the collision of the metaverse and crypto native assets. I think that the synthesis of these two things is inevitable and will happen sooner than people think. **Fred:** There's a really good recent podcast of Tim’s where he talks about what infrastructure is necessary for the metaverse. If you listen to the whole thing, it's just like a red light flashing, "this is crypto, this is crypto," in a great way. **Blake:** Gaming specifically has had these issues and these centralized platforms really do own the assets. So it's not shocking that they understand it probably better than most, because users are saying, "I bought this skin and I can't transfer that into another game?" That feels inevitable at this point. **Fred:** One thing that might be underappreciated is how much **kids have grown up in these virtual worlds, so these ideas might just be a lot more intuitive and normal to them.** Not just that, but kids understanding finance, kids super into creating their own culture and being a part of that more and more directly in any way they can. **Jesse:** One of the really remarkable things that’s happened since our last discussion is that, in addition to kids who were native to crypto or native to gaming, **a lot of other people also showed up at the door of crypto and learned behaviors that were completely esoteric six to twelve months ago.** Like installing a crypto wallet in your browser, on your phone and the concept of signing transactions and paying gas fees, these are things that Web 2 people sort of sneered at, yet millions of people have figured it out. **Fred:** MetaMask announced 5 million monthly active users the other day. That's starting to get pretty real. And even some of these experiences like TopShot where people debate if that’s really crypto or not. The answer, I think on some level, is that most things which use crypto are normalizing it for everyone. **Jesse:** I think that that's where it ultimately goes, but it is interesting how it seems **some people have gravitated towards the full crypto experience, all the jankiness included, because it's the real thing.** It'll be interesting to see in a year from now where that conversation is, whether people want the abstraction or they want a sense of really owning their stuff and having it go with them wherever they interact. **Fred:** One other dimension people might under-appreciate is how automated getting paid for various actions on the internet might become as crypto proliferates. If you're an influencer on Instagram, currently you do various paid partnerships directly with a brand. **In the future, it might just be you take a picture with a product in it, irrespective of whether or not you meant to, the image is scanned, and you get paid automatically.** If you're a software engineer and you contribute code to a crypto protocol, the very same thing may happen. There's no employment agreement.  **At some point, kids are just going to stop opening bank accounts and just have a crypto wallet.** It's so much better. It's like, “Here's a little downloadable widget and it works with everything on the internet.” **Blake:** In a crypto context, everything is an API and your data - what you actually share, what you opt in to, all these choices you make - can be stored with you and you can share your friend graph if you want to for certain applications. This is really empowering in a lot of ways. **Fred:** I think people have not yet internalized that crypto or **blockchains will be the single source of truth for everything in digital life, and digital life is becoming most of life.** And that includes bank account, reputation, identity, all those form factors get combined. **Jesse:** To end, there were some ideas we talked about a year ago that haven't happened yet. One is tokenizing physical goods. The other is social tokens. We're still trying to figure out product-market fit around those. **Tokenizing physical goods is definitely going to happen.** The logistics of the physical world are still not entirely wired up to the blockchain yet, but they will be. **The way social tokens will come to fruition is essentially through these investment clubs buying NFTs** from creators and then creating communities around those NFTs wherein the community token or access to that community ends up becoming something akin to a social token for the creator. **Blake:** On social tokens, I don't have a concrete way of how it will happen, but I think at some point, **people will hold these tokens whether earned or bought, and it’ll unlock access to communities or access to creators, or both.** The physical goods stuff is really limited by the logistics side of it. That gives me a little bit of pause, but it does feel inevitable that at some point you can just own a fraction of a Yeezy. That just seems like a no-brainer. **Fred:** **Tokenizing physical goods will be like Webvan in the early internet. It's not the thing that's going to work first, but it will work later.** I think we'll see people try that idea again soon. **Social tokens: It sounds like we're all still high conviction!** It’ll be exciting to see what happens with crypto and creators after another year. ## https://www.paradigm.xyz/writing/uniswap-v3-the-universal-amm # Uniswap v3: The Universal AMM > Uniswap v3 allows liquidity providers to provide custom amounts of liquidity in selected price ranges. This unlocks tremendous capital efficiency gains for liquidity providers who can manually adjust their exposure. ## Introduction Uniswap v3 ([paper](https://uniswap.org/whitepaper-v3.pdf)) allows liquidity providers to provide custom amounts of liquidity in selected price ranges. This unlocks tremendous capital efficiency gains for liquidity providers who can manually adjust their exposure. But this feature also greatly expands the design space for *automated* liquidity provision. Any static AMM can be approximated by a custom liquidity provision strategy involving multiple positions on Uniswap v3. We can visualize the liquidity provided by any AMM as a curve in "tick space." Applying this method to existing AMMs like Curve, Balancer, and the logarithmic market scoring rule (LMSR) shows how those AMMs concentrate their liquidity across different prices, revealing the unique "liquidity fingerprint" corresponding to each of those AMMs. Follow-up work will explore how strategies like this can be efficiently and accurately approximated in practice on Uniswap v3. #### Automated market makers This paper assumes you are familiar with automated market makers between two assets $X$ and $Y$ that are defined as a trading function (see [paper](https://doi.org/10.1145/3419614.3423251)), meaning a relationship between its reserves $x$ and $y$. We will only consider two-asset pools. For ease of comparison, let's define the constants in each of these formulas in terms of $s$, where $s$ is the quantity of $x$ when $x = y$. You can loosely think of $s$ as the number of \`\`shares" that liquidity providers have in that pool. For example, the constant product formula used by Uniswap v2 (ignoring fees) can be described with the formula $x \\cdot y = s^2$, with $s$ roughly corresponding to the total supply of liquidity tokens. We will use $P$ to refer to the price of asset $X$ in terms of asset $Y$. $P$ is equivalent to the negated derivative of the reserves curve, $-\\frac{dy}{dx}$. (For more background on thinking about AMMs in terms of derivatives, see the [YieldSpace paper](https://yield.is/YieldSpace.pdf)). #### Uniswap v3 In Uniswap v3, anyone can create a position to provide some amount of liquidity—$L$—within a price range between two ticks. Tick indexes ($t_i$) are logarithmic in price, and specify the lower and upper prices at which that position provides liquidity. As shown in the [Uniswap v3 whitepaper](https://uniswap.org/whitepaper-v3.pdf), this is the trading function that describes the relationship between the reserves of a single Uniswap v3 position while its liquidity is in range: $$ (x + x_{offset})\cdot (y + y_{offset}) = L^2 $$ $$ x_{offset} = \frac{L}{\sqrt{p_{upper}}} $$ $$ y_{offset} = L \cdot \sqrt{p_{lower}} $$ ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--e62fd1237a/1dcf1afb2da5f8f629952c2058cc6f91/asset-https-cdn-sanity-io-images-dgybcd83--e62fd1237a.png) If a strategy involves providing liquidity in multiple positions, these definitions defined in terms of total reserves will no longer apply. It would therefore be helpful to find a *local* definition for liquidity, that describes liquidity in its conventional sense: the pool's resistance to price impact when someone is trading with it. As shown in Appendix A, it turns out that $L$ can also be defined as the rate of change of $y$(the reserves of the $Y$ token) for a given change in $\\sqrt{P}$ (the square root of the price of the $Y$ token in terms of the token): $$ L = \frac{dy}{d\sqrt{P}} $$ ## Simulating other curves How can liquidity providers use Uniswap v3 to simulate a custom curve? One intuitive way to do so is to create many different positions, with a custom amount of liquidity in each: ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--1d1eaeda50/8f0330b5c2abbb9815a18364c6384402/asset-https-cdn-sanity-io-images-dgybcd83--1d1eaeda50.png) The more narrow these "slices" are, the more accurately this will simulate the target curve. For this post, we will treat tick space as infinitely divisible, and imagine that a liquidity provider is allowed to provide any arbitrary function $L(t_i)$ to provide that amount of liquidity at any tick. Graphing the $L(t_i)$ function shows us the "liquidity fingerprint" of these other AMMs. (For convenience in defining functions of ticks, we will define as $t_i$ as $\\ln(P)$, as if our tick size was $e$.) Appendix B shows the steps to derive this $L(t_i)$ function from a given invariant. #### Uniswap v2 The behavior of the reserves in [Uniswap v2](https://uniswap.org/whitepaper.pdf) can be described with the following equation: $$ x \cdot y = s^2 $$ ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--edaf34e7a4/9f16da1c214690224b454663d7f28384/asset-https-cdn-sanity-io-images-dgybcd83--edaf34e7a4.png) The liquidity fingerprint of this reserves curve is a flat line: $$ L = s $$ To simulate this curve in Uniswap v3, we can simply create a single position with liquidity $s$, and set our tick boundaries to $t_{min}$ and $t_{max}$. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--3e5f25be09/39490dddaa4fe45d7706d49adc1ec964/asset-https-cdn-sanity-io-images-dgybcd83--3e5f25be09.png) #### Curve (with constant chi) The formula used by Curve is described in the [StableSwap whitepaper](https://curve.fi/files/stableswap-paper.pdf). That paper first describes its invariant in terms of a constant amplification factor, $x$. Their formula can be written as: $$ 2 \chi s (x + y) + xy = 4 \chi s^2 + s^2 $$ This reserves curve (with Uniswap v2 shown for comparison) looks like: ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--2fd248bc4f/65ea8b8f45f41db42919907d40ba16c3/asset-https-cdn-sanity-io-images-dgybcd83--2fd248bc4f.png) It turns out that with a constant $X$, the liquidity provided by this formula is *exactly equivalent* to a single Uniswap v3 position, if we set $L = s \\cdot (2\\chi + 1)$), and set the upper and lower prices to ${\\left(\\frac{2\\chi + 1}{2\\chi}\\right)}^2$ and ${\\left(\\frac{2\\chi}{2\\chi + 1}\\right)}^2$. This means that we can simulate this formula with a single position in Uniswap v3: ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--528df2ff04/2929e6dacbcdd26abd00b88348e05a62/asset-https-cdn-sanity-io-images-dgybcd83--528df2ff04.png) Curve in fact uses a non-constant $X$, which is defined (using our terminology) as $\\frac{Axy}{s^2}$, where A is a constant amplification factor. This leads to a more complicated equation that is harder to represent with a closed-form liquidity function. In follow-up work, I'll show how to approximate this and other curves numerically. #### Balancer The reserves in a two-asset [Balancer](https://balancer.fi/whitepaper.pdf) pool can be described by this invariant, where $w_x$ is the weight of the $X$ asset and $w_x$ is the weight of the $Y$ asset (or $1 - w_x$): ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--eb69add056/6b6ba44422014602a0f8de50925ee209/asset-https-cdn-sanity-io-images-dgybcd83--eb69add056.png) $$ x^{w_x} \cdot y^{w_y} = s $$ In liquidity space, this corresponds to an exponential function: $$ L(t_i) = s \cdot (2 {w_x}^{w_y} {w_y}^{w_x}) \cdot e^{(w_x - \frac{1}{2}) t_i} $$ ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--839bfa075c/ecd1785f13543815a37dffa0f25dff6e/asset-https-cdn-sanity-io-images-dgybcd83--839bfa075c.png) Intuitively, when asset $X$ is weighted less heavily, more of the pool's liquidity is reserved for lower prices of asset $X$. This makes sense, because at any given time, liquidity reserved for lower prices is effectively buy orders for asset $X$, so it is currently held in asset $Y$. #### Logarithmic market scoring rule The [logarithmic market scoring rule](https://mason.gmu.edu/~rhanson/mktscore.pdf) (LMSR) is one of the first and most widely studied automated market makers. The two-asset case is best known for its application to a binary prediction market (i.e., between YES and NO shares), where the price of the two assets (in cash) adds up to 1. Typically, LMSR is described in terms of the rule for market-making between each asset (YES and NO) and cash. We could instead describe it in terms of the rule for market-making between one asset and the other. If we do that, then as explained [here](https://docs.gnosis.io/conditionaltokens/docs/introduction3/), the reserves can be described by this invariant: $$ 2^{-\frac{x}{s}} + 2^{-\frac{y}{s}} = 1 $$ The reserves curve for this formula looks like: ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--bbdd2f9a95/6ec608f0d59998ded1e83cd039bf8572/asset-https-cdn-sanity-io-images-dgybcd83--bbdd2f9a95.png) When transformed into tick space, the liquidity fingerprint of this curve is shaped like—you guessed it—the hyperbolic secant function: $$ L(t_i) = \frac{s}{\ln(2)} \cdot \operatorname{sech}{\left(\frac{t_i}{2}\right)} $$ ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--8173bd46fb/de9c28f49be46a212bbbb2d2188c715a/asset-https-cdn-sanity-io-images-dgybcd83--8173bd46fb.png) As you can see, LMSR concentrates more of its liquidity closer to tick 0 (the price of 1). In prediction markets, when YES and NO shares are equal, that implies a probability of 50%. So LMSR concentrates more liquidity to support probabilities around 50% than to support more extreme probabilities. Appendix B shows how this liquidity fingerprint can be computed. ## Future work This paper showed how several popular AMMs could be simulated using Uniswap v3, and showed how graphing curves in liquidity space provides insight into their unique \`\`liquidity fingerprints". However, there are several limitations that need to be overcome before Uniswap v3 can be used to simulate most of these AMMs: - Ticks are not infinitely divisible, and liquidity providers have to approximate this curve using the granular ticks available. - The gas cost of minting and burning is proportional to the number of ticks updated, so providing liquidity at custom levels across all of tick space would be insurmountably inefficient. - Finally, not every useful AMM can be easily represented as a function in liquidity space. Future work will demonstrate some techniques for getting around these problems using numerical approximation, as well as some smart contract tricks to make custom liquidity provision much more gas-efficient. ## Appendices #### Appendix A: Definition of liquidity We can show that in Uniswap v3, the derivative $\\frac{dy}{d\\sqrt{P}}$ is equal to $L$. We start with the trading function (while the position is in range): $$ (x + x_{offset})\cdot (y + y_{offset}) = L^2 $$ Solving for $x$(to use later): $$ x = \frac{L^2}{y + y_{offset}} - x_{offset} $$ Solving for $y$: $$ y = \frac{L^2}{x + x_{offset}} - y_{offset} $$ Finding $P$ as a function of $x$ by taking $-\\frac{dy}{dx}$: $$ P = \frac{L^2}{\left(x + x_{offset}\right)^2} $$ Solving for $\\sqrt{P}$ instead: $$ \sqrt{P} = \frac{L}{x + x_{offset}} $$ Substituting for $x$ and simplifying: $$ \sqrt{P} = \frac{y + y_{offset}}{L} $$ Solving for $y$: $$ y = L * \sqrt{P} - y_{offset} $$ Taking the derivative: $$ \frac{dy}{d\sqrt{P}} = L $$ #### Appendix B: Example derivation This appendix shows how to go from an AMM formula defined as a trading function to a liquidity curve in tick space. We'll use LMSR as an example. As shown in Appendix A, liquidity can be defined as the rate of change of $y$ with respect to $\\sqrt{P}$. Since $P$ is simply -1 times the derivative of $y$ with respect to $x$, we know that liquidity can be computed as: $$ L = \frac{dy}{d\sqrt{-\frac{dy}{dx}}} $$ We start with the AMM defined as an invariant: $$ 2^{-\frac{x}{s}} + 2^{-\frac{y}{s}} = 1 $$ Solving for $y$: $$ y = -s \log_2{(1-2^{-\frac{x}{s}})} $$ Taking the derivative and negating it to get the price (of asset $X$ in terms of asset $Y$) as a function of $x$: $$ P_x(x) = -\frac{dy}{dx} = \frac{1}{2^{\frac{x}{s}}-1} $$ We then need to find the formula for that same price, but as a function of $y$ rather than $x$. Since this curve (like the others described in this post) is symmetrical between $x$ and $y$, we can easily get the price as a function of $y$ by replacing $x$ with $y$ and taking the reciprocal: $$ P_y(y) = 2^{\frac{y}{s}} - 1 $$ Next, we invert this to find $y$ as a function of $P$, and then rewrite it as a function of $\\sqrt{P}$. $$ y_{\sqrt{P}}(\sqrt{P}) = s \log_2{(\sqrt{P}^2+1)} $$ Then we take the derivative with respect to $\\sqrt{P}$: $$ L(\sqrt{P}) = \frac{dy}{d\sqrt{P}} = \frac{2s}{\ln(2)} \cdot \frac{1}{\sqrt{P}+\frac{1}{\sqrt{P}}} $$ Finally, we convert to tick space by rewriting this as a function of tick index $t_i$ ($ln(P)$): $$ L(t_i) = \frac{1}{\ln(2)} \cdot \frac{2}{e^{\frac{t_i}{2}}+e^{-\frac{t_i}{2}}} = \frac{s}{\ln(2)} \cdot \operatorname{sech}{\left(\frac{t_i}{2}\right)} $$ ## https://www.paradigm.xyz/writing/how-mistx-uses-flashbots-bundles-to-provide-frontrunning-protection # How mistX uses Flashbots bundles to provide frontrunning protection > Examining mistX, a "gasless exchange" leveraging Flashbots bundles for transaction. After covering CowSwap [on Uncommon Core](https://www.youtube.com/watch?v=FvFxKVaSloA) a few days ago, today I looked at another **"gasless exchange"** - [mistX](https://app.mistx.io/#/exchange). When making a gasless trade, the trader does **not pay a transaction fee to the miner**. In CowSwap, a relayer pays the Ethereum gas fee on behalf of the trader and recoups it from the trade execution. MistX uses a different approach by relying on **Flashbots bundles**. In this post, we will unpack a [typical mistX transaction](https://etherscan.io/tx/0x669796b2b32c95421ce493975d7796561e5d98c79fe6de9c0f8e41911bbded1a) to learn more about how their exchange works. Before we start, what is this transaction supposed to do? ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--fe47142107/3a337142d5d43d7757fa44cb70c490bb/asset-https-cdn-sanity-io-images-dgybcd83--fe47142107.png) The intent of the trader can be seen in the decoded input data (1): They wanted to swap 82.9 MIST for at least 9,234 USDC. In practice, they received 9,327 USDC (2). ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--bace28588d/65449a2af0855e8790b43dbfea966c51/asset-https-cdn-sanity-io-images-dgybcd83--bace28588d.png) mistX’s main innovation is to **publish transactions exclusively as a bundle in Flashbot’s private mempool** instead of in Ethereum’s public mempool, where it would be exposed to hungry sandwich attackers. Etherscan tags transactions that their node did not see on the public p2p layer before they were included in a block as “private” (3). A Flashbots bundle must be - **executed atomically** - meaning either entirely or not at all - **mined at the top of a block** (possibly with other non-competing bundles) We can see that this was indeed the case, as the transaction has position 1 in the block (4). This property ensures that Flashbots miners **can’t frontrun the trade**, even if a sandwich attack would be profitable. The goal is that users can safely set a non-zero slippage tolerance to ensure timely inclusion even in a volatile market. In practice, traders are still trusting Flashbots miners not to sandwich a bundle. However, such an abuse would be easily detectable, and Flashbots can cut them off from future flow. Eventually, Flashbots hopes to remove any need for trust by making miners [blind to the transactions they include](https://ethresear.ch/t/mev-sgx-a-sealed-bid-mev-auction-design/9677) until they are already on-chain. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--f7531c647c/789b4c6d601b4e6750ccc60d719387e1/asset-https-cdn-sanity-io-images-dgybcd83--f7531c647c.png) The second innovation afforded by Flashbots bundles is **gasless transactions**. A mistX transaction does not pay a native transaction fee to miners (5). Instead the trader pays the miner via a smart contract call made in one of the transactions from the Flashbots bundle. This payment is **conditional on the trade executing as well**, and so if the trade was to revert - typically because the user’s slippage tolerance was broken - then the miner has no incentive to include it. This approach differs from CowSwap’s in that CowSwap takes the execution risk from the trader, whereas in mistX the transaction is actually risk-free. As a result, traders no longer have to worry about **failed transactions**, and there is less wasted blockspace as well. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--e656cd2257/0ffe39ec6b83c90da465378d9bfb85e2/asset-https-cdn-sanity-io-images-dgybcd83--e656cd2257.png) However, while the transaction is gasless, it is all but free for the trader. They pay in one of two ways: - With **worse execution**, as mistX removes some ETH from their input or output to pay the miner; or - by **taking ETH from the user’s wallet**. This step should be unnecessary in the future, as the exchange can shave off ETH after the first hop, or accept USD stablecoins as an alternative. In the screenshot, we can see that the transaction paid 0.0099 ETH to Sparkpool, the including miner, and 0.0005 to the mistX fee wallet (6). This comes down to another 0.27%, or $25. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--613e06c660/001e917e42fddda41df41dbb2ae19ca8/asset-https-cdn-sanity-io-images-dgybcd83--613e06c660.png) The way to calculate the cost of a mistX transaction is actually the exact same as when using the public mempool. It’s **gas used \* gas price = final fee in ETH**. First, since Flashbots bundles are bound to the first slots in each block, they compete with other important transactions like arbitrage, liquidations, and sandwich attacks. As a result, they incur a large **opportunity cost**. This opportunity cost will hopefully go down over time, as Flashbots miners start including more bundles per block, and exchanges like mistX start batching multiple trades in the same bundle. Second, mistX trades - and gasless transactions in general - **use more gas than regular DEX trades**. Instead of the 205k gas used here (7), executing the same trade on Uniswap would have cost around 160-180k gas. The difference is the two extra transactions made by mistX: one to the miner, and one to their own fee wallet. Bottom line, mistX combines two nice innovations: frontrunning protection via Flashbots bundles, and gasless transactions. Right now, they route all trades to Uniswap v2, so for many trades it is still better to use a regular DEX aggregator (or meta-aggregator like CowSwap) to minimize price impact. Nonetheless, using Flashbots bundles in this way represents an interesting proof-of-concept for the entire Defi economy. Acknowledgments: Thanks to [Dire](https://twitter.com/Dire_0x) of mistX and [Robert Miller](https://twitter.com/bertcmiller) of Flashbots for patiently answering all my questions, and Georgios Konstantopoulos for review. ## https://www.paradigm.xyz/writing/booby-trapping-the-ethereum-blockchain # Booby Trapping the Ethereum Blockchain > This is the second in a series of blog posts about bugs I've found in go-ethereum (Geth). If you haven't already, take a look at Part 1 here. Today's post is about a bug This is the second in a series of blog posts about bugs I've found in [go-ethereum](https://github.com/ethereum/go-ethereum/) (Geth). If you haven't already, take a look at Part 1 [here](https://www.paradigm.xyz/2021/03/the-block-mined-in-january-584942419325/). Today's post is about a bug in Geth's state downloader which could be used to trick it into syncing with mainnet incorrectly. If exploited, an attacker could have booby trapped the Ethereum blockchain and triggered a hard fork at will. # Synchronization Whenever someone wants to run an Ethereum node, they must first synchronize with the network. This means downloading or computing all of the data needed to build a complete picture of the chain state at the latest block. Depending on the needs of the user, some tradeoffs between security and speed can be made, so Geth supported (at the time) two different sync modes: full sync and fast sync. As the name would suggest, full sync performs a full synchronization of the Ethereum blockchain. This means that Geth will download and validate the proof-of-work seals on every single block. Geth will also execute every single transaction in the block, which allows it to generate the blockchain state locally without needing to trust other nodes. This is more secure but comes with a heavy speed tradeoff, as a full Geth sync may take anywhere from days to weeks to complete. However, some users may not want to wait weeks for a full sync to complete. Perhaps they have a deadline to meet or they simply don't think the speed tradeoff is worth it. For this, Geth offers a mode where chain data up to a recent block (known as the pivot) is synchronized using a faster approach, with only the few remaining blocks being synchronized using the slower full sync algorithm. In fast sync mode, Geth downloads but does not verify the proof-of-work on every block, instead choosing certain blocks at random. Geth also does not execute any transactions, instead choosing to download the state trie directly from peers in order to arrive at the final blockchain state. Of course, Geth doesn't just blindly trust state trie data that peers send back, or a malicious peer could claim that a certain account has much more ether than it actually does. To understand how Geth can tell whether the data it just received is correct or not, we must first understand the Merkle-Patricia trie. # Merkle-Patricia Trie The Merkle-Patricia trie (MPT) is a key data structure in Geth and is a combination of the Merkle tree and the Patricia trie. Put very simply, a Patricia trie stores data in a tree-like structure based on the data's prefix. This is a more optimal way of storing similar data when compared to something like a hashmap, although there may be a speed tradeoff. For example, here's how several words all starting with `r` might be stored in a Patricia trie. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--d237421b58/c48316ad4c2cff7212b7967e2786c90c/asset-https-cdn-sanity-io-images-dgybcd83--d237421b58.png) *By Claudio Rocchini - Own work, CC BY 2.5, https://commons.wikimedia.org/w/index.php?curid=2118795* Meanwhile, a Merkle tree is simply a tree where the leaf nodes are hashes of the data and all other nodes are hashes of their children. If a user knows the Merkle root (i.e. the top hash) of the Merkle tree and wants to check whether a specific piece of data was contained in the tree, they can do so using only a path through the tree, which is proportional to the `log` of the number of leaf nodes, rather than the number of leaf nodes itself. In the diagram below, a user can prove that `L2` is a member of the tree by providing `Hash 0-0` and `Hash 1`. The verifier will then generate `Hash 0-1`, `Hash 0`, and `Top Hash` which can be compared with the Merkle root they expected. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--d184885c88/be89a5135ed77d09ad616c91cd250ead/asset-https-cdn-sanity-io-images-dgybcd83--d184885c88.png) *By Azaghal - Own work, CC0, https://commons.wikimedia.org/w/index.php?curid=18157888* With a MPT, the prefix-based storage layout of the Patricia trie is combined with the Merkle tree to create a data structure whose contents can be cryptographically verified while still maintaining good runtime performance. In the MPT, keys and values are arbitrary byte strings. To retrieve the value for a key, the key is first converted into a sequence of hexadecimal characters such that every byte becomes two hex characters. Then, the root node is consulted to determine what the next node should be for the first character in the sequence. The child node is then consulted for the second character, and the process repeats until the final node is found for the final character in the sequence. In the example below, we see there are actually three different types of nodes in the MPT. An extension node (or, a short node, as it's referred to in the Geth codebase) is an optimization which states that the given node is responsible for multiple characters in the stream. In this case, the root node covers all keys which begin with `a7`, removing the need for two distinct nodes to represent `a` and `7`. A branch node (or a full node) contains pointers for every possible character as well as one extra slot for the value at the current node. Finally, a leaf node (or a value node) indicates that the given node must match until the end of the key1. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--b8f18805dd/ece4ff638371eaf17e099f37bd7d3f10/asset-https-cdn-sanity-io-images-dgybcd83--b8f18805dd.png) # State Trie Now that we know how the Merkle-Patricia trie works, we can examine the global state trie itself. The global state trie is where most of the data for the blockchain is stored. Although it's convenient to imagine the state trie as a distinct entity that is unique to each block, the reality is that duplicating the entire state trie for each block would be extremely inefficient as only a small percentage of the trie changes from block to block. Instead, Geth maintains what can be imagined like a pool of MPT nodes. The state trie for each block is simply a subset of the whole pool, and as new blocks are mined or imported, new MPT nodes are inserted into the pool. In order to identify the root nodes in the pool of nodes, the block header must be consulted. Every block contains a field known as the `stateRoot`, which points to the root node of the MPT which stores account data keyed by the account address2. This allows Geth to look up account information such as the nonce or balance for any address using the algorithm we described above. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--8d6f6f0878/87e91aee6f21a60aa32162a00b99b21a/asset-https-cdn-sanity-io-images-dgybcd83--8d6f6f0878.png) Note that for contracts, the account state will contain a non-empty `storageRoot` and `codeHash`. The `storageRoot` points to another root node, but this time for a MPT which stores contract storage data. This MPT is keyed on the storage slot and the value is the raw data itself. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--a6c86d5235/6f47674127e746dcf46a3c9c6e051f26/asset-https-cdn-sanity-io-images-dgybcd83--a6c86d5235.png) To store the MPT on disk, Geth chose to use LevelDB as its database. However, LevelDB is a key-value datastore that only supports string-to-string mappings, and a MPT is not a string-to-string mapping. To solve this problem, Geth flattens the global state trie by writing each node as a key-value pair: the key is the hash of the node and the value is the serialized node itself. This is also how Geth is able to look up the state trie for any given block, because the `stateRoot` field in the block header is the key which can be used to find the serialized MPT node in LevelDB. # Trie Confusion So let's say that you're starting up a Geth node and you're connecting to the network using fast sync. Geth will quickly download all of the block data but not execute any transactions. Before long, you'll have a chain of blocks but no state information. Here, Geth kicks off the state downloader which begins synchronizing from the pivot block's `stateRoot`. ```solidity // NewSync creates a new trie data download scheduler. func NewSync(root common.Hash, database ethdb.KeyValueReader, callback LeafCallback, bloom *SyncBloom) *Sync { ts := &Sync{ database: database, membatch: newSyncMemBatch(), requests: make(map[common.Hash]*request), queue: prque.New(nil), bloom: bloom, } ts.AddSubTrie(root, 0, common.Hash{}, callback) return ts } ``` The state downloader will send a request to its peers for the MPT node data corresponding to the MPT node key. When it receives a result, it verifies that the node data hashes to the expected node key. If it does, then the state downloader knows that the node is correct and will process it by dispatching more requests for each child of the node. ```solidity // Create and schedule a request for all the children nodes requests, err := s.children(request, node) if err != nil { return committed, i, err } if len(requests) == 0 && request.deps == 0 { s.commit(request) committed = true continue } request.deps += len(requests) for _, child := range requests { s.schedule(child) } ``` If a leaf node is encountered, that is, a node which contains a serialized account state, then the account's code and state trie will be queued for fetching. ```solidity callback := func(leaf []byte, parent common.Hash) error { var obj Account if err := rlp.Decode(bytes.NewReader(leaf), &obj); err != nil { return err } syncer.AddSubTrie(obj.Root, 64, parent, nil) syncer.AddRawEntry(common.BytesToHash(obj.CodeHash), 64, parent) return nil } ``` [Source](https://github.com/ethereum/go-ethereum/blob/87c463c47aa6d10a55a4b860bab3d53199814d01/core/state/sync.go#L31-L39) Note that there's a distinction between synchronizing a sub trie and a raw entry. While both will download an arbitrary blob of data, if the syncer is expecting a raw trie then it will parse the data as a trie node and begin synchronizing its children. On the other hand, if the syncer is expecting a raw entry it will simply write the blob to the database and terminate. ```text // If the item was not requested, bail out request := s.requests[item.Hash] if request == nil { return committed, i, ErrNotRequested } if request.data != nil { return committed, i, ErrAlreadyProcessed } // If the item is a raw entry request, commit directly if request.raw { request.data = item.Data s.commit(request) committed = true continue } ``` [Source](https://github.com/ethereum/go-ethereum/blob/87c463c47aa6d10a55a4b860bab3d53199814d01/trie/sync.go#L183-L197) Additionally, note that it's not uncommon for Geth to want to request the same node multiple times. For example, two contracts might share the same `stateRoot` if they contain identical storage, or two accounts might share the same account state. In this case, Geth doesn't want to spam the network with spurious requests so it will merge them together. ```solidity func (s *Sync) schedule(req *request) { // If we're already requesting this node, add a new reference and stop if old, ok := s.requests[req.hash]; ok { old.parents = append(old.parents, req.parents...) return } // Schedule the request for future retrieval s.queue.Push(req.hash, int64(req.depth)) s.requests[req.hash] = req } ``` However, the syncer doesn't merge the `raw` attribute of a request. This means that if there is already a pending raw entry request but the syncer schedules a sub trie request with the same hash, it will be merged and the end result will still be a raw entry request. Remember that a raw request does not process the node for children to be synced. This means that if we can somehow generate a collision between a raw node and a sub trie node, we'll be able to cause Geth to sync an incomplete state trie. Furthermore, Geth (at the time) doesn't bail out when reading from a trie node that doesn't exist, likely assuming that such a situation could never happen if the downloader reported a successful sync, meaning that a Geth node with a missing trie node would behave completely differently from any other node with a fully synchronized trie. So how can we generate such a collision? It turns out to be extremely simple: all we need to do is deploy a contract whose code is equal to the serialized state root of another contract we control. Our code hash will necessarily be the same as the state root hash, which means that if our contract code is synchronized first, our other contract's state trie will never be fully downloaded. # Putting it all Together Fully weaponizing this vulnerability would have required multiple steps and a lot of waiting. First, we deploy a contract whose state trie will be overwritten using the exploit. This contract should have a unique `stateRoot` so that the MPT node associated with that `stateRoot` won't be synchronized earlier. ```solidity contract Discrepancy { uint public magic = 1; // make sure we have a unique stateRoot uint[] private filler = [1,2,3,4,5,6,7,8,9,0]; } ``` Next, we deploy another contract which will use the discrepancy to trigger a hard fork: ```solidity contract Hardfork { function hardfork(Discrepancy target) public { require(target.magic() == 0, "no discrepancy found"); selfdestruct(msg.sender); } } ``` Finally, we deploy a third contract whose code will be equivalent to the state root of our `Discrepancy` contract. We must take care here to ensure that the address of this contract is "smaller" than the address of the discrepancy contract itself so that it will always be synced before the discrepancy contract. ```solidity contract Exploit { constructor(bytes memory stateRoot) public { assembly { return(add(stateRoot, 0x20), mload(stateRoot)) } } } ``` Now we sit back and relax. As new Geth nodes join the network using fast sync, they will request the `Exploit` contract first which will sync its state sub trie as well as its code. When `Exploit`'s code is synced, it will create a raw request which looks exactly identical to a request for `Discrepancy`'s state root, except it won't be processed as a sub trie request. This means that the node will never download `Discrepancy`'s state trie so future requests to read `magic` will return `0` instead of `1`. After sufficient time has passed, all we need to do is call `Hardfork.hardfork(discrepancy)`. Every node which has correctly synchronized the entire network will see a reverted transaction, while every Geth node which had joined the network using fast sync will see a successful transaction. This will result in two different state roots for that block, meaning that we just triggered a chain split at will. The Geth team quickly patched this attack by properly handling trie read errors in [PR #21039](https://github.com/ethereum/go-ethereum/pull/21039), then fully fixed the vulnerability by distinguishing between code blobs and trie blobs in [PR #21080](https://github.com/ethereum/go-ethereum/pull/21080). # Conclusion This was an extremely interesting bug which gave an attacker the ability to set a booby trap on the Ethereum network and detonate it whenever they liked, causing all fast-synced Geth nodes to fork off mainnet. It relied on extremely complex internal logic within Geth's synchronization and data storage code, which may explain why it went unnoticed for so long. Tune in later for the third and final (for now, at least) installment in this series, where we'll be exploring a bug in Geth that's so new, the details are still embargoed at the time of writing. *1 Technically, value nodes in Geth don't contain a suffix. Instead, you can think of it like an extension node followed by a value node (which just contains the raw data).* *2 In reality Geth uses what it calls a "secure trie" which just hashes all keys using the SHA-3 algorithm in order to ensure all keys are always a fixed length.* ## https://www.paradigm.xyz/writing/liquidity-mining-on-uniswap-v3 # Liquidity Mining on Uniswap v3 > Uniswap v3 replaces fungible ERC-20 liquidity positions with non-fungible ERC-721 liquidity positions. Does that mean it no longer supports flexible Uniswap-v2-style liquidity mining? Or that liquidity mining programs will have to be actively managed, selecting specific ranges to incentivize? Or that liquidity mining programs could be gamed by providing huge amounts of inactive liquidity? Uniswap v3 replaces fungible ERC-20 liquidity positions with non-fungible ERC-721 liquidity positions. Does that mean it no longer supports flexible Uniswap-v2-style liquidity mining? Or that liquidity mining programs will have to be actively managed, selecting specific ranges to incentivize? Or that liquidity mining programs could be gamed by providing huge amounts of inactive liquidity? **No.** Uniswap v3 can support the same kind of liquidity mining as Uniswap v2—incentivizing all active liquidity pro rata, at a constant rate per second—with only relatively modest compromises. It indirectly incentivizes concentration of liquidity, since liquidity providers are rewarded for their share of virtual liquidity (while it is active), rather than the total value of the tokens they supplied. It can even do all this in a single staking contract, allowing people to stake the same liquidity with multiple incentives at the same time and eliminating the need to deploy new contracts for different incentives. Omar Bohsali (currently an [Entrepreneur in Residence](https://www.paradigm.xyz/team/omarbohsali/) at Paradigm) recently received a grant from the Uniswap Grants Program to implement this algorithm. You can see track his progress [on GitHub](https://github.com/omarish/uniswap-v3-staker). This is the first in a series of posts on **How I Learned To Stop Worrying and Love Non-Fungible Liquidity.** The next post will talk about how Uniswap v3 positions can be used as collateral. ### The billion-dollar algorithm To understand how the standard liquidity mining algorithm can be adapted for Uniswap v3, we first need to understand how it works for earlier versions of Uniswap. This algorithm—for efficient incremental calculation of proportional reward distribution—was first described in [Scalable Reward Distribution on the Ethereum Blockchain](https://uploads-ssl.webflow.com/5ad71ffeb79acc67c8bcdaba/5ad8d1193a40977462982470_scalable-reward-distribution-paper.pdf), by Bogdan Batog, Lucian Boca, and Nick Johnson. (Hat tip [@FrankieIsLost](https://twitter.com/FrankieIsLost) for discovering this paper.) The first liquidity mining program where rewards were computed on-chain was SNX's [incentive](https://sips.synthetix.io/sips/sip-31) for the sETH Uniswap pool. This was implemented in the [Unipool](https://github.com/k06a/Unipool/commit/e4bdb0a978fd498a1480e3d1bc4b4c1682c74c12#diff-0d1e350796b5338e3c326be95f9a9ad147d4695746306a50a9fdccf8dbbfd708) sETH contract, written in 2019 by Anton Bukov. I consider this one of the most influential smart contracts ever written. Suppose you want to incentivize liquidity in a Uniswap v1 or v2 pool over a particular period. You want to distribute tokens fairly across liquidity providers and linearly over time—say, at a rate of $R$ tokens per second. To do this, imagine cutting the pool into single-second time slices. For each of those slices, a given liquidity provider should receive $R \\cdot \\frac{l(t)}{L(t)}$ tokens, where $l(t)$ is that individual liquidity provider's balance of liquidity tokens at time $t$ and $L(t)$ is the total quantity of staked liquidity for that pool at time $t$. Their reward for a period from $t_0$ to $t_1$ would be the total sum of their rewards for each of these seconds: $$ \sum_{t=t_0}^{t_1} R \cdot \frac{l(t)}{L(t)} $$ This would be easy enough to compute off-chain. But how can we efficiently compute it on-chain, with only incremental updates every time someone enters or leaves the pool? If the user's balance $l$ is constant over that period, then the above formula can be simplified to: $$ R \cdot l\cdot \sum_{t=t_0}^{t_1} \frac{1}{L(t)} $$ We can then decompose that sum into a difference of two sums. (A very similar trick was used for the oracle accumulator introduced in Uniswap v2.) $$ R \cdot l \cdot (\sum_{t=0}^{t_1} \frac{1}{L(t)} - \sum_{t=0}^{t_0} \frac{1}{L(t)}) $$ This means that all we need to track in the staking contract is a single accumulator tracking "seconds per liquidity" since the beginning of the pool: $$ s_l(t_i) = \sum_{t=0}^{t_i} \frac{1}{L(t)} $$ In the Unipool contract, this accumulator is [called](https://github.com/k06a/Unipool/commit/e4bdb0a978fd498a1480e3d1bc4b4c1682c74c12#diff-0d1e350796b5338e3c326be95f9a9ad147d4695746306a50a9fdccf8dbbfd708R19) `rewardPerTokenStored`. When anyone stakes or unstakes liquidity—thus changing $L$ —the staking contract updates the $_$ accumulator, by adding $\\frac{t_{now} - t_{last}}{L}$ to its previous value. (Technically, in the Unipool contract and most of its forks, the accumulator tracks , rather than multiplying by the reward rate later.) When someone stakes liquidity, the contract checkpoints their starting value of the accumulator, $s_{l}(t_0)$. When they later unstake, the contract looks at the new value of the accumulator $s_{l}(t_1)$ and computes their rewards for that period: $$ R(l, s_l(t_1), s_l(t_0)) = R \cdot l \cdot (s_l(t_1) - s_l(t_0)) $$ Uniswap v1 and v2 didn't need any built-in support for these incentives, because these numbers (both the accumulator and the checkpointed values) only change when the staking contract is touched. In addition to laying the groundwork for the yield farming trend—during which it [was](https://github.com/Synthetixio/synthetix/blob/develop/contracts/StakingRewards.sol) [forked](https://github.com/yam-finance/yam-protocol/blob/master/contracts/incentivizers/YAMIncentives.sol) [repeatedly](https://github.com/Uniswap/liquidity-staker/blob/master/contracts/StakingRewards.sol)—this clever algorithm turned out to be quite versatile. For example, Uniswap v3 uses a similar algorithm to track fees earned by individual positions (with some additional tricks to support concentrated liquidity). While it is most useful on-chain (where efficiency is paramount), it is also useful for simplifying off-chain computations. The UNI retroactive distribution was based on a [query](https://github.com/Uniswap/retroactive-query/blob/master/src/07_02_liquidity_provider_query_pt_2.sql) that reimplemented this algorithm in SQL. ### Time to concentrate Uniswap v3 complicates the situation, but not unsolveably. As described in the [whitepaper](https://uniswap.org/whitepaper-v3.pdf), Uniswap v3 supports *concentrated liquidity*—liquidity that is active only while the current price tick ($i_c$) is within a particular range ($i_{lower} \\leq i_c < i_{upper}$). This means that a price movement can change the liquidity balance of staked positions without the staking contract being touched. For a given position with liquidity, we now need to calculate: $$ R \cdot l \cdot \sum_{t=t_1}^{t_2} \begin{cases} \frac{1}{L(t)} & i_{lower} \leq i_c < i_{upper} \\ 0 & i_c < i_{lower} \\ 0 & i_c \geq i_{upper} \\ \end{cases} $$ This can be decomposed into: $$ R \cdot l \cdot ((\sum_{t=t_1}^{t_2} \frac{1}{L(t)}) -(\sum_{t=t_1}^{t_2} \begin{cases}\frac{1}{L(t)}& i_c < i_{lower} \\ 0 & i_c \geq i_{lower} \end{cases}) -(\sum_{t=t_1}^{t_2} \begin{cases}\frac{1}{L(t)} & i_c \geq i_{upper} \\ 0 & i_c < i_{upper} \end{cases})) $$ We can interpret this as `secondsPerLiquidityInside = secondsPerLiquidity` - `secondsPerLiquidityBelow(lowerTick) - secondsPerLiquidityAbove(upperTick)`. The first term can be computed using the same global $s_l$ accumulator discussed above. In the Uniswap v3 contracts, this global accumulator is tracked alongside the price oracle, as `secondsPerLiquidityX128`. To allow us to compute the other two terms, Uniswap v3 checkpoints `secondsPerLiquidityOutside` for each tick every time that tick is crossed. "Outside" means on the opposite side of the tick from the current price. This allows us to compute the total `secondsPerLiquidity` accrued on either side of the tick at any time. For example, if `tickCurrent < i`, then `secondsPerLiquidityBelow(i) = secondsPerLiquidity - secondsPerLiquidityOutside(i)`; if `tickCurrent >= i`, then `secondsPerLiquidityBelow(i) = secondsPerLiquidityOutside(i)`. (This is quite similar to how Uniswap v3 tracks and computes the fees earned above and below ticks.) For any range, we can therefore use the above formula to compute `secondsPerLiquidityInside` for that range. Uniswap v3 does this calculation for you, and exposes the result through the convenient `snapshotCumulativesInside` [function](https://docs.uniswap.org/reference/core/UniswapV3Pool#snapshotcumulativesinside). The staking contract can simply snapshot this `secondsPerLiquidityInside` when a user stakes. When they later unstake, the staking contract looks at the new `secondsPerLiquidityInside`, takes the difference, and multiplies it by $R \\\\cdot l$ to get the total rewards earned by the position during that period. ### Compromises We do have to make some compromises based on technical limitations of the new system: - *Fuzzy cutoffs*: There is no way to automatically snapshot all of the accumulators at the exact moment that an incentive ends. After that cutoff, the contract cannot always distinguish between liquidity that was staked before the cutoff and liquidity that was staked after. To accomodate this, the contract can apply a decay to the reward rate for anyone who unstakes after the incentive ends. People who want to lock in the exact reward rate would need to unstake before that. - *Unstaked liquidity*: The algorithm uses the total amount of active liquidity in the core contract, which might be higher than the total *staked* liquidity. Unstaked liquidity will still be allocated a share of the rewards, as if it was staked but unclaimed. The creator of an incentive could specify a claim deadline after which they would be able to recover all unclaimed rewards. ### Conclusion Far from "breaking" liquidity mining, Uniswap v3 opens up a vast design space for it. While this post describes an algorithm for implementing "classic" liquidity mining on top of Uniswap v3, I think this barely scratches the surface. As described in section 6.3 of the whitepaper, the Uniswap v3 core contracts expose several other indexes (such as `secondsOutside` and `tickCumulativeOutside`). I'm looking forward to seeing how protocols make use of these new features. In a future post, I'll address another common concern about building on top of Uniswap v3 positions: how lending protocols can use them as collateral. ## https://www.paradigm.xyz/writing/everlasting-options # Everlasting Options > This paper introduces a new type of derivative, the everlasting option. Everlasting options give traders long-term options exposure without the effort, risk, or expense of rolling positions. ## Introduction This paper introduces a new type of derivative, the *everlasting option*. Everlasting options give traders long-term options exposure without the effort, risk, or expense of rolling positions. We derive a simple no-arbitrage pricing model for everlasting options which extends to all funding-fee-based perpetual derivatives, including perpetual futures. ## Options Basics ### Option Types We'll start by providing a brief overview of the simplest type of option, the *European option*. There are two types of European options, *calls* and *puts*. A *call* gives the holder the right to buy a certain asset (the *underlier*) for a certain price (the *strike*), at a certain time on a certain date (the *expiration*). A *put* gives the holder the right to *sell* the underlier for the strike price at expiration. ### Examples For example, a $3000 strike May 15 ETH put gives the holder the right to sell 1 ETH for $3000 at a particular time on May 15. If the trading price of ETH (the *spot*) is $2900 on May 15 when the put expires, the trader will be able to buy 1 ETH for $2900 on the market and then immediately sell it for $3000 via the put, locking in a profit of $100. This quantity is known as the *payoff*. On the other hand, if the trader is holding a $3000 strike put at expiry when the price of ETH is $3100, the trader can sell ETH for a higher price on the market than she can using the put. In this case, there is no way to profit using the put, and we say the payoff is $0. ### Payoff Calculation Although a European option can only be used, or *exercised*, at one specific moment on its expiration date, we can calculate the payoff at any time. It is a measure of how much money the option would be worth if it were to be exercised immediately. In general, the payoff of a put is max(strike-spot, 0). The farther below the strike price ETH is trading, the more money we can make selling ETH via the put. But, if the price of ETH is above the strike price at expiration, then it is better to sell ETH directly on the market than it is to use the put, and the put is worthless. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--a7862cd3a4/099eb1226075245f9897be330cc6f894/asset-https-cdn-sanity-io-images-dgybcd83--a7862cd3a4.png) *See: https://colab.research.google.com/drive/1nehkZjTh_Kloz_vC--e1h7W_s-yGzh9b?usp=sharing* Similarly, the payoff of a call is max(spot - strike, 0). If ETH is trading at $3100 and we have a $3000 strike ETH call at expiration, we can buy ETH for $3000 using the call and then immediately sell it on the market for $3100, netting a payoff of $100. But if ETH is trading at $2900 and we have a $3000 strike ETH call, the payoff is $0. ### Options Pricing An option is generally worth more than its payoff up until the moment it expires (excluding a few special cases). Consider the $3000 strike ETH put expiring tomorrow. If the price of ETH is currently $3000, this put's current payoff is $0. But the price of ETH could fall by tomorrow, in which case the put would be worth more than $0 at expiry. So the put must be worth something greater than $0 now to account for that possibility. One basic and widely-used model for options pricing is the Black-Scholes model. The graph below shows the Black-Scholes price of a $3000 strike ETH put compared to the payoff at various spot ETH prices one day before expiry. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--d31d325505/7710e99102da87cdb644b442fd4572e3/asset-https-cdn-sanity-io-images-dgybcd83--d31d325505.png) *See: https://colab.research.google.com/drive/1nehkZjTh_Kloz_vC--e1h7W_s-yGzh9b?usp=sharing* ## Rolling Positions ### Definition A primary use case for options is *hedging*, or protecting against risk. If an investor holds a large portfolio of ETH, for example, she may choose to buy enough $3000 strike ETH puts to ensure that she will always be able to sell her position for at least $3000 per ETH, regardless of what happens to the market price of ETH. However, these puts will eventually expire. If the investor wants to keep her hedge, she will have to *roll* her options position. In this case, this means closing out the position in the puts that are about to expire and opening a new position in puts with the same strike that will expire later. ### Example For example, the investor might have originally bought $3000 strike May 15 ETH puts. When they get close to expiring on May 15, she may sell them and buy the same number of $3000 strike June 15 ETH puts. She will have to repeat this process every month for as long as she wants to hold her position. ### Problems When the investor comes to the market to roll her position, she will most likely be trading with a market participant called a *market maker*. Market makers make money when *uninformed* participants — such as those rolling options positions — trade against them. However, market makers *lose* money when *informed* participants — such as those who know news about the price of ETH — trade against them. Because market makers don't know who is informed and who is uninformed, they must charge a fee, called a *spread*, on *every* trade. Spreads tend to be especially high in the options market, where informed trades can be very costly for market makers. This makes rolling positions a costly proposition. Rolling a position also involves work and risk. The trader may simply forget to roll, leaving her position unhedged. Or she might *misclick*, or execute the trade incorrectly, which can be expensive and dangerous. Even if everything goes perfectly, the whole process is stressful and takes time, siphoning attention away from more productive endeavors. ### Existing Solutions There is an existing product called the *perpetual American option*, which is an option that can be exercised at any time and has no expiration date. Selling a perpetual American option requires a market maker to take on a huge amount of risk and uncertainty up-front, which makes them both very expensive and very difficult to price. As a result, they are effectively never traded. The existence of this product is why we call our new alternative the *everlasting option.* ## Liquidity Fragmentation The existence of many different options expiration dates leads to one additional problem: *liquidity fragmentation.* If market makers must make markets on options expiring not just this week, but every week for the next three months, they will be forced to spread out their capital, making it harder for other participants to execute large trades or to determine fair prices. This fragmented market also makes trading options more confusing, as participants must decide which expiry to transact in. ## Analogy to the Futures Market Futures contracts, which traditionally have expiration dates as well, share all of these problems. If a trader wants long-term exposure to ETH using traditional expiring futures, she will have to roll her position just as she would in the case of options. For example, she might buy the ETH futures contract expiring May 15. Then, close to expiry on May 15, she might sell that contract and buy the ETH futures contract expiring June 15, and so on. Just as with options, rolling her futures position takes time, introduces risk, and will require her to pay spreads to market makers on an ongoing basis. The existence of multiple futures expiries also leads to liquidity fragmentation in the futures market. ## Perpetual Futures *Perpetual Futures* ("perps" for short), introduced to crypto by BitMEX in 2016, solve these problems. They give traders futures exposure for as long as they want it without the need to roll. They also concentrate all the futures liquidity for a given underlier on a given exchange into a single product. Perps have become massively popular, trading tens and sometimes hundreds of billions of dollars of value per day. ### Mechanism Simplified a bit, perps work as follows: every day, those who are *long* the perp (have bought it) must pay a *funding fee* to those who are *short* the perp (have sold it). This funding fee is calculated as (mark-index): the difference between the *mark price*, the trading price of the perp, and the *index price,* the price of the underlier, such as ETH. This funding fee mechanism causes the price of the perp to stay in line with the price of the underlier. Roughly speaking, if the perp gets much more expensive than the underlier, then longs will have to pay high funding fees, which should incentivize them to sell the perp, bringing down its price. As it turns out, we can get a lot more precise than this. See [The Cartoon Guide to Perps](https://research.paradigm.xyz/cartoon-guide-to-perps) for a walkthrough of perp mechanics, or our model below for a precise valuation formula. ### Examples If the ETH perp is trading at $3100 while the price of ETH is at $3000, the longs must pay the shorts mark - index = $3100 - $3000 = $100 per day. If the ETH perp is trading for $2900 while the price of ETH is at $3000, mark - index = $2900 - $3000 = -$100, meaning the shorts must pay the longs $100 per day. ## Everlasting Options Everlasting options are the equivalent of perpetual futures for options. A trader holding the $3000 strike everlasting ETH put can effectively always sell her ETH for $3000. She will have to pay funding fees to finance her position, but because she does not have to trade with market makers on an ongoing basis, she does not pay spreads or incur operational risk except when entering and exiting her position. Since multiple expiries are no longer required, liquidity will be less fragmented, although in the basic version there will still be different everlasting options for different strikes. ### Mechanism Everlasting options work exactly the same way as perpetual futures, with one difference: the funding fee is calculated as the difference of the mark price and the current payoff of the option, so that the funding fee is (mark - payoff) instead of (mark - index). #### Examples Consider the $3000 strike everlasting ETH put with funding paid once daily. If ETH is currently trading at $2900, the current payoff of the put is $3000 - $2900 = $100. If the everlasting put is trading for $150 the instant before funding is paid, then the longs would have to pay the shorts mark - payoff = $150 - $100 = $50 per day. If ETH is currently trading at $3100, above the strike of the everlasting put, then the put's payoff is $0. If the everlasting put is trading for $50 the instant before funding is paid, then the longs would have to pay the shorts mark - payoff = $50 - $0 = $50 per day. Notice that the payoff of a $0 strike ETH call is just the price of ETH — in other words, payoff = index. This means the $0 strike call is equivalent to an ETH future. Appropriately, the daily funding fee for the $0 strike everlasting call is mark - payoff = mark - index, the same as the funding fee for a perpetual future. ### Pricing Everlasting options would not be very useful if we didn't know how much they were worth. Fortunately, by means of the no-arbitrage argument laid out below, we do: they are equivalent to a particular constantly rolling options portfolio, and will therefore have the same price as that portfolio. If these prices diverge too much, arbitrageurs will step in to bring them back in line. If funding is paid once per day, this equivalent portfolio consists of one half an options contract expiring today, one quarter of an options contract expiring tomorrow, one eighth of an options contract expiring the day after that, and so on. All of these contracts have the same strike as the everlasting option itself. We can also create an everlasting option with multiple smaller funding payments per period -- i.e. 1/24 of the funding is paid each hour -- which changes the composition of the equivalent portfolio. See Appendix B for details. In either case, we can price the everlasting option by pricing this basket. This can be done simply by taking the weighted sum of the individual options prices (estimating the contribution of positions consisting of less than, say, 1/1024 of the portfolio). Options market makers are quite capable of pricing these individual expiring options. If we were to use simple Black-Scholes assumptions, which do not match real world behavior but are close, an everlasting option with funding paid twice daily would behave almost exactly like a regular expiring option with the same strike expiring in one day. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--000cb0e566/096c2e66dad728d66d011b4b7d3f0d15/asset-https-cdn-sanity-io-images-dgybcd83--000cb0e566.png) ## Equivalent Portfolio ### Price Dynamics Around Funding Payment Reasoning about funding-fee-based perpetuals such as everlasting options is tricky because their pricing contains a natural discontinuity. Funding is paid at a particular, precise time, say, midnight. Just as is the case when stocks pay a dividend, we should expect the price of the perpetual to jump immediately after funding payment. Therefore, while it is natural to think of things happening "at the same time as" the funding payment is made, this will only lead to suffering. When reasoning about the behavior of a perpetual derivative around funding payment time, it is best to think about what happens either immediately *before*, or immediately *after*, funding is paid. As an aside, to the extent that current perp exchanges do not automatically update their order books after funding payments, as stock exchanges do after dividends, they are exposing their market markers to arbitrage losses. For example, if the longs are due to pay the shorts a funding fee, a rational trader should short the perpetual a microsecond before expiry, collect the payment, and then buy to close their short a microsecond after expiry, collecting a profit with little risk. ### Equivalent Portfolio Intuition #### Description As mentioned, an everlasting option for which funding is paid once daily is equivalent to a portfolio of regular expiring options: one half of a contract expiring at the time of the next funding payment, one quarter of a contract expiring at the time of the funding payment after that, one eighth of a contract expiring at the time of the funding payment after that, and so on. The total number of contracts in this portfolio sums to one. This means that, at the time of the funding payment, half of a contract, representing one half of the total portfolio, has just expired. The funding payment then corresponds to the cost of rolling the portfolio: buying half a contract's worth of new options to make up for the half contract that has just expired. But, unlike in the case of manual rolling, these new contracts are distributed across multiple expiries, no spreads have to be paid, and no execution risk is incurred. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--621fb6d5e2/18b0bd8d8b57862f1fe8559a1336558a/asset-https-cdn-sanity-io-images-dgybcd83--621fb6d5e2.png) ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--05fa051af9/e06abf63ed0abb384e650f625fa6c48d/asset-https-cdn-sanity-io-images-dgybcd83--05fa051af9.png) #### Argument Imagine Alice is long one contract of an everlasting option for which funding is paid once daily, at midnight. Alice must pay (mark - payoff) in funding tonight at midnight. Let's think about what this cash flow means. The mark price is the cost to buy the everlasting option infinitesimally before funding is paid, so Alice pays what she has to to double her position. On the other hand, since the term for the payoff is negative, she *receives* the payoff, which is what she would get if she were long one contract of the equivalent regular option expiring at midnight. To repeat, if being long an everlasting option is equivalent to being long some portfolio of regular options, this means Alice doubles her position in each of those options an instant before expiry, then receives one contract's worth of payoff at the instant of expiry. That would imply that, up until she doubles her position, Alice is long exactly *half* a contract of the option expiring tonight at midnight. Extending this train of thought, if we want Alice's everlasting option equivalent portfolio to keep working after tonight, her position in the regular option expiring midnight *tomorrow* must be exactly half of a contract after the doubling tonight. This can only be the case if it it is *one fourth* of a contract before the doubling... and so on. Note this argument works for any expiring derivative with a defined payoff, not just European options. ### Formal Proof See Appendix B. ## Further Applications This framework can be used to price *any* funding-fee based perpetual derivative for which we can price the expiring equivalents, not just European calls and puts. That includes perpetual futures. It also includes binary puts, which pay off $0 if the price of the underlier is above a given strike and $1 if it is below, and can therefore be used as proxies for protocol failure. ### Floating Strike Everlasting Options The framework can also be used to price a perpetual option whose strike is an exponentially-weighted moving average of the underlier price over time. This is because the expiring equivalent, the floating-strike Asian option, can also be priced, although doing so is not simple. Owning such a put would effectively always allow an ETH holder to sell their holdings at, say, the exponentially-weighted average price of ETH with a half-life of one day, protecting her against sudden drops in the price of ETH. Because the strike would automatically follow the price of ETH, it is possible that a single such product could fulfill the hedging requirements of the majority of ETH holders. This could potentially consolidate much of ETH options liquidity and volume into a single market. ## Future Work Future work lies primarily in the area of applications. - Is there a market for everlasting options, or for other new funding-fee-based perpetuals? - Which types will be most useful? - How can they best be parameterized? - How can exchanges and traders best manage their risk, and what are appropriate liquidation criteria for those trading on margin? If you have thoughts about these questions, or questions of your own, we would love to hear from you. You can email me at [dave@paradigm.xyz](mailto:dave@paradigm.xyz) or [DM me on Twitter](https://twitter.com/messages/compose?recipient_id=1184231093576392704), or reach Sam at [https://twitter.com/SBF_FTX](https://twitter.com/SBF_Alameda). Acknowledgments: [Dan Robinson](https://twitter.com/danrobinson) for many conversations that contributed to this post, both indirectly and directly. [Hasu](https://twitter.com/hasufl) for extensive feedback on clarity and structure for this paper. [Georgios Konstantopoulos](https://twitter.com/gakonst) for suggesting appropriate graphs. ## Appendices ### A Formal Mechanism Description #### A.1 Definitions We will use the following terms throughout the rest of the paper. $\\text{PAYOFF}$ – the payoff we would like our perpetual derivative to track. For a perpetual future, this is $\\text{SPOT}$, the spot price of the future’s underlying on some exchange. For an everlasting call, it is max $\\max(\\text{SPOT} - \\text{STRIKE}, 0)$. $\\text{REGPRICE}_t$ – the price of a regular, expiring derivative that settles to $\\text{PAYOFF}$ at time $t$. For perpetual futures, this would be the price of a regular future expiring at time $t$. For an everlasting option it would be the price of an option expiring at time $t$. $\\text{MARK}$ – in our idealized case, the trading price of the perpetual derivative on its exchange. $\\text{FUNDING FEE}$ – a payment made from those who are long the perpetual derivative to those who are short it (or vice versa, if the fee is negative) $\\text{FUNDING PERIOD}$ – a period of time (for example, one day) over which one complete funding fee payment is made. $\\text{FUNDING FREQUENCY}$ – the number of payments per payment period (for example, 24 hourly payments per one-day funding period). #### A.2 Mechanics Traders may buy and sell the perpetual derivative as they choose on its native exchange, causing changes to its $\\text{MARK}$ price. $\\text{FUNDING FREQUENCY}$ times per $\\text{FUNDING PERIOD}$, there is a transfer of $$ \text{FUNDING FEE} = \frac{\text{MARK} - \text{PAYOFF}}{\text{FUNDING FREQUENCY}} $$ from those long the derivative to those short it. ### B Pricing #### B.1 Formula Let $t_1, t_2, ...$ be the times of the next funding payments of our perpetual derivative. If we have a perpetual future with a funding period of one day and a funding frequency of 24, and it is currently 8:15, this might be 9:00, 10:00, 11:00, and so on. The price of our perpetual derivative is then $$ \frac{1}{\text{FUNDING FREQUENCY}} \sum_{i=1}^\infty \left( \frac{\text{FUNDING FREQUENCY}}{\text{FUNDING FREQUENCY} + 1} \right)^i \text{REGPRICE}_{t_i} $$ Note that this is a geometric series, and the total number of equivalent contracts sums to 1. Concretely, for an everlasting call option with funding paid daily at midnight, its price is the same as that of a basket of regular calls with the same strike: $\\frac{1}{2}$ expiring at midnight tonight, $\\frac{1}{4}$ expiring at midnight tomorrow, and so on. #### B.2 Proof Without loss of generality, assume that our perpetual derivative is trading for less than $$ \frac{1}{\text{FUNDING FREQUENCY}} \sum_{i=1}^\infty \left( \frac{\text{FUNDING FREQUENCY}}{\text{FUNDING FREQUENCY} + 1} \right)^i \text{REGPRICE}_{t_i} $$ In that case, we buy one contract of the perpetual derivative and short the basket consisting of $$ \frac{1}{\text{FUNDING FREQUENCY}} \sum_{i=1}^\infty \left( \frac{\text{FUNDING FREQUENCY}}{\text{FUNDING FREQUENCY} + 1} \right)^i \text{REGDERIV}_{t_i} $$ where $\\text{REGDERIV}_t$ is the derivative that settles to $\\text{PAYOFF}$ at $t$. By assumption, we generate some profit by doing this. The moment infinitesimally before $t_1$, we sell $\\frac{1}{\\text{FUNDING FREQUENCY} + 1}$ of our perpetual derivative, receiving $$ \frac{\text{MARK}}{\text{FUNDING FREQUENCY} + 1} $$ Our position in the derivative is then $\\frac{\\text{FUNDING FREQUENCY}}{\\text{FUNDING FREQUENCY}+1}$, so that at the time of funding payment, we pay $$ \frac{\text{FUNDING FREQUENCY}}{\text{FUNDING FREQUENCY} + 1} \frac{\text{MARK} - \text{PAYOFF}}{\text{FUNDING FREQUENCY}} = \frac{\text{MARK} - \text{PAYOFF}}{\text{FUNDING FREQUENCY} + 1} $$ and, because we are short $\\frac{1}{\\text{FUNDING FREQUENCY}+1}$ of $\\text{REGDERIV}_{t_1}$, we must pay $$ \frac{\text{PAYOFF}}{\text{FUNDING FREQUENCY} + 1} $$ so that our total cash flow is $$ \frac{\text{MARK}}{\text{FUNDING FREQUENCY} + 1} - \frac{\text{MARK} - \text{PAYOFF}}{\text{FUNDING FREQUENCY} + 1} - \frac{\text{PAYOFF}}{\text{FUNDING FREQUENCY} + 1} = 0 $$ Our position in both the perpetual derivative and the basket of expiring derivatives has now been sized down by $$ \frac{\text{FUNDING FREQUENCY}}{\text{FUNDING FREQUENCY} + 1} $$ so that, at the next expiry, we will be able by a similar process to further reduce our outstanding position for a cost of 0, and so on, until our overall positions are infinitessimal. This means that our original profit was risk free, and the difference in price between the perpetual and the basket violates the no-arbitrage assumption. ## https://www.paradigm.xyz/writing/on-staking-pools-and-staking-derivatives # On Staking Pools and Staking Derivatives > The transition from Proof of Work (PoW) to Proof of Stake (PoS) is Ethereum’s most anticipated milestone since its inception. We explore the problems that ETH stakers experience today, and show how staking pools and staking derivatives solve these problems while increasing the effective security of the network. The transition from Proof of Work (PoW) to Proof of Stake (PoS) is Ethereum’s most anticipated milestone since its inception. Instead of using the energy-costly PoW to extend the blockchain, PoS allows users to *stake* their ETH and operate block-producing nodes called *validators*. The first step towards PoS in Ethereum was launching a standalone network that can come to consensus, called the [*Beacon Chain*](https://beaconcha.in/). In return for providing security to this system, stakers are rewarded with new ETH from inflation. In the future, the Beacon Chain and Ethereum as we know it will merge, allowing stakers to also earn the transaction fees and Miner-Extractable Value ([MEV](https://research.paradigm.xyz/MEV)) that currently go to PoW miners. Ethereum’s PoS protocol does not provide stakers with some of the functionality they have come to expect in other PoS implementations like Cosmos, Tezos, and Polkadot. The rationale behind that is to incentivize decentralization, but we posit that the market will always step in to make staking more efficient and convenient. So it is important to ensure that the solution that has the most private benefit to stakers also leads to a healthy systemic outcome for Ethereum as a whole. In this post, we explore the problems that ETH stakers experience today. We then show how staking pools and staking derivatives solve these problems for stakers while, counterintuitively, also increasing the effective security of the network ## How does solo staking ETH work? To solo stake in Ethereum, a user has to deposit 32 ETH to the [*ETH2 Deposit Contract*](https://etherscan.io/address/0x00000000219ab540356cbb839cbe05303d7705fa#code), along with specifying two key parameters: 1. The *validator public key*: Before depositing, the user generates a keypair for their validator. The private key is used to sign on blocks, whereas the public key serves as their unique identifier. 2. The *withdrawal credentials* for the deposited 32 ETH: Once withdrawals are enabled, the principal (32 ETH) and staking rewards can only be withdrawn to this address. Critically, the public key and withdrawal credentials do not need to be controlled by the same entity. The user is then expected to operate an ETH2 validator node and sign on blocks when it’s their turn, or get penalized for not following the protocol. ## What are the problems of ETH stakers? The efficiency and convenience of a staking protocol can be broken down into the following properties, along with their Ethereum implementation: | Project | Forge | Dapp | Speedup | -- | -- | -- | -- |[guni-lev](https://github.com/hexonaut/guni-lev/) | 28.6s | 2m36s | **5.45x** |[solmate](https://github.com/transmissions11/solmate) | 6s | 46s | **7.66x** |[geb](https://github.com/reflexer-labs/geb) | 11s | 40s | **3.63x** |[vaults](https://github.com/rari-capital/vaults) | 1.4s | 5.5s | **3.9x** These properties represent significant hurdles for stakers. All else equal, they would prefer to be able to stake any amount of ETH, delegate the operation of their infrastructure, and withdraw their staked ETH instantly. If possible, they would also like to use their staked ETH in other applications, as has become standard procedure in decentralized finance. Below, we discuss - how staking pools solve delegation and the minimum stake requirement; and - how staking derivatives—issued by these staking pools—address the long lockup and allow stakers to unlock liquidity on their staked ETH. ## How does a staking pool work? On its face, a staking pool works similarly to a mining pool in PoW, but due the nature of PoS it can offer additional benefits to its customers: 1. By pooling ETH together, stakers can bypass the 32 ETH minimum requirement. This allows smaller stakers to participate in PoS. 2. Instead of having each user operate their own validator(s), the pool handles the operational aspect of staking. Some may also insure customers against protocol penalties like slashing. 3. The pool can maintain a reserve of liquid ETH to satisfy demand for immediate withdrawal, similar to how a bank would. This eliminates the withdrawal period, assuming that not all customers want to withdraw at the same time. 4. Finally, the pool can offer a token that represents the staked ETH which can be used in other applications. This point is so important that we dedicate a full chapter to its discussion further below. Staking pools can either be centralized or decentralized, each with their own set of tradeoffs. ### How does a centralized staking pool work? Any big exchange can trivially implement a staking pool. In fact, many [already](https://support.kraken.com/hc/en-us/articles/360052734432-Ethereum-2-0-staking-FAQ) [support](https://www.binance.com/en/eth2) ([or will support](https://help.coinbase.com/en/coinbase/trading-and-funding/staking/ethereum-2-0-staking)) Beacon Chain staking. The exchange simply needs to: 1. Allow users to opt into staking, in return for staking rewards. 2. Run the validators using the customer’s ETH. Since the exchange does the staking, the user does not need to run any infrastructure. Offering instant liquidity is very easy for them as well, since they already have large liquid ETH reserves. Given how valuable customer acquisition and liquidity is to the exchange business, they can offer this service at no additional cost to the user. ### How does a decentralized staking pool work? Now that we have established the differences between solo and pooled staking, as well as how centralized staking pools work, we will explore the architecture of a decentralized staking pool, using [Lido](http://lido.finance/) as an example. From the user’s perspective, things are very straightforward: They deposit ETH into an Ethereum smart contract, and receive stETH as a receipt. The stETH token’s balance adjusts over time to reflect the distribution of staking rewards that accrue to the contract. That means, 1 stETH will always represent 1 ETH staked. From Lido’s perspective, each time 32 ETH is buffered on the Ethereum smart contract, the DAO selects a new validator from a governance-controlled registry. It then calls the deposit contract, assigning the 32 ETH to that validator’s public key, and uses the LidoDAO’s withdrawal credentials. There are two questions that need to be answered here: - **How are the withdrawal credentials managed?** The withdrawal credentials are an ETH2 BLS key, [split to a 6-of-11 multisig using a distributed key generation ceremony](https://blog.lido.fi/lido-withdrawal-key-ceremony/). This is not optimal, but also not a risk while withdrawals from the Beacon Chain are not enabled. By the time stakers can withdraw, Lido will have transitioned to an ETH1 smart contract as the withdrawal credential instead of a multi-sig. After that point, 1 stETH will be trustlessly redeemable for 1 ETH, assuming the smart contract has no administrative functionalities over the funds. - **Who are the validators and how do they get into the registry?** Validators are [professional staking businesses](https://mainnet.lido.fi/#/lido-dao/0x55032650b14df07b85bf18a3a3ec8e0af2e028d5/) like p2p.org, Chorus One, or stakefish, that have to be approved by governance. Each validator has a maximum stake that they can own, which is also voted on by governance. ## Unpacking the stETH token We have already established that stETH is a claim on staked ETH and any rewards accruing in the smart contract. This is also called a *staking derivative*. Staking derivatives will have a major impact on the entire Ethereum ecosystem, including ETH stakers, regular ETH holders, the competition between pools, and even Ethereum itself. **Stakers**: The main benefit for stakers is rehypothecation, which allows them to stake while simultaneously using the principal in other applications, similar to how Uniswap’s LP tokens can be used as collateral across DeFi. This greatly lowers the opportunity cost of staking. **Non-staking ETH holders**: If stETH can be used as collateral to borrow ETH, it can unlock demand to borrow ETH to use it in leveraged staking. This would push up the rates for supplying ETH[1](https://www.paradigm.xyz/2021/04/on-staking-pools-and-staking-derivatives#fn1), ultimately benefiting all ETH holders with higher interest rates. **Competition between pools**: The existence of stETH grants its pool an important network effect. This network effect creates a strong incentive to stake with the market leader, which indicates that ETH staking derivatives could follow a power-law or winner-take-all distribution due to the liquidity moat and network effects associated with them. As a result, it is possible that stETH will replace ETH in many use cases, and potentially even replace ETH altogether. **Ethereum**: There exists a popular argument that staking derivatives lower the security of PoS because they separate block production from staking and slashing. This is also known as a principal-agent problem, and can lead to scenarios where the block producers may not be incentivized to follow the protocol since they have nothing at stake. However, this argument has to be weighted against the benefits: If staking derivatives lower the cost of staking, they could lead to far more (or even all) ETH being staked. Note that this is a perfect example of a virtuous cycle: the more liquid stETH becomes, the lower the opportunity cost of staking, which leads to more ETH being staked, which in turn further deepens the liquidity of stETH, and so on. Without staking derivatives, we might expect 15-30% of ETH to be staked. However, *with* staking derivatives, this number could be as high as 80-100%, because there is no additional cost to staking compared to non-staking. To show why this leads to higher economic security, consider the following attack scenarios: - If 20% of all ETH is staked, and an attacker wanted to acquire 66% of all stake (a critical threshold to corrupt the chain), they would have to buy 40% of all ETH in the open market. - If 60% of ETH were staked, but the stETH is liquid, then the attacker would have to buy 66% of all stETH, which also comes down to 40% of all ETH. Note that this has additional steps, where the attacker would first have to redeem the stETH to remove the honest validators and then re-stake their ETH. - Above 60% staked, the share of all ETH the attacker would have to buy is now higher than 40% and only increases from there. - If 100% of ETH are staked, then the attacker would need 66% of all stETH to get to the same threshold. **We can conclude that if staking derivatives can increase the number of ETH staked above 60%, they would strictly increase Ethereum’s economic security instead of decreasing it.** ## So who will win the staking market? Decentralization is often seen as an invisible benefit that comes at a higher price, and as a result users are often not willing to pay for it (see e.g. Binance Smart Chain vs Ethereum debate). This line of thinking does not apply to decentralized staking pools, because they have three critical advantages over their centralized counterparts. - **They are more socially scalable:** One metric that matters for PoS security is how much of the stake is controlled by a single entity. For exchanges, that number might be capped at 15-30%; at more than that, there might be social concerns about power centralization in the Ethereum ecosystem. A decentralized staking pool can control any share of the network, as long as each individual validator in the DAO is not too big and as long as the withdrawal credentials cannot change / be voted on.We have to emphasize how important it is that the decentralized staking pool by that point *has shed all of its governance functionality*. Neither fees, nor withdrawal addresses, nor the validator registry can be allowed to be changed by human inputs. - **Their staking derivative is trustless:** A large exchange like Coinbase or Binance can only issue a custodial token, whose adoption is necessarily capped as—all else equal—users strictly prefer a trustless token over a trusted one. This causes centralized pools to miss out on the staking derivative’s network effect.One could point out that with WBTC, a centralized token was able to win the market for tokenized BTC. However, we posit that this is only because BTC on Ethereum can’t be tokenized in a way that is both trustless and capital-efficient, whereas for staked ETH that is possible. - **They have fewer restrictions around MEV Extraction:** Institutional staking pools (e.g. exchanges) may have social and reputational constraints that prevent them from extracting certain forms of MEV. This allows smaller staking firms and decentralized pools without these constraints to provide higher returns for their stakers. This could turn the aforementioned decentralization premium for using a decentralized staking pool into a *decentralization discount*. **These benefits are so large, that the leader in pooled staking will likely be a decentralized / non-custodial staking pool. If said pool is sufficiently governance-minimized, it could possibly win the entire market without causing any systemic risk for Ethereum.** ## Conclusion Staking pools and their staking derivatives are subject to similar market realities as MEV extraction, in the sense that their existence is inevitable. As long as there is a private benefit to creating and using them, they will exist and flourish. However, if the right solution wins and is sufficiently adopted, it can lead to systemic benefits for Ethereum as well. Due to stETH’s vast network effect and the fact that decentralized pools can be both non-custodial and possibly earn more revenue from MEV, we see it as likely that a single such decentralized pool can win the whole market. As a result, we should be focused on making sure a non-custodial and robust version of stETH wins the market instead of a centralized one, to ensure a good systemic outcome. ## *Notes* *1 - We also refer the reader to Chitra and Evans’ work on *[*staking versus lending*](https://arxiv.org/abs/2006.11156)* and the *[*equilibria*](https://arxiv.org/abs/2001.00919)* which manifest between these 2 forces. *[*↩*](https://www.paradigm.xyz/2021/04/on-staking-pools-and-staking-derivatives#fnlink1) *Disclaimer:* *Paradigm owns LDO tokens* Acknowledgments: Thanks for valuable discussions and reviews to [Arjun Balaji](https://twitter.com/arjunblj), [Vasiliy Shapovalov](https://twitter.com/_vshapovalov), [Konstantin Lomashuk](https://twitter.com/Lomashuk) ## https://www.paradigm.xyz/writing/uncovering-a-four-year-old-bug # Uncovering a Four Year Old Bug > Uncovering a Four Year Old Bug *Every adventure requires a first step - The Cheshire Cat* What does it take to find a bug? What about one in a contract that's survived the test of time? The journey to a critical vulnerability isn't always straightforward and might begin when you least expect it. A few weeks ago I tweeted about a critical bug I had found. The bug affected contracts that are over four years old and now manage over a billion dollars in assets. Today, I'll tell you the story of how it happened. # The White Rabbit It was just after lunch when I got a push notification from one of the Ethereum security group chats. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--7b04a58929/01a183a62aab6367e2fb892d1231f20d/asset-https-cdn-sanity-io-images-dgybcd83--7b04a58929.png) This immediately caught my attention for two reasons: 1. Most users of go-ethereum (geth) will normally never run into an error, because the software is written to be extremely resilient 2. This error was occurring on the latest version of geth, meaning it had all the newest security patches Having just found a [bug](https://samczsun.com/undisclosed/) in geth myself recently, I couldn't help wonder if there was an ongoing attack. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--c3e4ab6575/40e724a575f43f548df62577251e429c/asset-https-cdn-sanity-io-images-dgybcd83--c3e4ab6575.png) Anatol confirmed that the block was indeed on mainnet and shared his log file to help with debugging. ```bash ########## BAD BLOCK ######### Chain config: {ChainID: 1 Homestead: 1150000 DAO: 1920000 DAOSupport: true EIP150: 2463000 EIP155: 2675000 EIP158: 2675000 Byzantium: 4370000 Constantinople: 7280000 Petersburg: 7280000 Istanbul: 9069000, Muir Glacier: 9200000, YOLO v2: , Engine: ethash} Number: 11805072 Hash: 0x0b3d0081b32c2159e2b77e5f2c798b737d0ae1a822669614c989377947c71ada 0: cumulative: 123312 gas: 123312 contract: 0x0000000000000000000000000000000000000000 status: 1 tx: 0x9bdf8792e0d6b62a68b9dbd849d60ca78ae6512d9a838d575d4f51d36a7ae095 logs: [0xc12c5d6000 0xc12c5d60b0 0xc12c5d6160 0xc12c5d6210 0xc12c5d62c0] bloom: 00200000000000040000000080000000000000000000001000010001000000000000000000000000000000000000000002000000080800000000000000000000000000000000000000000008000000200000000000000000000000008000010000000000000000000000000000000010000000000000000000000010000000000000000000000000004000000000000000000001000000080000004000000000000000000000000000000000000000000000000000000000000000000000000000008002000082000000000040000000000000000000001002000000000020000000200000000000000000000000000000000000000000400080000000000000 state: [snip] 203: cumulative: 11152534 gas: 45752 contract: 0x0000000000000000000000000000000000000000 status: 1 tx: 0x63fe497529605f75abdaa5b026ef5e6d878fca827a7ee2a3168d9c4f0347baef logs: [0xc127c05970] bloom: 00000000000000000000000000000000000000000800000000010000000000000000000000000000000000000000000000000800000000000000000000200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000020000034000000000000000000000000000000000000000000000000000000000000 state: Error: invalid gas used (remote: 12458355 local: 11152534) ############################## ``` This error says that the block header claimed that all of the transactions used a total of `12458355` gas, but when the node executed all of the transactions it only used `11152534` gas instead. I first double-checked that my own node knew of the suspicious [block](https://etherscan.io/block/11805072). ```bash $ seth block 11805072 hash 0x0b3d0081b32c2159e2b77e5f2c798b737d0ae1a822669614c989377947c71ada ``` Given that the block hash matched, I knew that this wasn't an exploit but rather some sort of error with Anatol's node. The error log tells us the gas used by each transaction, so I quickly wrote a script to check each transaction in the block and compare the actual gas used with what Anatol's node reported. This let me pinpoint the [offending transaction](https://etherscan.io/tx/0x4048958b7c522cb182951a8bb82814ff04d56cbf049ebc8f430d818c70a178dd). ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--6e67e37184/90e1ee6a125f7cfbad3738968f16f916/asset-https-cdn-sanity-io-images-dgybcd83--6e67e37184.png) I knew that there must be some difference in state between Anatol's node and mainnet, so I DMed him for RPC access so I can inspect the contracts that the offending transaction interacted with. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--2a76c9e3c2/a5e1eda164d7ca04b312173f1e0a61e9/asset-https-cdn-sanity-io-images-dgybcd83--2a76c9e3c2.png) The transaction in question was a simple ERC20 transfer, so I quickly simulated it on Anatol's node, which failed. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--de625df0d3/ec969375aa7a8b954eed9d756447dfba/asset-https-cdn-sanity-io-images-dgybcd83--de625df0d3.png) I quickly confirmed that the sending account contained enough tokens so all that was left was to comb through each sub-call to see where the gas usage discrepancy came from. After wrangling with `seth` for a bit, I found the root cause. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--d08f665e1e/b930d5a34cb0c6f030e9e05e6d01dcca/asset-https-cdn-sanity-io-images-dgybcd83--d08f665e1e.png) [This contract](https://etherscan.io/address/9e6d0f3cdedab391483b234e6c06bc35aaba75c7#code) contains an address in storage slot 0 on mainnet but no address on Anatol's node, a clear indication that there was some storage corruption. Anatol revealed that he actually restored the geth database from a backup, so most likely something got lost along the way and the node couldn't read the storage entry for that specific contract. Given that it'd be practically impossible to figure out what else was corrupted, I recommend he give snap sync a shot to quickly get his node back up and running. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--482b348b45/4ed21d489ca94a30213f099907693eee/asset-https-cdn-sanity-io-images-dgybcd83--482b348b45.png) # Cake and a Drink Earlier I had noticed that in order to be ERC20-compliant, each token contained two functions which emitted `Transfer` and `Approval` functions which could only be called by the `EToken2` contract. It would be extremely interesting if I could somehow trick the `EToken2` contract into emitting fake events, so I focused on this first. There was only one place in the `EToken2` contract which triggered a token to emit the event, and that was in `_proxyTransferEvent`. ```solidity function _proxyTransferEvent(uint _fromId, uint _toId, uint _value, bytes32 _symbol) internal { if (proxies[_symbol] != 0x0) { // Internal Out Of Gas/Throw: revert this transaction too; // Recursive Call: safe, all changes already made. Proxy(proxies[_symbol]).emitTransfer(_address(_fromId), _address(_toId), _value); } } ``` Interestingly though, the function didn't take the proxy directly but the symbol indirectly. This was a classic example of an indirection attack because if I could change the value of `proxies[_symbol]` then I would be able to trigger a `Transfer` event on any target I wanted. There were three calls to `_proxyTransferEvent`: minting would trigger an event from `address(0)` to `msg.sender`, burning would trigger an event from `from` to `address(0)`, and transferring would trigger an event from `from` to `to`. The first two were not particularly useful because I could only control at most one of the two parameters, but the last was interesting because I could potentially trigger a `Transfer` event from an arbitrary address to an arbitrary address. Unfortunately, here I ran into a problem. The only way to reach the `_transfer` function was through the `proxyTransferFromWithReference` function, and that function would only allow the address specified in `proxies` to trigger a transfer for the specific symbol. This meant that if I owned a token and updated my proxy to the proxy for another token, I would no longer be able to trigger the transfer to cause the exploit. It seemed like this potential exploit was dead, but I was reluctant to give up on it so I scrolled around some more. It was then that I really looked closer at the function signature for `_transfer`. ```solidity function _transfer( uint _fromId, uint _toId, uint _value, bytes32 _symbol, string _reference, uint _senderId ) internal checkSigned(_senderId, 1) returns (bool); ``` I had completely dismissed the `checkSigned` modifier because it was obviously a no-op in the default configuration. If it was significant, then users would have to submit some sort of signature with each transfer and that was obviously not happening. Now, with nowhere else to turn, I decided to look into what exactly `checkSigned` was doing. ```solidity function _checkSigned(Cosigner _cosigner, uint _holderId, uint _required) internal returns(bool) { return _cosigner.consumeOperation(sha3(msg.data, _holderId), _required); } modifier checkSigned(uint _holderId, uint _required) { if (!isCosignerSet(_holderId) || _checkSigned(holders[_holderId].cosigner, _holderId, _required)) { _; } else { _error('Cosigner: access denied'); } } ``` Incredible! It turns out that `checkSigned` actually performed an external call if a `Cosigner` is set for a user. This would explain why I never saw any users providing any signatures for a simple transfer. At the same time, this security feature was exactly what I needed to finalize my exploit. I've talked about how reentrancy is really just a subset of what I've dubbed *unsafe external calls*, because the real risk is in the fact that control flow is handed to a third-party contract which can then go and do whatever it wants. The attacker could choose to reenter through the same function, but they could just as well do anything else, and this is a great example of that. The problem I was facing was that I needed `proxies[symbol]` to be my own proxy before the transfer call, but a different value after I had begun the transfer process. Now with the cosigner functionality, I could set a custom cosigner which would swap my symbol's proxy when it receives a call to `consumeOperation`. This call would happen after the call to `proxyTransferFromWithReference` but before the call to `_proxyTransferEvent`, allowing me to trigger an arbitrary event on any `EToken2`-issued token! # Pepper This was a good start, but the impact was not quite what I was looking for. This was because `EToken2` is a whitelisted platform and only a centralized authority could issue new tokens. If I were an attacker and I wanted to pull off this attack, I would have to sign up and probably go through KYC/AML, which is obviously not ideal. It was also unclear who exactly might be affected by this bug, and I couldn't really go and test it for myself. Undeterred, I stowed this finding away and kept looking for something else. While scanning through the contract, I noticed some interesting logic for transferring access from one user to another. ```solidity function grantAccess(address _from, address _to) returns(bool) { if (!isCosignerSet(getHolderId(_from))) { _error('Cosigner not set'); return false; } return _grantAccess(getHolderId(_from), _to); } function _grantAccess(uint _fromId, address _to) internal checkSigned(_fromId, 2) returns(bool) { // Should recover to previously unused address. if (getHolderId(_to) != 0) { _error('Should recover to new address'); return false; } // We take current holder address because it might not equal _from. // It is possible to recover from any old holder address, but event should have the current one. address from = holders[_fromId].addr; holders[_fromId].addr = _to; holderIndex[_to] = _fromId; // Internal Out Of Gas/Throw: revert this transaction too; // Recursive Call: safe, all changes already made. eventsHistory.emitRecovery(from, _to, msg.sender); return true; } ``` As it happens, I was so engrossed in figuring out how exactly to swap around the proxy that I didn't pay attention to what was actually going on in the contract. Notice that in the signature for `_transfer`, the from and to values are actually `uint`, not `address`. The `EToken2` contract maintains a mapping of users (`address`) to holder id (`uint`) and this was the logic for granting your holder id to another address. The moment I realized this, I started studying this function in earnest. At a high level, this function essentially transferred ownership of some data from one entity to another, and one common mistake to make when implementing this sort of internal ownership transfer is to update the receiver correctly but forget to invalidate the sender. If the receiver isn't updated correctly, any sort of testing will instantly reveal that there's a problem. If the sender isn't invalidated correctly, simple tests might not notice anything wrong. Looking closer at the implementation of `_grantAccess`, I saw that it was intentionally designed such that it's possible to determine the previous address that owned a specific holder id. This was intended to allow a user who accidentally granted access to the wrong wallet to still maintain ownership, but intuitively I knew something was off here. Even still, I couldn't quite figure out what that was at first glance. After all, if an attacker were to grant access to their holder id to another user, that's just putting their own funds at risk. Why would anyone want to do that? After stewing on it for a little bit, I realized that I was looking at it in the wrong way. The key was that while the other user would have full ownership over "my" holder id, I would also have full ownership over "their" holder id. In other words, I would be able to backdoor any new user of the `EToken2` platform and gain full access to their account, which translates to control over any `EToken2`-issued token they owned. It was a quick step from there to figure out how to weaponize this exploit. I needed to grant access to a user before they first use the `EToken2` platform, but I can't just go around granting access to random addresses. The solution was clear - I could just scan the mempool for transactions which would result in a user becoming registered with the `EToken2` platform, and then frontrun any transactions I find. What's more, because of `EToken2`'s architecture, I wouldn't just be attacking a single token but multiple tokens with multi-million dollar market caps. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--2c99e144a5/6ab5c3f973ccfeaf350224e30387432b/asset-https-cdn-sanity-io-images-dgybcd83--2c99e144a5.png) ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--4620d5981d/5187266fd2b171086d3508cb0fd2e7da/asset-https-cdn-sanity-io-images-dgybcd83--4620d5981d.png) ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--1ed3d7feba/917518255ae8225fe3cf094c41893a2f/asset-https-cdn-sanity-io-images-dgybcd83--1ed3d7feba.png) ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--9175f1dd98/5cde5275dab32db9324e90d7cba7f1e5/asset-https-cdn-sanity-io-images-dgybcd83--9175f1dd98.png) At this point, I knew I had found what I was looking for, and it was time to contact the project. # 52 Finding the bug was one thing, but fixing it was another. `EToken2` had been designed to be non-upgradable, but forcing every single token issued on top of `EToken2` to migrate their data to a new contract would be unduly burdensome. Oleksii, fellow white hat and also the head architect at Ambisafe, agreed. We had to find another way. There weren't many things in `_grantAccess` that could revert. In fact, there was only one. The very last line in the function logged an event using the `eventHistory` contract. If this call reverted, then so would the call to `_grantAccess` and it would be impossible for anyone to backdoor another account. However, the [EventsHistory](https://etherscan.io/address/0x60bf91ac87fee5a78c28f7b67701fbcfa79c18ec#code) contract doesn't allow administrators to redefine the handler for an event. ```solidity function addVersion(address _caller, string _name, string _changelog) noValue() checkAccess("admin") returns(bool) { if (versions[_caller] != 0) { return false; } if (bytes(_name).length == 0) { return false; } if (bytes(_changelog).length == 0) { return false; } uint version = ++latestVersion; versions[_caller] = version; versionInfo[version] = VersionInfo(block.number, msg.sender, _caller, _name, _changelog); return true; } function () noValue() { if (versions[msg.sender] == 0) { return; } // Internal Out Of Gas/Throw: revert this transaction too; // Call Stack Depth Limit reached: revert this transaction too; // Recursive Call: safe, all changes already made. if (!emitters[msg.sig].delegatecall(msg.data)) { throw; } } ``` It seemed like we were at a dead end, but we quickly realized the situation wasn't nearly as bad as it appeared. Although the `EventsHistory` contract was intended to be immutable, it too had a bug which could be "exploited" by the admins. Each emitter was handled using a `delegatecall`, which causes the code to be executed with the current contract's context. If we wanted to perform an upgrade on the `EventsHistory` contract, we could just register a [fake emitter](https://etherscan.io/address/0x197EeC05Dd08178C1006F9475219ee004bcca08e) which would perform the upgrades we wanted by directly writing to storage. Oleksii quickly wrote a few contracts to patch up the vulnerabilities I had found. The first would replace the handler for the `emitRecovery` function and would require that any addresses being granted access had explicitly opted in to being granted access. The second would replace the handler for all ERC20-related events and would require that the proxy contract for a given symbol was the expected proxy. The third would perform the upgrade on the `EventsHistory` contract by replacing the handlers and then forever disable the ability to register new emitters, making the contract truly immutable. On April 6th, a mere 4 days after I had taken that first step, the upgrades were deployed and this saga was forever [immortalized](https://etherscan.io/tx/0x0825e01f1253fc2592e54e23201e99ae0880a947033108bfa1ca868a23886475) on the blockchain. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--814301f9db/ca7d229e1f1188ffac44fd733a3aa5e9/asset-https-cdn-sanity-io-images-dgybcd83--814301f9db.png) *Acknowledgments: Special thanks to *[*Anatol*](https://twitter.com/shark0der)* for the very special role he played in this and *[*Oleksii*](https://github.com/lastperson)* for sacrificing his weekend in order to resolve this with me.* ## https://www.paradigm.xyz/writing/understanding-automated-market-makers-part-1-price-impact # Understanding Automated Market-Makers, Part 1: Price Impact > Every day, thousands of people use a decentralized exchange (DEX) for the first time. However, the idiosyncrasies of a public blockchain routinely catch newcomers off-guard, even those familiar with trading on more traditional venues. Every day, [thousands of people use a decentralized exchange (DEX) for the first time](https://www.theblockcrypto.com/data/decentralized-finance/dex-non-custodial). However, the **idiosyncrasies of a public blockchain** routinely catch newcomers off-guard, even those familiar with trading on more traditional venues. As a result, traders bleed money to arbitrageurs and frontrunners, leading to worse-than-necessary execution. At a high level, we can break down the costs of each trade into several parts: 1. **Price impact** 2. **Broker or trading fees** 3. **Slippage** 4. **Transaction fees of the underlying blockchain** This article on automated market-makers (AMMs) will serve as an intro to the series and discuss the first and most crucial cost: price impact. You will learn - how AMMs like Uniswap v2, Sushiswap, and Balancer[1](https://research.paradigm.xyz/amm-price-impact#fn:1) determine the prices they quote; and - how to minimize the price impact of your trade using a few simple strategies. # What are liquidity pools? Most DEXs consist of many **liquidity pools** that represent different trading pairs, like ETH/WBTC. Instead of matching buyers and sellers in an orderbook, these liquidity pools act as an **automated market maker**. A liquidity pool is a smart contract that holds reserves of two or more tokens and allows anyone to deposit and withdraw funds from them, but only according to very specific rules. One such rule is the **constant product formula x \* y = k,** where x and y are the reserves of two tokens, A and B. In order to withdraw some amount of token A, one must deposit a proportional amount of token B to maintain the constant k before fees.[2](https://research.paradigm.xyz/amm-price-impact#fn:2) # How does an AMM determine its price? From the constant product formula it follows that the price of that token A is simply *price_token_A = reserve_token_B / reserve token_A*. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--38aabd457f/e5388f3c967a87548230080d8ca0cafa/asset-https-cdn-sanity-io-images-dgybcd83--38aabd457f.png) *Chart 1: Different AMM formulas result in different pricing curves. When a hypothetical Uniswap v2 liquidity pool has 15 Y-tokens, it will only pay 0.1 X-tokens for the marginal Y-token. But when it has only 2.5 Y-token, it will pay 4.0 X-tokens. Other pricing curves are designed to concentrate more liquidity around a certain price (e.g. 1.0 for stablecoins). Source: Curve Whitepaper* To look at a real-world example, at the time of writing there are 2,700 WBTC and 86,000 ETH in Uniswap’s [ETH/WBTC pool](https://info.uniswap.org/pair/0xbb2b8038a1640196fbe3e38816f3e67cba72d940). This reserve ratio implies that ETH’s **market price** at the time of writing is 2,700 / 86,000 = 0.0314 WBTC. Crucially, **the AMM does not update this price as other markets move around it**. The market price only moves as the reserve ratio of the tokens in the pool changes, which happens when someone trades against it. To explore an example, what happens if the price on Binance falls to 0.0310 WBTC? That implies Uniswap LPs are currently buying ETH at a premium, creating an **arbitrage opportunity**. As a result, **arbitrageurs** buy the “cheap” ETH on Binance and sell it on Uniswap for an immediate profit. They keep doing this until the next unit of Uniswap ETH only pays 0.0310 WBTC—same as on Binance—and they can no longer profit by selling more. In our example above, this point is reached after selling 550 ETH to the pool for 17.2 WBTC (ignoring fees and gas for simplicity). As a result, even though AMMs don’t update their prices based on incoming real-world information, traders can still expect the price quoted by an AMM to [closely track the global market price because of continuous arbitrage](https://web.stanford.edu/~guillean/papers/uniswap_analysis.pdf). # What is Price Impact? While we learned how to compute the current market price from the ratio of two token reserves, this market price only shows the **price the AMM wants for the marginal token**. However, in practice, a trader will often buy or sell many tokens at once, with every token costing more than the previous one. This **difference between the current market price and the expected fill price is called **[**price impact**](https://uniswap.org/docs/v2/protocol-overview/glossary/#price-impact). Price impact is a function of - the size of your trade relative to the size of the liquidity pool; as well as - the trading rule being used (e.g. constant product formula). ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--b01c1e9761/d588768906511f30fcd3ac72e62cd179/asset-https-cdn-sanity-io-images-dgybcd83--b01c1e9761.png) *Price impact of different trade sizes* Chart 2: Comparing the average fill price (left y-axis) and price impact (right y-axis) for different order sizes (x-axis). Both factors increase with order size. The larger the order relative to the pool, the further above the market price will the trade get filled. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--0d56ad9630/3cb61e051d06df3ced8f22ea4d468253/asset-https-cdn-sanity-io-images-dgybcd83--0d56ad9630.png) *Price impact of sell order on different pool sizes* *Chart 3: Comparing the average fill price (left y-axis) and price impact (right y-axis) of a 10 WBTC sell order on different pool sizes on Uniswap V2 (x-axis). The pool size is the total value of the pool including the reserves of both assets. The orders represent 0.19%, 1.85%, and 18.52% of the pool respectively. So a good rule of thumb is that ****the price impact of your order is about twice the size of your order relative to the pool****.* # How can Price Impact be minimized? As we alluded earlier, price impact can represent a large share of a trade’s overall execution cost. Here are some simple strategies to minimize it: - **Find the deepest market:** So far, we established that price impact is a function of trade size relative to the size of the pool or market. It follows then that we want to **find the pool that has the most liquidity in the price range we care about**, which is where we will get filled closest to the market price. A token’s [depth table on Coingecko](https://www.coingecko.com/en/coins/uniswap#markets) is a good starting point to analyze this. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--79f0d6f4d3/eaee236e6c9677a53fa8089bf2a62394/asset-https-cdn-sanity-io-images-dgybcd83--79f0d6f4d3.png) *Comparing market depth* *Chart 4: Trading pairs for UNI, sorted by liquidity within 2% of the market price. Note the difference in spread between Uniswap and Bitfinex. Source: Coingecko* - **Look outside of DeFi:** While this is a post on AMMs, we won’t pretend you can always get the best execution on-chain. In fact, since the AMMs discussed spread their liquidity across a continuous range of prices, they often have little liquidity concentrated around the current market price. This is a known problem that many DEXs are trying to solve, for example, Uniswap v3 will [allow market makers to place their liquidity concentrated around the current market price](https://uniswap.org/blog/uniswap-v3/), making prices more competitive to CEXs as a resultWhen a trade moves the price on a DEX and the same token trades in other markets, an arbitrage opportunity is created. As discussed, arbitrageurs will “backrun” the trade (i.e., insert their own transaction immediately after) and move the price back to the global market price. It’s easy to see why **the existence of such an arbitrage is itself proof of an execution mistake**, as the trader is donating capital to the arbitrageur. This begs the question: should you execute an on-chain trade with more than 2-3% price impact if other markets exist? - **Mind the trading fee**: AMMs have a trading fee of 0.30%, which translates to a spread of 0.6% between the best buy order and the best sell order. Within this range, the AMM does not quote any prices. In other words, **even the most liquid AMM trade has an implicit 0.3% price impact**. Minimizing the impact of fees is extremely important, especially for trades that would have very little price impact on a CEX, so a CEX might be the better execution venue outright. (For comparison, the same trade would have a [0.10%](https://www.binance.com/en/fee/trading) fee on Binance and [0.07%](https://help.ftx.com/hc/en-us/articles/360024479432-Fees) on FTX.)That said, there are other reasons to pay more for DEX access, including retaining full custody or avoiding an onboarding, KYC, or deposit process. However, even in those cases, traders should be aware that their higher execution prices include an implicit **decentralization or instant liquidity premium**. - **Spread out trades**: First, it’s possible to split one trade into several smaller trades over time. This is especially relevant for traders who prefer to trade on a DEX in spite of other liquid markets existing outside DeFi. In that case, you can e.g., buy in 20% increments and let arbitrageurs revert the price after every trade. These five orders together will cause lower price impact than a single large order, but with the added tradeoff of higher gas costs and execution time. The larger the trade, the better this strategy is, as the fixed cost of gas decreases relative to the benefit of marginally better execution. This strategy also works when assets are mean reverting, e.g. stablecoins. - **The direct route is not always the cheapest**: Not every trade has a direct token pair, and even if it does, it may be cheaper to use a **bridge currency** instead. For example, while tokens A:B might have a direct pair, it is often cheaper to trade A → ETH → B, if these pairs are sufficiently more liquid. Aggregators are very useful in that regard, even if you just use them to look at their route suggestions. - **Use DEX aggregators**: Finally, you can use a DEX aggregator like 1inch, Matcha or Paraswap. Aggregators are the DeFi equivalent of [smart order routing](https://en.wikipedia.org/wiki/Smart_order_routing) and work because AMMs will sell the first token at a cheaper price than the tenth token. Whenever a token trades in multiple pools, aggregators will buy the token across all pools in order to minimize price impact on each one of them. Instead of spreading the trade over time in a single market, this order executes at once, spread over many possible markets. Aggregators also command substantially higher gas costs than a single trade, similar to splitting trades manually. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--7be88218a0/2f5cd492afe93d0be9eef29f38866cee/asset-https-cdn-sanity-io-images-dgybcd83--7be88218a0.png) Chart 5: The optimal strategy to buy 10 ($3,200), 50 ($16,000), 100 ($32,000), and 200 AAVE ($64,000) with ETH. The larger the trade, the more exchanges are added to the route to avoid moving any individual pool too much. Source: 1inch # Outlook In the second part this series, we will focus entirely on **slippage**. Almost all AMM trades are subject to frontrunning, causing them to be **filled at the maximum slippage the trader is willing to accept**. This is a unique “feature” of trading on a public blockchain that cannot be avoided with how decentralized exchanges work today. The cost can only be shifted around, leading us to formulate “The Sandwich Trilemma”. _Credits: Thanks for valuable discussions and reviews to [EvanSS](https://twitter.com/Evan_ss6), [Georgios Konstantopoulos](https://twitter.com/gakonst), [Dave White](https://twitter.com/_Dave__White_), [Dan Robinson](https://twitter.com/danrobinson), [Arjun Balaji](https://twitter.com/arjunblj), and [raul](https://twitter.com/raulGpoker)_ *Disclaimer: This post is for general information purposes only. It does not constitute investment advice or a recommendation or solicitation to buy or sell any investment and should not be used in the evaluation of the merits of making any investment decision. It should not be relied upon for accounting, legal or tax advice or investment recommendations. This post reflects the current opinions of the authors and is not made on behalf of Paradigm or its affiliates and does not necessarily reflect the opinions of Paradigm, its affiliates or individuals associated with Paradigm. The opinions reflected herein are subject to change without being updated.* ## Notes 1. Other forms of DEXs based on a central-limit order book (such as Serum) or batch auctions (such as Gnosis) are not in scope for this article. [↩](https://research.paradigm.xyz/amm-price-impact#fnref:1) 2. Fees slightly increase the k every trade [↩](https://research.paradigm.xyz/amm-price-impact#fnref:2) ## https://www.paradigm.xyz/writing/paradigm-ctf-2021-swap # Paradigm CTF 2021 - swap > Paradigm CTF 2021 took place in early February and together, players solved all but two of the challenges during the competition (and one of the remaining two mere days later). We're taking a look at the "swap" challenge in the form of a guided walkthrough. *When you have eliminated all which is impossible, then whatever remains, however improbable, must be the truth - Sherlock Holmes* Paradigm CTF 2021 took place in early February and together, players solved all but two of the challenges during the competition (and one of the remaining two mere days later). *Embed* However, the second of the two remained unsolved for almost 2 months until just a few days ago. *Embed* Today, we'll be taking a look at `swap` in the form of a guided walkthrough. Each section will give you a small hint at the end in case you're stuck. If you haven't already, take a look at the challenge files [here](https://github.com/paradigm-operations/paradigm-ctf-2021/tree/c84e7307769cdf08e76ab32755e0d3816ad3bff4/swap/public/contracts) and familiarize yourself with the code. ## The Challenge This challenge implements a fictional stablecoin AMM. Users can do all the things you'd expect from an AMM: swap assets and mint/burn/transfer LP shares. The contract is initialized with 100 ether worth of four stablecoins (DAI, TUSD, USDC, USDT) and the win condition is to reduce the TVL of the AMM to 1% of what it started with. Initially, you might assume that there's a bug in the `swap` function, but it's easy to confirm with reasonable confidence that the function behaves as expected and won't give you any free stablecoins. You might also try stealing the LP tokens from the setup contract itself, but the ERC20 implementation appears to be correct and so that's impossible too. You could try minting and burning LP tokens, but you'll find that the invariants appear to be correctly maintained and that you can't mint more LP tokens than you deserve, or burn more LP tokens that you have. Finally, just to really drive the point home, all functions are marked `nonReentrant`. At this point, the challenge is looking pretty hopeless so under contest conditions it's perfectly reasonable to just drop it and move onto a different problem. However, now that we have all the time in the world, how might we tackle this? Well, keen observers might notice that the win condition is slightly different in this challenge. In every other challenge, it's always required to drain the entire contract of all assets. However, in this challenge, you only need to drain a percentage. Why might this be? ## Everything Is Intentional One of the lessons I've learned the hard way is that everything in a CTF, no matter how innocuous, is intentional. In this sense, the win condition is a subtle hint towards what the solution requires. The fact that you don't need to drain all of the assets to win should strongly suggest that it's in fact *impossible* to drain all of the assets. But what does this mean for us? Working from first principles, we can reset our assumptions by following this chain of logic: 1. We need to remove (some, but not all) assets from the pool 2. The only way for assets to leave the pool is through a swap or a burn 3. Swapping appears to be correctly implemented such that no assets can be stolen 4. Burning also appears to be correctly implemented such that no assets can be stolen 5. However, while swapping is a single-step process, burning is a two-step process where the first step is somehow acquiring LP tokens. The burn operation itself says nothing about where the LP tokens come from, so there must be a way to get free LP tokens The subtle hint also reinforces this theory. Assuming that we can't steal the LP tokens from the setup contract, we'll never be able to burn 100% of all LP tokens and so we'll never be able to drain the entire contract. Under the assumption that there must be a way to get free LP tokens, can you figure out what the solution is? ## No Matter How Improbable There are only two ways to get LP tokens. The first is to mint them, and the second is to be transferred them. We've already established that the ERC20 implementation is sound (although you may want to double-check that before committing yourself to the more challenging route) which leaves us with the `mint` function. ```solidity struct MintVars { uint totalSupply; uint totalBalanceNorm; uint totalInNorm; uint amountToMint; ERC20Like token; uint has; uint preBalance; uint postBalance; uint deposited; } function mint(uint[] memory amounts) public nonReentrant returns (uint) { MintVars memory v; v.totalSupply = supply; for (uint i = 0; i < underlying.length; i++) { v.token = underlying[i]; v.preBalance = v.token.balanceOf(address(this)); v.has = v.token.balanceOf(msg.sender); if (amounts[i] > v.has) amounts[i] = v.has; v.token.transferFrom(msg.sender, address(this), amounts[i]); v.postBalance = v.token.balanceOf(address(this)); v.deposited = v.postBalance - v.preBalance; v.totalBalanceNorm += scaleFrom(v.token, v.preBalance); v.totalInNorm += scaleFrom(v.token, v.deposited); } if (v.totalSupply == 0) { v.amountToMint = v.totalInNorm; } else { v.amountToMint = v.totalInNorm * v.totalSupply / v.totalBalanceNorm; } supply += v.amountToMint; balances[msg.sender] += v.amountToMint; return v.amountToMint; } ``` The goal now is to somehow adjust `v.amountToMint` such that we are minted way more LP tokens than we deserve. We can start by reviewing the function itself again, but this time with a fine-tooth comb. The function begins by constructing an object to represent the local variables. Then, for each token, we record the current balance of the AMM as well as the balance of the sender. If the amount to be deposited is greater than the sender's balance, then we update the amount requested. We perform the transfer, record the current balance again, then update the total deposited counters appropriately. Nothing is immediately obvious, so we must begin eliminating the impossible and leave ourselves with only the improbable. Unfortunately, sometimes we might not know enough to immediately differentiate between the impossible and the improbable, so we'll need to keep an open mind. We can again reset our assumptions by working from first principles using the following chain of logic: 1. We clearly need to change `v.amountToMint` in such a way that the value is larger than what it should be 2. The equation to calculate the amount to mint is implemented correctly 3. Therefore, there must be another way to either tamper with `v.amountToMint` directly or to tamper with one of the values it depends on. Do you see any way to do this, even if it seems impossible or improbable at first? ## True Names Have Power Notice that `v.amountToMint` is a field on `MintVars memory v`. This means that any time we write to `v.amountToMint`, we're actually writing to memory. Unlike data on the stack (recall that the EVM is a stack-based VM), data in memory can be *aliased*, meaning that the same data can be accessed through multiple symbolic names. It just so happens that we have two pointers to memory in scope. The first is `MintVars memory v`, and the second is `uint[] memory amounts`. If we could somehow cause the latter to point to the same memory address as the former, then we could trigger undefined behavior by updating one through the other. In order to understand where the `amounts` variable comes from, we'll first take a brief detour to the land of the Solidity ABI. All transactions are but blobs of data, and it's the job of the ABI to define a standard way of parsing that blob into structed information. Before a contract's code is executed, Solidity inserts some logic which decodes the transaction data into the types that the code expects. Only then does the contract begin executing. In the case of `mint(uint256[])`, the ABI decoder will decode the transaction data into a single array of `uint256`. Is there some way that we can trick the ABI decoder into causing the decoded array to alias with the `MintVars` object constructed later? ## Around the World According to the Solidity documentation, the ABI encoding of an array is as follows: ```solidity <- 32 bytes -> OOOOO....OOOOO [offset to array start] [....] LLLLL....LLLLL [length in words] DDDDD....DDDDD [data #1] DDDDD....DDDDD [data #2] [....] DDDDD....DDDDD [data #L] ``` To parse that data, the ABI decoder runs the following pseudocode: ```solidity function decodeArrayAt(uint arg) private returns (bytes memory) { uint offset = read(0x04+0x20*arg); uint length = read(0x04+offset); bytes memory data = malloc(length); memcpy(data, 0x04 + offset + 0x20, length); return data; } ``` So far so good. Let's take a look at how `malloc` is implemented, again in pseudocode: ```solidity function malloc(uint size) private returns (bytes memory) { bytes memory buf; assembly { buf := mload(0x40) mstore(0x40, add(add(buf, size), 0x20)) mstore(buf, size) } return buf; } ``` Solidity uses what is known as a linear memory allocator (or arena-based allocator). This just means that Solidity will allocate new memory linearly along the block of total available memory. To allocate a new chunk, Solidity reads the *free-memory pointer* stored at `0x40` to determine where the next free address is, and moves it forward to reflect the fact that a new chunk of memory was just allocated. Notice that there are no checks to ensure that the amount of memory requested is not excessively large. This means that if one was to allocate a specific amount of memory, then the free memory pointer may overflow and begin re-allocating in-use memory. In this case, two calls to the pseudo-`malloc` might return pointers which alias each other. Fortunately for us, we can control exactly the size of memory the allocator will allocate simply by changing the ABI-encoded representation of our array. This lets us cause the allocator to allocate `v` over top of our `amounts` array. Can you figure out the final step to solving this challenge? ## Technical Difficulties Because `v` and `amounts` now alias each other, both will share the same values and updating one will update the other. This means that while you can manipulate `v` by writing into `amounts`, the reverse is true as well. As such, if you just tried to force some initial values into `v` by calling `mint` with some custom values, you might've found that your data kept getting clobbered by the writes to `v.totalSupply`, `v.totalBalanceNorm`, and `v.totalInNorm`. This means that some careful planning is needed to make sure that your values stay consistent over all four iterations of the loop. Additionally, `v.amountToMint` is updated *after* the four iterations, meaning that even if we try to write directly to `amounts[3]`, it'll just be overwritten with the correctly calculated value in the end. This means that we'll need to either make `v.totalInNorm` or `v.totalSupply` extremely big, or make `v.totalBalanceNorm` extremely small. To do this, we first swap out all of the stablecoins in the AMM except for DAI. This means that `v.totalBalanceNorm` will not increase after the first iteration because the AMM has no balance. This just makes our lives a bit easier later on. Next, we'll purchase the right amount of DAI/TUSD/USDC such that when `amounts[i] = v.has` is executed, we'll write our desired values into `v`. The balance of DAI will be written to `v.totalSupply`, so we'll want to set this to a large number such as `10000e18`. The balance of TUSD will be written to `v.totalBalanceNorm`, so we'll update that to `1`. Finally, the balance of USDC will be written to `v.totalInNorm` so we'll also set that to `10000e18`. There's no point manipulating the USDT balance because the value will be clobbered anyways. Finally, we just need to assemble our payload and send the transaction, giving us the flag we worked so hard for: `PCTF{hon3y_1_Ov3rFLOw3d_7h3_M3MOry}`. You can find the official solution [here](https://github.com/paradigm-operations/paradigm-ctf-2021/tree/master/swap/private/Exploit.sol). ## Conclusion This was by far the most complex challenge in the CTF and for good reason - it made use of a vulnerability that most people haven't heard of and very few people actively think about. It also challenged basic assumptions about what Solidity source code really does. However, I think it made for a great exercise in solving problems from first principles, eliminating assumptions, and exploring the entire search space. Hopefully you enjoyed this writeup and I'll see you next year at Paradigm CTF 2022! ## https://www.paradigm.xyz/writing/a-cosmos-thesis # A Cosmos Thesis > On Ethereum, all applications run on a shared state machine. In Cosmos, many application-specific blockchains pass assets and other messages between one another. If Ethereum is a mainframe computer, Cosmos is a protocol for networking independent servers. On Ethereum, all applications run on a shared state machine. In Cosmos, many application-specific blockchains pass assets and other messages between one another. If Ethereum is a mainframe computer, Cosmos is a protocol for networking independent servers. The mainframe approach works well while applications remain local to the platform. However, there is a limit to the number of applications each of these blockchains can support, and they are not designed to talk to one another. Today, congestion on the Ethereum mainchain drives applications to resettle on alternative L1’s and L2’s because they can’t afford to pay Ethereum’s metropolitan premium. Each new L{1,2} needs awkward middleware—“bridges”—to communicate with the others. Cosmos offers a different vision for an interchain future: one built around interoperability as a first principle. Cosmos believes that giving sovereign chains a shared communication standard is a natural step in the evolution of protocol design. This vision is inclusive, not competitive. Ethereum and other platforms will be able to integrate this interoperability model, too. ## What is Cosmos? Cosmos is not itself a blockchain—it is a blueprint for designing application-specific blockchains, called Zones. A world of many blockchains would not be realistic if each had to implement all of the networking and consensus code from scratch, so Cosmos provides template software to handle those functions, the [Cosmos SDK](https://cosmos.network/sdk). Years of work on the SDK has made [launching a Zone as easy as deploying a smart contract](https://cosmos.network/starport/). However, the approach is not unique to Cosmos: other projects that incorporate the idea of application-specific chains also give developers a “blockchain in a box” (for example, Polkadot’s [Substrate](https://polkadot.network/build/) framework, which is analogous to Cosmos’s SDK). Cosmos is unique because it achieves practical interoperability without enshrining a shared security layer. These features are best explained in contrast to Ethereum’s architecture. ### Security Models Ethereum’s security model is uniform. Every application deployed on Ethereum shares the same security level: that of the Ethereum ledger broadly. Because all Ethereum applications exist within a shared runtime, they are tightly coupled and interoperable by default. Cosmos’s security model, in contrast, is non-uniform. Each Zone (and roughly speaking, each application) must choose the level of security sufficient for its purpose and incentivize a rational market of validators to provide that security. Each Zone exists in its own runtime, so they are not interoperable by default, and communication requires a shared message-passing protocol. ### Interoperability Cosmos deals with the non-uniformity of security assumptions across Zones by treating interoperability as an opt-in market process: Zones, and their users, choose their level of exposure to the security risks of other remote Zones. Uncoupled Zones will not even pass assets. Fully coupled Zones may each be shards of a single consensus process. The integral of these pairwise relationships over an ecosystem of Zones is an emergent security topology – an interchain. The [Inter-Blockchain Communication (IBC) protocol](https://ibcprotocol.org/) is a general communication standard devised to enable every necessary flavor of interoperability. IBC can be applied to everything from simple asset transfers, to cross-Zone data availability proofs, to slashing validators on remote Zones (i.e., fully shared security). Additionally, any blockchain that uses a consensus mechanism with finality can implement IBC and can join the Cosmos Network. For example, ETH2’s Gasper, Polkadot’s GRANDPA, and Libra’s HotStuff are all IBC-compatible. *Everything* is a Cosmos Zone, by design. IBC works in production today. The first standardized application, cross-Zone asset transfers, went live [last week](https://twitter.com/cosmos/status/1376529756938702855?s=20). This composability model is already sufficient for most DeFi applications; see Vitalik’s argument which [covers many notable examples](https://ethresear.ch/t/cross-shard-defi-composability/6268) (AMM’s, lending, etc.). ## Cosmos’s Pitch To recap, in Cosmos, every application is encouraged to deploy as a sovereign Cosmos Zone. Cosmos provides the core software substrates needed to develop these blockchains and make them interoperable (the SDK, IBC, etc.). Cosmos treats interoperability as a spectrum and allows every chain on the network to choose how it interacts with the others. Collectively, these relationships form the Interchain. So, why might you find Cosmos’s model attractive? ### Advantages of Sovereign Chains 1. **Scalability**: networks of application-specific chains are more scalable than chains where everything has to be secured by all validators; even sharded platforms have upper limits. Cosmos Zones scale out “horizontally” through dynamic setpoints on acceptable counterparty safety assumptions. 2. **MEV Resistance**: a sovereign application-specific chain has access to powerful MEV mitigations and fine-grained control over the incentives it is exposed to. - Transaction ordering mechanisms can be tailored to specific use-cases (e.g., the Cosmos Hub’s AMM enforces batching of all trades in a block). - Each Cosmos Zone secures only a single application, so they are less likely to accumulate MEV over time than platforms that offer arbitrary programmability. In this sense, Cosmos Zones are closer to Bitcoin than they are to Ethereum. - Additionally, Zones get to choose who they interoperate with, so they’re not exposed to the externalized incentives of arbitrary applications as on a shared platform. - See “[MEV and Me](https://research.paradigm.xyz/MEV)” for a deeper discussion. 1. **Developer experience**: a Cosmos Zone can optimize its runtime for a specific application, rather than trying to build general-purpose optimizations (e.g., for the EVM). Developers can use whatever languages and tools they want; many already have SDK bindings available. 2. **Defensibility**: since Zones are responsible for their own security, their tokens and value capture mechanisms are more difficult to fork out, and races-to-the-bottom are less likely. ### Disadvantages of Sovereign Chains 1. **Security**: smart contracts on Ethereum can rely on the platform for protection from safety failures like rollbacks or invalid state transitions. On Cosmos, each chain is responsible for its own security, so applications may fail more often. - *Counterargument 1*: by nature, every Ethereum application either overpays for security or does not contribute its fair share, and all applications share the risk of a catastrophic correlated security failure ([MEV’s death-by-a-thousand-cuts](https://research.paradigm.xyz/MEV)). It is healthier for applications that are unable to pay for their own security to fail quickly. - *Counterargument 2*: in practice, many applications on Ethereum (such as Maker and Compound, though not Uniswap) already trust governance tokens for safety. They might as well use them for consensus, too. Scoping governance token permissions is a similar problem to designing application-specific shared-security layers. - *Counterargument 3:* Cosmos will enable a wide variety of shared-security options in the future. IBC can be used to couple the consensus sets of multiple Zones. Zones like [LazyLedger](https://twitter.com/lazyledger_org?lang=en) will enable sovereign execution environments to share security via rollups (much like the [rollup-centric Ethereum](https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698) design). 1. **Synchronous** **interoperability**: while Cosmos chains can transfer assets to each other and interact in other asynchronous ways, it is not possible to make synchronous calls from one Cosmos chain to another. - *Counterargument*: synchronous interaction is still possible within a single Cosmos chain. Synchronous interaction with *all* other applications is ultimately impossible to maintain at scale. As a result, sharded platforms like Ethereum 2.0 and Polkadot trade synchronous communication for scalability, as do rollups and other layer-2 architectures. 1. **Mental** **overhead**: application developers are required to grok arcane details of blockchain protocol design, like MEV. - *Counterargument*: this is probably inevitable. Application developers are not insulated from front-running behavior on Ethereum. They will be forced to consider these dynamics regardless of whether they deploy to a shared platform or their own blockchain, and the latter generally admits more powerful mitigations. Both architectures can abstract some complexity with advanced tooling and middleware. ### In Summary Blockchain protocol design is nebulous. There is no “correct” level of scalability or security. Qualities like credible neutrality cannot be exhaustively defined. Today, application platforms enshrine static setpoints on those design decisions. Cosmos is the first which allows developers to explore the full trade-off space without giving up simple composability. Free markets frequently find better solutions to highly multivalent problems than any we could manually enshrine. Cosmos is testing that hypothesis in the context of blockchain application design. With IBC’s launch, the capital-I Interchain emerges. *Acknowledgments: *[*Arjun Balaji*](https://twitter.com/arjunblj)*, *[*Dave White*](https://twitter.com/_Dave__White_)*, *[*Fiskantes*](https://twitter.com/Fiskantes)*, *[*Fred Ehrsam*](https://twitter.com/fehrsam)*, *[*Hasu*](https://twitter.com/hasufl)*, *[*Georgios Konstantopoulos*](https://twitter.com/gakonst)*, *[*Lakshman Sankar*](https://twitter.com/lakshmansankar?lang=en)*, *[*Matt Huang*](https://twitter.com/matthuang)*, *[*Zaki Manian*](https://twitter.com/zmanian) ## https://www.paradigm.xyz/writing/the-block-mined-in-january-584942419325 # The Block Mined In January, 584942419325 > This is the first in a series of blog posts about the bugs I've found in go-ethereum (Geth), the official Golang implementation of the Ethereum protocol. While you don't need a deep understanding of Geth in order to follow these blog posts, knowledge of how Ethereum itself works will be helpful. This first post is about a bug in Geth's uncle validation routine which did not behave correctly given a specially crafted uncle. If exploited, this could have caused an accidental fork between Geth and Parity nodes. This is the first in a series of blog posts about the bugs I've found in [go-ethereum](https://github.com/ethereum/go-ethereum/) (Geth), the official Golang implementation of the Ethereum protocol. While you don't need a deep understanding of Geth in order to follow these blog posts, knowledge of how Ethereum itself works will be helpful. This first post is about a bug in Geth's uncle validation routine which did not behave correctly given a specially crafted uncle. If exploited, this could have caused an accidental fork between Geth and Parity nodes. ## Blocks and Uncles Every blockchain has a canonical chain, which is defined through some metric like the total length of the chain or the amount of work required to produce the total chain. However, network latency means that sometimes two blocks can be produced at the same time. Only one block can be included in the canonical chain, so the other block must be left out. Some blockchains such as Bitcoin will completely ignore these blocks, rendering them *orphaned* from the canonical chain. Other blockchains such as Ethereum will still reward miners who put in the effort but rolled a nat 1 on block propagation. In Ethereum, these orphaned blocks that still get included are known as *uncles*. An uncle needs to satisfy certain conditions in order to be considered valid. First, all of the block's properties must be valid according to normal consensus rules, and second, an uncle block must be the child of a block at most 6 blocks away from the current head of the chain. However, one exception applies: while normal blocks must not be more than 15 seconds in the future, an uncle block is not restricted in this way. ## A Brief Interlude on Integers Most programming languages have the concept of platform-dependent integers and fixed-width integers. Platform-dependent integers may be 32 bits or 64 bits (or something else!) depending on the platform that the program was compiled on. In C/C++ and Go you might use `uint` while in Rust you might use `usize`. However, sometimes the programmer might want to guarantee that their variable can hold 64 bits of data, even if the platform is 32-bit. In these cases, the programmer can use a fixed-width integer type. In C/C++ that would be `uint64_t`, in Go `uint64`, and in Rust `u64`. The benefit of these built-in integer types is that they're all first-class citizens and thus are very simple to use. Consider this implementation of the Collatz Conjecture which supports 64-bit integers. ```solidity func collatz(n uint64) uint64 { if n % 2 == 0 { return n / 2 } else { return 3 * n + 1 } } ``` However, this implementation has a slight flaw, it doesn't support inputs which are larger than 64 bits. For that, we'll need *big integers*. Most languages support this either within the standard library itself such as `big.Int` in Go, or through external libraries for C/C++ or Rust. Unfortunately, using big integers has a big downside: they're much clunkier to use. This is illustrated in the reimplementation of the Collatz Conjecture, but supporting arbitrarily large integers. ```solidity var big0 = big.NewInt(0) var big1 = big.NewInt(1) var big2 = big.NewInt(2) var big3 = big.NewInt(3) func collatzBig(n *big.Int) *big.Int { if new(big.Int).Mod(n, big2).Cmp(big0) == 0 { return new(big.Int).Div(n, big2) } else { v := new(big.Int).Mul(big3, n) v.Add(v, big1) return v } } ``` Clearly, the 64-bit version is much simpler to write and read, and so it's no surprise that programmers like to use simple integer types when possible. ## Expectation vs Reality In Ethereum, most data is expected to fit within 256 bits, although some fields are only expected to be an integer value with no limit on size. Notably, the block timestamp `Hs` is defined to be a 256-bit integer. ![Ethereum Yellow Paper, page 6](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--1ee49002ef/ad3f3880390cf01801fb6ea1bc8a9d22/asset-https-cdn-sanity-io-images-dgybcd83--1ee49002ef.png) The Geth team attempted to be faithful to this definition by validating that the timestamp on an uncle block was not larger than `2256-1`. Recall that uncles have no restrictions on future mining. ```solidity // Verify the header's timestamp if uncle { if header.Time.Cmp(math.MaxBig256) > 0 { return errLargeBlockTime } } else { if header.Time.Cmp(big.NewInt(time.Now().Add(allowedFutureBlockTime).Unix())) > 0 { return consensus.ErrFutureBlock } } ``` [Source](https://github.com/ethereum/go-ethereum/blob/f03402232cd7bcc558b70a20df5b326b1d71e1ad/consensus/ethash/consensus.go#L244-L253) Unfortunately, the code then immediately coerced the block timestamp into a 64-bit integer in order to calculate the correct difficulty for the block. ```solidity // Verify the block's difficulty based in it's timestamp and parent's difficulty expected := ethash.CalcDifficulty(chain, header.Time.Uint64(), parent) ``` [Source](https://github.com/ethereum/go-ethereum/blob/f03402232cd7bcc558b70a20df5b326b1d71e1ad/consensus/ethash/consensus.go#L257-L258) This would not be so bad if Parity behaved in the same way, but Parity would saturate the timestamp at `264-1` instead of overflowing. ```solidity let mut blockheader = Header { parent_hash: r.val_at(0)?, uncles_hash: r.val_at(1)?, author: r.val_at(2)?, state_root: r.val_at(3)?, transactions_root: r.val_at(4)?, receipts_root: r.val_at(5)?, log_bloom: r.val_at(6)?, difficulty: r.val_at(7)?, number: r.val_at(8)?, gas_limit: r.val_at(9)?, gas_used: r.val_at(10)?, timestamp: cmp::min(r.val_at::(11)?, u64::max_value().into()).as_u64(), extra_data: r.val_at(12)?, seal: vec![], hash: keccak(r.as_raw()).into(), }; ``` [Source](https://github.com/openethereum/parity-ethereum/blob/6cf3ba7efd8a366b440c7675df1c0576c8cd4762/ethcore/types/src/header.rs#L333-L349) This means that if a malicious miner included an uncle with a block timestamp of `584942419325-01-27 07:00:16 UTC`, or unix time `264`, then Geth would calculate the difficulty using unix time `0` while Parity would calculate the difficulty using unix time `264-1`. These two values would be different, so one of the two clients would have split from the canonical chain after failing to verify the block. The Geth team fixed this bug in [PR 19372](https://github.com/ethereum/go-ethereum/pull/19372), which switched all timestamps to use `uint64`. # Conclusion Every client participating in a consensus protocol must behave exactly identically, so what may seem like a completely benign operation might actually be the trigger which causes half of the network to disconnect. This also goes to show that you don't need to be highly technical in order to find impactful bugs, so if this seems like something you'd be interested in, there's no better way to get started than to [dive right in](https://github.com/ethereum/go-ethereum/). Next time, we'll be exploring how Geth stores the data that makes up Ethereum, and how a skilled attacker could have planted a ticking time bomb that would hard fork the chain when detonated. ## https://www.paradigm.xyz/writing/ethereum-blockspace-who-gets-what-and-why # Ethereum Blockspace - Who Gets What and Why > Blockspace is the commodity that powers the heartbeats of all cryptocurrency networks. In the blockspace market, miners are the producers, mining pools are the auctioneers, and users are the bidders. The influences of the blockspace market are so pervasive that they touch almost every facet of the cryptocurrency ecosystem. *“Market that can operate freely is like a wheel that can turn freely: it needs an axle and well-oiled bearings. How to provide that axle and keep those bearings well oiled is what market design is about.”* *― Alvin E. Roth,* [*Who Gets What — and Why: The New Economics of Matchmaking and Market Design*](https://www.goodreads.com/work/quotes/42295123) ## Overview of the blockspace market **Blockspace is the commodity that powers the heartbeats of all cryptocurrency networks.** In the blockspace market, miners are the producers, mining pools are the auctioneers, and users are the bidders. The influences of the blockspace market are so pervasive that they touch almost every facet of the cryptocurrency ecosystem. After a user initiates a transaction, it is propagated peer-to-peer in each node’s mempool. Each transaction has a fee attached to it. The fee signals the desire to purchase blockspace, which allows the transaction to be processed and included in a block. Every moment there are numerous proposed blocks existing in this “Schrödinger’s state” between unconfirmed and confirmed, competing to find the first hash output that satisfies the difficulty target. Each block has a probability of becoming the next block. By contributing billions of computations per second, the miners collapse the probability wave and materialize the ledger history. Since the size of a block is capped, there is a limited number of transactions that can go through at a given time, **thereby giving blockspace an implicit time-value**. A transaction that stays unconfirmed for too long may be subject to market volatility, or get frontrun by arbitrage bots. The fee users pay to purchase blockspace, reflects their willingness to bid for its spacetime. The blockspace market connects the miners and users together. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--3599ad31e9/253a06a22dce256de1ef5821f7c24dbb/asset-https-cdn-sanity-io-images-dgybcd83--3599ad31e9.png) On the surface, the blockspace market looks complex and chaotic because it lacks central coordination. It relies on detailed rules, procedures and the confluence of supply and demand to make self-adjustments. How do we know if the current market design is optimized for success? Nobel Laureate Alvin E. Roth is considered a pioneer in the field of market design. In his seminal book “Who Gets What - and Why” he states that in order to function properly the markets need to do at least three things: 1. **Market depth:** a large enough number of potential buyers and sellers to interact. In the case of the blockspace market, the suppliers are incentivized by the block reward to provide hashpower. On the other hand, demand for blockspace increases as more people use the network for transactions. 2. **Safety:** market participants must feel safe to reveal or act on confidential information they may hold. Due to the transparent nature of on-chain transactions, users submitting sealed bids may not always get the outcome that they intended. Furthermore, transactions require a high degree of settlement assurance. That is, there should be sufficient hashpower to make re-orgs expensive. 3. **Lack of congestion:** transactions should go through or get cancelled in a timely manner. When a market doesn’t deal effectively with congestions that volume brings, participants may not be able to get their transaction included in a block without too much delay. As witnessed from the recent popularity of Ethereum Dapps, gas price also skyrocketed as a result of congestions. In both Bitcoin and Ethereum’s history, how to optimize the design of the blockspace market structure often sparks many heated debates. **In the following sections, we illustrate the structure of the Ethereum blockspace market from the perspectives of the supply (miner) and the demand (users)**. We examine if the current blockspace market design provides depth, ease congestion, or participation is safe and simple. Next, we discuss the popular proposals to optimize the market structure, as well as how the blockspace market will likely evolve in the future. ## The supply side: the structure of Ethereum mining **The ultimate purpose of the entire mining industry is serving as a decentralized transparent clearinghouse for a single commodity: the blockspace.** The task is by no means trivial. In a distributed system that operates globally 24/7 without an authoritative coordinator, miners need to provide strong [settlement assurance](https://medium.com/@nic__carter/its-the-settlement-assurances-stupid-5dcd1c3f4e41) on the blockspace auctioned anonymously, by contributing a significant amount of capital on hardware and energy to produce an astronomical number of computations to secure the network. Despite popular concerns of hashpower concentration, the mining industry is not a single-minded organism. Fluctuations in the blockspace market affect each component with different degrees of impact; and each individual miner is heavily affected by factors like location, machine type, temperature, maintenance, and mining strategies. Bitcoin and Ethereum mining have distinctly different market structures. Bitcoin and a number of PoW coins have almost fully migrated to the ASIC era. Ethereum on the other hand, despite being the second largest in market cap, has [barely any ASIC presence](https://twitter.com/TimBeiko/status/1365307748360011782?s=20). While every once a while rumors of new ASIC manufacturers would emerge, it is estimated that around 80-90% of the current Ethereum hashpower is dominated by GPUs. **Structurally, how does a blockspace supplier market consisting primarily of GPUs differ from a market mainly of ASICs?** Every story of GPU mining begins with NVIDIA and AMD. They either directly sell discrete graphics cards or wholesale GPU chips and memory to lower stream graphics card manufacturers. These in turn manufacturers remove functions that have nothing to do with mining, and thus are referred to as “mining cards”. There are many white-label custom mining card brands. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--b73cfaf914/80715d43717af00086d0ead2c0dfd23a/asset-https-cdn-sanity-io-images-dgybcd83--b73cfaf914.png) There are significantly more OEMs than the ASICs market. As a result, the hashpower composition of Ethereum is much more diverse than a typical ASICs network. This also makes it challenging for distributors to monopolize the channels. There are more options for miners, as they don’t have to wait for ASIC manufacturers such as Bitmain, Whatsminer to sort out supply chain constraints. This means that the initial supply is usually not as bottlenecked as ASICs that use advanced backend processes. In addition, GPU miners are not tied to any specific networks. Miners engaging in speculative mining almost exclusively use GPU miners. Moreover, retail GPU cards are valuable in other areas of computing such as gaming, datacenter, and AI jobs. Overall, GPU miners have higher option value in their hardware. Structure determines properties. The hardware composition determines the industry’s capex and energy consumption. The two factors are pivotal in calculating mining expense, which has a rippling effect on the rest of the mining ecosystem: from manufacturing, distribution, hosting facilities, fluctuation of gas cost, preference for EIPs, to the defining characteristics of its mining cycles. In [The Alchemy of Hashpower](https://www.aniccaresearch.tech/blog/the-alchemy-of-hashpower-part-ii), we introduced the four archetypal phases of the mining cycle according to the relative rates of change between Bitcoin price and network hashrate: ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--b4c55ac1c7/9a9d3bbd0ff9366c6cb07b48349dc4c1/asset-https-cdn-sanity-io-images-dgybcd83--b4c55ac1c7.jpg) Due to the inherent illiquidity of hardware, network hashpower tends to lag price changes. The “hardware reaction time” is determined by various exogenous factors such as manufacturers’ supply chain constraints, foundry wafer backlog, facility capacity, and even shipping logistics. These delays are especially significant this year as the market sails full throttle into a raging bull trend. Miners and investors rush to place orders for new machines. The manufacturers on the other hand, are just beginning to recover from the supply chain halt during COVID, and the global integrated circuits [shortage](https://hbr.org/2021/02/why-were-in-the-midst-of-a-global-semiconductor-shortage) is forcing all semiconductor businesses - mining, automobile, consumer electronics, to wait in a long queue for wafer allocation. In addition, NVIDIA recently [announced](https://blogs.nvidia.com/blog/2021/02/18/geforce-cmp/) that they will artificially nerf the performance of Ethash on the newest cards to discourage miners from buying up all the GPU inventory. This means that unless coin price or fee continue to rise astronomically from here, by the time the backlog of machines finally come online, the “inventory flush” and “shakeout” phase can be potentially very painful. In Ethereum, mining revenue primarily comes from three sources: 1. coinbase reward (2 ETH per block + uncle rewards) 2. transaction fees, and 3. miner extractable value (more on this later). Transaction fees as a percentage of total block reward are much higher in Ethereum than in Bitcoin. This means miners pay attention to not just coin price but also gas trends. Even if price stays flat, increase of transaction fees will be sufficient to incentivize miners to increase hashpower-under-management. ![Data source: Coinmetrics](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--ba969c6445/3b86384ebb8798aac44f5e297e44d720/asset-https-cdn-sanity-io-images-dgybcd83--ba969c6445.png) In addition, as discussed in the earlier sections, due to the option value of GPUs and flexibility in distribution, it is easier to scale up or down hashpower compared to an ASIC network. As a result, the cycles in Ethereum mining tend to be shorter: ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--6610a52489/c4dafeb88c8b6c3981edad93082dc0b1/asset-https-cdn-sanity-io-images-dgybcd83--6610a52489.png) A shorter cycle means competition ramps up faster when mining revenue is high, and hardware option value means it is easier for hashpower to unwind when revenue is low. Unit profitability (block reward per Megahash/s) can fluctuate wildly, making it challenging to predict earnings as a result: ![Data Source: CoinMetrics](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--171ba5ab36/f914b7ababe9b635574376de8753fa71/asset-https-cdn-sanity-io-images-dgybcd83--171ba5ab36.png) A noticeable increase in coin price and fees attract more miners to participate. **However, unlike most commodity markets, more producers doesn’t mean an increase in the supply of blockspace. The supply of blockspace is determined by block size and the average block time. This means that the increase in hashpower does not drive down network transaction fees but increases the security budget of the network**. As more miners enter the competition, it becomes more expensive to re-org historical blocks, and therefore improves the network’s settlement assurance. ## The demand side: the time-value of blockspace Since the block size is limited, participation in a permissionless manner requires competition over the system’s resources. For anyone initiating on-chain transactions, the fee paradigm is a defining core user experience. As the most popular platform for storing and executing smart contracts, Ethereum experienced a meteoric rise in utility. DeFi “money legos” have enabled products and services to interlock permissionlessly, and greatly fuel innovation in new financial schemes. Ethereum users today participate in the blockspace market via a repeated first-price auction. It is a simple auction where users submit a bid for their transaction to be included in the next block, which is paid to the miner in the form of a transaction fee. Users can choose their bid via their transaction’s “gas price”, denominated in gwei/gas (1gwei = 1e-9 ETH). Empirical observations of mining pools’ transaction selection methodologies shows that over 75% of them follow a default strategy without prioritization. That is, simply including transactions with descending order in fees without prioritizing any specific addresses. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--6fdb8ad262/e030f669abc97ea30895845775c14402/asset-https-cdn-sanity-io-images-dgybcd83--6fdb8ad262.png) *(Source: *[*Ethereum Gas Price Statistics*](https://www.zora.uzh.ch/id/eprint/194455/1/econwp373.pdf)*)* The market structure is simple: users want to minimize the fees paid to miners to enjoy a smooth experience, whereas miners want to maximize their revenue since they are for-profit entities. It is an undisputed fact that the fees paid by users will always obey the laws of supply and demand: blockspace per second is the scarce asset, and as a result users that want immediate inclusion of their transactions will always pay more than users willing to wait for the next block, as evidently seen by the shape of the pending transaction queue below. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--903db2d686/b98fc1af9c18ab7c3cb04757ba39a7d8/asset-https-cdn-sanity-io-images-dgybcd83--903db2d686.png) *The pending transaction queue. *[*\[source\]*](https://www.gasnow.org/) Blockspace is the closest thing in crypto to “digital real estate”. Blockspace has the inherent value of being “a real estate” where economic activities occur. **For miners, blockspace in the future has lower time value due to uncertainties in price, network difficulty, and fees. For users, blockspace in the future has lower time value because of the uncertainty in the profitability and the utility of their transaction.** ## Congestion and fees The time value of blockspace directly translates to the amount of fees users pay. In this fee paradigm, estimating the “correct” gas price is a hard problem as evidently seen by the volatility of gas prices in the span of a single block. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--eca62b78be/b47efbfa797bbbbb37c8b6eda608537f/asset-https-cdn-sanity-io-images-dgybcd83--eca62b78be.png) *Median gas prices fluctuate from 100 to 400 Gwei in the span of a week. *[*\[source\]*](http://www.corelab.ntua.gr/athecrypt2021/slides/Leonardos.pdf) Recall Roth’s three requirements for successful market design: depth, safety, and overcome congestions. It is clear that in times of congestions, the gas price often spikes too much for general users. Where exactly is the bottleneck? This unpredictability stems from the fact that users cannot coordinate on the correct fee for being included in the next 1, 5 or 10 blocks. Most users today bid in a “one shot” fashion: They broadcast a transaction once and wait for it to be included. Constant factor improvements can be made by allowing users to express their fee preference over a range of blocks, e.g. using [fee escalation algorithms](https://insights.deribit.com/market-research/analysis-of-eip-2593-escalator/). The initial version of a novel technology is always crude. Over the years, different working versions emerge to address the problem of congestion. The market design of blockspace involves balancing the interests of many factions in the ecosystem. At the current juncture, three possible paths have been discussed: 1. Short-term: increase block size. Temporary patch and may compromise security. 2. Medium-term: change auction mechanism. Requires community consensus. 3. Long-term: scalability solutions. Rollups and ETH 2.0. One may be tempted to increase the size of a block, so that it can fit more transactions (i.e. increase the supply, assuming constant demand). This change would only be a painkiller that temporarily alleviates the pain from high fees, since fresh demand would quickly fill up blocks, bringing fees up again. In addition, block size increases make the blockchain node software more resource intensive, so they should be avoided to preserve the decentralization of the system. Another approach would be to restructure the bidding process. The fee mechanism in all blockchains today implements a “generalized first price auction”. EIP-1559 is a proposal which changes the mechanism to a fixed-price sale when the system is not congested[ ](https://research.paradigm.xyz/ethereum-blockspace#fn:1)[^1], allowing users to easily choose the “optimal” bid for their inclusion preferences (contrary to the status quo). Variants of EIP-1559 have been deployed in [Near](https://insights.deribit.com/market-research/transaction-fee-economics-in-near/), [Celo](https://docs.celo.org/celo-codebase/protocol/transactions/gas-pricing) and [Filecoin](https://filecoin.io/blog/posts/eip-1559-in-filecoin/). It is also scheduled for activation in Ethereum in July 2021, which will be the biggest fee market mechanism change to ever happen in a public blockchain. EIP-1559 is also one of the most controversial topics in Ethereum to-date. With [over 60%](https://stopeip1559.org/) of the mining pools signaling opposition to the proposal, EIP-1559 has turned into a “trade war” between the users and the producers of blockspace. Although the exact impact to miners’ fee income is difficult to quantify yet, the mining community generally believes that gas price needs to increase significantly to make up for the difference. A’jian(阿剑), a vocal critic of the proposal in the Chinese Ethereum community, believes that the EIP-1559 *“would lose miners’ loyalty.”* Kevin Pan, the founder of Poolin, thinks that it won’t actually impact mining revenue very much, but *“it is extremely insulting.”* However, not all miners feel the same way. The founders of F2Pool, who are active users of DeFi products themselves, are in favor of the proposal. Even Jihan Wu, the notorious instigator of Bitcoin’s block size civil war, voiced support for the change in fee mechanism. Ultimately, in a structureless open ecosystem with roots over different parts of the world, human coordination remains one of the biggest challenges. Longer term, the proper solution is to allow the supply side to scale horizontally, without meaningfully affecting the trust requirements of the layer 1 system. After all, users want low fees, and low fees are not an economic mechanism design question but a fundamental blockchain scalability question. It is worth noting that scalability also allows more demand to enter the system, which would counterbalance the decrease in the average fee per transaction. The main approach here is the so-called layer 2 solutions, such as [Optimistic](https://research.paradigm.xyz/rollups) and [ZK Rollups](https://medium.com/starkware/on-the-road-to-starknet-a-permissionless-stark-powered-l2-zk-rollup-83be53640880). ## The Dark Forest and the Dark Pools If we were in the Bitcoin context, then the discussion around the demand side would end here. In Ethereum however, an entire financial system is being built which distorts the rules of the game. Certain “opportunities” may exist on Ethereum for a limited time, in the form of arbitrages waiting to be seized, or limited participation slots in a high-demand sale of an asset (e.g. an ICO). Similarly to how people race to queue up to get limited edition clothing, developers have built software which intelligently races for on-chain opportunities, and even competes with other bots by placing gas price bids. This concept is called a Priority Gas Auction (PGA) which was first described in Phil Daian et al’s seminal paper “[Flash Boys 2.0](https://arxiv.org/abs/1904.05234)”**. The “irregular” revenue stream which is generated from PGAs is called Miner Extractable Value or MEV.** Bots participating in PGAs get to have access to a potentially very profitable opportunity, and they are willing to bid at exorbitant gas prices, up to the profit they’re going to make. In [Ethereum is a Dark Forest](https://medium.com/@danrobinson/ethereum-is-a-dark-forest-ecc5f0505dff), the authors described one extraction in which around $12k worth of tokens fell into the grasp of the “predators”. These predators are arbitrage bots that constantly monitor the activities on the mempool, and try to front run specific types of transactions according to a predetermined algorithm. DEX platforms such as Uniswap are likely infested with arbitrage bots. As a result, some service providers have started to offer “dark pools” - transactions that bypass the public mempools and therefore are invisible to the public until they land on-chain[ ](https://research.paradigm.xyz/ethereum-blockspace#fn:2)[^2]. These dark pools do not broadcast to the network, and instead relay the transactions directly to the miners, such that they are not broadcasted to other nodes on the network. These dark pools are not entirely used for profit-maximization purposes. In [Escaping the Dark Forest](https://samczsun.com/escaping-the-dark-forest/), security researcher [samczsun](https://twitter.com/samczsun) documented how his group rescued 25k ETH from a faulty smart contract using this technique. Front-running and dark pools are not unique to the cryptocurrency market. They epitome a driving force in finance as old as time: secrecy. Wall Street has long embraced this controversial beast. A market that looks thick on a human timescale, with hundreds of opportunities to trade in the course of a single second, can look comparatively thin to a computer. It is estimated that after 2015, dark pools account for [15-18% of the trading activities](https://www.ecb.europa.eu/pub/pdf/scpops/ecb.op193.en.pdf) of exchange-listed securities in the U.S. The “total addressable market” of MEV is [exponentially growing](https://explore.flashbots.net/), with at least $350m of MEV extracted since the beginning of 2020, one third of which happened during February 2021. Most of the extracted MEV is concentrated in arbitrage actions between popular automated market makers such as Uniswap, Sushiswap, Curve and Balancer, with a smaller slice of the pie being attributed to liquidations on Compound and Aave. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--537882c045/ab70f2d4283b6900ad86adbd7516725b/asset-https-cdn-sanity-io-images-dgybcd83--537882c045.png) *Cumulative Extracted MEV since January 1st 2020 *[*https://explore.flashbots.net*](https://explore.flashbots.net/) The butterfly effect is staggering: Arbitrage and liquidation opportunities create MEV. MEV gets competed for via PGAs. Fee estimators use PGA-inflated gas prices as a reference, causing users to overpay for their transactions. **At its core, the issue stems from the fact that users and bots are in the same pool, independently of whether they go after MEV or not.** Ideally, MEV-transactions should be in a separate transaction pool from non-MEV transactions. This would allow the MEV-extracting bots to compete with each other while all other transactions, say, the transfer of a CryptoPunk, would be in the no-MEV pool, which would enjoy a less volatile gas market. Unfortunately, such drastic changes to Ethereum would be hard to execute. A simpler way to fix this issue would be to introduce a new API endpoint for miners, where they’d accept bundles of MEV-only transactions. That way, traders would submit their transactions directly to that endpoint, with users continuing to use the rest of the system like today. This is the approach [that Flashbots is taking](https://ethresear.ch/t/flashbots-frontrunning-the-mev-crisis/8251), which is the least disruptive to our knowledge. ## How will miners adapt to MEV? In the past, when fees’ % of total block reward was negligible, a miner’s primary focus was to capture as many shares of the blocksidy as possible. The miner would pick a mining pool that has a sufficiently large amount of hashpower hosted. After years of development, mining pool infractures have more or less been optimized to the same range of performance. A pool that lags behind its peers will be identified easily and quickly filtered out by the competition. Miners don’t really care about which pool they use beyond the basic parameters (luck, payout schedule, and pool fees). Users don’t really care which mining pool picks up their transactions, and the mining pool doesn’t care who the users are as long as the fee is attractive. As MEV grows relative to the block reward, the considerations of miners, mining pools and users start to become more nuanced. With MEV, the blockspace market mechanism will shift from a pure commodity market to incorporate some elements of a match-making market. When users submit transactions they should be conscious of the mining pool’s ability to execute them in a timely manner. **All else equal, MEV causes gas prices to be higher than they would be if MEV did not exist. This implies that miners are already indirectly extracting a fraction of the total MEV that gets extracted by traders, estimated at **[**~12% today**](http://explore.flashbots.net/). A [recent analysis](https://insights.deribit.com/market-research/establishing-bounds-for-miner-revenue-in-eip-1559/) also hinted that the fees earned due to MEV will eventually dominate the fees earned through “regular” revenue streams (if not already!). That said, miners are profit seeking entities and may want to capture more of the MEV. Miners could choose to specialize and run internal trading operations. Using their benevolent powers over transaction ordering, they can choose to insert, re-order and even censor transactions to maximize their trading operation’s profits. At the limit, it has been theorized that miners will reorganize the blockchain over and over, as they try to extract MEV from past blocks for themselves (colloquially referred to as “time bandit” attacks). While possible, this scenario is not obviously plausible: miners are (for the most part) structurally long ETH, and such an action would directly negatively impact their ETH investment. This train of thought generalizes to the statement that any theoretical miner attack is not going to be executed if it can be detected by users[ ](https://research.paradigm.xyz/ethereum-blockspace#fn:3)[^3]. A more optimistic take would be that miners decide to outsource MEV extraction to traders. They could do that either the aforementioned Flashbots approach, where they keep the block reward and outsource just the ordering, or by renting out their hashrate to specialized trading firms. Independently of the method pursued, we expect that Ethereum mining pools will inevitably start to be more active in the MEV extraction process, as they seek to offer the best yield on their miners’ hashrate. As the race towards MEV extraction heats up, it remains to be seen how the (de)centralization of Ethereum’s mining ecosystem will be affected by this market structure change. ## How can the rest of the ecosystem participate in MEV? Financialization of hashpower is an important underlying trend in the mining space. If blockspace is analogous to real estate, then hashpower is the equity in the property, and a forward contract on hashpower is similar to mortgage. For miners, selling their hashpower through **hashpower instruments \*\*is a way for them to lock-in future revenue**. \*\*Similar to renting hashpower on cloud mining platforms, forward contracts let the miner sell a fixed amount of hashpower for a period of time, for an upfront price. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--5b3c2d52f9/74866c2d1c1a73c4ff5fdedd071a4bbb/asset-https-cdn-sanity-io-images-dgybcd83--5b3c2d52f9.png) **Active DeFi users who are expecting network MEV activities to accumulate can speculate by purchasing these hashpower instruments.** For example, a trader who is expecting network MEV activities to surge in the next 15 days can purchase x amount of hashpower over the next 15 days for an upfront price. During the contract period, the mining rewards plus the MEV revenue captured by the miner will subsequently be forwarded to the trader. If the trader is well positioned, the purchase can potentially earn back the trader’s own MEV fees paid to the mining pool. Both liquid hashpower instruments and MEV represent the cutting edge evolution for the mining capital markets. New tools are actively being built to advance in these directions. MEV plus hashpower instruments closes a full loop for the users and the miners. ## Conclusion The Ethereum blockspace market structure is a fascinating topic to study, and for a good reason. In this analysis, we observed key differences between the supply side of the GPU and ASIC hashpower markets. We also identified the key mechanisms which create the demand side dynamics. We then tied the two together under the umbrella of Miner Extractable value. As Charlie Noyes wrote in [MEV and ME](https://research.paradigm.xyz/MEV): *“Any attempt to prevent miners from accessing the revenue stream is liable to incentivize the creation of off-protocol markets.”*. MEV is an inevitable result of the growing complexity of Ethereum transaction types. As tools and knowledge base for MEV become more mainstream, more interesting MEV patterns will emerge. These behaviors will profoundly impact how frequent DeFi users plan for their blockspace purchase strategies. Changing how a commodity is sold on the market changes the way the commodity is produced. MEV creates new avenues for mining revenue, and thus will in turn influence how the mining industry interfaces with the buyers of the blockspace. New patterns will emerge in the Ethereum mining cycles. *Acknowledgments: We’d like to thank Tina Zhen, Tarun Chitra, Hasu and Alex Obadia for their comments on earlier drafts of this post.* [^1]: In times of burst demand, the auction mechanism post-EIP-1559 degrades back to a first price auction. To limit the duration of this phase, EIP-1559 implements an exponentially increasing fee which throttles back the demand to below the supply values, transitioning the mechanism back to the second price auction phase. [^2]: The transaction can be made public only if the miner decides to publish the transaction themselves. [^3]: We also recommend this recent analysis on how miners could engage in actions which are opposing to users’ best interests, as well as this explainer between benign and malicious MEV. ## https://www.paradigm.xyz/writing/surviving-crypto-cycles # Surviving Crypto Cycles > How to survive a crypto cycle. *Originally sent as a private note to portfolio companies: *[*PDF*](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-212d2999e4/a1c4b8f10d983616dabd6d81ebcd4039/asset-https-cdn-sanity-io-files-dgybcd83-p-212d2999e4.pdf) Founders, In the first 2 months of 2021, crypto prices have already doubled and continue to hit new all-time highs. Bitcoin has crossed $1 trillion in market capitalization. Pixelated crypto art regularly sells for millions. Senators even have lasers for eyes! Euphoria abounds. As co-founder of Coinbase through 3 prior market cycles (2011, 2013, and 2017), I’ve experienced these euphoric highs before. I’ve also experienced the communal despair and disillusionment that have followed. Below are some observations and learnings I’ve taken from living through these past crypto cycles. I share them with the hope they help you, your team, and your community prepare for whatever is ahead, so that you can avoid potential pitfalls and maximize your chances of success. While it’s impossible to predict the future, past cycles give us some sense of what to be ready for. They can help us imagine the potential aftermath of this latest wave of euphoria. And they serve as a reminder that bouts of uncertainty and volatility are to be expected given the scale of the opportunity for crypto: a technology that could transform not just money, but the financial system and the internet broadly. **Observations of Past Crypto Cycles** A (large) caveat: future cycles will almost certainly look different than past cycles. We may not even be in another cycle! But markets do tend to go through cycles, with key elements that generally repeat themselves. To prepare for future scenarios, it’s worth understanding these elements of cycles past: - **They are highly emotional.** Founders, employees, and customers quickly gain or lose large sums of money and have a hard time handling either, completely rationally. Compounding this effect, periods of “hype” have historically been short, while “normal/down” periods have been much longer. At Coinbase, we were riding high in 2013, only to experience 3 long, gut-wrenching down years until 2017. Many employees became dejected and over a third of the company turned over. Being a founder felt incredibly challenging and lonely. - **They attract massive public attention.** The media want to talk to you. Family members ask you to explain what's going on. Friends press for investment advice. Companies or protocols are touted as “going to the moon” one day, only to have their obituaries written the next. - **They strengthen the ecosystem.** Crypto has exited every cycle stronger than it entered. This is true across all key metrics: entrepreneurial and developer activity, academic research, infrastructural maturity, corporate adoption, public awareness, and simplistic price, amongst others. Zooming out, cycles can be reframed as volatile periods around a relatively consistent adoption curve. Despite the emotional gyrations, at Coinbase we came out of each cycle in better shape, by every metric and by many multiples, than at the end of the previous cycle. - **They wash out weak companies.** While a rising tide lifts all boats in upcycles, poor fundamentals and flawed strategies are ruthlessly exposed in downcycles. Many fail to survive. Those who do have the tremendous advantage of having built while others perished and typically thrive when the next upcycle arrives. - **They draw regulatory attention.** With public attention comes regulatory attention. At Coinbase we spared no expense in figuring out our regulatory strategy before regulators came knocking. - **They push infrastructure to the limit.** This is true of companies, crypto-native apps, and the blockchains themselves. Exchanges go offline. Transaction fees rise 10-100x. At Coinbase we ran out of working capital to support the massive influx of customer demand in 2013, forcing us to pause the customers’ ability to buy -- not the best experience amidst the largest influx of customers we had ever seen! **Creating Resilience to Cycles** It’s challenging to predict the specifics of any cycle, and thus wise to simply be resilient to them. The most important thing you can do in times of euphoria or despair is think for yourself. But sometimes the experience of others helps in that thought process. So, with that caveat, here is what I've found to be effective in creating resilience during cycles: - **Lead by example.** Cycles draw focus to the short term. Remaining focused on the mission gives your team and community a fighting chance to do the same. - **Keep the main thing the main thing.** Since it feels like everything is working in boom times, it's tempting to want to do everything. Maintain a high bar for changing or expanding your scope. The same idea is true in a downcycle. The crypto graveyard is littered with the remains of companies who pivoted away from their core mission in a downcycle, only to watch with anguish as their idea started to work in the next upcycle. In 2015, a Coinbase board member suggested we start constructing private blockchains for banks because it offered a short term cash opportunity -- a pivot we are glad we avoided as off-mission and temporary. - **Make a stress test checklist.** Assume your product sees 10-100x its normal use. What breaks? Ask this of every team lead. At Coinbase, we attempted to estimate customer support caseloads, cash burn rate, and server load ahead of time -- and we still undershot the 10x+ load spikes at the peak of cycles. - **Consider fundraising.** Ask yourself: "If crypto goes through a protracted down cycle, do I have enough cash to survive?" Cash that is easy to come by today may not be tomorrow. At Coinbase, we found ourselves running low on cash shortly after 2013-14. Luckily, we decided to fundraise before crypto was in serious winter; had we not, we may not have survived until the 2017 spring. When we completed a large fundraise, we put half of it in a separate bank account to create friction around drawing down our rainy day fund. If your personal bank account is near 0, consider taking a small, non-life-changing amount off the table. It may help you sleep better at night and maintain focus on achieving the most ambitious version of your mission. - **Caution newcomers.** Remind recruits that they should prepare themselves for long down periods if they join your company. Coinbase had countless employees join during the highs of 2013-14 thinking crypto was on a straight line to the moon, only to become dismayed and leave when crypto "crashed" before picking up again in 2017. Prepare your customers and community as you prepare your team. When a down cycle starts, you can quickly go from being celebrated as a visionary leader to being crucified as a scam artist. - **Repeat your message multiple times, through multiple channels, from multiple people.** It is harder for messages to be heard during noisy, heady times. - **Prepare yourself for a marathon, not a sprint.** So many founders flame out. Stay healthy and allow yourself to take time to clear your head. Challenging situations become easier to deal with the more you have experienced them. Give yourself the opportunity to build that experience. **Forging Ahead** Foundational technology breakthroughs carry both great opportunity and great uncertainty, the two key ingredients in the recipe for cycles. It shouldn’t be a surprise that crypto would be a more extreme example as it begins to redefine multiple large, global markets: money, financial services, and the internet itself. Cycles are neither good nor bad; they are natural. Peak euphoria provides the opportunity for the world to dream about the future. Rock-bottom despair forces practicality and clarity. When things are good, they're never as good as they seem; when things are bad, they're never as bad as they seem. I do not know how the current cycle will play out, or even that it is a cycle at all. I do know that every past cycle has left crypto stronger than where it started. Times when things feel like they are going well are the times to build resiliency and set yourself up for success no matter what the future holds. I hope you embrace that opportunity. As always, we are here to support you. Fred Ehrsam and the Paradigm team ## https://www.paradigm.xyz/writing/the-cartoon-guide-to-perps # The Cartoon Guide to Perps > In this post, I’ll share what I learned: four very different (but mathematically identical) mental models for what perps are, how they work, and when they don’t. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--85b6caf283/ffa432623bdb391f7e47cdfd89688619/asset-https-cdn-sanity-io-images-dgybcd83--85b6caf283.png) Illustrations by: [Chelsea Myers](https://www.instagram.com/tinyattic/) About a month ago, I realized I didn’t understand perps. For the cost of $1, a 100x bitcoin perp (short for “perpetual swap”) behaves like $100 of bitcoin. This is a pretty neat trick, especially considering you can’t redeem the perp for bitcoin or anything else. My vague idea of how they achieved this (“funding rate,” right?) seemed lacking for an instrument that traded tens or sometimes hundreds of billions of dollars per day. I spent some time puzzling it over with some brilliant people, including the creators of some of the world’s most popular perps. In this post, I’ll share what I learned: four very different (but mathematically identical) mental models for what perps are, how they work, and when they don’t. ## Perp anatomy ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--91f0f78d8b/415e2d59262276197e0fcd9631396db9/asset-https-cdn-sanity-io-images-dgybcd83--91f0f78d8b.png) Let’s start with the basics. Unlike bitcoin, which can be traded anywhere, your standard perp is native to a particular exchange and can only be traded there. Perp implementations can also vary quite a bit from exchange to exchange. This post models a simplified version of the FTX perp. A perp’s value at any given time is represented by its mark price. This is the price used to calculate profits and losses and trigger liquidations. It is generally based on the trading price of the perp on its exchange. The basic idea of the perp is that, ignoring complicating factors like inflationary rewards, it should be worth about the same as its underlier (i.e. bitcoin). The underlier’s value is represented in the system by the index price, which is generally calculated from its trading price on some external exchange. When the index price and mark price are the same, the perp is worth the same as the underlier, and all is as it should be. When the index price and the mark price diverge, the system transfers a funding fee between those who are *long* the perp (have bought it) and those who are *short* the perp (have sold it). In our example perp, the funding fee paid by the longs to the shorts is $(mark price - index price) per contract per day. When this number is negative, the shorts pay the longs. Traders must also put down collateral, known as margin. When the mark price moves against the trader, the resulting losses are deducted from this margin. If the margin balance gets too low, the trader will be *liquidated*, meaning their position is automatically closed out. Taken together, these pieces explain what a perp *is*, but not what it *does.* ## Perp as thermostat ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--ceaa83a4b4/c4d2416a634f3d6a5c8b81965d261a2c/asset-https-cdn-sanity-io-images-dgybcd83--ceaa83a4b4.png) A thermostat is an example of a [feedback control system](https://en.wikipedia.org/wiki/Control_system#Feedback_control_systems), which keeps a value near a set point by applying increasing force as it strays. The hotter your house gets relative to your desired temperature, the higher your thermostat will crank the AC. Similarly, our perp wants its mark price to equal its index price. It attempts to achieve this by charging the funding rate of $(mark price - index price) per contract per day. The more expensive the perp gets relative to the underlier, the larger this difference will be, and the more the longs will have to pay the shorts. Compared to the situation where there is no funding fee, longs might be marginally more inclined to close their positions, and traders in general might be marginally more inclined to open new shorts. This increase in selling should push down the price of the perp. However, markets are notoriously hard to predict. How do we know how much more selling the funding fee will induce, or how much impact that selling will have on the price? And what if there are other factors we haven’t considered that are pushing prices in the opposite direction? ## Perp as PNL loan Let’s follow along with Alice and Bob, two crypto enthusiasts who don’t know about perps because their friends shamefully neglected to send them this post. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--df4a9bff4b/cf22539f1186b50c5796370eb201cd6c/asset-https-cdn-sanity-io-images-dgybcd83--df4a9bff4b.png) We join them with the price of bitcoin at $100k. Alice wants to go long a bitcoin and Bob wants to go short one, but Alice doesn’t have $100k and Bob can’t find a bitcoin to borrow. They make a deal: they will *pretend* Alice bought a bitcoin from Bob for $100k (the mark price). As the price of bitcoin (the index price) changes, they will settle profits and losses in cash, moving the mark price. Until settled, losses are treated as debt with an interest rate of 100% per day. The next morning, the price of Bitcoin jumps to $110k. Alice has $10k of profit on the pretend trade, which Bob needs to pay her. However, it will take him an hour to get the money. During that hour, Bob pays Alice interest on her unrealized profit. At the rate of 100% per day, this comes out to $10k/24 ~ $400 in interest. After that hour, Bob also transfers Alice her $10k in profits, so that they are back to even. Now it is as if they had just made their deal with Bitcoin at $110k, the new mark price. They have, of course, re-invented the perp: Bob must pay Alice $(index price - mark price) per day until he transfers over her profits and resets the mark price to the current index price. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--eda4b5d176/e2fe5d733435c1d7f6f831726eb3fdec/asset-https-cdn-sanity-io-images-dgybcd83--eda4b5d176.png) While there is no guarantee that Bob will ever pay Alice her unrealized profits, as long as he remains solvent Alice will be receiving 100% interest per day on her missing capital. This is a good deal whenever her cost of capital is less than 100% per day, which should be almost always. ## Perp as loan swap Let’s rejoin Alice and Bob with the price of bitcoin back at $100k. Alice wants to short the dollar against bitcoin, and Bob wants to short bitcoin against the dollar. They make another deal: Alice will borrow $100k from Bob, and Bob will borrow one bitcoin from Alice. Since they are each borrowing equivalent amounts, no cash or bitcoin actually needs to change hands. Each will pay interest on their debt at a rate of 100% per day. With the price of Bitcoin at $100k, these interest payments cancel out perfectly. If their debt amounts ever get out of balance, each agrees to let the other equalize the debt by means of a cash transfer. The next morning, once again, the price of Bitcoin jumps to $110k. At the 100% per day interest rate, Alice owes Bob $100k in interest per day on her borrowed $100k, while Bob now owes Alice $110k in interest per day on his borrowed bitcoin. Netted out, Bob must pay Alice $10k in interest per day, or around $400 per hour, until he transfers an additional $10k to her to equalize their debts. Once again, Alice and Bob have re-invented the perp. The $(index price - mark price) funding rate arises when we net out the interest on Alice’s cash debt (the size of which is equivalent to the mark price) with the interest on Bob’s bitcoin debt (the value of which scales with the index price). ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--28eb5241e6/ce9f707c51e764608c8c103b07764fd5/asset-https-cdn-sanity-io-images-dgybcd83--28eb5241e6.png) Once again, our perp makes sense as long as both parties remain solvent and the cost of capital is less than 100% per day. ## Perp as one-day future Let’s consider a new pair: Anon and Bot. Nobody knows who Anon is, and Bot isn’t even a person. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--025d87937b/a2f048ef8b3fb5e631cb59f5b32d9413/asset-https-cdn-sanity-io-images-dgybcd83--025d87937b.png) These two can’t talk to each other, let alone structure complex deals. Can their interactions tell us anything universally true about perps? I thought not, until the inimitable [Sam Bankman-Fried](https://twitter.com/SBF_Alameda) showed me a theoretical scheme to let them gradually transform a perp into its underlier. Imagine the price of Bitcoin is again at $100k. Anon is long one bitcoin perp (Bot is short) and would like to trade it in for one bitcoin. Unfortunately, the mark price of the perp, which we will in this example define as its trading price, is only $90k. If Anon were to sell her entire perp position, she would get only $90k for it, and would need an additional $10k to buy a whole bitcoin. However, if she were to sell just 1/24th of her position, she would need only $10k / 24 ~ $400 extra to buy 1/24th of a bitcoin from Bot. This happens to be precisely the amount of funding fee she receives from Bot every hour. So, Anon waits an hour, collects her funding fee, and trades that and 1/24th of her perp position for 1/24th of a bitcoin. Now she owns 23/24ths of a bitcoin perp and 1/24th of a bitcoin. If she keeps transforming her position in this way, within a few days it will be almost entirely bitcoin. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--ce279ee28d/08fe40505ae4e6a9bcc000ee43508c76/asset-https-cdn-sanity-io-images-dgybcd83--ce279ee28d.png) Amazingly, Anon’s time-weighted exposure to bitcoin through the perp during this process ends up being the same as it would be if she were holding a futures contract expiring in exactly 24 hours. Ignoring interest rate term structure, this means the two should be priced roughly the same. Now we have a way to interpret the constant factor on the funding rate. If the funding rate were, say, 50% of $(mark price - index price) per contract per day instead of 100%, it would take Anon twice as long to transmute her perp, which would then be equivalent to a *two* day future. Pretty crazy, right? ## Margin and liquidations All of our examples so far have relied on funding rates actually being paid when they are due. While Alice and Bob simply trusted each other, Anon and Bot must put down *margin* to enter into their positions. This is meant to cover any losses that might occur before the positions can be liquidated. Let’s say Anon wants to go long $100 worth of Bitcoin via a 100x perp. She must deposit at least $1 of margin, but she deposits $1.50 to be safe. Almost immediately, the mark price of the perp drops by 1%, so that she has lost $1. This $1 is removed from Anon’s margin account, which now contains only $0.50. This is below the minimum threshold set by the exchange, so she is liquidated and will have to pay a penalty. Ultimately, she may get back only $0.25. Now imagine that the price had dropped 2% before the system was able to liquidate her. In that case, her losses would have totaled $2, and Bot, who was on the other side of the trade, would have made $2. However, Anon only had $1.50 of margin posted, so that Bot’s last $0.50 of profit would have had to come from somewhere else. On most perp exchanges, this place would have been the *insurance fund.* Generally speaking, the system is safe to the extent that liquidations happen quickly enough and the insurance fund is sufficiently capitalized. ## Perpetual innovation There you have it: how I see perps as they exist today. Are you working to change how all of us will see them tomorrow? I’d love to help. You can email me at [dave@paradigm.xyz](mailto:dave@paradigm.xyz) or [DM me on Twitter](https://twitter.com/messages/compose?recipient_id=1184231093576392704). ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--d3a477f28b/ba08fb9c16c4febd5251c17ef9dd50da/asset-https-cdn-sanity-io-images-dgybcd83--d3a477f28b.png) ## https://www.paradigm.xyz/writing/the-future-of-nfts # The Future of NFTs > A live discussion about the future of NFTs. The future of NFTs and what that means for creators, developers, and communities. With Blake Robbins and Reed Duchscher (manager of MrBeast). **Listen here:** [Apple](https://podcasts.apple.com/us/podcast/creator-economics/id1534098122) | [Spotify](https://open.spotify.com/show/3YT4bw7YOEBaPtqmxbX0Nw) *Embed* Transcript **Reed:** \[00:00:00\] Hey! Welcome back to Creator Economics! Our next guest is a good friend of Blake & I — Fred Ehrsam. Fred is one of the most brilliant minds in all of crypto. Fred is best known for being the co-founder of a company called: Coinbase. He is also the co-founder and Managing Partner at a venture firm called: Paradigm. **Fred:** \[00:00:37\] Pleasure to be here! I would talk to you two even if this wasn't some kind of a show, so I feel like this is the best kind of thing to do. **Reed:** \[00:00:46\] I touched on it briefly, but can you give us a little bit about your background and how you got to where you are today. **Fred:** \[00:00:55\] Yeah, sure! Like most people, I grew up playing way too many video games as a kid. I was a semi-professional gamer in high school. This was back in like 2005 before esports was a thing. So I went to school (Duke), and I did computer science because I kind of grew up on the internet. After school, I got what I thought was the intersection of a job that seemed like playing a video game and a legitimate career. The overlap of those two things, in my mind, was being a trader at Goldman. I ended up at Goldman Sachs in New York, where I was trading foreign exchange. It turns out that game wasn't quite as much fun as I thought it would be. Most of the territory on the map was already explored. I was sitting there bored on the nights and weekends. One night, I discovered crypto on a Georgetown professor's blog. I started trading crypto around at work, in the bathroom, on my phone. I eventually got bored at Goldman Sachs and decided to move out to California. After moving out, I met my future co-founder for Coinbase on Reddit (2012). A few years later, we have Coinbase. Three years ago, I started Paradigm, which is an investment firm that just does crypto. **Blake:** \[00:02:20\] That's crazy. I never knew that you met Brian (co-founder of Coinbase) on Reddit. I have so many questions, but...first, what games were you playing in 2005? **Fred:** \[00:02:30\] There were three big games for me. The first was this obscure first person shooter called America's Army. I was on the best team in the world at that game. The next was Call of Duty Modern Warfare. I'd scrim with pros in that. I also played way too much world of Warcraft. Literally. Probably spent three or four thousand in World of Warcraft and then another three or four thousand hours playing the first person shooters. Candidly, I think gaming helped me understand crypto a lot better. In games there are virtual items and virtual currencies in these games. When you live in the metaverse as a kid, the prospect that everybody might do something like that one day starts to seem a lot less weird. **Blake:** \[00:03:12\] Yeah. I'm similar. I was born and raised on the internet. I also play way too many games. You and I have talked about this countless times too. Specifically, Counter-Strike skins and how that feels like a foreshadow into this world. I'm curious though. Did you find your co-founder for Coinbase (Brian) on the Bitcoin subreddit? Did you just post: "Hey, I'm looking for other interesting in people that are spending time in crypto?" **Fred:** \[00:03:44\] Yeah, if you roll the clock back to 2011, Bitcoin was the only cryptocurrency that existed. It was only talked about in two places. One place was a really old school PHP forum called Bitcointalk.org. That's actually where the HODL meme came from — a drunk guy, randomly posted HODL on that forum way back in the day. And then the other place was the Bitcoin subreddit. The reality at the time was probably 80 to 90% of people on there were crypto anarchists and had no idea what was going on. However, 10 to 20% of the people on the subreddit potentially saw the future. Brian and I met in that context. I remember going to the first Bitcoin meet-ups in San Francisco. For context, this was early 2012 and they were in a furniture showroom that opened up at night for extra cash. No exaggeration, I think roughly a third of the people who showed up were homeless. They just wanted the free food and booze. Bitcoin and cryptocurrency was very non-obvious at the time. That's the magic of the internet though, right? You can meet people who are very intelligent and have these very disparate or non-mainstream points of view and and start to create something special with them. For example, that's how Blake and I met. We met on Twitter, and we were originally Twitter friends. I had a mutual friend of ours, Jackson, stay at my house for the last week who I met through you as a Twitter friend. I think a lot of people underrate how important the internet is for forming connections in the physical world nowadays. **Reed:** \[00:05:45\] Completely agree. I've met some of my closest friends on Twitter. And now actually from League of Legends, you get in these random lobbies with another friend and they have their friends playing with you. All of a sudden, two years later, you're like, wow, I'm still talking to this person who I've never physically met, but we've have played over a hundred games of League of Legends together. I want to piggyback on a few different questions about crypto. I think right now it's an interesting time for crypto. As we are having this conversation, I think Bitcoin's at 49,000 as of today, where do you think we are in like the crypto lifecycle? Are we still incredibly early? **Fred:** \[00:06:32\] I increasingly have thought about crypto in three stages of development. The first is a new digital money. The second is a new financial system. The third is a new broad internet application platform. If I had to guess, and these are highly speculative because with any new foundational technology, it is very hard to predict the future and where you are on the trend. But...if I had to guess: We're probably order of magnitude 10% into a new digital money. We're maybe one tenth of 1% into a new financial system. And we are effectively at zero on a new internet application platform. It's super early. **Blake:** \[00:07:19\] I'm curious...you've been through so many ups and downs over the past 10 years in crypto. I imagine there's still going to be rocky waters moving forward and all of that, but what gave you the conviction to devote your professional career to crypto back in 2011 or 2012? Has that come through? Or are you still like: "Okay. We're not even at that point that I believed was going to happen." **Fred:** \[00:08:00\] I'll say two things. As time has gone on, my conviction is crypto working and the scope of what I think that means have gone up substantially. I think that's a very cool phenomenon that exists for any huge fundamental technological breakthrough. At the beginning of any technological breakthrough, it is very hard to predict all of the first, second or third order effects. In the context of crypto — I thought it was just going to be Bitcoin and it was just going to be digital money. I thought we'd be doing some cool internet payments. It's hard to imagine building a new financial system from the ground up or building a whole new internet application platform. We're at like 0% on some of these trends. We're just seeing the tip of these things. The other thing I would say is I've been in crypto for 10 years now. I've experienced some pretty intense ups and downs. At times, crypto has felt stratospheric at many times. Other times, everybody thought it was dead. There's something very cool about going through that kind of volatility and experience. Brian and I use the analogy that: It's as if you're a rubber band and at some point you just get stretched so many times that things tend to not phase you anymore. It's, it's been very, very gut wrenching, but I also wouldn't trade the experience for anything. **Blake:** \[00:09:50\] Yeah. I literally can't imagine. I watched a lot of this from the sidelines, but there were some real moments of: "This is going to the absolute moon." And then there was some moments where it felt like everyone was just kicked in the stomach, and people were stuck questioning: "How do we recover from this?" It's been amazing to watch. I respect the hell out of you and everyone else that's worked so hard to continue to push this forward. It feels like we're finally in this moment right now where Bitcoin is now a thing and at the very least is a store of value. It took 10 years to get her though. I'm curious how long it will take for these other stages of crypto to develop? **Fred:** \[00:10:42\] That's a good question. I started an investment firm premised on the idea that crypto would be the most important technological trend of the next 30 years. I think it will play out, at least over that timeframe. We are probably 25 years into a mainstream internet and it feels like we're just getting started there in many ways. I think it's going to take a long time. The crypto maximalist world view is: Crypto in retrospect is obvious as a mainstream digital money and store of value. Of course, we want an open standard for digital money in a digital world. Why would we not? I think that thought might seem crazy to some today, and it's certainly seemed crazy to almost everybody four years ago. However, it might seem extremely obvious in retrospect. This is the thing about crypto and any new foundational technology. Generally speaking, you have to accept the initial premise of the new technology for your mind to be able to get to all the steps after that kind of foundational layer. For example, let's say we are living in a world where there's a new digital money in the world: People probably want to do stuff with their new digital money like they do in the current financial system with their regular money. That also means we probably want a financial system that is built on top of the new digital money and interacts with it natively. That's the beginning of what we see in DeFi and crypto today. I think DeFi has a cute and somewhat obfuscating name for what's actually occurring there. DeFi has gone from zero to almost $50 billion in user assets in the last two and a half years. It looks like a classic product market fit graph. It's exponential. Up and to the right. I think people still may not grasp the magnitude of what that could mean in 20 years. I think the crypto money thing will take 20-30 years more to play out, easily. The new financial system will take the same amount of time. And the new application platform, will take at least 20-30 years. We are just starting to see the canaries in the coal mine: TikTok almost got censored across nation state borders, or the President got de-platformed, not only from every major social site, but also Amazon Web Services. I say this independent of political view. The takeaway from looking at all of that is if you want to build a truly global application, crypto might be the only way you can do that now. That doesn't even touch all the power that crypto has, where you can build economics directly into apps. You can own all sorts of things, including digital money and digital items like NFTs. If you' are picturing a world where we are living in a Ready Player One Metaverse, you definitely want it to be on some neutral platform where you can own all your own stuff. I don't think we want to live in like Facebook town — if it's our whole life and they could delete your character amongst other things. In any case, it's super early. The more that crypto develops, the more clear it is to me that crypto is the open standard we're going to use for money, information, any digital items. For example, NFTs are part of the tip of that spear. **Reed:** \[00:14:46\] Let's transition into NFTs. This is a question that I've gotten every hour of every day for the last two weeks from other individuals. We are now seeing creators like Logan Paul create NFTs. I think he used Bondly. We are also seeing Nifty Gateway be used. If you're a creator, should you be pushing into NFTs right now? If so, what do you think that looks like? Is it on an individualized item or are you selling a lot of units? I think Logan sold 4,000 units of that trading card. If you're a creator watching, listening, or reading this: what do you think they should start out with? **Fred:** \[00:14:13\] It's a good question. NFTs are just at the start. This period in time will be looked back on as a lot of short term irrational exuberance. This is similar to the beginning bubbles of crypto, where there were a million coins that ended up not mattering. Yet, the trend, is a paradigm shift in terms of how we think about media on the internet and it will be long and enduring. The nature of these sorts of innovations is that people try a whole bunch of stuff at the beginning, not knowing exactly what to do with the new form factor. They throw spaghetti at the wall. Most of it falls off, but there's one or two things that ended up working and sticking. We are that beginning phase today. To answer your question directly of: if I'm a creator, what do I do? The first step is trying to understand why are NFTs powerful? What's the nature of the new medium, because I suspect the most powerful applications of NFTs will be the ones that are uniquely enabled. It could be helpful for us to talk about what that looks. A lot of the stuff being created today won't matter in a couple of years. For that reason, it can be dangerous to release an edition of a thousand for a piece of art. I think that's probably going to be irrelevant for the most part absent of a few idiosyncratic exceptions. The really powerful stuff will be people using NFTs as a new digital medium and building things that wouldn't be possible without this technology. **Blake:** \[00:17:40\] Taking a step back, how do you think about NFTs right now? **Fred:** \[00:17:53\] There have been a thousand thinkfluencer pieces over the last week alone about NFTs. And it's unclear, what even is this thing? Here's the way I think about NFTs: If Bitcoin changed the world by showing everybody that there could be an open standard for digital money, NFTs might change the world by showing everybody that it's an open standard for any digital items. We are just at the beginning of what that means. If you look back in history, there's always been a paradox in creating or capturing value around digital items. If you look at songs, even pre-internet, you need a song to proliferate in the world and get really popular for it to have value. You've gotta play it over the radio. People would copy the song off the radio onto a cassette and make bootlegs. In the internet age that went bananas with Napster. And there's this weird inherent tension in there. Right? If you're a creator, you want your work to spread really, really widely. That's what makes it so valuable. At the same time, if it spreads like digital media where you can copy it infinitely for free then how do you capture any value? It seems paradoxical. It's funny because our solution to that so far has been to try to let it proliferate to a certain extent, but to also try to restrict it. You have DMCA copyright laws or put it in a walled garden, like YouTube or Spotify or Apple Music. The end result is kinda messy. And of course there's a lot of negative externalities to having these centralized gatekeepers of digital media. You guys work with these creators all day, so you know, the story much better than I do. My rudimentary understanding of these centralized platforms is that they are the modern feudal Lords of the internet. You pay them for protection so that they keep your digital media safe and put a garden around it that you can extract value from. At the same time, you become beholden to them. Your work can't really leave their walls, your following can't really leave their walls. It's just kind of anti internet. You can't build on top of it either. NFTs might solve that paradox. It might be that a piece of digital media can be used by anybody, anyone can build on top of it, it can get copied infinitely, etc. and that's great...but there is still is just one owner. And that's a way for the creators to capture value. We are very early in that trend because, just like early crypto, people have to care about NFTs in order for people to build broader platforms around them. It will take a number of years for this idea to catch on and it will seem like a toy at first. NFTs had to matter before a developer was going to come along and build the future Instagram or Spotify on top of them. That will take a couple of years. I think that's what is going to happen over the next five years. Zooming way out, I think you can think of NFTs as internet native property rights. Where you get the best of both worlds: your digital media can spread like wildfire AND you can still be the original creator of it. You can still sell it to somebody. There will be all sorts of nuances layered on top of that, but that's the core nuggets. **Reed:** \[00:22:05\] I have so many questions. What do you think YouTube in 10 years looks like based on that premise? Like what do you think YouTube looks like in 10 years? Is there a situation where Mr. Beast could potentially sell channel by channel instead of YouTube the advertising rights to that video. **Fred:** \[00:22:29\] The creator community has a good a view into this, so I'd be curious to hear what you guys think. In broad strokes, here's what I think is going to happen: Now that NFTs work. You have a business model for creators to sell any of their digital work online. The next logical step from that in my mind is those digital works will ultimately flow up into a creator token. We've all talked about this a bit. Blake and I have been in a side chat for a year and a half musing about how could a Mr. Beast coin get created. We always suspected it would happen, but we didn't know quite how. Now there is a straight line between NFTs and what gives a creator token value. For example: Let's say that a creator can keep a 10% cut of any NFT that they sell. That 10% cut can just flow up into the value of a creator token. All of a sudden you now have an asset that represents you as a creator. That asset is also native to the internet. That is really important because I think that is the beginning of disintermediating the need for a central platform around a creator. You won't need Twitter or YouTube to amass all your followers. It's like using crypto wallets. If you imagine that every user on YouTube are represented by a crypto wallet, as is the creator. All the followers are just the crypto wallets following the address of the crypto creator. You won't need a central platform for the social graph anymore. I think that's where we are heading. It's an economic model and it's a way to directly own your community and following. The crazy thing about this paradigm is all the media is open, so people are going to try to build a million different platforms around it. Who knows? I couldn't tell you what the future YouTube looks like. My brain isn't big enough for that. I do know ...or one thing I will say is this new architecture and the power of it — is something that I have high conviction in. **Blake:** \[00:25:00\] Do you think there is a world where Mr. Beast makes a video and he actually turns that video into an NFT. Maybe it gets posted on all of these random sites and maybe the marketplace just become the place where you consume it? Maybe you are watching it on Nifty Gateway or Zora? And, he can sell the rights to that, or maybe he just doesn't even sell it? But, there is a piece where the video itself has an NFT. And if you buy a chunk of that, then you get access into the Beast token and then you can get into his private community. That's at least one idea that immediately came to mind when you were talking about this. And I think right now we're seeing NFTs as just pure static art. But I think there is something around maybe just make the whole video an NFT. **Fred:** \[00:25:57\] Yeah, I think that's spot on Blake. A number of things that you're saying are really important. One is that marketplaces and platforms are getting smashed into one. Crypto embeds economics in everything, so I think that's very right. I would also say it's just, it's so unpredictable what these platforms are gonna are going to look like. One thing that Mr. Beast has proven to be really powerful is: if you have a highly aligned community behind a creator they love that can create some really powerful businesses. Mr. Beast Burger is super innovative in this dimension. The reason why I think this is going to get really crazy is because the NFT model makes it so that the consumers of the product are also part owners of the product. What if all of Mr. Beast followers owned a piece of the Mr. Beast Burger business and it was digitally native? I think that's where we're kind of heading. **Reed:** \[00:27:20\] You could completely tokenize a creator and every business they start in their career. Right? Could you actually just create a token associated with that creator? They wouldn't even need to potentially do sponsorships on a per video basis because as the value of that creator goes up, the value of that token rises. **Fred:** \[00:27:50\] That's right. We are going to get all sorts of new behaviors out of these highly aligned creators and their communities that we could never have predicted. I think there's little spots on the internet today of this. If you look at things like Twitch Plays Pokemon, or Mr. Beast Burger, or even Wall Street Bets. These are sort of the canaries in the coal mine of how much people find purpose in these communities. These are the very early signs of the potential economic power that exists behind these highly aligned communities and how crazy/creative they can get together. The thing that we haven't really had yet — Wall Street Bets was the first kind of outcropping of this — was some economic alignment behind the community where if it worked, they all benefited. I think one could take a pejorative view of Wall Street Bets and say: "Oh, this is kind of like a short term, zero sum game." Which may be true, may not be true. But what I do know is... It demonstrated that on the internet, a highly aligned group of people with a shared purpose community and mission is really powerful. The opportunity for creators is to harness that kind of alignment and power through a crypto token. That's where we're headed. **Blake:** \[00:29:20\] We have talked about this a bit offline, but it feels like social tokens are the next wave of all of this. You will finally have this incentive, where you are staking or betting on the upside in their career. You can imagine that if Reed started a YouTube channel tomorrow and created a Reed token. People would buy-in. They are going to be far more aligned because they're going to have upside in that moving forward. I think we're going to see these new creators emerge that are very Wall Street Bets-esque where the community is like: "Hey, we own like 50% of their upside — let's go and make sure this person is like the biggest creator of all time." I think there's going to be some really interesting ripple effects that happen around that. **Fred:** \[00:30:12\] Yeah, it's a shared mission. The thing hat crypto on social media has shown in a comical and almost cringe-worthy way is once people are economically aligned, they become your distribution. One thing that I thought was funny, I was scrolling through Elon Musk's twitter feed the other day. And if you look at the engagement on his tweets, the most common response by far is Dogecoin memes. I would bet that if anybody with a large online following just tweeted the word "Bitcoin" alone. That's it. That's the tweet. It will get more engagement than any other thing they've ever done on social media. It just shows the power of what happens when there is economic alignment with the community behind these things. I think that force could extend could extend quite far. It might be the way these new kind of digital companies or collectives get started. Perhaps it starts with a creator launching some kind of community, and it grows into this big, weird, amorphous kind of decentralized company. Almost like a subreddit where they start the fire, but just like any company — they might be the minority of what actually pushes it forward over time. **Reed:** \[00:32:03\] Yeah. You and I talked about this a little bit and I think the interesting thing about Elon is like people can invest in Tesla. I think people are really looking for a way to invest in these individual creators. It's also goes with my thesis. That was why I started Night Media. I think that loyalty to brands is ending and now it's loyalty to the individual. And creators are kind of at the forefront of that. So this is all really interesting to think about. Social tokens is incentivizing fans to feel invested. Like they have that deeper loyalty. And that's like, where I see this whole industry going. There are probably 10 to 15 creators that are kind of sitting at the top that have massive communities. Now they need to start figuring out like how they turn these into real businesses or how they allow their fans to get deeper involvement. **Fred:** \[00:33:03\] Yeah, that is spot on. I think you're right that people want to feel invested. The one thing that Wall Street Bets showed is that people are seeking purpose increasingly through the internet. Wall Street Bets is a mix of economics (a way to make money) and finding community (purpose in life more generally). The same is true of what you're saying — where brands feel corporate now, but creators feel authentic. And that's sort of your thesis with Night Media. You said: "Feel bought in." I think the interesting thing about crypto is that they actually are bought in. It's real economic alignment. That is the rocket fuel that has been shown to be really powerful in crypto. And I think the same thing could start to be true of these creators and their communities. **Blake:** \[00:34:13\] I'm curious if, if we go back to NFTs as a concept. Right now, the people who are skeptical are saying: "Oh, I can just copy and paste this image, or I can go and copy and paste this video or whatever." Right? Obviously that's very lazy, but I'm curious from your side how you would respond to that. You touched on it a little bit of how people will do it with cassette tapes and music back in the day and that music or that artists still succeeded. I'm curious how you view it just in general with NFTs today, because that is, I think the very simple view that some people are taking on it. **Fred:** \[00:34:52\] Look, it took me a while to get over that same hurdle. It goes back to the paradox of digital media. The whole point of anything digital is that you can replicate it for zero marginal costs. At the same time, anybody who spent time in digital worlds knows that digital scarcity works. Bitcoin showed that. It has been shown to work in video games too with skins. Ultimately, I think it works in the art market too. For example, let's say there was an original Picasso painting. And then there were a bunch of replica Picasso paintings, but only one was actually created by the real Picasso. I think we all have an intuitive answer as to like what accrues value. I think the same thing is going to exist in the digital world. There's going to be only one or a series of works that are minted truly by a creator, whether it's a blog post, a piece of music, album art, a 3d character to be played in a video game, etc. People will look at that and say, this actually was made by the creator. That will be the schelling point for attention. That's the thing everybody's going to say is real. And there's a mental leap there. I also think it's really early. I'm not sure if NFTs will be a panacea for everything. One way to think about NFTs is that it's more akin to a patronage model. e.g. As somebody who loves this piece of work, I'm going to buy it. And perhaps that's less mainstream than everybody paying for music on iTunes through a subscription service that's enforced by copyright law. I do suspect it will go further than that though. And here's why ... We've seen with video games that people like to play games. They like to enforce rules around reality to make things fun. Imagine playing a video game or a board game where there were no rules, it would just suck. I think that dynamic occurs again and again in gaming and, and just sort of in life broadly. And I think that will happen here too. We will get the best of both worlds where people will allow these open standards to exist. Anybody can freely build anything. At the same time, I do think people will enforce standards just to create great digital experiences. I think the challenge to all this, which you can infer based on what I'm saying is: it's going to take a while for all of these platforms to get built to give the NFTs more fundamental value. It's just like Bitcoin in 2012. Some people own it. You can't really do anything with it. It seems like a novelty. Everybody's asking where is the utility. The answer is like there kind of isn't any, except that there's this future idea that these cool collectibles could be used fro a lot (including store of value or whatever). NFTs will seem like a novelty at first. However, over the next 5 to 10 years, people will build these apps. There's going be games or the next version of Spotify or YouTube. Those platforms will start giving the NFTs value. And then the two enter a self-reinforcing feedback loop. The platforms will inform what types of NFTs makes sense and will give them value. And now that the NFTs have utility value and have a form factor that makes sense with the platforms, more people will build platforms for them. And off we go... **Reed:** \[00:39:05\] What platforms should creators be looking at right now? What's the easiest point of access, if they would like to mint an NFT? **Fred:** \[00:39:20\] Here's what I would say. If you believe that NFTs are extremely important and versatile building blocks that will be used and remixed to get put into all sorts of different applications and potentially your own creator token then... The most important thing is that you own your NFTs. You need to mint them yourself. If you don't do that, you can't roll them up into some future token that you own because you don't own the original NFTs. To the extent that they're not just simple, basic building blocks that exist for anybody to import into a new app, then future applications that import NFTs, aren't gonna be able to use your stuff either. That would suck as a creator. Since all this NFT stuff is new, most creators don't grasp how important it is that these are open and neutral building blocks for those reasons. My most important piece of advice is to mint and own your NFTs yourself. Some platforms let you do that. Others don't. We are in a weird stage right now where people don't understand that. I also think that it's sort of like the service Coinbase offered with Bitcoin. People are conflating the open standard for the asset with the platform itself. There are platforms where they mint your works for you. That's convenient, but you don't own it anymore. That's great for some because the platform is super user-friendly for both the creators and the marketplace users on it. To get more specific about this, I am very biased here. I think the best platform out there is: [Zora](http://zora.co/)\* which is made by an ex-Coinbase designer and a couple of other ex-Coinbase people. The reason that I really like their approach is because it's a protocol where you mint the NFT from your Ethereum account, which means you own it forever. If you want to do other stuff with it later, you can. And the other powerful thing about Zora is that it embeds the market for the NFT directly into the NFT... The reason that is important is because that means that there's this marketplace for your NFT, that just exists on the blockchain. You don't need any central marketplace to give it value. This creates wild dynamics. You can go look at any NFT minted on Zora and you can see who's bidding on it. As a creator you can choose who buys it. Let's say I'm some random creator and Virgil Abloh bids on my NFT. I probably want to sell it to Virgil, not random XYZ person. To summarize, Zora is an open standard for creating NFTs yourself and it's an open standard for the markets around them. In my opinion, that's the most interesting. It's early as it's an open protocol. The interfaces that are built on top of it are still being built. Over time, I think there'll be like a thousand interfaces. And of course, there are other great players out there. Other marketplaces have been crushing it too, such as Nifty Gateway or Foundation. Again, I can't emphasize enough how important it is to mint and own your own NFT **Reed:** \[00:43:10\] Is Nifty Gateway, allowing creators to mint their own NFTs, or is it being minted by them? **Fred:** \[00:43:18\] My understanding is that, today, Nifty Gateway is actually the one that's doing the minting from their Ethereum accounts. This is great for convenience. I think it's problematic for eventual, true artists ownerships — which is where I think we are going. **Reed:** \[00:43:37\] Yeah. I think that's a really important point. If you're a creator listening, try to really understand who is actually minting and owning these NFTs before you jump in a relationship because you want to get something into market. I hope everyone actually takes their time and does their research to really understand the ecosystem. **Fred:** \[00:43:52\] The other thing I would say is there is a lot of NFT mania today. I would really advise creators to not just go mint a hundred or a thousand of some random image. I think you're going to end up with a bunch of community members who might think today, like: "Oh, this is going to be super valuable." And then in six months to a year, it could be like meaningless and you have a lot of community members who are kind of pissed. The thing I would really encourage creators to do is to experiment in small ways, don't go bananas. Try to get really creative with it. What is it that you can do with NFTs as a new medium? That could be really cool or is building towards something bigger. The best internet creators have a mind for that naturally. And then it's just a matter of that developing over the course of the next couple of years as people try these little experiments. **Blake:** \[00:45:03\] Yeah. I think it gets really interesting around like social tokens and membership products. Like if you have X number of these tokens or X, Y, and Z creators tokens, and you can get access to a private community and or maybe there's gated content behind that. I think those pieces get really really interesting. I think it's just another reason of why you need to be minting the NFT because if you're not, then you might not have the control or freedom to do that moving forward. **Fred:** \[00:45:32\] Totally. And the wild thing about these things is they take on a life of their own. For people who aren't familiar. There's this thing called Unisocks in the DeFi ecosystem. They are literally are pairs of socks. There were 500 created by the designer of, what is now one of the largest DeFi apps in Ethereum, Uniswap. Uniswap is a decentralized exchange. The point is that the the designer of Uniswap made these socks. 500 pairs, and then he created a token that's attached to every pair. He launches the thing out there. It's sort of like a joke or novelty at first. Guess how much one pair of socks of tokenized socks is going for right now? **Blake:** \[00:46:30\] I know the answer at this point. **Reed:** \[00:46:32\] Same yeah, I know because you just asked this. I I'm guessing it's went up since we talked, but I think he was at like $166,000 last time. You and I looked. **Fred:** \[00:46:40\] Yeah, it's $125,000 right now. **Reed:** \[00:46:42\] Okay. So it's went down a little, I guess it was a different one. Maybe one sold yesterday. **Fred:** \[00:46:46\] Yeah. In any case, I think the point is on. What we've seen with the Chinese version of StockX and the whole sneakerhead community is people love thinking about these collectibles as something that just represents a piece of their fandom. If you look at the sneakerhead community, there's this whole keep it deadstock thing — where you never actually wear the shoes. It turns out the sneakers are actually traded synthetically more than people actually take physical delivery of the sneakers. It wouldn't surprise me if we see the same thing happen with some of these creator tokens. For example, imagine if you create 10 tokens to have a 10 minute FaceTime call with me. Three people might use their tokens the first week after it's launched. You can imagine being three years down the line and there's like two of these tokens left and people might just like shove it under the mattress and view it as a store value. In the same way, that someone might collect a rare coin that the US mint made a hundred years ago. I think that's another odd dynamic of what's occurring here. **Blake:** \[00:48:10\] Yeah, I think that's spot on as far as just like the things that have gotten me the most interested. Especially Unisocks and that dynamic of where if you redeem it, then it destroyed on the supply side. And now there's only 350 pairs that are actually left to be redeemed. I think it gets really interesting in the FaceTime example as well. Or maybe you can redeem the token to be in a video or I'll fly you out for a fan experience. You can imagine those things happening. Those cashing in for a large, large amount of money. And again, it sort of indexes on how big this creator is or how big this collective is. And as a 'buyer' of these tokens you view it as "I know that Mr. Beast is going to continue to go up. And so this will only become more valuable to want to be in one of his videos" You're either going to hold that, or maybe you're just going to cash it in because you know this is a once in a lifetime opportunity. I think those pieces are just super interesting to think about. **Fred:** \[00:49:03\] Yeah. Another funny form factor of this that I saw yesterday was on The Bored Elon Musk twitter account. They are selling a token that will allow whoever purchases the token to write the next tweet on their account. That was kind of taking off. I don't know where it settled. I should probably look at it today. **Blake:** \[00:49:25\] Wow. That's super interesting to think about as NFTs or social tokens becoming a redemption mechanism. If you have this collectible, then it can be transformed into: you're now in this elite group of collectors and being in this elite group of collectors, you have access to X, Y, and Z. I think that piece feels like the next wave. **Fred:** \[00:49:57\] Yeah. And the level of community engagement that can come behind that is super powerful. Like one example that I found very interesting last week was seeing Nadeshot, the CEO of 100 Thieves, tweet that if you guys retweet this a hundred thousand times I'll get a tattoo. That's pretty extreme though. It's basically like community gets to decide how I alter my body as a creator. And that was without any economics tied to it. So I can only imagine how far this might go, if you throw economics in the soup there. **Blake:** \[00:50:40\] Oh, imagine in some very futuristic world, where someone bids for the spot of where he does it or what the message is of the tattoo. Right? I can imagine there's a world where someone says I'm actually going to just sell this spot of my body or, and be like: "do you want to buy the tattoo placement?" I imagine you will have these companies or people bidding for that. There's so many different pieces of this. **Fred:** \[00:51:05\] Right. And like /r/place for those who remember that Reddit experiment is sort of like a primitive, really digitally native version of that. Or like Twitch Plays Pokemon is sort of in this vein too. It's just all been for the lols so far. The interesting question is if you put a real economic engine behind it — could that do real substantive things. **Reed:** \[00:51:38\] Well, Fred, we appreciate you coming on! I know we're closing in on an hour. Every time I talk to you, I feel like I just gained a wealth of knowledge. So hopefully everyone listening feels the same way, but we appreciate you coming on. **Fred:** \[00:51:48\] It's always good to talk to you guys. **Blake:** \[00:51:50\] Yeah, this is, this was super informative. Definitely check out Fred's blog and follow Fred on Twitter, but he's brilliant. And I'm super thankful that he came on to talk about this. **Fred:** \[00:52:00\] The thing that's great about this is I feel like there's so many good ideas in the minds of the creators and the communities that follow them. When you grow up on the internet, you see it all over the place. If you ever read Reddit, it feels like a lot of the smartest people in the world and the best ideas come from there. There is a reason that a lot of the best memes and cultural artifacts start on 4chan. There is: "How do we better unearth that?" And I think this might be how it gets done. This might be the future business model for creators and these broad decentralized communities. The cool thing about it is that you two are the ones that have been studying these communities, pilot them, and are members of them. I'm really looking forward to continuing to jam with people like you to figure out exactly how it was going to play out. **Reed:** \[00:53:00\] Thanks everyone. ## https://www.paradigm.xyz/writing/establishing-bounds-for-miner-revenue-in-eip-1559 # Establishing Bounds for Miner Revenue in EIP-1559 > We believe that the impact of EIP-1559 on both miner revenue and ETH holders has not been well explored. The main reason this analysis has been difficult before is that miner-extractable value has started to make up a large share of miner revenue due to constant arbitrage opportunities in Defi. ## Goal of the analysis - Establish lower, middle and upper bounds for how much miner revenue will be burned ## Analysis We believe that the impact of EIP-1559 on both miner revenue and ETH holders has not been well explored. The main reason this analysis has been difficult before is that miner-extractable value has started to make up a large share of miner revenue due to constant arbitrage opportunities in Defi. To give you a quick refresher The revenue miners receive, and that EIP-1559 stands to affect, currently consists of three sources: 1. *A block subsidy of 2 ETH per block as well as an extra reward for uncle blocks.* 2. *Fees from users who bid for inclusion in the blockspace market (irrespective of their final position in the block).* 3. *And third, the difficult-to-quantify but very high value miners can extract by inserting (or not inserting) transactions at specific points in the block. This is called miner-extractable value, or MEV, and most miners currently “outsource” it to frontrunning and arbitrage bots, who run bidding auctions with each other in the mempool.* *After activation of EIP-1559, ****miners will continue to receive the same revenue from the block subsidy and MEV****. The value from inclusion fees would be burned as long as the system isn’t congested (demand below the maximum gas limit). When demand exceeds the maximum gas limit, there would be an additional first-price auction between transactors, with the proceeds going to miners.* *(*[*Source*](https://insights.deribit.com/market-research/miners-will-accept-eip-1559-here-is-why/)*)* Fortunately, last week we saw the launch of Flashbot’s MEV dashboard. This project can identify MEV transactions by looking for certain MEV generating patterns (this is done by inspecting [every call](https://github.com/flashbots/mev-inspect-rs/) performed along the transaction’s execution trace). The full methodology can be seen [here](https://explore.flashbots.net/data-metrics). In combination with overall revenue, we can now correctly assign transaction types to their correct buckets. ## Chart 1: Establishing the absolute lower bound ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--78c304d42c/e9935ea1a7cc3d067b945b900e4e1af8/asset-https-cdn-sanity-io-images-dgybcd83--78c304d42c.jpg) Using the data of flashbots.net allows us to establish an **absolute lower bound for fee revenue from MEV extraction**. Chart 1 makes the assumption that no MEV exists beyond what flashbots can already recognize. But as you can see from the below methodology, many protocols and transaction types are still missing and will only be added over time. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--1e912e5425/f72fd14bb58f67c36665a14d14aff132/asset-https-cdn-sanity-io-images-dgybcd83--1e912e5425.jpg) ([Source](https://explore.flashbots.net/data-metrics)) So we know this assumption is false, but it presents an **absolute lower bound for fee revenue from MEV extraction** that we can now build on. ## Chart 2: 67% of MEV is correctly classified ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--ec290f7d68/0436d6b7cf05269998afcc4c7780d41e/asset-https-cdn-sanity-io-images-dgybcd83--ec290f7d68.jpg) The second chart assumes that flashbots correctly classifies 67% of the MEV that is currently extracted by miners. We can visualize this assumption by multiplying the share of MEV among all transaction fees by 1.5. ## Chart 3: 50% of MEV is correctly classified ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--27873b9f9e/b305697ee4fb0f019fd24928487342ed/asset-https-cdn-sanity-io-images-dgybcd83--27873b9f9e.jpg) The third chart assumes that half of current MEV is correctly classified by flashbots. We can visualize this assumption by multiplying the share of MEV among all transaction fees by 2. ## Chart 4: 33% of MEV is correctly classified ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--f6b5d6a834/2197c827e08de771d93039a5facf8061/asset-https-cdn-sanity-io-images-dgybcd83--f6b5d6a834.jpg) In the fourth chart, we can see the distribution under the assumption that only 33% of current MEV is correctly classified by flashbots. We don’t believe this is correct today, but we do strongly believe that this where Ethereum is headed and that it will become true in less than 12 months. That is because the range of possible MEV is constantly expanding and extraction methods are becoming more sophisticated, while user demand to transact does not necessarily increase at the same pace. ## Shortfalls of this analysis - Non-MEV transactions will also pay tips when the chain is congested, so miners will receive some of the orange area (congestion fee) as well - MEV transactions also pay a basefee, so miners lose some of the green area. Though we believe it is negligible compared to the value stored in the tip - Our analysis does not capture MEV that miners extract directly, e.g. via including their own transactions. ## Conclusion We can see that circulating estimates that EIP-1559 would burn over 50% of miner revenue are completely unfounded. Depending on how much unclassified MEV we missed, our guesses range from 20% to 35% at most. These numbers still don’t represent credible upper bounds, since not only has flashbots not yet correctly classified the entire Dark Forest, but the Dark Forest itself is always expanding. ## Resources - [Miners will accept EIP-1559, here is why](https://insights.deribit.com/market-research/miners-will-accept-eip-1559-here-is-why/) - Uncle rate [Ethereum Uncle Rate](https://ycharts.com/indicators/ethereum_uncle_rate) - [MEV Dashboard](https://explore.flashbots.net/) ## https://www.paradigm.xyz/writing/miners-will-accept-eip-1559-here-is-why # Miners will accept EIP-1559, here is why > EIP-1559 is one of the most highly-anticipated Ethereum upgrades of all time, radically changing how users bid for transactions, among other major benefits. EIP-1559 is one of the most highly-anticipated Ethereum upgrades of all time, radically changing how users bid for transactions, among [other major benefits](https://insights.deribit.com/market-research/analysis-of-eip-1559/). EIP-1559 has overwhelming community support and is technically ready to be included in the hard fork after Berlin, pending the usual core developer evaluation process. Lately, miners have started to rally against the proposal. This is not too surprising, since the mechanism would burn some of the transaction fees miners would have previously received. Although it may seem counterintuitive, our hypothesis is that the best strategy for miners is to support the deployment of EIP-1559. We test this hypothesis by examining the two most effective ways for miners to protest the proposal: (1) fork Ethereum to create an altcoin without EIP-1559; and (2) block EIP-1559 on Ethereum by driving the basefee to zero. After considering their feasibility & cost, we find that any form of aggressive protesting would damage long-term miner revenue more than cooperating with users. ## Miners are structurally long ETH and the Ethereum economy The revenue miners receive, and that EIP-1559 stands to affect, currently consists of three sources: - First, a block subsidy of 2 ETH per block as well as an extra reward for uncle blocks. - Second, fees from users who bid for inclusion in the blockspace market (irrespective of their final position in the block). - And third, the difficult-to-quantify but very high value miners can extract by inserting (or not inserting) transactions at specific points in the block. This is called miner-extractable value, or MEV, and most miners currently “outsource” it to frontrunning and arbitrage bots, who run bidding auctions with each other in the mempool. After activation of EIP-1559, **miners will continue to receive the same revenue from the block subsidy and MEV**. The value from inclusion fees would be burned as long as the system isn’t congested (demand below the maximum gas limit). When demand exceeds the maximum gas limit, there would be an additional first-price auction between transactors, with the proceeds going to miners. To earn these rewards, miners have to invest in mining hardware, power purchasing agreements, and other capital expenditures. This investment makes them **structurally long ETH and the Ethereum economy** because they have to mine for the investment to pay off. While we don’t deny that EIP-1559 has the potential to reduce one of those three sources of revenue, miners will still have enough future revenue “at stake” to protect Ethereum and its users. Even with the entire basefee being burned, MEV and the block subsidy will still be a significant source of revenue for miners. Finally, the deployment of this upgrade *could* also mark a turning point in user demand for Ethereum, ultimately growing the Ethereum economy as a whole. ## Users are the Ethereum economy To understand the power dynamic in Ethereum, it is important to understand that all three sources of revenue stem from users and the applications and businesses that serve them. Users create the demand for ETH, which miners then sell to them in exchange for fiat, as well as for other tokens in the Ethereum ecosystem. Their demand to transact, exchange, borrow, lend etc. these tokens creates congestion fees. And finally, their usage of Defi applications, e.g. decentralized exchanges, creates MEV in the form of constant price arbitrage and other opportunities for miners. **Users are the Ethereum economy**. Miners provide a service to them in the form of network security. It is a transactional relationship – miners don’t provide this service out of the good of their heart, but in response to the financial incentive that users create for them. **Users have no moral (or other) obligation to pay miners more than is needed for Ethereum to be secure anymore than miners have a moral (or other) obligation to keep mining when it’s not profitable for them.** Ultimately, the power dynamic between users and miners can be explained with replaceability. It is near impossible for miners to replace the current Ethereum users as their main source of revenue. But it is very possible for users to replace some or even most of the current Ethereum miners. Having established this basic relationship between miners and users, we will apply the framework to various scenarios of how the EIP-1559 activation could play out. ## Scenario 1: Miners maintain the old chain without EIP-1559 We mention this only for the sake of completeness because in many other blockchains, upgrades face an inherent uphill battle. That is because it’s generally cheaper for users to do nothing and stay on the existing chain, and hence it becomes easier to block new proposals from going through. This cannot happen in Ethereum due to the difficulty bomb. In short, if there is no hard fork to reset the difficulty bomb, mining difficulty will increase until Ethereum itself grinds to a halt. That makes it impossible to stay on the old chain ‒ **any EIP-1559 opponents would need to incur the same cost of going through a hard fork that at least defuses the difficulty bomb**. ## Scenario 2: Miners create an altcoin with Ethereum’s state A more viable proposal would be for miners to simply fork Ethereum and create their own altcoin, similar to how ETC once forked from ETH or how BCH forked from Bitcoin. **Whether it can make sense to fork would depend on the opportunity cost of doing so ** [^1]. In the case of EIP-1559, miners would have to decide between mining their new altcoin chain and the existing Ethereum chain. This opportunity cost is no joke, since—as we previously established—in order to pay miners any revenue, a blockchain **first needs to create value for users for there to be a valuable block subsidy, congestion fees and MEV**. Both Bitcoin and Ethereum have been forked dozens (or even hundreds) of times, but most of these forks never got any traction with users. Building that traction is a lot easier when you can also **fork a blockchain’s state**, and all successful forks of the past have done just that. In Bitcoin, the state is simply a list of coin ownership. BCH forked this list to leverage Bitcoin’s existing supply distribution and airdrop new coins to all BTC holders. But Ethereum’s state is more complex, containing not just the distribution of Ether, but also thousands of different tokens, smart contracts, applications, and so on. **These would also be copied in a fork, but they would be mere skeletons on another chain**. For example, many of the largest tokens on Ethereum such as stablecoins or WBTC are claims on an asset in the real world. Duplicating the claim wouldn’t duplicate the asset. These claim tokens would continue to operate on the EIP-1559 Ethereum chain, but be worthless on the fork chain. As a consequence, remaining Defi apps on the fork chain that rely on collateral would also unwind, for example the collateral-backed stablecoin DAI or any form of AMM pool. In short, everything other than ETH, including important off-chain infrastructure like oracles, liquidation bots, etc. would blow up and it would create a huge mess on the fork chain. While ETC was able to fork from Ethereum in 2016, a similar event is no longer possible today. **The emergence of tokenized assets and Defi has made Ethereum’s state unforkable ** [^2]. ## Scenario 3: Miners create an altcoin with a fresh state If Ethereum’s state cannot be forked, what about an altcoin that copies only the safe elements of Ethereum’s state (e.g. the distribution of ETH) or even starts from a completely fresh state? This is more viable than scenario 2), as is proven by other “stateless” forks of Ethereum such as Tron and most recently Binance Smart Chain (BSC). Especially the success of the latter proves that there is tremendous value in leveraging Ethereum’s Virtual Machine (EVM), the existing wallet infrastructure (like Metamask), and developer tooling. Further, while dapps wouldn’t be copied automatically, they would be trivially deployed and could later be populated with new assets. Given the rapid success of BSC, wouldn’t there possibly be market demand for a “permissionless” version of it, with PoW mining instead of a centralized operator? The new chain could even increase the gas limit, to target the same demographic of users who are currently priced out of using Ethereum due to the high gas prices. But on further reflection, this approach is also loaded with problems, and the issue is around supply distribution. If the new chain decided to reset the supply distribution of ETH and start from 0, **it would lose the existing supply distribution. Bootstrapping a new supply distribution would require years of high inflation, making the asset unattractive to hold**. BSC, in comparison, doesn’t have this issue, since Binance is the only block producer and needs no additional mining incentive. But if the new chain, alternatively, copied the distribution of ETH, then a lot of the new ETH would be in the hands of potentially hostile users who could use it to depress the price for a long time. **This would render any block reward for miners on the new chain worthless and shows that even “stateless” forks require some amount of support from existing users**. ## Scenario 4: Miners join the new chain but block EIP-1559 there As we have laid out, any attempts to create an altcoin are basically doomed to fail. This leaves one more possibility, which is also the most discussed by miners. In this scenario, miners would join users on the new Ethereum blockchain, but then suppress the EIP-1559 mechanism from burning any ETH by manipulating the basefee to zero. The method would work as follows: The EIP-1559 controller determines the next block’s basefee by observing the size of the previous block. If the previous block exceeded the target gas limit (50% of the maximum), the basefee would increase to throttle transactor demand. If it was smaller than the target gas limit, the basefee would decrease to encourage demand. Miners can technically control how many transactions they include, and hence can control the blocksize, and hence can control the basefee. If they **only ever mined blocks that are less than half-full, the basefee would never increase above zero** and hence none of the fees would be burned. **However, competition between different miners makes this strategy impossible in practice**. First, imagine that a single mining pool with 5% of hashpower tried to implement this strategy. They would only mine blocks that are half-full or smaller, even if demand far exceeds that level. Meanwhile, the other 95% of hashpower would mine larger blocks, make more revenue from fees, and the basefee would increase anyway. The 5% mining pool quickly would realize it is bleeding money and give up or lose all of its hashpower. This shows that **self-interested miners want to include as many transactions as possible, as long as there is competition between them**. So what if there was less competition? Imagine that instead of 5%, 60% of miners would agree to implement this strategy. The outcome would be the same, since for every half-full block the 60% cartel mines, the other 40% would get to mine full blocks, and get all that extra revenue from congestion fees and MEV, and basefee would still increase over time. We call this an **unstable coalition**. The strategy *only* works if the hostile miners could find a way to **eliminate that competition, so that no one else can mine large blocks either**. With 60% of hashpower they could do that by implementing a so-called miner-activated soft fork (or MASF). This MASF would dictate that blocks over half-full are now invalid, and hence the 60% of miners should simply ignore them. Now the 40% could still technically mine larger blocks, but the 60% would refuse to build on them, and so all the transactions and block rewards distributed by the minority cartel would evaporate. Now you have to understand that **MASFs are nothing new**. Miners can already form such a cartel today to e.g. drive up fees by restricting the gas limit, charge higher fees from larger transactions, or set a price floor. All of these strategies seem more profitable at first, but there is good reason miners don’t attempt to implement them. First, they require cooperation from many mutually distrusting parties, which is very difficult to achieve. But more importantly, a MASF would be an **unprecedented attack on the Ethereum network and its users**. It would both destabilize the network at the consensus level and disrupt the trust of users into Ethereum. This already threatens future miner revenue, but users can also oppose the censor in more active ways. For example, we would expect users would start broadcasting their transactions directly to a friendly mining pool to withhold fees and MEV from the censoring pool. In summary, **basefee manipulation is not a stable equilibrium for miners without a MASF**. But if miners did implement a MASF, it would be an **unprecedented and self-destructive attack on Ethereum and hence their own investment ** [^3]. ## Scenario 5: Miners join the new chain and smoothly implement EIP-1559 In light of the unsatisfying outcomes for miners in scenarios 1 to 4, we are convinced **their dominant option is to simply cooperate with users**. Even if miners made less money on the new chain—which is not a given—that would still be far more than they could by trying to create an altcoin. Any such altcoin would have near-zero value in relation to ETH, no transaction fees from congestion, and no MEV from Defi arbitrage opportunities. Further, implementing a MASF to suppress the basefee would be an unprecedented and transparent attack on Ethereum and its users. We have never seen such an attack in the wild, and for good reason. It would likely disrupt user confidence and the value of ETH as well as the economic activity happening in the system, and hence goes directly against miners’ interests. ## Possible concessions On top of the five scenarios discussed above, there has also been discussion of different concessions users could make to appease miners. The main ones mentioned were: 1. Raising the block subsidy on the new chain to compensate miners for the burning of basefee 2. [EIP-969](https://eips.ethereum.org/EIPS/eip-969): Changing Ethereum’s PoW algorithm to remove ASIC miners from the network 3. Instead of burning the basefee, distribute it to the miners of the next N blocks We however re-emphasize that **it is already in the best interests of miners to cooperate with users on the upgrade**. Hence users don’t need to meet the miners’ demands and make any further concessions to them. ## Conclusion This is how we expect the upcoming EIP1559 transition to play out, and we are confident in our analysis. We look forward to discussing these arguments with the community at the [upcoming EIP-1559 roundtable](https://medium.com/ethereum-cat-herders/ethereum-1559-community-call-d43d5f0bf909) (Friday, February 26, 2021, at 14:00 UTC). ## Resources & Further reading - [Deribit Insights Analysis of EIP-1559](https://insights.deribit.com/market-research/analysis-of-eip-1559/) by Hasu and Georgios Konstantopoulos - EIP-1559 [updates](https://hackmd.io/@timbeiko/1559-updates/https%3A%2F%2Fhackmd.io%2F%40timbeiko%2F1559-update-006) and [resource list](https://hackmd.io/@timbeiko/1559-updates/https%3A%2F%2Fhackmd.io%2F%40timbeiko%2F1559-resources) by Tim Beiko - [Ethereum is now unforkable, thanks to DeFi](https://haseebq.com/ethereum-is-now-unforkable-thanks-to-defi/) by Haseeb Qureshi - [Transaction Fee Mechanism Design for the Ethereum Blockchain: An Economic Analysis of EIP-1559](http://timroughgarden.org/papers/eip1559.pdf) by Tim Rougharden - [What does a Miner revolt look like?](https://medium.com/coinmonks/what-does-a-miner-revolt-look-like-a99216fe270e) by Micah Zoltu - [Debunking EIP-1559 misconceptions](https://hackmd.io/S6kW1MjvT8-SjmaoZTyaJw) by Micah Zoltu *Acknowledgments: Thanks for feedback to Tim Beiko, Pintail, *[*mewny*](https://twitter.com/mewn21)*, and *[*Jing Wang*](https://twitter.com/jinglanW)*.* [^1]: There are also other large costs involved with bringing a new blockchain to market [^2]: We strongly recommend you read Ethereum is now unforkable, thanks to DeFi, by Haseeb Qureshi. His article lays out in great detail what would happen if someone tried to fork Ethereum’s state, concluding that it is utterly impossible today [^3]: For a formalized version of this same argument, see Tim Roughgarden’s analysis Chapters 6.2 and 7 ## https://www.paradigm.xyz/writing/mev-and-me # MEV and me > Ethereum’s core insight was that flexible smart contracts allow developers to explore a new frontier of permissionless applications. The explosive growth of decentralized financial protocols built on Ethereum (“DeFi”) is a glimpse at what this innovation could enable in the future. Like programming libraries in the first Internet revolution, DeFi’s “money legos” enable developers to build complex systems by composing and remixing simple building blocks. This complexity also brings novel risks. One of these risks is Miner Extractable Value, or MEV. Ethereum’s core insight was that flexible smart contracts allow developers to explore a new frontier of permissionless applications. The explosive growth of decentralized financial protocols built on Ethereum (“DeFi”) is a glimpse at what this innovation could enable in the future. Like programming libraries in the first Internet revolution, DeFi’s “money legos” enable developers to build complex systems by composing and remixing simple building blocks. This complexity also brings novel risks. One of these risks is *Miner Extractable Value, or MEV.* ## Miner Extractable Value The concept of MEV was first introduced by Phil Daian in “[Flash Boys 2.0](https://arxiv.org/abs/1904.05234),” and more recently popularized by my colleagues Dan Robinson, Georgios Konstantopoulos, and samczsun in “[Ethereum is a Dark Forest](https://medium.com/@danrobinson/ethereum-is-a-dark-forest-ecc5f0505dff)” and “[Escaping the Dark Forest](https://samczsun.com/escaping-the-dark-forest/).” It has become a foundational concept in cryptoeconomics, but what actually is MEV? What are the implications for permissionless blockchains? ## What is MEV? *MEV is a measure of the profit a miner (or validator, sequencer, etc.) can make through their ability to arbitrarily include, exclude, or re-order transactions within the blocks they produce.* Imagine there’s a $10,000 arbitrage opportunity available on Uniswap after a large trade has caused price slippage. An arbitrage bot notices the opportunity and submits a transaction to capture it, offering a $10 txfee to the miner. One of two things may happen: 1. A miner will copy and censor the arbitrageur’s transaction in order to capture the opportunity themselves. 2. Other bots will notice and bid a higher txfee, starting a bidding war for the right to capture the arbitrage. The auction is called a “Priority Gas Auction” (PGA). The $10,000 potential profit is MEV. If a miner does not capture it, and a PGA is kicked off, the difference between the price at which the auction settles and the total MEV available is the winning trader’s profit (e.g., if a $7,000 fee is paid to a miner, the remaining $3,000 is left to the trader). This example gives a high-resolution view of MEV, but it does not paint the whole picture. MEV is not just a curiosity. These little financial games create incentive ripples, a winding chain of cause and effect that must be followed to see the contagion. This post will explore that thread and explain why *MEV may harm Ethereum and its users.* ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--e632e74534/aad1afb0dc99302cb008491c1d706842/asset-https-cdn-sanity-io-images-dgybcd83--e632e74534.png) As a direct result of DeFi’s inflective success, the known lower bound of *Ethereum MEV is growing at an exponential rate.* At this pace, we believe that MEV could create meaningful issues within the next year. ## The state of play *It is impossible to say how much MEV is on Ethereum in total. All the MEV which we are currently aware of only constitutes the lower bound.* This is because MEV can be created any time a user interacts with a blockchain, and smart contracts enable a functionally infinite number of potential interactions. Thus, it is computationally infeasible to calculate a blockchain’s total potential MEV by brute force. However, we can establish a baseline by adding up the MEV that’s known to have been extracted (which is the “*realized MEV*” shown in the graph above). Then, we can use heuristics to infer how much higher than our baseline the true lower bound could be, and how the qualitative texture of the unexploited MEV could affect the blockchain’s environment. ## MEV today The defining feature of Ethereum’s current era is that most miners are not attempting to exploit MEV themselves (yet). Nearly all of the current activity is driven by non-mining traders. However, *some MEV can only be captured by miners,* because they have the authority to arbitrarily order (or exclude) transactions. Non-mining traders can access a strictly smaller subset of “simple” MEV; “complex” preferences cannot be efficiently expressed through PGA’s. This means that we see almost entirely PGA-style MEV being realized. Uniswap arbitrage, like our earlier example, is one the most common flavors of MEV in practice. Another type of MEV seen often in practice is theft from vulnerable smart contracts. One example is described in the “Dark Forest” post by Dan and co. They found a smart contract with a vulnerability that would allow anyone to steal the funds inside; Dan planned to recover the funds by exploiting it before a thief could. However, an arbitrage bot automatically recognized and copied their transaction, replacing their address with its own, and bid a higher transaction fee. The bot’s transaction executed before theirs and made off with the funds. ## MEV tomorrow *The next era of MEV will come when Ethereum miners begin actively exploiting MEV.* However, until recently, there was a common hypothesis that miners are altruistic enough to forgo MEV revenue and continue running default node software. Bitcoin miners have empirically chosen not to run [selfish mining strategies](https://www.cs.cornell.edu/~ie53/publications/btcProcFC.pdf), so there is some precedent. We think this miner-altruism hypothesis has been proven definitively false in the last 3 months. A small but meaningful portion of the hashrate has been observed [exploiting MEV themselves](https://oko.palkeo.com/11708078/), [revenue-sharing with traders rather than allowing permissionless fee auctions](https://twitter.com/bantg/status/1349470728320659456?s=20), and [selling access to private memory pools](https://www.rekt.news/return-to-the-dark-forest/). Rather, we believe that MEV is now overcoming miners’ threshold activation energy. Feverish non-mining trader activity highlights opportunities that miners can capture more efficiently and profitably. Additionally, the types of MEV that non-mining traders *can’t* access are a pot of totally untouched miner revenue; that pot may be far larger than the MEV realized to date. At some level, it is more surprising that it took miners this long to become involved. The dam has probably burst: *miners will venture further into the frontier, exploring more exotic forms of MEV and collusion. Significant risk could be posed to Ethereum and its users.* The rest of this post will explore what this future could look like in more detail, starting with what we mean when referring to MEV’s potential “risks.” ## MEV can harm users MEV is an invisible tax that miners can collect from users. In our earlier Uniswap example, a large trade caused price slippage, creating a $10,000 profit opportunity (MEV). The bot which arbitrages the market back to parity with the true price is making the Uniswap market more efficient without harming the original trader in the process. This is an example of a *benign MEV transaction.* However, in a different version of the same trade, an arbitrage bot would recognize the user’s trade *before* it’s executed and “sandwich” their transaction between a buy and sell order of its own. The net effect is that *MEV levies an invisible tax on the user:* their order is manipulated into executing at an artificially inflated price, which the bot then sells into for an instant profit. Of course, a miner could do this at no cost to themselves. This is what one might call a *malignant MEV transaction.* ## MEV can harm Ethereum MEV inherently encourages consensus instability. Imagine there are two miners, Sam and Dan, who are paid a $100 reward for each block they find. Sam has found 3 blocks, the first of which contained our $10,000 Uniswap arbitrage. Now, Dan has a choice: he can either mine on top of Sam’s 3 blocks, or he can attempt to re-mine the first block in order to take the Uniswap arbitrage for himself. The $10,000 is much more lucrative than the $100 block reward, and Dan is more rational than honest, so he decides to re-mine the first block. While Dan’s at it, since the current longest chain is height 3, he also re-mines the second and third blocks (and captures any MEV that was in those, too). After the re-org, Dan owns the longest chain and he and Sam can progress from the third block. This is known as a “time-bandit” attack: *if block rewards are small enough compared to MEV, it can be rational for miners to destabilize consensus.* Our example was a two-party system. In the real multiplayer world, it is possible that every rational miner would attempt to re-org the third block and essentially halt progress. However, this could destroy the value of the miners’ hashrate investments. If we see this behavior at all, it will more likely be in the form of shorter, more frequent re-orgs that do not halt progress entirely. ## Is MEV unique to Ethereum? No, hypothetically MEV can also be seen on Bitcoin. The incentives to censor Lightning channels or to double-spend colored coins are technically MEV. However, our hypothesis is that Bitcoin is inherently less exposed to MEV than blockchains like Etheruem. *The reason for that lies in the complexity and “statefulness” of the respective blockchain:* 1. The rate at which MEV accumulates on a given blockchain is generally proportional to the complexity of its application-layer behavior. 2. Arbitrarily flexible protocols, such as Ethereum, cannot bound this complexity and are inherently biased towards greater complexity over time. 3. MEV incentives cannot be easily mitigated without altering Ethereum’s UX. This is why we say that *Ethereum’s complexity may be a curse.* ## MEV follows complexity In some purely theoretical sense, even Bitcoin cannot bound its potential MEV exposure. However, Bitcoin’s design discourages unintended high-MEV use cases well enough that, in practice, they are rarely seen. This doesn’t seem likely to change going forward, so we don’t expect that MEV will become a bigger problem for Bitcoin (the inflation is a separate discussion). In contrast, we can observe that the MEV surface on Ethereum is growing exponentially, mainly as a result of the large flows of value through DeFi applications. *The financial primitives which seem so promising could alternatively be viewed as parasitic to Ethereum: spinning a boundless web of MEV which grows larger and more complex by the day.* ## Ethereum can’t bound complexity If the Lightning Network created untenable MEV on Bitcoin – realistically threatening Bitcoin’s consensus stability – we could remove the opcodes needed to create payment channels from Bitcoin’s limited ruleset (Script) in a relatively straightforward way. On the other hand, if we discovered that some application patterns (e.g. DEX’s, lending, tokenized custodial assets, etc.) posed similar risks to Ethereum, it would be impossible to preclude all possible implementations of those behaviors at the level of the EVM. Individual implementations could be forked off, but we could not prevent the general behavior without permissioning contract deployment or severely constraining the EVM. In either case, Ethereum would no longer enable “permissionless smart contracts.” ## MEV is hard to fix Finally, it is natural to ask if Ethereum could build a mechanism to counteract MEV into the protocol. In short, no, at least without altering Ethereum’s developer and/or user experience. *Any attempt to prevent miners from accessing the revenue stream is liable to incentivize the creation of off-protocol markets.* For example, if all transactions were only allowed to pay a flat rate, we would expect miners to collude with traders to accept payment for transaction priority out-of-band. Similarly, if all transaction fees were burned or paid to a communal pot, miners would simply accept fees separately. This is why we say that MEV cannot be *easily* counteracted. Potential mitigations exist, but they require structural changes to the way Ethereum applications are architected and users interact with them. ## In conclusion If Bitcoin’s incentive security fails, at least before block rewards go to ~zero, it’s difficult to imagine that any permissionless blockchain will not suffer a similar fate. Bitcoin’s simplicity is not only aesthetically elegant but also minimizes its extra-protocol incentive surface. We are more concerned about Ethereum. Ethereum’s application-layer complexity and MEV are continuing to grow exponentially. The known lower-bound on MEV revenues could be larger than the value of ETH miner security incentives within the year. *Large-scale, efficient MEV extraction may make the “tax” on Ethereum users untenable. Ethereum could become congested and more costly for all applications. The platform UX would be impaired, and that could stall Ethereum’s network effects and momentum.* Of course, the main unknown is whether Ethereum miners will begin maximally exploiting MEV at scale. Miners can access a superset of the MEV available to non-mining traders, and can extract all of it with maximum efficiency, so the cost and UX issues could be disastrous. There is also the possibility of time-bandits, although it feels unlikely that miners would damage their long-term interest in Ethereum with major re-orgs. A lite version, in which miners intentionally uncle or re-org only small handfuls of lucrative blocks, could still be harmful. In any case, it’s time to seriously consider what measures we can take if the situation deteriorates. ## Mitigating MEV An ideal solution would simply reduce the MEV on Ethereum, or increase the miner security incentive without additional inflation. Within the Ethereum paradigm, where permissionless applications share in platform security uniformly, our options are limited: 1. Better Application Design: every application can design itself to minimize the amount of MEV it creates. This may be a competitive differentiator, as users will get lower costs and better UX. However, the protocol cannot force applications to do this, and there is a limit to how much MEV can be avoided. 2. Additional Security Incentives: stable miner revenue streams other than the block reward (such as EIP-1559’s burned BASEFEEs, or state rents) are additive to protocol security and could help offset MEV. Otherwise, most research is focused on ways to make destabilizing consensus (time-bandit attacks) more difficult or more costly, rather than avoiding the root MEV: 1. Separating Inclusion and Ordering: miners (or validators) could only be responsible for transaction *inclusion*, and the right to decide the transaction *ordering* could be auctioned off separately. In theory, this would quarantine the re-org incentive. However, this guarantees that users will always endure the level of MEV extraction admitted by the auction, which may be equivalent to a multi-block time-bandit attack. 2. Finality: Nakamoto Proof-of-Work has only probabilistic finality. BFT-based algorithms have strong finality guarantees, and time-bandit attacks are more difficult because greater collusion is required to re-org even a single finalized block. However, with enough MEV the incentive to re-org could still overcome the difficulty of collusion. Additionally, participants still have the authority to arbitrarily order transactions in blocks for which they are the proposer, so finality alone cannot help with “normal” front-running. 3. Proof-of-Stake: PoS-based blockchains can slash validators who attempt to re-org and thus make time-bandits significantly more costly, especially when combined with strong finality. However, with enough MEV the incentive to re-org could still be greater than the slashing penalty. All of these approaches have serious implications for Ethereum’s ecosystem. Many involve changes to the core protocol and could take years to implement. Those that could be done only at the application-layer still likely require that developers re-architect and migrate most of the ecosystem to other environments. Hopefully, the next year will bring more clarity on MEV and Ethereum’s path forward. A number of Paradigm’s portfolio companies are working on MEV mitigations and related problems. If this is of interest to you, don’t be a stranger. ## Rollup Rollups have emerged as the dominant L2 scaling solution for Ethereum. There are a few different flavors, but generally rollups allow an aggregator to execute applications off-chain, publishing only the bare minimum information needed to show fraud (or the lack thereof) to Ethereum. This allows low latency and high throughput without giving up security guarantees of the base-layer chain. In addition to their promise as a scaling solution, rollups can also enable the separation of transaction ordering and execution (see Optimism’s “[MEV Auction](https://ethresear.ch/t/mev-auction-auctioning-transaction-ordering-rights-as-a-solution-to-miner-extractable-value/6788)” proposal). Vitalik Buterin has more recently suggested that Ethereum could become primarily a data-availability layer for rollups which handle all transaction execution, [centralizing MEV capture into rollup sequencers](https://medium.com/@VitalikButerin/i-feel-like-this-post-is-addressing-an-argument-that-isnt-the-actual-argument-that-mev-auction-b3c5e8fc1021) (“ETH 1.5”). This would be a significant departure from Ethereum’s current design and come with tradeoffs. For example, cross-rollup and rollup-mainchain interoperability breaks synchrony, and may require different assumptions to be done practically (especially in a many-rollup world). Our portfolio companies are working on two different rollup flavors: ### Starkware [StarkWare](https://starkware.co/) is working on [ZK-Rollup](https://medium.com/starkware/on-the-road-to-starknet-a-permissionless-stark-powered-l2-zk-rollup-83be53640880) (ZKRU), which *proactively* includes efficiently verifiable correctness proofs with block, rather than *optimistically* assuming validity and ensuring that fraud proofs are available if there is a challenge. Although not the original flavor of rollup imagined for the separation of execution and ordering, ZKRU can achieve this. The proof engine could also be used to enforce additional constraints on the ordering. For example, if VDF-based priority or other deterministic ordering mechanisms become available. ### Optimism [Optimism](https://optimism.io/) is working on the other leading flavor, Optimistic Rollup (ORU), which publishes the minimum data necessary to check fraud but *optimistically* assumes correctness until challenged. This results in a relatively long finality window but allows their rollup to use essentially the same execution environment as the L1’s EVM (so existing contracts can move ~seamlessly). Optimism were the original proposers of MEVA and ETH1.5 more generally. ### Flashbots [Flashbots](https://github.com/flashbots/pm) is a research and development organization formed to mitigate the negative externalities and existential risks posed by MEV, starting with Ethereum. They have built out tooling to quantify MEV and eliminate the information asymmetry in the ecosystem. They are now implementing a proof of concept for permissionless MEV extraction called MEV-Geth, a sealed-bid block space auction mechanism for communicating transaction order preference. Flashbots’ goal is to make sure MEV incentives do not become opaque and undemocratic. Hopefully, their infrastructure will allow application developers to better understand how to minimize their MEV exposure, and let some pressure off that could otherwise accumulate into really harmful externalities (e.g., a time-bandit attack). ### Cosmos [Cosmos](https://cosmos.network/intro) is an alternative model for permissionless, interoperable applications. Although not directly related to MEV on Ethereum, Cosmos is an architecture which could realistically enable an application ecosystem of similar complexity without adopting Ethereum’s uniform-security paradigm. It is imagined that Cosmos blockchains will be largely application-specific, and not share security with one another by default, which may allow them to avoid externalities that would be harmful on a shared platform. If Ethereum goes strongly in the direction of ETH1.5, it will look very similar to Cosmos (in fact, [LazyLedger](https://twitter.com/lazyledger_org?lang=en) is basically Cosmos’ ETH1.5). *Acknowledgments: Deep thanks to my colleagues Arjun Balaji, Dan Robinson, Georgios Konstantopoulos, and Matt Huang, as well as Hasu, for discussion and feedback which helped inform this post.* ## https://www.paradigm.xyz/writing/how-does-optimism-s-rollup-really-work # How does Optimism's Rollup really work? > This article is for everyone who is familiar with Optimistic Rollup as a mechanism and wants to learn how Optimism’s solution works, and evaluate the proposed system’s performance and security. We explain the motivation behind each design decision and then proceed to dissect Optimism’s system, along with links to the corresponding code for each analyzed component. At Paradigm, we work very closely with the companies in our portfolio. That work includes diving deep with them in their protocol design and implementation. We recently talked about the mechanics of Optimistic Rollup (OR), the dominant solution for scaling Ethereum while preserving its flourishing developer ecosystem. In this post, we do a deep dive on Optimism, the company which invented the first EVM-compatible Optimistic Rollup protocol *(Disclosure: Paradigm is an investor in Optimism)*. This article is for everyone who is familiar with Optimistic Rollup as a mechanism and wants to learn how Optimism’s solution works, and evaluate the proposed system’s performance and security. We explain the motivation behind each design decision and then proceed to dissect Optimism’s system, along with links to the corresponding code for each analyzed component. ## The importance of software reuse in Optimism Ethereum has developed a moat around its developer ecosystem. The developer stack is comprised of: - [Solidity](https://docs.soliditylang.org/en/v0.8.0/) / [Vyper](https://vyper.readthedocs.io/en/stable/): The 2 main smart contract programming languages which have large toolchains (e.g. [Ethers](https://github.com/ethers-io/ethers.js/), [Hardhat](https://github.com/nomiclabs/hardhat), [dapp](http://dapp.tools/), [slither](https://github.com/crytic/slither)) built around them. - Ethereum Virtual Machine: The most popular blockchain virtual machine to date, the internals of which are understood much better than any alternative blockchain VM. - [Go-ethereum](https://github.com/ethereum/go-ethereum): The dominant Ethereum protocol implementation which makes up for >75% of the network’s nodes. It is extensively tested, fuzzed (even finding bugs in [golang itself](https://github.com/golang/go/issues/42553)!) and as many would call it: “[lindy](https://en.wikipedia.org/wiki/Lindy_effect)”. Since Optimism is targeting Ethereum as its Layer 1, it would be nice if we could reuse all of the existing tooling, with little/no modifications necessary. This would improve developer experience as devs wouldn’t need to learn a new technology stack. The above DevEx argument has been laid out multiple times, but I’d like to emphasize another implication of software reuse: security. Blockchain security is critical. You cannot afford to get things wrong when you are handling other people’s money. By performing “surgery” on the existing tooling, instead of re-inventing the wheel, we can preserve most of the security properties the software had before our intervention. Auditing then becomes a simple matter of inspecting the difference from the original, instead of re-inspecting a codebase that’s potentially 100k+ lines of code. As a result, Optimism has created “optimistic” variants of each piece of the stack. We will now go through them one by one: ## The Optimistic Virtual Machine Optimistic Rollups rely on using fraud proofs to prevent invalid state transitions from happening. This requires executing an Optimism transaction on Ethereum. In simple terms, if there was a dispute about the result of a transaction that e.g. modified Alice’s ETH balance, Alice would try to replay that exact transaction on Ethereum to demonstrate the correct result there [^1]. However, certain EVM opcodes would not behave the same on L1 and L2 if they rely on system-wide parameters which change all the time such as loading or storing state or getting the current timestamp. As a result, the first step towards resolving a dispute about L2 on L1 is a mechanism that guarantees that it’s possible to reproduce any “context” that existed at the time the L2 transaction was executed on L1 (ideally without too much overhead). Goal: A sandboxed environment that guarantees deterministic smart contract execution between L1 and L2. Optimism’s solution is the [Optimistic Virtual Machine](https://medium.com/ethereum-optimism/ovm-deep-dive-a300d1085f52). The OVM is implemented by replacing context-dependent EVM opcodes with their OVM counterparts. A simple example would be: - A L2 transaction calls the `TIMESTAMP` opcode, returning e.g. 1610889676 - An hour later, the transaction (for any reason) has to be replayed on Ethereum L1 during a dispute - If that transaction were to be executed normally in the EVM, the `TIMESTAMP` opcode would return 1610889676 + 3600. We don’t want that! - In the OVM, the `TIMESTAMP` opcode is replaced with `ovmTIMESTAMP` which would show the correct value, at the time the transaction was executed on L2 All context-dependent EVM opcodes have an `ovm{OPCODE}` counterpart in the core OVM smart contract, the [`ExecutionManager`](https://github.com/ethereum-optimism/contracts-v2/blob/2b99de2f63ba57bb28a038d2832105fceef9edee/contracts/optimistic-ethereum/OVM/execution/OVM_ExecutionManager.sol#L197-L754). Contract execution starts via the EM’s main entry point, the [`run`](https://github.com/ethereum-optimism/contracts-v2/blob/2b99de2f63ba57bb28a038d2832105fceef9edee/contracts/optimistic-ethereum/OVM/execution/OVM_ExecutionManager.sol#L135-L140)[ function](https://github.com/ethereum-optimism/contracts-v2/blob/2b99de2f63ba57bb28a038d2832105fceef9edee/contracts/optimistic-ethereum/OVM/execution/OVM_ExecutionManager.sol#L135-L140). These opcodes are also modified to have a pluggable [state database](https://github.com/ethereum-optimism/contracts-v2/blob/2b99de2f63ba57bb28a038d2832105fceef9edee/contracts/optimistic-ethereum/OVM/execution/OVM_ExecutionManager.sol#L148-L150) to interact with, for reasons we’ll dive into in the Fraud Proofs section. Certain opcodes which do not “make sense” in the OVM are disallowed via Optimism’s [`SafetyChecker`](https://github.com/ethereum-optimism/contracts-v2/blob/2b99de2f63ba57bb28a038d2832105fceef9edee/contracts/optimistic-ethereum/OVM/execution/OVM_SafetyChecker.sol#L20-L27), a smart contract that effectively acts as a static analyzer returning 1 or 0, depending on if the contract is “OVM-safe”. We refer you to the appendix for a complete explanation of each modified/banned opcode. Optimism’s Rollup looks like this: ![Figure 1: The Optimistic Virtual Machine](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--b6a7887bf8/875d0b5bce2cbead57cc39182392d8f1/asset-https-cdn-sanity-io-images-dgybcd83--b6a7887bf8.png) *Figure 1: The Optimistic Virtual Machine* The area marked with a question mark will be covered in the Fraud Proofs section, but before that, we must cover some additional ground. ## Optimistic solidity Now that we have our sandbox, the OVM, we need to make our smart contracts compile to OVM bytecode. Here are some of our options: - Create a new smart contract language that compiles down to OVM: A new smart contract language is an easy to dismiss idea since it requires re-doing everything from scratch, and we’ve already agreed we don’t do that here. - Transpile EVM bytecode to OVM bytecode: was [tried](https://github.com/ethereum-optimism/optimism-monorepo/blob/2ca62fb41be6ef69b0c07a1bd5502ac425aaf341/packages/solc-transpiler/src/compiler.ts#L420-L496) but abandoned due to complexity. - Support Solidity and Vyper by modifying their compilers to produce OVM bytecode. The currently used approach is the 3rd. Optimism forked solc and [changed ~500 lines](https://github.com/ethereum-optimism/solidity/compare/27d51765c0623c9f6aef7c00214e9fe705c331b1...develop-0.6) (with [a little help](https://twitter.com/jinglanW/status/1310718738417811459)). The Solidity compiler works by converting the Solidity to Yul then into EVM Instructions and finally into bytecode. The change made by Optimism is simple yet elegant: For each opcode, after compiling to EVM assembly, try to “rewrite” it in its ovm variant if needed (or throw an error if it’s banned). This is a bit contrived to explain, so let’s use an example by comparing the EVM and OVM bytecodes of this simple contract: ```solidity pragma solidity ^0.6.12; contract C { uint x; function foo() public { x += 1; } } ``` ```solidity $ solc C.sol --bin-runtime --optimize --optimize-runs 200 6080604052348015600f57600080fd5b506004361060285760003560e01c8063c298557814602d575b600080fd5b60336035565b005b60008054600101905556fea264697066735822122001fa42ea2b3ac80487c9556a210c5bbbbc1b849ea597dd6c99fafbc988e2a9a164736f6c634300060c0033 ``` We can [disassemble](https://github.com/daejunpark/evm-disassembler) this code and dive into the opcodes [^2] to see what’s going on (Program Counter in brackets): ```solidity ... [025] 35 CALLDATALOAD ... [030] 63 PUSH4 0xc2985578 // id("foo()") [035] 14 EQ [036] 60 PUSH1 0x2d // int: 45 [038] 57 JUMPI // jump to PC 45 ... [045] 60 PUSH1 0x33 [047] 60 PUSH1 0x35 // int: 53 [049] 56 JUMP // jump to PC 53 ... [053] 60 PUSH1 0x00 [055] 80 DUP1 [056] 54 SLOAD // load the 0th storage slot [057] 60 PUSH1 0x01 [059] 01 ADD // add 1 to it [060] 90 SWAP1 [061] 55 SSTORE // store it back [062] 56 JUMP ``` What this assembly says is that if there’s a match between the calldata and the function selector of `foo()` [^3], then `SLOAD` the storage variable at `0x00`, add `0x01` to it and `SSTORE` it back. Sounds about right! How does this look in OVM [^4]? ```solidity $ osolc C.sol --bin-runtime --optimize --optimize-runs 200 60806040523480156100195760008061001661006e565b50505b50600436106100345760003560e01c8063c298557814610042575b60008061003f61006e565b50505b61004a61004c565b005b6001600080828261005b6100d9565b019250508190610069610134565b505050565b632a2a7adb598160e01b8152600481016020815285602082015260005b868110156100a657808601518282016040015260200161008b565b506020828760640184336000905af158601d01573d60011458600c01573d6000803e3d621234565260ea61109c52505050565b6303daa959598160e01b8152836004820152602081602483336000905af158601d01573d60011458600c01573d6000803e3d621234565260ea61109c528051935060005b60408110156100695760008282015260200161011d565b6322bd64c0598160e01b8152836004820152846024820152600081604483336000905af158601d01573d60011458600c01573d6000803e3d621234565260ea61109c5260008152602061011d56 ``` This is much bigger, let’s disassemble it again and see what changed: ```solidity ... [036] 35 CALLDATALOAD ... [041] 63 PUSH4 0xc2985578 // id("foo()") [046] 14 EQ [047] 61 PUSH2 0x0042 [050] 57 JUMPI // jump to PC 66 ... [066] 61 PUSH2 0x004a [069] 61 PUSH2 0x004c // int: 76 [072] 56 JUMP // jump to PC 76 ``` Matching the function selector is the same as before, let’s look at what happens afterward: There’s a lot going on here. The gist of it however is that instead of doing an `SLOAD`, the bytecode builds up the stack to make a `CALL`. The receiver of the call is pushed to the stack via the `CALLER` opcode. Every call comes from the EM, so in practice, `CALLER` is an efficient way to call the EM. The data of the call starts with the selector for `ovmSLOAD(bytes32)`, followed by its arguments (in this case, just a 32 bytes word). After that, the returned data is handled and added into memory. Moving on: ```solidity ... [297] 82 DUP3 [298] 01 ADD // Adds the 3rd item on the stack to the ovmSLOAD value [299] 52 MSTORE [308] 63 PUSH4 0x22bd64c0 // <---| id("ovmSSTORE(bytes32,bytes32)") [313] 59 MSIZE // | [314] 81 DUP2 // | [315] 60 PUSH1 0xe0 // | [317] 1b SHL // | [318] 81 DUP2 // | [319] 52 MSTORE // | [320] 83 DUP4 // | [321] 60 PUSH1 0x04 // | [323] 82 DUP3 // | [324] 01 ADD // | CALL to the CALLER's ovmSSTORE [325] 52 MSTORE // | (RETURNDATA handling is omited [326] 84 DUP5 // | because it is identical to ovmSSLOAD) [327] 60 PUSH1 0x24 // | [329] 82 DUP3 // | [330] 01 ADD // | [331] 52 MSTORE // | [332] 60 PUSH1 0x00 // | [334] 81 DUP2 // | [335] 60 PUSH1 0x44 // | [337] 83 DUP4 // | [338] 33 CALLER // | [339] 60 PUSH1 0x00 // | [341] 90 SWAP1 // | [342] 5a GAS // | [343] f1 CALL // <---| ... ``` Similarly to how `SLOAD` was rewired to an external call to `ovmSLOAD`, `SSTORE` is rewired to make an external call to `ovmSSTORE`. The call’s data is different because `ovmSSTORE` requires 2 arguments, the storage slot and the value being stored. Here’s a side by side comparison: ```solidity ovmSLOAD [217] 63 PUSH4 0x03daa959 [222] 59 MSIZE [223] 81 DUP2 [224] 60 PUSH1 0xe0 [226] 1b SHL [227] 81 DUP2 [228] 52 MSTORE [229] 83 DUP4 [230] 60 PUSH1 0x04 [232] 82 DUP3 [233] 01 ADD [234] 52 MSTORE [235] 60 PUSH1 0x20 [237] 81 DUP2 [238] 60 PUSH1 0x24 [240] 83 DUP4 [241] 33 CALLER [242] 60 PUSH1 0x00 [244] 90 SWAP1 [245] 5a GAS [246] f1 CALL ``` ```solidity ovmSSTORE [308] 63 PUSH4 0x22bd64c0 [313] 59 MSIZE [314] 81 DUP [315] 60 PUSH1 0xe0 [317] 1b SHL [318] 81 DUP2 [319] 52 MSTORE [320] 83 DUP4 [321] 60 PUSH1 0x04 [323] 82 DUP3 [324] 01 ADD [325] 52 MSTORE [326] 84 DUP5 [327] 60 PUSH1 0x24 [329] 82 DUP3 [330] 01 ADD [331] 52 MSTORE [332] 60 PUSH1 0x00 [334] 81 DUP2 [335] 60 PUSH1 0x44 [337] 83 DUP4 [338] 33 CALLER [339] 60 PUSH1 0x00 [341] 90 SWAP1 [342] 5a GAS [343] f1 CALL ``` Effectively, instead of making an `SLOAD` and then a `SSTORE`, we’re making a call to the Execution Manager’s `ovmSLOAD` and then its `ovmSSTORE` methods. Comparing the EVM vs OVM execution (we only show the `SLOAD` part of the execution), we can see the virtualization happening via the Execution Manager. This functionality is implemented [here](https://github.com/ethereum-optimism/solidity/blob/416121951c95b2af1120f39a0c89fe1479deeca4/libyul/backends/evm/EVMDialect.cpp#L117-L150) and [here](https://github.com/ethereum-optimism/solidity/blob/df005f39493525b43f1153dff8da5910a2b83e34/libsolidity/codegen/CompilerContext.cpp#L64-L367). ![EVM](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--67e1ffcd47/a0d283c3a11c40f6b9fc38d13a03e5a0/asset-https-cdn-sanity-io-images-dgybcd83--67e1ffcd47.png) *EVM* ![OVM](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--73218dd7d3/a591a6c608d0181465ae627e12d2bb44/asset-https-cdn-sanity-io-images-dgybcd83--73218dd7d3.png) *OVM* There’s a “gotcha” of this virtualization technique: The contract size limit gets hit faster: Normally, Ethereum contracts can be up to 24KB in bytecode size [^5]. A contract compiled with the Optimistic Solidity Compiler ends up bigger than it was, meaning that contracts near the 24KB limit must be refactored so that their OVM size still fits in the 24KB limit since they need to be executable on Ethereum mainnet (e.g. by making external calls to libraries instead of inlining the library bytecode.) The contract size limit remains the same as OVM contracts must be deployable on Ethereum. ## Optimistic Geth The most popular implementation of Ethereum is go-ethereum (aka geth). Let’s see how a transaction typically gets executed in go-ethereum. On each [block](https://github.com/ethereum/go-ethereum/blob/7770e41cb5fcc386a7d2329d1187174839122f24/core/blockchain.go#L1889), the state processor’s [`Process`](https://github.com/ethereum/go-ethereum/blob/7770e41cb5fcc386a7d2329d1187174839122f24/core/state_processor.go#L58) is called which calls [`ApplyTransaction`](https://github.com/ethereum/go-ethereum/blob/6487c002f6b47e08cb9814f16712c6789b313a97/core/state_processor.go#L88) on each transaction. Internally, transactions are converted to [messages](https://github.com/ethereum/go-ethereum/blob/6487c002f6b47e08cb9814f16712c6789b313a97/core/types/transaction.go#L227-L246) [^6], messages get applied on the current state, and the newly produced state is finally stored back in the database. This core data flow remains the same on Optimistic Geth, with some modifications to make transactions “OVM friendly”: Modification 1: OVM Messages via the Sequencer Entrypoint Transactions get converted to [OVM Messages](https://github.com/ethereum-optimism/go-ethereum/blob/f8b6a248713a2636a491d1727dc4d62c2c8bfa49/core/state_processor.go#L93-L97). Since messages are stripped of their signature, [the message data is modded](https://github.com/ethereum-optimism/go-ethereum/blob/e3c17388429335dfe5d6af1993e624c16c5df881/core/state_transition_ovm.go#L68-L118) to include the transaction signature (along with the rest of the original transaction’s fields). The `to` field gets replaced with the “[sequencer entrypoint](https://github.com/ethereum-optimism/contracts-v2/blob/c1851bac8114e1e600a98d143b977c5a026ba20e/contracts/optimistic-ethereum/OVM/precompiles/OVM_SequencerEntrypoint.sol#L28-L87)” contract’s address. This is done in order to have a compact transaction format, since it will be published to Ethereum, and we’ve established that the better our compression, the better our scaling benefits. Modification 2: OVM sandboxing via the Execution Manager In order to run transactions through the OVM sandbox, they _must _be sent to the Execution Manager’s `run` function. Instead of requiring that users submit only transactions which match that restriction, all messages are [modded](https://github.com/ethereum-optimism/go-ethereum/blob/e3c17388429335dfe5d6af1993e624c16c5df881/core/state_transition.go#L207-L214) to be sent to the Execution Manager internally. What happens here is simple: The message’s `to` field is replaced by the Execution Manager’s address, and the message’s original data is [packed as arguments to run](https://github.com/ethereum-optimism/go-ethereum/blob/e3c17388429335dfe5d6af1993e624c16c5df881/core/state_transition_ovm.go#L37-L54). As this might be a bit unintuitive, we’ve put together a repository to give a concrete example: [https://github.com/gakonst/optimism-tx-format](https://github.com/gakonst/optimism-tx-format). Modification 3: Intercept calls to the State Manager The StateManager is a special contract which..doesn’t exist on Optimistic Geth [^7]. It only gets deployed during fraud proofs. The careful reader will notice that when the arguments are packed to make the `run` call, Optimism’s geth also packs a hardcoded State Manager address. That’s what ends up getting used as the final destination of any `ovmSSTORE` or `ovmSLOAD` (or similar) calls. When running on L2, any messages targeting the State Manager contract get [intercepted](https://github.com/ethereum-optimism/go-ethereum/blob/f2e33654675e71b3eda4bd2ad2d07efb5aa65a42/core/vm/evm.go#L80-L88), and they are wired to [directly talk to Geth’s StateDB (or do nothing)](https://github.com/ethereum-optimism/go-ethereum/blob/f2e33654675e71b3eda4bd2ad2d07efb5aa65a42/core/vm/ovm_state_manager.go). To people looking for overall code changes, the best way to do this is by searching for [*UsingOVM*](https://github.com/ethereum-optimism/go-ethereum/search?q=UsingOVM) and by comparing the [diff from geth 1.9.10](https://github.com/ethereum-optimism/go-ethereum/compare/58cf5686eab9019cc01e202e846a6bbc70a3301d...master). Modification 4: Epoch-based batches instead of blocks The OVM does not have blocks, it just maintains an ordered list of transactions. Because of this, there is no notion of a block gas limit; instead, the overall gas consumption is rate limited based on time segments, called epochs [^8]. Before a transaction is executed, there’s a [check](https://github.com/ethereum-optimism/contracts-v2/blob/aad70cd7a85ddeb9fbeb90b51429864792aa9757/contracts/optimistic-ethereum/OVM/execution/OVM_ExecutionManager.sol#L158-L159) to see if a new epoch needs to be started, and after execution its gas consumption is [added](https://github.com/ethereum-optimism/contracts-v2/blob/aad70cd7a85ddeb9fbeb90b51429864792aa9757/contracts/optimistic-ethereum/OVM/execution/OVM_ExecutionManager.sol#L1596-L1623) on the cumulative gas used for that epoch. There is a separate gas limit per epoch for sequencer submitted transactions and “L1 to L2” transactions. Any transactions [exceeding the gas limit](https://github.com/ethereum-optimism/contracts-v2/blob/aad70cd7a85ddeb9fbeb90b51429864792aa9757/contracts/optimistic-ethereum/OVM/execution/OVM_ExecutionManager.sol#L1552-L1594) for an epoch [return early.](https://github.com/ethereum-optimism/contracts-v2/blob/aad70cd7a85ddeb9fbeb90b51429864792aa9757/contracts/optimistic-ethereum/OVM/execution/OVM_ExecutionManager.sol#L161-L165) This implies that an operator can post several transactions with varying timestamps in one on-chain batch ([timestamps are defined by the sequencer](https://github.com/ethereum-optimism/go-ethereum/blob/42c15d285804ce4bd77309dfdb1842c860d5c0f1/miner/worker.go#L867-L879), with some restrictions which we explain in the “Data Availability Batches” section). Modification 5: Rollup Sync Service The [sync service](https://github.com/ethereum-optimism/go-ethereum/blob/master/rollup/sync_service.go) is a new process that runs [alongside](https://github.com/ethereum-optimism/go-ethereum/blob/c01384ba625fb1714cbfe6a1824ebc991f4c3b7d/eth/backend.go#L212-L215) “normal” geth operations. It is responsible for [monitoring](https://github.com/ethereum-optimism/go-ethereum/blob/master/rollup/sync_service.go#L647-L676) Ethereum logs, [processing](https://github.com/ethereum-optimism/go-ethereum/blob/master/rollup/sync_service.go#L999-L1022) them, and [injecting](https://github.com/ethereum-optimism/go-ethereum/blob/master/rollup/sync_service.go#L943) the corresponding L2 transactions to be applied in the L2 state via [geth’s worker](https://github.com/ethereum-optimism/go-ethereum/blob/42c15d285804ce4bd77309dfdb1842c860d5c0f1/miner/worker.go#L213). ## The Optimistic Rollup Optimism’s rollup is a rollup using: - The OVM as its runtime / state transition function - Optimistic Geth as the L2 client with a single sequencer - Solidity smart contracts deployed on Ethereum for: - data availability - dispute resolution and fraud proofs [^9]. In this section, we dive into the smart contracts which implement the data availability layer and explore the fraud proof flow end-to-end. ## Data Availability Batches As we saw before, transaction data is compressed and then sent to the Sequencer Entrypoint contract on L2. The sequencer then is responsible for “rolling up” these transactions in a “batch” and publishing the data on Ethereum, providing data availability so that even if the sequencer disappears, a new sequencer can be launched to continue from where things were left off. The smart contract that lives on Ethereum which implements that logic is called the [Canonical Transaction Chain](https://github.com/ethereum-optimism/contracts-v2/blob/3ce74d9f56b6e5df9af5485294da0e1e3c6db660/contracts/optimistic-ethereum/OVM/chain/OVM_CanonicalTransactionChain.sol#L22) (CTC). The Canonical Transaction Chain is an append-only log representing the “official history” (all transactions, and in what order) of the rollup chain. Transactions are submitted to the CTC either by the sequencer, a prioritized party who can insert transactions into the chain, or via a first-in-first-out queue which feeds into the CTC. To preserve L1’s censorship resistance guarantees, anybody can submit transactions to this queue, forcing them to be included into the CTC after a delay. The CTC provides data availability for L2 transactions published per batch. A batch can be created in 2 ways: - Every few seconds, the sequencer is expected to check for new transactions which they received, roll them up in a batch, along with any additional metadata required. They then publish that data on Ethereum via [`appendSequencerBatch`](https://github.com/ethereum-optimism/contracts-v2/blob/3ce74d9f56b6e5df9af5485294da0e1e3c6db660/contracts/optimistic-ethereum/OVM/chain/OVM_CanonicalTransactionChain.sol#L340). This is automatically done by the [batch submitter](https://github.com/ethereum-optimism/batch-submitter/) service. - When the sequencer censors its users (i.e. doesn’t include their submitted transactions in a batch) or when users want to make a transaction from L1 to L2, users are expected to call [`enqueue`](https://github.com/ethereum-optimism/contracts-v2/blob/3ce74d9f56b6e5df9af5485294da0e1e3c6db660/contracts/optimistic-ethereum/OVM/chain/OVM_CanonicalTransactionChain.sol#L213) and [`appendQueueBatch`](https://github.com/ethereum-optimism/contracts-v2/blob/3ce74d9f56b6e5df9af5485294da0e1e3c6db660/contracts/optimistic-ethereum/OVM/chain/OVM_CanonicalTransactionChain.sol#L290), which “force” include their transactions in the CTC. An edge case here is the following: If the sequencer has broadcast a batch, a user could force include a transaction which touches state that conflicts with the batch, potentially invalidating some of the batch’s transactions. In order to avoid that, [a time delay is introduced](https://github.com/ethereum-optimism/contracts-v2/blob/0ad4dcfdef11ef87e278a8159de8414c8e329ba1/contracts/optimistic-ethereum/OVM/chain/OVM_CanonicalTransactionChain.sol#L311-L314), after which batches can be appended to the queue by non-sequencer accounts. Another way to think about this, is that the sequencer is given a “grace period” to include transactions via `appendSequencerBatch`, else users will `appendQueueBatch`. Given that transactions are mostly expected to be submitted via the sequencer, it’s worth diving into the batch structure and the execution flow: You may notice that `appendSequencerBatch` takes no arguments. Batches are submitted in a tightly packed format, whereas using ABI encoding and decoding would be much less efficient. It uses inline assembly to slice the calldata and unpack it in the expected format. A batch is made up of: - Header - Batch contexts (>=1, *note: this context is not the same as the message/transaction/global context we mentioned in the OVM section above)* - Transactions (>=1) ![Figure 3: Compact batch format](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--5394cea4f0/115a9075517bbfe057b88aa88b5108d3/asset-https-cdn-sanity-io-images-dgybcd83--5394cea4f0.png) *Figure 3: Compact batch format* The batch’s header specifies the number of contexts, so a serialized batch would look like the concatenation of `[header, context1, context2, …, tx1, tx2, ... ]` The function proceeds to do [2 things](https://github.com/ethereum-optimism/contracts-v2/blob/0ad4dcfdef11ef87e278a8159de8414c8e329ba1/contracts/optimistic-ethereum/OVM/chain/OVM_CanonicalTransactionChain.sol#L399-L428): 1. Verify that all context-related invariants apply 2. Create a merkle tree out of the published transaction data If context verification passes, then the batch is converted to an [OVM Chain Batch Header](https://github.com/ethereum-optimism/contracts-v2/blob/0ad4dcfdef11ef87e278a8159de8414c8e329ba1/contracts/optimistic-ethereum/libraries/codec/Lib_OVMCodec.sol#L65-L71), which is then [stored](https://github.com/ethereum-optimism/contracts-v2/blob/0ad4dcfdef11ef87e278a8159de8414c8e329ba1/contracts/optimistic-ethereum/OVM/chain/OVM_CanonicalTransactionChain.sol#L759-L783) in the CTC. The stored header contains the batch’s merkle root, meaning that proving a transaction was included is a simple matter of providing a merkle proof that verifies against the stored merkle root in the CTC. A natural question here would be: This seems too complex! Why are contexts required? Contexts are necessary for a sequencer to know if an enqueued transaction should be executed before or after a sequenced transaction. Let’s see an example: At time T1, the sequencer has received 2 transactions which they will include in their batch. At T2 (>T1) a user also [enqueue](https://github.com/ethereum-optimism/contracts-v2/blob/3ce74d9f56b6e5df9af5485294da0e1e3c6db660/contracts/optimistic-ethereum/OVM/chain/OVM_CanonicalTransactionChain.sol#L213)’s a transaction, adding it to the [L1 to L2 transaction queue](https://github.com/ethereum-optimism/contracts-v2/blob/0ad4dcfdef11ef87e278a8159de8414c8e329ba1/contracts/optimistic-ethereum/OVM/chain/OVM_CanonicalTransactionChain.sol#L271-L284) (but not adding it to a batch!). At T2 the sequencer receives 1 more transaction and 2 more transactions are enqueued as well. In other words, the pending transactions’ batch looks something like: ```solidity [ (sequencer, T1), (sequencer, T1), (queue, T2), (sequencer, T2), (queue, T3), (queue, T4), ]; ``` In order to maintain timestamp (and block number) information while also keeping the serialization format compact, we use “contexts”, bundles of shared information between sequencer & queued transactions. Contexts must have strictly increasing block number and timestamp. Within a context, all sequencer transactions share the same block number and timestamp. For “queue transactions”, the timestamp and block number [are set to whatever they were at the time of the enqueue call](https://github.com/ethereum-optimism/go-ethereum/blob/af6480b2e27d273b444f6912a3da20f8795eb9d8/rollup/sync_service.go#L1035-L1052). In this case, the contexts for that batch of transactions would be: ```solidity [ { numSequencedTransactions: 2, numSubsequentQueueTransactions: 1, timestamp: T1, }, { numSequencedTransactions: 1, numSubsequentQueueTransactions: 2, timestamp: T2, }, ]; ``` ## State Commitments In Ethereum, every transaction causes a modification to the state, and the global state root. Proving that an account owns some ETH at a certain block is done by providing the state root at the block and a merkle proof proving that the account’s state matches the claimed value. Since each block contains multiple transactions, and we only have access to the state root, that means we can only make claims about the state after the entire block has been executed. *A little history:* Prior to [EIP98](https://github.com/ethereum/EIPs/issues/98) and the Byzantium hard fork, Ethereum transactions produced intermediate [state roots after each execution](https://github.com/ethereum-optimism/go-ethereum/blob/f8b6a248713a2636a491d1727dc4d62c2c8bfa49/core/state_processor.go#L110-L116), which were provided to the user via the transaction receipt. The TL;DR is that removing this improves performance (with a small caveat), so it was quickly adopted. Additional motivation given in [EIP PR658](https://github.com/ethereum/EIPs/pull/658) settled it: The receipt’s `PostState` field indicating the state root corresponding to the post-tx execution state was [replaced](https://github.com/ethereum-optimism/go-ethereum/blob/f8b6a248713a2636a491d1727dc4d62c2c8bfa49/core/types/receipt.go#L82) with a boolean Status field, indicating the transaction’s success status. As it turns out, the caveat was not trivial. EIP98’s rationale section writes: *This change DOES mean that if a miner creates a block where one state transition is processed incorrectly, then it is impossible to make a fraud proof specific to that transaction; instead, the fraud proof must consist of the entire block.* The implication of this change, is that if a block has 1000 transactions and you have detected fraud at the 988th transaction, you’d need to run 987 transactions on top of the previous block’s state before actually executing the transaction you are interested in, and that would make a fraud proof obviously very inefficient. Ethereum doesn’t have fraud proofs natively, so that’s OK! Fraud proofs on Optimism on the other hand are critical. Earlier, we mentioned that Optimism does not have blocks. That was a small lie: Optimism has blocks, but each block has 1 transaction each, let’s call these “microblocks” [^10]. Since each microblock contains 1 transaction, each block’s state root is actually the state root produced by a single transaction. Hooray! We have re-introduced intermediate state roots without having to make any breaking change to the protocol. This of course currently has a constant size performance overhead since microblocks are still technically blocks and contain additional information that’s redundant, but this redundancy can be removed in the future (e.g. make all microblocks have 0x0 as a blockhash and only populate the pruned fields in RPC calls for backwards compatibility) We now can introduce the [State Commitment Chain](https://github.com/ethereum-optimism/contracts-v2/blob/0ad4dcfdef11ef87e278a8159de8414c8e329ba1/contracts/optimistic-ethereum/OVM/chain/OVM_StateCommitmentChain.sol) (SCC). The SCC contains a list of state roots, which, in the optimistic case, correspond to the result of applying each transaction in the CTC against the previous state. If this is not the case, then the fraud verification process allows the invalid state root, and all following it, to be deleted, so that the correct state root for those transactions may be proposed. Contrary to the CTC, the SCC does not have any fancy packed representation of its data. Its purpose is simple: Given a list of state roots, it [merklizes them and saves](https://github.com/ethereum-optimism/contracts-v2/blob/0ad4dcfdef11ef87e278a8159de8414c8e329ba1/contracts/optimistic-ethereum/OVM/chain/OVM_StateCommitmentChain.sol#L303-L353) the merkle root of the intermediate state roots included in a batch for later use in fraud proofs via [`appendStateBatch`](https://github.com/ethereum-optimism/contracts-v2/blob/0ad4dcfdef11ef87e278a8159de8414c8e329ba1/contracts/optimistic-ethereum/OVM/chain/OVM_StateCommitmentChain.sol#L119). ## Fraud Proofs Now that we understand the fundamental concepts of the OVM along with the supporting functionality for anchoring its state on Ethereum, let’s dive into dispute resolution, aka fraud proofs. The sequencer does 3 things: 1. Receives transactions from its users 2. Rolls up these transactions in a batch and publishes them in the Canonical Transaction Chain 3. Publishes the intermediate state roots produced by the transactions as a state batch in the State Commitment Chain. If, for example, 8 transactions were published in the CTC, there would be 8 state roots published in the SCC, for each state transition S1 to S8. ![Figure 4: The state roots for each state transition caused by a transaction get published to the State Commitment Chain. Transaction data gets published as batches in the Canonical Transaction Chain.](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--f4ea7f459b/96647411cad9ec54cf0614aedd92461d/asset-https-cdn-sanity-io-images-dgybcd83--f4ea7f459b.png) *Figure 4: The state roots for each state transition caused by a transaction get published to the State Commitment Chain. Transaction data gets published as batches in the Canonical Transaction Chain.* However, if the sequencer is malicious, they could set their account balance to 10 million ETH in the state trie, an obviously illegal operation, making the state root invalid, along with all state roots that follow it. They’d do that by publishing data that looks like: ![Figure 5: The sequencer publishes an invalid state root for T4. All state roots after it are also invalid, since a state root's validity requires that its ancestor is also valid.](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--3332831f10/78c812f4c06ca242442376a5b3bd1614/asset-https-cdn-sanity-io-images-dgybcd83--3332831f10.png) *Figure 5: The sequencer publishes an invalid state root for T4. All state roots after it are also invalid, since a state root’s validity requires that its ancestor is also valid.* Are we doomed? We have to do something! As we know, Optimistic Rollup assumes the existence of verifiers: For each transaction published by the sequencer, a verifier is responsible for downloading that transaction and applying it against their local state. If everything matches, they do nothing, but if there’s a mismatch there’s a problem! To resolve the problem, they’d try to re-execute T4 on Ethereum to produce S4. Then, any state root published after S4 would be pruned, since there’s no guarantee that it’d correspond to valid state: ![Figure 6: After a successful fraud proof, all invalid state roots are pruned. ](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--ac9bffc4e1/5ad89b4916a7bc7b8a2ed28edb85f979/asset-https-cdn-sanity-io-images-dgybcd83--ac9bffc4e1.png) *Figure 6: After a successful fraud proof, all invalid state roots are pruned.* From a high level, the fraud proof statement is “Using S3 as my starting state, I’d like to show that applying T4 on S3 results in S4 which is different from what the sequencer published (😈). As a result I’d like S4 and everything after it to be deleted.” How is that implemented? What you saw in Figure 1, was the OVM running in its “simple” execution mode, in L2. When running in L1 the OVM is in Fraud Proof Mode and a few more components of it get enabled (the Execution Manager and the Safety Checker are deployed on *both* L1 and L2): - Fraud Verifier: Contract which coordinates the entire fraud proof verification process. It calls to the [State Transitioner Factory](https://github.com/ethereum-optimism/contracts-v2/blob/0ad4dcfdef11ef87e278a8159de8414c8e329ba1/contracts/optimistic-ethereum/OVM/verification/OVM_StateTransitionerFactory.sol#L34-L57) to [initialize a new fraud proof](https://github.com/ethereum-optimism/contracts-v2/blob/0ad4dcfdef11ef87e278a8159de8414c8e329ba1/contracts/optimistic-ethereum/OVM/verification/OVM_FraudVerifier.sol#L127) and if the fraud proof was successful it [prunes](https://github.com/ethereum-optimism/contracts-v2/blob/0ad4dcfdef11ef87e278a8159de8414c8e329ba1/contracts/optimistic-ethereum/OVM/verification/OVM_FraudVerifier.sol#L198) any batches which were published after the dispute point from the State Commitment Chain. - State Transitioner: Gets deployed by the Fraud Verifier when a dispute is created with a pre-state root and the transaction being disputed. Its responsibility is to call out to the [Execution Manager](https://github.com/ethereum-optimism/contracts-v2/blob/0ad4dcfdef11ef87e278a8159de8414c8e329ba1/contracts/optimistic-ethereum/OVM/verification/OVM_StateTransitioner.sol#L343) [^11][and faithfully execute the transaction on-chain](https://github.com/ethereum-optimism/contracts-v2/blob/0ad4dcfdef11ef87e278a8159de8414c8e329ba1/contracts/optimistic-ethereum/OVM/verification/OVM_StateTransitioner.sol#L343) according to the rules, to produce the correct post-state root for the disputed transaction. A successfully executed fraud proof will result in a [state root mismatch between the post-state root in the state transitioner and the one in the State Commitment Chain](https://github.com/ethereum-optimism/contracts-v2/blob/0ad4dcfdef11ef87e278a8159de8414c8e329ba1/contracts/optimistic-ethereum/OVM/verification/OVM_FraudVerifier.sol#L192-L196). A state transitioner can be in any of the 3 following states: [`PRE EXECUTION, POST EXECUTION, COMPLETE`](https://github.com/ethereum-optimism/contracts-v2/blob/0ad4dcfdef11ef87e278a8159de8414c8e329ba1/contracts/optimistic-ethereum/OVM/verification/OVM_StateTransitioner.sol#L34-L38). - State Manager: Any data provided by the users gets stored [here](https://github.com/ethereum-optimism/contracts-v2/blob/0ad4dcfdef11ef87e278a8159de8414c8e329ba1/contracts/optimistic-ethereum/OVM/execution/OVM_StateManager.sol#L14). This is an “ephemeral” state manager which is [deployed only for the fraud proof](https://github.com/ethereum-optimism/contracts-v2/blob/0ad4dcfdef11ef87e278a8159de8414c8e329ba1/contracts/optimistic-ethereum/OVM/verification/OVM_StateTransitioner.sol#L90) and only contains information about the state that was touched by the disputed transaction. The OVM running in fraud proof mode looks like: ![Figure 7: The OVM in Fraud Proof mode](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--2daa96c6d6/9dd8a580bf4a3c8f6615ce00ee8c312f/asset-https-cdn-sanity-io-images-dgybcd83--2daa96c6d6.png) *Figure 7: The OVM in Fraud Proof mode* Fraud proofs are broken down in a few steps: ### Step 1: Declare which state transition you’re disputing 1. The user calls the Fraud Verifier’s [`initializeFraudVerification`](https://github.com/ethereum-optimism/contracts-v2/blob/0ad4dcfdef11ef87e278a8159de8414c8e329ba1/contracts/optimistic-ethereum/OVM/verification/OVM_FraudVerifier.sol#L81), providing the pre-state root (and proof of its inclusion in the State Commitment Chain) and the transaction being disputed (and proof of its inclusion in the Transaction chain). 2. A State Transitioner contract is deployed via the State Transitioner Factory. 3. A State Manager contract is deployed via the State Manager Factory. It will not contain the entire L2 state, but will be populated with only the parts required by the transaction; you can think of it as a “partial state manager”. The State Transitioner is now in the `PRE EXECUTION` phase. ![Figure 8: Initializing a fraud proof deploys a new State Transitioner and State Manager, unique to the state root and transaction being disputed. ](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--28101e0cdc/fa2f1d38bf6e9bff4e53e26fe867e950/asset-https-cdn-sanity-io-images-dgybcd83--28101e0cdc.png) *Figure 8: Initializing a fraud proof deploys a new State Transitioner and a State Manager, unique to the state root and transaction being disputed.* ### Step 2: Upload all the transaction pre-state If we try to directly execute the transaction being disputed, it will [immediately fail with an INVALID_STATE_ACCESS error](https://github.com/ethereum-optimism/contracts-v2/blob/master/contracts/optimistic-ethereum/OVM/execution/OVM_ExecutionManager.sol#L1335-L1340), since none of the L2 state that it touches has been loaded on the freshly-deployed L1 State Manager from Step 1. The OVM sandbox will detect if the SM has not been populated with some touched state, and enforce that all the touched state needs is loaded first. As an example, if a transaction being disputed was a simple ERC20 token transfer, the initial steps would be: 1. Deploy the ERC20 on L1 [^12]: The contract bytecode of the L2 and L1 contracts must match to have identical execution between L1 and L2. We [guarantee](https://github.com/ethereum-optimism/optimism-ts-services/blob/2654c5de7a5b8a2111fca0c313b58e436e141bd5/src/services/fraud-prover.service.ts#L625-L629) that with a “magic” prefix to the bytecode which copies it into memory and stores it at the specified address. 2. Call [`proveContractState`](https://github.com/ethereum-optimism/contracts-v2/blob/0ad4dcfdef11ef87e278a8159de8414c8e329ba1/contracts/optimistic-ethereum/OVM/verification/OVM_StateTransitioner.sol#L173-L237): This will link together the L2 OVM contract with the freshly deployed L1 OVM contract (the contract is deployed and linked, but still has no storage loaded). Linking [means](https://github.com/ethereum-optimism/contracts-v2/blob/master/contracts/optimistic-ethereum/OVM/verification/OVM_StateTransitioner.sol#L222-L231) that the OVM address is used as the key in a mapping where the value is a structure containing the contract’s account state. 3. Call [`proveStorageSlot`](https://github.com/ethereum-optimism/contracts-v2/blob/0ad4dcfdef11ef87e278a8159de8414c8e329ba1/contracts/optimistic-ethereum/OVM/verification/OVM_StateTransitioner.sol#L245-L300): Standard ERC20 transfers reduce the sender’s balance by an amount, and increase the receiver’s balance by the same amount, typically stored in a mapping. This will upload the balances of both the receiver and the sender before the transaction was executed. For an ERC20, balances are typically stored in a mapping, so the key would be the `keccak256(slot + address)`, as per Solidity’s [storage layout](https://docs.soliditylang.org/en/latest/internals/layout_in_storage.html#mappings-and-dynamic-arrays). ![Figure 9: During the proof pre-execution phase, all contract state that will get touched must be uploaded](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--1aeba7c5c5/e7e7d7b503d532e2f1150979acdb33b1/asset-https-cdn-sanity-io-images-dgybcd83--1aeba7c5c5.png) *Figure 9: During the fraud proof pre-execution phase, all contract state that will get touched must be uploaded* ### Step 3: Once all pre-state has been provided, run the transaction The user must then trigger the transaction’s execution by calling the State Transitioner’s [`applyTransaction`](https://github.com/ethereum-optimism/contracts-v2/blob/0ad4dcfdef11ef87e278a8159de8414c8e329ba1/contracts/optimistic-ethereum/OVM/verification/OVM_StateTransitioner.sol#L311-L346). In this step, the Execution Manager starts to execute the transaction using the fraud proof’s State Manager. After execution is done, the State Transitioner transitions to the `POST EXECUTION` phase. ![Figure 10: When the L2 transaction gets executed on L1, it uses the State Manager which was deployed for the fraud proof and contains all the uploaded state from the pre-execution phase.](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--7a735ad253/2d3fab3a79551e1e8f8e998eb5757ce3/asset-https-cdn-sanity-io-images-dgybcd83--7a735ad253.png) *Figure 10: When the L2 transaction gets executed on L1, it uses the State Manager which was deployed for the fraud proof and contains all the uploaded state from the pre-execution phase.* ### Step 4: Provide the post-state During execution on L1 (Step 3), the values in contract storage slots or account state (e.g. nonces) will change, which should cause a change in the State Transitioner’s post-state root. However, since the State Transitioner / State Manager pair do not know the entire L2 state, they cannot automatically calculate the new post-state root. In order to avoid that, if the value of a storage slot or an account’s state changes, the storage slot or account gets marked as [“changed”](https://github.com/ethereum-optimism/contracts-v2/blob/0ad4dcfdef11ef87e278a8159de8414c8e329ba1/contracts/optimistic-ethereum/OVM/execution/OVM_StateManager.sol#L549-L570), and a counter for uncommitted [storage slots](https://github.com/ethereum-optimism/contracts-v2/blob/master/contracts/optimistic-ethereum/OVM/execution/OVM_ExecutionManager.sol#L1384) or [accounts](https://github.com/ethereum-optimism/contracts-v2/blob/master/contracts/optimistic-ethereum/OVM/execution/OVM_ExecutionManager.sol#L1306) is incremented. We require that for every item that was changed, that the user also provides a merkle proof from the L2 state, indicating that this was indeed the value that was observed. Each time a storage slot change is “committed”, [the contract account’s storage root is updated](https://github.com/ethereum-optimism/contracts-v2/blob/0ad4dcfdef11ef87e278a8159de8414c8e329ba1/contracts/optimistic-ethereum/OVM/verification/OVM_StateTransitioner.sol#L418-L425). After all changed storage slots have been committed, the contract’s state is also committed, [updating the transitioner’s post-state root](https://github.com/ethereum-optimism/contracts-v2/blob/0ad4dcfdef11ef87e278a8159de8414c8e329ba1/contracts/optimistic-ethereum/OVM/verification/OVM_StateTransitioner.sol#L379-L386). The counter is correspondingly decremented for each piece of post-state data that gets published. It is thus expected that after the state changes for all contracts touched in the transaction have been committed, the resulting post-state root is the correct one. ![Figure 11: In the post execution phase, any state that was modified must be uploaded.](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--2d3cf0391e/632e928ff560f253a8bbf290059aa4fd/asset-https-cdn-sanity-io-images-dgybcd83--2d3cf0391e.png) *Figure 11: In the post execution phase, any state that was modified must be uploaded.* ### Step 5: Complete the state transition & finalize the fraud proof Completing the state transition is a simple matter of calling [`completeTransition`](https://github.com/ethereum-optimism/contracts-v2/blob/0ad4dcfdef11ef87e278a8159de8414c8e329ba1/contracts/optimistic-ethereum/OVM/verification/OVM_StateTransitioner.sol#L444), which requires that all accounts and storage slots from Step 4 have been committed (by checking that the counter for uncommitted state is equal to 0). Finally, [`finalizeFraudVerification`](https://github.com/ethereum-optimism/contracts-v2/blob/0ad4dcfdef11ef87e278a8159de8414c8e329ba1/contracts/optimistic-ethereum/OVM/verification/OVM_FraudVerifier.sol#L147) is called on the Fraud Verifier contract which checks if the state transitioner is complete and if yes, it calls [`deleteStateBatch`](https://github.com/ethereum-optimism/contracts-v2/blob/f6069a881fbf6c35687a1676a73c67596b3ef4f9/contracts/optimistic-ethereum/OVM/chain/OVM_StateCommitmentChain.sol#L86) which proceeds to delete all state root batches after (including) the disputed transaction from the SCC. The CTC remains unchanged, so that the original transactions are re-executed in the same order. ![Figure 12: Once the State Transitioner is complete, the fraud proof is finalized and the invalid state roots get removed from the state commitment chain.](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--e3e60d71b4/f76a727636aac188c7bf6710ef24e430/asset-https-cdn-sanity-io-images-dgybcd83--e3e60d71b4.png) *Figure 12: Once the State Transitioner is complete, the fraud proof is finalized and the invalid state roots get removed from the state commitment chain.* ## Incentives + Bonds In order to keep the system open and permissionless, the SCC is designed to allow anybody to be a sequencer and publish a state batch. To avoid the SCC being spammed with junk data, we introduce 1 limitation: The sequencer must be [marked as collateralized](https://github.com/ethereum-optimism/contracts-v2/blob/master/contracts/optimistic-ethereum/OVM/chain/OVM_StateCommitmentChain.sol#L133-L137) by a new smart contract, the [bond manager](https://github.com/ethereum-optimism/contracts-v2/blob/master/contracts/optimistic-ethereum/OVM/verification/OVM_BondManager.sol). You become collateralized by depositing a fixed amount, which you can withdraw with a 7 day delay. However, after collateralizing, a malicious proposer could just repeatedly create fraudulent state roots, in hopes that nobody disputes them, so that they make bank. Ignoring the scenario of users socially coordinating an emigration from the rollup and the evil sequencer, the attack cost here is minimal. The solution is very standard in L2 system design: If fraud is successfully proven, X% of the proposer’s bond gets burned [^13] and the remaining (1-X)% gets distributed [proportionally](https://github.com/ethereum-optimism/contracts-v2/blob/master/contracts/optimistic-ethereum/OVM/verification/OVM_BondManager.sol#L162-L187) to every user that provided data for Steps 2 and 4 of the fraud proof. The sequencer’s cost of defection is now much higher, and hopefully creates a sufficient incentive to prevent them from acting maliciously, assuming they act rationally [^14]. This also creates a nice incentive for users to submit data for the fraud proof, even if the state being disputed does not directly affect them. ## Nuisance Gas There is a separate dimension of gas, called “nuisance gas”, which is used to bound the net gas cost of fraud proofs. In particular, witness data (e.g merkle proofs) for the fraud proof’s setup phase is not reflected in the L2 EVM gas cost table. `ovmOPCODES` have a separate cost in nuisance gas, which gets charged whenever a new [storage slot](https://github.com/ethereum-optimism/contracts-v2/blob/f6069a881fbf6c35687a1676a73c67596b3ef4f9/contracts/optimistic-ethereum/OVM/execution/OVM_ExecutionManager.sol#L1254-L1256) or [account](https://github.com/ethereum-optimism/contracts-v2/blob/f6069a881fbf6c35687a1676a73c67596b3ef4f9/contracts/optimistic-ethereum/OVM/execution/OVM_ExecutionManager.sol#L1182-L1187) is touched. If a message tries to use more nuisance gas than allowed in the message’s context, execution [reverts](https://github.com/ethereum-optimism/contracts-v2/blob/f6069a881fbf6c35687a1676a73c67596b3ef4f9/contracts/optimistic-ethereum/OVM/execution/OVM_ExecutionManager.sol#L1457-L1461). ## Recap There’s a lot going on. The summary is that whenever there’s a state transition: 1. Somebody will dispute it if they disagree 2. they’ll publish all related state on Ethereum including a bunch of merkle proofs for each piece of state 3. They will re-execute the state transition on-chain 4. They will be rewarded for correctly disputing, the malicious sequencer will get slashed, and the invalid state roots will be pruned guaranteeing safety This is all implemented in Optimism’s [Fraud Prover service](https://github.com/ethereum-optimism/optimism-ts-services/blob/master/src/services/fraud-prover.service.ts) which is packaged with an optimistic-geth instance in a [docker compose image](https://github.com/ethereum-optimism/verifier). ## Review & Conclusion First of all: ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--1ef12e5ee1/bbe47630c435e39c35bc394d761f8fe9/asset-https-cdn-sanity-io-images-dgybcd83--1ef12e5ee1.png) You’ve made it! That was a long technical post with lots of references. I do not expect you to remember it all, but hopefully, this post can serve as a reference while you evaluate Optimism and Optimistic Rollup solutions. TL;DR: Optimism provides a throughput increasing solution for Ethereum while maintaining full compatibility with existing tooling and re-using well-tested and optimized software written by the Ethereum community. We are beyond excited for the future of Ethereum and the new use cases and companies that will be uniquely enabled by Optimism’s scalable infrastructure. For any further questions or discussions about Ethereum L2 scaling, Optimism, or Optimistic Rollups please @ me on [Twitter](https://twitter.com/gakonst) or drop me an [email](mailto:georgios@paradigm.xyz). ## Appendix ### OVM Opcodes We proceed to break down each OVM opcode by category: 1. Expressing [execution context](https://github.com/ethereum-optimism/contracts-v2/blob/f6069a881fbf6c35687a1676a73c67596b3ef4f9/contracts/optimistic-ethereum/iOVM/execution/iOVM_ExecutionManager.sol#L44-L66) related information: - Message Context: Who calls what ? Is it a state changing call? Is it a static call? Is it a contract creation call? - `CALLER`: Address of the caller - `ADDRESS`: Currently loaded contract address - Transaction Context: Information about the transaction - `TIMESTAMP`: Block timestamp - `NUMBER`: Block number - `GASLIMIT`: Block gas limit - Global Context: Chain-specific parameters - `CHAINID`: The Layer 2 chain’s chain id constant (420 for Optimism) 1. Contract Interactions: Each time there’s a message call to another contract, these opcodes are responsible for switching the context, making an external call and parsing revert information, if any: - `CALL`: adjusts the message context (`ADDRESS` and `CALLER`) before making an external contract call - `STATICCALL`: same as `CALL`, but sets the next message’s context to be static before making an external contract call - `DELEGATECALL`: leaves the context unchanged and makes an external contract call Each external call to a contract is also preceded by a [lookup to see if the contract’s state is loaded](https://github.com/ethereum-optimism/contracts-v2/blob/2b99de2f63ba57bb28a038d2832105fceef9edee/contracts/optimistic-ethereum/OVM/execution/OVM_ExecutionManager.sol#L961-L972), except for addresses `0x00-0x64`, which are reserved for precompiled contracts and do not require any lookups. 1. Contract Storage Access: - `SSTORE` - `SLOAD` The EVM versions would call the `ADDRESS` opcode and would then store or load the appropriate storage slot. Since we’re in the OVM, these opcodes must be overwritten to instead call [`ovmADDRESS`](https://github.com/ethereum-optimism/contracts-v2/blob/2b99de2f63ba57bb28a038d2832105fceef9edee/contracts/optimistic-ethereum/OVM/execution/OVM_ExecutionManager.sol#L649) and also check if these storage slots are present in the state trie when [storing](https://github.com/ethereum-optimism/contracts-v2/blob/2b99de2f63ba57bb28a038d2832105fceef9edee/contracts/optimistic-ethereum/OVM/execution/OVM_ExecutionManager.sol#L1229-L1246) and [loading data](https://github.com/ethereum-optimism/contracts-v2/blob/2b99de2f63ba57bb28a038d2832105fceef9edee/contracts/optimistic-ethereum/OVM/execution/OVM_ExecutionManager.sol#L1203-L1220). 1. Contract Creation: - `CREATE` - `CREATE2` Similarly, these opcodes are overridden to use [`ovmADDRESS`](https://github.com/ethereum-optimism/contracts-v2/blob/2b99de2f63ba57bb28a038d2832105fceef9edee/contracts/optimistic-ethereum/OVM/execution/OVM_ExecutionManager.sol#L364) for the deployer, adjusting the context to use the deployer as the `ovmCALLER` and the contract’s address as the [new context](https://github.com/ethereum-optimism/contracts-v2/blob/2b99de2f63ba57bb28a038d2832105fceef9edee/contracts/optimistic-ethereum/OVM/execution/OVM_ExecutionManager.sol#L904-L908)’s `ovmADDRESS`. A noticeable difference is there’s an [existence check](https://github.com/ethereum-optimism/contracts-v2/blob/2b99de2f63ba57bb28a038d2832105fceef9edee/contracts/optimistic-ethereum/OVM/execution/OVM_ExecutionManager.sol#L366-L368) in an allowlist (deployed as a [precompile](https://github.com/ethereum-optimism/contracts-v2/blob/2b99de2f63ba57bb28a038d2832105fceef9edee/contracts/optimistic-ethereum/OVM/execution/OVM_ExecutionManager.sol#L868-L875)), which prevents unauthorized users from deploying contracts. This is added as part of Optimism’s [defense-in-depth approach](https://medium.com/ethereum-optimism/mainnet-soft-launch-7cacc0143cd5) towards a full production mainnet and will be removed once [arbitrary contract deployment](https://github.com/ethereum-optimism/contracts-v2/blob/2b99de2f63ba57bb28a038d2832105fceef9edee/contracts/optimistic-ethereum/OVM/precompiles/OVM_DeployerWhitelist.sol#L190-L196) is [enabled](https://github.com/ethereum-optimism/contracts-v2/blob/2b99de2f63ba57bb28a038d2832105fceef9edee/contracts/optimistic-ethereum/OVM/precompiles/OVM_DeployerWhitelist.sol#L159-L166). 1. Contract code access: - `EXTCODECOPY`: Currently, `ovmEXTCODECOPY` will return a minimum of 2 bytes even if the length input is 1. This limitation will be removed before mainnet release, although the compiler already truncates it to 1 byte on the contract side, so unless you are writing some custom inline assembly, it should not be an issue even now. - `EXTCODESIZE` - `EXTCODEHASH` In addition, certain opcodes which “do not make sense” or cannot be made into safe counterparts have been blocked altogether: - `SELFBALANCE`, `BALANCE`, `CALLVALUE`: For the purposes of the OVM, we have removed all notion of native ETH. OVM contracts do not have a direct `BALANCE`, and the `ovm*CALL` opcodes do not accept a value parameter. Instead, OVM contracts are expected to use a wrapped ETH ERC20 token (like the popular WETH9) on L2 instead. - The ETH ERC20 is not deployed yet and the sequencer currently accepts transactions with a 0 gasPrice. - Gas is paid via the ETH ERC20 with a transfer to the sequencer. - `ORIGIN`: Scroll to the “Account Abstraction” section for more information. - `SELFDESTRUCT`: Not yet implemented. - `COINBASE`, `DIFFICULTY`, `GASPRICE`, `BLOCKHASH`: Not supported The `ovmCREATE(2)` opcodes are responsible for doing this safety check [and revert otherwise](https://github.com/ethereum-optimism/contracts-v2/blob/f6069a881fbf6c35687a1676a73c67596b3ef4f9/contracts/optimistic-ethereum/OVM/execution/OVM_ExecutionManager.sol#L749-L751). ### L1 to L2 interoperability In order to support L1 <> L2 communication, Transactions (via the new `meta` field) and messages in optimistic-geth are augmented to include additional metadata, as seen below: ![Figure 13: Geth vs Optimistic-Geth internal message format](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--90000d8e32/bb4ff6c92308037a977e6e779d382a08/asset-https-cdn-sanity-io-images-dgybcd83--90000d8e32.png) *Figure 13: Geth vs Optimistic-Geth internal message format* Optimism allows asynchronous calls between L1 and L2 users or contracts. Practically, this means that a contract on L1 can make a call to a contract on L2 (and vice versa). This is implemented by deploying “bridge” contracts in both Ethereum and Optimism. The sending chain’s contract calls [`sendMessage`](https://github.com/ethereum-optimism/contracts-v2/blob/master/contracts/optimistic-ethereum/OVM/bridge/OVM_BaseCrossDomainMessenger.sol#L39) with the data it wants to pass over, and a relay calls `relayMessage` \[[L1](https://github.com/ethereum-optimism/contracts-v2/blob/master/contracts/optimistic-ethereum/OVM/bridge/OVM_L1CrossDomainMessenger.sol#L77-L83), [L2](https://github.com/ethereum-optimism/contracts-v2/blob/master/contracts/optimistic-ethereum/OVM/bridge/OVM_L2CrossDomainMessenger.sol#L48)\] on the receiving chain to actually relay the data. ![Figure 14: The L1 <> L2 contract interface is abstracted over arbitrary messages](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--a9a4d26cb1/60c482f2bc57d9d45fbdafbdf2ca364a/asset-https-cdn-sanity-io-images-dgybcd83--a9a4d26cb1.png) *Figure 14: The L1 <> L2 contract interface is abstracted over arbitrary messages* Conveniently, all transactions from L1 to L2 get automatically relayed by the sequencer. This happens because the L1->L2 bridge calls [`enqueue`](https://github.com/ethereum-optimism/contracts-v2/blob/master/contracts/optimistic-ethereum/OVM/bridge/OVM_L1CrossDomainMessenger.sol#L281-L284), queuing up the transaction for execution by the sequencer. In a way, the sequencer is an “always on” relay for L1 to L2 transactions, while L2 to L1 transactions need to be explicitly relayed by users. Whenever a message is sent, a `SentMessage(bytes32)` event is emitted, which can be used as a wake-up signal for [relay services](https://github.com/ethereum-optimism/optimism-ts-services/blob/master/src/services/message-relayer.service.ts). Using the default bridge contracts by Optimism, requires that all L2 to L1 transactions are [at least 1 week old](https://github.com/ethereum-optimism/contracts-v2/blob/master/contracts/optimistic-ethereum/OVM/bridge/OVM_L1CrossDomainMessenger.sol#L206), so that they are safe from fraud proofs. It could be the case that developers deploy their own bridge contracts with semi-trusted mechanisms that allow L2 to L1 transactions with a smaller time restrictment. The simplest example of this mechanism would be [depositing an ERC20 on a L1 bridge contract](https://github.com/ethereum-optimism/optimism-tutorial/blob/dev-xdomain/contracts/L1_ERC20Adapter.sol) and [minting the equivalent token amount on L2](https://github.com/ethereum-optimism/optimism-tutorial/blob/dev-xdomain/contracts/L2_ERC20.sol). ![Figure 15: End to end message flow for a L1 <> L2 deposit and withdrawal](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--2086a8228f/bd7f0e635f0c160e7d114a01dcf74253/asset-https-cdn-sanity-io-images-dgybcd83--2086a8228f.png) *Figure 15: End to end message flow for a L1 <> L2 deposit and withdrawal* As a developer integrating with Optimism’s messengers, it’s very easy: Just call `messenger.sendMessage` with the function and target address you want to call on L2. This wraps the message in a [`relayMessage`](https://github.com/ethereum-optimism/contracts-v2/blob/ad5e11860a2b1b25e886e5fdec46b1afb7a5372d/contracts/optimistic-ethereum/OVM/bridge/OVM_BaseCrossDomainMessenger.sol#L73-L92) call, targeting the L2 Cross Domain Messenger. That’s all! Same for L2 to L1. This is all enabled by the new `L1MessageSender`, `L1BlockNumber` and `L1Queue` fields in the message and transaction `meta`. ## Account Abstraction Overview The OVM implements a basic form of [account abstraction](https://docs.ethhub.io/ethereum-roadmap/ethereum-2.0/account-abstraction/). In effect, this means that the only type of account is a smart contract (no EOAs), and all user wallets are in fact smart contract wallets. This means that, at the most granular level, OVM transactions themselves do not have a signature field, and instead simply have a to address with a data payload. It is expected that the signature field will be included within the data (we covered that when we talked about the Sequencer Entrypoint contract!). 3 opcodes have been added in order to support account abstraction: - `ovmCREATEEOA` - `ovmGETNONCE` - `ovmSETNONCE` Backwards Compatibility Developers need not be concerned with any of this when they start building their applications – Optimism has implemented a standard [ECDSA Contract Account](https://github.com/ethereum-optimism/contracts-v2/blob/master/contracts/optimistic-ethereum/OVM/accounts/OVM_ECDSAContractAccount.sol) which enables backwards compatibility with all existing Ethereum wallets out of the box. In particular, it contains a method [`execute(...)`](https://github.com/ethereum-optimism/contracts-v2/blob/master/contracts/optimistic-ethereum/OVM/accounts/OVM_ECDSAContractAccount.sol#L36) which behaves exactly like EOAs on L1: it recovers the signature based on standard L1 EIP155 transaction encoding, and increments its own nonce the same way as on L1. The OVM also implements a new opcode, [`ovmCREATEEOA`](https://github.com/ethereum-optimism/contracts-v2/blob/master/contracts/optimistic-ethereum/OVM/execution/OVM_ExecutionManager.sol#L464), which enables anybody to deploy the `OVM_ECDSAContractAccount` to the correct address (i.e. what shows up on metamask and is used on L1). `ovmCREATEEOA` accepts two inputs, a hash and a signature, and recovers the signer of the hash. This must be a valid L1 EOA account, so an `OVM_ECDSAContractAccount` is deployed to that address. This deployment is automatically handled by the sequencer [the first time an account sends an OVM transaction](https://github.com/ethereum-optimism/contracts-v2/blob/master/contracts/optimistic-ethereum/OVM/precompiles/OVM_SequencerEntrypoint.sol#L66-L67), so that users need not think about it at all. The sequencer also handles wrapping the user transaction with a call to [`execute(...)`](https://github.com/ethereum-optimism/contracts-v2/blob/master/contracts/optimistic-ethereum/OVM/precompiles/OVM_SequencerEntrypoint.sol#L72-L80). eth_sign Compatibility For wallets which do not support custom chain IDs, the backwards-compatible transactions described above do not work. To account for this, the `OVM_ECDSAContractAccount` also allows for an alternate signing scheme which can be activated by the `eth_sign` and `eth_signTypedData` endpoints and follows a standard Solidity ABI-encoded format. The [`@eth-optimism/provider`](https://www.npmjs.com/package/@eth-optimism/provider)` `package implements a web3 provider which will use this encoding format. In order to support this, a `SignatureHashType` field was added to geth’s transaction and message types. Account Upgradeability Technically, the `ovmCREATEEOA` opcode deploys a proxy contract which [`ovmDELEGATECALLs`](https://github.com/ethereum-optimism/contracts-v2/blob/master/contracts/optimistic-ethereum/OVM/accounts/OVM_ProxyEOA.sol#L31-L49) to a deployed implementation of `OVM_ECDSAContractAccount`. This proxy account can upgrade its implementation by calling its own [`upgrade(...)`](https://github.com/ethereum-optimism/contracts-v2/blob/master/contracts/optimistic-ethereum/OVM/accounts/OVM_ProxyEOA.sol#L56)` `method. This means that users can upgrade their smart contract accounts by sending a transaction with a to field of their own address and a data field which calls `upgrade(...)`. Note that the sequencer does not recognize any wallet contracts other than the default at this time, so users should not upgrade their accounts until future releases. Because of this, one restriction of the OVM is that there is no `tx.origin` (`ORIGIN` EVM opcode) equivalent in the OVM. The big advantage of this, is that it future proofs the system. As we said, the long-term state of accounts would be to use BLS signatures which can be aggregated, resulting in more compact data and as a result more scalability. This feature allows accounts which have BLS-ready wallets to opt-in upgrade to a future `OVM_BLSContractAccount`, while other accounts remain in their “old” wallet without noticing a thing. [^1]: Executing on Ethereum is guaranteed to always produce the “correct” result for a computation [^2]: The number in brackets is the program counter. If you are not familiar with EVM assembly we recommend this and this as an introduction [^3]: A great place to search for “function signature to name” conversions is the https://www.4byte.directory/ website. In addition, you can decompile EVM bytecode to assembly using EtherVM or Etherscan. All of these are great tools to understand what is going on here [^4]: I built Optimism’s solc from source and copied it to my PATH (after renaming it to osolc) [^5]: There’s an EIP to remove this limitation, which would solve this issue. Unfortunately, the EIP is stale at the time of writing this document [^6]: A message is basically a transaction stripped of any signatures, carrying only the information required to perform a state transition [^7]: It exists counterfactually! [^8]: Since every transaction passes through the ExecutionManager.run function, this logic is implemented inside EM.run, instead of “natively” in optimistic-geth [^9]: 7 day dispute period (configurable) [^10]: Not to confused with the microblocks from Bitcoin-NG [^11]: Before that call is made, the Execution Manager is set on the State Manager, to ensure that the latest version is used in case there was an update between the dispute’s initialization and the transaction’s execution. [^12]: The bytecode between the two contracts MUST be the same. Effectively, we’re deploying an L2 OVM contract and run it inside the OVM Execution Manager deployed on the L1 EVM. Inception! [^13]: Instead of burning it, it could be sent to a DAO funding public goods, or any other extra-protocol system. Burning the bond is a safe choice, since it is guaranteed that the attacker cannot access it in any way (whereas the attacker could subvert the public goods DAO and reclaim the funds that way) [^14]: Bryan Ford and Rainer Böhme in Rationality is Self-Defeating in Permissionless Systems disagree about the usage of incentives to guide intended results in an open system. Although out of scope, we recommend reading the article ## https://www.paradigm.xyz/writing/almost-everything-you-need-to-know-about-optimistic-rollup # (Almost) Everything you need to know about Optimistic Rollup > In this post, we dive into the principles of modern “Layer 2 solutions”, their corresponding security model, and how they can solve Ethereum’s scalability issues. This blogpost is targeted at “crypto-curious” individuals interested in learning more about cutting-edge Ethereum scaling techniques as well as developing a motivation on how to build and architect such systems. One of the biggest challenges in the Ethereum ecosystem is having low latency and high throughput under tight resource constraints (e.g. CPU, bandwidth, memory, disk space). The decentralization of a system is determined by the ability of the weakest node in the network to verify the rules of the system. A high-performance protocol that can be run on low-resource hardware is called “scalable”. In this post, we dive into the principles of modern “Layer 2 solutions”, their corresponding security model, and how they can solve Ethereum’s scalability issues. This blogpost is targeted at “crypto-curious” individuals interested in learning more about cutting-edge Ethereum scaling techniques as well as developing a motivation on how to build and architect such systems. *Throughout the post, important keywords or concepts are highlighted in bold, as they are words/jargon you will encounter throughout your journey in crypto. The topic is complicated. If you find yourself confused, keep reading, it’ll all make sense in the end.* ## Blockchain Resource Requirements Three factors impact the resource requirements of running a node in a decentralized network such as Bitcoin and Ethereum [^1]: - **Bandwidth**: The cost of downloading and broadcasting any blockchain-related data - **Compute**: The cost of running computations inside scripts or smart contracts - **Storage**: The cost of storing transaction data for indexing purposes, and the cost of storing “state” in order to continue processing new blocks of transactions [^2]. Performance is measured in 2 ways: - **Throughput**: The number of transactions the system can process per second. - **Latency**: The time it takes for a transaction to be processed. The desired property of emerging crypto-networks such as Bitcoin and Ethereum is decentralization. **But what makes a network decentralized?** - **Low Trust**: This is the property which allows any individual to verify that there will never be more than 21m bitcoin, or that their bitcoin is not counterfeited. Individuals who run node software independently compute the latest state and verify that all rules were followed in the process - **Low Cost**: If the node software is expensive to operate, individuals will rely on trusted third parties to verify the state. High costs imply high trust requirements, which is what we wanted to avoid in the first place. Another desired property is **scalability**: **The ability to scale throughput and latency superlinearly to the cost of running the system.** This definition is great, but doesn’t incorporate “trust”. Hence, we specify **“decentralized scalability”: achieving scalability without meaningfully increasing the system’s trust assumptions.** Zooming in, Ethereum’s runtime environment is the Ethereum Virtual Machine (EVM). Transactions that run through the EVM perform various operations at different costs (e.g. a store operation costs more than an addition). The unit of computation in a transaction is called “gas”, and the system is parameterized to process at most 12.5m gas per block, where a block of transactions gets produced on average every 12.5 seconds. As a result, **Ethereum’s latency is 12.5 seconds and its throughput is 1m gas per second.** A question you may ask is: What does 1m gas per second buy you? - ~47 “simple transfer” transactions per second. These transactions cost 21000 gas and are the simplest type of transaction, transferring ETH from A to B. - 16 ERC20 token transfers per second. These involve more storage operations than ETH transfers, and as a result cost 60k gas each. - ~10 Uniswap asset trades per second. The average cost of a token to token trade is [about](https://github.com/Uniswap/uniswap-v2-periphery/blob/master/test/UniswapV2Router01.spec.ts#L369-L374) 102k gas. - …pick your favorite transaction’s gas cost and divide 1m with it *(12.5m / 12.5 / gas)* Notice how as a transaction’s execution complexity increases, the system’s throughput decreases to very low values. There’s room for improvement! **Solution 1: Use an intermediary** We could use a trusted third party to facilitate all our transactions. That way, we’d get very high throughput and probably sub-second latency, which is great! That would not change any system-wide parameter, but we’d be opting in into a trust model unilaterally set by the third party. They may choose to censor us or even seize our assets, which is not desired. **Solution 2: Make blocks bigger and more frequent** We can reduce the latency by reducing the time between 2 blocks, and we can increase throughput by increasing the block gas limit. This change would make the cost to operate a node higher, preventing individuals from running nodes (e.g. happening with EOS, Solana, Ripple etc.). In solution 1, the trust is increased. In solution 2, the cost is increased. That eliminates both of them as scalability options. ## Rediscovering Optimistic Rollup from first principles *In the following section we assume the reader is familiar with *[*hashes*](https://blockgeeks.com/guides/what-is-hashing/)* and *[*merkle trees*](https://media.consensys.net/ever-wonder-how-merkle-trees-work-c2f8b7100ed3)*.* With our learnings so far, let’s simulate a socratic dialogue with the goal of discovering a protocol that can increase Ethereum’s effective throughput without increasing the burden for users and node operators. *Q. So…we want to scale Ethereum without meaningfully changing the trust & cost assumptions. How do we go about that?* A: We want to lower the requirements of existing operations in terms of their costs on the system (see three resources types above). In order to understand why that is not trivial to do, we need to first look at Ethereum’s architecture: **Every node in Ethereum currently stores and executes every transaction submitted to it by users**. During execution, a transaction is [run through the EVM](https://github.com/ethereum/go-ethereum/blob/45cb1a580abad0d4e8caa1c8b7dfacd5ef3d27bc/core/vm/evm.go#L273), and it [interacts](https://github.com/ethereum/go-ethereum/blob/45cb1a580abad0d4e8caa1c8b7dfacd5ef3d27bc/core/state_transition.go#L219-L273) with the EVM’s state (e.g. storage, balances etc.) - which is expensive. Common smart contract [optimization](https://medium.com/coinmonks/8-ways-of-reducing-the-gas-consumption-of-your-smart-contracts-9a506b339c0a) techniques center around minimizing the number of interactions with the state, but they only provide small constant factor improvements. *Q: Are you saying there’s a way to transact without touching the state, and thereby keeping the resource cost low?* A: At the limit, could we move all execution off-chain and keep some data on-chain. _We can do that by introducing a third party, called the **sequencer**. They are responsible for storing and executing user-submitted transactions locally. In order to maintain liveness of the system, sequencers are expected to periodically submit a merkle root of the transactions they receive and the resulting state roots on Ethereum. This is a step towards the right direction because **we store only O(1) data in Ethereum’s state for O(N) off-chain transactions**. *Q: So we achieve scaling by having the sequencer compute everything off-chain and only publish merkle roots?* A: Yes. *Q: OK so once you’re in, the sequencer guarantees that your transfers are cheap. How would deposits and withdrawals work?* A: A user will enter the system by depositing on Ethereum, followed by the sequencer crediting the user with the corresponding amount. A user will withdraw back to Ethereum by making a transaction that says “I want to withdraw 3 ETH, my account currently has >3 ETH and here’s the proof for it”. Even though the L1 does not have the actual user state,\*\* the user proves that they have sufficient funds at the current state by showing a merkle proof\*\* referencing the state roots published by the sequencer. *Q: We established that a user needs a merkle proof to withdraw their funds. How does the user get the data to construct the merkle proof?* A: They can ask the sequencer to provide them with the data! *Q: But what if the sequencer is temporarily or permanently unavailable?* A: The sequencer may either be malicious, or simply be offline because of a technical issue, which would cause performance degradation (or worse, theft!). So we must also demand that **the sequencer submits the full transaction data on-chain to be stored, but not to be executed**. The objective here is to get **data availability**. Given that all the data is permanently stored on Ethereum, even if the sequencer disappears, a new sequencer may retrieve all the Layer 2-related data from Ethereum, reconstruct the latest L2 state and continue from where their predecessor left off. Q: *So if the sequencer is online but refuses to provide me with the merkle proof data, I can download it from Ethereum?* A: Yes, you can either sync an Ethereum node [yourself](https://docs.ethhub.io/using-ethereum/running-an-ethereum-node/), or connect to [one of the many](https://ethereum.org/en/developers/docs/nodes-and-clients/nodes-as-a-service/) hosted node services. *Q: So something I still don’t understand…How can you store something on Ethereum without executing it? Doesn’t every transaction go through the EVM?* A: Say you submitted 10 transactions transferring ETH from A to B. Executing each transaction would perform the following actions: Increment A’s nonce, decrease A’s balance and increase B’s balance. That’s quite a few writes and reads from the [world state](https://medium.com/cybermiles/diving-into-ethereums-world-state-c893102030ed). Instead, you can send an encoding of all transactions to a smart contract’s `publish(bytes _transactions) public { }` function. Notice that the function’s body is empty!. This means that **the published transaction data is not interpreted, executed and no state access is made anywhere; it’s just stored in the historical logs of the blockchain** (which is cheap to write to). *Q: Can we trust the sequencer? What if they publish an invalid state transition?* A: Anytime the sequencer publishes a batch of state transitions there is a **“dispute period”** during which any party can publish a **“fraud proof”** which indicates that one of the state transitions was invalid. This is proven by replaying the transaction which caused the state transition onchain and comparing the resulting state root with the one that was published by the sequencer. If the state roots do not match, then the fraud proof is successful and the state transition is cancelled. If there were more state transitions after the invalid one, they also get cancelled. **Transactions which are older than the dispute period cannot be disputed anymore and are considered final.** *Q: Hold on! You said earlier, it’s not scaling if it a) increases the cost, or b) introduces new trust assumptions. In the scheme you describe here, don’t we additionally assume that there is always someone around to report fraud??* A: Correct. We assume that there are entities called **“verifiers”** who are responsible for watching for fraud, and if there’s a mismatch between Layer 1 and Layer 2 state they publish a fraud proof. We also assume that verifiers are able to reliably get their fraud proofs included in Ethereum within the dispute period deadline. We consider the existence of a verifier a “weak” assumption. Imagine, if there’s applications with thousands of users, you only need 1 person to run a verifier. That doesn’t sound too unrealistic! On the other hand, changing the trust model of Ethereum or increasing the cost for operating an Ethereum node is a “strong” assumption change which we don’t want to do. This is what we meant by “meaningfully change the underlying system’s assumptions” when we defined decentralized scalability. *Q: I agree that someone will run a verifier, because many parties have a vested interest in the success of this new solution. But surely, that also depends on how much it costs to actually do it. So what are the resource requirements for running a verifier and a sequencer?* A: Sequencers and Verifiers must run an Ethereum full node (*not an archive node)*, a full L2 node, to produce the L2 state. Verifiers run software that’s responsible for creating fraud proofs, and sequencers run software that’s responsible for bundling user transactions and publishing them. *Q: Is that it?* A: Yes! Congratulations! You’ve rediscovered **Optimistic Rollup** [^3], the most anticipated scaling solution of the 2019-2021 era. This is for a good reason, as it is the final artifact of a multi year long research process in the Ethereum community, which you experienced in a short dialogue. ## Incentives in Optimistic Rollup Layer 2 scaling is based on the fact that we try to minimize the number of executed on-chain transactions. We use fraud proofs to cancel any invalid state transitions which may happen. Since a fraud proof is an on-chain transaction, we also want to minimize the amount of fraud proofs that get issued on Ethereum. In the ideal scenario, fraud never happens, and as a result fraud proofs never get issued. We disincentivize fraud by introducing a [**fidelity bond**](https://en.wikipedia.org/wiki/Fidelity_bond#:~:text=A%20fidelity%20bond%20is%20a,dishonest%20acts%20of%20its%20employees.). In order for a user to become a sequencer, they must first post a bond on Ethereum, which they will forfeit if fraud is proven. In order to incentivize individuals to look for fraud, the sequencer’s bond is slashed and distributed to verifiers. ### Fidelity Bonds and Dispute Periods There’s 2 parameters to be tuned when designing the incentives for a fraud proof: - **Fidelity Bond Size:** The amount which must be posted by the sequencer that gets distributed to verifiers. The bigger this is, the bigger the incentive to be a verifier and the smaller the incentive to commit fraud as a sequencer. - **Dispute Period Duration:** The time window during which a fraud proof can be published, after which an L2 transaction is considered safe on L1. A long dispute period provides better security guarantees against censorship attacks. A shorter dispute period creates a nice user experience for users withdrawing from the L2 back to L1 because they do not need to wait long before they can re-use their funds on L1. In our opinion, there’s no correct static value for either of these parameters. Maybe 10 ETH bonds and 1 day dispute period is enough. Maybe 1 ETH and 7 days are enough. The real answer is that it depends on the incentive to be a verifier (which depends on the cost to run one) and how easy it is to get a fraud proof published (which depends on L1 congestion). Both of these should be tunable, either manually or automatically. As an honorary mention, [EIP1559](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1559.md) introduces a new `BASEFEE` opcode to Ethereum which can be used to estimate on-chain congestion, and as a result programmatically tune the duration of the dispute period. It’s important to get the implementation of this punishment mechanism right, otherwise it could be exploited in practice. Here is an example of a naive implementation that would not work: 1. Alice posts a 1 ETH bond, allowing her to be a sequencer in the system 2. Alice publishes a fraudulent state update 3. Bob notices that and publishes a dispute. If successful, this should grant the 1 ETH from Alice’s bond to Bob and cancel the fraudulent state update 4. Alice notices the dispute and publishes a dispute as well (disputing herself!) 5. Alice receives her 1 ETH, effectively paying no penalty even though she tried to commit fraud. Alice can mount this attack reliably by “frontrunning”, i.e. broadcasting an identical transaction as Bob’s but with a higher gas price, causing Alice’s transaction to be executed before Bob’s. This means that Alice can consistently try to cheat with minimal costs (just the Ethereum transaction fees). Fixing that is simple: **Instead of granting the full bond to the disputer, X% of it gets burned instead**. In the above example, if we burned 50% Alice would receive 0.5 ETH back instead, which would be a sufficient disincentive to not try cheating in Step 2. Of course, this bond burning reduces the incentive to run a verifier (since the payout becomes smaller), so the bond post-burn should be a big-enough incentive for verifiers instead. ## Popular Optimistic Rollup criticisms and our responses Now that we have gone through the building blocks of an Optimistic Rollup, let’s explore and address the most popular criticisms against that mechanism. ### Long withdrawal/dispute periods are fatal for adoption and composability We mentioned above that long dispute periods are great for security. There seems to be an inherent trade off here: Long dispute periods are bad for OR adoption, since any user that wants to withdraw their funds from OR needs to wait, say, 7 days until their funds are withdrawn. Small dispute periods are great for a smooth user experience, but then you are risking the case where fraud happens and no dispute gets included in time. We do not consider this to be a problem. Due to this potentially large withdrawal delay, we expect market makers to jump in and offer faster withdrawal services. This is possible because someone who validates the L2 state can correctly judge if a withdrawal is fraudulent or not, and hence “buy” it at a small discount for their services. Example: Actors: - Alice: has 5 ETH on L2. - Bob: has 4.95 ETH on L1 in a “market maker” smart contract and is running a verifier on the L2 Steps: 1. Alice lets Bob know that she wants a “fast” withdrawal, offering him a 0.05 ETH fee 2. Alice initiates a withdrawal to Bob’s “market maker” smart contract 3. 2 things can happen: 4. Bob checks that the withdrawal is valid on his L2 verifier and approves the fast withdrawal. This transfers 4.95 ETH to Alice’s L1 address *instantly*. Bob will be able to claim the 5 ETH after the withdrawal period is over, netting a nice profit. 5. Bob’s verifier alerts him that this transaction is not valid. Bob disputes the state transition caused by that transaction, canceling it *and* earning the sequencer’s bond for allowing the malicious transaction to happen. Alice either was honest and got her funds out instantly, or she was dishonest and got punished. We expect the fees paid to these market makers to compress over time, if there’s demand for this service, making the procedure completely invisible to users eventually. **The most important implication of this feature is that it enables composability with L1 contracts without having to wait for the full dispute period.** *Note that this technique was first described in *[*“Simple Fast Withdrawals”*](https://ethresear.ch/t/simple-fast-withdrawals/2128)*.* ### Miners can be bribed to censor withdrawals, breaking OR’s safety In [“Nearly-zero cost attack scenario on Optimistic Rollup”](https://ethresear.ch/t/nearly-zero-cost-attack-scenario-on-optimistic-rollup/6336) it is argued that miner incentives are such that it’s trivial for a sequencer to collude with Ethereum miners to censor any dispute transaction. This of course would be fatal for any optimistic system, given the reliance on disputes for safety. We disagree with the argument of this post. We posit that the honest side will always be willing to bribe the miner, with as much or more than the malicious side. In addition, miners incur an additional cost each time they deviate from “honest” behavior by helping the malicious side win. Such behavior would undermine the value of Ethereum, which potentially adds an additional cost for miners to engage in it In fact, this [exact scenario has been studied in academic literature](https://arxiv.org/pdf/2002.10736.pdf), proving that **“the threat of this kind of counterattack induces a subgame perfect equilibrium in which no attack occurs in the first place”.** *We’d like to thank Hasu for bringing this paper’s proof to our attention.* ### Verifier’s Dilemma creates disincentives for operating a verifier, breaking OR’s safety Ed Felten has authored a [great analysis](https://medium.com/offchainlabs/the-cheater-checking-problem-why-the-verifiers-dilemma-is-harder-than-you-think-9c7156505ca1) and [workaround](https://medium.com/offchainlabs/cheater-checking-how-attention-challenges-solve-the-verifiers-dilemma-681a92d9948e) to the Verifier’s Dilemma, which we summarize below: 1. If the system’s incentives work as intended, nobody will cheat 2. If nobody cheats, then there’s no point in running a verifier because you make no money from operating it 3. Since nobody runs a verifier, there’s eventually an opportunity for a sequencer to cheat 4. The sequencer cheats, the system no longer functions as intended It sounds like this is very important, and almost paradoxical! More verifiers reduce the expected payout for an individual verifier, assuming the size of the rewards’ is fixed. In addition, more verifiers seemingly reduce the size of the pie since there’s less fraud happening, further exacerbating the issue. In a follow-up analysis, Felten additionally provides a method to work around the verifier’s dilemma. I’d like to take the opposite side here and say that the verifier’s dilemma is not as important as critics say. In practice, there are non-monetary incentives to be a verifier. For example, if you are a large app building on a rollup, or if you are a token holder, since if the system were to fail your app would no longer work or your token value would be reduced. In addition to that, the demand for fast withdrawals creates an incentive for market making verifiers to exist (as we saw in the previous section), independently of fraud happening. To make that point more concrete, Bitcoin provides no incentives to store the entire blockchain history or provide your local data to your peers, but people do it altruistically anyway. Even if running a verifier in a vacuum is not incentive compatible, it keeps the system safe which is the most important thing for entities invested in the system’s success. As a result, we claim that **there is no need to design mechanisms to work around the Verifier’s Dilemma in Optimistic Layer 2 systems**. ## Conclusion In line with the title of the post, we analyzed one of the technologies that will matter for Ethereum in 2021: Optimistic Rollup. Summarizing its benefits: OR is an extension to Ethereum which carries over Ethereum’s security, composability and developer moats, while improving performance and not meaningfully impacting cost or trust requirements for Ethereum users. We explore the incentive structures which make Optimistic Rollups work, and provided responses to common criticisms. We want to emphasize that the maximum OR performance is bound by the data you can publish on L1. As a result, there’s merit in 1) Compressing the data you publish as much as possible (e.g. via [BLS signature aggregation](https://eprint.iacr.org/2018/483.pdf)), 2) Having a large and cheap data layer (e.g. [ETH2](https://ethresear.ch/t/phase-one-and-done-eth2-as-a-data-availability-engine/5269)) For complementary reading, we recommend Buterin’s [An Incomplete Guide to Rollups](https://vitalik.ca/general/2021/01/05/rollup.html) and [Trust Models](https://vitalik.ca/general/2020/08/20/trust.html). We also recommend investigating OR’s close cousin, ZK Rollup, being built by our friends at [StarkWare](https://starkware.co/). Finally, there are other ways to get decentralized scalability, namely, [sharding](https://eth.wiki/sharding/Sharding-FAQs) and [state channels](https://statechannels.org/) each with their own upsides and downsides. In a follow-up post, we will publish an in-depth mechanism and codebase analysis of the company which invented the first EVM-compatible optimistic rollup: [Optimism](https://optimism.io/). ## Let’s talk Questions? Thoughts? [@gakonst](https://twitter.com/gakonst) *Acknowledgments: We’d like to thank Hasu, Patrick McCorry, Liam Horne, Ben Jones, Kobi Gurkan and Dave White for providing valuable feedback when writing this post.* [^1]: We also refer the reader to Buterin’s excellent paper: “Blockchain Resource Pricing”. [^2]: Notably, storing “state” (account balances, contract bytecode, nonces) is more costly than storing raw transaction data. [^3]: Context: Optimistic rollup is the combination of “optimistic contracts” and “on chain data availability” (aka “rolling up the data”) ## https://www.paradigm.xyz/writing/paradigm-s-open-problems-a-series # Paradigm's Open Problems: A Series > About a month ago, we finally got around to publishing a truly wicked problem that had been plaguing my partner Dan Robinson and I for nearly two years. It was a Hail Mary pass; mostly, we hoped it would encourage whoever ended up cracking it to give us some closure, maybe years down the road. About a month ago, we finally got around to publishing a [truly wicked problem](https://research.paradigm.xyz/uniswap-fees) that had been plaguing my partner Dan Robinson and I for nearly two years. It was a Hail Mary pass; mostly, we hoped it would encourage whoever ended up cracking it to give us some closure, maybe years down the road. We couldn’t have been more surprised when a solution rolled in after only a few weeks. Two researchers we hadn’t previously met, [Dave White](https://twitter.com/_Dave__White_) and [Martin Tassy](https://twitter.com/MartinTassy), independently came to the same result. We got to talking and collaborated on a write-up, which Dave just published as Paradigm’s [first guest author](https://research.paradigm.xyz/uniswaps-alchemy). Reflecting on the experience, we at Paradigm were glad that getting the problem out there helped put it to bed. We were overjoyed that it created an opportunity to work with incredible people we probably wouldn’t have met otherwise – that feels like an experiment worth repeating. To that end, **we plan to make **[**“Paradigm’s Open Problems”**](https://www.paradigm.xyz/tag/open-problems/)** an ongoing series.** We aren’t sure yet what the next one will be or when we’ll release it – the best problems don’t reveal themselves on a schedule. We can promise that it will be worth sinking your teeth into. In the meantime, don’t hesitate to reach out. “Open Problems” could be anything that creates opportunities for talented researchers to collaborate with Team Paradigm. Some examples of things we’ve thought about: - Extensions and follow-ups to published problems - Expanded solutions (modified assumptions, practical applications, etc.) - Entirely new problems; they could be related to our portfolio companies or other research, but anything interesting is fair game You can reach any of us individually on Twitter or email ([firstname@paradigm.xyz](mailto:firstname@paradigm.xyz)), or our research group’s email ([research@paradigm.xyz](mailto:research@paradigm.xyz)). ## https://www.paradigm.xyz/writing/uniswaps-alchemy # Uniswap's Financial Alchemy > An investigation into the nature of constant product markets. ![Uniswap LP getting rich by getting mercilessly arbed (source).](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--9a6d604cb0/a90df353532947c942696d9bda327a5a/asset-https-cdn-sanity-io-images-dgybcd83--9a6d604cb0.png) ## 1. The Question On October 14th, [Charlie Noyes](https://twitter.com/_charlienoyes) posted on [Twitter](https://twitter.com/_charlienoyes/status/1316446325035200512?s=20) a question that he and [Dan Robinson](https://twitter.com/danrobinson) had been debating: For any Uniswap pair, what is the optimal fee? Can this optimal fee beat an unrebalanced portfolio, achieving “no impermanent loss” or even excess growth (in expectation)? ### 1.1. Context An [automated market maker](https://web.archive.org/web/20211013222909/https://cointelegraph.com/explained/uniswap-and-automated-market-makers-explained) is a type of decentralized exchange that lets customers trade between on-chain assets like USDC and ETH. Uniswap is the most popular AMM on Ethereum. Like most AMMs, Uniswap facilitates trading between a particular pair of assets by holding reserves of both assets. It sets the trading price between them based on the size of its reserves in such a way that prices will stay in line with the broader market. Anybody who would like to can join the "pool" for a particular pair and become a liquidity provider, or LP, so-called because they provide liquid assets for others to trade against. LPs contribute assets to both reserves simultaneously, taking on some of the risk of trading in exchange for a share of the returns. ### 1.2. The Problem Setting The problem supposes that the pool is providing liquidity between cash and a risky asset whose price moves randomly. It also makes the particularly brutal assumption that all incoming trades are *informed* -- arbitrage transactions that take place only when the AMM's price is out of line. In other words, the pool loses money on every trade. ### 1.3. Conventional Wisdom At first glance, it seems that being a Uniswap LP in these circumstances would be a costly mistake. Because market makers demand a lower price to buy than to sell, they directly profit when asset prices don't move and they get a roughly balanced amount of incoming buys and sells. These are often called "uninformed" trades, because they aren't correlated with short term price movements. On the other hand, market makers lose money when they buy the asset just before prices drop, or when they sell it just before prices rise. Accordingly, one of the market maker's most feared counterparties is the arbitrageur, who comes to trade only when prices have changed and left the market maker behind. Every trade she executes is pure profit for her and pure loss for the market maker. Since there are no uninformed trades in our Uniswap problem setting (literally every trade is an arbitrage trade), it seems obvious that the LPs should lose out big time. ### 1.4. The Challenge Nevertheless, Dan and Charlie intuited that there might be more to the story. For some underlying price dynamics, they suspected, it could still make sense to be an LP on Uniswap even if it meant getting run over on every single trade. They brought their problem to mathematical finance legend Steven Shreve before setting it loose on crypto Twitter, where [Martin Tassy](https://math.dartmouth.edu/~mtassy/) and [I](https://twitter.com/_Dave__White_) independently produced [partial](https://twitter.com/_Dave__White_/status/1321318971820290048?s=20) [solutions](https://twitter.com/MartinTassy/status/1322640368790343681?s=20) before collaborating to extend his nearly complete solution to [the general case](https://math.dartmouth.edu/~mtassy/articles/AMM_returns.pdf). The four of us spent some time over the next few weeks discussing the results over Telegram, probing for errors and building our intuitions. Those discussions are the basis of this post. ## 2. The Solution If the volatility of an asset is high enough relative to its average rate of return, LPs on Uniswap will do better than HODLers over time, *even when the only incoming trades are arbs.* This is due to a phenomenon known as volatility harvesting: under certain conditions, it is possible to outperform any static portfolio of two assets by periodically rebalancing them. In this case, to “rebalance” means to make trades such that the proportion of total portfolio value held in each asset returns to a fixed allocation, such as 50/50. So, when they get arbed, LPs essentially pay a fee to the market to rebalance their portfolios for them. In this particular mathematical setting, it turns out that when this rebalancing is beneficial, you want to do it as often as possible. This means liquidity providers should set their fee, which determines the width of the price window in which rebalances occur, to be as low as possible without being zero. This is good news for Uniswap, because it means that even in circumstances where arbitrage trades dominate, low fees can still make sense, enabling Uniswap to stay competitive as on-chain orderbooks proliferate and begin to offer tighter spreads. That said, it's worth repeating that these results hold for a very particular stylized mathematical setting, which involves assumptions very similar to those of the [Black-Scholes Options Pricing Model](https://en.wikipedia.org/wiki/Black%E2%80%93Scholes_model). We also assume a different fee structure than the one used in production Uniswap for mathematical convenience. 2.1. Standard of Comparison We evaluate different strategies by comparing their *asymptotic wealth growth rates*, which measure how fast they compound (or lose) value over long periods of time. This quantity is important because strategies that optimize it perform better than strategies that don't [almost surely](https://en.wikipedia.org/wiki/Almost_surely) as time goes on. We compare all strategies to the "unrebalanced portfolio," which holds half of its value in cash and half of its value in the risky asset to start, and is never changed after that point. This is the community standard for measuring so-called "impermanent loss" in AMMs. The unrebalanced portfolio will always hold the same amount of cash no matter what happens. That means that in the worst case, when the risky asset loses all of its value, the unrebalanced portfolio will consist almost entirely of cash, and will therefore have a growth rate of zero in the long run. On the other hand, if the risky asset sees exponential growth, it will quickly come to dominate the unrebalanced portfolio, which therefore have the same growth rate as the risky asset. It's worth noting that two portfolios can share the same asymptotic wealth growth rate while behaving quite differently close-up. For example, if the risky asset has a growth rate of zero, then zero-fee Uniswap shares will always be worth less than the unrebalanced portfolio, but since neither is expected to compound growth or loss over time, both will have a wealth growth rate of zero. ### 2.2. Volatility Drag ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--3fac1b8946/50a7a280b8c7ab1ef0c703cc4356c393/asset-https-cdn-sanity-io-images-dgybcd83--3fac1b8946.png) To understand these results, it helps to first understand the concept of volatility drag. Let's say that every year the price of our risky asset either drops In any given year, if we invest $100 in the asset, our "expected value" is 502+1752=$112.5. If we simply buy and hold, the expected value of our portfolio will keep increasing by 12.5% each year. This seems like a pretty good deal. Unfortunately, in the real world, our profits will not materialize. If we buy and hold this security, we will eventually lose everything. This is because losses are disastrous when compounding wealth over time. If we suffer a 50% loss one year, and see a 75% gain the next year, we will have only 50%∗175%=87.5% of what we had when we started. Similarly, if we have a good year and make 75%, but then lose 50% the next year, we will again be left with 175%∗50%=87.5% of what we had when we started. Over time, the law of large numbers guarantees that our internal rate of return will be −12.5% per year, and we will inevitably go bankrupt. ### 2.3. Wait, What? If you have been trained to analyze gambles through the lens of expected value, there's a good chance that the previous section seems extremely weird and perhaps flat-out incorrect. In fact, we had the full, closed-form mathematical solution to this problem for over a week before I had any idea what it meant at an intuitive level due to precisely this issue. The root of it is this: expected value is a theoretical quantity that measures what would happen if we replicated a given gamble simultaneously across an infinite number of parallel universes. Reality, however, doesn't work that way. We get only one shot at each gamble, and the effects of the gambles we make aren't instantaneous, but instead compound over time. We can view it from another angle to help reconcile the math. As we repeat the −50%/+75% gamble over and over, reinvesting our bankroll each time, the expected value grows largely due to the very small number of paths where everything goes exactly right, resulting in astronomical returns. As time goes on, these paths represent a smaller and smaller proportion of all those that are possible, and our chance of actually seeing one of them realized shrinks to zero. ### 2.4. The Value of Rebalancing In the face of volatility drag, it pays to keep some of your money in reserve even when you're looking at a bet with positive expected value. That way, you lose less when things go wrong, boosting your compounded wealth in the long run. As far as trading is concerned, all of this shakes out to some pretty familiar concepts. When prices go up, it sometimes makes sense to close out part of your position to lock in profits in case prices fall again. When prices go down, it sometimes makes sense to buy the dip to get access to expected future returns at a favorable price. In certain settings, such as this one, the optimal strategy is to continually rebalance your portfolio, such that you always have a constant proportion of your wealth invested in each position — say, half cash, half risky asset. This is not always the optimal balance, and in general [you want more of the risky asset in your portfolio the higher its returns relative to its volatility](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2927791), but we defer further exploration to future work. The benefits of rebalancing to long-term wealth growth can be massive, and can mean the difference between becoming exponentially wealthy and going bankrupt. This is true even when, as in our setting, each individual rebalance trade is at an unfavorable price and causes an instantaneous loss. ### 2.5. Resources There's a good chance you are feeling unsatisfied by these explanations and would like to learn more. You might start by reviewing [The Kelly Criterion](https://en.wikipedia.org/wiki/Kelly_criterion), a theoretically optimal betting strategy based on these principles. [@wpoundstone](https://twitter.com/wpoundstone?lang=en)'s [*Fortune's Formula*](https://www.amazon.com/Fortunes-Formula-Scientific-Betting-Casinos/dp/0809045990/ref=sr_1_1?s=books&ie=UTF8&qid=1309976818&sr=1-1) is a highly regarded and accessible book on its history and implications. Alternately, for an in-depth mathematical treatment of the mathematics of wealth growth, I highly recommend [@ole_b_peters](https://twitter.com/ole_b_peters)' [Ergodicity Economics Lecture Notes](https://ergodicityeconomics.com/lecture-notes/) or [his article in](https://www.nature.com/articles/s41567-019-0732-0) [*Nature*](https://www.nature.com/articles/s41567-019-0732-0). If you choose to investigate for yourself, be careful. This is poorly understood territory, and many of the sources I found during the course of my own research contained errors that set my understanding back by hours or days. In particular, if you see anyone making an appeal to mean reversion or logarithmic utility functions, I advise you to move on. The key results in this area do not require you to assume any particular return distribution or utility function. ### 2.6. Fee Alchemy ![Wealth growth discontinuity at 0% fee (source).](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--4e3acfa4a0/6eb60afe92dd7d43077e63c7c9139bcb/asset-https-cdn-sanity-io-images-dgybcd83--4e3acfa4a0.png) When it's beneficial to be an LP in this setting, LPs should rebalance as often as possible to stay maximally balanced at minimal cost. The fee should therefore be set as low as possible without being zero so that rebalances are triggered by increasingly tiny price movements. Dan Robinson calls this "picking up pennies in the quantum foam." However, when the fee is exactly zero, all the benefits of rebalancing disappear, and in most cases LPs are worse off than they would be if they just held the unrebalanced portfolio. Understanding this seeming anomaly helps shed light on the rest of the problem. Uniswap uses the "constant product" invariant, which means that in the absence of fees, each trade must leave the product of the reserve balances constant. We express this as $$R_\\alpha R_\\beta = C$$ in our notation, although readers already familiar with Uniswap may be more used to writing it as $$x\*y=k$$. However, it turns out that this product $$C$$ is exactly the quantity that must increase in order for rebalancing to provide us with excess wealth growth. Why is $$C$$ so important? One way of looking at it is that $$\\sqrt{C}$$ is the [geometric mean](https://en.wikipedia.org/wiki/Geometric_mean) of our reserve balances $$R_\\alpha$$ and $$R_\\beta$$. Like the arithmetic mean, the geometric mean increases as the reserve quantities grow. Unlike the arithmetic mean, however, the geometric mean shrinks as the reserve quantities get out of balance, even if their arithmetic mean stays the same. In the no-fee case, $$C$$ remains constant, so trades always lead to \*either\* bigger reserves \*or\* more balanced reserves. It's never both. As a result, there's no engine for wealth growth. However, a nonzero fee, implemented as in either real-world Uniswap or our setting, guarantees that $$C$$ increases with every trade. When $$C$$ increases over time, it means the reserves are not only growing, but staying balanced as well, providing the benefits discussed above. To see the precise mathematics of how this works out, see [prop 3.1 in Martin's and my proof](https://math.dartmouth.edu/~mtassy/articles/AMM_returns.pdf). ## 3. The Math With all that said, we can now precisely answer the questions laid out in [Charlie's original problem statement](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-f907dc485c/1daf80127b54686926f76cf5f7d64013/asset-https-cdn-sanity-io-files-dgybcd83-p-f907dc485c.pdf). To restate, they concern the wealth growth rate $$G$$ of a Uniswap-style AMM with percentage fee $$1-\\gamma$$ making a market between cash and an asset whose price moves as a Geometric Brownian Motion with parameters $$\\mu$$ (drift) and $$\\sigma$$ (volatility). ### 3.1. Growth Rate of LP Wealth $$ d = \mu - \frac{\sigma^2}{2} $$ $$ G = \mathop{\mathbb{E}}[\displaystyle{\lim_{T\to\inf}}\frac{1}{T}\log(W(T))] = \begin{cases} \frac{d}{2}((\frac{1 + \gamma^{\frac{4d}{\sigma^2}}}{1 - \gamma^{\frac{4d}{\sigma^2}}})(\frac{1-\gamma}{1+\gamma})+1) & \text{if } d\neq0, \gamma \notin \lbrace0,1\rbrace \\ \\ \frac{\sigma^2}{4\log{\gamma}}\frac{\gamma-1}{\gamma+1} & \text{if } d=0, \gamma \notin \lbrace0,1\rbrace \\ \\ \max({\mu - \frac{\sigma^2}{2},0}) & \text{if } \gamma = 0 \\ \\ \frac{1}{2}(\mu - \frac{\sigma^2}{2}) & \text{if } \gamma = 1 \end{cases} $$ ### 3.2. Optimal Fee & Excess Return It pays to be an LP vs. holding the unrebalanced portfolio of half cash and half the security if and only if $$\\mu > 0$$ and $$\\frac{2\\sqrt{\\mu}}{\\sqrt{3}} < \\sigma < 2\\sqrt{\\mu}$$. In these cases, LPs should set their fees as low as possible without being zero, and they will realize a wealth growth rate asymptotically approaching $$\\frac{\\mu}{2}-\\frac{\\sigma^2}{8}$$. ### 3.3. Interpretation Since Geometric Brownian Motions model compound growth, they too are subject to volatility drag, which is mathematically expressed as the $$-\\frac{\\sigma^2}{2}$$ term of the GBM wealth growth rate: $$ G = \mu - \frac{\sigma^2}{2} $$ That means the range of $$\\frac{2\\sqrt{\\mu}}{\\sqrt{3}} < \\sigma < 2\\sqrt{\\mu}$$ in which it makes sense to be an LP on Uniswap corresponds to HODL growth rates of $$-\\mu < G < \\frac{\\mu}{3}$$. This gives us a lens through which to view our results: rebalancing allows us to partially counteract the volatility drag on the underlying asset. If the average return even without volatility drag is zero or negative, no amount of rebalancing will help us, and we are better off just holding cash, although the rebalanced portfolio will still do better than just HODLing the asset itself. On the other hand, if the average return without volatility drag is positive: - If volatility drag costs the asset more than 200% of its average log return, rebalancing on Uniswap won't be able to eliminate enough of the drag to make it worthwhile, and you are better off just holding cash. - If volatility drag costs the asset less than 66% of its average log return, offsetting drag by rebalancing on Uniswap will not be worth the cost, and you are better off simply holding the asset. - Within that range, being a Uniswap LP will eventually make you rich, and in fact richer than you could become by holding any unrebalanced portfolio consisting of cash and the asset. This includes both some assets that will eventually dwindle into nothing and some assets that will go parabolic. ### 3.4. The Proofs A pre-print of the full proof can be found [here](https://math.dartmouth.edu/~mtassy/articles/AMM_returns.pdf). It works by modeling the dynamics for a discrete random walk and then taking the limit of the behavior as you shrink step size to zero. You can also check out my original proof for the zero log drift case and play with some of the simulations of the problem [here](https://colab.research.google.com/drive/1wfYQJo0K03ImAQHkdIpWbuOSyaHdWjp3?usp=sharing). It works by stretching time, variance, and fee into equivalent configurations to produce identities. ### 3.5. How much trust should we place in these results? In my biased opinion: quite a lot. We have two independent methods of proof which produce the same results where their domains overlap. We also have simulations that validate our predictions: ![Simulated vs. predicted wealth growth rates](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--c49908f896/b60d60038247dac246a372778ea64a57/asset-https-cdn-sanity-io-images-dgybcd83--c49908f896.png) Still, this is extremely confusing territory, and my understanding of it has changed many times in the past few weeks. If you do happen to spot an error, don't hesitate to reach out. ## 4. Future Work While we hope you agree that these results are theoretically interesting (and/or maddening), plenty of work remains to establish their relevance to the real world. For example, many of our assumptions could be modified or expanded: - How do these results translate to the multi-asset case, or when LPs can choose to rebalance to proportions other than 50/50, as in Balancer? - What happens when we no longer allow infinite trades per unit of time? - How about as we introduce transaction costs, which could even be variable to reflect priority gas auction dynamics? There are also empirical questions: - Can we estimate these parameters for securities trading in the market today? - How many actively traded tokens would have benefited from a rebalancing strategy such as the one we have described? - Can we determine what proportion of realized Uniswap LP return in the wild is due to volatility harvesting? Finally, and perhaps most interestingly, there is the question of application. How can we take what we have learned here and use it to improve existing protocols, create new ones, and grow the DeFi ecosystem as a whole? ## 5. Let's Talk Questions? Thoughts? Potential applications? We want to hear from you. [@_charlienoyes](https://twitter.com/_charlienoyes) ● [@danrobinson](https://twitter.com/danrobinson) ● [@_Dave__White_](https://twitter.com/_Dave__White_) ● [@MartinTassy](https://twitter.com/MartinTassy) #### Acknowledgements Thanks to [Vitalik Buterin](https://twitter.com/VitalikButerin), [Matt Huang](https://twitter.com/matthuang), [Georgios Konstantopoulos](https://twitter.com/gakonst), and [Alex Evans](https://twitter.com/alexhevans) for conversations which contributed to this post. ## https://www.paradigm.xyz/writing/so-you-want-to-use-a-price-oracle # So you want to use a price oracle > Everything you need to know about price oracles and how to use them safely. In late 2019, I published a post titled “[Taking undercollateralized loans for fun and for profit](https://samczsun.com/taking-undercollateralized-loans-for-fun-and-for-profit/)”. In it, I described an economic attack on Ethereum dApps that rely on accurate price data for one or more tokens. It's currently late 2020 and unfortunately numerous projects have since made very similar mistakes, with the most recent example being the Harvest Finance hack which resulted in a collective loss of 33MM USD for protocol users. While developers are familiar with vulnerabilities like reentrancy, price oracle manipulation is clearly not something that is often considered. Conversely, exploits based on reentrancy have fallen over the years while exploits based on price oracle manipulation are now on the rise. As such, I decided it was time that someone published a definitive resource on price oracle manipulation. This post is broken down into three sections. For those who are unfamiliar with the subject, there is an introduction to oracles and oracle manipulation. Those who want to test their knowledge may skip ahead to the case studies, where we review past oracle-related vulnerabilities and exploits. Finally, we wrap up with some techniques developers can apply to protect their projects from price oracle manipulation. ## Oracle manipulation in real life Wednesday, December 1st, 2015. Your name is David Spargo and you’re at the Peking Duk concert in Melbourne, Australia. You’d like to meet the band in person but between you and backstage access stand two security guards, and there’s no way they would let some average Joe walk right in. How would the security guards react, you wonder, if you simply acted like you belonged. Family members would surely be allowed to visit the band backstage, so all you had to do was convince the security guards that you were a relative. You think about it for a bit and come up with a plan that can only be described as genius or absolutely bonkers. After quickly setting everything up, you confidently walk up to the security guards. You introduce yourself as David Spargo, family of Peking Duk. When the guard asks for proof, you show them the irrefutable evidence - [Wikipedia](https://en.wikipedia.org/w/index.php?title=Peking_Duk&oldid=693419023). ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--b51c7ac979/478de00a19ab969a6c1d5552db1509ed/asset-https-cdn-sanity-io-images-dgybcd83--b51c7ac979.png) The guard waves you through and asks you to wait. A minute passes, then two. After five minutes, you wonder if you should make a run for it before law enforcement makes an appearance. As you’re about to bail, Reuben Styles walks up and introduces himself. You walk with him to the green room where the band was so impressed with your ingenuity that you end up sharing a few beers together. Later, they share what happened on their Facebook page. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--d11872463e/ea4c471cb35fb4c0bf861e6337f83c9e/asset-https-cdn-sanity-io-images-dgybcd83--d11872463e.png) ## What is a price oracle? A price oracle, generously speaking, is anything that you consult for price information. When Pam asks Dwight for the cash value of a Schrute Buck, Dwight is acting as a price oracle. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--26854b01a4/667691f946d6110ac21340212b9a24fe/asset-https-cdn-sanity-io-images-dgybcd83--26854b01a4.png) On Ethereum, where everything is a smart contract, so too are price oracles. As such, it’s more useful to distinguish between how the price oracle gets its price information. In one approach, you can simply take the existing off-chain price data from price APIs or exchanges and bring it on-chain. In the other, you can calculate the instantaneous price by consulting on-chain decentralized exchanges. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--a0ea0fc0c0/c9b507ac85bacaae5cb3a9cad20366d1/asset-https-cdn-sanity-io-images-dgybcd83--a0ea0fc0c0.png) Both options have their respective advantages and disadvantages. Off-chain data is generally slower to react to volatility, which may be good or bad depending on what you’re trying to use it for. It typically requires a handful of privileged users to push the data on-chain though, so you have to trust that they won’t turn evil and can’t be coerced into pushing bad updates. On-chain data doesn’t require any privileged access and is always up-to-date, but this means that it’s easily manipulated by attackers which can lead to catastrophic failures. ## What could possibly go wrong? Let’s take a look at a few cases where a poorly integrated price oracle resulted in significant financial damage to a DeFi project. ### Synthetix sKRW Oracle Malfunction Synthetix is a derivatives platform which allows users to be exposed to assets such as other currencies. To facilitate this, Synthetix (at the time) relied on a custom off-chain price feed implementation wherein an aggregate price calculated from a secret set of price feeds was posted on-chain at a fixed interval. These prices then allowed users to take long or short positions against supported assets. On June 25, 2019, one of the price feeds that Synthetix relied on mis-reported the price of the Korean Won to be 1000x higher than the true rate. Due to [additional errors](https://blog.synthetix.io/response-to-oracle-incident/) elsewhere in the price oracle system, this price was accepted by the system and posted on-chain, where a trading bot quickly traded in and out of the sKRW market. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--031a8872b1/f0368428fff79789994c8582d072933d/asset-https-cdn-sanity-io-images-dgybcd83--031a8872b1.png) In total, the bot was able to earn a profit of over 1B USD, although the Synthetix team was able to negotiate with the trader to return the funds in exchange for a bug bounty. Synthetix correctly implemented the oracle contract and pulled prices from multiple sources in order to prevent traders from predicting price changes before they were published on-chain. However, an isolated case of one upstream price feed malfunctioning resulted in a devastating attack. This illustrates the risk of using a price oracle which uses off-chain data: you don't know how the price is calculated, so your system must be carefully designed such that all potential failure modes are handled properly. ### Undercollateralized Loans As mentioned earlier, I published a post in September 2019 outlining the risks associated with using price oracles that relied on on-chain data. While I highly recommend reading the [original post](https://samczsun.com/taking-undercollateralized-loans-for-fun-and-for-profit/), it is quite long and heavy in technical details which may make it hard to digest. Therefore, I’ll be providing a simplified explanation here. Imagine you wanted to bring decentralized lending to the blockchain. Users are allowed to deposit assets as collateral and borrow other assets up to a certain amount determined by the value of the assets they’ve deposited. Let’s assume that a user wants to borrow USD using ETH as collateral, that the current price of ETH is 400 USD, and that the collateralization ratio is 150%. If the user deposits 375 ETH, they’ll have deposited 150,000 USD of collateral. They can borrow 1 USD for every 1.5 USD of collateral, so they’ll be able to borrow a maximum 100,000 USD from the system. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--e132da6d7d/23bdc9e5d2a61db119b5cf3e0c9709f0/asset-https-cdn-sanity-io-images-dgybcd83--e132da6d7d.png) But of course, on the blockchain it’s not as simple as simply declaring that 1 ETH is worth 400 USD because a malicious user could simply declare that 1 ETH is worth 1,000 USD and then take all the money from the system. As such, it’s tempting for developers to reach for the nearest price oracle shaped interface, such as the current spot price on Uniswap, Kyber, or another decentralized exchange. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--d1550bea3f/e87aa387ce54ddcc5faee0bd6bf262b4/asset-https-cdn-sanity-io-images-dgybcd83--d1550bea3f.png) At first glance, this appears to be the correct thing to do. After all, Uniswap prices are always roughly correct whenever you want to buy or sell ETH as any deviations are quickly correct by arbitrageurs. However, as it turns out, the spot price on a decentralized exchange may be wildly incorrect during a transaction as shown in the example below. Consider how a Uniswap reserve functions. The price is calculated based on the amount of assets held by the reserve, but the assets held by the reserve changes as users trade between ETH and USD. What if a malicious user performs a trade before and after taking a loan from your platform? Before the user takes out a loan, they buy 5,000 ETH for 2,000,000 USD. The Uniswap exchange now calculates the price to be 1 ETH = 1,733.33 USD. Now, their 375 ETH can act as collateral for up to 433,333.33 USD worth of assets, which they borrow. Finally, they trade back the 5,000 ETH for their original 2,000,000 USD, which resets the price. The net result is that your loan platform just allowed the user to borrow an additional 333,333.33 USD without putting up any collateral. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--105f796af9/71463e8f92f0a9d9b6d63dc875d942d2/asset-https-cdn-sanity-io-images-dgybcd83--105f796af9.png) This case study illustrates the most common mistake when using a decentralized exchange as a price oracle - an attacker has almost full control over the price during a transaction and trying to read that price accurately is like reading the weight on a scale before it’s finished settling. You’ll probably get the wrong number and depending on the situation it might cost you a lot of money. ## Synthetix MKR Manipulation In December 2019, Synthetix suffered another attack as a result of price oracle manipulation. What’s notable about this one is that it crossed the barrier between on-chain price data and off-chain price data. Reddit user u/MusaTheRedGuard [observed](https://www.reddit.com/r/ethfinance/comments/eexbfa/daily_general_discussion_december_24_2019/fby3i6n/) that an attacker was making some very suspicious trades against sMKR and iMKR (inverse MKR). The attacker first purchased a long position on MKR by buying sMKR, then purchased large quantities of MKR from the Uniswap ETH/MKR pair. After waiting a while, the attacker sold their sMKR for iMKR and sold their MKR back to Uniswap. They then repeated this process. Behind the scenes, the attacker’s trades through Uniswap allowed them to move the price of MKR on Synthetix at will. This was likely because the off-chain price feed that Synthetix relied on was in fact relying on the on-chain price of MKR, and there wasn’t enough liquidity for arbitrageurs to reset the market back to optimal conditions. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--d1aad7db5e/588ffa03e194740084277d4a0b36866f/asset-https-cdn-sanity-io-images-dgybcd83--d1aad7db5e.png) This incident illustrates the fact that even if you think you’re using off-chain price data, you may still actually be using on-chain price data and you may still be exposed to the intricacies involved with using that data. ### The bZx Hack In February 2020, bZx was hacked twice over the span of several days for approximately 1MM USD. You can find an excellent technical analysis of both hacks written by palkeo [here](https://www.palkeo.com/en/projets/ethereum/bzx.html), but we will only be looking at the second hack. In the second hack, the attacker first purchased nearly all of the sUSD on Kyber using ETH. Then, the attacker purchased a second batch of sUSD from Synthetix itself and deposited it on bZx. Using the sUSD as collateral, the attacker borrowed the maximum amount of ETH they were allowed to. They then sold back the sUSD to Kyber. If you’ve been paying attention, you’ll recognize this as essentially the same undercollateralized loan attack, but using a different collateral and a different decentralized exchange. ### yVault Bug On July 25, 2020, I reported a bug to yEarn regarding the launch of their new yVault contracts. You can read the official writeup about this bug [here](https://blog.trailofbits.com/2020/08/05/accidentally-stepping-on-a-defi-lego/), but I will briefly summarize it below. The yVault system allows users to deposit a token and earn yield on it without needing to manage it themselves. Internally, the vault tracks the total amount of yVault tokens minted as well as the total amount of underlying tokens deposited. The worth of a single yVault token is given by the ratio of tokens minted to tokens deposited. Any yield the vault earns is spread across all minted yVault tokens (and therefore, across all yVault token holders). The first yVault allowed users to earn yield on USDC by supplying liquidity to the Balancer MUSD/USDC pool. When a user supplies liquidity to Balancer pools, they receive BPT in return which can be redeemed for a proportion of the pool. As such, the yVault calculated the value of its holdings based on the amount of MUSD/USDC which could be redeemed with its BPT. This seems like the correct implementation, but unfortunately the same principle as given before applies - the state of the Balancer pool during a transaction is not stable and cannot be trusted. In this case, because of the bonding curve that Balancer chose, a user who swaps between from USDC to MUSD will not receive a 1:1 exchange rate, but will in fact leave behind some MUSD in the pool. This means that the value of BPT can be temporarily inflated, which allows an attacker to manipulate the price at will and subsequently drain the vault. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--f9fcfedb6c/51466d16733593da0b6c190695d79cc4/asset-https-cdn-sanity-io-images-dgybcd83--f9fcfedb6c.png) This incident shows that price oracles are not always conveniently labelled as such, and that developers need to be vigilant about what sort of data they’re ingesting and consider whether that data can be easily manipulated by an unprivileged user. ### Harvest Finance Hack On October 26, 2020, an unknown user hacked the Harvest Finance pools using a technique that you can probably guess by now. You can read the official post-mortem [here](https://medium.com/harvest-finance/harvest-flashloan-economic-attack-post-mortem-3cf900d65217), but once again I’ll summarize it for you: the attacker deflated the price of USDC in the Curve pool by performing a trade, entered the Harvest pool at the reduced price, restored the price by reversing the earlier trade, and exited the Harvest pool at a higher price. This resulted in over 33MM USD of losses. ## How do I protect myself? By now, I hope that you’ve learned to recognize the common thread - it's not always obvious that you're using a price oracle and if you don't follow the proper precautions, an attacker could trick your protocol into sending them all of your money. While there’s no one-size-fits-all fix that can be prescribed, here are a few solutions that have worked for other projects in the past. Maybe one of them will apply to you too. ## Shallow Markets, No Diving Like diving into the shallow end of a pool, diving into a shallow market is painful and might result in significant expenses which will change your life forever. Before you even consider the intricacies of the specific price oracle you’re planning to use, consider whether the token is liquid enough to warrant integration with your platform. ## A Bird in the Hand is Worth Two in the Bush It may be mesmerizing to see the potential exchange rate on Uniswap, but nothing’s final until you actually click trade and the tokens are sitting in your wallet. Similarly, the best way to know for sure the exchange rate between two assets is to simply swap the assets directly. This approach is great because there’s no take-backs and no what-ifs. However, it may not work for protocols such as lending platforms which are required to hold on to the original asset. ## Almost Decentralized Oracles One way to summarize the problem with oracles that rely on on-chain data is that they’re a little too up-to-date. If that’s the case, why not introduce a bit of artificial delay? Write a contract which updates itself with the latest price from a decentralized exchange like Uniswap, but only when requested by a small group of privileged users. Now even if an attacker can manipulate the price, they can’t get your protocol to actually use it. This approach is really simple to implement and is a quick win, but there are a few drawbacks - in times of chain congestion you might not be able to update the price as quickly as you’d like, and you’re still vulnerable to sandwich attacks. Also, now your users need to trust that you’ll actually keep the price updated. ## Speed Bumps Manipulating price oracles is a time-sensitive operation because arbitrageurs are always watching and would love the opportunity to optimize any suboptimal markets. If an attacker wants to minimize risk, they’ll want to do the two trades required to manipulate a price oracle in a single transaction so there’s no chance that an arbitrageur can jump in the middle. As a protocol developer, if your system supports it, it may be enough to simply implement a delay of as short as 1 block between a user entering and exiting your system. Of course, this might impact composability and miner collaboration with traders is on the rise. In the future, it may be possible for bad actors to perform price oracle manipulation across multiple transactions knowing that the miner they’ve partnered with will guarantee that no one can jump in the middle and take a bite out of their earnings. ## Time-Weighted Average Price (TWAP) Uniswap V2 introduced a TWAP oracle for on-chain developers to use. The [documentation](https://uniswap.org/docs/v2/core-concepts/oracles/) goes into more detail on the exact security guarantees that the oracle provides, but in general for large pools over a long period of time with no chain congestion, the TWAP oracle is highly resistant to oracle manipulation attacks. However, due to the nature of its implementation, it may not respond quickly enough to moments of high market volatility and only works for assets for which there is already a liquid token on-chain. ## M-of-N Reporters Sometimes they say that if you want something done right, you do it yourself. What if you gather up N trusted friends and ask them to submit what they think is the right price on-chain, and the best M answers becomes the current price? This approach is used by many large projects today: Maker runs a set of [price feeds](https://developer.makerdao.com/feeds/) operated by trusted entities, Compound created the [Open Oracle](https://medium.com/compound-finance/announcing-compound-open-oracle-development-cff36f06aad3) and features reporters such as [Coinbase](https://blog.coinbase.com/introducing-the-coinbase-price-oracle-6d1ee22c7068), and Chainlink aggregates price data from Chainlink operators and exposes it on-chain. Just keep in mind that if you choose to use one of these solutions, you’ve now delegated trust to a third party and your users will have to do the same. Requiring reporters to manually post updates on-chain also means that during times of high market volatility and chain congestion, price updates may not arrive on time. ## Conclusion Price oracles are a critical, but often overlooked, component of DeFi security. Safely using price oracles is hard and there’s plenty of ways to shoot both yourself and your users in the foot. In this post, we covered past examples of price oracle manipulation and established that reading price information during the middle of a transaction may be unsafe and could result in catastrophic financial damage. We also discussed a few techniques other projects have used to combat price oracle manipulation in the past. In the end though, every situation is unique and you might find yourself unsure whether you’re using a price oracle correctly. If this is the case, feel free to [reach out](https://samczsun.com/contact/) for advice! *Acknowledgments: Special thanks to Dan Robinson and Georgios Konstantopoulos for reviewing this post, and to @zdhu_ and mongolsteppe for pointing out an error.* ## https://www.paradigm.xyz/writing/governance-minimization # Governance Minimization > Governance minimization allows stakeholders to depend on a protocol. This creates a virtuous cycle of adoption, enabling scale that would otherwise be unachievable. Look no further than successful traditional internet protocols like HTTP and SMTP to see this power today. *"THE BEST GOVERNMENT IS THAT WHICH GOVERNS LEAST"* *— UNKNOWN* Those who read my blockchain governance [post](https://medium.com/@FEhrsam/blockchain-governance-programming-our-future-c3bfe30f2d74) from 2017 know I was excited about crypto exploring different forms of governance, especially on-chain governance. In the 3 years since, on-chain governance has gone from obscure to a popular component of many important protocols. Despite this traction, I think **the most widely used protocols will trend towards governance minimization**. Why? Governance minimization allows stakeholders to depend on a protocol. This creates a virtuous cycle of adoption, enabling scale that would otherwise be unachievable. Look no further than successful traditional internet protocols like HTTP and SMTP to see this power today. Their governance minimization has allowed them to become standards everyone depends on, generating levels of use far exceeding what any company could achieve. This post explains governance minimization, where governance remains important, and speculates on implications. ## Governance Minimization Governance minimization means reducing the power and reliance on governance wherever possible. Governance minimization is important because it supports the primary value proposition of protocols: credible neutrality. Minimizing governance tends to make protocols more credibly neutral. In practice today, governance minimization most directly applies to minimizing on-chain governance. If a protocol wants to achieve maximum adoption and can avoid using governance for a function, it should do so. ## What is credible neutrality? Credible neutrality is dependability. It means a stakeholder (e.g a user or a developer) can use or build on a protocol with confidence it will [not change against their interests](https://nakamoto.com/credible-neutrality/). Protocols remain credibly neutral by avoiding "capture" by any particular group. ## Why is credible neutrality important? Credible neutrality is primary value proposition of crypto today. It's what allows for new forms of open and predictable money. It's what creates platforms where anyone can openly create and access new applications. Lack of credible neutrality in existing platforms makes its importance clear. Central banks are not credibly neutral as platforms for money because a subset of stakeholders can decide to print money at will. Facebook and Twitter are not credibly neutral as platforms for applications because a subset of stakeholders can make changes that kill entire developer ecosystems. It creates safety of value locked in a platform — both concrete (funds) and abstract (development time, users) — from theft, shutdown, and restriction. A total failure of credible neutrality is an exit scam. Some stakeholders of a platform can abscond, in part or in whole, with the value other stakeholders own or have created. A literal example is a centralized crypto exchange operator running off with user funds. An abstract example is Twitter shutting down third party developer interfaces to enshrine the interface of Twitter Inc. ## What governance minimization is *not* Governance minimization is *not* the idea that governance can or should go away entirely. In fact, this is impossible! There are some protocol functions that are hard or impossible to perform without governance ("essential governance", more on this later). And at a minimum, governance always exists through the ability to coordinate socially ("informally") and hard fork. ## **Governance minimization creates more neutral protocols** Creating a perfect governance system is like designing a perpetual motion device. There are well-known game theoretic results which show all governance systems are both [inherently unstable](https://vitalik.ca/general/2020/09/11/coordination.html#understanding-the-game-theory) and [fail to simultaneously satisfy all desirable properties](https://en.wikipedia.org/wiki/Arrow%27s_impossibility_theorem). Formalizing a governance system tends to magnify these inherent issues by reducing the ability for informal governance to solve edge cases as they show up. As a result, the more formal a governance system, the more susceptible it tends to be to capture over a sufficient time horizon. This is primarily because formalizing a governance system requires formalizing stakeholders (who has a say and how much of a say they should have). Formalizing stakeholders is very hard in practice at a single point in time and near impossible over time. ## **Tokenholder misalignment** Formalizing stakeholders for on-chain governance today typically occurs through simple token ownership and the governance itself through tokenholder voting. Unfortunately, token holdings are not an accurate reflection of stakeholder value in a protocol for a number of reasons, including: - Not all stakeholders will necessarily be tokenholders, especially users and developers. - Token ownership may not accurately reflect a stakeholder's importance to the protocol, present or future. The next Facebook or Google-scale app, when it appears, could be strangled in the cradle by those with higher ownership. - Stakeholders change over time. The is especially obvious when considering future stakeholders which don't yet exist. Consider the interests of the mega app which has yet to be created. As a result, tokenholder voting creates a litany of misalignment issues with the long term use of a protocol, including: - [External pressures](https://vitalik.ca/general/2019/05/09/control_as_liability.html). For example, Facebook Inc faced external pressure to lock down developer access to the most detailed social graph in the world (the Facebook platform). Right or wrong, this killed many applications and incalculable numbers of future applications yet to be created. - Value capture. Tokenholders may want to capture value for themselves at the expense of others. For example, Twitter monopolized its protocol's UI at the expense of third party developers. - Time horizon mismatch. Unlike a protocol, tokenholders have non-infinite time horizons. This may drive them to capture value short term at the expense of the long term use of the protocol. For example, Maker holders with a short term horizon might increase stability fees to generate value short term irrespective of long term impacts. Ironically, Facebook is a good example of the opposite, where Mark Zuckerberg famously refused to display ads (capture value) while the network effect of Facebook was still growing. - Outside economic interests. Tokenholders may be large holders of another token and vote with that interest in mind rather than the interests of the protocol being changed. Liquidity mining programs in DeFi are especially vulnerable to this form of misalignment. Exploits to act on these misalignments are well documented and hard to avoid. Prominent attacks include [buying votes](https://vitalik.ca/general/2018/03/28/plutocracy.html) or voting with borrowed tokens — an attack made easier with the invention of flash loans that has [already worked](https://www.coindesk.com/flash-loans-manipulate-defi-protocol-elections)! ## Other side effects Even if participants don't explicitly capture a system, governance may still create unintended side effects. For example, formal governance systems can encourage action versus inaction, even when inaction is superior. Governance can also be extremely time and energy consuming. ## **Speed of evolution** A common argument for on-chain governance is that it can allow protocols to evolve faster. However, there is little, if any, empirical evidence of on-chain governance causing faster protocol evolution. On-chain governance is also extremely nascent, so judging it too heavily is likely premature. What *has* been demonstrated is the opposite: that rapid evolution can occur without on-chain governance. For example, early Ethereum and Uniswap are protocols that evolved quickly through hard forking alone. This agility can be attributed to a combination of tight knit communities, lower systemic importance, and high levels of trust in core development teams. What about ossification at later stages? Evolution may slow as some combination of network effects, pointer stickiness (protocols becoming embedded in the code of other protocols/applications), and risk aversion set in. Still, if a change is important enough, users and applications can voluntarily opt into it. This usually means a hard or soft fork for a layer-1 protocol and a voluntary migration for layer 2 protocols or application, as seen with the v1 to v2 transitions in protocols like Uniswap, Maker, Compound, and Augur. Ultimately, if a protocol becomes sufficiently inferior to a new alternative, eventually it will be surpassed and die. This is how evolution works in nature. Individual organisms do not evolve (in the genetic code sense). Evolution occurs when copies are made with mutations. This approach has also worked in open source in the past (e.g Linux). Since credible neutrality is the primary value proposition of protocols, erring towards governance minimization over time, even if it means slower evolution at the individual protocol level, will lead to maximal use. ## Governance minimization enables faster ecosystem-wide evolution Most importantly, dependable individual protocols enable faster ecosystem-wide evolution because developers can use these building blocks with confidence. Imagine how much faster development of internet applications would be if every company's code was open source, neutral, and usable by anyone. ## **When** ***is*** **governance valuable?** Governance is needed where a core mechanism of a protocol requires human input. Human input is needed when a protocol's response to a particular action cannot be known in advance or derived from on-chain data, and thus cannot be coded into the protocol. We refer to these mechanisms as "essential governance". Areas of essential governance include: - Consensus itself (e.g. the layer 1 consensus mechanism of Bitcoin or Ethereum). Consensus is governance over which of two otherwise valid histories is valid. This governance is tightly constrained: Bitcoin miners can double-spend and revert history but cannot print unlimited Bitcoin. - Oracles. Oracles need some form of human mechanism to decide whether or not their data is valid. Areas where governance is likely required include: - Treasury management. Governance is likely required for the foreseeable future: deciding how to allocate funds is a hard problem to automate. - Complex parameter setting. As one example, Maker currently needs governance to approve new collateral types and set their corresponding collateral requirements. These functions are inherently hard to codify: the suitability and risk profile of a new collateral type (some of which may not even exist today!) is hard to assess in advance. Some governance can be eliminated over time. For example, Maker could build a mechanism that programmatically sets interest rates, eliminating the need for governance to set them. Governance is often a complex tradeoff. For example, the Maker system chooses to allow many different collateral types for the benefit of greater capital efficiency. This, of course, also has the drawback that the ability to handle new collateral types requires governance and all of the system risks, community energy, and complexity associated with that governance. It's possible to build a governance minimized alternative to Maker with only one type of collateral; whether or not this system would be "better" is challenging to assess. Finally, governance may be a feature in some cases. For example, people changing the rules of a game (governance) could be a core mechanic of some games or social apps. ## **Governance minimization is not a panacea** While governance minimized protocols are more dependable, adverse outcomes for some subset of stakeholders can still occur. For example, the majority of participants in a governance minimized protocol can still choose to hard fork for their own benefit and at the expense of others. However, the cost is high: setting a social norm of violating credible neutrality causes future potential stakeholders to lose trust and eliminating stakeholders tends to reduce the network effects and use of a protocol. Forking can also be a feature, of course: it allows two different stakeholder groups to live on the protocols they each want. Most importantly, eliminating governance in some places does not mean it can or will be eliminated everywhere. It may even make governance more important in the smaller number of areas it concentrates. ## **Crypto governance remains important and ripe for innovation** Well functioning governance remains vital, especially in areas of essential governance (e.g. layer 1 consensus, oracles). If the point of a blockchain is to provide a ledger of universally accepted truth, its integrity is paramount. Innovation in on-chain governance systems remains an important frontier. Improvements beyond the current naïve “one token, one vote” standard likely exist (e.g. [quadratic voting](https://en.wikipedia.org/wiki/Quadratic_voting#:~:text=Quadratic%20voting%20is%20a%20collective,voting%20paradox%20and%20majority%20rule.), [futarchy](http://mason.gmu.edu/~rhanson/futarchy.html)) and are important to create. I remain excited to watch those experiments get run and continue to believe we’ll see more innovation in governance systems through blockchains than through “the real world” in the coming decades. ## Value Capture The extent to which governance is needed to capture value is an experiment playing out in real time. Pointer stickiness, gas costs, user-initiated state (e.g. a live bid in a decentralized exchange which a user would need to re-initiate in a new protocol), and other network effects are some factors that could create defensibility and allow a governance minimized protocol to capture value. Value capture = use x take rate. The central claim of this post is that use of governance minimized protocols will be higher (the left side of the equation). Take rate (the right side of the equation) remains an open question. It may be that governance minimized protocols have higher use but lower take rates relative to a traditional company. And where that nets out economically is to be discovered. Separately, many tend to hear "value capture" and think "evil!". Value capture can serve a few important purposes. First, it incentivizes creation of protocols in the first place. Second, if governance is needed, governance value capture is necessary to incentivize contributions to governance and for security (to make 51% attacks on governance more costly). Finally, it can help fund further development. Ultimately only "essential governance" is defensible. Anything inessential is likely to be competed away over time. ## Conclusion Governance minimized protocols will see the most use. It is the core attribute which kicks off the positive feedback loop between trust and adoption as a standard. It also puts powerful, basic tools in the hands of all creators, generating more opportunity and faster progress for the entire crypto ecosystem. As crypto grows into one of the most important technologies of the coming decades, it can lead to greater opportunity and faster progress society-wide. *Acknowledgments: Thanks to Brian Armstrong, Vitalik Buterin, Gus Coldebella, Jacob Horne, Matt Huang, Georgios Konstantopoulos, Steve Lee, Charlie Noyes, James Prestwich, Dan Romero, and David Vorick for conversations which contributed to this post.* ## https://www.paradigm.xyz/writing/crypto-market-structure-3-0 # Crypto Market Structure 3.0 > A discussion on the crypto market structure overtime. In the early 2010s, the crypto market consisted of a handful of small, retail-focused brokers. Over the last decade, the market has grown to over $15B of daily volume across spot, derivatives, and on-chain markets. Today, BTC sits among the most liquid assets in the world. The quirkiness of crypto-assets has created a novel market: Crypto markets are open 24/7. Users all over the world can access completely fungible assets. Public blockchains allow frictionless transfer of crypto and fiat in minutes. Individuals can custody assets themselves as securely as the banks. Unlike the NYSE or Nasdaq, retail users can trade on the largest crypto exchanges directly without intermediation. Even with these advantages, the crypto market structure is opaque and poorly understood due to global fragmentation, rapid change, and the diversity of participants. This essay outlines the two significant evolutions in the crypto market over the last decade and articulates a vision for what the future could hold. # **Market Structure 1.0: 2010 to 2017** The prehistory of the crypto market began with p2p trading over Bitcointalk and IRC. The first real market structure began in earnest in July 2010 with the launch of Mt. Gox. Over the next five years, many early exchanges launched fiat on-ramps to service individuals. With bitcoin’s nascency, accessing stable banking channels was a challenge, leading to the rise of stablecoins like Tether. As adoption grew, over-the-counter (OTC) desks began servicing the handful of early institutional firms. Without sophisticated market makers, liquidity was poor. Cross-border and cross-venue spreads were often measured in single-digit percentages. The influx of new market participants in December 2017 overwhelmed exchanges daily and marked the end of an era. It’s not worth reflecting on this bygone time further; thank you to the early builders who got us here. ## **Market Structure 2.0: 2018 to Present** Since December 2017, the crypto market evolved to a 2.0 iteration, growing from a market designed for individuals to one that’s institutionally accessible. Over this time, derivatives volumes grew over 25x while bid-ask spreads fell 10x. The market matured from manual, expensive, and BTC-denominated to fully electronic, cheap, and stablecoin-denominated. The major drivers of this shift are: - **Derivatives liquidity eclipsing spot:** Since 2017, the epicenter of crypto liquidity shifted from the spot market to derivatives. Crypto derivatives lagged spot volumes in 2017 but now trade 3-5x as much at over $10B/day. As two-sided liquidity increased, Bitcoin volatility fell materially, with 60d volatility ranging from 2-4% currently, from 4-8% in 2017-18, and 7-10%+ in 2013-14. Today’s derivatives landscape is diverse, including the US-regulated market (CME, Bakkt), global players (FTX, Deribit), and offerings from international spot exchanges (Binance, Huobi, OKEx). - **Electronification of OTC execution:** Since 2017, OTC spreads have compressed an order of magnitude, from 50-200bp to 5-10bp today for an 8-figure BTC trade. In 2017, OTC trading was primarily over voice and chat. Today, it is fully electronic, dominated by quantitative trading firms like Jump, B2C2, Amber, and Alameda Research. Rather than firing up Skype, clients can connect directly to platforms hosted by market makers and stream quotes, execute trades over API. - **The emergence of lending:** In 2017, there was nearly 0 credit in crypto. Today, trading firms can access over $2B of BTC and stablecoin borrow, with desks intermediating both retail (BlockFi, Celsius, Blockchain.com) and institutional (Genesis) lenders. The lending market has lowered market makers’ capital costs, benefiting institutional clients with tighter spreads and retail users with high single-digit yields. - **Stablecoins as the crypto-finance reserve asset:** In 2017, nearly every crypto-assets’ dominant trading pair was BTC-denominated. This resulted in significant price dislocations and evaporating liquidity during high volatility periods. Today, the most liquid trading pair of almost every top-30 crypto asset is stablecoin-denominated. Stablecoins have replaced BTC as the crypto market’s reserve asset, reflected in 10x growth in total stablecoin issuance from January 2018 ($2B to $20B). - **Institutional services and products:** In 2017, institutions were limited to accessing the market through retail channels. Today, institutions can work dozens of qualified custodians, electronic execution, and lend/borrow markets new entrants like Tagomi, Fireblocks, and Anchorage in addition to incumbents like Coinbase and Genesis/BitGo. ECNs like Paradigm.co have improved block trading workflows while specialized venues like LMAX Digital now lead global BTC:USD liquidity. ## **Market Structure 3.0: ~2020 to ?** We’re in the early stages of the next structural evolution, from 2.0 to 3.0. At maturity, the 3.0 iteration will (1) be radically more capital-efficient and (2) bridge centralized markets to emerging decentralized finance (DeFi) markets. ### *1. Capital efficiency* Crypto trading remains capital inefficient due to market fragmentation and a lack of industry-wide credit assessment. Today, exchanges have high margin requirements, and firms cannot cross-margin, i.e., use margin posted at one broker or venue to collateralize a position elsewhere. This forces firms to fully fund nearly all their trading activity and subjects trade settlement to many block confirmations (at-minimum). Full funding is especially taxing in highly volatile environments when on-chain congestion is most significant. As a result of these inefficiencies, the perpetual swap has become the dominant source of short-dated funding. Crypto perps: “Came for incremental capital efficiency, stayed for the 20x leverage.” Dependence on the perp market as the backbone of market funding is very sub-optimal: cascading liquidations in March 2020 resulted in over $1.6B notional liquidations on BitMEX alone, much of which should be preventable in a more capital-efficient market. Credit creation and shortened trade lifecycles drive capital efficiency. Credit creation allows firms to get more than $1 of buying power per $1. Shorter trade lifecycles mean the same $1 can go around more times, increasing liquidity per dollar. Some specific ways we’ll see credit creation and shorter trade lifecycles: - **Dedicated prime brokerage:** Large exchanges have the most robust balance sheets in crypto, allowing them to extend significant credit directly. Indirectly, PBs like Coinbase enable clients to margin across venues and cold storage speeds up trade lifecycles by moving transfers off-chain. - **Crypto-native derivatives clearing:** In traditional markets, exchange-traded derivatives are cleared by central clearinghouses who maintain the ledger of margin calculations. Over the last few years, firms like Zero Hash and ErisX have attempted to port this model to crypto directly. Alternatively, approaches like X-Margin could achieve this crypto-natively by making cryptographic collateral attestations on-chain. - **A formal repo market:** The $2-4T/day repo market allows institutions to borrow cash on a secured short-term basis. Crypto already has an informal repo market through the perpetual swap funding, and bi-laterally settled OTC repo ($50M/day). A formal institutional repo market could enable sizable near-term borrowing without exposure to perp venues. - **Lower on-chain confirmation thresholds:** Superior understanding of public blockchain settlement assurances drives faster deposit times between known counterparties. Fireblocks’ Digital Asset Transfer Network settles over $25B/month on-chain and allows members to opt into “instant” deposits with each other. Fireblocks-initiated transfers are SGX-signed and ensure that an (unconfirmed) transaction is the only one signed for a given UTXO. These guarantees allow exchanges like FTX to accept deposits from other Fireblocks users, as soon as the transaction hits the mempool. ### *2. CeFi ↔ DeFi convergence* Decentralized finance (DeFi) first appeared in late 2017 and grew parallel to Market Structure 2.0. As DeFi continues to gain structural importance, CeFi and DeFi will converge as they see overlap in market participants, liquidity pools, and product UX. Even in its 1.0 iteration, DeFi has already begun disrupting “CeFi.” Some examples: - **Liquidity is built on AMMs first:** In 2017-18, building liquidity in a nascent asset required working with exchanges and market makers. With AMMs enabling permissionless listings, passive retail LPs ca create market depth before a professional LP even has inventory. Once the starting point of liquidity, major global crypto exchanges are now a late mover in the long-tail. - **Best execution requires on-chain interaction:** AMMs like Curve now hold nearly $1B in stablecoins. The direct implication is that brokers unable to access on-chain liquidity have an immediate disadvantage versus those who can. This shift happened quickly; the impact of AMMs on centralized liquidity was visible as recently as March 2020. For many MMs, this has been a real forcing function to onboard to DeFi. - **Crypto-native cross-margining:** Margin positions in DeFi have been tokenized since the start, taking forms like Uniswap LP shares, Compound cTokens, and Synthetix synths. DeFi margin tokens are fully-collateralized and callable on-chain, enabling transparent rehypothecation when used composably (e.g., using Uniswap LP shares as Maker CDP collateral). While FTX has already pioneered tokenized margin on centralized venues, the design surface is only now opening up. - **DeFi’s frictionless UX:** DeFi UX is *better* than CeFi in many ways. While critics often focus on gas fees, DeFi offers users superior security UX (non-custodial) and frictionless access. Scanning a QR code and signing a MetaMask transaction is accessible and closer to using Snapchat than fiddling with a traditional brokerage. Though DeFi already has deep spot trading and lending markets, DeFi hasn’t “eaten” CeFi yet. Throughput and high gas fees remain significant structural barriers. As L2 solutions come to market, DeFi presents a real threat to centralized venues as applications like Synthetix, which can replicate BTC-margined synthetic assets with UX that’s comparable to using FTX. What does this mean for CeFi players? A few implications: - **Better DeFi interfaces:** Exchanges will lean on their scale efficiency to intermediate DeFi for users the same way they have with staking services. Offering interfaces to access DeFi is a natural way to prevent capital flight on-chain. Providing liquidity of locked assets, lower fees (via pooling), and additional off-chain margin are some ways exchanges can incentivize users to access DeFi through their interface. For many users, an exchange account may be the most convenient way to access on-chain protocols as the default wallet. - **Normalization of non-custodial trading:** Non-custodial exchange offerings are another natural “defense” against capital flight. Binance and FTX have fully leaned into the challenge, building non-custodial DEXs Binance Chain (a Cosmos zone) and Serum (on Solana). Protocols like Arwen can enable non-custodial trading for exchanges pursuing a hybrid approach. Newer projects like dYdX and DeversiFi (originally via Bitfinex) are building to scale and aim to compete with centralized UX, powered by StarkWare’s ZK-based L2. - “**CeDeFi” is real:** Beyond non-custodial window dressing, every major CeFi player will attempt to capitalize on “CeDeFi” unironically. Low effort solutions could be structured products trying to mimic on-chain yields. A more comprehensive solution could include full EVM-compatible chains that can port DeFi, e.g., Binance SmartChain. - **Institutional DeFi support:** Retail users have lower frictions to access DeFi relative to large institutions, subject to compliance or regulatory hurdles. As larger firms are beginning to view DeFi markets as a first-class citizen, service providers will seek to enable frictionless access for their clients without compromising existing workflows. Over time, we may even see some projects launch whitelisted (KYC’d) liquidity pools over time. Off-chain DeFi insurance could alleviate mechanism and contract risks far more coverage on a un/under-collateralized basis. As scalability improves, on-chain financial infrastructure will begin competing with centralized infrastructure. However, the diversity of users and the importance of fiat on-ramps means centralized venues aren’t disappearing any time soon. The long-term winners are users, who can explore the spectrum of options across trust, price, risk, and UX. ## **Conclusion** The crypto market structure has gone through two significant evolutions over the first decade. Despite rapid innovation, the market is far from maturity or the scale needed to support a multi-trillion dollar market cap. Crypto market change has always been grassroots, driven by entrepreneurs and user demand. While this has resulted in some wheel re-invention, the optimistic view is that innovation wins long-term—the crypto sandbox of today is the design of every major market in the future. Historically, the crypto market has been opaque and poorly understood. We hope this essay provides a useful starting point for future dialogue as we build an open and efficient financial system over the coming decade. If you are focused on Market Structure 3.0 (or 4.0+, we won’t discriminate), we’d love to explore it together. Please reach out at any stage, the earlier the better: [arjun@paradigm.xyz](mailto:arjun@paradigm.xyz) ## https://www.paradigm.xyz/writing/escaping-the-dark-forest # Escaping the Dark Forest > On September 15, 2020, a small group of people worked through the night to rescue over 9.6MM USD from a vulnerable smart contract. This is our story. I was about to wrap up for the night when I decided to take another look at some smart contracts. I wasn’t expecting anything interesting, of course. Over the past few weeks I had seen countless yield farming clones launch with the exact same pitch: stake your tokens with us and you could be the next cryptocurrency millionaire. Most were simply forks of well-audited code although some tweaked bits and pieces, sometimes with catastrophic results. But amidst all of the noise there was some code I hadn’t seen before. The contract held over 25,000 Ether, worth over 9,600,000 USD at the time, and would be a very juicy payday for anyone who managed to find a bug in its logic. I quickly looked through the code for where Ether is transferred out and found two hits. One of them transferred the Ether to a hardcoded token address, so that could be ignored. The second was a burn function that transferred Ether to the sender. After tracing the usage of this function, I discovered that it would be trivial for anyone to mint tokens to themselves for free, but then burn them in exchange for all of the Ether in the contract. My heart jumped. Suddenly, things had become serious. Some digging revealed that the contract I had found was part of [Lien Finance](https://lien.finance/)’s protocol. Unfortunately, their team was anonymous! The only IM platform they supported was Telegram, and I couldn’t be sure that the admins of that channel were actually protocol developers or just a few early supporters. The last thing I wanted to do was accidentally leak the exploit to the wrong person. After browsing their website a little while longer, I noticed that they had worked with ConsenSys Diligence and CertiK for an audit. This seemed like a good avenue, since both ConsenSys and CertiK must have interacted with the developers during their audits. I quickly pinged [maurelian](https://twitter.com/maurelian_) on Telegram. ![You never want to be on the receiving end of this message](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--9a8c5fa108/fc6e92d39752664b9335cb9d18a5f89e/asset-https-cdn-sanity-io-images-dgybcd83--9a8c5fa108.png) Unfortunately, time ticked on, my heart kept pounding, but there was no response from maurelian. It seemed like he had already gone to sleep. Desperate, I sent a message to the ETHSecurity Telegram channel. ![Artist's rendering of the message, since I deleted the original](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--ff8a6d8a32/d829751112b2920bc5b2b4008ef2cf46/asset-https-cdn-sanity-io-images-dgybcd83--ff8a6d8a32.png) Within minutes, I got a message from someone I’d worked with quite a few times in the past - [Alex Wade](https://twitter.com/wadealexc). My head had just hit the pillow when I got a knock on my door. It was my roommate: “Sam’s in the ETHSec Telegram asking for anyone from Diligence.” ![It was, in fact, a long night](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--f6a2f48e28/5e4411cdb8aeb08c2cc572a914a1a2db/asset-https-cdn-sanity-io-images-dgybcd83--f6a2f48e28.png) Knowing Sam, this couldn’t be good. I found a channel we’d set up with Lien a few months ago and an email address. Better than nothing, given their team was anon. I was still half asleep. Sam, not wanting to commit details to text, asked for a Zoom call. Groggily wishing I was back in bed, I attempted to gauge the severity of the situation: ![Five minutes later, it was clear that the situation called for coffee](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--e8e611fe8a/f677d0f69095d25be1c2e1810f600e17/asset-https-cdn-sanity-io-images-dgybcd83--e8e611fe8a.png) Sam and I reviewed the code together. By this point, Sam had already prepared a sample exploit and was able to confirm the issue on his machine. The conversation quickly turned to discussing options: 1. Attempt to exploit the issue ourselves. 2. Reach out to Lien and have them go public, urging users to withdraw. Neither of these were appealing options. The first was risky because, as discussed in [Ethereum is a Dark Forest](https://www.paradigm.xyz/2020/08/ethereum-is-a-dark-forest/) by [Dan Robinson](https://twitter.com/danrobinson) and [Georgios Konstantopoulos](https://twitter.com/gakonst/), the possibility of our transactions getting frontrun was very real. The second option was similarly risky, as a public announcement would draw attention to the problem and create a window of opportunity for attackers. We needed a third option. Recalling a section from *Ethereum is a Dark Forest*, Sam reached out to [Scott Bigelow](https://twitter.com/epheph): *If you find yourself in a situation like this, we suggest you reach out to Scott Bigelow, a security researcher who has been studying this topic and has a prototype implementation for a better obfuscator.* After participating in the recovery attempt from *Ethereum is a Dark Forest,* which ultimately lost to front-runners, I was hungry for a re-match. I’ve spent time monitoring front-running and designing a simple system that seemed able to fool generalized front-runners, at least for the $200 I’d been able to test it with. When Sam reached out to me in the late evening with the innocent-sounding “mind staying up for another hour or so”, I couldn’t wait to try it out! I was already working it out: how I’d make a few tweaks, stay up a couple hours, feel a sense of accomplishment having helped rescue and return a few thousand dollars of user funds, and get a good night’s sleep. Those plans immediately fell apart when Sam shared the contract with me: ~25,000 ETH, valued at $9.6M, at stake. For as much as I wanted that rematch, $9.6M was way outside my humble script’s weight class. For the past few months, I had been trying to establish contacts with miners for this very purpose: white-hat transaction cooperation. If ever there was a time to appeal to a miner to include a transaction without giving front-runners the chance to steal it, it was now. Luckily, [Tina](https://twitter.com/tzhen) and I have worked together over the past few months on establishing this cooperation. It seemed like a slim chance at the time, but it was worth a shot: let’s bring Tina into the rescue attempt to work with a mining pool to mine a private transaction. I had just evacuated from the Bobcat forest fire and was sipping on unknown beachy drinks zoning out to the monotonic sound of dark Pacific waves, when a Telegram DM from Sam buzzed me back to a darker reality: “funds at risk, frontrunnable”. Over the last few weeks, I had been collaborating with Sam and Scott on a research project on MEV and could already guess their ask before they sent it: a direct channel to shield a whitehat tx from getting sniped by the “advanced predators” in the mempool’s “dark forest” Since this was a risky move that entailed exposing our strategy to miners, we decided we should first try to get the greenlight from the anonymous Lien team. While Alex was trying to get in contact via ConsenSys-internal channels, we tried to loop in CertiK as well. I realized it may take another 4 hours before Certik's US-based auditors would wake up, yet the clock was ticking. Knowing nothing much about CertiK beyond the fact it had serviced quite a few Asian projects, I tried to reach the CertiK China team to arbitrage the time zone difference. I blasted a casual sounding message in “DeFi the World” and “Yellow Hats” WeChat groups. Four leads slid into my DMs independently within 30 minutes, confirming the WeChat ID that I connected with was indeed the real Zhaozhong Ni, CTO of CertiK. I was added to a WeChat group with 5 CertiK team members, yet at this point I was still not in a position to disclose the project nor the vulnerability. To minimize the exposure and potential liability, we could only invite one member from Certik to join our whitehat operation. After passing a final verification via official email, Georgios Delkos, the engineering lead at CertiK joined our call. With Georgios’s help, Alex was able to quickly get in contact with the Lien team and verify their identity. We brought them up-to-speed on the current situation and asked for their permission to try working directly with a mining pool to rescue the vulnerable funds. After some deliberation, the Lien team agreed that the risk from trying to rescue the funds directly or publishing a warning was too high, and gave the go-ahead to continue. Now we needed to identify a mining pool that had the infrastructure ready in place and would be willing to cooperate with us ASAP. Which mining pool should we tap? Which contact from the pool would be in a position to make technical decisions swiftly that help us beat the clock? SparkPool came to mind, as I knew they had been working on a piece of public infrastructure called Taichi Network that could easily offer what we needed. I decided to ping Shaoping Zhang, SparkPool’s co-founder, who had helped me investigate mempool events in the past. Half an hour later, Shaoping responded: “You mean do we have a whitelist service for transactions? Sorry, we don’t.” Oops, something was lost in translation, “whitehat” and “whitelist” sounded similar in Chinese. “There’s 10mn dollar worth of funds at risk. samczsun is on the line.” I tried again to communicate the situation without revealing any specifics. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--35cf502fb2/b4e56bd07cd7089fe08f9c2a99ce01d4/asset-https-cdn-sanity-io-images-dgybcd83--35cf502fb2.png) “Are you guys saving the world again? Do you need help from our mining pool?” To my surprise and great relief, Shaoping jokingly extended an offer to help. After official email verification, Shaoping popped into our marathon Zoom call with the support of a roomful of SparkPool devs. After lunch, just when I was about to take a nap, I received a message from Tina: “Has SparkPool ever helped with whitehat transactions??” I mistook it for whitelisting a transaction at first. No whitehats had approached us before, and we were not familiar with what “whitehat transactions” entailed. After Tina explained it in more details, I realized that what they needed was a private transaction service, i.e. the whitehats wanted to send transactions to save a DeFi contract, but in order to prevent getting front-runned, they needed a mining pool to include the transaction without broadcasting it. We had been working on a “private transaction” feature on our Taichi Network, which was still under development and had not been tested. I brought the whitehats’ request to our development team, and explained the urgency: our private transaction feature needed to be in production within a few hours. Our devs said they could try their best to finish in time, and we immediately got to work. We finished development of the private transaction feature in 2 hours, and then spent some time fixing bugs. After we completed our internal testing, we sent the *whitehat.taichi.network* endpoint to Scott Bigelow to deliver the whitehat payload. While SparkPool was working to deliver this brand new whitehat API, Sam and I were finishing the script to generate 4 sequential signed transactions. Processing these transactions in order would *not* withdraw the ~25,000 ETH itself, but would transfer 30,000 SBT+LBT tokens (which were “falsely” created) to the Lien team, allowing them to submit the final transaction to convert these tokens back into ETH. By transferring the infinitely mintable SBT+LBT tokens to Lien instead of ETH, we used more transactions to obscure how the attack worked from generalized front-runners (in case of a re-org), and *I was able to avoid incurring $9.6M of income, even if for a moment*. Once we had generated 4 signed transactions, Sam and I spent a long time verifying their combinated behavior using a variety of multi-call transaction simulation tools. These 4 transactions, less than 1.5KB of data in total, were ready to heist $9.6M of assets, so long as no-one but SparkPool sees them until it is too late. I tested SparkPool’s whitehat endpoint with a meaningless transaction, and it worked exactly as expected: the transaction was not seen in the mempool, then suddenly appeared as part of a SparkPool block! It was like watching water vapor turn directly into ice without that *pesky* liquid phase. After adapting the transaction-creation script to feed the transactions directly to SparkPool’s new endpoint, it was time. I hesitated for a moment, but this was absolutely our best effort. We might lose $9.6M, but there would be no regrets: I hit “run” in IntelliJ. I’m not sure why, but I expected it to take a while, like node would understand the gravity of the situation and take its time. It did not; the transactions were sent in a matter of milliseconds. Everyone on the call began refreshing Etherscan with such vigor, I wondered if the Etherscan team would see a 3-minute spike in traffic. Since only SparkPool had the transactions, and only a portion of SparkPool’s hash rate was dedicated to this purpose, there was nothing to do but sweat and wait. Each block that appeared from another miner mocked us. Someone on the call would announce the miner to nervous chuckles. The ~15 blocks it took before our transactions were included felt like hours, but finally, we had our immaculate transactions: mined, in order, not reverted. We watched with relief as more and more blocks were built on top of ours and our concerns about block re-orgs quickly faded. The Lien team was now in possession of enough SBT+LBT tokens to liquidate their entire system, and Sam went to coordinate the final phase of the rescue. Now that we had successfully transferred the tokens to Lien and there was no sign of any frontrunning, attempted or otherwise, we quickly pinged them with the good news. They confirmed that they received the tokens and immediately sent out a transaction to withdraw the bulk of the ether stored in the contract. Seconds later, a pending transaction appeared on Etherscan. As we watched the loading indicator spin, I took the opportunity to reflect upon the events that led to this moment. What had started as a quick glance at some contracts ended up turning into full-blown warroom that pulled in experts from around the world. Without Alex and Georgios, we wouldn’t have been able to make contact with the Lien developer. Without Scott, we would’ve been going into a rescue blind. Without Tina, we wouldn’t have been able to get in contact with CertiK or SparkPool. Without SparkPool, we would’ve been doomed to repeat the history that Dan had written about just weeks ago. And yet on a late Tuesday night, our unlikely group united under a common cause and worked tirelessly to try and ensure that over 9.6 million dollars would be returned to their rightful owners. All of our efforts over the last 7 hours led to this single pending transaction and the spinning dots that came with it. When the loading indicator finally turned into a green checkmark, the tense silence on the call gave way to a collective sigh of relief. ![The Transaction](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--58a771c47a/285b681a1498dd0462812e8387c8e035/asset-https-cdn-sanity-io-images-dgybcd83--58a771c47a.png) *The Transaction* [^1] We had escaped the dark forest. If you’re interested in the technical details behind the exploit, [click here](https://medium.com/lien-finance/interruption-of-service-incident-analysis-32077389c13) to learn more. If for some reason you still haven’t read [*Ethereum is a Dark Forest*](https://www.paradigm.xyz/2020/08/ethereum-is-a-dark-forest/), you should definitely do so too. *Acknowledgments: This post was the culmination of the hard work of many people. Special thanks to Alex Wade, Scott Bigelow, Tina Zhen, Georgios Delkos, and SparkPool for being there when the ecosystem needed you most, as well as Alex Obadia and Dan Robinson for reviewing this post and providing feedback.* [^1]: The transaction ## https://www.paradigm.xyz/writing/ethereum-is-a-dark-forest # Ethereum is a Dark Forest > It’s no secret that the Ethereum blockchain is a highly adversarial environment. If a smart contract can be exploited for profit, it eventually will be. But this unforgiving environment pales in comparison to the mempool. If the chain itself is a battleground, the mempool is something worse: a dark forest. This is a horror story. ## The Challenge Like any normal person, I spend a lot of time lurking in the #support channel of the Uniswap Discord. (Disclosure: [Uniswap](https://uniswap.org/) is a portfolio company of Paradigm.) On Wednesday afternoon, someone asked whether it was possible to recover Uniswap liquidity tokens that had been accidentally sent to the pair contract itself. My initial thought was that the tokens would be locked forever. But late that night, I had the sudden realization that if the tokens were still there, they could be recovered — by *anyone*. When anyone calls the `burn` function on a Uniswap core contract, the contract [measures](https://github.com/Uniswap/uniswap-v2-core/blob/master/contracts/UniswapV2Pair.sol#L140) its own liquidity token balance and burns it, giving the withdrawn tokens to the address specified by the caller. This is a core part of the intended behavior of Uniswap v2 (the basic mechanism is described in section 3.2 of the [Uniswap v2 whitepaper](https://uniswap.org/whitepaper.pdf)). I found the contract. The liquidity tokens were still there—and were worth around $12,000. This meant three things: - There was a ticking clock. Even if nobody else noticed the free money, anyone could remove their own liquidity at any time, accidentally receiving the tokens from the contract. - I could put on my white hat and try to recover the tokens for the person who had accidentally sent them in. It would be as simple as calling the `burn` function on the pool, passing it my own address. - Except… I knew it wouldn’t be simple. ## The Dark Forest It’s no secret that the Ethereum blockchain is a highly adversarial environment. If a smart contract can be exploited for profit, it eventually will be. The frequency of new hacks indicates that some very smart people spend a lot of time examining contracts for vulnerabilities. But this unforgiving environment pales in comparison to the mempool (the set of pending, unconfirmed transactions). If the chain itself is a battleground, the mempool is something worse: a dark forest. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--8cf07ce507/f7ad79cd06811df958665855369794d1/asset-https-cdn-sanity-io-images-dgybcd83--8cf07ce507.jpg) [The Dark Forest](https://en.wikipedia.org/wiki/The_Dark_Forest) is my favorite science fiction book. It introduces the concept of a “dark forest” — an environment in which detection means certain death at the hands of advanced predators. In this environment, publicly identifying someone else’s location is as good as directly destroying them. (This concept is also the inspiration for the [Dark Forest](https://zkga.me/) game on the Ethereum testnet.) In the Ethereum mempool, these apex predators take the form of “arbitrage bots.” Arbitrage bots monitor pending transactions and attempt to exploit profitable opportunities created by them. No white hat knows more about these bots than Phil Daian, the smart contract researcher who, along with his colleagues, wrote the [Flash Boys 2.0](https://arxiv.org/pdf/1904.05234.pdf) paper and coined the term “miner extractable value” (MEV). Phil once told me about a cosmic horror that he called a “generalized frontrunner.” Arbitrage bots typically look for specific types of transactions in the mempool (such a DEX trade or an oracle update) and try to frontrun them according to a predetermined algorithm. Generalized frontrunners look for *any* transaction that they could profitably frontrun by copying it and replacing addresses with their own. They can even execute the transaction and copy profitable *internal transactions* generated by its execution trace. That was why this rescue wasn’t going to be simple. This `burn` function could be called by anyone. If I submitted a transaction calling `burn`, it would be like a flashing “free money” sign pointing directly at this profitable opportunity. If these monsters were really in the mempool, they would see, copy, mutate, and frontrun my transaction, taking the money before my transaction was included. Note how much more brutal this environment is than even the Ethereum blockchain state itself. This free money had been sitting on-chain for about eight hours, undetected, waiting to be swept by anyone who called `burn`. But any attempt to pick it up would get instantly sniped in-flight. ## The Rescue To try to extract the money without alerting the bots, I would need to obfuscate the transaction so that the call to the Uniswap pair couldn’t be detected. This would involve writing and deploying custom contracts. Because I’m a professional DeFi thought leader, I had never actually deployed a contract to Ethereum before. I needed help, and it was past midnight. Luckily, some of the best smart contract engineers I know live in a European time zone. My Paradigm colleague [Georgios Konstantopoulos](https://medium.com/u/4c26a75f4164?source=post_page-----ecc5f0505dff--------------------------------) agreed to help with contract deployment and submitting the transactions. [Alberto Cuesta Cañada](https://medium.com/u/8206cbb70805?source=post_page-----ecc5f0505dff--------------------------------), the lead engineer at another of our portfolio companies, [Yield](https://twitter.com/yield), volunteered to implement the contracts. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--20093a2ce8/e624c26a8ebef1c1815ab3d9fcc2728a/asset-https-cdn-sanity-io-images-dgybcd83--20093a2ce8.gif) Some excellent Ethereum security engineers helped us come up with an obfuscation plan. In addition to burying the call as an internal transaction, we would split the transaction in two: a `set` transaction that activates our contract, and a `get` transaction that rescues the funds if the contract has been activated. This would be implemented as follows: 1. Deploy a `Getter` contract which, when called by its owner, would make the `burn` call ONLY if activated, and otherwise revert. 2. Deploy a `Setter` contract which, when called by its owner, would activate the `Getter` contract. 3. Submit the `set` transaction and the `get` transaction *in the same block*. The code for our custom smart contracts: ```solidity interface IGetter { function set(bool) external; } interface IPool { function burn(address to) external returns (uint amount0, uint amount1); } contract Setter { address private owner; constructor () public { owner = msg.sender; } function set(address getter, bool on) public { require(msg.sender == owner, "no-owner"); IGetter(getter).set(on); } } ``` ```solidity contract Getter is IGetter { IPool private pool; address private setter; address private getter; address private dest; bool private on; constructor(address pool_, address setter_, address getter_, address dest_) public { pool = IPool(pool_); setter = setter_; getter = getter_; dest = dest_; } function set(bool on_) public override { require(msg.sender == setter, "no-setter"); on = on_; } function get() public { require(msg.sender == getter "no-getter"); require(on == true, "no-break"); pool.burn(dest); } } ``` If the attacker only tried executing the `get` transaction, it would revert without calling the `burn` function. We were hoping that by the time the attacker had executed both the `set` and `get` transactions in sequence to spot the internal call to `pool.burn` and frontrun us, our transactions would already be included. To our surprise, the `get` transaction would get rejected by Infura even when we manually overrode the gas estimator. After several failed attempts and resets, the time pressure got to us, and we got sloppy. We let the second transaction slip into a later block. It was a fatal mistake. Our `get` transaction did get included—but with a `UniswapV2: INSUFFICIENT_LIQUIDITY_BURNED` error, meaning the liquidity was gone. It turned out that, in the seconds after our `get` transaction entered the mempool, [someone](https://etherscan.io/tx/0xcc7f752e990b32befa1e0c82b036b3753ec3d876b336007cd568983dca0af497) had executed the call and swept the funds. The monsters had devoured us. ## The Lesson ### Monsters are real We knew intellectually that these generalized frontrunning bots existed. But until you’ve actually seen them in action, you’re likely to underestimate them. We held out some hope that doing the rescue as an internal call via an authorized contract, passing a variable from storage as the `to` address, might protect us. It didn’t. If you find yourself in a situation like this, we suggest you reach out to [Scott Bigelow](https://twitter.com/epheph), a security researcher who has been studying this topic and has a prototype implementation for a better obfuscator. ### Don’t get sloppy Even under time pressure, we should have stuck to the plan. If we had spent more time on the scripts, tweaked the contracts (perhaps changing the `Getter` contract to do nothing instead of reverting if called before being activated), or even synced our own node to avoid using Infura, we probably would have been able to get the transactions into the same block. ### Don’t rely on normal infrastructure The weirder what you’re doing is, the harder it will be to jam it through existing infrastructure like Infura. In our case, we were trying to submit a transaction that looked like it would fail based on the current blockchain state, which Infura has reasonable protections against. Using our own node could have sidestepped this problem. Better yet, if you happen to know a miner (we didn’t), you could have them include the transaction directly in a block, skipping the mempool—and the monsters—entirely. ### The future is only going to get scarier ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--4ea98d0863/42eca3fa8e8970134a8dd5e1c860aefa/asset-https-cdn-sanity-io-images-dgybcd83--4ea98d0863.png) This was just one example of a frontrunning incident. Similar things happen countless times every day. Today, the frontrunners are just bots. Tomorrow, it will be miners. Miners today leave money on the table by not acting on these opportunities. In the future, they *will* reorder and submit transactions in their mempools for their benefit. Even worse, they could reorg blocks mined by other miners, in an attempt to steal MEV which was not claimed by them, resulting in chain instability. We think this future can be prevented, and are excited about several ambitious attempts to do so. [Optimism](https://medium.com/ethereum-optimism) has a vision of how MEV can be redirected for the benefit of the ecosystem, as part of its layer-2 scaling solution, optimistic rollup. [StarkWare](https://medium.com/u/373f5878a0c6?source=post_page-----ecc5f0505dff--------------------------------), in addition to its own layer-2 scaling systems, has built a “verifiable delay function” service called [VeeDo](https://medium.com/starkware/presenting-veedo-e4bbff77c7ae) that could make Ethereum applications immune to this kind of front-running attack. (Paradigm is invested in both Optimism and StarkWare.) If you are thinking about MEV, or building something in this area, please reach out to us! *Acknowledgments: Thanks to Alberto Cuesta Cañada, Scott Bigelow, Phil Daian, Charlie Noyes, and samczsun for discussions that helped inform this post.* ## https://www.paradigm.xyz/writing/crypto-native-insurance # Crypto-native Insurance > Crypto-native insurance has the potential to be the next big financial primitive in DeFi. Crypto-native insurance - on-chain insurance covering protocols and DAOs - has the potential to be the next big financial primitive in DeFi. The market size could be enormous and the initial wedge is credible. Design challenges abound. Whoever solves them can create one of the fundamental building blocks of DeFi, supporting billions in value today, and unlock broader use by increasing the amount of capital users, investors, and traders are willing to commit to the system. As crypto expands into all financial and internet applications, crypto-native insurance has the opportunity to provide a critical service which backs the broader digital economy, supporting trillions tomorrow. **Why crypto-native insurance?** *Trust* DeFi has rapidly grown 10x over the last year from $500m in user funds to $5bn today. Money-losing bugs have occurred amidst this growth and the stakes are increasing. By enhancing trust, insurance can simultaneously enable DeFi to continue its rapid pace of iteration and grow its potential market size. Offering centralized insurance to enhance user trust was an important step we took early in building Coinbase. In 2014 I personally secured the first ever crypto insurance (I believe) from Lloyds of London. The impact was material but not critical for early crypto adopters with high risk tolerance, increasingly important for mainstream users, and a requirement for institutions when they eventually onboarded. Absent speculation, crypto-native insurance is likely to follow a similar adoption arc as centralized crypto insurance. *Speculation* Insurance also creates a prediction market on the likelihood a protocol or DAO will fail. I suspect many crypto traders will love to play in this market, and, like most modern financial markets, speculators will be key in bootstrapping the market and constitute the majority of the volume (for example, in modern foreign exchange markets 95% of volume is speculation, 5% "real flows"). Speculation is societally positive here: it helps bootstrap liquid markets for those seeking "real" coverage and provides a barometer for how safe different DeFi elements are. Through this lens, "insurance" can be thought of as closer to modern credit derivatives products like credit default swaps (CDS). **Wedge: Credible** The combination of users/investors looking for insurance, traders looking to speculate, and longer term investors seeking yield-producing products produces a credible wedge today. With $4.5bn locked in DeFi and insurance covers 5% of the market (the rough ratio in traditional credit markets of insurance total market size), a successful system could see $225m demand today. **Market size: Potentially very large** The market size for crypto-native insurance is hard to estimate as it 1) barely exists today and 2) will probably look very different than traditional insurance products and markets. With that said: *Bottom up* Sustained growth in DeFi would produce a large opportunity alone. If and as crypto expands to become the digital financial system of the world, the opportunity becomes enormous and difficult to estimate. *Top down* The insurance market is $5tn globally today. However, that's inclusive of all types of insurance which are unlikely to be relevant to crypto anytime soon. Credit derivatives are a better comparison. Much like some investors need protection against companies failing, some crypto users will need protection against the on-chain entities they rely on (protocols, DAOs, or otherwise) failing. The credit derivatives market globally is $4.2tn, of which $3.7tn are credit default swaps - the product that may look most similar to a successful insurance offering in DeFi. *Empirical* There are 2 empirical data points in crypto today. First, insurance for centralized crypto companies is in the [high hundreds of millions](https://cointelegraph.com/news/crypto-insurance-a-promising-sector-despite-caution-of-major-players) to [low billions](https://www.coindesk.com/the-crypto-insurance-market-may-total-6-billion-thats-nowhere-near-enough). Second, one crypto-native insurance mutual with manual governance, [Nexus Mutual](https://twitter.com/NexusMutual), has grown from $0.5m in coverage a year ago to ~$15m today. **Hard problems** There are a lot of hard design problems to tackle in building crypto-native insurance, including: - On-chain or off-chain? A successful system is likely programmable, crypto-native, and allows new products to be community driven. For these reasons, this post assumes the winner will be on-chain (protocol and/or DAO-based) vs off-chain (a centralized provider writing cover for crypto-native applications out of band). - Market structure. Modern insurance markets are opaque and dominated by a few large insurers. What will the successful crypto-native insurance landscape look like? A protocol that allows lots of private entities to participate transparently? A DAO or series of DAOs that serve as underwriters? Both? Something totally different? - Liquidity. A successful system allows insurance seekers, traders, and investors to easily bootstrap new markets. This is especially important as insurance is an inherently idiosyncratic and fragmented market. A perpetual swap-like product which allows for easier bootstrapping and avoids fragmentation across multiple expiries (a pitfall with an options-based approach) may accomplish this goal. - What triggers a payout? A successful system should make this as clear as possible. As one example of potential for ambiguity: if a system fails economically but not technically, should that trigger a payout? - Manual or programmatic payout decisions? An ideal system would be entirely programmatic for efficiency, composability, and predictability/clarity. The often weeks long delays in resolving Augur markets through manual payout decisions emphasize the benefits of programmatic payouts. However, it's unclear if this is feasible in practice. What happens if a failure occurs which clearly should trigger a payout but does not? Ironically, it's possible most bugs which insurance is intended to cover in concept are missed in practice if forced to be defined programmatically in advance - otherwise, wouldn't the bug have been discovered and fixed? Concretely, in the words of Vitalik: *“If there was a programmatic oracle IsBroken(x), then the code of x could just be modified to reject all transactions that set IsBroken(x) to true.”* - Ease of creating and evaluating coverage. A successful system makes it easy to write new coverage and to evaluate coverage as an insurance seeker or investor. This is challenging since each smart contract being underwritten, whether a protocol, DAO, other otherwise, is different. Highly technical security auditors may evolve as the evaluators and pricers of risk. - Capital efficiency. A successful system balances capital efficiency with systemic risk. Leverage must exist as full collateralization ($1 needed for every $1 of coverage) is untenably capital inefficient for most investors and traders. On the other hand, high leverage threatens system stability and undermines the point of insurance in the first place. For reference, in outstanding policies are roughly 50x the underlying collateral in traditional insurance markets. Crypto-native insurance will likely start more conservatively as it is significantly less mature and more volatile. - Resilient to manipulation. A successful system minimizes gaming and maintains trust. Traditional CDS markets have had [all sorts of bizarre and unintended outcomes](https://www.bloomberg.com/amp/opinion/articles/2018-12-13/credit-default-swaps-get-weird-after-sears-bankruptcy). - Business model. This is downstream of the product/market structure. The largest traditional insurance companies have market caps >$100bn and margins of ~5%. However, a crypto-native insurance business model probably looks much different. It may be an open protocol which itself has a business model, an underwriting DAO, or something else. And there may be little opportunity to sustainably capture value. A perpetual swap for CDS may be a winning approach across a number of these dimensions, as it could be on-chain, programmatic, able to bootstrap and maintain liquidity, and capital efficient. **Prior work** - [Nexus Mutual](https://twitter.com/NexusMutual): an on-chain insurance mutual/collective. Nexus is governance-driven for payouts, offers fixed duration coverage, uses a native token ([NXM](https://coinmarketcap.com/currencies/nxm/)) for incentives and staking, and only requires partial collateralization due to the mutual's pooled risk model. As previously mentioned, Nexus Mutual has grown from ~[$0.5m to ~$15m](https://defipulse.com/nexus-mutual) in coverage over the last year, is still relatively small compared to the $4.5bn asset base of DeFi, and [has successfully completed one payout](https://www.coindesk.com/defi-insurance-firm-nexus-mutual-makes-its-first-payout-following-bzx-attacks). - [Opyn](https://opyn.co/): options which can act as a form of insurance. Opyn options, expressed via oTokens, have expiry dates (vs perpetual coverage), are on-chain and programmatic, have little/no governance overhead, and provide holistic economic coverage in one sense (options protect downside via the price of a specified asset), but is imprecise in others (e.g. cannot target specific technical failures), and requires full collateralization from options writers. Opyn is young and has low (~$1m) usage today. **Crypto-insurance ends up not materializing. Why?** - Problem space proves intractable. One or more of the hard design problems listed above are not solved and prevent an effective product from proliferating. - Need for insurance eliminated by substitute mechanisms. For example, socialized losses become commonplace (e.g. TheDAO) or protocols/DAOs commonly have insurance-like mechanisms built in (e.g. MakerDAO's MKR dilution in case of undercollateralization). - Need for insurance eliminated by formal verification. Formal verification - the ability to test the boundaries of code - is advancing quickly and is likely to be feels complimentary. However, it's unlikely to be a comprehensive solution, especially to the extent economic vs purely technical failures are covered. **Net: Crypto-native insurance is hard to build but high potential** Crypto-native insurance can produce a valuable service to the community and feels ripe to build today. The problem space is extremely challenging to navigate, but if navigated, has the opportunity to support billions in DeFi today and trillions in global commerce as crypto expands over the coming decades. ## https://www.paradigm.xyz/writing/joining-paradigm-georgios-konstantopoulos # Joining Paradigm > Georgios Konstantopoulos joins Paradigm as a Research Partner. I’m excited to announce that I’m joining [Paradigm](http://twitter.com/paradigm) as a Research Partner to help [Matt Huang](https://twitter.com/matthuang), [Fred Ehrsam](https://medium.com/u/b947efe0a51a?source=post_page-----750e5f178185--------------------------------), [Charlie Noyes](https://medium.com/u/868d3026194c?source=post_page-----750e5f178185--------------------------------), [Dan Robinson](https://medium.com/u/10c4e6618569?source=post_page-----750e5f178185--------------------------------), [Arjun Balaji](https://medium.com/u/215d7482aa0c?source=post_page-----750e5f178185--------------------------------), and the rest of team Paradigm to continue building the best asset management firm in the cryptocurrency industry. In recent months, I spent a lot of time thinking about my longer-term career arc. I’ve worked as a consultant in the cryptocurrency industry for almost three years, working in various roles with many companies, but I wanted to help build something that I could see myself working on for the next ten years. In addition, after spending most of my professional career independently, I was interested in joining a small, but high-powered team. The ideal role would look like a combination of a PhD student’s research, with a consultant’s tactical deployment across mission-critical projects. When I expressed these thoughts to Matt, he soon reached out with a “brainstorm” idea: designing a position at Paradigm which matches my skill set. The more I thought about it, the more excited I got. At Paradigm, I can apply my skills and experience across a variety of projects, alongside a team of similarly motivated investors and world-class entrepreneurs. I have always wanted to work more closely with Dan, with whom I’ve been having discussions around cutting edge cryptocurrency ideas for the last couple of years. I am looking forward to having more access to Charlie’s brilliant mind and Arjun’s wealth of resources and knowledge about finance. But I’m even more thrilled to be joining Matt, and learn from his past investing experience, and Fred, whose contributions to this industry can be compared only with few others’. I will be working closely with our portfolio companies. In particular, I aim to accelerate their technical research and development roadmaps and help design, implement and evaluate mechanisms which will be used to establish and maintain their dominance in the industry. I look forward to continuing my research in cryptography and distributed systems, diving deeper into the decentralized finance ecosystem, and contributing to the long-run security and adoption of Bitcoin and Ethereum. I’d like to thank my past clients for trusting me with their deadlines and the people I interact with daily for contributing to my professional growth. Outside of my professional life, I would like to thank my friends and family for encouraging me to take this opportunity even though moving to the US far away from my home in Greece means that we would no longer spend as much time together. This is a new chapter for me and I cannot wait to see the fruits of this partnership. ## https://www.paradigm.xyz/writing/funding-bitcoin-development # Funding Bitcoin development > Announcing our support for Anthony Towns' work on Bitcoin Core. Significant value is stored in Bitcoin (at $150B+ market cap), yet Bitcoin software is maintained by a relatively small group of developers. Large corporations like Google or Boeing have legions of engineers working on search or autopilot software, but Bitcoin has neither the headcount nor the central coordination. This is by design, of course. Bitcoin is open-source and decentralized. No single entity should control it. But equally, no single entity is responsible for improving it. It is easy for Bitcoin users and companies to free-ride without contributing to Bitcoin development — a classic tragedy of the commons. Today, Bitcoin development relies on volunteers and a handful of groups who fund Bitcoin Core development, including Chaincode, Blockstream, MIT DCI, Square Crypto, Xapo, BitMEX, Okcoin, [and others](https://blog.bitmex.com/who-funds-bitcoin-development/)). Paradigm will now be joining this group. As an investor in Bitcoin and other cryptocurrencies, Paradigm has a vested interest in Bitcoin's success, and we believe it is our responsibility to help fund Bitcoin development. To that end, we are excited to announce that we have started supporting Anthony Towns' work on Bitcoin Core. Anthony Towns has been an active contributor to open source software for over 20 years, beginning with his work on Debian in 1998. Anthony has been contributing to Bitcoin Core since 2017, after learning about Bitcoin via an interest in micropayments and the Lightning Network. Recently, Anthony has been involved in several potential upgrades to Bitcoin, including Schnorr and Taproot. With Paradigm's support, Anthony will continue his work on Bitcoin Core full-time. Paradigm will pay his salary, but Anthony will have complete freedom to choose what he works on. We're excited about the great work Anthony has done and will continue to do in furthering Bitcoin. You can find Anthony on [Github](https://github.com/ajtowns), [LinkedIn](https://au.linkedin.com/in/ajtowns), and [Twitter](https://twitter.com/ajtowns). ## https://www.paradigm.xyz/writing/analysis-of-eip-2593-escalator # Analysis of EIP-2593 (Escalator) > Today, we continue our analysis of blockspace market proposals by looking at EIP-2593, more widely known as “escalating bid algorithm”, or simply “escalator”. It is being advertised as an alternative to EIP-1559 with a big overlap in design goals. Today, we continue our analysis of blockspace market proposals by looking at [EIP-2593](https://github.com/danfinlay/EIPs/blob/Escalator/EIPS/eip-x.md), **more widely known as “escalating bid algorithm”, or simply “escalator”**. It is being **advertised as an alternative to EIP-1559** with a big overlap in design goals. For such a simple proposal, there is a remarkable amount of misconceptions floating around in the public discourse [^1]. In this analysis, we want to focus on the escalator proposal as specified in the EIP itself. With the developers call on blockspace market changes coming up today, we decided to offer our perspective as well. ## What is the escalator proposal? In the escalator proposal, users continue to participate in first-price auctions for blockspace. However, **each transaction has the option of providing parameters for an escalating bid**, creating a time-based auction for block producers to include that transaction. EIP-2593 Introduces the following parameters which must be specified by a user: - START_PRICE: The lowest price that the user would like to pay for the transaction. - START_BLOCK: The first block that this transaction is valid at. - MAX_PRICE: The maximum price the sender would be willing to pay to have this transaction processed. - MAX_BLOCK: The last block that the user is willing to wait for the transaction to be processed in. ## Comparing design goals Both 1559 and 2593 seek to address UX problems in the blockspace market. However, 1559 has three more design goals, which we explain in [our analysis of the proposal](https://insights.deribit.com/market-research/analysis-of-eip-1559/). It (1) implements a slack mechanism, (2) separates Ethereum’s security from transaction fees, and (3) prevents economic abstraction. 2593 is a much narrower proposal, because it does not enable any of these functionalities. This is not a criticism of the proposal itself, but merely a correction on how it is advertised by its supporters (incl. the original EIP). That said, let’s compare them in the area where their goals overlap, by looking at the ways 1559 and 2593 want to implement their respective UX improvements. **EIP-1559**: The mechanism attempts to create a fixed-price sale for blockspace most of the time. The only time a fixed-price sale does not occur is when blocks are near-full (i.e. the slack is exhausted), and the first-price tip auction kicks in. This allows users to make a binary decision whether they want to transact or not rather than expend mental cycles on guessing the correct fee rate. Due to the behavior of the BASEFEE mechanism, the duration of first-price tip auctions is minimized. **EIP-2593**: This mechanism attaches an escalating bid to transactions, to slowly test what the optimal bid is. Starting from a lower fee helps against overpaying, as miners should include the transaction at the minimum price they are willing to accept [^2]. The escalating ensures a transaction is included eventually, assuming it reaches a value that is higher than the gas prices in the network. This helps against underpaying. ## Evaluating escalator algorithms 2593’s small scope makes it relatively straightforward to evaluate. Every user has preferences on two main dimensions: cost, and speed. In a hypothetical world where each user can broadcast a transaction only once, they need to encode both preferences into a single value: their fee rate. Adding an escalator function would add a second dimension to that transaction, as the user can determine the fee in advance for many blocks into the future *assuming the transaction hasn’t been included*. This gives the user more control, and should be a strict improvement over the status quo. In the real world, users can broadcast their transactions as often as they want, but this process carries computational costs for the network and mental and operational costs for users. So the overall logic still holds. Specifically, an escalator is an incremental improvement on the existing first-price auction model (you might call it optimized first-price auction), because it allows users to pre-define their bidding strategy. As a result, it comes into play whenever there is a first-price auction, and the time preference of users is not high. For users with high time preference, it’s easy to see why the proposal can’t change things. If a transaction chases an opportunity that closes within 1-2 blocks (which is the case for all arbitrage transactions, DeFi liquidations, etc.), then there’s simply not enough time for a bidding process to play out. Such transactors are much more afraid of underpayment (missing the cut for the block) than overpayment. As a result, they will continue to add a large margin of safety to their fees. For transactors with lower time preference and higher price sensitivity (which is, as of today, most transactions most of the time), **escalator algorithms are a welcome improvement over the status quo**. As these users can more safely set their bids at the middle to lower range of recently processed transactions, we find it likely that the amount of overbidding for blockspace would decline. Whether that reduces fees for individual users is impossible to say, since any UX gain can also induce demand for further transactions. ## Evaluating the EIP’s analysis The biggest part of the EIP is a scenario-analysis of the current blockspace market mechanism, EIP-1559, and EIP-2593. Further, the author considers two tiers of users (high vs. low time preference) under three different levels of congestion: (1) “blocks that are regularly half full”, (2) “blocks that are regularly less than half full”, and (3) “blocks that repeatedly full in a surprising (“black swan”) series.” This creates 2 x 3 x 3 = 18 different scenarios, which he mentally simulates to find the correct user strategy given their preferences. Finally, he evaluates the outcome for the respective user type. We see several problems with this analysis. **First, in two of the three congestion levels, the escalator simply doesn’t matter**. Whenever blocks are not full, miners will include any transaction paying the minimum fee. This is the same in all proposals, and no first-price auction takes place. Since escalators don’t matter unless there is a first-price auction, it also makes some of the authors’ considerations on the correct user-strategy moot. This part of the analysis can also be ignored on empirical grounds, as block utilization has been high for some time now. For this purpose, we analyzed congestion between January 1, 2020 and today [^3]. After excluding 4% of empty blocks (which were not empty due to lack of demand), 77% of the remaining blocks were at least 95% full, and 86% of blocks were at least 50% full. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--0831276308/ea85176158a6aa0bbf94aeed345e3e92/asset-https-cdn-sanity-io-images-dgybcd83--0831276308.png) Second, the remaining congestion level describes blocks that are repeatedly full as a “surprising series” or even “a black swan”. The rationale behind that is puzzling to us, given that most blocks are full. One explanation is that the author looked at 1559’s proposal to double the blocksize and then always target 50% utilization by changing the BASEFEE. However, such a mechanism where the system pushes blocks to be 50% full does not exist in 2593, and can’t exist because it depends on the existence of a BASEFEE. We give this elastic blocksize as one of the design options uniquely enabled by a BASEFEE-like mechanism. Third, it assumes a first-price auction takes place in EIP-1559 when blocks are half-full or less-than half full (presumably using the tip, but this is not specified further). One of the benefits of 1559 is that it removes the need for first-price auctions most of the time. There is no reason for users to bid more than the minimum fee miners would accept. They are not in competition with any other users for inclusion, since there is always excess blockspace. Maybe the author is worried about bidding wars between wallets on behalf of users, but this also makes no sense, since there is no benefit to bidding more than the minimum and one wallet doesn’t have to worry what another bids. An equilibrium for the minimum tip should emerge based on the binary decision for miners to include a transaction or not. In summary, we find that the analysis either over indexes on unrealistic assumptions (such as empty or half-full blocks) or ignores additional benefits (such as the benefit of a fixed-price sale over a first-price auction). This is not a criticism of the proposal per se, which is a small but solid improvement, but merely of the unnecessarily weak arguments made in its favor. It implies a zero-sum mentality that we don’t see necessary at all. ## Mutually exclusive or complementary? **Escalators improve the way first-price auctions are done today, whereas 1559 tries to minimize the number of first-price auctions that happen in the first place**. When framed like this, it becomes clear that the two proposals are not mutually exclusive, but actually complement each other. You can implement 1559 and then use an escalator for the tip auction whenever it takes place. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--a66e1ef15d/37d9a8ad3ae019bd09b2a71bb5ed5165/asset-https-cdn-sanity-io-images-dgybcd83--a66e1ef15d.png) As we can see in the above diagram, in a world of today + escalator, 100% of blocks still have a first-price auction [^4]. It is only more optimized by the existence of an escalator. In a “naive” 1559, there is a fixed-price sale 95% of the time and an unoptimized first-price auction 5% of the time [^5]. Finally, an escalator would make 1559’s remaining 5% of first-price auctions more efficient. ## Reframing the question of escalator algorithms The strategy employed by the escalator is one that users can use in manual form, which they actively do today. If their transaction is not included at the chosen fee rate, they click “accelerate transaction” in their wallet to broadcast it again with a higher fee rate. **The main benefit of 2593 is internalizing the bumping process for users**. However, there are already companies emerging that do this kind of transaction management professionally for users, such as [any.sender](https://www.anydot.dev/). In theory, nothing prevents this from being implemented in every wallet. So the question isn’t if we should implement 2593, it already is implemented manually by users and automatically by companies and soon probably mainstream wallets. **The question is if it should be done in protocol instead**. ### Arguments for in-protocol escalators - **More reliable**: Extra-protocol implementation requires manual rebroadcasting of the transaction, so there must be an active off-chain actor (like a background process on a wallet, or a dedicated service such as any.sender) - **Less data-intensive**: It allows a single message to encode an escalation strategy vs. the user broadcasting a new message every time to bump the fee [^6]. ### Arguments against in-protocol escalators - **Feature creep on the base layer**: Anything that can be done outside the protocol should be done outside the protocol. - **Worse privacy**: Users reveal their fee preferences and strategy (how much they’re willing to pay) to the entire network compared to a single party. - **Less flexibility**: More elaborate elevator strategies can be implemented outside and there is more competition between providers to find an algorithm that works for users (2593 can be changed while in EIP phase, but not really after it’s live) Different readers will have different views on the weight of these pro and contra arguments. Personally, we strongly believe base layer protocols should be as lean as possible. The opportunity cost of not implementing 2593 is low, given that external options to use escalators are increasingly available. It also depends on adoption. The more users employ a protocol-external escalator, the more transactions have to be rebroadcast. At some point, it becomes attractive to encode these strategies into a single transaction, saving users time and resources. **It could be an attractive middle ground to observe adoption in wallets first, and then internalize the feature when it becomes popular**. ## Conclusion In this analysis, we tried to show that the escalator algorithm has a much smaller, and very different design scope than EIP-1559. It is often described as an alternative, a framing that we strongly disagree with. 2593 has a much smaller scope and even where their goals overlap, the results are difficult to compare (100% first-price auction vs ~5%). Instead, the two proposals complement each other, and we are in favor of both, though not necessarily at the base layer. Escalator algorithms are already used today, both manually by users and internally by firms that transact a lot on Ethereum, and offered by professional services. This proves that escalators are a dominant strategy for users to adopt. Hence, the right question is not whether escalator algorithms are useful, but whether they should be implemented in- or outside the protocol. This concludes our analyses of Ethereum blockspace market proposals. Next, we will turn our attention towards past and future proposals for Bitcoin. *Acknowledgments: *[*Dankrad Feist*](https://twitter.com/dankrad)* and *[*Tim Beiko*](https://twitter.com/TimBeiko) [^1]: Maybe the biggest myth is perpetuated by a recent Ethereum.org blog post: “The main advantage for escalator is that it enables highly efficient price discovery, while at the same time protecting users from over-paying by charging the second price in queue.” This is entirely wrong, as there is no specification about any second price auction in the EIP. In fact, you simply cannot have second price auctions without a fee burn. Otherwise, miners will always fill blocks with their own high gas transactions to prop up the clearing price [^2]: A miner can wait for the escalator to bump the fee, but at the risk of another miner earning that reward [^3]: Specifically from blocks 9195000 to 10324328 [^4]: Technically, there is no first-price auction in blocks that aren’t near-full, as all users can pay the minimum fee. In practice, the protocol has no way of enforcing less than 100% block utilization. [^5]: The 95/5 split is simply used to illustrate a point, it’s impossible to know how frequent first-price auctions would be ahead of time. However, we can get a good instinct by looking at how fast BASEFEE rises whenever blocks are near 20m gas (the only time a first-price auction takes place.) Blocks can only stay there for a short period of time, before BASEFEE pushes them back down violently [^6]: Realistically speaking, we do not expect a fee-bump transaction to be rebroadcast over 5 times. Therefore, the burden of re-signing and re-broadcasting a transaction on the user, the network and other nodes should be negligible ## https://www.paradigm.xyz/writing/creators-communities-and-crypto # Creators, Communities, and Crypto > A discussion between Fred and Blake Robbins on digital creators, communities and crypto. Digital creators have exploded. They are increasingly looking for ways to grow, engage, and monetize their followings. Internet-native communities have also exploded. reddit’s communities have gone from obscure to mainstream. Both the impact and censorship of online communities have reached the highest levels of public discourse - economically, politically, and socially. As a result, creators and communities are looking for new ways to do things. Crypto may be the main source of solutions and innovation for both groups over the coming years. I sat down with Blake Robbins, student of the new wave of content creators and e-sports and partner at Ludlow Ventures, and Jesse Walden, long time thinker at the intersection of internet communities and crypto and founder of Variant, to discuss how crypto can enable creators and communities to do things they may never have expected. Condensed transcript below. **Listen here:** [Spotify](https://open.spotify.com/show/7u1gzOuS7DOTm4fKotk0BA?si=xK3NIBJkTj2Q26dJzF0fhQ) | [iTunes](https://podcasts.apple.com/us/podcast/fred-ehrsam/id1518666851) | [Overcast](https://overcast.fm/+c948EV-Ek) | [Breaker](https://www.breaker.audio/fred-ehrsam/e/65626728) ***Fred***: Hey guys. Glad we finally found time to talk about some of our favorite topics: digital creators, internet communities, and how crypto will change the game for both. *Let's start on the creator side. Blake, you wrote a good blog post a couple of weeks ago describing the current landscape of business models (non-crypto) for creators. Which models are working today?* ***Blake:*** *The biggest model today is advertising. YouTube is the only one that's really nailed the advertising for these creators. Surprisingly, Facebook has not even come close. Then there's brand deals. This is especially interesting in the case of TikTok, where TikTok is positioning to bring these brand deals to creators themselves. For example, TikTok brought Chipotle to (Vlogger) David Dobrik__and were like, “hey, let's do a brand deal on here”. The result was a viral TikTok template where people created their own videos that garnered over 2 billion views. There's affiliate revenue (e.g. Amazon links). Then there's subscriptions, like on Twitch, and the accompanying donations from these platforms. And then there’s merch.* *One area that I think is unexplored and relevant to this conversation is digital merch. What does digital merch look like? Not your avatar wearing a digital shirt. Rather: a badge saying you found this person early. Being able to flex to your friends that you found an artist or a content creator before everyone else - and you can actually prove that through your badge. It’s like the idea behind tour merch - it means you were there early and a real fan. What is the digital equivalent of that?* ***Jesse:*** _I think that last category is very fertile ground and we’ll see tons of experiments there. We’ve seen it in crypto: the social measuring contest is when you bought your first Bitcoin. Everyone wants to stake their claim. A crypto company called Foundation is getting at this. The idea is: you tokenize (create crypto-based tokens representing) creative products of any kind. The platform lets you buy, sell or redeem a token. The result is a liquid marketplace from day one. Both the creator and their fans can benefit from being early in the marketplace or benefit from the secondary market appreciation. It’s one interesting experiment sort of along the lines of what you're describing, where this token is merch. It’s a signifier of being early. And there’s also a financial component to it._ ***Fred:*** *Imagine Yeezy drops being done this way. As we’ve seen with the Chinese versions of sneaker marketplace StockX like Poizon and DoNew, most of the activity comes from people trading the shoes synthetically. Roughly 80% of the sneaker trading volume comes from people who never even take delivery of the shoes or wear them. And it’s a big market: Poizon does over $2 billion a year in volume.* ***Blake:*** *Interestingly, the initial pitch for StockX was that you were never even going to get your physical shoes. An investor friend of mine who saw that pitch was basically like, “I know the new Yeezys are coming out, I know they’re going to go up in price, just let me buy shares in it.”* ***Jesse:*** *The (crypto) ICO boom in 2017 proved this too. People were speculating on ideas rather than delivery of real products.* *Uniswap, a crypto company that you guys \[Paradigm\] invested in, ran exactly this experiment for fun. They created a bunch of physical socks (“Unisocks”) and tokenized them. The crypto tokens are redeemable for the socks and trade on the open crypto market. The socks were launched at $14. They’re now trading for $160 each. So far only 30% of the tokens have been redeemed for the physical socks. There’s been about $130,000 in trading volume on 500 pairs of Unisocks. So about 70% of the volume is speculation vs people “actually buying” the socks. And half the trades are people trading fractional pairs of socks!* ***Fred:*** *It seems like there are two components: financial and social. How important are each of those and which will take off first?* ***Blake:*** *I think it’s almost all social. For most fans it's really about the flex: “I was the first person to be a fan” or “I’m the biggest fan”, and that can be shown in a bunch of different ways. Maybe you get a new badge or achievement when you donate more than $500 to that person. That’s a real flex. They’re clearly a super fan. The social side of it exists because people just want validation. This is how it works on Twitch with subscribers and donations today. This becomes cool because this idea can apply to the broader Internet. Maybe you've bought $1,000 worth of stuff from Adidas. Badges that represent who you are and your purchasing history. It feels like something that is largely unexplored right now on the Internet.* ***Jesse:*** *That makes sense to me. I want to believe that the economic incentives are powerful too. Once given the opportunity to participate economically, it’ll be sort of a zero to one moment where suddenly, the latent demand to participate financially is exposed and everyone wants to do it.* *We saw the financial angle work in the crypto ICO boom. My hypothesis is that given the right tools the financial angle will work in less technical communities too. Platforms can capitalize on this. But I agree: it's not widely understood and there haven't been enough experiments to prove it.* ***Fred:*** *I can't help but wonder if we've seen this movie before in other categories like Bitcoin and the art market. Both started as a community of people who thought an ideology or a work was cool. Those communities grew dramatically, and as they grew, they added the financial elements.* *Bitcoin started as a small and obscure community of people who just thought the idea of digital currency was cool. Obviously Bitcoin was inherently financial in some sense, but it was mostly a social community first - a cypherpunk email list - and then the financial element developed as the phenomeon grew.* *The same thing is true of modern art or art broadly. In the beginning, some artists create art and generally don’t care about money. They probably care about social status. And then there are the people who buy the work at the beginning because they think it's cool. But before you know it, you have hedge fund managers buying art through highly opaque markets and auction systems like Sotheby's for tens or hundreds of millions of dollars.* *And then the funny thing is the financial element becomes a social element: a status symbol. It's what we see in the Hypebeast culture. Is it really about the design of the shoes? Or is it about the fact that you have this ultra rare pair of shoes that's worth $10,000? Whole brands like Supreme and modern artists like Jeff Koons just go straight to this meta dynamic as the “art” itself. The social and financial elements start to interact and turn back on one another.* ***Jesse****: Right. Should we talk specifically about the idea of personal, tradable shares for a person?* *People are running early experiments of this in crypto. The first person I'm aware of to tokenize themselves a web designer named Dapp Boi. His tokens were redeemable for an hour of his time. And you could speculate on the future value of his time as a designer. So you can redeem the token for his time or you could just hold it as a sign of “I was there first”. If he becomes this famous designer, you could cash in on that later.* *Outside of crypto there are other experiments that have been run. Like Mike Merrill, this guy who literally securitized himself so shareholders can vote on life decisions that he makes. Also Spencer Dinwiddie (a star player on the Brooklyn Nets), who is issuing a bond based on his future NBA earnings and sponsorships, kind of similar to \[David\] Bowie Bonds. It's a very explicit financialization of a person.* ***Blake:*** *There’s something to explore there. A lot of these creators need a way to finance their dreams and are taking massive risk when starting out. People could invest to help a creator make something new. Or a creator could auction off the future ad revenue from a YouTube video that’s already out.* ***Fred:*** *I wonder if there are two angles to use crypto in “financing” for creators and communities. One is the traditional financing angle: people need money to create things. The second is that it’s actually all about distribution. Creators or communities often don’t need the money. For example, how much does it cost for Charli D’Amelio, the most popular western TikTok star, to create a video? Next to nothing. What all creators and communities need desperately, however, is a fanbase or community. And if you sell a piece of yourself or your future, that could help create a community around you. Your fans/users become your distribution. Fame is also a self-reinforcing phenomenon. Just like any network effect, getting over that initial chicken and egg hurdle, especially in an algorithmic feed world, is huge.* *I'm curious if you guys have intuitions around how much creators using crypto will skew towards people wanting to raise money vs it being a distribution strategy?* ***Jesse:*** *My intuition is it’s more likely to start with distribution than crowdfunding. There are tools to fund future development or work available to most creators. If you're a musician, you go to a record label and I'm sure there's the equivalent in the influencer world. Competing head to head with existing services is not the way to go. The new cool thing that you can do is like align your community with your success through some distribution of value that's not necessarily in return for direct financial contribution. This is aligned with the recent reddit experiment, where they are giving tokens away to community members rather than raising money.* ***Blake:*** *The financing side of this space is still pretty broken. Almost all of these people take on incredible amounts of risk. Or working jobs then quitting once they get to a certain point. Or just start really young and so they're just like, “OK, I'm going to do this while in high school, and if it works then I stick with it, if not, I'll just do other stuff”.* *I tend to agree though that using it as a mechanism to grow your audience that will hopefully go out and promote you is really valuable. There's an angle where they might already have a thousand diehard fans and it's a matter of: “how do I make sure you get some upside or for promoting me and encouraging everyone to watch this? How do we just make sure we're more aligned?”. This is something that's definitely worth exploring.* ***Jesse:*** *I wonder if it's a question of distribution scale. If you have a lot of distribution, crowdfunding is the way to go. Whereas if you're trying to build distribution, you don't start with crowdfunding. You find some other means to finance yourself and then just build your community by distributing some economic incentives.* ***Fred:*** *Right. There is “reflexive” value in communities around people or ideas: the more people interested in something, the higher the value of the thing (creator, idea, community, etc). Bitcoin is an extreme example but it applies to anything.* *There's a guy named Dan Robinson on our team who asked me if I've read a SciFi book called “The Unincorporated Man”. I said “no, is it worth reading?” And his response was, “Eh, it’s fun but since so few people have read it it is low ROI” And I was like, “Oh, that's really interesting. So books are reflexive? The more people read something the more value it has?” And he said, “Right, true of any book. Part of the value is social signaling. Part of it is creating a common cultural touchstone. The Bible and other religious or cult works are massively reflexive. The money of books. For Dummies books are maximally utilitarian.” So Jesse, to your point, scale breeds further scale. Fame gives the opportunity for bigger fame. Kim Kardashian proved and mastered this.* ***Blake****: I like that, that's cool.* ***Jesse:*** *Yeah, that's trippy. And weird. It makes sense, though. Think about how many people actually tweet the photos of the books they're reading as a way to virtue signal.* ***Fred:*** *How will creator or community crypto tokens start? From existing creators/personalities/ communities that choose to tokenize an already large user base or new upstarts? And how will they evolve?* ***Blake:*** *reddit is fascinating because they're a large existing platform trying to tokenize. But my hunch is that it will be more early/new things. So much of the status and value comes from this social signaling that you were either early or you're the biggest supporter of that person. From that angle there’s less value for someone who already has 20 million subscribers.* ***Jesse:*** *I want to say it'll be new creators. If the creators are already making money, they have little incentive to switch to a new system. Innovator’s dilemma. Maybe like the perfect middle ground is middle class creators that are just getting by and are willing to try new things.* *This gets to another question you raised Fred: how could crypto change the dynamics between communities or creators and platforms?* *What it unlocks is the potential for that community to have autonomy from the platform. In the context of a single creator, they could have some existing leader board that is tied to an existing platform like Twitch. And then, they could bootstrap their community token off of that leaderboard. And then now there's this cross platform asset that could work across platforms. You can start to imbue this community token with all kinds of value that the original platform didn't offer as part of their product experience. You can imagine the same working for bootstrapping tokenized communities off platforms with built in reputation systems like reddit.* ***Fred:*** *So a community can uproot itself from its platform and create its own digital nation. It’s a way for creators to shift power from current platforms and own their distribution/communities more directly.* ***Blake:*** *Yeah, there's probably low hanging fruit within this world. If you can slot into the donation platform for a platform tool like Steam Labs (the donation tool Twitch steamers use) then you can use it to start tokenizing these communities. Imagine if you could take those community tokens elsewhere, whether it's on YouTube or Twitter or other platforms.* ***Jesse:*** *What's nice about Twitch and Stream Labs is they give creators easy templates to monetize their audience. I’ve met a few teams that pitched the idea of helping creators tokenize. And the question I always drill them on is: what are the templates that you're giving creators to make that can be useful across platforms? They probably need a template to get started - they are busy doing other things. Although over time there will probably be innovation on monetization that comes from creators, too.* ***Fred:*** *What types of things might work early on? Jesse, I like your intuition that the early uses cases look like a toy vs being extremely serious/financial. Two main reasons: first, if you go straight to a hardcore tokenization of somebody’s income stream that requires a high level of trust. Questions come up like: who’s auditing the income stream? Whereas with toy use cases, people are comfortable messing around with them and then before you know it, they transition to serious. We probably won’t know what token models will work at the beginning. People will throw spaghetti at the wall and see what sticks, whether it's on the community side or on the creator side. Second, toy use cases probably have fewer legal issues. Does that sound right to you? If so, what are some of the early experiments that are worth running?* ***Jesse:*** *Having a toy is a mental crutch to help people get comfortable with the idea of digital ownership or an economic stake in a creator’s work. And I think once that mental model is established, you can expand. You can tokenize physical products, create markets around them and let people experience ownership as a keystone of the interactive experience with the creator. And then I imagine there's lots of other interesting things that could be tried. Like voting on what the creator should do, i.e. what game the creator should play next.* ***Blake:*** *I think staking money on creators in novel ways can be big. For example: “if you win 10 games in a row, you automatically release the fan’s donation”, or helping them choose thumbnails for their social media and gradually building an “advisory board” of superfans. It could even turn into superfans working for these creators and communities.* ***Fred:*** *Blake, this makes me think of the last category of business models for creators you mentioned: using their platform to start a company. For example, Nadeshot (former Call of Duty pro who started eSports team 100 Thieves). What if these creators could get their communities to crowdfund new companies or products? This happened in crypto with the Ethereum crowdsale in rallying around Vitalik as a creator. Kylie Jenner turned her Instagram follower base into a billion dollar business with Kylie Cosmetics. While building an independent business to monetize is uncommon today, I can't help but wonder if that's the one that generates a lot of value and becomes more common tomorrow.* ***Blake:*** *Yeah, I think the biggest creators will evolve into building their own things. The one weird thing is these people aren't perhaps naturally business savvy. And so, like in Kylie's case, you have to make sure that there's someone really smart behind the scenes who's running it. There’s a lot to explore here. I'm sure if Nadeshot could have gotten money from his fans he would have loved that. The investors would have loved that too. Let's all be aligned. It’s a really cool concept.* ***Jesse:*** *Do you think the concepts of digital scarcity and ownership are important in the creator/gaming worlds? Are they understood?* ***Blake:*** *It's definitely understood in the context of gaming with virtual skins. I think crypto going mainstream likely looks closer to a sticker or something like that vs. “you're buying a token”. Crypto gets to the real critical mass when they don't even necessarily know that they're interacting with it.* ***Fred:*** *Right. One tailwind: mainstream audiences seem to better understand financial mechanics a lot more today than even 5 years ago. That probably helps adoption. I can't help but think about what's happening in Animal Crossing. Even though the economy is closed and kind of comical, two weeks ago there was a change in interest rates on turnips (yes, turnips) by the virtual central bank in the game that produced a massive economic crisis.* *It seems like there are three trends happening here. First, the fact that a casual game like Animal Crossing has these financial gameplay dynamics suggests that people's understanding of financialization has gone up a lot in the last couple of years. If you look at Robinhood activity among millennials and Gen Z's, or you look at the Google searches for day trading, it's a parabolic chart. Second, as we discussed before, if anything becomes big enough (like art), it will get financialized. And finally, technology, especially crypto, is making it easier to financialize anything. So it feels like there's a convergence of a couple of different forces here that are all related.* *Let’s get back to future predictions.__What will the first creator or community + crypto success look like? And secondly, let's say we go 30 years into the future. What crazy thing will come out of this that seems impossible today?* ***Blake:*** *Getting a token that shows you found someone early****.*** *I have a lot of conviction that the social status of being able to prove that you were an early supporter will catch on.* *Looking 50 years in the future and seeing the crazy side of this, I think we will eventually choose people to make famous. People will auction off their coins and people will go in on that person to become famous. Someone super influential might buy in and cosign that person. The person could end up becoming the biggest star in the world because everyone is able to buy a piece. It’s like a human as Bitcoin.* ***Jesse:*** *It's funny - that's already happened in crypto with Sergey Nazarov, the Chainlink CEO. Chainlink is this token that started out completely useless. But this token took on this enormous market cap and the community, mainly from 4chan, followed it and “made” the founder of Chainlink. And then he sort of worked his way into that fame and somehow Chainlink is now building actual functionality by virtue of having the money to go and build.* ***Fred****: I find it interesting that people have this very negative gut reaction to the idea of investing in people. It can sound dystopian: you can “own someone”. I think what people are really negatively reacting to is the inequality of opportunity as exists in society today and how this idea forces us to look directly at that. It's less about the mechanism itself.* *I say this because you guys have just painted the opposite picture: that being able to invest directly in people could allow them to do things they could never do otherwise. It’s similar to loans or venture capital in the real world. It can be predatory, but it also can enable people to do things they could never do otherwise.* ***Jesse:*** *I do think we're going to see a bunch of cool creative products that might have been on Kickstarter but end up getting launched through these dynamically priced markets. And then I think the 50 year future trend is going to be building businesses like 100 Thieves through crowdsourcing around creators or online communities. Pooling resources to build and operate the brand from scratch, completely online. Something completely user operated, where the users are both influencers and creators.* ***Fred:*** *Near term I think people will start to “get credit” on the blockchain for things they do online. This could be what they do in a reddit community, in a video game, in interacting with a DeFi (decentralized finance) application on a blockchain. This is already happening today quietly: everyone who has an Ethereum wallet and interacts with a crypto app is building a history and the start of a crypto-based online identity. And then that identity can start to unlock different things: a loan, which is purely financial, or an entrance into a super secret chat room, which is purely social.* *I think the far future thing that we'll see happen is communities will begin to form like digital nation states. We’ll live in a world where physical domicile matters a lot less and digital presence matters a lot more. Empirically this trend is already happening, and I think crypto can be a game changer in enabling communities to coordinate independent of current platforms, both socially and financially.* *I think we all see the fifty year potential. And then the main practical question is: what is going to work in the next five years and how do we help support that?* ***Jesse****: 100%. I’d love to keep the conversation going. Thanks for putting it together Fred.* ***Blake:*** *Thanks guys.* ## https://www.paradigm.xyz/writing/analysis-of-eip-1559 # Analysis of EIP-1559 > Ethereum improvement proposal (EIP) 1559 will be the largest change to how users bid for blockspace in any of the major blockchains. If implemented, [Ethereum improvement proposal (EIP) 1559](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1559.md) will be the largest change to how users bid for blockspace in any of the major blockchains. While the proposed rules are relatively simple, the proposal would mean significant changes for users, miners, and wallet providers, and even affect the security of Ethereum overall. In this analysis, we untangle the different building blocks of the proposal to make it easier to reason about. We then analyze the proposal against its own design goals. Finally, we look into possible weaknesses. ## Design goals 1. **Better UX**: First price auctions, as used by blockchains like Bitcoin and Ethereum, are easy to understand and implement, but also inefficient. (If you want to learn more, there are good explainers [here](https://haseebq.com/blockchain-fees-are-broken/) and [here](https://ethresear.ch/t/first-and-second-price-auctions-and-improved-transaction-fee-markets/2410)). One of the biggest problems is fee estimation. EIP-1559 seeks to solve this by having all transactions pay the same fee rate, most of the time. Users would have to decide whether to pay the fee or not, but no longer how much to bid. This hopefully leads to lower fees due to better fee estimation. 2. **Slack mechanism**: Demand for blockspace can be volatile. As a result, some blocks are half-full while others are highly congested. A slack mechanism would allow some blocks to be larger, as long as other blocks are smaller. That way we could enforce a longer-term average blocksize limit, but allow for variation across individual blocks. 3. **Better security**: Blockchains that rely only on transaction fees for security (such as Bitcoin in the future) can run into problems when [the block subsidy runs out](https://uncommoncore.co/research-paper-a-model-for-bitcoins-security-and-the-declining-block-subsidy/). If transaction fees are burned, we could extend the block subsidy without increasing the overall coin supply. 4. **Prevent economic abstraction**: When users can pay transaction fees in any token (e.g. stablecoins), this could threaten the reserve status and hence monetary premium of the native token. By demanding that fees must be paid in Ether and then burning them, EIP-1559 seeks to make economic abstraction more difficult. ## How it works ### BASEFEE + Tip As the first building block, a minimum fee called BASEFEE is commanded by the protocol. Minimum fees are usually not enforceable since the protocol cannot prevent external price discovery for transaction inclusion. The protocol can always command a price, but if miners and users agree on a lower price, users can pay miners in-protocol, and miners can refund users off-protocol. EIP-1559 solves this by burning the entire BASEFEE, so it cannot be refunded. Since miners get none of the fee, users must incentivize them in a different way to include their transactions. This brings us to the perspective of users. When submitting transactions, users have to configure two values: First, they determine a GAS_PREMIUM (from now on just called “tip”) as a bid for inclusion. Most often, it must only be high enough to compensate miners for the marginal increase in uncle risk (e.g. 1 Gwei). During times of congestion, it allows for the old first-price auction between transactors. Second, users determine a FEECAP that represents the most they are willing to pay for inclusion (incl. the tip). This is necessary because BASEFEE can actually move up or down, as we will see in a minute, and users who set an insufficient FEECAP should be able to wait for inclusion in a later block. In summary, BASEFEE allows the protocol to enforce a minimum fee without incentivizing the formation of an off-chain market. It serves as a foundation for more flexible blockspace utilization mechanisms, such as uniform price auctions and elastic block sizes. ![](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--d7fe13194e/c8314ef3f723c1cd461b08b8c34fe04e/asset-https-cdn-sanity-io-images-dgybcd83--d7fe13194e.jpg) ### Elastic blocksize cap More flexibility in blocksize is desirable, but allowing an unbounded blocksize has known incentive problems. The ability to drive up uncle rates with larger blocks creates an incentive for miners to centralize. Further, validation costs must be contained [so the network can remain trustless](https://insights.deribit.com/market-research/why-bitcoin-might-not-survive-a-bitcoin-standard/). Here is where elastic block size mechanisms come in. The goal is to allow miners to make larger blocks, but only at a provable cost. Increased orphan rate on its own is not a provable cost, since it can be mitigated by increased centralization, but burning fees in-protocol is. In EIP-1559, miners can periodically exceed the blocksize cap in order to react to burst demand, but will only do so if there is real user demand to pay for it. The BASEFEE primitive discourages miners from propping up their blocks with garbage transactions by introducing a real cost (the fee burn) for doing so. Reacting to burst demand becomes possible because EIP-1559 replaces the existing hard cap on block size with two values: a long-term target of 10m gas per block and a new hard ceiling of 20m gas per block [^1]. Over the long-term, the network adjusts the BASFEE up and down to target the desired average blocksize. While blocks are under the target, the fee decreases over time to encourage demand. While blocks are over the limit, the fee increases over time to discourage demand. The size of the change is determined by the distance from 10m, but is capped at 12.5% in either direction per block. In summary, the BASEFEE adjustment mechanism makes transacting more or less expensive for users to target the desired level of blockspace utilization. ## Expected behavior ### Better UX To evaluate the UX for users and wallet providers, we have to consider the system in different states of congestion. **State of no congestion**: Whenever blocks are below the maximum cap of 20m gas, there is no reason for users to increase their tips beyond the minimum. This remains true even as the BASEFEE adjusts up and down over time. As a result, inclusion in blocks can be entirely determined by BASEFEE. Users who are willing to pay the BASEFEE plus the minimum tip will get into the next block [^2]. Whenever there is no congestion, users can buy blockspace at a fixed price. It’s the same experience as going to Amazon today and seeing a fixed price for the item you want versus having to bid for it in an auction. The user can then either take the deal or leave it. As a result, fee estimation for users and wallets becomes highly predictable. Users can even set their FEECAP lower than the current BASEFEE to wait for inclusion in a later block when fees are lower. **State of occasional congestion**: As blocks above 10M gas are mined, the BASEFEE starts to rise. In fact, it continues to rise until a block with 10M or below gas is mined. If the next block is 10M, the BASEFEE will stabilize at wherever the fee is at right now. If the next block is below 10M, the BASEFEE will start to decline. This is an important realization. If blocks have been above 10m for some time, transacting can get very expensive, and this eventually pushes demand back down. How fast do transaction costs rise? Consider a BASEFEE of 1 billion wei per gas at block 0. At an ETH price of 240, a typical 21k gas transaction costs 0.0005. After only 10 blocks of 20M gas, the transaction will cost 0.02. After 100 blocks, it will cost 657. This is the power of exponential growth. ![Figure 1](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--d7d28db2e0/908c591fa5bea5192563bed949611e83/asset-https-cdn-sanity-io-images-dgybcd83--d7d28db2e0.jpg) As blocks approach the cap of 20M gas, we expect users with urgent transactions to engage in tip auctions because there is no longer a binary way for the protocol to determine priority among them (previously either a user was willing to pay BASEFEE or not). As a result, in times of congestion the protocol falls back to the existing first-price auction model. Even during a tipping auction, the size of BASEFEE remains predictable for transactors. If BASEFEE has a fictitious starting value of 100 at block 0, it can at most go to 100 \* 112.5% at T1, to 100 \* 112.5%2 at T2, to 100 \* 112.5%3 at T3, and so on. The same applies to the case of the decreasing fee. The colored area in Figure 2 illustrates the potential values the BASEFEE may receive in the future blocks based on its initial value (100 in this example). ![Figure 2](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--0d6df4ab83/6aa03b6cfaf1d0bf7de6ac3285d50b98/asset-https-cdn-sanity-io-images-dgybcd83--0d6df4ab83.jpg) **State of extended congestion**: It should be now clear that EIP-1559 allows for larger blocks for a short period of time, but not a longer period. After only 30 min of burst demand, the BASEFEE for a simple 21000 gas transaction will have surpassed $1000 (assuming initial BASEFEE = 1 Gwei). The only way for BASEFEE to return to more “normal” levels is for blocks below 10m to be mined. Imagine there have been 100 blocks with 20m gas in a row. To stick with the previous example, the cost of an average transaction has increased to $657 plus tip. For BASEFEE to return to its starting point, 89 empty blocks must be mined. Alternatively, we can also mine 183 blocks of 5m gas, 371 blocks of 7.5m gas, and so on. ![Figure 3](https://images.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-images-dgybcd83--30259c8ce1/19a13ffb4ffe4f7fc5a47e66612c014a/asset-https-cdn-sanity-io-images-dgybcd83--30259c8ce1.jpg) Hence, a typical pattern under high congestion will be a series of large blocks followed by a series of very small to small blocks. This makes sense, as users with a high time-preference can now get their transactions mined faster. But eventually, the BASEFEE outgrows the demand from transactors, and they have to wait for BASEFEE to come down again. Another way of thinking about this is that the slack mechanism pulls a number of blocks worth of capacity from the near future into the immediate present. But it can’t generate more capacity, eventually the debt has to be repaid. ### Slack mechanism After reviewing how EIP-1559 responds to congestion, we can see that its slack mechanism is closely tied to the maximum amount BASEFEE can change between blocks. The slower it adjusts, the more gracefully the system could handle variations in demand. A common theme for such variations is the cyclicality of the day-night cycle or the weekday-weekend cycle. In its current form, EIP-1559 does not allow for blocks to be larger at night and bigger at days, because these periods are so long that fees would skyrocket into the billions of dollars during the day and equally swiftly fall close-to-zero during the night. Hence the slack mechanism works on the time-frame of minutes to half an hour, but not beyond that. The longer demand pulls the block size into one direction, e.g. towards full blocks, the more violently it is pulled back by the rubberband of a rising BASEFEE. ### Better security Many blockchains have disinflationary monetary policy, meaning the number of new coins they issue goes down over time. When issuance drops low enough, transaction fees are supposed to pay for security. EIP-1559 is not compatible with such a fee-only security model, because the bulk of transaction fees wouldn’t incentivize miners but are burnt instead. Hence, one could say that EIP-1559 assumes a perpetual block subsidy for miners for the protocol to be secure. But the better way of thinking about this would be to say that it makes perpetual block subsidy much more palatable as a design option. The reason is that the fee burn acts as a deflationary force on the coin supply, thereby allowing new coins to be issued elsewhere without inflating the overall supply. Because protocols with perpetual block subsidy generate a more stable income stream for miners, it is fair to say that EIP-1559 has a positive effect on the long-term security and stability of Ethereum. ### Prevent economic abstraction Before EIP-1559, transaction fees technically didn’t have to be paid in ETH. While the network supports only fees paid in ETH, users could in theory pay miners in any currency they want out-of-band. But a miner can also be paid [indirectly via MEV](https://arxiv.org/abs/1904.05234). For example, a miner could include a DEX transaction without any fees because he could make money elsewhere by front-running it. EIP-1559 largely fixes this problem. The BASEFEE part of every transaction is denominated in ETH, and it always gets burned. In that case, ETH is removed from the coin supply, no matter who pays for it. A miner is still free to include lower BASEFEE transactions, but only if he pays the difference from his ETH-denominated block subsidy. The miner earns less ETH in that block, but the user retains more. So for the token supply, it’s a wash. Someone has to pay for the transaction in ETH. We say “largely fixes this problem” because EIP-1559 can prevent economic abstraction of the BASEFEE, but not the tip. Since the tip isn’t burned, the protocol has no way to enforce how or where it is paid. The result is the same kind of off-chain market that is possible pre EIP-1559. However, as we have shown earlier, in most scenarios it is not necessary for users to raise their tips above the minimum. ## Possible problems One major concern with EIP-1559 is whether miners can manipulate the basefee, and whether they want to. When the BASEFEE is zero, miners receive the entire bid from users since there is no burn. Remember also that a tip auction only starts to take place when the demand for blockspace exceeds the available supply. Once fees are near zero, miners would have a simple strategy of keeping them there forever. If they never mine a block above 10m gas, the BASEFEE never increases either. If demand never exceeds 10m (or whatever limit below 10m the miners decided to set), miners will earn the entire fee. However, what is best for miners as a group is not necessarily best for individual miners. This is known as the collective action problem. If blocks are capped at 10m gas, and there is demand to transact for 20m gas, it only takes one miner to break the coalition and include the tip-paying transactions anyway. Turning this into a stable monopoly would require a miner-activated soft fork (MASF). In a MASF, over 50% of the hashrate would pledge to ignore any blocks larger than 10M gas, thereby incentivizing the minority to follow the newly implemented rules. Since this attack vector exists on any network and at all times, we don’t perceive it as an EIP-1559 specific risk at this time. ## Summary We find that EIP-1559 largely holds what it promises. It should make fee estimation much more predictable except for very short periods of high congestion, where the system falls back on the established first-price auction model. These periods are bound to last minutes, because of how BASEFEE rises exponentially to throttle demand. The benefits are made possible by BASEFEE as an interesting building block. Its ability to set minimum fees in the protocol opens a new design space, ranging from elastic blocksize, perpetual block subsidy, better resistance against economic abstraction, to better auction models going forward. EIP-1559 is promising, but that does not mean it is also the best it can be. We only evaluated the existing set of parameters against its self-reported goals. Further research into different configurations of the mechanism would be a good idea. **If you want to replicate our numbers and graphs or run your own experiments, we made our **[**code available on GitHub**](https://github.com/gakonst/eip1559/)**.** *Acknowledgments: *[*Su Zhu*](https://twitter.com/zhusu)*, *[*Patrick McCorry*](https://twitter.com/paddypisa)*, *[*John Adler*](https://twitter.com/jadler0)*, *[*Nick Johnson*](https://twitter.com/nicksdjohnson)*, *[*Dankrad Feist*](https://twitter.com/dankrad)*, *[*Tarun Chitra*](https://twitter.com/tarunchitra)*, *[*James Prestwich*](https://twitter.com/_prestwich)*, and *[*Caleb Tebbe*](https://twitter.com/calebtebbe) [^1]: To prevent feature creep, the specification was recently changed back from hard-coding the 10m/20m limits to retaining the status quo of a miner-voted target X. The ceiling would then automatically update to 2*X. [^2]: There could be an exception depending on how miners decide to order transactions inside a block. If a miner naively optimizes revenue, he might arrange transactions decreasing from the highest tip. As a result, higher tip transactions would be placed higher in the same block than lower tip transactions. As a result, transactions that rely on intra-block priority (such as market making or liquidation services) might continue to engage in tip auctions even when blocks are below capacity. ## https://www.paradigm.xyz/writing/bitcoin-for-the-open-minded-skeptic # Bitcoin for the open-minded skeptic > A discussion on Bitcoin for skeptics. *Originally published as a report for institutional investors: *[*PDF*](https://www.paradigm.xyz/static/Bitcoin_For_The_Open_Minded_Skeptic.pdf) Bitcoin has grown from idea (2008), to working system (2009), to its first real-world use at <$0.01 per coin (2010), to a global currency valued at $8K+ per coin and $150B+ in aggregate (May 2020). Although Bitcoin is empirically one of the best investments of the past decade, it still remains controversial. Is it a new form of money? A speculative bubble? Or a bit of both? Investors have well-established frameworks for evaluating assets like equities, credit, and real estate. But a new *monetary asset* such as Bitcoin appears so infrequently that no clear framework exists. This paper outlines a simple and intuitive framework for Bitcoin as a new monetary asset. ## Why now? In the course of our work, we are often in the position of explaining Bitcoin to investors and institutions approaching it for the first time. Never before have we seen more interest in Bitcoin and its potential as a digital companion to gold. Financial crises stress the limits of existing systems and can highlight the need for new ones. This was true during the financial crisis of 2008 (out of which Bitcoin was born), and it is perhaps more true today with the unprecedented levels of monetary and fiscal stimulus being pursued by governments worldwide. There has been no shortage of writing about Bitcoin over the past 11 years. This paper does not claim any novel insight. Instead, it is a summary of the conversation we often have with investors seeking to understand Bitcoin for the first time. ## Money *The two greatest inventions of the human mind are Writing and Money—the common language of intelligence and the common language of self-interest.* — Mirabea Money is an old and complex idea. Historically, it has taken many forms: from decorative axes and cowry shells to precious metals and representative paper. The last major shift was arguably in the early 1970s with the end of the US gold standard and the beginning of the modern fiat currency system. We can think of money as a competitive market like any other. Gold dominated for centuries not by accident but by possessing important features such as being scarce and unforgeable. Today, fiat currencies dominate largely through local monopoly power, but all monetary assets still compete globally, with gold, US Dollars, and Euros favored as reserve assets. Like written language, money is a protocol standard with immense network effects. A new monetary asset can only emerge if it better fulfills the core functions of money, and it can overcome the adoption hurdle of a new money. We believe Bitcoin offers a compelling answer to both. ## Store of value One of the primary functions of money is to be a store of value: a mechanism to transfer purchasing power across time and geography. All successful money fulfills this function. If a monetary asset loses trust as a store of value, then savings quickly flow elsewhere, as seen in hyperinflationary economies like Venezuela. ## Gold Gold has been trusted as a store of value for millennia. Importantly, the supply of gold on Earth is scarce. Confidence in this scarcity rests in humanity's understanding of nature: that gold cannot yet be cost-effectively synthesized (despite alchemists’ best efforts throughout history). Gold also has many other desirable properties, such as being easy to recognize (no tarnishing), easy to divide, easy to measure (by weight), and easy to verify (through melting), so it is no surprise that gold replaced predecessors to become a global standard. ## Paper currency & the US dollar Paper currencies emerged to simplify the daily use of precious metals as a means of exchange (another core function of money). Although paper notes were initially linked to precious metals, today most paper currencies are free-floating and established by government fiat. The US Dollar is the leading fiat currency and has been the global reserve currency for much of the last century (replacing the British sterling before it). In addition to being a trusted store of value, the US Dollar is the leading means of exchange and unit of account. A significant share of global trade is priced and settled in US Dollars, whether or not the United States is directly involved. Confidence in the US Dollar rests on trust in the government (e.g., to wisely manage its monetary policy). There is great efficiency in placing such trust in a single institution, but there is also risk. Fiat currencies can lose credibility and be devalued through the actions of the government, who in times of crisis may face short-term pressures that outweigh concerns for long-term credibility. Countries like Venezuela offer an extreme precedent for currency value in the face of eroding trust: the currency becomes worthless. Many investors, including central banks, own both gold and US Dollars (or US Dollar-denominated assets) because they offer complementary trade-offs. We can think of the US Dollar as a *centralized* monetary asset, which can be devalued by a single actor, and gold as a *decentralized* monetary asset, which cannot. ## Bitcoin Bitcoin is a new *decentralized* monetary asset, akin to gold. It combines the scarce, money-like nature of gold with the digital transferability of modern currency. Although it remains relatively nascent, Bitcoin has great potential as a *future* store of value based on its intrinsic features. As with any monetary asset, Bitcoin must be scarce, portable, fungible, divisible, durable, and broadly accepted in order to be useful. Bitcoin rates strongly across most of these dimensions, except for broad acceptability: - Scarcity: Bitcoin supply is scarce, and asymptotically approaches 21 million coins. Achieving scarcity in digital form was Bitcoin's great technical breakthrough (building on decades of computer science research). - Portability: Bitcoin is extremely portable, especially relative to gold. Arbitrary amounts of value can be held in a USB stick, or digitally transported across the globe in minutes. - Fungibility: Any two Bitcoins are practically interchangeable, although each Bitcoin has a distinct history on the public ledger. - Divisibility: Each Bitcoin can be divided into 100 million smaller units (called "satoshis"). - Durability: Bitcoins are durable and do not degrade over time. - Broad Acceptability: Bitcoin’s primary weakness: it is far less broadly accepted than gold or US Dollars, although it has made impressive strides over the past decade. We can think of broad acceptability along two dimensions, both of which are important: the % of people who trust and accept Bitcoin, and the % of wealth that trusts and accepts Bitcoin. Beyond these classic monetary features, Bitcoin is also: - Digital: Digital money like Bitcoin is cheaper to store and easier to transfer than gold, which is physically cumbersome. Bitcoin is also instantly verifiable, whereas gold can require a slow and manual verification process. - Programmable: Bitcoin is programmable, which has subtle but far-reaching implications. Today Bitcoin scripting enables applications like escrow or micropayments. Over time we may be surprised by what can be built with Bitcoin (much as we were surprised by the Internet, another programmable substrate). - Decentralized and Censorship-Resistant: The rules of the Bitcoin network (such as its monetary policy) are governed by a decentralized peer-to-peer network, involving a disparate and global user base of consumers, investors, companies, developers, and miners. It is impractical (if not impossible) for a single actor to unilaterally influence the rules of the system. This affords Bitcoin holders a special kind of confidence: that Bitcoin cannot be devalued by arbitrary monetary policy decisions, and that they will always be able to hold and transfer their Bitcoin freely. This could be valuable not just to individuals and companies but also to governments whose foreign currency reserves may be subject to the whims of foreign entities. - Universal: Similar to physical bearer assets like US Dollar bills or gold, Bitcoin is a digital bearer asset that anyone can hold and transfer. The same is not true of digital US Dollars (which require a bank account that supports US Dollars) or digital exposure to gold (which requires a brokerage account). A broadly accepted store of value with the above features would represent a significant improvement over gold, but Bitcoin still lacks broad acceptance and remains nascent as a store of value (as compared to gold's millennia of history and credibility). A better product is not enough—Bitcoin must have a go-to-market strategy to reach broad acceptance. ## Bitcoin as a bubble Since Bitcoin’s inception, many intelligent investors have observed that it appears to be a bubble. They are more right than they know. If we define a bubble asset as one that is *overvalued relative to intrinsic value*, then we can think of all monetary assets as bubble assets. By definition, a store of value is an intermediate asset that people demand, not for its direct utility, but for its ability to be valuable in the future. This value is reflexive: people will believe in a store of value if they expect others to believe in it (who in turn should expect others to believe in it, and so on). This phenomenon is distinct from other asset classes, which have utility-based demand, with speculation occurring around this underlying utility. For monetary assets, the utility is in the collective speculation itself. As Nobel-laureate Robert Shiller observes: *"Gold is a bubble, but it's always been a bubble. It has some industrial uses, but basically it's like a fad that's lasted thousands of years."* This is not an argument against gold (or Bitcoin) as a valuable monetary asset, but an astute insight into the bubble-like, reflexive nature of money. We can think of money as a bubble that never pops (or that hasn’t popped yet) and the value of fiat currency, gold, or Bitcoin as relying on collective belief. Other factors like a government's power, the industrial utility of gold, or the robustness of Bitcoin's codebase can help reinforce this belief, but belief is critical. Such large amounts of value emerging from collective belief may seem circular and non-fundamental. However, there is real value in the social and economic coordination that monetary assets facilitate (much as there is real value in common language). Moreover, such collective belief cannot arise around any arbitrary asset—a successful monetary asset must compete to earn this belief based on intrinsic features. Having superior intrinsic features explains why gold is preferred to silver or fur pelts and Bitcoin is preferred to any number of Bitcoin copycats. ## Bubbles as a go-to-market strategy If Bitcoin succeeds in becoming a trusted store of value, then its end state is to be a bubble. Bubbles are also how Bitcoin gains broader acceptance. Throughout Bitcoin's 11-year history, there have been at least four Bitcoin bubbles of note - 2011: From ~$1 (Apr 2011) to ~$31 (Jun 2011) to ~$2 (Nov 2011) - 2013: From ~$13 (Jan 2013) to ~$266 (Apr 2013) to ~$65 (Jul 2013) - 2013–2015: From ~$65 (Jul 2013) to ~$1242 (Nov 2013) to ~$200 (Jan 2015) - 2017–2018: From ~$1000 (Apr 2017) to ~$19500 (Dec 2017) to ~$3500 (Dec 2018) Each bubble has a familiar pattern. High conviction investors start buying when Bitcoin is boring and unloved. The resulting rise in Bitcoin price attracts media attention, which then attracts investors (or speculators), many with lower conviction and shorter time horizons. This drives the price of Bitcoin higher, which drives further attention and investor interest. This cycle repeats until demand exhausts and the bubble crashes. Although painful for those involved, each bubble leads to broader awareness and motivates Bitcoin's underlying adoption, gradually expanding the base of long-term holders who believe in Bitcoin's potential as a future store of value. This dynamic is evident in the successively higher price floors that Bitcoin reaches during times of maximum disillusionment: ~$2 in 2011, ~$200 in 2015, and ~$3500 in 2018. Broader awareness also encourages the building of Bitcoin infrastructure by startups like Coinbase and incumbents like the CME and Fidelity, further improving Bitcoin's liquidity and utility as a monetary asset. Through successive bubbles, Bitcoin reaches greater levels of scale in users, transaction volumes, network security, and other fundamental metrics. ## The future of Bitcoin As Bitcoin becomes more broadly accepted, what will its future look like? Some wonder whether people will be earning salaries or making everyday payments in Bitcoin. While these behaviors may exist to some degree, Bitcoin seems unlikely to challenge the US Dollar as the leading means of exchange and unit of account (at least anytime soon). Instead, Bitcoin is likely to earn a place alongside gold as a sensible part of many investment portfolios. This has already begun with an early-adopter, tech-forward crowd, and we expect it to grow to include a broader set of investors and institutions over time. Eventually, central banks may come to view Bitcoin as a complement to their existing gold holdings. Ultimately, monetary assets rise and fall on timescales that stretch beyond human lifespans, making them a challenge to forecast. There was a time before the US Dollar reigned when the reserve currency was British, or French, or Dutch, or further into ancient history, Greek or Roman. Similarly, there was a time before the adoption of gold when more primitive forms of money were dominant. The idea of a fiat currency like the US Dollar being untethered to gold is itself a recent phenomenon that seemed unthinkable half a century ago. In the future, it seems likely that the global monetary order could change in ways that would be unthinkable to us today, with digital currencies such as Bitcoin playing a significant role. ## Market size As a decentralized store of value, it is most natural to consider Bitcoin's market size relative to gold, whose aggregate value is estimated to be ~$9T (May 2020) between central bank reserves (17%), private investment holdings (22%), jewelry (47%), and other miscellaneous forms (14%). Some but not all of this value is addressable by Bitcoin. Over time, the market demand for assets like gold and Bitcoin could expand to exceed $9T, especially given the prevailing direction of global monetary policy. According to the IMF, total international reserves reached $13T in 2019 between gold (11%), foreign currency reserves (86%), and IMF-related assets (3%). If foreign governments (some of whom already bristle at their dependence on US Dollar FX reserves) begin to adopt Bitcoin as a complement to existing gold holdings, the market size for Bitcoin could expand significantly. Beyond complementing gold's investment demand, Bitcoin may also address broader store of value markets indirectly. Consider, for example, people who hold fiat currencies with eroding credibility such as the Argentine Peso or the Turkish Lira, but who may have difficulty accessing US Dollars or gold. Or consider various collectibles like art or gemstones, some of which are owned primarily as stores of value. Or consider the empty NYC apartment that is owned by a foreigner interested in storing value outside his or her native country. Bitcoin could plausibly address subsets of these behaviors more effectively. Deferring a precise estimate of market size, we believe it is clear that Bitcoin has significant headroom if it continues to gain broader acceptance. ## Risks Although it has come a long way in 11 years, many risks remain for Bitcoin: - Crossing the Chasm: Bitcoin has gained credibility with early adopters, including some large institutional investors, but it remains niche relative to incumbent monetary assets like gold. There is risk that Bitcoin never achieves the broad acceptance that its proponents hope it will. Of course, therein also lies the opportunity. If Bitcoin were already a broadly accepted store of value, then it would likely be worth orders of magnitude more with relatively little remaining upside. - Volatility: Bitcoin has been (and continues to be) quite volatile relative to US Dollars. There is risk that this volatility limits adoption or prevents investors from considering Bitcoin as a credible store of value. For better or worse, this volatility may be inherent to the process of Bitcoin adoption as natural swings in investor confidence (as faced by any early-stage upstart) are reflected in Bitcoin prices. Bitcoin’s bubble-like adoption process exacerbates this effect. As Bitcoin matures and becomes more broadly accepted as a monetary asset akin to gold, investor confidence and Bitcoin prices should stabilize. - Regulation: Bitcoin is a new currency and payment rail that sits outside of existing systems, posing a potential challenge to existing regulatory frameworks. Similar to early Internet regulation, there is hope that governments pursue nuanced regulation(s) that allow innovative use-cases to prevail. However, there is risk that regulation is onerous and ultimately hinders broader Bitcoin adoption. One mitigating factor is that Bitcoin is a global, decentralized network like the Internet, which is difficult to control for any single government, although governments can plausibly limit access to Bitcoin in various ways. - Technical Risk: The Bitcoin codebase and network have been battle-tested for over a decade, but it continues to evolve and there remain some open questions about how the system might behave in the long run (for example, when the Bitcoin supply approaches its asymptote and miners must be compensated primarily with transaction fees rather than block rewards). - Competitive Risk: Other cryptocurrencies could compete with Bitcoin, as could digital fiat currencies sponsored by governments. Relative to other cryptocurrencies, Bitcoin has a strong first-mover advantage in acceptance, security, and credibility that will be difficult for competitors to overcome. Relative to digital fiat currencies, Bitcoin remains differentiated in its scarce, gold-like nature. Digital US Dollars or digital Renminbi would still be subject to local monetary policy decisions, although they have the benefit that they are currency units people already know and use. - Unknown Unknowns: We must acknowledge that a digital monetary asset such as Bitcoin has never existed before. We are in uncharted territory with more uncertainty than is typical ## Conclusion Bitcoin is a new monetary asset that is climbing an adoption curve. Although it is not yet a broadly accepted store of value, Bitcoin has great potential as a future store of value based on its intrinsic features. Since monetary assets do not arise frequently, Bitcoin is likely to challenge our ordinary intuitions, and it has stirred (understandable) controversy in the investment world. Therein lies the opportunity, of course. We believe Bitcoin offers a compelling risk/reward profile for patient, long-term investors willing to spend the time to truly understand Bitcoin. We hope this paper provides a helpful starting point. ## Acknowledgments This paper benefited from the feedback and contributions of many: - Fred Ehrsam, my partner and co-founder at Paradigm, and our colleagues Alana Palmedo, Arjun Balaji, Charlie Noyes, and Dan Robinson. - Michael Abramson, Alfred Lin, and Kevin Kelly of Sequoia Capital. I’m grateful to them and the rest of my former colleagues at Sequoia Capital for their open-minded interest in Bitcoin circa 2014-2018. - Wences Casares of Xapo, and member of the Board of Directors of Paypal and Libra - Pete Briger and Michael Hourigan of Fortress Investment Group - John Pfeffer of Pfeffer Capital, and formerly of KKR - Micky Malka of Ribbit Capital - Nick Shalek of Ribbit Capital, and formerly of the Yale Investments Office - Steve Lee of Square Crypto, and contributor to Bitcoin Core development - Peter Palmedo of Sun Valley Gold - Tyler Cowen of George Mason University and Marginal Revolution ## Translations - [English \[pdf\]](https://www.paradigm.xyz/static/Bitcoin_For_The_Open_Minded_Skeptic.pdf) - [Chinese \[pdf\]](https://www.paradigm.xyz/static/Bitcoin_For_The_Open_Minded_Skeptic_CN.pdf) ## https://www.paradigm.xyz/writing/7-things-to-read-about-bitcoin-for-institutional-investors # 7 Things To Read About Bitcoin (For Institutional Investors) > Demystifying Bitcoin for a new cohort of investors. After some quiet years, Bitcoin is top of mind again. We recently published a paper ("[Bitcoin for the Open-Minded Skeptic](https://www.paradigm.xyz/static/bitcoin_for_the_open_minded_skeptic.pdf)") to help demystify Bitcoin for a new cohort of investors. Many investors and institutions ask us: what else should we read to get smarter on Bitcoin? Here are some favorites. ### 1. Wences Casares (Mar 2019) Wences is the founder of a Bitcoin wallet company (Xapo) and a board director at Paypal and Libra. Wences saw Bitcoin's potential early and is credited as "Patient Zero" for introducing many investors (especially in Silicon Valley) to Bitcoin. In 2019, Wences finally put his Bitcoin thesis on paper in "[The case for a small allocation to Bitcoin](https://www.kanaandkatana.com/valuation-depot-contents/2019/4/11/the-case-for-a-small-allocation-to-bitcoin)": *Bitcoin is a fascinating experiment but it is still just that: an experiment. As such it still has a chance of failing and becoming worthless. In my (subjective) opinion the chances of Bitcoin failing are at least 20%. But after 10 years of working well without interruption, with more than 60 million holders, adding more than 1 million new holders per month and moving more than $1 billion per day worldwide, it has a good chance of succeeding. In my (subjective) opinion those chances of succeeding are at least 50%. If Bitcoin does succeed, 1 Bitcoin may be worth more than $1 million in 7 to 10 years. That is 250 times what it is worth today (at the time of writing the price of Bitcoin is ~ $4,000).* Wences goes on to poignantly share his personal journey to Bitcoin, after growing up in Argentina and seeing his family lose their entire savings three times: *I grew up in Patagonia, Argentina, where my parents are sheep ranchers. Growing up I saw my family lose their entire savings three times: the first time because of an enormous devaluation, the second time because of hyperinflation and the last time because the government confiscated all bank deposits.* *It seemed like every time we were recovering, a new and different economic storm would wipe us out again. My memory of these events is not economic or financial but very emotional. I remember my parents fighting about money, I remember being scared, I remember everybody around us being scared and returning to desperate, almost animal like behavior. I also remember thinking how unfair it was that these crises hit the poor the hardest.* *People who had enough money to get some US dollars protected themselves that way, people who had even more money and could afford to buy a house or apartment protected themselves that way, and people who had even more money and could have a bank account abroad protected themselves that way. But the poor could not do any of those things and got hit the hardest.* *When I saw the emergence of the Internet I was young and idealistic and I sincerely thought the Internet was going to democratize money and fix money forever. But it has been 30 years since the Internet was created and it has fixed many problems but increasing economic freedom is not one of them.* *I was about to give up hope for the Internet to fix this problem when I ran into Bitcoin by accident. At first I was very cynical but the more I learned about it the more curious I became, after six months of studying and using Bitcoin I decided to dedicate the rest of my career, my capital and my reputation to help Bitcoin succeed.* *Nothing would make me prouder than to be able to tell my grandkids that I was part one of a very large community who helped Bitcoin succeed. And that because Bitcoin succeeded now billions of people can safely send, receive and store any form of money they want as easily as they can send or store a picture. So that what I saw happen to my parents and countless others can never happen again.* \>> [The case for a small allocation to Bitcoin, Mar 2019](https://www.kanaandkatana.com/valuation-depot-contents/2019/4/11/the-case-for-a-small-allocation-to-bitcoin) ### 2. Paul Tudor Jones (May 2020) Paul is one of the most highly regarded macro traders of the past thirty years and the founder of hedge fund Tudor Investment Corporation. In his [May 2020 letter to investors](https://www.scribd.com/document/460382154/May-2020-BVI-Letter-Macro-Outlook), he predicts a "Great Monetary Inflation" and reveals a Bitcoin investment: *But the \[Great Monetary Inflation\] caused me to revisit Bitcoin as an investable asset for the first time in two and a half years. It falls into the category of a store of value and it has the added bonus of being semi- transactional in nature. The average Bitcoin transaction takes around 60 minutes to complete which makes it “near money.” It must compete with other stores of value such as financial assets, gold and fiat currency, and less liquid ones such as art, precious stones and land. The question facing every investor is, “What will be the winner in ten years’ time?”* *At the end of the day, the best profit-maximizing strategy is to own the fastest horse. Just own the best performer and not get wed to an intellectual side that might leave you weeping in the performance dust because you thought you were smarter than the market. If I am forced to forecast, my bet is it will be Bitcoin.* \>> [BVI Letter - The Great Monetary Inflation, May 2020](https://www.scribd.com/document/460382154/May-2020-BVI-Letter-Macro-Outlook) ### 3. Marc Andreessen (Jan 2014) Marc is the cofounder of venture capital firm Andreessen Horowitz (a16z) and previously the cofounder of Netscape, which was pivotal to the rise of the Internet. In 2014, Marc wrote [Why Bitcoin Matters](https://dealbook.nytimes.com/2014/01/21/why-bitcoin-matters/) as an op-ed for The New York Times: *A mysterious new technology emerges, seemingly out of nowhere, but actually the result of two decades of intense research and development by nearly anonymous researchers.* *Political idealists project visions of liberation and revolution onto it; establishment elites heap contempt and scorn on it.* *On the other hand, technologists – nerds – are transfixed by it. They see within it enormous potential and spend their nights and weekends tinkering with it.* *Eventually mainstream products, companies and industries emerge to commercialize it; its effects become profound; and later, many people wonder why its powerful promise wasn’t more obvious from the start.* *What technology am I talking about? Personal computers in 1975, the Internet in 1993, and – I believe – Bitcoin in 2014.* \>> [Why Bitcoin Matters, Jan 2014](https://dealbook.nytimes.com/2014/01/21/why-bitcoin-matters/) ### 4. Bill Miller (Sep 2015, Nov 2017) Bill is the founder of Miller Value Partners, former portfolio manager at Legg Mason Capital Management, and famed value investor. In 2015, Bill wrote about Bitcoin from a value investor's perspective: *Stylized views of value investing often invoke low accounting multiples, but we try to take a broader definition of “value” in our pursuit of assets trading at substantial discounts to their intrinsic value. Our approach is a probabilistic one, meaning that we try to think about various potential states of the future that could affect an asset’s value. We then determine what an asset could be worth under a handful of representative scenarios, multiply each scenario’s value by the probability we think it could occur, and sum up the values to get a “central tendency of value.” Our thought process on Bitcoin is a representative example of our probabilistic value approach, even though the asset may not hit the radar screens of more traditional value investors. So, we will first briefly introduce Bitcoin and then talk about a framework for valuation.* \>> [A Value Investor's Case for... Bitcoin?!, Sep 2015](https://millervalue.com/a-value-investors-case-for-bitcoin/) In 2017, Bitcoin reached new all time highs and elicited vocal skepticism from many. Bill captured this skepticism well and offered his response: *Recently, there’s been an unusual confluence of opinion by some of the world’s best and most sophisticated investors, financial executives and academics about an investment we hold in some client accounts: Bitcoin. Jamie Dimon, Ray Dalio, Howard Marks, Larry Fink, Bob Shiller and Paul Krugman all are on the record with comments on the cryptocurrency. Dimon called it a “fraud” and people who owned it “stupid;” Dalio said it was a “bubble;” Marks referred to it as “an unfounded fad;” Fink said its price was an “index of money laundering;” Shiller said it was the “best example” of a bubble right now; and Krugman had previously proclaimed it “evil.” In a CNBC interview in 2014, Warren Buffett advised investors to stay away from it and called it a “mirage.” He said the idea that it had some “huge intrinsic value” was “just a joke in my view.”* *In general, I think the strongly held negative views on Bitcoin fall under the rubric “new things, old thinking.” Whenever we are confronted by something we haven’t seen before we try to understand it by assimilating it to something we have seen before or that we think we understand. We reason by analogy, or we employ metaphors that seem to fit. Sometimes this is effective, other times not. As we gain greater understanding and experience, our thinking becomes (hopefully) better and more accurate.* \>> [“Certitude is not the test of certainty. We have been cocksure of many things that were not so.” – Oliver Wendell Holmes, Nov 2017](https://millervalue.com/certitude-not-test-certainty/) ### 5. Murray Stahl (Oct 2017) Murray is the founder of Horizon Kinetics, a value-oriented investment adviser. In 2017, Murray wrote about cryptocurrency's potential to protect against long-term erosion of purchasing power: *A major reason that academics and the mainstream investment business do not accept cryptocurrency as legitimate is because modern portfolio theory defines risk as price volatility. Cryptocurrency has been far more volatile than even the most volatile equity class. Yet, in a historical, rather than day to day or year to year context, the great investment issue has never been control of volatility. It has been the retention of purchasing power or, stated differently, defense against the erosion of purchasing power—the contest of unending government efforts to debase the value of money versus the struggles of the citizenry to resist debasement.* *To put this in relatable terms, here are just two examples of the mind-numbingly long history of government monetary policy, domestic and foreign, recent and ancient, to debase their currencies. Over any saver’s lifetime, this can be devastating.* - *The Roman Empire debased its coinage for 2,000 years. As one example, during the 73 years between Marcus Aurelius’s reign ended in 180 CE and the beginning of the reign of Emperor Gallienus, the denarius silver coin was debased from 75% silver to only 5%, by which time the silver was just a surface coating that would wear off. That is 93% depreciation, which works out to about 3.6% per year.* - *Staying with the 73 year timeframe, from 1943 to 2016, the U.S. dollar likewise lost 93% of its purchasing power, based on an annualized inflation rate of just over 3.6%. For most of that period, though, U.S. citizens could earn a comparable yield on their bank deposits or treasury bills, so that purchasing power could be maintained. That’s not been the case over the past ten years, though, since short-term interest rates have been kept near zero; today, money really does earn a negative return.* \>> [Horizon Kinetics - Q3 2017 Commentary, Oct 2017](https://horizonkinetics.com/wp-content/uploads/Q3-2017-Commentary_Final.pdf) ### 6. John Pfeffer (Dec 2017) John is a entrepreneur and investor and previously a partner at KKR for over 10 years. In 2017, John wrote [An (Institutional) Investor's Take on Cryptoassets](https://s3.eu-west-2.amazonaws.com/john-pfeffer/An+Investor's+Take+on+Cryptoassets+v6.pdf): *Blockchain technology has the potential to disrupt a number of industries and to create significant economic surplus. The open-source nature of public blockchain protocols, combined with intrinsic mechanisms to break down monopoly effects, mean that the vast majority of this economic surplus will accrue to users. While tens or perhaps hundreds of billions of dollars of value will also likely accrue to the cryptoassets underlying these protocols and therefore to investors in them, this potential value will be fragmented across many different protocols and is generally insufficient in relation to current valuations to offer a long-term investor attractive returns relative to the inherent risks.* *The one key exception is the potential for a cryptoasset to emerge as a dominant, non-sovereign monetary store of value, which could be worth many trillions of dollars. While also risky, this potential value and the probability that it might develop for the current leading candidate for this use case (Bitcoin) would appear to be sufficiently high to make it rational for many investors to allocate a small portion of their assets to Bitcoin with a long-term investment horizon.* \>> [An (Institutional) Investor's Take on Cryptoassets, Dec 2017](https://s3.eu-west-2.amazonaws.com/john-pfeffer/An+Investor's+Take+on+Cryptoassets+v6.pdf) John also presented his Bitcoin investment thesis at the [2018 Sohn Investment Conference (Youtube)](https://www.youtube.com/watch?v=CeNSoCpA3HM). ### 7. Vijay Boyapati (Mar 2018) Vijay Boyapati was an early Google engineer who wrote "[The Bullish Case for Bitcoin](https://medium.com/@vijayboyapati/the-bullish-case-for-bitcoin-6ecc8bdecc1)" in March 2018. As a self-described adherent to Austrian Economics, Vijay infuses his thesis with ideology not uncommon throughout the Bitcoin community. Although such ideology may or may not appeal to every investor, Vijay nevertheless provides a sharp and thorough overview of Bitcoin and its potential as a new monetary asset. Here's one excerpt on the evolution of money in stages: *There is an obsession in modern monetary economics with the medium of exchange role of money. In the 20th century, states have monopolized the issuance of money and continually undermined its use as a store of value, creating a false belief that money is primarily defined as a medium of exchange. Many have criticized Bitcoin as being an unsuitable money because its price has been too volatile to be suitable as a medium of exchange. This puts the cart before the horse, however. Money has always evolved in stages, with the store of value role preceding the medium of exchange role.* One of the fathers of marginalist economics, William Stanley Jevons, explained that: *Historically speaking … gold seems to have served, firstly, as a commodity valuable for ornamental purposes; secondly, as stored wealth; thirdly, as a medium of exchange; and, lastly, as a measure of value.* *Using modern terminology, money always evolves in the following four stages: collectible, store of value, medium of exchange, and unit of account.* ## https://www.paradigm.xyz/writing/the-yield-protocol-on-chain-lending-with-interest-rate-discovery # The Yield Protocol: On-Chain Lending With Interest Rate Discovery > This paper presents a sketch of a new building block for decentralized finance: yTokens. yTokens are like zero-coupon bonds: on-chain obligations that settle on a specific future date based on the price of some target asset, and are secured by collateral in another asset. Read the paper here: [PDF](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-73b8fb60d5/e3d390f2f4771f48ec3e0ab5dc482032/asset-https-cdn-sanity-io-files-dgybcd83-p-73b8fb60d5.pdf) ## Abstract This paper presents a sketch of a new building block for decentralized finance: yTokens. yTokens are like zero-coupon bonds: on-chain obligations that settle on a specific future date based on the price of some target asset, and are secured by collateral in another asset. By buying or selling yTokens, users can synthetically lend or borrow the target asset for a fixed term. yTokens are fungible and trade at a floating price, which means their “interest rates” are determined by the market. The prices of yTokens of varying maturities can be used to infer interest rates, and even to construct a yield curve. Depending on the target asset, yTokens can settle through “cash-settlement” using an on-chain price oracle, through “physical settlement” in the target ERC20 token, or by synthetically issuing or borrowing the target ERC20 token on another platform. ## https://www.paradigm.xyz/writing/an-analysis-of-uniswap-markets # An analysis of Uniswap markets > Uniswap — and other constant product markets — appear to work well in practice despite their simplicity. In this paper, we give a simple formal analysis of constant product markets and their generalizations, showing that, under some common conditions, these markets must closely track the reference market price. Read the paper here: [PDF](https://arxiv.org/pdf/1911.03380.pdf) ## Abstract Uniswap — and other constant product markets — appear to work well in practice despite their simplicity. In this paper, we give a simple formal analysis of constant product markets and their generalizations, showing that, under some common conditions, these markets must closely track the reference market price. We also show that Uniswap satisfies many other desirable properties and numerically demonstrate, via a large-scale agent-based simulation, that Uniswap is stable under a wide range of market conditions. ## https://www.paradigm.xyz/writing/joining-paradigm-arjun-balaji # Joining Paradigm > Arjun Balaji joins Paradigm as an Investment Partner. I’m excited to announce that I’m joining [Paradigm](https://twitter.com/paradigm)’s investment team to help [Fred Ehrsam](https://twitter.com/FEhrsam), [Matt Huang](https://twitter.com/matthuang), [Charlie Noyes](https://twitter.com/_charlienoyes), and [Dan Robinson](https://twitter.com/danrobinson) build the best asset management firm in the cryptocurrency industry. I’ve had the pleasure of collaborating with the group through the process of testing my own theses over the last couple of years. After leaving every conversation with new perspective, I was convinced I didn’t want to stop talking. As we discussed working together, I was attracted to the team’s intellectual rigor, long-term commitment to the industry, and optimism about the future. My focus will primarily be on cryptocurrency markets and investments in public blockchains. I’ll also be on the hunt for exciting early-stage opportunities. If you’re working on anything I’d find particularly interesting, please feel free to reach out ([arjun@paradigm.xyz](mailto:arjun@paradigm.xyz)). I’m fortunate to have spent the last few years in NYC, one of the greatest cities in the world, but am excited to move to the Bay Area. As I enter my new role, I remain exceptionally grateful to close friends and industry peers who have collaborated with me and helped improve my work over the last several years, including [Nic Carter](https://twitter.com/nic__carter) (Castle Island VC), [Brendan Bernstein](https://twitter.com/bmbernstein) (Tetras Capital), [Miles Suter](https://twitter.com/milessuter) (Cash App), [Murad Mahmudov](https://twitter.com/MustStopMurad) (Adaptive Capital), [Ari Nazir](https://twitter.com/AriMNazir) (Neural Capital), [Yassine Elmandjra](https://twitter.com/yassineARK) (ARK Invest), [Marty Bent](https://twitter.com/martybent) & [Matt Odell](https://twitter.com/matt_odell) (TFTC), [Pratyush Buddiga](https://twitter.com/pratyushbuddiga) (Pic One), [Hasu](https://twitter.com/hasufl) (Uncommon Core), the research team at [The Block](https://theblockcrypto.com/), and countless others. ## https://www.paradigm.xyz/writing/the-rainbow-network-an-off-chain-decentralized-synthetics-exchange # The Rainbow Network: An Off-Chain Decentralized Synthetics Exchange > This paper presents the Rainbow Network, a design for an off-chain non-custodial exchange and payment network supporting any assets for which two parties can agree on a price oracle. Read the paper here: [PDF](https://assets.ctfassets.net/vb2n37v5ldjn/asset-https-cdn-sanity-io-files-dgybcd83-p-035e78d318/c47645183d3495720beef4944bb213a8/asset-https-cdn-sanity-io-files-dgybcd83-p-035e78d318.pdf) ## Abstract This paper presents the Rainbow Network, a design for an off-chain non-custodial exchange and payment network supporting any assets for which two parties can agree on a price oracle. The Rainbow Network allows a user to trade, borrow, lend, and make payments in synthetic assets, entirely off-chain, while having only one on-chain payment channel collateralized by a single asset. ## https://www.paradigm.xyz/writing/joining-paradigm-dan-robinson # Joining Paradigm > Dan Robinson joins Paradigm as a Research Partner. I’m excited to announce that I’m joining [Paradigm](https://twitter.com/paradigm) as a Research Partner, to help [Matt Huang](https://medium.com/@matthuang), [Fred Ehrsam](https://medium.com/@FEhrsam), and [Charlie Noyes](https://medium.com/@csnoyes) build a new kind of investment firm. I’ve always hoped I would get a chance to work alongside Matt, who has been one of my closest friends for almost twenty years, and who first introduced me to Bitcoin six years ago. But I’m equally thrilled to be joining Fred, who has already had a legendary impact on this small industry, and Charlie, one of the sharpest people I’ve ever met. Another thing that drew me to this opportunity is Paradigm’s long-term perspective, and their commitment to pushing the entire industry forward by investing in basic research. In addition to helping Matt, Fred, and Charlie think about investments, an explicit part of my role will be contributing to research and development on open-source protocols and projects. I’m looking forward to continuing to work on Bitcoin, Ethereum, Plasma, Interledger, Ivy, and Stellar, as well as getting to explore other areas more deeply, including decentralized finance, proof-of-stake consensus, and zero-knowledge proofs. If you’re working on something interesting, please reach out to me at [dan@paradigm.xyz](mailto:dan@paradigm.xyz)! I have been blessed to have worked with some extraordinary people at [Chain](https://medium.com/@chaininc) and [Interstellar](https://medium.com/@interstellar) over the past 2.5 years and am beyond grateful for the opportunities [Adam Ludwin](https://medium.com/@adamludwin) and [Jed McCaleb](https://medium.com/@Jed_McCaleb) have given me to work on transformative and cutting-edge projects. Adam, and the company he built, changed my life, and taught me countless lessons that I hope to carry forward. ## https://www.paradigm.xyz/investments # Investments - [Nous Research](https://nousresearch.com/) — Decentralized AI training - [Kalshi](https://kalshi.com/) — Prediction market platform - [Zipline](https://www.zipline.com/) — Autonomous drone delivery infrastructure - [Citadel Securities](https://www.citadelsecurities.com/) — Global market maker - [SendCutSend](https://sendcutsend.com/) — Rapid manufacturer - [Antares](https://antaresindustries.com/) — Factory-produced nuclear microreactors - [True Anomaly](https://www.trueanomaly.space/) — Orbital space defense - [Hyperliquid (HYPE)](https://app.hyperliquid.xyz/) — Financial trading platform - [Coinbase](https://www.coinbase.com/) — Crypto exchange and onchain platform - [Tempo](https://tempo.xyz/) — Blockchain for payments - [Andromeda](https://andromeda.ai/) — AI compute marketplace - [Stripe](https://stripe.com/) — Internet payments infrastructure - [Uniswap](https://uniswap.org/) — Decentralized crypto exchange protocol - [3Jane](https://www.3jane.xyz/) — Credit-backed yieldcoin protocol - [Across](https://across.to/) — Intent-based crosschain bridge - [Agora](https://www.agora.finance/) — Stablecoin issuer and payments infrastructure - [AI Arena](https://aiarena.io/) — AI-powered NFT gaming - [Amber](https://www.ambergroup.io/) — Digital asset platform - [Andromeda](https://andromeda.ai/) — AI compute marketplace - [Antares](https://antaresindustries.com/) — Factory-produced nuclear microreactors - [Argent](https://www.argent.xyz/) — Self-custody wallet - [Axiom](https://www.axiom.xyz/) — ZK proving infrastructure - [Aztec](https://aztec.network/) — Privacy-first Ethereum L2 - [Babylon](https://babylonlabs.io/) — Native Bitcoin staking protocol - [BetDex](https://www.betdex.com/) — Peer-to-peer sports betting exchange - [Bitso](https://bitso.com/) — Latin American crypto financial platform - [Blast](https://blast.io/) — Ethereum L2 with native yield - [Blowfish](https://blowfish.xyz/) — Wallet transaction security APIs - [Blur](https://blur.io/) — NFT marketplace for pro traders - [Chainalysis](https://www.chainalysis.com/) — Blockchain intelligence platform - [Citadel Securities](https://www.citadelsecurities.com/) — Global market maker - [Code4rena](https://code4rena.com/) — Competitive smart contract audits - [Coinbase](https://www.coinbase.com/) — Crypto exchange and onchain platform - [CoinSwitch](https://coinswitch.co/) — Crypto exchange in India - [Compound](https://compound.finance/) — DeFi lending protocol - [Conduit](https://conduit.xyz/) — Rollup deployment platform - [Cosmos (ATOM)](https://cosmos.network/) — Interoperable blockchain ecosystem - [Crown](https://brl.xyz/) — Brazilian real stablecoin issuer - [D3](https://d3.inc/) — Onchain domain infrastructure - [Dework](https://dework.xyz/) — Work and bounty platform - [Divine](https://divine.inc/) — Blockchain-based unsecured lending - [dYdX](https://dydx.exchange/) — Decentralized perpetuals exchange - [El Dorado](https://eldorado.io/) — Cross-border payments for Latin America - [Ellipsis Labs](https://ellipsislabs.xyz/) — Onchain exchange infrastructure - [Etherealize](https://www.etherealize.com/) — Ethereum institutional finance platform - [Euler](https://www.euler.finance/) — Modular DeFi lending protocol - [Exponential](https://exponential.fi/) — DeFi investment platform - [fab2](https://fab2.com/) — Chip manufacturing infrastructure - [Farcaster](https://www.farcaster.xyz/) — Decentralized social protocol - [Fireblocks](https://www.fireblocks.com/) — Digital asset custody infrastructure - [Flashbots](https://www.flashbots.net/) — MEV infrastructure and research - [Fractal](https://www.fractal.is/) — Gaming NFT marketplace - [friend.tech](https://www.friend.tech/) — SocialFi app on Base - [Gauntlet](https://www.gauntlet.xyz/) — DeFi risk management platform - [Genesis Digital Assets](https://genesisdigitalassets.com/) — Bitcoin mining company - [Gitcoin](https://www.gitcoin.co/) — Open-source funding platform - [GTE](https://www.gte.xyz/) — Decentralized global exchange - [Hang](https://www.hang.com/) — Brand loyalty platform - [Harmonic](https://harmonic.fun) — Mathematical reasoning AI lab - [Harmonic](https://harmonic.gg/) — Solana block-building infrastructure - [Hyperliquid (HYPE)](https://app.hyperliquid.xyz/) — Financial trading platform - [Irreducible](https://www.irreducible.com/) — ZK proof acceleration hardware - [Ithaca](https://www.ithaca.xyz/) — Open-source crypto development - [Jambo](https://www.jambo.technology/) — Mobile network for emerging markets - [Kalshi](https://kalshi.com/) — Prediction market platform - [Keep Network](https://keep.network/) — Bitcoin privacy infrastructure - [Kuru Labs](https://linktr.ee/kuru.io) — Onchain orderbook for Monad - [Lido](https://lido.fi/) — Decentralized Ethereum staking protocol - [Lightspark](https://www.lightspark.com/) — Bitcoin payment infrastructure - [Limit Break](https://limitbreak.com/) — Mobile crypto gaming company - [Liquid](https://tryliquid.xyz/) — Mobile-first perps trading - [Lootrush](https://www.lootrush.com/) — Gaming NFT marketplace - [Mad Realities](https://madrealities.xyz/) — Decentralized entertainment network - [Magic Eden](https://magiceden.io/) — NFT marketplace - [Maker (MKR)](https://makerdao.com/) — Stablecoin protocol - [Matrixport](https://www.matrixport.com/) — Crypto financial services platform - [Mesh Connect](https://www.meshconnect.com/) — Seamless crypto payments - [MetaDAO](https://metadao.fi/) — Markets for decision-making - [Monad](https://www.monad.xyz/) — Parallel EVM blockchain - [Moonpay](https://www.moonpay.com/) — Crypto payments infrastructure - [Morpho](https://morpho.org/) — Onchain lending and borrowing - [N3XT](https://n3xt.io/) — Crypto-enabled narrow bank - [Noble](https://www.noble.xyz/) — Stablecoin issuance protocol - [Noise](https://noise.xyz/) — Prediction market for trends - [Nous Research](https://nousresearch.com/) — Decentralized AI training - [O(1) Labs](https://o1labs.org/) — Crypto computing system - [OpenSea](https://opensea.io/) — NFT marketplace - [Optimism](https://www.optimism.io/) — Layer 2 blockchain - [Opyn](https://www.opyn.co/) — DeFi options protocol - [Osmosis](https://osmosis.zone/) — Cross-chain AMM protocol - [Parallel](https://parallel.life/) — Sci-fi NFT card game - [Phantom](https://phantom.app/) — Web3 wallet - [Plural](https://www.pluralfinance.com/) — Tokenized energy asset management - [Privy](https://www.privy.io/) — Embedded wallet infrastructure - [Rain](https://www.rain.com/) — Crypto exchange in EMEA - [Reflexer Labs](https://reflexer.finance/) — Stablecoin protocol - [Revolut](https://www.revolut.com/) — Global digital banking platform - [Ribbon Finance](https://www.ribbon.finance/) — Decentralized structured products - [Rift](https://app.rift.trade/) — Onchain trading protocol - [Royal](https://royal.io/) — Music investment platform - [SendCutSend](https://sendcutsend.com/) — Rapid manufacturer - [Sky Mavis](https://skymavis.com/) — Play-to-earn gaming - [Sorella Labs](https://sorellalabs.xyz/) — Sustainable onchain markets mitigating MEV - [Spacemesh](https://spacemesh.io/) — Blockmesh operating system - [Standard Economics](https://www.standardeconomics.com/) — Cross-border payments app - [Starkware](https://starkware.co/) — ZK-based Layer 2 blockchain - [Stripe](https://stripe.com/) — Internet payments infrastructure - [Succinct](https://succinct.xyz/) — Zero-knowledge infrastructure - [Symbiotic](https://symbiotic.fi/) — Shared security protocol & marketplace - [Synthetix (SNX)](https://synthetix.io/) — Synthetic derivatives protocol - [TaxBit](https://taxbit.com/) — Tax & accounting software - [Tempo](https://tempo.xyz/) — Blockchain for payments - [Trade[XYZ]](https://trade.xyz/) — Decentralized trading platform - [True Anomaly](https://www.trueanomaly.space/) — Orbital space defense - [Uniswap](https://uniswap.org/) — Decentralized crypto exchange protocol - [Utopia Labs](https://utopialabs.com/) — Crypto payments & treasury management - [Vana](https://www.vana.org/) — Network for user-owned data - [Ventuals (formerly Shadow)](http://ventuals.com/) — Perps for private company valuations - [Wildcard](https://www.wildcardgame.com/) — Web3 game - [Yield](https://yieldprotocol.com/) — Decentralized fixed-rate borrowing & lending protocol - [Zcash Open Development Lab](https://x.com/zodl_app) — Zcash developers - [Zipline](https://www.zipline.com/) — Autonomous drone delivery infrastructure - [Zora](https://zora.co/) — NFT-based social platform `Investment disclaimer: The current and historical investments or portfolio companies mentioned, referred to, or described on this page are not representative of all investments in vehicles managed by Paradigm and there can be no assurance that the investments will be profitable or that other investments made in the future will have similar characteristics or results. A list of investments can be found `[`here`](/investment-disclosures)`. Excluded are positions that remain confidential due to competitive considerations or are pending public announcement by portfolio companies, as well as portfolio companies that have shut down without a liquidity event or exit and for which the equity has been written to zero without the corresponding receipt of another asset. Further, the list of investments is updated periodically, and as such may not reflect the most recent Paradigm investments. Past results of Paradigm's investments, pooled investment vehicles, or investment strategies are not indicative of future results. ``The liquid token positions presented reflect certain holdings of Paradigm's closed-end funds and are provided for informational purposes only. Position sizes fluctuate and are subject to change without notice. Nothing contained on this page or Paradigm's social media constitutes, or should be construed as, an offer to sell or a solicitation of an offer to buy any security, or as investment advice.` ## Careers We don't just fund the frontier — we build it. Paradigm incubates projects from the ground up, working shoulder-to-shoulder with founders and researchers to turn early ideas into the protocols and companies that define what comes next. [All Careers](/careers) ## https://www.paradigm.xyz/team # Team ## Investing & Research - [Matt Huang](https://www.paradigm.xyz/team/matt-huang) — Co-Founder & Managing Partner - [Alana Palmedo](https://www.paradigm.xyz/team/alana-palmedo) — Managing Partner - [Dan Robinson](https://www.paradigm.xyz/team/dan-robinson) — General Partner - [Georgios Konstantopoulos](https://www.paradigm.xyz/team/georgios-konstantopoulos) — General Partner & CTO - [Frankie](https://www.paradigm.xyz/team/frankie) — General Partner - [Alpin Yukseloglu](https://www.paradigm.xyz/team/alpin-yukseloglu) — Partner, Investing & Research - [Arjun Balaji](https://www.paradigm.xyz/team/arjun-balaji) — Partner, Investing & Research - [Ricardo de Arruda](https://www.paradigm.xyz/team/ricardo-de-arruda) — Partner, Investing & Research - [Calvin Zeng](https://www.paradigm.xyz/team/calvin-zeng) — Partner, Investing & Research - [Storm Slivkoff](https://www.paradigm.xyz/team/storm-slivkoff) — Research Partner - [Justin Wang](https://www.paradigm.xyz/team/justin-wang) — Research Partner ## Operations Leads - [David Swain](https://www.paradigm.xyz/team/david-swain) — Chief Marketing Officer - [Katie Biber](https://www.paradigm.xyz/team/katie-biber) — Chief Operating Officer - [Jordan Qualls](https://www.paradigm.xyz/team/jordan-qualls) — Chief Financial Officer - [Alex Popescu](https://www.paradigm.xyz/team/alex-popescu) — Chief Compliance Officer - [Alex Grieve](https://www.paradigm.xyz/team/alex-grieve) — VP of Government Affairs - [Veit Moeller](https://www.paradigm.xyz/team/veit-moeller) — VP, Brand & Design - [Stefan Schropp](https://www.paradigm.xyz/team/stefan-schropp) — Senior Regulatory Counsel - [Ben Hinshaw](https://www.paradigm.xyz/team/ben-hinshaw) — Deputy General Counsel - [Rama Somayajula](https://www.paradigm.xyz/team/rama-somayajula) — Head of Trading - [Chris Kraeuter](https://www.paradigm.xyz/team/chris-kraeuter) — Head of Communications - [Dan McCarthy](https://www.paradigm.xyz/team/dan-mccarthy) — Head of Talent - [Josie Franciose McGuinn](https://www.paradigm.xyz/team/josie-franciose-mcguinn) — Head of Events - [Pam Tholen](https://www.paradigm.xyz/team/pam-tholen) — Head of Investor Relations - [Lindsay Slocum](https://www.paradigm.xyz/team/lindsay-slocum) — Investor Relations Lead - [Dominique Little](https://www.paradigm.xyz/team/dominique-little) — Government Affairs Lead ## Collaborators - [Fred Ehrsam](https://www.paradigm.xyz/team/fred-ehrsam) — Co-Founder & Senior Advisor - [Caitlin Pintavorn](https://www.paradigm.xyz/team/caitlin-pintavorn) — Venture Partner - [Justin Slaughter](https://www.paradigm.xyz/team/justin-slaughter) — Senior Advisor - [transmissions11](https://www.paradigm.xyz/team/transmissions11) — Research Associate - [Ciamac Moallemi](https://www.paradigm.xyz/team/ciamac-moallemi) — Research Advisor - [Cobie](https://www.paradigm.xyz/team/cobie) — Advisor ## https://www.paradigm.xyz/frontiers-2026 # Frontiers 2026 ## Speakers Meet the Frontiers 2026 speakers. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. - Christian Legnitto — @LegNeato — VectorWave - Dan Robinson — @danrobinson — Paradigm - Daniel Couser — @0xKitsune — Tempo - Georgios Konstantopoulos — @gakonst — Paradigm - Guillermo Rauch — @rauchg — Vercel - Jacob Thornton — @fat — Pierre Computer - Suraj Nair — @SurajNair_1 — Physical intelligence - Quinn Slack — @sqs — Amp - Johannes Hagemann — @JohannesHa — Prime Intellect - Pat O'Grady — @patrick-ogrady — commonware - Sam Herring — Nous Research ## https://www.paradigm.xyz/writing # Writing - [RSI Simulator](https://www.paradigm.xyz/writing/rsi-simulator) — An interactive web game and model explorer from Paradigm that demonstrates the economics of recursive self-improvement and AI R&D. - [Announcing Our Fourth Fund](https://www.paradigm.xyz/writing/announcing-our-fourth-fund) — Paradigm has raised our fourth fund: $1.2B to back the most ambitious builders at the frontier of technology. - [Introducing EVMbench](https://www.paradigm.xyz/writing/evmbench) — Paradigm and OpenAI build EVMbench as an open evaluation framework that tests AI agents across detecting, patching, and exploiting vulnerabilities. - [Tempo: The Blockchain Designed for Payments](https://www.paradigm.xyz/writing/tempo-payments-first-blockchain) — The payments-first blockchain incubated by Stripe and Paradigm - [Paradigm Comments on SEC and CFTC’s Joint Reporting and Definition Requests](https://www.paradigm.xyz/writing/paradigm-comments-on-sec-and-cftc-s-joint-reporting-and-definition-requests) — Paradigm encourages holistic review and agency alignment between CFTC and SEC regarding swaps. - [GPU World](https://www.paradigm.xyz/writing/gpu-world) — GPU World: A story competition from Neal Stephenson, Gwern, and Matt Huang. What if the world had one GPU per person? $100K in total prizes. - [Joining Paradigm](https://www.paradigm.xyz/writing/joining-paradigm-calvin-zeng) — Calvin Zeng Joins Paradigm - [RSI Simulator](https://www.paradigm.xyz/writing/rsi-simulator) — An interactive web game and model explorer from Paradigm that demonstrates the economics of recursive self-improvement and AI R&D. - [Centaur 2.0: Permissions, Context, and MCP](https://www.paradigm.xyz/writing/centaur-2-0-permissions-context-and-mcp) — We’re launching Centaur 2.0 with better permissions, broader tool access, and a faster, more reliable foundation. - [Joining Paradigm](https://www.paradigm.xyz/writing/joining-paradigm-justin-wang) — Justin Wang joins Paradigm as a Research Partner - [Paradigm Files Comment Letter on Binary KPI Options Proposal](https://www.paradigm.xyz/writing/paradigm-files-comment-letter-on-binary-kpi-options-proposal) — Paradigm urges SEC to complete holistic review process with CFTC before making decision on binary KPI options proposal - [Paradigm Files Comment Letter on the CFTC’s Prediction Markets NPRM](https://www.paradigm.xyz/writing/paradigm-files-comment-letter-on-the-cftc-s-prediction-markets-nprm) — Paradigm supports gaming framework; encourages additional clarifications - [Formally Verifying a Compiler Using Automated Research](https://www.paradigm.xyz/writing/solidus) — We formally verified a compiler using Lean and are launching two new challenges to improve it, as an experiment in collaborative research. - [Paradigm Files Comment Letter on the NCUA’s GENIUS Act Stablecoin Rulemaking](https://www.paradigm.xyz/writing/paradigm-files-comment-letter-on-the-ncuas-genius-act-stablecoin-rulemaking) — Paradigm raises key issues for credit union-affiliated stablecoin issuers - [Paradigm Backs Michael Lewellen on Appeal to the Fifth Circuit](https://www.paradigm.xyz/writing/paradigm-backs-michael-lewellen-on-appeal-to-the-fifth-circuit) — Paradigm pushes back on threats to non-custodial software developers - [Announcing Our Fourth Fund](https://www.paradigm.xyz/writing/announcing-our-fourth-fund) — Paradigm has raised our fourth fund: $1.2B to back the most ambitious builders at the frontier of technology. - [Paradigm Backs Kalshi in Latest Prediction Market Challenge](https://www.paradigm.xyz/writing/paradigm-backs-kalshi-in-latest-prediction-market-challenge) — Paradigm files Sixth Circuit amicus brief against Tennessee overreach - [Project Kryptos](https://www.paradigm.xyz/writing/kryptos) — Paradigm is now the steward of the solution to Kryptos, one of the last great cryptography puzzles — but it's a secret, even to us. Now we’re looking for more people to try to find the solution. - [Paradigm Files Comment Letter on FinCEN and OFAC’s GENIUS Act Rulemaking](https://www.paradigm.xyz/writing/paradigm-files-comment-letter-on-fincen-and-ofacs-genius-act-rulemaking) — Paradigm urges tailored sanctions compliance framework - [Paradigm Files Comment Letter on the FDIC’s GENIUS Act Stablecoin Rulemaking](https://www.paradigm.xyz/writing/paradigm-files-comment-letter-on-the-fdics-genius-act-stablecoin-rulemaking) — Paradigm raises key issues on the FDIC’s framework for stablecoin issuers. - [The Political Number We’ve Been Missing](https://www.paradigm.xyz/writing/the-political-number-weve-been-missing) — Kalshi’s American Power Index (KPOW) finally provides an easy way to know in real time which way the wind is blowing in American politics. - [Stablecoins are Global - Paradigm’s Response to FCA 26/13](https://www.paradigm.xyz/writing/stablecoins-are-global-paradigms-response-to-fca-26-13) — The FCA’s latest crypto perimeter guidance is intended to bring clarity to the U.K.’s digital asset regime. We explain how parts of the proposal could fragment global markets and how the FCA can avoid it. - [Paradigm Files Comment Letter on Treasury’s GENIUS State Pathway Rulemaking](https://www.paradigm.xyz/writing/paradigm-files-comment-letter-on-treasurys-genius-state-pathway-rulemaking) — Paradigm raises critical issues on pivotal stablecoin rulemaking - [Open Sourcing Centaur: Multiplayer, self-hosted, secure agents](https://www.paradigm.xyz/writing/open-sourcing-centaur-multiplayer-self-hosted-secure-agents) — Paradigm and Tempo open source Centaur, a Slack-native multiplayer, self-hosted and secure agent for investing, building, and researching. - [Paradigm Files Comment Letter on the OCC’s GENIUS Rulemaking](https://www.paradigm.xyz/writing/paradigm-files-comment-letter-on-the-occ-s-genius-rulemaking) — Paradigm raises critical issues on pivotal stablecoin rulemaking - [PACTs: Protecting Your Bitcoin From a Quantum Sunset](https://www.paradigm.xyz/writing/pacts-protecting-your-bitcoin-from-a-quantum-sunset) — A possible way for Bitcoin holders to protect themselves from having their funds frozen in an emergency post-quantum hard fork—without having to publicly move their coins. - [Paradigm Files Comment Letter on the CFTC’s Prediction Markets Rulemaking](https://www.paradigm.xyz/writing/paradigm-files-comment-letter-on-the-cftc-s-prediction-markets-rulemaking) — Paradigm supports CFTC’s engagement and urges additional clarity - [Paradigm Backs Kalshi in Latest State Overreach](https://www.paradigm.xyz/writing/paradigm-backs-kalshi-in-latest-state-overreach) — Paradigm files amicus brief in support of Kalshi in Commonwealth of Massachusetts v. KalshiEX LLC - [Introducing the 2026 Paradigm Fellowship](https://www.paradigm.xyz/writing/introducing-the-2026-paradigm-fellowship) — Applications are open for the 2026 Paradigm Fellowship. Four days, ~30 people, Northern California. August 12–15. - [Paradigm Files Comment Letter on NCUA’s GENIUS Rulemaking](https://www.paradigm.xyz/writing/paradigm-files-comment-letter-on-ncua-s-genius-rulemaking) — Paradigm weighs in on opening GENIUS proposal for credit unions - [Releasing Reth 2.0!](https://www.paradigm.xyz/writing/releasing-reth-2-0) — Reth is now faster, smaller, and ready for the next frontier of crypto infrastructure. - [An Interactive Guide to GENIUS Implementation](https://www.paradigm.xyz/writing/an-interactive-guide-to-genius-implementation) — The GENIUS Act is law. We built a real-time tracker for what comes next. - [Paradigm Files Ninth Circuit Amicus in New Front of Prediction Market Battle](https://www.paradigm.xyz/writing/paradigm-files-ninth-circuit-amicus-in-new-front-of-prediction-market-battle) — Paradigm Files Amicus Brief Opposing New Front of Attacks on Federal Regulation of Prediction Markets - [Paradigm February 2026 Poll on Prediction Markets](https://www.paradigm.xyz/writing/paradigm-february-2026-poll-on-prediction-markets) — Over a third of Americans are using prediction markets in some way. Our new poll delves into what is driving the growth of this space and how Americans feel about the rise of prediction markets. - [Introducing EVMbench](https://www.paradigm.xyz/writing/evmbench) — Paradigm and OpenAI build EVMbench as an open evaluation framework that tests AI agents across detecting, patching, and exploiting vulnerabilities. - [Green Mining, Stable Grids: Clarifying Misconceptions about Bitcoin Mining](https://www.paradigm.xyz/writing/clarifying-misconceptions-about-bitcoin-mining) — Bitcoin mining uses abundant, often renewable, and off-peak electricity to stabilize the grid and lower costs. Policymakers should treat it as an energy asset, not an energy threat. - [Getting the Details Right: Paradigm’s Response to the FCA and Bank of England](https://www.paradigm.xyz/writing/paradigms--response-to-the-fca-and-bank-of-england) — The Bank of England and FCA need to fix key design flaws in their crypto framework. Paradigm's response identifies where rigid rules risk leaving the U.K. behind. - [Introducing Paradigm Predictions](https://www.paradigm.xyz/writing/introducing-paradigm-predictions) — Paradigm Predictions is a tool for exploring the landscape of prediction markets. We aim to make prediction market data intuitive, accessible, and easy to explore. - [Paradigm Files Ninth Circuit Amicus Brief to Oppose State Encroachment on Federal Regulation](https://www.paradigm.xyz/writing/paradigm-files-ninth-circuit-amicus-brief-to-oppose-state-encroachment-on-federal-regulation) — The Ninth Circuit should follow the clear statutory text and historical record. Federal law governs these markets, full stop. Allowing states to override that judgment would undermine regulatory certainty, stifle innovation, and unravel a system Congress carefully constructed. - [Joining Paradigm as Head of Trading](https://www.paradigm.xyz/writing/joining-paradigm-rama-somayajula) — Rama Somayajula joins Paradigm as Head of Trading - [Paradigm Files Comment with Banking Regulators on Safety and Soundness Standards](https://www.paradigm.xyz/writing/paradigm-files-comment-with-banking-regulations-on-safety-and-soundness-standards) — Regulators should look to the statutory text and not subsequent commentary when defining what is a safe and sound practice. - [Data Banishes Fear](https://www.paradigm.xyz/writing/data-banishes-fear) — A new report on how stablecoins interact with the banking system and credit creation suggests stablecoins will be positive for the banking system and credit provision on net. - [Polymarket Volume Is Being Double-Counted](https://www.paradigm.xyz/writing/polymarket-volume-is-being-double-counted) — After analyzing Polymarket’s market structure, event data, and smart contracts, we discovered that most Polymarket analyses and dashboards have been mistakenly double-counting volume. - [Bridging the Gap: How Crypto Expands Financial Access for America’s Underbanked](https://www.paradigm.xyz/writing/bridging-the-gap-how-crypto-expands-financial-access-for-america-s-underbanked) — No group stands to gain more from crypto access than the unbanked and underbanked. - [Treasury: When Implementing GENIUS, Follow Congress’s Direction](https://www.paradigm.xyz/writing/treasury-when-implementing-genius-follow-congress-direction) — Congress has already spoken on allowing affiliates to issue yield; regulatory agencies cannot alter that decision. - [Execution Matters: Paradigm's Response to FCA CP25/25](https://www.paradigm.xyz/writing/execution-matters-paradigm-s-response-to-fca-cp25-25) — Paradigm responds to the FCA on key priorities for applying their Handbook to cryptoassets, emphasizing that execution of regulatory details will determine U.K.'s crypto leadership success. - [Paradigm Files (Another) Amicus Brief to Oppose State Encroachment on Federal Regulation](https://www.paradigm.xyz/writing/paradigm-files-another-amicus-brief) — Yesterday, Paradigm filed an amicus brief in KalshiEX LLC v. Martin, a Fourth Circuit case about Maryland’s effort to treat federally regulated swaps as gambling. This isn’t a close call. - [Paradigm joins DEF and SPI in comment to Treasury on how innovative crypto practices can prevent and combat illicit finance](https://www.paradigm.xyz/writing/paradigm-joins-def-and-spi-in-comment) — The solution to problems associated with illicit finance will be found within crypto itself. - [Ithaca x Tempo](https://www.paradigm.xyz/writing/ithaca-x-tempo) — The Ithaca team is joining Tempo to build the infra needed for Tempo to scale, meet real-world demand, and remain open to everyone. - [Congress Passed GENIUS. Market Structure Is Next. But Skipping Crypto Tax Would Be a Mistake.](https://www.paradigm.xyz/writing/congress-passed-genius-market-structure-is-next-but-skipping-crypto-tax-would-be-a-mistake) — Unless Congress acts to clarify crypto tax rules, upside from GENIUS and market structure will be capped. - [Paradigm’s Response to CFTC Request for Comment](https://www.paradigm.xyz/writing/paradigm-s-response-to-cftc-request-for-comment) — The importance of the CFTC providing targeted regulatory clarity on event contracts and perpetuals with all deliberate speed. - [Why Close SEC–CFTC Coordination Is Key to Unlocking U.S. Market Innovation](https://www.paradigm.xyz/writing/sec-cftc-coordination) — The SEC and CFTC are holding a roundtable to harmonize their rules. We discuss the potential opportunity at hand for financial markets. - [Paradigm Files Amicus Brief Defending Innovation in DeFi](https://www.paradigm.xyz/writing/paradigm-files-amicus-brief-defending-innovation-in-defi) — Paradigm backs Uniswap, all DeFi developers against patent abuse - [Tempo: The Blockchain Designed for Payments](https://www.paradigm.xyz/writing/tempo-payments-first-blockchain) — The payments-first blockchain incubated by Stripe and Paradigm - [Public Stocks on Public Blockchains: How Do We Get There?](https://www.paradigm.xyz/writing/public-stocks-on-public-blockchains) — Paradigm Files Comment with the SEC Crypto Task Force on Equity Market Tokenization - [Paradigm Urges CFTC to Embrace DeFi in Spot Crypto Trading Rules](https://www.paradigm.xyz/writing/paradigm-urges-cftc-to-embrace-defi-in-spot-crypto-trading-rules) — Paradigm files comment to CFTC stressing that any spot crypto trading regime must not disadvantage DeFi. - [Opportunity Markets](https://www.paradigm.xyz/writing/opportunity-markets) — Introducing opportunity markets, private prediction markets where those who spot opportunities get paid by those who can act on them - [The Senate Market Structure Approach Is the Best Path Forward](https://www.paradigm.xyz/writing/market-structure-rfi-response) — Paradigm’s responses to the Senate Banking Committee’s RFI on market structure legislation. - [A Blueprint for American Crypto Leadership: Breaking Down the White House’s 180-Day Report](https://www.paradigm.xyz/writing/a-blueprint-for-american-crypto-leadership-breaking-down-the-white-house-s-180-day-report) — The White House laid out comprehensive steps to spur growth and unlock crypto’s potential in the United States. - [Paradigm Files Amicus Brief to Oppose State Encroachment on Federal Regulation](https://www.paradigm.xyz/writing/paradigm-files-amicus-brief-to-oppose-state-encroachment-on-federal-regulation) — Paradigm files amicus brief in support of Kalshi in KalshiEX LLC v. Flaherty - [The GENIUS Act Passed - Now the Real Work Begins](https://www.paradigm.xyz/writing/the-genius-act-passed-now-the-real-work-begins) — The GENIUS Act is now law. What steps do regulators need to take to implement its stablecoin regime? - [Joining Paradigm](https://www.paradigm.xyz/writing/joining-paradigm-ricardo-de-arruda) — Ricardo de Arruda joins Paradigm as an Investment and Research partner. - [Paradigm Files Amicus in Lewellen v. Bondi](https://www.paradigm.xyz/writing/paradigm-files-amicus-in-lewellen-v-bondi) — Paradigm files amicus brief supporting Michael Lewellen's lawsuit challenging the DOJ's increasingly aggressive use of 18 U.S.C. § 1960 against software developers - [Paradigm Policy Market Mapping Exercise Spring 2025](https://www.paradigm.xyz/writing/paradigm-policy-market-mapping-exercise-spring-2025) — Crypto ownership is more than an investment—it’s a signal. Paradigm’s new market mapping exercise explores the voters behind the movement, offering fresh insight into how and why crypto is shaping American politics. - [The L1 Dilemma](https://www.paradigm.xyz/writing/the-l1-dilemma) — How to win as a new L1. - [Paradigm Files Amicus Brief Supporting Roman Storm](https://www.paradigm.xyz/writing/paradigm-files-amicus-brief-supporting-roman-storm) — Paradigm files amicus brief supporting Storm’s proposed jury instructions in United States v. Storm. - [UK Crypto Regulation Must Embrace DeFi: Paradigm Responds to the FCA](https://www.paradigm.xyz/writing/uk-crypto-regulation-must-embrace-defi-paradigm-responds-to-the-fca) — Paradigm responds to the Financial Conduct Authority on the importance of embracing DeFi. - [Introducing the 2025 Paradigm Fellowship](https://www.paradigm.xyz/writing/introducing-the-2025-paradigm-fellowship) — We’re excited to announce our third annual Paradigm Fellowship: a program for students, recent grads, and dropouts who are curious techno-optimists – drawn to markets, incentive design, and shaping how money moves online. - [Quantum Markets](https://www.paradigm.xyz/writing/quantum-markets) — A capital efficient mechanism for scaling futarchy. - [Orbital](https://www.paradigm.xyz/writing/orbital) — The future holds a million stablecoins. Today's infrastructure isn't ready. This paper introduces Orbital, an automated market maker for pools of 2, 3, or 10,000 stablecoins. Orbital unlocks capital efficiency by bringing concentrated liquidity to unlimited dimensions. - [DeFi Perps Deserve a Path Forward in the US: Paradigm Responds to the CFTC’s Perpetual Derivatives Request for Comment](https://www.paradigm.xyz/writing/defi-perps-deserve-a-path-forward) — Paradigm Files Comment Letter on Perpetual Derivatives - [Introducing Alloy v1.0: The simplest, fastest Rust toolkit for the EVM](https://www.paradigm.xyz/writing/introducing-alloy-v1-0) — We’re excited to release Alloy v1.0, our first stable release, reaffirming our commitment to performance, stability, and great developer experience. Alloy is a complete re-write of ethers-rs and builds on years of experience on shipping successful tooling for the Rust Ethereum ecosystem. - [Multiverse Finance](https://www.paradigm.xyz/writing/multiverse-finance) — Addressing capital efficiency in prediction markets by splitting the financial system into parallel universes. - [Across Prime](https://www.paradigm.xyz/writing/across-prime) — Across Prime introduces a new "bonded" model for trustless cross-chain bridging, which can be more gas and capital efficient than current "escrowed" models. - [Timing Advantages in Onchain Auctions](https://www.paradigm.xyz/writing/timing-advantages-in-onchain-auctions) — This paper studies and quantifies one of the fundamental limits to reducing MEV: latency advantages. - [Joining Paradigm](https://www.paradigm.xyz/writing/joining-paradigm-alpin-yukseloglu) — Alpin Yukseloglu joins Paradigm as an Investment and Research Partner. - [Southern District, Stand Down: Prosecuting Code Is Not Justice](https://www.paradigm.xyz/writing/southern-district-stand-down-prosecuting-code-is-not-justice) — Until the Storm case is dropped, all of crypto and every software developer are at risk. - [The Key Neutrality of Baselayer Markets](https://www.paradigm.xyz/writing/the-key-neutrality-of-baselayer-markets) — Paradigm responds to the SEC Crypto Task Force’s questions regarding MEV. - [Market Structure Legislation Principles](https://www.paradigm.xyz/writing/market-structure-principles) — Our proposed principles for market structure legislation aim to explicitly protect DeFi and early-stage innovators. - [Demystifying the North Korean Threat](https://www.paradigm.xyz/writing/demystifying-the-north-korean-threat) — There’s more to the DPRK than just Lazarus Group. - [TradFi Tomorrow: DeFi and the Rise of Extensible Finance](https://www.paradigm.xyz/writing/tradfi-tomorrow-defi-and-the-rise-of-extensible-finance) — Our survey of over 300 TradFi participants showed that a majority are excited about DeFi and want regulatory clarity for the space. - [Ress: Scaling Ethereum with Stateless Reth Nodes](https://www.paradigm.xyz/writing/stateless-reth-nodes) — Ress is a Stateless Ethereum node implementation in <4K LoC using the Reth SDK. - [Paradigm Policy Anchors](https://www.paradigm.xyz/writing/paradigm-policy-anchors) — Paradigm’s Policy Anchors guide how we engage on policy matters globally on behalf of our portfolio companies and all of crypto. - [Introducing Paradigm’s Policy Anchors and New Policy Council Additions](https://www.paradigm.xyz/writing/anchors-council-additions) — Paradigm Policy releases its Policy Anchors, and adds six new members to its Policy Council. - [What comes after Ethereum’s Pectra hard fork?](https://www.paradigm.xyz/writing/what-comes-after-ethereums-pectra-hard-fork) — The Reth team’s view on what should happen in Fusaka, Ethereum’s next hard fork after Pectra. - [Announcing: Foundry v1.0](https://www.paradigm.xyz/writing/announcing-foundry-v1-0) — Foundry, the leading smart contract development framework, releases v1.0. - [What You Should Know Before Watching the Congressional Debanking Hearings](https://www.paradigm.xyz/writing/debanking-hearings) — A primer on the debanking of crypto companies and entrepreneurs in advance of the February 2025 House and Senate hearings on the subject - [Ethereum Acceleration](https://www.paradigm.xyz/writing/ethereum-acceleration-1) — Since its inception, Ethereum has been a pioneering force in crypto. Ethereum paved the way for smart contracts, DAOs, and DeFi, and continues to innovate on frontier challenges like ZK and MEV. Ethereum’s community of researchers and engineers has built a strong foundation for the next generation of decentralized applications. - [Paradigm Files Amicus Supporting NFT Creators’ Lawsuit Against SEC](https://www.paradigm.xyz/writing/nft-amicus) — Paradigm files amicus brief outlining why the mere usage of blockchain technology does not turn digital creations into investment contracts. - [Distribution Markets](https://www.paradigm.xyz/writing/distribution-markets) — This paper introduces distribution markets, a new kind of prediction market for events whose outcomes aren't just "yes" or "no" but could be any number. Instead of betting on a particular outcome or range, traders can express how likely they think each different possibility is across the whole infinite range of outcomes. - [Paradigm Files Amicus to Support Keeping Election Markets in the US](https://www.paradigm.xyz/writing/amicus-brief-kalshi) — Paradigm files amicus in case against the CFTC to make sure Americans can access election-related prediction markets - [The 5 Levels of Secure Hardware](https://www.paradigm.xyz/writing/the-5-levels-of-secure-hardware) — Programmable cryptography enables fun, safe, and intelligent experiences. Hardware is necessary to achieve programmable cryptography at scale. How to think about the levels of secure hardware? Let’s get to Level 5. - [Bitcoin for the Sovereign](https://www.paradigm.xyz/writing/btc-for-the-sovereign) — Why the game theory for sovereign adoption of BTC has changed. - [Introducing Solar](https://www.paradigm.xyz/writing/solar) — A blazingly fast, modular and contributor friendly Solidity compiler, written in Rust - [pm-AMM: A Uniform AMM for Prediction Markets](https://www.paradigm.xyz/writing/pm-amm) — Introducing pm-AMM: an automated market maker designed for prediction markets. We introduce a new methodology for deriving AMMs for particular assets, and apply it to prediction market tokens, creating an AMM that may provide more consistent liquidity and reduce the risk of losing everything. - [October 2024 Public Opinion Poll](https://www.paradigm.xyz/writing/october-polling) — Crypto will matter at the ballot box this November. Our October poll, the last of our election series, confirms it: a surprising percentage of American voters identify themselves as single issue crypto voters. - [Paradigm Provides Amicus Support for DEF and Beba’s Lawsuit Against the SEC](https://www.paradigm.xyz/writing/beba-amicus) — Paradigm and other investors file amicus brief supporting DEF and Beba's lawsuit against the SEC - [Introducing Ithaca](https://www.paradigm.xyz/writing/ithaca) — We are excited to announce Paradigm’s $20M investment in Ithaca, a new company with the mission to accelerate crypto development across the entire stack. - [Unichain](https://www.paradigm.xyz/writing/unichain) — Unichain is an optimistic rollup optimized for efficient markets by delivering fast state updates, offering a framework for applications to internalize MEV, and providing an economic finality system for quick settlement across blockchains. - [How to Remove the Relay](https://www.paradigm.xyz/writing/removing-the-relays) — MEV-Boost, the current sidecar protocol for MEV extraction in Ethereum, relies heavily on centralized actors called relays. Using a novel form of silent threshold encryption, a non-interactive construction that can leverage validators' existing BLS keypairs, we propose an alternative architecture that allows builders and proposers to communicate directly, with purely cryptographic privacy assumptions. - [Regulation by Enforcement Isn't Just a Meme](https://www.paradigm.xyz/writing/regulation-by-enforcement-isn-t-just-a-meme) — A data-driven analysis of the SEC's actions against the crypto industry under Chair Gensler. - [Looking Back / Looking Forward](https://www.paradigm.xyz/writing/looking-forward) — A personal reflection on working at the intersection of crypto and policy - [July 2024 Democratic Public Opinion Poll](https://www.paradigm.xyz/writing/Dem-polling) — Democratic voters are increasingly gravitating towards crypto. That’s the primary takeaway of our new poll of registered Democrats, the complement to our poll of Republicans from June. These results dovetail with recent reports that Democratic candidates for office and Members of Congress are becoming pro-crypto, indicating that political figures are following the lead of their voters. - [Paradigm Files Comment on the CFTC’s Overbroad Proposed Rule on Political Event Contracts and Prediction Markets](https://www.paradigm.xyz/writing/prediction-market-comment) — Paradigm files comment letter in response to the CFTC's proposed rule on prediction markets and election contracts. - [June 2024 Republican Public Opinion Poll](https://www.paradigm.xyz/writing/GOP-Polling) — In June, Paradigm conducted a first-of-its kind poll of Republican voters to better understand how they think about crypto. The results were clear: Republicans embrace financial freedom and want the current Administration’s crypto approach to end. - [Paradigm Files Amicus Brief Supporting CFAT and Lejilex’s Lawsuit Against the SEC](https://www.paradigm.xyz/writing/amicus-brief-lejilex) — Paradigm has submitted an amicus brief supporting Lejilex and the Crypto Freedom Alliance of Texas's lawsuit against the SEC. - [Releasing Reth 1.0!](https://www.paradigm.xyz/writing/reth-prod) — Reth is now feature-complete, stable, and recommended for production usage and staking. - [Paradigm Fellowship 2024](https://www.paradigm.xyz/writing/paradigm-fellowship-2024) — We’re launching the 2024 Paradigm Fellowship, a program to gather crypto’s most formidable young engineers and researchers. - [Paradigm Files Comment Letter on ESMA’s Market Abuse Consultation](https://www.paradigm.xyz/writing/paradigm-files-comment-letter-on-esma-market-abuse) — Paradigm has filed a second comment letter regarding MiCA. - [Releasing Revmc](https://www.paradigm.xyz/writing/revmc) — Accelerating the EVM by compiling to native code. - [Releasing Alloy](https://www.paradigm.xyz/writing/alloy-release) — After a year of development we're excited to release Alloy, an ecosystem of performant, well-tested and well-documented libraries for interacting with EVM-based blockchains. - [Announcing Paradigm's Third Fund](https://www.paradigm.xyz/writing/paradigms-third-fund) — Paradigm has raised our third fund: an $850M venture fund focused on crypto projects at the earliest stages. - [Policy Lab RH-001: Settling the Unsettled](https://www.paradigm.xyz/writing/settling-the-unsettled) — Paradigm Policy Lab-funded research argues that public blockchains can be used to settle financial transactions, stressing the importance of developing proactive and multi-faceted solutions to settlement vulnerabilities before a “black swan” scenario occurs. - [From Staking to Restaking](https://www.paradigm.xyz/writing/symbiotic) — Introducing Symbiotic, a generalized, permissionless protocol providing shared security through restaking. - [Priority Is All You Need](https://www.paradigm.xyz/writing/priority-is-all-you-need) — In this post, we introduce MEV taxes, a mechanism that arbitrary applications can use to capture their own MEV. This mechanism could be used today on OP Stack L2s like OP Mainnet, Base, and Blast, because the block proposers on those chains follow a set of rules we call competitive priority ordering. - [Paradigm Files Amicus Brief Supporting Challenge Against the SEC’s Dealer Rule, Which Could Have Sweeping Implications for DeFi](https://www.paradigm.xyz/writing/dealer-rule-amicus) — Paradigm filed an amicus brief supporting the Blockchain Association and Crypto Freedom Alliance of Texas motion for summary judgment in their challenge to the SEC’s new Dealer Rule, which could have sweeping implications for DeFi and all of crypto. - [The Edges of Finance](https://www.paradigm.xyz/writing/the-edges-of-finance) — Some parts of crypto seem alien when compared to traditional finance. They make more sense when you view them in the context of a broader shift away from banks toward digital financial services provided by a range of people and companies. Innovation in finance is moving from the core to the edges. - [How to Raise the Gas Limit, Part 2: History Growth](https://www.paradigm.xyz/writing/how-to-raise-the-gas-limit-2) — In this post we continue our investigation of Ethereum scaling from Part 1, now turning our attention from state growth to history growth. Using high resolution datasets, our goal is to 1) build a technical understanding of Ethereum’s scaling bottlenecks, and 2) help frame the discussion around what Ethereum gas limit is optimal. - [Reth Execution Extensions](https://www.paradigm.xyz/writing/reth-exex) — Execution Extensions (ExExes) are post-execution hooks for building real-time, high performance and zero-operations off-chain infrastructure on top of Reth. - [Fig: Frame Interface Guidelines](https://www.paradigm.xyz/writing/fig) — We’re excited to open source Frame Interface Guidelines (Fig), which outlines best practices for building great Farcaster Frame experiences, inspired by Apple’s Human Interface Guidelines. - [Paradigm Files Comment Letter on ESMA’s Financial Instruments Consultation](https://www.paradigm.xyz/writing/paradigm-files-comment-letter-on-esma-s-financial-instruments-consultation) — Paradigm has filed a comment letter in response to a consultation as part of the EU’s landmark crypto law, known as MiCA. - [Reth’s path to 1 gigagas per second, and beyond](https://www.paradigm.xyz/writing/reth-perf) — Reth’s performance roadmap and how we intend to scale Ethereum. - [Reth AlphaNet](https://www.paradigm.xyz/writing/reth-alphanet) — Reth AlphaNet is a testnet OP Stack-compatible rollup aimed at maximizing Reth performance and enabling experimentation of bleeding edge Ethereum Research. - [Crypto's Biggest Skeptics are EVM-pilled](https://www.paradigm.xyz/writing/Cryptos-Biggest-Skeptics-are-EVM-pilled) — Central banks love to publicly question crypto. And yet their use of crypto technology tells a much different story: central bank future-of-finance efforts increasingly leverage crypto Open Source Software (OSS). - [Paradigm Files Amicus Brief Supporting Coinbase's Lawsuit vs. SEC](https://www.paradigm.xyz/writing/amicus-brief-coinbase) — Paradigm filed an amicus brief supporting Coinbase’s lawsuit against the SEC, which seeks judicial review of the agency’s refusal to provide rules for crypto. - [March 2024 Public Opinion Poll](https://www.paradigm.xyz/writing/March-2024-Polling) — Key findings about American voters use of crypto and the importance of this growing voting bloc. - [Announcing Reth Beta!](https://www.paradigm.xyz/writing/reth-beta) — After 21 alpha releases Reth is entering beta.1 and preparing for our 1.0 “production ready” release in the next few months. In this post, we discuss the core features, performance, and stability of Reth Beta. - [Everything Is A Perp](https://www.paradigm.xyz/writing/everything-is-a-perp) — Power perps are assets that target the power of an index price. It’s a fun rabbit hole to go down. The longer you think about power perps, the more you see how everything resembles a power perp. - [Joining Paradigm as Research Advisor](https://www.paradigm.xyz/writing/joining-paradigm-ciamac-moallemi) — I'm excited to announce that I've joined Paradigm as a Research Advisor. I am excited to be working with Dan Robinson, Matt Huang, and the rest of the Paradigm investing - [How to Raise the Gas Limit, Part 1: State Growth](https://www.paradigm.xyz/writing/how-to-raise-the-gas-limit-1) — The goal of this blogpost series is to develop a scientific approach for understanding and enacting Ethereum's scaling roadmap. - [Paradigm Files Amicus Brief in SEC v. Kraken](https://www.paradigm.xyz/writing/amicus-brief-kraken) — Paradigm filed an amicus brief in SEC vs. Kraken that supplements the arguments made by Kraken and explains, once again, why the SEC's approach is unsupported by case law and is an unlawful attempt to grant itself new and unpermitted regulatory authority. - [Leaderless Auctions](https://www.paradigm.xyz/writing/leaderless-auctions) — Leaderless Auctions are decentralized auctions with no auctioneer. They address the “last look” problem that can emerge when one participant is allowed to act after all others. - [Paradigm Files Amicus Brief in Support of KalshiEx Congressional Control Contract Case vs. the CFTC](https://www.paradigm.xyz/writing/paradigm-files-amicus-brief-in-support-of-kalshiex-congressional-control-contract-case-vs-the) — Paradigm filed an amicus brief in support of Kalshi's lawsuit against the CFTC, which challenges the Commission's disapproval of the listing of a prediction market on Congressional control. - [Paradigm Files Comment Letter on FinCEN's Proposed Reporting Requirements for Mixers](https://www.paradigm.xyz/writing/paradigm-files-comment-letter-on-fincen-s-proposed-reporting-requirements-for-mixers) — Paradigm today filed a comment to FinCEN’s Notice of Proposed Rulemaking, which labels all “convertible virtual currency mixing”–defined broadly–as a primary money laundering concern, and seeks to impose a new reporting requirement on all related transactions. - [What comes after Ethereum's Cancun hard fork?](https://www.paradigm.xyz/writing/ethereum-2024) — Where we outline the Paradigm Reth team's current view on possible next steps for Ethereum's upgrade after Cancun, Prague. - [Paradigm Responds to the CFPB’s Proposed “Larger Participants” Digital Wallet Rule](https://www.paradigm.xyz/writing/paradigm-responds-to-the-cfpb-s-proposed-larger-participants-digital-wallet-rule) — The Consumer Financial Protection Bureau has proposed a rule intended to regulate large centralized digital payment companies, but captures crypto wallets in the process. Paradigm urges the Bureau to appropriately narrow the scope of the rule to exclude crypto wallets, which are quite different than the rule's ostensibly intended targets. - [Paradigm Files Amicus Brief in SEC’s Lawsuit Against Ripple](https://www.paradigm.xyz/writing/paradigm-files-amicus-brief-in-sec-s-lawsuit-against-ripple) — Last week, Paradigm filed an amicus brief in the SEC’s lawsuit against Ripple Labs, Inc. Our goal is to help the Court avoid the unintended consequences of casually endorsing the SEC’s position in this case, which conflates an investment scheme with the crypto asset sold in that scheme. - [Paradigm Files Comment Letter on IRS' Unduly Burdensome Proposed Crypto Broker Rule](https://www.paradigm.xyz/writing/paradigm-files-comment-letter-on-irs-unduly-burdensome-proposed-crypto-broker-rule) — The IRS and Treasury Department's crypto broker rule is unduly broad and burdensome, indiscriminately implicating wide swaths of the crypto industry. Paradigm's comment letter urges the IRS to substantially revise the proposed rule to ensure it is properly tailored and practically administrable. - [You Can’t Regulate What You Don’t Understand (2.0)](https://www.paradigm.xyz/writing/you-cant-regulate-what-you-dont-understand-2-0) — The recent SEC Inspector General report highlighted the impact that limiting crypto ownership has had on the SEC’s hiring efficacy. In light of this, Paradigm Policy revisited and revised our suggested updates to government ethics rules. - [Paradigm Files Amicus Brief in Harper vs. IRS](https://www.paradigm.xyz/writing/paradigm-files-amicus-brief-in-harper-vs-irs) — Paradigm filed an amicus brief in support of James Harper’s lawsuit against the IRS, which challenges the agency’s ability to use “John Doe” summons as a dragnet to surreptitiously obtain the private records of large groups of crypto users. - [Paradigm Files Amicus Brief in SEC's Case Against Binance](https://www.paradigm.xyz/writing/paradigm-files-amicus-brief-in-sec-s-case-against-binance) — Paradigm filed an amicus brief in the SEC lawsuit against Binance. Paradigm was not an investor in Binance and has no direct financial interest in the outcome of the lawsuit. However, we believe it is critical to stand against government overreach regardless of who the defendant is. - [The Casino on Mars](https://www.paradigm.xyz/writing/casino-on-mars) — Settling the crypto frontier begins with a speculative step. - [Electronification, Trading, and Crypto](https://www.paradigm.xyz/writing/electronification-trading-crypto) — An analysis of the historical evolution of financial markets — and why crypto is about more than just making existing processes digital. - [Introducing Rivet](https://www.paradigm.xyz/writing/rivet) — Rivet is a developer wallet & tools, akin to React DevTools. It enables developers to inspect, debug, modify, and manipulate the state of Ethereum. - [The Open Problems of Onchain Games](https://www.paradigm.xyz/writing/the-open-problems-of-onchain-games) — Or: why put games on a blockchain? - [Paradigm and a16z File Joint Amicus Brief in SEC v. Coinbase](https://www.paradigm.xyz/writing/paradigm-and-a16z-file-joint-amicus-brief-in-sec-v-coinbase) — Paradigm and a16z filed a joint amicus brief in SEC vs. Coinbase that supplements the arguments made by Coinbase in its filing last week and demonstrates why the SEC's approach is unsupported by case law and represents a significant and problematic expansion of its regulatory authority. - [The Future of Payments Includes Stablecoins](https://www.paradigm.xyz/writing/the-future-of-payments-includes-stablecoins) — Any legislation on stablecoins should promote openness and competition while recognizing that stablecoins are inherently different from bank deposits and MMFs. - [Collaborate with Paradigm](https://www.paradigm.xyz/writing/collaborate-with-paradigm) — Paradigm is a group of builders that supports other builders. Some of our most fruitful collaborations involve deep work with entrepreneurial teams to solve important business and research problems. - [Joining Paradigm](https://www.paradigm.xyz/writing/joining-paradigm-alex-grieve) — Alex Grieve joins Paradigm as Government Affairs Lead. - [Paradigm Files Amicus Brief in SEC vs. Bittrex](https://www.paradigm.xyz/writing/paradigm-files-amicus-brief-in-sec-vs-bittrex) — Paradigm filed an amicus brief rejecting the SEC's unsupported attempt to expand its jurisdiction to secondary market trading of crypto assets. - [Introducing Alloy: Fast, battle-tested and well-documented building blocks for Ethereum, in Rust](https://www.paradigm.xyz/writing/alloy) — Alloy is a Rust interface to Ethereum. It is a rewrite of the popular ethers-rs crate, using our learnings from the last 4 years of Rust Ethereum engineering, to create stable and useful foundations for the next 5 years. - [Releasing Reth](https://www.paradigm.xyz/writing/reth-alpha) — Reth is a new Ethereum execution node written in Rust that is modular, contributor-friendly and blazing-fast. Reth is now entering public alpha and we’re excited to invite node operators and developers to try it out. - [Paradigm Comments on the SEC's Proposed Redefinition of Exchange](https://www.paradigm.xyz/writing/paradigm-comments-on-the-sec-s-proposed-redefinition-of-exchange) — Through this haphazard rulemaking, the SEC inappropriately attempts to bring crypto trading platforms, including DEXs, under its remit and regulate them as securities exchanges. It thus appears that after suing Coinbase for failing to do the impossible—registering as a securities exchange when it was incapable of doing so—the Commission now intends to force DEXs into the same Hobson’s choice. - [Introducing flood: a load testing tool for benchmarking EVM nodes](https://www.paradigm.xyz/writing/flood) — Load testing is a critical step in the development of resilient, high-performing data systems. Nevertheless, load testing has not been widely applied in the development of cryptocurrency infrastructure. We're thrilled to bridge this gap with the introduction of flood, a benchmarking tool specifically designed for performance analysis of RPC endpoints. - [Paradigm Files Amicus Brief in Coin Center Lawsuit over Tornado Cash Sanctions](https://www.paradigm.xyz/writing/paradigm-files-amicus-brief-in-coin-center-lawsuit-over-tornado-cash-sanctions) — Paradigm filed an amicus brief in the lawsuit that Coin Center and others brought in Florida to challenge the government’s sanctioning of the Tornado Cash open-source code. - [Intent-Based Architecture and Their Risks](https://www.paradigm.xyz/writing/intents) — The road to centralisation is paved with good intents. - [Paradigm Files Amicus Brief in NY AG's Case Against KuCoin Pushing Back Against Allegation that ETH is a Security](https://www.paradigm.xyz/writing/paradigm-files-amicus-brief-in-ny-ag-s-case-against-kucoin-pushing-back-against-allegation-that) — Paradigm filed an amicus brief in the lawsuit that the NY AG brought against KuCoin, in which the OAG alleged that certain tokens traded by KuCoin, including ETH, are securities. Our brief highlights the unfairness of the OAG’s tactics, which deprive the most affected parties an opportunity to defend themselves in court. - [Paradigm Files Amicus Brief Supporting Coinbase’s Writ of Mandamus](https://www.paradigm.xyz/writing/paradigm-files-amicus-brief-supporting-coinbase-s-writ-of-mandamus) — Today Paradigm filed an amicus brief in support of Coinbase’s lawsuit that seeks to compel the SEC to respond to the company’s pending rulemaking petition. - [Paradigm Files Comment Letter in Response to Proposed Amendments to the Custody Rule](https://www.paradigm.xyz/writing/paradigm-files-comment-letter-in-response-to-proposed-amendments-to-the-custody-rule) — Paradigm submitted a comment letter to the SEC regarding the Commission’s proposed amendments and redesignation of rule 206(4)-2 (better known as the Custody Rule). - [Artemis: An Open-Source MEV Bot Framework](https://www.paradigm.xyz/writing/artemis) — We're excited to open source Artemis, a framework for writing MEV bots in Rust. Artemis is designed to be simple, modular, and fast. - [Blend: Perpetual Lending With NFT Collateral](https://www.paradigm.xyz/writing/blend) — Blend is a peer-to-peer perpetual lending protocol that enables lending against arbitrary collateral with no oracle dependencies. - [Time, slots, and the ordering of events in Ethereum Proof-of-Stake](https://www.paradigm.xyz/writing/mev-boost-ethereum-consensus) — Introduction On April 2nd, a malicious Ethereum network participant stole $20M from a MEV searcher by exploiting a vulnerability in the mev-boost-relay (see Flashbots’ post-mortem). In the following days, developers addressed - [Moneyness In the Digital Age](https://www.paradigm.xyz/writing/moneyness-in-the-digital-age) — The recent events surrounding Silicon Valley Bank (SVB) provide a lens for reexamining age-old questions about the relationship between money and credit — and crypto’s important role in the future. - [Paradigm Files Amicus Brief in SEC vs Terra](https://www.paradigm.xyz/writing/paradigm-files-amicus-brief-in-sec-vs-terra) — Paradigm was not an investor in the Terra ecosystem and our brief was filed in support of neither party’s motion—our only interest was to push back against the SEC’s continued attempts to expand their jurisdiction over crypto. - [The Current SEC Disclosure Framework Is Unfit for Crypto](https://www.paradigm.xyz/writing/secs-path-to-registration-part-iii) — The grand bargain of the US securities laws is that any issuer selling securities to the general public must provide the public with a set of disclosures approved by the SEC. These laws are intended to address information asymmetry and ensure that the investing public has the material information necessary to make informed investment decisions. The securities laws are not intended to turn the SEC into a gatekeeper or “merit regulator” that itself decides which projects are investable and which are not. Congress meant for discretion to remain solidly in the hands of individual investors. - [Paradigm Files Van Loon Amicus Brief](https://www.paradigm.xyz/writing/paradigm-files-van-loon-amicus-brief) — Paradigm filed an amicus brief in the lawsuit that six Tornado Cash users brought to challenge the government’s unprecedented sanctioning of the Tornado Cash open-source code. - [March 2023 Public Opinion Poll](https://www.paradigm.xyz/writing/march-2023-public-opinion-poll) — While Washington sits on the sidelines, Americans want regulatory clarity on crypto. That's the bottom line on a poll we recently conducted to better understand how Americans view crypto. - [Lessons from Crypto Projects’ Failed Attempts to Register with the SEC](https://www.paradigm.xyz/writing/secs-path-to-registration-part-ii) — As we show in a number of case studies, the projects that attempted to come into compliance with the SEC’s registration requirements expended great effort and resources yet ultimately most of them failed, and those that persist do so in a state of uncertainty and comparative disadvantage. The failure of projects that have attempted to register is due in large part to the SEC’s reluctance to provide a workable framework through rulemaking, exemptive relief, guidance and industry engagement. - [Due to SEC Inaction, Registration is Not a Viable Path for Crypto Projects](https://www.paradigm.xyz/writing/secs-path-to-registration-part-i) — SEC Chair Gary Gensler would like the American public to believe that it is just as simple and easy for crypto founders to register tokens or crypto products with the SEC. It’s not. - [Paradigm Files Amicus Brief in SEC vs Wahi](https://www.paradigm.xyz/writing/paradigm-files-amicus-brief-in-sec-vs-wahi) — Paradigm filed an amicus brief in SEC vs. Wahi that rejects the SEC’s expansive and unsupported application of securities laws to crypto secondary markets. - [You Can't Regulate What You Can't Understand: The Case for Modernizing Government Ethics Rules](https://www.paradigm.xyz/writing/ethics-rules-government-use-of-crypto) — Ethics rules effectively bar most government employees from owning crypto. - [Using On-Chain Data for Policy Research, Part 3: Mint/Burn Dashboard](https://www.paradigm.xyz/writing/using-on-chain-data-for-policy-research-part-3) — Today, fiat-backed stablecoins are an important part of the crypto ecosystem and looking closely at on-chain data can surface issues that lead to better-designed stablecoins. Rather than write an academic-style report, our approach here is to make available a clean data set and deliver an interactive data dashboard to encourage more individual use and exploration of on-chain activity. - [Using On-Chain Data for Policy Research, Part 2: Stablecoin Risk Rundown](https://www.paradigm.xyz/writing/using-on-chain-data-for-policy-research-part-2) — The first post in this series provided an overview of one of the many ways to access on-chain data for use in policy research. This piece builds on that work by introducing a set of policy issues relevant to stablecoins, including what can and can't be probed using on-chain data. It also covers a few practical steps related to data cleaning. It is intended for policy professionals operating at the academic-practitioner frontier. - [Generating secure randomness on Ethereum using SNARKs](https://www.paradigm.xyz/writing/eth-rng) — In this post, we propose designs and reference implementations that utilize SNARKs and VDFs to achieve fully secure randomness on Ethereum. - [Introducing Reth](https://www.paradigm.xyz/writing/reth) — Paradigm is excited to announce Reth, a free, open-source Ethereum execution layer client. In this post, we’ll discuss why we are making Reth and what to expect from us in the future. - [Paradigm × wagmi](https://www.paradigm.xyz/writing/paradigm-and-wagmi) — Paradigm is sponsoring Tom and Jake to focus full-time on building open-source libraries to accelerate web3 frontend development. - [Introducing Paradigm’s Policy Council](https://www.paradigm.xyz/writing/introducing-paradigm-s-policy-council) — We are excited to announce the first iteration of the Paradigm Policy Council, an impressive group of bipartisan talent with a diverse set of experiences. This team will advise Paradigm’s leadership team and help us tell the story of Web3 in Washington and around the world. - [Paradigm Files Amicus Brief in CFTC Action Against "Ooki DAO"](https://www.paradigm.xyz/writing/paradigm-files-amicus-brief-in-cftc-action-against-ooki-dao) — Paradigm is filing an amicus brief in the case recently brought by the CFTC against “the Ooki DAO.” While we are not a party to the case, we thought it was necessary to speak up against the CFTC’s attempt to expand liability to unsuspecting technology users and impair the ability of DAOs to operate in the US. - [Using On-Chain Data for Policy Research: Part 1](https://www.paradigm.xyz/writing/using-on-chain-data-for-policy-research-part-1) — Crypto policy work rarely involves real, granular data. This is a missed opportunity, given how many tools used by the modern economics and finance community should directly translate to crypto data analysis. Crypto offers granular data, available to anyone, by design. - [Ethereum's New ‘Staking’ Model Does Not Make ETH A Security](https://www.paradigm.xyz/writing/ethereums-new-staking-model-does-not-make-eth-a-security) — Ethereum’s adoption of a proof-of-stake consensus mechanism does not make ETH (or even staked ETH) an investment contract, and such a finding would result in a nonsensical application of securities laws. - [Open Sourcing the Art Gobblers Smart Contracts](https://www.paradigm.xyz/writing/open-sourcing-gobblers) — Today, we’re excited to announce that the Art Gobblers smart contracts are open source and available on our Github repo. - [What is the Merge?](https://www.paradigm.xyz/writing/what-is-the-merge) — The Ethereum network will soon undergo an update known as the Merge. The primary goal of the Merge is to transition Ethereum's consensus mechanism from a model known as proof-of-work (PoW) to one called proof-of-stake (PoS). - [Art Gobblers](https://www.paradigm.xyz/writing/artgobblers) — Art Gobblers is a decentralized art factory owned by aliens. As artists make cool art, Gobblers gains cultural relevance, making collectors want the art more, incentivizing artists to make cooler art. It's also an on-chain game. - [Goldfish: A Provably Secure Replacement for LMD GHOST in PoS Ethereum](https://www.paradigm.xyz/writing/goldfish) — The Merge: From Proof-of-Work to Proof-of-Stake The upcoming transition of Ethereum from proof-of-work (PoW) to proof-of-stake (PoS) is the culmination of years of research and development. - [GOO (Gradual Ownership Optimization)](https://www.paradigm.xyz/writing/goo) — GOO aligns fungible and non-fungible token incentives. - [Data Availability Sampling: From Basics to Open Problems](https://www.paradigm.xyz/writing/das) — The purpose of this blog post is to explain the basics of data availability sampling (DAS), the model upon which it rests, and challenges and open problems when it comes to implementing the technique in practice. - [Variable Rate GDAs](https://www.paradigm.xyz/writing/vrgda) — Variable Rate GDAs (VRGDAs) enable selling tokens close to a targeted schedule by adjusting prices as sales get ahead of/behind it. - [Cosmos without Tendermint: Exploring Narwhal and Bullshark](https://www.paradigm.xyz/writing/experiment-narwhal-bullshark-cosmos-stack) — Many of us at Paradigm have been excited about the latest developments on high-throughput & low-latency consensus using directed acyclic graphs (DAGs), in particular the Narwhal mempool and the Tusk and Bullshark consensus algorithms, and beyond. - [LP Letter Excerpt — July 20th, 2022](https://www.paradigm.xyz/writing/lp-letter-excerpt-july-20th-2022) — As long-term investors in crypto, we wanted to provide some additional context on recent market events. Here is an excerpt of what we recently shared with our investors: - [Understanding Blockchain Latency and Throughput](https://www.paradigm.xyz/writing/consensus-throughput) — How to properly measure a (blockchain) system is one of the least talked about but most significant steps in its design and evaluation. There are numerous consensus protocols and variations with various performance and scalability tradeoffs. But as of yet, there is still no universally agreed-upon, reliable method that enables apples-to-apples comparisons. In this blog post, we outline a method inspired by measurements in data-center systems and discuss common errors to avoid when evaluating a blockchain network. - [DAO Strategy and Legal Wrappers](https://www.paradigm.xyz/writing/dao-strategy-and-legal-wrappers) — Discussion on the strategic considerations and legal structures necessary for DAOs to operate effectively and legally in the real world, addressing the complexities and options available to founders for managing legal risk and facilitating operations. - [Legal Options for DAOs](https://www.paradigm.xyz/writing/legal-options-for-daos) — A discussion on legal options related to DAOs. - [Evaluating Web3 jobs like an investor](https://www.paradigm.xyz/writing/evaluating-web3-jobs-like-an-investor) — This piece advises treating the evaluation of Web3 job opportunities with the same diligence as an investor would, leveraging accessible on-chain quantitative metrics and qualitative aspects to make informed decisions about potential roles. - [Joining Paradigm](https://www.paradigm.xyz/writing/joining-paradigm-katie-biber) — Katie Biber joins Paradigm as the CLO. - [Paradigm Fellowship](https://www.paradigm.xyz/writing/paradigm-fellowship) — At Paradigm, we want to work with the brightest minds in crypto. The Paradigm Fellowship is for that next generation of crypto talent. - [Joining Paradigm](https://www.paradigm.xyz/writing/joining-paradigm-caitlin-pintavorn) — Caitlin Pintavorn joins Paradigm as an Investment Associate. - [The Dominance of Uniswap v3 Liquidity](https://www.paradigm.xyz/writing/the-dominance-of-uniswap-v3-liquidity) — New research published today shows that Uniswap Protocol v3 has deeper liquidity in ETH/USD, ETH/BTC and other ETH pairs than leading centralized exchanges. This research demonstrates that AMM market structure – which is largely crypto-native today – can surpass order-book exchanges and transform traditional financial market structure to be more liquid, stable, and secure. - [Hardware Acceleration for Zero Knowledge Proofs](https://www.paradigm.xyz/writing/zk-hardware) — Zero Knowledge cryptography is one of the most notable innovations in the last fifty years of computer science. Zero Knowledge Proofs (ZKPs) offer unique properties that make them essential components of various blockchain scaling and privacy solutions. - [Gradual Dutch Auctions](https://www.paradigm.xyz/writing/gda) — This paper introduces the Gradual Dutch Auction, or GDA, a mechanism that enables efficient sales of assets that do not have liquid markets. - [Announcing Foundry v0.2.02](https://www.paradigm.xyz/writing/foundry-02) — Foundry is a portable, fast, and modular toolkit for Ethereum application development, written in Rust. Foundry is built by Solidity developers for Solidity developers. - [Token compensation: a brief explainer for job candidates](https://www.paradigm.xyz/writing/token-compensation-a-brief-explainer-for-job-candidates) — An explanation on token compensation. - [Joining Paradigm](https://www.paradigm.xyz/writing/joining-paradigm-transmissions11) — Transmissions11 joins Paradigm as a Research Engineer. - [Joining Paradigm](https://www.paradigm.xyz/writing/joining-paradigm-justin-slaughter) — Justin Slaughter joins Paradigm as Policy Director. - [Base Layer Neutrality](https://www.paradigm.xyz/writing/base-layer-neutrality) — With this analysis, we hope to ease uncertainty plaguing industry actors and provide clarity around the scope of sanctions compliance obligations. - [Constant Rate Issuance Sales Protocol](https://www.paradigm.xyz/writing/constant-rate-issuance-sales-protocol) — This paper introduces the Constant Rate Issuance Sales Protocol, or CRISP, a pricing mechanism that aims to sell NFTs at a targeted rate over time. - [Joining Paradigm](https://www.paradigm.xyz/writing/joining-paradigm-frankie) — Frankie joins Paradigm as a Research Engineer. - [Introducing the Foundry Ethereum development toolbox](https://www.paradigm.xyz/writing/introducing-the-foundry-ethereum-development-toolbox) — Foundry is a portable, fast and modular toolkit for Ethereum application development. - [Paradigm’s New Chief Technology Officer](https://www.paradigm.xyz/writing/paradigms-new-chief-technology-officer) — Today, we are excited to announce Georgios Konstantopoulos as our new Chief Technology Officer. - [Paradigm’s New Venture Fund](https://www.paradigm.xyz/writing/paradigms-new-venture-fund) — Announcing our new venture fund to continue investing in the next generation of crypto companies and protocols. - [Hiding in Plain Sight](https://www.paradigm.xyz/writing/hiding-in-plain-sight) — I like challenging assumptions. I like trying to do the impossible, finding what others have missed, and blowing people's minds with things they never saw coming. - [A Guide to Designing Effective NFT Launches](https://www.paradigm.xyz/writing/a-guide-to-designing-effective-nft-launches) — Blockchains revolutionized fundraising for open-source software, but not everything worked right from the start. In fact, ICOs of the 2016-2018 era were often horribly broken mechanisms that allowed founders to cash out before delivering any products. Many lessons have been learned since, with today’s projects having a working product before launching a token and distributing it to incentivize usage and decentralize governance. - [RICKS](https://www.paradigm.xyz/writing/ricks) — Introducing a new NFT fractionalization primitive: RICKS (Recurrently Issued Collectively Kept Shards) - [Martingale Shares](https://www.paradigm.xyz/writing/martingale-shares) — Introducing a new NFT primitive: Martingale shares, or "Mortys." Mortys are synthetics representing fractional ownership of classes of NFTs. - [The Community Garden: The Case for Leaving FAANG Companies for Crypto](https://www.paradigm.xyz/writing/the-community-garden-the-case-for-leaving-faang-companies-for-crypto) — This piece discusses reasons individuals might leave FAANG companies for crypto. - [Floor Perps](https://www.paradigm.xyz/writing/floor-perps) — Introducing the floor perpetual: a synthetic NFT that tracks the floor price of a given project and can be minted by locking up NFTs from that project. - [Power Perpetuals](https://www.paradigm.xyz/writing/power-perpetuals) — Introducing a new type of derivative: the power perpetual. - [Two Rights Might Make A Wrong](https://www.paradigm.xyz/writing/two-rights-might-make-a-wrong) — It only takes one vulnerability to cause serious financial damage to hundreds if not thousands of innocent users. Breaking down how I found and helped patch a vulnerability that put over 109k ETH at risk. - [The Dangers of Surprising Code](https://www.paradigm.xyz/writing/the-dangers-of-surprising-code) — If you work in software engineering, odds are you've heard of at least one software engineering principle. While I wouldn't advocate for religiously following every principle to the letter, there are a few that are really worth paying attention to. - [TWAMM](https://www.paradigm.xyz/writing/twamm) — This paper introduces a new type of automated market maker, or AMM, that helps traders on Ethereum efficiently execute large orders -- The time-weighted average market maker, or TWAMM (pronounced "tee-wham"). - [Ethereum Reorgs After The Merge](https://www.paradigm.xyz/writing/ethereum-reorgs-after-the-merge) — There has recently been discussion about the possibility of miners adopting a hypothetical modified Ethereum client that allows them to essentially accept bribes to make a short reorg of the chain (the main use case for making such bribes being to attack DeFi protocols). - [Expanding our Research Team](https://www.paradigm.xyz/writing/expanding-our-research-team) — At Paradigm, we have always been focused on finding special people, whether it’s the entrepreneurs we back, or the people we bring onto our team. - [Creators, Communities, and Crypto Part II](https://www.paradigm.xyz/writing/creators-communities-and-crypto-part-ii) — Discussion between Jesse Walden, Blake Robbins, and Fred Ehrsam about the future of Creators, Communities, and Crypto. - [Uniswap v3: The Universal AMM](https://www.paradigm.xyz/writing/uniswap-v3-the-universal-amm) — Uniswap v3 allows liquidity providers to provide custom amounts of liquidity in selected price ranges. This unlocks tremendous capital efficiency gains for liquidity providers who can manually adjust their exposure. - [How mistX uses Flashbots bundles to provide frontrunning protection](https://www.paradigm.xyz/writing/how-mistx-uses-flashbots-bundles-to-provide-frontrunning-protection) — Examining mistX, a "gasless exchange" leveraging Flashbots bundles for transaction. - [Booby Trapping the Ethereum Blockchain](https://www.paradigm.xyz/writing/booby-trapping-the-ethereum-blockchain) — This is the second in a series of blog posts about bugs I've found in go-ethereum (Geth). If you haven't already, take a look at Part 1 here. Today's post is about a bug - [Liquidity Mining on Uniswap v3](https://www.paradigm.xyz/writing/liquidity-mining-on-uniswap-v3) — Uniswap v3 replaces fungible ERC-20 liquidity positions with non-fungible ERC-721 liquidity positions. Does that mean it no longer supports flexible Uniswap-v2-style liquidity mining? Or that liquidity mining programs will have to be actively managed, selecting specific ranges to incentivize? Or that liquidity mining programs could be gamed by providing huge amounts of inactive liquidity? - [Everlasting Options](https://www.paradigm.xyz/writing/everlasting-options) — This paper introduces a new type of derivative, the everlasting option. Everlasting options give traders long-term options exposure without the effort, risk, or expense of rolling positions. - [On Staking Pools and Staking Derivatives](https://www.paradigm.xyz/writing/on-staking-pools-and-staking-derivatives) — The transition from Proof of Work (PoW) to Proof of Stake (PoS) is Ethereum’s most anticipated milestone since its inception. We explore the problems that ETH stakers experience today, and show how staking pools and staking derivatives solve these problems while increasing the effective security of the network. - [Uncovering a Four Year Old Bug](https://www.paradigm.xyz/writing/uncovering-a-four-year-old-bug) — Uncovering a Four Year Old Bug - [Understanding Automated Market-Makers, Part 1: Price Impact](https://www.paradigm.xyz/writing/understanding-automated-market-makers-part-1-price-impact) — Every day, thousands of people use a decentralized exchange (DEX) for the first time. However, the idiosyncrasies of a public blockchain routinely catch newcomers off-guard, even those familiar with trading on more traditional venues. - [Paradigm CTF 2021 - swap](https://www.paradigm.xyz/writing/paradigm-ctf-2021-swap) — Paradigm CTF 2021 took place in early February and together, players solved all but two of the challenges during the competition (and one of the remaining two mere days later). We're taking a look at the "swap" challenge in the form of a guided walkthrough. - [A Cosmos Thesis](https://www.paradigm.xyz/writing/a-cosmos-thesis) — On Ethereum, all applications run on a shared state machine. In Cosmos, many application-specific blockchains pass assets and other messages between one another. If Ethereum is a mainframe computer, Cosmos is a protocol for networking independent servers. - [The Block Mined In January, 584942419325](https://www.paradigm.xyz/writing/the-block-mined-in-january-584942419325) — This is the first in a series of blog posts about the bugs I've found in go-ethereum (Geth), the official Golang implementation of the Ethereum protocol. While you don't need a deep understanding of Geth in order to follow these blog posts, knowledge of how Ethereum itself works will be helpful. This first post is about a bug in Geth's uncle validation routine which did not behave correctly given a specially crafted uncle. If exploited, this could have caused an accidental fork between Geth and Parity nodes. - [Ethereum Blockspace - Who Gets What and Why](https://www.paradigm.xyz/writing/ethereum-blockspace-who-gets-what-and-why) — Blockspace is the commodity that powers the heartbeats of all cryptocurrency networks. In the blockspace market, miners are the producers, mining pools are the auctioneers, and users are the bidders. The influences of the blockspace market are so pervasive that they touch almost every facet of the cryptocurrency ecosystem. - [Surviving Crypto Cycles](https://www.paradigm.xyz/writing/surviving-crypto-cycles) — How to survive a crypto cycle. - [The Cartoon Guide to Perps](https://www.paradigm.xyz/writing/the-cartoon-guide-to-perps) — In this post, I’ll share what I learned: four very different (but mathematically identical) mental models for what perps are, how they work, and when they don’t. - [The Future of NFTs](https://www.paradigm.xyz/writing/the-future-of-nfts) — A live discussion about the future of NFTs. - [Establishing Bounds for Miner Revenue in EIP-1559](https://www.paradigm.xyz/writing/establishing-bounds-for-miner-revenue-in-eip-1559) — We believe that the impact of EIP-1559 on both miner revenue and ETH holders has not been well explored. The main reason this analysis has been difficult before is that miner-extractable value has started to make up a large share of miner revenue due to constant arbitrage opportunities in Defi. - [Miners will accept EIP-1559, here is why](https://www.paradigm.xyz/writing/miners-will-accept-eip-1559-here-is-why) — EIP-1559 is one of the most highly-anticipated Ethereum upgrades of all time, radically changing how users bid for transactions, among other major benefits. - [MEV and me](https://www.paradigm.xyz/writing/mev-and-me) — Ethereum’s core insight was that flexible smart contracts allow developers to explore a new frontier of permissionless applications. The explosive growth of decentralized financial protocols built on Ethereum (“DeFi”) is a glimpse at what this innovation could enable in the future. Like programming libraries in the first Internet revolution, DeFi’s “money legos” enable developers to build complex systems by composing and remixing simple building blocks. This complexity also brings novel risks. One of these risks is Miner Extractable Value, or MEV. - [How does Optimism's Rollup really work?](https://www.paradigm.xyz/writing/how-does-optimism-s-rollup-really-work) — This article is for everyone who is familiar with Optimistic Rollup as a mechanism and wants to learn how Optimism’s solution works, and evaluate the proposed system’s performance and security. We explain the motivation behind each design decision and then proceed to dissect Optimism’s system, along with links to the corresponding code for each analyzed component. - [(Almost) Everything you need to know about Optimistic Rollup](https://www.paradigm.xyz/writing/almost-everything-you-need-to-know-about-optimistic-rollup) — In this post, we dive into the principles of modern “Layer 2 solutions”, their corresponding security model, and how they can solve Ethereum’s scalability issues. This blogpost is targeted at “crypto-curious” individuals interested in learning more about cutting-edge Ethereum scaling techniques as well as developing a motivation on how to build and architect such systems. - [Paradigm's Open Problems: A Series](https://www.paradigm.xyz/writing/paradigm-s-open-problems-a-series) — About a month ago, we finally got around to publishing a truly wicked problem that had been plaguing my partner Dan Robinson and I for nearly two years. It was a Hail Mary pass; mostly, we hoped it would encourage whoever ended up cracking it to give us some closure, maybe years down the road. - [Uniswap's Financial Alchemy](https://www.paradigm.xyz/writing/uniswaps-alchemy) — An investigation into the nature of constant product markets. - [So you want to use a price oracle](https://www.paradigm.xyz/writing/so-you-want-to-use-a-price-oracle) — Everything you need to know about price oracles and how to use them safely. - [Governance Minimization](https://www.paradigm.xyz/writing/governance-minimization) — Governance minimization allows stakeholders to depend on a protocol. This creates a virtuous cycle of adoption, enabling scale that would otherwise be unachievable. Look no further than successful traditional internet protocols like HTTP and SMTP to see this power today. - [Crypto Market Structure 3.0](https://www.paradigm.xyz/writing/crypto-market-structure-3-0) — A discussion on the crypto market structure overtime. - [Escaping the Dark Forest](https://www.paradigm.xyz/writing/escaping-the-dark-forest) — On September 15, 2020, a small group of people worked through the night to rescue over 9.6MM USD from a vulnerable smart contract. This is our story. - [Ethereum is a Dark Forest](https://www.paradigm.xyz/writing/ethereum-is-a-dark-forest) — It’s no secret that the Ethereum blockchain is a highly adversarial environment. If a smart contract can be exploited for profit, it eventually will be. But this unforgiving environment pales in comparison to the mempool. If the chain itself is a battleground, the mempool is something worse: a dark forest. - [Crypto-native Insurance](https://www.paradigm.xyz/writing/crypto-native-insurance) — Crypto-native insurance has the potential to be the next big financial primitive in DeFi. - [Joining Paradigm](https://www.paradigm.xyz/writing/joining-paradigm-georgios-konstantopoulos) — Georgios Konstantopoulos joins Paradigm as a Research Partner. - [Funding Bitcoin development](https://www.paradigm.xyz/writing/funding-bitcoin-development) — Announcing our support for Anthony Towns' work on Bitcoin Core. - [Analysis of EIP-2593 (Escalator)](https://www.paradigm.xyz/writing/analysis-of-eip-2593-escalator) — Today, we continue our analysis of blockspace market proposals by looking at EIP-2593, more widely known as “escalating bid algorithm”, or simply “escalator”. It is being advertised as an alternative to EIP-1559 with a big overlap in design goals. - [Creators, Communities, and Crypto](https://www.paradigm.xyz/writing/creators-communities-and-crypto) — A discussion between Fred and Blake Robbins on digital creators, communities and crypto. - [Analysis of EIP-1559](https://www.paradigm.xyz/writing/analysis-of-eip-1559) — Ethereum improvement proposal (EIP) 1559 will be the largest change to how users bid for blockspace in any of the major blockchains. - [Bitcoin for the open-minded skeptic](https://www.paradigm.xyz/writing/bitcoin-for-the-open-minded-skeptic) — A discussion on Bitcoin for skeptics. - [7 Things To Read About Bitcoin (For Institutional Investors)](https://www.paradigm.xyz/writing/7-things-to-read-about-bitcoin-for-institutional-investors) — Demystifying Bitcoin for a new cohort of investors. - [The Yield Protocol: On-Chain Lending With Interest Rate Discovery](https://www.paradigm.xyz/writing/the-yield-protocol-on-chain-lending-with-interest-rate-discovery) — This paper presents a sketch of a new building block for decentralized finance: yTokens. yTokens are like zero-coupon bonds: on-chain obligations that settle on a specific future date based on the price of some target asset, and are secured by collateral in another asset. - [An analysis of Uniswap markets](https://www.paradigm.xyz/writing/an-analysis-of-uniswap-markets) — Uniswap — and other constant product markets — appear to work well in practice despite their simplicity. In this paper, we give a simple formal analysis of constant product markets and their generalizations, showing that, under some common conditions, these markets must closely track the reference market price. - [Joining Paradigm](https://www.paradigm.xyz/writing/joining-paradigm-arjun-balaji) — Arjun Balaji joins Paradigm as an Investment Partner. - [The Rainbow Network: An Off-Chain Decentralized Synthetics Exchange](https://www.paradigm.xyz/writing/the-rainbow-network-an-off-chain-decentralized-synthetics-exchange) — This paper presents the Rainbow Network, a design for an off-chain non-custodial exchange and payment network supporting any assets for which two parties can agree on a price oracle. - [Joining Paradigm](https://www.paradigm.xyz/writing/joining-paradigm-dan-robinson) — Dan Robinson joins Paradigm as a Research Partner. ## https://www.paradigm.xyz/frontiers-2026/faq # Frontiers 2026 FAQ ### How do I attend? Attendance is by application and approval. Apply through the form on this site and our team will review your submission. If you're approved, we'll notify you with details about the event. Applications are reviewed on a rolling basis and close in mid-September. ### Who should apply? Frontiers is built for hyper-technical builders: application and infrastructure engineers, researchers, protocol developers, and open source contributors. If you're shipping at the frontier, this is for you. ### What’s the format of the event? Day 1 (Mon, Oct 12): Kickoff talk and evening reception. Day 2 (Tue, Oct 13): Mainstage technical talks in the morning, hacking through the evening. Day 3 (Wed, Oct 14): Morning talks, hacking, and hackathon presentations to close. ### What does the hackathon involve? The hackathon runs throughout the event. We will provide preview access & credits to AI tooling for participants. Our engineering team will be on-site to advise. Hack solo or in a team. ### Will the talks be recorded or streamed? Yes. All sessions are live streamed during the event and remain available afterward on our YouTube channel, so you can catch anything you missed or revisit a talk later. The hackathon itself isn't streamed, keeping the building space focused and low-pressure. ### Is there a cost to attend and what is included? Frontiers is free to attend with approval of your application. Breakfast, lunch, and snacks are provided throughout, along with evening receptions. ### Do you cover travel or hotels? We're unable to cover travel expenses. Preferred hotels near the venue will be recommended upon acceptance. ### Who can I contact with questions? Reach out to [frontiers@paradigm.xyz](mailto:frontiers@paradigm.xyz) with any questions about the event, travel or your application. ## https://www.paradigm.xyz/research # Research Investing and research are one integrated team at Paradigm. We work on technical problems in which theory and implementation inform each other. We build open source systems, contribute to research, and help founders reason from first principles. Our work is meant to expand what builders can prove, deploy, and scale. ## RSI Simulator A web game and explorer to demonstrate the economics of AI R&D. These tools can be helpful for understanding the inputs and constraints of recursive self-improvement. [https://www.paradigm.xyz/research/rsi](https://www.paradigm.xyz/research/rsi) Research Index Our research spans cryptography and markets to AI security and protocol design. It manifests in open source tools, protocol contributions, and new primitives for builders. - [RSI Simulator](https://www.paradigm.xyz/writing/rsi-simulator) — An interactive web game and model explorer from Paradigm that demonstrates the economics of recursive self-improvement and AI R&D. - [Introducing EVMbench](https://www.paradigm.xyz/writing/evmbench) — Paradigm and OpenAI build EVMbench as an open evaluation framework that tests AI agents across detecting, patching, and exploiting vulnerabilities. - [PACTs: Protecting Your Bitcoin From a Quantum Sunset](https://www.paradigm.xyz/writing/pacts-protecting-your-bitcoin-from-a-quantum-sunset) — A possible way for Bitcoin holders to protect themselves from having their funds frozen in an emergency post-quantum hard fork—without having to publicly move their coins. - [Orbital](https://www.paradigm.xyz/writing/orbital) — The future holds a million stablecoins. Today's infrastructure isn't ready. This paper introduces Orbital, an automated market maker for pools of 2, 3, or 10,000 stablecoins. Orbital unlocks capital efficiency by bringing concentrated liquidity to unlimited dimensions. - [GPU World](https://www.paradigm.xyz/writing/gpu-world) — GPU World: A story competition from Neal Stephenson, Gwern, and Matt Huang. What if the world had one GPU per person? $100K in total prizes. - [RSI Simulator](https://www.paradigm.xyz/writing/rsi-simulator) — An interactive web game and model explorer from Paradigm that demonstrates the economics of recursive self-improvement and AI R&D. - [Centaur 2.0: Permissions, Context, and MCP](https://www.paradigm.xyz/writing/centaur-2-0-permissions-context-and-mcp) — We’re launching Centaur 2.0 with better permissions, broader tool access, and a faster, more reliable foundation. - [Formally Verifying a Compiler Using Automated Research](https://www.paradigm.xyz/writing/solidus) — We formally verified a compiler using Lean and are launching two new challenges to improve it, as an experiment in collaborative research. - [Project Kryptos](https://www.paradigm.xyz/writing/kryptos) — Paradigm is now the steward of the solution to Kryptos, one of the last great cryptography puzzles — but it's a secret, even to us. Now we’re looking for more people to try to find the solution. - [Open Sourcing Centaur: Multiplayer, self-hosted, secure agents](https://www.paradigm.xyz/writing/open-sourcing-centaur-multiplayer-self-hosted-secure-agents) — Paradigm and Tempo open source Centaur, a Slack-native multiplayer, self-hosted and secure agent for investing, building, and researching. - [PACTs: Protecting Your Bitcoin From a Quantum Sunset](https://www.paradigm.xyz/writing/pacts-protecting-your-bitcoin-from-a-quantum-sunset) — A possible way for Bitcoin holders to protect themselves from having their funds frozen in an emergency post-quantum hard fork—without having to publicly move their coins. - [Introducing Paradigm Predictions](https://www.paradigm.xyz/writing/introducing-paradigm-predictions) — Paradigm Predictions is a tool for exploring the landscape of prediction markets. We aim to make prediction market data intuitive, accessible, and easy to explore. - [Polymarket Volume Is Being Double-Counted](https://www.paradigm.xyz/writing/polymarket-volume-is-being-double-counted) — After analyzing Polymarket’s market structure, event data, and smart contracts, we discovered that most Polymarket analyses and dashboards have been mistakenly double-counting volume. - [Opportunity Markets](https://www.paradigm.xyz/writing/opportunity-markets) — Introducing opportunity markets, private prediction markets where those who spot opportunities get paid by those who can act on them - [Quantum Markets](https://www.paradigm.xyz/writing/quantum-markets) — A capital efficient mechanism for scaling futarchy. - [Orbital](https://www.paradigm.xyz/writing/orbital) — The future holds a million stablecoins. Today's infrastructure isn't ready. This paper introduces Orbital, an automated market maker for pools of 2, 3, or 10,000 stablecoins. Orbital unlocks capital efficiency by bringing concentrated liquidity to unlimited dimensions. ## Prediction Markets Open Interest Distribution A new tool for exploring the full landscape of prediction markets, from weather and elections to the economy and scientific discoveries. Browse, zoom, and filter across platforms to see the big picture of how the world is pricing the future. [https://predictions.paradigm.xyz](https://predictions.paradigm.xyz) ## Project Kryptos Paradigm is the steward of the solution to Kryptos, a cryptography puzzle that has gone unsolved for 35 years. Our new capture-the-flag contest encourages the development of better techniques for solving Kryptos and puzzles like it. [https://paradigm.xyz/kryptos](https://paradigm.xyz/kryptos) ## Paradigm Puzzles Hard problems, by design A series of cryptographic challenges and technical puzzles designed for builders and researchers who want to go deeper — into protocol design, security assumptions, and the unsolved edges of the stack. [https://paradigm.xyz/puzzles](https://paradigm.xyz/puzzles) ## Programs - [Hyperion](https://paradigm.xyz/hyperion-2026) — 2026-06 - [Paradigm Fellowship 2026](https://paradigm.xyz/fellowship-2026) — 2026-08 ## https://www.paradigm.xyz/build # Build Many of us have built tools, protocols, and companies that are among the most used on the internet. We write software, much of it open source, and we incubate new companies, from developer tools like Foundry and Reth to Tempo, a payments network we created with Stripe. We also build alongside others, including [security evals with OpenAI](https://openai.com/index/introducing-evmbench/). ## Incubation: Tempo Tempo is a payments-first Layer 1 blockchain incubated by Stripe and Paradigm. Built for stablecoins and real-world transactions, Tempo is designed to support faster, lower-cost, programmable payments at global scale. [https://tempo.xyz](https://tempo.xyz) ## Open Source Paradigm builds and contributes to projects that advance the frontier. We believe in doing so even when there may not be a direct commercial incentive. - [Centaur](https://github.com/paradigmxyz/centaur) — Multiplayer, self-hosted, secure agents for Slack. - [EVMbench](https://github.com/paradigmxyz/evmbench) — An open benchmark and agent harness from OpenAI and Paradigm that evaluates whether AI agents can detect, patch, and exploit high-severity vulnerabilities. - [Foundry](https://github.com/foundry-rs/foundry) — Blazing fast, portable and modular toolkit for Ethereum application development written in Rust. - [Reth](https://github.com/paradigmxyz/reth) — Modular, contributor-friendly and blazing-fast implementation of the Ethereum protocol, written in Rust. - [Alloy](https://github.com/alloy-rs/alloy) — Stable, well-tested, and performant building blocks for Ethereum, in Rust. - [Artemis](https://github.com/paradigmxyz/artemis) — Framework for MEV bots in Rust, designed to be simple, modular, and fast. - [Cryo](https://github.com/paradigmxyz/cryo) — Easiest way to extract blockchain data to Parquet, CSV, JSON, or a Python dataframe. - [Solar](https://github.com/paradigmxyz/solar) — Blazingly fast, modular and contributor friendly Solidity compiler, written in Rust. - [Flood](https://github.com/paradigmxyz/flood) — Load testing tool for benchmarking EVM nodes over RPC. - [Flux](https://github.com/paradigmxyz/flux) — Graph-based LLM power tool for exploring many completions in parallel. - [Data Portal](https://github.com/paradigmxyz/paradigm-data-portal) — Collection of open source crypto datasets for researchers and tool builders. - [Rivet](https://github.com/paradigmxyz/rivet) — Browser extension that enables developers to inspect, debug, modify, and manipulate the state of Ethereum. - [Wagmi](https://github.com/wevm/wagmi) — Developer library with over 20 hooks for working with wallets, contracts, transactions, signing, and more. - [Viem](https://github.com/wevm/viem) — Fast, modular Typescript interface for Ethereum developers. - [Centaur 2.0: Permissions, Context, and MCP](https://www.paradigm.xyz/writing/centaur-2-0-permissions-context-and-mcp) — We’re launching Centaur 2.0 with better permissions, broader tool access, and a faster, more reliable foundation. - [Introducing EVMbench](https://www.paradigm.xyz/writing/evmbench) — Paradigm and OpenAI build EVMbench as an open evaluation framework that tests AI agents across detecting, patching, and exploiting vulnerabilities. - [Introducing Paradigm Predictions](https://www.paradigm.xyz/writing/introducing-paradigm-predictions) — Paradigm Predictions is a tool for exploring the landscape of prediction markets. We aim to make prediction market data intuitive, accessible, and easy to explore. - [Introducing the 2026 Paradigm Fellowship](https://www.paradigm.xyz/writing/introducing-the-2026-paradigm-fellowship) — Applications are open for the 2026 Paradigm Fellowship. Four days, ~30 people, Northern California. August 12–15. ## https://www.paradigm.xyz/investment-disclosures # Investment Disclosures Investment Disclosures The current and historical investments or portfolio companies mentioned, referred to, or described on this page are not representative of all investments in vehicles managed by Paradigm and there can be no assurance that the investments will be profitable or that other investments made in the future will have similar characteristics or results. Excluded are positions that remain confidential due to competitive considerations or are pending public announcement by portfolio companies, as well as portfolio companies that have shut down without a liquidity event or exit and for which the equity has been written to zero without the corresponding receipt of another asset. Further, the list of investments is updated periodically, and as such may not reflect the most recent Paradigm investments. Past results of Paradigm's investments, pooled investment vehicles, or investment strategies are not indicative of future results. The liquid token positions presented reflect certain holdings of Paradigm's closed-end funds and are provided for informational purposes only. Position sizes fluctuate and are subject to change without notice. Nothing contained on this page or Paradigm's social media constitutes, or should be construed as, an offer to sell or a solicitation of an offer to buy any security, or as investment advice. | 3Jane Across Agora AI Arena Amber Andromeda Antares Argent Art Gobblers Axiom Aztec Babylon BetDex Bitso Blast Blowfish Blur Chainalysis Citadel Securities Code4rena Coinbase CoinSwitch Compound Conduit Cosmos (ATOM) Crown D3 Dework Divine dYdX EDX Markets El Dorado Ellipsis Labs Etherealize Euler Exponential Fab2 Farcaster Fireblocks Flashbots Fractal friend.tech Gauntlet Genesis Digital Assets Gitcoin Global Illumination GTE Guidestar Hang Harmonic (AI lab) Harmonic (Solana) Hyperliquid (HYPE) Intrinsic Irreducible Ithaca Jambo Jet Protocol Kalshi Keep Network Kuru Labs Lido Lightspark Limit Break Liquid Lootrush | M1X Global Mad Realities Magic Eden Maker (MKR) Matrixport Mesh Connect MetaDAO Monad Moonpay Morpho N3XT Namebase Nebulous Noble Noise Nous Research NXYZ O(1) Labs OpenSea Optimism Opyn Osmosis ParagonDAO Parallel Parallel Editions Phantom Pixie Chess Plural Privy Rain Reddio Reflexer Labs Revolut Ribbon Finance Rift Royal SendCutSend Showtime Sky Mavis Sorella Labs Spacemesh Standard Economics Starkware Stripe Succinct Sup Symbiotic Synthetix (SNX) Tagomi Talarion TaxBit Tempo Tendermint Tessera True Anomaly Uniswap Utopia Labs Vana Veil Ventuals (formerly Shadow) Wildcard Yield Zcash Open Development Lab Zipline Zora | | --- | --- | ## https://www.paradigm.xyz/about # About Paradigm is a technology investment firm. We live on the frontier and believe in progress through technology. We invest in areas with the greatest rates of technological change, including crypto, AI, robotics, and other frontiers. We back founders at every stage from first check through to public markets. We're builders and investors. Many of us have worked on tools, protocols, and companies that are now some of the most used on the internet. We build software, much of it open source, that aims to advance what’s possible. We believe depth is a prerequisite for invention, and that real progress happens close to the metal, not in the boardroom or the ivory tower. We are as likely to collaborate on a research paper or ship code as we are to partner on product, business, or policy strategy. If you're building something ambitious at the frontier, come work with us. - **2018** Founded - **130+** Investments - [Announcing Our Fourth Fund](https://www.paradigm.xyz/writing/announcing-our-fourth-fund) — Paradigm has raised our fourth fund: $1.2B to back the most ambitious builders at the frontier of technology. - [Colossus Profile: Paradigm Shifts](https://colossus.com/article/paradigm-shifts-matt-huang/) - [Project Kryptos](https://www.paradigm.xyz/writing/kryptos) — Paradigm is now the steward of the solution to Kryptos, one of the last great cryptography puzzles — but it's a secret, even to us. Now we’re looking for more people to try to find the solution. - [Introducing the 2026 Paradigm Fellowship](https://www.paradigm.xyz/writing/introducing-the-2026-paradigm-fellowship) — Applications are open for the 2026 Paradigm Fellowship. Four days, ~30 people, Northern California. August 12–15. ## “A paradigm is a reconstruction of the field from new fundamentals” —Thomas Kuhn ## Leadership - [Matt Huang](https://www.paradigm.xyz/team/matt-huang) — Co-Founder & Managing Partner - [Alana Palmedo](https://www.paradigm.xyz/team/alana-palmedo) — Managing Partner Contact | San Francisco [sf@paradigm.xyz](mailto:sf@paradigm.xyz) General Inquiries [info@paradigm.xyz](mailto:info@paradigm.xyz) | New York City [nyc@paradigm.xyz](mailto:nyc@paradigm.xyz) Press Inquiries [press@paradigm.xyz](mailto:press@paradigm.xyz) | Washington DC [dc@paradigm.xyz](mailto:dc@paradigm.xyz) Coworking [coworking@paradigm.xyz](mailto:coworking@paradigm.xyz) | | --- | --- | --- | ## https://www.paradigm.xyz/oss # Open Source ## Open Source Paradigm builds and contributes to projects that advance the frontier. We believe in doing so even when there may not be a direct commercial incentive. - [Centaur](https://github.com/paradigmxyz/centaur) — Multiplayer, self-hosted, secure agents for Slack. - [EVMbench](https://github.com/paradigmxyz/evmbench) — An open benchmark and agent harness from OpenAI and Paradigm that evaluates whether AI agents can detect, patch, and exploit high-severity vulnerabilities. - [Foundry](https://github.com/foundry-rs/foundry) — Blazing fast, portable and modular toolkit for Ethereum application development written in Rust. - [Reth](https://github.com/paradigmxyz/reth) — Modular, contributor-friendly and blazing-fast implementation of the Ethereum protocol, written in Rust. - [Alloy](https://github.com/alloy-rs/alloy) — Stable, well-tested, and performant building blocks for Ethereum, in Rust. - [Artemis](https://github.com/paradigmxyz/artemis) — Framework for MEV bots in Rust, designed to be simple, modular, and fast. - [Cryo](https://github.com/paradigmxyz/cryo) — Easiest way to extract blockchain data to Parquet, CSV, JSON, or a Python dataframe. - [Solar](https://github.com/paradigmxyz/solar) — Blazingly fast, modular and contributor friendly Solidity compiler, written in Rust. - [Flood](https://github.com/paradigmxyz/flood) — Load testing tool for benchmarking EVM nodes over RPC. - [Flux](https://github.com/paradigmxyz/flux) — Graph-based LLM power tool for exploring many completions in parallel. - [Data Portal](https://github.com/paradigmxyz/paradigm-data-portal) — Collection of open source crypto datasets for researchers and tool builders. - [Rivet](https://github.com/paradigmxyz/rivet) — Browser extension that enables developers to inspect, debug, modify, and manipulate the state of Ethereum. - [Wagmi](https://github.com/wevm/wagmi) — Developer library with over 20 hooks for working with wallets, contracts, transactions, signing, and more. - [Viem](https://github.com/wevm/viem) — Fast, modular Typescript interface for Ethereum developers. ## https://www.paradigm.xyz/disclosures # Disclosures Important Disclosures This website (the “Website”) is intended solely to provide general information about Paradigm Operations LP (together with its affiliates, “Paradigm,” “we,” “our,” or “us”), its services to entrepreneurs and management teams, and its personnel. Nothing on the Website is directed at or should be relied upon by any investors or prospective investors in any vehicle managed by Paradigm. Paradigm does not intend to solicit or make its investment advisory services available to the general public. Under no circumstances should any information provided on this Website be considered as an offer soliciting the purchase or sale of any security or interest in any pooled investment vehicle sponsored by Paradigm, nor should it be construed as an offer to provide investment advisory services. Such offers or solicitations will be made separately and only by means of the confidential offering documents of the specific pooled investment vehicles, which should be read in their entirety, and only to those who, among other requirements, meet certain qualifications under federal securities laws. The investments and strategies discussed on this Website may not be suitable for all investors and are not obligations of or guaranteed by Paradigm. Nothing on this Website constitutes investment, accounting, tax or legal advice or is a recommendation that you purchase, sell or hold any security or other investment or that you pursue any investment style or strategy. Any investments or portfolio companies described or referred to on this Website are not representative of all investments made by funds managed by Paradigm and there can be no assurance that the investments described are, or will be, profitable or that other investments made in the future will have similar character or results. Past performance is not indicative of future results. Statements, quotes or “posts” (whether contained on this website or in any podcasts, videos and social media material) by Paradigm personnel and third parties reflect the sole views or opinions of the individual and do not reflect the views of Paradigm. Such statements are subjective and cannot be independently verified. There is no assurance that another market participant would share the same views. This Website may contain forward-looking statements, which can be identified by the use of words such as “outlook,” “believe,” “expect,” “potential,” “continue,” “may,” “should,” “seek,” “approximately,” “predict,” “intend,” “will,” “plan,” “estimate,” “anticipate” or the negative version of these words or other comparable words. Forward-looking statements are subject to various risks and uncertainties, speak only as of the date on which they are made and are subject to change. Forward-looking statements are not guarantees of the underlying expected actions or future performance and future results may differ significantly from those anticipated by the forward-looking statements. Paradigm undertakes no obligation to publicly update or review any forward-looking statement, whether as a result of new information, future developments or otherwise. Certain quotes and/or videos shown on the Website include statements provided by certain personnel of portfolio companies or other investments, some of whom may also be invested in the Paradigm funds. None of these individuals were compensated for providing these statements. These individuals have an incentive to make positive statements about Paradigm to maintain goodwill with Paradigm. Third party statements reflect the subjective views of the speaker and Paradigm has not independently verified such information and makes no representation or warranty, express or implied, as to the accuracy or completeness of the information contained herein. Any forward-looking statements and/or opinions expressed by third parties are subject to change without notice and may differ or be contrary to opinions expressed by others. Information on this Website speaks only as of the date indicated. Paradigm may not promptly update or correct this Website even if it is aware that information is inaccurate, outdated or otherwise inappropriate. Any opinions expressed on this Website are subject to change. You agree that Paradigm is not responsible for any action that you take or decision you make in reliance on any information contained on this Website. ## https://www.paradigm.xyz/terms # Terms Website Terms of Use Paradigm Operations LP (“Paradigm,” “we,” “us,” or “our”) operates paradigm.xyz and related websites (collectively, the “Site”). This Website Terms of Use (the “Terms”) govern access to and use of the Site and constitute a legal agreement between you and Paradigm. By accessing or using the Site, you agree to these Terms. If you do not agree to these Terms, please do not access or use the Site. We suggest that you review these Terms periodically for changes. All materials on the Site are meant to be reviewed in their entirety, including any footnotes, legal disclaimers, restrictions or disclosures, and any copyright or proprietary notices. Any disclaimers, restrictions, disclosures or hedge clauses apply to any partial document or material in the same manner as they do the whole, and will be deemed incorporated in the portion of any material or document that you consult or download. If you have any questions about these Terms, please contact legalops@paradigm.xyz. All references to “you” or “your,” as applicable, mean the person who accesses, uses, and/or participates in the Site in any manner, and each of your heirs, assigns, and successors. If you use the Site on behalf of an entity or another individual, you represent and warrant that you have the authority to bind that entity or individual, your acceptance of the Terms will be deemed an acceptance by that entity or individual, and “you” and ”your” herein shall refer to that entity, its directors, officers, employees, and agents. Eligibility Access to and use of the Site is available only to individuals who can form legally binding contracts under applicable law. By accessing or using the Site, you represent and warrant that you meet these eligibility criteria. Ownership of the Site and its Content The Site contains proprietary content, information and material that is protected by applicable intellectual property and other laws, including copyright. All content, related intellectual property, and other rights are the sole and exclusive property of Paradigm, its affiliates, and/or its licensors, unless Paradigm expressly grants them to another. Subject to your complete and ongoing compliance with these Terms, Paradigm grants you a non-transferable, non-exclusive, revocable, limited license to access and use the Site for personal use. You may also discuss information you learn from the Site with your financial, legal or tax advisors, and others with whom you share investment decisions. We reserve all rights not expressly granted to you by these Terms. The Site (including, but not limited to, text, photographs, graphics, video, audio content, and computer code) are protected by copyright as collective works or compilation under the copyright laws of the United States and other countries. All individual articles, photographs, graphics, video, audio, and other content or elements comprising the Site are also copyrighted works. All copyrights in the Site are owned by us or by our third-party licensors to the extent permitted under the United States Copyright Act and all international copyright laws. All rights in the product names, company names, trade names, logos, service marks, trade dress, slogans, product packaging, and designs of the Site, whether or not appearing in large print or with the trademark symbol, belong exclusively to Paradigm, its affiliates, and/or its licensors and are protected from reproduction, imitation, dilution, or confusing or misleading uses under national and international trademark and copyright laws. The use or misuse of these trademarks or any materials, except as permitted herein, is expressly prohibited, and nothing stated or implied on the Site confers on you any license or right under any patent or trademark of Paradigm, its affiliates, or any third party. Except where expressly authorized by Paradigm in writing, you are prohibited from publishing, reproducing, distributing, entering into a database, displaying, performing, modifying, creating derivative works, transmitting, or in any way exploiting any part of the Site. You may print copies of any accessible portion of the Site only for your own personal use. Feedback By sending us any feedback, comments, questions, or suggestions concerning Paradigm, the Site, or any services we may provide (collectively, “Feedback”), you represent and warrant (a) that you have the right to disclose the Feedback, (b) that the Feedback does not violate the rights of any other person or entity, and (c) that your Feedback does not contain the confidential or proprietary information of any third party or parties. By sending us any Feedback, you further (i) agree that we are under no obligation of confidentiality, express or implied, with respect to the Feedback, (ii) acknowledge that we may have something similar to the Feedback already under consideration or in development, (iii) grant us an irrevocable, non-exclusive, royalty-free, perpetual, worldwide license to use, modify, prepare derivative works, publish, distribute, and sublicense the Feedback, and (iv) irrevocably waive, and cause to be waived, against Paradigm and its agents, employees, or directors any claims and assertions of any moral rights contained in such Feedback. This Feedback section shall survive any termination of these Terms or the Site. Privacy Policy Information we collect from the Site shall be subject to the [Paradigm Privacy Policy](/privacy), which is incorporated in these Terms by reference. Rules and Prohibitions While using the Site, you agree to comply with all applicable laws, rules, and regulations. In addition to other prohibitions in these Terms or displayed on the Site, you agree that you will not: - distribute, publish, copy, rent, lease, sublicense, assign, transmit, sell or otherwise transfer any part of the Site, including any content on the Site, unless Paradigm expressly permits in writing; - disassemble, reverse engineer, modify, translate, alter, replicate, or decompile all or any portion of the Site or otherwise discern the source code of the Site; - adapt, modify, translate, or create derivative works from the Site; - probe, circumvent, disable, or interfere with features related to security or authentication measures; - access or collect data from the Site using automated means or attempt to access data you do not have permission to access; - use the Site, or encourage others to use the Site, to create, collect, transmit, store, use, or process any data that violates any applicable laws, or infringes, violates or otherwise misappropriates the intellectual property or other rights of any third party (including any moral right, privacy right, or right of publicity); - use the Site or assist someone else to use the Site in an unlawful, misleading, discriminatory, harassing, or fraudulent way; - impose unreasonable requests or burdens on our systems or resources, attempt to disrupt or otherwise overwhelm our infrastructure, or interfere with the access of any other user to the Site; - use the Site to conduct any unlawful or fraudulent activities, send unsolicited communications or spam, or publish or link to malicious content designed to disrupt another individual’s browser or computer; - resell or make any commercial use of content on the Site without our prior written consent including, without limitation, using the Site to build a similar or competitive website, product, or service; - remove any copyright, trademark, or other proprietary notice or legend contained on (or printed from) the Site; - post, publish, broadcast, commercially exploit or otherwise use Paradigm’s logo or trademark for any purpose; - use the Site in any way not specifically permitted under these Terms; or - attempt to indirectly undertake any of the above. We have the right, but not the obligation, to monitor and record activity on the Site and respond as we deem appropriate. We may monitor and record activity on the Site for any reason or for no reason. We may investigate any complaint or reported violation of our policies. We may report any activity we suspect may violate any law or regulation to regulators, law enforcement officials, or other persons or entities we deem appropriate. We may issue warnings, suspend, or terminate use of the Site, deny access to all or part of the Site or take any other action we deem appropriate. We reserve all rights and remedies available to us, including but not limited to suspending or disabling your ability to access the Site for violation of these or other provisions in the Terms. Unauthorized Access The Site is not absolutely protected against unauthorized third parties. You acknowledge that any information provided through the internet may be potentially accessed by unauthorized third parties. Although Paradigm will make reasonable efforts to protect the privacy of users of the Site, no guarantee can be made that unauthorized third parties will not access the information contained on the Site. You acknowledge that Paradigm is not responsible for notifying you that unauthorized third parties have gained such access or that any data has been otherwise compromised during transmission across computer networks or telecommunications facilities, including, but not limited to, the internet. Any unauthorized use of the Site or the content herein may also violate copyright laws, trademark laws, the laws of privacy and publicity, and/or communications regulations and statutes. Paradigm does not grant, by implication, estoppel or otherwise, any license or right to use material on the Site other than those set forth above, and you shall not make any other use of such material without Paradigm’s written permission. Communications While we make commercially reasonable efforts to ensure that the Site is secure, we do not guarantee the security of the Site or your communications with us through the Site. Electronic communications can be intercepted by third parties and, accordingly, transmissions to and from the Site may not be secure. Communications to Paradigm, particularly those containing confidential information, may be sent by mail to: Paradigm Operations LP, Attn: Legal Department. Paradigm shall be free to use, for any purpose, any ideas, concepts, know-how, or techniques provided by you to Paradigm through the Site. Disclaimers YOUR USE OF THE SITE IS AT YOUR SOLE RISK. EXCEPT WHERE REQUIRED BY LAW, WE MAKE NO REPRESENTATIONS OR WARRANTIES WITH RESPECT TO THE SITE OR ITS CONTENT, OR ANY PRODUCT OR SERVICE AVAILABLE ON OR PROMOTED THROUGH THE SITE. THE SITE AND ALL OF ITS CONTENT ARE PROVIDED ON AN “AS IS,” “AS AVAILABLE” BASIS, WITHOUT REPRESENTATIONS OR WARRANTIES OF ANY KIND. CERTAIN CONTENT ON THE SITE HAS BEEN OBTAINED FROM THIRD-PARTY SOURCES, INCLUDING COMPANIES IN WHICH FUNDS MANAGED BY PARADIGM HAVE INVESTED. PARADIGM MAKES NO REPRESENTATIONS OR WARRANTIES ABOUT THE ACCURACY OF INFORMATION ON THE SITE. ANY PROJECTIONS, ESTIMATES, FORECASTS, TARGETS, PROSPECTS, OR OPINIONS ON THE SITE ARE SUBJECT TO CHANGE WITHOUT NOTICE AND MAY DIFFER OR BE CONTRARY TO OPINIONS EXPRESSED BY OTHERS. TO THE FULLEST EXTENT PERMITTED BY LAW, PARADIGM, ITS AFFILIATES, AND THEIR SERVICE PROVIDERS AND LICENSORS DISCLAIM ANY AND ALL REPRESENTATIONS AND WARRANTIES, WHETHER EXPRESS, IMPLIED, ARISING BY STATUTE, CUSTOM, COURSE OF DEALING, COURSE OF PERFORMANCE OR IN ANY OTHER WAY, WITH RESPECT TO THE SITE, ITS CONTENT, AND ANY PRODUCTS OR SERVICES AVAILABLE OR PROMOTED THROUGH THE SITE. WITHOUT LIMITING THE GENERALITY OF THE FOREGOING, PARADIGM, ITS AFFILIATES, AND THEIR SERVICE PROVIDERS AND LICENSORS DISCLAIM ALL REPRESENTATIONS AND WARRANTIES (A) OF TITLE, NON-INFRINGEMENT, MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE; (B) RELATING TO THE SECURITY OF THIS SITE; (C) THAT THE CONTENT OF THE SITE IS ACCURATE, COMPLETE OR CURRENT; OR (D) THAT THE SITE WILL OPERATE SECURELY OR WITHOUT INTERRUPTION OR ERROR. WE DO NOT REPRESENT OR WARRANT THAT THE SITE, ITS SERVERS, OR ANY TRANSMISSIONS SENT FROM US OR THROUGH THE SITE WILL BE FREE OF ANY HARMFUL COMPONENTS (INCLUDING VIRUSES). PARADIGM IS NOT RESPONSIBLE FOR ANY ERRORS OR OMISSIONS IN THE CONTENT AVAILABLE ON THE SITE OR FOR DAMAGES ARISING FROM THE USE OR PERFORMANCE OF THE SITE. APPLICABLE LAW MAY NOT ALLOW THE LIMITATION OF CERTAIN WARRANTIES, SO ALL OR PART OF THIS DISCLAIMER OF WARRANTIES MAY NOT APPLY TO YOU. Limitation of Liability IN NO EVENT SHALL PARADIGM AND/OR ITS LICENSORS BE LIABLE TO ANYONE FOR ANY DIRECT, INDIRECT, PUNITIVE, SPECIAL, EXEMPLARY, INCIDENTAL, CONSEQUENTIAL OR OTHER DAMAGES OF ANY TYPE OR KIND (INCLUDING PERSONAL INJURY, LOSS OF DATA, REVENUE, PROFITS, REPUTATION, USE OR OTHER ECONOMIC ADVANTAGE) EVEN IF PARADIGM AND/OR ITS LICENSORS HAVE BEEN PREVIOUSLY ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. THIS LIMITATION OF LIABILITY APPLIES WHETHER THE ALLEGED LIABILITY IS BASED ON CONTRACT, TORT (INCLUDING NEGLIGENCE), STRICT LIABILITY OR ANY OTHER BASIS. THE LIMITATION OF DAMAGES SET FORTH ABOVE IS A FUNDAMENTAL ELEMENT OF THE BASIS OF THE BARGAIN BETWEEN US AND YOU. THIS LIMITATION OF LIABILITY SECTION APPLIES FULLY IN ALL STATES, INCLUDING RESIDENTS OF NEW JERSEY. WITHOUT LIMITING THE FOREGOING, UNDER ALL CIRCUMSTANCES, THE MAXIMUM LIABILITY OF PARADIGM, ITS AGENTS AND EMPLOYEES WITH RESPECT TO YOUR USE OF THE SITE IS $1. Links to Other Websites and Services The Site may contain links or access to third-party content, websites, services, or systems, including portfolio companies in investments managed by Paradigm. Paradigm does not endorse any third-party content, websites, services, or systems, or guarantee their quality, accuracy, reliability, completeness, currency, timeliness, non-infringement, merchantability, or fitness for any purpose. Third-party content, websites, services, or systems are not under the control of Paradigm, and if you choose to access any such content, websites, services, or systems, you do so entirely at your own risk. Your interactions with such third parties will be governed by the third parties’ own terms of service and privacy policies, and any other similar terms. Additionally, Paradigm reserves the right to remove third-party content, and restrict or block users who post content, to comply with applicable law, including because such content may be construed to constitute testimonials, advice, recommendations or advertisements for securities-related products or services, including recommendations or testimonials of Paradigm products and services. International Use Due to the global nature of the Internet, the Site may be accessed by users in countries other than the United States. We make no warranties that materials on the Site are appropriate or available for use in such locations. If it is illegal or prohibited in your country of origin to access or use the Site, then you should not do so. Those who choose to access the Site outside the United States do so on their own initiative and are responsible for compliance with all local laws and regulations. Modification and Discontinuation of the Site We reserve the right at any time to modify, edit, delete, suspend or discontinue, temporarily or permanently, the Site (or any portion thereof) and/or the information, materials, products and/or services available through Paradigm (or any part thereof) with or without notice. You agree that we shall not be liable to you or to any third party in such event. Paradigm Social Media The information on the Site and any other pages that Paradigm may create from time to time, including, but not limited to, X (Twitter), LinkedIn, YouTube, and any other social media platforms is for informational purposes only. Nothing on or within these pages constitutes an offer to sell, or a solicitation of an offer to buy, any security or product of Paradigm or Paradigm-managed fund. Paradigm is not responsible for any content posted by third parties on these pages. Indemnity and Release You are responsible for your use of the Site, and you agree to release and defend, indemnify, and hold harmless Paradigm and its officers, directors, employees, contractors, consultants, affiliates, investors, service providers, business partners, subsidiaries and agents from and against every claim, liability, damage, loss, and expense, including reasonable attorneys’ fees and costs, arising out of or in any way connected with: (i) your violation of any of these Terms, any representation, warranty, or agreement referenced in these Terms, or any applicable law or regulation; (ii) your violation of any third-party right, including any intellectual property right or right of publicity, confidentiality, other property, or privacy right; or (iii) any dispute or issue between you and any third party arising out of your access to the Site. Paradigm reserves the right, at our own expense, to assume the exclusive defense and control of any matter otherwise subject to indemnification by you (without limiting your indemnification obligations) and you agree to cooperate with our defense of that claim. If the defense or settlement is assumed by you, Paradigm may at any time thereafter elect to take over control of the defense and settlement of the claim. You must not settle any claim without Paradigm’s prior written consent. You further release Paradigm, its officers, employees, agents, and successors from claims, demands, and damages of every kind or nature, known or unknown, suspected or unsuspected, disclosed or undisclosed, arising out of or in any way related to such disputes and/or the Site. If you are a California resident, you waive California Civil Code Section 1542, which provides: A general release does not extend to claims that the creditor or releasing party does not know or suspect to exist in his or her favor at the time of executing the release and that, if known by him or her, would have materially affected his or her settlement with the debtor or released party. If you are not a California resident, you waive your rights under any statute or common law principle similar to Section 1542 that governs your rights in the jurisdiction of your residence. In addition, you understand and agree that your use of the Site is predicated upon your waiver of any right to sue Paradigm, its agents, officers, directors and employees directly or to participate in a suit for any losses or damages resulting from your use of the Site. Notwithstanding the foregoing, nothing contained in preceding paragraphs or elsewhere in these Terms shall constitute a waiver by you of any of your legal rights under applicable U.S. federal securities laws or any other laws whose applicability is not permitted to be contractually waived. Termination Paradigm may terminate your access to the Site for any reason, without prior notice. These Terms shall survive any termination or expiration of your access to the Site. Modification of these Terms We reserve the right to update or modify the Terms at any time without prior notice, and unless otherwise stated, such changes will be effective immediately upon being posted through the Site. Your use of the Site following any such change constitutes your agreement to be bound by the modified Terms. Arbitration By using the Site, you agree that Paradigm, at its sole discretion, may require you to submit any disputes arising from the use of the Site or these Terms, including disputes arising from or concerning their interpretation, violation, nullity, invalidity, non-performance or termination, as well as disputes about filling gaps in these Terms or their adaptation to newly arisen circumstances, to final and binding arbitration under the International Rules of Arbitration (the “Rules”) of the American Arbitration Association, by one or more arbitrators appointed in accordance with the Rules. Notwithstanding the Rules, however, such proceeding shall be governed by the laws of California and will take place in the state of California. Notice for California Users Under California Civil Code Section 1789.3, California users of the Site are entitled to the following specific consumer rights notice: The Site is provided to you by Paradigm Operations LP which may be contacted regarding complaints or concerns at legalops@paradigm.xyz. The Complaint Assistance Unit of the Division of Consumer Services of the California Department of Consumer Affairs may be contacted in writing at 400 R Street, Suite 1080, Sacramento, California 95814, or by telephone at (916) 445-1254 or (800) 952-5210. General *Entire Agreement*. These Terms (together with our Privacy Policy and any other legal documents, policies, terms, or agreements governing the Site) comprise the entire agreement between you and Paradigm with regard to the Site and supersedes all prior or contemporaneous negotiations, discussions or agreements, whether written or oral, between the parties regarding the subject matter contained in these Terms. *Assignment*. You may not assign or transfer these Terms or your rights under these Terms, in whole or in part, by operation of law or otherwise, without our prior written consent. We may assign these Terms in whole or in part at any time to any entity without your notice or consent. Any purported assignment by you in violation of this section shall be void. *No Waiver*. Our failure at any time to require performance of any provision of these Terms or to exercise any right provided for herein will not be deemed a waiver of such provision or such right. All waivers must be in writing. Unless the written waiver contains an express statement to the contrary, no waiver by Paradigm of any breach of any provision of these Terms or of any right provided for herein will be construed as a waiver of any continuing or succeeding breach of such provision, a waiver of the provision itself, or a waiver of any right herein. *Severability*. If any provision of these Terms is held to be invalid or unenforceable, such provision shall be struck, and the remaining provisions shall be enforced to the fullest extent under law. *Governing Law and Venue*. These Terms are governed by the laws of the State of California without regard to conflict of law principles. You and Paradigm agree to submit to the personal and exclusive jurisdiction of the state courts and federal courts located within the State of California. You agree to bring any claim solely in your individual capacity and you expressly waive any right to bring any claim as part of a group or as a class action. *No Agency*. No joint venture, partnership, employment, or agency relationship exists between you, Paradigm, or any third-party provider as a result of the Terms or use of the Site. ## https://www.paradigm.xyz/privacy # Privacy Privacy Policy This Privacy Policy (“Privacy Policy” or “Policy”) applies to the collection and use of Personal Information by Paradigm (“Company,” “we,” “us,” or “our”). It describes the Company's practices regarding the collection, use, and disclosure of Personal Information. This Policy applies to your access and use of any of our websites (the “Site”) or online services on which we post this Policy, when you communicate with us via email, and when you engage with us offline (collectively with the Site, the “Services”). By accessing or otherwise using our Services, you agree to our collection, disclosure, and use of Personal Information as described herein and agree to our Terms of Use. This Policy does not apply to information we collect about employees, job applicants, and independent contractors. This Policy also does not govern the information handling practices of our portfolio companies. For purposes of this Policy, “Personal Information” means information that identifies, relates to, describes, is reasonably capable of being associated with, or could reasonably be linked, directly or indirectly, with a particular consumer or household. It does not include de-identified or aggregate information. Personal Information We Collect We may collect information about you when we provide our Services. We collect information directly from you, automatically when you access our Services, and from unaffiliated parties. *Information You Provide to Us Directly*: We may collect information directly from you when you use our Services, request information about our Services, provide us with your information at an event, or when you otherwise voluntarily provide information to us. *Automatically-Collected Information*: We and our vendors may use cookies and other technologies for analytics and to improve the Site. These technologies, for example, may allow us to tailor the Site to your needs, track the pages you visit, help us manage content, and compile statistics about usage of our Site. You can choose to accept or decline cookies. Most web browsers automatically accept cookies, but your browser may allow you to modify your browser settings to decline cookies if you prefer. If you disable cookies, you may be prevented from taking full advantage of the Site, because the Site may not function properly. As we adopt additional technologies, we may also gather additional information through other methods. *Information We Collect from Third Parties*: We may collect information about you or others through our affiliates or through non-affiliated parties. We may also collect information about you from others. For example, users may provide us with information about colleagues or other prospective users of our Services. We may collect information when you communicate with us on social media services such as LinkedIn and Twitter. We may combine information that we collect from you through the Services with information that we obtain from other parties and information derived from other products or services we provide. The categories of Personal Information we may have collected from these sources include the following: - Personal identifiers: Such as name, address, email address, telephone numbers, IP address or other unique identifier, account name and password, and other similar information. - Commercial information: Such as transaction data regarding transactions you've made with us. - Internet or other electronic activity information: Such as device and browser type, your browsing and search history on our Site, and information regarding your interaction with our Site and our advertisements. - Business information: Such as general information about your employment or business, such as a business title, business phone, business email address, business product and service offerings, and other information you provide us when communicating with us. - Other information: Such as other information we may collect from or about you, including when you communicate with us for support, product evaluation, dispute resolution, or other issues. - Inferences drawn from the Personal Information identified above. You are not required to provide us with information, but certain features of the Services may not be accessible or available, absent the provision of the requested information. To manage cookie preferences, [open your privacy choices](#privacy-choices). How We Use Personal Information We use your Personal Information for business and commercial purposes, including: - to provide you with information you request from us, - to contact you from time to time with news and other information about the Company, or in response to your inquiries or other requests, - to provide and improve the Services, - to monitor or improve our Site, - for internal business analysis, - to prevent fraud, activities that violate our Terms of Use or that are illegal, - to protect our rights and the rights and safety of our users or others, - to process payments for the Services, - to comply with our legal obligations or as permitted by law, and - to administer and troubleshoot the Services. We may aggregate and/or de-identify information collected through the Services. We may use de-identified or aggregated data for any purpose, including without limitation for research and marketing purposes and may also disclose such data to other parties, including without limitation, advertisers, promotional partners, sponsors, event promoters, and/or others. When We Disclose Personal Information Categories of Personal Information that we have disclosed to unaffiliated parties for a business purpose in the 12 months prior to the date of this Policy are as follows: - personal identifiers, - financial information, - internet or other electronic network activity information, and - inferences from the foregoing. Categories of Unaffiliated Parties to Which We Have Disclosed Personal Information for a business purpose in the 12 months prior to the date of this Policy are as follows: - Vendors that provide customer relationship management (CRM) services; assist us in operating, analyzing, and displaying content on our website; provide analytics information; advertise or market our products; provide website hosting; and provide legal and accounting services. - Vendors that facilitate transactional services requiring payment information; and provide legal and accounting services. - Vendors that provide data security services and cloud-based data storage; host our Site and assist with other IT-related functions; advertise and market our products; and provide analytics information. - Vendors that host our Site and assist with other IT-related functions; advertise and market our products; provide analytics information; and provide legal and accounting services. We may also disclose your Personal Information as required or permitted by law to comply with a subpoena or similar legal process or government request, or when we believe in good faith that disclosure is legally required or otherwise necessary to protect our rights and property or the rights, property or safety of others, including to law enforcement agencies, and judicial and regulatory authorities. We may also disclose your Personal Information to unaffiliated parties to help detect and protect against fraud or data security vulnerabilities. We may transfer your Personal Information to another party in the event of an actual or contemplated sale, merger, reorganization of our entity or other restructuring. We may disclose or transfer your information to affiliates. We may also disclose your information to others with your consent. Cookies and Other Tracking Technologies Cookies are small, sometimes encrypted text files that are stored on computer hard drives by websites that you visit. They are used to help users navigate websites efficiently as well as to provide information to the owner of the websites. To find out more about cookies, including how to see what cookies have been set and how to manage and delete them, please visit www.allaboutcookies.org. When you visit our Site, we may place a “cookie” or other online tracking devices (e.g. web beacons) that recognize you. The cookies and other tracking technologies may also collect information about your IP address or actions taken in connection with the Site. We may use cookies or similar tracking technologies to capture information about the use of our Site, including to improve your user experience. We use Google Analytics to evaluate the use of our website. Google Analytics uses cookies and other identifiers to collect information, such as how often users visit a website, what pages they visit when they do so, and what other websites they visited prior to visiting a website. To learn more about how Google Analytics collects personal information, review Google's Privacy Policy. State Privacy Rights – California If you are a California resident, you may have separate rights regarding your Personal Information, in accordance with California law. California Consumer Privacy Act Throughout this Policy, we discuss in detail the specific pieces of personal information and sensitive personal information we collect, the sources of that information, and how we disclose it. Under the California Consumer Privacy Act (“CCPA”), we also have to provide you with the categories of personal information and sensitive personal information we collect and disclose for business or commercial purposes. As used in this section, “personal information,” “sensitive personal information,” “business purposes,” “commercial purposes,” and “categories” shall have the meanings set forth by the CCPA.In the twelve months leading up to the effective date of this Policy, we have collected and disclosed the categories of personal information described in the section above on “[Personal Information We Collect](#personal-information-we-collect)” for business or commercial purposes. The categories of personal information are: (1) personal identifiers, (2) commercial information; (3) Internet or other electronic activity information; (4) business information; (5) other information we may collect from or about you, including when you communicate with us for support, product evaluation, dispute resolution, or other issues; and (6) inferences drawn from the personal information identified above.Some of the categories of personal information above may also be sensitive personal information under the CCPA. We may collect the following type of sensitive personal information: information you may voluntarily provide that may reveal race/ethnic origin or other protected classifications.We collect the categories of personal information identified above from the following sources: (1) directly from you; (2) through your use of the Services; and (3) third parties such as social media networks.We process the categories of personal information identified above for the purposes as described in more detail in the section above on “[How We Use Personal Information.](#how-we-use-personal-information)” The California Consumer Privacy Act (CCPA) gives California residents rights described below with respect to their personal information. This Section only applies to you if you are a California resident. It applies to personal Information that we collect on or through the Services and through other means (such as information collected offline and over the telephone). It does not apply to personal information we collect from our employees and job applicants in their capacity as employees and job applicants. CCPA Rights If you are a California resident, you may have certain rights. California law may permit you to request that we: - Provide you the categories of personal information we have collected or disclosed about you; the categories of sources of such information; the business or commercial purpose for collecting, “selling,” or “sharing” your personal information; the categories of third parties to whom we disclose or “sell,” or with whom we “share,” personal information; and the categories of personal information we “sell” or “share.” - Provide access to and/or a copy of certain information we maintain about you. - Delete certain information we maintain about you. - Correct inaccurate personal information we maintain about you. The CCPA also allows you to limit the use or disclosure of your sensitive personal information if your sensitive personal information is used for certain purposes. Please note that we do not use or disclose sensitive personal information other than for purposes for which you cannot opt out under the CCPA.You also have the right to opt out of “sales” and “sharing” of personal information. We have not “sold” or “shared” your personal information in the 12 months preceding the effective date of this Policy. As our Services are not directed to minors, we do not knowingly “sell” or “share” the personal information of children under 16. You may have the right to receive information about the financial incentives that we offer to you, if any. You also have the right to not be discriminated against (as provided for in applicable law) for exercising certain of your rights. Certain information may be exempt from such requests under applicable law. We need certain types of information so that we can provide the Services to you. If you ask us to delete it, you may no longer be able to access or use the Services. Exercising Your Rights To exercise any of the rights above, or to ask a question, contact personnel@paradigm.xyz. *Our Commitment to Allowing You to Exercise Your Rights – Non-Discrimination * You also have the right not to be discriminated against (as provided for in California law) for exercising your rights. Verification of Identity – Access or Deletion Requests We also will take reasonable steps to verify your identity before responding to a request. For example, we may ask you for identifying information and attempt to match it to information that we maintain about you, which may involve you providing identifying information. If we are unable to verify you through this method, we shall have the right, but not the obligation, to request additional information from you. If we are unable to verify your identity with the degree of certainty required, we will not be able to honor your request. We will notify you to explain the basis of the denial. Authorized Agents You may designate an agent to submit requests on your behalf. If you would like to designate an agent to act on your behalf, you and the agent will need to provide us with a power of attorney or your signed permission indicating the agent has been authorized to submit the opt-out request on your behalf. We may also require that you verify your identity directly with us or confirm with us that you provided the agent with permission to submit the request. California Do Not Track Some browsers have a “do not track” feature that lets you tell websites that you do not want to have your online activities tracked. At this time, our Site does not respond to browsers' “DNT” signals. Retention of Your Personal Information The personal information we do or will collect, including sensitive personal information, will be retained for as long as necessary to fulfill the purposes of the collection or for legal obligations as set forth in this Privacy Policy. These purposes may include to comply with reporting, legal and accounting obligations. Marketing Emails You may opt out of receiving marketing emails from us by following the instructions in those marketing emails. If you choose to opt out, we may still send you non-marketing communications, such as those about changes to our Terms, or our ongoing business relations with you. Personal Information of Minors The Services are not intended for minors under 16. If we discover that an individual under 16 has provided us with Personal Information, we will delete the Personal Information to the extent required by the Children's Online Privacy Protection Act or other applicable law. Third Party Websites Our Site may contain social media buttons or links to third-party websites or services, which may have privacy policies that differ from our own. We are not responsible for the activities and practices that take place on those social media platforms or third-party websites. We recommend that you review the privacy policies posted on any platform or website that you may access through our Site. How We Keep Your Personal Information Secure We implement and maintain security measures appropriate to the nature of the Personal Information that we collect, use, retain, transfer or otherwise process. Those measures include administrative, physical and technical safeguards to protect the security, confidentiality and integrity of Personal Information. However, data security incidents and breaches can occur due to a variety of factors that cannot reasonably be prevented; therefore, our safeguards may not always be adequate to prevent all breaches of security. International Residents Personal Information collected from you, including via our Site, will be transferred to the United States where the Site is hosted. You hereby consent to the transfer of your Personal Information to the United States as described in this Privacy Policy. Please do not use the Site if you do not agree to the transfer and processing of your Personal Information in the United States, which may not provide the same level of protection for your data as your home country. Changes to This Policy We will review and update this Policy periodically. We will notify you of material changes in accordance with applicable law. By continuing to use the Services, you acknowledge the applicability of the updated Privacy Policy. If you disagree with any changes and do not wish your information to be subject to a revised Privacy Policy, you will need to stop using the Services. Contact Us If there are any questions regarding this Policy, you may contact us at privacy@paradigm.xyz. ## https://www.paradigm.xyz/contact # Contact | San Francisco [sf@paradigm.xyz](mailto:sf@paradigm.xyz) General Inquiries [info@paradigm.xyz](mailto:info@paradigm.xyz) | New York City [nyc@paradigm.xyz](mailto:nyc@paradigm.xyz) Press Inquiries [press@paradigm.xyz](mailto:press@paradigm.xyz) | Washington DC [dc@paradigm.xyz](mailto:dc@paradigm.xyz) Coworking [coworking@paradigm.xyz](mailto:coworking@paradigm.xyz) | | --- | --- | --- | ## https://www.paradigm.xyz/research-index # Research Index ## All Research From cryptographic breakthroughs to AI security and protocol design, our research is built to ship — as open source tools, protocol contributions, and new primitives for builders at the frontier. - [GPU World](https://www.paradigm.xyz/writing/gpu-world) — GPU World: A story competition from Neal Stephenson, Gwern, and Matt Huang. What if the world had one GPU per person? $100K in total prizes. - [RSI Simulator](https://www.paradigm.xyz/writing/rsi-simulator) — An interactive web game and model explorer from Paradigm that demonstrates the economics of recursive self-improvement and AI R&D. - [Centaur 2.0: Permissions, Context, and MCP](https://www.paradigm.xyz/writing/centaur-2-0-permissions-context-and-mcp) — We’re launching Centaur 2.0 with better permissions, broader tool access, and a faster, more reliable foundation. - [Formally Verifying a Compiler Using Automated Research](https://www.paradigm.xyz/writing/solidus) — We formally verified a compiler using Lean and are launching two new challenges to improve it, as an experiment in collaborative research. - [Project Kryptos](https://www.paradigm.xyz/writing/kryptos) — Paradigm is now the steward of the solution to Kryptos, one of the last great cryptography puzzles — but it's a secret, even to us. Now we’re looking for more people to try to find the solution. - [Open Sourcing Centaur: Multiplayer, self-hosted, secure agents](https://www.paradigm.xyz/writing/open-sourcing-centaur-multiplayer-self-hosted-secure-agents) — Paradigm and Tempo open source Centaur, a Slack-native multiplayer, self-hosted and secure agent for investing, building, and researching. - [PACTs: Protecting Your Bitcoin From a Quantum Sunset](https://www.paradigm.xyz/writing/pacts-protecting-your-bitcoin-from-a-quantum-sunset) — A possible way for Bitcoin holders to protect themselves from having their funds frozen in an emergency post-quantum hard fork—without having to publicly move their coins. - [Introducing Paradigm Predictions](https://www.paradigm.xyz/writing/introducing-paradigm-predictions) — Paradigm Predictions is a tool for exploring the landscape of prediction markets. We aim to make prediction market data intuitive, accessible, and easy to explore. - [Polymarket Volume Is Being Double-Counted](https://www.paradigm.xyz/writing/polymarket-volume-is-being-double-counted) — After analyzing Polymarket’s market structure, event data, and smart contracts, we discovered that most Polymarket analyses and dashboards have been mistakenly double-counting volume. - [Opportunity Markets](https://www.paradigm.xyz/writing/opportunity-markets) — Introducing opportunity markets, private prediction markets where those who spot opportunities get paid by those who can act on them - [Quantum Markets](https://www.paradigm.xyz/writing/quantum-markets) — A capital efficient mechanism for scaling futarchy. - [Orbital](https://www.paradigm.xyz/writing/orbital) — The future holds a million stablecoins. Today's infrastructure isn't ready. This paper introduces Orbital, an automated market maker for pools of 2, 3, or 10,000 stablecoins. Orbital unlocks capital efficiency by bringing concentrated liquidity to unlimited dimensions. - [Multiverse Finance](https://www.paradigm.xyz/writing/multiverse-finance) — Addressing capital efficiency in prediction markets by splitting the financial system into parallel universes. - [Across Prime](https://www.paradigm.xyz/writing/across-prime) — Across Prime introduces a new "bonded" model for trustless cross-chain bridging, which can be more gas and capital efficient than current "escrowed" models. - [Timing Advantages in Onchain Auctions](https://www.paradigm.xyz/writing/timing-advantages-in-onchain-auctions) — This paper studies and quantifies one of the fundamental limits to reducing MEV: latency advantages. - [Demystifying the North Korean Threat](https://www.paradigm.xyz/writing/demystifying-the-north-korean-threat) — There’s more to the DPRK than just Lazarus Group. - [What comes after Ethereum’s Pectra hard fork?](https://www.paradigm.xyz/writing/what-comes-after-ethereums-pectra-hard-fork) — The Reth team’s view on what should happen in Fusaka, Ethereum’s next hard fork after Pectra. - [Ethereum Acceleration](https://www.paradigm.xyz/writing/ethereum-acceleration-1) — Since its inception, Ethereum has been a pioneering force in crypto. Ethereum paved the way for smart contracts, DAOs, and DeFi, and continues to innovate on frontier challenges like ZK and MEV. Ethereum’s community of researchers and engineers has built a strong foundation for the next generation of decentralized applications. - [Distribution Markets](https://www.paradigm.xyz/writing/distribution-markets) — This paper introduces distribution markets, a new kind of prediction market for events whose outcomes aren't just "yes" or "no" but could be any number. Instead of betting on a particular outcome or range, traders can express how likely they think each different possibility is across the whole infinite range of outcomes. - [The 5 Levels of Secure Hardware](https://www.paradigm.xyz/writing/the-5-levels-of-secure-hardware) — Programmable cryptography enables fun, safe, and intelligent experiences. Hardware is necessary to achieve programmable cryptography at scale. How to think about the levels of secure hardware? Let’s get to Level 5. - [pm-AMM: A Uniform AMM for Prediction Markets](https://www.paradigm.xyz/writing/pm-amm) — Introducing pm-AMM: an automated market maker designed for prediction markets. We introduce a new methodology for deriving AMMs for particular assets, and apply it to prediction market tokens, creating an AMM that may provide more consistent liquidity and reduce the risk of losing everything. - [Unichain](https://www.paradigm.xyz/writing/unichain) — Unichain is an optimistic rollup optimized for efficient markets by delivering fast state updates, offering a framework for applications to internalize MEV, and providing an economic finality system for quick settlement across blockchains. - [How to Remove the Relay](https://www.paradigm.xyz/writing/removing-the-relays) — MEV-Boost, the current sidecar protocol for MEV extraction in Ethereum, relies heavily on centralized actors called relays. Using a novel form of silent threshold encryption, a non-interactive construction that can leverage validators' existing BLS keypairs, we propose an alternative architecture that allows builders and proposers to communicate directly, with purely cryptographic privacy assumptions. - [Releasing Revmc](https://www.paradigm.xyz/writing/revmc) — Accelerating the EVM by compiling to native code. - [From Staking to Restaking](https://www.paradigm.xyz/writing/symbiotic) — Introducing Symbiotic, a generalized, permissionless protocol providing shared security through restaking. - [Priority Is All You Need](https://www.paradigm.xyz/writing/priority-is-all-you-need) — In this post, we introduce MEV taxes, a mechanism that arbitrary applications can use to capture their own MEV. This mechanism could be used today on OP Stack L2s like OP Mainnet, Base, and Blast, because the block proposers on those chains follow a set of rules we call competitive priority ordering. - [How to Raise the Gas Limit, Part 2: History Growth](https://www.paradigm.xyz/writing/how-to-raise-the-gas-limit-2) — In this post we continue our investigation of Ethereum scaling from Part 1, now turning our attention from state growth to history growth. Using high resolution datasets, our goal is to 1) build a technical understanding of Ethereum’s scaling bottlenecks, and 2) help frame the discussion around what Ethereum gas limit is optimal. - [Fig: Frame Interface Guidelines](https://www.paradigm.xyz/writing/fig) — We’re excited to open source Frame Interface Guidelines (Fig), which outlines best practices for building great Farcaster Frame experiences, inspired by Apple’s Human Interface Guidelines. - [Everything Is A Perp](https://www.paradigm.xyz/writing/everything-is-a-perp) — Power perps are assets that target the power of an index price. It’s a fun rabbit hole to go down. The longer you think about power perps, the more you see how everything resembles a power perp. - [Joining Paradigm as Research Advisor](https://www.paradigm.xyz/writing/joining-paradigm-ciamac-moallemi) — I'm excited to announce that I've joined Paradigm as a Research Advisor. I am excited to be working with Dan Robinson, Matt Huang, and the rest of the Paradigm investing - [How to Raise the Gas Limit, Part 1: State Growth](https://www.paradigm.xyz/writing/how-to-raise-the-gas-limit-1) — The goal of this blogpost series is to develop a scientific approach for understanding and enacting Ethereum's scaling roadmap. - [Leaderless Auctions](https://www.paradigm.xyz/writing/leaderless-auctions) — Leaderless Auctions are decentralized auctions with no auctioneer. They address the “last look” problem that can emerge when one participant is allowed to act after all others. - [What comes after Ethereum's Cancun hard fork?](https://www.paradigm.xyz/writing/ethereum-2024) — Where we outline the Paradigm Reth team's current view on possible next steps for Ethereum's upgrade after Cancun, Prague. - [The Casino on Mars](https://www.paradigm.xyz/writing/casino-on-mars) — Settling the crypto frontier begins with a speculative step. - [The Open Problems of Onchain Games](https://www.paradigm.xyz/writing/the-open-problems-of-onchain-games) — Or: why put games on a blockchain? - [Collaborate with Paradigm](https://www.paradigm.xyz/writing/collaborate-with-paradigm) — Paradigm is a group of builders that supports other builders. Some of our most fruitful collaborations involve deep work with entrepreneurial teams to solve important business and research problems. - [Intent-Based Architecture and Their Risks](https://www.paradigm.xyz/writing/intents) — The road to centralisation is paved with good intents. - [Blend: Perpetual Lending With NFT Collateral](https://www.paradigm.xyz/writing/blend) — Blend is a peer-to-peer perpetual lending protocol that enables lending against arbitrary collateral with no oracle dependencies. - [Time, slots, and the ordering of events in Ethereum Proof-of-Stake](https://www.paradigm.xyz/writing/mev-boost-ethereum-consensus) — Introduction On April 2nd, a malicious Ethereum network participant stole $20M from a MEV searcher by exploiting a vulnerability in the mev-boost-relay (see Flashbots’ post-mortem). In the following days, developers addressed - [Generating secure randomness on Ethereum using SNARKs](https://www.paradigm.xyz/writing/eth-rng) — In this post, we propose designs and reference implementations that utilize SNARKs and VDFs to achieve fully secure randomness on Ethereum. - [Open Sourcing the Art Gobblers Smart Contracts](https://www.paradigm.xyz/writing/open-sourcing-gobblers) — Today, we’re excited to announce that the Art Gobblers smart contracts are open source and available on our Github repo. - [Art Gobblers](https://www.paradigm.xyz/writing/artgobblers) — Art Gobblers is a decentralized art factory owned by aliens. As artists make cool art, Gobblers gains cultural relevance, making collectors want the art more, incentivizing artists to make cooler art. It's also an on-chain game. - [Goldfish: A Provably Secure Replacement for LMD GHOST in PoS Ethereum](https://www.paradigm.xyz/writing/goldfish) — The Merge: From Proof-of-Work to Proof-of-Stake The upcoming transition of Ethereum from proof-of-work (PoW) to proof-of-stake (PoS) is the culmination of years of research and development. - [GOO (Gradual Ownership Optimization)](https://www.paradigm.xyz/writing/goo) — GOO aligns fungible and non-fungible token incentives. - [Data Availability Sampling: From Basics to Open Problems](https://www.paradigm.xyz/writing/das) — The purpose of this blog post is to explain the basics of data availability sampling (DAS), the model upon which it rests, and challenges and open problems when it comes to implementing the technique in practice. - [Variable Rate GDAs](https://www.paradigm.xyz/writing/vrgda) — Variable Rate GDAs (VRGDAs) enable selling tokens close to a targeted schedule by adjusting prices as sales get ahead of/behind it. - [Cosmos without Tendermint: Exploring Narwhal and Bullshark](https://www.paradigm.xyz/writing/experiment-narwhal-bullshark-cosmos-stack) — Many of us at Paradigm have been excited about the latest developments on high-throughput & low-latency consensus using directed acyclic graphs (DAGs), in particular the Narwhal mempool and the Tusk and Bullshark consensus algorithms, and beyond. - [Understanding Blockchain Latency and Throughput](https://www.paradigm.xyz/writing/consensus-throughput) — How to properly measure a (blockchain) system is one of the least talked about but most significant steps in its design and evaluation. There are numerous consensus protocols and variations with various performance and scalability tradeoffs. But as of yet, there is still no universally agreed-upon, reliable method that enables apples-to-apples comparisons. In this blog post, we outline a method inspired by measurements in data-center systems and discuss common errors to avoid when evaluating a blockchain network. - [The Dominance of Uniswap v3 Liquidity](https://www.paradigm.xyz/writing/the-dominance-of-uniswap-v3-liquidity) — New research published today shows that Uniswap Protocol v3 has deeper liquidity in ETH/USD, ETH/BTC and other ETH pairs than leading centralized exchanges. This research demonstrates that AMM market structure – which is largely crypto-native today – can surpass order-book exchanges and transform traditional financial market structure to be more liquid, stable, and secure. - [Hardware Acceleration for Zero Knowledge Proofs](https://www.paradigm.xyz/writing/zk-hardware) — Zero Knowledge cryptography is one of the most notable innovations in the last fifty years of computer science. Zero Knowledge Proofs (ZKPs) offer unique properties that make them essential components of various blockchain scaling and privacy solutions. - [Gradual Dutch Auctions](https://www.paradigm.xyz/writing/gda) — This paper introduces the Gradual Dutch Auction, or GDA, a mechanism that enables efficient sales of assets that do not have liquid markets. - [Constant Rate Issuance Sales Protocol](https://www.paradigm.xyz/writing/constant-rate-issuance-sales-protocol) — This paper introduces the Constant Rate Issuance Sales Protocol, or CRISP, a pricing mechanism that aims to sell NFTs at a targeted rate over time. - [Hiding in Plain Sight](https://www.paradigm.xyz/writing/hiding-in-plain-sight) — I like challenging assumptions. I like trying to do the impossible, finding what others have missed, and blowing people's minds with things they never saw coming. - [A Guide to Designing Effective NFT Launches](https://www.paradigm.xyz/writing/a-guide-to-designing-effective-nft-launches) — Blockchains revolutionized fundraising for open-source software, but not everything worked right from the start. In fact, ICOs of the 2016-2018 era were often horribly broken mechanisms that allowed founders to cash out before delivering any products. Many lessons have been learned since, with today’s projects having a working product before launching a token and distributing it to incentivize usage and decentralize governance. - [RICKS](https://www.paradigm.xyz/writing/ricks) — Introducing a new NFT fractionalization primitive: RICKS (Recurrently Issued Collectively Kept Shards) - [Martingale Shares](https://www.paradigm.xyz/writing/martingale-shares) — Introducing a new NFT primitive: Martingale shares, or "Mortys." Mortys are synthetics representing fractional ownership of classes of NFTs. - [Floor Perps](https://www.paradigm.xyz/writing/floor-perps) — Introducing the floor perpetual: a synthetic NFT that tracks the floor price of a given project and can be minted by locking up NFTs from that project. - [Two Rights Might Make A Wrong](https://www.paradigm.xyz/writing/two-rights-might-make-a-wrong) — It only takes one vulnerability to cause serious financial damage to hundreds if not thousands of innocent users. Breaking down how I found and helped patch a vulnerability that put over 109k ETH at risk. - [Power Perpetuals](https://www.paradigm.xyz/writing/power-perpetuals) — Introducing a new type of derivative: the power perpetual. - [The Dangers of Surprising Code](https://www.paradigm.xyz/writing/the-dangers-of-surprising-code) — If you work in software engineering, odds are you've heard of at least one software engineering principle. While I wouldn't advocate for religiously following every principle to the letter, there are a few that are really worth paying attention to. - [TWAMM](https://www.paradigm.xyz/writing/twamm) — This paper introduces a new type of automated market maker, or AMM, that helps traders on Ethereum efficiently execute large orders -- The time-weighted average market maker, or TWAMM (pronounced "tee-wham"). - [Ethereum Reorgs After The Merge](https://www.paradigm.xyz/writing/ethereum-reorgs-after-the-merge) — There has recently been discussion about the possibility of miners adopting a hypothetical modified Ethereum client that allows them to essentially accept bribes to make a short reorg of the chain (the main use case for making such bribes being to attack DeFi protocols). - [Uniswap v3: The Universal AMM](https://www.paradigm.xyz/writing/uniswap-v3-the-universal-amm) — Uniswap v3 allows liquidity providers to provide custom amounts of liquidity in selected price ranges. This unlocks tremendous capital efficiency gains for liquidity providers who can manually adjust their exposure. - [Booby Trapping the Ethereum Blockchain](https://www.paradigm.xyz/writing/booby-trapping-the-ethereum-blockchain) — This is the second in a series of blog posts about bugs I've found in go-ethereum (Geth). If you haven't already, take a look at Part 1 here. Today's post is about a bug - [Liquidity Mining on Uniswap v3](https://www.paradigm.xyz/writing/liquidity-mining-on-uniswap-v3) — Uniswap v3 replaces fungible ERC-20 liquidity positions with non-fungible ERC-721 liquidity positions. Does that mean it no longer supports flexible Uniswap-v2-style liquidity mining? Or that liquidity mining programs will have to be actively managed, selecting specific ranges to incentivize? Or that liquidity mining programs could be gamed by providing huge amounts of inactive liquidity? - [Everlasting Options](https://www.paradigm.xyz/writing/everlasting-options) — This paper introduces a new type of derivative, the everlasting option. Everlasting options give traders long-term options exposure without the effort, risk, or expense of rolling positions. - [On Staking Pools and Staking Derivatives](https://www.paradigm.xyz/writing/on-staking-pools-and-staking-derivatives) — The transition from Proof of Work (PoW) to Proof of Stake (PoS) is Ethereum’s most anticipated milestone since its inception. We explore the problems that ETH stakers experience today, and show how staking pools and staking derivatives solve these problems while increasing the effective security of the network. - [Understanding Automated Market-Makers, Part 1: Price Impact](https://www.paradigm.xyz/writing/understanding-automated-market-makers-part-1-price-impact) — Every day, thousands of people use a decentralized exchange (DEX) for the first time. However, the idiosyncrasies of a public blockchain routinely catch newcomers off-guard, even those familiar with trading on more traditional venues. - [Uncovering a Four Year Old Bug](https://www.paradigm.xyz/writing/uncovering-a-four-year-old-bug) — Uncovering a Four Year Old Bug - [Paradigm CTF 2021 - swap](https://www.paradigm.xyz/writing/paradigm-ctf-2021-swap) — Paradigm CTF 2021 took place in early February and together, players solved all but two of the challenges during the competition (and one of the remaining two mere days later). We're taking a look at the "swap" challenge in the form of a guided walkthrough. - [A Cosmos Thesis](https://www.paradigm.xyz/writing/a-cosmos-thesis) — On Ethereum, all applications run on a shared state machine. In Cosmos, many application-specific blockchains pass assets and other messages between one another. If Ethereum is a mainframe computer, Cosmos is a protocol for networking independent servers. - [The Block Mined In January, 584942419325](https://www.paradigm.xyz/writing/the-block-mined-in-january-584942419325) — This is the first in a series of blog posts about the bugs I've found in go-ethereum (Geth), the official Golang implementation of the Ethereum protocol. While you don't need a deep understanding of Geth in order to follow these blog posts, knowledge of how Ethereum itself works will be helpful. This first post is about a bug in Geth's uncle validation routine which did not behave correctly given a specially crafted uncle. If exploited, this could have caused an accidental fork between Geth and Parity nodes. - [Ethereum Blockspace - Who Gets What and Why](https://www.paradigm.xyz/writing/ethereum-blockspace-who-gets-what-and-why) — Blockspace is the commodity that powers the heartbeats of all cryptocurrency networks. In the blockspace market, miners are the producers, mining pools are the auctioneers, and users are the bidders. The influences of the blockspace market are so pervasive that they touch almost every facet of the cryptocurrency ecosystem. - [The Cartoon Guide to Perps](https://www.paradigm.xyz/writing/the-cartoon-guide-to-perps) — In this post, I’ll share what I learned: four very different (but mathematically identical) mental models for what perps are, how they work, and when they don’t. - [Establishing Bounds for Miner Revenue in EIP-1559](https://www.paradigm.xyz/writing/establishing-bounds-for-miner-revenue-in-eip-1559) — We believe that the impact of EIP-1559 on both miner revenue and ETH holders has not been well explored. The main reason this analysis has been difficult before is that miner-extractable value has started to make up a large share of miner revenue due to constant arbitrage opportunities in Defi. - [Miners will accept EIP-1559, here is why](https://www.paradigm.xyz/writing/miners-will-accept-eip-1559-here-is-why) — EIP-1559 is one of the most highly-anticipated Ethereum upgrades of all time, radically changing how users bid for transactions, among other major benefits. - [MEV and me](https://www.paradigm.xyz/writing/mev-and-me) — Ethereum’s core insight was that flexible smart contracts allow developers to explore a new frontier of permissionless applications. The explosive growth of decentralized financial protocols built on Ethereum (“DeFi”) is a glimpse at what this innovation could enable in the future. Like programming libraries in the first Internet revolution, DeFi’s “money legos” enable developers to build complex systems by composing and remixing simple building blocks. This complexity also brings novel risks. One of these risks is Miner Extractable Value, or MEV. - [How does Optimism's Rollup really work?](https://www.paradigm.xyz/writing/how-does-optimism-s-rollup-really-work) — This article is for everyone who is familiar with Optimistic Rollup as a mechanism and wants to learn how Optimism’s solution works, and evaluate the proposed system’s performance and security. We explain the motivation behind each design decision and then proceed to dissect Optimism’s system, along with links to the corresponding code for each analyzed component. - [(Almost) Everything you need to know about Optimistic Rollup](https://www.paradigm.xyz/writing/almost-everything-you-need-to-know-about-optimistic-rollup) — In this post, we dive into the principles of modern “Layer 2 solutions”, their corresponding security model, and how they can solve Ethereum’s scalability issues. This blogpost is targeted at “crypto-curious” individuals interested in learning more about cutting-edge Ethereum scaling techniques as well as developing a motivation on how to build and architect such systems. - [Paradigm's Open Problems: A Series](https://www.paradigm.xyz/writing/paradigm-s-open-problems-a-series) — About a month ago, we finally got around to publishing a truly wicked problem that had been plaguing my partner Dan Robinson and I for nearly two years. It was a Hail Mary pass; mostly, we hoped it would encourage whoever ended up cracking it to give us some closure, maybe years down the road. - [Uniswap's Financial Alchemy](https://www.paradigm.xyz/writing/uniswaps-alchemy) — An investigation into the nature of constant product markets. - [So you want to use a price oracle](https://www.paradigm.xyz/writing/so-you-want-to-use-a-price-oracle) — Everything you need to know about price oracles and how to use them safely. - [Governance Minimization](https://www.paradigm.xyz/writing/governance-minimization) — Governance minimization allows stakeholders to depend on a protocol. This creates a virtuous cycle of adoption, enabling scale that would otherwise be unachievable. Look no further than successful traditional internet protocols like HTTP and SMTP to see this power today. - [Escaping the Dark Forest](https://www.paradigm.xyz/writing/escaping-the-dark-forest) — On September 15, 2020, a small group of people worked through the night to rescue over 9.6MM USD from a vulnerable smart contract. This is our story. - [Ethereum is a Dark Forest](https://www.paradigm.xyz/writing/ethereum-is-a-dark-forest) — It’s no secret that the Ethereum blockchain is a highly adversarial environment. If a smart contract can be exploited for profit, it eventually will be. But this unforgiving environment pales in comparison to the mempool. If the chain itself is a battleground, the mempool is something worse: a dark forest. - [Analysis of EIP-2593 (Escalator)](https://www.paradigm.xyz/writing/analysis-of-eip-2593-escalator) — Today, we continue our analysis of blockspace market proposals by looking at EIP-2593, more widely known as “escalating bid algorithm”, or simply “escalator”. It is being advertised as an alternative to EIP-1559 with a big overlap in design goals. - [Analysis of EIP-1559](https://www.paradigm.xyz/writing/analysis-of-eip-1559) — Ethereum improvement proposal (EIP) 1559 will be the largest change to how users bid for blockspace in any of the major blockchains. - [The Yield Protocol: On-Chain Lending With Interest Rate Discovery](https://www.paradigm.xyz/writing/the-yield-protocol-on-chain-lending-with-interest-rate-discovery) — This paper presents a sketch of a new building block for decentralized finance: yTokens. yTokens are like zero-coupon bonds: on-chain obligations that settle on a specific future date based on the price of some target asset, and are secured by collateral in another asset. - [An analysis of Uniswap markets](https://www.paradigm.xyz/writing/an-analysis-of-uniswap-markets) — Uniswap — and other constant product markets — appear to work well in practice despite their simplicity. In this paper, we give a simple formal analysis of constant product markets and their generalizations, showing that, under some common conditions, these markets must closely track the reference market price. - [The Rainbow Network: An Off-Chain Decentralized Synthetics Exchange](https://www.paradigm.xyz/writing/the-rainbow-network-an-off-chain-decentralized-synthetics-exchange) — This paper presents the Rainbow Network, a design for an off-chain non-custodial exchange and payment network supporting any assets for which two parties can agree on a price oracle. ## https://www.paradigm.xyz/team/matt-huang # Matt Huang **Co-Founder & Managing Partner** Matt Huang is Co-Founder and Managing Partner at Paradigm. He serves on the boards of Stripe and Kalshi, and is the founder and project lead of Tempo, a payments network co-founded by Paradigm and Stripe. Before founding Paradigm in 2018, Matt was a partner at Sequoia Capital, where he led investments across internet, mobile, frontier technologies, and the firm’s crypto efforts. Earlier, Matt founded Hotspots, a Y Combinator company acquired by Twitter in 2012, and was an early investor in ByteDance, Instacart, and Benchling. He holds a B.S. in Mathematics from MIT. Executive Assistant: [Anita Wong](/team/anita-wong) ## Links - [Twitter](https://x.com/matthuang) - [LinkedIn](https://www.linkedin.com/in/kmhuang/) ## https://www.paradigm.xyz/team/alana-palmedo # Alana Palmedo **Managing Partner** Alana Palmedo is Managing Partner at Paradigm and joined the firm at its founding. She and Matt co-lead the firm’s investing and research efforts and oversee firm management. Alana serves on the CFTC Innovation Advisory Committee and on the boards of Antares, Crown and True Anomaly (Observer). She has 20 years of asset management experience from Cascade Investments, Russell Investments, and Boston University. She holds an MBA from MIT Sloan and a B.S. in Finance from Pacific Lutheran University. Executive Assistant: [Nicki Lardieri](/team/nicki-lardieri) ## Links - [Twitter](https://x.com/alanapalmedo) - [LinkedIn](https://www.linkedin.com/in/askorniakoffpalmedo/) ## https://www.paradigm.xyz/team/dan-robinson # Dan Robinson **General Partner** Dan Robinson is a General Partner at Paradigm, focused on research. Previously, Dan was a software engineer and protocol researcher who worked on programming languages and compilers, as well as market and mechanism design. Dan practiced as a litigation attorney at Paul, Weiss, Rifkind, Wharton & Garrison LLP. He earned a J.D. from Harvard Law School and an A.B. from Harvard University. ## Links - [Twitter](https://x.com/danrobinson) - [LinkedIn](https://www.linkedin.com/in/danielprobinson/) ## https://www.paradigm.xyz/team/georgios-konstantopoulos # Georgios Konstantopoulos **General Partner & CTO** Georgios Konstantopoulos is the Chief Technology Officer and a General Partner at Paradigm. He is also the CTO at Tempo, a payments network co-founded by Paradigm and Stripe. Georgios drives Paradigm’s open source strategy and execution across sectors and invests in founders using frontier technology. Previously, Georgios was an independent consultant and researcher focused on cryptography, information security and mechanism design. He earned his M.Eng. in Electrical & Computer Engineering from Aristotle University of Thessaloniki. ## Links - [Twitter](https://x.com/gakonst) - [LinkedIn](https://www.linkedin.com/in/gakonst/) ## https://www.paradigm.xyz/team/frankie # Frankie **General Partner** Frankie is a General Partner at Paradigm. Previously, he was a machine learning engineer building deep learning models and infrastructure for fraud detection. He holds a B.S. in computer science and mathematical economics from the University of Pennsylvania. ## Links - [Twitter](https://x.com/frankieislost) ## https://www.paradigm.xyz/team/alpin-yukseloglu # Alpin Yukseloglu **Partner, Investing & Research** Alpin Yukseloglu is a Partner at Paradigm. He has built infrastructure for consensus protocols, helped find and fix $1B+ in OSS security vulnerabilities, and worked on ML research in collaboration with companies like OpenAI. All the production code he has ever written is open source. Alpin holds degrees in Electrical Engineering, Computer Science, and Business Administration from UC Berkeley. ## Links - [Twitter](https://x.com/0xalpo) - [LinkedIn](https://www.linkedin.com/in/alpin-yukseloglu) ## https://www.paradigm.xyz/team/arjun-balaji # Arjun Balaji **Partner, Investing & Research** Arjun Balaji is a Partner at Paradigm. Previously, Arjun was an independent consultant and engineer focused on crypto and physical infrastructure. He holds a B.S. in Computer Science and Neuroscience from Northeastern University. ## Links - [Twitter](https://x.com/arjunblj) - [LinkedIn](https://www.linkedin.com/in/arjunbalaji/) ## https://www.paradigm.xyz/team/ricardo-de-arruda # Ricardo de Arruda **Partner, Investing & Research ** Ricardo de Arruda is a Partner at Paradigm. Previously, he was a data scientist at Allium, focused on petabyte-scale data infrastructure and fraud detection. Earlier in his career, Ricardo worked as a quantitative developer at macro hedge funds. He studied computer engineering and economics before dropping out of university. ## Links - [Twitter](https://x.com/notawizard) ## https://www.paradigm.xyz/team/calvin-zeng # Calvin Zeng **Partner, Investing & Research** Calvin Zeng is a Partner at Paradigm. Previously, he was a Partner at Dandelion Capital, a technology-focused crossover investment firm. Earlier in his career, Calvin worked at Altimeter Capital, TPG Capital, and Vista Equity Partners. He graduated from Princeton University with a degree in economics and computer science. ## Links - [LinkedIn](https://www.linkedin.com/in/calvinzeng/) - [Twitter](https://x.com/zirppls) ## https://www.paradigm.xyz/team/storm-slivkoff # Storm Slivkoff **Research Partner** Storm Slivkoff is a Research Partner at Paradigm focused on frontier methods in data science and data engineering. Storm spends much of his time working on open source tools for collecting, analyzing, and visualizing data. Storm also works on public-facing research spanning a variety of topics, including decentralized systems, optimization, forensic market analysis, and prediction markets. Previously, Storm earned a Ph.D. in neuroscience from UC Berkeley where he used voxelwise modeling to study visual attention. He also holds a B.S. in bioengineering and B.A. in applied math from Rice University. ## Links - [Twitter](https://x.com/notnotstorm) - [LinkedIn](https://www.linkedin.com/in/storm-slivkoff-6861911a4/) ## https://www.paradigm.xyz/team/justin-wang # Justin Wang **Research Partner** Justin Wang is a Research Partner at Paradigm. He previously led the development of EVMbench, a smart contract security collaboration between OpenAI and Paradigm. Earlier in his career, he worked on adversarial robustness and agent safety research, collaborating with organizations like Anthropic and the AI Security Institute. Before that, he worked on capabilities research and engineering. He studied mathematics before dropping out of university. ## https://www.paradigm.xyz/team/david-swain # David Swain **Chief Marketing Officer** David Swain is Chief Marketing Officer at Paradigm. Previously, David was Vice President of Partnerships and Content Strategy at Strava, joining through the acquisition of Prokit, the company he co-founded and led as CEO. David spent nearly a decade in leadership roles at Meta, most recently as Head of Global Communications on Instagram’s management team. At Facebook, he led communications for Facebook Platform and its work with the developer and startup ecosystem. He began his career in agency roles, helping startups, venture firms, and developers grow their brands and navigate their growth. David holds a B.S. in Psychology and Economics from St. Lawrence University. ## Links - [Twitter](https://x.com/DavidSwain) - [LinkedIn](https://www.linkedin.com/in/swaindavid/) ## https://www.paradigm.xyz/team/katie-biber # Katie Biber **Chief Operating Officer** Katie Biber is Chief Operating Officer at Paradigm. She joined Paradigm in 2022 as Chief Legal Officer and held that position until 2026. She was previously General Counsel at Anchorage, CLO at Brex, and Senior Counsel at Airbnb. Katie spent the first decade of her career as a campaign finance and First Amendment lawyer on the front lines of politics. She earned her J.D. from Harvard Law School and B.A. from George Washington University. ## Links - [Twitter](https://x.com/katiebiber) - [LinkedIn](https://www.linkedin.com/in/katiebiber/) ## https://www.paradigm.xyz/team/jordan-qualls # Jordan Qualls **Chief Financial Officer** Jordan is the Chief Financial Officer at Paradigm. Previously, Jordan was the VP of Finance & Operations at UP Partners. Prior to UP Partners he spent three years with Paradigm as the firm's Controller. Jordan began his career at PwC LLP where he spent almost ten years in their Capital Markets and Asset Management practices. Jordan earned his CPA in California and has a B.S. in Economics & Accounting from the University of California, Santa Barbara. ## Links - [LinkedIn](https://www.linkedin.com/in/jordan-qualls-45810b18/) ## https://www.paradigm.xyz/team/alex-popescu # Alex Popescu **Chief Compliance Officer** Alex Popescu is Chief Compliance Officer at Paradigm. Prior to Paradigm, Alex served for fourteen years in a variety of legal and compliance roles at Fortress Investment Group, a global investment manager offering credit, real estate, private equity, and permanent capital vehicle strategies. Most recently, Alex was the Director of Compliance for Fortress’s Credit and Real Estate business. Prior to that, he was the Director of Compliance for Fortress’s Private Equity business. He began his career as Regulatory Counsel, supporting all of Fortress's business lines on regulatory matters. Alex holds a J.D. from Brooklyn Law School and B.A. from Columbia University. ## Links - [LinkedIn](https://www.linkedin.com/in/alex-p-71713320/) ## https://www.paradigm.xyz/team/alex-grieve # Alex Grieve **VP of Government Affairs** Alex Grieve is the VP of Government Affairs at Paradigm. Prior to joining Paradigm, Alex was Vice President of Tiger Hill Partners, a regulatory advisory and lobbying firm, where he led Tiger Hill's crypto practice, and worked with high growth startups across tech and fintech. Alex also served as the Republican government affairs lead for the Depository Trust & Clearing Corporation (DTCC), the securities clearinghouse and financial market infrastructure. Prior to DTCC, Alex served as an aide to Speaker of the House John Boehner, and began his career on the campaign of Gabriel Gomez for U.S. Senate. He earned an MBA from the Yale School of Management and a B.A. from Colgate University. ## Links - [Twitter](https://x.com/alexandergrieve) - [LinkedIn](https://www.linkedin.com/in/alexander-grieve-9a963a39/) ## https://www.paradigm.xyz/team/veit-moeller # Veit Moeller **VP, Brand & Design** Veit Moeller is VP, Brand & Design at Paradigm. Previously, he was Head of Design at OpenAI, leading the in-house studio and overseeing the brand ecosystem. Prior to that, he was Global Creative Director at Meta, defining the brand identity for WhatsApp and reigniting brand love for Instagram. Before relocating to California, Veit served as Executive Creative Director at Mercedes-Benz's global agency in Berlin. His work has been recognized by leading industry awards including D&AD, One Show, and Cannes Lions. He holds an M.A. in Design and Visual Communication from SRH Berlin University of Applied Sciences. ## Links - [Twitter](https://x.com/veitmoeller) - [LinkedIn](https://www.linkedin.com/in/veitmoeller/) ## https://www.paradigm.xyz/team/stefan-schropp # Stefan Schropp **Senior Regulatory Counsel** Stefan Schropp serves as Senior Regulatory Counsel for Paradigm. Prior to joining Paradigm, Stefan was Counsel in the litigation group at Ropes & Gray, where he spent nine years as a civil litigator working primarily on M&A and securities-related litigation, as well as on crypto-related issues. Prior to Ropes, Stefan clerked for the U.S. Court of Appeals for the Eleventh Circuit, worked for the North Carolina General Assembly, and taught middle school math in Charlotte, N.C. He earned his law degree and master’s in public administration from UNC-Chapel Hill, his MBA from Queens University, and his bachelor’s degreefrom Yale University. ## https://www.paradigm.xyz/team/ben-hinshaw # Ben Hinshaw **Deputy General Counsel** Ben is the Deputy General Counsel at Paradigm. He began his legal career at Gunderson Dettmer serving as outside counsel for venture-backed technology companies and leading venture capital firms. Most recently, he was the Associate General Counsel at Khosla Ventures. Ben also founded and led Willow Labs, building a wildfire analytics platform to protect lives, properties and investments. He earned a B.A. and J.D. from the University of California, Berkeley. ## Links - [LinkedIn](https://www.linkedin.com/in/ben-hinshaw-59436b8b/) ## https://www.paradigm.xyz/team/rama-somayajula # Rama Somayajula **Head of Trading** Rama Somayajula is Head of Trading at Paradigm. Previously, he was a derivatives trader at FalconX focused on electronic and OTC market making across crypto options and futures. Prior to FalconX, Rama was a quantitative trader at Blockchain.com and began his career as a trader at Citadel Securities. He holds a B.S.E. in Computer Science and a B.B.A. in Business Administration from the University of Michigan. ## Links - [LinkedIn](https://www.linkedin.com/in/rama-somayajula/) ## https://www.paradigm.xyz/team/chris-kraeuter # Chris Kraeuter **Head of Communications** Chris Kraeuter is Head of Communications at Paradigm. Previously, Chris worked on communications at the Solana Foundation, he advised the Ethereum Foundation on messaging strategy, and he led financial communications at Intel. Earlier, he shaped narratives for technology leaders including Slack and Meta, and worked with venture firms like Accel, KKR, and Andreessen Horowitz. Chris began his career as a business journalist at publications including Forbes and Dow Jones MarketWatch. He holds degrees in Finance and Journalism from the University of Missouri. ## Links - [Twitter](https://x.com/chris_kraeuter) - [LinkedIn](https://www.linkedin.com/in/chriskraeuter/) ## https://www.paradigm.xyz/team/dan-mccarthy # Dan McCarthy **Head of Talent** Dan McCarthy is the Head of Talent at Paradigm, focused on helping Paradigm’s portfolio companies build world-class teams. He began his career in engineering recruiting at Google before joining Clever (YC S12) as its first recruiter and later its head of talent. Most recently, he led Lime’s executive recruiting team across operations in San Francisco and Shenzhen. Dan holds a B.A. in Political Science from Stanford University. ## Links - [Twitter](https://x.com/dmccarthy7) - [LinkedIn](https://www.linkedin.com/in/dmccarthy7/) ## https://www.paradigm.xyz/team/josie-franciose-mcguinn # Josie Franciose McGuinn **Head of Events** Josie is the Head of Events at Paradigm, strategically leading all internal and external events. Prior to joining Paradigm, Josie spent 15+ years at the Sundance Institute as the Director of Events overseeing and growing the events division. She managed a department of event and operation experts who planned, produced and executed over 150 multiform events annually at the Sundance Film Festival and year round programs. Josie began her career in events working for Ronald Reagan Library, US Women’s Ski Team, S&R Originals and The Depot. Josie earned her B.A. in Marketing Communications and Public Relations at California Lutheran University. ## Links - [Twitter](https://x.com/josiefranciose) - [LinkedIn](https://www.linkedin.com/in/josie-franciose-mcguinn-96283916/) ## https://www.paradigm.xyz/team/pam-tholen # Pam Tholen **Head of Investor Relations** Pam Tholen is Head of Investor Relations at Paradigm, leading the firm’s business development and LP engagement efforts. Previously, she spent 12 years at KKR across product strategy, investor relations, and fundraising, most recently as Head of New Business Development. Pam also spent five years with Bridgewater Associates, leading strategic institutional relationships and building out the firm's efforts in the global wealth channel. Pam began her career in M&A investment banking at Lehman Brothers. She holds an AB in Politics and a Certificate in French from Princeton University and served as term member of the Council on Foreign Relations. ## Links - [LinkedIn](https://www.linkedin.com/in/pamtestanitholen) ## https://www.paradigm.xyz/team/lindsay-slocum # Lindsay Slocum **Investor Relations Lead** Lindsay joined Paradigm in 2020 and serves as an Investor Relations Lead. She is responsible for investor correspondence, business development and assists with fundraising efforts. Previously, Lindsay was a Finance Manager at the firm having been promoted from Finance Associate. Earlier in Lindsay's career, she was a Deals Senior Associate at PwC LLP where she worked on various M&A transactions in the technology, financial services, and biotech sectors. Lindsay earned her B.A in Economics & Accounting at Claremont McKenna College. ## Links - [Twitter](https://x.com/lindsay_slocum) - [LinkedIn](https://www.linkedin.com/in/lindsayslocum/) ## https://www.paradigm.xyz/team/dominique-little # Dominique Little **Government Affairs Lead** Dominique Little is a Government Affairs Lead at Paradigm. Prior to joining Paradigm, Dominique was a Legislative Correspondent working in the technology and telecommunications portfolio for U.S. Senator Cory Booker. In this role, she focused on issues relating to digital assets, artificial intelligence, and algorithmic biases. Dominique also served as Assistant to the Chief Staff in Sen. Booker’s office. Prior to working in Congress, Dominique was a Finance Assistant for Sen. Booker’s presidential campaign in 2019. She earned a B.A. in Political Science from Rutgers University-New Brunswick. ## Links - [LinkedIn](https://www.linkedin.com/in/dominique-little/) - [Twitter](https://twitter.com/domsimonee) ## https://www.paradigm.xyz/team/fred-ehrsam # Fred Ehrsam **Co-Founder & Senior Advisor** Fred Ehrsam is Co-Founder and Senior Advisor at Paradigm, and Co-Founder and CEO of Nudge, a neurotechnology company building non-invasive brain-computer interfaces. Fred co-founded Coinbase, the largest U.S. cryptocurrency exchange, where he served as President from 2012 to 2017 and remains a board member. He serves on the President's Council of Advisors on Science and Technology. Fred has been an early investor in OpenAI, Anthropic, Anduril, SpaceX, and other frontier technology companies. Prior to Coinbase, Fred was a foreign exchange trader at Goldman Sachs in New York. He holds a B.S. in Computer Science and Economics from Duke University. ## Links - [Twitter](https://x.com/FEhrsam) - [LinkedIn](https://www.linkedin.com/in/fredehrsam/) ## https://www.paradigm.xyz/team/caitlin-pintavorn # Caitlin Pintavorn **Venture Partner** Caitlin Pintavorn is a Venture Partner at Paradigm. She currently works at Stripe on 0-1 bets and on strategy in the Technical Office of the President of Technology & Business. Previously, she was an investor at Paradigm and Insight Partners, and worked in product at PathAI. Caitlin double majored in Economics and Public Health at Brown University. ## Links - [Twitter](https://x.com/caitlinxyz) - [LinkedIn](https://www.linkedin.com/in/caitlin-pintavorn/) ## https://www.paradigm.xyz/team/justin-slaughter # Justin Slaughter **Senior Advisor** Justin Slaughter is a Senior Advisor at Paradigm. He previously was Paradigm’s VP of Regulatory Affairs. Prior to that, he was the Director of the Office of Legislative and Intergovernmental Affairs and Senior Advisor to Acting SEC Chair Allison Herren Lee and he was the Chief Policy Advisor and Special Counsel to former Commissioner Sharon Bowen at the CFTC. He also served as General Counsel to Senator Edward J. Markey. He began his career as a law clerk to Judge Jerome Farris on the U.S. Court of Appeals for the Ninth Circuit. Justin holds a B.A. from Columbia University and a J.D. from Yale Law School. ## Links - [Twitter](https://x.com/jbsdc) - [LinkedIn](https://www.linkedin.com/in/justin-slaughter-a3041416/) ## https://www.paradigm.xyz/team/transmissions11 # transmissions11 **Research Associate** Transmissions is a Research Advisor at Paradigm. Transmissions works to push the efficiency frontier of smart contracts by developing optimized libraries and primitives. He is also interested in interpreting and programmatically steering large language models. He's currently exploring new frontiers at MIT. ## Links - [Twitter](https://x.com/transmissions11) ## https://www.paradigm.xyz/team/ciamac-moallemi # Ciamac Moallemi **Research Advisor** Ciamac Moallemi is William von Mueffling Professor of Business in the Decision, Risk, & Operations Division of the Graduate School of Business at Columbia University, and the Director of the Briger Family Digital Finance Lab. In his work with Paradigm, he focuses on applied research in mechanism and market design, with a particular focus on decentralized finance. ## Links - [Website](https://moallemi.com/ciamac/) - [Twitter](https://x.com/ciamac) - [LinkedIn](https://www.linkedin.com/in/ciamacmoallemi/) ## https://www.paradigm.xyz/team/cobie # Cobie **Advisor** Cobie leads Coinbase’s Base app. Previously, he founded Echo, an early stage funding platform which Coinbase acquired. He's known for early investments in major protocols and influential market commentary, and was the host of the popular UpOnly podcast. In his work with Paradigm, Cobie provides perspectives on emerging trends across the crypto ecosystem. ## Links - [Twitter](https://x.com/cobie) ## https://www.paradigm.xyz/oss/centaur # Centaur Multiplayer, self-hosted, secure agents for Slack. ## Links - [GitHub](https://github.com/paradigmxyz/centaur) - [Github](https://github.com/paradigmxyz/centaur) - [Docs](https://centaur.run/what-is-centaur) - [Website](https://centaur.run/) GitHub: 1298 stars · 241 forks · 85 contributors ## https://www.paradigm.xyz/oss/evmbench # EVMbench An open benchmark and agent harness from OpenAI and Paradigm that evaluates whether AI agents can detect, patch, and exploit high-severity vulnerabilities. ## Links - [GitHub](https://github.com/paradigmxyz/evmbench) - [Github](https://github.com/paradigmxyz/evmbench) - [Website](https://evmbench.org) - [Research](https://cdn.openai.com/papers/evmbench.pdf) GitHub: 454 stars · 75 forks · 20 contributors ## https://www.paradigm.xyz/oss/foundry # Foundry Blazing fast, portable and modular toolkit for Ethereum application development written in Rust. ## Links - [GitHub](https://github.com/foundry-rs/foundry) - [Github](https://github.com/foundry-rs/foundry) - [Docs](https://book.getfoundry.sh/) - [Website](https://getfoundry.sh/) GitHub: 10597 stars · 2627 forks · 705 contributors ## https://www.paradigm.xyz/oss/reth # Reth Modular, contributor-friendly and blazing-fast implementation of the Ethereum protocol, written in Rust. ## Links - [GitHub](https://github.com/paradigmxyz/reth) - [Github](https://github.com/paradigmxyz/reth) GitHub: 5771 stars · 2530 forks · 788 contributors ## https://www.paradigm.xyz/oss/alloy # Alloy Stable, well-tested, and performant building blocks for Ethereum, in Rust. ## Links - [GitHub](https://github.com/alloy-rs/alloy) - [Github](https://github.com/alloy-rs/alloy) GitHub: 1329 stars · 668 forks · 337 contributors ## https://www.paradigm.xyz/oss/artemis # Artemis Framework for MEV bots in Rust, designed to be simple, modular, and fast. ## Links - [GitHub](https://github.com/paradigmxyz/artemis) - [Github](https://github.com/paradigmxyz/artemis) GitHub: 2964 stars · 576 forks · 34 contributors ## https://www.paradigm.xyz/oss/cryo # Cryo Easiest way to extract blockchain data to Parquet, CSV, JSON, or a Python dataframe. ## Links - [GitHub](https://github.com/paradigmxyz/cryo) - [Github](https://github.com/paradigmxyz/cryo) GitHub: 1580 stars · 186 forks · 44 contributors ## https://www.paradigm.xyz/oss/solar # Solar Blazingly fast, modular and contributor friendly Solidity compiler, written in Rust. ## Links - [GitHub](https://github.com/paradigmxyz/solar) - [Github](https://github.com/paradigmxyz/solar) GitHub: 560 stars · 112 forks · 50 contributors ## https://www.paradigm.xyz/oss/flood # Flood Load testing tool for benchmarking EVM nodes over RPC. ## Links - [GitHub](https://github.com/paradigmxyz/flood) - [Github](https://github.com/paradigmxyz/flood) GitHub: 374 stars · 59 forks · 23 contributors ## https://www.paradigm.xyz/oss/flux # Flux Graph-based LLM power tool for exploring many completions in parallel. ## Links - [GitHub](https://github.com/paradigmxyz/flux) - [Github](https://github.com/paradigmxyz/flux) - [Website](https://flux.paradigm.xyz) GitHub: 898 stars · 130 forks · 29 contributors ## https://www.paradigm.xyz/oss/data-portal # Data Portal Collection of open source crypto datasets for researchers and tool builders. ## Links - [GitHub](https://github.com/paradigmxyz/paradigm-data-portal) - [Github](https://github.com/paradigmxyz/paradigm-data-portal) - [Website](https://data.paradigm.xyz) GitHub: 336 stars · 20 forks · 17 contributors ## https://www.paradigm.xyz/oss/rivet # Rivet Browser extension that enables developers to inspect, debug, modify, and manipulate the state of Ethereum. ## Links - [GitHub](https://github.com/paradigmxyz/rivet) - [Github](https://github.com/paradigmxyz/rivet) GitHub: 928 stars · 93 forks · 40 contributors ## https://www.paradigm.xyz/oss/wagmi # Wagmi Developer library with over 20 hooks for working with wallets, contracts, transactions, signing, and more. ## Links - [GitHub](https://github.com/wevm/wagmi) - [Github](https://github.com/wevm/wagmi) - [Docs](https://wagmi.sh) - [Sponsors](https://github.com/sponsors/wevm) GitHub: 6746 stars · 1440 forks · 342 contributors ## https://www.paradigm.xyz/oss/viem # Viem Fast, modular Typescript interface for Ethereum developers. ## Links - [GitHub](https://github.com/wevm/viem) - [Github](https://github.com/wevm/viem) - [Docs](https://viem.sh) - [Sponsors](https://github.com/sponsors/wevm) GitHub: 3553 stars · 1527 forks · 752 contributors ## https://www.paradigm.xyz/investments/antares # Antares **Hardware & Defense, Infrastructure** Antares is a nuclear fission energy company developing compact microreactors for defense and space applications, delivering safe, reliable power where traditional energy sources cannot. [Website](https://antaresindustries.com/), [X](https://x.com/AntaresNuclear), [LinkedIn](https://www.linkedin.com/company/antares-industries/) Founders - [Jordan Bramble](https://x.com/jordanbramble) - [Julia DeWahl](https://x.com/juliadewahl) ## https://www.paradigm.xyz/investments/tempo # Tempo **Payments, Infrastructure** Tempo is a blockchain built for payments, incubated by Stripe and Paradigm and led by Paradigm co-founder Matt Huang. Purpose-built for stablecoin payments at scale, Tempo is designed so that enterprises can move real financial operations onchain—built on the belief that stablecoins become a default rail for global commerce. [Website](https://tempo.xyz/), [X](https://x.com/tempo) Founders - [Matt Huang](https://x.com/matthuang) Open Roles - [Enterprise GTM (NY)](https://jobs.ashbyhq.com/tempo-xyz/a403e56e-749f-402e-9949-f8aef622d9d0?utm_source=jobs.paradigm.xyz) - [Partnerships ](https://jobs.ashbyhq.com/tempo-xyz/8bba7722-48ad-469d-a7c0-986784ffc017?utm_source=jobs.paradigm.xyz) - [Technical Solutions Lead](https://jobs.ashbyhq.com/tempo-xyz/402b14ef-cffb-4832-a2cc-e14ee48a48a8?utm_source=jobs.paradigm.xyz) - [View All](/careers?company=Tempo) ## https://www.paradigm.xyz/investments/andromeda # Andromeda **AI, Infrastructure** Andromeda is an AI compute marketplace that connects enterprises and developers to GPU capacity across major cloud providers and independent data centers through a unified API. Co-founded by Nat Friedman and Daniel Gross, Andromeda simplifies AI infrastructure so teams can run workloads at scale without managing multiple cloud providers. [Website](https://andromeda.ai/), [X](https://x.com/andromeda_ai) Founders - [Nat Friedman](https://x.com/natfriedman) - [Daniel Gross](https://x.com/danielgross) Open Roles - [Founding Product Designer ](https://jobs.ashbyhq.com/andromeda/e50376f9-befe-42db-88d4-b74173757daa) - [Staff SRE, AI Infrastructure](https://jobs.ashbyhq.com/andromeda/ff479ce6-223c-4e78-9ace-ed23a729cd52?utm_source=jobs.paradigm.xyz) - [Compute Trader](https://jobs.ashbyhq.com/andromeda/f6955d43-a0ed-41d5-be55-524b9f8b0c83?utm_source=jobs.paradigm.xyz) - [View All](/careers?company=Andromeda) ## https://www.paradigm.xyz/investments/hype # Hyperliquid (HYPE) **Trading & Markets** Hyperliquid is a purpose-built Layer 1 blockchain and on-chain perpetuals DEX, operating one of the fastest and most liquid decentralized derivatives exchanges in crypto. Its native L1 achieves sub-second finality and processes thousands of orders per second entirely on-chain. Hyperliquid has become the leading on-chain perps venue by volume, with its HYPE token reflecting the success of a vertically integrated, community-owned financial platform. [Website](https://hyperfoundation.org/), [X](https://x.com/HyperliquidX) Founders - [Jeff Yan](https://x.com/chameleon_jeff) ## https://www.paradigm.xyz/investments/uniswap # Uniswap **DeFi, Trading & Markets** Uniswap is the leading decentralized exchange protocol, letting anyone swap tokens directly from their own wallet with no intermediary. Its automated market maker design—liquidity pooled in smart contracts rather than order books—became the default architecture for onchain trading and has processed trillions of dollars in cumulative volume across Ethereum and the networks built on top of it. [Website](https://app.uniswap.org/), [X](https://x.com/Uniswap) Founders - [Hayden Adams](https://x.com/haydenzadams) Open Roles - [Senior Smart Contract Engineer](https://jobs.ashbyhq.com/uniswap/9a047e27-54dd-44df-9c0c-4ca6bc2d57bf?utm_source=jobs.paradigm.xyz) - [Senior Backend Engineer](https://jobs.ashbyhq.com/uniswap/f475ea4a-b8be-442a-b8e2-9a6003d1a51a?utm_source=jobs.paradigm.xyz) - [View All](/careers?company=UniSwap) ## https://www.paradigm.xyz/investments/stripe # Stripe **Payments, Infrastructure** Stripe builds economic infrastructure for the internet. Its APIs let businesses of every size—from weekend projects to the world’s largest companies—accept payments, manage billing, issue cards, and run financial operations. What began as seven lines of code for accepting payments has become the financial operating layer for a meaningful share of online commerce. [Website](https://stripe.com/), [X](https://x.com/stripe) Founders - [Patrick Collison](https://x.com/patrickc) - [John Collison](https://x.com/collision) Open Roles - [Machine Learning Engineer ](https://stripe.com/jobs/listing/machine-learning-engineer/8014859) - [Full-Stack Engineer ](https://stripe.com/jobs/listing/full-stack-engineer/8003382) - [View All](/careers?company=Stripe) ## https://www.paradigm.xyz/investments/coinbase # Coinbase **Consumer, Infrastructure, Payments, Trading & Markets** Coinbase is the leading US cryptocurrency exchange, where tens of millions of retail and institutional customers buy, sell, trade, and custody digital assets. Beyond the exchange it operates Base, its own blockchain network built on Ethereum, institutional prime brokerage, and stablecoin infrastructure around USDC—making it foundational plumbing for the onchain economy, not just a trading venue. [Website](https://www.coinbase.com/), [X](https://x.com/coinbase) Founders - [Brian Armstrong](https://x.com/brian_armstrong) - [Fred Ehrsam](https://x.com/fehrsam) Open Roles - [Senior Software Engineer, Full Stack](https://www.coinbase.com/careers/positions/8070574) - [Staff Product Designer (Experience & Engagement)](https://www.coinbase.com/careers/positions/8014564) - [View All](/careers?q=coinbase) ## https://www.paradigm.xyz/investments/true-anomaly # True Anomaly **Hardware & Defense, Infrastructure** True Anomaly builds spacecraft and software for space security. Founded by veterans of US Space Force operations units, the company makes autonomous orbital vehicles alongside AI-enabled training and mission software, giving the US and its allies awareness of what’s happening in orbit—and options when it’s contested. [Website](https://www.trueanomaly.space/), [X](https://x.com/The_TrueAnomaly) Founders - [Even Rogers](https://x.com/jollyrogersta) - Kyle Zakrzewski Open Roles - [Director, Propulsion Engineering](https://job-boards.greenhouse.io/trueanomalyinc/jobs/5098710007) - [Electrical Engineer, Harness](https://job-boards.greenhouse.io/trueanomalyinc/jobs/5102779007) - [Mechanical Engineer, Spacecraft (II-III)](https://job-boards.greenhouse.io/trueanomalyinc/jobs/5098194007) - [View All](/careers?company=True+Anomaly) ## https://www.paradigm.xyz/investments/sendcutsend # SendCutSend **Hardware & Defense, Consumer** SendCutSend is an online custom manufacturing service: upload a design and receive laser-cut, machined, or bent metal parts in days, with no minimum order. By making precision fabrication work like e-commerce, it opened industrial-grade manufacturing to engineers, startups, and makers who were previously shut out by job-shop minimums, quoting cycles, and lead times. [Website](https://sendcutsend.com/), [X](https://x.com/sendcutsend) Founders - [Jim Belosic](https://x.com/jimbelosic) - Jacob Graham Open Roles - [Product Designer ](https://recruiting.paylocity.com/Recruiting/Jobs/Details/4344376) - [Process Engineer](https://recruiting.paylocity.com/Recruiting/Jobs/Details/4334380) - [Senior Software Engineer](https://recruiting.paylocity.com/Recruiting/Jobs/Details/4317598) - [View All](/careers?company=SendCutSend) ## https://www.paradigm.xyz/investments/citadel-securities # Citadel Securities **Trading & Markets** Citadel Securities is one of the world’s largest market makers, quoting prices in equities, options, fixed income, currencies, and commodities for institutional clients around the world. Founded by Ken Griffin, the firm applies quantitative research and engineering at unusual scale to make markets more liquid, more efficient, and cheaper to trade for everyone on the other side. [Website](https://www.citadelsecurities.com/), [X](https://x.com/citsecurities) Founders - Ken Griffin Open Roles - [Quantitative Trader – University Graduate](https://www.citadelsecurities.com/careers/details/quantitative-trader-university-graduate-us-new-york/) - [Crypto Quant Researcher](https://www.citadelsecurities.com/careers/details/crypto-quant-researcher/) - [Crypto Quantitative Developer](https://www.citadelsecurities.com/careers/details/crypto-quantitative-developer/) - [View All](/careers?company=Citadel+Securities) ## https://www.paradigm.xyz/investments/zipline # Zipline **Hardware & Defense, Consumer, Infrastructure** Zipline designs, builds, and operates autonomous delivery drones, and runs the largest drone delivery network in the world. It began by flying blood to hospitals in Rwanda and now delivers medicine, food, and consumer goods across Africa and the United States. The company builds its aircraft, autonomy stack, and logistics operations in-house. [Website](https://www.zipline.com/), [X](https://x.com/zipline) Founders - [Keller Cliffton](https://x.com/Keller) - [Ryan Oksenhorn](https://x.com/ryanzip) Open Roles - [Forward Deployed AI Engineer](https://www.zipline.com/open-roles/7764239003) - [Autonomy Droid Perception](https://www.zipline.com/open-roles/7805425003) - [View All](/careers?company=Zipline) ## https://www.paradigm.xyz/investments/kalshi # Kalshi **Consumer, Trading & Markets** Kalshi is a CFTC-regulated exchange where people trade directly on the outcomes of real-world events—economic data, elections, weather, sports, and culture. The founders spent years working with regulators to make event contracts a legal, exchange-traded asset class in the US, and the market they opened now serves retail traders, institutional hedgers, and forecasters who want a live price on what happens next. [Website](https://kalshi.com/), [X](https://x.com/Kalshi) Founders - [Tarek Mansour](https://x.com/mansourtarek_) - [Luana Lopes Lara](https://x.com/luanalopeslara) Open Roles - [Software Engineer, Product](https://jobs.ashbyhq.com/kalshi/3dd97725-4a12-4963-b47a-cb5c562cfd1d?utm_source=jobs.paradigm.xyz) - [Software Engineer, Trading Platform ](https://jobs.ashbyhq.com/kalshi/13c4b111-5dab-4560-9843-70c06c1acf6e?utm_source=jobs.paradigm.xyz) - [Infrastructure Engineer](https://jobs.ashbyhq.com/kalshi/3d255a5d-7b0c-4a92-bae1-1ddb040f733e?utm_source=jobs.paradigm.xyz) - [View All](/careers?company=Kalshi) Links - [predictions.paradigm.xyz](https://predictions.paradigm.xyz/) ## https://www.paradigm.xyz/investments/nous-research # Nous Research **AI, Infrastructure** Nous Research is an open-source AI lab best known for its Hermes family of language models, among the most widely used open models in the ecosystem. Formed from a community of independent researchers, Nous runs as a decentralized lab: it publishes open weights and builds distributed training infrastructure like DisTrO and the Psyche network, on the conviction that frontier AI should not belong only to closed labs. [Website](https://nousresearch.com/), [X](https://x.com/NousResearch) Founders - [Jeffrey Quesnelle](https://x.com/theemozilla) - [Karan Malhotra](https://x.com/karan4d) - [Teknium (Ryan)](https://x.com/Teknium) Open Roles - [Research Scientist ](https://nousresearch.com/research-scientist) - [MLE (Reinforcement Learning)](https://nousresearch.com/machine-learning-engineer-reinforcement-learning) - [View All](/careers?company=Nous+Research)