Merge pull request #279 from anoma/bengt/cuppa-tea

Bengt/cuppa tea

packages/docs/pages/integrating-with-namada/sdk/generating-accounts.mdx

@@ -21,7 +21,7 @@ struct MultisigAccount {
 }
 ```
 
-Multisignature accounts, because they are initialised by an on-chain transaction, will always have their public key revealed to the ledger. However, when keypairs are generated in an offline fashion, the user must submit a transaction in order to reveal their public key. Because of this, it is helpful to add the field `revealed` to the account struct.
+Multisignature accounts, because they are initialized by an on-chain transaction, will always have their public key revealed to the ledger. However, when keypairs are generated in an offline fashion, the user must submit a transaction in order to reveal their public key. Because of this, it is helpful to add the field `revealed` to the account struct.
 
 ```rust
 use namada_sdk::core::types::key::common::{PublicKey, SecretKey};

packages/docs/pages/networks/testnets.mdx

@@ -45,7 +45,7 @@ If you find a bug, please submit an issue with the `bug` [issue template](https:
 ## Testnet flowchart
 ![testnet_flowchart](/images/testnet_flowchart.png)
 
-The Namada public testnet is permissionless, anyone can join without the authorisation of a centralised party. Expect frequent upgrades (every two weeks).
+The Namada public testnet is permissionless, anyone can join without the authorisation of a centralized party. Expect frequent upgrades (every two weeks).
 
 ## Block explorer
 

packages/docs/pages/operators/networks.mdx

@@ -4,5 +4,5 @@ This guide will explore setting up Namada networks.
 
 It is broken into the following sections:
 
-* [Decentralised network setup](./networks/genesis-flow.mdx)
+* [Decentralized network setup](./networks/genesis-flow.mdx)
 * [Local network setup](./networks/local-network.mdx)

packages/docs/pages/operators/networks/_meta.json

@@ -1,4 +1,4 @@
 {
-    "genesis-flow": "Setting up a decentralised network",
+    "genesis-flow": "Setting up a decentralized network",
     "local-network": "Setting up a local network"
 }

packages/docs/pages/operators/networks/genesis-flow.mdx

@@ -1,6 +1,6 @@
 # Setting up a decentarlised Namada network
 
-Setting up a decentralised Namada network requires coordination between two distinct parties:
+Setting up a decentralized Namada network requires coordination between two distinct parties:
 
 1. [The network coordinator](./genesis-flow/coordinator.mdx#the-network-coordinator)
 2. [The pre-genesis network participants](./genesis-flow/participants.mdx#pre-genesis-network-participants)

packages/docs/pages/operators/networks/genesis-flow/participants.mdx

@@ -182,7 +182,7 @@ The optional `--discord-handle` flag is the discord handle of the validator acco
 
 The `--address` flag is the Namada address of the account.
 
-The `--path` flag is the path to the `transactions.toml` file that will be appended to, and requires the established account to already be initialised under.
+The `--path` flag is the path to the `transactions.toml` file that will be appended to, and requires the established account to already be initialized under.
 
 </Callout>
 

packages/docs/pages/operators/validators/proof-of-stake.mdx

@@ -32,7 +32,7 @@ Validators on Namada are slashed for misbehavior. Automatic slashing conditions
 
 ## Jailing
 
-Validators on Namada are jailed for either misbehaviour or for being offline for too long. If a number of blocks pass (also defined in the protocol parameters under `liveness_window_check`) in which none have been signed by the validator in question, the validator is jailed.
+Validators on Namada are jailed for either misbehavior or for being offline for too long. If a number of blocks pass (also defined in the protocol parameters under `liveness_window_check`) in which none have been signed by the validator in question, the validator is jailed.
 
 When a validator is jailed, they are unable to participate in the consensus protocol. A validator is jailed for at least the pipeline amount of epochs, but must be unjailed manually by the validator. This is done by submitting an `unjail-validator` command.
 

packages/docs/pages/operators/validators/validator-setup.mdx

@@ -18,7 +18,7 @@ The method for setting up a genesis validator is described under the [pre-genesi
 
 ## Post-genesis validators
 
-Post-genesis validators are validators that become initialised after the genesis block. This is the most common way of becoming a validator, and is the method described in this section.
+Post-genesis validators are validators that become initialized after the genesis block. This is the most common way of becoming a validator, and is the method described in this section.
 
 <Callout type="info" emoji="🤡">
 Note the use  of the placeholder `aliace` for the alias parameter. This is a completely configurable parameter, and should just refer to the alias of the key/address generated.

packages/docs/pages/users/transparent-accounts.mdx

@@ -6,7 +6,7 @@ All accounts in Namada have a unique address, exactly one Validity Predicate and
 
 There are currently 3 types of account addresses:
 - **Implicit:** An implicit account is derived from your keypair and can be used to authorize certain transactions from the account. Implicit accounts have no code attached to them, and can only have one key controlling it. This differs it from established accounts, which can support multiple keys.
-- **Established:** An established account is a associated with one or more cryptographic keys. Each account has the `vp_user` predicate which validate any associated transaction. The main purpose of this code is to ensure that the multisignature threshold is correctly met and stores the keys that verify transactions. All established accounts will be inititalised through on-chain transactions, unlike implicit accounts, which exist as soon as the keypair is generated.
+- **Established:** An established account is a associated with one or more cryptographic keys. Each account has the `vp_user` predicate which validate any associated transaction. The main purpose of this code is to ensure that the multisignature threshold is correctly met and stores the keys that verify transactions. All established accounts will be initialized through on-chain transactions, unlike implicit accounts, which exist as soon as the keypair is generated.
 - **Internal:** Special internal accounts, such as protocol parameters account, PoS and IBC.
 
 ## Manage keypairs

packages/docs/pages/users/transparent-accounts/multisignature.mdx

@@ -25,7 +25,7 @@ namadaw gen \
 --alias my-key2
 ```
 
-Accounts on Namada are initialised through the following method:
+Accounts on Namada are initialized through the following method:
 
 **Non-multisig account (single signer)**
 ```shell

packages/specs/pages/base-ledger/multisignature.mdx

@@ -61,7 +61,7 @@ Once this transaction is executed, the following storage writes are made in asso
 - The threshold of the multisignature account
 - The list of public keys for the signers of the multisignature account
 
-Multisignature accounts can also be initialised at genesis time - in this case, the requisite parameters are kept in the genesis file and written to storage during initialisation.
+Multisignature accounts can also be initialized at genesis time - in this case, the requisite parameters are kept in the genesis file and written to storage during initialisation.
 
 ## Multisig account init validation
 

packages/specs/pages/economics/proof-of-stake.mdx

@@ -18,7 +18,7 @@ with the intent of carrying out attacks. Many PoS blockchains rely on the 1/3 By
 ## Goals of Rewards and Slashing: Liveness and Security
 
 * **Security: Delegation and Slashing**: we want to make sure validators are 
-  backed by enough funds to make misbehaviour very expensive. Security is 
+  backed by enough funds to make misbehavior very expensive. Security is 
   achieved by punishing (slashing) if they do. *Slashing* locked funds (stake)
   intends to disincentivize diverging from correct execution of protocol, 
   which in this case is voting to finalize valid blocks. 

packages/specs/pages/economics/proof-of-stake/objects-and-txs.mdx

@@ -13,7 +13,7 @@ The data relevant to the PoS system in the ledger's state are epoched. Each data
 
 Changes to the epoched data do not take effect immediately. Instead, changes in epoch `n` are queued to take effect in the epoch `n + pipeline_length` for most cases and `n + pipeline_length + unbonding_length + cubic_slash_window_width` for [unbonding](#unbond) actions. Should the same validator's data or same bonds (i.e. with the same identity) be updated more than once in the same epoch, the later update overrides the previously queued-up update. For bonds and unbonds, the token amounts are added up. Once the epoch `n` has ended, the queued-up updates for epoch `n + pipeline_length` are final and the values become immutable.
 
-Additionally, any account may submit evidence for [a slashable misbehaviour](#slashing).
+Additionally, any account may submit evidence for [a slashable misbehavior](#slashing).
 
 ### Validator
 
@@ -117,7 +117,7 @@ Once an offense has been reported:
 
 Instead of absolute values, validators' total bonded token amounts and bonds' and unbonds' token amounts are stored as their deltas (i.e. the change of quantity from a previous epoch) to allow distinguishing changes for different epoch, which is essential for determining whether tokens should be slashed. Slashes for a fault that occurred in epoch `n` may only be applied before the beginning of epoch `n + unbonding_length`. For this reason, in epoch `m` we can sum all the deltas of total bonded token amounts and bonds and unbond with the same source and validator for epoch equal or less than `m - unbonding_length` into a single total bonded token amount, single bond and single unbond record. This is to keep the total number of total bonded token amounts for a unique validator and bonds and unbonds for a unique pair of source and validator bound to a maximum number (equal to `unbonding_length`).
 
-To disincentivize validators misbehaviour in the PoS system a validator may be slashed for any fault that it has done. An evidence of misbehaviour may be submitted by any account for a fault that occurred in epoch `n` anytime before the beginning of epoch `n + unbonding_length`.
+To disincentivize validators misbehavior in the PoS system a validator may be slashed for any fault that it has done. An evidence of misbehavior may be submitted by any account for a fault that occurred in epoch `n` anytime before the beginning of epoch `n + unbonding_length`.
 
 A valid evidence reduces the validator's total bonded token amount by the slash rate in and before the epoch in which the fault occurred. The validator's voting power must also be adjusted to the slashed total bonded token amount. Additionally, a slash is stored with the misbehaving validator's address and the relevant epoch in which the fault occurred. When an unbond is being withdrawn, we first look-up if any slash occurred within the range of epochs in which these were active and if so, reduce its token amount by the slash rate. Note that bonds and unbonds amounts are not slashed until their tokens are withdrawn.
 

packages/specs/pages/index.mdx

@@ -19,7 +19,7 @@ You can find an introduction to Namada from a product perspective [here](https:/
 
 ### What is Anoma?
 
-Anoma is an intent-centric, privacy-preserving architecture for decentralised counterparty discovery, solving, and settlement. You can find the Anoma specs [here](https://specs.anoma.net).
+Anoma is an intent-centric, privacy-preserving architecture for decentralized counterparty discovery, solving, and settlement. You can find the Anoma specs [here](https://specs.anoma.net).
 
 ### How does Namada relate to Anoma?
 
@@ -38,7 +38,7 @@ Users of Namada earn rewards, retain privacy of assets, and contribute to shared
 
 ### Layout of this specification
 
-These documents describe the behaviour of the Namada protocol. This description is organized into five sub-sections:
+These documents describe the behavior of the Namada protocol. This description is organized into five sub-sections:
 
 - [Base ledger](./base-ledger.mdx)
 - [Governance](./governance.mdx)