certusone -> wormhole-foundation

.github/ISSUE_TEMPLATE/wormhole-issue-template.md

@@ -1,42 +1,49 @@
 ---
 name: Wormhole issue Template
 about: Default issue template
-title: ''
-labels: ''
-assignees: ''
-
+title: ""
+labels: ""
+assignees: ""
 ---
 
-Github issues are **ONLY** for reporting bugs. Before contributing new features (such as a new chain) please first read the [contribution frequently asked questions](https://github.com/certusone/wormhole/blob/dev.v2/CONTRIBUTING.md#contributions-faq).
+Github issues are **ONLY** for reporting bugs. Before contributing new features (such as a new chain) please first read the [contribution frequently asked questions](https://github.com/wormhole-foundation/wormhole/blob/dev.v2/CONTRIBUTING.md#contributions-faq).
 
 For user support questions such as VAA not found, please use the [Wormhole Official Discord](https://discord.gg/wormholecrypto). Do not give your wallet private key or mnemonic words to anyone.
 
 <!--- Provide a general summary of the issue in the Title above -->
 
 ## Expected Behavior
+
 <!--- Tell us what should happen -->
 
 ## Current Behavior
+
 <!--- Tell us what happens instead of the expected behavior -->
 
 ## Possible Solution
+
 <!--- Not obligatory, but suggest a fix/reason for the bug, -->
 
 ## Steps to Reproduce
+
 <!--- Provide a link to a live example, or an unambiguous set of steps to -->
 <!--- reproduce this bug. Include code to reproduce, if relevant -->
+
 1.
 2.
 3.
 
 ## Context (Environment)
+
 <!--- How has this issue affected you? What are you trying to accomplish? -->
 <!--- Providing context helps us come up with a solution that is most useful in the real world -->
 
 <!--- Provide a general summary of the issue in the Title above -->
 
 ## Detailed Description
+
 <!--- Provide a detailed description of the change or addition you are proposing -->
 
 ## Possible Implementation
+
 <!--- Not obligatory, but suggest an idea for implementing addition or change -->

.github/workflows/guardiand-docker.yml

@@ -10,7 +10,7 @@ on:
 
 env:
   REGISTRY: ghcr.io
-  IMAGE_NAME: certusone/guardiand
+  IMAGE_NAME: wormhole-foundation/guardiand
 
 jobs:
   build-and-push-image:

.github/workflows/relayer-docker.yml

@@ -7,7 +7,7 @@ on:
 
 env:
   REGISTRY: ghcr.io
-  IMAGE_NAME: certusone/payloadv1-relayer
+  IMAGE_NAME: wormhole-foundation/payloadv1-relayer
 
 jobs:
   build-and-push-relayer-image:

.spr.yml

@@ -1,4 +1,4 @@
-githubRepoOwner: certusone
+githubRepoOwner: wormhole-foundation
 githubRepoName: wormhole
 githubHost: github.com
 requireChecks: true

CONTRIBUTING.md

@@ -10,18 +10,15 @@ and code reviews are our most important tools to accomplish that.
   complex features, it can be useful to submit a [formal design document](design/template.md).
 
 - Development happens on a long-lived development branch (`dev.v2` and `dev.v1`).
-  Every change going into a development branch is reviewed individually (see below). Release branches may be used 
+  Every change going into a development branch is reviewed individually (see below). Release branches may be used
   to support in-the-wild releases of Wormhole. We aim to support at most two release
   branches at the same time. Changes can be cherry-picked from the development branch to release branches, but
   never from release branches to a development branch.
-
 - Releases are first tested on a testnet.
 
 - Commits should be small and have a meaningful commit message. One commit should, roughly, be "one idea" and
   be as atomic as possible. A feature can consist of many such commits.
-
 - Feature flags and interface evolution are better than breaking changes and long-lived feature branches.
-
 - We optimize for reading, not for writing - over its lifetime, code is read much more often than written.
   Small commits, meaningful commit messages and useful comments make it easier to review code and improve the
   quality of code review as well as review turnaround times. It's much easier to spot mistakes in small,
@@ -42,12 +39,10 @@ The answer is... maybe? The following things are needed in order to fully suppor
   a node or light client for every chain supported by Wormhole. This adds up, and the barrier to support new
   chains is pretty high. Your proposal should clearly outline the value proposition of supporting the new chain.
   **Convincing the DAO to run nodes for your chain is the first step in supporting a new chain.**
-
 - The chain needs to support smart contracts capable of verifying 19 individual secp256k1 signatures.
 
 - The smart contract needs to be built and audited. In some cases, existing contracts can be used, like with
   EVM-compatible chains.
-
 - Support for observing the chain needs to be added to guardiand.
 
 - Web wallet integration needs to be built to actually interact with Wormhole.
@@ -68,13 +63,17 @@ own features on top of, without requiring any changes in Wormhole itself.
 Please open a GitHub issue outlining your use case, and we can help you build it!
 
 # Pre-Commit checks
-Run `./scripts/lint.sh -d format` and `./scripts/lint.sh lint`. 
+
+Run `./scripts/lint.sh -d format` and `./scripts/lint.sh lint`.
 
 ## IDE Integration
+
 ### Golang formatting
-You must format your code with `goimports` before submitting. 
-You can install it with `go install golang.org/x/tools/cmd/goimports@latest` and run it with `goimports -d ./`. 
-You can enable it in VSCode with the following in your `settings.json`. 
+
+You must format your code with `goimports` before submitting.
+You can install it with `go install golang.org/x/tools/cmd/goimports@latest` and run it with `goimports -d ./`.
+You can enable it in VSCode with the following in your `settings.json`.
+
 ```json
   "go.useLanguageServer": true,
   "go.formatTool": "goimports",
@@ -95,22 +94,22 @@ We believe automated tests ensure the integrity of all Wormhole components. Anyo
 Places to find out more about existing test coverage and how to run those tests:
 
 - **Guardian Node**
-    - Tests: `./node/**/*_test.go`
-    - Run: `cd node && make test`
+  - Tests: `./node/**/*_test.go`
+  - Run: `cd node && make test`
 - **Ethereum Smart Contracts**
-    - Tests: `./ethereum/test/*.[js|sol]`
-    - Run: `cd ethereum && make test`
+  - Tests: `./ethereum/test/*.[js|sol]`
+  - Run: `cd ethereum && make test`
 - **Solana Smart Contracts**
-    - Tests: `./solana/bridge/program/tests/*.rs`
-    - Run: `cd solana && make test`
+  - Tests: `./solana/bridge/program/tests/*.rs`
+  - Run: `cd solana && make test`
 - **Terra Smart Contracts**
-    - Tests: `./terra/test/*`
-    - Run: `cd terra && make test`
+  - Tests: `./terra/test/*`
+  - Run: `cd terra && make test`
 - **Cosmwasm Smart Contracts**
-    - Tests: `./cosmwasm/test/*`
-    - Run: `cd cosmwasm && make test`
+  - Tests: `./cosmwasm/test/*`
+  - Run: `cd cosmwasm && make test`
 - **Algorand Smart Contracts**
-    - Tests: `./algorand/test/*`
-    - Run: `cd algorand && make test`
+  - Tests: `./algorand/test/*`
+  - Run: `cd algorand && make test`
 
-The best place to understand how we invoke these tests via GitHub Actions on every commit can be found via `./.github/workflows/*.yml` and the best place to observe the results of these builds can be found via [https://github.com/certusone/wormhole/actions](https://github.com/certusone/wormhole/actions).
+The best place to understand how we invoke these tests via GitHub Actions on every commit can be found via `./.github/workflows/*.yml` and the best place to observe the results of these builds can be found via [https://github.com/wormhole-foundation/wormhole/actions](https://github.com/wormhole-foundation/wormhole/actions).

DEVELOP.md

@@ -84,7 +84,7 @@ First, create an SSH key on the VM:
 
 You can then [add your public key on GitHub](https://github.com/settings/keys) and clone the repository:
 
-    git clone git@github.com:certusone/wormhole.git
+    git clone git@github.com:wormhole-foundation/wormhole.git
 
 Configure your Git identity:
 

Dockerfile.client

@@ -1,5 +1,5 @@
 #syntax=docker/dockerfile:1.2@sha256:e2a8561e419ab1ba6b2fe6cbdf49fd92b95912df1cf7d313c3e2230a333fdbcc
-FROM ghcr.io/certusone/solana:1.10.31@sha256:d31e8db926a1d3fbaa9d9211d9979023692614b7b64912651aba0383e8c01bad AS solana
+FROM ghcr.io/wormhole-foundation/solana:1.10.31@sha256:d31e8db926a1d3fbaa9d9211d9979023692614b7b64912651aba0383e8c01bad AS solana
 
 # libudev is needed by spl-token-cli, and ncat is needed by the devnet setup
 # script to be able to signal a health status for tilt

SECURITY.md

@@ -8,51 +8,52 @@ If you find a security issue in wormhole, we ask that you immediately **[report
 
 ## 3rd Party Security Audits
 
-We engage 3rd party firms to conduct independent security audits of Wormhole.  At any given time, we likely have multiple audit streams in progress.
+We engage 3rd party firms to conduct independent security audits of Wormhole. At any given time, we likely have multiple audit streams in progress.
 
 As these 3rd party audits are completed and issues are sufficiently addressed, we make those audit reports public.
 
 - **[January, 10, 2022 - Neodyme](https://storage.googleapis.com/wormhole-audits/2022-01-10_neodyme.pdf)**
-    - **Scopes**: *Ethereum Contracts, Solana Contracts, Terra Contracts, Guardian, and Solitaire*
+  - **Scopes**: _Ethereum Contracts, Solana Contracts, Terra Contracts, Guardian, and Solitaire_
 - **[July 1, 2022 - Kudelski](https://storage.googleapis.com/wormhole-audits/2022-07-01_kudelski.pdf)**
-    - **Scopes**: *Ethereum Contracts, Solana Contracts, Terra Contracts, and Guardian*
+  - **Scopes**: _Ethereum Contracts, Solana Contracts, Terra Contracts, and Guardian_
 
 ## White-Hat Hacking on Wormhole
 
-We want to lower the bar for White-hat hackers to find security bugs in Wormhole.  Why? The easier we make this process, the more likely it will be for white-hats to find bugs in Wormhole and responsibly disclose them, helping to secure the network.
+We want to lower the bar for White-hat hackers to find security bugs in Wormhole. Why? The easier we make this process, the more likely it will be for white-hats to find bugs in Wormhole and responsibly disclose them, helping to secure the network.
 
 Here's a list of strategies we've found helpful for getting started on Wormhole:
 
-- Review the existing unit and integration testing (found in [CONTRIBUTING.md](https://github.com/certusone/wormhole/blob/dev.v2/CONTRIBUTING.md)) and see what we're already testing for.
-    * Check out places were we might be missing test coverage entirely.  This could be a ripe spot to look for something we missed.
-    * Check out places were we have unit/integration tests, but we lack sufficient [negative test](https://en.wikipedia.org/wiki/Negative_testing) coverage.
+- Review the existing unit and integration testing (found in [CONTRIBUTING.md](https://github.com/wormhole-foundation/wormhole/blob/dev.v2/CONTRIBUTING.md)) and see what we're already testing for.
+  - Check out places were we might be missing test coverage entirely. This could be a ripe spot to look for something we missed.
+  - Check out places were we have unit/integration tests, but we lack sufficient [negative test](https://en.wikipedia.org/wiki/Negative_testing) coverage.
 - Review our different smart contract implementations (eg. Solana, EVM, CosmWasm, Move) and attempt to understand how and why they are different.
-    * Does one chain have a safety check that another chain doesn't?
-    * Does one chain have a specific set of nuances / gotchas that that were missed on another chain?
+  - Does one chain have a safety check that another chain doesn't?
+  - Does one chain have a specific set of nuances / gotchas that that were missed on another chain?
 - Consider going beyond the source code
-    * Review the deployed contracts on chain. Is something odd that we missed? 
+  - Review the deployed contracts on chain. Is something odd that we missed?
 
 We'll continue to iterate on this list of white-hat bootstrap strategies as we grow our lessons learned internally hacking on Wormhole and from other white-hats who have been successful via our bug bounty program.
 
-It's important to remember this is an iterative process. If you spend the time to come up with a new test case, but didn't actually find a bug, we'd be extremely appreciative if you'd be willing to send a [pull request](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request) with additional positive and negative test cases.  This process has shown repeatedly to improve your ability to understand Wormhole, and will increase your odds of success.
+It's important to remember this is an iterative process. If you spend the time to come up with a new test case, but didn't actually find a bug, we'd be extremely appreciative if you'd be willing to send a [pull request](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request) with additional positive and negative test cases. This process has shown repeatedly to improve your ability to understand Wormhole, and will increase your odds of success.
 
 ## Guidance to Chain Integrators
 
-As the list of chains connected to Wormhole increases, so does the risk that a given connected could introduce risks to the Wormhole network.  As a result, Wormhole does have built-in safety features (e.g.: [Governor white-paper](https://github.com/certusone/wormhole/blob/dev.v2/whitepapers/0007_governor.md)) to reduce the "blast radius" of such case. That said, a defense in depth strategy is required to do as much as possible to secure the network. As part of this methodology, the Wormhole project recommends that all connected chains current and future implement robust security programs of their own to do their part in managing chain compromise risk to the wormhole network.
+As the list of chains connected to Wormhole increases, so does the risk that a given connected could introduce risks to the Wormhole network. As a result, Wormhole does have built-in safety features (e.g.: [Governor white-paper](https://github.com/wormhole-foundation/wormhole/blob/dev.v2/whitepapers/0007_governor.md)) to reduce the "blast radius" of such case. That said, a defense in depth strategy is required to do as much as possible to secure the network. As part of this methodology, the Wormhole project recommends that all connected chains current and future implement robust security programs of their own to do their part in managing chain compromise risk to the wormhole network.
 
 Here are a few ways in which connected chains can maintain high security standards:
 
 For source code ensure relevant bits are:
+
 - All open source
 - Audited by an independent third party with public audit reports
 - Included in a public bug bounty program. The bounty rewards should be sufficiently large to incentivize white-hat mindshare in finding security bugs and responsibly disclosing them
 - Version control systems contain adequate access controls and mandatory code review (e.g.: In github, use of branch protection and a minimum of one independent reviewer to merge code)
-- Maintaining a [SECURITY.md](https://github.com/certusone/wormhole/blob/dev.v2/SECURITY.md) in the root of the repository (like this one) to offer guidance and transparency on security relevant topics
+- Maintaining a [SECURITY.md](https://github.com/wormhole-foundation/wormhole/blob/dev.v2/SECURITY.md) in the root of the repository (like this one) to offer guidance and transparency on security relevant topics
 - Includes sufficient unit and integration test coverage (including negative tests), which are run on every commit via continuous integration. Ensure that the results of those test runs are visible to the public
 
 Additionally, ensure:
 
 - The Wormhole team has sufficient contact information and an associated call or page tree to reach you in the event of a security incident.
 - That Wormhole has the full upgrade authority on relevant bridge contracts to act quickly in the case of a security incident.
 - You have an established incident response program in place, with established patterns and playbooks to ensure deterministic outcomes for containment.
-- When security issues do occur, that the chain makes every attempt to inform affected parties and leads with transparency.
+- When security issues do occur, that the chain makes every attempt to inform affected parties and leads with transparency.