software-crypto-web3 by vasilyu1983/ai-agents-public
npx skills add https://github.com/vasilyu1983/ai-agents-public --skill software-crypto-web3使用此技能来设计、实现和审查安全的区块链系统:智能合约、链上/链下集成、托管和签名、测试、审计以及生产运维。
默认采用:安全优先的开发模式、明确的威胁模型、全面的测试(单元测试 + 集成测试 + 分叉测试 + 模糊测试/不变性测试)、高价值场景下的形式化验证、升级安全性(时间锁、治理、回滚计划)以及针对密钥托管和签名的纵深防御策略。
| 任务 | 工具/框架 | 命令 | 使用场景 |
|---|---|---|---|
| Solidity 开发 | Hardhat/Foundry | npx hardhat init 或 forge init | Ethereum/EVM 智能合约 |
| Solana 程序 | Anchor | anchor init | Solana 区块链开发 |
| Cosmos 合约 | CosmWasm | cargo generate --git cosmwasm-template |
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
| Cosmos 生态系统合约 |
| TON 合约 | Tact/FunC + Blueprint | npm create ton@latest | TON 区块链开发 |
| 测试 (Solidity) | Foundry/Hardhat | forge test 或 npx hardhat test | 单元测试、分叉测试、不变性测试 |
| 安全审计 | Slither/Aderyn/Echidna | slither . 或 aderyn . | 静态分析、模糊测试 |
| AI 辅助审查 | AI 扫描器(可选) | N/A | 审计前准备(手动验证发现) |
| 模糊测试 | Echidna/Medusa | echidna . 或 medusa fuzz | 基于属性的模糊测试 |
| Gas 优化 | Foundry Gas 快照 | forge snapshot | 基准测试和 Gas 优化 |
| 部署 | Hardhat Deploy/Forge Script | npx hardhat deploy | 主网/测试网部署 |
| 验证 | Etherscan API | npx hardhat verify | 源代码验证 |
| 可升级合约 | OpenZeppelin Upgrades | @openzeppelin/hardhat-upgrades | 基于代理的升级 |
| 智能钱包 | ERC-4337, EIP-7702 | 账户抽象 SDK | 智能账户和赞助 Gas(验证网络支持) |
当你需要以下内容时,请使用此技能:
Project needs: [Use Case]
- EVM-compatible smart contracts?
- Complex testing needs -> Foundry (fuzzing, invariants, gas snapshots)
- TypeScript ecosystem -> Hardhat (plugins, TS, Ethers.js/Viem)
- Enterprise features -> NestJS + Hardhat
- High throughput / low fees?
- Rust-based -> Solana (Anchor)
- EVM L2 -> Arbitrum/Optimism/Base (Ethereum security, lower gas)
- Telegram distribution -> TON (Tact/FunC)
- Interoperability across chains?
- Cosmos ecosystem -> CosmWasm (IBC)
- Multi-chain apps -> LayerZero or Wormhole (verify trust assumptions)
- Bridge development -> custom (high risk; threat model required)
- Token standard implementation?
- Fungible tokens -> ERC20 (OpenZeppelin), SPL Token (Solana)
- NFTs -> ERC721/ERC1155 (OpenZeppelin), Metaplex (Solana)
- Semi-fungible -> ERC1155 (gaming, fractionalized NFTs)
- DeFi protocol development?
- AMM/DEX -> Uniswap V3 fork or custom (concentrated liquidity)
- Lending -> Compound/Aave fork (collateralized borrowing)
- Staking/yield -> custom reward distribution contracts
- Upgradeable contracts required?
- Transparent proxy -> OpenZeppelin (admin/user separation)
- UUPS -> upgrade logic in implementation
- Diamond -> modular functionality (EIP-2535)
- Backend integration?
- .NET/C# -> multi-provider architecture (see backend integration references)
- Node.js -> Ethers.js/Viem + durable queues
- Python -> Web3.py + FastAPI
特定链的考虑因素:
请参阅 references/ 获取特定链的最佳实践。
安全基线 : 假设处于对抗性环境中。将合约和签名基础设施视为公开的、可攻击的 API。
密钥管理是生产加密系统的主要风险驱动因素。使用真实的密钥管理标准作为基线(例如,NIST SP 800-57)。
| 模型 | 谁持有密钥 | 典型用途 | 主要风险 | 默认控制措施 |
|---|---|---|---|---|
| 非托管式 | 最终用户钱包 | 消费者应用,自我托管 | 网络钓鱼、授权、用户体验错误 | 硬件钱包支持、清晰的签名用户体验、白名单 |
| 托管式 | 你的服务 (HSM/MPC) | 交易所、支付、B2B | 密钥盗窃、内部威胁、操作失误 | HSM/MPC、职责分离、限额/审批、审计日志 |
| 混合式 | 责任分担 | 企业 | 复杂的故障模式 | 明确的恢复/覆盖路径、操作手册 |
最佳实践:
避免:
强制要求 所有状态变更函数都必须遵循。
// 正确:CEI 模式
function withdraw(uint256 amount) external {
// 1. 检查:验证条件
require(balances[msg.sender] >= amount, "Insufficient balance");
// 2. 效果:在外部调用之前更新状态
balances[msg.sender] -= amount;
// 3. 交互:最后进行外部调用
(bool success, ) = msg.sender.call{value: amount}("");
require(success, "Transfer failed");
}
// 错误:在状态更新之前进行外部调用(重入风险)
function withdrawUnsafe(uint256 amount) external {
require(balances[msg.sender] >= amount);
(bool success, ) = msg.sender.call{value: amount}("");
require(success);
balances[msg.sender] -= amount; // 太晚了!
}
| 类别 | 工具 | 目的 | 使用时机 |
|---|---|---|---|
| 静态分析 | Slither | 漏洞检测,92+ 个检测器 | 每个合约 |
| 静态分析 | Aderyn | 基于 Rust,适用于大型代码库 | 大型项目 |
| 模糊测试 | Echidna | 基于属性的模糊测试 | 复杂状态 |
| 模糊测试 | Medusa | 并行化的 Go 模糊测试器 | CI/CD 流水线 |
| 形式化验证 | SMTChecker | 内置的 Solidity 检查器 | 每个合约 |
| 形式化验证 | Certora | 基于属性的证明 (CVL) | DeFi,高价值 |
| 形式化验证 | Halmos | 符号测试 | 复杂的不变性 |
| AI 辅助 | Sherlock AI | 机器学习漏洞检测 | 审计前准备 |
| AI 辅助 | Olympix | DevSecOps 集成 | CI/CD 安全 |
| AI 辅助 | AuditBase | 423+ 个检测器,LLM 驱动 | 业务逻辑 |
| 变异测试 | SuMo | 测试套件质量评估 | 测试验证 |
// Certora CVL 规则示例
rule balanceNeverNegative(address user) {
env e;
require balances[user] >= 0;
deposit(e);
assert balances[user] >= 0;
}
AI 辅助审查 : 使用 AI 工具进行审计前准备和覆盖,而不是用于最终的安全决策。将输出视为不可信,并使用确定性工具、测试和手动审查来复现发现。
| 策略 | 实现 |
|---|---|
| 私有内存池 | Flashbots Protect, MEV Blocker |
| 提交-揭示 | 哈希承诺,截止日期后揭示 |
| 批量拍卖 | CoW Protocol, Gnosis Protocol |
| 加密内存池 | Shutter Network |
// 提交-揭示模式
mapping(address => bytes32) public commitments;
function commit(bytes32 hash) external {
commitments[msg.sender] = hash;
}
function reveal(uint256 value, bytes32 salt) external {
require(
keccak256(abi.encodePacked(value, salt)) == commitments[msg.sender],
"Invalid reveal"
);
// 处理揭示的值
}
注意 : 采用率和升级时间表变化很快。在提出建议之前,请通过 WebSearch 验证当前的 ERC-4337 生态系统状态以及任何 EIP-7702 激活详情。
| 标准 | 类型 | 关键特性 | 使用场景 |
|---|---|---|---|
| ERC-4337 | 智能合约钱包 | 无需协议变更的完整 AA | 新钱包、DeFi、游戏 |
| EIP-7702 | EOA 增强 | EOA 执行智能合约代码 | 现有钱包、批量交易 |
| ERC-6900 | 模块化账户 | AA 钱包的插件管理 | 可扩展的钱包功能 |
ERC-4337 架构:
User -> UserOperation -> Bundler -> EntryPoint -> Smart Account -> Target Contract
|
v
Paymaster (gas sponsorship)
EIP-7702 (Pectra 升级):
关键能力:
// 最小化 ERC-4337 账户(简化版)
import "@account-abstraction/contracts/core/BaseAccount.sol";
contract SimpleAccount is BaseAccount {
address public owner;
function validateUserOp(
UserOperation calldata userOp,
bytes32 userOpHash,
uint256 missingAccountFunds
) external override returns (uint256 validationData) {
// 验证签名
require(_validateSignature(userOp, userOpHash), "Invalid sig");
// 如果需要,支付预付款
if (missingAccountFunds > 0) {
(bool success,) = payable(msg.sender).call{value: missingAccountFunds}("");
require(success);
}
return 0; // 有效
}
}
注意 : L2 市场份额和风险阶段变化很快。在陈述排名、TVL 或阶段分类之前,请使用当前数据(例如,L2Beat 和生态系统仪表板)。
| L2 | 类型 | 最适合 | 关键特性 |
|---|---|---|---|
| Base | 乐观汇总 | 消费者应用,主流采用 | Coinbase 集成,低费用 |
| Arbitrum | 乐观汇总 | DeFi,成熟生态系统 | 最大的 TVL,DAO 资助 |
| Optimism | 乐观汇总 | 公共产品,Superchain | OP Stack,资助计划 |
| zkSync Era | ZK 汇总 | 快速最终性,原生 AA | zkEVM,无提款延迟 |
| StarkNet | ZK 汇总 | Cairo 开发,ZK 原生 | STARK 证明,自定义 VM |
主要机构在 OP Stack 上启动 L2:
自 2024 年 3 月起,汇总使用基于 Blob 的数据发布:
Before: calldata posting -> expensive
After: blob posting -> lower data availability cost
Optimism、zkSync 在 2025 年针对 Blob 进行了批量优化。
现实检查 : 漏洞利用经常导致巨大损失。访问控制、签名/托管和集成错误仍然是主要的事故驱动因素。
| 错误 | 影响 | 预防措施 |
|---|---|---|
| 缺少访问控制 | 未经授权的管理员操作 | 使用 OpenZeppelin Ownable2Step, AccessControl |
| 重入攻击 | 通过回调耗尽资金 | CEI 模式, ReentrancyGuard, Slither 检查 |
| 未检查的外部调用 | 静默失败 | 始终检查返回值,使用 SafeERC20 |
| 整数溢出 (0.8 之前) | 任意值操作 | 使用 Solidity 0.8.x+(内置检查) |
| 抢先交易 | MEV 提取,三明治攻击 | 提交-揭示, Flashbots Protect, 私有内存池 |
| 预言机操纵 | 价格源攻击 | TWAP, 多个预言机, 合理性边界 |
| 初始化不当 | 代理接管 | 使用 initializer 修饰符, _disableInitializers() |
| 存储冲突 (代理) | 数据损坏 | 遵循 EIP-1967 插槽,使用 OpenZeppelin 升级 |
避免:
tx.origin 进行授权(网络钓鱼风险)block.timestamp 生成随机数(矿工/验证者影响)transfer/send 的返回值最佳实践:
不要依赖 LLM 进行:
使用 LLM 进行:
资源
模板
相关技能
重要 : 当用户询问有关 Web3/加密开发的推荐问题时,你必须在回答之前使用 WebSearch 检查当前趋势。
"Web3 development best practices 2026""[Ethereum/Solana/Base] development updates 2026""smart contract security 2026""[Hardhat/Foundry] comparison 2026"搜索后,提供:
每周安装次数
203
仓库
GitHub 星标
46
首次出现
2026年1月23日
安全审计
安装于
opencode145
gemini-cli140
codex139
cursor129
github-copilot127
claude-code121
Use this skill to design, implement, and review secure blockchain systems: smart contracts, on-chain/off-chain integration, custody and signing, testing, audits, and production operations.
Defaults to: security-first development, explicit threat models, comprehensive testing (unit + integration + fork + fuzz/invariants), formal methods when high-value, upgrade safety (timelocks, governance, rollback plans), and defense-in-depth for key custody and signing.
| Task | Tool/Framework | Command | When to Use |
|---|---|---|---|
| Solidity Development | Hardhat/Foundry | npx hardhat init or forge init | Ethereum/EVM smart contracts |
| Solana Programs | Anchor | anchor init | Solana blockchain development |
| Cosmos Contracts | CosmWasm | cargo generate --git cosmwasm-template | Cosmos ecosystem contracts |
| TON Contracts | Tact/FunC + Blueprint | npm create ton@latest | TON blockchain development |
| Testing (Solidity) | Foundry/Hardhat | forge test or npx hardhat test | Unit, fork, invariant tests |
| Security Audit | Slither/Aderyn/Echidna | slither . or aderyn . | Static analysis, fuzzing |
| AI-Assisted Review | AI scanners (optional) | N/A | Pre-audit preparation (verify findings manually) |
| Fuzzing | Echidna/Medusa | echidna . or medusa fuzz | Property-based fuzzing |
| Gas Optimization | Foundry Gas Snapshots | forge snapshot | Benchmark and optimize gas |
| Deployment | Hardhat Deploy/Forge Script | npx hardhat deploy | Mainnet/testnet deployment |
| Verification | Etherscan API | npx hardhat verify | Source code verification |
| Upgradeable Contracts | OpenZeppelin Upgrades | @openzeppelin/hardhat-upgrades | Proxy-based upgrades |
| Smart Wallets | ERC-4337, EIP-7702 | Account abstraction SDKs | Smart accounts and sponsored gas (verify network support) |
Use this skill when you need:
Project needs: [Use Case]
- EVM-compatible smart contracts?
- Complex testing needs -> Foundry (fuzzing, invariants, gas snapshots)
- TypeScript ecosystem -> Hardhat (plugins, TS, Ethers.js/Viem)
- Enterprise features -> NestJS + Hardhat
- High throughput / low fees?
- Rust-based -> Solana (Anchor)
- EVM L2 -> Arbitrum/Optimism/Base (Ethereum security, lower gas)
- Telegram distribution -> TON (Tact/FunC)
- Interoperability across chains?
- Cosmos ecosystem -> CosmWasm (IBC)
- Multi-chain apps -> LayerZero or Wormhole (verify trust assumptions)
- Bridge development -> custom (high risk; threat model required)
- Token standard implementation?
- Fungible tokens -> ERC20 (OpenZeppelin), SPL Token (Solana)
- NFTs -> ERC721/ERC1155 (OpenZeppelin), Metaplex (Solana)
- Semi-fungible -> ERC1155 (gaming, fractionalized NFTs)
- DeFi protocol development?
- AMM/DEX -> Uniswap V3 fork or custom (concentrated liquidity)
- Lending -> Compound/Aave fork (collateralized borrowing)
- Staking/yield -> custom reward distribution contracts
- Upgradeable contracts required?
- Transparent proxy -> OpenZeppelin (admin/user separation)
- UUPS -> upgrade logic in implementation
- Diamond -> modular functionality (EIP-2535)
- Backend integration?
- .NET/C# -> multi-provider architecture (see backend integration references)
- Node.js -> Ethers.js/Viem + durable queues
- Python -> Web3.py + FastAPI
Chain-Specific Considerations:
See references/ for chain-specific best practices.
Security baseline : Assume an adversarial environment. Treat contracts and signing infrastructure as public, attackable APIs.
Key management is a dominant risk driver in production crypto systems. Use a real key management standard as baseline (for example, NIST SP 800-57).
| Model | Who holds keys | Typical use | Primary risks | Default controls |
|---|---|---|---|---|
| Non-custodial | End user wallet | Consumer apps, self-custody | Phishing, approvals, UX errors | Hardware wallet support, clear signing UX, allowlists |
| Custodial | Your service (HSM/MPC) | Exchanges, payments, B2B | Key theft, insider threat, ops mistakes | HSM/MPC, separation of duties, limits/approvals, audit logs |
| Hybrid | Split responsibility | Enterprises | Complex failure modes | Explicit recovery/override paths, runbooks |
BEST:
AVOID:
Mandatory for all state-changing functions.
// Correct: CEI pattern
function withdraw(uint256 amount) external {
// 1. CHECKS: Validate conditions
require(balances[msg.sender] >= amount, "Insufficient balance");
// 2. EFFECTS: Update state BEFORE external calls
balances[msg.sender] -= amount;
// 3. INTERACTIONS: External calls LAST
(bool success, ) = msg.sender.call{value: amount}("");
require(success, "Transfer failed");
}
// Wrong: External call before state update (reentrancy risk)
function withdrawUnsafe(uint256 amount) external {
require(balances[msg.sender] >= amount);
(bool success, ) = msg.sender.call{value: amount}("");
require(success);
balances[msg.sender] -= amount; // Too late!
}
| Category | Tool | Purpose | When to Use |
|---|---|---|---|
| Static Analysis | Slither | Vulnerability detection, 92+ detectors | Every contract |
| Static Analysis | Aderyn | Rust-based, faster for large codebases | Large projects |
| Fuzzing | Echidna | Property-based fuzzing | Complex state |
| Fuzzing | Medusa | Parallelized Go fuzzer | CI/CD pipelines |
| Formal Verification | SMTChecker | Built-in Solidity checker | Every contract |
| Formal Verification | Certora | Property-based proofs (CVL) | DeFi, high-value |
| Formal Verification | Halmos | Symbolic testing |
// Certora CVL rule example
rule balanceNeverNegative(address user) {
env e;
require balances[user] >= 0;
deposit(e);
assert balances[user] >= 0;
}
AI-assisted review : Use AI tooling for pre-audit preparation and coverage, not for final security decisions. Treat outputs as untrusted and reproduce findings with deterministic tools, tests, and manual review.
| Strategy | Implementation |
|---|---|
| Private mempool | Flashbots Protect, MEV Blocker |
| Commit-reveal | Hash commitment, reveal after deadline |
| Batch auctions | CoW Protocol, Gnosis Protocol |
| Encrypted mempools | Shutter Network |
// Commit-reveal pattern
mapping(address => bytes32) public commitments;
function commit(bytes32 hash) external {
commitments[msg.sender] = hash;
}
function reveal(uint256 value, bytes32 salt) external {
require(
keccak256(abi.encodePacked(value, salt)) == commitments[msg.sender],
"Invalid reveal"
);
// Process revealed value
}
Note : Adoption numbers and upgrade timelines change quickly. Verify current ERC-4337 ecosystem state and any EIP-7702 activation details with WebSearch before making recommendations.
| Standard | Type | Key Feature | Use Case |
|---|---|---|---|
| ERC-4337 | Smart contract wallets | Full AA without protocol changes | New wallets, DeFi, gaming |
| EIP-7702 | EOA enhancement | EOAs execute smart contract code | Existing wallets, batch txns |
| ERC-6900 | Modular accounts | Plugin management for AA wallets | Extensible wallet features |
ERC-4337 Architecture:
User -> UserOperation -> Bundler -> EntryPoint -> Smart Account -> Target Contract
|
v
Paymaster (gas sponsorship)
EIP-7702 (Pectra Upgrade):
Key Capabilities:
// Minimal ERC-4337 Account (simplified)
import "@account-abstraction/contracts/core/BaseAccount.sol";
contract SimpleAccount is BaseAccount {
address public owner;
function validateUserOp(
UserOperation calldata userOp,
bytes32 userOpHash,
uint256 missingAccountFunds
) external override returns (uint256 validationData) {
// Verify signature
require(_validateSignature(userOp, userOpHash), "Invalid sig");
// Pay prefund if needed
if (missingAccountFunds > 0) {
(bool success,) = payable(msg.sender).call{value: missingAccountFunds}("");
require(success);
}
return 0; // Valid
}
}
Note : L2 market share and risk stages change quickly. Use current data (for example, L2Beat and ecosystem dashboards) before stating rankings, TVL, or stage classifications.
| L2 | Type | Best For | Key Feature |
|---|---|---|---|
| Base | Optimistic | Consumer apps, mainstream adoption | Coinbase integration, low fees |
| Arbitrum | Optimistic | DeFi, mature ecosystem | Largest TVL, DAO grants |
| Optimism | Optimistic | Public goods, Superchain | OP Stack, grant programs |
| zkSync Era | ZK-Rollup | Fast finality, native AA | zkEVM, no withdrawal delay |
| StarkNet | ZK-Rollup | Cairo development, ZK-native | STARK proofs, custom VM |
Major institutions launching L2s on OP Stack:
Since March 2024, rollups use blob-based data posting:
Before: calldata posting -> expensive
After: blob posting -> lower data availability cost
Optimism, zkSync optimized batching for blobs in 2025.
Reality check : Exploits regularly cause large losses. Access control, signing/custody, and integration bugs remain top incident drivers.
| Mistake | Impact | Prevention |
|---|---|---|
| Missing access control | Unauthorized admin actions | Use OpenZeppelin Ownable2Step, AccessControl |
| Reentrancy | Drain funds via callback | CEI pattern, ReentrancyGuard, Slither checks |
| Unchecked external calls | Silent failures | Always check return values, use SafeERC20 |
| Integer overflow (pre-0.8) | Arbitrary value manipulation | Use Solidity 0.8.x+ (built-in checks) |
AVOID:
tx.origin for authorization (phishing risk)block.timestamp for randomness (miner/validator influence)transfer/sendBEST:
Do not rely on LLMs for:
Use LLMs for:
Resources
Templates
Related Skills
IMPORTANT : When users ask recommendation questions about Web3/crypto development, you MUST use WebSearch to check current trends before answering.
"Web3 development best practices 2026""[Ethereum/Solana/Base] development updates 2026""smart contract security 2026""[Hardhat/Foundry] comparison 2026"After searching, provide:
Weekly Installs
203
Repository
GitHub Stars
46
First Seen
Jan 23, 2026
Security Audits
Gen Agent Trust HubPassSocketPassSnykWarn
Installed on
opencode145
gemini-cli140
codex139
cursor129
github-copilot127
claude-code121
Azure RBAC 权限管理工具:查找最小角色、创建自定义角色与自动化分配
131,500 周安装
| Complex invariants |
| AI-Assisted | Sherlock AI | ML vulnerability detection | Pre-audit prep |
| AI-Assisted | Olympix | DevSecOps integration | CI/CD security |
| AI-Assisted | AuditBase | 423+ detectors, LLM-powered | Business logic |
| Mutation Testing | SuMo | Test suite quality assessment | Test validation |
| MEV extraction, sandwich attacks |
| Commit-reveal, Flashbots Protect, private mempool |
| Oracle manipulation | Price feed attacks | TWAP, multiple oracles, sanity bounds |
| Improper initialization | Proxy takeover | Use initializer modifier, _disableInitializers() |
| Storage collision (proxies) | Data corruption | Follow EIP-1967 slots, use OpenZeppelin upgrades |