Skip to main content

Lossless

Lossless (LSS) — 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).

Lossless — a Security / DeFi / Infra project: a protocol and products (Lossless Protocol, Aegis) that add a security layer for transactions and smart contracts, including detection/monitoring, freezing of suspicious transactions and an investigation/fund recovery process (per the website and the official documentation). The LSS token is an ERC‑20 on Ethereum.

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: a protocol/toolset for protecting tokens/contracts: monitoring and “hack mitigation” (freeze/investigation/recovery).
  • Who it’s for: token/protocol teams (integrating protection), white‑hat hackers/“finders” and stakers (participating in detection/freezing), DeFi users (indirectly).
  • Why onchain/token: onchain is needed to execute the freeze/staking/voting mechanics; LSS is used for staking/finders and for participation in protocol processes (per the docs/CMC).

How it works (very briefly)

  1. The user does: a project integrates Lossless (for example, the LERC‑20 extension) or uses Aegis/monitoring; “finders”/stakers track events and report suspicious addresses.
  2. The system does: upon suspicion of a hack/exploit, the protocol initiates a temporary freeze and starts a verification process; then — an extended freeze and a resolution/reversal procedure (described in the whitepaper/tech docs).
  3. The user gets: prevention/reduction of losses and (ideally) recovery of funds; for “finders”/stakers — rewards (per the documentation).
  4. Where the blockchain is: the LSS token, staking/controllers/protocol contracts and the freeze are executed onchain (Ethereum and supported networks).
  5. Token role (if any): LSS is used for staking/participation in “hack spotting” processes and governance mechanisms (per the whitepaper/docs).

Quick links: AI thesis fit

Project passport

Field Value
Project name Lossless
Also known as (aliases) LSS; Lossless Protocol; Lossless Aegis; LERC‑20
Logo (logo) ../assets/386_lossless_logo.png
Token symbol (ticker) LSS
Category Security | DeFi | Infra
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 0x3b9be07d622accaed78f479bc0edabfd6397e320
Token model (token_type) utility (staking + governance)
Max supply 100,000,000 LSS (Etherscan)
Issuance fixed (per max supply)
Tokenomics (tokenomics, brief) finders stake LSS to freeze; the stake can be confiscated upon a false report (Tier‑1 whitepaper)
Governance “committee voting” / governance contracts (per the docs)
Admins/keys —
Audit yes (official Audits page in the docs)
Bug bounty yes (Immunefi)
Team (team) —
Funding (investors/funding) —
AI component (ai_component) monitoring/threat detection (no ML metrics)
Use‑case (use_case) exploit mitigation (freeze + investigation)
DecAI Fit — AI thesis fit 3/6 — medium alignment with the Decentralized AI thesis
DecAI Fit component summary 1 / 3 / 2 / 3
Last verified 2026-02-11

General project overview

Lossless is building a “hack mitigation” layer for Web3: the project offers a protocol and tools that make it possible to monitor and stop (freeze) suspicious/malicious transactions, then carry out a verification and, if the incident is confirmed, continue the freeze and fund recovery/return procedure. The protocol documentation describes the LERC‑20 extension, the “finders” reporting and staking process, the committee/voting and the smart contracts. The website highlights the products: Lossless Protocol (platform), Aegis (monitoring), Vault Protection, Token Minter, etc.

Features/modules

  • Lossless Protocol (exploit mitigation: freeze + investigation/resolution process).
  • LERC‑20 standard/extension of ERC‑20 (integration into tokens).
  • Aegis (proactive threat monitoring and protection).
  • The “finders” community model (stake and rewards for detection/freezing).
  • Governance/committee voting (the decision‑making mechanism for incidents).

Typical scenarios

  • Scenario 1: a token team implements Lossless/LERC‑20 → gains the ability to freeze/reverse malicious transactions following the protocol process.
  • Scenario 2: a “finder” tracks onchain events → stakes LSS and initiates a freeze → receives a reward when the incident is confirmed (per the whitepaper).
  • Scenario 3: a project connects Aegis monitoring → receives alerts/protection for mission‑critical contracts (per the website).

Getting started (wallet/network)

  • What you need: an EVM wallet (MetaMask) for operations with LSS/staking; for integration — a developer and access to the documentation.
  • Network/chain: Ethereum (the LSS token); the protocol claims support for several networks (per the website).
  • Fees: network fees (gas) on the respective network when staking/interacting with the contracts.

