Remove Defender and Holesky (#2944)

* Remove Defender from the repo

* Removed Holesky test chain

* More Holesky changes

* Skip Sonic strategy fork tests

* Fix Base cross chain strategy fork tests

* Fix Base Curve AMO fork test

Author: naddison36

.gitignore

@@ -63,11 +63,7 @@ contracts/build/
 contracts/dist/
 contracts/.localKeyValueStorage
 contracts/.localKeyValueStorage.mainnet
-contracts/.localKeyValueStorage.holesky
 contracts/.localKeyValueStorage.base
-contracts/scripts/defender-actions/dist/
-
-contracts/lib/defender-actions/dist/
 
 todo.txt
 brownie/env-brownie/
@@ -93,4 +89,4 @@ unit-coverage
 .certora_internal
 
 # Possible Agent.md file
-AGENTS.md
+AGENTS.md

CLAUDE.md

@@ -9,7 +9,7 @@ Origin DeFi's OTokens monorepo containing smart contracts for:
 - **OETH** (Origin Ether) - an Ethereum liquid staking token
 - **OS** (Origin Sonic) - Sonic chain native token
 
-Deployed on Ethereum Mainnet, Base, Arbitrum, Sonic, Plume, Holesky, and Hoodi. All smart contract work happens in the `contracts/` directory.
+Deployed on Ethereum Mainnet, Base, Arbitrum, Sonic, Plume, Hoodi, and HyperEVM. All smart contract work happens in the `contracts/` directory.
 
 ## Setup
 
@@ -118,16 +118,11 @@ Key strategies: Aave, Compound, Convex/Curve, Balancer, Morpho, Native Staking (
 ### Harvesters
 `contracts/harvest/` - collect reward tokens from strategies and swap to yield-bearing assets. `Harvester` for OUSD, `OETHHarvester` for OETH, network-specific variants exist.
 
-### Automation (Defender Actions)
-`scripts/defender-actions/` - OpenZeppelin Defender automation scripts for:
-- `doAccounting` - periodic vault accounting
-- `harvest` - automated harvesting
-- `sonicRequestWithdrawal` / `sonicClaimWithdrawals` - Sonic staking lifecycle
-- `crossChainRelay` - Base ↔ Mainnet CCTP relay
-
-Bundle with: `pnpm rollup -c ./scripts/defender-actions/rollup.config.cjs`
-
-**Scheduled actions (Talos):** distinct from the Defender scripts above — the Talos runner's cron/manual actions live in `contracts/tasks/actions/*.ts`, are scheduled in `contracts/migrations/seed_schedules.sql`, and are catalogued in `contracts/docs/ACTIONS.md`. Update that doc in the same change whenever a scheduled action is added, removed, or its behaviour changes.
+### Automation (Talos)
+The Talos runner's cron/manual actions live in `contracts/tasks/actions/*.ts`,
+are scheduled in `contracts/migrations/seed_schedules.sql`, and are catalogued
+in `contracts/docs/ACTIONS.md`. Update that doc in the same change whenever a
+scheduled action is added, removed, or its behaviour changes.
 
 ### Cross-Chain
 - CCTP (Circle) for USDC bridging

contracts/README.md

@@ -248,7 +248,6 @@ When using Hardhat tasks, there are a few options for specifying the wallet to s
 1. Primary key
 2. AWS KMS signer
 3. Impersonate
-4. Defender Relayer
 
 ### Primary Key
 
@@ -314,144 +313,10 @@ pnpm hardhat healthcheck --network mainnet
 
 **No Postgres required for local runs.** The library's nonce queue is gated by `process.env.DATABASE_URL`: if unset, the action uses a raw ethers signer with ethers' own nonce handling. The gate is a single `if (!process.env.DATABASE_URL) return null` check at the top of the handler — no DB connection is opened. If you want to opt in locally (e.g., via `docker compose up`), set `DATABASE_URL` and the queue engages; `unset DATABASE_URL` to go back.
 
-Signer construction (KMS via `utils/signersNoHardhat.js`, `DEPLOYER_PK` / `GOVERNOR_PK` fallbacks, `IMPERSONATE`, Defender) stays exactly as described in the sections above. The library only handles the nonce wrap; it does not construct signers here.
-
-### Defender Relayer
-
-Open Zeppelin's [Defender](https://defender.openzeppelin.com/) product has a [Relayer](https://docs.openzeppelin.com/defender/v2/manage/relayers) service that is a managed wallet. It handles the nonce, gas, signing and sending of transactions.
-
-To use a [Relayer](https://defender.openzeppelin.com/v2/#/manage/relayers) account, first log into Defender and create an API key for the account you want to use. Use the generated API key and secret to set the `DEFENDER_API_KEY` and `DEFENDER_API_SECRET` environment variables.
-
-```
-export DEFENDER_API_KEY=
-export DEFENDER_API_SECRET=
-```
-
-Once you have finished sending your transactions, the API key for hte Relayer account should be deleted in Defender and the environment variables unset.
-
-```
-unset DEFENDER_API_KEY
-unset DEFENDER_API_SECRET
-```
-
-### Deploying Defender Actions
-
-Actions are used to run operational jobs are specific times or intervals.
-
-[rollup](https://rollupjs.org/) is used to bundle Actions source code in
-[/scripts/defender-actions](./scripts/defender-actions) into a single file that can be uploaded to Defender. The
-implementation was based off
-[Defender Actions example using Rollup](https://github.com/OpenZeppelin/defender-autotask-examples/tree/master/rollup).
-The rollup config is in [/scripts/defender-actions/rollup.config.cjs](./scripts/defender-actions/rollup.config.cjs). The
-outputs are written to task specific folders under [/scripts/defender-actions/dist](./scripts/defender-actions/dist/).
-
-The [defender-autotask CLI](https://www.npmjs.com/package/@openzeppelin/defender-autotask-client) is used to upload the
-Action code to Defender. For this to work, a Defender Team API key with `Manage Actions` capabilities is needed. This
-can be generated by a Defender team admin under the `Manage` tab on the top right of the UI and then `API Keys` on the
-left menu. Best to unselect all capabilities except `Manage Actions`.
-
-Save the Defender Team API key and secret to your `.env` file.
-
-```
-# Open Zeppelin Defender Team API key
-DEFENDER_TEAM_KEY=
-DEFENDER_TEAM_SECRET=
-```
-
-The following will bundle the Actions code ready for upload.
-
-```
-cd contracts
-pnpm rollup -c ./scripts/defender-actions/rollup.config.cjs
-```
-
-If you get error like the below, you will need to install `@rollup/rollup-darwin-x64`
-
-```
-Error: Cannot find module @rollup/rollup-darwin-x64. npm has a bug related to optional dependencies (https://github.com/npm/cli/issues/4828). Please try `npm i` again after removing both package-lock.json and node_modules directory.
-```
-
-If you are on Apple Silicon (M1/M2/M3) and you node is emulated x64, then the following will return `x64` rather than `arm64`.
-
-```
-node -p "process.arch"
-```
-
-If x64, run the following to install the required rollup package.
-
-```
-pnpm add -D @rollup/rollup-darwin-x64
-```
-
-The following will upload the different Action bundles to Defender.
-
-```sh
-cd contracts
-pnpm rollup -c ./scripts/defender-actions/rollup.config.cjs
-
-# Set the DEFENDER_TEAM_KEY and DEFENDER_TEAM_SECRET environment variables in the .env file
-
-# Set the DEBUG environment variable to oeth* for the Defender Action
-pnpm hardhat setActionVars --id e2929f53-db56-49b2-b054-35f7df7fc4fb
-pnpm hardhat setActionVars --id 6e4f764d-4126-45a5-b7d9-1ab90cd3ffd6
-pnpm hardhat setActionVars --id 84988850-6816-4074-8e7b-c11cb2b32e7e
-pnpm hardhat setActionVars --id f92ea662-fc34-433b-8beb-b34e9ab74685
-pnpm hardhat setActionVars --id b1d831f1-29d4-4943-bb2e-8e625b76e82c
-pnpm hardhat setActionVars --id 6567d7c6-7ec7-44bd-b95b-470dd1ff780b
-pnpm hardhat setActionVars --id 6a633bb0-aff8-4b37-aaae-b4c6f244ed87
-pnpm hardhat setActionVars --id 076c59e4-4150-42c7-9ba0-9962069ac353
-pnpm hardhat setActionVars --id ca80b55c-f3f7-4e03-a2f5-ea444645f8d9
-pnpm hardhat setActionVars --id f74f24b4-d98b-4181-89cc-6608369b6f91
-pnpm hardhat setActionVars --id aa194c13-0dbf-49d2-8e87-70e61f3d71a8
-pnpm hardhat setActionVars --id 65b53496-e426-4850-8349-059e63eb2120
-pnpm hardhat setActionVars --id a4f8ca5f-7144-469b-b84a-58b30fed72ce
-pnpm hardhat setActionVars --id cbddb98e-a0f6-4aa8-bd73-20aa8e81d704
-
-# Mainnet
-pnpm hardhat updateAction --id e2929f53-db56-49b2-b054-35f7df7fc4fb --file doAccounting
-pnpm hardhat updateAction --id 6e4f764d-4126-45a5-b7d9-1ab90cd3ffd6 --file harvest
-pnpm hardhat updateAction --id 84988850-6816-4074-8e7b-c11cb2b32e7e --file sonicRequestWithdrawal
-pnpm hardhat updateAction --id f92ea662-fc34-433b-8beb-b34e9ab74685 --file sonicClaimWithdrawals
-pnpm hardhat updateAction --id b1d831f1-29d4-4943-bb2e-8e625b76e82c --file claimBribes
-pnpm hardhat updateAction --id 6567d7c6-7ec7-44bd-b95b-470dd1ff780b --file manageBribeOnSonic
-pnpm hardhat updateAction --id 6a633bb0-aff8-4b37-aaae-b4c6f244ed87 --file managePassThrough
-pnpm hardhat updateAction --id 076c59e4-4150-42c7-9ba0-9962069ac353 --file manageBribes
-pnpm hardhat updateAction --id ca80b55c-f3f7-4e03-a2f5-ea444645f8d9 --file ousdRebalancer
-pnpm hardhat updateAction --id f74f24b4-d98b-4181-89cc-6608369b6f91 --file updateVotemarketEpochs
-pnpm hardhat updateAction --id aa194c13-0dbf-49d2-8e87-70e61f3d71a8 --file manageMerklBribes # Mainnet
-pnpm hardhat updateAction --id 65b53496-e426-4850-8349-059e63eb2120 --file manageMerklBribes # Base
-pnpm hardhat updateAction --id a4f8ca5f-7144-469b-b84a-58b30fed72ce --file claimSSVRewards
-
-# These are Base -> Mainnet & Mainnet -> Base actions
-# they share the codebase. The direction of relaying attestations is defined by the
-# network of the relayer that is attached to the action
-pnpm hardhat updateAction --id bb43e5da-f936-4185-84da-253394583665 --file crossChainRelay
-pnpm hardhat updateAction --id e571409b-5399-48e4-bfb2-50b7af9903aa --file crossChainRelay
-
-# One-off action for backfilling a missing tx-level key in Defender KV store
-pnpm hardhat updateAction --id cbddb98e-a0f6-4aa8-bd73-20aa8e81d704 --file crossChainRelayBackfillTx
-
-# OUSD Ethereum -> HyperEVM actions
-pnpm hardhat updateAction --id 0b852456-96a0-4f1d-9d6c-39e1c6ae9dfc --file crossChainRelayHyperEVM
-pnpm hardhat updateAction --id 65f04f74-8da7-4fc5-94b3-96be31bac03b --file crossChainRelayHyperEVM
-
-```
-
-To backfill a missing tx-level cross-chain relay key, set
-`HARDCODED_TRANSACTION_ID` and `HARDCODED_DESTINATION_CHAIN_ID` in
-`scripts/defender-actions/crossChainRelayBackfillTx.js`, then bundle/upload and
-run the `crossChainRelayBackfillTx` Action manually in Defender.
-
-This stores both tx-level keys with value `processed` in Defender's key-value
-store:
-
-- `cctp_message_<HARDCODED_TRANSACTION_ID>` (legacy format)
-- `cctp_message_<HARDCODED_TRANSACTION_ID>_<cctpDestinationDomainId>` (current
-  format from `tasks/crossChain.js`, where domain id is derived from the
-  hardcoded destination chain id: mainnet `1 -> 0`, base `8453 -> 6`, hyperevm
-  `999 -> 19`)
-
-`rollup` can be installed globally to avoid the `npx` prefix.
+Signer construction (KMS via `utils/signersNoHardhat.js`, `DEPLOYER_PK` /
+`GOVERNOR_PK` fallbacks, and `IMPERSONATE`) stays exactly as described in the
+sections above. The library only handles the nonce wrap; it does not construct
+signers here.
 
 ### Encrypting / decrypting validator private keys
 
@@ -470,7 +335,11 @@ The process is as follows:
 
 #### Storing encrypted validator private keys
 
-Defender Action that operates the validators will by default request a validator with encrypted private keys and store those encrypted keys in the `validator-keys` S3 bucket. Each validator private key is one S3 object and the name of the object is the pubkey (schema: [pubkey].json) of the validator. The S3 bucket has versioning enabled so we can always retrieve possibly overwritten / deleted objects.
+The validator automation requests validators with encrypted private keys and
+stores those encrypted keys in the `validator-keys` S3 bucket. Each validator
+private key is one S3 object and the name of the object is the pubkey (schema:
+`[pubkey].json`). The S3 bucket has versioning enabled so overwritten or deleted
+objects can be recovered.
 
 #### Storing the master private key
 

contracts/contracts/automation/AutoWithdrawalModule.sol

@@ -16,7 +16,7 @@ import { IStrategy } from "../interfaces/IStrategy.sol";
  *      1. Deploy this module
  *      2. Call `safe.enableModule(address(this))` to authorize it
  *
- *      An off-chain operator (e.g. Defender Relayer) calls `fundWithdrawals()`
+ *      An off-chain operator calls `fundWithdrawals()`
  *      periodically. The module:
  *        - First tries to satisfy the queue from idle vault funds
  *        - If there's still a shortfall, withdraws the exact shortfall amount
@@ -66,7 +66,7 @@ contract AutoWithdrawalModule is AbstractSafeModule {
 
     /**
      * @param _safeContract Address of the Gnosis Safe (Guardian multisig).
-     * @param _operator     Address of the off-chain operator (e.g. Defender relayer).
+     * @param _operator     Address of the off-chain operator.
      * @param _vault        Address of the OUSD/OETH vault.
      * @param _strategy     Initial strategy to pull liquidity from.
      */
@@ -91,7 +91,7 @@ contract AutoWithdrawalModule is AbstractSafeModule {
 
     /**
      * @notice Fund the vault's withdrawal queue from the configured strategy.
-     *         Called periodically by an off-chain operator (Defender Actions).
+     *         Called periodically by an off-chain operator.
      *
      * Steps:
      *   1. Ask the vault to absorb any idle asset it already holds.
@@ -100,7 +100,7 @@ contract AutoWithdrawalModule is AbstractSafeModule {
      *
      * This function never reverts on "soft" failures (strategy underfunded,
      * Safe exec failure). It emits a descriptive event instead so off-chain
-     * monitoring can alert the team without breaking the Defender action.
+     * monitoring can alert the team without breaking the automation action.
      */
     function fundWithdrawals() external onlyOperator {
         // Step 1: Let the vault absorb any asset it already holds idle.

contracts/contracts/automation/RebalancerModule.sol

@@ -16,7 +16,7 @@ import { VaultStorage } from "../vault/VaultStorage.sol";
  *      1. Deploy this module
  *      2. Call `safe.enableModule(address(this))` to authorize it
  *
- *      An off-chain operator (e.g. Defender Action) calls
+ *      An off-chain operator calls
  *      `processWithdrawalsAndDeposits` periodically with computed strategy/amount
  *      arrays. Either array may be empty. All intelligence (APY fetching, target
  *      allocation, constraint enforcement) lives off-chain. This contract is a
@@ -87,7 +87,7 @@ contract RebalancerModule is AbstractSafeModule {
 
     /**
      * @param _safeContract Address of the Gnosis Safe (Guardian multisig).
-     * @param _operator     Address of the off-chain operator (e.g. Defender relayer).
+     * @param _operator     Address of the off-chain operator.
      * @param _vault        Address of the OUSD vault.
      */
     constructor(

contracts/contracts/strategies/NativeStaking/ValidatorAccountant.sol

@@ -91,7 +91,7 @@ abstract contract ValidatorAccountant is ValidatorRegistrator {
     /// the accounting function will treat that as a validator slashing.
     /// @notice Perform the accounting attributing beacon chain ETH to either full or partial withdrawals. Returns true when
     /// accounting is valid and fuse isn't "blown". Returns false when fuse is blown.
-    /// @dev This function could in theory be permission-less but lets allow only the Registrator (Defender Action) to call it
+    /// @dev This function could in theory be permission-less but only the automation registrator can call it
     /// for now.
     /// @return accountingValid true if accounting was successful, false if fuse is blown
     /* solhint-enable max-line-length */

contracts/deploy/deployActions.js

@@ -23,7 +23,6 @@ const {
 const { replaceContractAt } = require("../utils/hardhat");
 const { resolveContract } = require("../utils/resolvers");
 const { impersonateAccount, getSigner } = require("../utils/signers");
-const { getDefenderSigner } = require("../utils/signersNoHardhat");
 const { sleep } = require("../utils/time");
 const { getTxOpts } = require("../utils/tx");
 const createxAbi = require("../abi/createx.json");
@@ -199,7 +198,7 @@ const upgradeNativeStakingSSVStrategy = async () => {
 
   const networkName = await getNetworkName();
   if (networkName == "hoodi") {
-    const sGovernor = isFork ? await getSigner() : await getDefenderSigner();
+    const sGovernor = await getSigner();
     await withConfirmation(
       strategyProxy.connect(sGovernor).upgradeTo(dStrategyImpl.address)
     );
@@ -232,7 +231,7 @@ const upgradeCompoundingStakingSSVStrategy = async () => {
     ]
   );
 
-  const sDeployer = isFork ? await getSigner() : await getDefenderSigner();
+  const sDeployer = await getSigner();
   await withConfirmation(
     strategyProxy.connect(sDeployer).upgradeTo(dStrategyImpl.address)
   );
@@ -390,7 +389,7 @@ const deployCompoundingStakingSSVStrategy = async () => {
   const cBeaconProofs = await ethers.getContract("BeaconProofs");
 
   let governorAddress;
-  // Deploy the proxy on Hoodi fork not as defender relayer since we will not
+  // Deploy the proxy on a Hoodi fork with the local signer since we will not
   // test SSV token claiming on that testnet
   if ((isTest && !isFork) || networkName == "hoodi") {
     // For unit tests and Hoodi, use the Governor contract
@@ -425,7 +424,7 @@ const deployCompoundingStakingSSVStrategy = async () => {
     );
   } else {
     // For fork tests, mainnet and Hoodi deployments.
-    // Should have already been deployed by the Defender Relayer as SSV rewards are sent to the deployer.
+    // Should already be deployed by the production signer because SSV rewards are sent to the deployer.
     // Use the deployStakingProxy Hardhat task to deploy
     cCompoundingStakingSSVStrategyProxy = await ethers.getContract(
       "CompoundingStakingSSVStrategyProxy"
@@ -447,7 +446,7 @@ const deployCompoundingStakingSSVStrategy = async () => {
       cCompoundingStakingSSVStrategyProxy.connect(sDeployer).claimGovernance()
     );
   } else {
-    /* Before kicking off the deploy script make sure the Defender relayer transfers the governance
+    /* Before kicking off the deploy script make sure the production signer transfers governance
      * of the proxy to the deployer account that shall be deploying this script so it will be able
      * to initialize the proxy contract
      *