Paradigm invented a new mechanism, MEV tax, which may change the existing DeFi landscape

This article is from Priority Is All You Need

Original author: Dan Robinson, Dave White

編譯：奧德人工智慧ly Planet Daily Husband

Paradigm published the article Priority Is All You Need on June 4, which introduced the new mechanism MEV tax in detail.

The MEV tax is a novel mechanism that allows applications to capture the MEV they generate themselves, rather than leaking it to block proposers (see the footnote at the end of the article for more information about block proposers). This mechanism takes advantage of competitive priority sorting during block construction. In this sorting method, transactions are sorted in descending order of priority fees, and transactions with higher priority are packaged in blocks first. The MEV tax is implemented by adding an additional fee to the priority fee of a transaction. Applications can set their own fees based on the priority fee of a transaction, thereby capturing most or even all of the MEV. This means that applications can run their own custom MEV auctions by participating in a single shared auction run by block proposers without the need for any off-chain infrastructure.

The birth of the MEV tax mechanism may have an impact on the existing DeFi ecosystem:

• Changing the way traditional MEV is distributed: Traditionally, most of the MEV flows to block proposers, and the MEV tax allows applications to capture this value and redistribute it to their users or use it for other purposes.

• Improved application revenue and user experience: Applications can increase their revenue by implementing MEV taxes while providing a better user experience as users can get higher transaction execution efficiency and better transaction prices.

• Solve some problems in DeFi: M such as optimizing DEX routing, reducing AMM losses to arbitrage, reducing MEV leakage of wallet users, etc. By introducing MEV tax, applications can improve their products and services, thereby improving the efficiency and sustainability of the DeFi ecosystem.

Citations

In this paper, we introduced the MEV tax, a mechanism that allows any application to capture its own MEV (Maximum Extractable Value).

This mechanism can be used immediately on OP Stack L2 chains such as OP Mainnet, Base, and Blast, because block proposers on these chains follow a set of rules we call contention prioritization.

To implement a MEV tax on these chains, a smart contract charges a fee based on the priority fee of a transaction. We show that if an application charges a $99 MEV tax for every $1 of priority fee paid by a searcher, it can capture 99% of the competing MEV for that transaction.

The MEV tax is a simple technique that opens up a vast design space. You can think of it as allowing any application on the chain to run its own custom MEV auction without requiring any off-chain infrastructure of its own, simply connecting to a shared auction run by block proposers.

We show how the MEV tax can be used to address three main questions in MEV research:

A decentralized exchange (DEX) router that optimizes the prices received by exchangers

Automated Market Maker (AMM) that minimizes liquidity provider losses (LVR) due to rebalancing

A wallet that lets users capture any “fallback” MEV generated by their transactions

But there’s a catch. The MEV tax only works if block proposers strictly follow competitive prioritization rules, including ordering transactions by priority fee without censorship, snooping, or delays. If block proposers deviate from these rules, they can circumvent the MEV tax to capture value. As a result, today’s MEV tax relies on trusting the L2 sequencer, and may not work at all on Ethereum L1, where block construction on the Ethereum mainnet is dominated by competitive builder auctions that maximize proposer revenue.

Nonetheless, the power and flexibility of the MEV tax suggests that prioritization may be the right choice for platforms that currently offer it. And the relative simplicity of competitive prioritization suggests that there may be a viable way to enforce it in a decentralized manner without trusting a single sequencer. We hope this post inspires further research into this problem.

Priority ordering

When someone sends a transaction on Ethereum mainnet or L2, they specify a priority fee that is paid to the block proposer. You can imagine this is specified via priorityFeePerGas, which is a number that is multiplied by the gas used in the transaction to get builderPriorityFee, the total payment amount in ETH.

There is no requirement in the Ethereum protocol that transactions in a block must be greedily sorted in descending priorityFeePerGas order. However, this is a popular way to build blocks. For example, this is the default algorithm used by the sequencer of the OP Stack chain and geth and reth. Priority sorting not only allows transactors to effectively express the urgency of their transactions, but also naturally directs certain types of MEV to block proposers.

This happens because priority sorting turns the competition for MEV into a priority gas auction. When there is an opportunity to profit from interacting with a chain, such as by arbitrage between an AMM and a centralized exchange, searchers compete to seize this opportunity first. If the chain uses priority sorting to determine the packaging and ordering of transactions, searchers will compete by setting high priority fees in their transactions.

