(a) would be the easiest and wouldn’t require waiting for the PR to get merged, but the ABI of the staking contract has no such function and it should also take the current wallet balance into account.
(b) writing a custom strategy by combining current RPC methods. Would require waiting for snapshot to merge that pull request. This could use the “hmyv2_getDelegationsByDelegatorByBlockNumber” in combination with “eth_getBalance”
I think this is quite important and I would really like to get your opinions on this.
Taking into consideration the stake ONE totally make sense !
option (a) @MaxMustermann2 works of course but it will need some wait time.
option (b) might be faster if snapshot can merge the propose strategy code in their codebase. My only comments here is about eth_getBalance. We need to query the 4 shard to retrieve the user total ONE balance. We know most of the account balance are now on shard 0 but let’s be future proof and also query balance on the 3 other shards.
Yeah, that’s true, the shard balance should be taken into account. The hmyv2_getBalanceByBlockNumber does also only contain the information for the current shard.
However, I think if, like @MaxMustermann2 said, the precompile extension will be done in a few days it would be the more elegant solution to use the smart contract call and then a bounty would not be required at all.