Enzyme Blue lets anyone set up an on-chain investment vehicle, and it has been on Foundry since the Hardhat days

What the protocol is for

Enzyme Blue is described as an Ethereum-based protocol for decentralized on-chain asset management. The stated purpose is to be a protocol for people or entities to manage their wealth and the wealth of others within a customizable and safe environment, and it says anyone can set up, manage and invest in customized on-chain investment vehicles.

Three words in that sentence carry the design. Manage their wealth and the wealth of others is the custody question, and the answer is that it is done on-chain and without an intermediary holding the assets. Customizable is the structural question, and the answer is that a vehicle is assembled from parts rather than bought off a shelf as a closed product. Decentralized is the deployment question.

The topic tags are blockchain, defi, enzyme, ethereum and protocol, and the primary language is Solidity. The licence is recorded as a custom one that GitHub cannot classify, though the README is explicit about the arrangement, and the default branch is dev rather than main, which tells you the active work happens on a development branch.

The homepage is enzyme.finance, and the deployment addresses for v4 are published on the documentation site rather than in this repository, which is a sensible division: the code is one thing, the set of addresses it has been deployed to is another and changes with every release.

The last push was on 2026-09-25. The most recent tagged releases are v1.1.2 from 2020-03-10, v1.1.1 from 2020-02-27 and v1.1.0 from 2020-02-19, so the tags stop more than six years before the last commit.

The Hardhat to Foundry migration, and the tests that did not come along

The most consequential sentence in the README is short: this repository has been migrated from Hardhat to Foundry, and most tests for core v4 system contracts have not been ported from Hardhat.

That is an unusual thing for a project to state plainly, and it is worth taking at face value. It means the toolchain migration was carried out for the build and the development loop, but the verification of the core system contracts did not come with it.

The consequence for anyone evaluating the code is direct. A test suite that covers the core contracts is what tells you whether a change to them is safe. The legacy test suite and its coverage live on a separate branch, the hardhat branch, and the README points you there for legacy test suite and test coverage. But the legacy branch tests the legacy code, not the v4 code on the dev branch you would actually be working on.

So for the core v4 system contracts, the position is that the old suite exists and the new one does not yet, and the coverage number in the legacy branch does not describe the current code. If you are reading the contracts as a reference rather than modifying them, that gap matters less. If you intend to fork and modify them, it matters a great deal, and the mitigation is to write your own tests in Foundry, which the Makefile makes straightforward.

The rest of the toolchain migration is visible in the build setup. The repository has a foundry.toml at the root, a remappings.txt for Solidity import paths, a lib/ directory for the vendored dependencies pulled in as git submodules, and a contracts/ directory alongside tests/. The Makefile is the entry point and it is the more interesting file, because it encodes the project's conventions.

The Makefile encodes the conventions, and it is strict about them

The Makefile is short but opinionated, and several of its settings are there to catch a class of mistake.

It sets SHELL to bash with .ONESHELL, so each recipe runs as one script rather than line by line, and .SHELLFLAGS to -eu -o pipefail -c. That means every recipe fails on an unset variable, on an unhandled error, and on a failing command in a pipeline, which in shell terms is a much stricter default than the usual make behaviour where a failing command in a recipe line can be ignored depending on how it is written.

It sets .DELETE_ON_ERROR, so a target whose recipe fails does not leave a half-written output file behind that a later make would consider up to date. That is the kind of setting that matters when the output is a compiled artifact.

It also disables built-in rules with --no-builtin-rules and warns on undefined variables with --warn-undefined-variables, and it prints a helpful hint about needing GNU Make 4.0 or later because it uses the .RECIPEPREFIX feature, which is what lets the recipes use > as the command prefix rather than a tab.

The targets themselves map onto the workflow. The default target is all, which depends on install and build. install runs git submodule update --init --recursive, which is how the vendored dependencies arrive. build depends on artifacts and interfaces, where artifacts compiles the contracts and interfaces generates the internal interfaces. test runs forge test, lint runs forge lint and forge fmt --check over the contracts and tests directories, and format applies forge fmt to the same two directories.

The variables at the top make the layout explicit: TESTS_DIR is tests, CONTRACTS_DIR is contracts, ARTIFACTS_DIR is artifacts, and INTERFACES_FILE points at tests/interfaces/interfaces.txt with INTERFACES_DIR at tests/interfaces/internal. A constraint worth noting is INTERFACES_PRAGMA := >=0.6.0 <0.9.0, which is the Solidity compiler version range the generated interfaces are expected to work with, so the project pins a language version window rather than tracking the newest compiler.

There is also a note on the lint target: a TODO saying that an upcoming foundry version will support error on lint failure, which tells you that at the time of writing, forge lint reports issues but the make target does not fail the build on them.

Building and testing, and what the environment file expects

The prerequisites are two tools: foundry and make, both linked from the README, and then a clone:

git clone [GIT_REPOSITORY_URL]

Note that the clone command in the README is a placeholder, with GIT_REPOSITORY_URL in capitals rather than the actual repository address. It is the one place in the document where the copy-paste-ready instruction was left as a template.

Compiling is a single make invocation, which runs install and build:

make

That compiles the contracts, builds the artifacts and generates the internal interfaces used by the foundry deployment and the tests. The interface generation is selective, and the README is explicit about it: interfaces are only generated for items listed in the interfaces file at tests/interfaces/interfaces.txt. That is a deliberate scoping decision, since generating an interface for every contract in a large system is both slow and produces a lot of files nobody imports, and it means when you add a contract and want an interface for it, you add its name to that list first.

