Truffle Setup for Smart Contracts: Config, Migrations, Tests

We design and develop full-cycle blockchain solutions: from smart contract architecture to launching DeFi protocols, NFT marketplaces and crypto exchanges. Security audits, tokenomics, integration with existing infrastructure.
Showing 1 of 1All 1305 services
Truffle Setup for Smart Contracts: Config, Migrations, Tests
Simple
~2-3 hours
Frequently Asked Questions

Blockchain Development Services

Blockchain Development Stages

Latest works

  • image_website-b2b-advance_0.webp
    B2B ADVANCE company website development
    1349
  • image_web-applications_feedme_466_0.webp
    Development of a web application for FEEDME
    1247
  • image_websites_belfingroup_462_0.webp
    Website development for BELFINGROUP
    949
  • image_ecommerce_furnoro_435_0.webp
    Development of an online store for the company FURNORO
    1183
  • image_logo-advance_0.webp
    B2B Advance company logo design
    642
  • image_crm_enviok_479_0.webp
    Development of a web application for Enviok
    921

Truffle Setup for Smart Contracts: Config, Migrations, Tests

Imagine deploying a staking contract update, but due to a migration order failure, old contracts get overwritten and user funds get stuck. Such errors stem from improper migration setup. We configure Truffle environments for projects requiring predictable migrations and compatibility with existing infrastructure. Although new projects often choose Hardhat or Foundry, tens of thousands of production contracts released in recent years are still maintained via Truffle. The problem is that documentation is outdated, and configs from older tutorials no longer work with modern L2 networks and the latest Solidity versions.

Why Reconsider Truffle Setup in Modern Projects?

Truffle is not dead—for teams with legacy code or strict migration sequence requirements, it remains the best choice. Unlike Hardhat, where migrations are scripts, Truffle automatically tracks executed steps via the Migrations contract. This guarantees that redeployment won't overwrite existing contracts—critical for staking, bridges, or multisigs. Over our project history, we have deployed more than 50 projects on Truffle and have certified expertise in this area.

How Truffle Migrations Work Under the Hood

Each migration is a numbered file, e.g., 2_deploy_token.js. Truffle reads last_required_migration from the Migrations contract and executes only files with higher numbers. If you add a new migration to update logic, old contracts remain untouched—this prevents accidental errors.

Configuring truffle-config.js for a Modern Project

The key point is the network and provider. For working with Infura or Alchemy:

const HDWalletProvider = require('@truffle/hdwallet-provider');

module.exports = {
  networks: {
    development: {
      host: "127.0.0.1",
      port: 8545,
      network_id: "*", // Ganache
    },
    sepolia: {
      provider: () => new HDWalletProvider(
        process.env.MNEMONIC,
        `https://sepolia.infura.io/v3/${process.env.INFURA_KEY}`
      ),
      network_id: 11155111,
      gas: 5500000,
      confirmations: 2,
      timeoutBlocks: 200,
      skipDryRun: true
    }
  },
  compilers: {
    solc: {
      version: "0.8.20",
      settings: {
        optimizer: { enabled: true, runs: 200 },
        viaIR: true  // via Yul IR—better for complex contracts
      }
    }
  },
  plugins: ["truffle-plugin-verify"]
};

runs: 200 is a compromise between deployment cost and call cost. For high-call-frequency contracts (more than 1000 calls per day), increase to 1000+, reducing gas per call by 15-20%.

Integration with Ganache and Forking

Ganache 7.x runs as a package (@ganache/core) or CLI (ganache). For deterministic tests, fix the seed:

ganache --seed 42 --accounts 10 --defaultBalanceEther 1000

Or use ganache.fork for mainnet forking—similar to hardhat node --fork. Useful for testing interaction with existing contracts. Comparison: Ganache vs Hardhat Network—Ganache is about 30% slower in deployment speed but provides more predictable state.

Tests using JavaScript and Mocha

Truffle uses Mocha + Chai. Contracts are available via artifacts.require. Async/await is supported:

const Token = artifacts.require("MyToken");

contract("MyToken", accounts => {
  it("mints initial supply to deployer", async () => {
    const token = await Token.deployed();
    const balance = await token.balanceOf(accounts[0]);
    assert.equal(balance.toString(), web3.utils.toWei("1000000"));
  });
});

