Organize images into folders and delete old images

docs/build/apps/example-application-tutorial/account-creation.mdx

@@ -15,13 +15,13 @@ Since we are building a [non-custodial application], the encrypted secret key wi
 
 :::
 
-![public and private keys](/assets/public-and-private-keys.png)
+![public and private keys](/assets/basic-pay/public-and-private-keys.png)
 
 Next, we'll trigger the user to submit a pincode to encrypt their secret key before it gets saved to their browser's `localStorage` (this is handled by the [`js-stellar-wallets` SDK]). The user will need to remember their pincode for future logins and to submit transactions.
 
 With BasicPay, when the user clicks the “Signup” button, they will be asked to confirm their pincode. When they do, the `create_account` operation is triggered, and the user's account is automatically funded with XLM for the minimum balance (starting with 10,000 XLM).
 
-![funded account](/assets/funded-account.png)
+![funded account](/assets/basic-pay/funded-account.png)
 
 When you're ready to move the application to Pubnet, accounts will need to be funded with real XLM. This is something the application can cover itself by depositing XLM into the user's account, with the use of [sponsored reserves], or the user can cover the required balance with their own XLM.
 

docs/build/apps/example-application-tutorial/anchor-integration/sep10.mdx

@@ -3,7 +3,7 @@ title: "SEP-10: Stellar Web Authentication"
 sidebar_position: 20
 ---
 
-import auth_valid from "/assets/auth_valid.png";
+import auth_valid from "/assets/basic-pay/auth_valid.png";
 
 Similar to the SEP-1 information, both SEP-6 and SEP-24 protocols make use of SEP-10 for authentication with the user. The user must prove they own the account before they can withdraw or deposit any assets as part of SEP-10: Stellar Web Authentication.
 
@@ -58,7 +58,7 @@ The `/src/routes/dashboard/transfers/+page.svelte` is doing **a lot** of work th
 
 Now, when the user clicks the "authenticate" button, it triggers the `auth` function.
 
-![authenticate](/assets/authenticate.png)
+![authenticate](/assets/basic-pay/authenticate.png)
 
 ```html title=/src/routes/dashboard/transfers/+page.svelte
 <script>

docs/build/apps/example-application-tutorial/anchor-integration/sep24.mdx

@@ -3,7 +3,7 @@ title: "SEP-24: Hosted Deposit and Withdrawal"
 sidebar_position: 40
 ---
 
-import sep24_transfers from "/assets/sep24_transfers.png";
+import sep24_transfers from "/assets/basic-pay/sep24_transfers.png";
 
 SEP-24 provides a standard way for wallets and anchors to interact by having the user open a webview hosted by an anchor to collect and handle KYC information. In this integration, a user's KYC information is gathered and handled entirely by the anchor. For the most part, after the anchor's webview has opened, BasicPay will have little knowledge about what's going on.
 

docs/build/apps/example-application-tutorial/anchor-integration/sep6.mdx

@@ -51,7 +51,7 @@ Since many of the SEP-6 (and SEP-24) endpoints require authentication, we wait u
 
 The user can then initiate one of the transfer methods (in BasicPay, only deposits and withdraws are supported) by clicking the “Deposit” or “Withdraw” button underneath a supported asset.
 
-![sep6](/assets/sep6_deposit_withdraw.png)
+![sep6](/assets/basic-pay/sep6_deposit_withdraw.png)
 
 ```html title=/src/routes/dashboard/transfers/+page.svelte
 <script>
@@ -132,7 +132,10 @@ BasicPay prompts the user to input additional information such as transfer type,
 
 We'll spare the code sample in this section, since it's mostly Svelte things going on. You can view the source here: https://github.com/stellar/basic-payment-app/blob/main/src/routes/dashboard/transfers/components/TransferDetails.svelte
 
-<img src={useBaseUrl("/assets/sep6_transfer_details.png")} width="45%" />
+<img
+  src={useBaseUrl("/assets/basic-pay/sep6_transfer_details.png")}
+  width="45%"
+/>
 
 ### Modal step 2: Gather KYC information
 
