🔥 Вчера Павел Дуров сделал сенсационное заявление — 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

Dear USA citizens,

🔥 You can read our channel using the telegram translation feature — or, as we say in russian, “perevoda cherez chatgpt”.

🅱️ We also recommend depositing liquidity on @bidask: our TON/USDT pool has been showing a 40% APY since our release.

Welcome aboard!
@TheOpenDevBlog

🔥 Вспоминаем истоки.

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

Не так давно у swap coffee появился свой DEX, он вышел сразу с аудитом от TrailOfBits (аудит почему-то был удалён из репы, найти его можно в истории коммитов). И среди всего аудита (весьма неплохого, судя по всему) давайте разберём одну багу, которая крайне характерна именно для TON — под номером 6 (четыре шесть) в отчёте.

Основой билдинга вокруг DEX является так называемый возврат исполнения — когда после успешно проведённой операции на DEX происходит исполнение какой то логики на следующем контракте. Например, в @bidask мультихопы реализованы по сути как 2 свапа — сначала один пул проводит свап, потом передает токены другому пулу и "просит" провести второй свап.

На блокчейне TON, ввиду его асинхронности, это реализовано через forward_payload-ы — то есть какие-то данные, которые можно передавать получателю результатов операции (например, после успешного свапа), чтобы он на основе этих данных делал что-то ещё.

С жетонами никакой проблемы нет, а вот TON, как валюта для оплаты комиссий, всегда вызывал проблему — как отделять логический TON, с которым проводится операция, от TON, который был прислан для комиссий? Ston fi не заморачивались — просто обернули TON в жетон, и всё. Но это не очень эффективно, поэтому другие DEX начали что то выдумывать.

Самым логичным решением было просто хранить TON на каком-то контракте DEX. Например, в @bidask он хранится на пуле. После свапа пул просто отправляет весь TON (и комиссионный, и свапнутый) получателю.

Так же сделали и swap coffee, но ошиблись: вместе с TON они слали просто forward_payload, ничего с ним не делая. Это кажется элегантным решением, свапающий сразу может вставить нужный ему опкод, вызвать нужную операцию на своем контракте после свапа, и не париться. Однако именно это и является проблемой — атакующий может указать в качестве получателя результатов свапа внутренний контракт декса, и от имени пула/vault-а (сообщение с TON же идет оттуда) указать ему что-то сделать (например, вывести ликву на кошелёк атакующего, или провести еще один свап, или депозитнуть еще ликвидности).

В этом и заключается баг, именно поэтому подобные сообщения нужно префиксовать чем-либо — например, мы в @bidask озаботились этим ещё при написании кода, и используем свой опкод, который вставляем перед forward_payload. Таким образом, сообщение не подпадает ни под одну схему интерфейса внутри DEX, и уязвимость не может быть проэксплуатирована.

Хорошо, что эту уязвимость обнаружили при аудите — это очень круто. Нам известно, что у как минимум 2-х других проектов на TON этот баг при аудите не был найден.

Думайте.
@TheOpenDevBlog

🔥 Расставим акценты.

Вчера один из наших авторов выступал на мероприятии, организованном TON CIS Hub, где рассказывал про актуальный статус on-chain разработки в блокчейне TON.

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

И это плохо, это то, что нам надо решать. Нужно публиковать статьи, рассказывать про best practices, делиться опытом, чтобы в экосистеме накапливались возможности упростить жизнь новым разработчикам. И нужно говорить как есть — что можно улучшить.

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

@TheOpenDevBlog

🔥 Open-source в каждый дом.

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

Собрали open-source контракты на TON, чтобы было легче вкатиться. В комментах дополняйте.

Jettons:
tolk-bench (Tolk, FunC) (Также есть NFT)
notcoin-contract (FunC)
tact-jetton (Tact)
_______
NFT:
NFT-TON-Studio (Tact)
Getgems-NFTs (FunC)
TON-Community (FunC)
_______
DeFi:
Ston fi v1 (FunC)
Ston fi v2 (FunC)
TON Studio DEX (Tact)
Coffee Swap (FunC)
EVAA (FunC)
jVault (FunC)
_______
Misc:
DeFi-Cookbook (Tact) — много примеров стандартных операций в смарт контрактах
Tact-Benchmarks (Tact, FunC) — Escrow, wallets v4, v5
Wallet v5 (FunC)
ZK2FA for wallet w5 (FunC) — пример extention-а для wallet v5
Nominators pool (FunC) — контракт для распределения наград за стейкинг TON

