Web3 Wind Indicator Issue 1: Interpretation of Jito BAM, BRC 2.0, EIP-7999

Welcome to the "Web3 Indicator" series, a concentrated analysis and interpretation by Shisi Jun on the latest technologies, protocols, and products in the Web3 industry.

The reason is that AI has doubled my speed in researching 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 the core changes from three perspectives: industry background → technical principles → potential impacts, and assess the trends they may trigger in the shortest time possible.

The author's views are mostly colored by pessimism, and do not constitute any investment trading, nor are they directed at any specific project parties.

Jito BAM | "Block Sorting + Plugin-based Block Building Market" on Solana

What is he:

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

Who and what background was introduced:

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 merits and demerits.

The lineup of participants is also very strong, including Triton One, SOL Strategies, Figment, Helius, Drift, Pyth, DFlow, etc. Obviously, this is a joint action by Solana's officials and mainstream projects.

Such motivation is actually easy to understand: on one hand, Solana faces the pressure of explosive development from Hyperliquid, a "native order book chain." The core value of Hyperliquid is very beneficial for market maker operations. However, the nature of Solana's development makes it difficult to make targeted optimizations. But if the transactions within the entire block can be customized, it can break through the limitations of Solana's linear block generation, 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 mid-term, it will expand to more node operators, aiming to cover 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, and is launched against this background.

What principle is achieved:

Additionally, to understand its value, one must also understand a characteristic of Solana's POH algorithm itself.

In other words, his block production is actually a gradual linear process (there are 64 tips time slots within a slot of 400ms, and when each time slot arrives, the current transaction is sent out, and it will not be changed unless rolled back), which is different from Ethereum's model of "organizing the entire block first, reaching consensus, and then synchronizing."

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

Looking again at the system structure of BAM as shown in the figure below, the purple part in the middle and the Plugin code part on the right are BAM.

He will arrange the transaction order of "this entire block" in the TEE (Trusted Execution Environment) first (combining some fixed sorting rules implemented by Plugin code), instead of sending transactions to the Leader one by one, and then submit it to the validator all at once.

The validator must also ultimately provide a TEE proof, indicating that he has indeed allocated the block space (exclusivity) to this order flow market.

Here, what stands out is the plugin feature, which can "embed" the rules into Tee's trading order sorting. This has significant practical application meaning:

For example: The oracle platform needs to fix the price update as the first transaction in a block, which can reduce the randomness of updating on-chain prices and thus avoid issues caused by untimely price updates. Another example is for DEX, where a plugin can be written to identify transactions with a high probability of failure and not package them directly in the Tee, then gradually wait for the transactions to expire, thereby reducing the fees incurred from failures.

His system can coexist with the existing Solana block production process: it still involves ordinary order flow, Jito bundle, and BAM operating in parallel. 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 development difficulties of Builder net on Ethereum and the highly anticipated mev share are similar and have been ongoing for many years.

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

However, the throughput of Solana's data and computation is there, and you have to stack a lot of TEE to handle the volume, along with disaster recovery, memory, and a full set of operations. If this project does not have continuous economic incentives, it will be very difficult to achieve positive returns.

In fact, the earnings of Jito are not high (compared to high-yield protocols on-chain). For example, in the second quarter of 2025, Jito only earned 22,391.31 SOL (approximately 4 million USD) through tips. Once Solana's massive transaction volume migrates over, Tee's downtime is inevitable, and Tee also has many characteristics such as memory crashes and storage clearing, which will increase the risk of downtime and lead to 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, both are "visible" experiential dividends. Market makers and enterprise-level trading platforms will pay for it. Moreover, the participation also aligns with Solana's official philosophy, making it a good way to gain visibility.

Finally: The positioning of BAM itself is not to handle the volume of 7x24 around the clock; it is a tool for providing deterministic assurance for key blocks. However, much of this deterministic assurance relies on absolute certainty rather than 30% certainty. In situations that are not 100% certain, even if it's 99%, it is still 0%. This is the key to the 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 Bitcoin Oridinals protocol and BRC20 standard, principle innovation and limitations.

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

Basically similar to the Alkanes protocol (methane), methane is based on btc's op-return field writing transaction instructions, running on the WASN virtual machine, while it runs on the EVM.

Who and what background was introduced:

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

The industry background is: In the past two years, (, the narrative of BTC programmable/L2 has ignited, and everyone has been searching for a viable engineering path. However, the gap between the market's trends and the development progress has been too large, resulting in the emergence of models like brc2.0 and alkanes only this year.

The market volume is somewhat limited, as the stage for BTC has always lacked a cohesive force to guide it, and many protocols can be derived from other protocols. Therefore, BRC 2.0 is very likely to have no actual relationship with BRC 20.

What principle is achieved:

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

The address on the EVM that the user needs 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, the logic is actually very similar to that of BRC20 for asset control; 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, carrying various bytecodes/call data, which are replayed and executed in the EVM.

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

In fact, this is very risky. At that time, I specifically had the AI search through their node code and found that there was no protection for "call depth/step limit". 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 him:

First of all, he still understands how to name things. At least, the buzz around brc2.0 will be better than creating a new protocol term, just like how RGB has been making noise again recently.

Secondly, he is not completely unrelated to BRC20, after all, his protocol design concept and field pattern are basically the same. However, this is not really a matter of copyright. However, I haven't seen the original author of BRC20 endorse it, so the connection should not be significant.

In the end, any platform that explores programmability may want to share the value of this world-class consensus. However, I believe that BTC should not pursue programmability because it will inevitably lag behind various high-speed chains in terms of functionality and user experience.

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, but the current strength of BTC lies in its limited supply and demand model. Limited supply and demand cannot be valued, so there is a price, and with the price comes 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 transaction type 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 the resource quotes at once, bidding with a unified semantics, with the aim of solving the problem of too many pricing dimensions on the chain.

Who and what background was introduced:

The direction has been driven by Vitalik's numerous articles. Previously, there was a paragraph about the EIP with "4 zeros" which later got renumbered to 7999; the name is not so stunning anymore. This direction is also a reflection of Vitalik's thoughts expressed in several articles, where we can see the evolution of his thinking from posts in 2022 to 2024.

Why bring it up now?

Due to the wallet, router, and price auctioneer, the fragmentation experience of the "multi-price system" has become evident: each block only has 6 blobs, so transactions that use blobs need to bid; and the transactions themselves are still in eip-1559; there are also different unit prices for calldata starting from 2015, with 0/non-0 bytes... The L2 developers have already been pushed to the wall, as they must set independent fee caps for each resource dimension. If any one dimension is set too low, it will lead to the failure of the entire transaction, even if the user's total fee budget is sufficient, the transaction may still fail due to a sudden increase in the base fee of a certain resource.

What principle is achieved:

The proposal plans to introduce a unified multidimensional fee market, with the core design allowing users to set a single max_fee parameter (replacing multiple max_fee_per_gas on different fields), while the EVM execution process will automatically dynamically allocate this fee 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, and its fields are as follows:

Obviously, this design is still better, after all, the author has seen the Gas fee design of ERC-4337, which is too complex to follow.

For details, see: From 4337 to 7702: An In-depth Analysis of the Past and Future of Ethereum Account Abstraction Track

How to evaluate him:

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

But the complexity will significantly increase, and the progress of the project also requires a more stable pace. This proposal will bring changes to the block header, RLP encoding, limit, and so on. This is not just a hard fork-level change; it will also require adaptations from other platforms across the entire chain, especially for a bunch of wallets.

Although they may not support this type of transaction, they need to interpret 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 are very profound economic reflections and are worth a closer look.