Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SEP-38: add context request parameter and fee & total_price response attributes #1204

Merged
merged 21 commits into from
May 23, 2022

Conversation

marcelosalloum
Copy link
Contributor

@marcelosalloum marcelosalloum commented May 17, 2022

What

Add the ability for SEP-38 quotes to detail the quote fees under the fee response field, and calculate the fees and price based on the input parameter context:

  • context is a mandatory request field and can be one of sep6 or sep31.
  • total_price is a new response field that describes the conversion rate with the fees included.
  • price will describe the conversion rate without including fees.
  • The GET /quote/:id response will look like this:
    {
      "id": "de762cda-a193-4961-861e-57b31fed6eb3",
      "expires_at": "2021-04-30T07:42:23",
      "total_price": "5.42",        // 542/100
      "price": "5.00",              // (542-42)/100
      "sell_asset": "iso4217:BRL",
      "sell_amount": "542",
      "buy_asset": "stellar:USDC:GA5ZSEJYB37JRC5AVCIA5MOP4RHTM335X2KGX3IHOJAPP5RE34K4KZVN&",
      "buy_amount": "100",
      "fee": {
        "total": "42.00",
        "asset": "iso4217:BRL",
        "details": [
          {
            "name": "PIX fee",
            "description": "Fee charged in order to process the outgoing PIX transaction.",
            "amount": "12.00"
          },
          {
            "name": "Service fee",
            "amount": "30.00"
          }
        ]
      }
    }
  • Also, updated the description of SEP-6 and SEP-31 transactions amount_fee and amount_fee_details, stating that it should be consistent with SEP-38 fee_details when provided.

Why

Comparing the previous design with partners that have a long history in the currency conversion business we found out that it's pretty common to use not only margin but also additive/inclusive fees.

That's why we decided to change the SEP design, so we can be compliant with these businesses.

Regarding the inclusion of "total_price", this was introduced so the conversion price and fees can be displayed to the user regardless of the remittance platform using additive or inclusive fees. For instance:

  • Moneygram uses additive fees, so they use price only:
    Screen Shot 2022-05-23 at 11 52 58 AM

  • wise.com uses inclusive fees, so they use total_price:
    Screen Shot 2022-05-23 at 11 53 09 AM