Учитесь на чужих ошибках, сейчас это вполне возможно.
@TheOpenDevBlog

🔥 Поделитесь: с какой болью вы встречались как разработчик при взаимодействии с контрактами в сети TON?

Что угодно — кривой интерфейс, контракт не отдает какую-то информацию, etc.

🆘 Делимся.

🔥 Cell-библиотека.

Одной из скрытых от глаз простого копеечного разработчика механик являются library cell-ы. Возможно, вы замечали, что, например, у jetton wallet USDT подозрительно маленький код, вряд ли такой контракт может поместиться в 1023 бита одного cell-а. Для того, чтобы так сделать, используются library cell.

Представьте себе всю информацию в блокчейне TON. В нем, например, находятся 3 миллиона кошельков USDT, или 50 пулов ликвидности @bidask. При трансфере жетонов jetton-wallet обязательно деплоит свою копию, принадлежащую другому адресу, то есть посылает свой код, чтобы блокчейн опубликовал его на новом адресе. Таким образом, если бы код USDT был обычным, то в блокчейне произошло бы как минимум 3 миллиона трансферов с одинаковым кодом jetton-wallet-а, что потратило бы немало forward fee.

Чтобы сократить forward fee для повторяющихся данных, в TON реализована система library cell-ов. Это возможность опубликовать cell с каким-то содержимым в мастерчейне, чтобы ссылаться на него из своих контрактов. Это полезно в случае, если вы часто шлёте этот cell в сообщениях (как раз как в случае с жетон трансферами). Таким образом, каждое ваше сообщение сокращается в размерах, что приводит к уменьшению forward fee.

Если library cell поставить в код адреса, то при вызове контракт будет разыменовывать ссылку на ячейку, которая лежит в мастерчейне. Каждый вызов адреса с кодом в library cell будет забирать меньше storage fee, ведь код контракта сократится до одной ячейки. Хороший пример — опять жетоны.

За всё надо платить, поэтому в качестве компенсации вам нужно оставить TON для storage fee за хранение данной ячейки в masterchain. Это дороже, чем хранить 1 контракт в basechain, но гораздо, кратно дешевле, чем 3 миллиона контрактов, или же если посчитать экономию на жетон трансферах. ❗️ Однако будьте осторожны — если вдруг storage fee превысят баланс контракта, на котором задеплоена либа в мастерчейне, то можно будет прислать сообщение с маленьким количеством TON, и контракт с либой заморозится, а всё, что использует данный library cell, может перестать работать. В такой ситуации задеплойте ту же самую либу с другого адреса, и всё заработает заново.

Подробнее про library cell можно почитать в офф документации. Примеры использования — в новоиспеченном jetton 2.0. Совсем недавно Ton Tech добавило поддержку публикации либ в sandbox, но, к сожалению, пока не добавила поддержку их удаления (да, их и удалять можно).

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

Library cell-ы крайне рекомендуется использовать в жетонах, а также всём, что вы можете часто деплоить. Удачи!

@TheOpenDevBlog

🔥 "New Bounce Message Format" — что это?

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

Для начала немного базы.

Bounce-сообщения — это механизм в TON, который призван возвращать TON отправителю при ошибке в исполнении смарт контракта. Например: вы пытаетесь послать 10 жетонов, а у вас их всего 9. Чтобы ваши TON не застряли на jetton wallet, после ошибки они возвращаются вам на кошелек.

Сейчас bounce-сообщение несёт за собой специальный опкод 0xffffffff, а также 256 бит оригинального сообщения, после которого случилась ошибка. Это очень мало (например, адрес в TON весит 267 бит), поэтому практически ни для чего дельного использовать bounce-сообщения нельзя.

Окончание базы.

Совсем недавно был опубликован proposal, который вводит новую систему bounce-сообщений. Новый формат позволяет вернуть на контракт-отправитель оригинальное сообщение, чтобы обработать ошибку, и совершить какое-либо действие с дополнительными данными. Новая система позволит узнавать коды ошибок, из-за которого произошёл bounce, и много разной информации, недоступной ранее (например, сколько газа потратил контракт прежде, чем выкинуть ошибку — непонятно, для чего кому-либо эта инфа, но вдруг понадобится). Новые bounce-сообщения будут нести опкод 0xfffffffe.

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

Изучаем.
@TheOpenDevBlog

🔥 Поднять щиты!

