Applications

We have seen how the idea of User Data, coupled with the expressivity of Pint, enable users to craft sophisticated expressions of their preferences over (potentially unrelated) on-chain state. This differs from, for example, the EVM, where individual transactions can only interact with multiple smart contracts atomically if additional smart contracts are first deployed to act on behalf of the user. The ability to atomically constrain arbitrarily many contracts' state in a single interaction significantly reduces chain-bloat, since only fundamental application logic needs to be deployed persistently on-chain. Furthermore, this application logic is modular and reusable : common interaction patterns can be deployed once, and used by everyone.

Applications can also express constraints over state which are time dependent. For example, if a user has a portfolio of various tokens which they wish to rebalance, they can express this logic directly in a contract. Conversely, if a user has a portfolio over which they have a persistent preference - for example, they wish to gradually dollar-cost-average from one token to another - this can also be encoded in Pint, and can be satisfied gradually over time by solvers without additional input from the user.

An advantage to the application layer being purely declarative derives from implicit composability. In the imperative paradigm, two applications are only compatible with one another if they explicitly implement each others’ interfaces. For example, in order for an application to gain access to the liquidity of a particular AMM contract, it must have awareness of that contract’s interface at compile-time, or else explicitly be designed with upgradeability in mind. This is not so for the declarative paradigm. Because we reason purely about state, any two applications which constrain the same state are implicitly composable - it is the solver who provides this abstraction.

In the imperative application design space, there are practical limits to the complexity of business logic that can be computed on-chain, because the network needs to be compensated for this computation, which can quickly become a prohibitive cost. In the declarative design space, correct adherence to application logic is ensured through the validation of solutions on-chain, with solvers being compensated for finding satisfactory state updates. This leaves the solver free to model the execution of this application logic in any way they see fit. Indeed, there may be more than one way to model business optimization problems, which is a domain over which solvers can compete. This is much more efficient than an application not only defining a canonical model for the logic, but also requiring that the whole network execute that model on-chain. In the class of problems that are hard to compute, but easy to verify, Essential leverages this ease of verification.