Multi-Leg Trading Paths

Sensible Taler currencies can be independently implemented by different parties. Not every pair of parties will have established mutual trust relations. In general, a path may have to be used through intermediates.

Payment systems take no risk when they form a connection between two other parties. They usually book money between the mutual accounts of the two parties. And if the transfer fails upstream, they need to undo that by either cancelation or a reverse booking. Prior to the actual payment being made, the elements in the multi-leg trade are requested, and the desired transfer value is reserved to be able to accept it later on. This kind of logic is also used when the payment system is an endpoint for the transaction.

In other words, given that a payment system is already running its internal services, it should not present more effort to also provide intermediate services. This can therefore be offered as a free service. The intermediate leg will be visible to the users, and this may invoke trust in the service, and possibly lead to new clients at a later time. Free advertising, is what it is.

Using Mutual Accounts

It is quite normal that trusted parties hold accounts with one another; they are called mutual accounts although it is not strictly required that it is bidirectional, because trust also does not need to be a bidirectional relation.

In general, a trusting party would be willing to maintain an account with a trusted party, because it has learnt that full backing is properly organised by the trusted party. This means that the trusted party can hold value in its stores as backing for the trusting party.

Unidirectional Trust

This is the most clumsy procedure, but it is still possible to make payment following a (sequence of) trust relations.

Let's say that X wants to pay into an account at a payment service Z, and wants to go through intermediate party Y.

When a trusting party Y holds an account with a trusted party Z, and Y is willing to reserve an amount A on that accuont with Z, then Y can tell Z to move A to any account at Z.

The receiving account at Z would be the end target, at least inasfar as Y is concerned. The value is taken from the account of Y at Z, so the value backed by Y would be reduced. This is covered by a preceding deposit of value at Y, by a party X who would like to pay to Z. As far as Y is concerned, party X is the starting point of the transfer.

Should Z decline the transfer, which would be highly exceptional after prior agreement via FIX Trading, then Y would receive its funds back in its account, then have enough value backing to send a cancelation back to X, along with a return of their funds.

Bidirectional Trust

This can be a simpler procedure, because more of it takes place internally for each step on the way. If the simpler procedure does not work, then the procedure for Unidirectional Trust can be used as a fallback.

Let's say that X wants to pay into an account at a payment service Z, and wants to go through intermediate party Y.

Now, if Y is asked for this, and it holds a mutual account for both X and Z, then it can internally book the value between those accounts. It would signal having done so to Z, which then has the extra value available at Y, which it trusts to be fully backed, and so the value can be forwarded to the internal account inside Z. This assumes that Z internally holds enough funds, otherwise it could ask Y first to payout.

Multiple Intermediates

Direct trading between a payer and payee would be a single-leg transaction. Trading via one intermediate would be a two-leg transaction. There is no reason to stop there. Any sequence of intermediates can be formed, using the procedures for bidirectional or unidrectional trust as appropriate for each of the legs.

When GNU Taler is used for a payment, then the payer is considered to pay from the Exchange that supplied the coins, so that determines the payment system initiating this procedure.

TODO

Transaction Semantics