Welcome to the "Web 3 Barometer" series, where I, Shijun, provide a concentrated analysis and interpretation of recent new technologies, protocols, and products in the Web 3 industry.
The impetus for this series is that AI has doubled my speed in researching new projects, and I believe that in the future, the value of humans will focus more on thinking, judgment, and inspiration.
Therefore, this series will help you grasp core changes and assess the trends they may trigger from three perspectives: industry background → technical principles → potential impacts.
The author's views are mostly pessimistic and should not be taken as investment advice, nor are they directed at any specific project.
Jito BAM | "Block Sorting + Plugin-based Block Building Market on Solana"
What it is:
In simple terms, BAM is a "block building" platform on Solana, similar to the goal of Ethereum's builder net doing PBS (separating block builders and validators), aimed at creating a more orderly transaction sequence, combating MEV, and preventing the risks of centralized malfeasance.
Who launched it and what is the background:
The leading party is the Jito camp, the largest transaction auction platform on Solana, occupying 90% of the validator client market, with strong leadership influence. I have previously conducted detailed research that can be referenced: Ten Thousand Words Research Report: The Evolution of MEV on Solana and Its Pros and Cons
The participants are also very strong, including Triton One, SOL Strategies, Figment, Helius, Drift, Pyth, DFlow, etc. Clearly, this is a joint action by Solana's officials and mainstream projects.
The motivation behind this is quite understandable: on one side, Solana faces explosive development pressure from "native order book chains" like Hyperliquid, which is very beneficial for market maker operations. However, Solana's inherent development nature makes it difficult to optimize specifically for this. If the entire block's transactions can be customized, it can break through the limitations of Solana's linear block production, thus benefiting various DeFi scenarios.
The official deployment plan is: initially operated by Jito Labs with a small number of validators participating; in the medium term, expanding to more node operators, aiming to cover 30%+ of network staking; ultimately, the code will be open-sourced and governed in a decentralized manner.
Additionally, with the industry's narrative trend towards "verifiable fairness," BAM is likely to gain support from validators and protocol parties. Therefore, I believe it is more rooted in the pursuit of fairness optimization concepts like TEE + PBS, launched against this background.
How it works:
To understand its value, one must also grasp a characteristic of Solana's POH algorithm.
Its block production is actually gradually linear (within a slot of 400 ms, there are 64 time segments for tips; when each time segment arrives, the current transaction is sent out, and it does not change unless rolled back), which is different from Ethereum's model of "arranging the entire block, reaching consensus, and then synchronizing."
Through this BAM system, Jito can easily upgrade a large number of validators' clients, thereby increasing the acceptance rate of the BAM system among validators.
Looking at the structure of the BAM system as shown in the diagram below, the purple part in the middle and the Plugin code on the right are BAM.
This will allow transactions on Solana to not be sent to the Leader one by one, but rather to first arrange the transaction order of "the entire block" in TEE (Trusted Execution Environment) (combined with fixed sorting rules implemented by Plugin code), and then submit it to the validators all at once.
Validators must also ultimately provide proof to TEE, indicating that they have indeed allocated the block's space (exclusivity) to this order flow market.
A notable feature here is the plugin functionality, which can "hardcode" rules into the transaction order sorting in TEE. This has practical application significance:
For example, an oracle platform may need to ensure that price updates are fixed as the first transaction in a block, which can reduce the randomness of on-chain price update transactions, thus avoiding issues caused by untimely price updates. Similarly, for DEX, a plugin can be written to identify high-probability failed transactions and not package them within TEE, gradually waiting for the transactions to expire, thereby reducing the fees incurred from failures.
It can coexist with the existing Solana block production process: still operating with ordinary order flow, Jito bundles, and BAM in parallel. BAM is "only accepting the entire block of BAM in a certain block."
How to evaluate it:
I believe this is a path characterized by "strong lineup, strong narrative, and focused scenarios," but I am not optimistic about it becoming a mainstream market path.
Similar to the reasons why the Builder net on Ethereum and the highly anticipated MEV share have struggled to progress over the years.
The reality is that TEE is costly, and the QPS limit is only in the thousands (back in 2013, TEE had only 128 MB of memory, and while it has developed significantly since then, it can still only handle QPS in the thousands), even though 40% of Ethereum's blocks are now constructed by TEE.
However, Solana's data and computational throughput are significant; you need to stack many TEEs to handle the volume, along with disaster recovery, memory, and bandwidth operations. If this project lacks continuous economic incentives, it will be difficult to achieve positive returns.
In fact, Jito's earnings are not high (compared to high-yield protocols on-chain); for instance, in the second quarter of 2025, Jito earned only 22,391.31 SOL (approximately 4 million USD) through tips. Once a significant volume of Solana's transactions migrates over, TEE failures will inevitably occur, and TEE has many characteristics such as memory failures and storage clearing, which will increase the risk of outages and lead to a large-scale disappearance of transactions.
However, it has the potential for "killer high-priced selling points": for example, oracle sequencing and failure waivers are all "visible" experiential benefits. Market makers and enterprise-level trading platforms will pay for it. Moreover, the involvement of Solana officials in the concept is a good way to gain visibility.
Finally, BAM's positioning is not to handle 7 x 24 throughput; it is a tool for "providing deterministic guarantees for key blocks." However, many deterministic guarantees rely on absolute certainty, not 30% certainty. In the absence of 100% certainty, even 99% is 0%, which is the key to the decision-making of major Web 3 projects.
BRC 2.0 | "Mapping EVM": Programmable Capabilities Driven by BTC
What it is:
It will be activated on September 2, 2025. I understand this as a "BTC-driven, EVM-executing" dual-chain shadow system. Note that it is not BRC 20, but refers to the second generation of BRC. For the background of BRC 20, you can refer to: Interpretation of Bitcoin Ordinals Protocol and BRC 20 Standard: Principles, Innovations, and Limitations
The core of 2.0 is that you write "instructions" on BTC using inscription or commit-reveal, running a "modified EVM" in the indexer to execute the corresponding deployment and calls. EVM does not charge gas (parameters are reserved but not priced), and transaction fees are calculated in BTC transactions.
It is fundamentally similar to the Alkanes protocol (Methane), where Methane writes transaction instructions based on the BTC op-return field and runs on the WASM virtual machine, while this runs on EVM.
Who launched it and what is the background:
The initiator's background is the bestinslot platform, which gained popularity during the BTC inscription era, continuing the idea of BRC-20: not altering BTC consensus while trying to layer "programmability" on top.
The industry background is that in the past two years (actually the last two years), the narrative around BTC programmability/L2 has been hot, with everyone looking for feasible engineering paths. However, the gap between market trends and development progress has been too large, leading to the emergence of models like BRC 2.0 and Alkanes only this year.
Market visibility is somewhat limited because the BTC stage has always lacked a cohesive force to guide it, and many protocols can derive from other protocols. Therefore, BRC 2.0 is likely to have no actual relationship with BRC 20.
How it works:
It operates in the indexer, not on the BTC chain or as a separate chain, executing EVM logic. Note that it is not considered a chain because there is no consensus.
The address on the EVM that users control is hashed from the user's BTC address and then mapped to a "virtual EVM address."
To operate this system, it is actually quite similar to the logic of asset control in BRC 20, which is just a JSON string. In BRC 2.0, it is defined as follows:
You can see that you are encoding instructions on BTC, with various bytecode/call data attached, which is replayed and executed in EVM.
Moreover, the signature and gas have also changed: the EVM layer gasPrice=0, only serving as a resource limit; actual fees are reflected in BTC transaction fees.
This approach is indeed very risky. I specifically had AI search through their node code and found no protection for "call depth/step limits." So theoretically, a contract with "infinite recursion/self-calling" could crash this VM (of course, this protection is not hard to implement: just set a maximum depth).
How to evaluate it:
First of all, they know how to name things; at least the buzz around BRC 2.0 will be better than creating a new protocol name, similar to how RGB has gained attention again recently.
Secondly, it is not entirely unrelated to BRC 20, as their protocol design concepts and field patterns are basically the same, but this is not a copyright issue. However, I have not seen the original author of BRC 20 endorse it, so the connection should not be significant.
Finally, all platforms exploring programmability may want to share the value of this world-class consensus. However, I believe that BTC should not pursue programmability because no matter how it is pursued, it will never catch up with the optimizations in functionality and experience offered by various high-speed chains.
Moreover, if programmability is even built into BTC itself, it would break its valuation trap. A project that can be practically applied can be valued based on PE, but the strength of BTC lies in its limited supply-demand model. Limited supply-demand cannot be valued, so there is a price, and with the price comes consensus. Thus, the limitations of BTC itself actually contribute to its success.
EIP-7999 | Ethereum Multidimensional Fee Market Proposal
What it is:
This proposal, led by Vitalik, is certainly worth a look. Additionally, in the latest EIP, it has been renamed from EIP-0000 to EIP-7999, so this article will refer to both.
This is a new transaction type proposed in the context of "transaction fee splitting" (where a single transaction has a price for blobs, a price for calldata, and an execution price under EIP-1559) following EIP-4844. It introduces a "total price cap + multiple resource price vectors."
You can understand it as: packaging all resource quotes at once and making a unified semantic bid, aiming to solve the problem of too many pricing dimensions on-chain.
Who launched it and what is the background:
The direction has been promoted by Vitalik through multiple articles. Previously, there was a section about "four zeros" in the EIP that was later renumbered to 7999, and the name is not as impressive. This direction has also been a recurring thought in Vitalik's writings, with reflections seen in posts from 2022 and 2024.
Why propose it now?
Because wallets, routers, and auctioneers have clearly felt the disjointed experience of a "multi-price system": each block only has 6 blobs, so transactions using blobs need to bid; the transactions themselves are still under EIP-1559; and there are different unit prices for calldata based on 0/non-0 bytes since 2015… L2 developers have been pushed to a corner because they must set independent fee caps for each resource dimension. Any dimension set too low will cause the entire transaction to fail, even if the user's total fee budget is sufficient, they may be unable to execute the transaction due to a sudden increase in the base fee for a particular resource.
How it works:
The proposal plans to introduce a unified multidimensional fee market. The core design allows users to set a single maxfee parameter (replacing multiple maxfeepergas on different fields), while the EVM execution process will automatically allocate this fee dynamically across different resources (EVM gas, blob gas, calldata gas).
Achieving this will not be easy. The plan is to introduce a new transaction type with the following fields:
Clearly, this design is somewhat better, as I found the gas fee design of ERC-4337 to be overly complex.
For more details, see: From 4337 to 7702: In-depth Interpretation of the Past and Future of Ethereum Account Abstraction Track
How to evaluate it:
I believe this direction is sound and has significance for unified fees, making it much easier for future L2/L3 developments, aligning well with Ethereum's grand strategy for L2.
However, complexity will clearly increase, and engineering progress will require a steadier pace. This proposal will change the block header, RLP encoding, limits, etc. This is not just a hard fork-level change; it will also require adaptations across the entire chain and other platforms, especially many wallets.
Although they can choose not to support this transaction type, they will still need to parse the state of such transactions.
Therefore, it definitely won't be implemented in the short term, at least not until 1-2 major hard forks later. However, Vitalik's two articles on the fee market contain profound economic insights worth a close look.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