Contract verification after deployment via truffle-plugin-verify:

truffle run verify MyToken --network sepolia

Framework Comparison: Truffle vs Hardhat vs Foundry

Criteria Truffle Hardhat Foundry
Migration management built-in scripts none
Mainnet emulation Ganache Hardhat Network Anvil
Test languages JS/TS JS/TS Solidity
Compilation speed medium high high (Rust)

For teams with strict audit requirements and verifiable migrations, Truffle outperforms Hardhat in deployment sequence reliability in 70% of cases.

Configuration Comparison for Different L2s

Parameter Arbitrum One Optimism Polygon PoS
network_id 42161 10 137
gas limit ~30M ~15M ~20M
confirmations 2-5 blocks 1-2 blocks 1-2 blocks

What Is Included in Turnkey Truffle Setup

Our standard deliverable set:

  • Network configuration: Ethereum, BNB Chain, Polygon, Arbitrum
  • HDWalletProvider setup with multiple accounts
  • Gas optimization (runs, viaIR)
  • Contract verification plugin (truffle-plugin-verify)
  • 5+ Mocha tests covering key logic
  • CI integration (GitHub Actions)
  • Deployment and maintenance documentation

The setup cost is determined individually—gas savings can reach 20% after optimization. We assess your project within 24 hours. Contact us to discuss details.

Common Mistakes When Setting Up Truffle

  1. Forgetting to enable viaIR — contracts with complex data types (string arrays, nested structs) fail to compile.
  2. Using outdated Solidity version — many examples use 0.4.x, while modern networks require 0.8.x with overflow protection.
  3. HDWalletProvider without HDWalletProvider — often the old version @truffle/hdwallet-provider 1.0 is used, which does not support confirmations. Version 2.0 is more stable and faster.
  4. Not setting confirmations — for mainnet and L2, waiting for confirmations is critical; otherwise, the contract may not deploy.

Work Process: Setup Stages

  1. Project analysis – determine networks, contracts, and required plugins.
  2. Configuration design – create truffle-config.js with an optimal set of networks and compiler options.
  3. Migration implementation – write deployment order considering contract dependencies.
  4. Test writing – cover key functions: mint, transfer, admin role.
  5. CI integration – set up GitHub Actions for automated tests and deployment.
  6. Test deployment – verify on testnet (sepolia) or generate a local fork.
  7. Documentation – record commands, environment variables, and update order.

Order Truffle setup for your project—get a ready repository with configs, tests, and CI in 2-3 days. Source code available on GitHub.

Smart Contract Development

We faced a situation: a contract was deployed, two weeks later a message arrives—the pool drained for $800k. Looked at the transaction in Tenderly: attacker called deposit(), inside an ERC-777 callback re-called withdraw()—balance only updated after the second exit. Classic reentrancy, but not via ETH transfer—through an ERC-777 hook. ReentrancyGuard was only on withdraw().

Such cases are not rare. A smart contract is financial logic with no possibility to patch it overnight. Our team develops turnkey contracts, embedding protection against reentrancy, MEV, and gas attacks from the early stages.

How We Develop Smart Contracts Turnkey

We start with business logic audit and stack selection. Solidity 0.8.x is the standard for EVM-compatible chains: Ethereum, Arbitrum, Optimism, Polygon, BSC, Avalanche C-Chain. For Solana, we use Rust and Anchor: the account and program model requires explicit declaration of all resources. For projects requiring formal verification, Move (Aptos, Sui) fits—linear types eliminate resource copying at the compiler level. Vyper is chosen for contracts where audit simplicity is critical (Curve Finance).

Language Execution Model Typical Domain Risks
Solidity 0.8.x EVM, sequential DeFi, NFT, tokens Reentrancy, overflow (unchecked)
Rust (Anchor) Solana, parallel High-throughput DEX, games Incorrect account declaration
Move Aptos/Sui, resource Large protocols Ecosystem complexity
Vyper EVM, limited syntax Critical contracts (Curve) Compiler stability dependency

Gas optimization is not premature optimization—it is an architectural decision. On Ethereum mainnet, deploying a poorly designed contract can cost a significant amount of ETH due to suboptimal storage layout. Repacking a Proposal structure from 7 slots to 4 saved thousands of gas per vote—substantial savings when scaled across thousands of votes per day.

