llms

eshaben · eshaben · commit 57c03afe5caa · 2025-03-19T14:51:05.000-04:00
diff --git a/llms.txt b/llms.txt
@@ -10,12 +10,10 @@ Doc-Page: https://wormhole.com/docs/build/core-messaging/wormhole-relayers/
 Doc-Page: https://wormhole.com/docs/build/
 Doc-Page: https://wormhole.com/docs/build/multigov/deploy-to-evm/
 Doc-Page: https://wormhole.com/docs/build/multigov/deploy-to-solana/
-Doc-Page: https://wormhole.com/docs/build/multigov/deployment/
 Doc-Page: https://wormhole.com/docs/build/multigov/faq/
 Doc-Page: https://wormhole.com/docs/build/multigov/
 Doc-Page: https://wormhole.com/docs/build/multigov/upgrade-evm/
 Doc-Page: https://wormhole.com/docs/build/multigov/upgrade-solana/
-Doc-Page: https://wormhole.com/docs/build/multigov/upgrade/
 Doc-Page: https://wormhole.com/docs/build/queries/faqs/
 Doc-Page: https://wormhole.com/docs/build/queries/
 Doc-Page: https://wormhole.com/docs/build/queries/overview/
@@ -1152,114 +1150,6 @@ When deploying MultiGov on Solana, several key parameters need to be set. Here a
  - `hubDispatcher` ++"Pubkey"++ - the Solana public key derived from an Ethereum address on the hub chain that dispatches messages to the spoke chains. This is crucial for ensuring that only authorized messages from the hub are executed on the spoke
 --- END CONTENT ---
 
