there is a bug in the operator_set_fee.rs` here this part
operator.operator_fee_bps = new_fee_bps.into();
it's updates the operator fee immediately. there is no delay, no “effective next epoch” rule, and no ramp-up period. Because Tip Router later reads this live fee when creating the reward snapshot, an operator can briefly change the fee to 100%, let the snapshot capture that value, and then restore the original fee in the same transaction. The live Operator account ends up showing the old fee again, but the snapshot keeps 100% and uses it to split rewards from the already-completed epoch. T
the vulnerability is not that operators are allowed to change fees; it is that fee changes take effect instantly and can be applied retroactively to rewards that were already earned under the previous fee.
i have a e2e poc that show this with imapct if need it
there is a bug in the operator_set_fee.rs` here this part
it's updates the operator fee immediately. there is no delay, no “effective next epoch” rule, and no ramp-up period. Because Tip Router later reads this live fee when creating the reward snapshot, an operator can briefly change the fee to 100%, let the snapshot capture that value, and then restore the original fee in the same transaction. The live Operator account ends up showing the old fee again, but the snapshot keeps 100% and uses it to split rewards from the already-completed epoch. T
the vulnerability is not that operators are allowed to change fees; it is that fee changes take effect instantly and can be applied retroactively to rewards that were already earned under the previous fee.
i have a e2e poc that show this with imapct if need it