In a competitive scenario where risk-free profits are squeezed to zero by competition, the winning searcher should eventually pay the full amount of MEV as a priority fee. So if there is a profit of 100 ETH to be gained by interacting with the contract, the first transaction to seize the opportunity will set a priority fee of 100 ETH. (We discuss some caveats to this in the Limitations section).

MEV Tax

Suppose a smart contract wants to capture the MEV of any transaction it interacts with. There is a large research literature on various application-specific ways in which smart contracts try to capture their own MEV.

But in reality, we don’t necessarily need to know anything specific about the application. If we know that blocks are built via competitive prioritization, then we have a unified signal for the amount of MEV in a transaction: the priority fee.

We propose that smart contracts can look at the priority fee of a transaction and charge their own fee based on it, which is an increasing function of the priority fee. For example, a contract might require the person who calls it to transfer applicationPriorityFee = 99 * proposerPriorityFee ETH to the contract.

This new fee is paid by the searcher sending the transaction, so it affects the behavior of that searcher. If there is 100 ETH of MEV in an opportunity, the winning transaction will now only set a priority fee of 1 ETH, because this will result in a total payment of 100 ETH (1 ETH to the block proposer, 99 ETH to the smart contract). Any higher priority fee will make the transaction unprofitable; any lower priority fee will cause the opportunity to be snatched away by a competitor who sets a higher fee. This means that the smart contract captures 99% of the MEV in the transaction.

We call this additional fee imposed by smart contracts the MEV tax. The MEV tax lets applications hijack prioritization for their own benefit, allowing them to recapture MEV for their users rather than letting it leak to block proposers.

If this fee grows fast enough as a function of priorityFeePerGas , then only negligible MEV will accrue to the proposer. Since priorityFeePerGas is denominated in wei (one hundred millionth of an ETH), we have a lot of precision to exploit. For example, as long as the sensitivity of the MEV tax is high enough that a priorityFeePerGas of 50,000 results in a prohibitively high tax, then the total amount paid to the proposer will be less than $0.01 .

However, there is an important caveat. As discussed in the “Limitations” section, the MEV tax only works if block proposers follow certain rules (which we call “competitive prioritization”) and do not deviate from those rules to maximize their own revenue. Enforcing these rules in a trustless manner is an open problem.

MEV capture for a single application

On a chain that guarantees blocks are built using competitive prioritization, the MEV tax can be used to alleviate three important issues with MEV: allowing DEX interfaces to improve trade execution for exchangers; allowing AMMs to reduce arbitrage losses for their LPs; and allowing wallets to reduce users’ MEV leakage by selling the right to run back to users.

DEX router searcher

In intent-based DEX routing protocols such as UniswapX and 1inch Fusion, a user (Alice) signs an exchange intent and searchers compete to route or fill the intent at the best price.

The current version of UniswapX uses two mechanisms to run this competition: a Dutch auction, where Alice’s limit price changes over time until it is filled by the searcher, and an initial off-chain request for quote (RFQ) auction to set the starting price of this Dutch auction.

On platforms that guarantee competitive prioritization, UniswapX can replace these with a mechanism: the MEV tax. It can be implemented by having users sign an order that can be filled immediately by anyone, but the execution price is a function of the transaction priority fee.

For example, if Alice has a UniswapX order to sell 1 ETH, she can define the execution price of the order to be minimumPrice + ($ 0.01 * priorityFeePerGas). minimumPrice can be a fixed value that she expects to be significantly lower than the current price.

Searchers will compete to fill Alices order by submitting transactions. Any transaction with the highest priority fee that does not fall back will fill the order, which should guarantee that the trader gets the best price the searcher can find. (Some exceptions to this are discussed in the Limitations section.)

If Alices minimum price is $3,000, and the current ETH price is $3,500, the priorityFeePerGas in the winning transaction is approximately 50,000. (Note that in a transaction costing 200,000 gas, this would result in only about 10 billion wei (about $0.000035) being paid to the block proposer.)

This has some potential advantages over the existing mechanism used in UniswapX.

Orders using the MEV tax can be completed faster and at better prices than orders using Dutch auctions. As described in the article, on-chain Dutch auctions leak some value to MEV due to price changes between blocks, and may take multiple blocks to complete. In contrast, orders using the MEV tax can often be completed in the next block while capturing the vast majority of their MEV.

