Offchain and onchain are one word per Foundation style guide (#429)

content/courses/connecting-to-offchain-data/oracles.md

@@ -38,7 +38,7 @@ Oracles can provide just about any type of data onchain. Examples include:
 While the exact implementation may differ from blockchain to blockchain,
 generally Oracles work as follows:
 
-1. Data is sourced off-chain.
+1. Data is sourced offchain.
 2. That data is published onchain via a transaction, and stored in an account.
 3. Programs can read the data stored in the account and use that data in the
    program's logic.
@@ -82,7 +82,7 @@ On the other hand, you may be less willing to trust a centralized oracle
 providing price information for trading applications.
 
 You may end up creating many standalone oracles for your own applications simply
-as a way to get access to off-chain information that you need. However, those
+as a way to get access to offchain information that you need. However, those
 oracles are unlikely to be used by the broader community where decentralization
 is a core tenet. You should also be hesitant to use centralized, third-party
 oracles yourself.
@@ -138,7 +138,7 @@ verify each oracle’s software to allow participation in the network. If an
 oracle operator acts maliciously and attempts to change the operation of the
 approved code, a data quote verification will fail. This allows Switchboard
 oracles to operate beyond quantitative value reporting, such as functions --
-running off-chain custom and confidential computations.
+running offchain custom and confidential computations.
 
 ### Switchboard Oracles
 
@@ -158,7 +158,7 @@ understand how Switchboard works:
   Each data source should correspond to a job account. The job account is a
   collection of Switchboard tasks used to instruct the oracles on how to fetch
   and transform data. In other words, it stores the blueprints for how data is
-  fetched off-chain for a particular data source.
+  fetched offchain for a particular data source.
 - **Oracle** - A separate program that sits between the internet and the
   blockchain and facilitates the flow of information. An oracle reads a feed’s
   job definitions, calculates the result, and submits its response onchain.
@@ -235,7 +235,7 @@ data is published onchain:
 
 #### How to use Switchboard Oracles
 
-To use Switchboard oracles and incorporate off-chain data into a Solana program,
+To use Switchboard oracles and incorporate offchain data into a Solana program,
 you first have to find a feed that provides the data you need. Switchboard feeds
 are public and there are many
 [already available that you can choose from](https://app.switchboard.xyz/solana/devnet/explore).

content/courses/offline-transactions/durable-nonces.md

@@ -131,7 +131,7 @@ sign with your cold wallet.
 
 ### Using Durable nonces overcome the short lifespan of regular transactions
 
-Durable nonces are a way to sign transactions off-chain and keep them in storage
+Durable nonces are a way to sign transactions offchain and keep them in storage
 until they are ready to be submitted to the network. And this allows us to
 create durable transactions.
 

content/courses/program-optimization/program-architecture.md

@@ -78,7 +78,7 @@ You can read about it in
 [the Solana documentation](https://solana.com/docs/intro/rent).</Callout>
 
 Rent etymology aside, putting data on the blockchain can be expensive. It’s why
-NFT attributes and associated files, like the image, are stored off-chain. You
+NFT attributes and associated files, like the image, are stored offchain. You
 ultimately want to strike a balance that leaves your program highly functional
 without becoming so expensive that your users don’t want to pay to open the data
 account.

content/courses/state-compression/compressed-nfts.md

@@ -17,7 +17,7 @@ description:
   structure
 - The cNFT data hash can’t be used to infer the cNFT data, but it can be used to
   **verify** if the cNFT data you’re seeing is correct
-- Supporting RPC providers **index** cNFT data off-chain when the cNFT is minted
+- Supporting RPC providers **index** cNFT data offchain when the cNFT is minted
   so that you can use the **Read API** to access the data
 - The **Metaplex Bubblegum program** is an abstraction on top of the **State
   Compression** program that enables you to more simply create, mint, and manage
@@ -77,7 +77,7 @@ data exists in the ledger state and could theoretically be retrieved from the
 original transaction by replaying the entire chain state from origin. However,
 it’s much more straightforward (though still complicated) to have an **indexer**
 track and index this data as the transactions occur. This ensures there is an
-off-chain “cache” of the data that anyone can access and subsequently verify
+offchain “cache” of the data that anyone can access and subsequently verify
 against the onchain root hash.
 
 This process is _very complex_. We’ll cover some of the key concepts below but
@@ -608,7 +608,7 @@ console.log(JSON.stringify(result, null, 2));
 ```
 
 This will return a JSON object that is comprehensive of what a traditional NFT’s
-on- and off-chain metadata would look like combined. For example, you can find
+on- and offchain metadata would look like combined. For example, you can find
 the cNFT attributes at `content.metadata.attributes` or the image at
 `content.files.uri`.
 
@@ -833,9 +833,9 @@ Take some time to familiarize yourself with the starter code provided. Most
 important are the helper functions provided in `utils.ts` and the URIs provided
 in `uri.ts`.
 
-The `uri.ts` file provides 10k URIs that you can use for the off-chain portion
-of your NFT metadata. You can, of course, create your own metadata. But this
-lesson isn’t explicitly about preparing metadata so we’ve provided some for you.
+The `uri.ts` file provides 10k URIs that you can use for the offchain portion of
+your NFT metadata. You can, of course, create your own metadata. But this lesson
+isn’t explicitly about preparing metadata so we’ve provided some for you.
 
 The `utils.ts` file has a few helper functions to keep you from writing more
 unnecessary boilerplate than you need to. They are as follows:
@@ -1262,7 +1262,7 @@ surface that data when requested.
 
 If we add a call to this function at the end of `main` and re-run your script,
 the data we get back in the console is very comprehensive. It includes all of
-the data you’d expect in both the onchain and off-chain portion of a traditional
+the data you’d expect in both the onchain and offchain portion of a traditional
 NFT. You can find the cNFT’s attributes, files, ownership and creator
 information, and more.
 

content/courses/state-compression/generalized-state-compression.md

@@ -20,7 +20,7 @@ description:
 - Concurrent Merkle trees are a specialized version of Merkle trees that allow
   concurrent updates.
 - Because data in a state-compressed program is not stored onchain, you have to
-  user indexers to keep an off-chain cache of the data and then verify that data
+  user indexers to keep an offchain cache of the data and then verify that data
   against the onchain Merkle tree.
 
 ## Lesson
@@ -185,8 +185,8 @@ in the ledger state and could theoretically be retrieved from the original
 transaction by replaying the entire chain state from the beginning. However,
 it’s much more straightforward (though still complicated) to have
 an **indexer** track and index this data as the transactions occur. This ensures
-there is an off-chain “cache” of the data that anyone can access and
-subsequently verify against the onchain root hash.
+there is an offchain “cache” of the data that anyone can access and subsequently
+verify against the onchain root hash.
 
 This process is complex, but it will make sense after some practice.
 
@@ -239,9 +239,9 @@ arbitrary state compression. Instead, you have two primary options:
 
 1. Use an indexing provider that will build a custom indexing solution for your
    program that observes the events sent to the Noop program and stores the
-   relevant data off-chain.
+   relevant data offchain.
 2. Create your own pseudo-indexing solution that stores transaction data
-   off-chain.
+   offchain.
 
 For many dApps, option 2 makes plenty of sense. Larger-scale applications may
 need to rely on infrastructure providers to handle their indexing.

content/courses/token-extensions/group-member.md

@@ -537,7 +537,7 @@ const groupMetadata: LabNFTMetadata = {
   tokenUri: "",
 };
 
-// Upload off-chain metadata
+// Upload offchain metadata
 groupMetadata.tokenUri = await uploadOffChainMetadata(payer, groupMetadata);
 
 // Format group token metadata

content/courses/token-extensions/token-extensions-metadata.md

@@ -389,7 +389,7 @@ export function createUpdateAuthorityInstruction(
 The function `createEmitInstruction` "emits" or logs out token-metadata in the
 expected TokenMetadata state format. This is a required function for metadata
 programs that want to follow the TokenMetadata interface. The emit instruction
-allows indexers and other off-chain users to call to get metadata. This also
+allows indexers and other offchain users to call to get metadata. This also
 allows custom metadata programs to store
 [metadata in a different format while maintaining compatibility with the Interface standards](https://solana.com/developers/guides/token-extensions/metadata-pointer#metadata-interface-instructions).
 
@@ -643,10 +643,10 @@ at 100 KiB. </Callout>
 **`helpers.ts`** file provides us with a useful helper function
 `uploadOffChainMetadata`.
 
-`uploadOffChainMetadata` is a helper to store the off-chain metadata on Arweave
+`uploadOffChainMetadata` is a helper to store the offchain metadata on Arweave
 using Irys (formerly Bundlr). In this lab we will be more focused on the Token
 Extensions Program interaction, so this uploader function is provided. It is
-important to note that an NFT or any off-chain metadata can be stored anywhere
+important to note that an NFT or any offchain metadata can be stored anywhere
 with any storage provider like [NFT.storage](https://nft.storage/), Solana's
 native [ShadowDrive](https://www.shdwdrive.com/), or
 [Irys (formerly Bundlr)](https://irys.xyz/). At the end of the day, all you need
@@ -695,12 +695,12 @@ you are running into airdropping problems:
 - Copy the address and airdrop some devnet sol from
   [faucet.solana](https://faucet.solana.com/).
 
-### 1. Uploading the off-chain metadata
+### 1. Uploading the offchain metadata
 
 In this section we will decide on our NFT metadata and upload our files to
 NFT.Storage using the helper functions provided in the starting code.
 
-To upload our off-chain metadata, we need to first prepare an image that will
+To upload our offchain metadata, we need to first prepare an image that will
 represent our NFT. We've provided `cat.png`, but feel free to replace it with
 your own. Most image types are supported by most wallets. (Again devenet Irys
 allows up to 100KiB per file)
@@ -763,7 +763,7 @@ console.log("Token URI:", tokenUri);
 
 Now run `npm run start` in your terminal and test your code. You should see the
 URI logged once the uploading is done. If you visit the link you should see a
-JSON object that holds all of our off-chain metadata.
+JSON object that holds all of our offchain metadata.
 
 ### 2. Create NFT function
 
@@ -1081,14 +1081,14 @@ const onChainMetadata = await getTokenMetadata(connection, mint.publicKey);
 // Now we can see the metadata coming with the mint
 console.log("onchain metadata =====>", onChainMetadata);
 
-// And we can even get the off-chain json now
+// And we can even get the offchain json now
 if (onChainMetadata?.uri) {
   try {
     const response = await fetch(onChainMetadata.uri);
     const offChainMetadata = await response.json();
-    console.log("Mint off-chain metadata =====>", offChainMetadata);
+    console.log("Mint offchain metadata =====>", offChainMetadata);
   } catch (error) {
-    console.error("Error fetching or parsing off-chain metadata:", error);
+    console.error("Error fetching or parsing offchain metadata:", error);
   }
 }
 ```
@@ -1292,14 +1292,14 @@ export default async function createNFTWithEmbeddedMetadata(
   // Now we can see the metadata coming with the mint
   console.log("onchain metadata =====>", onChainMetadata);
 
-  // And we can even get the off-chain JSON now
+  // And we can even get the offchain JSON now
   if (onChainMetadata?.uri) {
     try {
       const response = await fetch(onChainMetadata.uri);
       const offChainMetadata = await response.json();
-      console.log("Mint off-chain metadata =====>", offChainMetadata);
+      console.log("Mint offchain metadata =====>", offChainMetadata);
     } catch (error) {
-      console.error("Error fetching or parsing off-chain metadata:", error);
+      console.error("Error fetching or parsing offchain metadata:", error);
     }
   }
 }

content/courses/token-extensions/transfer-hook.md

@@ -95,7 +95,7 @@ const [pda] = PublicKey.findProgramAddressSync(
 By storing the extra accounts required by the `Execute` instruction in the
 `extra_account_meta_list` PDA, these accounts can be automatically added to a
 token transfer instruction from the client. We'll see how to do that in the
-off-chain section.
+offchain section.
 
 #### 1. `initialize_extra_account_meta_list` instruction:
 

content/guides/games/interact-with-tokens.md

@@ -211,7 +211,7 @@ pub struct CreateMint<'info> {
 
 The `create_mint` instruction creates a new token mint, using a Program Derived
 Address (PDA) as both the address of the token mint and its mint authority. The
-instruction takes a URI (off-chain metadata), name, and symbol as parameters.
+instruction takes a URI (offchain metadata), name, and symbol as parameters.
 
 This instruction then creates a metadata account for the token mint through a
 [Cross-Program Invocation (CPI)](/docs/core/cpi.md) calling the

content/guides/getstarted/rust-to-solana.md

@@ -244,10 +244,10 @@ Alternatively,
 [install the Anchor CLI](https://www.anchor-lang.com/docs/installation) locally,
 and then use `anchor init <project-name>` to create a new Anchor project.
 
-## Creating Off-chain Programs
+## Creating offchain Programs
 
 So far, this guide has covered the key details of developing **onchain Solana
-programs** in Rust. However, it’s also possible to develop **off-chain Solana
+programs** in Rust. However, it’s also possible to develop **offchain Solana
 clients** in Rust. This can be done by using the
 [solana_sdk crate](https://docs.rs/solana-sdk/latest/solana_sdk/). This contains
 the [solana_client crate](https://docs.rs/solana-client/latest/solana_client/)
@@ -257,7 +257,7 @@ that allows Rust programs to interact with a Solana node via the
 Another option is to use the
 [anchor_client crate](https://docs.rs/anchor-client/latest/anchor_client/) which
 interacts with Solana programs written in Anchor via RPC. Alternatively,
-consider writing onchain programs in Rust, and off-chain
+consider writing onchain programs in Rust, and offchain
 [clients in JS/TS](https://solana.com/de/docs/clients/javascript-reference).
 
 ## Wrap Up

content/guides/javascript/compressed-nfts.md

@@ -364,7 +364,7 @@ changed (unless we want it to).
 
 > Learn more about how State Compression uses
 > [concurrent merkle trees](https://docs.solana.com/learn/state-compression#what-is-a-concurrent-merkle-tree)
-> to cryptographically secure off-chain data using the Solana ledger.
+> to cryptographically secure offchain data using the Solana ledger.
 
 ### Define our NFT's metadata
 

content/guides/token-extensions/dynamic-meta-data-nft.md

@@ -55,7 +55,7 @@ the JavaScript client. Each NFT will have some basic structure provided via the
 Token Metadata interface:
 
 - default on-chain fields - `name`, `symbol` and `uri`
-  - the `uri` is a link to an off-chain json file which contains the off chain
+  - the `uri` is a link to an offchain json file which contains the off chain
     metadata of the NFT
 - we will also have custom "additional fields" that we define
 

docs/advanced/actions.md

@@ -88,7 +88,7 @@ interface.
    an optional list of related actions.
 2. the [POST request](#post-request) returns a signable transaction or message
    that the client then prompts the user's wallet to sign and execute on the
-   blockchain or in another off-chain service.
+   blockchain or in another offchain service.
 
 ### Action Execution and Lifecycle
 

docs/advanced/state-compression.md

@@ -3,14 +3,14 @@ sidebarSortOrder: 4
 title: State Compression
 description:
   'State Compression is the method of cheaply and securely storing
-  "fingerprints" of off-chain data in the Solana leger, instead of expensive
+  "fingerprints" of offchain data in the Solana leger, instead of expensive
   accounts.'
 ---
 
 On Solana, [State Compression](/docs/advanced/state-compression.md) is the
-method of creating a "fingerprint" (or hash) of off-chain data and storing this
+method of creating a "fingerprint" (or hash) of offchain data and storing this
 fingerprint on-chain for secure verification. Effectively using the security of
-the Solana ledger to securely validate off-chain data, verifying it has not been
+the Solana ledger to securely validate offchain data, verifying it has not been
 tampered with.
 
 This method of "compression" allows Solana programs and dApps to use cheap
@@ -25,7 +25,7 @@ this final hash on-chain.
 ## What is State Compression?
 
 In simple terms, state compression uses "**_tree_**" structures to
-cryptographically hash off-chain data together, in a deterministic way, to
+cryptographically hash offchain data together, in a deterministic way, to
 compute a single final hash that gets stored on-chain.
 
 These _trees_ are created in this "_deterministic_" process by:
@@ -40,7 +40,7 @@ These _trees_ are created in this "_deterministic_" process by:
 
 This `root hash` is then stored onchain, as a verifiable **_proof_** of all of
 the data within every leaf. Allowing anyone to cryptographically verify all the
-off-chain data within the tree, while only actually storing a **minimal** amount
+offchain data within the tree, while only actually storing a **minimal** amount
 of data on-chain. Therefore, significantly reducing the cost to store/prove
 large amounts of data due to this "state compression".
 

docs/clients/rust.md

@@ -30,7 +30,7 @@ development:
   SBF. This crate contains many fundamental data types and is re-exported from
   [`solana-sdk`], which cannot be imported from a Solana program.
 
-- [`solana-sdk`] — The basic off-chain SDK, it re-exports
+- [`solana-sdk`] — The basic offchain SDK, it re-exports
   [`solana-program`] and adds more APIs on top of that. Most Solana programs
   that do not run on-chain will import this.
 

docs/core/tokens.md

@@ -551,8 +551,8 @@ spl-token initialize-metadata <TOKEN_MINT_ADDRESS> <YOUR_TOKEN_NAME>
 <YOUR_TOKEN_SYMBOL> <YOUR_TOKEN_URI>
 ```
 
-The token URI is normally a link to off-chain metadata you want to associate
-with the token. You can find an example of the JSON format
+The token URI is normally a link to offchain metadata you want to associate with
+the token. You can find an example of the JSON format
 [here](https://raw.githubusercontent.com/solana-developers/opos-asset/main/assets/DeveloperPortal/metadata.json).
 
 For example, running the following command will store the additional metadata

docs/economics/staking/stake-programming.md

@@ -4,12 +4,12 @@ title: Stake Programming
 
 To maximize stake distribution, decentralization, and censorship resistance on
 the Solana network, staking can be performed programmatically. The team and
-community have developed several on-chain and off-chain programs to make stakes
+community have developed several on-chain and offchain programs to make stakes
 easier to manage.
 
 #### Stake-o-matic aka Auto-delegation Bots
 
-This off-chain program manages a large population of validators staked by a
+This offchain program manages a large population of validators staked by a
 central authority. The Solana Foundation uses an auto-delegation bot to
 regularly delegate its stake to "non-delinquent" validators that meet specified
 performance requirements.

docs/terminology.md

@@ -144,7 +144,7 @@ consensus.
 
 ## drone
 
-An off-chain service that acts as a custodian for a user's private key. It
+An offchain service that acts as a custodian for a user's private key. It
 typically serves to validate and sign transactions.
 
 ## entry