Tighten Tier 1 page and fix #validator Discord channel name

rice2000 · claude · rice2000 · commit dc280426dcb9 · 2026-05-07T13:22:19.000-04:00
- Restructure tier-1-orgs.mdx: move Step-by-Step checklist up to lead
  the actionable content, drop sections fully covered by the admin guide
  (history archives, quorum set, SEP-20 declaration, monitoring).
- Trim Tier 1 requirements table; drop week-range phase labels.
- Note in configuring.mdx that HIGH quality requires a history archive.
- Fix `#validators` -&gt; `#validator` in Discord channel references across
  ledgers.mdx, maintenance.mdx, tier-1-orgs.mdx.

Co-Authored-By: Claude Opus 4.7 (1M context) &lt;noreply@anthropic.com&gt;
diff --git a/docs/learn/fundamentals/stellar-data-structures/ledgers.mdx b/docs/learn/fundamentals/stellar-data-structures/ledgers.mdx
@@ -89,7 +89,7 @@ The close time is a UNIX timestamp indicating when the ledger closes. Its accura
 
 ### Upgrades
 
-How the network adjusts overall values (like the base fee) and agrees to network-wide changes (like switching to a new protocol version). This field is usually empty. When there is a network-wide upgrade, the SDF will inform and help coordinate participants using the #validators channel on the Dev Discord and the Stellar Validators Google Group.
+How the network adjusts overall values (like the base fee) and agrees to network-wide changes (like switching to a new protocol version). This field is usually empty. When there is a network-wide upgrade, the SDF will inform and help coordinate participants using the #validator channel on the Dev Discord and the Stellar Validators Google Group.
 
 ### Transaction set result hash
 
diff --git a/docs/validators/admin-guide/configuring.mdx b/docs/validators/admin-guide/configuring.mdx
@@ -96,7 +96,7 @@ QUALITY="MEDIUM"
 
 :::note Tier 1 quality rating
 
