Предзаказ обмена
...
Отримання рейту - потрібне ДО формування квоти, для розуміння Юзером витраченної комісіі та приблизного рейту після обміну.
Квота запитується при кожній зміні кількості у формі обміну. Буде один єдиний крок обміну.
Умови валідацї на підтвердження Обміну:
- Мінімум та максимум для обміну з налаштувань (нове)
- Баланс Юзера
- Баланс брокера (при отриманні квоти). Юзер бачить як неможливість обміну у формі.
Потребує змін дизайну:
- Показувати мінімум та максимум для Обміну
- Прибрати зайві поля. Залишається один рейт, без можливості робити реверс рейту ( погодити )
- Прибрати поле з комісією
1.1. При отриманні Квоті(перехід на крок підтвердження Квоти) має враховуватись баланс Брокера
Це вираховується на стороні Бека. Пункти при яких буде запитуватися квота:
- зміна кількості на обмін From
- зміна валют Send/Receive
- зміна пари методом “Реверс”
- інтервальне оновлення кожні 10 секунд
1.2. При невдалому отриманні Квоти - повідомляти причину помилки
Погодити тексти помилок для Юзера.
1.3. Попередня форма, до формування Квоти, має бути “калькулятором” для прозорого розуміння Юзером сплати комісіі, обрахунок, рейт
Ця можливсть буде присутня в межах баланса брокера і в межах налаштувань мінімума та максимума на Обміну.
1.4 Користивуч не має бути прив'язаний до Балансу Брокера, на етапі приблизного обрахування його обміну
Буде прив'язанийПри цій запропонованій побудові - Фронт має отримувати зміну по квоті при кожній зміни кількості на обмін. Фронт не зможе адекватно обробляти це бо:
Юзер може протягом короткоко часу ввести, змінити, додати Кількість на обмін багато разів - що приводить кожного разу до Нового запиту отримання Квоти, відповідно отримання Квоти може бути успішним/неуспішним та отримання Квоти може зайняти тривалий час .
Це побуджує велечезну кількість запитів на отримання квоти, що буде означати не зовсім неочікуєму роботу обрахунку у формі на Фронті
Це питання вирішується на стороні БекуВ нас має бути можливість користуватися офф-чейн свапом з підключеною зовнішньою Платформою та без, в контексті однієї форми для обміну.
Якщо - ні , то налаштування потрібно розділити : ЮзерАпп з 2ма видами налаштувань обміну або внутрішній/або зовнішній . Поєднати це проблематично та потребує досліджень та роз'яснень, а потім погодження як це має бути для Операторів, які не потребують інтеграціі зовнішних Платформ.
Це питання потрібно погодити з Менеджментом, враховуючі Операторів які не очікують інтеграцію з зовнішніми платформамиДля Обміну було б раціонально мати РейтСорс у налаштуваннях маркету з показником ЛастПрайс, отриманий з Трейдінгу(або інший рейт-сорс Зовнішньої платформи)
Додатково: у маркета мало б бути делька рейт-сорсів. Та припиненні роботи одного рейт-сорсу(падііня сервісу) - вмикання наступного. Це запобігає некоректній роботі Свапу на платформі.
Тільки для внутрішього Обміну це буде потрібноВ якій валюті береться комісія за Обмін на Зовнішній платформі?
В нас є можливисть налаштування як у базовій так і у валюті квотування - чи не буде це ломати наш Обмін в Операціях?
Це питання потрібно погодити з Менеджментом
Чи показувати взагалі комісію ЮзеруТакож змінилася структура отримання даних для свопу, колись ми отримували масив маркетів для кожної валюти, зараз ми отримуємо всі маркети в одному масиві
Вирішено. Зараз отримуємо в контексті Валюти в новому запиті.ще таке загальне питання до беків, по отриманню даних,
Конкретно до сутності маркетів, до чого вони унаслідувалися від моделі типу «Market» на базі неї будувався логіна свопу, інста ордер і дт., зараз зʼявилася ще одна нова сутність «BasicMarket»
Питання:
Її ми будемо використовувати тільки для off/on chain swap?
Чи ми переходимо тільки на неї?
Після дзвінку:Бек робить оновлення сутностей, найменування полів та їх чищення. В ітозі будуть впровадженні нові сутності а старі видалені згодом.
Фронт буде прибирати поля, які не будуть використовуватитись у сутності Market
Фронт додає нову сутність SwapMarket
____________________________________________________________________
...