Skip to main content

AgentLISA

AgentLISA (LISA) — 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).

AgentLISA — an AI/Security / Infra project (an AI platform for security analysis of smart contracts and “agent economy” transactions), token (symbol: LISA) on BNB Smart Chain.

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 service that uses AI to “scan” smart contracts/transactions and returns vulnerability analysis results.
  • Who it’s for: Web3 contract developers, protocol teams and security researchers.
  • Why onchain/token: $LISA is used as the payment token for the platform’s services and as an incentive mechanism (bug bounty/curation/governance) within the ecosystem.
  • What you can actually touch (Tier‑1): public scan results (Public Scans): https://agentlisa.ai/scans/public

How it works (very briefly)

  1. The user does: uploads code or selects a contract for analysis (per the whitepaper: direct scanning deployed contracts).
  2. The system does: runs a “multi‑agent” analysis (a set of specialized agents for vulnerability classes) and produces a report.
  3. The user gets: results (vulnerabilities/risks) and can integrate the checks into CI (GitHub Actions) or an IDE.
  4. Where the blockchain is: the LISA token as BEP‑20 on BSC; the analysis itself is an offchain service.
  5. Token role: payment for scans/subscriptions and incentivizing security activities (bug bounty/curation/governance) per the whitepaper.

Quick links: AI thesis fit

Project passport

Field Value
Project name AgentLISA
Also known as (aliases) LISA, $LISA
Logo (logo) ../assets/196_agentlisa_logo.svg
Token symbol (ticker) LISA
Category AI/Security | Infra
Primary chain (chain) BNB Smart Chain
Type EVM
Network status mainnet
Consensus (consensus) PoSA (BNB Smart Chain; 21 validators)
Launch date (launch_date) 2025-12-18 (TGE date, per the whitepaper)
Project status (status) active
Token (standard) BEP-20
Token contract 0x0AA9D742A1e3C4Ad2947eBbf268aFA15D7c9bFBd
Token model (token_type) utility (governance)
Max supply 1,000,000,000 LISA (per the whitepaper and BscScan)
Issuance fixed
Tokenomics (tokenomics, brief) payments for services; bug bounty/curation; governance; initial circulating supply 216.2M (per the whitepaper)
Governance governance via the token is claimed (per the whitepaper)
Admins/keys —
Audit —
Bug bounty it is claimed that $LISA is used for bug bounty programs (per the whitepaper)
Team (team) —
Funding (investors/funding) Series A $12M (per the whitepaper)
AI component (ai_component) multi-agent LLM security analyzer
Use‑case (use_case) smart contract vulnerability scanning
DecAI Fit — AI thesis fit 3/6 — medium alignment with the Decentralized AI thesis
DecAI Fit component summary 3 / 1 / 3 / 2
Last verified 2026-02-11

General project overview

Per the whitepaper, AgentLISA is an “AI‑powered smart contract security platform” for the autonomous “agent economy”, where security must be “continuous, programmable, real-time”. The document describes the product directions: an AI auditor (multi‑chain), PaymentShield for x402/auto‑payments, wallet security monitoring, as well as the LISA‑Bench dataset/benchmark and the CARL self‑learning loop.

Features/modules

  • Agentic Auditor: multi‑agent analysis of smart contracts (agents for reentrancy, access control, price manipulation, etc.).
  • PaymentShield: described in the whitepaper as a security layer for autonomous payments/x402.
  • Wallet Health Check: monitoring of approvals/compromises/alerts.
  • LISA‑Bench + CARL: a vulnerability dataset and the “Continuous Auditing and Retraining Loop” cycle (per the whitepaper).

Typical scenarios

  • Scenario 1: a team deploys a contract → runs a scan/audit on the platform → receives a list of vulnerabilities/risks.
  • Scenario 2: a team connects GitHub Actions/IDE plugins → gets “security gates” on commits (per the whitepaper).
  • Scenario 3: a researcher participates in a bug bounty → receives payouts/incentives in $LISA (per the whitepaper: bug bounty programs).

Getting started (wallet/network)

  • What you need: web access to AgentLISA (public scans) / an account; for the token — an EVM wallet for BSC.
  • Network/chain: BNB Smart Chain (LISA token).
  • Fees: BSC gas (if interacting with the token) + payment for services/subscriptions (per the whitepaper: payments for services).

Architecture/tech (non‑AI)

  • Components (whitepaper): the scanning web platform, IDE/GitHub Actions integrations, API/integration with x402; offchain AI analysis; a token for the economic layer.
  • Where logic runs: AI vulnerability analysis — offchain; onchain — the token and its utility/governance.

Token/economics (expanded, no forecasts)

Per the whitepaper (“The $LISA Token Economy”):

  • Total supply: 1,000,000,000 $LISA; TGE date: 2025‑12‑18; initial circulating: 216,200,000 (21.62%).
  • Utilities: payment for services; funding bug bounties; community validation/curation (with slashing); ecosystem development; governance.

Governance

  • Governance: the whitepaper explicitly states that $LISA holders participate in governance (platform parameters/bounties/treasury allocation).

Security and incidents

  • Bug bounty: described in the whitepaper as a token utility/ecosystem mechanic (payouts in $LISA and an optional stake for prioritization).
  • Audits/incidents: no public Tier‑1 links to an audit of the token/platform contracts are recorded in this card.

Project status and timeline

  • Current status: the website/public scans are available; the LISA token exists as BEP‑20 on BSC.
  • Roadmap: see the whitepaper (Q4 2025 token launch; 2026 roadmap).

Ecosystem/integrations

  • Integrations (whitepaper): IDE plugins (VSCode/Cursor), GitHub Actions, x402 protocol, “direct scanning” of deployed contracts.