-The example above uses `QUALITY="MEDIUM"`, which is appropriate for a new validator building a track record. If your organization is a [Tier 1 participant](/docs/validators/tier-1-orgs) (or aspiring to become one), you should declare your own organization as `QUALITY="HIGH"`. Declaring a lower quality level significantly reduces your weight in [leader election](#impact-of-validator-quality-on-nomination) and may limit your participation in consensus.
+The example above uses `QUALITY="MEDIUM"`, which is appropriate for a new validator building a track record. If your organization is a [Tier 1 participant](/docs/validators/tier-1-orgs) (or aspiring to become one), you should declare your own organization as `QUALITY="HIGH"`. Note that `HIGH` quality requires [publishing a history archive](/docs/validators/admin-guide/publishing-history-archives) — the requirement is programmatically enforced. Declaring a lower quality level significantly reduces your weight in [leader election](#impact-of-validator-quality-on-nomination) and may limit your participation in consensus.
 
 :::
 
diff --git a/docs/validators/admin-guide/maintenance.mdx b/docs/validators/admin-guide/maintenance.mdx
@@ -25,7 +25,7 @@ We recommend performing the following steps in order (repeat sequentially as nee
 
 ## Special Considerations During Quorum Set Updates
 
-When you join the ranks of node operators, it's also important to join the conversation. The best way to do that: follow the`#validators` channel on the [Stellar Developer Discord](https://discord.gg/stellardev). If you can't do that for some reason, sign up for the [Stellar Validators Google Group](https://groups.google.com/forum/#!forum/stellar-validators).
+When you join the ranks of node operators, it's also important to join the conversation. The best way to do that: follow the `#validator` channel on the [Stellar Developer Discord](https://discord.gg/stellardev). If you can't do that for some reason, sign up for the [Stellar Validators Google Group](https://groups.google.com/forum/#!forum/stellar-validators).
 
 Sometimes an organization needs to make changes that will impact the quorum sets of others:
 
diff --git a/docs/validators/tier-1-orgs.mdx b/docs/validators/tier-1-orgs.mdx
@@ -21,13 +21,66 @@ Running a single [Basic or Full Validator](/docs/validators) is a meaningful con
 | --- | --- |
 | **Full Validators** | 3, each [publishing a separate history archive](/docs/validators/admin-guide/publishing-history-archives) |
 | **Geographic dispersion** | Nodes in different data centers or cloud regions |
-| **Quorum set** | Adopt the standard Tier 1 quorum set [configuration](/docs/validators/admin-guide/configuring#choosing-your-quorum-set) |
-| **Quality rating** | Declare your organization [`HIGH` quality](/docs/validators/admin-guide/configuring#validator-quality) |
 | **Self-verification** | [SEP-20](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0020.md) on-chain identity linking + [SEP-1](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0001.md) stellar.toml |
 | **Uptime** | 99.9%+ target with 24/7 [monitoring and alerting](/docs/validators/admin-guide/monitoring) |
 | **Coordination** | Active communication with other Tier 1 organizations |
 | **Trust** | Other Tier 1 organizations must choose to include you in their quorum sets |
 
+## Step-by-Step Path to Tier 1
+
+### Phase 1: First Full Validator
+
+Work through the [Admin Guide](/docs/validators/admin-guide) to stand up a single Full Validator on Mainnet:
+
+- [ ] Review [prerequisites](/docs/validators/admin-guide/prerequisites) and provision a server
+- [ ] [Install](/docs/validators/admin-guide/installation) Stellar Core
+- [ ] [Configure](/docs/validators/admin-guide/configuring) for Mainnet with a validator key pair (`stellar-core gen-seed`)
+- [ ] [Prepare your environment](/docs/validators/admin-guide/environment-preparation) and initialize the database
+- [ ] Set up a [history archive](/docs/validators/admin-guide/publishing-history-archives)
+- [ ] [Start your node](/docs/validators/admin-guide/running-node) and sync to the network
+- [ ] Set up [monitoring](/docs/validators/admin-guide/monitoring) with Prometheus + Grafana
+
+### Phase 2: Three Full Validators
+
+Scale to the Tier 1 architecture:
+
+- [ ] Provision 2 additional servers in **different geographic regions**
+- [ ] Generate **unique** key pairs for each node — never share seeds
+- [ ] Configure each with its own [history archive](/docs/validators/admin-guide/publishing-history-archives) (one archive per node)
+- [ ] Deploy the standard Tier 1 [quorum set](/docs/validators/admin-guide/configuring#choosing-your-quorum-set) on all three nodes, declaring your own organization as `HIGH` quality
+- [ ] Extend monitoring to cover all three nodes
+
+### Phase 3: Identity and Verification
+
+Make your organization discoverable and verifiable:
+
+- [ ] Configure public DNS for each node (e.g., `core-a.example.com`, `core-b.example.com`, `core-c.example.com`)
+- [ ] Create funded Stellar accounts for each validator node
+- [ ] Set home domain on-chain for each ([SEP-20](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0020.md))
+- [ ] Publish a complete stellar.toml ([SEP-1](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0001.md)) with organization info and all three `[[VALIDATORS]]` entries
+- [ ] Verify your nodes appear correctly on [Obsrvr Radar](https://radar.withobsrvr.com/)
+
+### Phase 4: Build Trust (Ongoing)
+
+Earn the confidence of existing Tier 1 organizations:
+
+- [ ] Join the [Stellar Dev Discord](https://discord.gg/stellardev) `#validator` channel
+- [ ] Maintain 99.9%+ uptime for 3+ months, visible on Obsrvr Radar
+- [ ] Participate in upgrade coordination and governance discussions
+- [ ] Respond promptly to maintenance coordination from other validators
+- [ ] Engage with SDF about Tier 1 candidacy when your track record is established
+
+### What Happens When You're Ready
+
+Once SDF and existing Tier 1 organizations agree you meet the bar:
+
+1. Existing Tier 1 organizations update their quorum sets to include your validators
+2. The standard Tier 1 quorum set configuration is updated to include your organization
+3. You begin appearing as Tier 1 on network monitoring tools
+4. You assume all the responsibilities described on this page
+
+This is not a unilateral decision by SDF. Every existing Tier 1 organization independently decides whether to trust you by adding you to their quorum set.
+
 ## Why Three Validators
 
 On Stellar, validators choose to trust _organizations_ when they configure their quorum set. If you are a trustworthy organization, you want your presence on the network to persist even if a node fails or you take it down for maintenance. A trio of validating nodes allows that to happen: other participants can require ⅔ of your nodes to agree. If one has issues, the other two still vote on your organization's behalf.
@@ -65,36 +118,6 @@ Becoming Tier 1 is not a unilateral decision by SDF — it depends on the quorum
 
 No single dimension is disqualifying on its own, but organizations that strengthen the network across multiple dimensions are the strongest candidates.
 
-## Publish History Archives
-
-In addition to participating in the Stellar Consensus Protocol, each Full Validator publishes an archive of network transactions. To do that, you need to [configure Stellar Core to record history](/docs/validators/admin-guide/publishing-history-archives) to a publicly accessible archive, and add the location of that archive to your stellar.toml.
-
-As a Tier 1 organization, **each of your three nodes must publish to a separate archive**. Never have two nodes write to the same archive — this causes undefined behavior and potential data loss. For example: `history-a.example.com`, `history-b.example.com`, `history-c.example.com`.
-
-Public archives make the network more resilient: when new nodes come online or existing nodes lose sync, they consult archives to catch up. More archives mean more redundancy and greater decentralization.
-
-## Set Up a Safe Quorum Set
-
-We recommend that every Tier 1 node use the same quorum set configuration, which is made up of inner quorum sets representing each Tier 1 organization. To configure a quorum set for your validator, we recommend copying the existing Tier 1 quorum set and adding your own organization to it.
-
-To see what the current recommended quorum set looks like, check out the [example Full Validator config file](https://github.com/stellar/packages/blob/master/docs/examples/pubnet-validator-full/stellar-core.cfg). For details on how quorum set configuration works, see [Choosing Your Quorum Set](/docs/validators/admin-guide/configuring#choosing-your-quorum-set).
-
-:::note
-
-Be sure to add your own validators to your quorum sets. As a Tier 1 organization with three validators and history archives, declare your organization [`HIGH` quality](/docs/validators/admin-guide/configuring#validator-quality). Declaring a lower quality level [limits your participation in consensus](/docs/validators/admin-guide/configuring#impact-of-validator-quality-on-nomination).
-
-:::
-
-## Declare Your Nodes (SEP-20)
-
-[SEP-20](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0020.md) creates a self-verified link between your validator nodes and your organization's website:
-
-1. **Create a funded Stellar account** for each validator node (1 XLM is sufficient).
-2. **Set the home domain** of each account to your organization's website using a [`set_options` operation](/docs/learn/fundamentals/transactions/list-of-operations#set-options).
-3. **Publish a stellar.toml** at `https://yourdomain.com/.well-known/stellar.toml` with full organization information and a `[[VALIDATORS]]` entry for each node, including public keys and history archive URLs.
-
-This allows anyone to look up your validator's public key, see its home domain, fetch the stellar.toml, and confirm the node belongs to your organization. See [SEP-1](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0001.md) for the full stellar.toml specification.
-
 ## Coordinate With Other Validators
 
 Whether you run three validators or one, coordinate with other validators when you make significant changes. Specifically, let them know when you plan to:
@@ -105,89 +128,17 @@ Whether you run three validators or one, coordinate with other validators when y
 
 For the Stellar network to expand safely, validators must coordinate off-chain to maintain good quorum intersection. Never change your quorum set without discussing it with other Tier 1 organizations first.
 
-## Monitor Your Nodes and Quorum Set
-
-Professional monitoring is a baseline expectation for Tier 1. Set up [Prometheus, Alertmanager, and Grafana](/docs/validators/admin-guide/monitoring) with the SDF-provided dashboards and alerting rules. Key metrics to watch:
-
-| Metric                           | Healthy      | Investigate            |
-| -------------------------------- | ------------ | ---------------------- |
-| `state`                          | `Synced!`    | Any other value        |
-| `ledger.age`                     | < 10 seconds | > 10 seconds           |
-| `quorum.qset.fail_at`            | ≥ 2          | ≤ 1                    |
-| `quorum.transitive.intersection` | `true`       | `false` — **critical** |
-
-You should also monitor your nodes' visibility on [Obsrvr Radar](https://radar.withobsrvr.com/), which other validators and SDF use to assess uptime and quorum health.
-
-## Keep Your Nodes Up To Date
-
-Running a validator requires vigilance. You need to keep your nodes on the latest version of Stellar Core, participate in protocol upgrade votes, and stay current on [Soroban settings](/docs/validators/admin-guide/soroban-settings) changes.
-
-Stay informed through these channels:
+## Stay Informed
 
 | Channel | Purpose |
 | --- | --- |
-| [Stellar Dev Discord](https://discord.gg/stellardev) — `#validators` | Primary coordination channel for validator operators. Release announcements, upgrade coordination, incident response. |
+| [Stellar Dev Discord](https://discord.gg/stellardev) — `#validator` | Primary coordination channel for validator operators. Release announcements, upgrade coordination, incident response. |
 | [stellar-core GitHub releases](https://github.com/stellar/stellar-core/releases) | Official release notes |
 | [Obsrvr Radar](https://radar.withobsrvr.com/) | Public validator uptime and quorum monitoring |
 
-## Step-by-Step Path to Tier 1
-
-### Phase 1: First Full Validator (Weeks 1–4)
-
-Work through the [Admin Guide](/docs/validators/admin-guide) to stand up a single Full Validator on Mainnet:
-
-- [ ] Review [prerequisites](/docs/validators/admin-guide/prerequisites) and provision a server
-- [ ] [Install](/docs/validators/admin-guide/installation) Stellar Core
-- [ ] [Configure](/docs/validators/admin-guide/configuring) for Mainnet with a validator key pair (`stellar-core gen-seed`)
-- [ ] [Prepare your environment](/docs/validators/admin-guide/environment-preparation) and initialize the database
-- [ ] Set up a [history archive](/docs/validators/admin-guide/publishing-history-archives)
-- [ ] [Start your node](/docs/validators/admin-guide/running-node) and sync to the network
-- [ ] Set up [monitoring](/docs/validators/admin-guide/monitoring) with Prometheus + Grafana
-
-### Phase 2: Three Full Validators (Weeks 4–8)
-
-Scale to the Tier 1 architecture:
-
-- [ ] Provision 2 additional servers in **different geographic regions**
-- [ ] Generate **unique** key pairs for each node — never share seeds
-- [ ] Configure each with its own [history archive](/docs/validators/admin-guide/publishing-history-archives) (one archive per node)
-- [ ] Deploy the standard Tier 1 [quorum set](/docs/validators/admin-guide/configuring#choosing-your-quorum-set) on all three nodes, declaring your own organization as `HIGH` quality
-- [ ] Extend monitoring to cover all three nodes
-
-### Phase 3: Identity and Verification (Week 8+)
-
-Make your organization discoverable and verifiable:
-
-- [ ] Configure public DNS for each node (e.g., `core-a.example.com`, `core-b.example.com`, `core-c.example.com`)
-- [ ] Create funded Stellar accounts for each validator node
-- [ ] Set home domain on-chain for each ([SEP-20](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0020.md))
-- [ ] Publish a complete stellar.toml ([SEP-1](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0001.md)) with organization info and all three `[[VALIDATORS]]` entries
-- [ ] Verify your nodes appear correctly on [Obsrvr Radar](https://radar.withobsrvr.com/)
-
-### Phase 4: Build Trust (Ongoing)
-
-Earn the confidence of existing Tier 1 organizations:
-
-- [ ] Join the [Stellar Dev Discord](https://discord.gg/stellardev) `#validators` channel
-- [ ] Maintain 99.9%+ uptime for 3+ months, visible on Obsrvr Radar
-- [ ] Participate in upgrade coordination and governance discussions
-- [ ] Respond promptly to maintenance coordination from other validators
-- [ ] Engage with SDF about Tier 1 candidacy when your track record is established
-
-### What Happens When You're Ready
-
-Once SDF and existing Tier 1 organizations agree you meet the bar:
-
-1. Existing Tier 1 organizations update their quorum sets to include your validators
-2. The standard Tier 1 quorum set configuration is updated to include your organization
-3. You begin appearing as Tier 1 on network monitoring tools
-4. You assume all the responsibilities described on this page
-
-This is not a unilateral decision by SDF. Every existing Tier 1 organization independently decides whether to trust you by adding you to their quorum set.
-
 ## Get in Touch
 
-If you think your organization is a strong Tier 1 candidate — or if you're working toward it and want guidance — reach out on the `#validators` channel in the [Stellar Dev Discord](https://discord.gg/stellardev). Community members and SDF team members can help you through the process.
+If you think your organization is a strong Tier 1 candidate — or if you're working toward it and want guidance — reach out on the `#validator` channel in the [Stellar Dev Discord](https://discord.gg/stellardev). Community members and SDF team members can help you through the process.
 
 As Stellar grows and more businesses build on the network, Tier 1 organizations will be crucial to healthy expansion of the network.
 
