Web3 Trends Issue 1: Interpreting Jito BAM, BRC2.0, and EIP-7999

Welcome to the "Web3 Trends" series, where Shisijun provides a concentrated analysis and interpretation of recent new technologies, protocols, and products in the Web3 industry.

The reason is that AI has doubled the speed at which I can research new projects. I think that in the future, people's value will be more focused on thinking, judgment, and inspiration.

Therefore, this series will help you grasp the core changes in the shortest time and judge the trends they may trigger from three perspectives: industry background → technical principles → potential impact.

Most of the author's views are pessimistic, and are not intended as any investment transaction, nor are they directed at any project party.

Jito BAM｜Block Ordering + Plug-in Block Building Market on Solana

What is it:

Simply put, BAM is a "block building" platform on Solana. Similar to the goal of Ethereum Builder Net to do PBS (block builder and validator separation), both are aimed at more orderly transaction order, fighting MEV, and preventing the risk of centralized maliciousness.

Who launched it and what kind of background:

The leading party is the Jito camp, the largest trading auction platform on Solana, which occupies 90% of the validator client market and has a strong leadership influence. The author has previously conducted detailed research, which can be referred to as: 10,000-word research report: The evolution of the MEV landscape 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. Obviously, this is a joint action of Solana official and mainstream projects.

This motivation is easy to understand: Solana faces the pressure of the explosive growth of "native order book chains" like Hyperliquid, whose core value lies in its ability to facilitate market maker operations. However, Solana's inherent developmental nature makes it difficult to optimize this in a targeted manner. However, if the transactions within the entire block can be customized, then the limitations of Solana's linear block generation can be overcome, thereby facilitating the optimization of various DeFi scenarios.

The official deployment plan is: in the initial stage, Jito Labs will run the nodes, with a small number of validators participating; in the medium term, it will be expanded to more node operators, with the goal of covering 30%+ of network staking; and finally the code will be open source and decentralized governance.

Coupled with the industry's narrative trend of "verifiable fairness", BAM's direction can easily gain support from validators and protocol parties. Therefore, the author believes that it is more based on the concept of pursuing fairness optimization such as TEE + PBS and was launched in the background.

How the principle is implemented:

In addition, to understand its value, you also need to understand a feature of Solana's own POH algorithm.

That is, its block generation is actually gradual and linear (a slot has 64 tip time periods under 400ms. When each time period expires, the current transaction is sent out and will not be changed unless rolled back). This is different from Ethereum's "arrange the entire block, reach consensus first, and then synchronize" model.

Through this BAM system, jito can easily upgrade the clients of a large number of validators, thereby increasing the proportion of BAM system accepted by validators.

Let’s look at the BAM system structure as shown below. The purple part in the middle and the Plugin code on the right are BAM.

He will make sure that the transactions on Solana are not pushed to the Leader one by one, but the transaction order of "this entire block" will be sorted in the TEE (Trusted Computing Environment) first (combined with some fixed sorting rules implemented by the Plugin code), and then handed over to the validator at one time.

The validator must ultimately provide TEE proof that he has indeed given the block space (exclusivity) to this order flow market.

The most unique feature here is the plug-in function, which can "hard-code" rules into the Tee transaction order sorting. This actually has practical application significance:

For example, oracle platforms require price updates to be scheduled as the first transaction in a block. This reduces the randomness of transactions updating on-chain prices and avoids issues caused by untimely price updates. For another example, for Dex, a plugin could be written to identify transactions with a high probability of failure and simply not include them in the Tee, allowing them to gradually expire, thereby reducing fees associated with failed transactions.

It can coexist with the existing Solana block production system: the normal order flow, Jito bundle, and BAM are still three parallel systems. BAM means "only BAM blocks are accepted in a block."

How to evaluate him:

The author believes that this is a path with "strong lineup, strong narrative, and focused scenes", but I am not optimistic that it will become the mainstream market path.

The reasons are similar to those of Builder Net on Ethereum and the highly sought-after MEV Share, which have been struggling to make progress over the years.

Because of the reality, TEE is expensive and its QPS limit is only in the thousands (in 2013, Tee only had 128M of memory, and now it has developed a lot, but it can only reach the thousands of QPS), although 40% of the blocks on Ethereum are now built by TEE.

However, Solana's data and computing throughput is high, and you'd need to deploy numerous TEEs to handle it, along with comprehensive operations and maintenance for disaster recovery, memory, and bandwidth. Without sustained economic incentives, it's difficult to generate positive returns.

Jito's returns are actually quite low (compared to high-yield protocols on the blockchain). For example, in the second quarter of 2025 alone, Jito earned only 22,391.31 SOL (approximately $4 million) through tips. Once Solana's massive transaction volume is migrated there, Tee downtime is inevitable. Furthermore, Tee's numerous features, such as memory failures and storage purging, increase the risk of downtime and the potential for widespread transaction loss.

However, it has the potential for killer selling points: oracle sequencing and no-failure payments, for example, offer tangible user benefits. Market makers and enterprise-level trading platforms will buy into it. Furthermore, participating in it also benefits from Solana's official support, making it a great way to gain recognition.

Finally: BAM itself is not positioned to provide 24/7 throughput. It is a tool to "provide deterministic guarantees for key blocks." However, many deterministic guarantees rely on absolute certainty, not 30% certainty. If it is not 100%, 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 Powered by BTC

