Труха⚡️Україна

Николаевский Ванёк

View

Реальна Війна | Україна | Новини

View

Труха⚡️Україна

View

Николаевский Ванёк

View

Реальна Війна | Україна | Новини

View

The Open Dev Blog

Тон макаки.
Исследуем проекты на тоне так глубоко, как только можно.
Просим указывать нас как первоисточник.
Contact: @rends_east, @therealmaloleg or @bazrov

TGlist rating

TypePublic

Verification

Not verified

Trust

Not trusted

Location

LanguageOther

Channel creation dateAug 11, 2024

Added to TGlist

Sep 22, 2024

I own this channel

History of changes

Linked chat

The Open Dev Chat

Statistic of Telegram Channel The Open Dev Blog

More details

Subscribers

687

24 hours

10.1%Week

30.4%Month

253.8%

Citation index

0

Mentions1Shares on channels0Mentions on channels1

Average views per post

0

12 hours1 2000%24 hours00%48 hours2120%

Engagement rate (ER)

0%

Reposts0Comments0Reactions0

Engagement rate by reach (ERR)

0%

24 hours0%Week0%Month0%

Average views per ad post

0

1 hour2470%1 – 4 hours5500%4 - 24 hours00%

More details

Connect our bot to the channel to find out the gender distribution of this channel's audience.

Total posts in 24 hours

1

Dynamic

Latest posts in group "The Open Dev Blog"

All posts

15.05.202510:29

🔥 Мы ищем контакты с трейдинг командами.

@bidask есть что предложить: мы быстрее, мы эффективнее, мы дешевле.
Мы готовы помочь с интеграцией, стратегиями, с чем угодно, что у вас вызывает трудности при интеграции нового DEX.

Считайте этот пост публичной рефералкой, мы будем крайне благодарны, если по вашей рекомендации или репосту к нам придет будущий партнер.

12.05.202509:32

🔥 GM
Подкиньте — какой у кого есть тулинг под FunC?
Пойдет что угодно. Го обмениваться опытом

09.05.202516:58

🔥 Мы пообщались с @kyouma из Ton Tech, чтобы выяснить подробности грядущего обновления TON, связанного с новой системой распределения контрактов по шардам.

Главной проблемой, которую и решали мы в @bidask, было то, что система распределения контрактов по шардам была строго детерминированной — брался хэш от state init, получался адрес контракта, и после этого по первым битам адреса определялось, в каком шарде будет контракт. Из-за этого все операции в TON были заметно дольше — ведь транзакция пользователя постоянно "прыгала" по шардам даже там, где это совершенно не нужно.

Решением для этого должны были стать anycast адреса. Не удивляйтесь, если ничего о них не слышали — они больше не поддерживаются. Это механизм, благодаря которому контракты могли делиться и соединяться вместе с шардами для распределения нагрузки на сеть.

На их основе даже был сделан DEX, позволяющий проводить обмены в рамках одного блока. Там не было использовано фишки со сплитом контрактов, просто были точки входа в DEX во всех шардах. Минусом такого подхода было деление ликвидности пар на все шарды и закономерное увеличение слипаджа. Немногие знают, но mainnet версия bidask, хоть и начала писаться до появления LUXNOX, во многом была вдохновлена именно этим решением. Мы следим за экосистемой 🤟

Как эту проблему решили?
Теперь в state init появился новый параметр — fixed_prefix_length. Он дает понять, какое количество бит в начале адреса при деплое можно перезаписать, чтобы контролировать, в какой шард пойдет контракт.

На счет обратной совместимости можно не переживать — на месте fixed_prefix_length раньше был другой, по сути бесполезный параметр, связанный с anycast, поэтому с точки зрения построения state init ничего глобально не изменилось.

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

Это сильно улучшит опыт взаимодействия с DeFi, ведь теперь протоколы могут контролировать ончейн, без брутфорса, что будут в 1 шарде. Не сразу, но это принесёт значимые плоды.

@TheOpenDevBlog

05.05.202512:05

🔥 Пока в TON, как обычно, происходит балаган, устроим себе пикник во время пира — расскажем про интересный, но уходящий от нас нюанс в разработке смарт контрактов на нашем любимом устаревшем отставшем от жизни и времени и всех конкурентов недоязыке программирования FunC.

