Abstract intent machine model


I think it would be very helpful to have a discrete mathematical model of intents that captures the essence which we want to capture without unnecessary implementation detail, but which is specific enough to clarify what we do and do not mean by the term “intent”. The best candidate I have thought of personally is that of an “intent machine”. In this post, I will walk through what an intent machine is, what definition of “intent” it provides, and (broadly) how this definition relates to Anoma’s protocol components.


Fix a state type T (can be equivalently understood as a possibly infinite set of possible states).

An intent I_T is a function of type T \to T \to { 0 | 1 }.

An intent machine IM_T is a potentially non-deterministic function IM_f of type (T, Set\ I) \to (T, Set\ I). Informally, the first tuple consists of the prior state and a set of intents which could possibly be processed, and the second tuple consists of the posterior state and a set of intents which was actually processed. Let’s name the arguments for clarity:

IM_f :: (prior :: T, available :: Set\ I) \to (posterior :: T, processed :: Set\ I)

In order to qualify as an intent machine, the function must preserve the property that all intents actually processed were satisfied:

\forall i \in processed . i\ prior\ posterior = 1 .

Let’s call this property “intent adherence”.

IM_f is required to satisfy this property, but it is not required to be deterministic.


Without loss of generality, IM_f can be decomposed into two steps and one constraint.

Two steps

  1. computing a set of (candidate state, processed intents) tuples which satisfy intent adherence
  2. selecting one of the tuples to return


IM_f may additionally constrain which state transitions are considered to be valid (potentially returned). This constraint can be modelled as a singular “system intent” which must always be satisfied, and it may itself change from one invocation of the machine to the next, so we shall model it as a distinct component of state:

