guides spring cleaning

src/pages/guides/general/create-deterministic-metadata-with-turbo.md

@@ -11,7 +11,7 @@ To utilize the metadata randomization feature in the MPL-Hybrid program, the off
 
 {% callout title="What is Turbo" %}
 
-Turbo is a ultrahigh-throughput Permaweb service that streamlines the funding, indexing, and transmission of data to and from Arweave. It provides graphical and programmatic interfaces for payment options in fiat currency with credit or debit cards as well as cryptocurrencies such as ETH, SOL, and AR.
+Turbo is an ultrahigh-throughput Permaweb service that streamlines the funding, indexing, and transmission of data to and from Arweave. It provides graphical and programmatic interfaces for payment options in fiat currency with credit or debit cards as well as cryptocurrencies such as ETH, SOL, and AR.
 
 {% /callout %}
 
@@ -31,7 +31,7 @@ npm i @ardrive/turbo-sdk
 
 In this example, we will show you how to upload metadata in a deterministic way. To do so, you'll need to prepare all the assets before starting. 
 
-To generate the metadata, you can use [one of these methods](/candy-machine/guides/create-an-nft-collection-on-solana-with-candy-machine#image-and-metadata-generators) and save the metadata follow an incremental naming convention starting from 0 like this:
+To generate the metadata, you can use [one of these methods](/candy-machine/guides/create-an-nft-collection-on-solana-with-candy-machine#image-and-metadata-generators) and save the metadata following an incremental naming convention starting from 0 like this:
 
 ```
 metadata/
@@ -52,7 +52,7 @@ import { TurboFactory } from '@ardrive/turbo-sdk';
 
 // Import here the keypair.json file that you're going
 // to use to pay for the upload
-import secretKey from "/path/to/your/kepypair.json";
+import secretKey from "/path/to/your/keypair.json";
 
 const turbo = TurboFactory.authenticated({
   privateKey: bs58.encode(Uint8Array.from(secretKey)),
@@ -68,15 +68,15 @@ To gain access to the Metaplex Aura network on the Solana and Eclipse blockchain
 
 ## Upload the Metadata
 
-Turbo simplifies the process of uploading entire folders of metadata using the `TurboAuthenticatedClient.uploadFolder()` function. This function supports Manifests by default, returning a Manifest ID via `result.manifestResponse?.id`, which can be used for metadata creation and escrow setup.
+Turbo simplifies the process of uploading entire folders of metadata using the `TurboAuthenticatedClient.uploadFolder()` function. This function supports Manifests by default, returning a Manifest ID via `metadataUploadResponse.manifestResponse?.id`, which can be used for metadata creation and escrow setup.
 
-To simplify the process, this guide provides helper function called `uploadAssetsAndMetadata()` that handles the entire workflow.
+To simplify the process, this guide provides a helper function called `uploadMetadata()` that handles the entire workflow.
 
 ```javascript
 const metadataUploadResponse = await uploadMetadata(turbo);
 ```
 
-**Steps of the `uploadAssetsAndMetadata()` helper**
+**Steps of the `uploadMetadata()` helper**
 
 1. Determines how many lamports are needed for the upload by calling `calculateRequiredLamportsForUpload()`, which calculates the upload cost in Winc (Turbo’s token) and converts it to lamports using `TurboAuthenticatedClient.getWincForToken()`.
 
@@ -186,7 +186,7 @@ import path from 'path';
 import fs from 'fs';
 import BigNumber from 'bignumber.js';
 
-import secretKey from "/path/to/your/kepypair.json";
+import secretKey from "/path/to/your/keypair.json";
 
 const imageFolderPath = path.join(__dirname, './assets');
 const metadataFolderPath = path.join(__dirname, './metadata');
@@ -197,7 +197,7 @@ const metadataFolderPath = path.join(__dirname, './metadata');
         const turbo = TurboFactory.authenticated({
             privateKey: bs58.encode(Uint8Array.from(secretKey)),
             token: 'solana',
-            gatewayUrl: `https://api.devnet.solana.com`,
+            gatewayUrl: `https://devnet-aura.metaplex.com/<YOUR_API_KEY>`,
             paymentServiceConfig: { url: "https://payment.ardrive.dev" },
             uploadServiceConfig: { url: "https://upload.ardrive.dev" },
         });
@@ -213,7 +213,7 @@ async function uploadMetadata(turbo: TurboAuthenticatedClient): Promise<TurboUpl
     // Calculate and upload metadata folder
     const requiredLamportsForMetadata = await calculateRequiredLamportsForUpload(
         turbo,
-        await calculateFolderSize(metadataFolderPath)
+        calculateFolderSize(metadataFolderPath)
     );
 
     // Top up wallet if required

src/pages/guides/general/how-to-diagnose-solana-transaction-errors.md

@@ -1,7 +1,7 @@
 ---
 title: How to Diagnose Transaction Errors on Solana
 metaTitle: How to Diagnose Transaction Errors on Solana
-description: Learn how to diagnose transaction errors on Solana and find logical solutions these errors.
+description: Learn how to diagnose transaction errors on Solana and find logical solutions for these errors.
 # remember to update dates also in /components/guides/index.js
 created: '06-16-2024'
 updated: '06-21-2024'
@@ -9,7 +9,7 @@ updated: '06-21-2024'
 
 ## Sharing Errors to a Support Network
 
-If you are receiving errors that you do not understand and wish to show to someone else it can sometimes be difficult to describe the situation. This often happens when using a form of SDK to send transactions such as Metaplex Umi, Solana SDK, Solana Web3js. These clients will often send whats called a **pre-flight transaction** or simulation to an RPC to check if the transaction is going to succeed or not. If a transaction is deemed to fail then a transaction is not sent to the chain and will just throw an error message instead. While this is good behavior on behalf of the network, it doesn't give us anything we can logically get help with. This is where skipping simulation/pre-flight comes into play and forcing the failing transaction to be registered by the chain which becomes sharable to other people. 
+If you are receiving errors that you do not understand and wish to show to someone else it can sometimes be difficult to describe the situation. This often happens when using a form of SDK to send transactions such as Metaplex Umi, Solana SDK, Solana Web3js. These clients will often send what's called a **pre-flight transaction** or simulation to an RPC to check if the transaction is going to succeed or not. If a transaction is deemed to fail then a transaction is not sent to the chain and will just throw an error message instead. While this is good behavior on behalf of the network, it doesn't give us anything we can logically get help with. This is where skipping simulation/pre-flight comes into play and forcing the failing transaction to be registered by the chain which becomes sharable to other people. 
 
 
 ## Skipping Preflight
@@ -101,16 +101,15 @@ By logging out the transaction ID you can visit a Solana blockchain explorer and
 - Solscan
 - Solana Explorer
 
-This transaction ID or explorer link can the be shared with someone who may be able to assist you.
+This transaction ID or explorer link can then be shared with someone who may be able to assist you.
 
 ## Common Types of Errors
 
-There are some common errors that normally occur 
-
+There are some common errors that normally occur.
 
 ### Error Codes xx (23)
 
