Почему я начал все генерировать заранее?

Последние 2 дня я переписывал свой скрипт по LayerZero, решая основные проблемы. Теперь это будет работать так:

1. Исходя из конфига будет полностью генерироваться путь, от и до, включая весь конфиг.
2. При первом запуске скрипт будет генерировать пути заранее в папку paths и записывать пути в {wallet_address}.json
3. При повторных запусках скрипт будет спрашивать нужно ли перезаписать пути для кошельков, которые уже содержат пути.

В чем преимущество такого способа?

- в разы легче дебагать, ты заранее знаешь весь путь для каждого кошелька, суммы и пр.
- возможность просчитать необходимые балансы, суммы комиссий и пр.
- возможность записывать статус для каждой строки
- проще прикрутить многопоточность, т.к. каждый поток будет работать со своим файлом

Сегодня начал тестить и это реально пиздато, теперь каждая функция возвращает True в случае успешного действия, а скрипт записывает статус как Success, при повторном запуске - софт пропустит действия со статусом Success. Это практически реализованная пауза, возможность перезапустить и продолжить с того-же места где остановился.

Пару полезностей по работе с LayerZero и не только

1. API LayerZero: https://api-mainnet.layerzero-scan.com/tx/
Можно по хешу проверять статус транзакции, но сразу скажу - порой лагает очень сильно, лучше использовать сразу 2 метода: чекать баланс в конечной сети + чекать статус транзакции по API. Если что-то вернет True - можно продолжать работу.

2. amount = token_contract.functions.balanceOf(address_wallet).call() не лучшая идея для назначения amount для транзакции, иногда вы будете получать insufficient balance
лучше уменьшайте сумму примерно на 0.0005% - будет все четко

3. Если контракт не апрувнут, вы всегда можете декодировать любую транзакцию по hash.
Как этом можно сделать прикрепил в изображении

4. 1inch - идеальное решение, если вы хотите одной функцией покупать разные токены в разных блокчейнах, но стоит колдовать с настройками gas и gas_limit. Я рекомендую создать словарь бустов, который для разных блокчейнов будет на разный % бустить эти значения.
Используйте такой подход в принципе если ваша функция универсальна для работы с разными блокчейнами.

5. Polygon и Fantom уебанские сети - транзакция с маленьким газом/газ-лимитом зависнет в мемпуле и не будет обработана.
Ей присвоится хеш, но по факту она не будет никогда включена в блокчейн. Рекомендую обрабатывать для таких сетей подобный вариант рекурсией с увеличением значений газ и газ-лимита

Ему конец, этому вашему даомемкеру 😜

Как задекодить любую транзакцию по data?

Недавно начал писать софт под ZkSync и возникла проблема с быстрым декодингом транзакций, т.к. процентов 80 контрактов не верифнуты. Нашел идеальный вариант - онлайн декодер. Функционал максимально простой, вставляете data-транзакции и выбираете 4byte Directory API

Ссылка на декодер

Слив EIP-1559 2023

Решил спустя долгое время поделиться своим универсальным решением по переходу с Legacy на EIP-1559. Если кратко, то скрипт парсит последние 5 блоков и высчитывает средние значения maxFeePerGas и maxPriorityFeePerGas.

*Для сетей BSC и Fantom, где нет EIP-1559 скрипт добавляет значение gasPrice

[ Github ]

В начале недели пытался написать софт под friend.tech. Это была моя первая попытка в MEV-бота.

Идея была такая: искать transfer на пустые кошельки как потенциальных новых юзеров, смотреть есть ли такой кошелек в API, брать @twitter и смотреть через API данные твиттера.

Начал я писать на python async, но сильно не устраивала скорость. Софт находил потенциальный кошелек примерно за ~20-40 секунд (к слову за это время 60% юзеров уже успевали выкупать первые акции). Тогда я вспомнил терна и его посты про ЯП GO. Сутки поковырялся и удалось переписать софт уже с местной асинхронностью (горутины). И вот тут софт искал нужные мне кошельки с определенным кол-вом подписчиков за 1.5-2 секунды (это учитывая 2 запроса к API: friend.tech и twitter). С такой скоростью уже можно было работать.

Дальше самое сложное - успевать выкупать акции. Начинал я с +4 блока от Buy-транзакции. Удалось разогнаться до +1-2 блока, я пытался ускориться, но не получалось (что только я не перепробовал). Основная проблема была во времени поиска buy-транзакции, тут нет привычного мемпула (он есть, но не тот что нужен). Туда изредка попадают транзакции (хз почему) как раз за 4 секунды (2 блока) до включения транзакции в блок, но работать с таким мемпулом не было смысла.

Тогда я начал копать глубже и оказалось что в технологии Rollup (Optimism) мемпулом является секвенсор. Секвенсор отвечает за упорядочение транзакций, именно в него сначала попадают транзакции, а после уже собираются в блоки.

