Prince ETH

Что именно вы авторизовали, когда подписывали?

Нажатие «Подписать» ощущается как момент, когда блокчейн-транзакция становится полностью определённой. Подпись доказывает, кто её авторизовал, поэтому так легко предположить, что теперь у транзакции есть одно очевидное значение везде и навсегда.

Обновление Boreas от Dusk показывает, почему это предположение неполное.

Когда Boreas вышел в мейннет 10 июня 2026 года на блоке перезапуска 4,414,095, Rusk начал применять явные границы версий при интерпретации транзакций. Ливые транзакции декодируются по действующим правилам протокола. Поддерживаемые Aegis-обёртки нормализуются в текущее представление. Локально запечатанные транзакции приводятся к каноническому виду перед фиксацией в реестре. Более старые декодеры остаются доступны для исторического воспроизведения.

Смысл важнее деталей реализации: Dusk явно запрещает mempool, блоку-производителю, консенсусному валидатору и пути воспроизведения интерпретировать одни и те же данные транзакции по разным правилам.

Подпись может аутентифицировать данные, которые вы авторизуете. Но она не может самостоятельно подсказать каждой будущей версии протокола, как понимать эти данные.

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

Для кошельков, бирж и аппаратных подписантов обработка версий протокола — это не просто «обвязка» совместимости. Это часть сохранения смысла того, что пользователь подписал.

@Dusk $DUSK #dusk

«Ожидает» — это правда факт на уровне всей сети?

Один кошелёк может пометить транзакцию Dusk как «ожидает», в то время как на другом узле вовсе нет соответствующей записи в mempool.

Это не обязательно является несоответствием. Так происходит из‑за того, как Dusk обрабатывает транзакции до того, как они становятся состоянием реестра.

Каждый peer выполняет собственные проверки допуска и ведёт собственный mempool. Запрос mempoolTxs для Dusk поэтому показывает реальный mempool того узла, к которому обращались, — а не общую для всей сети очередь, разделяемую всеми peers.

Обработка в эпоху Boreas-era Moonlight делает это ещё менее интуитивным. Допустимая транзакция, чей nonce опережает текущую последовательность аккаунта, может быть отложена, пока не придут недостающие nonces. В этот период она находится вне видимого реального mempool узла. Поэтому даже тот узел, который получил транзакцию, может ещё не показывать её в mempoolTxs.

Истечение срока добавляет ещё одно локальное измерение: это политика узла, а не «срок жизни», закодированный прямо в самой транзакции.

Это меняет то, как я бы понимал слово «ожидает». До консенсуса Dusk не предоставляет одну авторитетную глобальную транзакционную «состояниe», которую могут наблюдать все. Разные узлы могут обоснованно хранить различающуюся информацию об одной и той же транзакции.

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

Именно консенсус превращает эти разрозненные локальные представления в общую историю реестра.

@Dusk $DUSK #dusk

Архивированное событие «Угасание» может описать изменение состояния, которого не происходило

Бэкенд может прочитать событие из финализированного архива Dusk и все равно принять неверное финансовое решение.

Поскольку Boreas стал активным в мейннете на блоке перезапуска 4,414,095, Dusk намеренно сохраняет в архивных данных откатившиеся события контрактов с пометкой reverted. Эти события являются историческим доказательством того, что выполнение их породило — но не подтверждением того, что их эффекты состояния пережили откат.
После Boreas откатившиеся события исключаются из канонического bloom блока, а откатившиеся события по ставкам не обновляют состояние провиженера.

Этот нюанс важен там, где события превращаются в мутации базы данных. Индексатор, который воспринимает «событие существует» как «операция выполнена успешно», может засчитать депозит, записать выплату или запустить логику downstream для состояния, которое цепочка откатила.

В собственных рекомендациях Dusk по депозитам Moonlight правило сформулировано явно: прямой депозит принимается только тогда, когда событие передачи соответствует ожидаемой операции и event.reverted === false.

