CIP-0030 GetBalance and Account/Network change

[josemmrocha]

Hello,

After integrating ccvault wallet (making use of CIP-0030), I have two suggestions.

1. getBalance(). It returns now the full balance of the account. Could it be possible to add another endpoint that returns the actual available balance? (total balance - ada attached to tokens). I am having the issue where I retrieve the balance to see if a user can pay for a CNFT, and total balance is higher than CNFT price, but their actual available balance is not. So when submitting the tx, it fails and user dont know why (when it is only that they dont have enough 'free' balance). It will always happen this. And problem will be bigger the more assets an account has.

2. Account/Network change: Is it possible to have events when account/network is changed? Just like Nami wallet has now. That way is easier to subscribe to this event, and act accordingly (calling .enable() again to resfresh the API for example). Without this events it is more difficult to manage when user changes to testnet, or changes account, having the website with dApp connector 'opened' and not knowing this changes took place.

Thanks

[rooooooooob]

@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.

[josemmrocha]

"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.

[mkazlauskas]

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>;