Feature Request: Consolidate BNS, BNSX Name, and Available Balance into a Single API Request

[alter-eggo]

Is your feature request related to a problem? Please describe. hey guys, at Leather team we are currently facing issues with throttling limits and excessive API requests, particularly when retrieving account information. This involves multiple API calls for BNS names, BNSX names, and balances, leading to delays and potential rate limiting issues.

Describe the solution you'd like We propose consolidating the retrieval of BNS names, BNSX names, and available balances into a single API request. This would involve enhancing the existing balance endpoint /extended/v1/address/<address>/balances or some new created endpoint, e.g. /profile to include:

• The BNS name, current endpoint: addresses/stacks/<address>
• The BNSX name, current endpoint: v2/contracts/call-read/<address>/bnsx-registry/get-primary-name?tip=latest
• The total balance, endpoint: /extended/v1/address/<address>/balances
• The available balance (total balance minus pending transactions) (currently we do separate request to fetch pending transactions)

By integrating these data points into one request, we can significantly reduce the number of API calls, streamline data retrieval, and improve application performance.

[zone117x]

Hello, there are several different asks in this issue:

• Regarding BNSX -- /v2/contracts/call-read/... is an RPC endpoint provided by the core node (see https://github.com/stacks-network/stacks-core/blob/47db1d0a8bf70eda1c93cb3e0731bdf5595f7baa/docs/rpc/openapi.yaml#L219). This repo has no special handling or understanding of the BNSX contract. I recommend opening a new issue to discuss the possibility of implementing indexing capability for BNSX.

• Regarding available balance -- AFAIK this isn't a standardized concept and requires heuristics to approximate. Are you just subtracting tx fees from pending transactions? What about pending contract-calls that lock STX? It sounds like this would first have to be a separate feature request in another issue.

• Regarding BNS and balances -- merging the functionality of the BNS subsystem into unrelated endpoints for the purpose of working around rate limits sounds like a bad idea. We're generally not going to make changes that violate the single responsibility principal like this.

[nattaja]

Ok, so can we get BTC transfer to BNS names (not talking about BNS-X now)?

[zone117x]

I'm not really sure what you mean by BTC transfer to BNS names. Can you elaborate?

[nattaja]

[nattaja]

Bitcoin transfer to bns names cross wallets (at least Leather and Xverse)

[zone117x]

I'm confused about what you're asking for and how it's related to this issue?

[markmhendrickson]

Thanks, @zone117x for the follow-up!

Regarding available balance -- AFAIK this isn't a standardized concept and requires heuristics to approximate. Are you just subtracting tx fees from pending transactions? What about pending contract-calls that lock STX? It sounds like this would first have to be a separate feature request in another issue.

@alter-eggo mind adding some exact details about how we're currently calculating "available balance" on the client-side?

Regarding BNS and balances -- merging the functionality of the BNS subsystem into unrelated endpoints for the purpose of working around rate limits sounds like a bad idea. We're generally not going to make changes that violate the single responsibility principal like this.

This seems like the key philosophical question here (whether Hiro is inclined to consolidate functionality within endpoints given application-specific needs or not). This would help simplify our implementation in addition to reduce the overall query load that we produce for the API. I presume that fewer queries would be desirable for Hiro as an API host as well, regardless of rate-limit considerations?

[alter-eggo]

@alter-eggo mind adding some exact details about how we're currently calculating "available balance" on the client-side?

@markmhendrickson we:

• fetch balance from api.hiro.so/extended/v1/address/<address>/balances
• fetch pending txs from api.hiro.so/extended/v1/tx/mempool?address=<address>&limit=50
• do calc availableBalance = balance - pendingOutboundTxsSum

[zone117x]

I presume that fewer queries would be desirable for Hiro as an API host as well, regardless of rate-limit considerations?

Unfortunately the load on the db would be the same. There are only really downsides for us in creating special purpose aggregate endpoints like this.

@alter-eggo can you create a new issue to request an "available balance" feature? And can you please include how exactly pendingOutboundTxsSum is calculated. So far it still sounds like an estimated available balance.

[smcclellan]

Closing as scope has changed here.

[markmhendrickson]

I've added an issue for the estimated balance enhancement here.

We'll remove BNSx support from Leather per https://github.com/leather-io/extension/issues/5679 to reduce the volume of requests and avoid rate limiting if a consolidated request isn't possible. We're considering the removal of BNS names from the account selector in Leather as well to further reduce the volume.