diff --git a/concept-amendments.html b/concept-amendments.html index 63c6f37d9b..85b99dbb6a 100644 --- a/concept-amendments.html +++ b/concept-amendments.html @@ -151,6 +151,7 @@
  • Testing Amendments
  • Known Amendments
  • FeeEscalation
  • +
  • FlowV2
  • MultiSign
  • SusPay
  • TrustSetAuth
  • @@ -227,6 +228,11 @@ TrustSetAuth +FlowV2 +v0.32.1 +Expected 2016-08-24 + + Tickets v0.31.0 TBD @@ -278,6 +284,23 @@ TrustSetAuth
  • It becomes invalid (for example, the LastLedgerSequence causes it to expire)
  • It gets dropped because there are too many transactions in the queue with a higher transaction cost.
  • +

    FlowV2

    + + + + + + + + + + + + + +
    Amendment IDStatus
    5CC22CFF2864B020BD79E0E1F048F63EF3594F95E650E43B3F837EF1DF5F4B26Planned for voting, expected to be enabled 2016-08-24
    +

    Replaces the payment processing engine with a complete rewrite. The new version of the payment processing engine is intended to follow the same rules as the old one, but occasionally produces different results due to floating point rounding.

    +

    FlowV2 also fixes an inconsistency in the way transfer fees are calculated between OfferCreate and Payment transaction types. In the old payment processing engine, the initial sender of a transaction paid the transfer fees for offers that were executed as part of payment processing, but the holder of the issuances paid the transfer fee if an offer was executed in offer placement. With FlowV2, the holder of the issuances always pays the transfer fee, regardless of whether the offer is executed as part of a Payment or an OfferCreate transaction. Offer processing outside of payments is unaffected.

    MultiSign

    diff --git a/concept-transfer-fees.html b/concept-transfer-fees.html index 7263c6234e..4f55ced191 100644 --- a/concept-transfer-fees.html +++ b/concept-transfer-fees.html @@ -161,6 +161,7 @@

    The following diagram shows a Ripple payment of 2 EUR.ACME from Alice to Charlie with a transfer fee of 1%:

    Alice sends 2,02€, Charlie receives 2,00€, and ACME owes 0,02€ less in Ripple

    Transfer Fees in Payment Paths

    +

    A transfer fee applies whenever an individual transfer would shift issuances from one party to another through the issuing account. In more complex transactions, this can occur multiple times. Transfer fees apply starting from the end and working backwards, so that ultimately the sender of a payment must send enough to account for all fees. For example:

    Diagram of cross-currency payment with transfer fees

    In this scenario, Salazar (the sender) holds EUR issued by ACME, and wants to deliver 100 USD issued by WayGate to Rosa (the recipient). FXMaker is a currency trader with the best offer in the order book, at a rate of 1 USD.WayGate for every 0.9 EUR.ACME. If there were no transfer fees, Salazar could deliver 100 USD to Rosa by sending 90 EUR. However, ACME has a transfer fee of 1% and WayGate has a transfer fee of 0.2%. This means:

    diff --git a/content/concept-amendments.md b/content/concept-amendments.md index 7d791ca983..67484ce872 100644 --- a/content/concept-amendments.md +++ b/content/concept-amendments.md @@ -95,6 +95,7 @@ The following is a comprehensive list of all known amendments and their status o | Name | Introduced | Enabled | |---------------------------------|------------|---------| +| [FlowV2](#flowv2) | v0.32.1 | Expected 2016-08-24 | | [Tickets](#tickets) | v0.31.0 | TBD | | [SusPay](#suspay) | v0.31.0 | TBD | | [TrustSetAuth](#trustsetauth) | v0.30.0 | Expected 2016-07-19 | @@ -121,6 +122,16 @@ A transaction remains in the queue until one of the following happens: * It becomes invalid (for example, the [`LastLedgerSequence`](reference-transaction-format.html#lastledgersequence) causes it to expire) * It gets dropped because there are too many transactions in the queue with a higher transaction cost. +## FlowV2 ## + +| Amendment ID | Status | +|--------------|--------| +| 5CC22CFF2864B020BD79E0E1F048F63EF3594F95E650E43B3F837EF1DF5F4B26 | Planned for voting, expected to be enabled 2016-08-24 | + +Replaces the payment processing engine with a complete rewrite. The new version of the payment processing engine is intended to follow the same rules as the old one, but occasionally produces different results due to floating point rounding. + +FlowV2 also fixes an inconsistency in the way [transfer fees](concept-transfer-fees.html) are calculated between OfferCreate and Payment transaction types. In the old payment processing engine, the initial sender of a transaction paid the transfer fees for offers that were executed as part of payment processing, but the holder of the issuances paid the transfer fee if an offer was executed in offer placement. With FlowV2, the holder of the issuances always pays the transfer fee, regardless of whether the offer is executed as part of a Payment or an OfferCreate transaction. Offer processing outside of payments is unaffected. + ## MultiSign ## | Amendment ID | Status | diff --git a/content/concept-transfer-fees.md b/content/concept-transfer-fees.md index 8ed99efc4b..44e7afc468 100644 --- a/content/concept-transfer-fees.md +++ b/content/concept-transfer-fees.md @@ -15,6 +15,8 @@ The following diagram shows a Ripple payment of 2 EUR.ACME from Alice to Charlie ## Transfer Fees in Payment Paths ## + + A transfer fee applies whenever an individual transfer would shift issuances from one party to another through the issuing account. In more complex transactions, this can occur multiple times. Transfer fees apply starting from the end and working backwards, so that ultimately the sender of a payment must send enough to account for all fees. For example: ![Diagram of cross-currency payment with transfer fees](img/transfer_fees_example.png)