Пишем смарт-контракты под конкретную бизнес-логику и проводим security review перед mainnet. Не шаблоны из GitHub — а код, который отражает вашу модель и проверен до того, как в него войдут реальные средства.
Нужна нестандартная логикаШаблонный ERC-20 не покрывает сценарий. Нужны кастомные роли, механика распределения, compliance-ограничения или многоуровневая логика взаимодействия контрактов.
Страх перед mainnetКонтракт написан, но непонятно, насколько он безопасен. Запустить с реальными деньгами страшно — а что если там уязвимость, которую сразу не видно?
Контракт от другого подрядчикаЕсть готовый код, но команда разошлась или доверия к архитектуре нет. Нужен честный review — что там внутри и можно ли это выводить на аудит.
Скоро аудит или листингПроект движется к публичному старту. Нужно пройти внешний аудит — и важно войти в него с подготовленным кодом, а не получить список из 20 Critical.
Большинство уязвимостей в смарт-контрактах появляются не потому, что разработчик плохой. Они появляются потому, что архитектура не была продумана с учётом реальных attack vectors — а потом это вскрывается уже на аудите или, что хуже, на mainnet.
Мы начинаем с бизнес-логики: какие роли нужны, какие сценарии критичны, где риски пересечения прав и как должен работать контракт в граничных состояниях. После этого архитектура ложится в код — не наоборот.
Мы партнёры CertiK, поэтому контракт проектируется с учётом требований институционального аудита с первого дня. Это резко сокращает количество findings и время до запуска.
В смарт-контрактах нет "откатить и починить". После деплоя логика зафиксирована. Если архитектура содержит уязвимость — она будет использована. Цена ошибки здесь не технический долг, а прямые финансовые и репутационные потери.
Прежде чем писать строчку Solidity, мы разбираем бизнес-логику: роли, сценарии, граничные состояния, зоны риска. Это предотвращает уязвимости на уровне проектирования.
Работаем с CertiK как авторизованные партнёры. Контракт проектируется под требования институционального аудита — а не переделывается перед ним с нуля.
Проводим внутренний аудит с реальным поиском уязвимостей — Critical / Major / Medium. Клиент входит во внешний аудит с подготовленным кодом и минимальным списком замечаний.
DeFi-протоколы из 12 контрактов с Chainlink, security token с compliance-архитектурой, bytecode-оптимизация под CertiK. Не учебные задачи — а production-код.
Каждый контракт сопровождается документацией по функциям, логике и критическим ветками. Это нужно и аудиторам, и команде разработки, которая будет работать с кодом дальше.
Сопровождаем проект через аудит, помогаем закрывать findings, поддерживаем связь с командой внешних аудиторов. Работа не заканчивается на merge в main.
Клиент обратился не за одним контрактом, а за полноценной on-chain системой: lending / treasury / управление логикой протокола / интеграция с оракулами. Риск в таких проектах возникает на стыке модулей — когда отдельно каждая часть выглядит рабочей, но в связке открывает уязвимости. Запустить без серьёзной подготовки означало получить тяжёлый список findings на аудите и потерять темп разработки.
Начали с архитектуры: разложили бизнес-логику по модулям, определили зоны риска, роли, сценарии обновлений и контрактные зависимости. Спроектировали систему из 12 взаимосвязанных контрактов с полной интеграцией Chainlink. Покрыли ключевые сценарии unit-тестами, задокументировали критические ветки логики. Провели внутренний pre-audit с фокусом на пересечение ролей, некорректную последовательность вызовов, зависимости от внешних данных и точки злоупотребления. Устранили замечания до подачи на внешнюю проверку.
Solidity · Hardhat · Chainlink Oracle · UUPS Proxy · AccessControl · Lending Logic · Treasury Module · Unit Tests · Pre-Audit · CertiK Review
Внешняя проверка прошла без Critical. Клиент получил цельную протокольную систему с понятной архитектурой и документацией — и избежал сценария, когда аудит вскрывает архитектурные ошибки слишком поздно.
Клиенту требовался не просто токен, а контрактная модель security token с корректной логикой владения. Здесь ошибки опасны не только с точки зрения взлома — они опасны с точки зрения самой модели прав: токен может начать двигаться не по тем правилам, которые нужны бизнесу, платформе или юридической структуре. Стандартные шаблоны из open-source здесь не подходят.
Начали с анализа сценариев владения: кто может покупать токен, кто переводить, какие проверки обязательны до транзакции. Спроектировали архитектуру на базе ERC-1400 с transfer restrictions и whitelist, встроенными в саму систему. Реализовали проверку участников, ограничения по обращениям и связку с KYC/compliance-логикой. Провели внутренний аудит с фокусом на корректность бизнес-правил внутри контракта — не только на безопасность кода.
Solidity · ERC-1400 · ERC-3643 · Transfer Restrictions · Whitelist Mechanics · KYC Integration · Compliance Architecture · Role Management · Pre-Audit
Клиент получил рабочий инструмент с корректной логикой доступа и transfer restrictions — а не технический токен с формальными ограничениями. Безопасность сочеталась с compliance-логикой, а права участников были реализованы так, как требовала модель проекта.
Продукт готов, контракт написан — но страшно нажать деплой в mainnet без честной проверки безопасности и логики.
Нужна сложная on-chain система: lending, staking, treasury, governance — с правильной архитектурой взаимодействия модулей.
Предстоит внешний аудит или листинг. Важно войти в него с подготовленным кодом, а не получить 30 findings и уйти на переписывание.
Есть готовый код, но доверия к архитектуре нет. Нужен честный review — что там внутри и можно ли это запускать.
Требуется compliance-логика, transfer restrictions и whitelist-механика — туда, где шаблонный токен не покрывает реальный сценарий.
Задача не вписывается в готовые шаблоны. Нужна кастомная архитектура под конкретный бизнес-сценарий с реальными деньгами внутри.
Стоимость зависит от сложности логики, числа контрактов и требований к безопасности. Ниже — ориентиры по типовым пакетам, с которых обычно начинается работа.
Backend / Architecture
Blockchain / Product
Backend / Smart contracts
Мы занимаемся разработкой проектов где нельзя ошибаться. Платёжные системы, Web3, backend-сервисы, инфраструктура, автоматизация, проекты с высокой нагрузкой.
Мы не делаем массовые сайты и шаблонные решения. Работаем с задачами где важна стабильность, безопасность и возможность масштабирования.
Расскажите что происходит — мы скажем можем ли помочь и как это выглядит по деньгам и срокам. Без обязательств.