T := (I_T, T').

IM_f :: ((I_{{system}_{prior}}, prior'), Set\ I) \to ((I_{{system}_{posterior}}, posterior'), Set\ I)

IM_f then satisfies:

I_{{system}_{prior}} \ prior\ posterior = 1.

Let’s call this property system intent adherence.

Note that I_{{system}_{posterior}} is not checked, but it will constrain future invocations of the intent machine.

Let’s go through the two steps in detail:

1 - Enumeration

The enumeration step enumerates all possible valid return pairs of (T, Set\ I).

\{(posterior, processed)\ |\ \forall i \in processed . i\ prior\ posterior = 1, processed \subset available, I_{{system}_{prior}}\ prior\ posterior = 1\}

2 - Selection

The selection step picks one pair from the set of valid options.

choose :: Set\ (T, Set\ I) \to (T, Set\ I).


All of the interesting structure happens in the selection phase. To aid the intuition, here are some example choose functions:

  • “Pure chaos”
    • Select at random a valid return pair
  • “Pareto-efficient chaos”
    • Select the return pair which satisfies the most intents, break ties with randomness.
  • “Utility maximization”
    • Select the return pair which maximizes some scalar function U_T :: T \to Nat.
  • “Profit maximization”
    • Utility maximization with U_T as the balance of some specific token owned by the operator’s address in the posterior state.
  • “Expected utility maximization”
    • Select the return pair which maximizes U_{{T}_{expected}}, given some probability distribution over future intents conditional on the posterior state.

Relation to Anoma

A resource machine is an intent machine with a system intent that interprets the state as a set of created/consumed resources, checks resource logic adherence, and enforces linearity.

Taiga is a concrete instantiation of a resource machine (currently using Halo 2).

Typhon, roughly, is a concrete instantiation of a distributed intent machine. This needs to be treated in combination with composition and will be covered in a follow-up post.

1 Like

Areas to expand upon:


  • Identity type and information flow control
  • Intents as atomic information flow constraints
  • Composition of intent machines
  • Distributed intent machines
    • Distribution of state
    • Distribution of computation
    • Distribution of enumeration
    • Distribution of selection


  • Resource machine system intent
  • Partial transaction encoding in resource machine
    • Intent composition

Revised basic model (after discussion with @isheff):

Fix a (possibly infinite) state type T.

Let an ordering Ord be Lt, Eq, or Gt.

An intent I_T is a partial ordering over transitions over T, i.e. a function of type T \to T \to T \to Ord.

An intent machine IM_T is a non-deterministic function of type (T, Set\ I) \to (T, Set\ I). Informally, the first tuple consists of the prior state and a set of intents which could possibly be processed, and the second tuple consists of the posterior state and a set of intents which were actually processed. Let’s name the arguments for clarity:

IM_T :: (prior :: T, available :: Set\ I) \to (posterior :: T, processed :: Set\ I)

In order to qualify as an intent machine, the function must preserve the property that all intents actually processed were satisfied:

\forall i \in processed . i\ prior\ posterior\ prior \neq Lt

Informally, this means that the intent either prefers transitioning to the new state or is neutral. Let’s call this property intent adherence.

(to be continued…)

Some preliminary notes on the connection between


Intents and State

We always have the option to run consensus over (subsets of) intents, which means composing the (ordered) views of the intent space of all the agents participating in consensus. This generalizes to consensus over intents over intents …, but obviously comes with all the downsides of needing to run consensus.

It is connected however, to the distribution of state itself, where composition of subspaces also happens by composing views via running consensus: Since intents will be formulated over resources, which have controllers who need to execute the transactions which result from the intents being matched, intents already carry information about which parties will be involved with execution.

Here, the controllers will execute transactions according to internal decision metrics, fee structures, etc. s.t. they are coupled into the intent machine.

Question: Do I understand correctly, that intents can only be valid if they are over resources with compatible controllers, or do we want a mechanism to run hybrid consensus on demand?

I’ll try to sketch this out in a hopefully non-synthetic, but very reduced,

Example to illustrate worst case incentives:

If we assume trust-aware distribution of solving, in the worst case controllers would just drop proposed PTXs by untrusted solvers.
The edge case of this is the bootstrapping stage, where every controller does the solving for resources they control on their own and only cooperates with the respective solvers/controllers on PTXs which include resources controlled by others. Since there is no trust, all parties assume maximal likelihood of defection.
As such, the assumed setting consists of: Maximally malicious parties, with maximal interests outside of solving rewards.
I assume settings like these will always be present, even once there is more trust and non-controller solvers show up in the network.

If we are able to come up with some reasonable incentive structure for this, I guess we can generalize towards something useful.

Spectrum of composition

It looks to me composition then can happen on a spectrum with the two endpoints:

  • Fully independent solvers come up with independent solutions and controllers pick amongst them according to their decision criteria. → Maximum competition and fully parallel

  • All solvers cooperate (making up one composed solver) to come up with exactly one proposal for each controller (or composed HPAXOS round between multiple controllers). This could include running consensus on intents or other mechanisms, but we cannot assume non-malicious behavior. → Maximum cooperation and fully sequential.

In reality, different solvers will populate this spectrum at different points. The above considerations should be independent of enumeration and selection which are roles within solvers.

1 Like

Can you give an example of what it means to run consensus over intents? Consensus, by the book, is the agreement of a set of agents on a value that has been proposed by one of the agents. So which agents agree on what and who proposes these values directly or indirectly?

Agree on a view of intents before actually solving them.


You could have a fairness criteria such that

  • intents for a given application can only be solved in a particular order; e.g., first-come first-serve.
  • In this scenario a solver could receive user intents over a given time interval (say every 1 second) submit a batch of intents ordered how they are received to Typhon where n rounds of consensus are performed before the intents can be solved (matched).
  • Thereafter, some intents from the batch would be solved and submitted as balanced transactions for ordering and execution.

(Obviously, threshold decryption is better and possibly provides greater inclusion gaurantees and welfare - less incentive to spam in a latency race, still optimisitc spam with TD - for users than the FCFS example).

1 Like

If multiple solvers have batches of intents alerady which they want to solve for, they could decide to run consensus over the union of these batches and solve together. Then, at least during this round, certain kinds of defection, like front running are prevented.

This gives no guarantees into rounds in the future, and I suspect that specific agents could strategically hold back messages (probably even dependent on some data they received in the ongoing consensus round).

intriguing, but, in place of writing down my thoughts on the game theoretic perspective, …

…, for the consensus side of things, red-belly has “something” similar (called Set Byzantine Consensus), and then there’s a more technical paper below, making reference to some classics, proposing set-union consensus

Set Byzantine Consensus

Definition 1 (Set Byzantine Consensus)
Assuming that each
correct node proposes an enumerable set of transactions as a
proposal, the Set Byzantine Consensus (SBC) problem is for
each of them to decide on a set in such a way that the following
properties are satisfied:

  1. SBC-Termination: every correct node eventually decides
    a set of transactions;
  2. SBC-Agreement: no two correct nodes decide different
    sets of transactions;
  3. SBC-Validity: a decided set of transactions is a valid non-
    conflicting subset of the union of the proposed sets;
  4. SBC-Nontriviality: if all nodes are correct and propose
    an identical valid non-conflicting set of transactions, then
    this subset is the decided set.

Set Union Consenus

3.1 Definition
We now give a definition of set-union consensus that is
motivated by practical applications to secure multiparty
computation protocols such as electronic voting, which
are discussed in more detail in the section “Application to
Consider a set of n peers P = {P1, . . . , Pn}. Fix some
(possibly infinite) universe M of elements that can be rep-
resented by a bit string. Each peer Pi has an initial set
Si (0)
⊆ M.
Let R : P (M) → P (M) be an idempotent function
that canonicalizes subsets of M by replacing multiple con-
flicting elements with the lexically smallest element in the
conflict set and removes invalid elements. What is consid-
ered conflicting or invalid is application-specific. During
the execution of the set-union consensus protocol, after
finite time, each peer Pi irrevocably commits to a set Si
such that the following applies:

  1. For any pair of correct peers Pi, Pj , it holds that
    Si = Sj.
  2. If Pi is correct and e ∈ Si 0, then e ∈ Si.
  3. The set Si is canonical, which is Si = R(Si).
    The canonicalization function allows us to set an upper
    bound on the number of elements that can simultaneously
    be in a set. For example in electronic voting, canonical-
    ization would remove malformed ballots and combine
    multiple different (encrypted) ballots submitted by the
    same voter into a single “invalid” ballot for that voter.