[Bug]: Wrong token amount for vUSDC minting and withdrawing on Venus

[bschorchit]

Describe the bug

Wrong token amount and fiat price displayed for minting and withdrawing vUSDC on Venus

Expected behavior

Display accurate token amount and fiat price for vUSDC - currently 1 USDC = 41.131844 vUSDC

Screenshots/Recordings

Steps to reproduce

1. Have USDC on BNB chain
2. Go to https://app.venus.io/#/core-pool/market/0xecA88125a5ADbe82614ffC12D0DB554E2e2867C8?chainId=56
3. Approve USDC spending
4. Click on Supply USDC
5. Notice the estimated changes displayed within MM confirmation

Error messages or log output

No response

Detection stage

In production (default)

Version

12.0.0

Build type

None

Browser

Brave

Operating system

MacOS

Hardware wallet

No response

Additional context

No response

Severity

No response

[jpuri]

After debugging I found that issue in this case is simulation api returning erroneous data.

[dbrans]

When querying token balances via RPC calls (e.g., eth_call to balanceOf), the response includes extra zeros appended to the actual balance value.

Affected Chains (so far):

• BNB Chain (BSC)
• Optimism (reported for OP token – appears to be a similar issue)

Example from BNB Chain:

curl 'https://bsc-dataseed1.binance.org/' \
  // headers removed for brevity
  --data-raw '{"jsonrpc":"2.0","id":169618779484965,"method":"eth_call","params":[{"from":"0x0000000000000000000000000000000000000000","data":"0x70a082310000000000000000000000003424b949dbc5d2d2654cb6fc622c4d723b2e8fb4","to":"0xeca88125a5adbe82614ffc12d0db554e2e2867c8"},"latest"]}'

Response:

{"jsonrpc":"2.0","id":169618779484965,"result":"0x000000000000000000000000000000000000000000000000000000134c31d25200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"}

• The first 32 bytes (64 characters after '0x') represent the correct balance: 000000000000000000000000000000000000000000000000000000134c31d252
• This decodes to the expected decimal value: 82882712146
• An additional 64 bytes (128 characters) of zeros are appended to the response

Verification of contract code:

The smart contract implementation of balanceOf is correct and, after delegating to an implementation, returns the proper value. Here's a simulation trace on tenderly.

The balance reported by block explorers (e.g., BscScan) matches the decoded value from the first 32 bytes of the RPC response

Analysis

The issue likely stems from the RPC node implementation or configuration, not from the client, simulations api, or smart contracts themselves

The problem affecting multiple chains suggests it might be related to common infrastructure or software these chains are using.

Next steps

1. Workaround in simulation API While this padding is unusual, the correct data appears to still be returned. In the short-term, we could handle this extra padding in the simulation api by removing extra padding.
2. Report to Chain Teams: Submit detailed bug reports to both the BNB Chain and Optimism teams.
3. Community Awareness: Share findings with the broader blockchain developer community. This can help identify if other chains or tokens are affected and pool resources for a solution

[dbrans]

Nick Hewitt noticed that if you go to the debugger it shows the raw output which matches geth:

[RAW_OUTPUT]":"0x000000000000000000000000000000000000000000000000000000134c31d25200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"