Contract Changelog Generator from Git History

WHAT IT DOES

Contract Changelog Generator from Git History is a read-only developer tool that generates structured changelog templates for smart contracts based on version history and git commit references. It reads contract bytecode and deployment metadata for multiple contract versions, verifies each address points to a valid deployed contract, fetches balance and block number metadata, and produces a comprehensive changelog following the Keep a Changelog format. The tool helps developers document contract evolution, track version changes, maintain release notes, and correlate on-chain deployments with source code history. It is essential for projects that need to maintain clear version documentation across multiple contract deployments.

HOW TO USE

Connect your EVM-compatible wallet via the BGWallet bridge and select the network where your contracts are deployed. Enter the contract name and a list of contract versions (one per line in the format: version,address,commit_hash). Click "Generate Changelog" to produce a structured changelog. Results include a summary of all versions with their addresses, and a complete changelog document with sections for each version (including Unreleased changes), commit references, deployment block numbers, balances, and placeholder sections for Added, Changed, and Fixed items. The tool also provides a copy button for the generated changelog. All analysis is read-only—no signatures or transactions are submitted.

TECHNICAL MECHANISM

The tool uses ethers.js v5.7.2 to fetch chain state via the provider. For each user-provided version entry, it validates the address format using a regex pattern, retrieves the contract bytecode via provider.getCode(address) to confirm deployment, fetches the balance via provider.getBalance(address) (converted to ETH), and retrieves the current block number via provider.getBlockNumber(). The tool parses the user-provided version list by splitting on newlines and commas to extract version name, contract address, and git commit hash. The changelog is generated in the Keep a Changelog format with sections for each version ordered from newest to oldest. Each version entry includes the version name, deployment block number, commit hash, contract address, balance, and placeholder sections for Added, Changed, and Fixed changes. The tool also generates a version history summary at the end of the changelog. The generated changelog is a template that requires manual review and enhancement with actual change details.

WHAT IT CANNOT SEE

This tool has fundamental limitations that users must understand. It cannot access or read git history without user input—the tool relies on the user to provide commit hashes manually. It cannot automatically detect which git commits correspond to which deployments without manual mapping—the user must specify the commit for each version. It cannot determine the nature of changes between versions without source code analysis—the tool generates placeholder sections that require manual filling. It cannot generate meaningful changelog entries without commit messages or user-provided descriptions—the generated changelog is a template. It cannot automatically correlate deployment timestamps with git commit timestamps without manual verification. It cannot automatically detect new versions or deployments. It cannot verify that the commit hash corresponds to the actual source code of the deployed contract. It cannot generate changelogs for versions that are not user-provided. It cannot compare bytecode differences between versions. The tool's changelog is a starting point and requires substantial manual enhancement to be useful as a production changelog.

PLEASE NOTE

This tool only supports EVM-compatible blockchains (Ethereum, Polygon, BSC, Avalanche C-Chain, Optimism, Arbitrum, and their testnets). Solana, Tron, Starknet, SUI, TON, Aptos, Bitcoin, Cosmos, and XRP are not supported. The tool is free, open-source, requires no API keys, and uses the wallet's native provider for all read operations. Always review and enhance generated changelogs with actual commit messages and change details to accurately reflect the contract evolution.