Assessment reports>Tradoor>Threat Model>Contract: TON Pool

Contract: TON Pool

The TON pool contract is largely identical to the USDT pool contract. The following noteworthy but trivial differences between the two can be observed:

  • the TON pool has no ClaimProtocolFee message; it is replaced by the WithdrawFee message

  • the TON pool CancelLiquidityOrder, ExecuteLiquidityOrder, CancelPerpOrder, ExecutePerpOrder, LiquidatePerpPosition message do not have a field to specify the fee receiver

  • the following fee parameters have no default value declared in the TON pool contract:

    • lpMinExecutionFee

    • perpMinExecutionFee

    • minStorageReserve

Additionally, since the TON pool uses native TON currency instead of USDT jettons as collateral for orders, handling of incoming assets and the flow for initiating orders to increase LP and perpetual positions have significant differences. Unlike the USDT pool, the TON pool JettonTransferNotification handler accepts messages from the tlpWallet, the wallet for the LP jetton controlled by the pool. Messages from this address are automatically assumed to request a decrease of the liquidity position. All other messages are rejected, returning the incoming jettons to the sender.

Jetton operations to request an increase of a position were replaced by messages as follows:

  • OP_CREATE_INCREASE_LP_POSITION_ORDER for the USDT pool is replaced by the CreateAddLiquidityOrder message in the TON pool

  • OP_CREATE_INCREASE_PERP_POSITION_ORDER for the USDT pool is replaced by the CreateIncreasePerpOrder message in the TON pool

  • OP_INCREASE_AUM for the USDT pool is replaced by IncreaseAum in the TON pool

The TON pool also calculates execution fees differently, since executing orders which use TON as collateral instead of USDC jettons requires different messages (and different costs) to transfer the collateral.

Lastly, we note that the TON pool LiquidatePerpPosition message contains a liquidationFeeReceiver field which is not actually used to send any liquidation fees. We could not determine whether this is a remnant of a previous version or the skeleton of a future change, but do not consider this an exploitable issue on its own.

Zellic © 2025Back to top ↑