Итак, финализация отвечает на один вопрос: эта архивная история считается урегулированной? Она не отменяет необходимости интерпретировать то, что говорит эта история.

Для интеграций Dusk после Boreas reverted — это не метаданные, которые можно игнорировать. Это часть условия принятия, разделяющего доказательства исторического выполнения и каноническое состояние.

@Dusk $DUSK #dusk

Может ли транзакция Dusk пройти on-chain и при этом всё равно не доставить DUSK на предполагаемый адрес в BSC? Да, потому что в этом сценарии моста есть две скрытые точки назначения, объединённые одним действием пользователя.

В текущем основном сценарии Dusk (mainnet → BSC) Web Wallet отправляет нативный DUSK на официальный аккаунт моста. Получатель в BSC — это не поле получателя этой транзакции; оно передаётся в memo. Мост считывает этот адрес в EVM-формате и использует его для маршрутизации выплаты BEP20.

Из-за этого меняется смысл слова «успешно». Подтверждённая on-chain транзакция Dusk доказывает, что передача со стороны источника дошла до аккаунта моста. Но сама по себе она не доказывает, что выплата на стороне назначения была направлена на тот адрес, который пользователь планировал. Документация Dusk предупреждает: отсутствующий или некорректный memo не может быть обработан автоматически и может сделать перевод необратимым.

Так что memo делает больше, чем просто описывает транзакцию. В этом сценарии оно является частью инструкции по доставке.

Я думаю, это задаёт полезную границу для кошельков и UX моста: когда инфраструктура потребляет метаданные, чтобы решить, куда дальше пойдёт ценность, эти метаданные следует считать вводом, критичным для транзакции. Аккаунт моста и адрес в memo заслуживают такого же тщательного предварительного контроля перед отправкой.

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

@Dusk $DUSK #dusk $TRUMP $ZEC

«Нулевой риск ликвидации» читается просто: «Я всегда смогу аккуратно управлять позицией». TermMax Alpha разделяет эти две идеи.

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

Но закрытие до наступления срока — это другая задача. В документации TermMax указано, что досрочное закрытие всё равно требует контрагента. Если ликвидность низкая, позицию может быть сложно быстро закрыть или для этого может потребоваться существенный проскальзывание.

Это различие важно. Риск ликвидации отвечает на вопрос, может ли протокол принудительно закрыть вас, потому что залога недостаточно. Риск выходной ликвидности отвечает на вопрос, найдётся ли кто-то, кто готов занять противоположную сторону, когда вы решаете выйти.

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

Поэтому «нет ликвидации» не означает «нет рыночного трения». Это описание того, как ограничивается риск снижения, а не того, насколько ликвидна позиция до наступления срока. Для меня это гораздо более полезный способ читать риск опционной позиции, чем один только заголовок.

@TermMax #TermMax $BTW $BLESS $BCH

Фиксированная ставка, меняющаяся котировка

TermMax может предлагать кредитование по фиксированной ставке и при этом давать двум пользователям, смотрящим на один и тот же рынок, разные APR.

Это звучит противоречиво только если «фиксированное» воспринимать как котировку, которая существует до сделки. Ордера TermMax Range Orders работают иначе: ликвидность распределяется вдоль ценовой кривой, а APR меняется по мере заполнения большей части этой кривой. Небольшой ордер может остановиться близко к одной точке; более крупный ордер способен поглотить более глубокую ликвидность и зафиксировать другую эффективную ставку.

Почему сделано именно так? Потому что рынку с фиксированным доходом всё равно нужна процедура ценообразования. Вместо того чтобы навязывать одну ставку для каждой величины сделки, Range Orders позволяют задающим ордера выразить, сколько ликвидности они готовы предоставить при разных APR. Ставка становится фиксированной после исполнения, а не до него.

Экономические последствия легко упустить из виду: заголовочный APR и исполнимый APR не всегда одно и то же. Объём является частью цены ликвидности с фиксированной ставкой.

