View Issue Details

IDProjectCategoryView StatusLast Update
0007448Talerwallet-corepublic2023-06-28 20:26
Reportersebasjm Assigned Tosebasjm  
PrioritylowSeverityfeatureReproducibilityhave not tried
Status confirmedResolutionopen 
Target Versionpost-1.0 
Summary0007448: wallet operation that receive amount in the request should specify if the amount include fee
DescriptionFor example
1.- the user wants to withdraw all the KUDOS from the bank, the amount in the request is the raw amount
2.- the user wants to pay for an article, doesn't have enough coins, wallet redirect to the withdrawal operation, the amount in the request is the effective amount (just what need for the payment)

The same happens to other commands:
 * deposit: the user may want specify the amount to send from the wallet or the amount to receive in the bank account
 * transfer and invoice also

Since the fee is affected by the coin selection this is not an easy calculation that the user can do from the UI.

We have a prepare command for every operation (prepareWitdraw/GetFeeForDeposit/peer/...) this prepare command is being use to get information about the operation like the total fee.

It will be enough to add the intention (semantic) of the amount in the prepare command, return the {effective,raw} amount and then always use the amount raw in the confirmation command.
TagsNo tags attached.


Florian Dold

2023-03-30 11:27

manager   ~0019992

Okay so what we want is for operations that take an *instructed* amount to also include some "mode" argument. But the *raw* and *effective* amounts are always interpreted the same. Can we agree on what we want these modes to be?

For withdrawal, I can see:
* raw (default): instructed amount is what is subtracted from the reserve balance (i.e. it's the raw amount)
* effective: instructed amount is what the user wants to have as material balance in the wallet

However, that does not really cover the user case where the merchant charges fees and the user has to pay for that. So in theory we could have a mode that withdraws enough to pay for some particular claimed order, but IMHO that's overkill.

For deposits:
* max: The instructed amount is ignored (can be zero in the request), and all coins are spent
* raw (default): The instructed amount is what will be paid to the "merchant" (or the customer's bank account), ignoring wire fees
* effective: The instructed amount is how the wallet's balance will be affected. Difficult to compute accurately because refresh is involved.

For peer-push-debit:
* raw (default): The instructed amount is what will be paid, deposit fees are covered by the sender, withdrawal fees from the reserve by the receiver
* effective: Instructed amount is the effect on the material balance. Difficult to compute accurately because refresh is involved.

Should we also have a mode where withdrawal fees are covered by the side that does peer-push-debit? However, that assumes the other party has the same withdrawal coin selection algorithm

For peer-pull-credit:
* raw (default): Amount that the other party has to put in the reserve, where the other party has to pay deposit fees
* effective: Amount that be added to on the initiator's balance

IMHO this is complex enough to warrant a new DD

Florian Dold

2023-03-30 12:18

manager   ~0019996

I've created DD41 with the above definitions as a starting point.


2023-03-31 15:56

developer   ~0019997

As discussed two new concepts, instructedAmount could be

    origin-effective: how the balance is going to change with the operation
    destination-effective: how the balance/account is going to change with the operation

Its going to be specified by the `mode` argument

And new functions to validate input from the user

checkPeerPushPayment(instructedAmount, mode) => AmountResult

type AmountResult = InstructedAmountPossible | InstructedAmountNotPossible

type InstructedAmountPossible = {
  type: "possible",

type InstructedAmountNotPossible = {
  type: "not-possible",
  closestHigher: {
  closestLower: {


2023-06-28 20:26

developer   ~0020318

this is going to be solved after DD41 is finished

Issue History

Date Modified Username Field Change
2022-11-10 13:51 sebasjm New Issue
2022-11-10 13:51 sebasjm Status new => assigned
2022-11-10 13:51 sebasjm Assigned To => Florian Dold
2023-02-17 02:53 Florian Dold Target Version => 0.9.3
2023-03-30 11:27 Florian Dold Note Added: 0019992
2023-03-30 11:27 Florian Dold Assigned To Florian Dold => sebasjm
2023-03-30 11:27 Florian Dold Status assigned => feedback
2023-03-30 12:18 Florian Dold Note Added: 0019996
2023-03-31 15:56 sebasjm Note Added: 0019997
2023-04-13 20:36 Florian Dold Category wallet (TS core) => wallet-core
2023-06-28 20:25 sebasjm Priority high => low
2023-06-28 20:25 sebasjm Status feedback => confirmed
2023-06-28 20:25 sebasjm Target Version 0.9.3 => post-1.0
2023-06-28 20:26 sebasjm Note Added: 0020318