Intent
Also: Intent-based architecture · Declarative transaction
A statement of the outcome a user wants, signed and published for others to fulfil, rather than an instruction specifying how to achieve it.
A transaction says do this. An intent says I will accept this result. The user signs a constraint — a minimum received, a deadline, an acceptable price — and specialised parties compete to satisfy it, choosing the route themselves.
Why the shift happened
Because specifying the route requires knowing the state of the system at execution time, and the user does not. Delegating the how to parties who do converts a problem of prediction into a problem of verification: the user checks the outcome against the constraint, which is something they can actually do.
What it moves rather than solves
- Extraction moves rather than disappears. Fillers compete, but they also see the intent before it settles, and what they do with that information is the same question that ordering has always raised.
- The constraint is the whole of the protection. An intent with a loose bound is an invitation, and the user who signs it has authorised the result.
- It concentrates capability. Fulfilling intents well requires inventory, infrastructure and speed, so the set of parties able to do it is small.
For agents the appeal is structural: an intent is a form a program can express safely, because it states what is acceptable rather than requiring the program to be right about the world.