Page Comparison

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

Получить перечень валют для offChainSwap с перечнем маркетов:

...

________________________________________

...

__________

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

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

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

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

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

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

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

____________________________________________________________________

...