Ціна BullBear AI (AIBB)

Конструктор AIBB одноразово карбує 10^17 токенів і зараховує весь обсяг на адресу розгортача. Контракт використовує 18 десяткових знаків: кожен AIBB відповідає 10^18 базових одиниць, а початковий випуск — 10^35 базових одиниць. Це початковий випуск під час розгортання, а не поточна кількість токенів в обігу.

Викликати launch може лише власник контракту (owner), і лише якщо запуску ще не було. Після успіху фіксуються номер блоку та час запуску, завдяки чому адреси без дозволу на надсилання до запуску можуть пройти перевірку запуску для переказів. Інші умови, зокрема достатній баланс, залишаються чинними. Цей перемикач описує механізм переказу токена, а не стан запуску продукту AI.

Обмеження до запуску перевіряє відправника токенів. Якщо відправник є у білому списку canAddLiquidityBeforeLaunch, він може обійти перевірку «торгівлю ще не відкрито». Самого лише перебування одержувача у списку недостатньо, щоб звичайний відправник пройшов перевірку. Хоча назва змінної згадує додавання ліквідності, ця перевірка фактично використовується на шляху переказу токенів. Конструктор додає до цього списку розгортача і сам контракт токена; owner також може додавати інші адреси спеціальною функцією. Білий список звільняє лише від перевірки запуску; для переказу й надалі потрібне виконання умов, таких як достатній баланс.

Owner може один раз зареєструвати початкову торгову пару через initializePair, а згодом додавати або вилучати ненульові адреси через addPair і delPair. Реєструється внутрішня множина адрес контракту; сама по собі вона не доводить наявність активного торгового пулу за цією адресою. Попри назву getMinterLength, функція повертає кількість торгових пар, а не кількість адрес, уповноважених карбувати токени.

Контракт спочатку перевіряє відправника: якщо це зареєстрована торгова пара, переказ обробляється як купівля. Інакше перевіряється одержувач; якщо він є зареєстрованою торговою парою, переказ обробляється як продаж. Якщо обидві сторони є торговими парами, перевірка відправника має пріоритет, тому застосовується напрям купівлі. Звичайний переказ, де жодна сторона не є торговою парою, оминає цю гілку комісій. Самого визначення напряму недостатньо для стягнення комісії: контракт має бути запущений, ані відправник, ані одержувач не повинні бути звільнені від комісії.

Ні. Якщо контракт запущено, обидві сторони не звільнені від комісії, а переказ пов’язаний із зареєстрованою торговою парою, контракт віднімає за напрямом купівлі або продажу «суму до скарбниці + суму спалення». Це фіксовані кількості у базових одиницях токена, а не відсоток від суми переказу; 10^18 базових одиниць дорівнюють 1 AIBB. Кількість одержувача = кількість переказу − сума до скарбниці для напряму − сума спалення для напряму. Owner може окремо змінювати обидві суми для купівлі та продажу, тому фіксована сума описує спосіб розрахунку, а не незмінність параметрів назавжди. Формула чистої кількості застосовується лише до успішного переказу. Якщо загальна сума застосовних комісій перевищує кількість переказу, віднімання спричиняє переповнення знизу й усю транзакцію скасовують. Тому підвищення комісій власником може унеможливити раніше можливий переказ; це не підтверджує поточних налаштувань комісій.

У переказі з комісією, що пов’язаний із зареєстрованою торговою парою, після запуску та за відсутності звільнення обох сторін, частина для скарбниці переказується від відправника до treasureWallet і лишається переказом токенів. Частина для спалення спалюється з балансу відправника та зменшує totalSupply. Для кожної частини береться сума відповідного напряму купівлі або продажу. Адресу одержувача скарбниці встановлює owner, але сам цей механізм не надає власникам токенів права на розподіл зі скарбниці.

Ні. Звільнення від комісії записується в isFeeExempt, і owner може його встановлювати або скасовувати; якщо звільнено відправника або одержувача, переказ не входить до гілки комісії купівлі чи продажу. Дозвіл до запуску записується в іншому списку й перевіряє тільки відправника. Саме звільнення від комісії не замінює дозвіл на надсилання до запуску.

transferFrom спочатку перевіряє та витрачає ліміт, наданий відправником викликачеві, а потім виконує переказ токенів. Обмежене схвалення зменшується на повну запитану суму переказу, а не на чисту суму, яку одержувач отримує після комісії; за недостатнього ліміту операція не виконується. Якщо схвалення дорівнює максимальному uint256, воно вважається необмеженим і не зменшується під час використання. Навіть за наявності схвалення діє обмеження на надсилання до запуску. Якщо контракт запущено, обидві сторони не звільнені від комісії та переказ пов’язаний із зареєстрованою парою, також обробляється комісія відповідного напряму.

burn спалює задану кількість AIBB із власного рахунку викликача і вимагає достатнього балансу. Після успішного виконання баланс цього рахунку та totalSupply одночасно зменшуються на однакову кількість. Операція не містить кроку повернення викликачу іншого активу, тому це не викуп іншого активу за AIBB.

Ні. burnFrom спершу має пройти перевірку схвалення, яке цільовий рахунок надав викликачу, а потім спалює токени цільового рахунку; на ньому також має бути достатній баланс. Обмежене схвалення зменшується на кількість спалення, тоді як необмежене схвалення на максимальний uint256 не зменшується. Успішне спалення зменшує і баланс цільового рахунку, і загальну пропозицію, тож самого знання адреси недостатньо, щоб спалити її активи.

rescueToken може викликати лише owner; функція переказує викликачу весь баланс зазначеного ERC-20 токена, який зберігає адреса контракту AIBB. clearStuckEthBalance дає owner змогу переказати ETH-баланс контракту. Ці функції працюють з активами, якими володіє сам контракт, а не з балансом довільного рахунку власника токенів.