Skip to main content

inSure DeFi (inSure Token)

inSure DeFi (inSure Token / SURE) — a reference card for a crypto project: what the product does and how verifiable the project’s key claims are; also — alignment with the Decentralized AI thesis (DecAI Fit).

inSure DeFi — a DeFi project (a “community-based insurance” mechanic) that offers “insurance” of a crypto portfolio/deposits via community vaults and voting by token holders. Token: SURE (ERC‑20 on Ethereum; addresses on other EVM networks are also claimed).

Disclaimer

Important: this page is a reference overview of the project. Within DecAIHub, we separately record a verification based on open sources within the AI thesis (what is real AI/onchain/why a token, and which sources this is based on).
This is not financial advice and not a recommendation to buy/sell/hold any asset. We do not assess price, returns, or entry/exit timing.
Conclusions are based on publicly available materials found as of the verification date. The absence of confirmation does not imply the absence of the technology.

TL;DR (for readers who are not into AI)

  • What it is: “community insurance” for crypto portfolios (claimed scenarios: scams/devaluation/stolen funds).
  • Who it’s for: holders of crypto assets who want risk coverage under community rules.
  • Why onchain/token: SURE is needed to enable a policy (a contribution to the vault), to vote on claims and to participate in pools/staking.

How it works (very briefly)

  1. The user does: buys SURE and enables coverage via the Dashboard; after 7 days of “contributing SURE to the community vault” the policy is activated.
  2. The system does: upon an insured event, the user creates a claim; an investigation and a community vote (Snapshot) take place; upon approval, a payout transaction from the community vault is initiated.
  3. The user gets: a payout of SURE from the vault within the chosen plan (per the whitepaper rules).
  4. Where the blockchain is: the SURE token and vault addresses on EVM networks; payouts are onchain transfers from the vault.
  5. Token role (if any): membership/contribution to the risk pool, voting power, the unit of payouts and staking mechanics.

Quick links: AI thesis fit

Project passport

Field Value
Project name inSure DeFi (inSure Token)
Also known as (aliases) inSure; inSureDAO; SURE
Logo (logo) ../assets/138_insure_logo.svg
Token symbol (ticker) SURE
Category DeFi
Primary chain (chain) Ethereum
Type EVM
Network status mainnet
Consensus (consensus) PoS (Ethereum)
Launch date (launch_date) —
Project status (status) active
Token (standard) ERC-20
Token contract 0xcb86c6a22cb56b6cf40cafedb06ba0df188a416e
Token model (token_type) utility (staking + governance)
Max supply 88,000,000,000 SURE (totalSupply in the contract source)
Issuance fixed supply (per the contract source)
Tokenomics (tokenomics, brief) insurance is enabled after 7 days of contribution to the vault; ~70% of SURE is locked in community vaults (whitepaper)
Governance Snapshot voting + Gnosis Safe (described in the whitepaper)
Admins/keys —
Audit —
Bug bounty —
Team (team) —
Funding (investors/funding) —
AI component (ai_component) —
Use‑case (use_case) community insurance for crypto portfolios
DecAI Fit — AI thesis fit 0/6 — no AI reality and no AI intent (ai_score=0)
DecAI Fit component summary 0 / 1 / 2 / 2
Last verified 2026-02-05

General project overview

In the Tier‑1 whitepaper, inSure DeFi describes itself as a “community‑based decentralized insurance ecosystem”, where a “policy” is enabled through holding/contributing the SURE token to community vaults. The coverage scenarios in the whitepaper include: scams (social engineering/fraud), drastic devaluation and stolen funds upon an exchange shutdown (under the rules described in the FAQ).

Critically: the decision‑making mechanism for payouts is described in the whitepaper as offchain voting (Snapshot) + a subsequent onchain payout transaction from the vault (via Gnosis Safe and the “Community Safe Signers”).

Features/modules

  • Dashboard (enable coverage): enabling an insurance plan after contributing SURE to the community vault.
  • Claims flow: ticket → investigation → vote on Snapshot → payout from the vault.
  • Community vaults (multi‑chain): vault addresses by network (Ethereum/BSC/Polygon/Avalanche, etc. on the contracts page).
  • Staking via LP: the whitepaper claims staking via DEX liquidity pools.

Typical scenarios

  • Scenario 1 (purchase/activation): the user buys SURE → enables a plan via the Dashboard → after 7 days the coverage is active.
  • Scenario 2 (claim): the user records an insured event → creates a claim on Snapshot → the community votes → upon approval receives a payout of SURE.
  • Scenario 3 (DAO member): holds SURE → votes on claims → participates in the governance of the community vaults.

