Anoma Over a Cup of Coffee


Explain Anoma over a cup of Coffee. The explanation should provide the listener a strong foundation to proceed with more inquiry.

Please critique this, tell me why and how it is wrong. Also, if you feel so inspired, I would encourage you to try this exercise as well.


I recognize I’m excluding many details. The goal is to explain to the listener without too many Proper nouns. For example, I decided not to include machine groupings but thought about it.


Anoma is a generalized architecture designed for intents. Intents are commitments to preferences over a shared state space. Intents let a user specify what they want by invoking a set of constraints. Intents allow users to control the amount of information they reveal - what to whom.

In the Anoma architecture, a user outsources the task of computation to a solver. A solver is a specialized agent that figures out how to satisfy a users’ intent. Solvers match intents, which are represented in the form of partial transactions. Partial transactions are combined to form a balanced transaction, which can contain many intents.

Solvers send fully balanced transactions to Typhon, Anoma’s ordering protocol, which provides the mempool, consensus, and execution engines. Taiga, Anoma’s shielded state transition protocol, checks the validity of the transactions, ensuring all application rules and predicates are satisfied.

Anoma realizes intents with a resource model. Resources can be represented as a UTXOs. Intents allow for arbitrary constraints which are represented as resource logic or as side information sent to the solver. This architecture requires an intent gossip network (p2p layer), a marketplace of solvers offering solutions, and a place to send matched intents.

Anoma scales with fractal instances. Nodes running the Anoma network can spin up an instance on-demand, or a particular set of nodes could operate a persistent instance within the Anoma network. Typhon allows for instances to interoperate and create atomic bundles that settle to multiple instances given enough overlap of Anoma nodes (validators). This feature is known as Chimera Chains.

Anoma allows for various runtime configurations that are up to the user and application developers to determine. For example, there could be a fairness or welfare criteria that needs to be achieved. In the former, a solver could send an encrypted batch of intents to Typhon which comes to consensus on the batch then decrypts the batch after x blocks for solvers to then match. This type of configuration is often referenced when describing Ferveo, a threshold decryption DKG protocol.

Anoma can be instantiated as a blockchain, albeit at any layer. It can settle to any other blockchain or act as a settlement layer. Anoma’s components can be used in isolation or more beneficially as one homogenous stack. It is up to users to choose the constraints they want satisfied and the security domain they wish to settle their intents to. Anoma applications are not married to any one particular instance and can be portable across any of Anoma’s fractal instances. Anoma application developers write programs in Juvix, a high-level functional language.

1 Like

Thank you for this post; I think it’s a great initiative, and I think it’s especially helpful as an exercise to do this in writing, so that we can compare our answers and discuss what kinds of explanations could be helpful to different audiences.

Please take the following as brainstorming, not canonical in any way.

Thinking about communications a lot this week, I think it is possible that our current strategy is completely wrong. It might be right or wrong in the details - what aspects of Anoma that are similar to or different than rollups, what aspects of the trust model and information flow control do we focus on, etc. - for specific audiences, but I am not so worried about this right now - rather, I am worried about the top of the semantic tower - I am worried about the overall shape - and that starts with the question:

What is Anoma?

There is no essential answer to this question. “Anoma” is just a word - in fact, it’s a word we made up. It means whatever we say it does.

So far, we have used “Anoma” to refer to several things:

  • the Anoma protocol, which Heliax is currently specifying and implementing
  • the Anoma network, the actual nodes running the Anoma protocol in the future
  • the Anoma foundation, a Swiss Stiftung tasked with supporting the project (both protocol & network)
  • the Anoma token, a token for economic coordination of the Anoma network, for which which the Anoma foundation has promised to propose a genesis allocation

In our explanations of Anoma, we almost always focus on the Anoma protocol - as your explanation does. Furthermore, we typically explain Anoma “from the inside” - what does the protocol consist of (Typhon & Taiga), how does it relate to other protocols, etc. Your explanation also includes a little bit of “what Anoma can do”, related to the existing blockchain language (“be instantiated as a blockchain”).

This style of explanation assumes - implicitly or otherwise (and I don’t want to pick on your explanation, it’s a great one - I just want to use it as a clear example) - that the most important thing to explain, and perhaps the thing which people want to know about when they sit down with you for coffee, is the Anoma protocol.

For most of the world, I think this assumption is false. We as Heliax - and to some extent fellow protocol designers and architects - see Anoma from the inside - we care about the structure of the protocol, and we relate ourselves to other protocols by their differences in interior structure. But to most of the world, protocols are something to be used - people and communities will care about what they can do with Anoma - how they can use it to instantiate their own autonomous economic systems, protect the privacy and integrity of their fellow community members, interoperate with other communities, etc. In order to do these things they need an actual computational instance, not a mathematical structure - in other words, they care not about the Anoma protocol, but rather about the Anoma network.

Furthermore, these potential users don’t care about the concepts the protocol uses to structure its interior - Typhon, Taiga, engines, even intents - they care about the affordances which the network offers them - they care about being able to create a community currency, control its distribution, model aspects of the world over which they want to economically coordinate, etc. The internal structure of Anoma will correspond to these functions, of course, but if we need to explain the internal structure of Anoma in order to explain these affordances, we have failed.

If we want to communicate Anoma to the people and communities who might want it, we need to choose our definitions on the basis of what they care about, not what we do. In this spirit, I propose a complete reorientation of our semantic structure, starting with “Anoma”:

  1. Anoma is not a protocol. Anoma is a network.
  2. The Anoma network is composed of machines, people, and communities running the Anoma protocol.
  3. The Anoma protocol is composed of:
    • Automated intent-centric accounting software (this is what Heliax is specifying).
    • A set of concepts and procedures for using this software to represent real economic relations (could also be understood as a culture of use: how to map between the protocol-level and intuition-level understandings of intents).
  4. The Anoma foundation is responsible for coordinating the initial development of the Anoma protocol and bootstrapping the Anoma network.
  5. The Anoma token is used by the Anoma network for economic coordination of network-level matters of economic interest (e.g. network-level public goods funding).
  6. The Anoma foundation will propose a genesis allocation. It is up to the members of the Anoma network to choose whether or not this allocation is, in fact, the Anoma token, and to control the allocation of the token over time (or make a different token the Anoma token - the token is a matter of social consensus; whatever people consider it to be).

Given this basis, explanations could look a lot different. As an example:

Anoma is an intent-based network of autonomous communities. Communities can participate in the Anoma network by running the Anoma protocol. The Anoma protocol is a sociotechnical infrastructure template: as a community with particular values, you can configure and reconfigure the protocol to operate in a particular way such that interactions with the network uphold your values. For example, you can create local currencies to circulate and organize economic relations within your community, encode environmental models to understand how your daily actions impact your long-term sustainability, and precisely define what interactions you want to have and data you want to reveal to other communities.

For communities, participating in the Anoma network provides both autonomy and interoperability. Anoma provides autonomy through infrastructural self-sovereignty: your community can control all of the parameters of the socioeconomic protocols you instantiate, you need not depend on any external parties or servers elsewhere in order to operate these protocols, and you choose which parts of your internal operations to reveal to communities outside your own. Anoma provides interoperability through protocol compatibility: both the computerized and conceptual parts of the Anoma protocol provide a universal syntax without requiring agreement on semantics, so the syntax can be agreed to by everyone, and specific communities can use the common syntax to determine where they do in fact agree on semantics, and interact only in those ways.

The current economic network and organizing paradigm restricts autonomy and limits freedom. Communities have two options: to give up autonomy for the sake of interoperability - use infrastructure, protocols, and currencies operated and controlled by someone else, and thereby participate in wider economic networks - or to give up interoperability for the sake of autonomy - opt out of the shared infrastructure and produce everything themselves. Anoma aims to offer a third way - one which preserves both autonomy and interoperability.

Anoma is still under construction. Development of the initial protocols and bootstrapping of the network is coordinated by the Anoma Foundation, a Swiss non-profit. You can learn more and join in at

1 Like

So to summarise: when we talk to other researchers who care about specific ways we achieve things (how do you enable heterogenous security? how do you achieve privacy?), it makes sense to talk about the protocol. When we talk to potential users (there is of course an overlap in categories, researchers are users too), it makes more sense to talk about how Anoma network could be useful for the user, not how the properties the user cares about are achieved. Is that a correct understanding?

1 Like

Yes - I’m also proposing that we should use the word “Anoma” consistently to mean either the network or the protocol but not both. So far, I think we’ve been mostly using it to mean the protocol, and I propose that we shift to using it to mean the network. (so, when we want to talk about the protocol, we should say “Anoma protocol”).


I like this idea of calling out the Anoma protocol to distinguish from Anoma, the network - as in, the Anoma protocol is for Autonomous Ecologies which can participate in the Anoma network by running the protocol.

1 Like

This is an excellent point. The affordances are what users, application designers, and future community members will care about. I think this is pretty clear upon reflection. Thanks for the link - Don Norman UX work is helpful.