Blockchain & Web3

Smart Contract Development

Contract logic, the tests around each function that moves value, and the deployment steps for the network you choose.

Start a project Book a call

Delivery focus

Built to move from idea to production.

Contract logic, the tests around each function that moves value, and the deployment steps for the network you choose. The work sits inside Blockchain & Web3 and is scoped, built, reviewed, and handed over as one engagement.

Clear product and technical roadmap

Scalable implementation standards

Launch support and measurable outcomes

Scope

ClickMasters builds and audits smart contracts for B2B companies across the USA, Europe, Canada, and Australia. ERC-20 token contracts with vesting schedules and governance. ERC-721 and ERC-1155 NFT contracts with royalty enforcement (ERC-2981). DeFi protocols staking, liquidity pools, yield farming. Custom business logic in Solidity on Ethereum, Polygon, BNB Chain, and Avalanche. Every contract tested with Hardhat and Foundry, gas-optimised, and audited before mainnet deployment.

When Blockchain Is NOT the Right Solution

Smart contracts are appropriate when: the business logic genuinely requires trustless, tamper-proof execution between parties who do not trust each other; decentralisation is a core product requirement (not just a marketing claim); and the asset or agreement being managed has sufficient value to justify the gas costs and development complexity. Smart contracts are NOT appropriate when: a traditional database and legal contract can enforce the same agreement (most B2B use cases); the data that the contract needs to act on lives off-chain and requires an oracle (adding a trust assumption that partially undermines the decentralisation argument); or the regulatory environment for your use case (security tokens, financial products) is not yet clear in your jurisdiction. ClickMasters will tell you honestly whether your use case requires blockchain.

Gas Optimisation Techniques

Every operation in a smart contract costs gas a fee paid to the Ethereum network in ETH to compensate validators for processing the transaction. Gas costs directly affect user experience: a poorly optimised smart contract might cost a user $50 in gas for an operation that a well-optimised contract performs for $5. Gas optimisation techniques: storage packing (storing multiple small values in a single 32-byte slot costs one SSTORE operation instead of multiple), using events instead of storage for historical data (emitting an event costs 375 gas per byte; storing 32 bytes to state costs 20,000 gas emit events for data that does not need to be read by on-chain logic), calldata instead of memory for function parameters (calldata is read-only and significantly cheaper), and unchecked arithmetic in loops where overflow is provably impossible. ClickMasters measures gas costs in tests and optimises the highest-cost operations before deployment.

What this engagement delivers

Solidity Contract Development

Production Solidity smart contracts on EVM-compatible networks: contract architecture (single vs proxy vs diamond pattern), OpenZeppelin inheritance (battle-tested base contracts), access control (role-based with AccessControl), events (emitted for all state changes), NatSpec documentation (dev/ for contract, param, return documentation).

Testing (Hardhat + Foundry)

Comprehensive test suites: Hardhat tests (TypeScript all functions, revert conditions, access control paths, edge cases), Foundry fuzzing (thousands of random inputs, property-based invariant tests), hardhat-gas-reporter (gas cost of every function), mainnet fork testing (test against real deployed contracts like Uniswap/Aave without deploying to mainnet).

Gas Optimisation

Reduce gas costs: storage packing (multiple small variables into single 32-byte slot), immutable/constant variables (no storage slot), calldata vs memory (cheaper for read-only args), unchecked arithmetic (save gas in loops where overflow is impossible), events vs storage for historical data (8x cheaper).

Upgradeable Contracts

