You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Originally, we had a feature in the extension that could discover addresses with balances by incrementally querying and storing any derived address that had a balance on chain. As the extension no longer has the ability to issue network requests, we would need a different mechanism to allow the extension to store any accounts with balance. (NOTE: This would have to occur after the user has approved a connection to the extension, this process would not be possible during setup without an approved connection)
One potential flow could work like this:
Namadillo tells the extension to derive a set of addresses (lets say 20), starting with 1 (as we already store the default path with the mnemonic, of index 0)
The extension returns these addresses while keeping track of the derived private keys & paths, and Namadillo issues balance queries for each address, and returns a boolean as to whether the extension should store the account, or simply just keeps track of an array of accounts to store
For each account that had a balance, the extension will use the derived private key, encrypt it and store the record
We could have a cutoff of say, 20 balance-less addresses, so if the previous 20 derived addresses have no balance, the process is complete, otherwise, query the next 20 derived addresses
Note: We may need to simply make a very generic call to the extension, which the interface can await. Something like namada.deriveAccounts(parentAccountId, 1, 20), where 1 is the first index to use, and 20 is the number of accounts to generate. The subsequent call would look like: namada.deriveAccounts(parentAccountId, 22, 20), etc., etc. until the number of unused accounts meets whatever threshold we specify. If we wish to store the account because it has balance, we could simply have a simple call: namada.storeAccounts(parentAccountId, Bip44Path[]), where we tell it to simply derive those accounts from the parent account for all paths provided.
The response of deriveAccounts() could be Account[], which would contain the path components, address, & public key, but maybe we only need path & address.
Originally, we had a feature in the extension that could discover addresses with balances by incrementally querying and storing any derived address that had a balance on chain. As the extension no longer has the ability to issue network requests, we would need a different mechanism to allow the extension to store any accounts with balance. (NOTE: This would have to occur after the user has approved a connection to the extension, this process would not be possible during setup without an approved connection)
One potential flow could work like this:
Note: We may need to simply make a very generic call to the extension, which the interface can await. Something like
namada.deriveAccounts(parentAccountId, 1, 20)
, where1
is the first index to use, and20
is the number of accounts to generate. The subsequent call would look like:namada.deriveAccounts(parentAccountId, 22, 20)
, etc., etc. until the number of unused accounts meets whatever threshold we specify. If we wish to store the account because it has balance, we could simply have a simple call:namada.storeAccounts(parentAccountId, Bip44Path[])
, where we tell it to simply derive those accounts from the parent account for all paths provided.The response of
deriveAccounts()
could beAccount[]
, which would contain the path components, address, & public key, but maybe we only need path & address.Or to make it simple:
The text was updated successfully, but these errors were encountered: