I have read the paper 'Anomala - Unified Architecture for Full Stack Decentralized Applications' for the third to fourth time. The biggest takeaway is still his abstract summary of BTC and ETH, as well as his positioning of design features centered on intention. The intention propagation layer (gossip network) and other features here are also distinctive, especially the value of pioneering research on intention composability, which has not yet been truly presented for application and commercial value. Since the paper is definitely quite long, I have summarized what I think is the most core and representative part of @ anoma, and tried to delete some less important information. But he is still very long. Introduction: Programmable settlement architecture cannot achieve counterparty discovery and resolution, which are necessary conditions for building most interactive multi-party applications. The architectural limitations of programmable settlement result in contemporary application protocols containing at least one Web2 component, becoming a centralized point. We propose Anoma, a unified architecture for full stack decentralized applications. Anoma follows the principles of intention centrality and isomorphic architecture/heterogeneous security, collectively forming a declarative decentralized application development paradigm. Interpretation: Firstly, the problem to be solved is defined as counterparty discovery and solution, as well as full stack decentralized dapp Background and Motivation The release of the Bitcoin protocol in 2008 marked the beginning of scriptable settlement, a distributed ledger architecture suitable for cryptocurrencies with discrete properties and monetary policies. Despite the Bitcoin script bitcoinscript ]Not Turing complete, but it can support applications beyond currency, such as Namecoin and Colored Coins. The introduction of the Ethereum protocol in 2014 pioneered programmable settlement, a new architecture category that builds decentralized applications through Turing complete virtual machine execution, greatly enhancing the expressive power of the settlement layer. Programmable settlements have paved the way for improved applications that cannot be supported by scriptable settlements, such as Interchangeable Tokens (ERC20) or Ethereum Name Service (ENS), which are mature versions of Colored Coins and Namecoin, respectively. In addition, it also supports many other ideal applications, such as non fungible tokens (NFTs), etc Although programmable settlement is sufficient for some applications, many contemporary applications have further demands. Settlement is suitable for scenarios where it has been decided with whom and why to settle, but contemporary applications often require facilities to help potential counterparties discover each other and decide with whom and why to settle. Anoma is a unified architecture for full stack decentralized applications, characterized by intention centrality, decentralized counterparty discovery, and outsourcing the computation of NP search problems to solvers for efficient state transitions. Interpretation: It provides a good abstract description of the characteristics of the most representative paradigm level solutions of BTC/ETH, as well as the features of Anoma. Architectural design philosophy Firstly, intention centrality; Next is the isomorphic protocol architecture and heterogeneous security model Intent: Sign the message, describe partial state transitions, and include state preference information (such as asset exchange or conditional transaction). The intention is partial and may not specify a counterparty, or it may be a complete state transition. Intentions can contain any code and require runtime evaluation by the settlement layer. The client broadcasts the signature intent to the intent propagation layer, and the solver or the counterparty's intent can be converted into a transaction. Intention propagation layer: a virtual sparse overlay network that propagates intentions, discovers counterparties, and solves transactions. Node broadcast intention (directed or undirected), which may include settlement condition fees, allocated to propagation nodes and solvers. Intentions can be confirmed and sorted in the data availability domain. Solver: Observe the intention and calculate the nodes of the solution, run local solving algorithms, and compete to satisfy constraints. Solvers do not have permission and can choose to handle high-value intentions by searching for combinable transactions based on settlement layer status and intention pools. Transaction: Complete state transition, following declarative programming, describing the final state rather than executing steps. The transaction is encrypted using the Ferveo DKG public key, and the consensus node decrypts it before revealing it. No need to trust intermediate execution steps, simplifying the reasoning of the submitter. Memory Pool: A virtual dense partition network for transactions, based on secure and concurrent domain partitioning, that only propagates encrypted transactions related to fractal instances while maintaining opacity. Execution environment: An algorithm that applies states and transactions to new states, supporting transparent (public), shielded (user proof of attributes through ZKP), and private (homomorphic encryption computation) state transitions. Anoma application example: Decentralized exchanges, Rollup, and various other scenarios Interpretation: Below, I will select scenes from the paper that better demonstrate the composability and coordination of intentions. Multi party and multi variable private barter scenario: Alice, Bob, and Charlie (departing from Berlin, Zurich, and Amsterdam respectively) hope to participate in a festival near Potsdam on a weekend in July. They require train tickets, hotel rooms, and festival tickets, aiming for the lowest total price. They are flexible on weekends and willing to share hotel rooms with others (if they also participate in festivals). David (hotel operator) offers single and quadruple rooms at prices that vary according to demand; Eve (festival producer) sells tickets at a fixed price but can be resold; The train ticket prices of Deutsche Bahn also fluctuate with demand. Traditional issues: Manual coordination (checking tickets, hotels, trains, creating spreadsheets) is inefficient and may result in resource unavailability due to other travelers booking, or cancellation fees due to some bookings (such as hotels) not matching other parts (such as train tickets). Anoma Solution: Intention expression: All parties create intentions, Description preferences: Alice, Bob Charlie: Obtain train tickets, hotel rooms, and holiday tickets for a certain weekend, with the lowest total price, and accept shared rooms (condition: cohabitants are holiday participants). David: We offer single/quadruple rooms at prices that vary according to demand. Eve: Selling holiday tickets at a fixed price or for resale. Deutsche Bahn: Provides train tickets, prices vary according to demand. Intend to submit in opaque byte string format to protect privacy. Advantages: Atomicity: All conditions (train tickets, hotels, tickets) are met at once to avoid partial booking failures. Privacy: requires transparency, identity confidentiality, and is suitable for multi-party coordination. Flexibility: Supports complex preferences (such as shared rooms, dynamic pricing) and diverse applications (token trading, AMM, auctions). Efficiency: Solver competition optimizes matching, reducing manual coordination and resource competition issues. Official GitHub address for the paper: https://(GitHub)/anoma/whitepaper/blob/main/whitepaper. pdf