settings.ts
Last updated
Last updated
Поле, которое определяет, какой именно роут будет запущен для ваших кошельков. Роут - это набор различных модулей, которые будут выполняться в нужной последовательности. В роуте могут быть выполнены как транзакции, так и запросы, так и чекер. Другими словами, всё, что угодно.
routes: ['flow-3'], // 'base' / 'flow-1' / 'flow-2' / 'flow-3' / 'checkers'Вы можете указывать только название роута, который находится в папке settings/routes.
// Например:
routes: ['one-time'],Данная логика позволяет сохранять прогоны для разного типа кошельков. Один роут может быть для тир1 аккаунтов с большим объемом, а второй может быть чисто для ежемесячного прогрева одной транзакцией. Всю эту логику мы позволяем строить вам. Ограничение только в вашей фантизии и умением пользоваться нашим инструментом.
Описание: Во время выполнения софта мы перемешаем все ваши кошельки/модули между собой в рандомном порядке.
true - рандом,
false - по порядку
shuffle: {
wallets: true,
modules: true,
},Важное примечание! Мы перемешиваем модули только в одной индекс группе.
Пример #1 В данном роуте мы используем 4 модуля: bitget-wait-balance, bitget-withdraw, xy-finance-bridge, wrap-eth.
const modules: UserModuleConfig[] = [
{
moduleName: 'bitget-wait-balance',
indexGroup: 0,
},
{
moduleName: 'bitget-withdraw',
indexGroup: 1,
},
{
moduleName: 'xy-finance-bridge',
indexGroup: 2,
},
{
moduleName: 'wrap-eth',
indexGroup: 3,
}
]shuffle: {
wallets: true, // Кошельки будут выполняться в рандом порядке? true - да, false - нет
modules: true, // Модули будут выполняться в рандом порядке? true - да, false - нет
},Модули при таких настройках будут выполнены следующим образом:
друг за другом в той же последовательности как и указаны в флоу. Потому что все они находятся в разных индекс группах. Несмотря даже на то, что в settings.ts мы указали shuffle.modules = true
Пример #2
В данном роуте мы используем 4 модуля: bitget-wait-balance, bitget-withdraw, xy-finance-bridge, wrap-eth.
const modules: UserModuleConfig[] = [
{
moduleName: 'bitget-wait-balance',
indexGroup: 0,
},
{
moduleName: 'bitget-withdraw',
indexGroup: 2,
},
{
moduleName: 'xy-finance-bridge',
indexGroup: 2,
},
{
moduleName: 'wrap-eth',
indexGroup: 2,
}
]shuffle: {
wallets: true, // Кошельки будут выполняться в рандом порядке? true - да, false - нет
modules: true, // Модули будут выполняться в рандом порядке? true - да, false - нет
},Модули при таких настройках будут выполнены следующим образом: - bitget-wait-balance: всегда первым модулем будет вызван этот модуль - bitget-withdraw, xy-finance-bridge, wrap-eth: для каждого кошелька все модули перемешаются между собой, потому что у них одинаковая индекс группа
Описание: Количество потоков, а если другими словами, то это - сколько кошельков будут одновременно выполнять транзакци.
threads: 30,Обычно, данное поле используется в комбинации с другими настройками.
Например с delay.betweenWallets. То есть, если вы укажите 30 потоков и задержку между кошельками от 5 до 60 секунд - это значит, что в диапазоне 60 секунд мы запустим все эти 30 кошельков и они одновременно будут выполнять модули.
Описание: Количество попыток, после которых кошелёк перестанет выполнять модуль и перейдёт к следующему кошельку
txAttempts: 3,Раздел, где можете указать любые задержки, которые вы можете регулировать во время выполнения софта
delay: {
beforeTxReceipt: [0, 0], // Задержка перед получением статуса транзакции
betweenTransactions: [5, 10], // Задержка между транзакциями
betweenWallets: [5, 20], // Задержка между кошельками
betweenModules: [0, 3], // Задержка между модулями
betweenCheckGas: [60, 120], // Задержка между ожиданием газа
betweenRetries: 30, // Задержка между неудачными транзакциями
betweenRestarts: 0, // Задержка (в часах) между повторным запуском скрипта (укажите 0, чтоб не запускать повторно)
},betweenTransactions - Данную задержку можно перебить задержкой, которую можете указать внутри модуля. В данном случае, мы не будем учитывать betweenTransactions в settings.ts, а будем брать delay, который вы указали внутри модуля.
// Например:
const modules: UserModuleConfig[] = [
{
moduleName: 'taiko-rubyscore-vote',
indexGroup: 0,
count: [5, 10],
delay: [30, 60] // Задержка между транзакциями внутри одного модуля ОТ и ДО
}
]
beforeTxReceipt - как только мы отправляем транзакцию к RPC, то вы можете регуляровать время, через которое мы проверим, дошла ли транзакция в блокчейн и прошла ли она статус pending.
betweenTransactions - задержку между одними и теми же транзакциями внутри одного модуля. Когда например вы вызываете wrap/unwrap, указываете count: [10, 10] и в данном случае у вас будет регулироваться задержка между этими 10 транзакциями.
Например:
Кошелёк #1, модуль #1 wrap, транзакция #1 -> 6 sec ->
Кошелёк #1, модуль #1 wrap, транзакция #2 -> 9 sec ->
Кошелёк #1, модуль #1 wrap, транзакция #3 -> 5 sec
betweenWallets - задержка между кошельками, после того, как кошелёк выполнил все модули.
Например:
Кошелёк #1, модуль #1, транзакция #1 -> 10 sec ->
Кошелёк #2, модуль #1, транзакция #1 -> 12 sec ->
Кошелёк #3, модуль #1, транзакция #1 -> 18 sec
betweenModules - задержку между модулями внутри одного кошелька.
Например:
Кошелёк #1, модуль #1 wrap, транзакция #1 -> 0 sec ->
Кошелёк #1, модуль #2 wrap, транзакция #1 -> 3 sec ->
Кошелёк #1, модуль #2 wrap, транзакция #1 -> 2 sec ->
betweenCheckGas - задержка между попытками проверки нужного газа, чтобы продолжить выполнять модули. Перед каждой транзакцией, мы проверяем, чтобы газ был ниже значения, которое вы указали в maxGas.
Например:
Кошелёк #1, модуль #1 wrap -> check gas -> normal gas -> транзакция #1 ->
Кошелёк #1, модуль #1 wrap -> check gas -> expensive gas -> 80 sec -> normal gas -> транзакция #2
betweenRetries - задержку между повторное попыткой выполнения транзакции, которая зафейлилась.
Кошелёк #1, модуль #1 wrap -> транзакция #1 -> success ->
Кошелёк #1, модуль #1 wrap -> транзакция #2 -> fail -> 30 sec ->
Кошелёк #1, модуль #1 wrap -> транзакция #2 -> again fail -> 30 sec ->
Кошелёк #1, модуль #1 wrap -> транзакция #2 -> success
betweenRestarts - задержка (в часах) между повторным запуском скрипта. Укажите 0, чтоб не запускать повторно. Повторный запуск - это когда софт заканчивает выполнение всех кошельков, а вам нужно заново запустить сразу же повторный прогон этих же кошельков с таким же флоу, которое у вас было до этого.
Возможность отфильтровать ваши кошельки перед стартом скрипта по ID. Чтобы не удалять или сортировать ваши кошельки в wallets.csv. Достаточно отрегулировать их этой настройков.
// Данное поле будет фильтровать кошельки по указанным ID
// Возможные форматы фильтра:
// ['5'] - на выходе будет только кошелек с ID 0005
// ['>5'] - на выходе будут кошельки с ID 0005 и больше
// ['<5'] - на выходе будут кошельки с ID 0005 и меньше
// [['1', '100']] - на выходе будут кошельки с ID от 0001 до 0100
// Данные форматы можно комбинировать
// Например: ['3', ['10', '13'], '20', '>100']
// возьмет кошельки с ID 0003, 0020, от 0010 до 0013 и все начиная с 0100 и больше
// Оставьте [], чтоб не применять фильтрацию
idFilter: [],Если вы хотите обрезать сумму, которая будет отображаться в логах, тогда можете указать нужное количество символов после запятой. То есть если вы укажите для токена BNB цифру 8, тогда в логах вы увидете следующую картину: Swap 0.02521259 BNB to 1.01 USDC
// До какого числа после запятой обрезать значения в логах
logsTrimNumber: {
BNB: 4,
ETH: 8,
WETH: 8,
USDT: 2,
USDC: 2,
AVAX: 3,
MATIC: 2,
// Дефолтное значение для значений, не указанных выше
default: 5,
},Минимальный баланс, который необходим для выполнения свапов. Если на балансе будет меньше, чем вы указали, тогда мы не будем использовать этот токен в работе.
minTokenBalance: {
ETH: 0,
USDT: 0,
USDC: 0,
DAI: 0,
wstETH: 0,
WBTC: 0,
UNI: 0,
CAKE: 0,
LUSD: 0,
rETH: 0,
iZi: 0,
},Это тоже самое, что и gasMultiplier. Только вместо того, чтобы брать актуальный газ с RPC, вы можете сами ставить диапазон, который будет использоваться для всех транзакций в этой сети. Так же можете указать подобное поле в настройках модуля и тогда модуль будет использовать уже локальную настройку.
// Диапазон вашего кастомного gwei, который будет применяться для транзакций
gweiRange: {
// taiko: [0.0501, 0.053],
taiko: [0.06, 0.07],
},Мы возьмём текущий gas сети, который отдаст нам RPC и добавим в процентах ваше значение. Например актуальный газ в Scroll 0.1, но вы знаете, что с таким газом транзакции долго проходят. Тогда вы указываете здесь scroll: 10 и тогда мы ускорим вашим транзакцию. А есть например сеть Base в которой можно наоборот уменьшить газ, чтобы транзакции стали дешевле. Тогда вы указываете base: -30 и тогда мы сделаем вашу транзакцию дешевле.
// Данный параметр - это процент, который будет добавлен/убавлен текущему газу в транзакциях
// Чтобы добавить 5%, укажите 5
// Чтобы убавить 5%, укажите -5
// Для отключения передайте 0
// Не работает для модулей, которым передан параметр gweiRange в настройках модуля
gasMultiplier: {
taiko: 0,
},Перед выполнением каждой из транзакции, мы проверяем включён ли у вас autoGas для сети в которой выполняется транзакция. Если же настройка включена, тогда мы проверяем по minBalance, чтобы баланс в этой сети был выше.
Например:
Кошелёк #1 имеет баланс 0.3 MATIC в Polygon
Кошелёк #1, модуль #1, транзакция #1 -> сеть polygon -> check balance ->
-> good balance -> отправляем транзакцию в блокчейн
Кошелёк #2 имеет баланс в 0.1 MATIC в Polygon
Кошелёк #1, модуль #1, транзакция #1 -> сеть polygon -> check balance ->
-> баланс ниже minBalance -> пополняем с OKX на ожидаемый баланс в 2-3 MATIC ->
-> текущий баланс 0.1 MATIC - 2 MATIC = 1.9 MATIC выводим с ОКХ -> ожидаем ->
-> баланс успешно пополнен до 2 MATIC -> отправляем транзакцию в блокчейн
Думаю уже заметили, что у нас есть 2 возможности пополнить кошелёк. Самый обычный способ - это статический вывод конкретной суммы, который не учитывает текущий баланс кошелька. В данном случае вам нужно указать:
withdrawToAmount: [2, 3],
// и указать нули в этом поле
expectedBalance: [0, 0],Вторая опция - это возможность пополнить кошелёк учитывая уже ваш текущий баланс. В данном случае, если у вас на кошельке уже есть 1.5 MATIC, а вы ожидаете увидеть на кошельке баланс от 2 до 3 MATIC, тогда мы возьмём рандомную цифру в указанном диапазоне, например 2.6 MATIC и отнимем от текущего баланса это значение. То есть: 1.5 MATIC - 2.6 MATIC = -1.1 MATIC. Вычислили, что вам нехватает 1.1 MATIC для нужного баланс и выводим его с биржи.
withdrawToAmount: [0, 0],
expectedBalance: [2, 3],Пример для всех сетей:
autoGas: {
Polygon: {
useAutoGas: false,
cex: 'okx', // binance | okx
// Минимальный баланс, ниже которого будет вызван модуль пополнения
minBalance: 0.2,
// Сумма ОТ и ДО для пополнения кошелька с бирж
// Если это OKX, то перед этим нужно добавить все свои кошельки в WhiteList на ОКХ - https://thorlab.io/
// Если Binance, то просто добавьте свой IP в настройках API
withdrawToAmount: [0, 0],
// Ожидаемый баланс на кошельке, который должен быть после выполнения автогаза.
// При указании данного параметра, withdrawToAmount не учитываются
expectedBalance: [2, 3],
// Время, через которое скрипт сделает проверку баланса MM кошелька, чтобы проверить актуальный баланс
// Пока кошелёк не будет пополнен с CEX дальнейшие действия будут заблокированы
// Если пополнение произошло неудачно, то кошелёк моментально заканчивает своё выполнение
withdrawSleep: [60, 70],
},
BSC: {
useAutoGas: false,
cex: 'binance', // binance | okx
minBalance: 0.002,
withdrawToAmount: [0.003, 0.0045],
expectedBalance: [0, 0],
withdrawSleep: [30, 40],
},
Avalanche: {
useAutoGas: false,
cex: 'binance', // binance | okx
minBalance: 0.004,
withdrawToAmount: [0.0085, 0.0099],
expectedBalance: [0, 0],
withdrawSleep: [50, 70],
},
Optimism: {
useAutoGas: false,
cex: 'okx', // binance | okx
minBalance: 0.0004,
withdrawToAmount: [0.0004, 0.0006],
expectedBalance: [0, 0],
withdrawSleep: [170, 190],
},
Arbitrum: {
useAutoGas: false,
cex: 'okx', // binance | okx
minBalance: 0.0004,
withdrawToAmount: [0.0004, 0.0006],
expectedBalance: [0, 0],
withdrawSleep: [170, 190],
},
// not used
ERC20: {
useAutoGas: false,
cex: 'okx', // binance | okx
minBalance: 0.004,
withdrawToAmount: [0.01, 0.011],
expectedBalance: [0, 0],
withdrawSleep: [170, 190],
},
opBNB: {
useAutoGas: false,
cex: 'binance', // binance | okx
minBalance: 0.0003,
withdrawToAmount: [0.01, 0.013],
expectedBalance: [0, 0],
withdrawSleep: [30, 40],
},
zkSync: {
useAutoGas: false,
cex: 'okx', // binance | okx
minBalance: 0.0003,
withdrawToAmount: [0.01, 0.012],
expectedBalance: [0, 0],
withdrawSleep: [170, 190],
},
Base: {
useAutoGas: false,
cex: 'okx', // binance | okx
minBalance: 0.0006,
withdrawToAmount: [0.005, 0.007],
expectedBalance: [0, 0],
withdrawSleep: [170, 190],
},
Linea: {
useAutoGas: false,
cex: 'okx', // binance | okx
minBalance: 0.0003,
withdrawToAmount: [0.01, 0.012],
expectedBalance: [0, 0],
withdrawSleep: [170, 190],
},
Fantom: {
useAutoGas: false,
cex: 'okx', // binance | okx
minBalance: 0.0003,
withdrawToAmount: [0.01, 0.012],
expectedBalance: [0, 0],
withdrawSleep: [170, 190],
},
Core: {
useAutoGas: false,
cex: 'okx', // binance | okx
minBalance: 0.0003,
withdrawToAmount: [0.01, 0.012],
expectedBalance: [0, 0],
withdrawSleep: [170, 190],
},
Celo: {
useAutoGas: false,
cex: 'okx', // binance | okx
minBalance: 0.0003,
withdrawToAmount: [0.01, 0.012],
expectedBalance: [0, 0],
withdrawSleep: [170, 190],
},
Klayn: {
useAutoGas: false,
cex: 'okx', // binance | okx
minBalance: 0.0003,
withdrawToAmount: [0.01, 0.012],
expectedBalance: [0, 0],
withdrawSleep: [170, 190],
},
},Модули, будут дожидаться исполнения, пока газ в используемой сети не станет ниже переданного значения. Для отключения передайте 0. Не работает для модулей, которым передан параметр maxGas в настройках модуля. В этом случае maxGas внутри модуля будет стоять в приоритете и мы будем использовать его.
maxGas: {
eth: 0,
scroll: 0,
arbitrum: 0,
optimism: 0,
polygon: 0,
zkSync: 0,
},Если значение true, первым делом при восстановлении будет выполняться кошельки на которых есть модули, которые еще не выполнялись. После чего выполняться те кошельки, где все невыполненные модули являются зафейленными.
Например:
У вас было 100 кошельков. Когда 76 кошельков прогнались софт по какой-то причине остановился. Из этих 76 кошельков только 66 выполнились успешно, а 10 остальных зафейлились по какой-то причине. Вот в итоге у вас осталось 10 кошельков, который зафейлились и еще 24 кошелька, который даже не начинали своё выполнение. Вот это поле как раз и регулирует от куда вы начнёте своё восстановление. То есть например, если у вас комп потух и софт стопнулся, а вы хотите продолжить с кошельков, которые еще не выполнялись, то вам нужно указать useRestartFromNotFinished: false и вызвать восстановление.
useRestartFromNotFinished: false,Определяет, будет ли софт сохранять модули в локальную базу данных или нет
// Сохранять ли зафейленные модули в saved-modules для рестарта
useSavedModules: true,
Определяет, запускать ли рестарт автоматически в конце основного скрипта, если остались зафейленые модули.
Например у вас было 100 кошельков. Из этих 100 кошельков успешно выполнились только 82 кошелька, а остальные 18 упали по какой-то из причин. Если же вы укажите в useRestartInMain: true, тогда по окончанию выполнения всех кошельков он повторно будет запускать все кошельки, которые зафейлились, то есть вот эти 18 кошельков.
useRestartInMain: false,Очень удобная функция, которая позволяет размазать все ваши кошельки до определённой даты, либо вызывать повторный запуск скрипта в конкретное время каждый день. Сейчас рассмотрим оба варианта по отдельности. Указывать оба поля одновременно нельзя!
calculateStart: {
// Время в которое скрипт будет автоматически запущен снова на следующий день
// Пример: '21:35'
// Формат: 'часы:минуты'
// Используется локальное время
startAgainTime: '',
// или
// Время до которого будут растянуты задержки между кошельками (betweenWallets)
// Пример: '11-05-2024 15:35' - задержка будет [0, рассчитанное время от момента запуска скрипта до указанной даты и времени]
// Формат: 'день-месяц-год часы:минуты'
// При использовании betweenWallets не работает
// Используется локальное время
finishTime: '',
},
startAgainTime - использую в том случае, если мне нужно прогонять все кошельки каждый день на протяжении недели или месяца. Важно знать, вам нужно понять какое количество потоков поставить в threads . Чтобы все кошельки успевали в течении дня проходить хотя бы за 15-20 часов. Если же вы запустили софт в 10:00 утра, а все кошельки закончили выполнение только в 5 утра, а рестарт стоит в 1 час ночи, тогда вы пропустите 2й день и оно будет ждать 3й день и стартанет в 1 час ночи. По этому нужно чтобы все кошельки закончили своё выполнение до 1 часа ночи или до того времени, которое у вас указано в startAgainTime.
finishTime - использую в том случае, если мне нужно прогнать все кошельки до конкретной даты. Например у меня есть 100 кошельков, а дедлайн у проекта через неделю. Если сегодня 20 августа, а дедлайн до 27 августа, тогда в finishTime я укажу 25-08-2024 12:00. В этом случае в среднем будет выполняться по 20 кошельков в день и в течении 5 дней оно закончит выполнять все кошельки.
Очень важно! Вместе с finishTime нужно указывать обязательно threads: 'all'
Будет ли софт использовать прокси во время запросов
// Использовать ли прокси при выполнении скрипта
useProxy: true,Количество неудачных попыток выполнения запросов перед тем как будет взято новое рандомное proxy из proxies.csv. Установите 0, если не хотите чтоб бралось новое proxy
txAttemptsToChangeProxy: 3,Вы можете редактировать settings.ts даже, если уже запустили софт, а после вызвали восстановление. То есть вы можете запустить скрипт, прогнать условно 20 кошельков, а после остановить. Изменить например количество потоков (или что-то другое) и запустить скрипт снова через восстановление. В итоге софт учтёт ваши изменения и продолжит с того места на котором он остановился в прошлый раз.
Если вы измените настройки внутри роута/модуля, то ваши настройки применятся только после перезапуска с нуля! То есть восстановление не подтянет ваши обновленные настройки в модулях.