Недавно популярный блогер overbafer1 выпустил ролик про "безопасность" сайтов, связанных с TON.

Вообще, стоит сказать, что в тусовках безопасников overbafer1 — это своеобразный мем. Все его когда-то смотрели, каждый когда-нибудь нет-нет да и да, ломал свой WI-FI по его гайдам, но как только соприкасаешься с реальной безопасностью, находишь работу, то стараешься всячески откреститься от этого опыта, он стыдный. Таких, как overbafer1, среди профессионалов в сфере безопасности называют "script kiddie". На личности уже перешли, теперь давайте по сути. Разберем, кто ведущий эксперт, а кто ведомый.

Видео разделено на две части. В первой из них overbafer1 показывает действительно рабочий хак, называющийся IDOR (Insecure Direct Object Reference), когда, обладая некоторой незначительной информацией (например, telegram id пользователя), можно посмотреть данные об его аккаунте в игре. Уязвимость реальная, хоть зачастую и low приоритета, но стоит понять специфику индустрии. Блокчейны как таковые строятся на том, что IDOR — это корректное поведение программы. Блокчейн отличается от банка тем, что банк не покажет ничью историю транзакций, кроме вашей, тем временем в блокчейне видно всё. Багу в игре нужно фиксить, но ее не стоит переоценивать. Тем более если приложение в бета тестировании.

Во второй же части блогер проводит "сканирование" сайтов, связанных с TON, автоматической тулзой, и показывает шокирующие результаты. На экране написано, что, например, у сайта ton.org 9 critical уязвимостей. Вкратце — это просто ничего не значащая липа. Автоматические инструменты для сканирования безопасности в 99% случаев выдают false-positive результаты, когда проверка на что-то сработала, но по сути никакого влияния на бизнес процесс не было и не будет оказано.

В ролике overbafer1 показывает результаты сканирования и там часто мелькает термин "CVE". Что это такое? CVE — это аббревиатура, которая расшифровывается как Common Vulnerabilities and Exposures. Это реестр уязвимостей, найденных в каком-либо софте, подтвержденных разработчиками этого софта. При занесении в реестр CVE присваивается severity (критичность) от 0 до 10.

Если сканер указал на CVE — это ещё не означает, что уязвимость есть. Это означает, что где-то в использующемся на сайте фреймворке, продукте и т.д была найдена какая-то уязвимость. Это совершенно не означает, что уязвимый сегмент кода используется на сайте, ведь это может быть, например, платежный модуль, а на сайте ton.org нет никакой платежки. И абсолютно не зря блогер показал одну реальную уязвимость минут за 10, и в часовом ролике не нашел времени показать какую-либо другую, предложив подписчикам "самим проэксплуатировать уязвимости на сайте".

За сайтами вроде ton.org или fragment.com ежедневно наблюдают десятки потенциальных злоумышленников. Любой, кто хостил сайт и смотрел в логи, замечал, что даже на самом ненужном никому домене проводится по 1-2 скана за сутки от неизвестных ботов. И уверяем, каждый из этих сканов покажет существование в приложении CVE.

Забавно, что в тг канале утилиты, которую использует блогер, есть, например, скан Пентагона, где было найдено 6 critical CVE. То есть наш родной ton.org всего на 30% слабее Пентагона.
Это выход на рынок США?????

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

Не ведитесь.
@TheOpenDevBlog x @bidask

🔥 @bidask будет кормить ВСЕГДА

Среди пользователей гуляет миф, что если в пуле концентрированной ликвидности увеличится TVL, то APY в нём уменьшится. Не раз и не два раза уже это слышим от различных представителей экосистемы. Это не так, давайте это разберём.

Для начала надо понять, откуда вообще APY в концентрированной ликвидности? Основные объемы высоколиквидных активов на DEX к стейблкоину (например, TON/USDT) — это всегда арбитраж. Арбитраж существует, пока для него существуют "арбитражные окна" — это возможность "купить подешевле, продать подороже". В контексте арбитража на @bidask — это значимое отличие от цены на CEX. То есть арбитражное окно существует, пока цена на DEX отличается от цены на CEX (математика чуть сложнее, потому что на DEX ещё существует комиссия провайдеров ликвидности, но это не влияет на рассуждение), и арбитражник может купить на @bidask, а продать на Binance, и получить с этого выгоду.

