Welcome to the "Web3 Barometer" series, a concentrated analysis and interpretation of recent new technologies, protocols, and products in the Web3 industry by Shijun.
The impetus for this series is that AI has doubled my usual research speed for new projects, and I believe that in the future, human value 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 any 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 platform for "block building" on Solana, similar to Ethereum's builder net aiming for PBS (separation of block builders and validators), both intended to organize transaction order, combat MEV, and prevent 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, holding 90% of the validator client market, with strong leadership influence. The author has previously conducted detailed research that can be referenced: A comprehensive report on the evolution of MEV on Solana.
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 official team and mainstream projects.
The motivation behind this is quite understandable: on one hand, 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. But 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 mid-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, the author believes it is more rooted in the pursuit of fairness optimizations like TEE + PBS.
How it works:
To understand its value, one must also grasp a characteristic of Solana's POH algorithm.
Its block production is actually a gradual linear process (a slot of 400ms has 64 tips time slots; when each time slot arrives, the current transaction is sent out, and unless rolled back, it does not change). This is different from Ethereum's model of "arranging the entire block, reaching consensus, then synchronizing."
Through the 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 system structure of BAM, 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, reducing the randomness of on-chain price update transactions and 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 in TEE, gradually waiting for the transactions to expire, thus reducing the fees incurred from failures.
It can coexist with the existing Solana block production process: still ordinary order flow, Jito bundle, and BAM running in parallel. BAM only accepts the entire block of BAM in a certain block.
How to evaluate it:
The author believes this is a path with "strong lineup, strong narrative, and focused scenarios," but I am not optimistic about it becoming a mainstream market path.
Similar to the reasons why Ethereum's Builder net and the highly anticipated MEV share have struggled to progress over the years.
The reality is that TEE costs are high, and the QPS limit is only in the thousands (back in 2013, TEE had only 128MB of memory, and while it has developed significantly since then, it can only handle QPS in the thousands). Although 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 massive transaction scale shifts to Solana, TEE outages will inevitably occur, and TEE has many characteristics such as memory outages and storage clearing, which will increase the risk of outages and lead to widespread transaction losses.
However, it has the potential for "killer high-priced selling points": for example, oracle sequencing and failure waivers are "visible" experiential benefits. Market makers and enterprise-level trading endpoints will pay for it. Moreover, Solana's official alignment in philosophy is a good way to gain visibility.
Finally, BAM's positioning is not to handle 7x24 throughput; it is a tool for "providing deterministic guarantees for key blocks." However, many deterministic guarantees rely on absolute certainty, not 30% certainty. Even at 99%, it is still 0%. This is the key to the final decision-making of major Web3 projects.
BRC 2.0 | "Mapping EVM": Programmable Capabilities Driven by BTC
What it is:
Set to activate on September 2, 2025, I understand this as a "BTC-driven, EVM-executing" dual-chain shadow system. Note that it is not BRC20, but refers to the second generation of BRC. For the background of BRC20, you can refer to: Interpretation of Bitcoin Ordinals Protocol and BRC20 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. Gas is not charged in the EVM (parameters are reserved but not priced), and transaction fees are counted 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 WASN virtual machine, while this runs on the 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 BRC-20 idea: maintaining BTC consensus while layering on "programmability."
The industry background is that in the past two years (actually the last two years), the narrative of BTC programmability/L2 has been hot, with everyone looking for a feasible engineering path. However, the gap between market trends and development progress has been too large, leading to the emergence of BRC2.0 and Alkanes 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, BRC2.0 is likely to have no actual relationship with BRC20.
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 EVM address controlled by users is hashed from the user's BTC address and mapped to a "virtual EVM address."
To operate this system, it is actually quite similar to the asset control logic of BRC20, which is just a JSON string. In BRC2.0, it is defined as follows:
You can see that you encode instructions on BTC, with various bytecode/call data attached, and it gets replayed and executed in the 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 is quite risky; I specifically had AI search through their node code and found no "call depth/step limit" protection. So theoretically, a contract with "infinite recursion/self-calling" could crash this VM (of course, this protection is not hard to add: just set a maximum depth).
How to evaluate it:
First, they know how to name things; at least the visibility of BRC2.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 BRC20, as its protocol design philosophy and field patterns are fundamentally similar, but this is not a copyright issue. However, I have not seen the original author of BRC20 endorse it, so the connection should not be significant.
Finally, all explorations of programmable platforms may want to share the value of this world-class consensus. However, the author believes that BTC should not pursue programmability because it will never catch up with the functional and experiential optimizations of 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 BTC's strength 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 have actually contributed to its strength.
EIP-7999 | Ethereum Multi-Dimensional Fee Market Proposal
What it is:
A 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 names.
This is a new transaction type proposed in the context of "transaction fee splitting" (i.e., a transaction where blobs have their price, calldata has its price, and execution has the price from EIP-1559) following EIP-4844.
You can understand it as: packaging all resource pricing into a single bid with unified semantics, aimed at solving 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 in the "4 zeros" EIP that was later renumbered to 7999, and the name is not as striking anymore. This direction has also been a recurring thought in Vitalik's writings, with reflections seen in posts from 2022 to 2024.
Why is it being proposed now?
Because wallets, routers, and auctioneers have clearly felt the fragmented experience of a "multi-price system": each block only has 6 blobs, so transactions using blobs need to bid; meanwhile, the transactions themselves are still under EIP-1559; and there has been calldata with different unit prices for 0/non-0 bytes since 2015… L2 developers have been pushed to a corner because they must set independent fee limits for each resource dimension. Any dimension set too low can lead to the failure of the entire transaction, even if the user's total fee budget is sufficient, a sudden increase in the base fee of a particular resource can prevent the transaction from being executed.
How it works:
The proposal plans to introduce a unified multi-dimensional fee market, with the core design allowing users to set a single maxfee parameter (replacing multiple maxfeepergas on different fields), while the EVM execution process will automatically dynamically allocate this fee across different resources (EVM gas, blob gas, calldata gas).
Achieving this is certainly not easy; the plan is to introduce a new transaction type with the following fields:
Clearly, this design is somewhat better, as the author has found the gas fee design of ERC-4337 to be overly complex.
For more details, see: From 4337 to 7702: An In-depth Interpretation of the Past and Future of Ethereum Account Abstraction Track.
How to evaluate it:
The author believes this direction is sound and has unified fee significance, making it much easier for future L2/L3 developments, aligning well with the current strategic direction of Ethereum's L2 battle.
However, complexity will significantly increase, and engineering progress will require a steadier pace. This proposal will change the block header, RLP encoding, limits, etc., which is not just a hard fork-level change but will also require adaptations across the entire chain, especially for many wallets.
While they can choose not to support this transaction type, they will need to parse the state of such transactions.
Therefore, it will definitely not be implemented in the short term; it is likely to happen only after 1-2 major hard forks. However, Vitalik's two articles on the fee market contain profound economic insights worth a close look.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