Unlike off-chain RFQs, auctions that fill orders using MEV taxes will happen atomically when on-chain transactions are executed. This means that the winning bidder can guarantee that the order will only be filled if its on-chain transaction succeeds. This can make on-chain liquidity (such as AMMs) more easily competitive with off-chain liquidity, which means UniswapX can serve as a more efficient router for multi-pool subsystems (such as Uniswap v4).

Automated Market Maker (AMM)

Typically, AMMs leak value due to arbitrageurs trading at stale prices at the top of blocks, as discussed in the loss-vs-rebalancing paper. We can use a MEV tax to allow AMMs to capture these MEVs. For simplicity, we will discuss how to do this on an AMM without centralized liquidity. (If you are interested in how to solve this problem when there is centralized liquidity, Sorella will release a solution soon.)

AMMs can capture MEV by charging an additional fee based on the priority fee of a transaction, allowing it to auction off the right to prioritize transactions in a block. There are many ways to calculate and denominate this fee. We will discuss an arguably neutral method – expressing it in units of pool liquidity sqrt(xy). The winning transactions will be those that increase the pools liquidity the most.

When the first transaction is executed on the pool in a block, the pool can enforce the condition x_end * y_end > x_start * y_start (as some constant for a ):

x_end * y_end > (sqrt(x_start * y_start) + a*priorityFeePerGas)^ 2 This formula will incentivize arbitrage traders to trade to the true price, after which the midpoint price of the pool should be the true price.

After that first trade, trading can work just like in Uniswap v2, using a fixed swap fee. Uninformed traders who wish to trade without paying the additional MEV tax will set a lower preferred fee.

There are many other ways to implement a MEV tax on an AMM, with different effects. For example, the MEV tax could be expressed in input or output tokens of an exchange, could affect the percentage of exchange fees applied by a pool, or could determine the minimum price at which users can trade. We think this is an interesting design space worth exploring.

Backrunning auctions

The above description shows how certain applications can be designed to avoid leaking MEV. But what if a wallet wants to help its users capture the MEV they generate when interacting with any application through any transaction, even if those applications do not include a MEV tax?

For example, when Alice makes a large trade on an AMM, she sometimes creates an arbitrage opportunity for “backrunners” to bring the price back to normal. Often, these opportunities leak to the MEV, rather than to Alice.

MEV-Share 和 MEVBlocker are two protocols that allow users to capture MEV from their transactions, but they rely on complex off-chain auction systems. The Orderflow Auction Design Space describes some other solutions.

When the MEV tax is combined with an intent-based smart contract wallet, we can build an alternative system to capture Alices trailing MEV. Suppose Alice did not create a transaction to trade on the AMM, but instead signed an intent that anyone can submit to Alices smart contract wallet to have it perform that action. Alices smart contract wallet charges a MEV tax to the person who submitted that transaction, which is paid to Alice.

The searcher that submitted Alices intent has the exclusive right to follow her, since they can do so atomically in the same transaction. Therefore, if search competition is high, all profits from following Alice should go to Alice through her MEV tax.

It is important to note that this system may not fully protect users from front-running attacks, as front-runners may be able to avoid paying the MEV tax to users. This issue (and some of its possible mitigations) is discussed in detail in the Limitations section below. However, it is at least an improvement over a public mempool system without any mitigations.

Other Use Cases

In addition to these examples, other potential uses of the MEV tax include almost all scenarios that currently use off-chain or Dutch auctions, such as:

• Protocols like Oval work by capturing the oracle extractable value (OEV) they create.

• Refinancing auctions in NFT-collateralized lending protocols like Blend.

• Lending protocol liquidations leak less value than Dutch auctions.

Cross-application MEV capture

The above solutions are designed to capture MEV generated when interacting with a single application. However, sometimes a searcher can capture more value by interacting with multiple applications in the same transaction.

If only one of these applications uses a MEV tax, then all MEV from transactions should be attributed to the application using the MEV tax, regardless of how high or low that MEV tax is.

But what if the searcher’s transactions interact with two applications that use MEV tax? For example, if some MEV can only be captured by filling a MEV taxed UniswapX order against a MEV taxed AMM?

