> For the complete documentation index, see [llms.txt](https://hummus-exchange.gitbook.io/hummus-exchange/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hummus-exchange.gitbook.io/hummus-exchange/welcome-to-hummus-exchange/next-gen-protocol-design.md).
# Next-gen protocol design
The key concept underpinning Hummus Exchange design is asset liability management (ALM). Most DeFi protocols today do not use the concept of liability.
For instance, once liquidity providers have made deposits, they will be given the ”LP Tokens” which represent a partial ownership of a pool. However, pools are often composed of multiple assets, and any user actions may change the relative percentage of tokens ratio in a pool. Consequently, liquidity providers may find that upon withdrawal, they will get a different amount to what they have deposited.
> Compared to a current generation Automated Market Maker, Hummus Exchange is different in that liability is recorded. Upon deposit, liquidity providers will be given LP tokens to specify the exact amount and the exact token that they have deposited. As a result, if the system is liquid, they will get back the exact amount of the same token upon withdrawal + token emission.
By introducing the concept of ALM, Hummus Exchange allows each token to grow organically based on its natural supply and demand. This is notably different from Curve which requires all tokens to have the same liquidity, thus making the least popular token the bottleneck for the growth of the pool. We refer to this design as “Extendable Liquidity Pool”.
This design also allows Hummus Exchange to enjoy other benefits such as a method to track its financial health, ability to lend out idle assets, enabling of new stablecoin solutions, and removal of impermanent loss.
### Paradigm Shift
The function for Hummus Exchange is to define the price slippage instead of the price itself, additionally, Hummus Exchange uses a **single-variant slippage function** instead of invariant curves. The ability to measure risk metrics using a single variable is one key reason why Hummus Exchange can get rid of the intertwinement of invariant curves, thus expanding its services into different verticals like lending and stablecoin.
### Liquidity providers
Hummus Exchange allows users to provide **unilateral liquidity**. Instead of pools of token pairs and bundles, Hummus Exchange uses accounts of tokens to record assets and liabilities, **allowing single-sided liquidity provision**.
Hummus Exchange also uses coverage ratio as the input parameter for our AMM (instead of liquidity), hence removing the same liquidity equilibrium constraint from Curve’s stableswap invariant, allows token to grow organically based on its organic demand and supply.
This design also allows new tokens to be added into an existing pool, greatly enhancing the scalability and capital efficiency of the protocol. For example, while the protocol may start with 3 base tokens (USDT, USDC, DAI), we may gradually add more tokens into the big pool (such as MIM) for shared liquidity.
### Asset listing & Governance
Hummus Exchange design requires special attention to asset listing. At launch, listing new tokens will be subjected to the team’s approval. Later on, HUM token holders will be able to govern parameters such as fees, asset listings and asset risk parameters, token inflation and liquidity mining schedules.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://hummus-exchange.gitbook.io/hummus-exchange/welcome-to-hummus-exchange/next-gen-protocol-design.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.