What's a safe way to calculate the onchain the price of a Balancer's BPT token? More specifically, from a Composable Stable Pool (if the clarification of the pool makes the calculation different). For example, the rETH-ETH pool.

This pool has the getRate function which does that job, but it's not safe to call it in onchain since it'd be vulnerable to MEV attacks.


2 Answers 2


This pool has the getRate function which does that job, but it's not safe to call it in onchain since it'd be vulnerable to MEV attacks.

Not the first time I see a question similar to this and still find it surprising. Unless I'm missing some major system-shifting advance in how MEV works, I don't see how a read-only call to a blockchain node would help a MEV attack.

Simplified walkthrough of a read call

  1. You construct a read-only call. In your example, for getRate you'd use an eth_call.
  2. You send this call to an Arbitrum node. This is a read-only call, it does not generate any network state changes, which means it is not a transaction and does not go through a transaction cycle.
  3. The Arbitrum node (for example, your own node or a node with a provider) does the computation against the latest state that it has locally to itself and responds with the data.

In your example with getRate and the rETH-ETH pool, here's the call that you'd make (in curl):

curl --request POST \
     --url ARBITRUM_NODE \
     --header 'content-type: application/json' \
     --data '
  "jsonrpc": "2.0",
  "method": "eth_call",
  "id": 1,
  "params": [
      "to": "0xadE4A71BB62bEc25154CFc7e6ff49A513B491E81",
      "data": "0x679aefce"

You'll get the exchange rate in hex in response.

It's also the exact same call that anyone makes when they go to the contract on arbiscan, click Read Contract > getRate.

It's also the same call that a lot of other services (TVL trackers, martketcap trackers, etc) make at the rate of hundreds or thousands of times per every block printed on Arbitrum. They are not visible to MEV bots, unless you are using a node owned by an MEV bot entity. And even then these calls would still be non-actionable calls from the MEV perspective.

Simplified walkthrough of an MEV attack

  1. User makes a read-only call (an eth_call most of the times) to a contract and decides to proceed with the response. For example, the exchange rate is favorable to the user.
  2. User constructs and signs the transaction and sends it to a blockchain node. This is a state changing transaction that needs to be picked up by a node and propagate to a miner/validator to be included in the new block or by the centralized sequencer in the case of Arbitrum.
  3. This is where an MEV bots comes into play (after a transaction is submitted by the user):
  • If it's Ethereum, the transaction goes from user to a node to the mempool. Once it's the mempool waiting to be picked up by a validator, it's spotted by an MEV bot. The bot retrieves the transaction from the mempool, simulates the transaction outcome (eg the exchange rate change) and front-runs the transaction with a higher fee.
  • If it's Arbitrum, the transaction is submitted to a node from which it's straight redirected to the Arbitrum sequencer. Theoretically, this where an MEV with access to the same node (unlike with mempool in Ethereum) can spot and front-run the transaction to shove it in the sequencer queue before the user's transaction.

In short, it's safe to be doing read-only calls to a contract through a node.




This works on stable pools since the balances are used as the Invariant calculation.

Even if someone were to imbalance the pool quite heavily he would only manage to influence the invariant in a minor way due to swap fees accumulating.

So the valuation mechanism is not really based on the pool’s reserves and their token Price but rather the invariant.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.