SBT и цифровые удостоверения

Soulbound Tokens (SBT) — это непередаваемые токены, используемые для цифровых удостоверений, сертификатов и репутационных систем. В экосистеме TON SBT применяются для подтверждения KYC, членства в DAO и образовательных достижений. Понимание SBT важно для проектирования систем, где идентичность и достижение должны быть привязаны к конкретному пользователю без возможности перепродажи.

NFT по стандарту TEP-62 можно свободно передавать между кошельками. Но некоторые токены не должны быть передаваемыми: дипломы, сертификаты, членство, репутационные баллы. Для таких случаев TON использует Soulbound Tokens (SBT) по стандарту TEP-85.

Что такое SBT?

Soulbound Token — это NFT, который привязан к кошельку владельца навсегда. Его нельзя передать, продать или обменять. SBT подтверждает факт: “этот кошелёк прошёл курс”, “этот кошелёк — участник DAO”, “этот кошелёк имеет KYC-верификацию”.

TEP-85 расширяет стандарт TEP-62 (NFT) тремя ключевыми изменениями:

Архитектура SBT

SBT использует ту же модель Collection + Item, что и NFT:

SBT Item: состояние

Ключевое отличие: transfer запрещён

Когда кто-то пытается вызвать transfer на SBT Item, контракт отклоняет сообщение. Это не баг — это фундаментальное свойство:

User A (owner)          SBT Item #42
  |                         |
  |-- transfer(User B) ---->|
  |                         | REJECT! SBT is non-transferable
  |<-- bounced message -----|
  |                         |

SBT не может быть:

• Передан другому кошельку
• Продан на маркетплейсе
• Обменян в DEX

Authority и отзыв (Revocation)

Authority — это адрес (обычно издатель SBT), который имеет право отозвать токен. Отзыв не удаляет SBT — он устанавливает revoked_at timestamp:

Authority (Issuer)      SBT Item #42
  |                         |
  |-- revoke() ------------>|
  |                         | revoked_at = 1710000000
  |<-- excesses ------------|
  |                         |

После отзыва SBT остаётся в блокчейне, но считается недействительным. Любой может проверить статус через get-метод.

Зачем нужен отзыв?

• Диплом: университет отзывает диплом при обнаружении плагиата
• Членство: DAO отзывает членство при нарушении правил
• Лицензия: регулятор отзывает лицензию при нарушениях
• KYC: провайдер отзывает верификацию при обнаружении фрода

Проверка SBT (Verification)

Как проверить, что конкретный кошелёк владеет действительным SBT?

Off-chain верификация

1. Вычислить адрес SBT Item: hash(code + init(index, collection))
2. Вызвать get_nft_data() на SBT Item
3. Проверить owner == expected_wallet
4. Проверить revoked_at == 0 (не отозван)

On-chain верификация

Смарт-контракт может проверить SBT, отправив запрос к SBT Item и обработав ответ:

1. Контракт вычисляет адрес SBT Item по известным index и collection
2. Отправляет prove_ownership сообщение
3. SBT Item отвечает ownership_proof с подтверждением
4. Контракт обрабатывает ответ и разрешает/запрещает действие

Примеры использования

Сертификаты об обучении

Образовательная платформа выдаёт SBT при завершении курса:

• Collection: “Platform Certificates”
• Item content: название курса, дата завершения, оценка
• Authority: платформа (может отозвать при обнаружении мошенничества)

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

Membership DAO

DAO выдаёт SBT для голосования:

• Collection: “DAO Membership”
• Item content: роль, дата вступления
• Authority: governance-контракт (может отозвать при исключении)

Контракт голосования проверяет наличие действительного SBT перед принятием голоса.

KYC-верификация

KYC-провайдер выдаёт SBT после верификации:

• Collection: “KYC Verified”
• Item content: уровень верификации (без персональных данных!)
• Authority: провайдер (может отозвать)

DeFi-протоколы проверяют наличие KYC SBT перед допуском к определённым операциям.

Реализация SBT в Tact

Основное отличие от NFT — переопределение transfer:

contract SbtItem {
    index: Int as uint32;
    collection: Address;
    owner: Address;
    authority: Address;
    revoked_at: Int as uint64;
    content: Cell;

    init(index: Int, collection: Address) {
        self.index = index;
        self.collection = collection;
        self.owner = newAddress(0, 0);  // Set during deploy
        self.authority = newAddress(0, 0);
        self.revoked_at = 0;
        self.content = emptyCell();
    }

    // Transfer is DISABLED for SBT
    receive(msg: NftTransfer) {
        // SBT cannot be transferred -- reject with error
        require(false, "SBT: transfer not allowed");
    }

    // Only authority can revoke
    receive("Revoke") {
        let ctx: Context = context();
        require(ctx.sender == self.authority, "Not authority");
        require(self.revoked_at == 0, "Already revoked");
        self.revoked_at = now();
    }

    // Prove ownership for on-chain verification
    receive(msg: ProveOwnership) {
        let ctx: Context = context();
        require(ctx.sender == self.owner, "Not owner");
        send(SendParameters{
            to: msg.dest,
            value: 0,
            mode: 64,  // carry remaining value
            body: OwnershipProof{
                index: self.index,
                owner: self.owner,
                revoked_at: self.revoked_at,
            }.toCell(),
        });
    }
}

SBT vs NFT: когда что использовать?

Правило: если токен должен быть привязан к личности и не должен торговаться — используйте SBT.

Частые ошибки

1. Реализуют SBT как обычный NFT, просто запрещая transfer, хотя стандарт SBT в TON имеет специфические методы (prove_ownership, request_owner) для верификации.
2. Не предусматривают механизм revoke (отзыв): SBT-сертификат должен иметь возможность аннулирования при необходимости.
3. Забывают о privacy: SBT on-chain видим всем, что может быть нежелательно для KYC-данных — нужно хранить только хеш данных, а не сами данные.
4. Не реализуют authority-проверку при выпуске: без неё любой может создать поддельный SBT от имени вашего контракта.