# To read or not to read?

**URL:** <https://forum.aztec.network/t/to-read-or-not-to-read/178>\
**Category:** Aztec\
**Tags:** utxos\
**Created:** [April 12, 2023, 10:57am UTC](https://forum.aztec.network/t/to-read-or-not-to-read/178 "2023-04-12T10:57:12Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![Mike](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.aztec.network/mike/32/7_2.png) [@Mike](https://forum.aztec.network/u/Mike)\
**Post date:** [April 12, 2023, 12:55pm UTC](https://forum.aztec.network/t/to-read-or-not-to-read/178/4 "2023-04-12T12:55:23Z")

</div>

> [@spalladino](#):
>
> Jokes aside, I understand that hard forks would be designed to be backwards compatible with app circuits, right? Unless the internal state representation needs to change in ways like the ones you mentioned (eg removing a hash function that was shown to be insecure).

Ideally, yes, we’d want to keep hard forks backwards-compatible. There are a few examples in Ethereum’s history where it’s removed a feature and broken apps (e.g. removing ‘gas rebates’ for setting nonzero storage to zero breaking gastoken).

---

_[View the full topic](https://forum.aztec.network/t/to-read-or-not-to-read/178)._