🔥 Перед очень большими новостями небольшой лайфхак вам на затравку.

Как бесплатно достать ключ для tonapi? Взять его в tonkeeper!

Заходим сюда (ссылка была получена через вкладку network в инспекторе - при каждом обновлении интерфейса приложение делает туда запрос) и берем ключ из параметра tonApiV2Key. Там же можно найти и эндпоинт для tonapi — keeper.tonapi.io. Может, у него аптайм выше стандартного)

Ключ лимитирован 100 запросами в секунду, но только для одного ip (подсчитано вручную, не точно). Для сравнения — бесплатный tonapi (без ключа) можно использовать только 1 раз в секунду.

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

Также стоит помнить, что ключи tonapi могут быть ограничены по Origin (домен сайта с которого должны отправляться запросы). В случае с tonkeeper это не так, а если найденный ключ всё же ограничен по домену — для использования его вне браузеров всегда можно добавить требуемый домен в header Origin.

The Open Network.
@TheOpenDevBlog

👍 DWF Labs х Bidask

😱😱😱😱😱

🔥 Делимся находками в процессе разработки @bidask

Многие разработчики на TON думают, что мод 64 в сообщении гарантирует, что баланс контракта останется таким же, как и до сообщения. И модом 64 они прикрываются, когда нужно отправить ровно 1 сообщение, не поменяв баланс контракта. Короче, используют мод 64 как гарант, что контракт со временем не обнулит свой баланс.

Ирония в том, что на самом деле мод 64 гарантирует, что баланс контракта НЕ УВЕЛИЧИТСЯ.

А всё дело в storage fee. Нюанс в том, что storage fee (плата за хранение информации в блокчейне) взимается с контракта до запуска TVM, то есть контролировать или отследить этот процесс невозможно. Таким образом, мод 64 рассчитывает, что баланс контракта останется таким же, как и ПОСЛЕ снятия storage fee с баланса. То есть balance_after <= balance_before.

Решений много, но глобально они все опираются на механизм raw_reserve и мод сообщения 128.
Для того, чтобы держать баланс контракта всегда одинаковым, нужно при каждом вызове, где нужно будет отправить сообщение, использовать raw_reserve(<нужный баланс>, 0), а в самом последнем сообщении на контракте использовать мод 128. Таким образом, последнее сообщение заберет с собой все остатки баланса, кроме зарезервированного, и это гарантирует (почти), что баланс контракта не изменится.
При таком решении очень важно понимать, что пользователь может прислать недостаточно газа (с учетом storage fee), и контракт упадет, потому что ему либо не хватит на резерв, либо на сообщение.
Вообще, у raw_reserve тоже есть разные моды, советуем ознакомиться.

@TheOpenDevBlog

🔥 Главная идея 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, с которой нас принято сравнивать, такой киллер фичи нет — в этом мы круче.

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

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

🔥 Пока в 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

🔥 Мы пообщались с @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

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

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

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

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

🅱️ Кидаем скрины скорости свапов, поехали

LFG

https://app.bidask.finance/

🌞 Отвечаем на вопросы про вчерашний релиз @bidask:

Вы обещали свап за 0 секунд, выходит за 15, почти как у других дексов.

🔥 До релиза @bidask обычные(!) трейдеры в выборе адреса своего кошелька полагались на удачу. Это неправильно. В TON очень важен кошелек, с которого вы проводите операции. Дело в том, что TON умеет шардироваться (делиться на части) при больших нагрузках. В данный момент нагрузки нет, поэтому сейчас, скорее всего, в районе 2-4 шардов всего (при 16 максимальных). Сообщения между шардами тратят время, именно поэтому в пики активности свапы в TON раньше длились по минуте-полторы. Если такие нагрузки вернутся в наш блокчейн сейчас, то @bidask этого не почувствует, в отличие от других DEX, поскольку он шард-оптимизирован.

Продвинутые трейдеры брутят себе кошельки, которые:
1) находятся в 1 шарде с протоколом, который им нужен.
2) совпадают шардом с jetton wallet, который нужен для операций в нужном протоколе.

@bidask, в отличие от других дексов на TON, при таком подходе позволяет делать свапы буквально моментально с точки зрения блокчейна. Независимый от нашего участия пример уже есть.
Важно, что даже при такой скорости в tonviewer пользователь ждет 10-15 секунд, пока кошелек обработает ончейн данные. Это от нас не зависит. Отметим, что одной из главных целей TON Core в 2025 году является уменьшение end-to-end latency, то есть как раз уменьшение задержек индексации блокчейна кошельками и приложениями. ЖДЕМ 😐

Мы обязательно сделаем тулзу, которая позволит подбирать кошельки для пулов @bidask, для реального раскрытия потенциала протокола для каждого юзера!
___

