Evgeny Kuzyakov

I have the same issue. It prevents opening a lightning channel, probably because it tries to use unconfirmed funds.

In the `near-sdk` FT implementation the contract uses the `account-id-hash` without prefix: https://github.com/near/near-sdk-rs/blob/b8277e009e1d7d8a95faa0b77d99ded0b8afc81d/examples/fungible-token/src/lib.rs#L36

This is technically complicated, because we can't automatically unstake the rewards for a given account. But if the account pings the contract, then we can unstake the extra balance from...

@wjdfx Are you suggesting to update documentation?

Good point. We definitely lacking some good standard for some contracts. While staking pool contract had a standard described in a NEP, it's currently lacking some guarantees that it should...

Let's have a contract for this. This seems like a common problem for multiple contracts. We want to store metadata somewhere and verify signature, but without having this functionality on...

It's not an issue for the production, because the minimum amount of NEAR the account can have is `0.01` due to state staking: https://nomicon.io/Economics/README.html#state-stake Still it's good to address it,...

Should be an easy way of doing it by copying the staking pool factory contract and modifying the input params.

Can't frontend or something like this check the existence of the owner's account? E.g. for testnet lockup contract deployment we verify that the master account exists: https://github.com/near/core-contracts/blob/4f245101d7d029ffb3450c560770db244fc7b3ce/scripts/deploy_lockup.sh#L24-L30 For staking pool,...

Right now, pool doesn't track what's the amount locked due to rewards and what amount is unlocked for a long time. It's not easy to keep track for more than...