Skip to main content
This page contains extensive information about custom entities used in communication with/in-between swap.coffee DEX contracts.

Types

AMM

Defines AMM strategy type of the pool.

AMM Settings

Some AMM strategies require additional settings whenever pool with such strategy is about to be created. Person who initiates this process must provide AMM settings cell within the transaction. Please, keep in mind that non-Constant Product pools may be created by the DEX administration only.

CurveFi Stable

Asset

Defines asset type (and metadata) to work with.

native

Used for TONcoin.

jetton

Used for any jettons.

extra

Used for extra currencies.

DepositLiquidityCondition

Defines condition, which will be checked whenever contract receives liquidity deposition request. If it fails, transaction will be reverted.

none

Equivalent to no-condition.

lp_quantity

Allows to set minimum quantity of LP tokens you will get in return after liquidity deposition happens. If real quantity is lower than the given one, transaction will be reverted.

reserves_ratio

Allows to check pool reserves ratio before your liquidity deposition happens. In other words, all of the following formulas must be true:
  • reserves1 / reserves2 >= min_nominator / denominator
  • reserves1 / reserves2 <= max_nominator / denominator

complex

Just a combination of lp_quantity and reserves_ratio.

WithdrawLiquidityCondition

Defines condition, which will be checked whenever user tries to withdraw already provided liquidity from the pool. If it fails, transaction will be reverted (and LP tokens will be minted back). Subtypes are very similar with DepositLiquidityCondition ones.

PoolParams

Used to uniquely identify the pool. Only one pool can exist for given asset-pair, AMM type and AMM settings.

PublicPoolCreationParams

Params that may be publicly used for new pools creation:

PrivatePoolCreationParams

Params that may be used for new pools creation by DEX administration only:

PoolCreationParams

Params for new pools creation.

NotificationDataSingle

Defines where to send (and with how much gas) custom payload for various actions within DEX. If receiver is none, it’s considered being equal to transaction recipient.

NotificationData

Defines how to handle notifications (custom payloads) in none of, one of or both scenarios of successful/failed execution.

PoolUpdateParams

Defines pool’s parameters that may be updated by DEX administrator.

SwapParams

Defines parameters that are essential for all (multi-hop) steps of single swap transaction:

SwapStepParams

Defines parameters that are unique for every (multi-hop) step of swap transaction:

SwapStepInternalParams

Same as SwapStepParams, but is being used in inter-contract communication.

PoolReserves

Defines reserves of the pool.

DepositLiquidityParamsTrimmed

Defines parameters required for liquidity provisioning. This exact entity is being used in inter-contract communication and lacks some of extra information (see below).

DepositLiquidityParams

Extended version of the previous one. Pool parameters are used to identify the pool.

WithdrawLiquidityParams

Defines parameters that may be specified by user when withdrawing already provided liquidity (by burning his LP tokens). This exact entity is being used as a custom_payload within burn message.

ContractUpdate

Entity used in administrative action of contract updates.

Messages

SwapNative

Must be sent by user to the Native Vault to initiate swap transaction.

SwapJetton

Must be sent by user to the corresponding Jetton Vault as a forward payload of a jetton-transfer message to initiate swap transaction. Query ID, jetton and it’s amount are being determined internally from jetton transfer notification and therefore mustn’t be present here.

SwapExtra

Must be sent by user to the corresponding Extra-Currency Vault to initiate swap transaction. Extra-currency and it’s amount are being determined internally from the vault type and extra-currencies dictionary within the message.

SwapSuccessfulEvent

Is being sent by the pool as an external outgoing message whenever swap step completes successfully. This message occurs after payout is guaranteed to happen, but before it actually happens.

SwapFailedEvent

Is being sent by the pool as an external outgoing message whenever swap step completes badly (i.e. it was slippage tolerated or deadline exceeded). This message occurs after payout (of the input asset) is guaranteed to happen, but before it actually happens. Despite the fact that message itself does not contain failure reason, it may be determined as an exit code of the TVM.

CreatePoolNative

Must be sent by user to the Native Vault as a part of pool creation (and it’s initial liquidity provisioning).

CreatePoolJetton

Must be sent by user to the corresponding Jetton Vault as a part of pool creation (and it’s initial liquidity provisioning). This message must be included as a forward payload to the jetton-transfer message. Query ID, jetton and it’s amount are being determined internally from jetton transfer notification and therefore mustn’t be present here.

CreatePoolExtra

Must be sent by user to the corresponding Extra-Currency Vault as a part of pool creation (and it’s initial liquidity provisioning). Extra-currency and it’s amount are being determined internally from the vault type and extra-currencies dictionary within the message.

DepositLiquidityNative

Must be sent by user to the Native Vault as a part of liquidity provisioning process.

DepositLiquidityJetton

Must be sent by user to the corresponding Jetton Vault as a part of liquidity provisioning process. This message must be included as a forward payload to the jetton-transfer message. Query ID, jetton and it’s amount are being determined internally from jetton transfer notification and therefore mustn’t be present here.

DepositLiquidityExtra

Must be sent by user to the corresponding Extra-Currency Vault as a part of liquidity provisioning process. Extra-currency and it’s amount are being determined internally from the vault type and extra-currencies dictionary within the message.

DepositLiquiditySuccessfulEvent

Is being sent by the pool as an external outgoing message whenever liquidity provisioning step completes successfully. This message occurs after LP tokens payout is guaranteed to happen, but before it actually happens.

DepositLiquidityFailedEvent

