Symbiosis & Fees
Who and how pays transaction fees for cross-chain operations conducted with the Symbiosis protocol.
Last updated
Was this helpful?
Who and how pays transaction fees for cross-chain operations conducted with the Symbiosis protocol.
Last updated
Was this helpful?
The Symbiosis protocol implements the following on-chain and cross-chain operations:
On-chain swaps,
Cross-chain swaps,
Cross-chain zaps (adding liquidity to Symbiosis Octopools),
Interchain communicating, including:
Adding liquidity to third-party DeFi protocols via cross-chain Zaps,
Swaps to BTC trough ThorChain,
Swaps to Solana via Chainflip)
Bridging,
Reverting stuck cross-chain operations.
Each cross-chain operation consists of multiple steps executed across the source blockchain, S-chain, and destination blockchain(s).
For example, a cross-chain swap (see Scheme 1) follows a structured sequence of transactions across these networks.
For the user, a cross-chain operation appears as a single transaction (Step 1 in Scheme 1). The user signs and submits this transaction on the source blockchain (where their assets are held) and covers the gas fee for this transaction.
In reality, a cross-chain operation consists of multiple transactions. The Symbiosis protocol executes additional transactions required to complete the swap (Step 5 and Step 9 in Scheme 1) and covers the gas fees for processing these transactions.
Now, let’s examine how the user refunds the gas fees and pays cross-chain fees to Symbiosis.
Let’s examine how gas costs are withheld using a cross-chain swap as an example. The same logic applies to other cross-chain operations.
If Boba BNB (Symbiosis S-chain) is the source or destination blockchain, the cross-chain operation requires one less calldata and one fewer transaction.
Additional fees
If you want to collect additional fees beyond Symbiosis' standard logic, you must deploy and manage your own collector smart contracts.
To accurately estimate gas fees and generate calldata, we recommend using the Symbiosis API.
For detailed guidance, refer to our Symbiosis Developer Tools
Next, we will extend Scheme 1 by incorporating the gas withholding process on the S-chain and destination blockchain (Scheme 2).
Workflow of Withholding Gas Costs (Scheme 2)
The initial transaction contains three calldatas, defining the execution steps on different blockchains:
Calldata0 – Instructions for the source blockchain.
Calldata1 – Instructions for the S-chain, including the estimated gas fee in a stablecoin equivalent (GasEstimatedUSD1).
Calldata2 – Instructions for the destination blockchain, including the estimated gas fee in a stablecoin equivalent (GasEstimatedUSD2).
Additionally, the calldatas include execution constraints, such as slippage tolerance and deadline for the cross-chain operation
These details are finalized at the time of transaction signing and cannot be modified afterward. By signing the initial transaction, the user agrees to all intermediate steps, restrictions, and fees.
The Symbiosis protocol processes the instructions from Calldata0 (Step 1). Once completed, it generates an Oracle request — a message for listeners — containing Calldata1 and Calldata2 for the next steps.
The Symbiosis Relayer Network listens for Oracle requests from Symbiosis contracts. Once an Oracle request appears, the network:
Extracts Calldata1 and Calldata2 and perform validation checks, ensuring GasEstimatedUSD1 is sufficient to cover gas costs on the S-chain.
If the checks pass, relayer nodes sign a transaction containing Calldata1 and Calldata2 using their MPC key and send it to the next blockchain (the blockchain is specified in the Oracle request; in this example, it's BOBA BNB).
Pays the gas fees required to execute this transaction.
An amount equal to GasEstimatedUSD1 is deducted from the transferred tokens at the next step.
The Symbiosis protocol processes instructions from Calldata1:
Tokens are minted on the S-chain.
An amount equal to GasEstimatedUSD1 is deducted from the minted token amount and kept.
The remaining tokens continue through the cross-chain swap process.
Once completed, it generates an Oracle request — a message for listeners — containing Calldata2 for the next step.
The Symbiosis Relayer Network listens for Oracle requests from Symbiosis contracts. Once an Oracle request appears, the network:
Extracts Calldata2 and perform validation checks, ensuring GasEstimatedUSD2 is sufficient to cover gas costs on the S-chain.
If the checks pass, relayer nodes sign a transaction containing Calldata2 using their MPC key and send it to the next blockchain (the blockchain is specified in the Oracle request; in this example, it's Avalanche).
Pays the gas fees required to execute this transaction.
An amount equal to GasEstimatedUSD2 is deducted from the transferred tokens at the next step.
The Symbiosis protocol processes instructions from Calldata2:
Tokens are released on the destination chain.
An amount equal to GasEstimatedUSD2 is deducted from the released token amount and kept.
The remaining tokens continue through the cross-chain swap process.
Once completed, tokens are sent to the user's address on the destination chain. it generates an Oracle request — a message for listeners — containing Calldata2 for the next step.
Important Notes
The initial execution parameters (e.g., GasEstimatedUSD1, GasEstimatedUSD2, slippage, deadlines) are set in Step 1 and remain unchanged throughout the cross-chain operation.
The Symbiosis Relayers Network uses the Advisor microservice to fetch gas prices on the blockchains supported by Symbiosis, ensuring transactions will be executed successfully.
Advisor Microservice Functions:
Validates cross-chain operation limits – Ensures the transaction amount complies with the limits imposed by the Symbiosis protocol.
Estimates gas costs – Estimates the gas cost (in the USD equivalent) to execute the given calldata
Verifies gas sufficiency – Checks whether the estimated gas fee is sufficient for executing the calldata (used by the Symbiosis Relayers Network).
For Points 2 and 3, Advisor simulates calldata execution on the given blockchain by calling an appropriate method. If the calldata cannot be executed, then:
Gas cost cannot be estimated.
The gas sufficiency check fails (indicating that the transaction cannot be processed).
