Closed reliablestaking closed 3 years ago
This makes sense, but we need to do a good job documenting it, mostly:
1) The assets are not on the account itself, but on its addresses (/accounts/{stake_address}/addresses/assets
maybe makes sense to stress this out)
2) There is no guarantee it will ever list all the assets. If an user is using a mangled address, it will not show.
Can you elaborate on 2, what do you mean by mangled address?
One other thing, I think /assets/{asset}
returns the total of an asset, I'm interested in the amount of said asset the account holds.
@reliablestaking A mangled addresses is a type of address which is basically a base address, but the staking key part of it is not part of the wallet. For example, I derive spending key from my wallet and add staking key from your wallet and make a base address. The balance stays with me but essentially you control the delegation. All mangled addresses are either pointer or base addresses but not all pointer or base are mangled addresses.
A chain can not differentiate between a normal base address and a mangled base address. Its something that only a wallet can differentiate. So, there is no way to guarantee that the assets associated with an account are really the assets that the account owner holds.
/assets/{asset}
returns the total assets of an account (so for example your pending rewards). An account cannot hold directly any tokens. Only addresses can hold tokens.
Reopened this issue since the feature it's not released yet. If all go as planned we should have the release in an hour. Will keep you posted.
All systems nominal.
@reliablestaking if you wish, you can test the endpoint (not officially released yet) described here. The endpoint is /accounts/{stake_address}/addresses/assets
. Have fun!
All systems nominal.
@reliablestaking if you wish, you can test the endpoint (not officially released yet) described here. The endpoint is
/accounts/{stake_address}/addresses/assets
. Have fun!
Thanks, this is great! 🎉 Any chance this could be further expanded by including the asset details along with each asset id? This will still require 1 + assets.length
api requests in order to retrieve all of the asset information.
All systems nominal. @reliablestaking if you wish, you can test the endpoint (not officially released yet) described here. The endpoint is
/accounts/{stake_address}/addresses/assets
. Have fun!Thanks, this is great! tada Any chance this could be further expanded by including the asset details along with each asset id? This will still require
1 + assets.length
api requests in order to retrieve all of the asset information.
Good call! Technically, it's possible, but our philosophy is to keep the data minimal and atomic/modular as much as we can. Even the free plan is so generous that calling each asset shouldn't be an issue (if you need the extra data). Generally, the aim is to fetch data in all use cases under 3 hops. We may improve this in the future, but we'd like to keep it as is at the moment for the sake of speed and simplicity.
Ok, no worries! Looping through the unit values and making additional api requests is easy enough - sounds like we shouldn't worry about hitting any api limits if/when needing to query many assets in a short timeframe 👍
Ok, no worries! Looping through the unit values and making additional api requests is easy enough - sounds like we shouldn't worry about hitting any api limits if/when needing to query many assets in a short timeframe +1
If it proves to be a problem in the future, we'll figure it out! ;)
Looks great on testnet! Really appreciate you adding this!
Looks great on testnet! Really appreciate you adding this!
You're welcome!
I currently have a process that will..
/accounts/{stake_address}/addresses
/addresses/{address}
/assets/{asset}
This however can result in a lot of calls, it would be nice if there was an endpoint like
/accounts/{stake_address}/assets
that would return a list of the assets directly.Thank you for taking this into consideration.