Skip to main content

inSure DeFi (inSure Token)

inSure DeFi (inSure Token / SURE) — справочная карточка криптопроекта: что делает продукт и насколько проверяемы ключевые утверждения проекта; также — соответствие тезису Decentralized AI (DecAI Fit).

inSure DeFi — DeFi проект (механика “community-based insurance”), который предлагает “страхование” крипто‑портфеля/депозитов через community vaults и голосование держателей токена. Токен: SURE (ERC‑20 на Ethereum; также заявлены адреса на других EVM‑сетях).

Дисклеймер

Важно: эта страница — справочный разбор проекта. В рамках DecAIHub отдельно фиксируется проверка сведений из открытых источников по AI‑тезису (что реально AI/onchain/зачем токен и на каких источниках это основано).
Это не является финансовой рекомендацией и не является советом покупать/продавать/держать актив. Мы не оцениваем цену, доходность, тайминг входа/выхода.
Выводы основаны на публично доступных материалах, обнаруженных на дату проверки. Отсутствие подтверждения не означает отсутствие технологии.

TL;DR (для тех, кто не про ИИ)

  • Что это: “комьюнити‑страховка” для крипто‑портфелей (заявлены сценарии scams/devaluation/stolen funds).
  • Для кого: держатели крипто‑активов, которые хотят покрытие рисков по правилам сообщества.
  • Зачем ончейн/токен: SURE нужен, чтобы включить полис (вклад в vault), голосовать по claim’ам и участвовать в пулах/стейкинге.

Как это работает (очень кратко)

  1. Пользователь делает: покупает SURE и включает coverage через Dashboard; после 7 дней “contributing SURE to the community vault” полис активируется.
  2. Система делает: при страховом событии пользователь создаёт claim; проходит расследование и голосование сообщества (Snapshot); при одобрении инициируется транзакция выплаты из community vault.
  3. Пользователь получает: выплату SURE из vault в рамках выбранного плана (по правилам белой книги).
  4. Где блокчейн: токен SURE и vault‑адреса в EVM‑сетях; выплаты — ончейн переводы из vault.
  5. Роль токена (если есть): членство/вклад в risk pool, voting power, единица выплат и стейкинг‑механики.

Быстрые ссылки: AI‑соответствие

Паспорт проекта

Поле Значение
Название проекта inSure DeFi (inSure Token)
Также известен как (aliases) inSure; inSureDAO; SURE
Лого (logo) ../assets/138_insure_logo.svg
Символ токена (ticker) SURE
Категория DeFi
Основная сеть (chain) Ethereum
Тип EVM
Статус сети mainnet
Консенсус (consensus) PoS (Ethereum)
Дата запуска (launch_date) —
Статус проекта (status) active
Токен (стандарт) ERC-20
Контракт токена 0xcb86c6a22cb56b6cf40cafedb06ba0df188a416e
Модель токена (token_type) utility (staking + governance)
Макс. предложение 88,000,000,000 SURE (totalSupply в исходнике контракта)
Эмиссия fixed supply (по исходнику контракта)
Токеномика (tokenomics, кратко) insurance включается после 7 дней вклада в vault; ~70% SURE заблокировано в community vaults (whitepaper)
Управление Snapshot voting + Gnosis Safe (описано в whitepaper)
Админы/ключи —
Аудит —
Bug bounty —
Команда (team) —
Финансирование (investors/funding) —
AI‑компонент (ai_component) —
Use‑case (use_case) community insurance for crypto portfolios
DecAI Fit — AI‑соответствие (AI thesis fit) 0/6 — нет AI reality и нет AI intent (ai_score=0)
Итог по компонентам DecAI Fit 0 / 1 / 2 / 2
Last verified 2026-02-05
Тип Ссылка
Website https://insuretoken.net/
Docs https://insuretoken.net/whitepaper.html
GitHub https://github.com/inSureToken/SmartContract/blob/master/inSure.sol
Releases / Changelog —
Whitepaper https://insuretoken.net/whitepaper.html
Roadmap https://insuretoken.net/roadmap.html
Security advisories —
Explorer https://etherscan.io/token/0xcb86c6a22cb56b6cf40cafedb06ba0df188a416e
X https://twitter.com/InsureToken
Discord —
Telegram https://t.me/insuretoken
Medium https://insureteam.medium.com
Audit report(s) —
Bug bounty —
CoinGecko (профиль, справочно) https://www.coingecko.com/en/coins/insure
CoinMarketCap (профиль, справочно) https://coinmarketcap.com/currencies/insure/

Общее описание проекта

inSure DeFi в Tier‑1 whitepaper описывает себя как “community‑based decentralized insurance ecosystem”, где “полис” включается через владение/вклад токена SURE в community vaults. Сценарии покрытий в whitepaper включают: scams (социнженерия/мошенничество), drastic devaluation и stolen funds при закрытии биржи (по правилам, описанным в FAQ).

Критично: механизм принятия решений о выплатах в белой книге описан как offchain‑голосование (Snapshot) + последующая onchain‑транзакция выплат из vault (через Gnosis Safe и “Community Safe Signers”).

Фичи/модули

  • Dashboard (enable coverage): включение страхового плана после вклада SURE в community vault.
  • Claims flow: тикет → расследование → голосование на Snapshot → выплата из vault.
  • Community vaults (multi‑chain): адреса vault по сетям (Ethereum/BSC/Polygon/Avalanche и др. на странице контрактов).
  • Staking через LP: в whitepaper заявлен стейкинг через DEX liquidity pools.

Типичные сценарии

  • Сценарий 1 (покупка/активация): пользователь покупает SURE → включает план через Dashboard → через 7 дней coverage активна.
  • Сценарий 2 (claim): пользователь фиксирует страховой случай → создаёт claim на Snapshot → сообщество голосует → при одобрении получает выплату SURE.
  • Сценарий 3 (участник DAO): держит SURE → голосует по claim’ам → участвует в управлении community vaults.

Как начать (кошелёк/сеть)

  • Что нужно: EVM‑кошелёк (например, MetaMask) и SURE; для claim’а требуется приватный кошелёк (в whitepaper просят не держать SURE на CEX).
  • Сеть/chain: SURE есть на Ethereum и ряде EVM‑сетей (адреса на странице “SURE Smart Contract Details”).
  • Комиссии: gas выбранной сети при переводах/голосованиях/взаимодействии с vault/DEX.

Архитектура/техника (без AI)

  • Компоненты: ERC‑20 SURE + bridge/обёртки в других EVM‑сетях; community vaults; offchain управление через Snapshot; исполнение транзакций через Safe.
  • Роли участников: держатели SURE (voters), claimants, community safe signers.
  • Где выполняется логика: голосование/оценка claim’ов — offchain; выплаты и хранение vault — onchain.
  • Зависимости: Snapshot, Safe (Gnosis Safe), EVM‑сети и DEX‑пулы для LP‑стейкинга.

Токен/экономика (развернуто, без прогнозов)

  • Утилити токена: включение страховых планов, voting power, участие в LP‑стейкинге, единица выплат.
  • Источники необходимости в протоколе: без владения/вклада SURE coverage не активируется; claim’ы голосуются держателями SURE.
  • Кто платит комиссии: пользователи/участники при ончейн действиях (gas) и при торговле SURE (DEX/CEX).
  • Куда идут комиссии: в whitepaper описан риск‑пул и buyback логика “surplus funds … used to rebuy SURE”, но без детальной onchain спецификации.
  • Эмиссия/сжигание: в репозитории смарт‑контракта зафиксирован totalSupply; модель инфляции/эмиссии в whitepaper не описана.
  • Механизмы безопасности/стимулов: vaults + голосование; ограничения “insurance enabled after 7 days”; критерии eligibility для claim’ов описаны в FAQ.
  • Распределение и график выпуска токенов: — (в Tier‑1 whitepaper нет таблицы распределения/вестинга).
  • Казначейство: community vaults по сетям; средства unlock’аются решением сообщества (Snapshot → Safe).