In this case, the relative amount of excess MEV captured by each application is determined by the MEV tax set by those applications. If the value of app_i as the MEV tax is given by the function tax_i(priority), the priority of the winning transaction can be determined by solving the priority in the following equation: tax_1(priorityPerGas) + tax_2(priorityPerGas) = total MEV

(Technically, we could add a third term priorityPerGas * gasUsed to account for the priority fee paid to the block proposer, but we will ignore this since, as discussed in Appendix A, priority fees are likely to be negligible under normal circumstances.)

In the simple case of a MEV tax that is linear in priorityPerGas (so tax_ 1(priorityPerGas) = a_ 1 * priorityPerGas ), you can solve for the share of MEV each application receives:

a_1 * priorityPerGas + a_2 * priorityPerGas = MEV

priorityPerGas = MEV/(a_ 1 + a_ 2)

tax_1(priorityPerGas) =(a_1/(a_1+a_2))*MEV

tax_2(priorityPerGas) = (a_2/(a_1+a_2))*MEV

An application faces a tradeoff when setting its own MEV tax – a higher tax rate allows it to capture a larger share of cross-application MEV when it occurs, but it means it may miss out on some cross-application MEV if there are competing extraction methods. For example, if there is an AMM that charges a MEV tax on every trade, then a MEV-taxed UniswapX order book may be filled by a different AMM or off-chain filler.

In many cases, there may be an equilibrium where two applications design their MEV taxes to share MEV in a way that maximizes their respective welfare. For example, a MEV-taxing AMM may want to capture value from a single informed trader near the top of a block, but then want to provide liquidity to other traders and applications (including those using the MEV tax) at a lower fixed fee. In this case, the AMM might set a relatively low MEV tax (e.g., $0.00001 * priorityFeePerGas ) so that arbitrage trades (if any) occur early in the block, and then charge no MEV tax for subsequent trades in the block. Applications like UniswapX that want to interact with the AMM could set a higher MEV tax (like $0.01 * priorityFeePerGas ) to ensure that their trades are included after the pool has already arbitraged. With these relative taxes, the AMM will eventually be arbitraged first even if there is only $1 of MEV and $50,000 of MEV in the UniswapX order book.

We believe this is a broad design space worthy of future research.

limitation

There are several complexities and flaws with the MEV tax. We think these are interesting areas for future research.

Incentive Incompatibility

MEV taxes are incentive-incompatible for monopolistic block proposers. They only work if there is fair competition for transaction inclusion, which only happens if block proposers follow rules we call “competitive prioritization” instead of maximizing their own revenue. We recommend that these rules include:

• Priority sorting: Transactions in a block must be sorted in descending order of priorityFeePerGas.

• Censorship resistance: If the block proposer receives transaction t 1 when building a block, and the block is not full or contains transaction t 2 , and t 2.priorityFeePerGas

• Pre-transaction privacy: Block proposers must accept transactions through a private endpoint and may not share these transactions with anyone before submitting a block, nor may they use the contents of these transactions to construct their own transactions.

• There is no finality. Block proposers must set a definite time (blockTime) before which they accept transactions from anyone and after which they do not accept transactions from anyone.

If one or more of these properties are violated, it could weaken the effectiveness of the MEV tax. A block proposer that violates censorship resistance could take advantage of the opportunity by excluding competing transactions and submitting a zero-priority transaction to avoid most MEV taxes. A block proposer that violates pre-transaction privacy could steal MEV from other transactions, or peek at their priority fees to know how high they need to set to outbid others, while a proposer who is able to submit a transaction later than others is free to finalize whether to outbid others, causing an adverse selection problem that ultimately inhibits competition.

Unfortunately, while the first property is easy to enforce at the protocol layer, enforcing the others in a trustless manner is an open problem.

In the absence of enforcement at the protocol level, a sequencer committed to these rules needs to be trusted not to deviate from them, and blocks may not follow them if proposers outsource block construction to competitive revenue-maximizing auctions (such as MEV-Boost on the Ethereum mainnet).

These problems could be “solved” by a single trusted orderer that commits to building blocks using competitive prioritization. Or they could be solved with decentralized mechanisms using some combination of consensus, cryptography, and/or trusted execution environments, such as Sorella’s Angstrom, Flashbots’ SUAVE, Leaderless Auctions, or Multiplicity.

Full Block