В некоторых проектах может потребоваться проверить, что один адрес НЕ равен другому. Многие эту проблему решают очень просто:
ifnot (equal_slices(address1, address2))

Фатальная ошибка.

Нюанс кроется буквально в названии функции — equal_slices не проверяет равенство адресов, она проверяет равенство слайсов.
Дело в том, что в TON существует больше одного способа записать адрес в slice, чтобы он корректно считался ~load_msg_addr — addr_std и addr_var. Если записать адрес двумя разными способами, а потом считать, то получится два разных, не равных друг другу слайса, хотя адрес один.

Что же делать? На самом деле, решение простое — кроме equal_slices также проверять, что длина адресов — 267 бит, ведь это длина addr_std.

Нюанс кажется местячковым, но олды знают и помнят, что именно благодаря нему в TON уже происходили взломы.

К сожалению или к счастью, addr_var очень скоро нас покинет. Наши репортеры и очевидцы из тестнета утверждают, что там он уже "пропал" 🫡🫡🫡

Крутая ироничная фраза.
@TheOpenDevBlog

29.04.202513:27

🔥 Нас можно будет найти на Token 2049.

Наши контакты в био канала.
До встречи! 🌞

26.04.202516:44

🔥 Главная идея DEX с концентрированной ликвидностью — это эффективность использования капитала. Но что такое вообще эффективность капитала?

Проще всего её представить в контексте обычной модели Uniswap. Предположим, пользователь открывает позицию на $10к на пару ETH\USDT в пуле с LP fee 0.3% на средний диапазон (1500-2000). Спустя месяц количество заработанных комиссий у него составляет приблизительно $600 (реальные числа с revert.finance). Таким образом его капитал за месяц был использован для свапов на общую сумму равную 600/0.003 = $200к, то есть полностью 20 раз!
Если же зайти на любой CPMM DEX, то там капитал на любой аналогичной высоколиквидной паре за месяц будет использован точно в разы меньше.

Остаётся вопрос: как ещё можно увеличивать показатель эффективности капитала?

Первый вариант — это манипулирование уровнями комиссий в пуле. Например очевидно, что если комиссий вообще не будет (ни комиссий протокола, ни комиссий для провайдеров ликвидности) — то почти наверняка вырастут объёмы торгов и эффективность капитала как следствие (если забыть, что комиссий мы не получим 😀). Комиссии lp провайдеров убирать бессмысленно, а вот с комиссиями протокола разъяснять долго — есть очень подробный ресёрч при содействии Uniswap Foundation на эту тему. Существует также опция использования динамических комиссий, больше всего в этом преуспела Meteora на солане — и её успешный опыт мы активно перенимаем в @bidask.

Очень важной опцией является использование автоматического реинвестирования заработанных комиссий обратно в позицию ликвидности. Да, это работает само собой в любом CPMM DEX, однако для CLMM это редкость, хотя это дает ощутимый прирост к доходности.

Предположим, вы просто положили деньги в банк под 12% годовых. Если вы получаете их ровно раз в год, то ваша доходность за год будет составлять как раз 12%. Если же будете получать их каждый месяц и реинвестировать - доходность будет уже ~12.68%, если же реинвестирование будет происходить непрерывно то это уже ~12.74%. Формула для подсчета APY при непрерывном реинвестировании: e^APR - 1.

Казалось бы, разница не такая большая для 12% годовых, чтобы о ней думать. Однако если представить ситуацию, которая вполне возможна при поставке концентрированной ликвидности на достаточно широкий диапазон, что актуальная цена не вышла из него в течении года — это будут вполне реалистичные 20-30% годовых.
Для 30% годовых непрерывное реинвестирование комиссий приведёт уже к 35% годовым вместо 30%, к 64% вместо 50% без реинвестирования, и так далее.

Учитывая, что существуют киты, которые не так следят за IL, а лишь ждут, пока комиссии полностью не окупят вкладываемую ими ликвидность — подобный буст процентов доходности вполне может сократить годик-другой до цели в 100% ROI.

