Procedures for Peer-to-Peer Trading

Taler Bullion (and its variants) do not need a central market to trade. Trading agreement are peer-to-peer procedures.

Taler Bullion, Energy, Focus and Dinosaur all trade in title-of-ownership in exchange for a Taler payment expressing the value of the underlying currency in a 1:1 ratio. This means that prices are not subject to trade; there is no "foreign exchange" between the underlying value and money.

This means that there is no need for an order book where market prices are balanced against each other on the basis of demand and supply. There is no need to oversee the market. And as a result, it is quite possible to trade directly between peers, as long as nog agreements are made that overlap on any of the resources.

Reference: Peer-to-peer trading is neither new nor unproven. Even in the presence of price negotiations has it been implemented in FIX Agora. This software has been overtaken by Java development (the language that has overtaken its own write-once-run-everywhere objective), and it is not maintained to comply with current-day Java versions. The ideas of FIX Agora are nicely described in the documentation. We develop our own FIX messaging below, founded on the special needs of Taler Bullion.

Lifecycle of an Order

Orders can be entered into the trading peer as a resource traded (such as a gold bar, silver coins, kWh in the hour following tomorrow noon, ...) and the possible quantities, whether the order can be partially taken out, and so on. Of course an order specifies that it is either a buy or sell.

After entry in the trading peer, a process is started, in the hope to clear the order before it expires.

  1. Did a peer register an IOI (indication of interest) that matches this order? If so, try to close the order with that or, if permitted, close part of it.

  2. Connect to peers one-by-one, either randomly or in a preferred order. Submit a QuoteRequest to each peer in turn. The peer should try to respond quickly, possibly with a QuoteRequestReject to skip for now. Any response that is less than optimal may be reason to try elsewhere first, and respond to peers in order of preference.

  3. Register an IOI (indiciation of interest) with each peer. Set a good end time, and track them under the order, so they can be withdrawn when they are no longer valid, or updated.

  4. Retries may be used when (a) a peer was not reachable, or (b) the end of and IOI (indication of interest) has arrived.

  5. At any time, when receiving a suitable QuoteRequest, lock the amount in the order while sending a Quote to try and close the (partial) order.

  6. At any time, when receiving a suitable Quote, lock the amount in the order while trying to close the (partial) order.

  7. When (partially) closing an order, (update or) cancel any peer state, such as QuoteRequest and IOI. Never pull out of final Quote offers (which is why those process lock the (partial) order).

  8. When a (partial) order is completed, send or receive the Taler payment corresponding to it.

The semantics of a final order is an obligation to make a Taler payment with the identity of the order. The proof of this payment serves as the proof of transfer of the title. Additional auditable records may be passed as agreed on the market, including orders for physical transport, but these are the obligations that follow from the payment, as in normal online trading. The rules will be modelled as international business-to-business trading rules, and may well exclude consumers to avoid their extra protection from professional trading responsibilities. Paperwork may be completed digitally, with digitally signed content using a pre-agreed key or key exchange method.

Data for an Order

Aside from the trading constraints themselves, an order is a core object in the trading peer software. It has a certain amount left, plus temporary locks on amounts, for ongoing trading processes. When trading commences, the locked amount is gone and when it is denied the amount is increased with the unfortunately locked amount.

Orders have a list of the peer state that may need to be updated. These may be part of open FIXT1.1 trading connections.

FIX and Security

FIX Messages are protected in a number of ways.

Encryption. FIX messages are not encrypted via the SecureData field. This adds no value in peer-to-peer connections. The FIX transport is run over TLS to protect it from third-party eyes.

Authentication. The initial LogOn exchange is authenticated with SASL. The SASL mechanism should normally use Realm Crossover to link back to the domain name of the party performing login, to avoid manual management of accounts for peer traders. SASL will generally require a number of these LogOn messages before an identity is confirmed. Until completed successfully, no authorisation is assigned to the session. TODO: An alternative would be signing the LogOn message with a challenge using PGP, as required below. PGP keys can be looked up under a DNSSEC-protected domain of a trading peer. The challenge may be derived from the TLS master key, as that involves random seeding from both end points.

Signatures. FIX messages are signed with a PGP key that can be traced under the domain of the sender, which is strong enough to serve as evidence for auditing purposes and as evidence of having agreed to a trade. These certainties are part of making an agreed-upon trade count as obligatory. PGP signatures take the form of RFC 9580 and uses the Version 6 Signature Packet or newer. The signature is applied to the transported FIX message starting at MsgType(35) of the StandardHeader and up to and excluding the SignatureLength(93) field in the StandardTrailer. The signature is stored in its binary form in the Signature(89) field of the FIX StandardTrailer, preceded by the corresponding SignatureLength(93) field. The PGP key must be declared under the trading peer's domain and must be protected with DNSSEC.

Identities. Parties must use the peer identity in the SenderCompID(49) and TargetCompID(56) fields of the StandardHeader of any FIX Message. It is generally in the interest of the party creating identities to not reuse those. If they were, then the other side could choose which signed message with a given identity to use. Being able to present another FIX message does not invalidate a FIX message that has (also) been signed.

Auditing. Traders are wise to keep logs of trading messages, serving as evidence of a negotiated trade. Due to the obligatory trade of follow-up on a trade, it is sufficient to demonstrate such trading as a sign of passing over the underlying value. Parties are forbidden from trading from the instant on when they are declared bankrupt or otherwise incapable of conducting reliable businesses. PGP keys and their DNSSEC-evidence may be saved to prove the ownership of the key by the recognised domain of a trading peer.

Timing. The SendingTime(52) field, which is always required in the StandardHeader, must be setup properly from the LogOn onwards, and it must increment properly. This settles timing during the trading mechanisms, and the relation to times of expiration. Short decision times can be used, with 60 seconds being common, in situations where locks are held on an amount, so as to avoid those to be exceeded. A finalising message may be rejected when it arrives after a lock has expired, though nothing stops the recipient from a re-lock and process anyway. Nothing except having traded the amount with another peer, of course.

Communication

The News and Email messages may be used for short textual messages. These are part of the audit trail of a trade. Once trades are conducted, the related trade is final, in the assumption that any preceding or following News and Email messages count as indicative. They can only be claimed through human processing, but are not standardised.

It is quite possible for such informal messages to be changed into formal FIX status though. For instance, a complete trade may be revoked in retrospect when both parties agree. This would include certainty that there are no auditing problems as a result of this. Exceptional situations, such as bankrupty, may require the other party to agree to such reversals because otherwise an invalid legal situation would arise (namely, trading after being declared bankrupt, and/or not being legally allowed to execute the trade).

The transmission of News will address any trading peer that succeeds in the LogOn exchane. The transmission of Email is dedicated to one specific trading peer, and may travel over an existing or new FIX transport.