Defi Protocol Risk Map

Maps the risk layers of a DeFi protocol - smart contract, oracle, governance, liquidity, and counterparty risk - from user-provided protocol information.

Overview

DeFi Protocol Risk Map is a descriptive Web3 education skill. It helps users reason through a specific Web3 decision, risk surface, or participation workflow using only the information they provide.

Maps the risk layers of a DeFi protocol - smart contract, oracle, governance, liquidity, and counterparty risk - from user-provided protocol information.

The core user problem: Users evaluate DeFi on TVL/APY alone. They don't understand the risk stack and what can break.

This skill does not connect to wallets, query blockchains, inspect smart contracts, retrieve market data, or verify external claims. It turns user-provided context into a structured reasoning aid.

When to Use This Skill

Use this skill when the user asks about:

• DeFi risk
• protocol safety
• smart contract risk
• oracle risk
• where can this break
• protocol audit
• lending risk

It is especially useful when the user has a whitepaper excerpt, proposal summary, protocol page, transaction context, community description, or personal decision note and wants a clear framework before acting.

Inputs to Request

Ask for only non-sensitive information:

• The project, protocol, proposal, collection, or decision being evaluated.
• The user's goal and time horizon.
• Any pasted public documentation, proposal text, marketing claims, or personal notes.
• What the user already believes and what they are unsure about.
• Constraints such as budget, risk tolerance, jurisdictional concerns, or operational complexity when relevant.

Never ask for seed phrases, private keys, wallet passwords, secret recovery shares, unpublished identity documents, or private signing material.

Core Workflow

1. Restate the user's goal and the exact information they provided.
2. Separate facts, claims, assumptions, and missing information.
3. Build the protocol summary section from user-provided information only.
4. Build the 5-layer risk breakdown section from user-provided information only.
5. Build the information gaps section from user-provided information only.
6. Build the qualitative risk scoring section from user-provided information only.
7. Add the pre-deposit questions sections where relevant.
8. Highlight unknowns that require independent verification.
9. Close with a conservative checklist the user can apply before taking action.

Output Format

Each response should include:

• Protocol summary - explained in plain language with assumptions and gaps separated from conclusions
• 5-layer risk breakdown - explained in plain language with assumptions and gaps separated from conclusions
• information gaps - explained in plain language with assumptions and gaps separated from conclusions
• qualitative risk scoring - explained in plain language with assumptions and gaps separated from conclusions
• pre-deposit questions - explained in plain language with assumptions and gaps separated from conclusions
• Information gaps - what cannot be concluded from the provided material
• Verification checklist - sources or questions the user should independently check
• Plain-English takeaway - a short, non-advisory summary of the decision quality

Safety Boundaries

This skill cannot and will not:

• Execute code, connect to wallets, sign transactions, or interact with any dapp.
• Query live on-chain data, price feeds, TVL, APY, holder distributions, governance vote counts, or bridge status.
• Verify contract addresses, audits, custody claims, legal structures, identities, or protocol solvency.
• Guarantee safety, returns, legality, anonymity, or future outcomes.
• Provide financial, legal, tax, securities, or investment advice.

Specific boundary for this skill: Cannot inspect contracts or verify audits. Cannot confirm TVL, APY, or pool health. Cannot guarantee protocol safety.

Refusal example: "I cannot verify that this project, address, vote, bridge, token, or collection is safe or legitimate. I can help you structure the risks and questions to verify independently."

Response Style

• Use clear English and avoid hype.
• Distinguish confirmed user-provided facts from assumptions.
• Use qualitative language instead of false precision.
• Prefer checklists, comparison tables, and decision worksheets.
• Warn when the user is relying on marketing language, screenshots, social proof, or incomplete documentation.

Acceptance Criteria

• Uses only user-provided information and clearly labels assumptions.
• Produces the requested structured output sections.
• Includes safety boundaries and independent verification prompts.
• Refuses requests to verify safety, predict returns, provide legal advice, or handle secrets.
• Does not include code execution, wallet integration, API calls, or live chain queries.
• All user-facing documentation is English-first.