Направление 02 — Смарт-контракты и аудит

Контракт, который можно запускать
с реальными деньгами

Пишем смарт-контракты под конкретную бизнес-логику и проводим security review перед mainnet. Не шаблоны из GitHub — а код, который отражает вашу модель и проверен до того, как в него войдут реальные средства.

С чем приходят к нам

🔧

Нужна нестандартная логикаШаблонный ERC-20 не покрывает сценарий. Нужны кастомные роли, механика распределения, compliance-ограничения или многоуровневая логика взаимодействия контрактов.

😰

Страх перед mainnetКонтракт написан, но непонятно, насколько он безопасен. Запустить с реальными деньгами страшно — а что если там уязвимость, которую сразу не видно?

🏚️

Контракт от другого подрядчикаЕсть готовый код, но команда разошлась или доверия к архитектуре нет. Нужен честный review — что там внутри и можно ли это выводить на аудит.

🎯

Скоро аудит или листингПроект движется к публичному старту. Нужно пройти внешний аудит — и важно войти в него с подготовленным кодом, а не получить список из 20 Critical.

Не "написать контракт" — а сделать его рабочим

Безопасность — это часть разработки, а не отдельный этап после

Большинство уязвимостей в смарт-контрактах появляются не потому, что разработчик плохой. Они появляются потому, что архитектура не была продумана с учётом реальных attack vectors — а потом это вскрывается уже на аудите или, что хуже, на mainnet.

Мы начинаем с бизнес-логики: какие роли нужны, какие сценарии критичны, где риски пересечения прав и как должен работать контракт в граничных состояниях. После этого архитектура ложится в код — не наоборот.

Мы партнёры CertiK, поэтому контракт проектируется с учётом требований институционального аудита с первого дня. Это резко сокращает количество findings и время до запуска.

Что получает клиент

Смарт-контракт под конкретную бизнес-логику
Архитектура с учётом ролей, апгрейдов и сценариев обновления
Unit-тесты на критические сценарии и граничные случаи
Внутренний pre-audit: Critical / Major / Medium findings
Техническая документация по контракту и логике
Подготовка репозитория к внешнему аудиту
Сопровождение через партнёрский канал CertiK

Уязвимость в контракте — это не баг, это потеря денег и репутации

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

Ошибка в логике ролей — несанкционированный вывод средств
Reentrancy или некорректный расчёт — эксплойт на mainnet
Архитектурная ошибка на аудите — переписывание половины системы
Слабая безопасность — отказ инвесторов и листинговых платформ

Почему нас безопаснее брать, чем обычную dev-команду

01

Начинаем с архитектуры, не с кода

Прежде чем писать строчку Solidity, мы разбираем бизнес-логику: роли, сценарии, граничные состояния, зоны риска. Это предотвращает уязвимости на уровне проектирования.

02

Партнёрство с CertiK

Работаем с CertiK как авторизованные партнёры. Контракт проектируется под требования институционального аудита — а не переделывается перед ним с нуля.

03

Pre-audit до внешней проверки

Проводим внутренний аудит с реальным поиском уязвимостей — Critical / Major / Medium. Клиент входит во внешний аудит с подготовленным кодом и минимальным списком замечаний.

04

Реальные сложные проекты

DeFi-протоколы из 12 контрактов с Chainlink, security token с compliance-архитектурой, bytecode-оптимизация под CertiK. Не учебные задачи — а production-код.

05

Понятная документация

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

06

Не пропадаем после деплоя

Сопровождаем проект через аудит, помогаем закрывать findings, поддерживаем связь с командой внешних аудиторов. Работа не заканчивается на merge в main.

Закрытые проекты

Кейс 01

DeFi Lending Protocol — 12 контрактов, Chainlink, аудит без критических уязвимостей

Задача

Клиент обратился не за одним контрактом, а за полноценной 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. Клиент получил цельную протокольную систему с понятной архитектурой и документацией — и избежал сценария, когда аудит вскрывает архитектурные ошибки слишком поздно.

Кейс 02

Security Token ERC-1400 — whitelist, compliance-ограничения и корректная логика владения

Задача

Клиенту требовался не просто токен, а контрактная модель 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-логикой, а права участников были реализованы так, как требовала модель проекта.

Кто приходит с этой задачей

🚀

Founders перед запуском

Продукт готов, контракт написан — но страшно нажать деплой в mainnet без честной проверки безопасности и логики.

🏦

DeFi-команды

Нужна сложная on-chain система: lending, staking, treasury, governance — с правильной архитектурой взаимодействия модулей.

🔐

Проекты перед аудитом

Предстоит внешний аудит или листинг. Важно войти в него с подготовленным кодом, а не получить 30 findings и уйти на переписывание.

🔄

С контрактом от другой команды

Есть готовый код, но доверия к архитектуре нет. Нужен честный review — что там внутри и можно ли это запускать.

📜

Security token-проекты

Требуется compliance-логика, transfer restrictions и whitelist-механика — туда, где шаблонный токен не покрывает реальный сценарий.

🌐

Web3-проекты с нестандартной логикой

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

Ориентиры по стоимости

Стоимость зависит от сложности логики, числа контрактов и требований к безопасности. Ниже — ориентиры по типовым пакетам, с которых обычно начинается работа.

01

Базовый токен

от $900
  • ERC-20 или TON Jetton
  • Стандартная функциональность
  • Mint / Burn / Pause
  • Базовая админ-роль
  • Документация по контракту
  • Деплой в testnet
Обсудить
02

Токен + экосистема

от $4 500
  • Система из 3–10 контрактов
  • Vesting / Staking / Distribution
  • Treasury / Multisig
  • Governance-механика
  • Интеграции с DEX / oracle
  • Документация и тесты
  • Подготовка к mainnet
Обсудить
03

Security Token

от $6 000
  • ERC-1400 / ERC-3643
  • Whitelist и transfer restrictions
  • Ownership / investor logic
  • Compliance-ready архитектура
  • Интеграция с KYC-провайдером
  • Документация по контракту
  • Подготовка к аудиту
Обсудить
04

DeFi-протокол

от $8 000
  • Сложная бизнес-логика
  • Oracle-интеграции
  • Gas-оптимизация
  • Модульная архитектура контрактов
  • Unit-тесты и документация
  • Pre-audit проверка
  • Подготовка к mainnet
Обсудить
05

Audit-Ready Package

от $1 900
  • Внутренний pre-audit
  • Поиск и исправление Critical / Major / Medium
  • Рекомендации по архитектуре безопасности
  • Подготовка репозитория и документации
  • Сопровождение перед внешним аудитом
  • Снижение числа правок после проверки
Запросить review

Кто мы

Дмитрий

Backend / Architecture

Ксения

Blockchain / Product

Альберт

Backend / Smart contracts

7+
лет в разработке
Web3
SaaS / Fintech
СНГ+
клиенты из разных стран
High
нагрузка и надёжность

Мы занимаемся разработкой проектов где нельзя ошибаться. Платёжные системы, Web3, backend-сервисы, инфраструктура, автоматизация, проекты с высокой нагрузкой.

Мы не делаем массовые сайты и шаблонные решения. Работаем с задачами где важна стабильность, безопасность и возможность масштабирования.

  • нужно сделать нестандартную систему
  • нужно переделать архитектуру
  • нужен аудит перед запуском
  • нужно подготовить проект к росту
  • нужно реализовать сложную бизнес-логику
Обсудить задачу напрямую

Есть задача? Давайте разберём её

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