@@ -152,7 +155,7 @@ export async function getKycServer(domain) {
 
 Our SEP-6 modal then queries the anchor’s SEP-12 endpoint for the required KYC fields with a `GET` request, and we present these fields for the user to complete.
 
-<img src={useBaseUrl("/assets/sep6_kyc.png")} width="45%" />
+<img src={useBaseUrl("/assets/basic-pay/sep6_kyc.png")} width="45%" />
 
 ```js title=/src/lib/stellar/sep12.js
 import { getKycServer } from "$lib/stellar/sep1";
@@ -206,7 +209,7 @@ export async function putSep12Fields({ authToken, fields, homeDomain }) {
 
 BasicPay receives back from the anchor a status message for the user to see. Once the status message is `ACCEPTED`, we can finally submit the actual transfer request!
 
-<img src={useBaseUrl("/assets/kyc_accepted.png")} width="50%" />
+<img src={useBaseUrl("/assets/basic-pay/kyc_accepted.png")} width="50%" />
 
 This component of the SEP-6 modal, like most of them, is almost entirely Svelte-related. So as to keep this tutorial (somewhat) uncluttered, we'll refer you to the source for the component, which you can find here: https://github.com/stellar/basic-payment-app/blob/main/src/routes/dashboard/transfers/components/KYCStatus.svelte
 

docs/build/apps/example-application-tutorial/confirmation-modal.mdx

@@ -11,7 +11,7 @@ The user should be informed about any actions that may take place, especially wh
 
 The modal window we've implemented facilitates this confirmation flow whenever we need it.
 
-![confirmation modal](/assets/confirm-pincode.png)
+![confirmation modal](/assets/basic-pay/confirm-pincode.png)
 
 ## Code implementation
 

docs/build/apps/example-application-tutorial/contacts-list.mdx

@@ -9,7 +9,7 @@ One central feature of BasicPay is a list of contacts containing a user's name a
 
 There are a few ways for a user to interact with the contact list. One way is that they can add a user and address on the `/dashboard/contacts` page (which also checks for a valid public key!).
 
-![contact list](/assets/add-contact.png)
+![contact list](/assets/basic-pay/add-contact.png)
 
 See it in action here: https://basicpay.pages.dev/dashboard/contacts
 

docs/build/apps/example-application-tutorial/manage-trust.mdx

@@ -15,7 +15,7 @@ An asset is displayed as an asset code and issuer address. Learn more in our [As
 
 :::
 
-![add-assets](/assets/add-assets.png)
+![add-assets](/assets/basic-pay/add-assets.png)
 
 This triggers a modal form for the user to confirm the transaction with their pincode. Once confirmed, a transaction containing the `changeTrust` operation is signed and submitted to the network, and a trustline is established between the user's account and the issuing account for the asset.
 
@@ -29,7 +29,7 @@ Every transaction must contain a sequence number that is used to identify and ve
 
 Trustlines hold the balances for all of their associated assets (except XLM, which are held at the account level), and you can display the user’s various balances in your application.
 
-![display assets](/assets/display-assets.png)
+![display assets](/assets/basic-pay/display-assets.png)
 
 See it in action here: https://basicpay.pages.dev/dashboard/assets
 

docs/build/apps/example-application-tutorial/path-payment.mdx

@@ -9,7 +9,7 @@ A path payment is where the asset sent can be different from the asset received.
 
 With BasicPay, the user sends a path payment by navigating to the Payments page, where they can either select a user from their contacts or input the public key of a destination address. They then select the Send and Receive Different Assets toggle and determine whether they want to specify the asset sent or received. Finally they select the asset sent and the asset received and the amounts and select the Preview Transaction button.
 
-![path payment](/assets/path-payment.png)
+![path payment](/assets/basic-pay/path-payment.png)
 
 The user will then preview the transaction, input their pincode, and select the Confirm button to sign and submit the transaction to the network.
 

docs/build/apps/example-application-tutorial/payment.mdx

@@ -9,15 +9,15 @@ A payment operation sends an amount in a specific asset (XLM or non-XLM) to a de
 
 In our BasicPay application, the user will navigate to the Payments page where can either select a user from their contacts or input the public key of a destination address with a specified asset they’d like to send along with the amount of the asset.
 
-![payment](/assets/payment.png)
+![payment](/assets/basic-pay/payment.png)
 
 The user clicks the "Confirm Transaction" button. If the destination account exists and is properly funded with XLM, this will trigger a Transaction Preview where they can view the transaction details.
 
 All Stellar transactions require a small fee to make it to the ledger. Read more in our [Fees section](../../../learn/fundamentals/fees-resource-limits-metering.mdx).
 
 In BasicPay, we’ve set it up so that the user always pays a static fee of 100,000 [stroops](../../../learn/fundamentals/stellar-data-structures/assets.mdx#amount-precision) (one stroop equals 0.0000001 XLM) per operation. Alternatively, you can add a feature to your application that allows the user to set their own fee.
 
-![payment](/assets/fees.png)
+![payment](/assets/basic-pay/fees.png)
 
 The user then inputs their pincode and clicks the "Confirm" button, which signs and submits the transaction to the ledger.
 

docs/build/apps/guestbook/overview.mdx

@@ -13,7 +13,7 @@ Although Ye Olde Guestbook is a full-fledged application on Stellar's Testnet, i
 
 :::
 
-![Ye Olde Guestbook Dapp](/img/tutorial/guestbook/frontend.png)
+![Ye Olde Guestbook Dapp](/assets/guestbook/frontend.png)
 
 ## Project setup
 
@@ -65,7 +65,7 @@ Here are the steps we've taken to start building Ye Olde Guestbook. Feel free to
 
 With the move to smart contract development, a newly emerging utility in the Stellar ecosystem is the "[Soroban template](https://developers.stellar.org/docs/build/guides/dapps/soroban-contract-init-template)." These templates can help alleviate the burden of writing boilerplate code, and can help adapt typical Stellar development workflows into framework-specific reference templates. We've created [just such a template](https://github.com/ElliotFriend/soroban-template-sveltekit-passkeys) that can help you get started developing with SvelteKit and passkeys from the very beginning. You can either use the template on the GitHub website:
 
-![GitHub Template Project](/img/tutorial/guestbook/github_template.png)
+![GitHub Template Project](/assets/guestbook/github_template.png)
 
 Or, you can (fork and) clone the template repository locally, and start working that way:
 

docs/build/apps/guestbook/passkeys-prerequisites.mdx

@@ -48,7 +48,7 @@ The `passkey-kit` package doesn't "ship" with a Zephyr program in the published
 
 2. Get an authentication token from the Mercury website. You can login to the [Testnet dashboard](https://test.mercurydata.app/) here. Click on the **Get access token** button under the "Active subscriptions" section. You'll be given a JWT which will be valid for the next seven days.
 
-   ![Mercury Data JWT Token](/img/tutorial/guestbook/mercury_token.png)
+   ![Mercury Data JWT Token](/assets/guestbook/mercury_token.png)
 
    Copy/paste this token into the `.env` file:
 

docs/build/apps/ingest-sdk/overview.mdx

@@ -47,7 +47,7 @@ Our example application is only interested in a small subset of the overall netw
 
 The example application will perform both of CDP pipelines. A minimum of two pipelines are required for a complete end to end CDP architecture.
 
-![](/assets/cdp_pipelines.png)
+![](/assets/ingest-sdk/cdp_pipelines.png)
 
 ### Ledger Metadata Export Pipeline
 

docs/build/apps/moneygram-access-integration-guide.mdx

@@ -103,11 +103,11 @@ This guide will assume the application has a basic client-server architecture. T
 
 Below are the 7 high-level steps to take to facilitate a cash-out (withdrawal) transaction.
 
-![Wallet - MoneyGram Page 1](/assets/wallet-mgi-architecture-1.png)
+![Wallet - MoneyGram Page 1](/assets/mgi/wallet-mgi-architecture-1.png)
 
 After Step 4, the application should open the URL provided by MoneyGram in a mobile webview or browser tab. MoneyGram will then prompt the user to provide KYC and transaction information. On completion of this flow, the application’s client should close the MoneyGram tab or webview and initiate the disbursement of funds.
 
-![Wallet - MoneyGram Page 2](/assets/wallet-mgi-architecture-2.png)
+![Wallet - MoneyGram Page 2](/assets/mgi/wallet-mgi-architecture-2.png)
 
 The provided reference number would then be taken to any MoneyGram cash agent in order to receive cash in the user’s fiat currency. These steps document the cash-out, or withdrawal flow. The deposit flow is similar and detailed in the steps below.
 

docs/data/indexers/build-your-own/galexie/README.mdx

@@ -16,7 +16,7 @@ Galexie is designed to make streamlined and efficient export of ledger metadata
 - Exporting ledger metadata in XDR which is Stellar Core’s native format.
 - Compressing data before export to optimize storage efficiency in the data lake.
 
-![](/assets/galexie-architecture.png)
+![](/assets/galexie/galexie-architecture.png)
 
 ## Why XDR Format?
 

docs/learn/fundamentals/fees-resource-limits-metering.mdx

@@ -27,7 +27,7 @@ All smart contract transactions require a resource fee in addition to an inclusi
 
 `Transaction Fee (Tx.fee) = Resource Fee (sorobanData.resourceFee) + Inclusion Fee`
 
-![Soroban Fees](/assets/soroban_fees.png) _\* Diagram: Solid line boxes are what is actually present in the transaction, while dotted lines are derivable._
+![Soroban Fees](/assets/diagrams/soroban_fees.png) _\* Diagram: Solid line boxes are what is actually present in the transaction, while dotted lines are derivable._
 
 Smart contracts on Stellar use a multidimensional resource fee model that charges fees for several resource types using [network-defined rates](../../networks/resource-limits-fees.mdx). The resource fee is calculated based on the resource consumption declared in the transaction and can fluctuate based on a mutable storage write fee (more on that in the [Storage Dynamic Pricing section](#dynamic-pricing-for-storage) below). If the transaction attempts to exceed the declared resource limits, it will fail. If the transaction uses fewer resources than declared, there will be no refunds [(with a couple of exceptions)](#refundable-and-non-refundable-resource-fees).
 

docs/learn/fundamentals/stellar-stack.mdx

@@ -9,7 +9,7 @@ sidebar_position: 10
 
 The Stellar stack is made up of the following components: the networks (Mainnet, Testnet, and Futurenet), Stellar Core, Horizon API, RPC, and SDKs, each of which plays a specific part in providing financial infrastructure that is resilient to failures, available to anyone, and fast and cheap enough to serve real-world use cases.
 
-![Stellar Stack](/assets/stellar-tech-stack.png)
+![Stellar Stack](/assets/diagrams/stellar-tech-stack.png)
 
 ## Networks
 

docs/learn/migrate/evm/smart-contract-deployment.mdx

@@ -240,7 +240,7 @@ This will create a new Rust project called `vault`.
 
 Now let's add the `soroban_token_contract.wasm` file to the `vault` project. To do this, we can drag and drop the file into the `vault` project directory.
 
-![vault-project](/img/vault-project.png)
+![vault-project](/img/migrating/vault-project.png)
 
 Next, we'll need to add the Soroban SDK as a dependency. To do this, open the `Cargo.toml` file in your project and ensure that it matches the following:
 

docs/learn/migrate/evm/solidity-and-rust-basics.mdx

@@ -399,21 +399,21 @@ We can interact with the smart contract using the `Remix IDE`. To do so, follow
 
 2. Navigate to the `Counter.sol` file in the file explorer.
 
-![Counter](/img/counter.png)
+![Counter](/img/migrating/counter.png)
 
 3. Press `Ctrl/Cmd + s` to compile the contract.
 4. Navigate to the `Deploy & Run Transactions` tab and click the `Deploy` button.
 
-![Deploy](/img/deploy-counter.png)
+![Deploy](/img/migrating/deploy-counter.png)
 
 The contract should appear under the `Deployed Contracts` tab:
 
-![Deployed](/img/deployed-contracts.png)
+![Deployed](/img/migrating/deployed-contracts.png)
 
 5. Click the `increment` button to increment the counter.
 6. Click the `getCount` button to get the current count.
 
-![Increment](/img/increment.png)
+![Increment](/img/migrating/increment.png)
 
 Up to this point, we've covered the basics of writing, deploying to a sandbox EVM, and interacting with a simple smart contract using Solidity. In the following section, we will extend our knowledge by learning how to achieve the same outcomes using Rust.
 

docs/tools/developer-tools/jupyter-notebooks.mdx

@@ -67,7 +67,7 @@ Congratulations you have a Jupyter Notebook with contract code that should look
 
 ## Screenshot
 
-![A running Jupyter notebook](/assets/jupyter-notebooks.png)
+![A running Jupyter notebook](/assets/dev-tools/jupyter-notebooks.png)
 
 ## Community
 

docs/tools/developer-tools/openzepplin-contracts.mdx

@@ -9,7 +9,7 @@ To bring battle-tested smart contracts to the Stellar developer community, OpenZ
 
 ## Getting Started with Contract Wizard
 
-![Contract Wizard](/assets/openzeppelin-contract-wizard.png)
+![Contract Wizard](/assets/dev-tools/openzeppelin-contract-wizard.png)
 
 [OpenZeppelin's Contract Wizard](https://wizard.openzeppelin.com/stellar) includes support for Stellar’s Rust-based smart contracts, making it easier for developers to generate and deploy secure, audited contracts.Developers can leverage pre-built contract templates for:
 

docs/validators/admin-guide/configuring.mdx

@@ -249,7 +249,7 @@ Once you add validators to your configuration, stellar core automatically genera
 - The combined weight of `MEDIUM` quality entities equals a single `HIGH` quality entity
 - The combined weight of `LOW` quality entities equals a single `MEDIUM` quality entity
 
-![Diagram Automatic Quorum Set Generation](/assets/validator_complete.png)
+![Diagram Automatic Quorum Set Generation](/assets/diagrams/validator_complete.png)
 
 _Diagram: Depiction of the nested quality levels and how they interact._
 

docusaurus.config.ts

@@ -22,7 +22,7 @@ const config: Config = {
   onBrokenAnchors: "ignore",
   onBrokenLinks: "throw",
   onBrokenMarkdownLinks: "throw",
-  favicon: "img/favicon-96x96.png",
+  favicon: "img/docusaurus/favicon-96x96.png",
   organizationName: "stellar",
   projectName: "stellar-docs",
   i18n: {
@@ -126,12 +126,12 @@ const config: Config = {
         autoCollapseCategories: false,
       },
     },
-    image: 'img/dev-docs-preview.png',
+    image: 'img/docusaurus/dev-docs-preview.png',
     navbar: {
       logo: {
         width: 100,
-        src: "img/stellar-logo.svg",
-        srcDark: "img/stellar-logo-dark.svg",
+        src: "img/docusaurus/stellar-logo.svg",
+        srcDark: "img/docusaurus/stellar-logo-dark.svg",
         href: "/",
       },
       items: [

src/components/LanguageButtons.tsx

@@ -1,11 +1,11 @@
 import React from "react";
 import BrowserOnly from '@docusaurus/BrowserOnly';
 import {useColorMode} from '@docusaurus/theme-common';
-import Kotlin from '@site/static/img/kt.png';
-import KotlinDark from '@site/static/img/kt-dark.png';
-import Typescript from '@site/static/img/ts.png';
-import Flutter from '@site/static/img/flutter.png';
-import FlutterDark from '@site/static/img/flutter-dark.png';
+import Kotlin from '@site/static/img/docusaurus/kt.png';
+import KotlinDark from '@site/static/img/docusaurus/kt-dark.png';
+import Typescript from '@site/static/img/docusaurus/ts.png';
+import Flutter from '@site/static/img/docusaurus/flutter.png';
+import FlutterDark from '@site/static/img/docusaurus/flutter-dark.png';
 
 export const LanguageButtons = () => {
     const {colorMode} = useColorMode();