# Smart Contracts ## The Pool and Pool Token contracts \ ​‌ ![The Pool and Pool token smart contracts](https://gblobscdn.gitbook.com/assets%2F-M-A8-UkkLv19w_JOqfw%2F-M7cBLVfdXs6oIY6CI-8%2F-M7cBmBjhu_UwNsfLsMR%2FPool%26Pol%20token.jpg?alt=media\&token=fe62d3d1-e74d-4f14-86c3-7f88256bc286) **Pool Token** is just a regular OpenZeppelin token contract. We did not modify it. It mints Pool Tokens against the back tokens received from Liquidity Providers (in our case, a back token is DAI). The contract burns tokens when Liquidity Providers withdraw their DAI from the Pool. Keeper Adapter operations are not accompanied by any change in the Pool Token supply. \ \&#xNAN;*Pool token exchange rate* to back token should be set at the Pool deployment by sending some amount of back tokens to the Pool contract. That will be the amount for a single Pool Token. In our case if we want to set 1 to 1 rate we should send a single DAI. If we send 0.5 DAI the rate will be two Pool Tokens for a single DAI.‌ The **Pool** **Contract** performs a set of core functions to keep the whole protocol work. It enables Liquidity Providers to join the Pool and exit from it. A Pool Contract also forms a queue of withdrawal requests when there are active auctions or an active queue. In addition, Pool Contract allows authorized adapters to take liquidity from the pool within their allowances and provides some other important functionality. The main public methods of the contract are the following: \ \- `join` helps to receive a back token amount (DAI in our Pool) sent to the contract by a Liquidity Provider. At the same time, **PoolToken** mints an equivalent amount of Pool tokens. \ \- `exit` is an opposite function to `join` and redeems Pool Tokens for back tokens. \ \- `addWithdrawRequest` is used to put a back token withdrawal request (in a Pool Token amount) in the queue if there is a lack of liquidity in the Pool due to active auctions. \ \- `removeWithdrawalRequest` is used to cancel a specific request by its ID from the queue. \ \- `processWithdrawQueue` will check if there is enough liquidity in the Pool to start payments for withdrawal requests one by one. If there is enough liquidity, the method will also perform withdrawals. \ \- `withdrawQueueIsActive` checks if there are any pending withdrawals in the Pool. \ \- `allocate` enables an authorized Keeper Adapter (by its ID) take a back token amount from the Pool within the allowance and put this amount to the Maker JOIN\_DAI contract to use for bids in auction(s). \ \- `payback` is opposite to the `allocate` method. A Keeper Adapter uses the method to return a back token amount from Maker (or from an Exchange in case of the won lot) to the Pool. \ \- `poolTokenTotalSupply` provides the current amount of outstanding Pool tokens. \ \- `poolBackTokenBalance` provides the current amount of liquidity in the Pool (in a back token). \ \- `availableAmountToWithdraw` provides the current balance of the Pool (in a back token) free of the amount taken to auction(s). ## Registry Contract ![A registry smart contract](https://gblobscdn.gitbook.com/assets%2F-M-A8-UkkLv19w_JOqfw%2F-M7cBp1TMcKTO96IuyUT%2F-M7cBuhEtWkM6yg-AzE1%2FRegistry.jpg?alt=media\&token=ba108e91-1e5c-47df-8205-3341ab33c416) This contract can register any smart contract added to the platform and, thus, authorizes them. A Registry Contract also allows for updating/ switching between contracts real time for the Pool purpose. For example, to change a bidding strategy from the currently used to a more suitable for actual market conditions during an auction, it is possible to switch from a contract with the current bidding strategy to the contract with some other one. It is also possible to switch between exchanges to be used to sell collateral. In a Registry Contract, adapter contracts (a Keeper Adapter, an Asset Manager, etc.), service contracts (a bidding strategy, an exchange, etc.), and core contracts (Pool, Pool Token) can be registered. This contract has two major methods: \ \- `setContract` adds a new contract to the Registry with a contract name and its address. \ \- `getContract` finds the contract added to the Registry by its name. ## Keeper Adapter Contract ![A Keeper Adapter smart contract](https://gblobscdn.gitbook.com/assets%2F-M-A8-UkkLv19w_JOqfw%2F-M7cBwaka8vZVezuhe-M%2F-M7cC04-xT0z-63KXQdz%2FKeeper%20Adapter.jpg?alt=media\&token=15120c58-53ca-4922-b642-66654180b602) The main purpose of a Keeper Adapter smart contract is to participate in Maker vault collateral liquidation auctions. This happens through making bids in DAI (a Pool Base Token) previously taken from the Pool and placed to the Maker's "JOIN\_DAI" contract. \ Keeper Adapter Contract uses three major methods related to auctions: \ \- `kick` is used to start an auction by "kicking" an undercollateralized vault. \ \- `bet` is used to make bids in auctions. \ \- `take` gets the won lot (or a Base Token amount from JOIN\_DAI contract) from Maker. --- # Agent Instructions: 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: ``` GET https://docs.atomica.org/atomica-liquidation-markets/developers-documentation/smart-contracts.md?ask= ``` The question should be specific, self-contained, and written in natural language. 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.