CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes.

Bitrise

✅✅✅ pr_smoke_e2e_pipeline passed on Bitrise! ✅✅✅

Commit hash: fc7623c
Build link: https://app.bitrise.io/app/be69d4368ee7e86d/pipelines/40b358b8-44bc-4313-bf09-f955ae877fa7

Do you have a link (or would you be able to describe in PR description) the issue this fixes?

Considering if this is related at all to solving it:

• fix(deps): unpin [email protected],x [email protected] #11972

Also, is there any possible way to add a regression test for this bugfix?

Do you have a link (or would you be able to describe in PR description) the issue this fixes?

Considering if this is related at all to solving it:

• fix(deps): unpin [email protected],x [email protected] #11972

@siibars Thanks for updating, much clearer! 👍

Looks like it is indeed related. bn.js v4 does accept numbers with scientific notation as input to the constructor while v5 throws an error. It seems likely that this was once working correctly when implemented towards bn.js@4 and then at some point it started failing as the library version used in that particular place got substituted with v5. Unfortunately, the way BN is imported from legacy ethereumjs-util makes these discrepancies currently not get caught in type checks.

> new (require('bnjs4'))('1.23e30')
BN { negative: 0, words: [ 824430 ], length: 1, red: null }

> new (require('bnjs5'))('1.23e30')
Uncaught Error: Invalid character
    at assert (/home/user/dev/mm/.worktrees/metamask-mobile/deps-ethereumjs-6/node_modules/bnjs5/lib/bn.js:6:21)
    at parseBase (/home/user/dev/mm/.worktrees/metamask-mobile/deps-ethereumjs-6/node_modules/bnjs5/lib/bn.js:274:7)
    at BN._parseBase (/home/user/dev/mm/.worktrees/metamask-mobile/deps-ethereumjs-6/node_modules/bnjs5/lib/bn.js:298:14)
    at BN.init [as _init] (/home/user/dev/mm/.worktrees/metamask-mobile/deps-ethereumjs-6/node_modules/bnjs5/lib/bn.js:105:14)
    at new BN (/home/user/dev/mm/.worktrees/metamask-mobile/deps-ethereumjs-6/node_modules/bnjs5/lib/bn.js:39:12)

First steps in sorting out this larger mess:

• fix(deps): unpin [email protected],x [email protected] #11972
  • fix(deps): ethereumjs-util@6->^7.1.5 #11932
  • fix: ethereumjs-util -> @ethereumjs/util@^8.1.0 #11979
• feat(controller-utils): support bn.js v4 input to BN functions core#4844

@siibars I am trying to track down exactly where the stakedBalanceWei (assets) string gets constructed - do you have a reference handy? Is it just being piped unmodified from a server-side API?

https://github.com/MetaMask/metamask-mobile/actions/runs/11526358054/job/32090342121?pr=12010#step:5:31

FAIL app/components/UI/Stake/hooks/useBalance.test.tsx
  ● useBalance › returns balance and fiat values based on account and pooled stake data

    expect(received).toBe(expected) // Object.is equality

    Expected: "5791332670714232000"
    Received: "05791332670714232000"

      76 |     expect(result.current.balanceFiat).toBe('$39506172511.60'); // Fiat balance
      77 |     expect(result.current.balanceFiatNumber).toBe(39506172511.6); // Fiat number balance
    > 78 |     expect(result.current.stakedBalanceWei).toBe('5791332670714232000'); // No staked assets
         |                                             ^
      79 |     expect(result.current.formattedStakedBalanceETH).toBe('5.79133 ETH'); // Formatted ETH balance
      80 |     expect(result.current.stakedBalanceFiatNumber).toBe(18532.26454); // Staked balance in fiat number
      81 |     expect(result.current.formattedStakedBalanceFiat).toBe('$18532.26'); //

      at Object.toBe (app/components/UI/Stake/hooks/useBalance.test.tsx:78:45)
      at asyncGeneratorStep (node_modules/@babel/runtime/helpers/asyncToGenerator.js:3:17)
      at _next (node_modules/@babel/runtime/helpers/asyncToGenerator.js:17:9)
      at node_modules/@babel/runtime/helpers/asyncToGenerator.js:22:7
      at Object.<anonymous> (node_modules/@babel/runtime/helpers/asyncToGenerator.js:14:12)