Итак, кривая TermMax не делает кредит «с плавающей ставкой». Она определяет, какую фиксированную ставку приносит ваша сделка до того, как позиция будет зафиксирована.

Фиксированная ставка ≠ фиксированная котировка.

@TermMax #TermMax $PEOPLE $MAGMA $BTW

Токенизация не устраняет трение. Она переносит его.

Токенизировать актив просто по сравнению с тем, чтобы заставить рынок вокруг него перестать «сверяться» сам с собой.

Именно эта часть текущего дизайна рыночной инфраструктуры Dusk для меня важнее, чем сам токен. Dusk Trade связывает обнаружение активов, онбординг инвесторов, определение прав (eligibility), координацию платежей, торговлю и расчёты, в то время как более широкий стек Dusk предоставляет средства контроля и нижний слой расчётов.

Тезис прост: токенизация создаёт реальную эффективность только тогда, когда несколько участников могут действовать с одним и тем же контролируемым состоянием. Если право собственности, доступность (eligibility) и расчёты продолжают жить в отдельных системах, токен может превратиться в ещё одну запись, которую нужно согласовывать, а не в запись, которая устраняет необходимость согласований.

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

Поэтому я бы не оценивал токенизацию по тому, насколько быстро можно выпустить ценные бумаги. Более сложная проверка — снижает ли инфраструктура количество «передач» без притворства, что код заменяет институты, ответственные за эти передачи.

@Dusk $DUSK #dusk $BOME $NEIRO

P2P-счётчик обратного отсчёта не является доказательством оплаты

Счётчик может создавать срочность, не добавляя никаких доказательств.

В текущей P2P-модели заказов Binance ордер со статусом «Оплачено (не подтверждено)» может показывать крайний срок выпуска. Этот таймер полезен: он подсказывает, на каком этапе находится ордер, и сколько времени осталось. Но он не говорит о том, достигла ли ожидаемая сумма VND на счёт получателя.

Это различие влияет на решение до подтверждения выпуска (Confirm Release).
Если таймер запущен, но в банковском аккаунте всё ещё не отображаются ожидаемые средства, сигналы расходятся. Счётчик не должен «перевешивать» проверку оплаты. Храните криптоактивы в эскроу и устраняйте несоответствие через сценарий Order/Appeal (ордер/апелляция).

Если деньги видны, проверка всё равно имеет второй уровень: соответствует ли платёж этому ордеру и информации о плательщике, которую ожидает Binance? Правила для продавцов на Binance напрямую рассматривают несоответствие имени плательщика как основание не выпускать средства.

Итак, таймер отвечает на вопрос о времени. Ваш счёт получателя и детали ордера отвечают на вопрос о платеже.

Простая ментальная модель: сроки говорят, когда действовать; доказательства — что безопасно делать.

@Binance Vietnam #BinanceP2PAnToan $AVAAI $ACE $ONG

У фиксированной ставки всё равно нужно назначить цену

TermMax называет её фиксированной ставкой заимствования/кредитования, но самое интересное происходит ещё до того, как ставка становится фиксированной.

На рынке TermMax создатели лимитных ордеров по диапазонам (Range Order Setters) могут размещать несколько Range Orders с настраиваемыми ценовыми кривыми. Получатель (taker) не получает ставку по единой формуле, действующей для всего протокола; исполнение происходит относительно ликвидности, распределённой вдоль этих кривых. Это означает, что размер сделки и доступная глубина могут изменить эффективную ставку, которую вы фиксируете.
Цепочка причинно-следственных связей проста:

Дизайн Range Order → распределение ликвидности → цена исполнения → подразумеваемая ставка → экономика фиксированной позиции.

Это меняет то, как я думаю о «DeFi с фиксированной ставкой». TermMax убирает один тип неопределённости после исполнения: стоимость заимствования или доход от кредитования фиксируются до погашения. Но он не устраняет ценовое обнаружение (price discovery) до исполнения. Надёжность позиции строится поверх маркет-мейкерского решения.