Где прочитать документацию протокола?

🔥 На docs.bidask.finance.
___

Tonkeeper пишет комиссию свапа 0.45 TON, это очень много, почему так?

🔥 Мы не знаем. Реальная комиссия сети — 0.04 TON за свап в рамках 1 бина, что крайне низко для такого комплексного протокола с таким количеством фич. По какой причине Tonkeeper (и, возможно, другие кошельки) завышает комиссию, нам непонятно, очень надеемся, что это исправят!

Мы разработчики этого протокола, задавайте вопросы.
@TheOpenDevBlog

🔥 Вчера Павел Дуров сделал сенсационное заявление — TON стал №1 блокчейном по объему трейдинга NFT, если считать off-chain сделки.

Многие посмеялись, посчитали это забавным предложением, но знаете ли вы, что существует стандарт токена (а соответственно, и NFT), который можно передать off-chain?

Это — ERC-965, стандарт токена для EVM сетей (есть более известный аналог — ERC20Permit). Вкратце суть такая — своим приватным ключом вы подписываете некоторую информацию, передаете получившееся как угодно (хоть сообщением в телеграме) другому юзеру, а он со своего Ethereum кошелька может предъявить в смарт контракт этот "чек" и забрать токены. А может не забирать, подождать (хотя вроде это небезопасно).
Этот стандарт нужен для того, чтобы пользователь, передающий токены, не платил за газ (что-то знакомое 🤔)

По сути, это аналог выписывания чека, чтобы получатель должен был самостоятельно зайти в банк и его обналичить. Забавно, что функция в proposal так и называется — sendByCheque.

С переносом данного стандарта в TON есть некоторая проблема. Дело в том, что в Ethereum сущности смарт-контракта и кошелька пользователя (External Owned Account — EOA) разделены. Таким образом, если у вас есть приватный ключ, вы точно знаете, какой кошелек (адрес) в EVM сети ему соответствует. При предъявлении чека токен использует функцию ECRECOVER, восстанавливает кошелек (адрес) отправителя, и переводит его токены владельцу чека.
В TON всё является смарт-контрактом, поэтому однозначно восстановить по подписи адрес затруднительно. Однако всегда можно что то придумать, если будет нужно.

😐 Так что, наверное, Ethereum является топ-1 блокчейном мира по off-chain передаче токенов. Пока.
@TheOpenDevBlog

🔥 Наш блог меняет TON.

Уже довольно давно мы писали обзор на (на наш взгляд) устаревший стандарт жетона, и спустя некоторое время выяснилось, что наш разбор приняла во внимание команда TON Studio!
Они выпустили стандарт «богатого на фичи» жетона (так и называется), в который имплементировали возможность:

⚫️ Деплоя контракта через трансфер жетона
⚫️ Отправки всех жетонов (shut up and take my money)
⚫️ Отказа от деплоя jetton wallet получателя

Реализовано это через заранее предусмотренное поле custom_payload (которое почти не использовалось) у любых жетонов. Отправляешь нужный mode (первые 32 бита custom_payload), и jetton wallet формирует сообщение в соответствии с заданным модом. Минтлесс жетон в такой ситуации остается out-of-scope, планов совмещать эти два стандарта пока нет (да и надо ли?)

Контракты, разумеется, написаны на tact, репа тут, берегитесь комментов под постом.

Кстати, по соседству находится шард оптимизированный жетон (jetton wallet всегда находится в 1 шарде с владельцем), который, видимо, станет новым основным стандартом жетона в самом скором времени (не обязательно имплементация на tact).

Мы в @bidask недавно воспользовались контрактами NFT на tact, и остались довольны. Будем сотрудничать и поддерживать Ton Studio и дальше — они делают крутую работу.

Богатейте фичами, а не мемами
@TheOpenDevBlog

🔥 Денис Васин в недавнем своем опусе написал, что рекомендация засовывать целые протоколы в один шард — это "похороны изначальной идеи масштабирования".

Хоть мы в @bidask и не занимаемся подобным, у нас только каждый отдельный пул в одном шарде, но нам эта мысль не кажется очевидной. Что думаете?

🔥 Как работает концентрированная ликвидность.

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

Обычные DEX, к которым на TON уже привыкли (их еще называют CPMM — constant product market maker) работают по простейшей формуле — есть количество токена X, количество токена Y, до свапа есть инвариант: X * Y == k. Пользователь присылает сколько то токенов, и DEX должен вычислить такое число выходящих токенов, чтобы после проведения операции значение X * Y == k сохранилось. После этого или перед этим берутся комиссии, это не принципиально, основной принцип таков. Почитать подробнее можно тут.

