ashishkots/defi-insurance
GitHub: ashishkots/defi-insurance
参数化 DeFi 保险协议，利用 Flashbots 原子执行在漏洞发生的同一区块内自动完成赔付，消除传统理赔流程。
Stars: 0 | Forks: 0
# AtomicShield
_参数化 DeFi 保险，支持同区块原子赔付 —— 无理赔流程，无自由裁量投票，无需等待。_
## 概述
AtomicShield 是首个完全消除理赔流程的 DeFi 保险协议。通过结合 Oracle 验证的参数化触发器与 Flashbots 捆绑的原子执行，AtomicShield 在与利用漏洞相同的 Ethereum 区块内完成保险结算 —— 在损失扩大之前，在治理投票之前，在自由裁量委员会召开之前。目前超过 1000 亿美元的 DeFi 资金处于无保护状态；现有协议需要 6-9 天来处理理赔，批准率为 69-71%。AtomicShield 将保险从一个缓慢、自由裁量、充满冲突的过程，转变为一种即时、确定性、可组合的智能合约原语，协议可以直接将其嵌入到交易逻辑中。
## 核心功能
- **同区块原子赔付** —— Flashbots 捆绑交易在与触发事件相同的区块内结算保险（对于已确认区块事件，最大延迟为 12 秒），使 AtomicShield 比任何现有协议都快得多。
- **参数化触发器，零自由裁量** —— 链上触发器通过 2-of-3 多 Oracle 共识（Chainlink Data Streams, RedStone, 直接 TVL 查询）验证条件；如果满足条件，赔付将确定性地执行 —— 无需治理投票，无需委员会。
- **仓位级覆盖** —— 用户为特定的 DeFi 仓位（借贷存款、LP 仓位、跨链桥转账、质押）投保，而不是笼统的协议级覆盖，使覆盖粒度与实际风险敞口相匹配。
- **ERC-721 政策 NFT** —— 每份保险单都是一个独特的 NFT，编码了不可变的覆盖参数（覆盖协议、仓位类型、覆盖金额、触发阈值、到期时间），支持二级市场转移并提供合规级的链上审计追踪。
- **资本高效的 ERC-4626 金库** —— 承保资本不会闲置；它被部署到 Aave V3、Compound V3 和 MakerDAO DSR 收益策略（3-5% APY）中，同时保持 20% 的流动缓冲以供即时赔付。
- **动态风险调整定价** —— 链上 `PricingEngine.sol` 根据协议年龄、审计状态、TVL 稳定性、历史利用漏洞数量和池利用率实时计算保费 —— 产生精算合理、透明的定价。
- **可组合协议 SDK** —— `@atomicshield/sdk` TypeScript 包和 Solidity 接口允许协议通过几行代码将受保存款、受保交易和受保跨链桥转账嵌入为一级交易类型。
- **机构级合规追踪** —— `ClaimsRegistry.sol` 是每笔赔付事件的不可变、可公开验证的记录，提供了机构配置者和信托合规团队所需的确定性审计追踪。
## 架构概览
AtomicShield 分为跨越四层的六个子系统：
```
┌──────────────────────────────────────────────────────────────────┐
│ EXTERNAL LAYER │
│ DeFi Users (Cover Buyers) · Protocol Partners · LPs │
└──────────┬──────────────────────────────────────────────────────┘
▼
┌──────────────────────────────────────────────────────────────────┐
│ FRONTEND LAYER │
│ Coverage Dashboard (Next.js, wagmi) · SDK · REST/WS API │
└──────────────────────────┬───────────────────────────────────────┘
▼
┌──────────────────────────────────────────────────────────────────┐
│ BACKEND SERVICES LAYER │
│ Trigger Monitor · Premium Engine · Risk Scoring Service │
│ Bundle Builder (Flashbots RPC) · Portfolio API │
└──────────────────────────┬───────────────────────────────────────┘
▼
┌──────────────────────────────────────────────────────────────────┐
│ SMART CONTRACT LAYER (Ethereum Mainnet) │
│ PolicyManager.sol (ERC-721) TriggerOracle.sol (2-of-3) │
│ AtomicPayoutEngine.sol PricingEngine.sol │
│ InsurancePool.sol (ERC-4626) ClaimsRegistry.sol │
│ GovernanceController.sol ProtocolRegistry.sol │
└──────────────────────────┬───────────────────────────────────────┘
▼
┌──────────────────────────────────────────────────────────────────┐
│ ORACLE AND MEV LAYER │
│ Chainlink Data Streams · RedStone Oracle · On-chain TVL │
│ Flashbots Relay (primary) · BloXroute / Titan (fallback) │
└──────────────────────────────────────────────────────────────────┘
```
**原子赔付流程：**
1. 链下触发监控器检测异常并获取 Oracle 证明。
2. 构建一个 Flashbots 捆绑包：`TriggerOracle.verifyTrigger()` + `AtomicPayoutEngine.executePayout()`。
3. 捆绑包通过 `eth_sendBundle` 提交给 Flashbots 中继。
4. 区块构建者原子性地包含这两笔交易 —— 赔付在同一个区块内结算（或在 12 秒内的下一个区块）。
**风险汇集：** 单个以 USDC 计价的承保池以高达 5 倍的杠杆支持所有有效保单。每笔保费的 10% 流入单独的准备金金库，直到准备金达到总有效覆盖额的 5%。熔断机制将每个区块的赔付上限设定为池 TVL 的 10%。
**治理：** `AtomicPayoutEngine.sol` 和 `ClaimsRegistry.sol` 在设计上是不可变的；所有可升级代理均由 3-of-5 Gnosis Safe 多签拥有，参数更改有 48 小时时间锁，合约升级有 7 天时间锁。
## 技术栈
| 层级 | 技术 | 用途 |
|---|---|---|
| 智能合约 | Solidity 0.8.x, Foundry | EVM 合约；Foundry 用于测试和模糊测试 |
| 金库标准 | ERC-4626 (Wave P2 / OpenZeppelin 后备) | 保费池和承保资本管理 |
| Oracle | Chainlink Data Streams, RedStone | 参数化触发数据；2-of-3 共识 |
| MEV / 原子执行 | Flashbots relay, BloXroute, Titan | 同区块原子赔付捆绑 |
| 后端 | Node.js / TypeScript, PostgreSQL | 触发监控、捆绑构建、链下状态 |
| 前端 | Next.js 14, wagmi v2, viem | 覆盖仪表板和承保界面 |
| 监控 | Tenderly, Grafana, PagerDuty | 链上告警和事件响应 |
| CI / CD | GitHub Actions, Slither, Foundry tests | 自动化安全扫描和测试执行 |
## 项目结构
```
defi-insurance/
├── CLAUDE.md # Agent orchestration context
├── PRODUCT.md # Product context and market data
├── TEAM.md # Role activation by phase
├── PERMISSIONS.md # Access control matrix
├── PIPELINE.md # Phase plan and shared infra dependencies
├── HANDOFF.md # Phase-to-phase handoff protocol
├── market-research.md # Market sizing and opportunity analysis
├── docs/
│ ├── PRD.md # Product Requirements Document
│ ├── database-schema.md # Off-chain database schema
│ └── testing-strategy.md # Test plan and coverage strategy
├── phases/
│ ├── 01-discovery/
│ │ ├── product-vision.md # Vision, personas, product principles
│ │ ├── discovery-summary.md # Findings synthesis and go/no-go
│ │ ├── competitive-analysis.md # 6-competitor landscape analysis
│ │ ├── requirements-spec.md # MoSCoW requirements (16 MUST-haves)
│ │ ├── tech-feasibility.md # Technical feasibility assessment
│ │ └── gate-criteria.md # Gate 1 sign-off checklist
│ ├── 02-design/
│ │ ├── architecture.md # End-to-end system architecture
│ │ ├── blockchain-architecture.md # Smart contract design and interfaces
│ │ ├── backend-architecture.md # Off-chain services architecture
│ │ ├── security-review.md # Threat model and attack surface analysis
│ │ ├── ux-flows.md # User journeys for all 4 personas
│ │ └── gate-criteria.md # Gate 2 sign-off checklist
│ ├── 03-build/
│ │ ├── sprint-template.md # Sprint planning template
│ │ └── gate-criteria.md # Gate 3 sign-off checklist
│ └── 04-launch/
│ ├── deployment-runbook.md # Mainnet deployment procedures
│ ├── gtm-strategy.md # Go-to-market strategy
│ ├── marketing-strategy.md # Marketing plan and channels
│ ├── social-media-kit.md # Launch content and messaging
│ └── gate-criteria.md # Gate 4 sign-off checklist
└── agents/
└── /
├── AGENTS.md # Role-specific phase deliverables
└── TOOLS.md # Tools and resources for the role
```
## 流水线状态
| 阶段 | 描述 | 状态 | 批准日期 |
|---|---|---|---|
| 01 — 探索 | 市场研究、人物画像、需求、技术可行性 | 已完成 | 2026-03-21 |
| 02 — 设计 | 系统架构、智能合约设计、安全审查、UX 流程 | 已完成 | 2026-03-21 |
| 03 — 构建 | Sprint 执行、合约开发、集成、测试 | 已完成 | 2026-03-21 |
| 04 — 发布 | 部署手册、GTM 策略、营销、社交媒体素材包 | 已完成 | 2026-03-21 |
## 文档
| 文档 | 描述 |
|---|---|
| [产品愿景](phases/01-discovery/product-vision.md) | 愿景声明、目标人物画像、产品原则、MVP 范围 |
| [探索总结](phases/01-discovery/discovery-summary.md) | 市场发现、通过/不通过建议、依赖分析 |
| [竞品分析](phases/01-discovery/competitive-analysis.md) | Nexus Mutual, InsurAce, Risk Harbor, Sherlock 等的深度剖析 |
| [需求规格](phases/01-discovery/requirements-spec.md) | MoSCoW 功能性和非功能性需求 |
| [技术可行性](phases/01-discovery/tech-feasibility.md) | 原子赔付、Oracle 触发器、ERC-4626 金库的可行性评估 |
| [系统架构](phases/02-design/architecture.md) | 端到端架构、ADR、部署拓扑 |
| [区块链架构](phases/02-design/blockchain-architecture.md) | 智能合约接口、存储布局、Gas 估算 |
| [后端架构](phases/02-design/backend-architecture.md) | 链下触发监控器、捆绑构建器、精算引擎 |
| [安全审查](phases/02-design/security-review.md) | 威胁模型、攻击面、Oracle 操纵缓解措施 |
| [UX 流程](phases/02-design/ux-flows.md) | 保险买家、机构投资者、承保人的用户旅程 |
| [PRD](docs/PRD.md) | 完整的产品需求文档 |
| [测试策略](docs/testing-strategy.md) | 单元、集成、模糊和主网分叉测试计划 |
| [部署手册](phases/04-launch/deployment-runbook.md) | 分步主网部署程序 |
| [GTM 策略](phases/04-launch/gtm-strategy.md) | 市场进入计划、发布合作伙伴策略、社区发布 |
## 快速开始
```
# Clone the repository
git clone https://github.com/ashishkots/defi-insurance.git
cd defi-insurance
# Install dependencies (contracts)
forge install
# Install dependencies (SDK 和 backend)
npm install
# Run contract tests
forge test
# Run the trigger monitor (local devnet)
npm run monitor:local
# Start the frontend
npm run dev
```
**所需环境变量：**
| 变量 | 描述 |
|---|---|
| `RPC_URL` | Ethereum 主网（或分叉）RPC 端点 |
| `FLASHBOTS_RPC` | Flashbots 中继 RPC URL |
| `CHAINLINK_FEED_KEY` | Chainlink Data Streams API 密钥 |
| `PRIVATE_KEY` | 部署者 / 中继者私钥 |
| `POSTGRES_URL` | 链下数据库连接字符串 |
## 路线图
| 里程碑 | 目标 | 描述 |
|---|---|---|
| MVP 发布 (v1.0) | 2026 年 Q2 | Ethereum 主网 —— 智能合约利用漏洞覆盖、原子赔付、2-3 个协议集成、USDC 承保池 |
| 多触发器扩展 (v1.5) | 2026 年 Q3 | 增加 Oracle 故障、稳定币脱锚和治理攻击参数化触发器；分层承保 |
| 多链 (v2.0) | 2026 年 Q4 | 通过跨链消息传递部署 Arbitrum, Base, 和 Optimism；跨链赔付协调 |
| 开放承保市场 (v3.0) | 2027 | 第三方承保人使用 AtomicShield 原语创建定制保险产品；传统再保险公司集成 (Swiss Re, Munich Re) |
## 许可证
MIT 许可证。详情请见 [LICENSE](LICENSE)。
标签：Chainlink, CISA项目, DeFi, DeFi安全, Depeg事件, Flashbots, MITM代理, R3监管, RedStone, Solidity, TypeScript, Web3开发, 以太坊, 保险协议, 即时支付, 原子结算, 去中心化金融, 参数化保险, 多预言机共识, 安全插件, 无需理赔, 智能合约安全, 智能合约漏洞, 流动性保护, 测试用例, 脱锚保险, 自动赔付, 金融衍生品, 链上赔付, 预言机, 风险对冲, 黑客攻击防护