Web3 Barometer: Interpreting Jito BAM, BRC2.0, EIP-7999

Author: Shisi Jun

Original link:

Statement: This article is a reprinted content, and readers can obtain more information through the original link. If the author has any objections to the form of reprint, please contact us, and we will make modifications according to the author's request. Reprinting is for information sharing only and does not constitute any investment advice, nor does it represent Wu's views and positions.

Jito BAM | "Block Ordering + Plugin-based Block Construction Market" on Solana

What is he:

In simple terms, BAM is a "block building" platform on Solana, similar to the goal of Ethereum's builder net to implement PBS (separating block builders from validators), aimed at organizing transaction order, combating MEV, and preventing the risks of centralized malfeasance.

By whom and what background was it launched:

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. The author has previously conducted detailed research for reference: A comprehensive report on the evolution of MEV on Solana and its pros and cons.

The lineup of participants is 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.

Such motivation is actually easy to understand: on one hand, Solana faces the explosive development pressure from Hyperliquid, a "native order book chain". The core value of Hyperliquid is very beneficial for market maker operations, but the developmental nature of Solana makes it difficult for it to make targeted optimizations in this regard. However, if the transactions in the entire block can be customized, it can break through the limitations of Solana's linear block production, thereby benefiting the optimization of various DeFi scenarios.

The official deployment plan is as follows: Initially, nodes will be operated by Jito Labs with a small number of validators participating; in the medium term, it will expand to more node operators, aiming to cover over 30% of the network staking; ultimately, the code will be open-sourced and governed in a decentralized manner.

In addition to the industry's narrative trend towards "verifiable fairness", the BAM direction easily gains support from validators and protocol parties. Therefore, the author believes that it is more based on the pursuit of fairness optimization concepts such as TEE + PBS that it is introduced as a background.

What principle is implemented:

Additionally, to understand its value, it is necessary to understand a characteristic of Solana's POH algorithm itself.

That is, his block production is actually gradually linear (there are 64 tip time periods in a slot of 400ms, and when each time period arrives, the current transaction is sent out, and it will not change anymore unless it is rolled back), which is different from Ethereum's model of "arranging the entire block, reaching consensus first, and then synchronizing."

By using this BAM suite system, as jito, it is actually easy to upgrade a large number of validators' clients, thereby increasing the proportion of the BAM system accepted by validators.

Looking at the system structure of BAM shown in the figure below, the middle purple section and the right side Plugin code section are BAM.

He will arrange the transaction order of "this entire block" in TEE (Trusted Execution Environment) first (according to some fixed sorting rules implemented by Plugin code), instead of sending them to the Leader one by one, and then hand them over to the validators all at once.

The validator must also ultimately provide a TEE proof, indicating that they have indeed allocated all the block's space (exclusivity) to this order flow market.

Here, the distinctive feature is the plugin functionality, which can "hard-code" the rules into Tee's order sorting for transactions. This actually has practical application significance:

For example: The oracle platform has a requirement to fix the price update as the first transaction in a block, which can reduce the randomness of price update transactions on the chain and avoid issues caused by delayed price updates. Another example is for DEX, where a plugin can be written to identify high-probability failed transactions and prevent them from being packed within the Tee, gradually waiting for the transactions to expire, thereby reducing the fees generated from failures.

He can coexist with the existing Solana block production process: still using the ordinary order flow, Jito bundle, and BAM three parallel systems. BAM means "only receiving a complete block of BAM in a certain block."

How to evaluate him:

The author believes: this is a path of "strong lineup, strong narrative, and focused scenes," but I am not optimistic about it becoming a mainstream market path.

The reasons for the slow progress of Builder net on Ethereum and the highly anticipated mev share are similar and have developed over many years.

Due to reality, the cost of TEE is high, and the QPS limit is only in the thousands (back in 2013, TEE only had 128M memory, and although it has developed a lot since then, it can still only achieve a QPS in the thousands). However, nowadays, 40% of the blocks on Ethereum are built using TEE.

However, the throughput of Solana's data and computation is there, and you need to stack a lot of TEEs to handle the load, along with full operational maintenance for disaster recovery, memory, and bandwidth. If this project doesn't have continuous economic incentives, it's very difficult to achieve positive returns.

In fact, Jito's earnings are not high (compared to high-yield protocols on-chain). For example, in the second quarter of 2025, Jito earned only 22,391.31 SOL (approximately 4 million USD) through tips. Once the massive transaction volume of Solana migrates over, Tee's downtime will inevitably follow, and Tee also has many characteristics such as memory crashes and storage clear-out, which will increase the risk of downtime and bring the risk of widespread transaction disappearance.

But it has the potential for "killer high-priced selling points": for example, oracle sequencing and failure-free payment, which are all "visible" experiential dividends. Market makers and enterprise-level trading platforms will pay for it. Moreover, Solana's official conceptual alignment also participates in it, making it a good way to generate buzz.

In the end: BAM itself is not positioned for 7x24 continuous throughput; it is a tool for "providing deterministic assurance for key blocks." However, many deterministic assurances rely on absolute certainty, rather than 30% certainty. In cases that are not 100% certain, even if it is 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 is he:

September 2, 2025, will be activated. I understand this as a "BTC-driven, EVM-executed" dual-chain shadow system. Note that it is not BRC20, but rather refers to the second generation of BRC. For background on BRC20, you can refer to: Interpretation of the Bitcoin Ordinals Protocol and the BRC20 Standard - Principles, Innovations, and Limitations.