Getting started (wallet/network)

  • What you need: an EVM wallet (e.g., MetaMask) and SURE; a claim requires a private wallet (the whitepaper asks not to hold SURE on a CEX).
  • Network/chain: SURE is available on Ethereum and a number of EVM networks (addresses on the “SURE Smart Contract Details” page).
  • Fees: gas of the chosen network for transfers/votes/interaction with the vault/DEX.

Architecture/tech (non‑AI)

  • Components: ERC‑20 SURE + bridges/wrappers on other EVM networks; community vaults; offchain governance via Snapshot; transaction execution via Safe.
  • Participant roles: SURE holders (voters), claimants, community safe signers.
  • Where logic runs: voting/assessment of claims — offchain; payouts and vault custody — onchain.
  • Dependencies: Snapshot, Safe (Gnosis Safe), EVM networks and DEX pools for LP staking.

Token/economics (expanded, no forecasts)

  • Token utility: enabling insurance plans, voting power, participation in LP staking, the unit of payouts.
  • Protocol necessity drivers: without holding/contributing SURE, coverage is not activated; claims are voted on by SURE holders.
  • Who pays fees: users/participants for onchain actions (gas) and when trading SURE (DEX/CEX).
  • Where fees go: the whitepaper describes a risk pool and a buyback logic “surplus funds … used to rebuy SURE”, but without a detailed onchain specification.
  • Issuance/burn: the smart contract repository records the totalSupply; the inflation/issuance model is not described in the whitepaper.
  • Security/incentive mechanisms: vaults + voting; the “insurance enabled after 7 days” restriction; eligibility criteria for claims are described in the FAQ.
  • Distribution and token issuance schedule: — (the Tier‑1 whitepaper contains no distribution/vesting table).
  • Treasury: community vaults by network; funds are unlocked by community decision (Snapshot → Safe).

Governance

  • Who makes decisions: SURE holders via Snapshot + the “Community Safe Signers” in Safe.
  • How protocol parameters change: decisions on claims/unlocking of funds are made by vote; then a transaction is created/signed in Safe.
  • Where decisions are discussed/made: Snapshot (creation of claims) and community channels.
  • Keys/multisig: the whitepaper describes a majority-of-signers rule (example: 11/21).

Security and incidents

  • Audits: — (no audit reports were found in the available Tier‑1 links).
  • Bug bounty: —.
  • Incidents: —.
  • Threat model: risks of centralization/collusion in voting, risks of errors in the offchain investigation process, risks of admin errors/compromise of Safe signers.

Project status and timeline

  • Current status: active (the whitepaper and the website describe a working process of claims/plans).
  • Key releases/milestones: —.
  • Roadmap: available on the website (see links).

Ecosystem/integrations

  • Integrations: Snapshot, Safe, Uniswap/PancakeSwap and other DEXs (listed on the wallets page), multichain addresses of SURE.
  • Partners: —.
  • Where it’s actually used: the claims flow and plans are described in the whitepaper; there are no public postmortems/a registry of cases in Tier‑1 sources.

AI component of the project

  • What is real AI here? there is no AI component (no AI intent is claimed in Tier‑1 sources).
  • What is truly onchain? the SURE token and vault addresses by network; payouts from the vault are onchain transfers.
  • Why is a token needed? plan activation/contribution to the risk pool, voting on claims and the unit of payouts.
  • Red flags (based on the information found): AI‑washing is absent (ai_score=0). Risks: governance‑washing (decisions on claims depend on offchain voting), security‑risk (the role of Safe signers, the absence of audits in Tier‑1).

DecAI Fit component summary

  • DecAI Fit: 0/6 — no AI reality and no AI intent (ai_score=0)
Component Level Score
AI reality absent 0
Onchain necessity low 1
Token necessity medium 2
Evidence Tier‑1 present (not for AI) 2
Details

AI reality

AI_0 — AI intent (Tier‑1 roadmap) (1/0)

  • AI_0 (decision): 0
  • Claim (one line): there are no Tier‑1 intentions about AI.
  • Evidence: Tier‑1 — https://insuretoken.net/whitepaper.html
  • Why sufficient / why not (one line): the whitepaper describes DeFi insurance without AI components.
  • Conflict note (if any): —.

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 0
  • Claim (one line): there is no AI logic.
  • Evidence: Tier‑1 — https://insuretoken.net/whitepaper.html
  • Why sufficient / why not (one line): there is no description of AI functions.
  • Conflict note (if any): —.

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 0
  • Claim (one line): not applicable (no AI).
  • Evidence: Tier‑1 — https://insuretoken.net/whitepaper.html
  • Why sufficient / why not (one line): —.
  • Conflict note (if any): —.

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 0
  • Metrics: —.
  • Context (version/date/how measured): —.
  • Evidence: Tier‑1 — https://insuretoken.net/whitepaper.html
  • Why sufficient / why not (one line): —.
  • Conflict note (if any): —.

