Digital Asset ExchangeDefinitions and supported routes
A deposit is an external transfer submitted for verification and Ledger credit. A withdrawal is a request to send an Asset externally. An internal exchange changes account balances and is neither type of blockchain transfer.
The catalog contains BTC, ETH, USDT, BNB, XRP, USDC, SOL, TRX, ZEC, AVAX, DOGE, LINK, POL, ADA, AAVE, XLM, NEAR, BCH, UNI and LTC. Availability is specific to Asset, Network and operation; inclusion does not enable deposits or withdrawals. Use only the route currently provided in your account.
Native coins, tokens on different chains and wrapped or bridged versions are not interchangeable. Symbols, logos and similar address formats do not prove compatibility. If an approved destination or route is unavailable, do not attempt the transfer.
Create and check deposit instructions
Create a request before sending and check its Asset, Network, address and required memo or tag. Receiving wallets can be shared. An internal request reference is not an on-chain memo unless expressly required in that field.
Use the current approved destination, not an old screenshot or informal message. Token contracts, placeholders and unverified addresses are not substitutes. Stop and contact support if instructions are absent, change unexpectedly or conflict.
Sending and evidence
Check all details in the sending service and retain evidence linking the transfer to you. Allow for charges deducted by the sender. Do not send unsupported tokens or select a bridge only because the resulting token has a similar symbol.
You must be lawfully entitled to the funds. A transfer from a shared exchange wallet may need a verifiable exchange withdrawal record rather than proof of personal control of its signing keys. Never provide keys or recovery phrases.
Submitting the transfer claim
Submit the actual blockchain transaction ID and relevant details through the request workflow after sending. An expected amount is not proof of receipt. False identifiers or claims against another person’s funds are prohibited.
A claim remains subject to review. Where a transaction contains multiple outputs or token events, the relevant receipt must be identified. Do not claim the same event through multiple requests; contact support to correct a submission.
Confirmations and entitlement
Operations verifies actual receipt at the approved destination on the correct Network, in the correct Asset and amount. The relevant event must meet that route’s confirmation or finality requirement. Visibility in an explorer or a sender’s completed label is not necessarily sufficient.
There is no single confirmation count for all chains. Conditions and reorganisations can require further review, and no fixed crediting time is promised.
Entitlement is checked separately from receipt. Shared destination, matching amount or public transaction ID alone does not establish ownership. Additional independent evidence may be required; unclear attribution can leave a request pending.
Credit and discrepancies
A verified receipt attributable to the account is credited once through the Ledger for the relevant chain event. Repeating confirmation must not produce another credit. Available Balance then reflects funds independently of any exchange.
Credit uses the actual verified received amount, not automatically the expected amount. Sender fees and incorrect estimates do not justify crediting funds that did not arrive. Report discrepancies with the request and transaction references.
Preparing a withdrawal
Choose an enabled route, a compatible address and required memo or tag, and review amount and fee. Independently check the recipient’s supported Network and token. A checksum does not prove recipient control or cross-chain compatibility.
Available Balance must cover amount plus fee and the minimum condition applies. Already reserved funds are unavailable for another operation. Additional checks may be required under the AML/KYC Policy.
Reservation, review and messages
Creation reserves amount and fee and records the request for manual review. It is not automatic broadcast. Operations may seek clarification, restrict processing where justified or attach a message.
Messages are informational. The authoritative status and financial records determine whether funds remain reserved, were released or were sent. Check History rather than relying only on a notification.
After a lost response, inspect History or retry the unchanged request in the same form. Do not repeatedly create new requests for one transfer. Contact support if the result remains uncertain.
Completion and release
Operations sends approved withdrawals externally and records completion with the actual outgoing transaction ID. Check it on the correct Network. Completion does not control the recipient’s crediting rules or prevent network disruption.
Rejection or cancellation under the operational procedure releases the reservation once. A review message alone does not release it. Once broadcast, recall is generally unavailable; report errors promptly rather than assuming reversal.
Incorrect transfers and recovery
Unsupported Assets, wrong Networks, contract destinations, missing memos and incorrect addresses can cause permanent loss. Aldenex may not control the recipient or be able to retrieve an unexpected token. Editing an internal request cannot recover a third-party transfer.
Recovery is assessed case by case for control, feasibility, entitlement and legal constraints. No recovery outcome, charge or deadline is guaranteed. Any proposed action and applicable charge must be explained before agreement. Independently verify any request for another payment to unlock disputed funds.
Delays and unresolved balances
Manual handling, incomplete evidence, finality, outages and legal or security checks can delay operations. No fixed processing time or continuous staffing is offered. Avoid transfers whose timing cannot tolerate these risks.
Disabling an Asset or route does not erase history or legitimate claims. Contact support about an outstanding receipt, reservation or balance so a lawful supported resolution can be assessed. Disabled availability does not authorise forfeiture or bypassing checks.
Contact about a transfer
Include registered email, request reference, Asset, Network, actual transaction ID if available and the issue. Initially send only necessary public transfer evidence. Arrange a secure method if sensitive identity or financial records are required.
Company contact: ADEMEX TECHNOLOGIES LTD, registered in England and Wales under company number 15576900, with its registered office at 71–75 Shelton Street, Covent Garden, London WC2H 9JQ, United Kingdom. For questions, requests or complaints, email support@aldenex.com or write to the registered office. Operational support is also available through @adelmex_support on Telegram. Never send passwords, authentication tokens, private keys or recovery phrases.