Это также смещает внимание на то, кто контролирует кривую. Создатель Range Order может формировать то, где именно предлагается ликвидность, тогда как сам протокол предупреждает, что плохо настроенные кривые могут привести к невыгодному исполнению. Значит, риск — это не только «сдвинутся ли ставки позже?». Это ещё и «была ли эта ставка сформирована эффективно, когда я вошёл?»

Второй порядок: фиксированный доход onchain не устраняет рыночную микроструктуру. Он делает микроструктуру более значимой именно в момент входа. Фиксированная ставка может быть предсказуемой месяцами — и при этом оставаться плохой ставкой, если кривая и глубина были недостаточными, когда вы её зафиксировали.

@TermMax #TermMax $BTW $RE $MAGMA

Сделает ли DuskEVM контракты Solidity приватными по умолчанию?
DuskEVM создаёт простое допущение: если приложение работает на Dusk, то оно автоматически унаследует модель приватности Dusk.

Но архитектура говорит точнее.

DuskEVM — это среда выполнения EVM на базе OP Stack. Там исполняются Solidity-контракты с привычными инструментами Ethereum, а пакеты и фиксации состояния оседают через DuskDS, который обеспечивает консенсус, детерминированную финализацию и доступность данных.

Это разделение важно, потому что совместимость выполнения и возможности приватности — не одно и то же гарантийное утверждение.

Собственная документация Dusk позиционирует DuskVM как путь для контрактов, которым требуется прямой доступ к активам L1, моделям транзакций, возможностям приватности или нулевого знания. DuskEVM, напротив, сначала решает другую задачу: выполнение, эквивалентное EVM, и совместимость для разработчиков. Приватно-ориентированные рабочие процессы могут подключаться к более широкому стеку Dusk, но при этом они всё равно зависят от того, как устроено приложение.

Поэтому полезный вопрос не «Могут ли разработчики Ethereum развернуть контракты на Dusk?». Могут.

Сложный вопрос в другом: какие гарантии даёт слой EVM, а какие нужно намеренно собрать из DuskDS или Dusk-native примитивов?

Это меняет ментальную модель. Dusk — это не просто «обёртка приватности» вокруг EVM. Это разделение выполнения, расчёта (settlement) и инфраструктуры, поддерживающей приватность, чтобы разработчики могли выбирать, откуда берётся каждая гарантия.

Для регулируемых финансов это модульность мощна — но также делает архитектурные решения частью модели комплаенса и конфиденциальности.

@Dusk $DUSK #dusk $HEMI $ACE

Одно правило Binance P2P заслуживает большего внимания, потому что оно разделяет две проверки, которые продавцы часто воспринимают как одно и то же: «Деньги пришли?» и «Они пришли от верифицированного покупателя?»

Для P2P-сделок не в CNY в правилах Binance по апелляциям говорится, что если имя в платежном аккаунте покупателя не совпадает с верифицированным именем на Binance P2P, криптовалюту выпускать нельзя. Продавцу предлагают вернуть полную сумму, а ордер отменяют после предоставления доказательств возврата и подтверждения покупателем получения.

Эта деталь важна, потому что получение правильной суммы — это лишь доказательство оплаты. Это не доказательство того, что личность плательщика совпадает с человеком из заказа.

Несовпадение имени не автоматически доказывает мошенничество. Могут быть невиновные объяснения: покупатель может использовать банковский счет другого члена семьи, корпоративный аккаунт или просто игнорировать требование к названию в назначении платежа. Но с точки зрения продавца практическое решение то же самое: не «разрешать» выпуск, сначала не разобравшись, а затем не задавать вопросы.

Перед Confirm Release сравните три вещи:
сумму в заказе,
фактический банковский баланс,
и имя отправителя с верифицированным именем покупателя, указанным в заказе.

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

