@Zen-Maxi Similar question as in the weETHs pr here: https://github.com/balancer/code-review/pull/94/files#diff-094145a04738e17e78f688615c745a3c99c80cc944fa47b274ad928bdcd68f39R93 #94

Ideally the rateProvider utilises getRateSafe to check if the system is paused (due to a wrong price data being pushed)

@Zen-Maxi Could you verify with the team the following observation.

Based on this txHash 0xb21d447fbaa73159d20cc2ecc508e224cdd66e41378601001af09308f3df16c0 It is indicated that Role "11" is allowed to call function updateExchangeRate(uint96 newExchangeRate) external requiresAuth on the contract with address "0xcB762D7bedfA78c725f2F347220d41062b6B0A4A" Indicated by the event "RoleCapabilityUpdated".

// ["event RoleCapabilityUpdated(uint8 indexed role, address indexed target, bytes4 indexed functionSig, bool enabled)"]
txHash 0xb21d447fbaa73159d20cc2ecc508e224cdd66e41378601001af09308f3df16c0
Result(4) [
  11n,
  '0xcB762D7bedfA78c725f2F347220d41062b6B0A4A',
  '0x3458113d',
  true
]

if I investigate which accounts have been given which role by looking at all UserRoleUpdated events. I see that no account has been given role "11". Meaning, currently no account is allowed to call updateExchangeRate.

Will hold off on the review here until we get an update.

@Zen-Maxi Similar question as in the weETHs pr here: https://github.com/balancer/code-review/pull/94/files#diff-094145a04738e17e78f688615c745a3c99c80cc944fa47b274ad928bdcd68f39R93 #94

Ideally the rateProvider utilises getRateSafe to check if the system is paused (due to a wrong price data being pushed)

Yes I think using getRateSafe() is a good idea, just noting that when the Accountant is paused, swapping would revert as calls to get the rate would revert.

@Zen-Maxi Could you verify with the team the following observation.

Based on this txHash 0xb21d447fbaa73159d20cc2ecc508e224cdd66e41378601001af09308f3df16c0 It is indicated that Role "11" is allowed to call function updateExchangeRate(uint96 newExchangeRate) external requiresAuth on the contract with address "0xcB762D7bedfA78c725f2F347220d41062b6B0A4A" Indicated by the event "RoleCapabilityUpdated".

// ["event RoleCapabilityUpdated(uint8 indexed role, address indexed target, bytes4 indexed functionSig, bool enabled)"]
txHash 0xb21d447fbaa73159d20cc2ecc508e224cdd66e41378601001af09308f3df16c0
Result(4) [
  11n,
  '0xcB762D7bedfA78c725f2F347220d41062b6B0A4A',
  '0x3458113d',
  true
]

if I investigate which accounts have been given which role by looking at all UserRoleUpdated events. I see that no account has been given role "11". Meaning, currently no account is allowed to call updateExchangeRate.

The UPDATE_EXCHANGE_RATE_ROLE is currently granted to eth:0x41DFc53B13932a2690C9790527C1967d8579a6ae and eth:0x71E2d6c34f569cC4Df5802d675B208FB8AE3Bcd6. Though for the mean time this would only be used for emergencies. In the future when eigen layer is emitting rewards the exchange rate is likely to increase though.