Bancor contracts-solidity: the legacy v2.1 smart contract set

The first line of the README says legacy

Everything else in this repository is secondary to the note at the top, which states that these are the legacy v2.1 contracts and points to another repository for the Bancor V3 contracts. If your goal is to integrate with Bancor today, this is the wrong repository and the README makes that clear before you read a word of the rest. The version in the package manifest is 0.7.15, and the heading in the README names the set as v0.7, so the naming has drifted across the package version, the README heading and the legacy label, which is worth knowing when you are matching a version in a lockfile against a checkout. The repository has no GitHub releases, so there is no tag history to consult either, and the last push was on 2026-07-29. What you have is a source tree for the old deployment, a test suite, and a CHANGELOG.

Converters and reserves are the two halves of the design

The architecture description is short and it is the whole model. The main contracts are the BancorNetwork contract, described as the entry point to the system, and the different converter contracts, which are the implementation of the liquidity pools and their reserves. A converter is therefore the pool itself and a reserve is the token inventory held on one side of it. The README then spends a paragraph on vocabulary, which is unusual and telling: the terms reserves and connectors mean the same thing throughout the code and documentation, reserve ratio and connector weight are used interchangeably, and connector balance refers to the token inventories held in a liquidity pool's reserves. Two different vocabularies for one concept is a warning sign for anyone reading the code for the first time, since a bug report or a search will use the older name while the source uses the newer one. The source tree is split to match, with a contracts directory and a components directory side by side.

Upgrades are opt-in and keep the old system alive

The upgradeability model is described in terms that are unusual for a deployed contract system, and it is the detail most worth understanding before you read the contracts. All smart contract functions are public and all upgrades are opt-in. If significant improvements are made, a new version is released, and token owners then choose between moving to the new system and staying in the old one. Where it is possible, new versions are designed to be backwards compatible and able to interact with the old versions. That means two generations of the system can be alive at once, which is a direct consequence of the choice to let holders decide. For an integrator this cuts both ways. It removes the risk of a forced migration, and it removes the guarantee that the deployment you inspected is the deployment the other holders are using. The README does not document a migration procedure, a version identifier in the contract code, or a way to tell which generation a given address belongs to, so that mapping is something you would have to establish from the deployment itself.

Hardhat and Foundry sit in the same repository

The build tooling is doubled up, and the presence of both is the clearest signal that this codebase is mid-migration rather than settled. The package manifest drives Hardhat: the build script compiles with hardhat compile, the test script runs hardhat test with a raised node memory limit of 8192 megabytes set through NODE_OPTIONS, and there is a separate script that sets a bail flag so the run stops at the first failure. There is also a coverage script with the same memory setting, a size script that reports contract sizes, a verify script for source verification, and a flatten script that flattens the sources for review. Alongside that, a foundry.toml at the repository root and a test-foundry directory indicate a second test path, with a test directory and a snapshot directory for the JavaScript side. Two harnesses covering the same contracts means the Solidity tests are being ported, and the manifest has not caught up: the README still says to check hardhat.config.js for configuration details, while the file in the tree is hardhat.config.ts.

Config and secrets live in a config.json you create

Some plugins, API keys and custom networks with secret configuration need a config.json file, and the project tells you the shape of it. The file is not committed, and the network entries carry the RPC url while the apiKeys section carries the explorer key, which in the example are empty strings that you fill in:

{
    "apiKeys": {
        "etherscan": ""
    },

    "networks": {
        "mainnet": {
            "url": ""
        }
    }
}

The point of the file is that verification against a public explorer needs a key and connecting to a network needs an endpoint, and the project does not want either baked into the repository. The entry for mainnet is there as a template for other networks. What the file does not do is select which network the tests run against, so that choice lives elsewhere in the Hardhat configuration.

The stated prerequisites are old enough to be a problem

The testing section lists two prerequisites with exact versions: node 12.20.0 and yarn 1.22.0. Pinning them that tightly is normal for a project of its vintage, and it becomes a real obstacle now, because node 12 has been end-of-life for years and the exact patch releases named here will not be on a current machine. The repository is still in a workable state, with a package-lock.json and a yarn.lock both present, so the dependency tree is pinned either way, and the scripts are all yarn based. The install step is a single command:

yarn install

Verification then comes in two forms, described as quick testing and full coverage:

yarn test

yarn coverage

The full coverage run is the slow one and it is the memory-hungry one, which is why the manifest raises the node heap size for it. If you are setting this up on a modern machine, expect to install a node version manager and build the old node yourself before anything else will work.

What a licence file that contradicts the README means

Here is a discrepancy worth resolving before you rely on the code. The README states that Bancor Protocol is open source and distributed under the Apache License v2.0. The licence field on the repository says other, a custom licence that GitHub cannot classify, with the terms in the LICENSE file, and the package manifest is blunter still, declaring the licence as SEE LICENSE IN LICENSE rather than naming a standard grant. A package field that defers to a file is a common way of saying the terms are not a standard SPDX identifier, and the repository-level classification agreeing with that suggests the LICENSE file itself is not plain Apache 2.0. Read the file, because the distinction between Apache 2.0 and a bespoke grant for a protocol's own contracts can be the difference between permissive reuse and terms you did not expect. There is also a security dimension: the manifest runs snyk-protect as part of the prepare script, and a .snyk file and a SECURITY-relevant history in the CHANGELOG mean dependency advisories have been taken seriously here.

What you can actually build with this repository

Stripped of the caveats, the useful things in this repository are the converter and reserve contract implementations, the test suite that exercises them, and the utilities directory that the README links to for its own documentation. The utilities exist because solidity development needs a way to mint test tokens, seed reserves and drive the contracts without a live network, and the manifest shows the same instinct in the tooling, with a size script for the contract size limit and a flatten script for review. What the repository does not offer is any promise of a deployed system being safe to use today, and the README says as much in blunt terms: it is a work in progress, and it tells you to make sure you understand the risks before using it. That warning sits alongside the legacy label, and both point the same way. Reading this code is worthwhile for understanding a converter and reserve architecture. Deploying it is a different decision, and the V3 repository is where that decision belongs.

Editorial conclusion

contracts-solidity suits a developer auditing the older Bancor Network deployment, reproducing its behaviour locally, or reading how a converter and reserve pair fit together, and for those uses the Hardhat setup with both quick and full coverage runs is enough. It does not suit building a new Bancor integration, since the V3 contracts live in a separate repository and this one is labelled legacy. Before adopting it, confirm you are looking at the v2.1 code and not the V3 set, read the LICENSE file rather than the Apache mention in the README, and check the stated node and yarn versions, because the prerequisites are old enough that a current toolchain may not match them.

Frequently asked questions

Official sources

1. bancorprotocol/contracts-solidity on GitHub
2. Issues
3. README