Scenarios
Pool deployment is triggered by the administrator of the AMM (this person is also the administrator of the router contract - router::admin_address) or by specific roles - pool factory (router::pool_factory_address) and pool admin (router::pool_admin_address). It is done by invoking the operation . Pool deployment leads to the processing of the operation inside the pool contract. This operation is used both - during the initial pool deployment and when the pool administrator wants to change some crucial parameters. Pool deployment consists of two stages
I. Forming and sending state_init data that holds
Router address
Jetton0/Jetton1 wallet addresses (these are attached to the router)
contract code
contract code
Next newly created pool would only accept the init message from the router and admin(which is set to BLACK_HOLE_ADDRESS in state_init). No operations (except for ) would be processed while the administrator address equals BLACK_HOLE_ADDRESS.
This ensures that the only thing that could activate the pool is the init operation sent by the pool
II. state_init message holds as a body operation
This message will be accepted and sets all the data that is needed for pool operation, including an optional flag that would activate the pool and make it available for mints and swaps.
Pool factory is expected to be a contract callable for anyone. It checks on-chain data validity for pool creation. The pool created by pool factory can only have a predefined number of fee and tick spacing settings
Position minting is done by sending two jettons to the router. Generally, the user calls pool::getMintEstimate to estimate the number of jettons that the person needs to send to mint a particular amount of liquidity in the given price range (tick range). Optionally, the user may send more jettons than needed to account for possible slippage.
While sending both jettons to router wallets, the user sends the payload that contains the position parameters. On receiving the jettons (operation ) router would compute the pool address and forward the operation to the pool ()
The pool uses a special structure - user Account () to create a barrier that would collect the proof that two jettons are funded and order to mint liquidity and then send it back to the pool for actual mint execution
Generally user calls to estimate the amount of the jettons that he/she needs to send to swap and then sends jettons to the router with a payload describing the future swap. The router forwards the swap to the pool by dynamically computing the pool address.