Над всем этим мы думали на старте разработки @bidask — и реализовали автоматическое реинвестирование комиссий. И даже у невероятно крутой Meteora, с которой нас принято сравнивать, такой киллер фичи нет — в этом мы круче.

01.04.202516:28

1 апреля нет большей шутки, чем выложить пост.

@bidask успешно проходит аудит, а мы тем временем решили накодить приколюху для нашего любимого TON-а.

Все мы знаем, что валидаторы плохо кушают, поэтому давайте их поздравим с праздником — днём математика!
Для этого команда @TheOpenDevBlog подготовила адрес, куда можно донатить валидаторам. Смарт-контракт сжигает на газ весь TON, что ему пришлют. Мы поздравили первыми!

Кроме того, отправка туда ваших TON повысит TPS сети, а это не менее важно.

Будьте внимательны — никто не сможет вернуть вам TON, если вы отправите его на этот адрес.

В комментах предлагаем обсудить все способы обмануть контракт. Закрывайте спойлерами ответы)

UPD: в комментах напомнили, что половина комиссий сжигается, поэтому таким образом мы еще и уменьшаем эмиссию TON!

In community we trust.
@TheOpenDevBlog

13.11.202414:45

Отвечаем на популярные вопросы о сэндвич ботах:

Почему это не MEV-боты?

🔥: MEV - это механизм, с помощью которого валидатор (майнер) может извлекать прибыль, манипулируя порядком транзакций в блоке. MEV-а в нашем блокчейне пока нет, но он обязательно появится, когда придут большие объемы. Чтобы оценить масштабы реального MEV-а, предлагаем вам прочитать статью, как сэндвич бот заплатил 46 ETH (>100к$) за одну транзакцию в виде комиссии. Конечно, существует вероятность, что валидаторы сговорились и бреют всех нас на 3-5 TON на обмене низколиквидных токенов, но она ничтожно мала.
_____________

Как узнать, что адреса находятся в одном шарде?

🔥: по первым битам адреса. Например: мы хотим проверить, находятся ли адреса EQDa4VOnTYlLvDJ0gZjNYm5PXfSmmtL6Vs6A_CZEtXCNICq_ и EQDSEqIDjlGdDvoqHJ_wTk6wRvgXwvE05QbCydqOEOpjpbhU в одном шарде. Мы переходим на нашу страничку, вставляем поочередно эти два адреса и видим, что у обоих шард - 1101. Значит — они находятся в одном шарде.
Важно: блокчейн может быть не нагружен, и в такие моменты количество шардов сокращается, и количество бит, нужных для проверки шарда, тоже сокращается, но всё равно советуем вам всегда смотреть на 4 бита и не париться. В данный момент максимальное количество шардов - 16 (4 бита), и если в будущем это число увеличится, то мы отредактируем наш сайт под новые требования.
_____________

Если я хочу обменивать жеттоны быстрее всех, какой кошелек мне нужно иметь?

🔥: Нужно иметь такой wallet, чтобы и он, и ваш jetton-wallet были в одном шарде с jetton-wallet, принадлежащем DEX. Важно: в одном шарде не с vault дедаста или router ston fi, а именно с их jetton-wallet-ами. Сделать это можно, генерируя себе wallet через наш сайт до тех пор, пока ваш jetton-wallet нужного вам жеттона не совпадёт шардом с jetton-wallet биржи. В случае с TON всё просто - для dedust ищите адрес в шарде с vault, в случае со ston fi - в шарде с pTON (для v1, про v2 расскажут в комментах)

@bidask x @TheOpenDevBlog

30.10.202416:55

Мы давно ничего не писали в канал, т.к все темы для постов, записанные в заметки, требуют большого погружения и ресерча. Если вы хотите ускорить появление постов — закиньте нам звезд, но это не инвестиционная рекомендация.

НО! Нас можно будет найти на TON Gateway. Обсудить с нами желательно всё, но для удобства мы составили список активностей, в которых мы принимаем участие:

⚫️ Мы очень активно заняты разработкой @bidask. Это наш основной проект, мы бросили на него все силы. Это очень серьёзный финансовый инструмент, который откроет пользователям на TON глаза на то, как реально должен использоваться DeFi. Мы открыты к сотрудничеству.

