software-crypto-web3

What this skill does

# 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

```text
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/](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](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 |

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.

```solidity
// 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