search

near / near-wallet

Web wallet for NEAR Protocol which stores keys in browser's localStorage
https://wallet.near.org
MIT License
214 stars 174 forks source link

Fungible token transfer sometimes requires signing two storage deposit transactions #2338

Open alexauroradev opened 2 years ago

alexauroradev commented 2 years ago

Problem Fungible token transfer sometimes requires signing two storage deposit transactions. Probably this is happening due to the decrease of the storage costs, while the old contracts were using the hardcoded 0.0125 NEAR for the storage (and the new ones -- 0.00125). Example: https://explorer.near.org/transactions/E2tC36DMkTWf6Uo4yxCJNMy7taFBhXiZb539CPCfwHZM -- failed https://explorer.near.org/transactions/8HXBq2QwVPup5wypfynWEgZRXudLxaeX3EhVT36u8vU6 -- succeeded

Expected Behavior Single storage deposit transaction.

Proposed solution Instead of guessing the amount of $NEAR to be deposited for the storage, one need to execute a view call to the token contract and check out the storage balance bounds. CLI version of the call:

$ near view 6b175474e89094c44da98b954eedeac495271d0f.factory.bridge.near storage_balance_bounds
View call: 6b175474e89094c44da98b954eedeac495271d0f.factory.bridge.near.storage_balance_bounds()
{ min: '12500000000000000000000', max: '12500000000000000000000' }

From this data one can extract the needed balance

stefanopepe commented 2 years ago

@MaximusHaximus I don't have clear what to do if the contract doesn't have this view method available, and how this could scale (I suppose this "view" can be called once and easily cached, instead of using the indexer every time).

I'll have you take it from there for both analysis and handover to the team.

From a product standpoint, I see risks in the latency of the operation - but they are lower than having this annoying "double signature" behavior, that would be amplified in presence of 2FA, Ledger and (soon) external services