Capitalization (#156)

* Capitalize "Mainnet"

* Capitalize Ghostnet

* Capitalize Smart Rollups

* Capitalize Dailynet

docs/architecture/governance.md

@@ -33,13 +33,13 @@ The voting participation target tries to match the exponential moving average of
 
 Previously, during the voting process, a test chain would be spun up during the “testing period” which took place between the exploration and promotion voting periods. The intent was that this test chain be used to verify that the new proposal worked correctly, but in practice, the test chain has never been used in this manner and has caused significant operational problems to node operators.
 
-The Florence upgrade eliminates the test chain activation, the testing period has been retained but is now named the “cooldown period”. Instead, testing the protocol continues by using test chains that operate outside of the mainnet voting process.
+The Florence upgrade eliminates the test chain activation, the testing period has been retained but is now named the “cooldown period”. Instead, testing the protocol continues by using test chains that operate outside of the Mainnet voting process.
 
 #### 4. Promotion Vote Period
 
 At the end of the Testing Period, the Promotion Vote Period begins. In this period, the network decides whether to adopt the amendment based on off-chain discussions and its behavior during the Testing Period. As in the Exploration Vote Period, bakers submit their votes using the ballot operation, with their votes weighted proportionally to the number of rolls in their staking balance.
 
-At the end of the Promotion Vote Period, the network counts the number of votes. If the participation rate reaches the minimum quorum and an 80% supermajority of non-abstaining bakers votes “Yea,” then the proposal is activated as the new mainnet. Otherwise, the process once more reverts to the Proposal Period. The minimum vote participation rate is set based on past participation rates.
+At the end of the Promotion Vote Period, the network counts the number of votes. If the participation rate reaches the minimum quorum and an 80% supermajority of non-abstaining bakers votes “Yea,” then the proposal is activated as the new Mainnet. Otherwise, the process once more reverts to the Proposal Period. The minimum vote participation rate is set based on past participation rates.
 
 See [the full details of the governance process](https://medium.com/tezos/amending-tezos-b77949d97e1e).
 

docs/architecture/governance/amendment-history.md

@@ -189,7 +189,7 @@ For more information, see the blog post from [Nomadic Labs](https://research-dev
 
 Mumbai's main changes are:
 
-* Smart rollups: Tezos enshrined rollups are enabled and provide a powerful scaling solution allowing anyone to deploy decentralized WebAssembly applications with dedicated computational and networking resources.
+* Smart Rollups: Tezos enshrined rollups are enabled and provide a powerful scaling solution allowing anyone to deploy decentralized WebAssembly applications with dedicated computational and networking resources.
 * Minimal block time reduction from 30s to 15s.
 * Ticket transfers between user accounts.
 

docs/architecture/smart-rollups.md

@@ -4,15 +4,15 @@ authors: 'Nomadic Labs, TriliTech'
 lastUpdated: 30th June 2023
 ---
 
-Rollups play a crucial part in providing next-generation scaling on Tezos. This page gives a technical introduction to smart rollups, their optimistic nature, and an intro to developing your own WASM kernel.
+Rollups play a crucial part in providing next-generation scaling on Tezos. This page gives a technical introduction to Smart Rollups, their optimistic nature, and an intro to developing your own WASM kernel.
 
 ## Prerequisites
 
 This page covers an advanced topic at the bleeding edge of Tezos core development. If you are interested in more fundamental reading, a great place to start is [Tezos Protocol and Shell](./protocol) and [Smart Contracts](../smart-contracts/languages).
 
 ## Examples
 
-For examples of smart rollups, see this repository: https://gitlab.com/tezos/kernel-gallery.
+For examples of Smart Rollups, see this repository: https://gitlab.com/tezos/kernel-gallery.
 
 ## What is a rollup?
 
@@ -35,7 +35,7 @@ published an invalid claim. Therefore, thanks to the refutation
 mechanism, a single honest participant is enough to guarantee that the
 input messages are correctly interpreted.
 
-In the Tezos protocol, the subsystem of smart rollups is generic with
+In the Tezos protocol, the subsystem of Smart Rollups is generic with
 respect to the syntax and the semantics of the input messages. More
 precisely, the originator of a smart rollup provides a program (in one
 of the languages supported by Tezos) responsible for interpreting input
@@ -60,13 +60,13 @@ terms of expressiveness.
 
 The purpose of this documentation is to give:
 
-- an overview of the terminology and basic principles of smart rollups
-- a complete tour of smart rollups related workflows
+- an overview of the terminology and basic principles of Smart Rollups
+- a complete tour of Smart Rollups related workflows
 - a reference documentation for the development of a WASM kernel.
 
 # Overview
 
-Just like smart contracts, smart rollups are decentralized software
+Just like smart contracts, Smart Rollups are decentralized software
 components. However, contrary to smart contracts that are processed by
 the network validators automatically, a smart rollup requires a
 dedicated *rollup node* to function.
@@ -86,7 +86,7 @@ the prefix `sr1`.
 
 ## Inputs
 
-There are two channels of communication to interact with smart rollups:
+There are two channels of communication to interact with Smart Rollups:
 
 1.  a global **rollups inbox** allows layer 1 to transmit
     information to all the rollups. This unique inbox contains two kinds
@@ -186,7 +186,7 @@ A **commitment** claims that the interpretation of all inbox messages
 published during a given commitment period and applied on the state of a
 parent commitment leads to a given new state by performing a given number
 of execution steps of the PVM. Execution steps are called **ticks** in
-the smart rollups terminology. A commitment must be published on the
+the Smart Rollups terminology. A commitment must be published on the
 layer 1 after each commitment period to have the rollup progress. A
 commitment is always based on a parent commitment (except for the
 genesis commitment that is automatically published at origination time).
@@ -269,7 +269,7 @@ all concurrent stakers to avoid the rollup being stuck.
 
 ## Tools
 
-Smart rollups come with two new executable programs: the Octez rollup
+Smart Rollups come with two new executable programs: the Octez rollup
 node and the Octez rollup client.
 
 The Octez rollup node is used by a rollup operator to deploy a rollup.
@@ -528,7 +528,7 @@ EMESSAGE=$(octez-smart-rollup-client-Pt${CURRENT_PROTOCOL} encode outbox message
 ## Triggering Execution of an Outbox Message
 
 Once an outbox message has been pushed to the outbox by the kernel at
-some level `${L}`, the user needs to wait for the commitment that includes this level to be cemented. On dailynet, the cementation process
+some level `${L}`, the user needs to wait for the commitment that includes this level to be cemented. On Dailynet, the cementation process
 of a non-disputed commitment is 40 blocks long while on Mainnet, it is 2
 weeks long.
 
@@ -701,9 +701,9 @@ general-purpose tool like [WABT](https://github.com/WebAssembly/wabt).
 wat2wasm hello.wat -o hello.wasm
 ```
 
-The contents of the resulting `hello.wasm` file is a valid WASM kernel. One of the benefits of choosing WASM as the programming language for smart rollups is that WASM has gradually become a ubiquitous compilation target over the years. Its popularity has grown to the point where mainstream, industrial languages like Go or Rust now natively compile to WASM. For example, `cargo`, the official Rust package manager, provides an official target to compile Rust to `.wasm` binary files, which are valid WASM kernels. This means that, for this particular example, one can build a WASM kernel while enjoying the strengths and convenience of the Rust language and the Rust ecosystem.
+The contents of the resulting `hello.wasm` file is a valid WASM kernel. One of the benefits of choosing WASM as the programming language for Smart Rollups is that WASM has gradually become a ubiquitous compilation target over the years. Its popularity has grown to the point where mainstream, industrial languages like Go or Rust now natively compile to WASM. For example, `cargo`, the official Rust package manager, provides an official target to compile Rust to `.wasm` binary files, which are valid WASM kernels. This means that, for this particular example, one can build a WASM kernel while enjoying the strengths and convenience of the Rust language and the Rust ecosystem.
 
-In the context of smart rollups, Rust has become the primary language where the WASM backend has been tested extensively. However, the WASM VM has not been modified in any way to favor this language. We fully expect that other mainstream languages, such as Go, are also great candidates for implementing WASM kernels.
+In the context of Smart Rollups, Rust has become the primary language where the WASM backend has been tested extensively. However, the WASM VM has not been modified in any way to favor this language. We fully expect that other mainstream languages, such as Go, are also great candidates for implementing WASM kernels.
 
 Let's move on and continue by:
 
@@ -747,7 +747,7 @@ kernel, but can be used by the PVM to give information to the kernel.
 
 When a new block is published on Tezos, the inbox exposed to the smart
 rollup is populated with all the inputs published on Tezos in this
-block. Keep in mind that all smart rollups which are originated on Tezos share the same inbox. As a consequence, a WASM kernel has to filter the inputs that are relevant for its purpose from the ones it does not need to process.
+block. Keep in mind that all Smart Rollups which are originated on Tezos share the same inbox. As a consequence, a WASM kernel has to filter the inputs that are relevant for its purpose from the ones it does not need to process.
 
 Once the inbox has been populated with the inputs of the Tezos block,
 the `kernel_run` function is called, from a clean `transient` state.
@@ -785,7 +785,7 @@ evolved arithmetic machine. It needs to be enriched with so-called
 "host" functions to be used for greater purposes. The host
 functions provide an API to the WASM program to interact externally.
 
-For smart rollups, the host functions exposed to a WASM kernel allow
+For Smart Rollups, the host functions exposed to a WASM kernel allow
 it to interact with the components of persistent state:
 
  - `read_input` - loads the oldest input still present in the inbox of the smart rollup in the transient memory of the WASM kernel. This means that the input is lost at the next invocation of `kernel_run` if it is not written in the durable storage
@@ -860,7 +860,7 @@ simple as running the following command.
 rustup target add wasm32-unknown-unknown
 ```
 
-Rust also proposes the `wasm64-unknown-unknown` compilation target. This target is **not** compatible with Tezos smart rollups, which only
+Rust also proposes the `wasm64-unknown-unknown` compilation target. This target is **not** compatible with Tezos Smart Rollups, which only
 provides a 32bit address space.
 
 The simplest kernel one can implement in Rust (the one that returns directly after being called, without specification) is the following Rust file (by convention named `lib.rs` in Rust).
@@ -1288,7 +1288,7 @@ solutions:
     protocol and is the unique source of truth regarding the semantics
     of rollups. The PVM is able to produce proofs enforcing this truth.
     This ability is used during the final step of refutation games.
--  **Inbox**: A sequence of messages from layer 1 to smart rollups.
+-  **Inbox**: A sequence of messages from layer 1 to Smart Rollups.
     The contents of the inbox is determined by the consensus of the
     Tezos protocol.
 -  **Outbox**: A sequence of messages from a smart rollup to

docs/dApps/best-practices.md

@@ -24,7 +24,7 @@ Connecting and interacting with a wallet is an experience specific to web3 apps
 
 1. **Do not force wallet connection**: the request to connect a user's wallet must come from the user interacting with your dapp, not appear out of nowhere, for example, when the dapp loads. Let the user get some details about your dapp before they decide to connect their wallet.
 2. **Choose the right position for the wallet button**: the users visiting your dapp will expect to find the button to connect or interact with their wallet in the upper part of the interface, on the left or right side. The button must be clearly visible and discoverable in one second.
-3. **Display wallet information**: the minimal information to display is the address of the connected account to let the users know which account they are using. A lot of dapps on Tezos also display the XTZ balance, as well as the network the dapp is connected to (mainnet/testnet) or the wallet used for the connection.
+3. **Display wallet information**: the minimal information to display is the address of the connected account to let the users know which account they are using. A lot of dapps on Tezos also display the XTZ balance, as well as the network the dapp is connected to (Mainnet/testnet) or the wallet used for the connection.
 4. **Offer the option to select the RPC node**: network traffic can get busy on Tezos, but you can provide a better UX by adding a switch for a different Tezos node if the one selected by default becomes too slow. Some power users may also like having the choice to enter the address of their favourite node!
 5. **Add an option to disconnect the wallet**: some users want to switch wallets while using your dapp, so there must be a way to disconnect their wallet and connect a new one effortlessly.
 

docs/dApps/unity.md

@@ -20,10 +20,10 @@ This Getting Started guide covers the following five steps essential for using t
 1. Installation of the Unity Editor (if not already installed)
 2. Installation of the Tezos Integration SDK in the Unity Editor within a new project
 3. Obtaining a Tezos-compatible wallet as an app or browser plugin (we'll use the **Temple** wallet for our [Inventory Sample Game](https://opentezos.com/gaming/unity-sdk/inventory-sample-game))
-4. Creating a wallet account for a test network (`ghostnet`) and acquiring test currency from an appropriate faucet
+4. Creating a wallet account for the Ghostnet test network and acquiring test currency from an appropriate faucet
 5. Linking this wallet account with the new Unity project
 
-By following these steps, your Unity app will be connected to the Tezos GhostNet test network via your specific wallet address. This allows you to invoke specific functionality on smart contracts you've created and deployed to GhostNet, as demonstrated in our [Inventory Sample Game](https://opentezos.com/gaming/unity-sdk/inventory-sample-game).
+By following these steps, your Unity app will be connected to the Tezos Ghostnet test network via your specific wallet address. This allows you to invoke specific functionality on smart contracts you've created and deployed to GhostNet, as demonstrated in our [Inventory Sample Game](https://opentezos.com/gaming/unity-sdk/inventory-sample-game).
 
 Explore the [Inventory Sample Game](https://opentezos.com/gaming/unity-sdk/inventory-sample-game) project and consult our [API Documentation](https://opentezos.com/gaming/unity-sdk/api-documentation/) to learn more about the exposed methods of our SDK, both for establishing wallet connections and for calling specific smart-contract entrypoints and Tezos data-view functions.
 

docs/developing/dev-environments.md

@@ -44,7 +44,7 @@ See https://taqueria.io/.
 
 To test smart contracts and dApps, you can use these test environments:
 
-- Test networks behave like Tezos mainnet but have differences that make it easier to test on them, such as faucets that provide free tokens and reduced block times for faster testing.
+- Test networks behave like Tezos Mainnet but have differences that make it easier to test on them, such as faucets that provide free tokens and reduced block times for faster testing.
 - Sandbox environments like [Flextesa](https://tezos.gitlab.io/flextesa/) run Tezos nodes locally on your computer in a sandbox mode.
 
 For more information about test environments, see [Using sandboxes and testnets](./testnets).

docs/developing/information/block-explorers.md

@@ -27,7 +27,7 @@ Block explorers are not only made for casual users to check if their coins are s
 Block explorers are also used by:
 
 * blockchain engineers who develop and debug new features in sandboxes (e.g. new blockchain consensus).
-* app developers who need debugging tools and more visibility into the current and past state of their contracts running on internal testnets and the mainnet.
+* app developers who need debugging tools and more visibility into the current and past state of their contracts running on internal testnets and Mainnet.
 
 * bakers and staking services who need reliable data about delegation and earnings history to calculate correct payouts, plan their bond pools and execute operations.
 * less technical user groups like auditors and regulators with strict requirements for data quality, as they need to access a trusted copy of the full on-chain history in a format that's easy to digest for their spreadsheets and compliance tools.

docs/developing/information/block-explorers/inspect-contract-tzstats.md

@@ -236,7 +236,7 @@ All these API calls can of course be made from any libraries and thus can be aut
 
 # Conclusion
 
-tzstats.com is extremely useful to monitor what is happening on the mainnet and public testnets.
+tzstats.com is extremely useful to monitor what is happening on Mainnet and public testnets.
 All the pieces of information regarding the cycles, the blocks, the transactions, the smart contracts, etc... can quickly be found, thanks to a user-friendly interface.
 
 In addition, _TzStats_ provides a complete and free REST API (for non-commercial use), without any authentication or enforcement of rate limits (as long as it remains reasonable). See the introduction of the [Tzstats API](https://tzstats.com/docs/api#tezos-api).

docs/developing/octez-client.md

@@ -9,7 +9,7 @@ Developers use the Octez client for many tasks, including:
 
 - Working with accounts
 - Sending transactions and interacting with contracts
-- Originating smart contracts and smart rollups
+- Originating smart contracts and Smart Rollups
 
 Other parts of Octez allow you to host, manage, and monitor nodes, bake blocks, and host RPC nodes.
 

docs/developing/octez-client/accounts.md

@@ -4,7 +4,7 @@ title: Creating accounts
 
 You can create or import accounts into the Octez client just like you do so in wallet applications.
 
-Octez keeps a local list of aliases for addresses, including user accounts, smart contracts, and smart rollups.
+Octez keeps a local list of aliases for addresses, including user accounts, smart contracts, and Smart Rollups.
 You can list the aliases that the Octez client is aware of by running the command `octez-client list known addresses`.
 When you run transactions with Octez, you can use the alias in place of the account address.
 

docs/developing/sandbox.md

@@ -4,7 +4,7 @@ authors: 'Mathias Hiron, Nomadic Labs, Tim McMackin, TriliTech'
 lastUpdated: 18th October 2023
 ---
 
-Local sandboxes allow you to test your work without sending any transactions to Tezos mainnet or testnets.
+Local sandboxes allow you to test your work without sending any transactions to Tezos Mainnet or testnets.
 
 The **sandboxed mode** of `octez-client` makes it possible to test your contracts or other projects while interacting with actual nodes, but without using a public test network or creating your own private network. In sandboxed mode, `octez-client` can create one or more local nodes for this.