Как получить доступ и смотреть в транзакции в секвенсоре я не знаю. Текущие боты явно имеют доступ в секвенсор. Я же остановился на спаме по 2 транзакции в блок, дальше пока нет времени изучать эту тему. Но тема реально интересная для изучения.

P.S. GO кстати очень крутой, мне зашел.

Как бесплатно оценивать стоимость токенов?

Нашел нормальную API, которая позволяет получать актуальную стоимость токенов.

Ограничений у API нет. В запросе нужно отправлять ID токена (конечной точки для получения ID нет 🧠), но можно спарсить инфу и найти.

Запрос на python может выглядеть примерно так:

def get_token_price(token_id):
    url = f"https://api.coinlore.net/api/ticker/?id={token_id}"
    response = requests.get(url)
    if response.status_code == 200:
        data = response.json()
        if data and isinstance(data, list) and isinstance(data[0], dict):
            price_usd = data[0].get("price_usd")
            if price_usd is not None:
                return Decimal(price_usd)
            else:
                logging.error(f"Ключ 'price_usd' отсутствует в данных: {data}")
                return None
        else:
            logging.error(f"Неожиданный формат ответа: {data}")
            return None
    else:
        logging.error(f"Статус ответа сервера: {response.status_code}")
        return None

Чем я занимался 2 месяца [part 1]

Спойлер: писал софт для zkSync и не только

В первую очередь хотелось сделать что-то уникальное. Поэтому к написаю софта я подошел основательно. Во-первых, я юзал аутсорс для поиска решений и в принципе реализаций каких-то частей проекта. Во-вторых, несколько недель ушло в принципе чтобы продумать все связи/логику.

Почему так долго? В первую очередь мне хотелось упростить себе работу в будущем. Поэтому я решил не просто написать софт для zkSync, а написать основу для всех софтов в будущем и уже на этой основе написать zkSync в качестве первого проекта.

В чем преимущество такого подхода? Упрощает разработку в будущем, плюс так как основа универсальна, я могу допиливать её отдельно от проектов, при этом все изменения будут применимы ко всем проектам.

Что входит в основу? Сюда входит БД, логика, выводы (web), обработки и т.п.. Да, я начал юзать БД в проектах и это одно из лучших решений в принципе. БД позволяет хранить очень много информации: данные кошельков, данные транзакций, текущие займы, любую другую информацию.

Зачем хранить всю эту информацию? В первую очередь это позволит дать софту больше инфы про каждый кошелек: хранить чтобы уже было сделано, какие NFT сминчены и т.п. Огромный плюс в возможностях вывода в web, по факту можно сделать локальный etherscan.

Чем я занимался 2 месяца [part 2]

Как примерно работает моя логика? В первую очередь софт хранит все действия которые были выполнены на кошельке. К примеру, минт NFT X. Это уникальное действие, которое можно сделать 1 раз. После того как софт сминтил NFT - он записал это в БД. Если софт вылетел и вы заново его запустили - он больше не будет минтить NFT X он уже знает что для этого кошелька он её заминтил.

И это проявляется во всем. Софт сам генерирует задачи для каждого кошелька на основе действий, которые он уже выполнял, он понимает что не делал бридж - он запланирует это действие на кошельке.

Лично я прошу указать лишь действия которые нужно будет сделать и количество транзакций. Расчеты сумм происходят непосредственно внутри софта, генерация задач, назначение даты и времени. Для набива объемов нужно указать к примеру только сумму какую вывести с биржи и какой объем набить в $.

Софт не будет в продаже (или будет или он нахуй никому не нужен), но пока не будет

Почему cli-интерфейсы это хорошо

Давно хотел уйти от нескольких исполнительных файлов по типу main.py \ withdrawal.py к более удобному формату. И cli-интерфейсы мне помогли. Мы не заставляем пользователя искать исполняемые файлы, запускать их, вместо этого они могут просто в терминале ввести подходящую команду.

Coinbase wallet moment

Для UI выбрал Сoinbase wallet, поскольку его проще автоматизировать нежели Metamask с его защитами. И вот значит все вообще отлично, все уже написано.

Пытаюсь в конце подписать транзакцию для бриджа 7$ (на балансе 20$) и в момент подписи вылезает ошибка. 10 раз руками пересоздаю транзакцию и с 10 раза мне дает подписать транзакцию.

Насколько нужно быть даунами, чтобы во-первых криво рассчитывать газ, во-вторых запрещать пользователю отправлять транзакцию с любым газом. Помимо этого отредактировать газ нельзя, только отменить транзакцию.

Это настолько сюр, что вообще пиздец. Вывод: не юзайте Сoinbase wallet

Оптимизация запросов к блокчейну

Тема на самом деле интересная. Почти в каждой сети существует multicall-контракты, которые уже внутри блокчейна делают нужные вам запросы.

