update some agave names to x1

Update names and repos to x1 and tacyhon

.github/CODEOWNERS

@@ -1 +1 @@
-* @anza-xyz/backport-reviewers
+* @x1-xyz/backport-reviewers

.gitignore

@@ -9,7 +9,7 @@ target/
 **/*.rs.bk
 .cargo
 
-/config/
+/config
 
 .cache
 
@@ -31,3 +31,4 @@ log-*/
 .DS_Store
 # scripts that may be generated by cargo *-bpf commands
 **/cargo-*-bpf-child-script-*.sh
+/config/

.mergify.yml

@@ -33,7 +33,7 @@ pull_request_rules:
     actions:
       request_reviews:
         teams:
-          - "@anza-xyz/community-pr-subscribers"
+          - "@x1-xyz/community-pr-subscribers"
   - name: label changes from monorepo-triage
     conditions:
       - author≠@core-contributors
@@ -98,7 +98,7 @@ pull_request_rules:
     actions:
       backport:
         assignees: &BackportAssignee
-          - "{{ merged_by|replace('mergify[bot]', label|select('equalto', 'community')|first|default(author)|replace('community', '@anza-xyz/community-pr-subscribers')) }}"
+          - "{{ merged_by|replace('mergify[bot]', label|select('equalto', 'community')|first|default(author)|replace('community', '@x1-xyz/community-pr-subscribers')) }}"
         title: "{{ destination_branch }}: {{ title }} (backport of #{{ number }})"
         ignore_conflicts: true
         labels:

CONTRIBUTING.md

@@ -255,9 +255,9 @@ before the PR can be merged.  Here are the steps:
 name = "solana-<PACKAGE_NAME>"
 version = "0.0.1"
 description = "<DESCRIPTION>"
-authors = ["Anza Maintainers <maintainers@anza.xyz>"]
-repository = "https://github.com/anza-xyz/agave"
-homepage = "https://anza.xyz"
+authors = ["X1 Labs maintainers <maintainers@x1.xyz>"]
+repository = "https://github.com/x1-labs/tachyon"
+homepage = "https://x1.xyz"
 documentation = "https://docs.rs/solana-<PACKAGE_NAME>"
 license = "Apache-2.0"
 edition = "2021"

Cargo.toml

@@ -139,9 +139,9 @@ resolver = "2"
 
 [workspace.package]
 version = "2.0.21"
-authors = ["Anza Maintainers <maintainers@anza.xyz>"]
-repository = "https://github.com/anza-xyz/agave"
-homepage = "https://anza.xyz/"
+authors = ["X1 Labs maintainers <maintainers@x1.xyz>"]
+repository = "https://github.com/x1-labs/tachyon"
+homepage = "https://x1.xyz/"
 license = "Apache-2.0"
 edition = "2021"
 

RELEASE.md

@@ -70,7 +70,7 @@ There are three release channels that map to branches as follows:
 1. Determine the new branch name.  The name should be "v" + the first 2 version fields
    from Cargo.toml.  For example, a Cargo.toml with version = "0.9.0" implies
    the next branch name is "v0.9".
