diff --git a/content/courses/connecting-to-offchain-data/oracles.md b/content/courses/connecting-to-offchain-data/oracles.md index fa638f4e2..0688f9603 100644 --- a/content/courses/connecting-to-offchain-data/oracles.md +++ b/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). diff --git a/content/courses/offline-transactions/durable-nonces.md b/content/courses/offline-transactions/durable-nonces.md index 4d166979e..a17a92b82 100644 --- a/content/courses/offline-transactions/durable-nonces.md +++ b/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. diff --git a/content/courses/program-optimization/program-architecture.md b/content/courses/program-optimization/program-architecture.md index 0af3b57a3..f18289284 100644 --- a/content/courses/program-optimization/program-architecture.md +++ b/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). 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. diff --git a/content/courses/state-compression/compressed-nfts.md b/content/courses/state-compression/compressed-nfts.md index 0e3372b81..461bec325 100644 --- a/content/courses/state-compression/compressed-nfts.md +++ b/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. diff --git a/content/courses/state-compression/generalized-state-compression.md b/content/courses/state-compression/generalized-state-compression.md index 00252dbf0..4333e308d 100644 --- a/content/courses/state-compression/generalized-state-compression.md +++ b/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. diff --git a/content/courses/token-extensions/group-member.md b/content/courses/token-extensions/group-member.md index 6953444d9..ca12d49d3 100644 --- a/content/courses/token-extensions/group-member.md +++ b/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 diff --git a/content/courses/token-extensions/token-extensions-metadata.md b/content/courses/token-extensions/token-extensions-metadata.md index 5dcc3a299..8baf0fa57 100644 --- a/content/courses/token-extensions/token-extensions-metadata.md +++ b/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. **`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); } } } diff --git a/content/courses/token-extensions/transfer-hook.md b/content/courses/token-extensions/transfer-hook.md index e389268ea..f27cead37 100644 --- a/content/courses/token-extensions/transfer-hook.md +++ b/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: diff --git a/content/guides/games/interact-with-tokens.md b/content/guides/games/interact-with-tokens.md index 4273f3cdc..9a08e5acd 100644 --- a/content/guides/games/interact-with-tokens.md +++ b/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 diff --git a/content/guides/getstarted/rust-to-solana.md b/content/guides/getstarted/rust-to-solana.md index 3d6995bf5..883f372c8 100644 --- a/content/guides/getstarted/rust-to-solana.md +++ b/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 ` 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 diff --git a/content/guides/javascript/compressed-nfts.md b/content/guides/javascript/compressed-nfts.md index 08e391ca3..18c5eb1de 100644 --- a/content/guides/javascript/compressed-nfts.md +++ b/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 diff --git a/content/guides/token-extensions/dynamic-meta-data-nft.md b/content/guides/token-extensions/dynamic-meta-data-nft.md index ad68dd621..279400ac2 100644 --- a/content/guides/token-extensions/dynamic-meta-data-nft.md +++ b/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 diff --git a/docs/advanced/actions.md b/docs/advanced/actions.md index 2a9d188bf..3aa38118d 100644 --- a/docs/advanced/actions.md +++ b/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 diff --git a/docs/advanced/state-compression.md b/docs/advanced/state-compression.md index a91eee2b8..99860da5e 100644 --- a/docs/advanced/state-compression.md +++ b/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". diff --git a/docs/clients/rust.md b/docs/clients/rust.md index 6f8d93d0e..767e5626c 100644 --- a/docs/clients/rust.md +++ b/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. diff --git a/docs/core/tokens.md b/docs/core/tokens.md index 36092eb10..32b147741 100644 --- a/docs/core/tokens.md +++ b/docs/core/tokens.md @@ -551,8 +551,8 @@ spl-token initialize-metadata ``` -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 diff --git a/docs/economics/staking/stake-programming.md b/docs/economics/staking/stake-programming.md index afac9e315..ed9852168 100644 --- a/docs/economics/staking/stake-programming.md +++ b/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. diff --git a/docs/terminology.md b/docs/terminology.md index 27c17ea1f..2ce27df49 100644 --- a/docs/terminology.md +++ b/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