Create Account
Log In
Dark
chart
exchange
Premium
Terminal
Screener
Stocks
Crypto
Forex
Trends
Depth
Close
Check out our API

CHZUSD
Chiliz / United States dollar
crypto Composite

Real-time
Apr 17, 2026 9:00:56 AM EDT
0.041630USD-4.012%(-0.001740)31,194,629CHZ1,312,769USD
0.017190Bid   0.042123Ask   0.024933Spread
OverviewHistoricalDepthTrends
Composite
0.041630
Coinbase
0.041700
Bitstamp
0.041620
Bitfinex
0.041436
Gemini
0.041600
OKX
0.041630
CHZ Reddit Mentions
Subreddits
Limit Labels     

We have sentiment values and mention counts going back to 2017. The complete data set is available via the API.
Take me to the API
CHZ Specific Mentions
As of Apr 17, 2026 8:50:25 AM EDT (11 minutes ago)
Includes all comments and posts. Mentions per user per ticker capped at one per hour.
19 hr ago • u/edilsonsilveira • r/binance • pionexbinancechiliz_funds_confirmed_onchain_but • Discussion • B
Funds confirmed on-chain but inaccessible — custodial refusal from exchange (technical case)
I’m dealing with a case that is clearly NOT a lost funds scenario, but exchanges are treating it as such.

Here are the facts:

\- Asset: CHZ
\- Network used: Chiliz Chain (CAP20)
\- Destination: Pionex deposit address
\- TXID: 0x4b12...b7a

The transaction is confirmed and visible on Chiliscan.

So the funds:
✔ Exist
✔ Are confirmed
✔ Were delivered to the correct address

The issue:
Pionex does not support CAP20 deposits in their interface and refuses to recover the funds.

However, from a technical standpoint:

\- Chiliz Chain is EVM-compatible
\- The receiving address is controlled by Pionex
\- The private key exists and can access funds across EVM chains

This is NOT a blockchain limitation.

This is:
→ A custodial access issue
→ A manual recovery case

Binance also contributed to this by:

\- Showing CAP20 (same name as CHZ)
\- Offering a 10x cheaper fee vs ERC20
\- Providing no interoperability warning

So naturally, the user chooses CAP20.

Question to the community:

Is there any valid technical reason for an exchange to refuse recovery in this scenario?

Or is this purely operational policy?

Because from everything I understand:
Recovery is possible.
They just don’t want to do it.
sentiment -0.58
19 hr ago • u/edilsonsilveira • r/binance • pionexbinancechiliz_funds_confirmed_onchain_but • Discussion • B
Funds confirmed on-chain but inaccessible — custodial refusal from exchange (technical case)
I’m dealing with a case that is clearly NOT a lost funds scenario, but exchanges are treating it as such.

Here are the facts:

\- Asset: CHZ
\- Network used: Chiliz Chain (CAP20)
\- Destination: Pionex deposit address
\- TXID: 0x4b12...b7a

The transaction is confirmed and visible on Chiliscan.

So the funds:
✔ Exist
✔ Are confirmed
✔ Were delivered to the correct address

The issue:
Pionex does not support CAP20 deposits in their interface and refuses to recover the funds.

However, from a technical standpoint:

\- Chiliz Chain is EVM-compatible
\- The receiving address is controlled by Pionex
\- The private key exists and can access funds across EVM chains

This is NOT a blockchain limitation.

This is:
→ A custodial access issue
→ A manual recovery case

Binance also contributed to this by:

\- Showing CAP20 (same name as CHZ)
\- Offering a 10x cheaper fee vs ERC20
\- Providing no interoperability warning

So naturally, the user chooses CAP20.

Question to the community:

Is there any valid technical reason for an exchange to refuse recovery in this scenario?

Or is this purely operational policy?

Because from everything I understand:
Recovery is possible.
They just don’t want to do it.
sentiment -0.58


Share
About
Pricing
Policies
Markets
API
Info
tz UTC-4
Connect with us
ChartExchange Email
ChartExchange on Discord
ChartExchange on X
ChartExchange on Reddit
ChartExchange on GitHub
ChartExchange on YouTube
© 2020 - 2026 ChartExchange LLC