Architecture/tech (non‑AI)

  • Components: protocol smart contracts (controller/governance/reporting/staking, etc.); the LERC‑20 extension; offchain monitoring/analytics tools; the UI platform.
  • Participant roles: token creators (integration), “finders”/white‑hats (reporting/freezing), the committee/voters, the protocol team.
  • Where logic runs: the critical freeze/staking/voting logic — onchain; monitoring/analytics/alerts — offchain.
  • Dependencies: Ethereum/EVM networks, RPC, monitoring infrastructure; token integrations.

Token/economics (expanded, no forecasts)

  • Token utility: participation in “hack spotting” and protocol processes (stake/voting), as well as incentives/rewards.
  • Protocol necessity drivers: per the whitepaper, “finders” stake LSS to freeze an address; upon a false trigger the stake can be confiscated — this is an economic mechanism against spam/false reports.
  • Who pays fees: participants interacting with the contracts (finders, stakers, projects).
  • Where fees go: network fees — to the network validators; the distribution of protocol fees is described in the whitepaper (percentages for finders/stakers/committee/company).
  • Issuance/burn: fixed max supply of 100M LSS.
  • Security/incentive mechanisms: staking LSS for the right to initiate a freeze; confiscation of the stake if the report is rejected; rewards upon confirmation (whitepaper).
  • Distribution and token issuance schedule: — (no Tier‑1 source found in links_*).
  • Treasury: — (not recorded).

Governance

  • Who makes decisions: the committee/governance participants + the company/token creator within “three party decision making” (whitepaper).
  • How protocol parameters change: via governance contracts/procedures (details — in the docs).
  • Where decisions are discussed/made: the documentation and GitHub repositories (links_*).
  • Keys/multisig: — (not established per Tier‑1 sources).

Security and incidents

  • Audits: yes (official Audits page in the docs, PDF).
  • Bug bounty: yes (Immunefi).
  • Incidents: — (no Tier‑1 confirmation found).
  • Threat model: assumes the possibility of false/malicious reports — hence the use of stake/confiscation; a trusted investigation and voting procedure (whitepaper).

Project status and timeline

  • Current status: mainnet (the products are available via web interfaces).
  • Key releases/milestones: — (not recorded in this card).
  • Roadmap: published in the Lossless blog (see links_*).

Ecosystem/integrations

  • Integrations: supported networks (Tier‑1 website): Ethereum, Arbitrum, Polygon, BNB Smart Chain, Avalanche, Fantom, Harmony, Elysium, Arthera.
  • Partners: — (not recorded in this card).
  • Where it’s actually used: the Lossless Protocol / Aegis web products are available via the links from the website (see links_*).

AI component of the project

  • What is real AI here? In Tier‑1 sources the project is primarily about onchain security and mitigation; “Aegis” is described as threat monitoring, but the public docs contain no clear metrics/description of ML models — so we assess the AI component cautiously.
  • What is truly onchain? the protocol contracts (staking/reporting/governance/controller) and the LSS token on Ethereum; the freeze/staking/voting mechanics.
  • Why is a token needed? LSS is used as a stake for initiating freezes and for participation/incentives in the hack detection process (whitepaper/docs).
  • Red flags (based on the information found): AI‑washing — “AI” in the tag/marketing without metrics; what to double‑check — the presence/description of models in Aegis and their quality; onchain/token‑washing — low risk (the mechanics are in the whitepaper).

DecAI Fit component summary

  • DecAI Fit: 3/6 — medium alignment with the Decentralized AI thesis
Component Level Score
AI reality low 1
Onchain necessity high 3
Token necessity medium 2
Evidence Tier‑1 present 3
Details

AI reality

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

  • AI_0 (decision): 1
  • Claim (one line): Aegis is positioned as a “threat monitoring / smart contract defence” tool.
  • Evidence: Tier‑1 — https://lossless.io
  • Why sufficient / why not (one line): this is a statement about monitoring, but without a description of models/metrics.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 0
  • Claim (one line): the presence of ML/AI models for detection is not confirmed in the tech documentation (in the available Tier‑1).
  • Evidence: Tier‑1 — https://docs.lossless.io/protocol
  • Why sufficient / why not (one line): the docs describe the hack‑mitigation process and mechanisms, but do not record a specific AI stack/metrics.
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 0
  • Claim (one line): a demo/example specifically of “AI detection” is not singled out as a verifiable artifact.
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): the cases in the whitepaper relate to the protocol logic/monitoring, but not to reproducible AI metrics.
  • Conflict note (if any): —

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 0
  • Metrics: —
  • Context (version/date/how measured): —
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): metrics of the AI component are not published in the available Tier‑1 sources.
  • Conflict note (if any): —

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

  • AI_4 (decision): 0
  • Claim (one line): the architecture of the security protocol is publicly described, but not the architecture of AI/ML models.
  • Evidence: Tier‑1 — https://docs.lossless.io/protocol
  • Why sufficient / why not (one line): this is not a tech description of the AI part.
  • Conflict note (if any): —

