Page Comparison

Предзаказ обмена

...

{
  "data": {
    "getOffChainSwapQuote": {
      "id": null,
      "fromCurrencyId": null,
      "toCurrencyId": null,
      "direction": null,
      "amount": null,
      "give": null,
      "receive": null,
      "commissionCurrencyIdcreatedAt": null,
      "commissionexpireAt": null,
      "createdAt": null,
      "expireAt": null,
      "status": "Amount is more then max",
      "isActive": null,
      "isErrored": true
    }
  }
}

...

{
  "data": {
    "getOffChainSwapQuote": {
      "id": null,
      "fromCurrencyId": null,
      "toCurrencyId": null,
      "direction": null,
      "amount": null,
      "give": null,
      "receive": null,
      "commissionCurrencyId": null,
      "commission": null,
      "createdAt": null,
      "expireAt": null,
      "status": "Amount is less then min",
      "isActive": null,
      "isErrored": true
    }
  }
}

...

{
  "data": {
    "getOffChainSwapQuote": {
      "id": null,
      "fromCurrencyId": null,
      "toCurrencyId": null,
      "direction": null,
      "amount": null,
      "give": null,
      "receive": null,
      "commissionCurrencyId": null,
      "commission": null,
      "createdAt": null,
      "expireAt": null,
      "status": "Offchain Swap isn't enabled",
      "isActive": null,
      "isErrored": true
    }
  }
}

...

{
  "data": {
    "getOffChainSwapQuote": {
      "id": null,
      "fromCurrencyId": null,
      "toCurrencyId": null,
      "direction": null,
      "amount": null,
      "give": null,
      "receive": null,
      "commissionCurrencyId": null,
      "commission": null,
      "createdAt": null,
      "expireAt": null,
      "status": "Internal Server Error. Try later",
      "isActive": null,
      "isErrored": true
    }
  }
}

...

1. Отримання рейту - потрібне ДО формування квоти, для розуміння Юзером витраченної комісіі та приблизного рейту після обміну.
   Квота запитується при кожній зміні кількості у формі обміну. Буде один єдиний крок обміну.
   Умови валідацї на підтвердження Обміну:
   - Мінімум та максимум для обміну з налаштувань (нове)
   - Баланс Юзера
   - Баланс брокера (при отриманні квоти). Юзер бачить як неможливість обміну у формі.
   Потребує змін дизайну:
   - Показувати мінімум та максимум для Обміну
   - Прибрати зайві поля. Залишається один рейт, без можливості робити реверс рейту ( погодити )
   - Прибрати поле з комісією
   1.1. При отриманні Квоті(перехід на крок підтвердження Квоти) має враховуватись баланс Брокера
   Це вираховується на стороні Бека. Пункти при яких буде запитуватися квота:
   - зміна кількості на обмін From
   - зміна валют Send/Receive
   - зміна пари методом “Реверс”
   - інтервальне оновлення кожні 10 секунд
   1.2. При невдалому отриманні Квоти - повідомляти причину помилки
   Погодити тексти помилок для Юзера.
   1.3. Попередня форма, до формування Квоти, має бути “калькулятором” для прозорого розуміння Юзером сплати комісіі, обрахунок, рейт
   Ця можливсть буде присутня в межах баланса брокера і в межах налаштувань мінімума та максимума на Обміну.
   1.4 Користивуч не має бути прив'язаний до Балансу Брокера, на етапі приблизного обрахування його обміну
   Буде прив'язаний

2. При цій запропонованій побудові - Фронт має отримувати зміну по квоті при кожній зміни кількості на обмін. Фронт не зможе адекватно обробляти це бо:

   Юзер може протягом короткоко часу ввести, змінити, додати Кількість на обмін багато разів - що приводить кожного разу до Нового запиту отримання Квоти, відповідно отримання Квоти може бути успішним/неуспішним та отримання Квоти може зайняти тривалий час .
   Це побуджує велечезну кількість запитів на отримання квоти, що буде означати не зовсім неочікуєму роботу обрахунку у формі на Фронті
   Це питання вирішується на стороні Беку

3. В нас має бути можливість користуватися офф-чейн свапом з підключеною зовнішньою Платформою та без, в контексті однієї форми для обміну.
   Якщо - ні , то налаштування потрібно розділити : ЮзерАпп з 2ма видами налаштувань обміну або внутрішній/або зовнішній . Поєднати це проблематично та потребує досліджень та роз'яснень, а потім погодження як це має бути для Операторів, які не потребують інтеграціі зовнішних Платформ.
   Це питання потрібно погодити з Менеджментом, враховуючі Операторів які не очікують інтеграцію з зовнішніми платформами

4. Для Обміну було б раціонально мати РейтСорс у налаштуваннях маркету з показником ЛастПрайс, отриманий з Трейдінгу(або інший рейт-сорс Зовнішньої платформи)
   Додатково: у маркета мало б бути делька рейт-сорсів. Та припиненні роботи одного рейт-сорсу(падііня сервісу) - вмикання наступного. Це запобігає некоректній роботі Свапу на платформі.
   Тільки для внутрішього Обміну це буде потрібно

5. В якій валюті береться комісія за Обмін на Зовнішній платформі?
   В нас є можливисть налаштування як у базовій так і у валюті квотування - чи не буде це ломати наш Обмін в Операціях?
   Це питання потрібно погодити з Менеджментом
   Чи показувати взагалі комісію Юзеру

6. Також змінилася структура отримання даних для свопу, колись ми отримували масив маркетів для кожної валюти, зараз ми отримуємо всі маркети в одному масиві
   Вирішено. Зараз отримуємо в контексті Валюти в новому запиті.

7.  ще таке загальне питання до беків, по отриманню даних, 

   Конкретно до сутності маркетів, до чого вони унаслідувалися від моделі типу «Market»  на базі неї будувався логіна свопу, інста ордер і дт., зараз зʼявилася ще одна нова сутність «BasicMarket»

   Питання: 

   Її ми будемо використовувати тільки для off/on chain swap? 

   Чи ми переходимо тільки на неї?
   
   Після дзвінку:

   1. Бек робить оновлення сутностей, найменування полів та їх чищення. В ітозі будуть впровадженні нові сутності а старі видалені згодом.

   2. Фронт буде прибирати поля, які не будуть використовуватитись у сутності Market

   3. Фронт додає нову сутність SwapMarket

...