CIP-0030 GetBalance and Account/Network change about cips HOT 3 OPEN

@josemmrocha

Could it be possible to add another endpoint that returns the actual available balance? (total balance - ada attached to tokens).

We talked about this in the original CIP-30 PR as well as #171 about how we might want to have more granularity for the balance/utxos endpoints but no consensus has been reached as of yet.

(total balance - ada attached to tokens)

What do you mean attached? Perhaps I'm misunderstanding you but can't you use ADA that is together with a non-ADA multiasset? You'll just want to return said asset(s) in a change output to the user to only use the ADA. Although if it's juts a single one then you'll still have the min ADA per utxo calculation coming into play so if that UTXO only had the minimum attached to it potentially wouldn't help if you weren't going to have a change output for some reason. Or if you're using multiple and bunching them in a single change output that ADA is still usable. Of course the user may or may not want that to happen but I'm not sure what the ideal general API for that would be about controlling what the user wants done with his or her UTXOs/bundling and that seems like it may be more on the wallet's side than the CIP-30 spec side but we haven't had this come up in discussion so far so maybe there is a better solution.

Account/Network change: Is it possible to have events when account/network is changed?

See #151 these were removed from CIP-30's first PR in order to get it merged as we had not reached a consensus yet by that time in the original PR and #151 was opened up to continue work there.

We should move this discussion over to #151 and #171 respectively instead of this issue.

from cips.

"What do you mean attached?" -> Sorry I meant 'locked'. I know I can make use of locked ADA in the inputs. But the problem comes when you build/submit an ADA transaction where quantity is between the 'usable' balance and total balance. For example, I had a case where user had 18 ADA (total balance). But had 6 ADA locked with assets (So 12 'free' ADA). I was trying to make a transaction of 14 ADA (Wallet allowed me to build the tx because the getBalance() is telling me I have enough ADA). But...when submitting the transaction it fails because the built tx is not ok (because minimum utxo not met for ex.). This could be managed before submitting the tx, if we had a getNonLockedBalance() or something like that.

As you said, I will continue the discussion in #151 and #171 . Thanks.

from cips.

For example, I had a case where user had 18 ADA (total balance). But had 6 ADA locked with assets (So 12 'free' ADA). I was trying to make a transaction of 14 ADA (Wallet allowed me to build the tx because the getBalance() is telling me I have enough ADA).

I don't think there's any locking and you should be able to make this tx (assuming ADA resides in addresses owned by the wallet). Sounds like your input selection is not working correctly. Edit: you should be able to spend 18 - ("min utxo value" of all your assets combined in a single utxo, that would be your change output)

Of course the user may or may not want that to happen but I'm not sure what the ideal general API for that would be about controlling what the user wants done with his or her UTXOs/bundling and that seems like it may be more on the wallet's side than the CIP-30 spec side but we haven't had this come up in discussion so far so maybe there is a better solution.

Input selection is a wallet concept, so it might make sense to have on CIP-30. It requires access to protocol parameters, so the interface is currently not sufficient to be able to do that on the dApp side without having an external source for it.

api.getUtxos(amount) is not sufficient, because:

1. It doesn't have transaction context, so it can't compute minimum fee and implicit coin (deposit/deposit reclaim/withdrawals), which can make input selection invalid if the dApp adds certificates or withdrawals to the tx.
2. It only works for single output (an array of amounts would work better)

Input selection API could look something like that (preliminary, would need to think about this a little more, e. g. might be a good idea to return new outputs instead of change if we think it's wallet's responsibility to pick a change address):

type Lovelace = number;
type Selection = { inputs: TransactionUnspentOutput[]; change: cbor<value>[]; minFee: Lovelace; };
type BuildTx = (selection: Selection): Promise<cbor<transaction>>;

api.selectUtxo(buildTx: BuildTx): Promise<Selection>;

from cips.