Pools

Deployment Policy

• Pool smart contracts can be deployed by anyone using the TON Network

• Pool smart contracts can be deployed in the Basechain

• The Pool Jetton minter smart contracts are deployed separately

• Pool deploys Payout minters and initiates them.

• The address of Pool Jetton wallet smart contract for deposit payout is calculated on Pool and passed to Deposit Payout in init message.

Security Policy

• The Pool smart contract could be stopped(paused) with Halter.

• Pool Smart Contract could be manually restored after it was stopped by Governance via Governor.

Pool Workflow

The staking pool workflow makes use of several participants that allow the system to work correctly at all times. The sequential ordered system is conducted as follows:

General workflow

Interraction	Action
Controller - Pool	Assets are lent to a Сontroller upon receiving a borrow request in accordance with the current lending rate
Controller - Pool	Assets are received and the correct profit/loss data is aggregated through a Сontroller
Staker - Pool	Manages deposits and withdrawals
Interest Manager - Pool	Sends aggregate lending round statistics
Interest Manager - Pool	Updates interest upon request from Interest Manager (each round)
Interest Manager - Pool	Interest Manager sends round profits share
Governor - Pool	Governors update specific parameters when requested: deposit params (open?, optimistic?), roles (halter, sudoer, interest_manager, governor), state (unhalt)

Validators interaction workflow

• Processing lending requests from Validator approvals whereby there is enough capital available and the request is commensurate with the desired rate and funding limit. Saves to the list of active controllers (it is expected that there will be no more than hundreds of those).

• Receiving debt repayments from Validator Controllers (which removes them from the list of active controllers).

• Account for fees: send governance fee to the Governance.

• Aggregate profit and loss data for each consensus round (denominated using the Pool Jetton/TON ratio) and send the corresponding data to Interest Managers.

Stakers interaction workflow

• The pool keeps track of the ratio of Pool Jetton/TON.

• Receiving deposits from Stakers and minting deposits and Pool Jettons on their behalf.

• Receiving Pool Jettons burn notifications (withdrawal requests) from Stakers wallets and minting Stakers wallet withdrawals (of TON) or reverting Pool Jettons burns.

• Keeping track of current round Payout overall sums (for Withdrawals and Deposits).

On aggregation event (lending round end):

• minting Pool Jetton through Pool Jetton minter and pass them to Deposit Payout minter to carry out the distribution

• sending TON to the Withdrawal Payout minter to fulfill withdrawals

Message Processing

Handlers of incoming messages

• borrow request (only from Сontroller)

• Governance requests (from Governors, Halter, Sudoer)

• debt repayment (only from Controller in the active controller list)

• deposits (from any user)

• burn notifications (from Pool Jetton wallets) bounces

Outcoming messages:

• deposits sent via a Controlle (which are inserted into an active controller list)

• aggregates profit notifications (to Interest Managers)

• fees that are paid to contribute to protocol Governance

• minting Pool Jettons (which are sent to a Deposit Payout and Nominator)

• sending TON (which are sent to a Withdrawal Payout and Nominator)

Storage

• state

• total_balance - The current total balance of TON. It is updated whenever deposits, withdrawals, or profit executions occur.

• interest_rate - surplus of credit that should be returned with credit body. Set as integer equal share of credit volume multiplied by 2**24

• optimistic_deposit_withdrawals? - flag declares whether optimistic deposit and withdrawal mode is enabled

• deposits_open? - flag declares whether deposits are open

• current_round_borrowers - current round_data

  • borrowers - dict of borrowers: controller_address -> borrowed_amount

  • round_id

  • active_borrowers - number of borrowers that haven’t returned a loan yet

  • borrowed - amount of borrowed TON (no interest)

  • expected - amount of TON expected to be returned (borrowed + interest)

  • returned - amount of already returned TON

  • profit - currently obtained profit (at the end of the round should be equal to returned-borrowed and expected-borrowed)

• prev_round_borrowers - Previous round_data

  • borrowers - dict of borrowers: controller_address -> borrowed_amount

  • round_id

  • active_borrowers - number of borrowers that haven’t returned a loan yet

  • borrowed - amount of borrowed TON (no interest)

  • expected - amount of TON expected to be returned (borrowed + interest)

  • returned - amount of TON already returned

  • profit - currently obtained profit (at the end of the round should be equal to returned-borrowed and expected-borrowed)

• min_loan_per_validator - minimal loan volume per validator

• max_loan_per_validator - maximal loan volume per validator

• governance_fee - share of profit sent to governance

• Minters Data

  • Pool Jetton minter address

  • Pool Jetton supply

  • Deposit Payout address

  • Deposit Payout supply == number of deposited TON in this round

  • Withdrawal Payout address

  • Withdrawal Payout supply == number of burned Pool Jettons in this round

• Roles addresses

  • sudoer

  • governance

  • interest manager

  • halter

  • approver

• Codes - a code of child contracts needed for deployment or address authorization

  • controller_code - needed for controller authorization

  • payout_code - needed for Deposit and Withdrawal Payout deployment

  • pool_jetton_wallet_code - needed to calculate the Deposit Payout wallet address