Dmail is discontinued: the remaining DMAIL spot path

Buying a residual DMAIL balance after service closure

A residual DMAIL purchase made sense only when a live spot pair and an enabled withdrawal route appeared together.

The service entered shutdown on May 15, 2026, and the team directed users to export mailbox content before then. That status separated a DMAIL token purchase from access to the former mailbox product. The trade created a spot balance on an exchange; it did not restore messaging, notifications or NFT-domain functions. A buyer therefore needed a narrower objective: acquire DMAIL through an order book, verify the fill and move the balance to a compatible EVM wallet while the venue supported both trading and withdrawals. If either function was disabled, the five-stage path stopped before funding. For the closely linked subject, see Dmail troubleshooting.

Bitrue still presented a DMAIL/USDT spot interface with limit and market controls. Availability remains account- and region-specific, so the decisive evidence is the logged-in market and withdrawal screen, not an old listing announcement. The workflow below applies only when both functions are enabled.

Setting up the five-stage spot path

The first-position path contained five stages: fund, select, buy, confirm and withdraw to a wallet on the matching network. First, place USDT in the exchange’s spot or trading account. Second, open DMAIL/USDT rather than a similarly named asset. Third, choose one order mode and submit the buy. Fourth, reconcile the fill against order history, trade history and the available token balance. Fifth, select either Ethereum or BNB Smart Chain only after the destination wallet shows the same chain. Those five stages produce two balance changes: USDT decreases and DMAIL increases.

Pair choice before the first order

The pair choice determined which asset funded the order and which balance appeared after settlement. In DMAIL/USDT, DMAIL is the base asset and Tether’s USDT is the quote asset. A buy converts quoted USDT into DMAIL; a sell reverses that direction. The pair contains two sides, but the first-position action is one spot buy. The published maximum supply was 200 million DMAIL, as explained in Dmail requirements guide in detail.

Old market pages require special treatment here. KuCoin, OKX, Bitget and Gate all published DMAIL listings, then later removed or scheduled removal of the pair and related services. Their historical announcements establish the contract and past pair format, not present execution. The usable venue is whichever accessible exchange currently shows an active DMAIL/USDT order book, accepts a buy order for the account’s jurisdiction and exposes a DMAIL withdrawal network. Confirm the ticker beside the full asset name and check the withdrawal control before depositing quote funds.

Limit and market modes for one primary buy

A limit order fixed the highest accepted price, while a market order prioritised immediate execution against available asks. Both modes bought the same DMAIL spot asset. The distinction lay in price control: the limit rested until sellers matched it, whereas the market order walked the visible asks within the venue’s controls.

Bitrue’s DMAIL screen exposed limit, market and trigger controls. Its market-order rule stated a 10% matching band around the displayed market price: buys stopped above 110% and sells stopped below 90%. That band did not guarantee a complete fill; it bounded which orders the engine would match. A thin book could therefore leave part of a market request unexecuted. For a first position, a limit buy made the maximum unit price explicit and left any remainder open. A market buy traded price certainty for faster matching, so the order history mattered immediately after submission.

A worked DMAIL fill from quote balance to position

A worked fill links the quoted spend, execution price and resulting DMAIL balance without relying on a live market price.

In this worked example, every changing market input is hypothetical: the limit price is 0.00010 USDT per DMAIL, the requested quantity is 5000 DMAIL and the book fills 3500 at that price before the remaining 1500 stays open. The filled quote amount equals 3500 × 0.00010, which is 0.35 USDT. The settled position therefore contains 3500 DMAIL, the open order contains 1500 DMAIL and the gross unspent quote amount tied to the unfilled portion is 0.15 USDT. Order charges sit outside this example, and no live price appears in the arithmetic.

After cancelling the unfilled remainder, the user should see zero DMAIL in open buy orders and 3500 DMAIL in the settled spot balance. That is the concrete result to confirm before opening the withdrawal form. A displayed order size of 5000 alone does not prove a 5000-token position.

Confirming the spot position in three records

A confirmed spot position appeared consistently across the order history, trade history and available DMAIL balance. The order record showed requested quantity and status. The trade record showed each execution price and filled quantity. The balance showed tokens no longer reserved by an open order.