-Doc-Content: https://wormhole.com/docs/build/multigov/deployment/
---- BEGIN CONTENT ---
----
-title: MultiGov Deployment to EVM
-description: Set up and deploy MultiGov to EVM locally with step-by-step instructions for configuring, compiling, and deploying smart contracts across chains.
----
-
-# Deploy MultiGov on EVM
-
-This guide provodes instructions to set up and deploy the MultiGov governance system locally. Before diving into the technical deployment, ensure that MultiGov is the right fit for your project’s governance needs by following the steps for the [integration process](/docs/build/multigov/){target=\_blank}.
-
-Once your project is approved through the intake process and you’ve collaborated with the Tally team to tailor MultiGov to your requirements, use this guide to configure, compile, and deploy the necessary smart contracts across your desired blockchain networks. This deployment will enable decentralized governance across your hub and spoke chains.
-
-## Prerequisites 
-
-To interact with MultiGov, you'll need the following:
-
-- Install [Foundry](https://book.getfoundry.sh/getting-started/installation){target=\_blank}
-- Install [Git](https://git-scm.com/downloads){target=\_blank}
-- Clone the repository:
-   ```bash
-   git clone https://github.com/wormhole-foundation/multigov
-   cd evm # for evm testing/deploying
-   ```
-
-## Development Setup
-
-For developers looking to set up a local MultiGov environment:
-
-1. Install dependencies:
-   ```bash
-   forge install
-   ```
-
-2. Set up environment variables:
-   ```bash
-   cp .env.example .env
-   ```
-<<<<<<<< HEAD:build/multigov/deployment.md
-========
-
->>>>>>>> origin:build/multigov/deploy-to-evm.md
-   Edit `.env` with your specific [configuration](/docs/build/multigov/deployment/#configuration){target=\_blank}
-
-3. Compile contracts:
-   ```bash
-   forge build
-   ```
-
-4. Deploy contracts (example for Sepolia testnet): <!-- would be nice to cover the contracts before the deployment step -->
-
-    For hub chains:
-    ```bash
-    forge script script/DeployHubContractsSepolia.s.sol --rpc-url $SEPOLIA_RPC_URL --broadcast
-    ```
-
-    For spoke chains (e.g., Optimism Sepolia):
-    ```bash
-    forge script script/DeploySpokeContractsOptimismSepolia.s.sol --rpc-url $OPTIMISM_SEPOLIA_RPC_URL --broadcast
-    ```
-
-## Configuration
-
-When deploying MultiGov, several key parameters need to be set. Here are the most important configuration points:
-
-### Hub Governor Key Parameters
-
-- `initialVotingDelay` ++"uint256"++ - the delay measured in seconds before voting on a proposal begins. For example, `86400` is one day
-- `initialProposalThreshold`  ++"uint256"++ - the number of tokens needed to create a proposal
-- `initialQuorum` ++"uint256"++ - the minimum number of votes needed for a proposal to be successful
-- `initialVoteWeightWindow` ++"uint256"++ - a window where the minimum checkpointed voting weight is taken for a given address. The window ends at the vote start for a proposal and begins at the vote start minus the vote weight window. The voting window is measured in seconds, e.g., `86400` is one day
-
-    !!! note
-        This helps mitigate cross-chain double voting.
-
-### Hub Proposal Extender Key Parameters
-
-- `extensionDuration` ++"uint256"++ - the amount of time, in seconds, for which target proposals will be extended. For example, `10800` is three hours
-- `minimumExtensionDuration` ++"uint256"++ - lower time limit, in seconds, for extension duration. For example, `3600` is one hour
-
-### Spoke Vote Aggregator Key Parameters
-
-- `initialVoteWindow` ++"uint256"++ - the moving window in seconds for vote weight checkpoints. These checkpoints are taken whenever an address that is delegating sends or receives tokens. For example, `86400` is one day
-
-    !!! note
-        This is crucial for mitigating cross-chain double voting
-
-### Hub Evm Spoke Vote Aggregator Key Parameters
-
-- `maxQueryTimestampOffset` ++"uint256"++ - the max timestamp difference, in seconds, between the requested target time in the query and the current block time on the hub. For example, `1800` is 30 minutes
-
-### Updateable Governance Parameters
-
-The following key parameters can be updated through governance proposals:
-
-- `votingDelay` - delay before voting starts (in seconds)
-- `votingPeriod` - duration of the voting period (in seconds)
-- `proposalThreshold` - threshold for creating proposals (in tokens)
-- `quorum` - number of votes required for quorum
-- `extensionDuration` - the amount of time for which target proposals will be extended (in seconds)
-- `voteWeightWindow` - window for vote weight checkpoints (in seconds)
-- `maxQueryTimestampOffset` - max timestamp difference allowed between a query's target time and the hub's block time
-
-These parameters can be queried using their respective getter functions on the applicable contract.
-
-To update these parameters, a governance proposal must be created, voted on, and executed through the standard MultiGov process.
---- END CONTENT ---
-
 Doc-Content: https://wormhole.com/docs/build/multigov/faq/
 --- BEGIN CONTENT ---
 ---
@@ -1578,75 +1468,6 @@ Follow these steps to upgrade the MultiGov Staking Program on Solana.
     ```
 --- END CONTENT ---
 
-Doc-Content: https://wormhole.com/docs/build/multigov/upgrade/
---- BEGIN CONTENT ---
----
-title: Upgrading MultiGov on EVM
-description: Learn the process and key considerations for upgrading MultiGov on EVM, ensuring system integrity and careful planning across cross-chain components.
----
-
-# Upgrade MultiGov Contracts on EVM
-
-MultiGov is designed to be flexible but stable. Due to the system's complexity and cross-chain nature, upgrades should be rare and carefully considered. When upgrades are necessary, they must be meticulously planned and executed to ensure system integrity and continuity.
-
-## Key Considerations for Upgrades
-
-- **`HubGovernor`**:
-    - Not upgradeable. A new deployment requires redeploying several components of the MultiGov system. Refer to the [Process for Major System Upgrade](/docs/build/multigov/upgrade/#process-for-major-system-upgrade) section for more details 
-
-- **`HubVotePool`**:
-    - Can be replaced by setting a new `HubVotePool` on the `HubGovernor`
-    - Requires re-registering all spokes on the new `HubVotePool`
-    - Must register the query type and implementation for vote decoding by calling `registerQueryType` on the new `HubVotePool` <!-- put registerQueryType link back in once repo is public https://github.com/wormhole-foundation/example-multigov/blob/main/evm/src/HubVotePool.sol#L84 -->
-    - A new proposal would have to authorize the governor to use the newly created hub vote pool and will also handle registering the appropriate query decoders and registering the appropriate spoke `SpokeVoteAggregators`
-
-- **`SpokeMessageExecutor`**:
-    - Upgradeable via [UUPS](https://www.rareskills.io/post/uups-proxy){target=\_blank} proxy pattern
-    - Stores critical parameters in `SpokeMessageExecutorStorage`
-
-- **`HubEvmSpokeAggregateProposer`**:
-    - Needs redeployment if `HubGovernor` changes
-    - Requires re-registering all spokes after redeployment
-
-- **`HubProposalMetadata`**:
-    - Needs redeployment if `HubGovernor` changes, as it references `HubGovernor` as a parameter
-
-- **`SpokeMetadataCollector`**:
-    - Requires redeployment if the hub chain ID changes or if `HubProposalMetadata` changes
-
-## Process for Major System Upgrade 
-
-1. **New `HubGovernor` deployment**:
-    - Deploy the new `HubGovernor` contract
-1. **Component redeployment**:
-    - Redeploy `HubEvmSpokeAggregateProposer` with the new `HubGovernor` address
-    - Redeploy `HubProposalMetadata` referencing the new `HubGovernor`
-    - If hub chain ID changes, redeploy `SpokeMetadataCollector` on all spoke chains
-1. **`HubVotePool` update**:
-    - Set the new `HubVotePool` on the new `HubGovernor`
-    - Register all spokes on the new `HubVotePool`
-    - Register the query type and implementation for vote decoding (`HubEvmSpokeVoteDecoder`)
-1. **Spoke re-registration**:
-    - Re-register all spokes on the new `HubEvmSpokeAggregateProposer`
-1. **Verification and testing**:
-    - Conduct thorough testing of the new system setup
-    - Verify all cross-chain interactions are functioning correctly
-1. **System transition and deprecation**:
-    - Create a proposal to switch the timelock to the new governor
-    - Communicate clearly to the community what changes were made
-1. **Monitoring**:
-    - Implement a transition period where the new system is closely monitored
-    - Address any issues that arise promptly
-
-## Important Considerations
-
-- Always prioritize system stability, upgrades should only be performed when absolutely necessary
-- Thoroughly audit all new contract implementations before proposing an upgrade
-- Account for all affected components across all chains in the upgrade plan
-- Provide comprehensive documentation for the community about the upgrade process and any changes in functionality
-- Always test upgrades extensively on testnets before implementing in production
---- END CONTENT ---
-
 Doc-Content: https://wormhole.com/docs/build/queries/faqs/
 --- BEGIN CONTENT ---
 ---