Полезное различие простое: верификация платежа отвечает на вопрос «деньги получены?» Верификация личности отвечает на вопрос «кто оплатил?» На Binance P2P для безопасного релиза нужно, чтобы оба вопроса были согласованы вместе.

@Binance Vietnam #BinanceP2PAnToan $BTC $ETH $SOL

На прошлой неделе я заказал ноутбук на Shopee. Оплата при получении. Курьер привёз посылку, я проверил, что она запечатана и соответствует заказу, заплатил 18 миллионов VND и забрал. Всё просто.

Но подумайте, что произошло: Shopee держала мой заказ в состоянии, когда продавец не мог забрать мои деньги, а я не мог получить товар, пока не будут выполнены оба условия. Продавец отправил товар первым, полагаясь на то, что COD гарантирует оплату. Я оплатил при доставке, полагаясь на то, что внутри посылки — то, что я заказал. Курьер был нейтральной третьей стороной, делающей обмен «атомарным»: товар и платеж переходят в один и тот же момент.

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

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

@Dusk _Foundation запускает смарт-контракты со встроенной конфиденциальностью через свою RUSK VM. Средства заблокированы, условия проверяются, и обмен остаётся атомарным. Но детали транзакции — кто, как и сколько, какой актив — скрыты от всех, кроме участников. Конфиденциальность COD с гарантиями блокчейна.

Самокритика: Shopee COD работает потому, что если ноутбук окажется сломанным, я могу отказаться от получения, и курьер заберёт его обратно. Конфиденциальные транзакции в ончейне делают разрешение споров сложнее. Если я заявлю, что «цифровой товар» не был доставлен, но ZKP говорит, что транзакция была действительной, кто арбитр? Приватность также ограничивает доказательства, доступные для споров. Аналогия работает на счастливом пути, но рушится, когда что-то идёт не так.

$DUSK нужно оценивать не только по тому, насколько гладко он исполняет всё при идеальном исходе, а по тому, как его конфиденциальные смарт-контракты обрабатывают споры и исключения.

Кто-нибудь ещё использует COD, потому что не доверяете онлайн-платежам? Вы уже мыслите как пользователь блокчейна 😂 #dusk $BICO $HOME

Процентная ставка фиксируется, но что получает кредитор, если заемщик не погасит долг?

Представьте: вы размещаете 1 000 USDC в позиции с фиксированной ставкой и уже знаете ожидаемое погашение к моменту окончания срока. Звучит просто. Но есть один вопрос, который часто упускают из виду: если заемщик не может полностью расплатиться, какой актив на самом деле обеспечивает этот «фиксированный» доход?

На TermMax кредит — это не просто цифра APY. У каждого рынка с фиксированной ставкой есть долговой токен, залог, дата погашения и пороговые значения LTV. Позиция заемщика представлена токеном GT — ERC-721, который фиксирует долг и залог. Если LTV достигает порога LLTV, позицию можно ликвидировать.

Самое интересное начинается дальше. Если долг не удается полностью урегулировать, TermMax использует механизм физической поставки. Когда держатели FT погашаются через пул, они могут получить пропорциональное распределение как базового токена, так и залога — вместо того, чтобы автоматически получить все обратно в исходном активе.

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

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

Так что прежде чем смотреть на FT и спрашивать «какая доходность?», я бы задал еще один вопрос:

«В сценарии худшего случая чем именно мне будут возвращать?»

@TermMax #TermMax $ALPINE $CLO $ACE

Один торговец отправил ровно 10 миллионов VND, а затем написал: «Я отправил это по ошибке, пожалуйста, верните деньги мне».

Я продавал 400 USDT на P2P. Как только заказ был создан, я ждал, пока покупатель сделает оплату.

Затем мой счет в Vietcombank внезапно показал входящий перевод на 10 миллионов VND. Прежде чем я успел все проверить, покупатель написал:
«Бро, я случайно перевел 10 миллионов VND на твой счет. Пожалуйста, отправь их обратно на этот банковский счет.»
Они предоставили другой банковский счет — НЕ тот, что отображается в P2P-заказе.