Running the tests needs an environment file. You create your .env file by copying .env.example and input your Ethereum and other networks' node endpoint info as needed, and the README says that generally only setting ETHEREUM_NODE_MAINNET, ETHEREUM_NODE_POLYGON and the like is fine.

The .env.example file in the repository shows the full shape of what that means:

ETHEREUM_NODE_MAINNET=
ETHEREUM_NODE_POLYGON=
ETHEREUM_NODE_ARBITRUM=
ETHEREUM_NODE_BASE=

ETHERSCAN_API_KEY_MAINNET=
ETHERSCAN_API_KEY_POLYGON=

Six variables, three network node endpoints and two explorer API keys, with a fourth node endpoint for Base and no explorer key listed for Arbitrum or Base. The explorer keys are there because tests and forks read contract source and metadata from the explorer, and a test that needs to verify a deployed contract's bytecode needs it.

The test suite itself runs with:

make test

and you can run a subset directly through forge, for example forge test --match-test <REGEX>, which is what you want when you are working on one contract and the full suite is slow.

A GPL-3 licence with an alternative-terms carve-out

The licensing section is the part of this repository most likely to matter to a reader who has not dealt with protocol code before, and it is a two-layer arrangement.

The public terms are GPL-3.0, with the licence text under LICENSES/GPL-3.0, and the README badge says GPL v3. The contributing section repeats it: by contributing, you agree your contribution is licensed under GPL-3.0.

The alternative terms clause is the part that catches people out. The copyright holder, Enzyme Foundation, may license this code under alternative terms, for example BUSL-1.1, for affiliated and internal products. The contributing section says the same thing from the other side: a contribution may also be sublicensed by Enzyme Foundation under alternative terms such as BUSL-1.1.

So the code is GPL-3.0 for the public and something else for the foundation's own use. BUSL-1.1 is the Business Source License, which is the source-available variant of an open source licence: it grants use rights but converts to an open licence after a set period, and it adds a use restriction in the meantime. The result is that you can use this code under GPL-3.0, and the foundation itself can use it under terms that are not GPL.

There is a third layer for the vendored dependencies, which the README handles with SPDX identifiers. Source files in this repository use GPL-3.0, and vendored third-party files retain their original identifiers, for example MIT for OpenZeppelin. The lib/ directory holds those vendored files as git submodules, and the SPDX statement is what keeps the two licensing layers from being confused with each other when you audit what is actually in your build.

The repository also carries a LICENSE-3rdparty-style arrangement in spirit through the LICENSES/ directory and a SECURITY.md. The licence is recorded in the repository metadata as a custom one that GitHub cannot classify, which is what happens when a repository has a layered licensing arrangement that does not reduce to a single SPDX identifier.

Where Enzyme Blue is the wrong choice

Three limits, and the first is about what a protocol release actually means for your users.

The first is that the tags stop in 2020. The recent releases listed are v1.1.2 from 2020-03-10, v1.1.1 from 2020-02-27 and v1.1.0 from 2020-02-19, while the last push was on 2026-09-25 and the development branch is v4. So the version numbers in the repository's release history describe a generation of the protocol that is not the one on the dev branch. The README tells you that v4 deployment addresses are on the documentation site, which means the authoritative version information for what you would actually deploy lives outside this repository, in a document that changes without a tag here.

For a protocol that holds assets, that is an uncomfortable position to be in, and it is worth being concrete about why. A contract deployment is not the same as a library release. Once a version is deployed with funds in it, the source at that address is the fact, not the tag. So the practical questions for you are which addresses the current deployments use, whether those addresses correspond to code you can match to a commit, and who is operating the upgrade path. None of those are answered by the tag list in this repository.

The second is the test coverage gap, restated from the other side. The migration from Hardhat to Foundry is stated as complete for the repository but not for the core v4 system contract tests. For a system whose entire job is custody and share accounting on-chain, the missing tests are on the parts where a bug costs money. The legacy branch has coverage, but of legacy code. So if you are auditing before deploying, you are auditing source whose tests do not currently exist in the same tree, which means your own review has to carry the weight that the legacy suite used to carry.

The third is the licensing for a commercial integrator. If you intend to build a product on this code, the public GPL-3.0 grant reaches into your product, and the carve-out only helps the foundation's affiliated and internal products, not yours. That is a deliberate structure and it is common in protocol code, but it means the commercial path is a separate negotiation rather than something you can rely on.

The alternative approach for most people is to use the deployed protocol rather than the source, through the interfaces the documentation site publishes. The difference in approach is that running a deployed v4 deployment means someone else operates the upgrade path and bears the operational burden, and your integration depends on their published interfaces rather than on your own fork, while forking the source means you control the code and the deployment but also inherit the untested core and the licence obligations. Which one is right depends on whether you are building a product on top of a protocol or you are building the protocol itself.

Editorial conclusion

Adopt the Enzyme protocol contracts if you are building an on-chain fund or managed investment vehicle and want to assemble the pieces yourself rather than depend on a single custodial arrangement, because the repository is the reference implementation and the deployment addresses for v4 are published. Do not adopt it without reading the licence terms, since the public grant is GPL-3.0 and the copyright holder may relicense the code under alternative terms for affiliated products, and do not expect the Foundry test suite to be as complete as the legacy one, because most core v4 tests were never ported from Hardhat. Verify first that the branch you work from is the v4 development branch rather than the hardhat branch that still holds the legacy suite, that your node endpoints and explorer API keys are set in a.env file copied from.env.example, that the interfaces you need appear in the interfaces list before you expect generated interfaces, and that you have Foundry and GNU Make 4.0 or newer installed, since the Makefile refuses to run without them.

Frequently asked questions

Official sources

1. enzymefinance/protocol on GitHub
2. Issues
3. Project website
4. README
5. Releases