К основному содержанию
T TON Adoption
← Словарь
NODE/03 · Term

TonProof

Расширение протокола TON Connect 2.0 для криптографической верификации владения кошельком. Используется как Sign-in with TON: dApp проверяет подпись приватного ключа от nonce-сообщения, выпущенного сервером.

Синонимы: ton proof, ton-proof, sign in with ton

TonProof — стандарт криптографического доказательства владения TON-кошельком, реализованный поверх TON Connect 2.0. Решает проблему «как сервер dApp узнаёт, что подключённый адрес принадлежит реальному владельцу, а не просто заявителю».

Зачем нужен

Базовый TON Connect 2.0 при подключении возвращает приложению адрес кошелька и публичный ключ. Этих данных достаточно, чтобы построить UI и отправлять транзакции на подтверждение, но не достаточно для аутентификации: любой клиент может предоставить чужой адрес. Сервер dApp не может отличить владельца от наблюдателя.

TonProof закрывает разрыв: dApp просит кошелёк подписать сообщение с nonce от сервера, и сервер верифицирует подпись приватным ключом владельца. Это превращает TON Connect в полноценную систему Sign-in.

Что подписывается

Структура сообщения по схеме v2:

  • Префикс ton-proof-item-v2/
  • Адрес кошелька (workchain + hash)
  • Длина домена + сам домен dApp
  • Timestamp
  • Payload (= серверный nonce)

Затем хэш с дополнительным префиксом ton-connect подписывается ed25519-ключом кошелька.

Защита от replay-атак

Nonce — одноразовая строка (32 байта). После успешного verify сервер заносит её в blacklist и больше не принимает. Это блокирует возможность переиспользовать перехваченную подпись для входа от чужого имени.

Где применяется

  • DeFi-протоколы и NFT-маркетплейсы для login (вместо email/password)
  • Mini Apps в Telegram, требующие аутентификации пользователя
  • Backend-сервисы, которые ассоциируют действия с конкретным wallet-аккаунтом

Что не делает

TonProof доказывает только владение в момент подписи. Если пользователь потерял доступ к ключу после login и кто-то ещё получил ключ — TonProof не отличит нового владельца от прежнего. Дополнительные слои (timeout сессии, refresh tokens) остаются на стороне dApp.

См. также