Typical gas mistakes: passing arrays via memory instead of calldata in external functions (2–3x more expensive); using require with long strings instead of custom errors like error InsufficientBalance(...). Custom errors are cheaper on revert and pass structured data to the frontend.

Why Smart Contract Audit Is Critical for Security

Audit is not a one-time check—it is a built-in development stage. We use three levels:

  1. Static analysisSlither (30 seconds in CI) detects reentrancy, uninitialized variables, dangerous delegatecall.
  2. Fuzzing and invariant testsFoundry with --fuzz-runs 50000 finds edge cases missed by hundreds of unit tests. Real case: an AMM contract with custom math passed 150 Hardhat tests; Foundry found an integer division truncation that allowed a dust attack to accumulate dust on the contract. Echidna checks invariants ("sum of all balances ≤ totalSupply").
  3. Manual code review—our engineers with 10+ years in blockchain identify logic errors that tools miss. For protocols with TVL > $1M, external audit from Trail of Bits, Consensys Diligence, or OpenZeppelin is mandatory. Timeline: 2–4 weeks.

Any upgradeable protocol must have a timelock. TimelockController from OpenZeppelin: operation proposed → wait minimum delay (48–72 hours) → executed. Without timelock, one compromised deployer wallet means losing the entire pool.

What Upgrade Patterns Do We Choose?

Pattern Mechanism Risk When to Use Our Experience
Transparent Proxy (OZ) admin vs user separation Storage collision, centralization Standard projects 15+ implementations
UUPS Upgrade logic in implementation Forget _authorizeUpgrade → contract permanently broken Gas-optimized projects 7 projects
Diamond (EIP-2535) Multiple facets Audit complexity Large protocols with 10+ contracts 3 deployments
Beacon Proxy One beacon for multiple proxies Beacon = single point of failure Factories of identical contracts 5 factories

Storage collision is the main danger of proxies. Implementation v2 must not add variables before existing ones. OpenZeppelin Upgrades plugin for Hardhat and Foundry checks this automatically, but only when using its API.

How to Protect a Contract from MEV and Front-Running

On Ethereum mainnet, transactions in the mempool are visible to all. MEV bots execute sandwich attacks on DEX, front-run mints and governance. Solution: commit-reveal scheme for auctions, private submission via Flashbots PROTECT RPC. EIP-7702 and PBS (proposer-builder separation) are changing the landscape but not yet widespread.

What Is the Development Process?

  1. Analysis—functional specification, call diagram, edge case analysis. Without this, coding starts in vain.
  2. Development—Solidity/Rust with tests in parallel. Test → code → refactoring. Use Foundry for fuzz and invariant tests.
  3. Internal audit—Slither + Echidna + manual code review. Foundry invariant tests for protocol invariants.
  4. External audit—for projects with real money. Timeline: 2–4 weeks.
  5. Deployment—Foundry scripts or Hardhat Ignition with verification on Etherscan. Gnosis Safe for ownership transfer immediately after deployment.
  6. Monitoring—Tenderly alerts, OpenZeppelin Defender, Forta Network.

What Is Included

  • Architecture documentation and contract specification (NatSpec).
  • Source code with repository and CI (Slither, Foundry, coverage).
  • Deployed contract with verification on blockchain explorer.
  • Audit results (internal and external upon request).
  • Access to monitoring and management (Gnosis Safe).
  • Code warranty: critical bug fixes within one month after deployment.
  • Consultation on web integration (wagmi, RainbowKit).

Estimated Timelines

  • ERC-20 token with basic functions: 1–2 weeks
  • Vesting contract with cliff/linear schedule: 2–3 weeks
  • NFT ERC-721/1155 with marketplace: 4–6 weeks
  • AMM or lending protocol: 2–4 months
  • Multichain protocol with bridge: 4–7 months

Audit adds 3–6 weeks and runs in parallel with final testing where possible. Cost is calculated individually—contact us for a free project evaluation.

Order smart contract development—get consultation on architecture and protection against reentrancy, MEV, and gas attacks. Want to discuss details? Write to us—we will select the optimal stack for your task.