Software Crypto/Web3 Engineering
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.
Quick Reference
| 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) |
Scope
Use this skill when you need:
- Smart contract development (Solidity, Rust, CosmWasm)
- DeFi protocol implementation (AMM, lending, staking, yield farming)
- NFT and token standards (ERC20, ERC721, ERC1155, SPL tokens)
- DAO governance systems
- Cross-chain bridges and interoperability
- Gas optimization and storage patterns
- Smart contract security audits
- Testing strategies (Foundry, Hardhat, Anchor)
- Oracle integration (Chainlink, Pyth)
- Upgradeable contract patterns (proxies, diamonds)
- Web3 frontend integration (ethers.js, web3.js, @solana/web3.js)
- Blockchain indexing (The Graph, subgraphs)
- MEV protection and flashbots
- Layer 2 scaling solutions (Base, Arbitrum, Optimism, zkSync)
- Account abstraction (ERC-4337, EIP-7702, smart wallets)
- Backend crypto integration (.NET/C#, multi-provider architecture, CQRS)
- Webhook handling and signature validation (Fireblocks, custodial providers)
- Event-driven architecture with Kafka for crypto payments
- Transaction lifecycle management and monitoring
- Wallet management (custodial vs non-custodial)
Decision Tree: Blockchain Platform Selection
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:
- Ethereum/EVM: Security-first, higher gas costs, largest ecosystem
- Solana: Performance-first, Rust required, lower fees
- Cosmos: Interoperability-first, IBC native, growing ecosystem
- TON: Telegram-first, async contracts, unique architecture
See references/ for chain-specific best practices.
Security-First Patterns (Jan 2026)
Security baseline: Assume an adversarial environment. Treat contracts and signing infrastructure as public, attackable APIs.
Custody, Keys, and Signing (Core)
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:
- Separate hot/warm/cold signing paths with limits and approvals [Inference]
- Require dual control for high-value transfers (policy engine + human approval) [Inference]
- Keep an immutable audit trail for signing requests (who/what/when/why) [Inference]
AVOID:
- Storing private keys in databases or application config
- Reusing signing keys across environments (dev/staging/prod)
- Hot-wallet automation without rate limits and circuit breakers [Inference]
Checks-Effects-Interactions (CEI) Pattern
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!
}
Security Tools (Jan 2026)
| 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.
MEV Protection
| 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
}
Account Abstraction (Jan 2026)
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.
ERC-4337 vs EIP-7702
| 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):
- EOAs can temporarily delegate to smart contracts
- Enables batch transactions, sponsored gas for existing addresses
- Complementary to ERC-4337 (uses same bundler/paymaster infra)
- Supported by Ambire, Trust Wallet, and growing
Key Capabilities:
- Gasless transactions: Paymasters sponsor gas in ERC-20 or fiat
- Batch operations: Multiple actions in single transaction
- Social recovery: Multi-sig or guardian-based key recovery
- Session keys: Limited permissions for dApps without full wallet access
Smart Wallet Development
// 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
}
}
Layer 2 Development (Jan 2026)
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 Selection Guide
| 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 |
Enterprise Rollups (2025-2026 Trend)
Major institutions launching L2s on OP Stack:
- Kraken INK - Exchange-native L2
- Uniswap UniChain - DeFi-optimized
- Sony Soneium - Gaming and media
- Robinhood - Arbitrum integration
EIP-4844 Blob Optimization
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.
Common Mistakes (2025-2026)
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 |
Anti-Patterns to Avoid
AVOID:
- Using
tx.origin for authorization (phishing risk)
- Storing secrets on-chain (all data is public)
- Using
block.timestamp for randomness (miner/validator influence)
- Ignoring return values from
transfer/send
- Using deprecated tooling (Truffle/Ganache/Brownie)
BEST:
- Run static analysis on every change (for example, Slither and Aderyn)
- Add fuzz/invariant tests before any audit
- Use formal methods for high-value DeFi (for example, Certora and symbolic testing)
LLM Limitations in Smart Contracts
Do not rely on LLMs for:
- Security-critical logic verification
- Gas optimization calculations
- Complex mathematical proofs
Use LLMs for:
- Boilerplate generation (tests, docs)
- Code explanation and review prep
- Initial vulnerability hypotheses (verify manually)
When NOT to Use This Skill
Navigation
Resources
- references/blockchain-best-practices.md - Universal blockchain patterns and security
- references/backend-integration-best-practices.md - .NET/C# crypto integration patterns (CQRS, Kafka, multi-provider)
- references/solidity-best-practices.md - Solidity/EVM-specific guidance
- references/rust-solana-best-practices.md - Solana + Anchor patterns
- references/cosmwasm-best-practices.md - Cosmos/CosmWasm guidance
- references/ton-best-practices.md - TON contracts (Tact/Fift/FunC) and deployment
- references/defi-protocol-patterns.md - AMM, lending, staking, yield farming, flash loans, oracle integration
- references/nft-token-standards.md - ERC-20/721/1155, SPL Token, Metaplex, token gating, metadata
- references/cross-chain-bridges.md - Bridge architectures, LayerZero, Wormhole, IBC, security analysis
- ../software-security-appsec/references/smart-contract-security-auditing.md - Smart contract audit workflows and tools (see software-security-appsec skill)
- data/sources.json - Curated external references per chain
- Shared secure review checklist: ../software-clean-code-standard/assets/checklists/secure-code-review-checklist.md
Templates
- Ethereum/EVM: assets/ethereum/template-solidity-hardhat.md, assets/ethereum/template-solidity-foundry.md
- Solana: assets/solana/template-rust-anchor.md
- Cosmos: assets/cosmos/template-cosmwasm.md
- TON: assets/ton/template-tact-blueprint.md, assets/ton/template-func-blueprint.md
- Bitcoin: assets/bitcoin/template-bitcoin-core.md
Related Skills
- ../software-security-appsec/SKILL.md - Security hardening, threat modeling, OWASP vulnerabilities
- ../software-architecture-design/SKILL.md - System decomposition, modularity, dependency design
- ../ops-devops-platform/SKILL.md - Infrastructure, CI/CD, observability for blockchain nodes
- ../software-backend/SKILL.md - API integration with smart contracts, RPC nodes, indexers
- ../qa-resilience/SKILL.md - Resilience, circuit breakers, retry logic for chains
- ../software-code-review/SKILL.md - Code review patterns and quality gates
- ../dev-api-design/SKILL.md - RESTful design for Web3 APIs and dApp backends
Trend Awareness Protocol
IMPORTANT: When users ask recommendation questions about Web3/crypto development, you MUST use WebSearch to check current trends before answering.
Trigger Conditions
- "What's the best blockchain for [use case]?"
- "What should I use for [smart contracts/DeFi/NFTs]?"
- "What's the latest in Web3 development?"
- "Current best practices for [Solidity/auditing/gas optimization]?"
- "Is [chain/protocol] still relevant in 2026?"
- "[Ethereum] vs [Solana] vs [other L1/L2]?"
- "Best framework for [smart contract development]?"
Required Searches
- Search:
"Web3 development best practices 2026"
- Search:
"[Ethereum/Solana/Base] development updates 2026"
- Search:
"smart contract security 2026"
- Search:
"[Hardhat/Foundry] comparison 2026"
What to Report
After searching, provide:
- Current landscape: What chains/tools are popular NOW
- Emerging trends: New protocols or patterns gaining traction
- Deprecated/declining: Chains or approaches losing relevance
- Recommendation: Based on fresh data and ecosystem activity
Example Topics (verify with fresh search)
- L2 ecosystem growth (Base, Arbitrum, Optimism)
- Solidity vs Rust for smart contracts
- Foundry vs Hardhat tooling
- Account abstraction (ERC-4337) adoption
- Cross-chain bridges and interoperability
- DeFi security patterns and audit practices
Operational Playbooks
- references/operational-playbook.md - Smart contract architecture, security-first workflows, and platform-specific patterns
Fact-Checking
- Use web search/web fetch to verify current external facts, versions, pricing, deadlines, regulations, or platform behavior before final answers.
- Prefer primary sources; report source links and dates for volatile information.
- If web access is unavailable, state the limitation and mark guidance as unverified.
Converted and distributed by TomeVault — claim your Tome and manage your conversions.
1---2name: software-crypto-web33description: Secure blockchain development for EVM, Solana, Cosmos, and TON. Use when building smart contracts, auditing, or integrating on-chain backends. Use when this capability is needed.4---56# Software Crypto/Web3 Engineering78Use 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.910Defaults 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.1112---1314## Quick Reference1516| Task | Tool/Framework | Command | When to Use |17|------|----------------|---------|-------------|18| Solidity Development | Hardhat/Foundry | `npx hardhat init` or `forge init` | Ethereum/EVM smart contracts |19| Solana Programs | Anchor | `anchor init` | Solana blockchain development |20| Cosmos Contracts | CosmWasm | `cargo generate --git cosmwasm-template` | Cosmos ecosystem contracts |21| TON Contracts | Tact/FunC + Blueprint | `npm create ton@latest` | TON blockchain development |22| Testing (Solidity) | Foundry/Hardhat | `forge test` or `npx hardhat test` | Unit, fork, invariant tests |23| Security Audit | Slither/Aderyn/Echidna | `slither .` or `aderyn .` | Static analysis, fuzzing |24| AI-Assisted Review | AI scanners (optional) | N/A | Pre-audit preparation (verify findings manually) |25| Fuzzing | Echidna/Medusa | `echidna .` or `medusa fuzz` | Property-based fuzzing |26| Gas Optimization | Foundry Gas Snapshots | `forge snapshot` | Benchmark and optimize gas |27| Deployment | Hardhat Deploy/Forge Script | `npx hardhat deploy` | Mainnet/testnet deployment |28| Verification | Etherscan API | `npx hardhat verify` | Source code verification |29| Upgradeable Contracts | OpenZeppelin Upgrades | `@openzeppelin/hardhat-upgrades` | Proxy-based upgrades |30| Smart Wallets | ERC-4337, EIP-7702 | Account abstraction SDKs | Smart accounts and sponsored gas (verify network support) |3132## Scope3334Use this skill when you need:3536- Smart contract development (Solidity, Rust, CosmWasm)37- DeFi protocol implementation (AMM, lending, staking, yield farming)38- NFT and token standards (ERC20, ERC721, ERC1155, SPL tokens)39- DAO governance systems40- Cross-chain bridges and interoperability41- Gas optimization and storage patterns42- Smart contract security audits43- Testing strategies (Foundry, Hardhat, Anchor)44- Oracle integration (Chainlink, Pyth)45- Upgradeable contract patterns (proxies, diamonds)46- Web3 frontend integration (ethers.js, web3.js, @solana/web3.js)47- Blockchain indexing (The Graph, subgraphs)48- MEV protection and flashbots49- Layer 2 scaling solutions (Base, Arbitrum, Optimism, zkSync)50- Account abstraction (ERC-4337, EIP-7702, smart wallets)51- **Backend crypto integration** (.NET/C#, multi-provider architecture, CQRS)52- Webhook handling and signature validation (Fireblocks, custodial providers)53- Event-driven architecture with Kafka for crypto payments54- Transaction lifecycle management and monitoring55- Wallet management (custodial vs non-custodial)5657## Decision Tree: Blockchain Platform Selection5859```text60Project needs: [Use Case]61 - EVM-compatible smart contracts?62 - Complex testing needs -> Foundry (fuzzing, invariants, gas snapshots)63 - TypeScript ecosystem -> Hardhat (plugins, TS, Ethers.js/Viem)64 - Enterprise features -> NestJS + Hardhat6566 - High throughput / low fees?67 - Rust-based -> Solana (Anchor)68 - EVM L2 -> Arbitrum/Optimism/Base (Ethereum security, lower gas)69 - Telegram distribution -> TON (Tact/FunC)7071 - Interoperability across chains?72 - Cosmos ecosystem -> CosmWasm (IBC)73 - Multi-chain apps -> LayerZero or Wormhole (verify trust assumptions)74 - Bridge development -> custom (high risk; threat model required)7576 - Token standard implementation?77 - Fungible tokens -> ERC20 (OpenZeppelin), SPL Token (Solana)78 - NFTs -> ERC721/ERC1155 (OpenZeppelin), Metaplex (Solana)79 - Semi-fungible -> ERC1155 (gaming, fractionalized NFTs)8081 - DeFi protocol development?82 - AMM/DEX -> Uniswap V3 fork or custom (concentrated liquidity)83 - Lending -> Compound/Aave fork (collateralized borrowing)84 - Staking/yield -> custom reward distribution contracts8586 - Upgradeable contracts required?87 - Transparent proxy -> OpenZeppelin (admin/user separation)88 - UUPS -> upgrade logic in implementation89 - Diamond -> modular functionality (EIP-2535)9091 - Backend integration?92 - .NET/C# -> multi-provider architecture (see backend integration references)93 - Node.js -> Ethers.js/Viem + durable queues94 - Python -> Web3.py + FastAPI95```9697**Chain-Specific Considerations:**9899- **Ethereum/EVM**: Security-first, higher gas costs, largest ecosystem100- **Solana**: Performance-first, Rust required, lower fees101- **Cosmos**: Interoperability-first, IBC native, growing ecosystem102- **TON**: Telegram-first, async contracts, unique architecture103104See [references/](references/) for chain-specific best practices.105106---107108## Security-First Patterns (Jan 2026)109110> **Security baseline**: Assume an adversarial environment. Treat contracts and signing infrastructure as public, attackable APIs.111112### Custody, Keys, and Signing (Core)113114Key management is a dominant risk driver in production crypto systems. Use a real key management standard as baseline (for example, [NIST SP 800-57](https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-5/final)).115116| Model | Who holds keys | Typical use | Primary risks | Default controls |117|------|-----------------|------------|---------------|------------------|118| Non-custodial | End user wallet | Consumer apps, self-custody | Phishing, approvals, UX errors | Hardware wallet support, clear signing UX, allowlists |119| Custodial | Your service (HSM/MPC) | Exchanges, payments, B2B | Key theft, insider threat, ops mistakes | HSM/MPC, separation of duties, limits/approvals, audit logs |120| Hybrid | Split responsibility | Enterprises | Complex failure modes | Explicit recovery/override paths, runbooks |121122BEST:123- Separate hot/warm/cold signing paths with limits and approvals [Inference]124- Require dual control for high-value transfers (policy engine + human approval) [Inference]125- Keep an immutable audit trail for signing requests (who/what/when/why) [Inference]126127AVOID:128- Storing private keys in databases or application config129- Reusing signing keys across environments (dev/staging/prod)130- Hot-wallet automation without rate limits and circuit breakers [Inference]131132### Checks-Effects-Interactions (CEI) Pattern133134**Mandatory** for all state-changing functions.135136```solidity137// Correct: CEI pattern138function withdraw(uint256 amount) external {139 // 1. CHECKS: Validate conditions140 require(balances[msg.sender] >= amount, "Insufficient balance");141142 // 2. EFFECTS: Update state BEFORE external calls143 balances[msg.sender] -= amount;144145 // 3. INTERACTIONS: External calls LAST146 (bool success, ) = msg.sender.call{value: amount}("");147 require(success, "Transfer failed");148}149150// Wrong: External call before state update (reentrancy risk)151function withdrawUnsafe(uint256 amount) external {152 require(balances[msg.sender] >= amount);153 (bool success, ) = msg.sender.call{value: amount}("");154 require(success);155 balances[msg.sender] -= amount; // Too late!156}157```158159### Security Tools (Jan 2026)160161| Category | Tool | Purpose | When to Use |162|----------|------|---------|-------------|163| Static Analysis | Slither | Vulnerability detection, 92+ detectors | Every contract |164| Static Analysis | Aderyn | Rust-based, faster for large codebases | Large projects |165| Fuzzing | Echidna | Property-based fuzzing | Complex state |166| Fuzzing | Medusa | Parallelized Go fuzzer | CI/CD pipelines |167| Formal Verification | SMTChecker | Built-in Solidity checker | Every contract |168| Formal Verification | Certora | Property-based proofs (CVL) | DeFi, high-value |169| Formal Verification | Halmos | Symbolic testing | Complex invariants |170| AI-Assisted | Sherlock AI | ML vulnerability detection | Pre-audit prep |171| AI-Assisted | Olympix | DevSecOps integration | CI/CD security |172| AI-Assisted | AuditBase | 423+ detectors, LLM-powered | Business logic |173| Mutation Testing | SuMo | Test suite quality assessment | Test validation |174175```solidity176// Certora CVL rule example177rule balanceNeverNegative(address user) {178 env e;179 require balances[user] >= 0;180 deposit(e);181 assert balances[user] >= 0;182}183```184185> **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.186187### MEV Protection188189| Strategy | Implementation |190|----------|----------------|191| Private mempool | Flashbots Protect, MEV Blocker |192| Commit-reveal | Hash commitment, reveal after deadline |193| Batch auctions | CoW Protocol, Gnosis Protocol |194| Encrypted mempools | Shutter Network |195196```solidity197// Commit-reveal pattern198mapping(address => bytes32) public commitments;199200function commit(bytes32 hash) external {201 commitments[msg.sender] = hash;202}203204function reveal(uint256 value, bytes32 salt) external {205 require(206 keccak256(abi.encodePacked(value, salt)) == commitments[msg.sender],207 "Invalid reveal"208 );209 // Process revealed value210}211```212213---214215## Account Abstraction (Jan 2026)216217> **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.218219### ERC-4337 vs EIP-7702220221| Standard | Type | Key Feature | Use Case |222|----------|------|-------------|----------|223| ERC-4337 | Smart contract wallets | Full AA without protocol changes | New wallets, DeFi, gaming |224| EIP-7702 | EOA enhancement | EOAs execute smart contract code | Existing wallets, batch txns |225| ERC-6900 | Modular accounts | Plugin management for AA wallets | Extensible wallet features |226227**ERC-4337 Architecture:**228```text229User -> UserOperation -> Bundler -> EntryPoint -> Smart Account -> Target Contract230 |231 v232 Paymaster (gas sponsorship)233```234235**EIP-7702 (Pectra Upgrade):**236- EOAs can temporarily delegate to smart contracts237- Enables batch transactions, sponsored gas for existing addresses238- Complementary to ERC-4337 (uses same bundler/paymaster infra)239- Supported by Ambire, Trust Wallet, and growing240241**Key Capabilities:**242- **Gasless transactions**: Paymasters sponsor gas in ERC-20 or fiat243- **Batch operations**: Multiple actions in single transaction244- **Social recovery**: Multi-sig or guardian-based key recovery245- **Session keys**: Limited permissions for dApps without full wallet access246247### Smart Wallet Development248249```solidity250// Minimal ERC-4337 Account (simplified)251import "@account-abstraction/contracts/core/BaseAccount.sol";252253contract SimpleAccount is BaseAccount {254 address public owner;255256 function validateUserOp(257 UserOperation calldata userOp,258 bytes32 userOpHash,259 uint256 missingAccountFunds260 ) external override returns (uint256 validationData) {261 // Verify signature262 require(_validateSignature(userOp, userOpHash), "Invalid sig");263 // Pay prefund if needed264 if (missingAccountFunds > 0) {265 (bool success,) = payable(msg.sender).call{value: missingAccountFunds}("");266 require(success);267 }268 return 0; // Valid269 }270}271```272273---274275## Layer 2 Development (Jan 2026)276277> **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.278279### L2 Selection Guide280281| L2 | Type | Best For | Key Feature |282|----|------|----------|-------------|283| Base | Optimistic | Consumer apps, mainstream adoption | Coinbase integration, low fees |284| Arbitrum | Optimistic | DeFi, mature ecosystem | Largest TVL, DAO grants |285| Optimism | Optimistic | Public goods, Superchain | OP Stack, grant programs |286| zkSync Era | ZK-Rollup | Fast finality, native AA | zkEVM, no withdrawal delay |287| StarkNet | ZK-Rollup | Cairo development, ZK-native | STARK proofs, custom VM |288289### Enterprise Rollups (2025-2026 Trend)290291Major institutions launching L2s on OP Stack:292- **Kraken INK** - Exchange-native L2293- **Uniswap UniChain** - DeFi-optimized294- **Sony Soneium** - Gaming and media295- **Robinhood** - Arbitrum integration296297### EIP-4844 Blob Optimization298299Since March 2024, rollups use blob-based data posting:300```text301Before: calldata posting -> expensive302After: blob posting -> lower data availability cost303```304305Optimism, zkSync optimized batching for blobs in 2025.306307---308309## Common Mistakes (2025-2026)310311> **Reality check**: Exploits regularly cause large losses. Access control, signing/custody, and integration bugs remain top incident drivers.312313| Mistake | Impact | Prevention |314|---------|--------|------------|315| **Missing access control** | Unauthorized admin actions | Use OpenZeppelin `Ownable2Step`, `AccessControl` |316| **Reentrancy** | Drain funds via callback | CEI pattern, `ReentrancyGuard`, Slither checks |317| **Unchecked external calls** | Silent failures | Always check return values, use `SafeERC20` |318| **Integer overflow (pre-0.8)** | Arbitrary value manipulation | Use Solidity 0.8.x+ (built-in checks) |319| **Frontrunning** | MEV extraction, sandwich attacks | Commit-reveal, Flashbots Protect, private mempool |320| **Oracle manipulation** | Price feed attacks | TWAP, multiple oracles, sanity bounds |321| **Improper initialization** | Proxy takeover | Use `initializer` modifier, `_disableInitializers()` |322| **Storage collision (proxies)** | Data corruption | Follow EIP-1967 slots, use OpenZeppelin upgrades |323324### Anti-Patterns to Avoid325326AVOID:327- Using `tx.origin` for authorization (phishing risk)328- Storing secrets on-chain (all data is public)329- Using `block.timestamp` for randomness (miner/validator influence)330- Ignoring return values from `transfer`/`send`331- Using deprecated tooling (Truffle/Ganache/Brownie)332333BEST:334- Run static analysis on every change (for example, Slither and Aderyn)335- Add fuzz/invariant tests before any audit336- Use formal methods for high-value DeFi (for example, Certora and symbolic testing)337338---339340### LLM Limitations in Smart Contracts341342**Do not rely on LLMs for:**343344- Security-critical logic verification345- Gas optimization calculations346- Complex mathematical proofs347348**Use LLMs for:**349350- Boilerplate generation (tests, docs)351- Code explanation and review prep352- Initial vulnerability hypotheses (verify manually)353354---355356## When NOT to Use This Skill357358- **Traditional backend without blockchain** -> Use [software-backend](../software-backend/SKILL.md)359- **Pure API design without Web3** -> Use [dev-api-design](../dev-api-design/SKILL.md)360- **General security without smart contracts** -> Use [software-security-appsec](../software-security-appsec/SKILL.md)361- **Frontend-only dApp UI** -> Use [software-frontend](../software-frontend/SKILL.md) + Web3 libraries362363---364365## Navigation366367**Resources**368369- [references/blockchain-best-practices.md](references/blockchain-best-practices.md) - Universal blockchain patterns and security370- [references/backend-integration-best-practices.md](references/backend-integration-best-practices.md) - .NET/C# crypto integration patterns (CQRS, Kafka, multi-provider)371- [references/solidity-best-practices.md](references/solidity-best-practices.md) - Solidity/EVM-specific guidance372- [references/rust-solana-best-practices.md](references/rust-solana-best-practices.md) - Solana + Anchor patterns373- [references/cosmwasm-best-practices.md](references/cosmwasm-best-practices.md) - Cosmos/CosmWasm guidance374- [references/ton-best-practices.md](references/ton-best-practices.md) - TON contracts (Tact/Fift/FunC) and deployment375- [references/defi-protocol-patterns.md](references/defi-protocol-patterns.md) - AMM, lending, staking, yield farming, flash loans, oracle integration376- [references/nft-token-standards.md](references/nft-token-standards.md) - ERC-20/721/1155, SPL Token, Metaplex, token gating, metadata377- [references/cross-chain-bridges.md](references/cross-chain-bridges.md) - Bridge architectures, LayerZero, Wormhole, IBC, security analysis378- [../software-security-appsec/references/smart-contract-security-auditing.md](../software-security-appsec/references/smart-contract-security-auditing.md) - Smart contract audit workflows and tools (see software-security-appsec skill)379- [data/sources.json](data/sources.json) - Curated external references per chain380- Shared secure review checklist: [../software-clean-code-standard/assets/checklists/secure-code-review-checklist.md](../software-clean-code-standard/assets/checklists/secure-code-review-checklist.md)381382**Templates**383- Ethereum/EVM: [assets/ethereum/template-solidity-hardhat.md](assets/ethereum/template-solidity-hardhat.md), [assets/ethereum/template-solidity-foundry.md](assets/ethereum/template-solidity-foundry.md)384- Solana: [assets/solana/template-rust-anchor.md](assets/solana/template-rust-anchor.md)385- Cosmos: [assets/cosmos/template-cosmwasm.md](assets/cosmos/template-cosmwasm.md)386- TON: [assets/ton/template-tact-blueprint.md](assets/ton/template-tact-blueprint.md), [assets/ton/template-func-blueprint.md](assets/ton/template-func-blueprint.md)387- Bitcoin: [assets/bitcoin/template-bitcoin-core.md](assets/bitcoin/template-bitcoin-core.md)388389**Related Skills**390391- [../software-security-appsec/SKILL.md](../software-security-appsec/SKILL.md) - Security hardening, threat modeling, OWASP vulnerabilities392- [../software-architecture-design/SKILL.md](../software-architecture-design/SKILL.md) - System decomposition, modularity, dependency design393- [../ops-devops-platform/SKILL.md](../ops-devops-platform/SKILL.md) - Infrastructure, CI/CD, observability for blockchain nodes394- [../software-backend/SKILL.md](../software-backend/SKILL.md) - API integration with smart contracts, RPC nodes, indexers395- [../qa-resilience/SKILL.md](../qa-resilience/SKILL.md) - Resilience, circuit breakers, retry logic for chains396- [../software-code-review/SKILL.md](../software-code-review/SKILL.md) - Code review patterns and quality gates397- [../dev-api-design/SKILL.md](../dev-api-design/SKILL.md) - RESTful design for Web3 APIs and dApp backends398399---400401## Trend Awareness Protocol402403**IMPORTANT**: When users ask recommendation questions about Web3/crypto development, you MUST use WebSearch to check current trends before answering.404405### Trigger Conditions406407- "What's the best blockchain for [use case]?"408- "What should I use for [smart contracts/DeFi/NFTs]?"409- "What's the latest in Web3 development?"410- "Current best practices for [Solidity/auditing/gas optimization]?"411- "Is [chain/protocol] still relevant in 2026?"412- "[Ethereum] vs [Solana] vs [other L1/L2]?"413- "Best framework for [smart contract development]?"414415### Required Searches4164171. Search: `"Web3 development best practices 2026"`4182. Search: `"[Ethereum/Solana/Base] development updates 2026"`4193. Search: `"smart contract security 2026"`4204. Search: `"[Hardhat/Foundry] comparison 2026"`421422### What to Report423424After searching, provide:425426- **Current landscape**: What chains/tools are popular NOW427- **Emerging trends**: New protocols or patterns gaining traction428- **Deprecated/declining**: Chains or approaches losing relevance429- **Recommendation**: Based on fresh data and ecosystem activity430431### Example Topics (verify with fresh search)432433- L2 ecosystem growth (Base, Arbitrum, Optimism)434- Solidity vs Rust for smart contracts435- Foundry vs Hardhat tooling436- Account abstraction (ERC-4337) adoption437- Cross-chain bridges and interoperability438- DeFi security patterns and audit practices439440---441442## Operational Playbooks443- [references/operational-playbook.md](references/operational-playbook.md) - Smart contract architecture, security-first workflows, and platform-specific patterns444445## Fact-Checking446447- Use web search/web fetch to verify current external facts, versions, pricing, deadlines, regulations, or platform behavior before final answers.448- Prefer primary sources; report source links and dates for volatile information.449- If web access is unavailable, state the limitation and mark guidance as unverified.450451---452> Converted and distributed by [TomeVault](https://tomevault.io/claim/vasilyu1983) — claim your Tome and manage your conversions.453<!-- tomevault:4.0:skill_md:2026-04-11 -->