# Ideas on Account Abstraction **URL:** \ **Category:** Aztec\ **Created:** [May 8, 2023, 8:05pm UTC](https://forum.aztec.network/t/ideas-on-account-abstraction/339 "2023-05-08T20:05:01Z")\ **Posts on this page:** 1\ **Showing post:** 11
**Author:** ![spalladino](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.aztec.network/spalladino/32/32_2.png) [@spalladino](https://forum.aztec.network/u/spalladino)\ **Post date:** [May 19, 2023, 7:26pm UTC](https://forum.aztec.network/t/ideas-on-account-abstraction/339/11 "2023-05-19T19:26:18Z")
In discussing [another topic](http://forum.aztec.network/t/reading-current-public-state-from-private-functions/454) with @LasseAztec, we’ve uncovered another issue of fee abstraction: > Be mindful that if part of a transaction is reverting, say the public part of a call, it will revert the entire transaction. Similarly to Ethereum, it might be possible for the block builder to create a block such that your valid transaction reverts because of altered state, e.g., trade incurring too much slippage or the like. ([source](https://docs.aztec.network/aztec/how-it-works/private-public-execution)) This means that the fact that the user has submitted a valid proof for their private execution, which includes the fee payment, is **no guarantee that the fee will be paid** , because a depending public function execution that comes later could revert the whole thing, leaving the sequencer without their fee. I can think of two ways around this: - Enqueued public function calls do **not** revert their associated private executions (this breaks @LasseAztec’s [proposal for access control](https://docs.aztec.network/aztec/how-it-works/private-public-execution#a-note-on-l2-access-control)). - We reintroduce a “signature validation and fee payment phase” for each tx, which is not allowed to make public calls, and is not reverted if a public call downstream fails. --- _[View the full topic](https://forum.aztec.network/t/ideas-on-account-abstraction/339)._