菜单
Load when Mandate402 work touches EVM contracts, chain integration, signing, custody, onchain/offchain boundaries, audits, or blockchain operations.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Load when backend API work touches authentication, authorization, rate limiting, CORS, input validation, public endpoints, or security remediation in Mandate402.
Load when architecture choices, ADRs, trade-off evaluation, technical debt, or pattern selection need explicit decision records for Mandate402.
Load when designing or reviewing backend systems, APIs, auth, databases, security, performance, scalability, CI/CD, monitoring, or production runtime patterns.
Load when reviewing Mandate402 code for secrets, auth, authorization, input validation, payment safety, blockchain integration, or release security risks.
Load when testing Cloudflare Workers, Vitest worker pools, binding mocks, integration tests, coverage, or worker test failures.
Load when planning or building React/Next.js UI with CO-STAR structure, design tokens, dashboards, hero sections, or custom UI prompts.
| name | software-crypto-web3 |
| description | Load when Mandate402 work touches EVM contracts, chain integration, signing, custody, onchain/offchain boundaries, audits, or blockchain operations. |
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 | 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 |
// 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) |
| Frontrunning | 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 |
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: