@elizaos/autonomous 2.0.0-alpha.71 → 2.0.0-alpha.72

package/test/contracts/lib/openzeppelin-contracts/audits/2017-03.md

@@ -1,292 +0,0 @@
-# OpenZeppelin Audit
-
-NOTE ON 2021-07-19: This report makes reference to Zeppelin, OpenZeppelin, OpenZeppelin Contracts, the OpenZeppelin team, and OpenZeppelin library. Many of these things have since been renamed and know that this audit applies to what is currently called the OpenZeppelin Contracts which are maintained by the OpenZeppelin Contracts Community.
-
-March, 2017
-Authored by Dennis Peterson and Peter Vessenes
-
-# Introduction
-
-Zeppelin requested that New Alchemy perform an audit of the contracts in their OpenZeppelin library. The OpenZeppelin contracts are a set of contracts intended to be a safe building block for a variety of uses by parties that may not be as sophisticated as the OpenZeppelin team. It is a design goal that the contracts be deployable safely and "as-is".
-
-The contracts are hosted at:
-
-https://github.com/OpenZeppelin/zeppelin-solidity
-
-All the contracts in the "contracts" folder are in scope.
-
-The git commit hash we evaluated is:
-9c5975a706b076b7000e8179f8101e0c61024c87
-
-# Disclaimer
-
-The audit makes no statements or warrantees about utility of the code, safety of the code, suitability of the business model, regulatory regime for the business model, or any other statements about fitness of the contracts to purpose, or their bugfree status. The audit documentation is for discussion purposes only.
-
-# Executive Summary
-
-Overall the OpenZeppelin codebase is of reasonably high quality -- it is clean, modular and follows best practices throughout.
-
-It is still in flux as a codebase, and needs better documentation per file as to expected behavior and future plans. It probably needs more comprehensive and aggressive tests written by people less nice than the current OpenZeppelin team.
-
-We identified two critical errors and one moderate issue, and would not recommend this commit hash for public use until these bugs are remedied.
-
-The repository includes a set of Truffle unit tests, a requirement and best practice for smart contracts like these; we recommend these be bulked up.
-
-# Discussion
-
-## Big Picture: Is This A Worthwhile Project?
-
-As soon as a developer touches OpenZeppelin contracts, they will modify something, leaving them in an un-audited state. We do not recommend developers deploy any unaudited code to the Blockchain if it will handle money, information or other things of value.
-
-> "In accordance with Unix philosophy, Perl gives you enough rope to hang yourself"
-> --Larry Wall
-
-We think this is an incredibly worthwhile project -- aided by the high code quality. Creating a framework that can be easily extended helps increase the average code quality on the Blockchain by charting a course for developers and encouraging containment of modifications to certain sections.
-
-> "Rust: The language that makes you take the safety off before shooting yourself in the foot"
-> -- (@mbrubeck)
-
-We think much more could be done here, and recommend the OpenZeppelin team keep at this and keep focusing on the design goal of removing rope and adding safety.
-
-## Solidity Version Updates Recommended
-
-Most of the code uses Solidity 0.4.11, but some files under `Ownership` are marked 0.4.0. These should be updated.
-
-Solidity 0.4.10 will add several features which could be useful in these contracts:
-
-- `assert(condition)`, which throws if the condition is false
-
-- `revert()`, which rolls back without consuming all remaining gas.
-
-- `address.transfer(value)`, which is like `send` but automatically propagates exceptions, and supports `.gas()`. See https://github.com/ethereum/solidity/issues/610 for more on this.
-
-## Error Handling: Throw vs Return False
-Solidity standards allow two ways to handle an error -- either calling `throw` or returning `false`. Both have benefits. In particular, a `throw` guarantees a complete wipe of the call stack (up to the preceding external call), whereas `false` allows a function to continue.
-
-In general we prefer `throw` in our code audits, because it is simpler -- it's less for an engineer to keep track of. Returning `false` and using logic to check results can quickly become a poorly-tracked state machine, and this sort of complexity can cause errors.
-
-In the OpenZeppelin contracts, both styles are used in different parts of the codebase. `SimpleToken` transfers throw upon failure, while the full ERC20 token returns `false`. Some modifiers `throw`, others just wrap the function body in a conditional, effectively allowing the function to return false if the condition is not met.
-
-We don't love this, and would usually recommend you stick with one style or the other throughout the codebase.
-
-In at least one case, these different techniques are combined cleverly (see the Multisig comments, line 65). As a set of contracts intended for general use, we recommend you either strive for more consistency or document explicit design criteria that govern which techniques are used where.
-
-Note that it may be impossible to use either one in all situations. For example, SafeMath functions pretty much have to throw upon failure, but ERC20 specifies returning booleans. Therefore we make no particular recommendations, but simply point out inconsistencies to consider.
-
-# Critical Issues
-
-## Stuck Ether in Crowdsale contract
-CrowdsaleToken.sol has no provision for withdrawing the raised ether. We *strongly* recommend a standard `withdraw` function be added. There is no scenario in which someone should deploy this contract as is, whether for testing or live.
-
-## Recursive Call in MultisigWallet
-Line 45 of `MultisigWallet.sol` checks if the amount being sent by `execute` is under a daily limit.
-
-This function can only be called by the "Owner". As a first angle of attack, it's worth asking what will happen if the multisig wallet owners reset the daily limit by approving a call to `resetSpentToday`.
-
-If a chain of calls can be constructed in which the owner confirms the `resetSpentToday` function and then withdraws through `execute` in a recursive call, the contract can be drained. In fact, this could be done without a recursive call, just through repeated `execute` calls alternating with the `confirm` calls.
-
-We are still working through the confirmation protocol in `Shareable.sol`, but we are not convinced that this is impossible, in fact it looks possible. The flexibility any shared owner has in being able to revoke confirmation later is another worrisome angle of approach even if some simple patches are included.
-
-This bug has a number of causes that need to be addressed:
-
-1. `resetSpentToday` and `confirm` together do not limit the days on which the function can be called or (it appears) the number of times it can be called.
-1. Once a call has been confirmed and `execute`d it appears that it can be re-executed. This is not good.
-3. `confirmandCheck` doesn't seem to have logic about whether or not the function in question has been called.
-4. Even if it did, `revoke` would need updates and logic to deal with revocation requests after a function call had been completed.
-
-We do not recommend using the MultisigWallet until these issues are fixed.
-
-# Moderate to Minor Issues
-
-## PullPayment
-PullPayment.sol needs some work. It has no explicit provision for cancelling a payment. This would be desirable in a number of scenarios; consider a payee losing their wallet, or giving a griefing address, or just an address that requires more than the default gas offered by `send`.
-
-`asyncSend` has no overflow checking. This is a bad plan. We recommend overflow and underflow checking at the layer closest to the data manipulation.
-
-`asyncSend` allows more balance to be queued up for sending than the contract holds. This is probably a bad idea, or at the very least should be called something different. If the intent is to allow this, it should have provisions for dealing with race conditions between competing `withdrawPayments` calls.
-
-It would be nice to see how many payments are pending. This would imply a bit of a rewrite; we recommend this contract get some design time, and that developers don't rely on it in its current state.
-
-## Shareable Contract
-
-We do not believe the `Shareable.sol` contract is ready for primetime. It is missing functions, and as written may be vulnerable to a reordering attack -- an attack in which a miner or other party "racing" with a smart contract participant inserts their own information into a list or mapping.
-
-The confirmation and revocation code needs to be looked over with a very careful eye imagining extraordinarily bad behavior by shared owners before this contract can be called safe.
-
-No sanity checks on the initial constructor's `required` argument are worrisome as well.
-
-# Line by Line Comments
-
-## Lifecycle
-
-### Killable
-
-Very simple, allows owner to call selfdestruct, sending funds to owner. No issues. However, note that `selfdestruct` should typically not be used; it is common that a developer may want to access data in a former contract, and they may not understand that `selfdestruct` limits access to the contract. We recommend better documentation about this dynamic, and an alternate function name for `kill` like `completelyDestroy` while `kill` would perhaps merely send funds to the owner.
-
-Also note that a killable function allows the owner to take funds regardless of other logic. This may be desirable or undesirable depending on the circumstances. Perhaps `Killable` should have a different name as well.
-
-### Migrations
-
-I presume that the goal of this contract is to allow and annotate a migration to a new smart contract address. We are not clear here how this would be accomplished by the code; we'd like to review with the OpenZeppelin team.
-
-### Pausable
-
-We like these pauses! Note that these allow significant griefing potential by owners, and that this might not be obvious to participants in smart contracts using the OpenZeppelin framework. We would recommend that additional sample logic be added to for instance the TokenContract showing safer use of the pause and resume functions. In particular, we would recommend a timelock after which anyone could unpause the contract.
-
-The modifiers use the pattern `if(bool){_;}`. This is fine for functions that return false upon failure, but could be problematic for functions expected to throw upon failure. See our comments above on standardizing on `throw` or `return(false)`.
-
-## Ownership
-
-### Ownable
-
-Line 19: Modifier throws if doesn't meet condition, in contrast to some other inheritable modifiers (e.g. in Pausable) that use `if(bool){_;}`.
-
-### Claimable
-
-Inherits from Ownable but the existing owner sets a pendingOwner who has to claim ownership.
-
-Line 17: Another modifier that throws.
-
-### DelayedClaimable
-
-Is there any reason to descend from Ownable directly, instead of just Claimable, which descends from Ownable? If not, descending from both just adds confusion.
-
-### Contactable
-
-Allows owner to set a public string of contract information. No issues.
-
-### Shareable
-
-This needs some work. Doesn't check if `_required <= len(_owners)` for instance, that would be a bummer. What if _required were like `MAX - 1`?
-
-I have a general concern about the difference between `owners`, `_owners`, and `owner` in `Ownable.sol`. I recommend "Owners" be renamed. In general we do not recomment single character differences in variable names, although a preceding underscore is not uncommon in Solidity code.
-
-Line 34: "this contract only has six types of events"...actually only two.
-
-Line 61: Why is `ownerIndex` keyed by addresses hashed to `uint`s? Why not use the addresses directly, so `ownerIndex` is less obscure, and so there's stronger typing?
-
-Line 62: Do not love `++i) ... owners[2+ i]`. Makes me do math, which is not what I want to do. I want to not have to do math.
-
-There should probably be a function for adding a new operation, so the developer doesn't have to work directly with the internal data. (This would make the multisig contract even shorter.)
-
-There's a `revoke` function but not a `propose` function that we can see.
-
-Beware reordering. If `propose` allows the user to choose a bytes string for their proposal, bad things(TM) will happen as currently written.
-
-
-### Multisig
-
-Just an interface. Note it allows changing an owner address, but not changing the number of owners. This is somewhat limiting but also simplifies implementation.
-
-## Payment
-
-### PullPayment
-
-Safe from reentrance attack since ether send is at the end, plus it uses `.send()` rather than `.call.value()`.
-
-There's an argument to be made that `.call.value()` is a better option *if* you're sure that it will be done after all state updates, since `.send` will fail if the recipient has an expensive fallback function. However, in the context of a function meant to be embedded in other contracts, it's probably better to use `.send`. One possible compromise is to add a function which allows only the owner to send ether via `.call.value`.
-
-If you don't use `call.value` you should implement a `cancel` function in case some value is pending here.
-
-Line 14:
-Doesn't use safeAdd. Although it appears that payout amounts can only be increased, in fact the payer could lower the payout as much as desired via overflow. Also, the payer could add a large non-overflowing amount, causing the payment to exceed the contract balance and therefore fail when withdraw is attempted.
-
-Recommendation: track the sum of non-withdrawn asyncSends, and don't allow a new one which exceeds the leftover balance. If it's ever desirable to make payments revocable, it should be done explicitly.
-
-## Tokens
-
-### ERC20
-
-Standard ERC20 interface only.
-
-There's a security hole in the standard, reported at Edcon: `approve` does not protect against race conditions and simply replaces the current value. An approved spender could wait for the owner to call `approve` again, then attempt to spend the old limit before the new limit is applied. If successful, this attacker could successfully spend the sum of both limits.
-
-This could be fixed by either (1) including the old limit as a parameter, so the update will fail if some gets spent, or (2) using the value parameter as a delta instead of replacement value.
-
-This is not fixable while adhering to the current full ERC20 standard, though it would be possible to add a "secureApprove" function. The impact isn't extreme since at least you can only be attacked by addresses you approved. Also, users could mitigate this by always setting spending limits to zero and checking for spends, before setting the new limit.
-
-Edcon slides:
-https://drive.google.com/file/d/0ByMtMw2hul0EN3NCaVFHSFdxRzA/view
-
-### ERC20Basic
-
-Simpler interface skipping the Approve function. Note this departs from ERC20 in another way: transfer throws instead of returning false.
-
-### BasicToken
-
-Uses `SafeSub` and `SafeMath`, so transfer `throw`s instead of returning false. This complies with ERC20Basic but not the actual ERC20 standard.
-
-### StandardToken
-
-Implementation of full ERC20 token.
-
-Transfer() and transferFrom() use SafeMath functions, which will cause them to throw instead of returning false. Not a security issue but departs from standard.
-
-### SimpleToken
-
-Sample instantiation of StandardToken. Note that in this sample, decimals is 18 and supply only 10,000, so the supply is a small fraction of a single nominal token.
-
-### CrowdsaleToken
-
-StandardToken which mints tokens at a fixed price when sent ether.
-
-There's no provision for owner withdrawing the ether. As a sample for crowdsales it should be Ownable and allow the owner to withdraw ether, rather than stranding the ether in the contract.
-
-Note: an alternative pattern is a mint() function which is only callable from a separate crowdsale contract, so any sort of rules can be added without modifying the token itself.
-
-### VestedToken
-
-Lines 23, 27:
-Functions `transfer()` and `transferFrom()` have a modifier canTransfer which throws if not enough tokens are available. However, transfer() returns a boolean success. Inconsistent treatment of failure conditions may cause problems for other contracts using the token. (Note that transferableTokens() relies on safeSub(), so will also throw if there's insufficient balance.)
-
-Line 64:
-Delete not actually necessary since the value is overwritten in the next line anyway.
-
-## Root level
-
-### Bounty
-
-Avoids potential race condition by having each researcher deploy a separate contract for attack; if a research manages to break his associated contract, other researchers can't immediately claim the reward, they have to reproduce the attack in their own contracts.
-
-A developer could subvert this intent by implementing `deployContract()` to always return the same address. However, this would break the `researchers` mapping, updating the researcher address associated with the contract. This could be prevented by blocking rewrites in `researchers`.
-
-### DayLimit
-
-The modifier `limitedDaily` calls `underLimit`, which both checks that the spend is below the daily limit, and adds the input value to the daily spend. This is fine if all functions throw upon failure. However, not all OpenZeppelin functions do this; there are functions that returns false, and modifiers that wrap the function body in `if (bool) {_;}`. In these cases, `_value` will be added to `spentToday`, but ether may not actually be sent because other preconditions were not met. (However in the OpenZeppelin multisig this is not a problem.)
-
-Lines 4, 11:
-Comment claims that `DayLimit` is multiowned, and Shareable is imported, but DayLimit does not actually inherit from Shareable. The intent may be for child contracts to inherit from Shareable (as Multisig does); in this case the import should be removed and the comment altered.
-
-Line 46:
-Manual overflow check instead of using safeAdd. Since this is called from a function that throws upon failure anyway, there's no real downside to using safeAdd.
-
-### LimitBalance
-
-No issues.
-
-### MultisigWallet
-
-Lines 28, 76, 80:
-`kill`, `setDailyLimit`, and `resetSpentToday` only happen with multisig approval, and hashes for these actions are logged by Shareable. However, they should probably post their own events for easy reading.
-
-Line 45:
-This call to underLimit will reduce the daily limit, and then either throw or return 0. So in this case there's no danger that the limit will be reduced without the operation going through.
-
-Line 65:
-Shareable's onlyManyOwners will take the user's confirmation, and execute the function body if and only if enough users have confirmed. Whole thing throws if the send fails, which will roll back the confirmation. Confirm returns false if not enough have confirmed yet, true if the whole thing succeeds, and throws only in the exceptional circumstance that the designated transaction unexpectedly fails. Elegant design.
-
-Line 68:
-Throw here is good but note this function can fail either by returning false or by throwing.
-
-Line 92:
-A bit odd to split `clearPending()` between this contract and Shareable. However this does allow contracts inheriting from Shareable to use custom structs for pending transactions.
-
-
-### SafeMath
-
-Another interesting comment from the same Edcon presentation was that the overflow behavior of Solidity is undocumented, so in theory, source code that relies on it could break with a future revision.
-
-However, compiled code should be fine, and in the unlikely event that the compiler is revised in this way, there should be plenty of warning. (But this is an argument for keeping overflow checks isolated in SafeMath.)
-
-Aside from that small caveat, these are fine.
-

package/test/contracts/lib/openzeppelin-contracts/audits/README.md

@@ -1,16 +0,0 @@
-# Audits
-
-| Date         | Version | Commit    | Auditor      | Scope                | Links                                                       |
-| ------------ | ------- | --------- | ------------ | -------------------- | ----------------------------------------------------------- |
-| May 2023     | v4.9.0  | `91df66c` | OpenZeppelin | v4.9 Changes         | [🔗](./2023-05-v4.9.pdf)                                    |
-| October 2022 | v4.8.0  | `14f98db` | OpenZeppelin | ERC4626, Checkpoints | [🔗](./2022-10-ERC4626.pdf) [🔗](./2022-10-Checkpoints.pdf) |
-| October 2018 | v2.0.0  | `dac5bcc` | LevelK       | Everything           | [🔗](./2018-10.pdf)                                         |
-| March 2017   | v1.0.4  | `9c5975a` | New Alchemy  | Everything           | [🔗](./2017-03.md)                                          |
-
-# Formal Verification
-
-| Date         | Version | Commit    | Tool    | Scope                                                                                                                            | Links                                |
-| ------------ | ------- | --------- | ------- | -------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------ |
-| May 2022     | v4.7.0  | `109778c` | Certora | Initializable, GovernorPreventLateQuorum, ERC1155Burnable, ERC1155Pausable, ERC1155Supply, ERC1155Holder, ERC1155Receiver        | [🔗](../certora/reports/2022-05.pdf) |
-| March 2022   | v4.4.0  | `4088540` | Certora | ERC20Votes, ERC20FlashMint, ERC20Wrapper, TimelockController, ERC721Votes, Votes, AccessControl, ERC1155                         | [🔗](../certora/reports/2022-03.pdf) |
-| October 2021 | v4.4.0  | `4088540` | Certora | Governor, GovernorCountingSimple, GovernorProposalThreshold, GovernorTimelockControl, GovernorVotes, GovernorVotesQuorumFraction | [🔗](../certora/reports/2021-10.pdf) |

package/test/contracts/lib/openzeppelin-contracts/certora/Makefile

@@ -1,54 +0,0 @@
-default: help
-
-SRC   := ../contracts
-DST   := patched
-DIFF  := diff
-SRCS  := $(shell find $(SRC) -type f)
-DSTS  := $(shell find $(DST) -type f)
-DIFFS := $(shell find $(DIFF) -type f)
-
-###############################################################################
-# Apply all patches in the $DIFF folder to the $DST folder
-apply: $(DST) $(patsubst $(DIFF)/%.patch,$(DST)/%,$(subst _,/,$(DIFFS)))
-
-# Reset the $DST folder
-$(DST): FORCE
-	@rm -rf $@
-	@cp -r $(SRC) $@
-
-# Update a solidity file in the $DST directory using the corresponding patch
-$(DST)/%.sol: FORCE
-	@echo Applying patch to $@
-	@patch -p0 -d $(DST) < $(patsubst $(DST)_%,$(DIFF)/%.patch,$(subst /,_,$@))
-
-###############################################################################
-# Record all difference between $SRC and $DST in patches
-record: $(DIFF) $(patsubst %,$(DIFF)/%.patch,$(subst /,_,$(subst $(SRC)/,,$(SRCS)) $(subst $(DST)/,,$(DSTS))))
-
-# Create the $DIFF folder
-$(DIFF): FORCE
-	@rm -rf $@
-	@mkdir $@
-
-# Create the patch file by comparing the source and the destination
-$(DIFF)/%.patch: FORCE
-	@echo Generating patch $@
-	@diff -ruN \
-		$(patsubst $(DIFF)/%.patch,$(SRC)/%,$(subst _,/,$@)) \
-		$(patsubst $(DIFF)/%.patch,$(DST)/%,$(subst _,/,$@)) \
-		| sed 's+$(SRC)/++g' \
-		| sed 's+$(DST)/++g' \
-		> $@
-	@[ -s $@ ] || rm $@
-
-###############################################################################
-help:
-	@echo "usage:"
-	@echo "  make apply:  create $(DST) directory by applying the patches to $(SRC)"
-	@echo "  make record: record the patches capturing the differences between $(SRC) and $(DST)"
-	@echo "  make clean:  remove all generated files (those ignored by git)"
-
-clean:
-	git clean -fdX
-
-FORCE: ;

package/test/contracts/lib/openzeppelin-contracts/certora/README.md

@@ -1,60 +0,0 @@
-# Running the certora verification tool
-
-These instructions detail the process for running Certora Verification Tool on OpenZeppelin Contracts.
-
-Documentation for CVT and the specification language are available [here](https://certora.atlassian.net/wiki/spaces/CPD/overview).
-
-## Prerequisites
-
-Follow the [Certora installation guide](https://docs.certora.com/en/latest/docs/user-guide/getting-started/install.html) in order to get the Certora Prover Package and the `solc` executable folder in your path.
-
-> **Note**
-> An API Key is required for local testing. Although the prover will run on a Github Actions' CI environment on selected Pull Requests.
-
-## Running the verification
-
-The Certora Verification Tool proves specs for contracts, which are defined by the `./specs.json` file along with their pre-configured options.
-
-The verification script `./run.js` is used to submit verification jobs to the Certora Verification service.
-
-You can run it from the root of the repository with the following command:
-
-```bash
-node certora/run.js [[CONTRACT_NAME:]SPEC_NAME] [OPTIONS...]
-```
-
-Where:
-
-- `CONTRACT_NAME` matches the `contract` key in the `./spec.json` file and may be empty. It will run all matching contracts if not provided.
-- `SPEC_NAME` refers to a `spec` key from the `./specs.json` file. It will run every spec if not provided.
-- `OPTIONS` extend the [Certora Prover CLI options](https://docs.certora.com/en/latest/docs/prover/cli/options.html#certora-prover-cli-options) and will respect the preconfigured options in the `specs.json` file.
-
-> **Note**
-> A single spec may be configured to run for multiple contracts, whereas a single contract may run multiple specs.
-
-Example usage:
-
-```bash
-node certora/run.js AccessControl # Run the AccessControl spec against every contract implementing it
-```
-
-## Adapting to changes in the contracts
-
-Some of our rules require the code to be simplified in various ways. Our primary tool for performing these simplifications is to run verification on a contract that extends the original contracts and overrides some of the methods. These "harness" contracts can be found in the `certora/harness` directory.
-
-This pattern does require some modifications to the original code: some methods need to be made virtual or public, for example. These changes are handled by applying a patch
-to the code before verification by running:
-
-```bash
-make -C certora apply
-```
-
-Before running the `certora/run.js` script, it's required to apply the corresponding patches to the `contracts` directory, placing the output in the `certora/patched` directory. Then, the contracts are verified by running the verification for the `certora/patched` directory.
-
-If the original contracts change, it is possible to create a conflict with the patch. In this case, the verify scripts will report an error message and output rejected changes in the `patched` directory. After merging the changes, run `make record` in the `certora` directory; this will regenerate the patch file, which can then be checked into git.
-
-For more information about the `make` scripts available, run:
-
-```bash
-make -C certora help
-```

package/test/contracts/lib/openzeppelin-contracts/certora/diff/token_ERC721_ERC721.sol.patch

@@ -1,14 +0,0 @@
---- token/ERC721/ERC721.sol	2023-03-07 10:48:47.736822221 +0100
-+++ token/ERC721/ERC721.sol	2023-03-09 19:49:39.669338673 +0100
-@@ -199,6 +199,11 @@
-         return _owners[tokenId];
-     }
- 
-+    // FV
-+    function _getApproved(uint256 tokenId) internal view returns (address) {
-+        return _tokenApprovals[tokenId];
-+    }
-+
-     /**
-      * @dev Returns whether `tokenId` exists.
-      *

package/test/contracts/lib/openzeppelin-contracts/certora/harnesses/AccessControlDefaultAdminRulesHarness.sol

@@ -1,47 +0,0 @@
-// SPDX-License-Identifier: MIT
-
-pragma solidity ^0.8.0;
-
-import "../patched/access/AccessControlDefaultAdminRules.sol";
-
-contract AccessControlDefaultAdminRulesHarness is AccessControlDefaultAdminRules {
-    uint48 private _delayIncreaseWait;
-
-    constructor(
-        uint48 initialDelay,
-        address initialDefaultAdmin,
-        uint48 delayIncreaseWait
-    ) AccessControlDefaultAdminRules(initialDelay, initialDefaultAdmin) {
-        _delayIncreaseWait = delayIncreaseWait;
-    }
-
-    // FV
-    function pendingDefaultAdmin_() external view returns (address) {
-        (address newAdmin, ) = pendingDefaultAdmin();
-        return newAdmin;
-    }
-
-    function pendingDefaultAdminSchedule_() external view returns (uint48) {
-        (, uint48 schedule) = pendingDefaultAdmin();
-        return schedule;
-    }
-
-    function pendingDelay_() external view returns (uint48) {
-        (uint48 newDelay, ) = pendingDefaultAdminDelay();
-        return newDelay;
-    }
-
-    function pendingDelaySchedule_() external view returns (uint48) {
-        (, uint48 schedule) = pendingDefaultAdminDelay();
-        return schedule;
-    }
-
-    function delayChangeWait_(uint48 newDelay) external view returns (uint48) {
-        return _delayChangeWait(newDelay);
-    }
-
-    // Overrides
-    function defaultAdminDelayIncreaseWait() public view override returns (uint48) {
-        return _delayIncreaseWait;
-    }
-}

package/test/contracts/lib/openzeppelin-contracts/certora/harnesses/AccessControlHarness.sol

@@ -1,7 +0,0 @@
-// SPDX-License-Identifier: MIT
-
-pragma solidity ^0.8.0;
-
-import "../patched/access/AccessControl.sol";
-
-contract AccessControlHarness is AccessControl {}

package/test/contracts/lib/openzeppelin-contracts/certora/harnesses/DoubleEndedQueueHarness.sol

@@ -1,59 +0,0 @@
-// SPDX-License-Identifier: MIT
-
-pragma solidity ^0.8.0;
-
-import "../patched/utils/structs/DoubleEndedQueue.sol";
-
-contract DoubleEndedQueueHarness {
-    using DoubleEndedQueue for DoubleEndedQueue.Bytes32Deque;
-
-    DoubleEndedQueue.Bytes32Deque private _deque;
-
-    function pushFront(bytes32 value) external {
-        _deque.pushFront(value);
-    }
-
-    function pushBack(bytes32 value) external {
-        _deque.pushBack(value);
-    }
-
-    function popFront() external returns (bytes32 value) {
-        return _deque.popFront();
-    }
-
-    function popBack() external returns (bytes32 value) {
-        return _deque.popBack();
-    }
-
-    function clear() external {
-        _deque.clear();
-    }
-
-    function begin() external view returns (int128) {
-        return _deque._begin;
-    }
-
-    function end() external view returns (int128) {
-        return _deque._end;
-    }
-
-    function length() external view returns (uint256) {
-        return _deque.length();
-    }
-
-    function empty() external view returns (bool) {
-        return _deque.empty();
-    }
-
-    function front() external view returns (bytes32 value) {
-        return _deque.front();
-    }
-
-    function back() external view returns (bytes32 value) {
-        return _deque.back();
-    }
-
-    function at_(uint256 index) external view returns (bytes32 value) {
-        return _deque.at(index);
-    }
-}

package/test/contracts/lib/openzeppelin-contracts/certora/harnesses/ERC20FlashMintHarness.sol

@@ -1,36 +0,0 @@
-// SPDX-License-Identifier: MIT
-
-pragma solidity ^0.8.0;
-
-import "../patched/token/ERC20/ERC20.sol";
-import "../patched/token/ERC20/extensions/ERC20Permit.sol";
-import "../patched/token/ERC20/extensions/ERC20FlashMint.sol";
-
-contract ERC20FlashMintHarness is ERC20, ERC20Permit, ERC20FlashMint {
-    uint256 someFee;
-    address someFeeReceiver;
-
-    constructor(string memory name, string memory symbol) ERC20(name, symbol) ERC20Permit(name) {}
-
-    function mint(address account, uint256 amount) external {
-        _mint(account, amount);
-    }
-
-    function burn(address account, uint256 amount) external {
-        _burn(account, amount);
-    }
-
-    // public accessor
-    function flashFeeReceiver() public view returns (address) {
-        return someFeeReceiver;
-    }
-
-    // internal hook
-    function _flashFee(address, uint256) internal view override returns (uint256) {
-        return someFee;
-    }
-
-    function _flashFeeReceiver() internal view override returns (address) {
-        return someFeeReceiver;
-    }
-}

package/test/contracts/lib/openzeppelin-contracts/certora/harnesses/ERC20PermitHarness.sol

@@ -1,17 +0,0 @@
-// SPDX-License-Identifier: MIT
-
-pragma solidity ^0.8.0;
-
-import "../patched/token/ERC20/extensions/ERC20Permit.sol";
-
-contract ERC20PermitHarness is ERC20Permit {
-    constructor(string memory name, string memory symbol) ERC20(name, symbol) ERC20Permit(name) {}
-
-    function mint(address account, uint256 amount) external {
-        _mint(account, amount);
-    }
-
-    function burn(address account, uint256 amount) external {
-        _burn(account, amount);
-    }
-}

package/test/contracts/lib/openzeppelin-contracts/certora/harnesses/ERC20WrapperHarness.sol

@@ -1,25 +0,0 @@
-// SPDX-License-Identifier: MIT
-
-pragma solidity ^0.8.0;
-
-import "../patched/token/ERC20/extensions/ERC20Wrapper.sol";
-
-contract ERC20WrapperHarness is ERC20Wrapper {
-    constructor(IERC20 _underlying, string memory _name, string memory _symbol) ERC20(_name, _symbol) ERC20Wrapper(_underlying) {}
-
-    function underlyingTotalSupply() public view returns (uint256) {
-        return underlying().totalSupply();
-    }
-
-    function underlyingBalanceOf(address account) public view returns (uint256) {
-        return underlying().balanceOf(account);
-    }
-
-    function underlyingAllowanceToThis(address account) public view returns (uint256) {
-        return underlying().allowance(account, address(this));
-    }
-
-    function recover(address account) public returns (uint256) {
-        return _recover(account);
-    }
-}