What is it:

It will be activated on September 2, 2025. I understand this to be a dual-chain shadow system driven by BTC and executed by EVM. Note that it does not refer to BRC20, but to the second generation of BRC. For more information on BRC20, please refer to: Interpreting the Bitcoin Ordinals Protocol and the Innovation and Limitations of the BRC20 Standard Principles.

The core of 2.0 is that you write "instructions" on Bitcoin using inscription or commit-reveal, and a modified EVM runs in the indexer to execute the corresponding deployment and calls. The EVM does not charge gas (the parameters are retained but not calculated), and the transaction fee is added to the Bitcoin transaction.

It is basically similar to the Alkanes protocol (Methane). Methane writes transaction instructions based on the op-return field of Bitcoin and runs in the WASN virtual machine, while it runs in the EVM.

Who launched it and what kind of background:

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

The industry background is: in the past two years (actually the past two years), the narrative of BTC programmability/L2 has been popular, and everyone is looking for an engineering path that can run smoothly. However, the gap between market trends and development progress is too large, resulting in the emergence of arbitrary models such as BRC2.0 and Alkanes only this year.

The market voice is somewhat limited because the BTC stage has never had a cohesive force to guide it, and many protocols can be derived from other protocols, so in fact, BRC2.0 is likely to have no actual relationship with BRC20.

How the principle is implemented:

It is in the indexer, not on the BTC chain nor a separate chain, to operate the EVM logic. 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 into a "virtual EVM address".

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

It can be seen that you encode instructions on BTC, with various bytecodes/call data, and it is replayed and executed in the EVM.

In addition, the signature and gas prices have also been changed: the EVM layer gasPrice is set to 0, which only serves as a resource limit; the actual handling fee is reflected in the BTC transaction fee.

This is actually quite risky. I had my AI search their node code and found no protection against "call depth/step limit." So, theoretically, a contract with infinite recursion/self-calling could potentially bring down the VM. (Of course, this protection is easy to fix: simply set a maximum call depth.)

How to evaluate him:

First of all, he still knows how to name things. At least brc2.0 will be more popular than creating a new protocol name. This is also the reason why RGB has become popular again recently.

Secondly, it is not completely unrelated to BRC20. After all, its protocol design concept and field mode are basically the same, but this does not count as copyright. However, I have not seen the original author of BRC20 on the platform, so the connection is probably not significant.

Finally, all platforms that have explored programmability may want to share the value of this world-class consensus. However, the author believes that BTC should not pursue programmability, because no matter how it pursues it, it will not be able to keep up with the optimization of functions and experience of various high-speed chains.

Moreover, once programmability is built into BTC itself, it will break its valuation trap. A project that can be put into practical use can be valued based on PE. However, 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 then there is a consensus on the price. Therefore, it is precisely the limitations of BTC itself that have made BTC successful.

EIP-7999 | Ethereum Multidimensional Fee Market Proposal

What is it:

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

This is a new transaction type with a "total price cap + multiple resource price vectors" proposed in response to the "transaction fee split" caused by EIP-4844 (that is, in a transaction, the blob has its own price, the calldata has its own price, and the execution has the price of EIP-1559).

You can think of it as: packaging all resource quotations at once and bidding with unified semantics, with the goal of solving the problem of too many pricing dimensions on the chain.

Who launched it and what kind of background:

This direction was driven by Vitalik's numerous articles. Previously, the EIP with "four zeros" was later numbered in the 7999 section, making the name less impressive. This direction also reflects Vitalik's thoughts on this topic in numerous posts, and his shifting thinking can be seen in posts from 2022 and 2024.

Why bring it up now?

Wallets, routers, and bidders have already clearly experienced the fragmented experience of the "multi-price system": each block has only 6 blobs, so transactions using blobs require bidding; the transactions themselves are still in EIP-1559; and calldata, which has been around since 2015, has different unit prices for 0 and non-zero bytes... L2 developers have been forced into a corner because they must set independent fee caps for each resource dimension. Setting any dimension too low will cause the entire transaction to fail. Even if the user's total fee budget is sufficient, the transaction may not be executed due to a sudden increase in the base fee of a certain resource.

How the principle is implemented:

The proposal plans to introduce a unified multi-dimensional fee market. The core design is to allow users to set a single max_fee parameter (instead of multiple max_fee_per_gas on different fields), and the EVM execution process will automatically and dynamically allocate this fee among different resources (EVM gas, blob gas, calldata gas).

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

Obviously, this design is better. After all, after seeing the gas fee design of ERC-4337, I found it too complicated to match.

For more details, see: From 4337 to 7702: An In-Depth Look at the Past and Future of Ethereum Account Abstraction

How to evaluate him:

The author believes that there is nothing wrong with this direction, and it has the significance of unifying fees. It will make it much easier to do L2/L3 in the future, and it is very consistent with the current L2 strategic direction of Ethereum.

However, the complexity will increase significantly, and the project will need to proceed at a more stable pace. This is because this proposal will change block headers, RLP encoding, limits, and more. This is not just a hard fork-level change, but will also require adaptation of other platforms throughout the chain, especially a large number of wallets.

Although they may not support this transaction type, they must parse the status of this transaction.

Therefore, it will definitely not be implemented in the short term, and it will only be possible after at least 1-2 major hard forks. However, Vitalik’s two articles on the fee market are very profound economic thinking and are worth reading carefully.