Specialist Blockchain Developer

An autonomous agent that builds blockchain applications — developing smart contracts, implementing DeFi protocols, integrating wallets, and deploying to EVM-compatible chains with security best practices.

When to Use This Agent

Choose Specialist Blockchain Developer when:

• You are developing smart contracts in Solidity for EVM chains
• You need to build DeFi protocols (AMMs, lending, staking)
• You want to integrate Web3 wallets (MetaMask, WalletConnect) into your frontend
• You need smart contract security patterns and audit preparation

Consider alternatives when:

• You need non-EVM blockchain development (Solana, Cosmos) — use chain-specific tools
• You are purely investing/trading and need market analysis
• You need legal or regulatory compliance advice for crypto

Quick Start

Copy
# .claude/agents/blockchain-developer.yml
name: specialist-blockchain-developer
description: Build blockchain applications and smart contracts
agent_prompt: |
  You are a Blockchain Developer. When building blockchain apps:

  1. Write secure smart contracts following OpenZeppelin patterns
  2. Implement proper access control and upgrade patterns
  3. Use Hardhat/Foundry for development and testing
  4. Integrate wallets and handle chain interactions safely
  5. Deploy with proper verification and monitoring
  6. Prepare for security audits

  Security rules:
  - ALWAYS use ReentrancyGuard on external calls
  - ALWAYS validate inputs with require statements
  - NEVER use tx.origin for authentication
  - ALWAYS test with coverage > 95%

Example invocation:

Copy
claude "Build an ERC-721 NFT contract with lazy minting, royalties, and metadata on IPFS"

Sample contract output:

Copy
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
import "@openzeppelin/contracts/token/common/ERC2981.sol";
import "@openzeppelin/contracts/utils/cryptography/EIP712.sol";
import "@openzeppelin/contracts/utils/cryptography/ECDSA.sol";

contract LazyMintNFT is ERC721, ERC2981, EIP712 {
    using ECDSA for bytes32;

    address public minter;
    mapping(uint256 => string) private _tokenURIs;
    mapping(uint256 => bool) private _minted;

    struct MintVoucher {
        uint256 tokenId;
        string uri;
        uint256 price;
        address creator;
    }

    constructor() ERC721("LazyNFT", "LNFT") EIP712("LazyNFT", "1") {
        minter = msg.sender;
        _setDefaultRoyalty(msg.sender, 500); // 5% royalty
    }

    function lazyMint(MintVoucher calldata voucher, bytes calldata signature)
        external payable
    {
        require(!_minted[voucher.tokenId], "Already minted");
        require(msg.value >= voucher.price, "Insufficient payment");

        bytes32 digest = _hashTypedDataV4(keccak256(abi.encode(
            keccak256("MintVoucher(uint256 tokenId,string uri,uint256 price,address creator)"),
            voucher.tokenId, keccak256(bytes(voucher.uri)), voucher.price, voucher.creator
        )));
        require(digest.recover(signature) == minter, "Invalid signature");

        _minted[voucher.tokenId] = true;
        _mint(msg.sender, voucher.tokenId);
        _tokenURIs[voucher.tokenId] = voucher.uri;
    }
}

Core Concepts

Smart Contract Development Stack

Tool	Purpose	Usage
Solidity	Smart contract language	Contract implementation
Hardhat	Development framework	Compile, test, deploy
Foundry	Fast testing framework	Fuzz testing, gas analysis
OpenZeppelin	Audited contract library	ERC standards, access control
IPFS/Arweave	Decentralized storage	Metadata, images
Ethers.js/Viem	JavaScript client	Frontend integration

Security Patterns

Copy
// Essential security patterns

// 1. Reentrancy Guard
import "@openzeppelin/contracts/utils/ReentrancyGuard.sol";

contract SecureContract is ReentrancyGuard {
    function withdraw() external nonReentrant {
        uint256 balance = balances[msg.sender];
        balances[msg.sender] = 0;  // State change BEFORE external call
        (bool success,) = msg.sender.call{value: balance}("");
        require(success, "Transfer failed");
    }
}

// 2. Access Control
import "@openzeppelin/contracts/access/AccessControl.sol";

contract Managed is AccessControl {
    bytes32 public constant ADMIN_ROLE = keccak256("ADMIN_ROLE");

    constructor() {
        _grantRole(DEFAULT_ADMIN_ROLE, msg.sender);
    }

    function adminFunction() external onlyRole(ADMIN_ROLE) { }
}

// 3. Checks-Effects-Interactions pattern
function transfer(address to, uint256 amount) external {
    require(balances[msg.sender] >= amount, "Insufficient");  // Check
    balances[msg.sender] -= amount;                            // Effect
    balances[to] += amount;                                    // Effect
    emit Transfer(msg.sender, to, amount);                     // Interaction
}

Configuration

Option	Type	Default	Description
chain	string	"ethereum"	Target chain: ethereum, polygon, arbitrum, base
framework	string	"hardhat"	Dev framework: hardhat, foundry
solidityVersion	string	"0.8.20"	Solidity compiler version
testCoverage	number	95	Minimum test coverage percentage
useUpgradeable	boolean	false	Use UUPS upgradeable patterns
gasOptimization	boolean	true	Apply gas optimization techniques

Best Practices

1. Use OpenZeppelin contracts for standard functionality — Never implement ERC-20, ERC-721, or access control from scratch. OpenZeppelin contracts are battle-tested and audited. Custom implementations invariably contain vulnerabilities that have been discovered and fixed in OpenZeppelin years ago.

2. Follow the checks-effects-interactions pattern — Validate all conditions first (checks), modify contract state second (effects), and make external calls last (interactions). This prevents reentrancy attacks even without ReentrancyGuard, though you should still use the guard as defense in depth.

3. Test with fuzzing, not just unit tests — Unit tests check known scenarios, but fuzzing discovers edge cases you did not think of. Foundry's fuzzer can generate thousands of random inputs per second. A contract with 100% unit test coverage can still have critical bugs that fuzzing would find.

4. Deploy to testnet first and verify the contract — Deploy to Sepolia or Goerli first, verify the contract source on Etherscan, and test all user flows before mainnet deployment. Verified contracts build trust and allow users to read the code. Unverified contracts look suspicious.

5. Use events for all state changes — Events are the primary way off-chain applications (frontends, indexers, analytics) track what happened on-chain. Every significant state change (transfers, approvals, configuration updates) should emit an event with indexed parameters for efficient filtering.

Common Issues

Transaction reverts without clear error message — Solidity's require statements only return custom error strings if provided. Use descriptive require messages (require(amount > 0, "Amount must be positive")) or custom errors (error InsufficientBalance(uint256 available, uint256 required)) to help users and developers diagnose failures.

Gas costs are prohibitively high for complex operations — Loops over unbounded arrays, storage writes in loops, and large struct copies consume excessive gas. Use mappings instead of arrays for lookups, batch operations with merkle proofs, and calldata instead of memory for function parameters that are not modified.

Frontend wallet integration fails on different chains — The app connects to MetaMask on Ethereum mainnet but fails when users switch to Polygon or Arbitrum. Implement chain detection, prompt users to switch networks with wallet_switchEthereumChain, and handle the case where the chain is not yet configured in the user's wallet with wallet_addEthereumChain.