Audit Comp | Anvil

Is this an upgrade of an existing system? If so, which? And what are the main differences?

No. This is a new protocol.

Where do you suspect there may be bugs? Useful aspects of this question are:

• Which parts of the code are you most concerned about?

TimeBasedCollateralPool accounting

• What attack vectors are you most concerned about? Tokens being stuck in the CollateralVault or stolen from the TimeBasedCollateralPool or CollateralVault

• Which part(s) of the system do you want whitehats to attempt to break the most? TimeBasedCollateralPool accounting

• Are there any assumed invariants that you want whitehats to attempt to break?

• CollateralVault

1. Owner cannot take tokens associated with account balances, only balances that are not associated with accounts (max withdrawable by owner is - --
2. CollateralVault balance - SUM(accountBalances))
3. Collateralizable contracts can only reserve & claim account tokens up to their account allowance, which decreases on reservation
4. CollateralReservations may not be changed, claimed, or released by any party other than the reserving collateralizable contract
5. CollateralReservations are resilient to contract governance actions (e.g. disabling the CollateralToken being used, changing the withdrawal fee, etc.)
6. Account balances for distinct ERC-20 tokens will be accounted for separately at all times (never mixed up)

• TimeBasedCollateralPool

1. • Accounts always receive units proportional to their staked tokens for staking operations and receive tokens proportional to their pool units for unstaking operations
2. • Tokens being unstaked are still claimable for at least 1 epoch after initiating unstaking
3. • Tokens being unstaked are never claimable after the end of the epoch following the epoch in which unstaking was initiated
4. • Units and balances for distinct ERC-20 tokens will be accounted for separately at all times (never mixed up)

What ERC20 / ERC721 / ERC777 / ERC1155 token standards are supported? Which are not?

ERC-20 tokens that are subject to governance review ahead of support. That is to say that attacks that stem from malicious code within a token contract should be out of scope for this program, as any complex / non-standard ERC-20 token will be restricted by governance until proven safe. Fee-on-Transfer tokens, rebasing tokens, and tokens with upgradeable contracts should assume to never be supported, as well as other tokens that could present a security risk.

What emergency actions may you want to use as a reason to invalidate or downgrade an otherwise valid bug report?

• For each emergency action, how does it work, how would it affect a bug report, and when would you utilize it?

If this is listed in your documentation, then a link to that part of the documentation would suffice.

• Note that normally, not all emergency actions are accepted as a valid reason to invalidate or downgrade an otherwise valid bug report, such as chain rollbacks.

This project is not a chain of its own and does not have the ability to rewrite history, so no emergency actions should be possible as a way to mitigate an otherwise possible theft. The TimeBasedCollateralPool contract is meant to be referenced by upgradeable proxies, so bug reports of “frozen” tokens that may be mitigated by a contract upgrade are less of a concern and therefore out of scope. Anvil will likely pay those out as low severity bugs reported via our forthcoming bug bounty program, but not as a part of this Audit Competition.

What monitoring systems may you want to use as a reason to invalidate or downgrade an otherwise valid bug report?

None to our knowledge.

There are possible admin actions in CollateralVault and TimeBasedCollateralPool, including contract upgrades for the latter, but those are only possible via governance, which is much slower than any attack and could not reasonably front-run an attack.

What addresses would you consider any bug report requiring their involvement to be out of scope, as long as they operate within the privileges attributed to them?

There are various roles defined in the CollateralVault and TimeBasedCollateralPool contracts that should be assumed to act in any way explicitly permitted by that role, and that is a valid non-bug use case. That is to say that if accounts with an Admin/Owner role, for instance, may withdraw tokens from the contract, registering an attack of the Admin/Owner stealing tokens is invalid because that is not theft – that is an explicitly permitted action.

That said, in the CollateralVault for instance, the design of the contract is such that the contract Owner should not be able to take tokens that are earmarked for an individual account (it may only take contract balance - SUM(user account balance). If an attack were to be found such that the owner could take funds that were earmarked for one or more accounts, that would be a valid bug because it undermines the trust assumptions of the contract.

What external dependencies are there?

There are external dependencies on ERC-20 tokens. Governance attacks, such as the approval of a malicious ERC-20 token is out of scope.

There are also dependencies on open source contracts such as OpenZeppelin. While those are 3rd party contracts, they are referenced from within Anvil’s contracts, so any vulnerabilities in Anvil contracts made possible by issues in dependency contracts such as OZ are in scope.

Where might whitehats confuse out-of-scope code to be in-scope?

The code for the TimeBasedCollateralPool contract is meant to be referenced by proxies as their implementation. A TimeBasedCollateralPool contract could be deployed and not initialized, since it is not meant to be called directly, leaving it open to some 3rd party initializing it. If that happens, it is not a valid attack on the contract, as it is not meant to be used directly.
Since the TimeBasedCollateralPool contract is meant to be referenced by upgradeable proxies, finding some loophole in contract logic such that tokens reserved by that contract become stuck would be a lower severity bug than it would be if the contract were not upgradeable. For that reason, token theft as a bug is very much in scope, whereas issues that could be solved via a successful contract upgrade are less critical and therefore out of scope.

Are there any unusual points about your protocol that may confuse whitehats?

There is rather complicated accounting in TimeBasedCollateralPool to allow for permissionless time-based unstaking. While that design may be hard to understand on first read, contract-, function-, and code-level comments should provide useful context to help interpret the logic In TimeBasedCollateralPool, the term “units” is used to represent an account’s proportional involvement in the pool. If not immediately apparent, please note units imply a percentage (account units / total pool units).

What is the test suite setup information?

No tests have been made public at the moment.

Public Disclosure of Known Issues Bug reports covering previously-discovered bugs (listed below) are not eligible for a reward within this program. This includes known issues that the project is aware of but has consciously decided not to “fix”, necessary code changes, or any implemented operational mitigating procedures that can lessen potential risk.

There are no known issues that fall within the defined scope of this program

Previous Audits Anvil’s completed audit reports can be found at [https://docs.anvil.xyz/contracts/audits]. Any unfixed vulnerabilities mentioned in these reports are not eligible for a reward.