⚫️Часть нашей команды участвует в разработке @circus_game. Это не наш проект, но мы в большой степени отвечаем за его техническую часть. Мы можем связать с владельцами для сотрудничества.

⚫️ Мы готовы проводить аудиты и консультации. У нас крайне мощный бэкграунд в безопасности как web2, так и web3, а также возможность привлечь к проекту дополнительные силы в случае, если компетенций основной команды не хватает (крайне редко). Мы уже консультировали ряд крупных и очень крупных проектов в разных блокчейнах.

Наши контакты в био канала.
До встречи! 🌞

20.09.202412:23

Про аудит: у них на лендинге можно найти проведённый в мае этого года аудит от tonbit.

И вроде бы всё прекрасно - проаудировали какие-то контракты, нашли какие-то уязвимости, команда их всех успешно исправила. Однако заметьте, насколько бы подробно вы не пытались прочитать и вникнуть в этот отчёт, у вас не получится этого сделать:
⚫️ На исходный год на гитхабе доступа нет.
⚫️ Из описания найденных уязвимостей имеются только краткие названия, которые мало о чём говорят.
⚫️По названиям файлов, которые были предоставлены для аудита даже не поймёшь, какой именно функционал проверялся.
⚫️ Проверялся ли сам бэкенд\индексер? Видимо нет.

Это не к тому, что tonbit плохо проводит аудиты, или tradoor специально кого-то обманывает. Очевидно, что за прошедшие 4 месяца они успели дописать много функционала, в том числе, возможно, и опционы, которые они вряд ли успели должным образом проверить.
Однако на первый взгляд кажется, что раз аудит есть, то всё должно быть супер. Всегда проводите dyor всего сами, в том числе и проверяйте публично доступные аудиты!

А если вам нужна консультация по вашим проектам в тоне, то можете писать нам 🙂

@theOpenDevBlog

20.09.202412:20

Критическая уязвимость в Tradoor.io

Не все знают, но в TON-е существует прямой конкурент Storm trade, на котором можно также торговать perpetuals на различные криптовалюты.
И интересной отличительной чертой является возможность торговать опционами, причём очень короткими, начиная с 5-минутных.

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

Не буду вдаваться в подробности, как именно должна рассчитываться справедливая стоимость опционов различной длительности (вкратце, чем выше волатильность, тем дороже в моменте должен быть опцион), так в чём же заключается уязвимость?

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

Пример - на скриншоте я купил PUT опцион на 5 минут с плечом ~43,000х. Но открыть опцион, очевидно, можно было на любой срок и абсолютно любым плечом. Суть в том, что открыв CALL и PUT опцион с огромным плечом одновременно, пользователь мог получить буквально бесплатные деньги, поскольку для выхода позиции в огроменный плюс было достаточно абсолютно любого минимального изменения цены в любую сторону.

Это означает возможность вывода ВСЕЙ ликвидности из волта опционов, совершив всего две сделки за 20$!

Я сразу попробовал связаться с командой через их бота поддержки, написал им про существующую уязвимость, и хоть ответа я так и не получил - буквально спустя пару часов они отключили индексер, а на следующее утро уязвимость уже была исправлена, теперь при попытке покупки опциона по произвольной цене вам просто вернутся ваши USDT. Конечно жаль, что команда не захотела отвечать на мой репорт, но исправили очень оперативно, за что ребятам респект. Если у кого-то есть контакты фаундеров, скиньте в лс, а то сам я не нашёл ничего кроме их чата, где не хочется наводить fud.

А эти заработанные 90$ в сделке при помощи бага я уже слил обратно, тестируя их протокол дальше ☹️

@theOpenDevBlog

Could not access
the media content

18.09.202413:14

Скоро будет пост о крутой найденной уязвимости в одном из протоколов на Тоне, а также о том, что не всегда стоит воспринимать факт проведённого аудита слишком серьёзно😐

18.09.202412:48

С постом про стандарт я немного запоздал, т.к хотелось максимально подробно всё рассказать. Но чем больше углублялся, тем больше понимал, что адекватно это в пост не впихнёшь, поэтому напишем обзорную часть.

