Had this contract been written in idiomatic glow, it would have been structured as a state machine and transitions would be forced to be explicit. You could spe

Had this contract been written in idiomatic glow, it would have been structured as a state machine and transitions would be forced to be explicit. You could specify invariants on the states as well as constrain the behaviour of the transitions. In this case the transition would have moved the SM out of the initialised state which would have precluded the ability to re-initialise the contract/state machine. Attempting to invoke said re-initialisation would cause a compile error. You could write the contract in such a way that would still allow this however it would be evident that something is amiss as it would be incredibly un-idiomatic and awkward. In the other case, the function had an implicit constraint that the value was within a certain bounds. The contract made no effort to check these bounds. With Glow you would have specified the constraints on the inputs and the interaction with the contract would be denied if the input for the function was outside those constrained bounds. This would be a compile error and possibly also a runtime check in the case of malicious actors ignoring bounds. I'm not sure how necessary the runtime check would be (as I'd have to check how the smart contract generation is set up) but at the very least the exploit would not have been able to occur.