From 2a5d3bf30c07c28f8dbac57d5aaa1ed1542b83d2 Mon Sep 17 00:00:00 2001 From: cam-schultz Date: Fri, 22 Nov 2024 08:56:26 -0600 Subject: [PATCH 1/3] remove dead link --- contracts/ictt/README.md | 7 ------- 1 file changed, 7 deletions(-) diff --git a/contracts/ictt/README.md b/contracts/ictt/README.md index 24875fd9b..9a7402277 100644 --- a/contracts/ictt/README.md +++ b/contracts/ictt/README.md @@ -19,13 +19,6 @@ The token transferrer also supports "multi-hop" transfers, where tokens can be t In addition to supporting basic token transfers, the token transferrer contracts offer a `sendAndCall` interface for transferring tokens and using them in a smart contract interaction all within a single Teleporter message. If the call to the recipient smart contract fails, the transferred tokens are sent to a fallback recipient address on the destination chain of the transfer. The `sendAndCall` interface enables the direct use of transferred tokens in dApps on other chains, such as performing swaps, using the tokens to pay for fees when invoking services, etc. -A breakdown of the structure of the contracts that implement this function can be found under `./contracts` [here](./contracts/README.md). - -## Audits - -Some contracts in this repository have been audited. The `main` branch may contain unaudited code. Please check [here](./audits/README.md) for which versions of each contract have been audited. -DO NOT USE UN-AUDITED CODE IN PRODUCTION! - ## Upgradability The token transferrer contracts implement both upgradeable and non-upgradeable versions. The non-upgradeable versions are extensions of their respective upgradeable token transferrer contract, and has a `constructor` that calls the `initialize` function of the upgradeable version. The upgradeable contracts are ERC7201 compliant, and use namespace storage to store the state of the contract. From a545672a3d273be3f74d3a8c099fe1e08ca9de2a Mon Sep 17 00:00:00 2001 From: cam-schultz Date: Fri, 22 Nov 2024 08:56:38 -0600 Subject: [PATCH 2/3] remove unaudited notice --- contracts/validator-manager/README.md | 3 --- 1 file changed, 3 deletions(-) diff --git a/contracts/validator-manager/README.md b/contracts/validator-manager/README.md index 5932d4cc9..12202aa76 100644 --- a/contracts/validator-manager/README.md +++ b/contracts/validator-manager/README.md @@ -1,8 +1,5 @@ # Validator Manager Contract -> [!CAUTION] -> The contracts in this directory are still under active development, are unaudited, and should not be used in production. - The contracts in this directory define the Validator Manager used to manage Avalanche L1 validators, as defined in [ACP-77](https://github.com/avalanche-foundation/ACPs/tree/main/ACPs/77-reinventing-subnets). `ValidatorManager.sol` is the top-level abstract contract that provides the basic functionality. The other contracts are related as follows: ```mermaid From 25e128df3253d22162ff29a43326c573c122f4e1 Mon Sep 17 00:00:00 2001 From: cam-schultz Date: Fri, 22 Nov 2024 08:57:19 -0600 Subject: [PATCH 3/3] add audit notice --- contracts/README.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/contracts/README.md b/contracts/README.md index f94cd1227..2f5bd6549 100644 --- a/contracts/README.md +++ b/contracts/README.md @@ -10,3 +10,10 @@ This directory is set up as a [Foundry](https://github.com/foundry-rs/foundry) p ## Generate documentation - Documentation can be generated by running `forge doc --build` from this repository. By default, this will generate documentation to `contracts/docs/`, and an HTML book to `contracts/docs/book/`. It's also possible to serve this book locally by running `forge doc --serve `. + +## Audits + +In general, the contracts in this repository have been audited. Any unaudited contracts will be explicitly marked as such. Note that the `main` branch may contain unaudited code. Please check [here](../audits/README.md) for which versions of each contract have been audited. + +> [!CAUTION] +> DO NOT USE UN-AUDITED CODE IN PRODUCTION! \ No newline at end of file