Недавний релиз мемкоина $DOGS снова подсветил проблему с архитектурой централизованного минта жетонов при аирдропах. Если число юзеров достаточно большое, то объективно никаких мощностей любого блокчейна просто физически не может хватить, если при минте жеттонов участвует один адрес - jetton-master.

Для решения такой проблемы недавно появился новый стандарт жетона на TON - mintless jetton (вот код). Как он работает: минт токенов больше не происходит через jetton-master, а он получается каждым участником аирдропа через его собственный jetton-wallet.

Реализовано это через механизм дерева Меркла (я советую прочитать это, если вы не знаете, что это такое). Механика работы следующая - каждый jetton-wallet хранит у себя переменную mercle_root, то есть хэш, находящийся на верхушке дерева. При получении аирдропа пользователь должен предъявить свой mercle_proof, то есть некоторое криптографическое доказательство, что пользователь в аирдропе участвует. При этом никакой централизованной системы не участвует, каждый jetton-wallet обладает всей полнотой информации, чтобы подтвердить право пользователя на аирдроп. Важно понимать - разумеется, вы ничего подобного при обычном получении аирдропа не увидите, поскольку логика работы, конечно же, будет и должна находиться под капотом приложения, которое отвечает за аирдроп.

Таким образом, при получении своих токенов с точки зрения блокчейна вы будете обращаться не к jetton-master-у, как обычно, а к своему jetton-wallet-у. Его код никак не подменить, несмотря на то, что он "типа ваш". Разумеется, обычный минт тоже присутствует, и ничего не ограничивает владельца токена в обход аирдропа сминтить себе дополнительные токены.

Надо признать, что этот стандарт является по настоящему новым словом в децентрализации. Несмотря на весь fud в сторону TON, в действительности такой пользовательской базы, какая есть у тех же $DOGS, нет больше нигде. И в условном эфире при похожей нагрузке на блокчейн комиссии за обычные транзакции бы подскочили до сотен долларов, как это было, например, во время халвинга биткоина.

15.09.202411:30

Сколько Aqua Protocol заработал с минта Nomis Score NFT?

В июле этого года к окончанию фарминга в боте Aqua Protocol был приурочен минт Nomis Score - NFT, показывающий "рейтинг" вашего кошелька. Разумеется, это была рефералка - минт одной NFT стоил 1.1 TON, часть средств уходило создателям проекта, а часть - человеку, который привёл аудиторию, то есть на кошелёк julia-innovator.ton.

Экономика такая: для обычного юзера награда за реферала 0.1 TON, но для julia-innovator.ton наградой было 50% от общей прибыли протокола (примерно 0.5 TON).

Реализовано все это в духе нашего поста про подписи. Пользователь получает параметр signature, который передается в транзакции от его кошелька, и который не позволяет подделать данные в сообщении.

На удивление, Aqua заработал с этой активности всего 774 тона, приведя при этом 1586 пользователей. Эти данные только из смарт-контрактов Nomis, платили ли они дополнительно - неизвестно.
Сами же основатели Nomis заработали 21488 TON, судя по данным блокчейна. По нынешнему курсу это порядка 122к$.
Данные взяты из re::doubt.

Friendly remainder - ничего, разумеется, криминального в рефералке нет, но это нигде не афишировалось, и я очень удивился, когда это увидел.

13.09.202412:54

Как узнать, что смарт-контракт внёс какие-то изменения в блокчейн, даже если он упал при исполнении?

Всё просто - в tonviewer можно посмотреть так называемую action фазу. Если ее нет, или она "skipped", то контракт никаких изменений не вносил.
Например, как тут. (нужно нажать на кружочек с восклицательным знаком и посмотреть на информацию внизу 😬) Как видите, compute фаза есть, а справа от нее пусто.

А вот в случае с моим контрактом, несмотря на ошибки при исполнении кода, action фаза отображается. При этом можно заметить, что "total actions" указано как 3, то есть за каждое исходящее сообщение было совершено одно действие (action). Таким образом, смарт-контракт в свои данные никаких изменений не вносил, только отправил 3 сообщения.
Если "total actions" больше, чем число исходящих сообщений, то смарт-контракт внёс изменения в свои ончейн данные.

@theOpenDevBlog

All posts