Управление

  • Кто принимает решения: держатели SURE через Snapshot + “Community Safe Signers” в Safe.
  • Как меняются параметры протокола: решения по claim’ам/разблокировке средств принимаются голосованием; далее транзакция создаётся/подписывается в Safe.
  • Где обсуждают/принимают решения: Snapshot (создание claim’ов) и комьюнити‑каналы.
  • Ключи/мультисиг: в whitepaper описано правило большинства подписантов (пример: 11/21).

Безопасность и инциденты

  • Аудиты: — (в доступных Tier‑1 ссылках отчётов аудита не найдено).
  • Bug bounty: —.
  • Инциденты: —.
  • Модель угроз: риски централизации/сговора при голосовании, риски ошибок в offchain‑процессе расследования, риски админ‑ошибок/компрометации подписантов Safe.

Статус проекта и таймлайн

  • Текущий статус: активен (whitepaper и сайт описывают работающий процесс claim’ов/планов).
  • Ключевые релизы/вехи: —.
  • Roadmap: есть на сайте (см. links).

Экосистема/интеграции

  • Интеграции: Snapshot, Safe, Uniswap/PancakeSwap и др. DEX (перечислены на странице wallets), мультичейн‑адреса SURE.
  • Партнёры: —.
  • Где реально используется: claims‑flow и планы описаны в whitepaper; публичных постмортемов/реестра кейсов в Tier‑1 источниках нет.

Ai составляющая проекта

  • Что здесь реально ИИ? AI‑компонента нет (в Tier‑1 источниках не заявлен AI intent).
  • Что реально onchain? токен SURE и vault‑адреса по сетям; выплаты из vault — ончейн переводы.
  • Зачем нужен токен? активация плана/вклад в risk pool, голосование по claim’ам и единица выплат.
  • Красные флаги (по найденной информации): AI‑washing отсутствует (ai_score=0). Риски: governance‑washing (решения по claim’ам зависят от offchain голосования), security‑risk (роль подписантов Safe, отсутствие аудитов в Tier‑1).

Итог по компонентам DecAI Fit

  • DecAI Fit: 0/6 — нет AI reality и нет AI intent (ai_score=0)
Компонент Уровень Score
AI reality нет 0
Onchain necessity низко 1
Token necessity средне 2
Evidence Tier‑1 есть (не по AI) 2
Подробнее

AI reality

AI_0 — намерения про AI (roadmap Tier‑1) (1/0)

  • AI_0 (decision): 0
  • Claim (1 строка): Tier‑1 намерений про AI нет.
  • Evidence: Tier‑1 — https://insuretoken.net/whitepaper.html
  • Why sufficient / why not (1 строка): whitepaper описывает DeFi‑страхование без AI‑компонентов.
  • Conflict note (если есть): —.

AI_1 — что делает ИИ (1/0)

  • AI_1 (decision): 0
  • Claim (1 строка): AI‑логики нет.
  • Evidence: Tier‑1 — https://insuretoken.net/whitepaper.html
  • Why sufficient / why not (1 строка): отсутствует описание AI‑функций.
  • Conflict note (если есть): —.

AI_2 — демо/примеры (1/0)

  • AI_2 (decision): 0
  • Claim (1 строка): не применимо (AI нет).
  • Evidence: Tier‑1 — https://insuretoken.net/whitepaper.html
  • Why sufficient / why not (1 строка): —.
  • Conflict note (если есть): —.

AI_3 — метрики/качество (1/0)

  • AI_3 (decision): 0
  • Метрики: —.
  • Контекст (версия/дата/на чём мерили): —.
  • Evidence: Tier‑1 — https://insuretoken.net/whitepaper.html
  • Why sufficient / why not (1 строка): —.
  • Conflict note (если есть): —.

AI_4 — техописание/архитектура/версии (1/0)

  • AI_4 (decision): 0
  • Claim (1 строка): не применимо (AI нет).
  • Evidence: Tier‑1 — https://insuretoken.net/whitepaper.html
  • Why sufficient / why not (1 строка): —.
  • Conflict note (если есть): —.

Onchain necessity