An exception to the normal operation of the MEV tax occurs when blocks are completely full. In this case, block proposers may have to exclude low priority transactions rather than just including them later in the block. Since transactions that interact with applications using the MEV tax are likely to have extremely low priority fees, these applications may be squeezed out by applications that do not use the MEV tax or applications that use extremely low MEV taxes. However, on chains that use a mechanism like EIP-1559 to set separate base fees, completely full blocks should be a rare occurrence. Furthermore, given that some transactions need to be delayed when blocks are full, delaying transactions that express lower urgency by setting a higher MEV tax may be a reasonable outcome.

Rollback transaction

The MEV tax essentially relies on a single-block auction, where each bid is a transaction. A drawback of such auctions is that unsuccessful bids often result in a rollback transaction being included on-chain, paying some base fee and congesting the chain.

If the sequencer could exclude failed transactions entirely, this would alleviate this problem, although this is difficult to achieve even with a centralized sequencer. (This also does not fully adhere to the censorship resistance property described above, although that definition could be adjusted.) A more sophisticated sequencer might be able to optimize this process by allowing transactions to specify the dispute auctions in which they participate, thereby enabling the sequencer to skip subsequent transactions that it knows will fail.

Disclosing user intent

The MEV tax only works when there is competition between searchers, which means the opportunity needs to be known to some degree. For applications like AMMs, where the opportunity is visible on-chain, this should happen naturally. But for applications like intent-based routing or tail bidding, this means the application may need to share the users intent with the searcher.

In some cases, the temporary privacy lost by broadcasting user intent before fulfilling it may leak value in ways that the MEV tax cannot recover.

For example, suppose Alice wants to buy a low-liquidity token using the trailing auction protocol described above. She publishes a signed intent for her smart contract wallet to buy that token on the AMM, and sets some slippage tolerance. Searchers can race to push the price of that token up to her slippage tolerance in a high-priority transaction without filling the users order. The winner, Bob, can then non-competitively satisfy Alices intent by including and back-running Alices intent in a low-priority transaction, thereby sandwiching Alices transaction and giving her a worse price while evading her MEV tax. Similar problems can occur when purchasing NFTs.

Note that such an attack is risky for Bob, since he cannot guarantee atomicity between buying the token and selling it to Alice. A naive Bob could fall victim to a tearing sandwich trap, where Alice posts an intent to buy a worthless token from herself, causing Bob to buy it in the hope of sandwiching it in her transaction, but Alice revokes her intent before Bob can complete the sandwich.

Applications can also mitigate this by limiting the set of searchers that share their intent and monitoring their behavior, as many existing order flow auctions do.

It is also possible to combine MEV taxes with privacy-minded builder features, such as those envisioned in Flashbots’ SUAVE design.

Finally, if Alice decides that the cost of sharing her intentions outweighs the benefits of competitive search, she can construct a transaction herself and submit it directly to the block. As described above, an ideal implementation of competitive prioritization would provide pre-transaction privacy for block proposers.

Discussion and preliminary work

Priority Gas Auctions. The Flash Boys 2.0 paper, which coined the term “miner extractable value,” examined some of the dynamics of prioritization in decentralized blockchains. The paper observed that Ethereum miners (when the network used proof-of-work) already prioritized transactions, and that arbitrageurs relied on this behavior to participate in “priority gas auctions,” where they bid for the right to be included in blocks first, which resulted in the majority of MEV from decentralized exchange arbitrage accruing to miners.

