In my view, canonicalization is the step where Newton turns an ambiguous Intent into an input precise enough for a Policy to evaluate consistently.
A raw Intent can arrive in many forms. For the same swap request, one user may enter 1 ETH, another may use 10¹⁸ wei, while someone else may refer to the asset by its token symbol instead of its contract address. A deadline may be provided or omitted because the user assumes the system will infer it.
To a human, these expressions may seem equivalent.
To a Policy engine, they are not the same input.
Before evaluation, Newton needs to parse the Intent into defined components: who requests the action, what action is requested, which asset and target are involved, and which constraints govern execution.
Only then can normalization begin.
Asset identifiers, amounts, chains, recipients, deadlines, slippage, and other constraints need standardized references, units, types, and formats so field ordering cannot alter the Intent’s meaning.
Default values also need a common rule. When a required field is missing or a parameter allows multiple interpretations, the system should not leave each operator to make its own assumption. The Intent should be treated as invalid or insufficiently specified before the Policy runs.
Once the fields are validated and normalized, Newton can construct a canonical representation: a single semantic object representing the original Intent. It can then be serialized under the same rules, ensuring every operator receives the same structure, values, and meaning.
This is the part I consider essential.
A Policy should not evaluate the words a user entered. It should evaluate the normalized Intent, after differences in format, units, and expression have been removed.
If this step fails, even a deterministic Policy cannot save the system.
Newton can preserve authorization consistency only when every operator receives the same canonical Intent before Policy evaluation.
@NewtonProtocol $NEWT #Newt $LAB $BTW
A raw Intent can arrive in many forms. For the same swap request, one user may enter 1 ETH, another may use 10¹⁸ wei, while someone else may refer to the asset by its token symbol instead of its contract address. A deadline may be provided or omitted because the user assumes the system will infer it.
To a human, these expressions may seem equivalent.
To a Policy engine, they are not the same input.
Before evaluation, Newton needs to parse the Intent into defined components: who requests the action, what action is requested, which asset and target are involved, and which constraints govern execution.
Only then can normalization begin.
Asset identifiers, amounts, chains, recipients, deadlines, slippage, and other constraints need standardized references, units, types, and formats so field ordering cannot alter the Intent’s meaning.
Default values also need a common rule. When a required field is missing or a parameter allows multiple interpretations, the system should not leave each operator to make its own assumption. The Intent should be treated as invalid or insufficiently specified before the Policy runs.
Once the fields are validated and normalized, Newton can construct a canonical representation: a single semantic object representing the original Intent. It can then be serialized under the same rules, ensuring every operator receives the same structure, values, and meaning.
This is the part I consider essential.
A Policy should not evaluate the words a user entered. It should evaluate the normalized Intent, after differences in format, units, and expression have been removed.
If this step fails, even a deterministic Policy cannot save the system.
Newton can preserve authorization consistency only when every operator receives the same canonical Intent before Policy evaluation.
@NewtonProtocol $NEWT #Newt $LAB $BTW