# Should the RM support independently balance-checked actions?
**URL:** https://forum.anoma.net/t/should-the-rm-support-independently-balance-checked-actions/852
**Category:** RM
**Created:** [November 6, 2024, 9:25am UTC](https://forum.anoma.net/t/should-the-rm-support-independently-balance-checked-actions/852 "2024-11-06T09:25:25Z")
**Posts on this page:** 2
**Page:** 1
### Author:  [@cwgoes](https://forum.anoma.net/u/cwgoes)
#### Post date: [November 6, 2024, 9:25am UTC](https://forum.anoma.net/t/should-the-rm-support-independently-balance-checked-actions/852/1 "2024-11-06T09:25:25Z")
The objective of this thread is to answer the following question:
_Do some applications (resource logics) have a reason to require that an action be (independently) balanced?_
At the moment, actions are required to be independently _valid_ but not independently _balanced_. This post was motivated by a discussion earlier this week of the counter example, where the counter resource logic must check that the kind of the created and consumed counter resources is the same in order to ensure that counters weren’t swapped and consumed/created in different actions (which would be independently valid and not balanced, while the transaction as a whole would be balanced). While the kind equality check implements the correct behavior, the discussion made clear that intuitions are not clear here - it would be easy for a developer to write a counter resource logic without realizing that they have to perform this check - and it prompted the idea that some applications might want to enforce that balance is checked for actions, not just transactions.
However, after thinking about it, I do not think adding a way for resource logics to enforce that an action is independently balanced is the right way to improve the developer ergonomics here, for two reasons:
1. The balance check is typically a _stricter_ check than what is actually desired. For example, with a counter, the logic which must be enforced really just is that the consumed and created resources differ only by their value (which gets incremented by 1). A counter which counts something (some change to other resources) might well need to be included in the same action, and that counter shouldn’t check that the whole action is balanced, because this might prevent other desired logic (such as intent matching with other actions) from working as usual in the RM.
2. Adding a flag for a resource logic to instruct the compliance logic to check that an action is independently balanced is _not_ an increase in expressive power, as the balance condition (or whatever subset of the balance condition the resource logic wanted to ensure was checked) could simply be directly checked by the resource logic itself, which has access to all the relevant data.
Rather than going in this direction, I propose instead that we create some abstractions / standard library functions around the common case of “a resource must be created which is exactly the same as a resource consumed except for difference X”, where in this case X is that the counter value is incremented by one. If such options are obvious and recommended to developers, it is much more difficult to screw up by mistake (since what the developer specifies is what is _allowed_ to change, not what is _not allowed_ to change - if they forget something, the system is still safe if perhaps no longer live). In general, in our standard library and developer interface design, we should err on the side of safety in this way.
Paging @vveiln @Michael @paulcadman for input here.
---
### Author:  [@Michael](https://forum.anoma.net/u/Michael)
#### Post date: [November 7, 2024, 1:18pm UTC](https://forum.anoma.net/t/should-the-rm-support-independently-balance-checked-actions/852/2 "2024-11-07T13:18:49Z")
Yes, balance-checked actions would prevent “desired logic (such as intent matching with other actions)”.
I am also against adding this as a flag because it doubles the amount of cases you need to think of when trying to write an application being composable with other applications.
Having standard library functions for property checking / matching seems like the best approach to me.
I am also very much for safe defaults, and I’ll think about how we can achieve this here.