AI_4 — tech description/architecture/versions (1/0)

  • AI_4 (decision): 0
  • Claim (one line): not applicable (no AI).
  • Evidence: Tier‑1 — https://insuretoken.net/whitepaper.html
  • Why sufficient / why not (one line): —.
  • Conflict note (if any): —.

Onchain necessity

OC_1 — contracts/addresses/chain (1/0)

  • OC_1 (decision): 1
  • Chain: Ethereum (primary per the links)
  • Addresses/identifiers: ERC‑20 0xcb86c6a22cb56b6cf40cafedb06ba0df188a416e; addresses on BSC/Polygon/Avalanche/Q Network are also listed.
  • Evidence: Tier‑1 — https://insuretoken.net/wallets.html#smart_contracts
  • Why sufficient / why not (one line): there are public onchain addresses of the token by network.
  • Conflict note (if any): —.

OC_2 — onchain beyond just a token (1/0)

  • OC_2 (decision): 0
  • What useful logic is onchain: Tier‑1 sources present no explicit smart contracts of an “insurance protocol” (the decision logic is mostly described as Snapshot + Safe) besides the token/vaults.
  • Evidence: Tier‑1 — https://insuretoken.net/whitepaper.html
  • Why sufficient / why not (one line): the payout process is described, but without onchain protocol contracts other than the token/vault.
  • Conflict note (if any): —.

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 0
  • “Replace the blockchain” test: without the blockchain the transparency of transfers disappears, but the claim decision process itself is described as offchain and could exist in a centralized way.
  • Evidence: Tier‑1 — https://insuretoken.net/whitepaper.html
  • Why sufficient / why not (one line): the criticality of onchain for the product is not proven.
  • Conflict note (if any): —.

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): the project has a token, SURE.
  • Evidence: Tier‑1 — https://insuretoken.net/wallets.html#smart_contracts
  • Why sufficient / why not (one line): the token addresses are published.
  • Conflict note (if any): —.

TK_1..TK_4 (1/0)

TK_1 — payment for the service (1/0)

  • TK_1 (decision): 1
  • Claim (one line): enabling an insurance plan requires acquiring/contributing SURE to the community vault.
  • Evidence: Tier‑1 — https://insuretoken.net/whitepaper.html
  • Why sufficient / why not (one line): the whitepaper explicitly describes “Acquire SURE tokens” and enabling coverage via a contribution to the vault.
  • Conflict note (if any): —.

TK_2 — incentives/collateral/penalties (1/0)

  • TK_2 (decision): 1
  • Claim (one line): the tokens in the vault form the risk pool for payouts; there is staking via LP and reward mechanics (an APR is mentioned).
  • Evidence: Tier‑1 — https://insuretoken.net/whitepaper.html
  • Why sufficient / why not (one line): the link between the vault and payouts is described, as well as staking via LP.
  • Conflict note (if any): —.

TK_3 — governance (1/0)

  • TK_3 (decision): 1
  • Claim (one line): SURE holders vote on insurance claims (“Anyone who holds SURE can vote…”).
  • Evidence: Tier‑1 — https://insuretoken.net/whitepaper.html
  • Why sufficient / why not (one line): the governance role is described directly.
  • Conflict note (if any): —.

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 1
  • Claim (one line): economically, the model could run on stable collateral/a subscription; in the whitepaper, SURE plays the role of membership/accounting and the payout currency.
  • Evidence: Tier‑1 — https://insuretoken.net/whitepaper.html
  • Why sufficient / why not (one line): Tier‑1 contains no unique token function that could not be replaced by another payment instrument (apart from the model adopted by the project).
  • Conflict note (if any): —.

Evidence (table)

Tier Source What it proves
Tier‑1 https://insuretoken.net/whitepaper.html the mechanics: acquire SURE → claim → payout; voting by SURE holders; a description of the community vaults/process
Tier‑1 https://insuretoken.net/wallets.html#smart_contracts onchain addresses of SURE by network (ERC‑20/BSC/Polygon/Avalanche/Q)
Tier‑1 https://github.com/inSureToken/SmartContract/blob/master/inSure.sol the token source code (including totalSupply in the code)

No comments to display

Back to top