Protocol Architecture Description
Introduction
Pool smart contracts are a central component of asset lending on the TON Liquid Staking protocol.
Pool
Definition and function
The Pool (Pool Central Contract) is the main driving architectural framework of the TON LSt protocol and the main arbiter that lends assets to Controllers and aggregates profit/loss information from them.
Interaction with Controllers
The Pool Contract caters to Controllers (Validator Controllers) by lending assets according to the current Interest Rate when a borrowing request is received.
Interaction with Stakers (also Users, Nominators)
Stakers represent regular users - holders of TON funds. The Pool contract is designed to safely manage Stakers' deposits and withdrawals.
Interaction with Interest Managers
The Pool is continuously connected with the Interest Manager and helps provision important data for the protocol.
The Pool forwards a share of the profits to the Interest Manager and updates deposit parameters and roles upon request.
The Interest Manager dispatches aggregate lending statistics and modifies interest rates upon receiving a request from the Interest Manager.
Interaction with Governor
Governor helps provide equitable Governance of the TON LSt Protocol. Because of this fact, Governor is in continuous communication with the Pool Central Contract.
To provision the equitability of the liquid staking protocol, Governance DAO helps decide key parameters (such as setting protocol fees, interest rates, and more) through governance voting. This framework leverages the voting power of governance token ((jetton, but not Pool Jetton)) holders to make protocol and ecosystem decisions based on voting weight.
Pool Jettons
Pool Jettons represent a collateralized asset Stakers receive in exchange for depositing TON into the TON Liquid Staking protocol. Pool Jettons are used to provision the management of user assets lent to specific liquidity pools within the protocol.
Payouts (Bills)
Deposits and withdrawals serve as the lifeblood of asset transactions on the protocol. While employing strict mode we presume that the Pool Jetton to TON ratio is unknown until the consensus round ends, postponing the actual transactions. However, the optimistic mode can be used as long as measures are in place to mitigate misbehaving validators.
Governance Components (Roles)
Halters
Halters act as an emergency safeguard for the TON Liquid Staking protocol and are capable of halting the protocol's operations in case of major system issues.
It is a role, which needs to be a hot wallet (private key stored in memory). It is a special role needed only during initial deployment while audits and practice still didn't prove 100% safety. In the long run, this role should be disembodied.
Sudoers
While initially empty, Sudoers gain the ability to send arbitrary messages from various parts of the system.
It is a special role that is needed only in emergency situation or for critical updates. This mechanism should be used for fixing bugs and vulnerabilities. This role should be empty most of the time. There is also a quarantine after setting this role to protect against hostile transfer(expected to be 24 hours).
Approvers
Approvers grant approvals to Controllers when they initiate an in-protocol borrowing request to ensure overall system integrity and compliance.
It decides and enforces whether Pool validators follow decentralization and safety measures set by Pool Governance, and thus can be simple wallet or multisignature wallet in the long run.
Interest Managers
Interest Managers receive validator round statistics and update interest parameters to enable dynamic interest rate management (changes in interest rates that will be available for loans).
Interest Manager can start as a simple wallet as well. However, provided that this actor receives all necessary information on-chain, in the future it is expedient to pass the Interest manager role to an automatic smart contract.
Governor
Governors represent the protocol’s main DAO governance contract used to set and manage the other governance components (this process is provisioned through TON token governance voting).
Governor can be single operator wallet (or better multisignature wallet) at the start which should upon protocol settling be passed to DAO.
To protect against the hostile transfer of Governance, such transfers are executed in two steps: first governance needs to declare governance_update_after
time (it should be after some period of time) and then Governance can be transferred after that.
Last updated