-While normally complimented with some additional text to describe the error codes these codes can sometimes appear on their own in a non descriptive manner. If this happens and you know the program that threw the error you can sometimes find the program in Github and it will have an errors.rs page that lists out all the possible errors of the program.
+While normally complemented with some additional text to describe the error codes these codes can sometimes appear on their own in a non descriptive manner. If this happens and you know the program that threw the error you can sometimes find the program in Github and it will have an errors.rs page that lists out all the possible errors of the program.
 
 Starting at an index of 0 you can count down/work out the position of the error in the list.
 
@@ -135,7 +134,7 @@ If we take the Mpl Core Candy Machine program as an example, this is an Anchor p
 
 [https://github.com/metaplex-foundation/mpl-core-candy-machine/blob/main/programs/candy-machine-core/program/src/errors.rs](https://github.com/metaplex-foundation/mpl-core-candy-machine/blob/main/programs/candy-machine-core/program/src/errors.rs)
 
-If your transaction is returning an error of `6006` will can take the end of the number, in this case `6` and work our way down the error.rs list starting from an index of 0. 
+If your transaction is returning an error of `6006` we can take the end of the number, in this case `6` and work our way down the error.rs list starting from an index of 0. 
 
 ```rust
 #[msg("Candy machine is empty")]

src/pages/guides/general/payer-authority-pattern.md

@@ -39,7 +39,7 @@ but have your program or a PDA serve as the authority for subsequent actions.
    Program Derived Addresses (PDAs) do not possess private keys that allow them
    to sign transactions in the same way as regular keypairs, so all of their
    interactions must be managed by calling a program. While a PDA can be the
-   authority of an account, It cannot directly be used to pay rent or fees
+   authority of an account, it cannot directly be used to pay rent or fees
    without involving complicated fund movements. Having a separate payer account
    to cover rent or small storage adjustments on behalf of the PDA avoids the
    complexity of funneling funds into the PDA just to pay for minor changes.
@@ -74,7 +74,7 @@ a client that works with this pattern.
     #[derive(Accounts)]
     pub struct CreateAccount<'info> {
         /// The address of the new account
-        #[account(init, payer = player_one, space = 8 + NewAccount::MAXIMUM_SIZE)]
+        #[account(init, payer = payer, space = 8 + NewAccount::MAXIMUM_SIZE)]
         pub account: Account<'info, NewAccount>,
         
         /// The account paying for the storage fees

src/pages/guides/general/spl-token-claim-airdrop-using-gumdrop.md

@@ -53,14 +53,14 @@ Ensure you mint enough tokens to cover your entire distribution list plus some b
 
 ## Distribution Methods
 
-To distribute the proofs to the users, gumdrop supports multiple distribution methods. Wallet-based distribution is recommended for:
+To distribute the proofs to the users, Gumdrop supports multiple distribution methods. Wallet-based distribution is recommended for:
 - Better reliability
 - Simpler implementation
 - No dependency on external services
 - Direct wallet verification
 
 For wallet distribution, you'll need to either
-- Send your users a claim URL containing the required proof data, using one of the already available Discord Bots 
+- Send your users a claim URL containing the required proof data, using one of the already available Discord Bots. 
 or:
 1. Store the claim data in your database indexed by wallet address
 2. Create a frontend that fetches claim data when users connect their wallet
@@ -126,7 +126,7 @@ Users need a frontend interface to claim their tokens. You can either:
 
 1. Use the hosted version at `https://gumdrop.metaplex.com`
 
-2. Host your own interface **recommended**. You might want to use the Gumdrop frontend as a starting point and customize it to your needs. For example it can massively increase the user experience by automatically filling in the claim data for the user based on the wallet they are connected with.
+2. Host your own interface **recommended**. You might want to use the Gumdrop frontend as a starting point and customize it to your needs. For example, it can massively increase the user experience by automatically filling in the claim data for the user based on the wallet they are connected with.
 
 Before launching:
 

src/pages/guides/index.md

@@ -8,6 +8,6 @@ description: Guides by Metaplex about the Solana blockchain.
 
 The guides in this section are **designed to help new Solana developers start their journey** by providing step-by-step instructions and practical examples they can execute. These guides focus on teaching key concepts with a structured learning path that gradually introduces developers to the Solana ecosystem. They cover everything from the basics of blockchain and Solana's unique features to advanced topics such as program development and optimization techniques.
 
-By incorporating a variety of learning resources, including tutorials and code samples, **the guides are designed to be accessibly to be new and experienced developers in the space**. The guides are regularly updated to reflect the latest developments in the Solana ecosystem.
+By incorporating a variety of learning resources, including tutorials and code samples, **the guides are designed to be accessible to new and experienced developers in the space**. The guides are regularly updated to reflect the latest developments in the Solana ecosystem.
 
 The guides are shared for educational and informational purposes only and are not to be relied upon as professional advice. All content included in these learning resources are not guaranteed to be current or error-free.

src/pages/guides/javascript/how-to-add-metadata-to-spl-tokens.md

@@ -20,7 +20,7 @@ It is recommended to use the available [create helper](https://developers.metapl
 
 ## Initial Setup
 
-This guide assumes that you already have an SPL token initialized for which you'd like to add metadata to. You might need to modify and move functions around to suite your needs. 
+This guide assumes that you already have an SPL token initialized for which you'd like to add metadata to. You might need to modify and move functions around to suit your needs.
 
 ## Initializing
 
@@ -91,7 +91,7 @@ You can place the Umi instantiation code inside or outside the code blocks, but
 ### Generating a New Wallet
 
 ```ts
-const umi = createUmi("https://devnet-aura.metaplex.com/<YOUR_API_KEY>")
+const umi = createUmi("https://api.devnet.solana.com")
 	.use(mplTokenMetadata())
 	.use(mplToolbox());
 
@@ -103,7 +103,7 @@ umi.use(signerIdentity(signer));
 
 // Airdrop 2 SOL to the identity
 // if you end up with a 429 too many requests error, you may have to use
-// the a different rpc other than the free default one supplied.
+// a different rpc other than the free default one supplied.
 await umi.rpc.airdrop(umi.identity.publicKey, sol(2));
 ```
 
@@ -114,9 +114,9 @@ const umi = createUmi("https://api.devnet.solana.com")
 	.use(mplTokenMetadata())
 	.use(mplToolbox());
 
-// You will need to us fs and navigate the filesystem to
+// You will need to use fs and navigate the filesystem to
 // load the wallet you wish to use via relative pathing.
-const walletFile = const imageFile = fs.readFileSync('./keypair.json')
+const walletFile = fs.readFileSync('./keypair.json')
 
 // Convert your walletFile onto a keypair.
 let keypair = umi.eddsa.createKeypairFromSecretKey(new Uint8Array(walletFile));
@@ -221,7 +221,7 @@ const tokenMetadata = {
 async function addMetadata() {
 	// Airdrop 2 SOL to the identity
     // if you end up with a 429 too many requests error, you may have to use
-    // the a different rpc other than the free default one supplied.
+    // a different rpc other than the free default one supplied.
     await umi.rpc.airdrop(umi.identity.publicKey, sol(2));
 
     // derive the metadata account that will store our metadata data onchain

src/pages/guides/javascript/how-to-create-a-solana-token.md

@@ -3,8 +3,8 @@ title: How to Create a Solana Token
 metaTitle: How to Create a Solana Token | Guides
 description: Learn how to create an SPL Token/meme coin on the Solana blockchain with Metaplex packages.
 # remember to update dates also in /components/guides/index.js
-created: '06-16-2024'
-updated: '06-21-2024'
+created: '04-19-2024'
+updated: '04-19-2025'
 ---
 
 This step by step guide will assist you in creating a Solana token (SPL Token) on the Solana blockchain. You can use the Metaplex Umi client wrapper and Mpl Toolbox package with Javascript. This enables you to create a function that you can use in scripts as well as frontend and backend frameworks.
@@ -39,12 +39,12 @@ npm i @metaplex-foundation/mpl-token-metadata
 ```
 
 ```js
-npm i @metaplex-foundation/umi-uploader-irys;
+npm i @metaplex-foundation/umi-uploader-irys
 ```
 
 ```js
-npm i @metaplex-foundation/mpl-toolbox;
-
+npm i @metaplex-foundation/mpl-toolbox
+```
 
 ### Imports and Wrapper Function
 
@@ -122,7 +122,7 @@ const umi = createUmi("https://devnet-aura.metaplex.com/<YOUR_API_KEY>")
 
 // You will need to us fs and navigate the filesystem to
 // load the wallet you wish to use via relative pathing.
-const walletFile = const imageFile = fs.readFileSync('./keypair.json')
+const walletFile = fs.readFileSync('./keypair.json')
 
 // Convert your walletFile onto a keypair.
 let keypair = umi.eddsa.createKeypairFromSecretKey(new Uint8Array(walletFile));
@@ -131,7 +131,6 @@ let keypair = umi.eddsa.createKeypairFromSecretKey(new Uint8Array(walletFile));
 umi.use(keypairIdentity(umiSigner));
 ```
 
-
 ## Creating the Token
 
 ### Uploading the Image
@@ -391,7 +390,7 @@ const createAndMintTokens = async () => {
   const createFungibleIx = createFungible(umi, {
     mint: mintSigner,
     name: "The Kitten Coin",
-    uri: metadataUri, // we use the `metedataUri` variable we created earlier that is storing our uri.
+    uri: metadataUri, // we use the `metadataUri` variable we created earlier that is storing our uri.
     sellerFeeBasisPoints: percentAmount(0),
     decimals: 0, // set the amount of decimals you want your token to have.
   });

src/pages/guides/javascript/how-to-create-an-nft-on-solana.md

@@ -3,15 +3,15 @@ title: How to Create an NFT On Solana
 metaTitle: How to Create an NFT On Solana | Guides
 description: Learn how to create an NFT on the Solana blockchain with Metaplex packages.
 # remember to update dates also in /components/guides/index.js
-created: '06-16-2024'
-updated: '06-18-2024'
+created: '04-19-2024'
+updated: '04-19-2025'
 ---
 
 Metaplex provides 3 different standards for creating NFTs on the Solana blockchain including **Core**, **Token Metadata**, and **Bubblegum**. Each standard and protocol provides unique advantages for projects and spread across the wide spectrum of minting and NFT requirements for projects.
 
 ## Core Asset (Recommended)
 
-Token Metadata is a protocol within Metaplex that focuses on the metadata aspects of NFTs. This standard defines how metadata is stored, retrieved, and associated with NFTs, ensuring that NFTs have rich, meaningful, and verifiable information attached to them.
+Core is the newest and most advanced digital asset standard created by Metaplex. This standard provides optimized account structures and enhanced functionality through a powerful plugin system.
 
 #### Why Use Core:
 

src/pages/guides/javascript/how-to-transfer-sol-on-solana.md

@@ -7,7 +7,7 @@ created: '06-16-2024'
 updated: '06-24-2024'
 ---
 
-This guide walks will show you how to build a Javascript function that transfers SOL from one wallet to another on the Solana blockchain utilizing the Metaplex Umi client wrapper and MPL Toolbox package.
+This guide will show you how to build a Javascript function that transfers SOL from one wallet to another on the Solana blockchain utilizing the Metaplex Umi client wrapper and MPL Toolbox package.
 
 ## Prerequisite
 
@@ -40,7 +40,7 @@ npm i @metaplex-foundation/umi-bundle-defaults
 ```
 
 ```js
-npm i @metaplex-foundation/mpl-toolbox;
+npm i @metaplex-foundation/mpl-toolbox
 ```
 
 ### Imports and Wrapper Function
@@ -59,7 +59,7 @@ import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'
 import { base58 } from '@metaplex-foundation/umi/serializers'
 
 // Create the wrapper function
-const transferSolana = async () => {
+const transfer = async () => {
   ///
   ///
   ///  all our code will go in here
@@ -68,7 +68,7 @@ const transferSolana = async () => {
 }
 
 // run the wrapper function
-transferSolana()
+transfer()
 ```
 
 ## Setting up Umi
@@ -80,9 +80,8 @@ This example is going to run through setting up Umi with a `generatedSigner()`.
 If you wish to generate a new wallet/private key to test with you generate a new signer with `umi`.
 
 ```ts
-const umi = createUmi("https://devnet-aura.metaplex.com/<YOUR_API_KEY>")
-  .use(mplCore())
-  .use(irysUploader())
+const umi = createUmi("https://api.devnet.solana.com")
+  .use(mplToolbox())
 
 // Generate a new keypair signer.
 const signer = generateSigner(umi)
@@ -91,24 +90,26 @@ const signer = generateSigner(umi)
 umi.use(signerIdentity(signer))
 
 // This will airdrop SOL on devnet only for testing.
-await umi.rpc.airdrop(umi.identity.publickey)
+await umi.rpc.airdrop(umi.identity.publicKey)
 ```
 
 ### Use an Existing Wallet Stored Locally
 
 ```ts
-const umi = createUmi("https://devnet-aura.metaplex.com/<YOUR_API_KEY>")
+import fs from 'fs';
+
+const umi = createUmi("https://api.devnet.solana.com")
   .use(mplToolbox())
 
 // You will need to use fs and navigate the filesystem to
 // load the wallet you wish to use via relative pathing.
-const walletFile = const imageFile = fs.readFileSync('./keypair.json')
+const walletFile = fs.readFileSync('./keypair.json')
 
 // Convert your walletFile onto a keypair.
 let keypair = umi.eddsa.createKeypairFromSecretKey(new Uint8Array(walletFile));
 
 // Load the keypair into umi.
-umi.use(keypairIdentity(umiSigner));
+umi.use(keypairIdentity(keypair));
 ```
 
 ## Transferring Sol
@@ -139,7 +140,7 @@ import { createUmi } from '@metaplex-foundation/umi-bundle-defaults'
 import { base58 } from '@metaplex-foundation/umi/serializers'
 
 const transfer = async () => {
-  const umi = createUmi("https://devnet-aura.metaplex.com/<YOUR_API_KEY>").use(mplToolbox())
+  const umi = createUmi("https://api.devnet.solana.com").use(mplToolbox())
 
   const signer = generateSigner(umi)
 

src/pages/guides/javascript/how-to-transfer-spl-tokens-on-solana.md

@@ -41,7 +41,7 @@ npm i @metaplex-foundation/umi-bundle-defaults
 ```
 
 ```js
-npm i @metaplex-foundation/mpl-toolbox;
+npm i @metaplex-foundation/mpl-toolbox
 ```
 
 ### Imports and Wrapper Function
@@ -61,7 +61,7 @@ import fs from 'fs'
 import path from 'path'
 
 const transferSplTokens = async () => {
-  const umi = createUmi("https://devnet-aura.metaplex.com/<YOUR_API_KEY>").use(mplToolbox())
+  const umi = createUmi("https://api.devnet.solana.com").use(mplToolbox())
 
   // import a wallet that has the SPL Token you want to transfer
   const walletFile = fs.readFileSync('./keypair.json')
@@ -101,7 +101,7 @@ const transferSplTokens = async () => {
   const res = await transferTokens(umi, {
     source: sourceTokenAccount,
     destination: destinationTokenAccount,
-    amount: 10000, // amount of tokens to transfer*
+    amount: 10000, // amount of tokens to transfer
   }).sendAndConfirm(umi);
 
   // Finally we can deserialize the signature that we can check on chain.

src/pages/guides/rpcs-and-das.md

@@ -1,36 +1,36 @@
 ---
 title: RPCs and DAS
 metaTitle: RPCs and DAS on the Solana Blockchain | Guides
-description: Learn about RPCS on the Solana blockchain and how DAS by Metaplex aids in storing and reading data on Solana.
+description: Learn about RPCs on the Solana blockchain and how DAS by Metaplex aids in storing and reading data on Solana.
 # remember to update dates also in /components/guides/index.js
 created: '06-16-2024'
-updated: '06-21-2024'
+updated: '04-19-2025'
 ---
 
 ## Roles of an RPC on the Solana Blockchain
-Remote Procedure Calls (RPCs) are a crucial part of the Solana blockchain infrastructure. They serve as the bridge between users (or applications) and blockchain, facilitating interactions and data retrieval.
+Remote Procedure Calls (RPCs) are a crucial part of the Solana blockchain infrastructure. They serve as the bridge between users (or applications) and the blockchain, facilitating interactions and data retrieval.
 
 #### Key Roles of an RPC
-1. **Facilitating Network Communication**
+1. **Facilitating Network Communication**:
 RPC servers handle requests from clients (users or applications) and interact with the blockchain to fulfill those requests. They provide a standardized way for external entities to communicate with the blockchain without requiring them to run a full node.
 
-2. **Submitting Transactions**
+2. **Submitting Transactions**:
 RPCs enable clients to submit transactions to the Solana blockchain. When a user wants to perform an action on the blockchain, such as transferring tokens or invoking a smart contract, the transaction is sent to an RPC server, which then propagates it to the network for processing and inclusion in a block.
 
-3. **Retrieving Blockchain Data**
+3. **Retrieving Blockchain Data**:
 RPC servers allow clients to ask the blockchain for various types of data, including:
 - **Account Information**: details about a specific account, such as balance, token holdings, and other metadata.
 - **Transaction History**: historical transactions associated with an account or a specific transaction signature.
 - **Block Information**: details about specific blocks, including block height, block hash, and transactions included in the block.
 - **Program Logs**: Access logs and output from executed programs (smart contracts).
 
-4. **Monitoring Network Status**
+4. **Monitoring Network Status**:
 RPCs provide endpoints to check the status of the network and nodes, such as:
 - **Node Health**: Determine if a node is online and functioning correctly.
 - **Network Latency**: Measure the time it takes for requests to be processed and responses to be received.
 - **Synchronization Status**: Check if a node is synchronized with the rest of the network.
 
-5. **Supporting Development and Debugging**
+5. **Supporting Development and Debugging**:
 RPC endpoints are essential tools for developers building on Solana. They provide functionalities to:
 - **Simulate Transactions**: simulate transactions to see their potential effects before submitting them to the network.
 - **Fetch Program Accounts**: retrieve all accounts associated with a specific program, which is useful for managing program state.
@@ -65,8 +65,8 @@ async function sendTransaction(transaction, payer) {
   console.log(`Transaction signature: ${signature}`);
 }
 
-// Example public key
-const publicKey = new solanaWeb3.PublicKey('ExamplePublicKeyHere');
+// Example public key (a real Solana address format)
+const publicKey = new solanaWeb3.PublicKey('7C4jsPZpht42Tw6MjXWF56Q5RQUocjBBmciEjDa8HRtp');
 
 // Get balance
 getBalance(publicKey);
@@ -74,13 +74,13 @@ getBalance(publicKey);
 
 ## Metaplex DAS
 
-Metaplex DAS (Digital Asset Standard) is a protocol or framework designed to standardize the read layer of NFTs and Tokens on the Solana blockchain allowing developers to standardise their code which fetching multiple different standards and layouts of Digital Assets.
+Metaplex DAS (Digital Asset Standard) is a protocol or framework designed to standardize the read layer of NFTs and Tokens on the Solana blockchain, allowing developers to standardize their code when fetching multiple different standards and layouts of Digital Assets.
 
 ### Indexing Digital Assets
-By indexing all the Digital Assets (NFTs and Tokens) users have access to much faster reads of data of these assets as the data is stored in an optimized database rather than fetching directly from chain.
+By indexing all the Digital Assets (NFTs and Tokens), users gain access to much faster reads of data for these assets as the information is stored in an optimized database rather than fetching directly from the blockchain.
 
 ### Syncing
-DAS has the ability to sync the reindexing of data during certain lifecycle instructions that are sent to the blockchain. By watching these instructions such as create, update, burn, and transfer we can always be assured that the DAS indexed data is up to date.
+DAS has the ability to sync the reindexing of data during certain lifecycle instructions that are sent to the blockchain. By watching these instructions, such as create, update, burn, and transfer, we can always be assured that the DAS indexed data is up to date.
 
 Currently Core, Token Metadata, and Bubblegum are all indexed by DAS.
 
@@ -90,3 +90,7 @@ To find out more about Metaplex DAS you can visit these pages:
 - [Metaplex DAS API Github](https://github.com/metaplex-foundation/digital-asset-standard-api)
 - [Metaplex Digital Asset RPC Infrastructure Github](https://github.com/metaplex-foundation/digital-asset-rpc-infrastructure)
 
+## RPC and DAS Integration
+
+RPCs and DAS complement each other in the Solana ecosystem. While standard RPCs provide direct access to on-chain data, Metaplex DAS offers an optimized, indexed layer specifically for digital assets. By leveraging both services appropriately, developers can build more efficient applications that retrieve general blockchain data through RPCs while accessing digital asset information through DAS, resulting in better performance and user experience.
+

src/pages/guides/rust/getting-started-with-rust.md

@@ -1,7 +1,7 @@
 ---
 title: Getting Started with Rust
 metaTitle: Getting Started with Rust | Guides
-description: A quick overview on how to get started with Rust in the Solana ecoSystem.
+description: A quick overview on how to get started with Rust in the Solana ecosystem.
 ---
 
 ## Introduction

src/pages/guides/rust/how-to-cpi-into-a-metaplex-program.md

@@ -104,7 +104,7 @@ TransferV1CpiBuilder::new()
 
 ```rust
 CreateV1CpiBuilder::new()
-        .asset(context.accounts,asset)
+        .asset(context.accounts.asset)
         .collection(context.accounts.collection)
         .authority(context.accounts.authority)
         .payer(context.accounts.payer)
@@ -113,7 +113,7 @@ CreateV1CpiBuilder::new()
         .system_program(context.accounts.system_program)
         .data_state(input.data_state.unwrap_or(DataState::AccountState))
         .name(args.asset_name)
-        .uri(arts.asset_uri)
+        .uri(args.asset_uri)
         .plugins(args.plugins)
 ```
 
@@ -130,7 +130,7 @@ Though accounts that have signed into your original instruction will automatical
 
 ```rust
 CreateV1CpiBuilder::new()
-        .asset(context.accounts,asset)
+        .asset(context.accounts.asset)
         ...
         .invoke()
 
@@ -138,18 +138,17 @@ CreateV1CpiBuilder::new()
 
 ### invoke_signed()
 
-`invoke_signed()` is used when a PDA is one of the accounts that needs to be a signer in a cpi call. Lets say for example we had a program that took possession of our Asset and one of our programs PDA addresses became the other of it. In order to transfer it and change the owner to someone else that PDA will have sign transaction.
+`invoke_signed()` is used when a PDA is one of the accounts that needs to be a signer in a cpi call. Lets say for example we had a program that took possession of our Asset and one of our programs PDA addresses became the owner of it. In order to transfer it and change the owner to someone else that PDA will have to sign the transaction.
 
-You'll need to pass in the original PDA seeds and bump so that the PDA can be recreated can sign the cpi call on your programs behalf.
+You'll need to pass in the original PDA seeds and bump so that the PDA can be recreated and can sign the cpi call on your programs behalf.
 
 ```rust
 let signers = &[&[b"escrow", ctx.accounts.asset.key(), &[ctx.bumps.pda_escrow]]]
 
 CreateV1CpiBuilder::new()
-        .asset(context.accounts,asset)
+        .asset(context.accounts.asset)
         ...
-        .invoke(signers)
-
+        .invoke_signed(signers)
 ```
 
 ## Full CpiBuilder Example

src/pages/guides/rust/metaplex-rust-sdks.md

@@ -10,7 +10,7 @@ Metaplex provides Rust SDKs for most of our programs which have consistent and p
 
 ## Modules
 
-The Core Rust SDKs our organized into several modules:
+The Core Rust SDKs are organized into several modules:
 
 - `accounts`: represents the program's accounts.
 - `instructions`: facilitates the creation of instructions, instruction arguments, and CPI instructions.
@@ -19,7 +19,7 @@ The Core Rust SDKs our organized into several modules:
 
 ### Accounts
 
-The **accounts** module is generated based on on-chain account state generation and their structs. These can be deserialized using a number of different methods based on if you are using RAW program generation or using a framework such as Anchor.
+The **accounts** module is generated based on on-chain account structures. These can be deserialized using a number of different methods based on if you are using RAW program generation or using a framework such as Anchor.
 
 These can be accessed from `<crate_name>::accounts`. In the case of `mpl-core` you could access the accounts as follows;
 
@@ -63,10 +63,9 @@ mpl_core::types
 
 While an **errors** module is generated for every SDK this just holds the error list for that specific program and users do not need to interact with this module.
 
-
 ## Instruction Builders
 
-Metaplex Rust SDKs will also currently come with two a **Builder** versions of each instruction which you can import. This abstracts a massive amount code for you and will return you an instruction that's ready to send.
+Metaplex Rust SDKs will also currently come with two **Builder** versions of each instruction which you can import. This abstracts a massive amount code for you and will return you an instruction that's ready to send.
 
 These include:
 
@@ -85,15 +84,9 @@ CreateV1InstructionArgs
 CreateV1InstructionData
 ```
 
-Each instruction that comes from a Metaplex Rust crate 
-
-Lets take the `CreateV1` instruction from Core as an example (this applies to all other instructions from this Crate and all other Metaplex crates too).
-
-If we look through the instructions in the  we can see we have a number of instructions available to us.
-
 ### Builder
 
-Builder instructions are designed to be used via
+Builder instructions are designed to be used when you need to create instructions for client-side transactions.
 
 The one we are interested in here is the `CreateV1Builder`.
 
@@ -121,10 +114,9 @@ pub struct CreateV1Builder {
     plugins: Option<Vec<PluginAuthorityPair>>,
     __remaining_accounts: Vec<solana_program::instruction::AccountMeta>,
 }
-
 ```
 
-These are your arguments of publickeys and data that will need to be passed into the builder. Some accounts may also be optional. These optional accounts my not be required at all by the program or could possibly default to another address if left out. This behaviour can vary from instruction to instruction. 
+These are your arguments of publickeys and data that will need to be passed into the builder. Some accounts may also be optional. These optional accounts may not be required at all by the program or could possibly default to another address if left out. This behaviour can vary from instruction to instruction. 
 
 If you click through to the `new()` function again and scroll down this time you'll see the individual functions with additional comments. In the below case you can see that the owner will default to payer, so we don't need to pass in owner if in this case if the payer is also going to be the owner of the Asset.
 
@@ -147,7 +139,7 @@ let create_asset_ix = CreateV1Builder::new()
         .payer(payer.pubkey())
         .name("My Nft".into())
         .uri("https://example.com/my-nft.json".into())
-.       .instruction();
+        .instruction();
 ```
 
 Now that we have our instruction ready we need to create a normal Solana transaction to send to our RPC. This includes a blockhash and signers.
@@ -187,7 +179,6 @@ let rpc_client = rpc_client::RpcClient::new("https://api.devnet.solana.com".to_s
     let res = rpc_client.send_and_confirm_transaction(&create_asset_tx).await.unwrap();
 
     println!("Signature: {:?}", res)
-
 ```
 
 ### CpiBuilder

src/pages/guides/rust/working-with-rust.md

@@ -105,7 +105,7 @@ let create_asset_ix = CreateV1Builder::new()
 .       .instruction();
 ```
 
-Now that we have our instruction ready we need to create a normal Solana transaction to send to our RPC. This includes a blockhash andxx§ signers.
+Now that we have our instruction ready we need to create a normal Solana transaction to send to our RPC. This includes a blockhash and signers.
 
 ### Full Builder Example
 
@@ -149,7 +149,7 @@ let rpc_client = rpc_client::RpcClient::new("https://api.devnet.solana.com".to_s
 
 ### CPI (Cross Program Invocation)
 
-You may have heard the term "CPI'ing into a program" or "Call a CPI on the program" terms thrown around before and be thinking "What they hell are they talking about?".
+You may have heard the term "CPI'ing into a program" or "Call a CPI on the program" terms thrown around before and be thinking "What the hell are they talking about?".
 
 Well CPI'ing into a program is basically one program calling upon another program during a transaction.
 
@@ -247,7 +247,7 @@ TransferV1CpiBuilder::new()
 
 ```rust
 CreateV1CpiBuilder::new()
-        .asset(context.accounts,asset)
+        .asset(context.accounts.asset)
         .collection(context.accounts.collection)
         .authority(context.accounts.authority)
         .payer(context.accounts.payer)
@@ -256,7 +256,7 @@ CreateV1CpiBuilder::new()
         .system_program(context.accounts.system_program)
         .data_state(input.data_state.unwrap_or(DataState::AccountState))
         .name(args.asset_name)
-        .uri(arts.asset_uri)
+        .uri(args.asset_uri)
         .plugins(args.plugins)
 ```
 
@@ -273,7 +273,7 @@ Though accounts that have signed into your original instruction will automatical
 
 ```rust
 CreateV1CpiBuilder::new()
-        .asset(context.accounts,asset)
+        .asset(context.accounts.asset)
         ...
         .invoke()
 
@@ -281,17 +281,17 @@ CreateV1CpiBuilder::new()
 
 #### invoke_signed()
 
-`invoke_signed()` is used when a PDA is one of the accounts that needs to be a signer in a cpi call. Lets say for example we had a program that took possession of our Asset and one of our programs PDA addresses became the other of it. In order to transfer it and change the owner to someone else that PDA will have sign transaction.
+`invoke_signed()` is used when a PDA is one of the accounts that needs to be a signer in a cpi call. Lets say for example we had a program that took possession of our Asset and one of our programs PDA addresses became the other of it. In order to transfer it and change the owner to someone else that PDA will have to sign the transaction.
 
-You'll need to pass in the original PDA seeds and bump so that the PDA can be recreated can sign the cpi call on your programs behalf.
+You'll need to pass in the original PDA seeds and bump so that the PDA can be recreated and can sign the cpi call on your programs behalf.
 
 ```rust
 let signers = &[&[b"escrow", ctx.accounts.asset.key(), &[ctx.bumps.pda_escrow]]]
 
 CreateV1CpiBuilder::new()
-        .asset(context.accounts,asset)
+        .asset(context.accounts.asset)
         ...
-        .invoke(signers)
+        .invoke_signed(signers)
 
 ```
 

src/pages/guides/setup-a-local-validator.md

@@ -3,8 +3,8 @@ title: Setup a Local Validator
 metaTitle: Setup a Local Validator
 description: Learn how to setup a local development environment and use a local validator
 # remember to update dates also in /components/guides/index.js
-created: '11-06-2024'
-updated: '11-06-2024'
+created: '04-19-2025'
+updated: '04-19-2025'
 ---
 
 ## Overview
@@ -89,7 +89,7 @@ solana-test-validator --account <address to load the account to> <path to accoun
 solana-test-validator --bpf-program <address to load the program to> <path to program file> --reset
 ```
 
-## Looking at Local transaction on Explorers
+## Looking at Local Transactions on Explorers
 
 Using a local validator doesn't prevent us from using the explorer since many explorers have the capability to connect to our local port and read the local ledger stored in the `test-ledger` folder we mentioned earlier.
 
@@ -144,7 +144,7 @@ Unfortunately, this part of the guide is available only for users on **Linux** o
 
 With the basics of the local validator setup and management, you can create and manage personalized local validators through **bash scripts**. 
 
-For example, you can create a `metaplex-test-validator` that includes the main Metaplex programs: `mpl-token-metadata`, `mpl-bubblegum`, and `mpl-core`.
+For example, you can create a `metaplex-local-validator` that includes the main Metaplex programs: `mpl-token-metadata`, `mpl-bubblegum`, and `mpl-core`.
 
 ### Setting Up Directories and Downloading Program Data
 
@@ -201,7 +201,7 @@ Start by opening a new script file using:
 sudo nano /usr/local/bin/metaplex-local-validator
 ```
 
-**Note**: If the /user/local/bin directory doesn’t exist, you can create it using `sudo mkdir -p -m 775 /usr/local/bin.`
+**Note**: If the /usr/local/bin directory doesn't exist, you can create it using `sudo mkdir -p -m 775 /usr/local/bin`
 
 Paste in the following code into the editor and save it:
 
@@ -226,11 +226,11 @@ eval $COMMAND
 Once your script is ready, modify its permissions so it can be executed:
 
 ```
-sudo chmod +x /usr/local/bin/metaplex-test-validator
+sudo chmod +x /usr/local/bin/metaplex-local-validator
 ```
 
 Finally, test your new validator within your project folder:
 
 ```
-metaplex-test-validator
+metaplex-local-validator
 ```

src/pages/guides/solana-programs.md

@@ -3,17 +3,17 @@ title: Solana Programs and State Overview
 metaTitle: Solana Programs and State Overview | Guides
 description: Learn about Solana Programs and how data is stored in account state on Solana.
 # remember to update dates also in /components/guides/index.js
-created: '06-16-2024'
-updated: '06-21-2024'
+created: '04-19-2024'
+updated: '04-19-2025'
 ---
 
 ## Solana Programs
 Solana programs are **executable code** that runs on the Solana blockchain. They are similar to smart contracts on other blockchain platforms, but with some distinct characteristics and optimizations specific to Solana.
 
 #### Key Characteristics:
-- **Stateless**: Solana programs do not store state internally. Instead, state is stored in seperate accounts on the chain.
+- **Stateless**: Solana programs do not store state internally. Instead, state is stored in separate accounts on the chain.
 - **Written in Rust**: Programs are typically written in Rust.
-- **Executed by Transactions**: Programs are invoked by transactions that specify the program ID and the required accounts and date.
+- **Executed by Transactions**: Programs are invoked by transactions that specify the program ID and the required accounts and data.
 
 ## Accounts
 Accounts **used to store both data and SOL**. Each account has an owner, which is a program that can modify its data.

src/pages/guides/templates/metaplex-nextjs-tailwind-template.md

@@ -4,7 +4,7 @@ metaTitle: Metaplex Solana NextJs Tailwind Template | Web UI Templates
 description: A web UI template using Nextjs, Tailwind, Metaplex Umi, Solana WalletAdapter and Zustand.
 ---
 
-Downloadable and reusable templates that utilizes Nextjs and Tailwind for the front end framework while also being preinstalled with Metaplex Umi, Solana WalletAdapter, and Zustand global store for ease of use.
+Downloadable and reusable templates that utilize Nextjs and Tailwind for the front end framework while also being preinstalled with Metaplex Umi, Solana WalletAdapter, and Zustand global store for ease of use.
 
 {% image src="/images/metaplex-next-js-template.png" classes="m-auto" /%}
 
@@ -54,7 +54,7 @@ In this example the RPC url is hardcoded into the `umiStore` umi state under `sr
 
 ```ts
 const useUmiStore = create<UmiState>()((set) => ({
-  // add your own RPC here
+  // Add your own RPC here.
   umi: createUmi("https://devnet-aura.metaplex.com/<YOUR_API_KEY>").use(
     signerIdentity(
       createNoopSigner(publicKey('11111111111111111111111111111111'))
@@ -72,7 +72,7 @@ By storing the umiInstance in **zustand** we can access it in both `.ts` and `.t
 
 While it's normally easier to use the helper methods below to access umi you can also access the state methods manually by calling for the `umiStore` state yourself.
 
-When fetching the `umi` state directly without a helper it will only pickup the umi instance and not the latest signer. By design when the walletAdapter changes state the state of the `signer` in the `umiStore` is updated but **NOT** applied to the `umi` state. So you will need to also pull the latest `signer` state and apply it to `umi`. This behavior can be outlined in the `umiProvider.tsx` file. In contrast, the `umi` [helpers](#helpers) always pull a fresh instance of the `signer` state.
+When fetching the `umi` state directly without a helper it will only pickup the umi instance and not the latest signer. By design when the walletAdapter changes state the state of the `signer` in the `umiStore` is updated but **NOT** automatically applied to the `umi` state. This behavior of keeping the signer and umi instance separate until explicitly combined can be seen in the `umiProvider.tsx` file. In contrast, the `umi` [helpers](#helpers) always pull a fresh instance of the `signer` state.
 
 ```ts
 // umiProvider.tsx snippet
@@ -111,15 +111,15 @@ Umi helpers are split up into several areas which can be called in different sce
 
 ### Transaction Helpers
 
-#### sendAndConfirmWithWalletAdapter()
+#### sendAndConfirmWalletAdapter()
 
-Passing a transaction into `sendAndConfirmWithWalletAdapter()` will send the transaction while pulling the latest walletAdapter state from the zustand `umiStore` and will return the signature as a `string`. This can be accessed in both `.ts` and `.tsx` files.
+Passing a transaction into `sendAndConfirmWalletAdapter()` will send the transaction while pulling the latest walletAdapter state from the zustand `umiStore` and will return the signature as a `string`. This can be accessed in both `.ts` and `.tsx` files.
 
 The function also provides and locks in the commitment level across `blockhash`, `send`, and `confirm` if provided. By default the commitment level of `confirmed` is used if no value is passed.
 
 There is also a `skipPreflight` flag that can be enabled if you need to debug failing transactions on chain. For more information about transactions errors you can view this guide [How to Diagnose Transaction Errors on Solana](/guides/general/how-to-diagnose-solana-transaction-errors).
 
-`sendAndConfirmWithWalletAdapter()` comes ready for priority fees via the `setComputeUnitPrice` instruction. These should reviewed and possibly adjusted or removed depending on your situation.
+`sendAndConfirmWalletAdapter()` comes ready for priority fees via the `setComputeUnitPrice` instruction. These should reviewed and possibly adjusted or removed depending on your situation.
 
 ```ts
 import useUmiStore from '@/store/useUmiStore'
@@ -127,14 +127,13 @@ import { setComputeUnitPrice } from '@metaplex-foundation/mpl-toolbox'
 import { TransactionBuilder, signerIdentity } from '@metaplex-foundation/umi'
 import { base58 } from '@metaplex-foundation/umi/serializers'
 
-const defaultPriorityFee
 
 const sendAndConfirmWalletAdapter = async (
   tx: TransactionBuilder,
   settings?: {
     commitment?: 'processed' | 'confirmed' | 'finalized'
     skipPreflight?: boolean
-  }
+      }
 ) => {
   const umi = useUmiStore.getState().umi
   const currentSigner = useUmiStore.getState().signer
@@ -221,11 +220,11 @@ export default umiWithSigner
 
 ### Example Transaction Using Helpers
 
-Within the `/lib` folder you will find a `transferSol` example transaction that utilizes both the fetching of the umi state using `umiWithCurrentWalletAdapter()` and the sending of the generated transaction using `sendAndConfirmWithWalletAdapter()`.
+Within the `/lib` folder you will find a `transferSol` example transaction that utilizes both the fetching of the umi state using `umiWithCurrentWalletAdapter()` and the sending of the generated transaction using `sendAndConfirmWalletAdapter()`.
 
 By pulling state from the umi store with `umiWithCurrentWalletAdapter()` if any of our transaction args require the `signer` type this will be automatically pulled from the umi instance which is generated with current user of `walletAdapter`. In this case the `from` account is determined by the current signer connected to umi (walletAdapter) and auto inferred in the transaction for us.
 
-By then sending transaction with `sendAndConfirmWithWalletAdapter` the signing process will use the `walletAdapter` and ask the current user to sign the transaction. The transaction will then be sent to the chain.
+By then sending transaction with `sendAndConfirmWalletAdapter` the signing process will use the `walletAdapter` and ask the current user to sign the transaction. The transaction will then be sent to the chain.
 
 ```ts
 // Example of a function that transfers SOL from one account to another pulling umi
@@ -256,9 +255,9 @@ const transferSolToDestination = async ({
     amount: sol(amount),
   })
 
-  // Use the sendAndConfirmWithWalletAdapter method to send the transaction.
+  // Use the sendAndConfirmWalletAdapter method to send the transaction.
   // We do not need to pass the umi stance or wallet adapter as an argument because a
-  // fresh instance is fetched from the `umiStore` in the `sendAndConfirmWithWalletAdapter` function.
+  // fresh instance is fetched from the `umiStore` in the `sendAndConfirmWalletAdapter` function.
   const res = await sendAndConfirmWalletAdapter(tx)
 }
 

src/pages/guides/understanding-pdas.md

@@ -3,8 +3,8 @@ title: Understanding Solana Program Derived Addresses (PDAs)
 metaTitle: Understanding Solana Program Derived Addresses | Guides
 description: Learn about Solana Program Derived Addresses (PDAs) and their use cases.
 # remember to update dates also in /components/guides/index.js
-created: '06-16-2024'
-updated: '06-21-2024'
+created: '04-19-2024'
+updated: '04-19-2025'
 ---
 
 ## Overview

src/pages/guides/validators.md

@@ -3,11 +3,94 @@ title: Validators and Staking
 metaTitle: Validators and Staking | Guides
 description: An overview of Solana Validators and staking mechanics.
 # remember to update dates also in /components/guides/index.js
-created: '06-16-2024'
-updated: '06-21-2024'
+created: '04-19-2025'
+updated: '04-19-2025'
 ---
 ## Overview
 
 Validators are responsible for processing transactions, generating new blocks, and validating the state of the blockchain to ensure accuracy and prevent double-spending. They participate in the consensus mechanism by voting on the legitimacy of blocks proposed by other validators, which helps to maintain the integrity and security of the network. Validators also contribute to the network's decentralization by staking their SOL tokens, which aligns their incentives with the network's health and stability.
 
-Validators often participate in governance decisions, providing insights and voting on proposals that affect the network's future. Many validators also contribute to the community by offering educational resources, running community nodes, and supporting the development of decentralized applications (dApps) and tools that enhance the ecosystem.
+Validators often participate in governance decisions, providing insights and voting on proposals that affect the network's future. Many validators also contribute to the community by offering educational resources, running community nodes, and supporting the development of decentralized applications (dApps) and tools that enhance the ecosystem.
+
+## Solana's Validator Network
+
+### Proof of Stake and Proof of History
+
+Solana uses a unique combination of Proof of Stake (PoS) and Proof of History (PoH) consensus mechanisms:
+
+- **Proof of Stake**: Validators must stake SOL tokens to participate in consensus. The amount staked influences their voting weight and potential rewards.
+- **Proof of History**: A cryptographic clock that provides a historical record of events, allowing validators to agree on the timing of events without requiring communication.
+
+This hybrid approach enables Solana to achieve high transaction throughput (up to 65,000 TPS) and low latency (400ms block times).
+
+### Validator Requirements
+
+Running a validator on Solana requires:
+
+- Hardware: High-performance servers with substantial computational power, including:
+  - CPU: 12 cores / 24 threads, 2.8GHz or faster
+  - RAM: 256GB or more
+  - Storage: 2TB or larger NVMe SSD
+  - Network: 1 Gbps or faster internet connection
+- Software: Solana validator software and supporting tools
+- SOL Tokens: To cover vote transaction fees and optional self-stake
+
+### Validator Economics
+
+Validators earn rewards through:
+
+1. **Transaction Fees**: A portion of transaction fees paid by users
+2. **Inflation Rewards**: New SOL tokens distributed to validators and delegators
+3. **MEV (Maximal Extractable Value)**: Additional value that can be extracted by influencing transaction ordering
+
+## Staking on Solana
+
+### Staking Mechanics
+
+Staking on Solana can be done in two primary ways:
+
+1. **Direct Staking (Validator)**: Running a validator node and staking your own SOL
+2. **Delegation (Delegator)**: Delegating your SOL to an existing validator without running a node yourself
+
+### Delegation Process
+
+To delegate SOL to a validator:
+
+1. Choose a validator based on performance, commission rate, and reliability
+2. Create a stake account using a compatible wallet (Phantom, Solflare, etc.)
+3. Delegate SOL to your chosen validator
+4. Monitor your staking rewards, which are automatically compounded
+
+### Stake Activation and Deactivation
+
+- **Activation**: When you delegate SOL, it takes approximately 2-3 epochs (2-3 days) for your stake to become active and start earning rewards
+- **Deactivation**: When you decide to undelegate, it takes approximately 2-3 epochs before your SOL becomes fully liquid again
+
+### Choosing a Validator
+
+Consider these factors when selecting a validator:
+- **Performance**: Uptime and block production history
+- **Commission**: The percentage of rewards the validator keeps (typically 5-10%)
+- **Total Stake**: Higher stake may indicate trust but also contributes to centralization
+- **Decentralization Impact**: Consider supporting smaller validators to enhance network decentralization
+
+## Tools and Resources
+
+### Staking Tools
+- [Solana Beach](https://solanabeach.io/validators) - Explorer and validator statistics
+- [Validators.app](https://www.validators.app/) - Detailed validator performance metrics
+- [Stakeview.app](https://stakeview.app/) - Validator ranking and comparison
+
+### Wallets Supporting Staking
+- Phantom
+- Solflare
+- Ledger
+- Math Wallet
+
+## Common Terms
+
+- **Epoch**: A time period in Solana (approximately 2-3 days) during which validator performance is measured and rewards are distributed
+- **Commission**: The percentage of staking rewards that validators charge delegators for their services
+- **Slashing**: A penalty for validator misbehavior, currently not implemented on Solana
+- **Vote Account**: An account that validators use to participate in consensus by voting on blocks
+- **Stake Account**: An account that holds delegated SOL tokens

src/pages/guides/what-is-solana.md

@@ -3,8 +3,8 @@ title: What is Solana?
 metaTitle: What is Solana? | Guides
 description: What is Solana and why would you want to build on it.
 # remember to update dates also in /components/guides/index.js
-created: '06-16-2024'
-updated: '06-21-2024'
+created: '04-19-2025'
+updated: '04-19-2025'
 ---
 
 # Solana Overview
@@ -34,6 +34,36 @@ The Solana blockchain is a high-performance, decentralized blockchain platform d
 7. **Low Costs:**
    Solana offers low transaction fees, making it an attractive option for developers and users looking to build and interact with dApps and DeFi platforms without the high costs associated with other blockchains.
 
-   ## Upcoming
-   
-   In addition to what is already a performant chain Solana is advancing with new developments like Runtime v2, which aims to improve transaction processing and a simplified developer experience for everyone.
+## Upcoming Developments
+
+In addition to what is already a performant chain, Solana is advancing with new developments like Runtime v2, which aims to improve transaction processing and provide a simplified developer experience for everyone.
+
+## Solana Ecosystem
+
+Solana has grown into a vibrant ecosystem that supports a wide range of applications and use cases:
+
+1. **DeFi (Decentralized Finance):**
+   Solana hosts numerous DeFi protocols including decentralized exchanges (DEXs), lending platforms, yield farming applications, and stablecoin projects that leverage its high throughput and low fees.
+
+2. **NFTs and Digital Collectibles:**
+   The platform has become a major hub for NFT marketplaces and collections due to its ability to handle high-volume minting and trading at a fraction of the cost of other chains.
+
+3. **Web3 Gaming:**
+   Game developers are increasingly building on Solana to create on-chain gaming experiences that benefit from fast transaction confirmations and affordable gas fees.
+
+4. **Payments and Commerce:**
+   Solana's speed makes it suitable for payment applications that require near-instant settlements, enabling efficient point-of-sale systems and e-commerce solutions.
+
+5. **DAOs (Decentralized Autonomous Organizations):**
+   Many communities have established governance structures on Solana, taking advantage of its efficient voting mechanisms and token management capabilities.
+
+## Why Build on Solana?
+
+Developers choose Solana for several compelling reasons:
+
+- **Performance at Scale:** Applications can serve millions of users without performance degradation
+- **Cost Efficiency:** Low transaction fees enable micro-transactions and frequent user interactions
+- **Developer Tooling:** Rich ecosystem of SDKs, frameworks, and educational resources
+- **Composability:** Easy integration with other protocols and applications in the ecosystem
+- **Sustainability:** Lower energy consumption compared to Proof of Work blockchains
+- **Growing User Base:** Access to a rapidly expanding community of users and developers

src/pages/guides/where-do-i-start.md

@@ -1,8 +1,8 @@
 ---
 title: Where Do I Start With Solana?
 metaTitle: Where Do I Start With Solana? | Guides
-description: An overiew of the Solana ecosystem frameworks and where to research.
+description: An overview of the Solana ecosystem frameworks and where to research.
 # remember to update dates also in /components/guides/index.js
-created: '06-16-2024'
-updated: '06-21-2024'
+created: '04-19-2024'
+updated: '04-19-2025'
 ---