Я остановился на 5 секунд и подумал:
Стоп. Мой заказ на 400 USDT стоил 10,08 миллиона VND. Покупатель отправил ровно 10 миллионов, не хватило 80K, и теперь утверждает, что это было ошибкой?

Это классическая мошенническая схема с «случайным переводом».

Если бы я вернул 10 миллионов VND на тот посторонний счет:
Я мог бы реально потерять 10 миллионов VND
Мои USDT все равно были бы в эскроу
Покупатель мог бы отменить заказ или подать апелляцию
В итоге я мог бы потерять все
Поэтому я НИЧЕГО не отправил обратно.

Я сделал скриншот всей переписки, сохранил банковский чек и сразу же открыл Апелляцию.

Служба поддержки Binance разобралась в течение 3 часов. Случай покупателя отклонили.

🔴 Кто-то говорит «Я отправил это по ошибке, пожалуйста, верните мне» → КРАСНЫЙ ФЛАГ
🔴 НИКОГДА не отправляйте деньги вне P2P-заказа/оплатного процесса
🟢 Сохраняйте все доказательства → Апелляция → пусть Binance разберется
🟢 Все платежи держите внутри Binance P2P
Если оглянуться назад, если бы я поспешил и вернул те деньги, мне, скорее всего, было бы сейчас очень плохо 😂

Кто-нибудь здесь сталкивался с этой схемой «случайного перевода»?

@Binance Vietnam
#BinanceP2PAnToan
$GPS $RED $STAR

КОГДА ЛИКВИДАЦИИ НЕДОСТАТОЧНО: КАК РАБОТАЕТ ФИЗИЧЕСКАЯ ДОСТАВКА TERMMAX

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

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

Вот здесь и важна физическая доставка.

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

Представьте долг на сумму 1 000 единиц. В обычных условиях обеспечение продается, чтобы восстановить стоимость для кредиторов. Но если можно эффективно ликвидировать только часть, принудительная передача остального в тонкий рынок может привести к еще худшему исполнению. Физическая доставка позволяет вместо этого передать оставшиеся активы держателям FT.

Преимущество очевидно: система не зависит исключительно от идеальных условий ликвидации.

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

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

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

@TermMax #TermMax $CYS $ONG $BMT

Я потратил 2 часа на сделку на 200 USDT, потому что покупатель «случайно» отправлял неправильные суммы

Эта ситуация испытывала мое терпение как ничто другое.

Я выставил 200 USDT на продажу. Покупатель создал ордер. Итого: 5,04 млн VND.

Первый перевод: 504 000 VND. Не хватило нуля. Покупатель сказал: «Извини, опечатка, я отправлю остальное».

Второй перевод: 4 500 000 VND. Итого получено: 5 004 000 VND. Все равно не хватает 36 000 VND. Покупатель сказал: «О, банк удержал комиссию, просто выпустите, пожалуйста».

Я сказал «нет». 5 004 000 — это не 5 040 000.

Третье сообщение от покупателя: «Ну давай, это же разница всего 36к. Не будь придирчивым».

Я остался непреклонен. Я написал: «Сумма в ордере — 5 040 000. Я выпущу только когда получу ровно 5 040 000».

Покупатель на 40 минут замолчал. Затем отправил третий перевод на 36 000 VND. И сразу же написал: «Готово. Выпускай сейчас.»

Я проверил. Итого получено: 5 040 000. Верно. Я выпустил.

Весь процесс занял 2 часа для сделки на 200 USDT.

Покупатель на самом деле пытался меня обмануть? Возможно, а возможно и нет. Но схема с несколькими небольшими переводами и «ошибками» — известный прием, чтобы запутать продавцов и заставить их выпустить до прихода полной суммы.

НЕ РАЗРЕШАЙТЕ выпускать, пока НЕ будет получена ТОЧНАЯ СУММА