AI component of the project

  • What is real AI here? Per the whitepaper: a multi‑agent architecture (specialized agents for vulnerability classes) and a “TrustLLM” foundation + CARL self‑evolution for improving the model/platform.
  • What is truly onchain? The LISA token on BSC (BEP‑20); the analysis itself is offchain.
  • Why is a token needed? Per the whitepaper: payments for scans/subscriptions, bug bounties, curation/slashing, ecosystem rewards, governance.
  • Red flags (based on the information found): “100% accuracy” and other quantitative claims of the whitepaper require independent external verification; the onchain part is mostly about the token economy, not about onchain inference/verification.

DecAI Fit component summary

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

AI reality

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

  • AI_0 (decision): 0
  • Claim (one line): AI is described as the core of the product (agentic auditor), not as “plans to introduce AI”.
  • Evidence: Tier‑1 — https://agentlisa.ai/whitepaper
  • Why sufficient / why not (one line): the whitepaper describes the current platform and the agent framework.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 1
  • Claim (one line): AI agents analyze contracts and detect vulnerability classes (reentrancy, access control, price manipulation, etc.).
  • Evidence: Tier‑1 — https://agentlisa.ai/whitepaper
  • Why sufficient / why not (one line): the whitepaper describes the “Specialized Agent Framework” and the purpose of the platform.
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 1
  • Claim (one line): there are public scan results (“Public Scans”) as a demonstration of the analyzer at work.
  • Evidence: Tier‑1 — https://agentlisa.ai/scans/public
  • Why sufficient / why not (one line): this is an observable artifact of the product at work (public reports/scans).
  • Conflict note (if any): —

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 0
  • Metrics: “100% accuracy on production audits” (a marketing claim).
  • Context (version/date/how measured): the methodology/dataset/accuracy metric are not formalized in the whitepaper as a verifiable benchmark.
  • Evidence: Tier‑1 — https://agentlisa.ai/whitepaper
  • Why sufficient / why not (one line): quantitative metrics are not provided in a verifiable form.
  • Conflict note (if any): —

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

  • AI_4 (decision): 1
  • Claim (one line): the multi‑agent framework, the TrustLLM foundation and the CARL feedback loop are described, as well as the LISA‑Bench dataset.
  • Evidence: Tier‑1 — https://agentlisa.ai/whitepaper
  • Why sufficient / why not (one line): a structured description of the components and integrations is present.
  • Conflict note (if any): —

Onchain necessity

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

  • OC_1 (decision): 1
  • Chain: BNB Smart Chain
  • Addresses/identifiers: 0x0AA9D742A1e3C4Ad2947eBbf268aFA15D7c9bFBd
  • Evidence: Tier‑1 — https://bscscan.com/token/0x0AA9D742A1e3C4Ad2947eBbf268aFA15D7c9bFBd
  • Why sufficient / why not (one line): BscScan confirms the token, decimals and max total supply.
  • Conflict note (if any): —

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

  • OC_2 (decision): 0
  • What useful logic is onchain: in the extracted Tier‑1 sources, the product’s onchain logic (other than the token) is not confirmed; the product is an offchain security scanning service.
  • Evidence: Tier‑1 — https://agentlisa.ai/whitepaper
  • Why sufficient / why not (one line): the whitepaper describes the platform/infrastructure and the token economy, but not onchain execution of the analysis.
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 0
  • “Replace the blockchain” test: most of the platform’s functions can be implemented without a blockchain; onchain is needed mainly for the token/incentives.
  • Evidence: Tier‑1 — https://agentlisa.ai/whitepaper
  • Why sufficient / why not (one line): there is no proof of the critical irreplaceability of onchain for the core analytics.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): AgentLISA has a token, $LISA.
  • Evidence: Tier‑1 — https://agentlisa.ai/whitepaper ; https://bscscan.com/token/0x0AA9D742A1e3C4Ad2947eBbf268aFA15D7c9bFBd
  • Why sufficient / why not (one line): the whitepaper describes the token economy; BscScan confirms the token.
  • 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): $LISA is the primary payment token for security scans/subscriptions/premium features.
  • Evidence: Tier‑1 — https://agentlisa.ai/whitepaper
  • Why sufficient / why not (one line): the whitepaper has an explicit “Payment for Services” section.
  • Conflict note (if any): —

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

  • TK_2 (decision): 1
  • Claim (one line): $LISA is used for bug bounties and for stake‑backed curation with slashing for invalid/malicious submissions.
  • Evidence: Tier‑1 — https://agentlisa.ai/whitepaper
  • Why sufficient / why not (one line): the utilities in the whitepaper directly describe the bounty + slashing logic.
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 1
  • Claim (one line): $LISA holders participate in governance (platform params, bounty rules, treasury allocation).
  • Evidence: Tier‑1 — https://agentlisa.ai/whitepaper
  • Why sufficient / why not (one line): the whitepaper has an explicit “Governance” item.
  • Conflict note (if any): —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 0
  • Claim (one line): the token utility is described (payments/bounty/curation/governance), but there is no strict proof that “it cannot be replaced with a stablecoin”.
  • Evidence: Tier‑1 — https://agentlisa.ai/whitepaper
  • Why sufficient / why not (one line): this is a design decision, not a proof of necessity.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://agentlisa.ai/whitepaper description of the platform (multi‑agent security), token economy (utilities, total supply, TGE date), roadmap
Tier‑1 https://agentlisa.ai/scans/public public scan results as a demonstration of the product
Tier‑1 https://bscscan.com/token/0x0AA9D742A1e3C4Ad2947eBbf268aFA15D7c9bFBd onchain token page (BSC), max total supply 1,000,000,000

No comments to display

Back to top