near / account-lookup

Temporary tool for account / lockup lookup

Account lookup service

This is a temporary tool to get the data from the deployed lockup contracts.

Contributing

To run this tool locally, use:

yarn
yarn start

account-lookup's Issues

Security Policy violation SECURITY.md

This issue was automatically created by Allstar.

Security Policy Violation
Security policy not enabled.
A SECURITY.md file can give users information about what constitutes a vulnerability and how to report one securely so that information about a bug is not publicly visible. Examples of secure reporting methods include using an issue tracker with private issue support, or encrypted email with a published key.

To fix this, add a SECURITY.md file that explains how to handle vulnerabilities found in your repository. Go to https://github.com/near/account-lookup/security/policy to enable.

For more information, see https://docs.github.com/en/code-security/getting-started/adding-a-security-policy-to-your-repository.

---

This issue will auto resolve when the policy is in compliance.

Issue created by Allstar. See https://github.com/ossf/allstar/ for more information. For questions specific to the repository, please contact the owner or maintainer.

lockup information is incorrect or null

I tried the function viewLockupState , and lockup amount is incorrect and lockup timestamp is null

Fix lockupAccountId variable

I was doing QA and code review and noticed that when you type in mike.near to the Account Lookup it will not get through all the list of validators, and a console error will appear.

https://near.github.io/account-lookup/#mike.near

This is in relation to the frontend task here:

https://github.com/near-projects/account-lookup

This is not your fault, but a bug that we discovered.

I think fixing this bug will help the team understand how NEAR works.

Error: Querying call/aurora.pool.near/get_account_total_balance failed: wasm execution failed with error: FunctionCallError(HostError(GuestPanic { panic_msg: "panicked at 'Failed to deserialize input from JSON.: Error("the account ID is invalid", line: 1, column: 83)', staking-farm/src/views.rs:69:1" })).
{
"error": "wasm execution failed with error: FunctionCallError(HostError(GuestPanic { panic_msg: "panicked at 'Failed to deserialize input from JSON.: Error(\"the account ID is invalid\", line: 1, column: 83)', staking-farm/src/views.rs:69:1" }))",
"logs": [],
"block_height": 57351511,
"block_hash": "FzAWmPtZcnqZpMAjbTyRPjZU7iwPSB2jowsXx5tKvAej"
}

This is because the smart contract on aurora.pool.near is slightly different and checks to see if a valid NEAR name was given as an argument.The problem is:the old contracts didn't check for a valid account name, and this javascript tool was sending the account ID of 71ed549b49566eeb37cdb70e18f2f23800fc1496.lockup.near doesn't exist as an account. Obviously the doesn't exist text is invalid.I think the fix will be around here:https://github.com/near-projects/account-lookup/blob/5426914b2258946d51f0166d721c9498bbc3e787/script.js#L338-L339

where the lockupAccountId is being set incorrectly to include the words “doesn’t exist”If you need to check if it exists or not, you can look at the cookbook recipe here:https://github.com/near/near-api-js/blob/master/examples/cookbook/utils/check-account-existence.js

Fetching an account without an assosiated lockup contract should display basic information and staking info

At some point, we broke the possibility to lookup non-lockup accounts. @mikedotexe forked this tool and I can see that indeed the tool used to work on his account: https://mikedotexe.github.io/account-lookup/#mike.near

@telezhnaya Could you consider fixing it in #10?

Extract the business logic into a separate npm package

We currently have a copy-paste implementation with some extra features on NEAR Wallet side and we plan to also integrate lockup viewing into NEAR Explorer.

@shelegdmitriy As per our discussion, please, extract the main logic into a separate git repo and make npm package out of it. Check out Wallet code to see what data do they need, so this new package can provide it.

Security Policy violation Branch Protection

This issue was automatically created by Allstar.

Security Policy Violation
No protection found for branch master

---

This issue will auto resolve when the policy is in compliance.

Issue created by Allstar. See https://github.com/ossf/allstar/ for more information. For questions specific to the repository, please contact the owner or maintainer.

Provide the financial department with foundation accounts details

It would be good if we can automate collecting the data for the financial department: how many tokens are liquid in foundation accounts

Ugly, but working solution is here
https://github.com/near/account-lookup/blob/temp_foundation_liquid_amount/script.js

It's a good idea to finish it and provide the code with the instruction, or at least not to lose it and reuse it later if the data needs to be refreshed

Handle deleted accounts and provide instructions if those are implicit accounts

There has been a situation where the implicit account has been converted into a named account, while the lockup contract has been issued for the implicit account id.

https://near.github.io/account-lookup/#ed25519:8tdgHbaBhUoKZnzA4fn4RiDj36JGf2nuH51CRfAczkR8 (this displayed nothing, while it should have displayed that the account is deleted and provide some helpful instructions, see below)

The original implicit account was: https://explorer.near.org/accounts/753be6a50dae345c1c574e186ab30cb7d604639dd67b17660f4c134fa0aebdbb

Then it was converted into a named account, and thus the implicit account has been deleted in favor of https://explorer.near.org/accounts/mikec.near

The lockup has been issued for the implicit account, and here it is: https://explorer.near.org/accounts/46afae1dd24b0ca3796293909c89335c6f215a3a.lockup.near (see the transaction details, which specified the owner account id)

If the owner still has the private key (keypair) corresponding to ed25519:8tdgHbaBhUoKZnzA4fn4RiDj36JGf2nuH51CRfAczkR8 public key, they can transfer 1 NEAR to 753be6a50dae345c1c574e186ab30cb7d604639dd67b17660f4c134fa0aebdbb account id, and thus gaining the control over lockup contract through this implicit account again.

The data is wrong if we use custom block_height

Story
we have an account https://explorer.near.org/accounts/opgran01.near
we checked the info for this account at the moment 31 dec 2020 (block_height 26490580)
the tool told us this account had 40 tokens as the owner and 35 tokens on the lockup
but in reality, the lockup had huge amount of money and we have the TX about it
https://explorer.near.org/transactions/3db8TpxEu1kSB4v4mPRBCqHsBBna8Zfq2Jkvf67A4CVs
These tokens were moved later, but only at Jan 12, 2021, so it shouldn't be shown at the moment Dec 31 2020.
https://explorer.near.org/transactions/9bw5bvmDGG2CkqgKhC51Yz2rLPLFCwSJXSWgGgsCYvZe#7hyM3yPVs1X8SJmhpYHj2ADmdtuM1rG4etUboH3adDd2

I was using this branch to debug it on the historical data https://github.com/near/account-lookup/tree/temp_foundation_liquid_amount
I tried to create the hotfix for my solution #20, but it should be much more complex.
I've also found some bugs there. These places are taking the information about the latest block, not about the desired one.
https://github.com/near/account-lookup/blob/temp_foundation_liquid_amount/script.js#L120
https://github.com/near/account-lookup/blob/temp_foundation_liquid_amount/script.js#L299
All viewFunction calls do the same
https://github.com/near/account-lookup/blob/temp_foundation_liquid_amount/script.js#L166

It's better to start from the beginning and create the solution where it's possible to enter the optional desired block_height at the main page.

Our final goal is to have the ability to set up the desired moment and see:

• account balance
• account staking info
• lockup balance
• lockup locked balance
• lockup staking info

Rewrite the logic to the same as in core-contracts/lockup

That should help us to get rid of bugs, hopefully