…` request parameters, so anchors can calculate the quote taking into consideration what they will be used for. ([#????](https://github.com/stellar/stellar-protocol/pull/????))
…ters, so Anchors can detail the margin costs.
@marcelosalloum marcelosalloum changed the title [WIP] SEP-38: add context and fee_details SEP-38: add context request parameter and fee_details response parameter May 17, 2022
@marcelosalloum marcelosalloum marked this pull request as ready for review May 17, 2022 20:48
ecosystem/sep-0038.md Outdated Show resolved Hide resolved
ecosystem/sep-0038.md Outdated Show resolved Hide resolved
ecosystem/sep-0038.md Outdated Show resolved Hide resolved
ecosystem/sep-0038.md Outdated Show resolved Hide resolved
ecosystem/sep-0038.md Outdated Show resolved Hide resolved
ecosystem/sep-0038.md Outdated Show resolved Hide resolved
@JakeUrban
Copy link
Contributor

@marcelosalloum I forgot to add a top-level comment so I'll do that here. Overall I think this is the right approach, although it seemed to be limiting the fees to only using the margin. I thought we had agreed to support additive / inclusive fees too, but I'm happy to discuss further.

@marcelosalloum
Copy link
Contributor Author

@marcelosalloum I forgot to add a top-level comment so I'll do that here. Overall I think this is the right approach, although it seemed to be limiting the fees to only using the margin. I thought we had agreed to support additive / inclusive fees too, but I'm happy to discuss further.

Since you're suggesting to support additive fees as part of SEP-38, should we enforce that SEP-31 amounts should be consistent with SEP-38's? For instance, sep31.amount_in == sep38.sell_amount (when quotes are used).

@marcelosalloum marcelosalloum marked this pull request as draft May 19, 2022 00:51
@marcelosalloum marcelosalloum force-pushed the sep38-context-and-fee-details branch from 5423002 to 243c2f7 Compare May 19, 2022 20:44
@marcelosalloum marcelosalloum marked this pull request as ready for review May 19, 2022 20:44
@marcelosalloum marcelosalloum requested review from JakeUrban and removed request for JakeUrban and reecexlm May 20, 2022 21:55
@JakeUrban JakeUrban changed the title SEP-38: add context request parameter and fee_details & effective_price response parameters SEP-38: add context request parameter and fee & effective_price response parameters May 23, 2022
@JakeUrban JakeUrban changed the title SEP-38: add context request parameter and fee & effective_price response parameters SEP-38: add context request parameter and fee & effective_price response attributes May 23, 2022
Copy link
Contributor

@JakeUrban JakeUrban left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have one requested adjustment but otherwise this looks ready!

ecosystem/sep-0031.md Outdated Show resolved Hide resolved
@marcelosalloum marcelosalloum requested a review from JakeUrban May 23, 2022 17:33
JakeUrban
JakeUrban previously approved these changes May 23, 2022
Copy link
Contributor

@JakeUrban JakeUrban left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've asked @leighmcculloch to take a look, but if he is busy we can merge.

@leighmcculloch
Copy link
Member

This PR doesn't communicate why this change is being made. Could you add that context? I'm specifically interested why applications need a price and an effective_price.

@leighmcculloch
Copy link
Member

price will describe the conversion rate without including fees.

Does this statement refer only to the fees that get added on, and not fees built into any rates?

@marcelosalloum
Copy link
Contributor Author

@leighmcculloch:

This PR doesn't communicate why this change is being made. Could you add that context? I'm specifically interested why applications need a price and an effective_price.

Good point! I've just updated the PR description.

--

price will describe the conversion rate without including fees.

Does this statement refer only to the fees that get added on, and not fees built into any rates?

Yes, only refers to fees that appear under the "fee" response parameter.

@leighmcculloch
Copy link
Member

Is "effective price" the best name we can give the price-inclusive-of-fees concept? A quick internet search revealed there is another concept named "effective exchange rate" which has different meaning. If there's not a better name sgtm, but I also don't see the effective on either of the screenshots, so maybe there's a better name we can use that will align with the existing money transfer industry?

@marcelosalloum
Copy link
Contributor Author

Is "effective price" the best name we can give the price-inclusive-of-fees concept? A quick internet search revealed there is another concept named "effective exchange rate" which has different meaning. If there's not a better name sgtm, but I also don't see the effective on either of the screenshots, so maybe there's a better name we can use that will align with the existing money transfer industry?

there's something called "out-the-door price" that has a similar meaning but is only used in the car selling business. I didn't really find a well known concept for this, so the options I have in mind are:

  • effective_price
  • out_the_door_price
  • final_price
  • total_price
  • customer_price

None of them seems great though, I'd continue with effective_price unless you guys think another option is clearly better.

@JakeUrban
Copy link
Contributor

The only other decent option we have (in my opinion) is price_including_fee or price_including_fees. I don't have a preference here.

The important thing is that this attribute communicates the discrepancy between price and the value you get when you calculate the rate using sell_amount and buy_amount.

@leighmcculloch
Copy link
Member

leighmcculloch commented May 23, 2022

I would lean total price, given that the term total is used in at least one of the screenshots above. Effective has a non-specific sense to it for me, where-as the price being described is a concrete value. But I don't feel strongly, and in light of all the options effective also seems fine too.

@JakeUrban JakeUrban changed the title SEP-38: add context request parameter and fee & effective_price response attributes SEP-38: add context request parameter and fee & total_price response attributes May 23, 2022
@marcelosalloum marcelosalloum merged commit faa9916 into master May 23, 2022
@marcelosalloum marcelosalloum deleted the sep38-context-and-fee-details branch May 23, 2022 21:46
marcelosalloum added a commit to stellar/anchor-platform that referenced this pull request May 27, 2022
…-protocol#1204 (#285)

### What

Update platform code to be compliant with the protocol change added in stellar/stellar-protocol#1204 & stellar/stellar-anchor-platform#32. 

Changes in the SEP:
* SEP-38 `GET /price` and `POST /quote` requests now need the new parameter `context=sep6|sep31`.
* SEP-38 `GET /price` and `GET|POST /quote` responses now return the new parameters `total_price` and `fee`.

Changes in the Platform->Anchor event schema:
* The `QuoteEvent` schema contains 4 new parameters: `"fee"`, `"total_price"`, `"send_amount"` and `"buy_amount"` parameters.

Changes in the Platform->Anchor `GET /rate` callback:
* Update types from `["indicative", "firm"]` to `["indicative_prices", "indicative_price", "firm"]`.
* Add the request parameter `"context=sep6|sep31"`, that should be mandatory for `["firm", "indicative_price"]` types.
* Add `"fee"`, `"total_price"`, `"send_amount"` and `"buy_amount"` response parameters.

### Why

Close #270, addressing the changes from stellar/stellar-protocol#1204 & stellar/stellar-anchor-platform#32.
marcelosalloum added a commit to stellar/stellar-anchor-tests that referenced this pull request Jun 3, 2022
### What

Update SEP-38 tests based on stellar/stellar-protocol#1204. The changes include:
* SEP-38 `GET /price` and `POST /quote` now require the mandatory `context` request parameter.
* SEP-38 `GET /price` and `GET|POST /quote` now return the mandatory response parameters `total_price` and `fee`.
* The updated formulas from [SEP38#price-formulas](https://github.com/stellar/stellar-protocol/blob/faa99165050dcd44a9e0f700c3d019258d8b4321/ecosystem/sep-0038.md#price-formulas) are now being validated.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants