Map native assets explicitly in an OKX DEX adapter

Represent native currency explicitly inside the application, then translate it into the provider's API convention. A placeholder address is an adapter encoding, not an ERC-20 contract to query or approve.

The OKX quote documentation uses 0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee as a native-token address representation. Keep this mapping scoped to the relevant provider and chain family rather than exporting it as a universal token identity.

Use a tagged internal asset

A proposed model distinguishes native assets from token contracts and always includes the chain. The native asset on one chain is not interchangeable with the native asset on another, even when both display similar names.

Translate only at request serialization and response normalization. Your balance reader can then use the appropriate native-balance operation, while an ERC-20 reader receives only real token contract addresses.

Check the execution value

For native input, review the returned transaction value alongside the intended amount and documented fees. Also reserve enough native balance for the transaction's fee policy. A “maximum” button that spends the full native balance may leave no funds for execution.

For token input, do not assume value is always zero without checking the selected route and documented requirements. Validate unexpected native value rather than silently stripping it or accepting it.

Keep wrapped assets distinct

A wrapped native token has a contract address and token allowance semantics. Do not replace it with the native sentinel merely because the ticker resembles the network's native asset. That changes both the funding source and transaction construction.

Test native-to-token, token-to-native and wrapped-native-to-token requests. The adapter should select the appropriate balance and approval paths, preserve the chain, and reject an unsupported sentinel instead of treating it as an ordinary contract address.