<100 subscribers
This article explores three trending topics—Jito BAM, BRC2.0, and EIP-7999—and offers critical evaluations.
Welcome to the Web3 Compass series, where Shisijun provides focused analysis on emerging technologies, protocols, and products in the Web3 space.
The catalyst for this series? AI has doubled my efficiency in researching new projects, highlighting that human value increasingly lies in judgment, insight, and creativity.
Each installment will break down innovations through three lenses—industry context → technical principles → potential impact—helping you grasp core developments swiftly and anticipate their ripple effects.
A disclaimer: My views often lean pessimistic and are neither investment advice nor targeted at specific projects.
What It Is
In short, BAM is a block-building platform for Solana, akin to Ethereum’s builder network implementing Proposer-Builder Separation (PBS). Both aim to standardize transaction ordering, combat MEV, and mitigate centralized risks.
Backstory and Key Players
Spearheaded by the Jito alliance—Solana’s dominant auction platform, controlling 90% of validator clients—BAM boasts heavyweight backers like Triton One, SOL Strategies, Figment, Helius, Drift, Pyth, and DFlow. This is clearly a coordinated effort by Solana’s core ecosystem.
The motivation is clear: Solana faces pressure from chains like Hyperliquid (a native order-book chain optimized for market makers). Solana’s open architecture makes such optimizations challenging, but customizable block construction could bypass its linear block-production limits, unlocking DeFi potential.
Deployment Roadmap
Phase 1
Phase 2: Expands to more operators, targeting 30%+ staked validators.
Final Phase: Open-sourced code and decentralized governance.
With the industry’s growing emphasis on "verifiable fairness," BAM’s TEE (Trusted Execution Environment) + PBS approach aligns neatly with validator and protocol interests.
Technical Mechanics
Solana’s Proof-of-History (PoH) processes blocks linearly (400ms slots split into 64 tips intervals, where transactions are finalized upon submission). Unlike Ethereum’s "consensus-then-sync" model, BAM lets Jito upgrade validator clients en masse, boosting adoption.
BAM’s architecture (see diagram below) features a purple core module and plugin system:
![BAM System Structure]
Transactions are no longer fed piecemeal to leaders. Instead, TEE sequences entire blocks using plugin-defined rules (e.g., prioritizing oracle price updates or filtering failed DEX trades), then submits them wholesale. Validators must prove exclusive block space allocation to BAM.
Plugins enable hardcoded sequencing logic. For example:
Oracles can mandate price updates as a block’s first transaction, reducing latency risks.
DEXs can discard likely-to-fail trades pre-execution, saving fees.
BAM coexists with Solana’s current flow: regular order flow, Jito bundles, and BAM blocks (which are all-or-nothing).
Critical Take
BAM is "high-profile, narrative-rich, and use-case-driven," but mainstream adoption faces hurdles. Like Ethereum’s Builder Net and MEV Share, progress may stall due to:
TEE limitations: High costs and ~1k QPS caps (despite handling 40% of Ethereum blocks). Solana’s throughput demands massive TEE scaling, plus redundancy for uptime.
Economic viability: Jito’s Q2 2025 revenue was just 22,391 SOL (~$4M). Migrating Solana’s volume risks TEE outages (volatile memory exacerbates this), potentially causing mass transaction drops.
Yet, BAM’s killer features—oracle sequencing, fail-safe transactions—could attract market makers and enterprises. With Solana’s ideological backing, it’s a PR win.
Final Note: BAM isn’t for 24/7 throughput but "critical-block determinism." But in Web3, 99% reliability equals 0%—absolute certainty is non-negotiable for big players.
What It Is
Scheduled for activation on September 2, 2025, BRC 2.0 is a "BTC-triggered, EVM-executed" shadow system (distinct from BRC-20). Users inscribe "commands" on Bitcoin (via inscriptions or commit-reveal), while a modified EVM in indexers handles deployment/calls. Gas is waived in EVM but paid via BTC transaction fees.
Similar to Alkanes (which uses BTC’s OP_RETURN and WASM), BRC 2.0 runs on EVM.
Backstory and Key Players
Pioneered by BestinSlot (a BTC inscription-era platform), BRC 2.0 extends BRC-20’s ethos: avoid consensus changes, layer programmability atop BTC.
The backdrop? BTC programmability/L2 hype has outpaced engineering, leaving a gap now filled by BRC 2.0 and Alkanes.
Market traction may lag due to BTC’s fragmented development culture. BRC 2.0 and BRC-20 share design DNA but lack formal ties.
Technical Mechanics
BRC 2.0 operates in indexers—not on-chain or as a separate chain (no consensus). User EVM addresses derive from hashed BTC addresses.
Commands are JSON strings (like BRC-20):
{ "p": "brc-20", "op": "deploy", ... }
Instructions (bytecode/calldata) are encoded in BTC transactions and replayed in EVM. Gas pricing is zeroed in EVM (resource caps only), with fees paid on BTC.
Risks: Code audits reveal no call-depth limits, risking infinite recursion crashes (fixable with max-depth guards).
Critical Take
Branding: "BRC 2.0" leverages existing buzz better than a new protocol name (see RGB’s resurgence).
Originality: Shares BRC-20’s schema but lacks creator endorsement.
Philosophy: BTC’s value lies in scarcity, not programmability. Chasing smart contracts dilutes its "unvaluable" status—a paradox where limitations become strengths.
What It Is
Proposed by Vitalik, this EIP (renamed from EIP-0000) addresses post-EIP-4844 fee fragmentation (blob vs. calldata vs. execution fees) by introducing a unified "total max fee + multi-resource price vector" transaction type.
Backstory
Vitalik has long advocated fee market reform (see 2022/2024 posts). The urgency stems from wallet/router pain:
Blobs: 6/block, auction-based pricing.
EIP-1559: Base fees for execution.
Calldata: Variable pricing since 2015.
L2 devs are squeezed—setting separate fee caps per resource risks transaction failures even with sufficient total funds.
Technical Mechanics
The proposal replaces multiple max_fee_per_gas fields with a single max_fee, dynamically allocated across EVM gas, blob gas, and calldata gas.
New transaction type fields:
[ max_fee, fee_vector, ... ]
Simpler than ERC-4337’s gas model (see From 4337 to 7702: Ethereum Account Abstraction’s Past and Future).
Critical Take
Pros: Unifies fees, easing L2/L3 development—aligned with Ethereum’s roadmap.
Cons: Complexity spikes. Changes to block headers, RLP encoding, and limits demand hard forks and ecosystem-wide upgrades (wallets, tools).
Timeline: Likely 1-2 major forks away. Vitalik’s fee-market essays remain essential reading for crypto-economic insights.
0x1AC9...1256
Support dialog