1. Overview
In blockchain asset custody services, deposit processing is generally divided into two categories: standard transfer (Transfer) deposits and contract-based transaction deposits.
This article explains the current supported scope, processing approach, and known limitations for contract-based deposits, helping users better understand deposit rules and reduce uncertainty caused by differences in on-chain data structures.
2. Supported Deposit Types
✔ 2.1 Standard Transfer Deposits (Fully Supported)
Includes:
ERC-20 standard transfers (supported)
TRC-20 standard transfers
BEP-20 standard transfers
TON standard Jetton transfers
Other mainstream blockchain native token transfers
These transactions follow standardized transfer structures, allowing the system to reliably recognize and automatically credit deposits.
✔ 2.2 Standard Contract Transfer Deposits (Supported)
Includes:
ERC-20 standard contract transfer calls (transfer / transferFrom)
Ethereum Mainnet Contract-triggered Internal Transaction
TRC-20 / BEP-20 equivalent standard token contract transfers
TON Jetton standard transfer paths
Contract interactions following standard token transfer logic
These transactions are structurally consistent or highly similar to standard transfers and can therefore be reliably recognized and credited.
3. Deposit Processing Limitations for Contract Transactions
For contract-based transactions (i.e., transactions that generate asset changes through smart contract execution), due to significant differences in blockchain design and contract implementations, the system currently handles them in the following categories:
❗ 3.1 Automatically Supported Cases
Contract interactions that strictly follow standard token transfer models can be automatically recognized and credited.
⚠️ 3.2 Partially Supported (Manual Processing Possible)
In some contract scenarios where on-chain data is clearly traceable, manual assistance may be used to complete deposit processing, such as:
Contract interactions with clearly identifiable fund flows
Single-path asset transfer structures that are easy to interpret
These cases may be processed successfully; however, outcomes depend on the clarity and completeness of on-chain data. For uncertain transactions, users may submit them for review and confirmation.
❌ 3.3 Unsupported Cases (Not Processable Even Manually)
The following scenarios may not be supported for deposit processing:
Non-standard contract implementations or custom asset logic
Multi-step complex contract interactions (nested / aggregated / cross-protocol calls)
DeFi aggregator or composable transaction outputs
Complex Object structures generated in SUI / Move-based models
Internal / proxy / wrapper message routing in TON network
Internal or custom contract logic that cannot be mapped to standard asset structures
In these cases, even if the transaction is successfully executed on-chain, it may not be mappable to the system’s deposit model and therefore cannot be credited.
4. Chain-Specific Notes
SUI (Move / Object Model)
Assets in the SUI network are represented as Objects. Different contract execution paths may generate different Object structures. In complex contract interactions, these structures may not be compatible with the current deposit parsing model.
TON Network
TON includes Internal messages, wrapper contracts, and multi-layer routing mechanisms. Some non-standard Jetton transfer paths may not be recognized as standard deposit events.
APT (Aptos / Move Model)
The Aptos network is also based on the Move language and resource model. Different contract execution paths may result in variations in on-chain resource structures.
In certain complex contract interactions or non-standard asset flows, the resulting data may not fully align with the system’s deposit parsing model, which may affect automatic processing.
5. Important Notes Before Using Contract Deposits
To reduce uncertainty in deposit processing, we recommend:
Prioritizing standard transfer (Transfer) methods for deposits
Using standard token contract paths whenever possible
Consulting support before initiating complex contract or DeFi-related transactions
Verifying unclear transaction types in advance to assess compatibility
In summary, Cobo’s automatic deposit processing primarily supports standard transfers (Transfer) ,standard token contract transfers (e.g., ERC-20 and equivalents) and ETH Mainnet Internal Tx, which provide stable and reliable deposit recognition.
For complex contract interactions or non-standard on-chain structures (including certain cases on SUI, TON, and APT networks), due to inherent differences in underlying data models, deposits may not always be automatically or manually processed.
Therefore, to ensure the most stable and predictable deposit experience, users are strongly encouraged to use standard transfer methods whenever possible.