Blockchain & Web3 Development Skill — Quick Reference
This skill equips blockchain developers with execution-ready patterns for building secure, gas-optimized smart contracts and decentralized applications. Apply these patterns when you need smart contract development, DeFi protocols, NFT implementations, security audits, or Web3 architecture.
Modern Best Practices (Jan 2026): Solidity 0.8.33+, security-first development, explicit threat models, comprehensive testing (unit, integration, fork, invariant), audits/formal methods where warranted, 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/Mythril/Echidna |
slither . |
Static analysis, 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 |
When to Use This Skill
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 (Optimism, Arbitrum, zkSync)
- 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 (Solidity tests, fuzzing, gas snapshots)
│ ├─ TypeScript ecosystem → Hardhat (plugins, TypeScript, Ethers.js)
│ └─ Enterprise features → NestJS + Hardhat
│
├─ High throughput/low fees?
│ ├─ Rust-based → Solana (Anchor framework)
│ ├─ EVM L2 → Arbitrum/Optimism (Ethereum security, lower gas)
│ └─ Telegram integration → TON (Tact/FunC contracts)
│
├─ Interoperability across chains?
│ ├─ Cosmos ecosystem → CosmWasm (IBC protocol)
│ ├─ Multi-chain DeFi → LayerZero or Wormhole
│ └─ Bridge development → Custom bridge contracts
│
├─ 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 (x*y=k, concentrated liquidity)
│ ├─ Lending → Compound/Aave fork (collateralized borrowing)
│ └─ Staking/Yield → Custom reward distribution contracts
│
├─ Upgradeable contracts required?
│ ├─ Transparent Proxy → OpenZeppelin (admin/user separation)
│ ├─ UUPS → Gas-efficient (upgrade logic in implementation)
│ └─ Diamond Standard → Modular functionality (EIP-2535)
│
└─ Backend integration?
├─ .NET/C# → Multi-provider architecture (see Backend Integration Patterns)
├─ Node.js → Ethers.js/Web3.js + Prisma
└─ 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 resources/ 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 the dominant risk driver in production crypto systems. Use general key management guidance as a baseline (NIST SP 800-57) https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-5/final
| 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 |
Do:
- 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!
}
Formal Verification
| Tool |
Purpose |
When to Use |
| SMTChecker |
Built-in Solidity checker |
Every contract |
| Certora |
Property-based verification |
DeFi protocols, high-value |
| Halmos |
Symbolic testing |
Complex invariants |
// Certora CVL rule example
rule balanceNeverNegative(address user) {
env e;
require balances[user] >= 0;
deposit(e);
assert balances[user] >= 0;
}
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
}
Optional: AI/Automation Extensions
Note: AI-assisted smart contract tools. Skip if not using AI tooling.
AI-Assisted Auditing
| Tool |
Purpose |
| Slither AI |
Enhanced static analysis |
| Olympix |
AI vulnerability detection |
| Auditless |
Automated audit reports |
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)
Navigation
Resources
- resources/blockchain-best-practices.md — Universal blockchain patterns and security
- resources/backend-integration-best-practices.md — .NET/C# crypto integration patterns (CQRS, Kafka, multi-provider)
- resources/solidity-best-practices.md — Solidity/EVM-specific guidance
- resources/rust-solana-best-practices.md — Solana + Anchor patterns
- resources/cosmwasm-best-practices.md — Cosmos/CosmWasm guidance
- resources/ton-best-practices.md — TON contracts (Tact/Fift/FunC) and deployment
- ../software-security-appsec/resources/smart-contract-security-auditing.md — Smart contract audit workflows and tools (see software-security-appsec skill)
- README.md — Folder overview and usage notes
- data/sources.json — Curated external references per chain
- Shared secure review checklist: ../software-clean-code-standard/templates/checklists/secure-code-review-checklist.md
Templates
- Ethereum/EVM: templates/ethereum/template-solidity-hardhat.md, templates/ethereum/template-solidity-foundry.md
- Solana: templates/solana/template-rust-anchor.md
- Cosmos: templates/cosmos/template-cosmwasm.md
- TON: templates/ton/template-tact-blueprint.md, templates/ton/template-func-blueprint.md
- Bitcoin: templates/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
Operational Playbooks
- resources/operational-playbook.md — Smart contract architecture, security-first workflows, and platform-specific patterns
1---2name: software-crypto-web3-23description: Production-grade blockchain and Web3 development with Solidity (Ethereum/EVM), Rust (Solana), CosmWasm (Cosmos), including smart contract architecture, security patterns, gas optimization, testing strategies, DeFi protocols, and deployment workflows.4---5
6# Blockchain & Web3 Development Skill — Quick Reference
7
8This skill equips blockchain developers with execution-ready patterns for building secure, gas-optimized smart contracts and decentralized applications. Apply these patterns when you need smart contract development, DeFi protocols, NFT implementations, security audits, or Web3 architecture.
9
10**Modern Best Practices (Jan 2026)**: Solidity 0.8.33+, security-first development, explicit threat models, comprehensive testing (unit, integration, fork, invariant), audits/formal methods where warranted, upgrade safety (timelocks, governance, rollback plans), and defense-in-depth for key custody and signing.
11
12---
13
14## Quick Reference
15
16| 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/Mythril/Echidna | `slither .` | Static analysis, fuzzing |
24| Gas Optimization | Foundry Gas Snapshots | `forge snapshot` | Benchmark and optimize gas |
25| Deployment | Hardhat Deploy/Forge Script | `npx hardhat deploy` | Mainnet/testnet deployment |
26| Verification | Etherscan API | `npx hardhat verify` | Source code verification |
27| Upgradeable Contracts | OpenZeppelin Upgrades | `@openzeppelin/hardhat-upgrades` | Proxy-based upgrades |
28
29# When to Use This Skill
30
31Use this skill when you need:
32
33- Smart contract development (Solidity, Rust, CosmWasm)
34- DeFi protocol implementation (AMM, lending, staking, yield farming)
35- NFT and token standards (ERC20, ERC721, ERC1155, SPL tokens)
36- DAO governance systems
37- Cross-chain bridges and interoperability
38- Gas optimization and storage patterns
39- Smart contract security audits
40- Testing strategies (Foundry, Hardhat, Anchor)
41- Oracle integration (Chainlink, Pyth)
42- Upgradeable contract patterns (proxies, diamonds)
43- Web3 frontend integration (ethers.js, web3.js, @solana/web3.js)
44- Blockchain indexing (The Graph, subgraphs)
45- MEV protection and flashbots
46- Layer 2 scaling solutions (Optimism, Arbitrum, zkSync)
47- **Backend crypto integration** (.NET/C#, multi-provider architecture, CQRS)
48- Webhook handling and signature validation (Fireblocks, custodial providers)
49- Event-driven architecture with Kafka for crypto payments
50- Transaction lifecycle management and monitoring
51- Wallet management (custodial vs non-custodial)
52
53## Decision Tree: Blockchain Platform Selection
54
55```text
56Project needs: [Use Case]
57 ├─ EVM-compatible smart contracts?
58 │ ├─ Complex testing needs → Foundry (Solidity tests, fuzzing, gas snapshots)
59 │ ├─ TypeScript ecosystem → Hardhat (plugins, TypeScript, Ethers.js)
60 │ └─ Enterprise features → NestJS + Hardhat
61 │
62 ├─ High throughput/low fees?
63 │ ├─ Rust-based → Solana (Anchor framework)
64 │ ├─ EVM L2 → Arbitrum/Optimism (Ethereum security, lower gas)
65 │ └─ Telegram integration → TON (Tact/FunC contracts)
66 │
67 ├─ Interoperability across chains?
68 │ ├─ Cosmos ecosystem → CosmWasm (IBC protocol)
69 │ ├─ Multi-chain DeFi → LayerZero or Wormhole
70 │ └─ Bridge development → Custom bridge contracts
71 │
72 ├─ Token standard implementation?
73 │ ├─ Fungible tokens → ERC20 (OpenZeppelin), SPL Token (Solana)
74 │ ├─ NFTs → ERC721/ERC1155 (OpenZeppelin), Metaplex (Solana)
75 │ └─ Semi-fungible → ERC1155 (gaming, fractionalized NFTs)
76 │
77 ├─ DeFi protocol development?
78 │ ├─ AMM/DEX → Uniswap V3 fork or custom (x*y=k, concentrated liquidity)
79 │ ├─ Lending → Compound/Aave fork (collateralized borrowing)
80 │ └─ Staking/Yield → Custom reward distribution contracts
81 │
82 ├─ Upgradeable contracts required?
83 │ ├─ Transparent Proxy → OpenZeppelin (admin/user separation)
84 │ ├─ UUPS → Gas-efficient (upgrade logic in implementation)
85 │ └─ Diamond Standard → Modular functionality (EIP-2535)
86 │
87 └─ Backend integration?
88 ├─ .NET/C# → Multi-provider architecture (see Backend Integration Patterns)
89 ├─ Node.js → Ethers.js/Web3.js + Prisma
90 └─ Python → Web3.py + FastAPI
91```
92
93**Chain-Specific Considerations:**
94
95- **Ethereum/EVM**: Security-first, higher gas costs, largest ecosystem
96- **Solana**: Performance-first, Rust required, lower fees
97- **Cosmos**: Interoperability-first, IBC native, growing ecosystem
98- **TON**: Telegram-first, async contracts, unique architecture
99
100See [resources/](resources/) for chain-specific best practices.
101
102---
103
104## Security-First Patterns (Jan 2026)
105
106> **Security baseline**: Assume an adversarial environment. Treat contracts and signing infrastructure as public, attackable APIs.
107
108### Custody, Keys, and Signing (Core)
109
110Key management is the dominant risk driver in production crypto systems. Use general key management guidance as a baseline (NIST SP 800-57) https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-5/final
111
112| Model | Who holds keys | Typical use | Primary risks | Default controls |
113|------|-----------------|------------|---------------|------------------|
114| Non-custodial | End user wallet | Consumer apps, self-custody | Phishing, approvals, UX errors | Hardware wallet support, clear signing UX, allowlists |
115| Custodial | Your service (HSM/MPC) | Exchanges, payments, B2B | Key theft, insider threat, ops mistakes | HSM/MPC, separation of duties, limits/approvals, audit logs |
116| Hybrid | Split responsibility | Enterprises | Complex failure modes | Explicit recovery/override paths, runbooks |
117
118Do:
119- Separate hot/warm/cold signing paths with limits and approvals [Inference]
120- Require dual control for high-value transfers (policy engine + human approval) [Inference]
121- Keep an immutable audit trail for signing requests (who/what/when/why) [Inference]
122
123Avoid:
124- Storing private keys in databases or application config
125- Reusing signing keys across environments (dev/staging/prod)
126- Hot-wallet automation without rate limits and circuit breakers [Inference]
127
128### Checks-Effects-Interactions (CEI) Pattern
129
130**Mandatory** for all state-changing functions.
131
132```solidity
133// Correct: CEI pattern
134function withdraw(uint256 amount) external {
135 // 1. CHECKS: Validate conditions
136 require(balances[msg.sender] >= amount, "Insufficient balance");
137
138 // 2. EFFECTS: Update state BEFORE external calls
139 balances[msg.sender] -= amount;
140
141 // 3. INTERACTIONS: External calls LAST
142 (bool success, ) = msg.sender.call{value: amount}("");
143 require(success, "Transfer failed");
144}
145
146// Wrong: External call before state update (reentrancy risk)
147function withdrawUnsafe(uint256 amount) external {
148 require(balances[msg.sender] >= amount);
149 (bool success, ) = msg.sender.call{value: amount}("");
150 require(success);
151 balances[msg.sender] -= amount; // Too late!
152}
153```
154
155### Formal Verification
156
157| Tool | Purpose | When to Use |
158|------|---------|-------------|
159| SMTChecker | Built-in Solidity checker | Every contract |
160| Certora | Property-based verification | DeFi protocols, high-value |
161| Halmos | Symbolic testing | Complex invariants |
162
163```solidity
164// Certora CVL rule example
165rule balanceNeverNegative(address user) {
166 env e;
167 require balances[user] >= 0;
168 deposit(e);
169 assert balances[user] >= 0;
170}
171```
172
173### MEV Protection
174
175| Strategy | Implementation |
176|----------|----------------|
177| Private mempool | Flashbots Protect, MEV Blocker |
178| Commit-reveal | Hash commitment, reveal after deadline |
179| Batch auctions | CoW Protocol, Gnosis Protocol |
180| Encrypted mempools | Shutter Network |
181
182```solidity
183// Commit-reveal pattern
184mapping(address => bytes32) public commitments;
185
186function commit(bytes32 hash) external {
187 commitments[msg.sender] = hash;
188}
189
190function reveal(uint256 value, bytes32 salt) external {
191 require(
192 keccak256(abi.encodePacked(value, salt)) == commitments[msg.sender],
193 "Invalid reveal"
194 );
195 // Process revealed value
196}
197```
198
199---
200
201### Optional: AI/Automation Extensions
202
203> **Note**: AI-assisted smart contract tools. Skip if not using AI tooling.
204
205#### AI-Assisted Auditing
206
207| Tool | Purpose |
208|------|---------|
209| Slither AI | Enhanced static analysis |
210| Olympix | AI vulnerability detection |
211| Auditless | Automated audit reports |
212
213#### LLM Limitations in Smart Contracts
214
215**Do not rely on LLMs for:**
216
217- Security-critical logic verification
218- Gas optimization calculations
219- Complex mathematical proofs
220
221**Use LLMs for:**
222
223- Boilerplate generation (tests, docs)
224- Code explanation and review prep
225- Initial vulnerability hypotheses (verify manually)
226
227---
228
229## Navigation
230
231**Resources**
232
233- [resources/blockchain-best-practices.md](resources/blockchain-best-practices.md) — Universal blockchain patterns and security
234- [resources/backend-integration-best-practices.md](resources/backend-integration-best-practices.md) — .NET/C# crypto integration patterns (CQRS, Kafka, multi-provider)
235- [resources/solidity-best-practices.md](resources/solidity-best-practices.md) — Solidity/EVM-specific guidance
236- [resources/rust-solana-best-practices.md](resources/rust-solana-best-practices.md) — Solana + Anchor patterns
237- [resources/cosmwasm-best-practices.md](resources/cosmwasm-best-practices.md) — Cosmos/CosmWasm guidance
238- [resources/ton-best-practices.md](resources/ton-best-practices.md) — TON contracts (Tact/Fift/FunC) and deployment
239- [../software-security-appsec/resources/smart-contract-security-auditing.md](../software-security-appsec/resources/smart-contract-security-auditing.md) — Smart contract audit workflows and tools (see software-security-appsec skill)
240- [README.md](README.md) — Folder overview and usage notes
241- [data/sources.json](data/sources.json) — Curated external references per chain
242- Shared secure review checklist: [../software-clean-code-standard/templates/checklists/secure-code-review-checklist.md](../software-clean-code-standard/templates/checklists/secure-code-review-checklist.md)
243
244**Templates**
245- Ethereum/EVM: [templates/ethereum/template-solidity-hardhat.md](templates/ethereum/template-solidity-hardhat.md), [templates/ethereum/template-solidity-foundry.md](templates/ethereum/template-solidity-foundry.md)
246- Solana: [templates/solana/template-rust-anchor.md](templates/solana/template-rust-anchor.md)
247- Cosmos: [templates/cosmos/template-cosmwasm.md](templates/cosmos/template-cosmwasm.md)
248- TON: [templates/ton/template-tact-blueprint.md](templates/ton/template-tact-blueprint.md), [templates/ton/template-func-blueprint.md](templates/ton/template-func-blueprint.md)
249- Bitcoin: [templates/bitcoin/template-bitcoin-core.md](templates/bitcoin/template-bitcoin-core.md)
250
251**Related Skills**
252
253- [../software-security-appsec/SKILL.md](../software-security-appsec/SKILL.md) — Security hardening, threat modeling, OWASP vulnerabilities
254- [../software-architecture-design/SKILL.md](../software-architecture-design/SKILL.md) — System decomposition, modularity, dependency design
255- [../ops-devops-platform/SKILL.md](../ops-devops-platform/SKILL.md) — Infrastructure, CI/CD, observability for blockchain nodes
256- [../software-backend/SKILL.md](../software-backend/SKILL.md) — API integration with smart contracts, RPC nodes, indexers
257- [../qa-resilience/SKILL.md](../qa-resilience/SKILL.md) — Resilience, circuit breakers, retry logic for chains
258- [../software-code-review/SKILL.md](../software-code-review/SKILL.md) — Code review patterns and quality gates
259- [../dev-api-design/SKILL.md](../dev-api-design/SKILL.md) — RESTful design for Web3 APIs and dApp backends
260
261---
262
263## Operational Playbooks
264- [resources/operational-playbook.md](resources/operational-playbook.md) — Smart contract architecture, security-first workflows, and platform-specific patterns