A decentralized exchange using an Automated Market Maker (AMM) model operates through various “Pools,” with each pool dedicated to a specific pair of assets. Users can trade between assets by sending one type of asset to a pool and receiving an equivalent value of the other asset in return.
The assets within these pools are supplied by “Liquidity Providers.” These providers contribute funds to the pool and retain proportional ownership of the pool’s assets. In exchange, they receive “Pool Tokens,” which represent their share. Liquidity providers can redeem their assets at any time by returning the pool tokens.
Each Pool corresponds to an Algorand Account. These accounts manage the pool’s assets and state. A single stateful Algorand Application governs all logic related to asset transfers and state management for the pools.
Each pool uses local state variables to keep track of operations, including the asset reserves (liquidity), which are updated with every transaction. These reserves are explicitly recorded in the local state, rather than inferred from account balances. Consequently, any “donations” to the pool or Algorand’s minimum balance requirements do not affect the calculated asset reserves.
Assets sent to a pool account through unrelated transactions—those not part of an authorized group—are considered “extra” and cannot be used to increase the pool’s liquidity or the shares of liquidity providers. These extra assets can only be transferred to the designated fee collector.
Pools are established through a two-step process: Bootstrap and Add Initial Liquidity.
Each pool is implemented as a Smart Signature Contract Account. While the Smart Signature is based on a standard template, it is customized for each pool by embedding the unique identifiers of the specific asset pair it represents.
At LEMA Center, the process of transforming an account into a pool involves an Application Call transaction to the AMM application. This transaction opts the account into the application and rekeys the contract account to the AMM application’s control.
Initially, the transaction must be authorized by the account’s Smart Signature. Once the transaction is completed, the Smart Signature loses authority over the account, as it is rekeyed to the AMM application, which then assumes full control of the pool account.
As part of the Bootstrap operation, the application creates the Pool Token asset and transfers its entire supply to the pool account using Inner Transactions. All Pool Token assets are generated by the application account, ensuring a single, consistent creator address for LEMA Center AMM pool tokens. The pool account itself is designated as the Reserve address for these Pool Tokens.
The Bootstrap operation requires a certain amount of Algo to meet the pool account’s minimum balance requirements , the 100,000 micro-Algo fee for asset creation, and transaction fees. This Algo must be deposited into the pool account before the Bootstrap Application Call, typically as part of the same transaction group, although this is not mandatory.
Adding funds to the pool involves combining Asset Transfer transactions with an Application Call to the AMM application. The pool uses an inner transaction to issue Pool Tokens to the user as a representation of their share in the pool. There are two distinct approaches for contributing liquidity to the pool.
When there is a no pool , the first user to provide liquidity has the freedom to define the ratio between the two assets. However, if the pool already contains liquidity, this transaction will be rejected, and the user must follow the Adding Subsequent Liquidity method instead.
The protocol allows users to add liquidity flexibly, meaning they don’t need to supply assets in the exact proportions of the current pool ratio. Instead, users can provide liquidity on a spectrum ranging from matching the current ratio to contributing entirely in a single asset. If the supplied assets deviate from the pool ratio, the protocol performs internal implicit swaps to balance them. A swap fee is applied to the portion of assets that are swapped, and this fee is deducted from the Pool Tokens the user receives.
When liquidity is added precisely at the current pool ratio, no swap fee is applied, and Pool Tokens are issued for the full value of the assets provided.
If the user provides liquidity at a ratio different from the pool’s current ratio, they should consider the potential loss of value caused by both price impact and swap fees. To address this, users can estimate the expected value of Pool Tokens after accounting for these factors and set a min_output parameter. This ensures the Pool Tokens received meet their expectations, protecting them from unexpected price changes that may occur between signing and completing the transaction
Liquidity providers can remove funds from the pool with an Asset Transfer of pool tokens and an Application Call.
Amounts of each asset are sent to the user by the pool using two inner transactions. The amount of each asset received is proportional to the pool tokens returned and dependent on the current ratio of the pool
Swaps are executed by combining an Asset Transfer transaction with an Application Call to the AMM application.
The pool sends the corresponding amount of the other asset to the user using an inner transaction.
Swaps can be of two types: fixed-input or fixed-output. In the case of a fixed-output swap, an additional inner transaction is used to return any unused portion of the input asset back to the user. This makes fixed-output swaps slightly more expensive in terms of transaction fees due to the extra transaction.
A swap fee is applied to all swaps, calculated as basis points per pool. This fee is deducted from the input amount before the swap formula determines the output amount.
Swaps include a slippage tolerance feature to account for potential changes in the exchange rate between the time a swap is initiated and when it is executed.
In a fixed-input swap, the minimum acceptable output amount is specified in the Application Call arguments. If the actual output amount falls below this threshold, the swap will not proceed.
For a fixed-output swap, the slippage tolerance is factored into the input amount, while the exact desired output amount is specified in the arguments. If the calculated input amount required to achieve the target output is greater than the provided input, the swap fails. Conversely, if the required input is less than the provided amount, the excess is returned to the user through an inner transaction.
LEMA Center collects fees on swaps, loans, and internal swap operations. These fees are divided between the protocol (Tinyman) and liquidity providers, with the latter’s portion being added to the pool reserves.
Each pool has configurable parameters for the fee rate and the fraction allocated to the protocol. The total fee rate can range from 0.01% to 1% (1 to 100 basis points), while the protocol’s share can range from 1/3 to 1/10 of the total fee. By default, the fee rate is set to 0.3%, with 1/6 (or 0.05% of the input) allocated to the protocol.
Pools use a single fee rate for all swaps, loans, and internal swap operations.
Protocol fees accumulate in both assets and can be claimed at any time by any user who submits the appropriate Application Call. Once claimed, the accumulated fees are transferred via inner transactions to the fee collector, which is defined by a global state variable (fee_collector). This address can be updated by the global fee_manager.
The fee parameters can be adjusted by the global fee_setter, which itself is controlled by the global fee_manager. The fee_manager address can be updated by its current holder, ensuring hierarchical control over fee configurations.