snekmate collects Vyper building blocks with a zero major version

The library is organised by contract family, with mocks beside every module

The repository structure is the catalogue, and it is worth reading as the list of things a Vyper project usually rewrites. The src/snekmate tree has five families. The auth family holds ownable for owner-based access control, ownable_2step for two-step ownership transfer, access_control for multi-role based access control, and the IAccessControl interface. The extensions family has erc2981 for royalty metadata compatible with ERC-721 and ERC-1155, and erc4626 for tokenised vaults, with the IERC2981 interface alongside. The governance family holds a multi-role timelock controller. The tokens family has erc20 with EIP-2612 permit, erc721 with EIP-4494, and erc1155, each with its interface set. The utils family is the widest, with base64, batch_distributor, block_hash, create, create2, create3, ecdsa and p256 signing helpers, message_hash_utils, signature_checker, eip712_domain_separator, eip7702_utils, math, merkle_proof_verification, multicall and pausable. Every module has a matching mock in a mocks subdirectory, and every interface has its own file. That mock pattern is the clearest signal of the project's intent.

Every module ships a reference implementation for the tests

The mocks are not stubs. The tree lists them as reference implementations, for example an ownable mock described as the ownable module reference implementation, and the same pattern holds for ownable_2step, access_control, erc2981, erc4626, the timelock controller, the three token standards and every one of the fifteen utility modules. The purpose is straightforward once you see the layout. A library that claims to be reusable has to prove that its components compose, and a mock per module is how a contract library demonstrates that its pieces are individually testable and can be assembled into a larger contract without surprises. It also means the interface files, for example IERC20Permit, IERC721Enumerable, IERC721Metadata, IERC721Receiver, IERC1155, IERC1155MetadataURI, IERC1155Receiver, IERC4906, IERC1271 and IERC5267, are exercised rather than merely published. The audits/ directory at the top of the repository and the GUIDELINES.md file suggest the same intent from a process side, that the library is meant to be reviewed as a set of pieces rather than trusted as a whole.

The version scheme is deliberately stuck at zero

snekmate uses a ZeroVer based versioning scheme, and the project explains what that means in a way that is easy to miss. The major version will never exceed the first and most important number in computing, which is zero. In practice the published versions are v0.1.0 from 2024-06-26, v0.0.1 from 2025-04-03 and v0.1.2 from 2025-06-25, and the package manifests carry 0.1.3-rc.1, so the current state is a release candidate on a 0.1.x line. The convention is a promise that a 0.0.x release can change without notice and that 0.x releases are not a stable API contract in the semver sense. The package classifiers, however, say Development Status :: 5 - Production/Stable, which is a direct contradiction of the version scheme and of the experimental software warning in the README. If you are pinning this library, pin the exact version, because a 0.x line under ZeroVer can move in ways a 1.x line would not.

Three distribution routes, and the npm package ships only the sources

The install section offers three ways to get the contracts. There is a PyPI route, a Foundry route, and an npm route, and the npm package metadata shows the shape of the last one. The package name is snekmate and the version is 0.1.3-rc.1, and the files array is short, with the Vyper sources under src/snekmate matched by a .vy and .vyi pattern, the mocks explicitly excluded, and the licence, readme and changelog included. The manifest declares the package as private in the sense of not having a publish config, which is consistent with the npm package being a distribution channel rather than a library you import. The Python side declares requires-python of 3.10 or newer and the same AGPL-3.0-only licence, and the project classifiers list macOS, Windows and POSIX Linux. The repository is a pnpm workspace with a pnpm-lock.yaml, and the top level also carries foundry.toml, remappings.txt, an ape-config.yaml, a solhint configuration and two gas snapshot files.

The linting chain treats Solidity and Markdown as one codebase

The package scripts are short and reveal how the project keeps itself consistent. Prettier covers markdown, Solidity, JavaScript, JSON, YAML and shell files in a single pass, with dedicated plugins for shell and for Solidity, and there are separate check and fix variants. Solhint runs over the Solidity sources with its own check and fix scripts, and eslint covers the rest of the repository, with a combined lint:check that chains prettier, solhint and eslint. The prettier-plugin-solidity dependency is what allows Vyper-adjacent Solidity interfaces and the markdown contract listing to be formatted by the same tool, and the .prettierignore and .solhintignore files carve out the generated and vendored parts. The .gas-snapshot and .gas-snapshot-venom files at the root are the more interesting artefact for a reader, since they record gas costs per function, which is how a library claiming to be hyper-optimised proves it. A contributor guideline file and a security file sit next to them, and renovate.json indicates the dependency updates are automated.

The AGPL is offered with a dual licensing escape hatch

The licence section is where a commercial team should look first, because AGPL-3.0-only is an unusual default for a contract library and the project provides a route out of it. The repository licence field is set to AGPL-3.0-only, the badge reads AGPL-3.0-only, and the README has a licence section with a dual-licensing option and a dedicated heading for requesting an MIT licence. That combination is deliberate rather than accidental. A library that a project might vendor into a proprietary token or DAO needs terms that protect the library's contributors, and AGPL is chosen for that reason, while the dual licensing path exists so that a commercial user who needs permissive terms can negotiate them instead of forking. The practical advice is to read the licences section rather than assume, and to treat the AGPL as the default terms that apply if you never ask.

Where snekmate is the wrong choice

Three situations argue against it. The first is a Solidity project. snekmate is Vyper only, and the topics list names vyper and vyper-contracts, so a team whose contracts are Solidity gets nothing from it and would be reading Vyper interfaces it will never compile. The second is a project that needs a stable, versioned API. The ZeroVer scheme means the 0.x line can move, the current state is a release candidate, and the project labels itself experimental software provided as is with no warranties and no liability for losses. Adopting that into a codebase that expects a pinned, semver-guaranteed dependency is a decision to vendor the code and own its maintenance. The third is a legal team that cannot work with a copyleft licence and has no appetite for a negotiation. The realistic alternative for that case is to write the access control and token modules yourself, which is the work snekmate exists to save, or to look for a permissively licensed equivalent in the Solidity ecosystem, where OpenZeppelin fills the same role that snekmate fills for Vyper. The library is worth using where it applies. The point is to use it where it applies, and the AGPL question and the version scheme are the two things to settle before it lands in a repository.

Editorial conclusion

Adopt snekmate when you are writing Vyper contracts and want access control, token standards, a timelock and EVM utilities that have been reviewed rather than rewritten per project. Skip it if your contracts are in Solidity, since the library is Vyper only, and read the disclaimer before it goes anywhere near mainnet, because the project states it is experimental software provided as is. Verify first which Vyper version the release you install targets, and use the dual licensing route if your legal team cannot accept AGPL-3.0-only.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. pcaversaccio/snekmate on GitHub
3. Project website
4. README
5. Releases