Ситуация для тех, кто не следил за происходящим.

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

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

Теперь самое интересное.

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

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

В любой компании, которая работает с деньгами пользователей, существует управление рисками. Перед каждым релизом проводится анализ рисков, составляется документация по потенциальным сценариям отказа, оцениваются последствия каждого из них и проектируются защитные механизмы. Это не какая-то "фишка" крупных компаний — это инженерная база для любого финансового продукта.

После этого архитектура строится по принципу fail-safe: один сбой не должен превращаться в катастрофу.

Если ломается логика баланса — должны сработать лимиты на вывод.

Если лимиты не срабатывают — должны включиться системы обнаружения аномальной активности.

Если и они не срабатывают — должны существовать аварийные механизмы, позволяющие мгновенно остановить вывод средств.

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

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

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

Утверждать, что это было сделано намеренно, без доказательств нельзя. Но если описанная схема действительно работала именно так, то произошедшее говорит об очень серьезном провале в проектировании и управлении рисками. И это, на мой взгляд, гораздо страшнее самого бага.
_________
@bitjam