Sometimes the hardest part of automation is not execution. It is deciding which instructions deserve to execute at all. In most software, that decision is hidden inside application logic. A user clicks a button, the system checks a few conditions, and the action moves forward. But once assets, permissions, and multiple operators enter the picture, trusting every request by default stops being a safe assumption.
Newton treats that problem differently. Every action begins as an Intent, a description of what someone wants to do. At that stage, nothing has happened onchain yet. The Intent is only a proposal. Before it can become a transaction, Newton evaluates it against a set of policies. Only intents that satisfy those rules are allowed to cross the boundary into execution.
At first glance, this sounds like a standard authorization layer. It is easy to imagine policy checks happening after the transaction has already been assembled, as if governance were simply adding one last signature before approval. That assumption reflects a deeper intuition: that transactions are the fundamental unit of the system, and governance merely constrains what can be done with them.
Newton reverses that relationship. The transaction does not exist until the policy engine decides that the Intent is acceptable. Evaluation comes first. Execution comes later.
That ordering changes the role of policy entirely. Policies are no longer passive constraints wrapped around transactions that already exist. They become the mechanism that determines whether a transaction deserves to exist in the first place. The Intent proposes an action, but policy decides whether that proposal is compatible with the rules of the system. Governance stops being a checkpoint at the edge of execution and becomes the layer that translates intention into authority.
The distinction matters because an Intent is not simply an incomplete transaction waiting for approval. It occupies a different position in the architecture. A transaction is already committed to a particular execution path: specific calldata, specific effects, specific state changes. An Intent describes something more abstract: a possible action that has not yet acquired consequences. Policy does not inspect that possibility after the fact. It interprets it and determines whether the system is willing to turn it into reality.
The design also creates a clean separation of responsibilities. Applications describe business goals without embedding governance logic into every workflow. Policy authors define the conditions under which those goals may become actionable. By forcing every Intent through the same evaluation layer, Newton avoids turning governance into a scattered collection of checks hidden across different applications.
The tradeoff is subtle but profound. Execution no longer stands at the center of the architecture. The entire system depends on the quality and completeness of the policy layer that mediates between intention and consequence. Weak policies authorize dangerous actions. Overly restrictive ones prevent legitimate intentions from ever materializing. Newton accepts that dependency because, in this model, governance is not protecting transactions. It is producing them.
I keep coming back to that inversion. Most systems treat transactions as the primitive and governance as a constraint. @NewtonProtocol treats Intent as the primitive, while transactions emerge only after governance has interpreted, filtered, and legitimized what someone wanted to do in the first place.
