Crypto Withdrawals

​

Overview

1. Call GET /crypto/v1/network-coin to confirm that the target chain and token have withdrawals enabled (withdrawEnable), and read the withdrawal fee and limits (withdrawFee / withdrawMin / withdrawMax) plus whether an address tag is required (withdrawIsTag).
2. Have the user obtain an SMS verification code (smsCode, see Prerequisites), then call POST /crypto/v1/withdraw-apply to submit the withdrawal.
3. Call POST /user-asset/v1/transactions to query crypto balance movements and follow the on-chain status and txHash of this withdrawal.

​

Prerequisites

1. The user is onboarded and has passed KYC: the user has been assigned an externalUserId. See Managing users.
2. Withdrawals are enabled for the target chain and token: query GET /crypto/v1/network-coin first, confirm that withdrawEnable = true for that network plus coin, and use withdrawIsTag to decide whether addressTag is mandatory.
3. The available balance is sufficient: the user’s availableBalance must be greater than or equal to the withdrawal amount plus the fee. For the balance model, see Account and asset model · Ledgering.
4. SMS verification is complete: a withdrawal moves money out, so it is treated as high risk and requires an SMS verification code smsCode (issued via POST /captcha/v1/send-mobile-code).
5. Compliance groundwork: where the Travel Rule applies, its requirements must be satisfied first. See Travel Rule.

​

API flow

​

Submitting a withdrawal

​

Request fields

Amount precision: amount and fee in the request body are numbers. When storing and displaying them, mind the token’s on-chain precision so that no precision is lost.

​

Request example (redacted)

curl -X POST "{{dicard-server}}/crypto/v1/withdraw-apply" \
  -H "Content-Type: application/json" \
  -d '{
    "externalUserId": "user_demo_001",
    "smsCode": "000000",
    "network": "TRON",
    "coin": "USDT",
    "name": "my-wallet",
    "address": "T-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
    "addressTag": "",
    "amount": 100.0,
    "fee": 1.0
  }'

Authentication: the example above omits the authentication headers to keep the focus on business fields. Real calls must carry X-DAPI-API-KEY, X-DAPI-SIGN, X-DAPI-TIMESTAMP, and X-DAPI-NONCE (HMAC-SHA256 signature). The rules are documented once in the Authentication guide and are not repeated here.

​

Response

Base your business logic on the actual status in the transaction records. Do not treat code = SYS_SUCCESS in the envelope as proof that the withdrawal has been credited; code only confirms that the request was accepted, and the on-chain transfer happens asynchronously.

​

Tracking withdrawal progress

​

Status and time to credit

• Acceptance is not the same as crediting: code = SYS_SUCCESS in the envelope only means DCS accepted the request and deducted the balance; the funds are only really at the destination once confirmed on-chain.
• Time to credit depends on on-chain confirmation speed: block times and confirmation counts differ by chain, so rely on the confirmation configuration in network-coin and the actual state of the target network.

​

Error handling

​

Best practices

1. Query network-coin before every withdrawal: drive your front-end validation from withdrawEnable, withdrawFee, withdrawMin, withdrawMax, and withdrawIsTag to cut down invalid requests and failed credits.
2. Enforce address and tag validation: validate the address format and tag against the chain’s rules while the user is still filling the form, and make the tag mandatory when withdrawIsTag = true. A wrong address or a missing tag can make the funds unrecoverable.
3. Never skip SMS verification: withdrawals move money out, so always require the second factor via smsCode.
4. Judge crediting by the on-chain status: acceptance is not crediting. Before telling the user the funds have arrived, check the on-chain confirmation status in the transaction records.
5. Minimise PII: on-chain addresses and user identifiers are sensitive. Redact them in logs and retain no more than compliance requires.

​

Next steps

• Crypto Deposits — the opposite direction (on-chain deposit into the available balance), sharing the network-coin chain and token matrix with this page
• Travel Rule — the compliance groundwork that withdrawals depend on
• User Balance — semantics of the free / freeze / total balances and how to query balance movements
• Account and asset model · Ledgering — the availableBalance / frozenBalance model
• Authentication guide — the shared reference for HMAC-SHA256 signature headers