Is being sent by the pool as an external outgoing message whenever liquidity provisioning step completes badly (i.e. it’s condition check failed or deadline exceeded). This message occurs after payout (of provided assets) is guaranteed to happen, but before it actually happens. Despite the fact that message itself does not contain failure reason, it may be determined as an exit code of the TVM.

LiquidityWithdrawalEvent

Is being sent by the pool as an external outgoing message whenever somebody withdraws previously provided liquidity. This message occurs after payout is guaranteed to happen, but before it actually happens.

WithdrawDeposit

Must be sent by the user to the PoolCreator or LiquidityDepository if only one of 2 liquidity provisioning transactions succeeded and user decides to cancel previously initiated process. As a result of this message execution, all half-way deposited funds will be returned back to the user.

Burn (liquidity withdrawal)

To withdraw liquidity, user simply needs to burn his LP tokens by sending the following message to his LP jetton wallet, according to jetton standard:
Although this scheme includes a custom_payload, regular jetton wallets do not support it, and therefore there is no way for user to provide any extra data related to token burning. That’s why we slightly modified code of our LP jetton wallets, and they support custom_payload. If needed, user may use it, passing WithdrawLiquidityParams as a custom_payload.

Miscellaneous

Payout

Is being sent by the Native Vault and Extra-Currency Vaults in some cases. More specifically, it occurs if:
  • Operation was initiated without notifications (custom payloads)
  • Operation was initiated with notification, but it’s recipient differs from the wallet that receives funds
It means that in a situation when operation was initiated with notification, but it’s recipient is the same as the one who receives funds, this message won’t be created.

CreateVault

Must be sent by a user to the Factory in order to create new vault.

Notification

Serves as a wrapper for any outgoing messages proposed by transaction initiator as a marker of operation completion status. Therefore, is being sent by Vaults or Pools after operation completes.

Inter-contract communication

SwapInternal

For any first step of swap transaction, this message will be sent from Vaults to the Pool. For any intermediate steps of swap transaction, it will be sent from one Pool to another.

PayoutInternal

Is being sent by Pools to the Vaults every time Pool decides that a payment must happen. Keep in mind that there’s no asset defined in the message, because it can be determined by the Vault data.

Deploy

Is being sent by Factory every time it decides to deploy a new contract.

CreatePoolCreatorRequest

Is being sent by Vaults to the Factory at the moment somebody tries to create new pool. Keep in mind that there’s no asset defined in the message, because it can be determined by the Vault data.

CreatePoolCreatorInternal

Is being sent by the Factory whenever it’s about to deploy new PoolCreator. Properties are pretty much the same with CreatePoolCreatorRequest.

CreatePoolRequest

Is being sent by the PoolCreator to the Factory when it’s time the uninitialize PoolCreator and deploy a Pool. Properties are pretty much the same with CreatePoolCreatorRequest.

CreatePoolInternal

Is being sent by the Factory whenever it’s about to deploy new Pool. Properties are pretty much the same with CreatePoolCreatorRequest.

CreateLiquidityDepositoryRequest

Is being sent by Vaults to the Factory at the moment somebody tries to deposit liquidity to some pool. Keep in mind that there’s no asset defined in the message, because it can be determined by the Vault data.

CreateLiquidityDepositoryInternal

Is being sent by the Factory whenever it’s about to deploy new LiquidityDepository. Properties are pretty much the same with CreateLiquidityDepositoryRequest.

DepositLiquidityInternal

Is being sent by the LiquidityDepository to the Pool when it’s time to uninitialize LiquidityDepository and execute liquidity provisioning on the Pool side. Properties are pretty much the same with CreateLiquidityDepositoryRequest.

CreateVaultInternal

Is being sent by the Factory whenever it’s about to deploy new Vault.

UpdatePoolInternal

Is being sent by the Factory to the Pool whenever it receives administrative request to do so.

ActivateVaultInternal

Is being sent by the Factory to the Vault whenever it receives administrative request to do so. When Factory creates new Jetton Vault, it internally initiates process of determining it’s own jetton wallet’s address. It is required to ensure security later on, but unfortunately in order to obtain that address Jetton Vault needs to ask Jetton Master for it. Not all Jetton Masters support such thing on-chain, therefore for some older jettons administrative affection is required.

WithdrawInternal

Is being sent by the Factory to the Pool whenever it receives administrative request to do so. Upon receiving such a message, Pool checks whether administrator is trying to withdraw not more than stored amount of collected protocol fees. If so, it sends payout command to the Vault to fulfill initial request.

UpdateContractInternal

Is being sent by the Factory to any DEX contract whenever it receives administrative request to do so.

Administrative

UpdateAdmin

Must be sent from the administrative wallet to the Factory in order to update administrative wallet’s address.

UpdatePool

Must be sent from the administrative wallet to the Factory in order to update parameters of the pool.

ActivateVault

Must be sent from the administrative wallet to the Factory in order to activate some Jetton Vault.

Withdraw

Must be sent from the withdrawer wallet to the Factory in order to withdraw some assets. Used to withdraw collected protocol fees: they are calculated (collected) on-chain, but must be distributed off-chain in order to significantly lower gas consumption for end-users.

UpdateCodeCell

Must be sent from the administrative wallet to the Factory in order to update code cells of all the contracts that will be deployed by the Factory in the future.

UpdateContract

Must be sent from the administrative wallet to the Factory in order to update already existing contract. contract_address must be none in case of administrator wanting to upgrade the Factory itself.

UpdateWithdrawer

Must be sent from the administrative wallet to the Factory in order to update withdrawer wallet’s address.