🔥 Главная идея 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/

🔥 Вчера Павел Дуров сделал сенсационное заявление — 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 и не занимаемся подобным, у нас только каждый отдельный пул в одном шарде, но нам эта мысль не кажется очевидной. Что думаете?