Для того, чтобы цена на @bidask двигалась, нужно свапать в нужную сторону: буквально "докладывать" в пул один актив, а второй "вынимать". Это означает, что если между нынешней ценой и ценой на CEX есть ликвидность, то она вся будет просвапана в угоду арбитражу, и абсолютно вся получит процент за предоставление ликвидности. При этом объем арбитража будет ровно таким, чтобы просвапать ликвидность от текущей цены до цены на CEX. Таким образом, если TVL в этом диапазоне цены увеличится в 10 раз, то и объемы арбитража тоже в 10 раз вырастут. А значит, и вырастут собранные fees.

Главный смысл концентрированной ликвидности, как это ни странно — в концентрации ликвидности. Именно благодаря этому объемы растут прямо пропорционально TVL в проходимом диапазоне. Каждый конкретный пользователь волен решать, расставлять ему ликвидность широко, более безопасно, и получать меньший процент, или узко, получая большой процент из-за лучшей концентрации ликвидности.

Разумеется, если залить ликвидность далеко от активной цены, ваш APY будет целых 0% в наносекунду! Не надо так делать, если вы не знаете, как с этим можно работать.

В чем подвох? Подвох в том, что если завтра внезапно TVL пула TON/USDT увеличится настолько, что эта ликвидность начнёт влиять на цену даже на CEX (например, до 50 миллионов $), то APY пула действительно уменьшится, потому что эта ликвидность начнёт оказывает значимое давление на движение цены. Мы будем этому рады, а пока это не так — bidask.finance.

APY TON/USDT на @bidask — 50%.
Думайте.
@TheOpenDevBlog

🔥 Мы провели свой первый публичный аудит на TON для проекта WEB3 - webdom ончейн маркетплейса доменов и юзернеймов на TON.

Нашли 1 очень серьезную уязвимость, специфическую именно для TON, о которой обязательно напишем пост позже.

Обращайтесь.
@TheOpenDevTeam x @TheOpenDevBlog

🔥 Освещаем.

Наши дорогие коллеги из Torch finance принесли вкусное — они разработали единый стандарт vault-ов для TON-а. Всё на Tolk (пока только 1.0).

Данный стандарт призван упростить билдинг DeFi инструментов на TON, по аналогии с тем, как на EVM сетях есть куча open-source стандартов для задач разной сложности. Часто архитекторы в других сетях оперируют не кастомными решениями, а занимаются собиранием продукта из коструктора — готовых open-source стандартов, применимых в конкретной ситуации.

Сам vault представляет из себя контракт, принимающий на вход конкретный актив, и минтящий share — lp токены доли пользователя от общего размера vault-а.

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

❗️ Мы уже говорили, и еще раз говорили, и еще раз скажем, что open-source — это то, что упрощает обмен опытом и онбординг в разработку. Нам нужны новые стандарты, open-source инструменты, блоги про разработку на TON. Если у вас это есть — делитесь!

Осветили.
@TheOpenDevBlog

🔥 До встречи на TOKEN2049 в Сингапуре!

Контакты в био канала.
@TheOpenDevBlog

🔥 На волне хайпа комиссионных жетонов разберёмся, как они работают.

Разбираться будем на примере нашумевшего $GIFTSTR. Он имеет комиссию на покупку и продажу себя. Как это реализовано?

Если посмотреть на транзакцию продажи, то там всё просто — при отправке жетонов с целью продать jetton wallet отправителя парсит свой forward_payload, и если находит там операцию продажи токена, отправляет 10% от депозита на jetton wallet команды. Это, к сожалению, ведёт к тому, что при неудавшемся свапе пользователь теряет 10% баланса. От этого крайне трудно избавиться, поэтому это не особо важно.

При покупке жетона всё сложнее. Когда мы продаем жетон, $GIFTSTR контролирует момент продажи, потому что он начинается с jetton wallet $GIFTSTR. При покупке же jetton wallet участвует только в конце, когда свап прошёл, и надо выплатить пользователю его жетоны. Поэтому самый простой способ проверять покупку — это проверять, что жетоны отправляются с адреса волта Dedust. И действительно — в такой ситуации jetton wallet отправляет 10% от полученного количества жетонов на кошелек команды.

Но у этого есть побочный эффект. Если выплата с волта Dedust происходит по иным причинам (например, вывод ликвидности), то пользователь тоже будет терять 10% от полученных токенов, хотя никакого свапа не произошло. Поэтому, несмотря на 100% APY на Dedust, класть ликвидность в $GIFTSTR — крайне сомнительная затея.

@TheOpenDevBlog