Dym
Dym transfers leave records that can be matched to receiving balances
UpdatedDym transfer status is checked by matching the transaction record with the receiving account’s balance. Start with the transaction hash, the network that processed it and the intended recipient. A submitted request doesn’t establish delivery, and a successful cross-chain send may still await processing on the receiving chain. Confirm the credited asset and amount, then account for later activity before comparing the recorded balance with the wallet display.
Match the transfer record to the receiving account
Open the transaction record on the network that processed the send, then compare its recipient and amount with the intended transfer. Use the actual blockchain transaction hash rather than a service’s internal withdrawal reference. The record should establish whether execution succeeded and identify the transfer that occurred. For a direct transfer within Dymension, the receiving account’s recorded credit provides the corresponding evidence of arrival.
Keep the account and network together throughout that comparison. Dymension supports hexadecimal addresses and Cosmos-style addresses beginning with dym1. These formats can represent the same underlying account, but two addresses shouldn’t be treated as equivalent merely because they appear in the same wallet application. Use the account’s corresponding representations. An address format alone also doesn’t establish which network a sending service used.
Read source execution separately from delivery
A transaction hash identifies a transaction; its existence doesn’t prove that the transfer executed successfully. Signing authorizes a request, while broadcasting submits it to a node. The transaction must subsequently pass execution and have its state changes committed. A wallet notification about submission can therefore appear before the network records a completed transfer.
Read the execution result, not just the presence of a block height. A transaction can appear in a block with an error.
For a successful direct send, inspect the transfer details and the recipient’s account activity. For a cross-chain send, that same success establishes the sending operation, with delivery requiring additional processing. This distinction explains why a source balance can decrease before the destination balance changes. Preserve the original hash while investigating; submitting another transfer creates another request rather than clarifying the first.
Why is a balance missing after a successful IBC send?
A successful IBC send can precede receipt because the destination chain must process the transfer packet. IBC means Inter-Blockchain Communication, and relayers carry the information needed between chains. The sending transaction and destination processing are separate events. Track the packet associated with the send, including its channel and sequence where the interface exposes them.
An ICS-20 acknowledgement records whether the receiving application accepted or rejected the token transfer. Confirm the destination credit as well as the packet result. A missing acknowledgement alone doesn’t prove that the recipient received nothing, because returning the acknowledgement is another relay step. For an IBC voucher, check its denomination trace when matching the credited balance. Returning tokens along their original route removes the corresponding trace entries and can restore the native denomination.
Which DYM balance should match the receipt?
Compare the receipt with the same asset’s balance on the receiving chain at a compatible point in its history. A current balance may already include later transfers or staking activity. When other activity occurred after arrival, reconcile those entries instead of expecting today’s balance increase to equal the original credit.
Staking changes availability. Bonded tokens belong to a staking position and shouldn’t be counted as immediately spendable transfer funds.
Use token quantities consistently when comparing account data with a wallet display. Dymension’s native base denomination is adym, with 18 decimal places per DYM. Raw account data and a formatted wallet amount can therefore express the same quantity very differently. Keep the sender’s network fee separate from the recipient’s credit, and use any service’s stated net withdrawal amount when that service deducts a charge. Don’t infer a fee from an unexplained difference.
Reconcile a completed transfer with a stale wallet display
Consider a hypothetical direct transfer within Dymension. The requested amount is 18.75 DYM, and the receiving account initially holds 6.25 DYM. Assume the sender has enough spendable funds for the amount and the separately charged transaction fee. Both addresses belong to the intended accounts, and no other receiving-account activity occurs during the comparison.
The sending transaction executes successfully and records an 18.75 DYM transfer to the intended recipient. The expected receiving balance is therefore 6.25 + 18.75 = 25 DYM. A subsequent account query shows 25 DYM, while the wallet screen still displays 6.25 DYM. The transfer record and recorded balance agree, so the tokens have arrived. Refresh the wallet’s balance view to check whether it now matches the recorded balance; another send would duplicate the payment.
If the account query instead showed the earlier balance, this comparison wouldn’t establish arrival. The query’s block height would need checking against the transfer’s inclusion height.
When is retrying a DYM transfer justified?
A retry is justified after the original attempt has a resolved failure and the relevant funds remain available or have returned. First distinguish a rejected submission from an executed transaction that failed. A wallet’s stale pending label doesn’t establish either condition. Read the transaction result and address the reported cause before authorizing a fresh request.
For a standard ICS-20 transfer, processing an error acknowledgement or timeout triggers the appropriate token refund. Passing a displayed deadline alone doesn’t establish that this processing occurred. Look for the refund in the sending account before relying on those funds. The original network fee is separate from the transferred amount. If the transfer remains unresolved, retain its identifiers and investigate that attempt rather than treating uncertainty as permission to resend.
Allow for a separate withdrawal settlement step
A withdrawal from a RollApp can involve settlement conditions beyond ordinary source transaction execution. Dymension’s eIBC mechanism allows operators using liquidity providers’ funds to fulfill withdrawals before the dispute period finishes. An operator must fulfill the withdrawal order for the recipient to receive funds early; submitting the withdrawal alone doesn’t establish receipt. Where this mechanism applies, distinguish the withdrawal request from fulfillment and compare the actual recipient credit with the withdrawal amount after the priority tip is deducted. Its conditions shouldn’t be applied to an ordinary direct DYM send within Dymension.
Keep the record that explains an unmatched credit
When a receiving service hasn’t credited a deposit, retain the sending hash, receiving address, network, amount and any associated packet record. Blockchain receipt and the service’s internal account credit are separate records. A successful transfer to the service’s address doesn’t identify why its customer balance remains unchanged. Provide the identifiers through that service’s support process without sharing wallet secrets. Once the credit is matched, retain the receipt for later reconciliation, especially if subsequent activity changes the balance. Record the token quantity separately from its displayed monetary value so the transfer remains identifiable in DYM.
Dym FAQs
Why did a failed DYM transfer still reduce my balance?
A transaction that fails during execution can still incur a network fee. Fee processing and the transfer’s state changes are separate parts of execution, so failure doesn’t necessarily return the fee. Compare the recorded fee with the balance decrease. A submission rejected before execution is a different case, and an unexplained debit needs its own transaction record.
Can closing my wallet cancel a submitted DYM transfer?
Closing a wallet doesn’t cancel a transaction that has already reached the network. The application displays account activity, while network nodes process the submitted transaction. Reopening the wallet may update its status, but it doesn’t reverse committed changes. Check the original transaction before deciding whether any further action is needed.
Does a missing memo explain an uncredited DYM exchange deposit?
A missing memo can prevent automatic customer credit when the receiving service requires one to identify deposits. The blockchain transfer may still reach the service’s address. Compare the transaction’s memo with that service’s deposit requirements and give support the transaction hash if they differ. There isn’t a universal memo requirement for every DYM recipient.
Is a changing fiat balance evidence that my DYM transfer failed?
A changing fiat estimate doesn’t establish whether tokens arrived. That estimate reflects a token quantity and the price used by the application. Compare the actual DYM quantity and transaction history to assess delivery. If those match, a different displayed monetary value doesn’t by itself indicate a missing transfer.
How can I distinguish repeated DYM sends with the same amount?
Match each separately executed send to its transaction hash and recipient activity. Equal amounts don’t make two records the same payment. Use the recorded order of transactions and their block details to distinguish them, then reconcile each credit separately. A screenshot showing only an amount can’t establish which attempt produced the receiving balance.