Это очень простая мат. модель, она работает для почти любых количеств токенов, но эволюция DeFi привела к появлению механики, гораздо более эффективно использующей ликвидность.

CLMM — concentrated liquidity market maker, усложняет механизм CPMM. Он вводит понятие диапазонов. Теперь предоставить ликвидность можно так, чтобы она использовалась только при торговле в определённом диапазоне цены, или "сконценрировать" её. Такой подход приоритизирует сконцентрированную ликвидность над всей остальной и позволяет получать гораздо больше комиссий при меньшем капитале. Эта механика вводит в действие целую новую "рыночную игру": теперь провайдеры ликвидности соревнуются в том, кто корректно предскажет цену и получит от этого выгоду, открывая пользователям ещё один способ заработать.

Помимо этого, концентрация ликвидности означает, что теперь нужно больше объёмов, чтобы сдвинуть цену, так как почти вся ликвидность в пуле сконцентрирована вокруг неё, и она будет использоваться, пока полностью не исчерпается. Иными словами, уменьшается slippage при свапе. Таким образом, концентрация ликвидности дает преимущество не только провайдерам, но и обменивающим.

Ввиду ограничений смарт-контрактов, на практике CLMM обычно реализуется через так называемые бины. Если предельно упрощать (в разных моделях по разному бывает), то бин — это маленький CPMM пул, который оперирует в рамках небольшого отрезка цены. Если вы зайдёте на @bidask в любой пул, то увидите график ликвидности. Каждый столбик на этом графике — это бин, у него есть своя ликвидность, и ликвидность у соседних бинов никак не пересекается.

Таким образом, если торги происходят в бине, в котором у вас лежит ликвидность, вы получаете неплохой процент на неё, однако если цена не в ваших бинах, вы ничего не получаете. Чем у́же выбранный вами диапазон — тем больше все зависит от того, насколько хорошо вы угадываете цену на будущем рынке, и наоборот — существуют стратегии предоставления ликвидности на очень широкие диапазоны, которые годами получают стабильные 15-20% годовых при минимальных рисках.

Разбирайтесь.
@TheOpenDevBlog

🔥 Давайте поговорим о TOLK

Новый ЯП на TON релизнулся, инфы ноль. В первые дни, пока команда @bidask не заметила, tonapi даже некорректно эмулировал контракты на tolk — выдавал ошибку при любом вызове контракта. Это быстро пофиксили, спасибо за это. А про новое мы, как обычно, вам всё расскажем.

Важное:
⚫️ Структуры.
Ключевое улучшение языка. Позволяет описывать и переиспользовать, собственно, структуры или схемы BoC. Записать или загрузить структуру теперь можно в одну строчку, а если быть точнее, в один метод: store() или load().
Больше никаких файлов и функций для обработки стораджа контракта. Понадобился новый глобал? Добавь в структуру и всё.
Больше никаких ошибок из-за того, что добавил в интерфейс контракта поле, но забыл добавить в билдинг сообщения. Компилятор обо всём предупредит.
Бесшовное взаимодействие с абсолютно неинтуитивной структурой Cell — это очень важное улучшение.
⚫️ Lazy load-ы.
Это, без преувеличений, геймченжер. Из структуры можно загружать не всё подряд, а ровно то, что вам нужно. А всё остальное просто скипать. Это очень круто, это практически нереализуемо на FunC, это реальная причина пересаживаться на tolk. Аналогом этого механизма является использование static cell-ов в стораджах и сообщениях — cell-ов, которые не меняются в большинстве случаев, а поэтому не распаковываются или не запаковываются, не тратя лишний газ. Насколько мы понимаем, основная оптимизация tolk в бенчмарках заключается именно в этом.
⚫️ Синонимы типов.
У нас в @bidask существуют funny-числа: это такие 256-битные представления вещественных чисел.
В FunC это обычный int, а потому перепутать funny и не-funny число — как раз плюнуть. Это обеспечило нам единственный critical bug в аудите.
Если бы в FunC были синонимы типов, ошибку бы заметили на стадии компиляции.
⚫️ Логические || и &&.
Ну тут особо останавливаться не надо, спасение пришло. Работают они как и должны — если выражение становится всегда верно или неверно, то оно не продолжает вычисляться.
⚫️ Switch-case.
Эпоха бесконечных if прошла, спасибо вашему дому, мы идем к другому.

На самом деле, изменений больше, очень много quality of life, но просто не видим смысла об этом всем рассказывать, наткнётесь по дороге. Главное, что делает tolk — это является похожим на традиционные языки программирования, не теряя, а приобретая в эффективности кода.

Все это предлагаем обсудить на ближайшем мероприятии в Москве. До встречи!

Каламбур.
@TheOpenDevBlog