<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>RenCryptoFish</title>
    <link>https://rencryptofish.com/</link>
    <description>Technical blog covering DeFi, perpetual swaps, and quantitative crypto trading</description>
    <language>en</language>
    <lastBuildDate>Sun, 11 Oct 2026 23:18:18 GMT</lastBuildDate>
    <atom:link href="https://rencryptofish.com/rss.xml" rel="self" type="application/rss+xml"/>
    <item>
      <title>Coordination, Markets, and Protocols</title>
      <link>https://rencryptofish.com/posts/coordination-markets-protocols</link>
      <description>A framework for understanding why coordination pulls toward centralization and why protocols occupy such a narrow and fragile corner of market structure</description>
      <content:encoded><![CDATA[<p>Every major coordination problem in history has been solved in a similar way: someone builds a central authority and takes a cut. Markets, platforms, brokers, exchanges. The pattern is so consistent it looks like a law of nature. Protocols are the rare exception. TCP/IP, HTTP, SMTP, Bitcoin. When they work, they become infrastructure that entire economies run on. But the path to getting there is brutal, because coordination has a natural gravity that pulls toward centralization.</p>

<p>This article builds a framework for understanding why. It starts with the coordination problem, introduces two dimensions that explain most market structures, and then shows why protocols occupy such a narrow and fragile corner of that space.</p>

<p>Start with the coordination problem. Any time N independent entities need to work together, there are 3 distinct forces working against them as N increases.</p>

<p><strong>Complexity</strong>: the number of potential 1-on-1 negotiation channels explodes quadratically. By the time you reach 30 entities, you are managing over 400 potential interpersonal conflicts or communication links.</p>

<p><strong>Incentive</strong>: the dilution of an individual's share. At N=2, you are 50% responsible. By N=20, your contribution feels mathematically negligible (5%), making "free riding" the rational choice for most participants.</p>

<p><strong>Stability</strong>: assume everyone is 95% reliable. In a small group, the chance of everyone agreeing is high (~90%). By N=30, the mathematical probability of holding the group together without a single defection or veto drops to near 20%.</p>

<img src="images/coordination-markets-protocols/coordination_trap.png" alt="The Coordination Trap: Why Difficulty Explodes as N Grows" />

<p>Markets are essentially "Coordination Technologies" to solve this problem, but they can take a variety of structures. There are a lot of ways to cut this, below I walk through one way to frame this.</p>

<h2>H-V: Asset Heterogeneity and Verification Cost</h2>

<p>Markets have many structures, terms commonly seen might be bazaar, broker, platform, and protocol. These structures are often a locally optimal solution based on attributes of the market, participants, and more.</p>

<img src="images/coordination-markets-protocols/hv_matrix.png" alt="Market Structure Matrix: H vs. V" />

<p>Two dimensions do most of the explanatory work:</p>

<p><strong>Asset Heterogeneity (H)</strong>: How unique is the item? (1 share of Apple stock = 0 heterogeneity, a vintage house = High H)</p>

<p><strong>Verification Cost (V)</strong>: How hard is it to prove the item is good? (checking a diamond = High V, checking a digital file = Low V)</p>

<p>| Name | Asset Heterogeneity (H) | Verification Cost (V) |</p>
<p>|---|---|---|</p>
<p>| Broker | High | High |</p>
<p>| Bazaar | High | Medium-High |</p>
<p>| Platform | Low | Low |</p>
<p>| Protocol | Very Low | Very Low |</p>

<p>Let's walk through various combinations of H and V:</p>

<h3>Broker (High H, High V)</h3>

<p>Why it stays here: Consider the market for M&A (buying companies) or High End Real Estate. Every deal is unique (H), and if you buy a "lemon" you lose billions (V is critical).</p>

<p>Cost_Search + Cost_Verify > Commission</p>

<h3>Bazaar (High H, Medium-High V)</h3>

<p>Why it stays here: In a Bazaar (e.g., a garage sale or early Craigslist), every item is unique (H is high). You cannot standardize the contract because selling a used toaster is different from selling a bike. Because H is high, the Information Asymmetry is massive. A central platform cannot efficiently price these items, only the two people staring at the object can agree on value.</p>

<h3>Platform (Low H, Low V)</h3>

<p><strong>The Compression Strategy</strong>: Platforms (Uber, Amazon, Airbnb) win by forcing H to zero. You don't choose "Dave who drives a Ford"; you choose "X Tier Ride."</p>

<p><strong>The Efficiency</strong>: By reducing Heterogeneity (H to 0), it's possible to reduce the transaction to a single variable: Price.</p>

<p><strong>The Stability</strong>: This creates a "Thick Market." Because everyone is in the market for the exact same thing (a standard ride), liquidity is maximized.</p>

<h3>Protocol (Very Low H, Very Low V)</h3>

<p>Platforms tend to rely on reputational trust, social graphs, and other mechanisms to reduce verification costs. Protocols substitute this with standards and/or cryptographic proofs.</p>

<p>Protocols push Cost of Verification ~ Cost of Compute</p>

<p><strong>When this wins</strong>: In markets where "Trust" is the biggest cost. For example we pay banks huge fees and taxes to verify money moved from A to B, a protocol over time compresses this to the cost of compute ~ cost of electricity.</p>

<p><strong>The limit</strong>: Protocols struggle with high H (heterogeneity). A blockchain can prove you own a token, but it cannot prove that the physical banana represented by that token isn't rotten. This is the "Oracle Problem." Until machines can verify physical reality (High V) without humans.</p>

<h2>What happens off the diagonal?</h2>

<p>The off-diagonal corners are unstable. In the top left (Low H, High V), a product looks standard but is nearly impossible to verify. Think counterfeit pharmaceuticals or blood diamonds before certification. This is Akerlof's "Market for Lemons": buyers refuse to trust, honest sellers can't prove themselves, and the market collapses. To survive, it must move onto the diagonal by introducing a broker ("I only buy from Tony") or inventing a verification test (the Kimberley Process) that pulls it toward a platform. The bottom right (High H, Low V) is equally unstable but for the opposite reason: every item is unique, yet verification is instant. When you can perfectly measure uniqueness, you can categorize it, and categorization kills heterogeneity. The market standardizes and slides left toward the platform model. Both corners resolve the same way: back to the diagonal.</p>

<h2>Technology and the Diagonal</h2>

<p>Many of the biggest platforms that have emerged on the internet have taken an industry or market in the top right (broker or bazaar) and used technology to reduce verification costs (reputation based systems) and heterogeneity (categorization and machine learning).</p>

<img src="images/coordination-markets-protocols/diagonal_migration.png" alt="The Diagonal Migration: Technology Pushes Markets from Broker to Protocol" />

<p>| Technology | Variable Reduced | Mechanism |</p>
<p>|---|---|---|</p>
<p>| TCP/IP | H to 0 | It didn't matter if you used a PC, Mac or Linux Server; the data "packet" became standardized. This created the Internet. |</p>
<p>| SSL / HTTPS | V to 0 | The little lock icon. Cryptography verifies you are actually talking to your bank, not a man in the middle. |</p>
<p>| The API | H to 0 | It turned messy internal databases into standardized "sockets" that other software can plug into. |</p>
<p>| Reputation Systems | V to 0 | Google/eBay/Airbnb/Uber reviews. They crowdsourced verification, allowing us to trust strangers. |</p>
<p>| Machine Learning | H to 0 | Clustering algorithms (K-means, DBSCAN, hierarchical clustering, Gaussian mixtures, etc.) can identify groupings among assets that appear diverse on the surface but share underlying similarities. |</p>

<h2>Friction and Frequency</h2>

<p>H and V explain what a market trades and how it verifies value. But there is a third dimension that determines whether trust is cheap or expensive: how often participants interact. Markets can also be defined by the Frequency of Interaction. Frequency of Interaction can act as the "Memory" of a market. If you treat every interaction as the first time you've met (Low Frequency), you must pay the full cost of Verification and Setup (High Friction). If you interact frequently, you build "State" (Memory/Reputation), which allows you to bypass those costs.</p>

<p>Frequency can also override verification through "The Shadow of the Future," anticipated future interaction may sustain cooperation. If the frequency is high enough, you do not need verification or even law. For example take the diamond market in New York where dealers trade high sums of diamonds with each other often over phone or chat based on a handshake agreement where settlement might be delayed. If counterparties trade with each other every day for decades, cheating once could risk being exiled forever. The same was also true for FTX, users logged on every day, traded, deposited, and withdrew and nothing went wrong. Even the initial concerns were often dismissed by those who had gotten used to the high frequency of interaction with the exchange.</p>

<p>The history of the web provides valuable lessons of increasing frequency to drive friction to zero.</p>

<img src="images/coordination-markets-protocols/friction_frequency.png" alt="Friction vs. Frequency: Internet and Bitcoin" />

<h3>Phase 1: Dial Up (Low Frequency)</h3>

<p><strong>The State</strong>: You had to physically log on. The cost to initiate a session was high (noise, blocking the phone line).</p>

<p><strong>The Result</strong>: You went online once a day for 30 minutes. You batched your emails. The friction of connecting kept the internet separate from real life.</p>

<h3>Phase 2: Broadband & Cookies (Medium Frequency)</h3>

<p><strong>The Mechanism</strong>: The "Session Cookie" was the breakthrough. It meant the server remembered you. You didn't have to verify your password for every single click.</p>

<p><strong>The Frequency Hack</strong>: The cookie simulates an infinite frequency connection. It tells the server, "I am the same person from 1 second ago."</p>

<p><strong>The Result</strong>: Ecommerce. You could fill a shopping cart. Without the memory of high frequency, the cart would empty every time you clicked a new page.</p>

<h3>Phase 3: Mobile & Push (Infinite Frequency)</h3>

<p><strong>The State</strong>: The iPhone made the connection permanent. You are never offline.</p>

<p><strong>The Result</strong>: The Attention Economy. Because frequency is infinite, friction is zero. Apps can push notifications to you. The barrier between "Digital" and "Physical" collapsed.</p>

<p>| Era / Tech | Low Frequency State (High Friction) | High Frequency Solution | The Resulting Friction Drop |</p>
<p>|---|---|---|---|</p>
<p>| Retail | Buying a song for $0.99 (iTunes) | Subscription (Spotify) | Payment Friction to 0. You consume without deciding. |</p>
<p>| Finance | Wiring Money (SWIFT) | Netting / Clearing House | Liquidity Friction to 0. Counterparties only settle the difference at the end of day. |</p>
<p>| Computing | Loading a Program (CD-ROM) | SaaS / Cloud (Always on) | Update Friction to 0. Software updates happen while you sleep. |</p>
<p>| Crypto | Onchain Transaction | ? | ? |</p>

<h2>Crypto and Frequency</h2>

<p>This is a dimension where crypto has a lot of room to develop. There have been a few examples of implementing a high frequency of interaction solution around protocols like Bitcoin such as:</p>

<p><strong>Lightning state channels</strong>: 2 counterparties open a private channel and can transact back and forth millions of times almost instantaneously only touching the blockchain to settle the final balance. This has found some adoption in the B2B use case, predominantly between exchanges.</p>

<p><strong>Custodial wrappers</strong>: Apps like Cash App use custodial lightning which improves user experience, higher frequency of interaction at the cost of verification. ETFs offer Bitcoin to a wide investor base who are familiar with the ETF instrument, allowing people to save in Bitcoin through an automatic 401K or other retirement plans.</p>

<p><strong>Account Abstraction</strong>: This is the crypto equivalent of the Session Cookie. Instead of signing every single transaction (high friction, like entering your password on every click), a session key lets you authorize a dApp once and interact freely for a defined period. It simulates high frequency trust without repeated verification.</p>

<p>The pattern across all three is the same tradeoff the internet made. Lightning works but mostly between exchanges, not end users. Custodial wrappers reach mass adoption by reintroducing the trusted intermediary the protocol was designed to remove. Account abstraction delegates signing authority, which means trusting code you didn't write. Each solution increases frequency by giving back some verification. The question is whether crypto can find a frequency solution that doesn't quietly rebuild the platform.</p>

<h2>Protocols are few and far between</h2>

<h3>The Friction Paradox</h3>

<p>Protocols push Verification Cost toward zero by replacing trust with cryptographic proof. But every proof is friction the user must bear. Every seed phrase, every gas fee, every transaction signature is the cost of trustlessness made tangible. Platforms can raise venture capital precisely because they capture value, and they spend that capital sanding down friction. Protocols, by design, have no central entity to do this.</p>

<p>This is the core tension: low V and low friction are at odds. Choosing trustlessness means choosing friction. A platform like Uber can spend billions making rides one-tap. A protocol has no one to write that check.</p>

<h3>The Bootstrap Problem</h3>

<p>Because no single entity captures value from a protocol, no single entity is incentivized to fund its development or polish its UX. The successful internet protocols sidestepped this: TCP/IP had DARPA, HTTP had CERN, SMTP had ARPANET. All funded by governments or academia before commercial platforms existed to compete. Bitcoin is the outlier: the token itself was the incentive mechanism. But even the "Fat Protocols" thesis, the idea that crypto tokens would solve the funding problem by letting protocols capture value directly, has largely bootstrapped speculation rather than usability.</p>

<h3>The Protocol Graveyard</h3>

<p>Protocols rarely die from technical inferiority. They die from friction, funding, and platform absorption.</p>

<p><strong>Gopher</strong> was the dominant information protocol of the early '90s until the University of Minnesota announced licensing fees. HTTP was technically comparable but free. The web won.</p>

<p><strong>XMPP</strong> powered Google Talk, Facebook Messenger, and others. Google embraced the open standard, gained users, then dropped federation for Hangouts in 2013. WhatsApp was built on a modified version of XMPP. The protocol community was hollowed out in the subsequent years. Embrace, extend, abandon.</p>

<p><strong>RSS</strong> was beautifully simple: any site could publish a feed, any user could subscribe, no algorithms, no gatekeepers. But it couldn't be monetized. Google Reader's shutdown in 2013 killed the ecosystem, and social media absorbed the function.</p>

<p><strong>OpenID</strong> offered self-sovereign identity: log in anywhere with one identity you control. It lost to "Sign in with Google" because managing your own identity is more friction than trusting a platform to do it for you.</p>

<p>The pattern: protocols that can't fund friction reduction get outcompeted by platforms that can.</p>

<h3>The Gravitational Pull</h3>

<img src="images/coordination-markets-protocols/gravitational_pull.png" alt="The Gravitational Pull: Protocol to Platform" />

<p>Protocols that succeed at reducing V create a friction gap that platforms rush to fill. Coinbase custodies 85% of spot ETF Bitcoin. Passkeys replace seed phrases via Google and Apple. Account abstraction hides gas fees behind a familiar UX. Every one of these friction-reduction layers reintroduces trust and centralization, re-creating the platform structure the protocol was designed to eliminate.</p>

<p>The pull from protocol back toward platform is nearly gravitational. The rare protocols that resist it (TCP/IP, HTTP, SMTP, Bitcoin) share traits: they solved low-H, low-V problems, they were simple enough to ship fast, and they arrived before or alongside a unique window where platforms couldn't yet compete.</p>]]></content:encoded>
      <pubDate>Tue, 27 Jan 2026 00:00:00 GMT</pubDate>
      <guid isPermaLink="true">https://rencryptofish.com/posts/coordination-markets-protocols</guid>
    </item>
    <item>
      <title>Leverage and Path Dependence for Perpetual Swaps</title>
      <link>https://rencryptofish.com/posts/leverage-path-dependence-perps</link>
      <description>How leveraged perpetual swap positions exhibit path dependence and introducing Expected Time to Liquidation</description>
      <content:encoded><![CDATA[<p>This article explores how leveraged perpetual swap positions exhibit path dependence, meaning the sequence of price movements determines which positions survive liquidation. The analysis demonstrates that leveraged perps behave similarly to synthetic options and introduces the concept of "Expected Time to Liquidation" to help traders understand the implicit duration of their leveraged positions.</p>

<h2>Understanding Path Dependence in Leveraged Perps</h2>

<p>Perpetual swaps are typically considered delta-one instruments with 1-to-1 payoffs matching underlying asset prices. However, leverage introduces complexity: "the sequence of spot price affects which positions survive and which positions get liquidated."</p>

<p>The article presents simulations showing liquidated positions (in red) versus surviving positions (in blue) for a 10x leveraged perpetual swap with 50% volatility.</p>

<a href="images/leverage-path-dependence-perps/perpetual_swap_liquidation_paths.png"><img src="images/leverage-path-dependence-perps/perpetual_swap_liquidation_paths.png" alt="Perpetual swap liquidation paths" /></a>

<p>When graphed, leveraged long perpetual payoffs resemble call option payoffs when margin isn't topped up and liquidation occurs.</p>

<a href="images/leverage-path-dependence-perps/leveraged_perpetual_payoff.png"><img src="images/leverage-path-dependence-perps/leveraged_perpetual_payoff.png" alt="Leveraged perpetual payoff" /></a>

<h2>Expected Time to Liquidation Framework</h2>

<p>Rather than expecting liquidation, traders benefit from understanding "how long a perp position is expected to survive can provide helpful intuition on the implicit duration of the position expressed."</p>

<p><strong>Key Variables:</strong></p>
<ul>
<li><strong>$S_0$</strong>: Initial entry price</li>
<li><strong>$L$</strong>: Leverage ratio</li>
<li><strong>$\sigma$</strong>: Annualized volatility</li>
<li><strong>$\mu$</strong>: Drift rate (market trend minus funding rate)</li>
<li><strong>$B$</strong>: Liquidation barrier = $S_0(1 - 1/L)$</li>
<li><strong>$\tau$</strong>: First passage time until liquidation</li>
</ul>

<p><strong>Price Dynamics Model:</strong></p>

<p>Price follows geometric Brownian motion:</p>

<p>$</p>
<p>dS_t = \mu S_t dt + \sigma S_t dW_t</p>
<p>$</p>

<p>Where $W_t$ represents standard Brownian motion.</p>

<p>Converting to log-space with $X_t = \ln(S_t/S_0)$:</p>

<p>$</p>
<p>dX_t = (\mu - \sigma^2/2)dt + \sigma dW_t</p>
<p>$</p>

<p>The liquidation barrier in log-space: $b = \ln(1 - 1/L)$</p>

<p><strong>Expected Time to Liquidation Formula:</strong></p>

<p>$</p>
<p>E[\tau] = \frac{-\ln(1 - 1/L)}{\mu + 0.5\sigma^2}</p>
<p>$</p>

<p>For days:</p>

<p>$</p>
<p>E[\tau_{\text{days}}] = 365 \times \frac{-\ln(1 - 1/L)}{\mu + 0.5\sigma^2}</p>
<p>$</p>

<h2>Practical Implications</h2>

<p>The heatmap analysis reveals that a 50x leveraged long position in a 150% volatility asset faces liquidation within approximately 6.6 days under zero drift and funding conditions.</p>

<a href="images/leverage-path-dependence-perps/liquidation_heatmap.png"><img src="images/leverage-path-dependence-perps/liquidation_heatmap.png" alt="Liquidation heatmap" /></a>

<p>Key insights include:</p>

<ul>
<li>Higher leverage reduces expected time to liquidation disproportionately</li>
<li>Funding costs further compress position duration</li>
<li>Lower funding rates (via products like Ethena or HLP) enable longer-term leveraged positions</li>
<li>Traders should calibrate leverage based on expected thesis timeframe and asset volatility</li>
</ul>

<a href="images/leverage-path-dependence-perps/median_liquidation_leverage_funding.png"><img src="images/leverage-path-dependence-perps/median_liquidation_leverage_funding.png" alt="Median liquidation time by leverage and funding" /></a>

<p>The analysis underscores why perpetual exchange liquidity and funding rate mechanisms significantly impact trader behavior and position sustainability.</p>

<p>---</p>

<p><em>Originally posted on <a href="https://x.com/0xren_cf/status/1928141261229465612">X</a>.</em></p>]]></content:encoded>
      <pubDate>Thu, 29 May 2025 00:00:00 GMT</pubDate>
      <guid isPermaLink="true">https://rencryptofish.com/posts/leverage-path-dependence-perps</guid>
    </item>
    <item>
      <title>Investing in Unto Labs</title>
      <link>https://rencryptofish.com/posts/investing-in-unto-labs</link>
      <description>On backing Liam Heeger, Will Yoo, and the team building Thru — a novel blockchain built from scratch with a RISC-V VM and competition-driven consensus</description>
      <content:encoded><![CDATA[<p>I first met Liam Heeger during the 2021 cycle. At the time he was working at Framework building a low latency trading system. We first met at a gathering of MEV interested anons who spent their days and nights in group chats talking about the microstructure of centralized exchanges and the intricacies and trade offs of the different blockchains that were gaining steam at that time. Through my limited conversation with him that night, I was surprised how quickly Liam had grasped the low level details of low latency trading such as jitter and connectivity without having apprenticed at a HFT firm previously, he seemed mostly self taught in a field where apprenticeships were the norm.</p>

<p>Some time passed, it was the bear market of 2023 and I was in Paris for EthCC. Liam happened to be in town, he had just started work on Firedancer. I was really excited to chat with him about it because we had recently made an investment in Solana. I was convinced that blockchains needed to continue to scale and that users desired a snappy, fast finality experience that they had grown accustomed to in modern web and mobile apps. I had been tracking the Firedancer repo closely and we chatted through some of the recent PRs, the optimizations Firedancer was making to improve Solana and to push the limits of what was considered possible. A lot of what developers on Solana were working on at the time and talking about was heavily overlooked by the broader industry, but we reasoned through each of the design choices from first principles and given the resources at that point in time, it seemed like the best path forward.</p>

<p>The work put in by Solana in the bear market paid off, memecoins came and the network became congested very quickly. Users loved the seamless mobile Phantom wallet experience of quickly trading the meme of the day on their phones but landing transactions became extremely challenging. The network was straining and it became clear that the scaling frontier needed to be pushed further. Breakout consumer apps are rare, often the idiom "catching lightning in a bottle" is used to describe the magical viral breakout moment that define consumer apps. But yet for on chain crypto apps this was extremely elusive. In 2021 and 2024, at the very moment where usage is the highest, the networks become incapable of scaling up to meet user demand. This makes it very hard to catch lightning in a bottle and often the lightning escapes. Blockchains needed to add the ability to scale up resources to meet this demand.</p>

<p>I reconnected with Liam in February 2025. I had heard he was working on Unto Labs building Thru. I had seen the press headlines, but when I chatted with him I was surprised. This was not Solana, this was not Firedancer, this was a completely novel way of approaching blockchains from scratch. A lot of the ideas stood out to me. I had spent most of 2024 understanding Bitcoin and the details behind its consensus mechanism that enabled competition in its resource provisioning layer that has historically eluded Proof of Stake chains. The core pillars of Thru stood out to me. A RISC-V virtual machine which benefits from open source work in every major industry and a competition driven consensus mechanism that forces all stakeholders to push the network forward without the heavy lift of social consensus and politics.</p>

<p>Through our conversations in 2025, I also met Will Yoo, co-founder of Unto Labs. Over the span of the past few months, we talked and worked through everything from consensus discussions to operational details at any time of weekdays and weekends. I was struck by Will's commitment, drive, and focus to grow Thru. We all recognized that we are still early and crypto is still a small industry. As of April 2025, there are only 10.3 million daily active addresses and a fraction of that in actual daily active users. Roughly 5.6 billion people access the internet each day. If every wallet were a human (which they are not), we have optimistically onboarded 0.18% of daily internet users.</p>

<p>Thru is not competing against Solana or Ethereum. Thru, like every other blockchain in crypto, is building the rails to support 5.6 billion users a day. To do that, innovations in the virtual machine, networking, and consensus mechanisms are all required.</p>

<p>Job's not finished.</p>]]></content:encoded>
      <pubDate>Tue, 29 Apr 2025 00:00:00 GMT</pubDate>
      <guid isPermaLink="true">https://rencryptofish.com/posts/investing-in-unto-labs</guid>
    </item>
    <item>
      <title>Analyzing Bitcoin Consensus: Risks in Protocol Upgrades</title>
      <link>https://rencryptofish.com/posts/analyzing-bitcoin-consensus</link>
      <description>An analysis of bitcoin&apos;s consensus mechanism, stakeholder roles, and the inherent difficulty of protocol changes</description>
      <content:encoded><![CDATA[<a href="https://bitcoin-cap.github.io/bcap/">Read the full paper →</a>

<p>This paper provides an analysis of bitcoin's consensus mechanism, focusing on the roles of various stakeholders, their powers, and the incentives that guide their actions. Bitcoin is incredibly difficult to change by design. The default is no change. Any significant change needs to pass that hurdle.</p>

<h2>The Nature of Bitcoin Consensus</h2>

<p>Bitcoin's consensus mechanism extends far beyond the technical protocol. It encompasses a social and economic process where multiple stakeholder groups must align before any change can be implemented. The system is deliberately conservative — the status quo has a built-in advantage, and any proposed modification faces significant resistance by default.</p>

<p>This conservatism is a feature, not a bug. It protects the network's core properties: fixed supply, censorship resistance, and permissionless access. The difficulty of changing Bitcoin is what makes these guarantees credible.</p>

<h2>Six Stakeholder Groups</h2>

<p>We categorize the roles people play in bitcoin's consensus into six distinct stakeholder groups, each with their own motivations and influence:</p>

<p>1. <strong>Users</strong> — Individuals and entities who hold and transact in bitcoin. They ultimately determine which version of the software (and thus which rules) they accept. Users express preferences through the software they run and the chain they recognize as valid.</p>

<p>2. <strong>Miners</strong> — Entities that expend computational resources to produce blocks. Miners have direct influence over which transactions are included in blocks and can signal support for or against proposed changes. Their economic incentives are tied to the value of block rewards and transaction fees.</p>

<p>3. <strong>Bitcoin Core Developers</strong> — Contributors who write, review, and maintain the reference implementation. They propose and implement technical changes but cannot force adoption. Their influence comes from expertise and trust rather than formal authority.</p>

<p>4. <strong>Bitcoin Core Maintainers</strong> — A smaller subset of developers with merge access to the repository. They serve as gatekeepers for the reference implementation. Notably, while Bitcoin Core maintainers do not have excessive power to change Bitcoin, they possess significant power to veto changes.</p>

<p>5. <strong>Economic Nodes</strong> — Exchanges, payment processors, and other businesses that validate transactions and enforce consensus rules. These entities have outsized influence because they determine which chain has economic activity and liquidity.</p>

<p>6. <strong>Investors and Speculators</strong> — Market participants whose capital allocation decisions signal confidence in (or concern about) proposed changes. Market reactions can accelerate or derail consensus processes.</p>

<h2>Shifting Power Dynamics</h2>

<p>The relative powers of the stakeholders shift depending on their role in the network's operation and the stage of the consensus change process. During normal operation, miners and economic nodes have the most direct influence on the network. During a proposed consensus change, the dynamic shifts:</p>

<ul>
<li><strong>Proposal stage</strong>: Developers and technical contributors dominate the conversation, as changes must first be coherent at a technical level.</li>
<li><strong>Debate stage</strong>: Users, businesses, and investors become more influential as the discussion moves from technical feasibility to economic and philosophical desirability.</li>
<li><strong>Activation stage</strong>: Miners and node operators become critical, as they must actually run the new software for a change to take effect.</li>
<li><strong>Post-activation</strong>: Users and economic nodes ultimately decide whether the change "sticks" by choosing which chain to recognize and transact on.</li>
</ul>

<h2>The Veto Power Asymmetry</h2>

<p>One of the key findings is the asymmetry between the power to propose changes and the power to block them. Bitcoin Core maintainers illustrate this clearly: while they cannot unilaterally push changes onto the network, their gatekeeping role over the reference implementation gives them substantial veto power. A change that is not merged into Bitcoin Core faces a much higher barrier to adoption, even if it has broad community support.</p>

<p>This asymmetry exists at every level. Any stakeholder group can effectively veto a change by refusing to adopt it:</p>

<ul>
<li>Miners can refuse to signal for activation</li>
<li>Economic nodes can refuse to upgrade their software</li>
<li>Users can continue running old versions</li>
<li>Developers can refuse to implement or review proposals</li>
</ul>

<p>The result is that consensus changes require broad, multi-stakeholder agreement — a high bar that protects the network but also makes beneficial upgrades slow and contentious.</p>

<h2>State of Mind</h2>

<p>We also introduce the concept of <strong>State of Mind</strong>, which affects the degree that stakeholders engage in the process of finding consensus. Stakeholders exist on a spectrum from fully engaged to completely passive:</p>

<ul>
<li><strong>Active participants</strong> closely follow technical discussions, run test software, and provide feedback on proposals. Their engagement directly shapes outcomes.</li>
<li><strong>Passive participants</strong> may hold strong opinions but do not actively contribute to the consensus process. They express preferences primarily through market behavior and software choices.</li>
<li><strong>Unaware stakeholders</strong> may not even know a consensus change is being proposed. Their inaction defaults to supporting the status quo.</li>
</ul>

<p>The State of Mind concept is important because it highlights that consensus is not a simple vote. The intensity of preference matters as much as the direction. A small group of deeply engaged stakeholders can have more influence than a large group of passive ones, for better or worse.</p>

<h2>Implications for Protocol Upgrades</h2>

<p>Understanding these dynamics has practical implications for anyone proposing or evaluating Bitcoin protocol changes:</p>

<ul>
<li><strong>The burden of proof is on the proposer.</strong> The default state of "no change" means that any proposal must demonstrate clear, compelling benefits that outweigh the risks of modification.</li>
<li><strong>Technical merit is necessary but not sufficient.</strong> A change must also navigate the social and economic consensus process, which requires buy-in from multiple stakeholder groups with different incentives.</li>
<li><strong>Activation mechanisms matter.</strong> The choice of how a change is activated (flag day, miner signaling, user-activated soft fork) affects which stakeholders have the most influence and can change the outcome.</li>
<li><strong>Patience is required.</strong> Bitcoin's consensus process is deliberately slow. Attempts to rush changes face resistance from the system's conservative design.</li>
</ul>

<p>The difficulty of changing Bitcoin is its greatest strength and its greatest challenge. It ensures that the network's fundamental properties remain stable, but it also means that even widely desired improvements can take years to implement. Understanding the roles, powers, and incentives of each stakeholder group is essential for navigating this process effectively.</p>]]></content:encoded>
      <pubDate>Wed, 06 Nov 2024 00:00:00 GMT</pubDate>
      <guid isPermaLink="true">https://rencryptofish.com/posts/analyzing-bitcoin-consensus</guid>
    </item>
  </channel>
</rss>