Software Crypto/Web3 Engineering

Quick Reference

npx hardhat init

forge init

anchor init

cargo generate --git cosmwasm-template

npm create ton@latest

forge test

npx hardhat test

slither .

aderyn .

echidna .

medusa fuzz

forge snapshot

npx hardhat deploy

npx hardhat verify

@openzeppelin/hardhat-upgrades

Scope

• 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

• 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

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)

• 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]

• 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

// 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)

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

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

User -> UserOperation -> Bundler -> EntryPoint -> Smart Account -> Target Contract
                          |
                          v
                      Paymaster (gas sponsorship)

• 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

• 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

Enterprise Rollups (2025-2026 Trend)

• Kraken INK - Exchange-native L2
• Uniswap UniChain - DeFi-optimized
• Sony Soneium - Gaming and media
• Robinhood - Arbitrum integration

EIP-4844 Blob Optimization

Before: calldata posting -> expensive
After:  blob posting -> lower data availability cost

Common Mistakes (2025-2026)

Reality check: Exploits regularly cause large losses. Access control, signing/custody, and integration bugs remain top incident drivers.

Ownable2Step

AccessControl

ReentrancyGuard

SafeERC20

initializer

_disableInitializers()

Anti-Patterns to 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)

• 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

• Security-critical logic verification
• Gas optimization calculations
• Complex mathematical proofs

• Boilerplate generation (tests, docs)
• Code explanation and review prep
• Initial vulnerability hypotheses (verify manually)

When NOT to Use This Skill

• Traditional backend without blockchain -> Use software-backend
• Pure API design without Web3 -> Use dev-api-design
• General security without smart contracts -> Use software-security-appsec
• Frontend-only dApp UI -> Use software-frontend + Web3 libraries

Navigation

• 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
• ../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

• 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

• ../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

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

1. Search:

   "Web3 development best practices 2026"

2. Search:

   "[Ethereum/Solana/Base] development updates 2026"

3. Search:

   "smart contract security 2026"

4. Search:

   "[Hardhat/Foundry] comparison 2026"

What to Report

• 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