here's the scoop on @intentessential ; it has two components, declarative execution environment (essentialvm) & constraint driven language (pint) pint contracts are composed of a storage block & a series of predicates; storage represents persistent state as we're used to in smart contracts, but predicates are composed of a series of constraints over which storage may mutate obligatory counter: storage is declared with a single counter value; a 64 bit signed integer (essentialvm default) 'Increment' predicate first declares which state variables (storage::counter) to access. any state identifier followed by the single quote (counter' vs counter) indicates the state variable after the current transaction. that is to say, the current state may be constrained and the next state may be constrained, this is how the state is mutated, not by directly writing the value to a storage slot constraints declare the conditions for a valid state transition, if one evaluates to false, the transaction reverts. the above constraint declares either the counter must go from nil (undefined) to 1 OR the counter must go from its current value to its current value + 1 -- essentialvm is a 64 bit stack machine, though instructions are not hiding imperative opcodes, at the vm level there is only a state transition and constraints over their properties predicates of a contract may also access other contracts' predicates and storage layouts, that is to say composition of constraints over external state is also possible this is a fresh take on what an execution layer can be, how we can solve and process state transitions within the constraints of smart contracts, and it wildly opens the design space for complex applications looking forward to learning more