Это выглядит примерно следующем образом:
1. Мы передаем в multicall-контракт список контрактов и функции (а так же их аргументы)
2. Внутри блокчейна multicall собирает нужную инфу и возвращает в виде массива

Тем самым одним запросом мы получаем дохуя много данных. Ответ выглядит примерно так:

[
{
"status": true,
"data": {"возвращаемые данные функции"},
},
{
"status": true,
"data": {"возвращаемые данные функции"},
},
]

Почему юзать multicall - тру?
Такие запросы значительно разгрузят ноду, к тому же вы не будете упираться в рейт лимиты, я уже не говорю о скорости обработки таких запросов.

Как это можно использовать?
Тут вынужден разочаровать - такие контракты не изменяют состояние блокчейна, а значит мы можем вызывать только .call (get-запросы). Я думаю каждый сам поймет как это можно адаптировать под собственные задачи, вот парочку: получать балансы токенов для нескольких сотен/тысяч кошельков (либо балансы нескольких тысяч токенов для кошелька), чекать пулы ликвидности сразу в нескольких дексах для тысяч токенов и т.д.

Большинство агрегаторов, DeFi-дашбордов используют multicall-контракты. Примеры как работать с такими контрактам есть в этой статье.

Почему вы до сих пор неправильно используете getAmountOut и slippage?

Мне часто скидывают паблик/приватные скрипт на ресерч и я ни разу не увидел правильного использования getAmountOut. Это особенно актуально сейчас, когда в каждом софте полно мусорных дексов, с нулевыми пулами.

Вот пример транзакции, где произошел скам-свап 0.1 $ETH на 26$ стейбла. Я думаю многие понимают откуда берется amountOutMin (как правило значение получается коллом функции getAmountOut). Основная проблема в том, что кодеры сами придумали что значение должно возращаться только по актуальной стоимости. Хотя это логически невозможно, функция просто возвращает сумму согласно текущей ликвидности.

Если вы захотите обменять 1 $ETH на 2000 $USDT, а ликвидности нет, то при запросе getAmountOut вам не вернется False, вам просто вернется сумма, к примеру 1000 $USDT и все, дальше большинство софтов сделает обмен и потеряет 1к баксов.

Как реализовать функцию правильно?

Одно из решений это сравнивать цену с API (пример: coingecko). Я думаю с реализацией проблем не возникнет. Слипаж тут нужно накидывать на цену с coingecko и сравнивать цены.

Если вы любите стабильность и делаете двойные свапы, то можете сравнивать значения до и после свапов. Вот вам пример. Мы сначала узнаем сколько мы получим токена_2 (пусть будет K) при обмене N количества токена_1, затем узнаем сколько мы получим токена_1(пусть будет X) при обмене K количества токена_2. И вот тут только мы накидываем к X слиппаж и сравниваем X с начальным количеством N токена_1.

Я думаю разберетесь, всем DYOR

Пора поделиться новостями чем я занимался последние 4 месяца

В июле, после отдыха, я начал планировать софт под ZkSync. Хотелось сделать что-то годное, ведь на текущий момент объективно из всех софтов выделяется только софт от Leo и его команды. Мне хотелось именно задать планку, использовать более сложные решения (БД, UI)

В августе, когда я приступил к написанию, я начал понимать что моих знаний в программировании с опытом в полгода вообще не хватает. Я нашел на аутсорсе senior-кодера и мы начали сотрудничать, искать пути для реализации моих идей. Мне хотелось создать очень плотный, универсальный шаблон для софта, максимально отделить web3 часть от шаблона и в итоге под новые блокчейны кодить только web3, параллельно усиливая шаблон. В итоге около 2х недель я рисовал блок-схемы как это должно было работать

В сентябре, мы закончили с основной работой (большую часть писал senior), далее в процессе тестов я уже сам переписал примерно 40% кода, т.к. либо находил лучшее решение, либо там было много ошибок. К этому моменту шаблон состоял из UI и базы данных, а так же часть логики была зашита уже в шаблон.

К октябрю меня уже окончательно заебал ZkSync, софт хотелось переписать, т.к. к этому времени я значительно апнулся в программировании и те идеи что я видел в августе, казалось все можно было улучшить/обновить. Здесь же я решил перенести софт полностью в UI и пилить сразу под Scroll, проект свежий, не так много контрактов и удобно тестить софт.

И вот мы потихоньку приходим к тому, что мне уже нравится и я хотел бы этим поделиться.

soon...

Дизайн за 100$ VS 500$

Написал статью о моем опыте работы с дизайнерами. В статье вы найдете:

✔️ Как я планировал потратить неделю на дизайн, а потратил месяц
✔️ Сравнение опыта работы с разными дизайнерами (+ скриншоты)
✔️ Как я заплатил 50$ за 1 страницу, где по итогу внесли 3 правки

И наконец как dsgn.harmony смог спасти положение и со своей командой отрисовать что-то нереальное.

В общем думаю будет интересно...