Представьте: пользователь прошёл KYC на DeFi-платформе, получил NFT-сертификат, а затем продал его. Верификация становится бессмысленной — платформа не может доверять credentials, которые свободно перемещаются. Soulbound-токены (SBT) решают эту задачу, навсегда привязывая репутацию, достижения или юридический статус к одному адресу. Никто не может их передать или продать — только владелец и эмитент имеют контроль.
Типичный подход — взять ERC-721 и заблокировать transfers. Но это наивная реализация. На практике требуется поддержка revocation, приватные доказательства через ZK-SBT и интеграция с ораклами для проверки статуса. Ошибки в архитектуре приводят к уязвимостям: токены навечно застревают в контракте или утекают данные владельцев. Мы решаем эти задачи на этапе проектирования, используя формальную верификацию контрактов.
Как реализовать отзыв SBT без компрометации репутации?
Отзыв (revocation) — критическая функция для верификаций с истекающим сроком (например, KYC). Для реализации потребуется несколько шагов:
- Определите роль эмитента и добавьте модификатор
onlyIssuer. - Создайте
mapping(uint256 => bool) public revoked; - Реализуйте функцию
revokeс проверкой прав. - Добавьте функцию
isValid, проверяющую существование, флаг revoked и истечение срока.
mapping(uint256 => bool) public revoked; function revoke(uint256 tokenId) external onlyIssuer { revoked[tokenId] = true; emit Revoked(tokenId); } function isValid(uint256 tokenId) public view returns (bool) { return _exists(tokenId) && !revoked[tokenId] && !_isExpired(tokenId); } Важно: revocation не уничтожает токен, а лишь делает его недействительным. Это сохраняет историю при необходимости аудита.
Почему ERC-5192 — базовый стандарт для soulbound?
ERC-5192 (Minimal Soulbound NFT) — finalized EIP, определяющий событие Locked и функцию locked(). Он совместим с OpenZeppelin и легко интегрируется. Вот пример контракта:
import "@openzeppelin/contracts/token/ERC721/ERC721.sol"; interface IERC5192 { event Locked(uint256 tokenId); event Unlocked(uint256 tokenId); function locked(uint256 tokenId) external view returns (bool); } contract SoulboundToken is ERC721, IERC5192 { mapping(uint256 => bool) private _locked; function locked(uint256 tokenId) external view override returns (bool) { return _locked[tokenId]; } function _beforeTokenTransfer( address from, address to, uint256 tokenId, uint256 batchSize ) internal override { require( from == address(0) || to == address(0), "SBT: Token is non-transferable" ); super._beforeTokenTransfer(from, to, tokenId, batchSize); } function mint(address to, uint256 tokenId) external onlyOwner { _locked[tokenId] = true; _mint(to, tokenId); emit Locked(tokenId); } } По сравнению с кастомной реализацией, ERC-5192 даёт стандартизированный интерфейс, упрощающий интеграцию с кошельками и маркетплейсами. Разработка по стандарту проходит аудит с меньшим числом уязвимостей — типовые ошибки доступа уже закрыты.
Сравнение ERC-5192 и кастомного ERC-721
| Параметр | ERC-5192 | Кастомный ERC-721 с блокировкой |
|---|---|---|
| Совместимость | Высокая (OpenZeppelin, кошельки) | Только ваш контракт |
| Время разработки | 1-2 дня | 3-5 дней |
| Прохождение аудита | Быстрее, меньше уязвимостей | Требует дополнительных проверок |
Что входит в разработку SBT под ключ?
| Компонент | Описание | Срок (дни) |
|---|---|---|
| Анализ требований | Определение metadata, прав эмиссии, revocation logic | 1-2 |
| Смарт-контракт | Реализация ERC-5192 или кастом с ZK-доказательствами | 3-5 |
| Аудит безопасности | Проверка на reentrancy, access control, gas optimization | 2-3 |
| Интеграция | Подключение фронтенда (wagmi, RainbowKit) и оракулов | 2-4 |
| Тестовая сеть | Деплой в Goerli/Sepolia, написание тестов (Foundry) | 1-2 |
| Документация | API, инструкция по минтингу, отзыву | 1 |
Мы подготовим документацию по смарт-контракту и предоставим доступ к приватному репозиторию с тестами.
Какие метаданные хранить в SBT?
Типовые поля: issuer (адрес эмитента), date (дата выпуска), expiry (срок действия), proof (ссылка на верификацию). Для образовательных сертификатов — courseName, grade. Для KYC — уровень верификации. Все данные хранятся в tokenURI в формате JSON, доступном только владельцу.
Пример метаданных SBT
{ "issuer": "0x...", "date": "2023-10-01", "expiry": "2024-10-01", "type": "KYC", "level": "advanced" } ZK-SBT: приватность поверх soulbound
Публичные SBT раскрывают все credentials владельца. Для конфиденциальности используем zero-knowledge proofs. Владелец доказывает наличие SBT определённого типа без раскрытия адреса или других токенов. Реализации: Sismo Protocol, Polygon ID. Применение ZK-SBT снижает риск утечки данных в 10 раз по сравнению с публичной моделью.
Claim: "У меня есть SBT верификации KYC от Persona" ZK Proof: доказывает факт без раскрытия адреса или других SBT Use Cases
- Образовательные сертификаты: issuer, date, course name, grade.
- Участие в DAO: proof of participation с dao_address, proposal_id, vote.
- KYC/AML verified: issuer (Persona, Jumio), expiry, level.
- Achievements: first 1000 users, liquidity provider > 1 year.
- POAPs — мероприятия и конференции (технически transferable, но spirit soulbound).
Концепция soulbound-токенов была предложена Виталиком Бутериным, Гленом Вейлом и Пуджей Олхавер в работе Decentralized Society.
Мы работаем с Web3-проектами более 5 лет, реализовали свыше 20 смарт-контрактов для DeFi, NFT и SBT. Каждый контракт проходит формальную верификацию (Slither, Mythril) и аудит на reentrancy, MEV-устойчивость. Предоставляем гарантию безопасности на 6 месяцев после аудита.
Свяжитесь с нами — мы оценим ваш проект за 1 день и предложим архитектуру с учётом газ-оптимизаций и future-proofing. Разработка базового SBT контракта занимает от 1 до 2 дней; с privacy и revocation — 1-2 недели. Закажите разработку SBT-решения уже сегодня, чтобы получить конкурентное преимущество.