search

fastnear / fastnear-api-server-rs

25 stars 4 forks source link

xREF balance is not updated when unstaked #11

Closed Sliman4 closed 1 month ago

Sliman4 commented 4 months ago

Unstaked here: https://pikespeak.ai/transaction-viewer/5gW8nMyFANfnJ8nA5LHo3DfJ2SoEhx7ajJcPMnMKsVnE Screenshot (made just now at the time of opening this issue): image

xREF is not a very standard token, in terms of that it's a liquid REF staking token and has methods that modify its balance other than ft_transfer and ft_transfer_call, but I guess this could be fixed by updating the balance after an account executes any transaction that involves an FT contract

evgenykuzyakov commented 1 month ago

I guess xREF should implement ft_mint and ft_burn logs, then it will be picked up by the indexer.

Sliman4 commented 1 month ago

Sounds reasonable, but not sure if they would do it. Any chance the balance can also be updated when someone makes any call to a token contract? In most cases it shouldn't result in additional overhead, since most calls are ft_transfer that modify the predecessor's balance anyway, but this will give better info for more partially-compliant tokens. I'm not sure what's the history behind .tkn.near which has different events, but if they're supported, I feel like more non-standard-but-popular tokens can be supported as well, especially if the solution is quite generic and can fix other tokens we don't know about. I don't really want to request the balances from RPC for each token after I get a json that already has most of the correct numbers in it

marco-sundsk commented 1 month ago

For xREF, it has a upgrade interface, and it's owner, the ref DAO, could call it. So, we are gonna add ft_mint and ft_burn logs soon.

marco-sundsk commented 1 month ago

PR for xREF to fix this, https://github.com/ref-finance/ref-token/pull/5, feel free to leave comment for any questions.

evgenykuzyakov commented 1 month ago

Sounds reasonable, but not sure if they would do it. Any chance the balance can also be updated when someone makes any call to a token contract? In most cases it shouldn't result in additional overhead, since most calls are ft_transfer that modify the predecessor's balance anyway, but this will give better info for more partially-compliant tokens. I'm not sure what's the history behind .tkn.near which has different events, but if they're supported, I feel like more non-standard-but-popular tokens can be supported as well, especially if the solution is quite generic and can fix other tokens we don't know about. I don't really want to request the balances from RPC for each token after I get a json that already has most of the correct numbers in it

This actually not a bad idea if we know that the contract is a fungible token. The only issue is to detect it the first time. Some tokens have false positives, e.g. it has a ft_transfer call, but actually not a fungible token contract.

Whitelist of custom tokens might be a good idea, but not for all FT. E.g. aurora has non-FT methods and some other contracts do too