@siibars I am trying to track down exactly where the stakedBalanceWei (assets) string gets constructed - do you have a reference handy? Is it just being piped unmodified from a server-side API?

https://github.com/MetaMask/metamask-mobile/actions/runs/11526358054/job/32090342121?pr=12010#step:5:31

FAIL app/components/UI/Stake/hooks/useBalance.test.tsx
  ● useBalance › returns balance and fiat values based on account and pooled stake data

    expect(received).toBe(expected) // Object.is equality

    Expected: "5791332670714232000"
    Received: "05791332670714232000"

      76 |     expect(result.current.balanceFiat).toBe('$39506172511.60'); // Fiat balance
      77 |     expect(result.current.balanceFiatNumber).toBe(39506172511.6); // Fiat number balance
    > 78 |     expect(result.current.stakedBalanceWei).toBe('5791332670714232000'); // No staked assets
         |                                             ^
      79 |     expect(result.current.formattedStakedBalanceETH).toBe('5.79133 ETH'); // Formatted ETH balance
      80 |     expect(result.current.stakedBalanceFiatNumber).toBe(18532.26454); // Staked balance in fiat number
      81 |     expect(result.current.formattedStakedBalanceFiat).toBe('$18532.26'); //

      at Object.toBe (app/components/UI/Stake/hooks/useBalance.test.tsx:78:45)
      at asyncGeneratorStep (node_modules/@babel/runtime/helpers/asyncToGenerator.js:3:17)
      at _next (node_modules/@babel/runtime/helpers/asyncToGenerator.js:17:9)
      at node_modules/@babel/runtime/helpers/asyncToGenerator.js:22:7
      at Object.<anonymous> (node_modules/@babel/runtime/helpers/asyncToGenerator.js:14:12)

We get this as wei string from the server side API.
https://github.com/consensys-vertical-apps/va-mmcx-staking-api/blob/81718575f23d03763d8abb991a2379cf54d25041/src/metaMaskPooledStaking/metaMaskPooledStaking.controller.ts#L77

using new BN(assets) instead of hexToBn(assets) fixes the issue.

hi @legobeat
to give you more details on where stakedBalanceWei comes from :
a. in the mobile it's populated here with 'pooledStakeData' which comes from an api server call,
b. this call is implemented in the stake-sdk here
c. The api server implementation makes call to a smart contract method 'getShares' here retrieve an share amount (uint256) and then converts it to a @ethersproject/bignumber to then converts it to a 'bignumber.js' (v9) here,
d. Finally it multiplies it here with conversion rate to get an asset amount
e. Finally Finally this server api implementation return d as a string here using BN.toString 😮

I think this hextobn util here make sense but Indeed the BN import should probably be aligned and this file should also be written in ts for more type safety at build time.

@amitabh94 I am curious about d. and e. working as expected with account with a high share amount / conversion rate with a lot of decimals, do we have tests for such cases ?

cheers

Bitrise

✅✅✅ pr_smoke_e2e_pipeline passed on Bitrise! ✅✅✅

Commit hash: e74f458
Build link: https://app.bitrise.io/app/be69d4368ee7e86d/pipelines/ae02fb19-c3c0-4056-b404-8691299cde94

Bitrise

✅✅✅ pr_smoke_e2e_pipeline passed on Bitrise! ✅✅✅

Commit hash: 6060b7d
Build link: https://app.bitrise.io/app/be69d4368ee7e86d/pipelines/f6eb14ec-5783-4abe-ae44-cd100edc850d

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
60.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

hi @legobeat to give you more details on where stakedBalanceWei comes from : a. in the mobile it's populated here with 'pooledStakeData' which comes from an api server call, b. this call is implemented in the stake-sdk here c. The api server implementation makes call to a smart contract method 'getShares' here retrieve an share amount (uint256) and then converts it to a @ethersproject/bignumber to then converts it to a 'bignumber.js' (v9) here, d. Finally it multiplies it here with conversion rate to get an asset amount e. Finally Finally this server api implementation return d as a string here using BN.toString 😮

I think this hextobn util here make sense but Indeed the BN import should probably be aligned and this file should also be written in ts for more type safety at build time.

@amitabh94 I am curious about d. and e. working as expected with account with a high share amount / conversion rate with a lot of decimals, do we have tests for such cases ?

cheers

We will have to check whether if we have specific test cases for decimals but what I know is that we use bignumber.js in Staking api which is used to deal with big numbers with decimal places.