-1. Create the new branch and push this branch to the `agave` repository:
+1. Create the new branch and push this branch to the `tachyon` repository:
     ```
     git checkout -b <branchname>
     git push -u origin <branchname>
@@ -99,23 +99,23 @@ Alternatively use the Github UI.
 ### Miscellaneous Clean up
 
 1. Pin the spl-token-cli version in the newly promoted stable branch by setting `splTokenCliVersion` in scripts/spl-token-cli-version.sh to the latest release that depends on the stable branch (usually this will be the latest spl-token-cli release).
-1. Update [mergify.yml](https://github.com/anza-xyz/agave/blob/master/.mergify.yml) to add backport actions for the new branch and remove actions for the obsolete branch.
-1. Adjust the [Github backport labels](https://github.com/anza-xyz/agave/labels) to add the new branch label and remove the label for the obsolete branch.
+1. Update [mergify.yml](https://github.com/x1-labs/tachyon/blob/master/.mergify.yml) to add backport actions for the new branch and remove actions for the obsolete branch.
+1. Adjust the [Github backport labels](https://github.com/x1-labs/tachyon/labels) to add the new branch label and remove the label for the obsolete branch.
 1. Announce on Discord #development that the release branch exists so people know to use the new backport labels.
 
 ## Steps to Create a Release
 
 ### Create the Release Tag on GitHub
 
-1. Go to [GitHub Releases](https://github.com/anza-xyz/agave/releases) for tagging a release.
+1. Go to [GitHub Releases](https://github.com/x1-labs/tachyon/releases) for tagging a release.
 1. Click "Draft new release".  The release tag must exactly match the `version`
    field in `/Cargo.toml` prefixed by `v`.
    1.  If the Cargo.toml version field is **0.12.3**, then the release tag must be **v0.12.3**
 1. Make sure the Target Branch field matches the branch you want to make a release on.
    1.  If you want to release v0.12.0, the target branch must be v0.12
 1. Fill the release notes.
    1.  If this is the first release on the branch (e.g. v0.13.**0**), paste in [this
-   template](https://raw.githubusercontent.com/anza-xyz/agave/master/.github/RELEASE_TEMPLATE.md).  Engineering Lead can provide summary contents for release notes if needed.
+   template](https://raw.githubusercontent.com/x1-labs/tachyon/master/.github/RELEASE_TEMPLATE.md).  Engineering Lead can provide summary contents for release notes if needed.
    1. If this is a patch release, review all the commits since the previous release on this branch and add details as needed.
 1. Click "Save Draft", then confirm the release notes look good and the tag name and branch are correct.
 1. Ensure all desired commits (usually backports) are landed on the branch by now.
@@ -126,24 +126,24 @@ Alternatively use the Github UI.
 
 ### Update release branch with the next patch version
 
-[This action](https://github.com/anza-xyz/agave/blob/master/.github/workflows/increment-cargo-version-on-release.yml) ensures that publishing a release will trigger the creation of a PR to update the Cargo.toml files on **release branch** to the next semantic version (e.g. 0.9.0 -> 0.9.1). Ensure that the created PR makes it through CI and gets submitted.
+[This action](https://github.com/x1-labs/tachyon/blob/master/.github/workflows/increment-cargo-version-on-release.yml) ensures that publishing a release will trigger the creation of a PR to update the Cargo.toml files on **release branch** to the next semantic version (e.g. 0.9.0 -> 0.9.1). Ensure that the created PR makes it through CI and gets submitted.
 
 Note: As of 2024-03-26 the above action is failing so version bumps are done manually. The version bump script is incorrectly updating hashbrown and proc-macro2 versions which should be reverted.
 
 ### Prepare for the next release
-1.  Go to [GitHub Releases](https://github.com/anza-xyz/agave/releases) and create a new draft release for `X.Y.Z+1` with empty release notes.  This allows people to incrementally add new release notes until it's time for the next release
+1.  Go to [GitHub Releases](https://github.com/x1-labs/tachyon/releases) and create a new draft release for `X.Y.Z+1` with empty release notes.  This allows people to incrementally add new release notes until it's time for the next release
     1. Also, point the branch field to the same branch and mark the release as **"This is a pre-release"**.
 
 ### Verify release automation success
-Go to [Agave Releases](https://github.com/anza-xyz/agave/releases) and click on the latest release that you just published.
+Go to [Tachyon Releases](https://github.com/x1-labs/tachyon/releases) and click on the latest release that you just published.
 Verify that all of the build artifacts are present (15 assets), then uncheck **"This is a pre-release"** for the release.
 
 Build artifacts can take up to 60 minutes after creating the tag before
 appearing.  To check for progress:
-* The `agave-secondary` Buildkite pipeline handles creating the Linux and macOS release artifacts and updated crates.  Look for a job under the tag name of the release: https://buildkite.com/anza-xyz/agave-secondary.
-* The Windows release artifacts are produced by GitHub Actions.  Look for a job under the tag name of the release: https://github.com/anza-xyz/agave/actions.
+* The `tachyon-secondary` Buildkite pipeline handles creating the Linux and macOS release artifacts and updated crates.  Look for a job under the tag name of the release: https://buildkite.com/x1-labs/tachyon-secondary.
+* The Windows release artifacts are produced by GitHub Actions.  Look for a job under the tag name of the release: https://github.com/x1-labs/tachyon/actions.
 
-[Crates.io tachyon-validator](https://crates.io/crates/tachyon-validator) should have an updated tachyon-validator version.  This can take 2-3 hours, and sometimes fails in the `agave-secondary` job.
+[Crates.io tachyon-validator](https://crates.io/crates/tachyon-validator) should have an updated tachyon-validator version.  This can take 2-3 hours, and sometimes fails in the `tachyon-secondary` job.
 If this happens and the error is non-fatal, click "Retry" on the "publish crate" job
 
 ### Update software on testnet.solana.com

SECURITY.md

@@ -5,11 +5,11 @@
 2. [Incident Response Process](#process)
 
 <a name="reporting"></a>
-## Reporting security problems in the Agave Validator
+## Reporting security problems in the Tachyon Validator
 
 **DO NOT CREATE A GITHUB ISSUE** to report a security problem.
 
-Instead please use this [Report a Vulnerability](https://github.com/anza-xyz/agave/security/advisories/new) link.
+Instead please use this [Report a Vulnerability](https://github.com/x1-labs/tachyon/security/advisories/new) link.
 Provide a helpful title, detailed description of the vulnerability and an exploit
 proof-of-concept. Speculative submissions without proof-of-concept will be closed
 with no further consideration.
@@ -25,15 +25,10 @@ Expect a response as fast as possible in the advisory, typically within 72 hours
 --
 
 If you do not receive a response in the advisory, send an email to
-security@anza.xyz with the full URL of the advisory you have created.  DO NOT
+security@x1.xyz with the full URL of the advisory you have created.  DO NOT
 include attachments or provide detail sufficient for exploitation regarding the
 security issue in this email. **Only provide such details in the advisory**.
 
-If you do not receive a response from [email protected] please followup with
-the team directly. You can do this in the `#core-technology` channel of the
-[Solana Tech discord server](https://solana.com/discord), by pinging the `Anza`
-role in the channel and referencing the fact that you submitted a security problem.
-
 <a name="process"></a>
 ## Incident Response Process
 
@@ -42,18 +37,18 @@ followed to contain, respond and remediate:
 
 ### 1. Accept the new report
 In response a newly reported security problem, a member of the
-`anza-xyz/admins` group will accept the report to turn it into a draft
-advisory.  The `anza-xyz/security-incident-response` group should be added to
+`x1-xyz/admins` group will accept the report to turn it into a draft
+advisory.  The `x1-xyz/security-incident-response` group should be added to
 the draft security advisory, and create a private fork of the repository (grey
 button towards the bottom of the page) if necessary.
 
 If the advisory is the result of an audit finding, follow the same process as above but add the auditor's github user(s) and begin the title with "[Audit]".
 
-If the report is out of scope, a member of the `anza-xyz/admins` group will
+If the report is out of scope, a member of the `x1-xyz/admins` group will
 comment as such and then close the report.
 
 ### 2. Triage
-Within the draft security advisory, discuss and determine the severity of the issue. If necessary, members of the anza-xyz/security-incident-response group may add other github users to the advisory to assist.
+Within the draft security advisory, discuss and determine the severity of the issue. If necessary, members of the x1-xyz/security-incident-response group may add other github users to the advisory to assist.
 If it is determined that this is not a critical network issue then the advisory should be closed and if more follow-up is required a normal Solana public github issue should be created.
 
 ### 3. Prepare Fixes
@@ -62,7 +57,7 @@ There is no CI available in the private repository so you must build from source
 Code review from the reporter is ideal, as well as from multiple members of the core development team.
 
 ### 4. Notify Security Group Validators
-Once an ETA is available for the fix, a member of the anza-xyz/security-incident-response group should notify the validators so they can prepare for an update using the "Solana Red Alert" notification system.
+Once an ETA is available for the fix, a member of the x1-xyz/security-incident-response group should notify the validators so they can prepare for an update using the "Solana Red Alert" notification system.
 The teams are all over the world and it's critical to provide actionable information at the right time. Don't be the person that wakes everybody up at 2am when a fix won't be available for hours.
 
 ### 5. Ship the patch

ci/buildkite-pipeline-in-disk.sh

@@ -289,7 +289,7 @@ if [[ -n $BUILDKITE_TAG ]]; then
   start_pipeline "Tag pipeline for $BUILDKITE_TAG"
 
   annotate --style info --context release-tag \
-    "https://github.com/FairCrypto/agave-xolana/releases/$BUILDKITE_TAG"
+    "https://github.com/x1-labs/tachyon/releases/$BUILDKITE_TAG"
 
   # Jump directly to the secondary build to publish release artifacts quickly
   trigger_secondary_step
@@ -307,7 +307,7 @@ if [[ $BUILDKITE_BRANCH =~ ^pull ]]; then
 
   # Add helpful link back to the corresponding Github Pull Request
   annotate --style info --context pr-backlink \
-    "Github Pull Request: https://github.com/FairCrypto/agave-xolana/$BUILDKITE_BRANCH"
+    "Github Pull Request: https://github.com/x1-labs/tachyon/$BUILDKITE_BRANCH"
 
   pull_or_push_steps
   exit 0

ci/buildkite-pipeline.sh

@@ -384,7 +384,7 @@ if [[ -n $BUILDKITE_TAG ]]; then
   start_pipeline "Tag pipeline for $BUILDKITE_TAG"
 
   annotate --style info --context release-tag \
-    "https://github.com/FairCrypto/agave-xolana/releases/$BUILDKITE_TAG"
+    "https://github.com/X1-labs/tachyon/releases/$BUILDKITE_TAG"
 
   # Jump directly to the secondary build to publish release artifacts quickly
   trigger_secondary_step
@@ -402,7 +402,7 @@ if [[ $BUILDKITE_BRANCH =~ ^pull ]]; then
 
   # Add helpful link back to the corresponding Github Pull Request
   annotate --style info --context pr-backlink \
-    "Github Pull Request: https://github.com/FairCrypto/agave-xolana/$BUILDKITE_BRANCH"
+    "Github Pull Request: https://github.com/X1-labs/tachyon/$BUILDKITE_BRANCH"
 
   pull_or_push_steps
   exit 0

ci/buildkite-solana-private.sh

@@ -287,7 +287,7 @@ if [[ $BUILDKITE_BRANCH =~ ^pull ]]; then
 
   # Add helpful link back to the corresponding Github Pull Request
   annotate --style info --context pr-backlink \
-    "Github Pull Request: https://github.com/FairCrypto/agave-xolana/$BUILDKITE_BRANCH"
+    "Github Pull Request: https://github.com/X1-labs/tachyon/$BUILDKITE_BRANCH"
 
   pull_or_push_steps
   exit 0

ci/channel-info.sh

@@ -11,7 +11,7 @@ here="$(dirname "$0")"
 # shellcheck source=ci/semver_bash/semver.sh
 source "$here"/semver_bash/semver.sh
 
-remote=https://github.com/FairCrypto/agave-xolana.git
+remote=https://github.com/X1-labs/tachyon.git
 
 # Fetch all vX.Y.Z tags
 #

ci/publish-installer.sh

@@ -26,14 +26,14 @@ fi
 # upload install script
 source ci/upload-ci-artifact.sh
 
-cat >release.anza.xyz-install <<EOF
+cat >release.x1.xyz-install <<EOF
 SOLANA_RELEASE=$CHANNEL_OR_TAG
 SOLANA_INSTALL_INIT_ARGS=$CHANNEL_OR_TAG
-SOLANA_DOWNLOAD_ROOT=https://release.anza.xyz
+SOLANA_DOWNLOAD_ROOT=https://release.x1.xyz
 EOF
-cat install/agave-install-init.sh >>release.anza.xyz-install
+cat install/agave-install-init.sh >>release.x1.xyz-install
 
 echo --- GCS: "install"
-upload-gcs-artifact "/solana/release.anza.xyz-install" "gs://anza-release/$CHANNEL_OR_TAG/install"
+upload-gcs-artifact "/solana/release.x1.xyz-install" "gs://anza-release/$CHANNEL_OR_TAG/install"
 echo Published to:
-ci/format-url.sh https://release.anza.xyz/"$CHANNEL_OR_TAG"/install
+ci/format-url.sh https://release.x1.xyz/"$CHANNEL_OR_TAG"/install

ci/publish-tarball.sh

@@ -122,7 +122,7 @@ for file in "${TARBALL_BASENAME}"-$TARGET.tar.bz2 "${TARBALL_BASENAME}"-$TARGET.
     upload-gcs-artifact "/solana/$file" gs://anza-release/"$CHANNEL_OR_TAG"/"$file"
 
     echo Published to:
-    $DRYRUN ci/format-url.sh https://release.anza.xyz/"$CHANNEL_OR_TAG"/"$file"
+    $DRYRUN ci/format-url.sh https://release.x1.xyz/"$CHANNEL_OR_TAG"/"$file"
 
     if [[ -n $TAG ]]; then
       ci/upload-github-release-asset.sh "$file"

ci/upload-github-release-asset.sh

@@ -26,7 +26,7 @@ fi
 # Force CI_REPO_SLUG since sometimes
 # BUILDKITE_TRIGGERED_FROM_BUILD_PIPELINE_SLUG is not set correctly, causing the
 # artifact upload to fail
-CI_REPO_SLUG=FairCrypto/agave-xolana
+CI_REPO_SLUG=X1-labs/tachyon
 #if [[ -z $CI_REPO_SLUG ]]; then
 #  echo Error: CI_REPO_SLUG not defined
 #  exit 1

docs/docusaurus.config.js

@@ -1,14 +1,14 @@
 const math = require("remark-math");
 const katex = require("rehype-katex");
 module.exports = {
-  title: "Agave",
+  title: "Tachyon",
   tagline:
-    "Agave is an open source project implementing a new, high-performance, permissionless blockchain.",
-  url: "https://docs.anza.xyz",
+    "Tachyon is an open source project implementing a new, high-performance, permissionless blockchain.",
+  url: "https://docs.x1.xyz",
   baseUrl: "/",
   favicon: "img/favicon.ico",
-  organizationName: "anza-xyz", // Usually your GitHub org/user name.
-  projectName: "agave", // Usually your repo name.
+  organizationName: "x1-labs", // Usually your GitHub org/user name.
+  projectName: "tachyon", // Usually your repo name.
   onBrokenLinks: "throw",
   stylesheets: [
     {
@@ -93,7 +93,7 @@ module.exports = {
           position: "right",
         },
         {
-          href: "https://github.com/anza-xyz/agave/",
+          href: "https://github.com/x1-labs/tachyon/",
           // label: "GitHub",
           className: "header-link-icon header-github-link",
           "aria-label": "GitHub repository",
@@ -141,7 +141,7 @@ module.exports = {
             },
             {
               label: "GitHub »",
-              href: "https://github.com/anza-xyz/agave",
+              href: "https://github.com/x1-labs/tachyon",
             },
             {
               label: "Discord »",
@@ -175,7 +175,7 @@ module.exports = {
           ],
         },
       ],
-      copyright: `Copyright © ${new Date().getFullYear()} Anza`,
+      copyright: `Copyright © ${new Date().getFullYear()} X1 Labs`,
     },
   },
   presets: [

docs/publish-docs.sh

@@ -9,15 +9,15 @@ fi
 CONFIG_FILE=vercel.json
 
 if [[ -n $CI_TAG ]]; then
-  PROJECT_NAME=docs-anza-xyz
+  PROJECT_NAME=docs-x1-xyz
 else
   eval "$(../ci/channel-info.sh)"
   case $CHANNEL in
   edge)
-    PROJECT_NAME=edge-docs-anza-xyz
+    PROJECT_NAME=edge-docs-x1-xyz
     ;;
   beta)
-    PROJECT_NAME=beta-docs-anza-xyz
+    PROJECT_NAME=beta-docs-x1-xyz
     ;;
   *)
     PROJECT_NAME=docs

docs/src/cli/index.md

@@ -11,7 +11,7 @@ cluster by delegating stake.
 
 To interact with a Solana cluster, we will use its command-line interface, also
 known as the CLI. We use the command-line because it is the first place the
-Anza core team deploys new functionality. The command-line interface is not
+X1 Labs core team deploys new functionality. The command-line interface is not
 necessarily the easiest to use, but it provides the most direct, flexible, and
 secure access to your Solana accounts.