# Verichains audit
## 3. Inappropria te zk-counter check leads to possib le out of counters before

- This is an already known issue. This error has been mitigated with the counters margin we add at the rom. You can check the margin [here](https://github.com/0xPolygonHermez/zkevm-rom/blob/main/main/constants.zkasm#L117)

### Example
- Binaries example: the **max real amount** of available binaries is set at [`constants.zkasm`](https://github.com/0xPolygonHermez/zkevm-rom/blob/main/main/constants.zkasm#L110):

CONST %TOTAL_STEPS_LIMIT = 2**23
CONST %MAX_CNT_BINARY_LIMIT = %TOTAL_STEPS_LIMIT / 16

- On the other hand, the value we use at the rom while processing a batch has a [safety margin from this value](https://github.com/0xPolygonHermez/zkevm-rom/blob/main/main/constants.zkasm#L121):

CONST %SAFE_RANGE = 20 ; safe guard counters to not take into account (%RANGE = 1 / SAFE_RANGE)
CONST %MAX_CNT_BINARY = %MAX_CNT_BINARY_LIMIT - (%MAX_CNT_BINARY_LIMIT / %SAFE_RANGE)

- Counters are [checked](https://github.com/0xPolygonHermez/zkevm-rom/blob/main/main/block-info.zkasm#L26) in the following way:

    %MAX_CNT_BINARY - CNT_BINARY - 7                       :JMPN(outOfCountersBinary)

- This means that when we are throwing an out of counters error, we still have the 5% of the total amount of counters available.
- The situation exposed at the report it's not dangerous because the executor will have enough binary counters to finish the `opBYTE` function and probably the ooc binary will be triggered at the next binary check of the execution. This kind of situation can be dangeraous in case this "not checking counters" happens in a loop or in a place where lots of counters are consumed before the next counters check.
- If we change the reported from binaries to steps, we will see that the exposed situation is found in many places of the code. Checking what is being reported in the field of steps will directly affect the performance because we will have to do too many steps checks.