Tinyman Docs
  • Tinyman V2 Overview
  • About Tinyman
  • Protocol Specification
    • Pool
      • Pool Creation
      • Adding Liquidity
      • Removing Liquidity
    • Swap
    • Fees
    • Flash Loan
    • Flash Swap
    • Additional Notes
  • FAQ
    • Migration FAQ
  • Fees
  • Permissioned Methods
    • Roles
    • Methods
    • Related Non-Permissioned Methods
  • Formulae
  • Disclaimer
  • Contracts
  • Audits & Security
  • Token and Governance
    • TINY Token Details
    • Governance Details
      • Overview
      • Governance Vault
      • Governance Rewards
      • Governance Process
      • TINY Farming
  • V2 Integration
    • Protocol Methods
      • Bootstrap
      • Add Initial Liquidity
      • Add Subsequent Liquidity
      • Remove Liquidity
      • Swap
      • Flash Loan
      • Flash Swap
    • State Data
    • Oracle Data
    • Calculating Quotes
    • Official SDKs
  • Swap Router
    • Transaction Specification
  • Swap Widget
    • Customization Preferences
    • How to export your Widget
  • Lending Pools
  • Trigger Orders & Recurring Orders
  • Liquid Staking
    • Liquid Staking
  • Tinyman V1
    • Overview
    • Tinyman AMM Basics
      • Creating Pools
      • Slippage & Excess
      • Farming
    • FAQ
    • Fees
    • Design Doc
    • Contracts
    • Tinyman Testnet
    • Disclaimer
    • Audits
    • Security
  • V1 Integration
    • Pool Lookup
    • Transaction Specifications
      • Bootstrap Pool
      • OptIn
      • Swap
      • Mint
      • Burn
      • Redeem
      • Create Validator App
      • Redeem Protocol Fees
    • Official SDKs
    • Community SDKs
  • Tinyman Presentations
  • Known Issues
    • 2021-11-12 - Pool overflow errors
Powered by GitBook
On this page

Was this helpful?

  1. Protocol Specification

Pool

PreviousProtocol SpecificationNextPool Creation

Last updated 2 years ago

Was this helpful?

An AMM based decentralized exchange is made up of a number of ‘Pools’, with one pool per asset pair. Users can swap assets through these pools by sending some of one asset and receiving the equivalent value of the other asset.

The funds in the pools are owned by ‘Liquidity Providers’. Each liquidity provider contributes and retains ownership of a share of the pool’s funds. The liquidity provider receives ‘Pool Tokens’ to represent their share of the pool. They can reclaim their assets at any time by returning the pool tokens.

Each Pool is an Algorand Account. The accounts hold the assets and state related to the pool. A single stateful Algorand Application contains all the logic that controls the asset transfers and state management of the pools.

Each Pool has a number of local state variables which are updated during every operation. The asset reserves (liquidity) of the pool are tracked in the local state and not determined dynamically from the account balances. This means that ‘donations’ to the pool or Algo making up the minimum balance do not contribute to the asset reserves.

If assets are transferred to the pool account with transactions that are not part of a documented group the assets will be lost. These assets are called “extra” and are only transferable to the fee collector. They will not affect the liquidity of the pool or the shares of the liquidity providers.

Pool Creation
Adding Liquidity
Removing Liquidity