Onchain necessity

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

  • OC_1 (decision): 1
  • Chain: Ethereum
  • Addresses/identifiers: LSS token: 0x3b9be07d622accaed78f479bc0edabfd6397e320
  • Evidence: Tier‑1 — https://etherscan.io/token/0x3b9be07d622accaed78f479bc0edabfd6397e320
  • Why sufficient / why not (one line): the token/address and basic onchain parameters are verifiable via Etherscan.
  • Conflict note (if any): —

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

  • OC_2 (decision): 1
  • What useful logic is onchain: the freeze/staking/voting mechanics and the hack mitigation processes are implemented via the protocol smart contracts.
  • Evidence: Tier‑1 — https://docs.lossless.io/protocol
  • Why sufficient / why not (one line): the docs describe the onchain process (freeze, staking, committee voting).
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 1
  • “Replace the blockchain” test: without onchain it is impossible to reliably freeze/reverse transactions and to perform staking/voting in a trust‑minimized model.
  • Evidence: Tier‑1 — https://docs.lossless.io/protocol
  • Why sufficient / why not (one line): the key value of Lossless is the onchain enforcement of the mitigation mechanics.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): the project has a token, LSS (ERC‑20).
  • Evidence: Tier‑1 — https://etherscan.io/token/0x3b9be07d622accaed78f479bc0edabfd6397e320
  • Why sufficient / why not (one line): the token is confirmed by the explorer.
  • Conflict note (if any): —

TK_1..TK_4 (1/0)

TK_1 — payment for the service (1/0)

  • TK_1 (decision): 0
  • Claim (one line): direct “pay‑per‑use” in LSS is not confirmed as mandatory in the available Tier‑1.
  • Evidence: Tier‑1 — https://docs.lossless.io/protocol
  • Why sufficient / why not (one line): the whitepaper is more about staking/committee/rewards than about paying for the service with LSS.
  • Conflict note (if any): —

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

  • TK_2 (decision): 1
  • Claim (one line): finders stake LSS to initiate a freeze; if the report is rejected, the stake can be confiscated; upon confirmation — rewards.
  • Evidence: Tier‑1 — https://docs.lossless.io/protocol
  • Why sufficient / why not (one line): this is the key incentive mechanism of the protocol.
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 1
  • Claim (one line): LSS is used for participation in governance/committee processes (including “committee voting”).
  • Evidence: Tier‑1 — https://docs.lossless.io/protocol
  • Why sufficient / why not (one line): governance and the role of token holders are described in the documentation/whitepaper.
  • Conflict note (if any): —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 0
  • Claim (one line): the token serves as collateral/incentive, and a simple “replacement” with offchain points/bonuses would worsen verifiability and economic security.
  • Evidence: Tier‑1 — https://docs.lossless.io/protocol
  • Why sufficient / why not (one line): staking/confiscation/rewards are tied to the token and the onchain process.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://lossless.io product showcase: Lossless Protocol, Aegis, LERC‑20, “freeze suspicious transactions”
Tier‑1 https://docs.lossless.io/protocol whitepaper/documentation: the hack mitigation process, finders staking, committee/governance
Tier‑1 https://docs.lossless.io/protocol/technical-reference/hack-mitigation-protocol/audits existence of an audits page and a link to the audit PDF
Tier‑1 https://immunefi.com/bug-bounty/lossless/ existence of a bug bounty and in-scope contracts
Tier‑1 https://etherscan.io/token/0x3b9be07d622accaed78f479bc0edabfd6397e320 the LSS token, network and max supply
Tier‑1 https://github.com/Lossless-Cash public repositories of the protocol/SDK
Tier‑2 https://coinmarketcap.com/currencies/lossless/ aggregator profile/market context and a brief description

No comments to display

Back to top