Add Fumadocs

.gitignore

@@ -41,3 +41,4 @@ public/sitemap*
 
 coverage
 .env.local
+.source

content/docs/core/accounts.mdx

@@ -0,0 +1,183 @@
+---
+sidebarSortOrder: 1
+sidebarLabel: Solana Account Model
+title: Solana Account Model
+description:
+  Learn about Solana's account model, including how accounts store data and
+  programs, rent mechanics, account ownership, and the relationship between
+  programs and data accounts. Understand the core concepts of Solana's key-value
+  storage system.
+---
+
+On Solana, all data is stored in what are referred to as "accounts”. The way
+data is organized on Solana resembles a
+[key-value store](https://en.wikipedia.org/wiki/Key%E2%80%93value_database),
+where each entry in the database is called an "account".
+
+## Key Points
+
+- Accounts can store up to 10MB of data, which can consist of either executable
+  program code or program state.
+
+- Accounts require a rent deposit in SOL, proportional to the amount of data
+  stored, which is fully refundable when the account is closed.
+
+- Every account has a program "owner". Only the program that owns an account can
+  modify its data or deduct its lamport balance. However, anyone can increase
+  the balance.
+
+- Programs (smart contracts) are stateless accounts that store executable code.
+
+- Data accounts are created by programs to store and manage program state.
+
+- Native programs are built-in programs included with the Solana runtime.
+
+- Sysvar accounts are special accounts that store network cluster state.
+
+## Account
+
+Each account is identifiable by its unique address, represented as 32 bytes in
+the format of an [Ed25519](https://ed25519.cr.yp.to/) `PublicKey`. You can think
+of the address as the unique identifier for the account.
+
+This relationship between the account and its address can be thought of as a
+key-value pair, where the address serves as the key to locate the corresponding
+on-chain data of the account.
+
+### AccountInfo
+
+Accounts have a
+[max size of 10MB](https://github.com/solana-labs/solana/blob/27eff8408b7223bb3c4ab70523f8a8dca3ca6645/sdk/program/src/system_instruction.rs#L85)
+(10 Mega Bytes) and the data stored on every account on Solana has the following
+structure known as the
+[AccountInfo](https://github.com/solana-labs/solana/blob/27eff8408b7223bb3c4ab70523f8a8dca3ca6645/sdk/program/src/account_info.rs#L19).
+
+The `AccountInfo` for each account includes the following fields:
+
+- `data`: A byte array that stores the state of an account. If the account is a
+  program (smart contract), this stores executable program code. This field is
+  often referred to as the "account data".
+- `executable`: A boolean flag that indicates if the account is a program.
+- `lamports`: A numeric representation of the account's balance in
+  [lamports](/docs/terminology.md#lamport), the smallest unit of SOL (1 SOL = 1
+  billion lamports).
+- `owner`: Specifies the public key (program ID) of the program that owns the
+  account.
+
+As a key part of the Solana Account Model, every account on Solana has a
+designated "owner", specifically a program. Only the program designated as the
+owner of an account can modify the data stored on the account or deduct the
+lamport balance. It's important to note that while only the owner may deduct the
+balance, anyone can increase the balance.
+
+> To store data on-chain, a certain amount of SOL must be transferred to an
+> account. The amount transferred is proportional to the size of the data stored
+> on the account. This concept is commonly referred to as “rent”. However, you
+> can think of "rent" more like a "deposit" because the SOL allocated to an
+> account can be fully recovered when the account is closed.
+
+## Native Programs
+
+Solana contains a small handful of native programs that are part of the
+validator implementation and provide various core functionalities for the
+network. You can find the full list of native programs
+[here](https://docs.solanalabs.com/runtime/programs).
+
+When developing custom programs on Solana, you will commonly interact with two
+native programs, the System Program and the BPF Loader.
+
+### System Program
+
+By default, all new accounts are owned by the
+[System Program](https://github.com/solana-labs/solana/tree/27eff8408b7223bb3c4ab70523f8a8dca3ca6645/programs/system/src).
+The System Program performs several key tasks such as:
+
+- [New Account Creation](https://github.com/solana-labs/solana/blob/27eff8408b7223bb3c4ab70523f8a8dca3ca6645/programs/system/src/system_processor.rs#L145):
+  Only the System Program can create new accounts.
+- [Space Allocation](https://github.com/solana-labs/solana/blob/27eff8408b7223bb3c4ab70523f8a8dca3ca6645/programs/system/src/system_processor.rs#L70):
+  Sets the byte capacity for the data field of each account.
+- [Assign Program Ownership](https://github.com/solana-labs/solana/blob/27eff8408b7223bb3c4ab70523f8a8dca3ca6645/programs/system/src/system_processor.rs#L112):
+  Once the System Program creates an account, it can reassign the designated
+  program owner to a different program account. This is how custom programs take
+  ownership of new accounts created by the System Program.
+
+On Solana, a "wallet" is simply an account owned by the System Program. The
+lamport balance of the wallet is the amount of SOL owned by the account.
+
+> Only accounts owned by the System Program can be used as transaction fee
+> payers.
+
+### BPFLoader Program
+
+The
+[BPF Loader](https://github.com/solana-labs/solana/tree/27eff8408b7223bb3c4ab70523f8a8dca3ca6645/programs/bpf_loader/src)
+is the program designated as the "owner" of all other programs on the network,
+excluding Native Programs. It is responsible for deploying, upgrading, and
+executing custom programs.
+
+## Sysvar Accounts
+
+Sysvar accounts are special accounts located at predefined addresses that
+provide access to cluster state data. These accounts are dynamically updated
+with data about the network cluster. You can find the full list of Sysvar
+Accounts [here](https://docs.solanalabs.com/runtime/sysvars).
+
+## Custom Programs
+
+On Solana, “smart contracts” are referred to as
+[programs](/docs/core/programs.md). A program is an account that contains
+executable code and is indicated by an “executable” flag that is set to true.
+
+For a more detailed explanation of the program deployment process, refer to the
+[Deploying Programs](/docs/programs/deploying.md) page of this documentation.
+
+### Program Account
+
+When new programs are
+[deployed](https://github.com/solana-labs/solana/blob/27eff8408b7223bb3c4ab70523f8a8dca3ca6645/programs/bpf_loader/src/lib.rs#L498)
+on Solana, technically three separate accounts are created:
+
+- **Program Account**: The main account representing an on-chain program. This
+  account stores the address of an executable data account (which stores the
+  compiled program code) and the update authority for the program (address
+  authorized to make changes to the program).
+- **Program Executable Data Account**: An account that contains the executable
+  byte code of the program.
+- **Buffer Account**: A temporary account that stores byte code while a program
+  is being actively deployed or upgraded. Once the process is complete, the data
+  is transferred to the Program Executable Data Account and the buffer account
+  is closed.
+
+For example, here are links to the Solana Explorer for the Token Extensions
+[Program Account](https://explorer.solana.com/address/TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb)
+and its corresponding
+[Program Executable Data Account](https://explorer.solana.com/address/DoU57AYuPFu2QU514RktNPG22QhApEjnKxnBcu4BHDTY).
+
+For simplicity, you can think of the "Program Account" as the program itself.
+
+> The address of the "Program Account" is commonly referred to as the “Program
+> ID”, which is used to invoke the program.
+
+### Data Account
+
+Solana programs are "stateless", meaning that program accounts only contain the
+program's executable byte code. To store and modify additional data, new
+accounts must be created. These accounts are commonly referred to as “data
+accounts”.
+
+Data accounts can store any arbitrary data as defined in the owner program's
+code.
+
+Note that only the [System Program](/docs/core/accounts.md#system-program) can
+create new accounts. Once the System Program creates an account, it can then
+transfer ownership of the new account to another program.
+
+In other words, creating a data account for a custom program requires two steps:
+
+1. Invoke the System Program to create an account, which then transfers
+   ownership to a custom program
+2. Invoke the custom program, which now owns the account, to then initialize the
+   account data as defined in the program code
+
+This data account creation process is often abstracted as a single step, but
+it's helpful to understand the underlying process.

content/docs/core/index.mdx

@@ -0,0 +1,117 @@
+---
+title: Core Concepts
+sidebarSortOrder: 2
+description:
+  Learn essential Solana blockchain concepts including accounts, transactions,
+  programs, programd derived addresses, cross program invocations, and how
+  tokens work on Solana.
+---
+
+Build a strong understanding of the core concepts that make Solana different
+from other blockchains. Understanding the "Solana programming model" through
+these core concepts is very important to maximize your success as a Solana
+blockchain developer.
+
+## Solana Account Model
+
+On Solana, all data is stored in what are referred to as "accounts”. The way
+data is organized on the Solana blockchain resembles a
+[key-value store](https://en.wikipedia.org/wiki/Key%E2%80%93value_database),
+where each entry in the database is called an "account".
+
+Learn more about [Accounts](/docs/core/accounts.md) here.
+
+## Transactions and Instructions
+
+On Solana, we send [transactions](/docs/core/transactions#transaction) to
+interact with the network. Transactions include one or more
+[instructions](/docs/core/transactions#instruction), each representing a
+specific operation to be processed. The execution logic for instructions is
+stored on [programs](/docs/core/programs) deployed to the Solana network, where
+each program stores its own set of instructions.
+
+Learn more about [Transactions](/docs/core/transactions.md) and
+[Instructions](/docs/core/transactions.md#instruction) here.
+
+## Fees on Solana
+
+The Solana blockchain has a few different types of fees and costs that are
+incurred to use the permissionless network. These can be segmented into a few
+specific types:
+
+- [Transaction Fees](/docs/core/fees.md#transaction-fees) - A fee to have
+  validators process transactions/instructions
+- [Prioritization Fees](/docs/core/fees.md#prioritization-fees) - An optional
+  fee to boost transactions processing order
+- [Rent](/docs/core/fees.md#rent) - A withheld balance to keep data stored
+  on-chain
+
+Learn more about [Fees on Solana](/docs/core/fees.md) here.
+
+## Programs on Solana
+
+In the Solana ecosystem, "smart contracts" are called programs. Each program is
+an on-chain account that stores executable logic, organized into specific
+functions referred to as _instructions_ and called via _instruction handler_
+functions within the respective deployed program.
+
+Learn more about [Programs on Solana](/docs/core/programs.md) here.
+
+## Program Derived Address
+
+Program Derived Addresses (PDAs) provide developers on Solana with two main use
+cases:
+
+- **Deterministic Account Addresses**: PDAs provide a mechanism to
+  deterministically derive an address using a combination of optional "seeds"
+  (predefined inputs) and a specific program ID.
+- **Enable Program Signing**: The Solana runtime enables programs to "sign" for
+  PDAs which are derived from its program ID.
+
+You can think of PDAs as a way to create hashmap-like structures on-chain from a
+predefined set of inputs (e.g. strings, numbers, and other account addresses).
+
+Learn more about [Program Derived Address](/docs/core/pda.md) here.
+
+## Cross Program Invocation
+
+A Cross Program Invocation (CPI) refers to when one program invokes the
+instructions of another program. This mechanism allows for the composability of
+Solana programs.
+
+You can think of instructions as API endpoints that a program exposes to the
+network and a CPI as one API internally invoking another API.
+
+Learn more about [Cross Program Invocation](/docs/core/cpi.md) here.
+
+## Tokens on Solana
+
+Tokens are digital assets that represent ownership over diverse categories of
+assets. Tokenization enables the digitalization of property rights, serving as a
+fundamental component for managing both fungible and non-fungible assets.
+
+- Fungible Tokens represent interchangeable and divisible assets of the same
+  type and value (ex. USDC).
+- Non-fungible Tokens (NFT) represent ownership of indivisible assets (e.g.
+  artwork).
+
+Learn more about [Tokens on Solana](/docs/core/tokens.md) here.
+
+## Clusters and Endpoints
+
+The Solana blockchain has several different groups of validators, known as
+[Clusters](/docs/core/clusters.md). Each serving different purposes within the
+overall ecosystem and containing dedicated api nodes to fulfill
+[JSON-RPC](/docs/rpc/index.mdx) requests for their respective Cluster.
+
+The individual nodes within a Cluster are owned and operated by third parties,
+with a public endpoint available for each.
+
+There are three primary clusters on the Solana network, each with a different
+public endpoint:
+
+- Mainnet - `https://api.mainnet-beta.solana.com`
+- Devnet - `https://api.devnet.solana.com`
+- Testnet - `https://api.testnet.solana.com`
+
+Learn more about [Clusters and Endpoints](/docs/core/clusters.md) here.

content/docs/core/meta.json

@@ -0,0 +1,5 @@
+{
+  "title": "Core Concepts",
+  "pages": ["accounts", "transactions"],
+  "defaultOpen": true
+}