The core of 2.0 is that you write "instructions" on BTC using inscription or commit-reveal, and run a "modified version of EVM" in the indexer to execute the corresponding deployment and calls. The EVM does not charge gas (the parameters are kept but not priced), and the transaction fees are counted on the BTC transaction.

Similar to the Alkanes protocol (methane), methane writes transaction instructions based on the op-return field of btc and runs on the WASM virtual machine, while it runs on the EVM.

By whom and what background was it launched:

The background of the initiator is: the bestinslot platform that became popular during the BTC inscription era continues the idea of BRC-20: without altering the BTC consensus, it aims to overlay "programmability" as much as possible.

The industry background is: In the past two years ((), the narrative of BTC programmability/L2 has been hot, and everyone has been looking for a feasible engineering path. However, the gap between the market's trends and the development progress has been too large, resulting in the emergence of arbitrary transformation models such as brc2.0 and alkanes only this year.

The market volume is somewhat limited because the stage for BTC has always been a non-aggregative force guiding it, and many protocols can be derived from other protocols. Therefore, BRC2.0 is very likely to have no actual relation to BRC20.

What principle is implemented:

He is in the indexer, not on the BTC chain and not on a separate chain, operating the logic of EVM. Note that it is not considered a chain because there is no consensus.

The address on the EVM that the user wants to control is obtained by hashing the user's own BTC address and then mapping it to a "virtual EVM address."

To operate this system is actually very similar to the logic of asset control in BRC20, it's just a json string. In brc2.0, it is defined as follows:

It can be seen that you are encoding instructions on BTC, with various bytecode/call data being uploaded, and it is replayed and executed in the EVM.

Moreover, the signature and Gas have also changed: set gasPrice=0 at the EVM layer, only for resource limits; the actual fee is reflected in the BTC transaction fee.

In fact, this is very risky. At that time, I specifically asked the AI to search through their node code and found that there was no protection for "call depth/step limit". So theoretically, a contract that allows for "infinite recursion/self-calling" could bring this VM down (of course, this protection is not difficult to implement: just set a maximum depth).

How to evaluate him:

Firstly, he does know how to name things. At least the volume of brc2.0 is better than creating a new protocol name, which is similar to how RGB has gained attention again recently.

Secondly, he is not completely unrelated to brc20, after all, his protocol design philosophy and field model are basically the same, but this doesn't count as copyright. However, I haven't seen the original author of brc20 endorse this, so the connection should not be significant.

In the end, all platforms exploring programmability may want to share the value of this world-class consensus. However, I believe that BTC should not pursue programmability, as any pursuit will inevitably lag behind the optimizations in functionality and experience offered by various high-speed chains.

Moreover, once programmability is built into BTC itself, it will break its valuation trap; a project that can be practically applied can be valued based on PE. However, the strength of BTC now lies in its limited supply and demand model, which cannot be valued; thus, there is a price, and with the price, there is consensus. Therefore, it is precisely the limitations of BTC itself that have contributed to its success.

EIP-7999 | Ethereum Multidimensional Fee Market Proposal

What is he:

The proposal led by Vitalik is definitely worth a look. Additionally, in the latest EIP, it has been renamed from EIP-0000 to EIP-7999, so this article will keep both names for now.

This is a new type of transaction proposed in the context of "transaction fee splitting" (i.e., the blob has its price, calldata has its price, and execution has the price of eip-1559) following EIP-4844, which consists of a "total price cap + multi-resource price vector."

You can understand it as: packaging all resource quotations in one go, making a unified semantic bid, with the aim of solving the problem of too many pricing dimensions on the chain.

By whom and what kind of background was it introduced:

The direction has been promoted by Vitalik through multiple articles. Previously, there was a paragraph with the EIP of '4 zeros' which was later renumbered to 7999; the name was not as impressive. This direction is also a reflection of Vitalik's thoughts expressed in multiple writings, where we can observe the evolution of his thinking from posts in 2022 to 2024.

Why bring it up now?

Because wallets, routers, and price auctioneers have clearly felt the fragmented experience of the "multi-price system": each block has only 6 blobs, so to use blob transactions, bidding is required; and the transactions themselves are still in eip-1559; there are also different unit prices for calldata, which has been around since 2015, based on 0/non-0 bytes... The L2 developers have been pushed to a corner because they must set independent fee ceilings for each resource dimension. If any dimension is set too low, it will cause the entire transaction to fail, even if the user's total fee budget is sufficient, a sudden increase in the base fee of a certain resource may prevent the transaction from being executed.

What principle is implemented:

The proposal plans to introduce a unified multi-dimensional fee market, with the core design allowing users to set a single max_fee parameter (replacing multiple max_fee_per_gas across different fields), while the EVM execution process will automatically allocate this fee dynamically across different resources (EVM gas, blob gas, calldata gas).

To achieve this, it is certainly not easy. His plan is to introduce a new type of transaction, with the following fields:

Clearly, this design is somewhat better, after all, the author found the Gas fee design of ERC-4337 to be quite complicated.

For details, see: From 4337 to 7702: An in-depth interpretation of the past and future of the Ethereum account abstraction track.

How to evaluate him:

The author believes that this direction is fine and has a unified fee significance, which will make it much easier when doing L2/L3 in the future, very much in line with the current L2 strategic direction of Ethereum.

But the complexity will obviously increase, and the engineering progress will also need a more steady pace. This proposal will lead to corresponding changes in block headers, RLP encoding, limits, etc. This is not just a hard fork level change; it will also trigger adaptations across the entire chain and other platforms, especially a bunch of wallets.

Although they may not support this type of transaction, they need to analyze the status of this transaction.

So 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 involve very profound economic considerations and are worth a close look.