Anoma & Intents

@WinterSoldierxz
October 2023
A Primer on Intents

Intents are commitment based authorizations over a future state.

● It concerns over the ʻwhatʼ and not the ʻhowʼ

Users retain custody of all their assets, but the complexity of interacting with blockchains is abstracted away and
pushed towards sophisticated third party agents known as solvers. With the major motivation here to simplify
UX, where the user only needs to think about future state changes you want
Intents arenʼt just limit orders
If the above description sounds familiar, thatʼs because intents already exist today, examples include:

1. Limit orders
2. ERC4337 Account Abstraction: Batch transactions, paymaster gas sponsorship
3. Yield Aggregators: Offer the best yield given constraints
4. DEX Aggregators: Offer the best swap route given constraints
5. Seaport NFT trading: Sell my NFT if the bid matches my ask

Other potential use cases:

1. Gas Sponsorship: Pay gas in USDC instead of ETH. The intent can only be fulfilled with a matching intent which pays ETH in fees.
2. Delegation: Only allow interacting with certain accounts in certain pre-authorized ways. The intent can only be fulfilled if the final
transaction respects the access control list specified in the intent.
3. Transaction Batching: Allow batching of intents for gas efficiencies.
4. Crowdfunding: commit to fund a project only if it receives more than X commitments; pre-commit donations to a winning project
(Gitcoin matching funds), commit to fund a campaign only if your favorite influencer funds it (Peer pressure)
5. OTC NFT trading - advanced preference such as willing to trade NFT A for NFT B of a certain rarity or above, but also willing to take 3 ETH
for it
6. Multilateral Trade Credit Set-Off (MTCS): MTCS, also known as obligation clearing, is a unique and powerful technique to save liquidity
in an economy.
7. Privacy preserving applications
Anoma intents

Anoma defines intents as binding commitments of preference over future state change(s). They are signed off-chain
messages that authorize one or more future states.

For example, the signer of [-2000 USDC, +1 ETH] intent declares “I authorize any future state where I have 1 more ETH and
2000 less USDC and I donʼt really care how that may happen.”
Anoma is an architecture, not a blockchain

Anoma is an architecture for blockchains. It is a framework, not a blockchain. Networks that implement the Anoma architecture is known as a
fractal instance of Anoma

Confusingly, the first planned fractal instance for Anoma will be also called “Anoma”

Anoma L1 is a PoS Blockchain built on the Cosmos SDK that will be the first implementation of the Anoma architecture

Anoma can also be deployed as:

- Layer 1s: Sovereign chains such as the Anoma L1

- Layer ʻ1.5ʼ: To decentralize specific applications that benefit from specific Anoma features (e.g. decentralized counterparty discovery) &
keep anchor on the same settlement layer.
- Layer 2s: Deploy the anoma state machine to a settlement layer like Ethereum
Anomaʼs Architecture
An Anoma tx lifecycle looks as follows: users sign intents → intents are gossiped in the p2p layer → solvers match compatible intents and form
txs (counterparty discovery & solving) → txs are settled on-chain.
Counterparty Discovery

Intent gossip layer

Matched intents
become
User Node 1 Node 2 Solvers transactions
Sign intent Read and match intents and sent to the
mempool

Node 3 Node n

Not all nodes will have Solvers can use any method to match intents, including but not limit to:
a view of all intents - ● Solvers Bringing Their Own Liquidity: Solvers become the
these nodes can counterparty to the trade by acting as a taker.
specialize in specific ● Partial Fills: A token being sold is bought by many independent
intents, such as ERC20 parties collectively.
transactions, ERC721 ● Direct CoWs: Two intents are direct inverses of each other.
transactions, or be ● Ring Trades: Intent can be solved even without the presence of
specific to certain direct CoWs. For example, 3 intents produce a balanced tx, even
applications. though no pairs of intents satisfy each otherʼs preferences
Solver incentivization, censorship, DoS resistance

Anomaʼs gossip system provides path authentication: the receiver of a message can verify a chain of signatures recursively back all the way to
the original sender, such that each party in the message chain can be verified to have authorised the next send, and can be both potentially paid
for participating in gossip and held accountable for inconsistent ordering across messages.

Node 1 Node 2 Node n

Intent + Sig 1 Intent + Sig 1 + sig 2

Receives
intent

At Settlement : Transaction is completed with a chain of signatures that can be traced back from node n to node 1
Privacy and information flow

In most cases in crypto, all user activity information is exposed to all on-chain observers, this fundamentally limits privacy preserving use cases.
Anoma uses a unified execution environment known as Taiga

Taiga offers composable privacy: developers

can ship applications and have users interact
Transparent Intent Shielded Intent Private Intent with the same application via transparent,
shielded, or private intents. This makes
privacy a user choice in contrast to an
application/infrastructure choice
“The who” Exposed Hidden Hidden

There exists a tradeoff between counterparty

discovery and privacy:
Partly hidden with TEEs, ● Intents that hide information about
“The what” Exposed Exposed to provers FHE etc. (still under the “what” can be processed more
development)
failr but have a harder time finding
counterparties
“The what” is hidden
● In a free market, solvers can price
The observer from on-chain observers
Everyone Everyone transparent, shielded, or private
but exposed to off-chain
zk prover(s) intent solving differently based on
quality of execution
Execution and Verification

For transactions to settle, they need to be verified on-chain. The verification is done by on-chain functions known as predicates.
Each account in Anoma has an associated predicate, which constrains the set of possible future states authorized by that account.

Examples: Predicates vs Intents Predicates vs Smart contracts

● Whitelist/blacklists ● Intents live off-chain as temporary ● Predicates and smart contracts

● Volume limits expression of preferences
● Access control (2 of 3 accounts ● Predicate live on-chain as
must sign a transfer) persistent expression of
preferences (although they can be
updated at any time)
both live on-chain
● Predicates are only concerned with
verification and not execution,
where as SCs are mainly concerned
with execution

The main role of predicates is to ensure atomic (all or nothing) settlement.In order for a tx to settle and
advance the on-chain state, the tx must satisfy predicates of all accounts it touches.