Balancer V2

The Smart contract addresses for Balancer can be found in the "Smart Contracts" section of their documentation here. The addresses are clearly labeled and easy to find, which aligns with the best practices for transparency and accessibility. This question receives a score of 100%.

Location: https://github.com/balancer/balancer-v2-monorepo

The team is public. The contributors on GitHub is public.

Devs took more than 72 hours to respond but after were very active. 100%.

Location: https://docs.balancer.fi/concepts/pools/    The documentation on the protocol suffices as a white paper.

This protocol's software architecture is in a DeFiLytic tool that links with other detailed docs.

There is 100% coverage of deployed contracts by software function documentation, which is in the code.    As documented below from https://github.com/balancer/balancer-v2-monorepo/blob/master/pkg/pool-linear/contracts/LinearPoolRebalancer.sol     function _depositToPool(IERC20 token, uint256 amount) private {   // Tokens can be deposited to the Vault with a 'deposit' operation, but that requires a prior 'managed'   // balance to exist. We therefore have to perform two operations: one to set the 'managed' balance (representing   // the new tokens that resulted from wrapping or unwrapping and which we are managing for the Pool), and   // another to deposit.   IVault.PoolBalanceOp[] memory deposit = new IVault.PoolBalanceOp;     // First, we inform the Vault of the 'managed' tokens.   deposit.kind = IVault.PoolBalanceOpKind.UPDATE;   deposit[0].poolId = _poolId;   deposit[0].amount = amount;   deposit[0].token = token;     // Then, we deposit them, clearing the 'managed' balance.   deposit[1].kind = IVault.PoolBalanceOpKind.DEPOSIT;   deposit[1].poolId = _poolId;   deposit[1].amount = amount;   deposit[1].token = token;     // Before we can deposit tokens into the Vault however, we must approve them.   token.safeApprove(address(_vault), amount);     _vault.managePoolBalance(deposit);   }     function _getDesiredMainTokenBalance() private view returns (uint256) {   // The desired main token balance is the midpoint of the lower and upper targets. Keeping the balance   // close to that value maximizes Pool swap volume by allowing zero-fee swaps in either direction.   (uint256 lowerTarget, uint256 upperTarget) = _pool.getTargets();   uint256 midpoint = (lowerTarget + upperTarget) / 2;

There is some implicit traceability between software documentation and implemented code. The documentation is in the comments, right with the code. I will give this an 80%

Information is well organized.

Code examples are in the Appendix at the end of this report.. As per the SLOC, there is 329% testing to code (TtC).    This score is guided by the Test to Code ratio (TtC). Generally a good test to code ratio is over 100%. However, the reviewer's best judgement is the final deciding factor.    TtC = 70602 / 21406 =329%    ───────────────────────────────────────────────────────────────────────────────  Language Files Lines Blanks Comments Code Complexity  ───────────────────────────────────────────────────────────────────────────────  JavaScript 102 21406 3194 6611 11601 1161  ───────────────────────────────────────────────────────────────────────────────  Total 102 21406 3194 6611 11601 1161  ───────────────────────────────────────────────────────────────────────────────  Estimated Cost to Develop $354,254  Estimated Schedule Effort 9.271584 months  Estimated People Required 3.394513  ───────────────────────────────────────────────────────────────────────────────  Processed 942299 bytes, 0.942 megabytes (SI)  ───────────────────────────────────────────────────────────────────────────────  Language Files Lines Blanks Comments Code Complexity  ───────────────────────────────────────────────────────────────────────────────  TypeScript 140 54069 9447 1140 43482 2201  JavaScript 133 10143 1879 1871 6393 251  Markdown 1 6390 7 0 6383 0  ───────────────────────────────────────────────────────────────────────────────  Total 274 70602 11333 3011 56258 2452  ───────────────────────────────────────────────────────────────────────────────  Estimated Cost to Develop $1,859,040  Estimated Schedule Effort 17.407797 months  Estimated People Required 9.487700  ───────────────────────────────────────────────────────────────────────────────  Processed 2978856 bytes, 2.979 megabytes (SI)  ───────────────────────────────────────────────────────────────────────────────

50% No indication of code coverage but clearly there is a complete set of tests. For Balancer for specifically "coverage" testing, that is tough on V2, since our code breaks the standard tools (specifically, the way we do errors with BalancerErrors, as it involves encoded strings in assembly). Balancer is working on getting around that, at least for future development.

On #12, Balancer has an extremely robust CI process. For instance . With every deployment, they generate and compare the bytecode with the deployed versions on chain, ensuring that the source code (i.e., build-info) in the repo is correct. It also computes and verifies the action-ids, which are used for generating permissions (so this is an integrity and important security check, as this is what the Maxis use to create governance transactions). Additionally, it generates and checks the deployment addresses of all contracts, including their active or deprecated status. This is great documentation for integrators. Finally, it verifies that all links in the documents are valid, ensuring the comments and markdown files are up-to-date.

This protocol has undergone formal verification. https://github.com/balancer/balancer-v2-monorepo/blob/master/audits/certora/2021-04-22.pdf

Multiple high quality audits. Top notch

The list of audits indicates the element of the software that was audited and the date and the applicability of the audit. Ideal, 100%

This protocol offers an active bug bounty of $1,000K

There is no documentation on protocol monitoring

There is no documentation on protocol monitoring    [...]

This is immutable code.

100% Code is Immutable and clearly indicated so in documentation

Code is immutable and is clearly indicated here. Actions that can be made on the contracts are itemized here for each chain.

All signers are clearly listed here. Many are provably human. Therefore 80%. Our goal is that evidence of clearly distinct human becomes part of this data set either through Gitcoin passport, KYC or even DeFiSafety multisig certification. But this list is very good.

Signer duties gives at least documentation about liveliness. While a quality protocol such as Balancer I am personally confident that all of the signers are conscientious about their transaction signing processes. The goal of this question is to normalize documenting the minimum acceptable process and checking signers against it. The goal is to start processes that allow lost key hacks to slowly disappear. We will give 20% for the signer duties comments.