«Это просто небольшая разница» — никогда не повод выпускать раньше

Сохраняйте спокойствие, четко укажите требуемую сумму и ждите

Если затягивается — подавайте Appeal, а не идите на компромисс

36 000 VND — это вообще ничто. Но если бы я выпустил после второго перевода, я бы отдал 200 USDT за 5 004 000 вместо 5 040 000.

И покупатель бы понял, что «случайное» недоплачивание работает.

Кто-то еще сталкивался с приемом «несколько небольших переводов»?

@Binance Vietnam #BinanceP2PAnToan $STAR $HEMI $ACE

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

Но что меня всегда беспокоило: в течение этих 2 недель аудиторам доступно ВСЁ. Каждая зарплата, каждый платеж поставщику, каждое значение по контракту клиента. Им нужно видеть всё, чтобы проверить, что цифры сходятся.

А что если бы они могли подтвердить «что цифры сходятся», не видя сами цифры?

Это уже не гипотетический вопрос. @Dusk использует доказательства с нулевым разглашением, чтобы реализовать ровно такую схему. Транзакция может доказать, что она корректна: что входные значения равны выходным, что соблюдены правила комплаенса — при этом не раскрывая проверяющей стороне реальные суммы или контрагентов. Аудитор может подтвердить «книги этой компании сбалансированы», не зная ни одну индивидуальную зарплату сотрудника.

Именно это Dusk называет «приватностью с возможностью аудита». Не приватностью, которая скрывает от регуляторов. А приватностью, которая удовлетворяет регуляторов, не раскрывая больше данных, чем необходимо.

Самокритика: аудиторы моей компании проверяют не только математику. Они ищут закономерности, аномалии — вещи, которые технически корректны, но при этом контекстно подозрительны. Например, одному и тому же поставщику многократно платят ровно 9 999 USD прямо чуть ниже порога в 10 000 для отчетности.

Проверка с нулевым разглашением подтверждает корректность, но может упустить контекст. ZKP может доказать «эта транзакция корректна», но не «эта совокупность корректных транзакций выглядит подозрительно». Комплаенс — это больше, чем математика.

$DUSK следует оценивать исходя из того, могут ли ее инструменты аудита с сохранением приватности обнаруживать подозрительные закономерности, а не просто подтверждать корректность отдельных транзакций.

Был ли у вашей компании аудит, во время которого вы мечтали, чтобы аудиторы могли проверить всё, не видя всего?

#dusk $GPS $TUT

Продал 500 USDT, а покупатель отправил деньги с чужого банковского счёта 😳

На прошлой неделе у меня был P2P-заказ на продажу 500 USDT. Покупатель отметил оплату как выполненную, и когда я проверил(а) банковское приложение, действительно пришло 12,6 миллиона VND. Настоящие деньги, настоящая транзакция.

Но затем я заметил(а) имя отправителя. Оно не совпадало с именем покупателя в заказе Binance. Вообще никак. Другая фамилия, всё другое.

Я сидел(а) и думал(а) минут пять, что делать. Деньги были реальными. Сумма была правильной. В какой-то момент хотелось просто выпустить монету и забыть.

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

Поэтому я не выпустил(а) монету. Я открыл(а) апелляцию и объяснил(а) Binance Support несоответствие имён. Они разобрались и всё решили.

Что я понял(а):

🔴 Пришедших денег НЕ достаточно. Имя отправителя ДОЛЖНО совпадать с именем покупателя в Binance KYC. 🟢 Если имена не совпадают — НЕ выпускайте. Сразу подавайте апелляцию. 🟢 Сделайте скриншоты всего: банковскую транзакцию, детали заказа, чат. 🟡 Платежи третьих лиц — один из самых распространённых P2P-рисков, о которых новые продавцы часто не задумываются.

То, что деньги «реальные», не значит, что деньги «чистые». Это две совершенно разные вещи.

Кто-то ещё сталкивался с несоответствием имени в P2P? Как вы это решили?

