supermajority is one word

book/src/implemented-proposals/staking-rewards.md

@@ -52,5 +52,5 @@ Solana's trustless sense of time and ordering provided by its PoH data structure
 
 As discussed in the [Economic Design](../implemented-proposals/ed_overview/) section, annual validator interest rates are to be specified as a function of total percentage of circulating supply that has been staked. The cluster rewards validators who are online and actively participating in the validation process throughout the entirety of their _validation period_. For validators that go offline/fail to validate transactions during this period, their annual reward is effectively reduced.
 
-Similarly, we may consider an algorithmic reduction in a validator's active amount staked amount in the case that they are offline. I.e. if a validator is inactive for some amount of time, either due to a partition or otherwise, the amount of their stake that is considered ‘active’ \(eligible to earn rewards\) may be reduced. This design would be structured to help long-lived partitions to eventually reach finality on their respective chains as the % of non-voting total stake is reduced over time until a super-majority can be achieved by the active validators in each partition. Similarly, upon re-engaging, the ‘active’ amount staked will come back online at some defined rate. Different rates of stake reduction may be considered depending on the size of the partition/active set.
+Similarly, we may consider an algorithmic reduction in a validator's active amount staked amount in the case that they are offline. I.e. if a validator is inactive for some amount of time, either due to a partition or otherwise, the amount of their stake that is considered ‘active’ \(eligible to earn rewards\) may be reduced. This design would be structured to help long-lived partitions to eventually reach finality on their respective chains as the % of non-voting total stake is reduced over time until a supermajority can be achieved by the active validators in each partition. Similarly, upon re-engaging, the ‘active’ amount staked will come back online at some defined rate. Different rates of stake reduction may be considered depending on the size of the partition/active set.
 

book/src/implemented-proposals/tower-bft.md

@@ -2,7 +2,7 @@
 
 This design describes Solana's _Tower BFT_ algorithm. It addresses the following problems:
 
-* Some forks may not end up accepted by the super-majority of the cluster, and voters need to recover from voting on such forks.
+* Some forks may not end up accepted by the supermajority of the cluster, and voters need to recover from voting on such forks.
 * Many forks may be votable by different voters, and each voter may see a different set of votable forks. The selected forks should eventually converge for the cluster.
 * Reward based votes have an associated risk. Voters should have the ability to configure how much risk they take on.
 * The [cost of rollback](tower-bft.md#cost-of-rollback) needs to be computable. It is important to clients that rely on some measurable form of Consistency. The costs to break consistency need to be computable, and increase super-linearly for older votes.

core/src/validator.rs

@@ -68,7 +68,7 @@ pub struct ValidatorConfig {
     pub broadcast_stage_type: BroadcastStageType,
     pub partition_cfg: Option<PartitionCfg>,
     pub fixed_leader_schedule: Option<FixedSchedule>,
-    pub wait_for_super_majority: bool,
+    pub wait_for_supermajority: bool,
 }
 
 impl Default for ValidatorConfig {
@@ -88,7 +88,7 @@ impl Default for ValidatorConfig {
             broadcast_stage_type: BroadcastStageType::Standard,
             partition_cfg: None,
             fixed_leader_schedule: None,
-            wait_for_super_majority: false,
+            wait_for_supermajority: false,
         }
     }
 }
@@ -297,7 +297,7 @@ impl Validator {
                 .set_entrypoint(entrypoint_info.clone());
         }
 
-        if config.wait_for_super_majority {
+        if config.wait_for_supermajority {
             info!(
                 "Waiting more than 66% of activated stake at slot {} to be in gossip...",
                 bank.slot()

validator/src/main.rs

@@ -538,10 +538,10 @@ pub fn main() {
                 .help("Redirect logging to the specified file, '-' for standard error"),
         )
         .arg(
-            Arg::with_name("wait_for_super_majority")
-                .long("wait-for-super-majority")
+            Arg::with_name("wait_for_supermajority")
+                .long("wait-for-supermajority")
                 .takes_value(false)
-                .help("After processing the ledger, wait until a super majority of stake is visible on gossip before starting PoH"),
+                .help("After processing the ledger, wait until a supermajority of stake is visible on gossip before starting PoH"),
         )
         .get_matches();
 
@@ -588,7 +588,7 @@ pub fn main() {
     validator_config.dev_halt_at_slot = value_t!(matches, "dev_halt_at_slot", Slot).ok();
 
     validator_config.rpc_config.enable_validator_exit = matches.is_present("enable_rpc_exit");
-    validator_config.wait_for_super_majority = matches.is_present("wait_for_super_majority");
+    validator_config.wait_for_supermajority = matches.is_present("wait_for_supermajority");
 
     validator_config.rpc_config.faucet_addr = matches.value_of("rpc_faucet_addr").map(|address| {
         solana_net_utils::parse_host_port(address).expect("failed to parse faucet address")