@MisterTicot Yes, I agree and I disagree. Of course, our representation is different than your standard exchange. However, I think it is clear that our representation is correct (mathematically speaking).

In other words 17900 xlm/BTC makes sense because it is 17900xlm/1btc.
More generally, on stellarport, we represent the price as the result of n units of A / m units of B.

I think the reason your standard exchange does it the other way is because in a standard exchange you cannot invert the trading pair. However, on stellar any asset can be traded against any other asset in any which way.

For instance on the crypto exchanges you always buy the alts with BTC. So, XLM/BTC means that you are buying XLM with your BTC. This is in contrast to your standard way of expressing prices:

1$/apple means 1$/1apple, in other words you are buying apples with dollars. The asset you are buying with is on top and the asset you are purchasing is below.

In some ways, due to its flexibility, trading with stellar is confusing. I guess, the main thing to remember on stellarport is that the price is the mathematically correct one. A/B means that you get units A/ units B.

6 days later

Hey ?

I'm trying to make JavaScript program to sign the XDR of a transaction from Stellar Port locally and send it to the network (or back to you, I'm not sure about the protocol).

I'm failing to convert the XDR string to an actual transaction object that I can sign.

Can you give me some help? I've been reading the documentation and searched on the web but couldn't find my way out of this ?

    excellent portal, well done!
    This being said, I'd like to point out some details that bug me:

    Apparently the calculation of the fee for the taker (=0.0015 * xlm_offer) isn't subtracted from the amount displayed in the "To receive xxx" field, where xxx is the name of the asset.
    This leads to 2 problems for the user:
    1/ the UI doesn't display correct information about the trade, before trading
    2/ this way of calculating and collecting fees constitutes a problem in some situations, although all the math behind is correct

    Let's consider a real-life example that illustrates both 1/ and 2/

    Imagine I want to buy 2 units of a custom asset named "atoz" at a price, say, of 1 XLM each.
    Thus, I select the pair XLM <> atoz, type 2 in the "Offer XLM" field…
    The software displays the number 2 in the "To receive atoz" field ⚠
    BUT creating this bid effectively credits the account with 1.997 atoz.
    Proof:
    https://stellar.expert/explorer/tx/6018d6a70bdeb069faf7c1f7455705f7e2d8236048fb5e0dfec150cfcad66c81

    In this example, the value received does not match the value displayed by the software.
    As a end-user, I can feel fooled. This is no minor issue, I think.
    (explained 1/ )
    Another side effect: it is overly difficult to buy precisely 2.0 atoz in a single trade
    Once the fee calculation is understood, what should I type in the "Offer XLM" field to receive exactly 2.0 atoz?
    I challenge you to find the answer without a pen and a paper!
    If that were not enough, the correct answer depends in some cases on wether your algorithm rounds or truncates the fee amount…
    (explained 2/ )

    Possible solutions:
    . allow spending more from the base asset than what's the user typed, in order to collect fees.
    I, for example, don't care at all paying 2.0xxxxxx XLM instead of 2.0XLM to get what I precisely want that is: 2.0 atoz.
    . OR allow both ways of taking the fee into account (and let the user choose what is appropriate for him) like many bitcoin clients did for subtracting transaction fees (in satoshis)

    Keep up the good work! ? thanks a lot

      wkta understood. Let me take this comment back to the others and chew on it a little. I will get back to you.

        @MisterTicot Sorry, I missed the part where you said you were trying to make a program. It should be as simple as:

        new StellarSdk.Transaction(xdr);
          6 days later
          6 days later

          PSA: We have just deployed the new trading interface to production.

          Additionally, we are introducing a weekly 10k XLM giveaway program as well.

            stellar job ? Really, it looks awesome.

            I would remove the load image. Looks cheesy to me and not necessary.

            7 days later

            We are submitting Stellarport as part of the upcoming SBC.

            Updates since the last SBC

            Migration from lupoex

            • We migrated from the name lupoex to stellarport to better represent our vision

            New landing page

            • Explainer video to explain what stellar and stellarport are
            • Features and screenshots
            • Realtime overall stats of the network (total accounts, 24h payments , trades and operations)
            • Contact form

            New Trading Interface

            • Totally redesigned
            • Vertical orderbook and trade history
            • Redesigned mobile view with tabs etc.
            • Optimized trade widget
            • Added Market/Limit orders
            • Added top and similar markets to the trading screen

            My wallet page

            • Added ability to merge accounts
            • Added ability to edit home domain and inflation destination
            • Enabled adding trust from asset balances page

            New Wallets

            • Built out a new process by which users can create wallets
            • Offers 3 methods - Keystore File, Raw Keypair and Ledger HW

            Misc

            • Added day/night mode
            • Worked on tightening theme/styles
            • Introduced the 10k giveaway (inflation pool) program
            • Enabled login for unfunded wallets
            • Redesigned asset tiles to better match asset brand colors (dynamically generated from asset image)

            Looking forward to 2018!

            Pedity Ah yes, good catch, we have (partially because of the blackwallet hack) decided to close source the code. I have removed the github link in the OP.

                18 days later

                Hey!

                I think you should check your manage(passive)offer transaction builder because it looks like n:d is in the wrong order.

                  istrau2
                  Sure.

                  I'm trying to passively offer one EURT for 10 XLM and took the XDR to sign. By reading it I found that the price is set to 10.

                  The JavaScript SDK API describe price as being: The exchange rate ratio (selling / buying)

                  So it should be {n:1, d:10} or 0.1 right?
                  Or am I missing something?