@Binance Vietnam #BinanceP2PAnToan $HEMI $APR $VELVET

В моём жилом доме есть товарищество собственников жилья. Каждый месяц каждая квартира платит взнос на содержание. Взамен мы получаем право голоса по решениям для здания: ставить ли новые лифты, перекрасить ли холл, нанимать ли новую охранную компанию. Чем регулярнее вы платите, тем серьёзнее учитывается ваш голос. Никто, кто не вносит взносы, не может решать, как тратятся общие ресурсы.
Эта структура почти напрямую соответствует тому, как сети Proof-of-Stake (доказательство доли) реализуют управление. Держатели токенов стейкают свои токены — это эквивалент оплаты взноса на содержание. Взамен они помогают валидировать транзакции, поддерживая работу сети, и получают возможность влиять на решения по протоколу через голосование по управлению.
@Dusk использует нативный $DUSK токен ровно для этого. Стаддеры участвуют в Succinct Attestation — механизме консенсуса сети, и их стейк напрямую повышает безопасность сети. Это не пассивный фарм доходности. Стаддеры активно участвуют в подтверждении блоков и поддержании детерминированной финальности. Награда даётся за реальную работу, а не за просто блокировку токенов и ожидание.
Самокритика: в моём доме у каждой квартиры один голос независимо от того, сколько она платит. На Dusk голосующие полномочия в управлении пропорциональны стейку. Это означает, что человек с существенно более крупным стейком имеет существенно более громкий голос. Аналогия со взносом на содержание здесь ломается: в здании семья в пентхаусе и семья в студии имеют равные права голоса. В модели управления с весом токенов пентхаус всегда выигрывает. Приводит ли это к лучшим решениям или лишь к более концентрированным — зависит целиком от того, насколько хорошо протокол распределяет стейк со временем.
#dusk следует оценивать не только по тому, сколько всего ценности залочено, но и по тому, насколько эффективно её механизм управления предотвращает превращение концентрации стейка в концентрацию решений.

$PORTAL $ACE

Ранней весной я открыл брокерский счёт в фирме по ценным бумагам в Районе 1. Я думал, что заполнение формы позволит мне сразу купить акции. На практике это заняло шесть рабочих дней. Они проверили мой документ, сверили мой адрес, проверили меня по чёрному списку и только потом активировали счёт. Когда я спросил, почему так долго, сотрудники сказали: "Положения Комиссии по ценным бумагам. Пройти через это должен каждый."

В обычной блокчейн-сети любой, у кого есть кошелёк, может купить токен мгновенно. Без KYC, без проверок. Это удобно, но для реальных ценных бумаг так работать не может, потому что закон требует, чтобы в торгах участвовали только проверенные инвесторы.

@Dusk embeds эту необходимость прямо в смарт-контракты через стандарт XSC, Confidential Security Contracts. Каждый выпущенный на Dusk security-токен несёт вместе с собой условия передачи: кто может покупать, кто может продавать, ограничения по юрисдикции, периоды блокировки. Программируемая комплаенс-проверка означает, что эти проверки не выполняются человеком, сидящим за столом, в течение шести дней. Код автоматически блокирует любые несоответствующие требованиям транзакции до того, как они будут выполнены.

Самокритика: автоматизированный код работает быстрее, чем человек-ревьюер, но человек более гибок, чем код. Брокерские сотрудники могли бы взять трубку и уточнить, когда мои документы были неоднозначны. Смарт-контракт знает только «валидно» или «невалидно». Законопослушный инвестор с опечаткой в своём KYC-имени может оказаться заблокированным полностью без возможности пересмотра пограничного случая — если только Dusk не построит механизм ручного оверрайда поверх автоматизированных правил.

$DUSK следует оценивать по тому, включает ли его программируемая комплаенс-проверка механизм ручного оверрайда в неоднозначных ситуациях, а не только по тому, сколько правил он может автоматизировать.
#dusk $H $HEMI