# Anoma Over a Cup of Coffee **URL:** \ **Category:** General Research\ **Created:** [September 20, 2023, 11:37pm UTC](https://forum.anoma.net/t/anoma-over-a-cup-of-coffee/249 "2023-09-20T23:37:57Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![apriori](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.anoma.net/apriori/32/1655_2.png) [@apriori](https://forum.anoma.net/u/apriori)\ **Post date:** [September 20, 2023, 11:37pm UTC](https://forum.anoma.net/t/anoma-over-a-cup-of-coffee/249/1 "2023-09-20T23:37:57Z")
### Objective 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. ### Caveats 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 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. ---
**Author:** ![cwgoes](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.anoma.net/cwgoes/32/22_2.png) [@cwgoes](https://forum.anoma.net/u/cwgoes)\ **Post date:** [September 21, 2023, 11:21am UTC](https://forum.anoma.net/t/anoma-over-a-cup-of-coffee/249/2 "2023-09-21T11:21:06Z")
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](https://www.interaction-design.org/literature/topics/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 [anoma.net](http://anoma.net). ---
**Author:** ![vveiln](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.anoma.net/vveiln/32/60_2.png) [@vveiln](https://forum.anoma.net/u/vveiln)\ **Post date:** [September 21, 2023, 1:54pm UTC](https://forum.anoma.net/t/anoma-over-a-cup-of-coffee/249/3 "2023-09-21T13:54:53Z")
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? ---
**Author:** ![cwgoes](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.anoma.net/cwgoes/32/22_2.png) [@cwgoes](https://forum.anoma.net/u/cwgoes)\ **Post date:** [September 21, 2023, 2:45pm UTC](https://forum.anoma.net/t/anoma-over-a-cup-of-coffee/249/4 "2023-09-21T14:45:54Z")
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”). ---
**Author:** ![apriori](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.anoma.net/apriori/32/1655_2.png) [@apriori](https://forum.anoma.net/u/apriori)\ **Post date:** [September 21, 2023, 4:48pm UTC](https://forum.anoma.net/t/anoma-over-a-cup-of-coffee/249/5 "2023-09-21T16:48:46Z")
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. ---
**Author:** ![apriori](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.anoma.net/apriori/32/1655_2.png) [@apriori](https://forum.anoma.net/u/apriori)\ **Post date:** [September 25, 2023, 2:05pm UTC](https://forum.anoma.net/t/anoma-over-a-cup-of-coffee/249/6 "2023-09-25T14:05:38Z")
> [@cwgoes](#): > > they care about the [affordances](https://www.interaction-design.org/literature/topics/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. 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. ---
**Author:** ![graphomath](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.anoma.net/graphomath/32/9_2.png) [@graphomath](https://forum.anoma.net/u/graphomath)\ **Post date:** [April 18, 2024, 7:47am UTC](https://forum.anoma.net/t/anoma-over-a-cup-of-coffee/249/7 "2024-04-18T07:47:58Z")
![image](https://europe1.discourse-cdn.com/flex013/uploads/anoma1/original/1X/8788397ad3d095db2c0b72e74c399bd1c4303a8b.png) ☕ ---
**Author:** ![lisaakselrod](https://avatars.discourse-cdn.com/v4/letter/l/51bf81/32.png) [@lisaakselrod](https://forum.anoma.net/u/lisaakselrod)\ **Post date:** [February 7, 2025, 1:35pm UTC](https://forum.anoma.net/t/anoma-over-a-cup-of-coffee/249/8 "2025-02-07T13:35:25Z")
Firstly, it’s impromper to read it over a cup of coffee. I’d say it should be a glass of wine, and tbh quite a good one. Otherwise it’s a waste of joyful and intellectually entertaining content. Secondly, to clarify the details that are interesting for real one might need already several bottles: 1. “Anoma allows for various runtime configurations” (and an example of batch decryption that follows right after) – how is it technically achieved? The only way that comes to my mind is VDF but afaik we don’t have anything feasible today. Of course there are more grounded tools like TEE and threshold encryption. But i am curious to know Anoma’s perspective on it from a purely cryptographical point of view. 2. Regarding the last abstract – iiuc Anoma is a modular creature that can be whatever you want it to be. From current Anoma’s journey – what is the most in-demand configuration or Anoma’s feature people utilize? p.s. if you ever host an intent house at the winery – please invite me. I am happy to talk Anoma all the way down. ---
**Author:** ![apriori](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.anoma.net/apriori/32/1655_2.png) [@apriori](https://forum.anoma.net/u/apriori)\ **Post date:** [February 7, 2025, 9:24pm UTC](https://forum.anoma.net/t/anoma-over-a-cup-of-coffee/249/9 "2025-02-07T21:24:50Z")
Welcome to the forums @lisaakselrod 😄 When I wrote this ~ 18 months ago, I was thinking [Ferveo (threshold decryption protocol)](https://github.com/anoma/ferveo). But there are other [techniques](https://anoma.net/research/privacy-in-tents) as well. The design space for programmable crypto x mechanism design is diverse. Maybe you have some ideas. There is a common design pattern in many crypto systems that has some kind of “off-chain” component, p2p network / marketplace, like private mempools + MEV-Boost in Ethereum, and “on-chain” component like smart contracts, accounts, balances. Much of the “off-chain” activity today is not programmable or legible to the Ethereum [protocol](https://barnabe.substack.com/p/seeing-like-a-protocol). Anoma is a protocol which brings the off-chain component into the protocol. This enables different design patterns for [applications](https://forum.anoma.net/t/anoma-applications/353). ---
**Author:** ![pipsandbills](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.anoma.net/pipsandbills/32/1441_2.png) [@pipsandbills](https://forum.anoma.net/u/pipsandbills)\ **Post date:** [June 30, 2025, 6:49am UTC](https://forum.anoma.net/t/anoma-over-a-cup-of-coffee/249/10 "2025-06-30T06:49:48Z")
So glad I found this forum topic and shoutout to @apriori for creating it. Started diving into Anoma in January and I have ever since read multiple papers, I would love an active discourse like this, talking about the possibiliies of the protocol