Three records should reconcile before withdrawal. If the order status says filled, the remaining quantity should be zero. If it says partially filled, only executed units belong to the position; the rest remain open until cancelled or matched. The available balance, rather than the total balance, controls how many tokens the withdrawal form accepts. Record the order identifier, the executed DMAIL quantity and the quote spent. Those three fields create a compact audit trail and expose whether the intended spot position settled as 100%, a partial fill or zero.

How do you choose the correct DMAIL withdrawal network?

The correct DMAIL withdrawal network is the one enabled by the venue and configured in the destination wallet.

DMAIL was issued as an ERC-20 token on Ethereum and a BEP-20 token on BNB Smart Chain. Those labels describe separate ledgers. Selecting one of the two determines where the exchange broadcasts the transfer and which block explorer records it.

The destination address may look identical across both EVM networks because a single EVM account in MetaMask, Trust Wallet or Ledger uses the same hexadecimal address on compatible chains. Address appearance does not select the ledger. The withdrawal form’s network field does. Match its label to the wallet’s active network, then confirm that the DMAIL token contract on that chain is 0xcC6f1e1B87cfCbe9221808d2d85C501aab0B5192. If the exchange offers only ERC-20, prepare Ethereum. If it offers only BEP-20, prepare BNB Smart Chain. When both appear, choose the route that the receiving wallet is already configured to display.

Do not substitute opBNB, Base or another EVM chain merely because the address format matches. Chain ID 204 identifies opBNB, while the supported BNB Smart Chain mainnet uses chain ID 56. A withdrawal selector must name the exact ledger, not only an EVM-compatible family.

Once the chain and contract match, copy the receiving address from the selected wallet network. A small first transfer followed by the remainder uses two on-chain transactions, which creates two transaction hashes and two independent confirmations. Because the first transaction repeats the contract and destination format intended for the remainder, its explorer record tests the chosen route without changing networks between requests. That route favours verification over a single all-at-once transfer.

Wallet preparation for Ethereum and BNB Smart Chain

An Ethereum or BNB Smart Chain wallet needed the proper network, token contract and native gas asset before withdrawal. MetaMask and Trust Wallet support both EVM networks, while a Ledger device can secure the same account through a connected wallet interface. Receiving DMAIL requires no Dmail mailbox account.

Ethereum uses chain ID 1 while BNB Smart Chain uses chain ID 56. ETH pays for later ERC-20 transfers on Ethereum, while BNB pays for later BEP-20 transfers on BNB Smart Chain. One gwei equals 10 ^-9 of the native asset and one wei equals 10 ^-18 . The exchange originates the outbound transaction; after receipt, the wallet owner needs the relevant native asset to move DMAIL again. The native coin is separate from the token and does not appear automatically with it. Etherscan covers the Ethereum record and BscScan covers the BNB Smart Chain record.

Matching the contract, decimals and transaction record

Contract metadata and the transaction record established whether the received asset was the intended DMAIL token. The verified DMAIL contract uses 18 decimal places and the same 42-character address on Ethereum and BNB Smart Chain: 0xcC6f1e1B87cfCbe9221808d2d85C501aab0B5192. An EVM address contains 20 bytes, rendered as 40 hexadecimal characters after the 0x prefix. One whole token equals 10 ¹⁸ base units. A transaction hash contains 32 bytes, normally shown as 64 hexadecimal characters after 0x. Compare network, contract, recipient and value in Etherscan or BscScan.

A clean exit from venue balance to wallet or USDT

A clean DMAIL exit ended in either a completed wallet withdrawal or a completed spot sale back to the quote asset. Both paths required the exchange balance to become available first. An open order is not an exit.

For a withdrawal, the terminal record was an on-chain transfer with the correct recipient, contract and value. The exchange status could move from requested to processing to completed, but the explorer transaction decided whether the wallet received tokens on the chosen ledger. For a spot sale, the terminal record was a filled DMAIL/USDT sell and an increased USDT balance. These endpoints should not be mixed: withdrawing moves the asset under wallet custody, while selling removes the DMAIL position and returns the quote asset inside the venue.

Close the workflow only after the destination balance and transaction record agree. In a test-then-remainder route, reconcile both hashes and add both token amounts. In a sale route, confirm the remaining DMAIL balance is the intended amount. The final state is a named wallet balance or a named USDT balance with no pending instruction.