Software Crypto Web3

Software Crypto/Web3 Engineering

Use this skill to design, implement, and review production blockchain systems: contracts and programs, signing and custody, protocol integrations, testing, audits, and operational controls.

Defaults to:

• Security-first design with explicit threat models
• Comprehensive testing: unit, integration, fork/simulation, fuzzing, invariants
• Formal methods for high-value paths
• Conservative key custody and signing controls
• Fresh web verification for volatile ecosystem facts

Quick Reference

When to Use This Skill

• Smart contract and blockchain program development
• DeFi, token, NFT, governance, and bridge integrations
• Backend crypto infrastructure, custody, and signing workflows
• Chain and framework tradeoff analysis
• Security reviews, audit preparation, and production hardening

When NOT to Use This Skill

• General backend work with no blockchain component → software-backend
• Pure frontend UI work with no wallet/protocol integration → software-frontend
• Generic application security outside smart contracts and crypto ops → software-security-appsec

Workflow

1. Identify the chain, product surface, custody model, and attack surface before recommending tooling.
2. Route generic backend, frontend, or non-crypto AppSec work to the adjacent skill when blockchain is incidental.
3. Pick the smallest viable protocol or framework from the decision tree.
4. Apply execution defaults for contracts, signing, settlement, and operational controls before discussing implementation detail.
5. Re-check volatile ecosystem claims, network support, and tool maturity with the navigation sources before final guidance.

ASCII Flow

Crypto or Web3 task
  -> Define asset, chain, wallet, contract, or custody boundary
  -> Classify risk: key, transaction, smart contract, bridge, or compliance
  -> Design least-privilege signing and replay protection
  -> Add monitoring, rollback, and incident response hooks
  -> Verify current protocol, wallet, and chain behavior
  -> Hand off legal or audit needs explicitly

Decision Tree

Choose the smallest surface area that meets the product need:

• EVM if ecosystem depth, audits, and tooling maturity dominate
• Solana if throughput and low fees dominate and the team can operate Rust safely
• CosmWasm if IBC-native interoperability is a core requirement
• TON if Telegram-native distribution is a product requirement
• Bitcoin/Lightning if the system is payment-settlement or wallet heavy rather than contract heavy

Prefer:

• Foundry for EVM testing, fuzzing, invariants, and gas snapshots
• Hardhat when plugin ecosystem or TS-heavy workflows are the real driver
• Latest stable Solidity 0.8.x (0.8.36 as of July 2026 — always confirm at soliditylang.org/releases; the patch version moves roughly monthly) for transient storage (EIP-1153), Pectra/Fusaka-era EVM features, and ERC-7201 namespace builtins
• ERC-7702 for EOA migration (retains existing address history, live since Pectra mainnet activation May 2025); ERC-4337 for new smart accounts or when full bundler/paymaster infrastructure is required — the two are complementary and increasingly deployed together, not mutually exclusive
• Chainlink CCIP when bridge security (independent Risk Management Network) is the top priority; LayerZero or Wormhole for broader chain coverage — verify current DVN/guardian set and audit status before trusting a bridge with material value
• L2s only after verifying current network support, bridge assumptions, and operational maturity — Arbitrum One and Base currently account for roughly three-quarters of L2 DeFi liquidity, with OP Mainnet, Starknet, Linea, and zkSync Era trailing; treat any specific TVL/market-share figure as a snapshot to re-verify, not a durable fact
• Existing audited protocol components over custom bridge or custom cryptography work

Execution Defaults

• Treat contracts, signing services, and webhook endpoints as public attack surfaces
• Require idempotency for deposit, withdrawal, and settlement handlers
• Separate read paths from transaction-submission paths
• Rate-limit hot wallet automation and require approvals for high-risk transfers
• Prefer allowlists, timelocks, pausability, and rollback plans where they reduce blast radius
• Never trust ecosystem popularity claims without fresh verification

Pre-Deploy Security Checklist

Before deploying a contract or custody flow to production:

• [ ] Reentrancy guards on all external-call paths (CEI pattern or ReentrancyGuard)
• [ ] Access control: every privileged function has an explicit owner/role check
• [ ] Integer overflow: confirmed Solidity 0.8+ or explicit SafeMath used throughout
• [ ] Replay protection: nonces or EIP-712 domain separator on all signed payloads
• [ ] Deposit/withdrawal handlers: idempotency key, confirmation threshold, and DLQ defined
• [ ] Oracle inputs: freshness check (max age); no single source of price truth
• [ ] Emergency controls: pause mechanism or time-lock tested in rehearsal
• [ ] Upgrade path: proxy admin key held by multisig, not EOA; upgrade procedure documented
• [ ] Fuzz and invariant tests pass with ≥ 10,000 runs (Echidna or Foundry)

Custody, Key Management, and On-Chain Judgment

• When NOT to put something on-chain: personally identifiable data, anything requiring later deletion/correction (right-to-erasure conflicts), high-frequency state that is cheaper and equally trustworthy off-chain with a periodic on-chain checkpoint/root, and business logic whose only requirement is internal auditability rather than public verifiability or trustless settlement. On-chain is a cost/trust tradeoff, not a default.
• Custody decision gates:
• Solo/EOA signing — prototypes and non-custodial personal wallets only; never for pooled user funds.
• Multisig (Safe or equivalent) — the default for treasury and admin/upgrade keys; transparent on-chain quorum, but every signer's device and review discipline becomes part of the trust boundary (see Bybit below).
• MPC (threshold signatures) — preferred for hot-wallet operational signing at scale: no single key material ever exists in one place, policy engines can gate transactions pre-signature, and key rotation doesn't require an on-chain migration. Higher implementation and vendor-trust complexity than multisig.
• HSM — for cold/root keys and where a compliance regime requires FIPS-validated hardware custody; pair with M-of-N operator access, not a single operator.