OC_1 — контракты/адреса/сеть (1/0)

  • OC_1 (decision): 1
  • Сеть: Ethereum (основная по ссылкам)
  • Адреса/идентификаторы: ERC‑20 0xcb86c6a22cb56b6cf40cafedb06ba0df188a416e; также указаны адреса в BSC/Polygon/Avalanche/Q Network.
  • Evidence: Tier‑1 — https://insuretoken.net/wallets.html#smart_contracts
  • Why sufficient / why not (1 строка): есть публичные onchain адреса токена по сетям.
  • Conflict note (если есть): —.

OC_2 — onchain не только токен (1/0)

  • OC_2 (decision): 0
  • Какая полезная логика onchain: в Tier‑1 источниках не представлено явных смарт‑контрактов “страхового протокола” (логика решений в основном описана как Snapshot + Safe), помимо токена/хранилищ.
  • Evidence: Tier‑1 — https://insuretoken.net/whitepaper.html
  • Why sufficient / why not (1 строка): процесс выплат описан, но без onchain протокольных контрактов кроме токена/vault.
  • Conflict note (если есть): —.

OC_3 — onchain критичен (1/0)

  • OC_3 (decision): 0
  • Тест “замены блокчейна”: без блокчейна исчезает прозрачность переводов, но сам процесс решения claim’ов описан как offchain и мог бы существовать централизованно.
  • Evidence: Tier‑1 — https://insuretoken.net/whitepaper.html
  • Why sufficient / why not (1 строка): критичность onchain для продукта не доказана.
  • Conflict note (если есть): —.

Token necessity

TK_0 — токена нет (1/0)

  • TK_0 (decision): 0
  • Claim (1 строка): у проекта есть токен SURE.
  • Evidence: Tier‑1 — https://insuretoken.net/wallets.html#smart_contracts
  • Why sufficient / why not (1 строка): адреса токена опубликованы.
  • Conflict note (если есть): —.

TK_1..TK_4 (1/0)

TK_1 — платёж за сервис (1/0)

  • TK_1 (decision): 1
  • Claim (1 строка): для включения insurance plan требуется приобрести/внести SURE в community vault.
  • Evidence: Tier‑1 — https://insuretoken.net/whitepaper.html
  • Why sufficient / why not (1 строка): whitepaper явно описывает “Acquire SURE tokens” и включение coverage через вклад в vault.
  • Conflict note (если есть): —.

TK_2 — стимулы/залоги/штрафы (1/0)

  • TK_2 (decision): 1
  • Claim (1 строка): токены в vault формируют risk pool для выплат; есть стейкинг через LP и механики вознаграждения (APR упомянут).
  • Evidence: Tier‑1 — https://insuretoken.net/whitepaper.html
  • Why sufficient / why not (1 строка): описана связь vault и выплат, а также staking через LP.
  • Conflict note (если есть): —.

TK_3 — управление (1/0)

  • TK_3 (decision): 1
  • Claim (1 строка): держатели SURE голосуют по страховым claim’ам (“Anyone who holds SURE can vote…”).
  • Evidence: Tier‑1 — https://insuretoken.net/whitepaper.html
  • Why sufficient / why not (1 строка): governance‑роль описана напрямую.
  • Conflict note (если есть): —.

TK_4 — токен заменим (1/0)

  • TK_4 (decision): 1
  • Claim (1 строка): экономически модель могла бы работать на стейбл‑коллатерале/подписке; SURE в whitepaper выполняет роль членства/учёта и валюты выплат.
  • Evidence: Tier‑1 — https://insuretoken.net/whitepaper.html
  • Why sufficient / why not (1 строка): в Tier‑1 нет уникальной функции токена, которую нельзя заменить иным платежным инструментом (кроме принятой в проекте модели).
  • Conflict note (если есть): —.

Evidence (таблица)

Tier Источник Что доказывает
Tier‑1 https://insuretoken.net/whitepaper.html механика: acquire SURE → claim → payout; голосование держателей SURE; описание community vaults/процесса
Tier‑1 https://insuretoken.net/wallets.html#smart_contracts onchain адреса SURE по сетям (ERC‑20/BSC/Polygon/Avalanche/Q)
Tier‑1 https://github.com/inSureToken/SmartContract/blob/master/inSure.sol исходник токена (в т.ч. totalSupply в коде)

No comments to display

Back to top