First come, first served. Through transaction sequencing rules (such as Themis 或者 Arbitrum Ones current sequencer Some attempts to mitigate MEV have focused on enforcing a different ordering rule, first-come, first-served (sometimes called “fair ordering”), where block proposers must order transactions in the order they see them.

Prioritization takes a different approach – treating transactions that arrive in a given time period equally and sorting them by their declared priority.

“Fair ordering” is difficult to enforce or even define in a real network environment with multiple validators. It can also lead to wasteful latency races and spam, even with a single trusted sequencer. Finally, a MEV tax may be able to eliminate some “first-come, first-served” MEVs, such as arbitrage profits from discontinuous “jumps” in asset prices. The potential advantage of priority ordering over first-come, first-served ordering is somewhat related to the advantages of discrete-time over continuous-time exchange discussed in Budish, Cramton, and Shim (2015) .

At the same time, while prioritization seems to leak value to MEV by default, this article shows how applications can be designed to recapture it.

Fee sharing. Blast is an Ethereum L2 that shares some of the priority and base fees with the smart contracts accessed in the transaction.

MEV taxes allow something similar (at least for priority fees), but can be implemented at the application layer on any chain that uses competitive prioritization, without requiring special support for fee sharing. They also allow applications to define their own taxes as custom functions of the priority fee, allowing greater flexibility and potentially increased composability of MEV-aware applications.

Trustless Solutions. This post focuses on the incentives for platforms to use competitive prioritization, and methods for leveraging competitive prioritization platforms, rather than discussing how to trustlessly execute it.

Each of the other properties required for competitive prioritization has been discussed extensively before. For example, in Fox, Pai, and Resnick (2023) , the authors discuss vulnerabilities in on-chain auctions without censorship resistance and describe a design for censorship-resistant auctions using multiple concurrent proposers. However, they do not recommend a specific ordering of transactions.

There is other research on building trust-minimized block construction mechanisms, including Flashbots’ SUAVE, Sorella’s Angstrom, Leaderless Auctions, Espresso and Offchain Labs’ decentralized Timeboost, and Péter Szilági’s forced public transaction packaging.

綜上所述

We hope this post encourages L2 to consider using prioritization (supported by default in the OP stack), and incentivizes applications to try MEV tax where supported.

We also hope that it will inspire further research on trust-minimizing contention prioritization protocols on L1 and L2.

footnote

1. In this post, we use “proposer” to refer to the participant or process that determines which transactions are included in a particular block. On Ethereum L2, this role is typically filled by a “sequencer”. On Ethereum L1, it is filled by a specific Ethereum validator, called a proposer, although proposers typically outsource the task of building blocks to a competitive auction involving “relays” and “builders”. The details of how these responsibilities are divided are beyond the scope of this post.

2. The priority fee per Gas is not actually explicitly specified in the transaction, but it can be calculated in the transaction. The transaction specifies the Gas price, but Ethereum also charges a base fee, which is taken from the Gas price and destroyed. For the purpose of MEV tax, the base fee should be ignored because it is not controlled by the trader. The priority fee per Gas (i.e. the price of the portion of the transaction fee that goes to the block proposer) can be calculated in Solidity as priorityGasPrice = tx.gasprice – block.basefee.

3. We can simply define “MEV” to exclude any searcher profits and refer only to the value that will flow to validators.

4. Note that proposerPriorityFee cannot actually be calculated as a multiple of the priorityFeePerGas amount (equal to the total Gas used in the transaction) during the contract, because there is no way to know how much Gas the transaction will ultimately use. However, this usually doesnt matter, as all we need is an upper bound on it. To be safe, you can multiply priorityFeePerGas by 30 million – the current maximum Gas in an Ethereum block. Overestimating this value will only mean that the MEV tax accounts for a larger proportion of MEV.

5. Assuming a transaction cannot exceed 30 million Gas, a priorityFeePerGas of 50,000 would result in a Gas payment of 1500 gwei — about $0.006 at an ETH price of $4,000.

6. If priorityFeePerGas is set so that the arbitrageur’s profit is zero, then the profit-maximizing arbitrage trade should correspond to the same trade on the function-maximizing AMM.

7. Arbitrum has discussed replacing this with a form of prioritization called Timeboost, but as of this writing, this is not yet in production.

This article is sourced from the internet: Paradigm invented a new mechanism, MEV tax, which may change the existing DeFi landscape

Related: Bitget Research Institute: Meme sector fell sharply over the weekend, LayerZero and zkSync are expected to issue tokens

In the past 24 hours, many new hot currencies and topics have appeared in the market, and it is very likely that they will be the next opportunity to make money. The following sectors need to be paid attention to: Meme sector, fan token sector Hot search tokens and topics by users: Scroll, Manta Network, BONK Potential airdrop opportunities include: Scroll, Orbiter Finance Data statistics time: May 20, 2024 4: 00 (UTC + 0) 1. Market environment Last week, BTC spot ETF had a net inflow for 5 consecutive days. The inflow of funds in the past two weeks has offset all the outflows in April. BTC rose 9% in a week, and the price fluctuated around 67,000. CME Federal Reserve observation data shows that the probability of the Federal…