Dymension
Dymension eIBC: withdrawing funds from RollApps
Dymension’s escrow IBC (eIBC) lets a RollApp withdrawal reach its recipient on the Hub settlement chain before the dispute period ends when a fulfiller supplies matching liquidity. The recipient pays a priority tip for that advance. Settlement continues separately, so early access requires an eligible withdrawal order and someone willing to finance it.
Priority tips and the withdrawal amount
The priority tip affects both the recipient’s net withdrawal and whether a liquidity provider considers the advance worth accepting. It is a percentage of the transferred tokens. An operator evaluates that fee against the provider’s minimum earnings and the operator’s own compensation requirements. A larger offered tip can meet a higher acceptance threshold, although it cannot supply missing liquidity.
The gross transfer amount, priority tip and net payout describe different quantities. Applicable bridging charges also affect the withdrawal’s economics. The protocol’s bridging fee follows a governance-controlled parameter, while providers and operators set their acceptance terms. The operator’s fee share applies to fee earnings, while the priority tip rate applies to transferred tokens. The order’s net payment specifies the recipient’s amount in its token denomination. Gas pays for transaction execution; it does not reserve bridge liquidity or compel an operator to accept a withdrawal.
How does a RollApp withdrawal become an eIBC order?
A withdrawal becomes available for eIBC fulfillment when its RollApp transfer packet reaches the Hub and the protocol records the pending withdrawal.
Packet delivery
The withdrawal request originates on the RollApp with its destination and transfer terms. A relayer carries the associated Inter-Blockchain Communication (IBC) packet to the Hub. Relaying supplies the message that the settlement chain needs; it does not provide the recipient’s early payment. The Hub tracks the packet against the relevant RollApp state while that state awaits finalization.
Order fulfillment
The eIBC client scans for pending, unfulfilled demand orders. It checks the originating RollApp, token denomination and payment amount against available liquidity authorizations. Compatible fee terms also matter. If an operator fulfills an eligible order, the liquidity provider’s funds cover the payment to the original recipient. Fulfillment redirects the pending withdrawal to the provider. If valid packet settlement completes, the provider receives the underlying tokens. Submitting the original withdrawal and completing an eIBC fill represent different protocol events.
What changes when an operator uses liquidity provider funds?
Authorized fulfillment separates the operator’s processing work from the liquidity provider’s capital, with the provider limiting which withdrawals the operator may finance.
Scoped authorization
A liquidity provider grants permission to an operator’s policy address. The authorization specifies spending limits for the RollApps and token denominations that it covers. Providers can also constrain fee terms and the maximum order price. The protocol applies these limits to authorized fulfillment, so permission for a selected RollApp does not imply unrestricted access to every balance. Operators do not receive direct custody of the provider’s funds merely because the provider grants this permission.
Capital during settlement
Unused tokens remain liquid in the provider’s account. Capital that finances a fill takes on the remaining settlement wait associated with that withdrawal. Operators earn an agreed share of the eIBC fee for processing withdrawals. Their gas account needs DYM to submit Hub transactions. An authorization can permit spending while the account lacks enough transferable tokens for a particular order.
Early recipient credit and later packet finalization
Recipient credit from an eIBC fill can precede the finalization of the original withdrawal packet. The fill establishes that the recipient received the liquidity advance. Valid RollApp state finalization permits packet settlement. Successful packet finalization completes the underlying withdrawal. An order marked fulfilled can therefore coexist with a pending packet. A record of the initial withdrawal alone establishes neither a successful liquidity advance nor final settlement.
On the optimistic settlement path, RollApp transfer packets reach finalization only after the applicable dispute period. That period follows protocol settings. It does not measure how quickly an operator will find suitable liquidity. The provider’s waiting time follows the remaining settlement exposure of the filled withdrawal. The priority tip therefore buys an advance against a pending transfer without shortening its underlying dispute period.
Hub v4.0.0 software also includes finalization based on a trusted execution environment (TEE). That separate path requires both protocol permission and RollApp-level enablement. Its availability changes the applicable finalization conditions; it does not describe an eIBC liquidity advance. When an unfilled order’s underlying RollApp state finalizes, packet settlement can pay its original recipient. On the manual finalization path, a Hub transaction must process the packet to complete the withdrawal. An eIBC liquidity advance still requires an actual fill.
Choosing early liquidity or normal settlement
If you need usable funds before optimistic settlement completes, a compatible eIBC fill can advance them. The advance serves that timing need only when the withdrawal and available capital satisfy the actual fulfillment conditions. For an operator using a liquidity provider’s grant, check:
- The order remains pending and unfulfilled, with eligibility for an eIBC fill.
- The liquidity authorization covers the originating RollApp and the order’s exact token denomination.
- The provider’s available balance covers the recipient’s payment and any operator fee charged during fulfillment. The order fits the authorization’s remaining spending limit and maximum price.
- The offered priority tip meets the provider’s and operator’s acceptance terms.
- The operator supports the RollApp and can process the fulfillment transaction.
Matching these conditions makes early fulfillment possible; actual fulfillment supplies the funds. Without a fill, the withdrawal remains subject to normal settlement and the validity of its underlying RollApp state.
Why can an eIBC withdrawal remain unfilled?
An eIBC withdrawal can remain unfilled because its fee terms, liquidity requirements or originating RollApp do not match an available operator and provider.
A provider may authorize the correct token while having too little available balance. A spending limit or maximum order price can also exclude a withdrawal. Operator support adds another dependency: permission to use funds does not ensure that a client is running and processing the relevant RollApp. Packet delivery and settlement progress matter independently. A withdrawal cannot obtain an advance merely from an attractive tip if its order is unavailable or no longer eligible.
Operators also need to monitor the RollApp state behind the orders that they process. Transaction data on the chosen data availability network enables full nodes to check the sequencer’s execution. Access to that data supports validation of the withdrawal’s underlying chain history.
An unreported fraudulent state transition can put funds at risk, including the liquidity that providers advance. Fast recipient payment does not remove that validation dependency. A higher tip cannot restore missing transaction data or make an invalid state transition valid.
Things people ask about Dymension
Can the destination account increase a pending eIBC order’s priority tip?
The destination account can increase the priority tip offered for a pending, unfulfilled withdrawal. This can help the order meet changed fee expectations during higher demand. The larger tip changes the recipient’s payment terms; it does not guarantee that a compatible provider will supply enough liquidity.
Is providing eIBC liquidity the same as delegating DYM to a validator?
Providing eIBC liquidity and delegating DYM create different commitments. Bridge liquidity finances withdrawal orders under an operator authorization and earns the applicable eIBC fees. DYM delegation bonds tokens to a validator for staking rewards. A staking delegation does not automatically create a transferable balance for an eIBC fill.
Can one eIBC operator serve multiple RollApps?
An eIBC operator can configure its client to process orders from multiple RollApps. Each withdrawal still needs compatible provider authorization, token liquidity and fee terms. Adding a RollApp to the client’s supported list does not expand a provider’s spending permissions or create liquidity for that chain.
Must every eIBC fill use a separate fulfillment transaction?
The eIBC client supports fulfilling multiple orders within one transaction. Each order must still satisfy the applicable liquidity and authorization requirements. Batching concerns how an operator submits fills. Each underlying withdrawal retains its own packet and settlement status, so inclusion in a batch does not imply identical settlement progress.
Do eIBC client configuration changes take effect without a restart?
The eIBC client needs a restart to apply configuration changes. This applies when an operator changes settings such as supported RollApps or fulfillment fee preferences. Updating a configuration file alone does not make a running client use those settings. Client settings cannot override liquidity provider authorization.
Does a liquidity provider need to give an operator its private key?
A liquidity provider authorizes fulfillment through an on-chain grant to the operator’s policy address, without handing over its private key. The provider signs the authorization and specifies its permitted scope. That mechanism gives the operator bounded fulfillment authority while the provider retains control of its own signing credentials.