Proxy patterns for logic updates: OpenZeppelin Transparent Proxy (UUPS or Transparent separates proxy storage from implementation logic), storage layout safety (OpenZeppelin upgrades plugin validates compatibility), initialiser pattern (constructors don't work in upgradeables use initialize() with initializer modifier), timelock (enforce delay between upgrade proposal and execution).

Contract Security (Slither + Mythril)

Pre-audit security analysis: Slither (Trail of Bits detects reentrancy, unprotected ETH withdrawal, integer overflow, incorrect access control, unchecked return values run on every PR), Mythril (symbolic execution explores all execution paths), manual review checklist (reentrancy guard on all functions transferring ETH/tokens, checks-effects-interactions pattern, pull payments pattern, front-running analysis).

Process

  1. Phase 1 · Week 1-2

    Contract Architecture Review

    Use case analysis, pattern selection (single vs proxy vs diamond), security considerations, gas estimate, upgrade planning. Deliverable: Contract Architecture + Gas Estimate.

  2. Phase 2 · Week 2-5

    Smart Contract Implementation

    Solidity implementation with OpenZeppelin standards, access control (AccessControl), events, NatSpec documentation, Hardhat/Foundry tests (unit, fuzz, invariant, fork tests). Deliverable: Smart Contracts + Test Suite.

  3. Phase 3 · Week 4-5

    Gas Optimisation

    Storage packing, immutable/constant usage, calldata optimisation, event vs storage decisions, unchecked arithmetic in loops, gas reporting. Deliverable: Gas-Optimised Contracts + Gas Report.

  4. Phase 4 · Week 5-6

    Security Analysis (Slither + Mythril)

    Automated static analysis (Slither), symbolic execution (Mythril), fuzzing (Echidna), manual review (checks-effects-interactions, reentrancy guards, front-running). Deliverable: Security Findings Report + Remediation.

  5. Phase 5 · Week 6-7

    Testnet Deployment & Audit

    Deploy to testnet (Sepolia/Mumbai), integration testing, fork tests against mainnet state, optional third-party audit coordination, remediation of findings, mainnet deployment. Deliverable: Mainnet Contracts + Verification.

Tech stack

Smart Contract
Solidity (primary), Yul (assembly optimisation), OpenZeppelin Contracts, Foundry, Hardhat
Testing
Foundry (fuzzing, invariant tests, fork tests), Hardhat (TypeScript tests), chai, waffle, hardhat-gas-reporter
Gas Optimisation
Storage packing, calldata vs memory, immutable/constant, unchecked arithmetic, event vs storage
Upgradeable
OpenZeppelin Transparent Proxy, UUPS, OpenZeppelin upgrades plugin, TimelockController
Security
Slither (static analysis 70+ patterns), Mythril (symbolic execution), Echidna (fuzzing), Certora Prover (formal verification)
Deployment
Foundry Cast, Hardhat Deploy, deterministic deployment (same address across networks), multi-sig (Safe)

How we work

"When Blockchain is NOT Right" Amber Callout

Honest guidance on smart contract appropriateness | Basic: "Smart contracts for everything" (no nuance)

ERC-20/721/1155 Distinction

Fungible vs non-fungible vs multi-token clear explanation with use cases | Basic: "Tokens" (no specificity)

Foundry Fuzzing Named

Property-based invariant tests, thousands of random inputs to find unexpected behaviour | Basic: Simple unit tests only

UUPS vs Transparent Proxy

Both upgrade patterns explained storage layout safety, initialiser pattern, timelock | Basic: "Upgradeable" (no implementation detail)

DAO Hack Reentrancy Reference

$60M DAO hack (2016) cited as example specific, credible | Basic: "Reentrancy" (no context)

Where this is used

DeFi Staking Protocol

ERC-20 staking contract with time-locked deposits, reward distribution, emergency withdrawal. 3 months of Foundry fuzz tests. 99% gas optimisation vs baseline. $2M TVL deployed.

NFT Collection Launch

ERC-721 with ERC-2981 royalties. Lazy minting (gas-free until purchase). Reveal mechanism (URI updates after sale). 10,000 NFTs minted in 48 hours.

DAO Governance Token

ERC-20 with OpenZeppelin Governor. Vesting contract for team (4-year cliff). Snapshot integration for gas-free voting. Deployed to Polygon.

Real-World Asset Tokenisation

ERC-1400 security token for real estate. Transfer restrictions (accredited investors only). Hyperledger Fabric private network for consortium.

Pricing guidance

These ranges are planning anchors. The quote names scope, timeline, and what is excluded. Talk through a quote.

Contract Architecture Review

$3,000 - $7,000

1 - 2 weeks

Use case analysis, pattern selection, security considerations, gas estimate

ERC-20 Token Contract

$5,000 - $12,000

2 - 3 weeks

Standard token + vesting + governance extension, Hardhat tests, audit

ERC-721 NFT Contract

$5,000 - $12,000

2 - 3 weeks

NFT + metadata + ERC-2981 royalties + access control, tests, audit

ERC-1155 Multi-Token

$6,000 - $14,000

2 - 4 weeks

Multi-token standard, batch mint/transfer, metadata, tests, audit

DeFi Protocol (Staking)

$10,000 - $28,000

3 - 6 weeks

Staking + rewards distribution + lockup periods, fuzz tests, audit

Custom Business Logic Contract

$8,000 - $22,000

2 - 5 weeks

Custom Solidity, full test coverage, gas optimisation, Slither + Mythril

Upgradeable Contract System

$10,000 - $28,000

3 - 6 weeks

UUPS proxy, storage layout validation, timelock, upgrade tests

Smart Contract Audit

$5,000 - $15,000

2 - 3 weeks

Manual review + Slither + Mythril + findings report + remediation support

FAQs

What is a smart contract and how is it different from a regular application?

A smart contract is a program that runs on a blockchain its code and state are stored on the chain, its execution is deterministic and transparent, and its results are tamper-proof. Unlike a regular application (which runs on a server controlled by the application operator and can be modified), a smart contract's logic is immutable once deployed (unless it uses an upgradeable proxy pattern) and executes identically for all parties regardless of who calls it. This trustlessness is the core property: a smart contract escrow releases payment when delivery is confirmed without either party needing to trust the other the contract's logic enforces the agreement. The trade-offs: smart contracts cannot read external data without an oracle (they are isolated from the internet), storage is expensive (every 32 bytes costs gas), and bugs cannot be patched without an upgrade mechanism designed in from the start.

What is the difference between ERC-20, ERC-721, and ERC-1155?

These are Ethereum token standards interface specifications that define how a token contract behaves so wallets, exchanges, and other contracts can interact with it without knowing the specific implementation. ERC-20 defines fungible tokens each token is identical and interchangeable (like currency one USDC is worth the same as any other USDC). ERC-721 defines non-fungible tokens (NFTs) each token has a unique ID and is distinct from all others (used for digital ownership each token represents a unique asset). ERC-1155 defines a multi-token standard a single contract can hold both fungible and non-fungible tokens, enabling efficient batch operations (mint 1,000 fungible game currency tokens and 50 unique item NFTs in one transaction). ClickMasters selects the appropriate standard based on the use case ERC-20 for utility tokens and stablecoins, ERC-721 for unique digital assets, ERC-1155 for gaming and platforms managing multiple token types.

What is gas optimisation and why does it matter?

Every operation in a smart contract costs gas a fee paid to the Ethereum network in ETH to compensate validators for processing the transaction. Gas costs directly affect the user experience: a poorly optimised smart contract might cost a user $50 in gas for an operation that a well-optimised contract performs for $5. Gas optimisation techniques reduce the gas cost of contract operations: storage packing (storing multiple small values in a single 32-byte slot costs one SSTORE operation instead of multiple), using events instead of storage for historical data (emitting an event costs 375 gas per byte; storing 32 bytes to state costs 20,000 gas emit events for data that does not need to be read by on-chain logic), and using calldata instead of memory for function parameters that are not modified (calldata is read-only and significantly cheaper). ClickMasters measures gas costs in tests and optimises the highest-cost operations before deployment.

What is a smart contract audit and do I need one?

A smart contract audit is a security review of Solidity code by an expert combining automated analysis (Slither, Mythril) with manual review to identify vulnerabilities before deployment. Once a smart contract is deployed and holds funds or controls assets, bugs cannot be fixed without a migration or a pre-designed upgrade mechanism. A single reentrancy bug (the type that enabled the 2016 DAO hack $60M lost) can drain all funds from a contract. ClickMasters strongly recommends security analysis on every contract that will hold or control value, and a full third-party audit for contracts controlling significant value (>$100K). ClickMasters performs pre-audit security analysis (Slither + Mythril + manual review) as a standard step before client deployment, and can recommend specialist smart contract audit firms (Trail of Bits, OpenZeppelin, ConsenSys Diligence, Certik) for high-value contracts requiring a formal third-party audit report.

Related reading

Smart Contract Development is one line inside Blockchain & Web3. Teams with an adjacent problem often compare it with Blockchain Development and DApp Development. For a written delivery narrative, read the SaaS booking platform QA case study and the rest of the case studies.

Back to Blockchain & Web3