Add legacy docs (#42)

* allow non existing github

* legacy structure

* ported over

* fix grid

* fixed app layout from 5 columns to 5 rows.

---------

Co-authored-by: tonyboylehub <tony@tonyboyle.co.uk>

src/components/Hero.jsx

@@ -23,10 +23,10 @@ export function Hero({
     title: 'Get started',
     href: `/${page.product.path}/getting-started`,
   }
-  secondaryCta = secondaryCta ?? {
+  secondaryCta = secondaryCta ?? (page.product.github ? {
     title: 'View on GitHub',
     href: page.product.github,
-  }
+  } : undefined);
 
   return (
     <div className="overflow-hidden bg-neutral-900 dark:-mb-32 dark:mt-[-7rem] dark:pb-32 dark:pt-[7rem] dark:lg:mt-[-7.25rem] dark:lg:pt-[7.25rem]">
@@ -63,9 +63,11 @@ export function Hero({
               )}
               <div className="mt-8 flex gap-4 md:justify-center lg:justify-start">
                 <Button href={primaryCta.href}>{primaryCta.title}</Button>
-                <Button href={secondaryCta.href} variant="secondary">
-                  {secondaryCta.title}
-                </Button>
+                {secondaryCta &&
+                  <Button href={secondaryCta.href} variant="secondary">
+                    {secondaryCta.title}
+                  </Button>
+                }
               </div>
             </div>
           </div>

src/components/products/Grid.jsx

@@ -36,7 +36,7 @@ export function MarkdocGrid() {
   return (
     <div className="not-prose">
       <Grid
-        className="relative md:grid-flow-col md:grid-cols-2 md:grid-rows-4"
+        className="relative md:grid-flow-col md:grid-cols-4 md:grid-rows-4"
         withoutFallback
       />
     </div>

src/components/products/GridAllProducts.jsx

@@ -34,7 +34,7 @@ export function MarkdocGrid() {
   return (
     <div className="not-prose">
       <Grid
-        className="relative md:grid-flow-col md:grid-cols-2 md:grid-rows-4"
+        className="relative md:grid-flow-col md:grid-cols-3 md:grid-rows-5"
         withoutFallback
       />
     </div>

src/components/products/MobileAppGrid.jsx

@@ -52,7 +52,7 @@ export function MarkdocGrid() {
   return (
     <div className="not-prose">
       <Grid
-        className="relative md:grid-flow-col md:grid-cols-2 md:grid-rows-4"
+        className="relative md:grid-flow-col md:grid-cols-4 md:grid-rows-4"
         withoutFallback
       />
     </div>

src/components/products/SwitcherPopover.jsx

@@ -21,7 +21,7 @@ export function SwitcherPopover({ children, menuItem, ...props }) {
               className="m-auto w-full max-w-[600px]  overflow-hidden  rounded-lg bg-white p-4 shadow-xl ring-1 ring-black ring-opacity-5 dark:border dark:border-slate-600 dark:bg-neutral-900"
             >
               <Grid
-                className="relative md:grid-flow-row md:grid-cols-2"
+                className="relative md:grid-flow-row md:grid-cols-4"
                 onClick={close}
                 menuItem={menuItem}
               />

src/components/products/index.js

@@ -10,6 +10,7 @@ import { toolbox } from './toolbox'
 import { umi } from './umi'
 import { amman } from './amman'
 import { das } from './das-api'
+import { legacyDocumentation } from './legacyDocumentation'
 
 
 export const products = [
@@ -24,5 +25,6 @@ export const products = [
   inscription,
   umi,
   amman,
-  das
+  das,
+  legacyDocumentation
 ].sort((a, b) => a.name.localeCompare(b.name))

src/components/products/legacyDocumentation/Hero.jsx

@@ -0,0 +1,8 @@
+import { Hero as BaseHero } from '@/components/Hero'
+import { HeroCode } from '@/components/HeroCode'
+
+export function Hero({ page }) {
+  return (
+    <></>
+  )
+}

src/components/products/legacyDocumentation/index.js

@@ -0,0 +1,110 @@
+import {
+  changelogSection,
+  documentationSection,
+  recipesSection,
+  referencesSection,
+} from '@/shared/sections'
+import { Hero } from './Hero'
+import { Logo } from './Logo'
+
+export const legacyDocumentation = {
+  name: 'Legacy',
+  headline: 'Products from our old docs',
+  description: 'A collection of documentation of older Programs and Tools which might not be used anymore or deprecated. Migrated from our old docs for documentation for completeness.',
+  path: 'legacy-documentation',
+  logo: Logo,
+  github: '',
+  className: 'accent-green',
+  sections: [
+    {
+      ...documentationSection('legacy-documentation'),
+      navigation: [
+        {
+          title: 'Auction House',
+          links: [
+            { title: 'Overview', href: '/legacy-documentation/auction-house' },
+            { title: 'Getting Started', href: '/legacy-documentation/auction-house/getting-started' },
+            { title: 'Auction House Settings', href: '/legacy-documentation/auction-house/settings' },
+            { title: 'Managing Auction Houses', href: '/legacy-documentation/auction-house/manage' },
+            { title: 'Trading Assets', href: '/legacy-documentation/auction-house/trading-assets' },
+            { title: 'Managing Buyer Escrow Account', href: '/legacy-documentation/auction-house/buyer-escrow' },
+            { title: 'Auction House Receipts', href: '/legacy-documentation/auction-house/receipts' },
+            { title: 'Finding Bids, listings, sales', href: '/legacy-documentation/auction-house/find' },
+            { title: 'How to manage Auction House using CLI', href: '/legacy-documentation/auction-house/manage-using-cli' },
+            { title: 'Timed Auctions with Auctioneers', href: '/legacy-documentation/auction-house/auctioneer' },
+            { title: 'FAQ', href: '/legacy-documentation/auction-house/faq' },
+          ],
+        },
+        {
+          title: 'Developer Tools',
+          links: [
+            {
+              title: 'Solita',
+              href: '/legacy-documentation/developer-tools/solita',
+            },
+            {
+              title: 'Shank',
+              href: '/legacy-documentation/developer-tools/shank',
+            },
+            {
+              title: 'Beet',
+              href: '/legacy-documentation/developer-tools/beet',
+            },
+            {
+              title: 'Cusper',
+              href: '/legacy-documentation/developer-tools/cusper',
+            },
+            {
+              title: 'Rust Bin',
+              href: '/legacy-documentation/developer-tools/rust-bin',
+            },
+          ],
+        },
+        {
+          title: 'Fixed Price Sale',
+          links: [
+            {
+              title: 'Introduction',
+              href: '/legacy-documentation/fixed-price-sale',
+            },
+            {
+              title: 'Overview',
+              href: '/legacy-documentation/fixed-price-sale/tech-description',
+            },
+          ],
+        },
+        {
+          title: 'Gumdrop',
+          links: [
+            {
+              title: 'Overview',
+              href: '/legacy-documentation/gumdrop',
+            },
+          ],
+        },
+        {
+          title: 'Mobile SDKs',
+          links: [
+            {
+              title: 'Android SDK',
+              href: '/legacy-documentation/mobile-sdks/android',
+            },
+            {
+              title: 'iOS SDK',
+              href: '/legacy-documentation/mobile-sdks/ios',
+            },
+          ],
+        },
+        {
+          title: 'Token Entangler',
+          links: [
+            {
+              title: 'Overview',
+              href: '/legacy-documentation/token-entangler',
+            },
+          ],
+        },       
+      ],
+    },
+  ],
+}

src/pages/legacy-documentation/auction-house/auctioneer.md

@@ -0,0 +1,24 @@
+---
+title: Timed Auction using Auctioneer
+metaTitle: Auction House - Timed Auction using Auctioneer
+description: Explains how to manage timed Auctions using Auctioneer.
+---
+
+The Timed Auction Auctioneer is an Auctioneer implementation that adds English-style auction rules built on top of Auction House.
+
+# Listing Config
+The listing config struct is used to store all feature-related parameters attached to each listing. All features can be configured on a per-listing basis.
+
+# Features
+* English Auction with start and end dates
+* Highest bid tracking
+* Reserve price (Minimum Bid)
+* Minimum Bid Increment - Require new bidders to bid a certain amount more than the current bid
+* Automatic Time Extension - Bids made close to the end of an auction (this period is customizable) will extend the auction end date a configurable amount
+* Prevent Highest Bidder cancellation - The highest bidder won't be able to cancel their bid and are required to purchase the NFT if they win*
+
+{% callout type="warning" %}
+
+*Due to Auction House's escrowless nature, it is unable to prevent users from transferring listed tokens from their wallets and nullifying their bids at this time.
+
+{% /callout %}

src/pages/legacy-documentation/auction-house/buyer-escrow.md

@@ -0,0 +1,103 @@
+---
+title: Manage Buyer Escrow Accounts
+metaTitle: Auction House - Manage Buyer Escrow Accounts
+description: "Explains how to manage Buyer Escrow Accounts."
+---
+## Introduction
+
+In the previous page we discussed how to make bids and listings, and execute sales of assets. When we talked about execution of sales, we briefly mentioned the **Buyer Escrow Account**. What is the utility of this account and why do we need to talk about it?
+
+This account is a program derived address (PDA) that acts as an escrow, by temporarily holds the bidder's funds (SOL or SPL-tokens). These funds are equal to the bidding price and are stored in this PDA until the sale goes through. When the sale is executed, the Auction House transfers these funds from the buyer escrow account PDA to the seller's wallet.
+
+Now the question is: are these funds automatically transferred from the bidder's wallet to the buyer escrow account when the bid is made?
+
+The answer is no. That is the very reason why we need to talk about managing the buyer escrow account and the funds in them. These funds are managed by the Auction House authority. Let us see how we the authority manages this account.
+
+## Getting Balance
+
+Adding to the discussion in the previous section, it is the responsibility of the Auction House to make sure that there are enough funds in the buyer escrow account, for the sale to go through. 
+
+To do so, firstly the Auction House should know how much funds are currently there in the buyer escrow account.
+
+{% dialect-switcher title="JS SDK" %}
+{% dialect title="JavaScript" id="js" %}
+
+Here's a code snippet that fetches the balance of the buyer escrow account for a given Auction House.
+
+```tsx
+import { Keypair } from "@solana/web3.js";
+
+const buyerBalance = await metaplex
+    .auctionHouse()
+    .getBuyerBalance({
+        auctionHouse,
+        buyerAddress: Keypair.generate() // The buyer's address
+    });
+```
+
+{% /dialect %}
+{% /dialect-switcher %}
+
+## Deposit Funds
+
+At this point, the Auction House knows how much funds are currently there in the buyer escrow account corresponding to a user.
+
+Now if this user makes a bid on an asset, Auction House can decide to transfer funds from the user's wallet to the buyer escrow account in case of insufficient funds.
+
+{% dialect-switcher title="JS SDK" %}
+{% dialect title="JavaScript" id="js" %}
+
+Let us see how funds can be transferred from the buyer's wallet to the buyer escrow account for an Auction House.
+
+```tsx
+import { Keypair } from "@solana/web3.js";
+
+const depositResponse = await metaplex
+    .auctionHouse()
+    .depositToBuyerAccount({
+        auctionHouse,              // The Auction House in which escrow
+                                   // buyer deposits funds. We only need a subset of
+                                   // the `AuctionHouse` model but we need
+                                   // enough information regarding its
+                                   // settings to know how to deposit funds.
+        buyer: metaplex.identity() // The buyer who deposits funds. This expects a Signer
+        amount: 10                 // Amount of funds to deposit. This can either
+                                   // be in SOL or in the SPL token used by
+                                   // the Auction House as a currency.
+    });
+```
+
+{% /dialect %}
+{% /dialect-switcher %}
+
+## Withdraw Funds
+
+The Auction House should also be able to withdraw funds back from the buyer escrow wallet to the buyer's wallet, in case the user wants their funds back and / or have cancelled their bid.
+
+{% dialect-switcher title="JS SDK" %}
+{% dialect title="JavaScript" id="js" %}
+
+Let us see how funds can be withdrawn from the buyer escrow wallet to the buyer's wallet for the given Auction House.
+
+```tsx
+import { Keypair } from "@solana/web3.js";
+
+const withdrawResponse = await metaplex
+    .auctionHouse()
+    .withdrawFromBuyerAccount({
+        auctionHouse,              // The Auction House from which escrow buyer withdraws funds
+        buyer: metaplex.identity() // The buyer who withdraws funds
+        amount: 10                 // Amount of funds to withdraw. This can either
+                                   // be in SOL or in the SPL token used by
+                                   // the Auction House as a currency.
+    });
+```
+
+{% /dialect %}
+{% /dialect-switcher %}
+
+## Conclusion
+
+Now that we have also discussed how to manage the funds in the buyer escrow account, we are very close to be able to fully launch and control our own marketplace.
+
+One important piece of information currently missing: how does a marketplace keep track of the listings, bids and sales? The Auction House program has something in the store for doing this, namely [Receipts](receipts).

src/pages/legacy-documentation/auction-house/faq.md

@@ -0,0 +1,56 @@
+---
+title: FAQ
+metaTitle: Auction House - FAQ
+description: "FAQ for Auction House"
+---
+
+## Can I get fees when NFTs get sold-on my Auction House?
+Yes, An Auction House may be configured to take `seller fee basis points`. This is part of the create and update command; see the CLI use it.
+
+Fees are paid to Creators,Then the Auction house and the seller gets the remainder of the sale. This is easy to calculate on your UI by taking the NFT royalties, Sale price, Auction House fee and displaying to the buyer what their total gains will be.
+
+## Does the Auction House restrict the user from selling their NFT on another Non-Auction House marketplace?
+No, the Auction House cannot stop users from sending their NFT even if they have a for-sale listing. If this happens, the `execute_sale` operation will fail and the buyer can get their funds back by canceling their bid.
+Marketplaces creating an Auction House experience will need to track the Buy/Sell trade state accounts and watch the TokenAccounts of sellers, so they can automatically cancel the listing and bids on NFTs that have been transferred from the original seller.
+
+Specifically Marketplaces should currently store:
+
+1. Trade Stade Account Keys
+2. Trade State Token Size and Price parts of the seed
+3. Token Account Keys that are stored in the trade state
+4. Auction House Receipts (Listing Receipts, Bid Receipts, and Purchase Receipts)
+
+Specifically Marketplaces need to track these two events on Token Accounts:
+
+1. Ownership has changed from the original Seller of the NFT
+2. Token Account Amount has changed to 0
+
+If these events happen the Auction House Authority can call instructions to cancel the bids and listings without the seller or buyer needing to be present.
+
+## Can people view the settings of my Auction House?
+Yes anyone can and should be able to verify the settings of your Auction House especially the `Can Change Sale Price` parameter.
+This can be done on the CLI with the `show` command.
+
+
+## Can the Auction House change the sale price on my NFT?
+Yes, but only in a certain scenario. The following conditions are required in order for an Auction House to be able to use this feature:
+
+1. The Auction House instance must have `Can Change Sale Price` set to `true`
+2. The NFT seller must list the NFT for sale at a price of 0. 
+
+{% callout type="warning" %}
+The Auction House can only sell it for 0 if you sign the transaction with your key, but currently it can sell it for an arbitrarily low price, e.g. 1 lamport. It is important to only list with Auction Houses you trust.
+{% /callout %}
+
+3. The Auction House now can use the `0` priced trade state you made in #2 to create new `sale` listings at different prices. 
+
+
+## What's the difference between public and private bids?
+A standard bid, also called a private bid, refers to a bid made that's specific to an auction. When the auction is complete the bid can be canceled and the funds in escrow returned to the bidder. However, Auction House also supports public bids which are specific to the token itself and not to any specific auction. This means that a bid can stay active beyond the end of an auction and be resolved if it meets the criteria for subsequent auctions of that token.
+
+Example:
+1. Alice places a public bid on Token A for 1 SOL.
+2. Bob also bids on Token A for 2 SOL.
+3. Bob wins the auction and becomes the new owner of Token A.
+4. A week later, Bob places Token A for auction but no one new places a bid.
+5. Because Alice never canceled her public bid, hers is the sold bid on the new auction of Token A, and she wins the auction.

src/pages/legacy-documentation/auction-house/find.md

@@ -0,0 +1,142 @@
+---
+title: Find bids, listings and sales
+metaTitle: Auction House - Find
+description: "Explains how to find bids, listings and sales."
+---
+## Introduction
+
+In the previous page we saw how to make receipts for bids, listings and sales. These receipts make it easier for the marketplace operators to keep track of these actions. But how does one fetch these bids, listings and sales?
+
+There are three types of functions provided for fetching bids, listings and sales:
+
+1. **Find all in an auction house**: using this type of function, all bids / listings / sales can be found for a given Auction House.
+
+2. **Find by receipt**: using this type of function, a single bid / listing / sale can be found, given the address of the corresponding receipt account.
+
+3. **Find by trade state**: We talked about [Trade States in the overview page](/programs/auction-house/overview). Trade state PDA accounts encoding the bid / listing / sale orders can also be used to find the corresponding action.
+
+### Find All in an Auction House
+
+There are multiple criteria to find all bids, listings and sales (or *purchases*) in an Auction House.
+
+{% dialect-switcher title="JS SDK" %}
+{% dialect title="JavaScript" id="js" %}
+
+Below is the snippet for finding bids by multiple criteria. You can use any combination of keys.
+     
+```tsx
+// Find all bids in an Auction House.
+const bids = await metaplex
+  .auctionHouse()
+  .findBids({ auctionHouse });
+
+// Find bids by buyer and mint.
+const bids = await metaplex
+  .auctionHouse()
+  .findBids({ auctionHouse, buyer, mint });
+
+// Find bids by metadata.
+const bids = await metaplex
+  .auctionHouse()
+  .findBids({ auctionHouse, metadata });
+```
+
+Here's a snippet for finding listings by multiple criteria. Again, you can use any combination of keys.
+
+```tsx
+// Find all listings in an Auction House.
+const listings = await metaplex
+  .auctionHouse()
+  .findListings({ auctionHouse });
+
+// Find listings by seller and mint.
+const listings = await metaplex
+  .auctionHouse()
+  .findListings({ auctionHouse, seller, mint });
+```
+
+Below is a snippet for finding purchases by multiple criteria. It supports only 3 criteria at the same time including the required `auctionHouse` attribute.
+
+```ts
+// Find all purchases in an Auction House.
+const purchases = await metaplex
+  .auctionHouse()
+  .findPurchases({ auctionHouse });
+
+// Find purchases by buyer and mint.
+const purchases = await metaplex
+  .auctionHouse()
+  .findPurchases({ auctionHouse, buyer, mint });
+
+// Find purchases by metadata.
+const purchases = await metaplex
+  .auctionHouse()
+  .findPurchases({ auctionHouse, metadata });
+
+// Find purchases by seller and buyer.
+const purchases = await metaplex
+  .auctionHouse()
+  .findPurchases({ auctionHouse, seller, buyer });
+```
+
+{% /dialect %}
+{% /dialect-switcher %}
+
+### Find by Receipt
+
+Below is the snippet for finding bids, listings and sales by corresponding receipt acccount address.
+
+{% dialect-switcher title="JS SDK" %}
+{% dialect title="JavaScript" id="js" %}
+     
+```tsx
+// Find a bid by receipt
+const nft = await metaplex
+  .auctionHouse()
+  .findBidByReceipt({ receiptAddress, auctionHouse };
+
+// Find a listing by receipt
+const nft = await metaplex
+  .auctionHouse()
+  .findListingByReceipt({ receiptAddress, auctionHouse };
+
+// Find a sale / purchase by receipt
+const nft = await metaplex
+  .auctionHouse()
+  .findPurchaseByReceipt({ receiptAddress, auctionHouse };
+```
+
+{% /dialect %}
+{% /dialect-switcher %}
+
+### Find by Trade State
+Below is the snippet for finding bids, listings and sales by corresponding trade state PDA accounts.
+
+{% dialect-switcher title="JS SDK" %}
+{% dialect title="JavaScript" id="js" %}
+     
+```tsx
+// Find a bid by trade state
+const nft = await metaplex
+  .auctionHouse()
+  .findBidByTradeState({ tradeStateAddress, auctionHouse };
+
+// Find a listing by trade state
+const nft = await metaplex
+  .auctionHouse()
+  .findListingByTradeState({ tradeStateAddress, auctionHouse };
+
+// Find a sale / purchase by trade state
+const nft = await metaplex
+  .auctionHouse()
+  .findPurchaseByTradeState({ sellerTradeState, buyerTradeState, auctionHouse };
+```
+
+{% /dialect %}
+{% /dialect-switcher %}
+
+## Conclusion
+
+We have finally covered all corners for managing trading on a marketplace. Everything covered till now was explained using code snippets using the JS SDK. 
+
+Next up we'll see how one can create and manage Auction Houses and the trading on them [using CLI](/programs/auction-house/how-to-guides/manage-auction-house-using-cli).

src/pages/legacy-documentation/auction-house/getting-started.md

@@ -0,0 +1,76 @@
+---
+title: Getting Started
+metaTitle: Auction House - Getting Started
+description: Lists the various libraries and SDKs you can use to manage Auction Houses.
+---
+
+The Auction House is a Solana program running on Mainnet Beta and Devnet. While you may interact with it like any other Solana program by sending transactions to a Solana node, Metaplex has built some tools to make working with it much easier. We have a **CLI** tool that will let you manage your auction house and a **JS SDK** to help you kick-start a user interface.
+
+## SDKs
+
+### JavaScript SDK
+The **JS SDK** provides an easy-to-use API to web developers to create and configure one's own Auction House. The SDK also allows developers to perform complicated procedures like bidding, listing, withdrawing funds from the Auction House treasury and fee accounts, and much more. 
+
+The main module that interacts with the Auction House program is the [Auction House module](https://github.com/metaplex-foundation/js/tree/main/packages/js/src/plugins/auctionHouseModule). This module contains several methods that make the process of making marketplaces painless. You may access this client via the `auctionHouse()` method of your `Metaplex` instance.
+```ts
+const auctionHouseClient = metaplex.auctionHouse();
+```
+
+{% dialect-switcher title="JS SDK" %}
+{% dialect title="JavaScript" id="js" %}
+
+Here are some of the useful methods provided by the SDK:
+
+```ts
+// Creating and updating the Auction House
+metaplex.auctionHouse().create();
+metaplex.auctionHouse().update();
+
+// Trading on Auction House
+metaplex.auctionHouse().bid();
+metaplex.auctionHouse().list();
+metaplex.auctionHouse().executeSale();
+
+// Cancelling a bid or listing
+metaplex.auctionHouse().cancelBid();
+metaplex.auctionHouse().cancelListing();
+
+// Finding bids, listings and purchases
+metaplex.auctionHouse().findBidBy();
+metaplex.auctionHouse().findBidByTradeState();
+metaplex.auctionHouse().findListingsBy();
+metaplex.auctionHouse().findListingByTradeState();
+metaplex.auctionHouse().findPurchasesBy();
+```
+
+{% /dialect %}
+{% /dialect-switcher %}
+
+
+There are also other methods that already exist in the Auction House module, and more methods will be added in the future. The *README* of the Auction House module will be updated with a detailed documentation of all these methods very soon.
+
+**Helpful links:**
+* [Github repository](https://github.com/metaplex-foundation/js/tree/main/packages/js/src/plugins/auctionHouseModule)
+* [NPM package](https://www.npmjs.com/package/@metaplex-foundation/js)
+
+## Program Libraries
+Program Libraries are auto-generated from the Program’s IDL using Solita. Whilst they require you to understand Solana programs and wire your own instructions, they have the advantage of immediately using the latest features when SDKs might take a bit longer to implement them.
+
+### JavaScript Program Libraries
+This is a lower level, auto-generated JavaScript library, which gets generated whenever the Auction House program (written in Rust) gets updated. 
+
+Therefore, this library is intended for advanced developers who wish to interact with the program by preparing instructions and sending transactions directly.
+
+**Helpful links:**
+* [Github repository](https://github.com/metaplex-foundation/metaplex-program-library/tree/master/auction-house/js)
+* [NPM package](https://www.npmjs.com/package/@metaplex-foundation/mpl-auction-house)
+
+## Rust Crates
+If you are developing in Rust, you can also use the Rust crates to interact with Metaplex’s programs. Since our programs are written in Rust, theses crates should contain everything you need to parse accounts and build instructions.
+
+This can be helpful when developing Rust clients but also when making CPI calls to Metaplex programs within your own program.
+
+**Helpful links:**
+* [Github repository](https://github.com/metaplex-foundation/metaplex-program-library/tree/master/auction-house/program)
+* [Crate page](https://crates.io/crates/mpl-auction-house)
+* [API references](https://docs.rs/mpl-auction-house/latest/mpl_auction_house/)

src/pages/legacy-documentation/auction-house/index.md

@@ -0,0 +1,164 @@
+---
+title: Overview
+metaTitle: Auction House - Overview
+description: Gives an overview of the Auction House program
+---
+
+
+{% callout type="warning" %}
+
+Please note that this program is marked as deprecated and is no longer actively maintained by the Metaplex Foundation team. New features, security fixes and backward compatibility are not guaranteed. Please use with caution.
+
+{% /callout %}
+
+## Introduction
+
+Auction House is a program that allows users to exchange assets within the Solana blockchain.
+
+There are plenty of ways to exchange assets on Solana, so why another program focused on solving this problem? Let's dive deep into that.
+
+The ethos of this program is to allow anyone to create and configure their own marketplace and even provide their own custom logic on how assets should be exchanged. The motivation behind the Auction House protocol is to create a healthy ecosystem of marketplaces that focus on different use-cases, and more importantly, each bringing their own flavor into the way they allow users to trade assets.
+
+The most important aspect of the Auction House program is that it provides ownership of assets to the user.
+
+Traditionally, as soon as the user lists an asset on a marketplace, the asset is moved from the user's wallet into a wallet known as the [Escrow](https://www.investopedia.com/terms/e/escrow.asp) wallet owned by the marketplace and is kept or **escrowed** there until the asset is delisted or sold. This poses some concerns:
+
+- The user can not list the same asset on multiple marketplaces
+- The user has to rely on the marketplaces’ escrow contracts to safely hold their asset.
+
+This is where Auction House shows its power. Its a transaction protocol that allows marketplaces to implement an **escrow-less** sales contract, thus providing ownership of assets to the users.
+
+## Creating an Auction House
+
+The Auction House program can be used to create a new marketplace by instantiating a new **Auction House** account. The Auction House account is a [Program Derived Address (PDA)](../../understanding-programs#program-derived-addresses-pda) which is derived from a given public key and, optionally, an SPL Token to use a currency (more on that below).
+
+   ![Properties.PNG](https://i.imgur.com/2HPpM9g.png#radius)
+
+
+The account can be configured in whichever way the user wants. We'll talk [more about these configurations in a dedicated page](settings) but here are some interesting configurable parameters:
+
+- `requireSignOff`: this allows marketplaces to gate which assets can be listed and which bids can be placed. On every relevant instruction, the Auction House [authority](https://docs.solana.com/staking/stake-accounts#understanding-account-authorities) needs to sign the transaction.
+- `canChangeSalePrice`: this parameter is only intended to be used on Auction Houses with `requireSignOff` set to `true`. This allows the Auction House to perform custom order matching to find the best price for the seller.
+- `sellerFeeBasisPoints`: this represents the share the marketplace takes on all trades. For instance, if this is set to `200`, i.e. 2%, then the marketplace takes 2% of every single trade that happens on their platform.
+
+## Listing and Bidding
+
+Once we have an active Auction House, users can start listing assets and bidding on assets on the marketplace.
+
+### Listing
+
+When a user lists an asset, the Auction House does two things:
+
+1. Auction House creates a **Sell Order**: in other words, creates a PDA known as the `SellerTradeState` which represents the listing of the asset. Trade States are special PDAs that are very cheap in comparison to other PDAs / Accounts. This is because these PDAs only store 1 byte of data, which is the [bump](https://solanacookbook.com/core-concepts/pdas.html#generating-pdas) of the PDA. All other information related to listings such as list price, amount of tokens, mint account etc, are hashed into the seeds of the PDA, instead of storing them inside the PDA itself, and therefore the PDA acts as a "proof of existence" for that listing, while being extremely cost efficient.
+
+![](https://i.imgur.com/ki27Ds8.png#radius)
+
+2. Auction House also assigns another PDA: `programAsSigner` PDA as the **Delegate**. Delegates are a feature of the Solana SPL-token program and are discussed in detail [here](https://spl.solana.com/token#authority-delegation). Delegation allows the Auction House to pull assets out of a token account when a sale goes through at a later point. This way, the asset need not be escrowed and can stay in the user's wallet up until the sale goes through.
+
+![](https://i.imgur.com/aIRl7Hb.png#radius)
+
+### Bidding
+
+Similar to the case of listing, when a user places a bid, the Auction House creates a **Buy Order**. In other words, it creates the `BuyerTradeState` PDA representing the bid. The bid amount (native or SPL tokens) needs to be transferred manually by the marketplace to the `BuyerEscrowAccount` PDA, which holds this amount till the sale goes through.
+
+> Example:
+>
+> - Alice lists an asset A for 5 SOL. In doing so, the Auction House creates the `SellerTradeState` PDA representing the bid. The Auction House also assigns the `programAsSigner` PDA as the **Delegate**, hence giving it the **Authority** to pull the asset from Alice's wallet when the sale goes through.
+> - Bob places a bid of 5 SOL on asset A. In doing so, the marketplace pulls 5 SOL from Bob's wallet to the `BuyerEscrowAccount` PDA. This amount will stay here up until the sale goes through.
+
+## Executing a Sale
+
+Once we have a listing and at least one bid placed for a given asset, a trade can be completed by calling the `executeSale` instruction.
+
+The `executeSale` instruction is a permission-less crank: in other words, can be executed by anyone without any fee or reward. On the execution of the `executeSale` instruction, two things happen:
+
+- The Auction House pulls the bid amount stored in the `BuyerEscrowAccount` and transfers this amount to the lister (minus Auction House fees).
+- The `programAsSigner` PDA, which the Auction House assigned as the **Delegate**, pulls the asset from the lister's wallet (more specifically, from the Token Account in the lister's wallet), and transfers the asset into the bidder's wallet, thus completing the trade.
+  ![](https://i.imgur.com/gpAX63m.png#radius)
+
+Now that we know how the `executeSale` instruction works, let's discuss the three trade scenarios in which the `executeSale` instruction is executed in different ways:
+
+1. _"Buying" at list price_: This is the case when a user places a bid for a listed asset, at the listed amount itself. In such cases, the `bid` and the `executeSale` instructions are executed in the same transaction, and thus the bidder effectively "buys" the asset.
+
+> Example:
+>
+> - Alice lists an asset A for 5 SOL. This creates a **Sell Order** for asset A.
+> - Bob notices the listing and places a bid of 5 SOL for the asset A. This creates a **Buy Order** for asset A.
+> - This enables the marketplace to place a bid on the asset and execute the sale in the same transaction, in practice allowing Bob to "buy" asset A.
+
+2. _"Selling" at bid price_: This is the case when a user, interested in an unlisted asset, places a bid on it. If the asset owner now lists the asset for the bid amount, the `list` and the `executeSale` instructions are executed in the same instruction, and thus the lister effectively "sells" the asset at the requested price.
+
+> Example:
+>
+> - Bob places a bid of 5 SOL for an unlisted asset A. This creates a **Buy Order** for asset A.
+> - Alice notices the bid and lists the asset A for 5 SOL. This creates a **Sell Order** for asset A.
+> - This enables the marketplace to list the asset and execute the sale in the same transaction, in practice allowing Alice to "sell" asset A.
+
+3. _Lister agreeing to a bid_: This is the case when the `executeSale` instruction is executed independently, after a **Buy Order** and a **Sell Order** exist for a given asset.
+
+> Example:
+>
+> - Alice lists an asset A for 5 SOL. This creates a **Sell Order** for asset A.
+> - Bob places a bid of 5 SOL for asset A, unaware of Alice's listing. This creates a **Buy Order** for asset A.
+> - Alice notices the matching bid and executes the sale.
+
+## Auctioning Fungible Assets
+
+So far, we've talked about exchanging assets using an Auction House account, but we've not dug into what type of assets can be exchanged that way. The most popular assets that can be listed in an Auction House are [Non-Fungible Tokens (NFTs)](/token-metadata/token-standard#the-non-fungible-standard).
+
+However, these are not the only assets that can benefit from the Auction House program. In fact, an asset can be any SPL Token so long as it has a Metadata account attached to its Mint account. If you'd like to know more about SPL Token and Metadata accounts, you can [read more about this in the overview of our Token Metadata program](/token-metadata).
+
+## Buying asset using a custom SPL Token
+
+In the examples showcased above, we've used SOL as the exchange currency to discuss how the Auction House program works. But SOL is not the only currency that can be configured for exchanging assets. The Auction House program allows marketplaces to configure any SPL-token to act as their currency.
+
+This can be achieved by setting the `treasuryMint` parameter in the Auction House account to the mint account of the SPL-token of your liking.
+
+## Custom Order Matching
+
+When we were discussing Trade States, there was a third Trade State which was shown in the Trade State diagram: the `FreeSellerTradeState`. What's the utility of this Trade State?
+
+During the introduction to the Auction House program, we briefly discussed how Auction House can be used by marketplaces to provide their own custom logic on how assets should be exchanged. This is where the `FreeSellerTradeState` comes in.
+
+When a buyer intentionally lists their asset for a price of 0 SOL / SPL-tokens, the `FreeSellerTradeState` is generated. The Auction House can then change the sale price to match a matching bid that is greater than 0. This allows the Auction House to do complicated order matching to find the best price for the seller and the marketplaces can write their own custom logic to do this order matching.
+
+## Auctioneer
+
+All of the auctions we've seen so far have one thing in common. They are, what we call, [**Double Auctions**](https://blogs.cornell.edu/info2040/2021/11/29/four-common-types-of-auctions/#:~:text=sealed%2Dbid%20auction.-,DOUBLE%20AUCTION,-Both%20buyers%20and). That is, they are un-timed auctions where buyers and sellers, bid and list until they find a common ground.
+However, there are several other forms of auctions such as English auctions and Dutch auctions which have become popular in the Solana ecosystem.
+The Auction House implementation is purposefully designed with instant sales in mind and does not offer other auction types out-of-the-box.
+
+**Auctioneer** is a customized contract type, written by the user, that uses the composability pattern of Auction House to control an individual Auction House account.
+
+To enable an Auctioneer instance on an Auction House, it must first be explicitly delegated. This Auctioneer instance will then be able to intercept most of the Auction House instructions in order to inject its own custom logic. Metaplex also provides some Auctioneer implementations like Timed Auctions. We will talk about this in greater detail in later pages of this documentation.
+
+![](https://i.imgur.com/RyZUfR9.png#radius)
+
+## Next steps
+
+On this page, we have gone through the very basics of the Auction House protocol and the power it possesses. There is a lot more that the Auction House is capable of.
+
+We'll start by listing various libraries that can be used to get started with this program:
+
+- [Getting Started](auction-house/getting-started)
+
+We will proceed to dive deeper into the Auction House settings and how to manage Auction House instances:
+
+- [Auction House Settings](auction-house/settings)
+- [Managing Auction Houses](auction-house/manage)
+
+Once we understand the basics of Auction House, we can begin to learn how to trade assets on Auction House powered marketplaces:
+
+- [Trading assets on Auction House](auction-house/trading-assets)
+- [Managing Buyer Account](auction-house/buyer-escrow)
+
+We will also explore how to track listings, bids and sales on Auction Houses and how to fetch them:
+
+- [Printing Receipts](auction-house/receipts)
+- [Finding bids, listings and purchases](auction-house/find)
+
+## Additional Reading Material
+
+- [Prof Lupin's Auction House guide](https://proflupin.xyz/metaplex-auction-house)
+- [Jordan's twitter thread](https://twitter.com/redacted_j/status/1453926144248623104)
+- [Armani's twitter thread](https://twitter.com/armaniferrante/status/1460760940454965248)

src/pages/legacy-documentation/auction-house/manage-using-cli.md

@@ -0,0 +1,259 @@
+---
+title: Manage Auction House using CLI
+metaTitle: Auction House - Manage using CLI
+description: "How to manage Auction House using CLI"
+---
+
+## Prerequisites
+
+- `ts-node`
+- `git`
+- `yarn`
+
+## Setup
+
+In order to get started with the Auction House CLI please follow these steps.
+
+```sh
+git clone https://github.com/metaplex-foundation/metaplex-program-library.git
+cd auction-house/cli
+```
+Note: By default you will be using the latest code on the tip of the `main` branch.
+
+Then:
+```sh
+cd js && yarn install && yarn bootstrap
+cd src
+```
+
+Once you have cloned the repo and installed packages, make sure you have a local `Keypair` setup. If you need help with that see these guides.
+
+- https://docs.solana.com/cli/install-solana-cli-tools
+- https://docs.solana.com/wallet-guide/file-system-wallet
+
+## Running Commands
+
+To run commands you will use
+`ts-node auction-house-cli.ts`
+
+### Help
+
+```
+ts-node auction-house-cli.ts
+Usage: auction-house-cli [options] [command]
+
+Options:
+-V, --version                     output the version number
+-h, --help                        display help for command
+
+Commands:
+show_escrow [options]
+withdraw [options]
+sell [options]
+withdraw_from_treasury [options]
+withdraw_from_fees [options]
+cancel [options]
+execute_sale [options]
+buy [options]
+deposit [options]
+show [options]
+create_auction_house [options]
+update_auction_house [options]
+help [command]                    display help for command
+
+```
+
+### Create
+
+Creates an Auction House
+
+See the command help with
+
+```
+ts-node auction-house-cli.ts help create_auction_house
+```
+
+Find your current Keypair, lets say it lives at `~/mywallet.key` or on Windows `C:\Users\windowsuser\mywallet.key`. To create an Auction House you will run.
+
+```
+ts-node auction-house-cli.ts create_auction_house --keypair ~/mywallet.key -e devnet -sfbp 1000 -ccsp false -rso false
+```
+
+In this case we don't need to require sign-off because we want to make a fully decentralized auction house. Since we did not specify `-tm, --treasury-mint <string>` The currency for payment will be SOL.
+Also, the options below will default to being set as the public key of `~/mywallet.key`
+
+```
+-twd, --treasury-withdrawal-destination <string>
+-fwd, --fee-withdrawal-destination <string>
+```
+
+If all goes well you will see
+
+```
+wallet public key: Gsv13oph2i6nkJvNkVfuzkcbHWchz6viUtEg2vsxQMtM
+No treasury withdrawal dest detected, using keypair
+No fee withdrawal dest detected, using keypair
+No treasury mint detected, using SOL.
+Created auction house HsKwc8dQtm8KLxshw67dwsNePkH6wMXo5Lwn1FuKjVYVS <--- Your auction house key will be different
+```
+
+Save this key `HsKwc8dQtm8KLxshw67dwsNePkH6wMXo5Lwn1FuKjVYVS` since it is the public key of the solana account that holds your Auction House. In all subsequent commands you will pass this key with the `-ah` option.
+
+## Show
+
+Prints the balances of the fee and treasury wallets configured for the auction house and its current settings options.
+
+See the command help with
+
+```
+ts-node auction-house-cli.ts help show
+```
+
+Notice I switched `--keypair` for `-k` this is shorthand but works just the same.
+
+```
+ts-node auction-house-cli.ts show -k ~/mywallet.key -ah HsKwc8dQtm8KLxshw67dwsNePkH6wMXo5Lwn1FuKjVYVS
+```
+
+The output will differ but similar to the following.
+
+```
+No treasury mint detected, using SOL.
+-----
+Auction House: HsKwc8dQtm8KLxshw67dwsNePkH6wMXo5Lwn1FuKjVYVS
+Mint: So11111111111111111111111111111111111111112
+Authority: DCDcpZaJUghstQNMHy9VAPnwQe1cGsHq7fbeqkti4kM3
+Creator: DCDcpZaJUghstQNMHy9VAPnwQe1cGsHq7fbeqkti4kM3
+Fee Payer Acct: AcWpR41NPMq73FZUspCiXxoLrJnW7zytgHKY5xqtETkU
+Treasury Acct: HFW5CY73qN3XK3qEP7ZFxbpBBkQtipPfPQzaDj3mbbY1
+Fee Payer Withdrawal Acct: DCDcpZaJUghstQNMHy9VAPnwQe1cGsHq7fbeqkti4kM3
+Treasury Withdrawal Acct: DCDcpZaJUghstQNMHy9VAPnwQe1cGsHq7fbeqkti4kM3
+Fee Payer Bal: 0
+Treasury Bal: 0
+Seller Fee Basis Points: 1000
+Requires Sign Off: false
+Can Change Sale Price: false
+AH Bump: 255
+AH Fee Bump: 252
+AH Treasury Bump: 254
+```
+
+### Fee Account
+
+In the above Show command you see a Fee Payer account.
+This account can be used to pay the fees on chain for sales execution, transfers and account creation. For this exercise we will teach you how to fund that account by airdropping some SOL on devnet. Your Auction House fee account is used only when the Auction House authority is signing the transaction. This is usually only in the case of `Requires Sign Off`
+
+```
+$ solana airdrop 2 AcWpR41NPMq73FZUspCiXxoLrJnW7zytgHKY5xqtETkU
+Requesting airdrop of 2 SOL
+Signature: 4qYFoD8GN6TZLDjLsqyyt6mhjYEjwKF36LJCDLtL88nTD3y3bFzXmVFHP6Nczf5Dn4GnmBJYtbqV9tN2WbsYynpX
+2 SOL
+```
+
+{% callout type="warning" %}
+
+The `solana airdrop` command is sometimes unreliable. If the command doesn't work, you can use the airdrop tool at https://solfaucet.com.
+
+{% /callout %}
+
+## Sell
+
+Place an NFT UP for sale.
+
+See the command help with
+
+```
+ts-node auction-house-cli.ts help sell
+```
+
+Place an NFT for sale by its mint address with the auction house for 1 SOL.
+
+```
+ts-node auction-house-cli.ts sell \
+  -k ~/mywallet.key \
+  -ah HsKwc8dQtm8KLxshw67dwsNePkH6wMXo5Lwn1FuKjVYVS \
+  --buy-price 1 \
+  --mint F7fejo7cT1fRyJxj1W2aWy3aeJz8iqLU9YvbBAzwJGh2 \
+  --token-size 1
+```
+
+Output:
+
+```
+wallet public key: CCJC2s8FDGAs8GqmngE9gviusEuNnkdUwchcYMZ8ZmHB
+wallet public key: DCDcpZaJUghstQNMHy9VAPnwQe1cGsHq7fbeqkti4kM3
+Set 1 F7fejo7cT1fRyJxj1W2aWy3aeJz8iqLU9YvbBAzwJGh2 for sale for 1 from your account with Auction House Ee53kiwLVw5XG98gSLNHoQRi4J22XEhz3zsKYY2ttsb7
+```
+
+### Require Sign-off
+
+If the auction house is set up to require sign off its wallet, as well as the seller are provided to the command.
+Do this using the `-ak` option.
+
+See the command help with
+
+```
+ts-node auction-house-cli.ts help sell
+```
+
+In a production scenario where the keypair for the auction house is stored on a sever managed by the organization hosting the auction house the transaction should be partially signed by the seller from the client then passed to the server for signing by the auction house before submitting to Solana.
+
+## Buy
+
+Place an offer on an NFT by its mint address at some price in SOL when using native SOL as the mint.
+
+See the command help with
+
+```
+ts-node auction-house-cli.ts help buy
+```
+
+The buy command is an offer on the NFT and will not result in a sale until the `execute_sale` action is triggered. This command offers 2 SOL for the NFT.
+
+```
+ts-node auction-house-cli.ts buy \
+  -k ~/mywallet.key \
+  -ah HsKwc8dQtm8KLxshw67dwsNePkH6wMXo5Lwn1FuKjVYVS \
+  --buy-price 2 \
+  --token-size 1 \
+  --mint 7v8kcqCHLih31bp2xwMojGWTMdrcFfzZsYXNbiLiRYgE
+wallet public key: 3DikCrEsfAVHv9rXENg2Hdmc16L71EjveQEF4NbSfRak
+wallet public key: DCDcpZaJUghstQNMHy9VAPnwQe1cGsHq7fbeqkti4kM3
+Made offer for  2
+```
+
+## Execute Sale
+
+Sell an NFT to a buyer at the price set by the seller.  Note that this currently requires the auction house authority, the buyer, or the seller to be the fee payer and thus sign the transaction.
+
+```
+$ ts-node auction-house-cli.ts execute_sale
+  -k ~/mywallet.key \
+  -ah HsKwc8dQtm8KLxshw67dwsNePkH6wMXo5Lwn1FuKjVYVS \
+  --buy-price 2 \
+  --mint DCqt9QQ3ot3qv53EhWrYAWFuh4XgSvFJvLRjgsDnhLTp \
+  --buyer-wallet 3DikCrEsfAVHv9rXENg2Hdmc16L71EjveQEF4NbSfRak \
+  --seller-wallet CCJC2s8FDGAs8GqmngE9gviusEuNnkdUwchcYMZ8ZmHB \
+  --token-size 1
+wallet public key: CCJC2s8FDGAs8GqmngE9gviusEuNnkdUwchcYMZ8ZmHB
+wallet public key: DCDcpZaJUghstQNMHy9VAPnwQe1cGsHq7fbeqkti4kM3
+Accepted 1 DCqt9QQ3ot3qv53EhWrYAWFuh4XgSvFJvLRjgsDnhLTp sale from wallet CCJC2s8FDGAs8GqmngE9gviusEuNnkdUwchcYMZ8ZmHB to 3DikCrEsfAVHv9rXENg2Hdmc16L71EjveQEF4NbSfRak for 2 from your account with Auction House HsKwc8dQtm8KLxshw67dwsNePkH6wMXo5Lwn1FuKjVYVS
+```
+
+## Other Actions
+
+Other actions are documented in the CLI and can be found using the `help` and `<command> help` subcommand:
+
+- _Cancel_ - Potential buyer revokes their offer.
+
+- _Show Escrow_ - Print out the balance of an auction house escrow account for a given wallet.
+
+- _Withdraw_ - Transfer funds from user's buyer escrow account for the auction house to their wallet.
+
+- _Deposit_ - Add funds to user's buyer escrow account for the auction house.
+
+- _Withdraw from Fee_ - Transfer funds from auction house fee wallet to the auction house authority.
+
+- _Withdraw from Treasury_ - Transfer funds from the auction house treasury wallet to the auction house authority.
+
+- _Update Auction House_ - Update any of the auction house settings including its authority or seller fee.

src/pages/legacy-documentation/auction-house/manage.md

@@ -0,0 +1,186 @@
+---
+title: Manage Auction Houses
+metaTitle: Auction House - Manage Auction Houses
+description: Explains how to manage Auction Houses.
+---
+
+## Introduction
+
+[On the previous page](auction-house/settings), we went through the various settings of an Auction House. So now, let’s see how we can use these settings to create and update Auction Houses. 
+
+We'll also talk about different ways of fetching Auction House. Lastly, we'll go see how to withdraw funds from the Auction House fee and treasury accounts.
+
+## Create Auction Houses
+
+An Auction House can be created with all the settings discussed in the previous page. The created Auction House account is referred to as an Auction House **Instance**.
+
+{% dialect-switcher title="JS SDK" %}
+{% dialect title="JavaScript" id="js" %}
+
+Let's go through an example of using the Metaplex JS SDK to create an Auction House. Note that by default the current identity is used as the authority of the Auction House. Moreover, by default `SOL` will be set as the `treasuryMint`. Lastly, helper accounts discussed in the last page will be automatically generated by the Auction House, but they can also be set manually while Auction House creation.
+
+```tsx
+const auctionHouseSettings = await metaplex
+    .auctionHouse()
+    .create({
+        sellerFeeBasisPoints: 500 // 5% fee
+        authority: metaplex.identity(),
+        requireSignOff: true,
+        canChangeSalePrice: true,
+        hasAuctioneer: true, // to enable auctioneer
+        auctioneerAuthority: metaplex.identity(),
+    });
+```
+
+{% /dialect %}
+{% /dialect-switcher %}
+
+
+## Auction House Account
+
+Now that we’ve created an Auction House instance, let’s see what data is stored inside it.
+
+Firstly, it stores all the settings that we have already discussed. In addition to these settings, the Auction House account stores a `creator` field, which points to the address of the wallet used to create the Auction House instance.
+
+Lastly, the Auction House instance also stores some PDA bumps, which are used to derive the addresses of the PDA accounts.
+
+> When building with PDAs, it is common to store the bump seed in the account data itself. This allows developers to easily validate a PDA without having to pass in the bump as an instruction argument.
+
+{% dialect-switcher title="JS SDK" %}
+{% dialect title="JavaScript" id="js" %}
+
+The Auction House account model can be explored in the [API References of the `AuctionHouse` model](https://metaplex-foundation.github.io/js/types/js.AuctionHouse.html).
+
+Here’s a small code example showcasing some of the Auction House attributes.
+
+```tsx
+const { auctionHouse } = await metaplex.auctionHouse().create({...});
+
+auctionHouse.address;                   // The public key of the Auction House account              
+auctionHouse.auctionHouseFeeAccount;    // The public key of the Auction House Fee account
+auctionHouse.feeWithdrawalDestination;  // The public key of the account to withdraw funds from Auction House fee account
+auctionHouse.treasuryMint;              // The mint address of the token to be used as the Auction House currency
+auctionHouse.authority;                 // The public key of the Auction House authority
+auctionHouse.creator;                   // The public key of the account used to create the Auction House instance
+auctionHouse.bump;                      // The `Bump` of the Auction House instance
+auctionHouse.feePayerBump;              // The `Bump` of the fee account
+auctionHouse.treasuryBump;              // The `Bump` of the treasury account
+auctionHouse.auctioneerAddress;         // he public key of the `Auctioneer` account
+```
+
+{% /dialect %}
+{% /dialect-switcher %}
+
+## Fetch Auction Houses
+
+Once created, the Auction House instance can be fetched. An Auction House can be uniquely identified by its PDA account address or a combination of its creator address and the treasury mint address.
+
+{% dialect-switcher title="JS SDK" %}
+{% dialect title="JavaScript" id="js" %}
+
+An Auction House can be fetched using two ways:
+
+1. **By address**: using the Auction House address
+2. **By creator and mint**: using the combination of the `creator` address and the treasury mint. Note that when the Auction House has Auctioneer enabled, the `auctioneerAuthority` is also required in addition to the creator and the mint.
+
+```tsx
+// by address
+const auctionHouse = await metaplex
+    .auctionHouse()
+    .findByAddress({ address: new PublicKey("Gjwc...thJS") });
+
+// by creator and mint
+// in this example, we assume that the Auction House
+// does not have Auctioneer enabled
+const auctionHouse = await metaplex
+    .auctionHouse()
+    .findByCreatorAndMint({
+        creator: new PublicKey("Gjwc...thJS"),
+        treasuryMint: new PublicKey("DUST...23df")
+    });
+```
+
+{% /dialect %}
+{% /dialect-switcher %}
+
+## Update Settings
+
+As in the case of Candy Machine, once an Auction House instance is created, you can update most of its settings later on as long as you are the authority of the Auction House instance. The following settings can be updated: `authority`, `sellerFeeBasisPoints`, `requiresSignOff`, `canChangeSalePrice`, `feeWithdrawalDestination`, `treasuryWithdrawalDestination`, `auctioneerScopes`.
+
+As we've already discussed, the authority of the Auction House is one of the settings that can be updated, as long as the current authority is the signer and the address of the new authority is mentioned.
+
+{% dialect-switcher title="JS SDK" %}
+{% dialect title="JavaScript" id="js" %}
+
+To update the settings, we need the full model in order to compare the current data with the provided data. For instance, if you only want to update the `feeWithdrawalDestination`, you need to send an instruction that updates the data whilst keeping all other properties the same.
+    
+Also, by default, `feeWithdrawalDestination` and the `treasuryWithdrawalDestination` are set to `metaplex.identity()`, ie., the same wallet which is set as the authority and the creator by default.
+
+```tsx
+import { Keypair } from "@solana/web3.js";
+
+const currentAuthority = Keypair.generate();
+const newAuthority = Keypair.generate();
+const newFeeWithdrawalDestination = Keypair.generate();
+const newTreasuryWithdrawalDestination = Keypair.generate();
+const auctionHouse = await metaplex
+    .auctionHouse()
+    .findByAddress({...});
+
+const updatedAuctionHouse = await metaplex
+    .auctionHouse()
+    .update({
+        auctionHouse,
+        authority: currentAuthority,
+        newAuthority: newAuthority.address,
+        sellerFeeBasisPoints: 100,
+        requiresSignOff: true,
+        canChangeSalePrice: true,
+        feeWithdrawalDestination: newFeeWithdrawalDestination,
+        treasuryWithdrawalDestination: newTreasuryWithdrawalDestination
+    });
+```
+
+{% /dialect %}
+{% /dialect-switcher %}
+
+## Withdraw Funds
+
+We have discussed in the previous page about the different helper accounts of Auction House. These are the **Fee Account** and the **Treasury Account**.
+
+Funds from both these accounts can be transferred back to "destination" wallets. These withdrawal destination accounts can be set by the Auction House authority.
+
+{% dialect-switcher title="JS SDK" %}
+{% dialect title="JavaScript" id="js" %}
+
+Here's a code snippet which transfers funds.
+    
+1. Auction House Fee Wallet to the Fee Withdrawal Destination Wallet.
+2. Transfers funds from Auction House Treasury Wallet to the Treasury Withdrawal Destination Wallet.
+    
+In both the cases, The Auction House from which the funds are being transferred and the amount of funds to withdrawn need to be specified. This amount can either be in SOL or in the SPL token used by the Auction House as a currency.
+
+```tsx
+// withdraw funds from fee account
+await metaplex
+    .auctionHouse()
+    .withdrawFromFeeAccount({
+        auctionHouse,
+        amount: 5
+    });
+
+// withdraw funds from treasury account
+await metaplex
+    .auctionHouse()
+    .withdrawFromTreasuryAccount({
+        auctionHouse,
+        amount: 10
+    });
+```
+
+{% /dialect %}
+{% /dialect-switcher %}
+
+## Conclusion
+
+At this point we've gone over the Auction House settings, the data an Auction House instance stores and how to create and update this data. However, we still don't know how assets are traded on Auction Houses. We'll talk about this in the [next page](auction-house/trading-assets).

src/pages/legacy-documentation/auction-house/receipts.md

@@ -0,0 +1,63 @@
+---
+title: Receipts
+metaTitle: Auction House - Receipts
+description: Explains how to generate Auction House receipts.
+---
+## Introduction
+
+To aid transaction / activity tracking on marketplaces, the Auction House program supports the generation of receipts for listings, bids and sales.
+
+In addition to printing receipts, Auction House cancels receipts when the corresponding instruction (bid, listing or sale) is cancelled.
+
+Let us see how receipts are printed.
+
+## Printing Receipts
+
+To generate these receipts, the receipt printing function should be called immediately after the corresponding transaction (`PrintListingReceipt`, `PrintBidReceipt`, and `PrintPurchaseReceipt`).
+
+Additionally, the `CancelListingReceipt `and `CancelBidReceipt` instructions should be called in the case of canceled listings and bids. Calling these two instructions will fill the `canceled_at` fields of the `ListingReceipt` and `BidReceipt` accounts.
+
+> While the receipts can be retrieved using the standard getProgramAccounts data flow, the official recommendation is to use Solana's AccountsDB plug-in to index and track the generated receipts.
+
+There are two fields that can be introduced to each function above to print the corresponding receipt:
+
+1. `printReceipt`: This is a boolean field that defaults to `true`. When this field is set to `true`, a receipt is printed for the corresponding function.
+
+2. `bookkeeper`: The address of the bookkeeper wallet responsible for the receipt. In other words, the bookeeper is the wallet that paid for the receipt. It's only responsibility at this time is tracking the payer of the receipt so that in the future if the account is allowed to be closed the program knows who should be refunded for the rent. This field defaults to `metaplex.identity()`.
+
+{% dialect-switcher title="JS SDK" %}
+{% dialect title="JavaScript" id="js" %}
+Here's an example of printing receipts for bid, list and execute sale instructions.
+     
+```tsx
+// printing the ListReceipt
+await metaplex
+    .auctionHouse()
+    .createListing({
+        printReceipt: true,
+        bookkeeper: metaplex.identity()
+    })
+
+// printing the BidReceipt
+await metaplex
+    .auctionHouse()
+    .createBid({
+        printReceipt: true,
+        bookkeeper: metaplex.identity()
+    })
+
+// printing the PurchaseReceipt
+await metaplex
+    .auctionHouse()
+    .executeSale({
+        printReceipt: true,
+        bookkeeper: metaplex.identity()
+    })
+```
+
+{% /dialect %}
+{% /dialect-switcher %}
+
+## Conclusion
+
+Now that we know how to print receipts for easy transaction tracking, how do we actually fetch details regarding these actions in practice? Let us explore ways to find bids, listings and sales for an Auction House in the [next page](find).

src/pages/legacy-documentation/auction-house/settings.md

@@ -0,0 +1,189 @@
+---
+title: Settings
+metaTitle: Auction House - Settings
+description: Explains Auction House settings in great detail.
+---
+
+## Introduction
+
+On this page, we will discuss settings that are available on an Auction House. These settings include some general settings that define how an Auction House operates, defination of some accounts (PDAs) that support the operation of the Auction House and some more specific settings that provide further configurability to the Auction House program.
+
+## The Authority
+
+The authority is the wallet which controls the usage of an account, and in this case, the Auction House instance. The authority address can be be mentioned when creating an Auction House. If not mentioned, the wallet which is being used to create the Auction House defaults as the authority. 
+
+The authority can also be transferred to another wallet after the creation of the Auction House, which transfers control of the Auction House. This action should be performed carefully.
+
+Authority wallet also plays another important role of guarding which assets could be listed and sold on the marketplace. We'll talk more about this functionality of the authority when we discuss [`requireSignOff`](#requiresignoff)
+
+{% dialect-switcher title="JS SDK" %}
+{% dialect title="JavaScript" id="js" %}
+
+When using the JS SDK, the authority of a Auction House will always default to the wallet being used to create the Auction House. You may explicitly set this authority by providing a valid signer to the authority property.
+
+```tsx
+import { Keypair } from "@solana/web3.js";
+
+const myCustomAuthority = Keypair.generate();
+const auctionHouseSettings = {
+  authority: myCustomAuthority,
+};
+```
+
+{% /dialect %}
+{% /dialect-switcher %}
+
+## Trade Settings
+
+These are trading-specific settings that can be set on an Auction House. These settings help in defining how a user interacts with the marketplace:
+
+1. `treasuryMint`: This defines the mint account of the SPL-token to be used as the currency of exchange in the marketplace. Most marketplaces on Solana usually use SOL as the currency of exchange and for trading assets. Using this setting, the authority of the Auction House can set any SPL-token to be used to buy and sell assets on the given marketplace.
+
+2. `sellerFeeBasisPoints`: This defines the secondary sale royalties that a marketplace receives on each sale of every asset on the given marketplace. `250` means `2.5%` royalty share.
+
+{% dialect-switcher title="JS SDK" %}
+{% dialect title="JavaScript" id="js" %}
+
+In this snippet we are creating an spl-token and setting it as the `treasuryMint` of the Auction House. We are also setting the marketplace royalties using `sellerFeeBasisPoints`.
+
+```tsx
+import { clusterApiUrl, Connection, Keypair } from "@solana/web3.js";
+import { Token, TOKEN_PROGRAM_ID } from "@solana/spl-token";
+
+const myKeypair = Keypair.generate();
+const connection = new Connection(
+    clusterApiUrl('devnet'),
+    'confirmed',
+);
+const myCustomToken = splToken.Token.createMint(connection, myKeypair, myKeypair.publicKey, null, 9, splToken.TOKEN_PROGRAM_ID)
+const auctionHouseSettings = {
+    treasuryMint: myCustomToken,
+    sellerFeeBasisPoints: 150
+};
+```
+
+{% /dialect %}
+{% /dialect-switcher %}
+
+
+## Helper Accounts
+
+There are several accounts that are necessary for the Auction House to function properly. Once set by the Auction House, the authority can reset and configure these accounts as per their liking.
+
+There are some accounts that are created and controlled by the Auction House program. These accounts are Program Derived Addresses (PDAs) which you can read more about [here](https://solanacookbook.com/core-concepts/pdas.html). These are the two settings that can be used to set these accounts:
+
+1. `auctionHouseFeeAccount`: The public key of the fee account which stores funds for paying for Auction House related transactions on behalf of the users. 
+
+2. `auctionHouseTreasury`: The public key of the treasury account which stores the funds received on every sale, as marketplace royalty.
+
+There are other accounts that are not created by the Auction House program, but are essential for withdrawing different types of funds from the Auction House, back to the authority:
+
+1. `feeWithdrawalDestination`: The public key of the account to which the funds can be withdrawn from the fee account. 
+
+2. `treasuryWithdrawalDestination`: The public key of the account to which the funds can be withdrawn from the treasury account.
+
+{% dialect-switcher title="JS SDK" %}
+{% dialect title="JavaScript" id="js" %}
+
+The following code snippet builds four different keypairs, corresponding to the four accounts discussed above and sets them.
+
+```tsx
+import { Keypair } from "@solana/web3.js";
+
+const feeAccount = Keypair.generate();
+const treasuryAccount = Keypair.generate();
+const feeWithdrawalDestination = Keypair.generate();
+const treasuryWithdrawalDestination = Keypair.generate();
+const auctionHouseSettings = {
+    auctionHouseFeeAccount: feeAccount,
+    auctionHouseTreasury: treasuryAccount,
+    feeWithdrawalDestination: feeWithdrawalDestination,
+    treasuryWithdrawalDestination: treasuryWithdrawalDestination,
+};
+```
+
+{% /dialect %}
+{% /dialect-switcher %}
+
+
+## Require Sign Off
+This setting allows marketplaces to gate asset listing and sales. As discussed in the authority section, the Auction House authority plays a role in the gating of assets. This censorship or centralised control can only take place when `requireSignOff = true`.
+
+When this happens, every transaction on the marketplace: listing, bidding and execution of sales needs to be signed by the Auction House authority. Fully decentralised marketplaces can choose to keep the `requireSignOff` setting as `false` to avoid censorship or centralised control of actions on that marketplace. 
+
+Setting `requireSignOff = true` has other powers as well: it allows marketplaces to implement their own custom order matching algorithms. We will talk more about this in the next section.
+
+{% dialect-switcher title="JS SDK" %}
+{% dialect title="JavaScript" id="js" %}
+
+The following code snippet sets `requireSignOff` to `true`.
+
+```tsx
+const auctionHouseSettings = {
+    requireSignOff: true
+};
+```
+
+{% /dialect %}
+{% /dialect-switcher %}
+
+## Can Change Sale Price
+
+`canChangeSalePrice` allows marketplaces to change the sale price of an asset, when a user intentionally lists an asset for free, or for 0 SOL (or any other SPL-token). By listing the asset for 0 SOL, the user allows marketplaces to apply custom matching algorithms in order to find the best price match for the "freely" listed asset.
+
+
+An important point to note here is that `canChangeSalePrice` can be set to `true` only if `requireSignOff` is also set to `true`. This is because custom matching is not possible in the case of permissionless listing and bidding. The Auction House should be able to "sign off" on a matching bid and execute the sale of the asset.
+
+{% dialect-switcher title="JS SDK" %}
+{% dialect title="JavaScript" id="js" %}
+
+The following code snippet sets `canChangeSalePrice` to `true`, while also ensuring that `requireSignOff` is also `true`
+
+```tsx
+const auctionHouseSettings = {
+    requireSignOff: true,
+    canChangeSalePrice: true
+};
+```
+
+{% /dialect %}
+{% /dialect-switcher %}
+
+## Auctioneer Settings
+
+The `Auctioneer` account is a PDA which uses the composability pattern of the Auction House program to control an Auction House Instance.
+
+The Auctioneer has the ability to be given the control, or Delegation over an Auction House instance using the `DelegateAuctioneer` instruction which we will discuss in the Auctioneer guide (*comming soon*).
+
+There are three setting pertaining to the Auctioneer which can be configured in the Auction House:
+
+1. `hasAuctioneer`: True if an `Auctioneer` instance exists for the given Auction House instance.
+2. `auctioneerAuthority`: The Auctioneer authority key. It is required when the Auction House is going to have Auctioneer enabled.
+3. `auctioneerScopes`: The list of scopes available to the user in the Auctioneer, for example: Bid, List, Execute Sale. It only takes place when the Auction House has Auctioneer enabled.
+
+{% dialect-switcher title="JS SDK" %}
+{% dialect title="JavaScript" id="js" %}
+
+The following code snippet sets `hasAuctioneer` to `true`. It also points the `auctioneerAuthority` to a generated public key and sets `auctioneerScopes` to allow the Auctioneer to buy, sell and excecute the sale on behalf of the Auction House.
+
+```tsx
+import { Keypair } from "@solana/web3.js";
+import { AuthorityScope } from '@metaplex-foundation/mpl-auction-house';
+
+const newAuthority = Keypair.generate();
+const auctionHouseSettings = {
+    hasAuctioneer: true,
+    auctioneerAuthority: newAuthority,
+    auctioneerScopes: [
+        AuthorityScope.Buy,
+        AuthorityScope.Sell,
+        AuthorityScope.ExecuteSale,
+    ]
+};
+```
+
+{% /dialect %}
+{% /dialect-switcher %}
+
+## Conclusion
+Now that we know about Auction House settings, on the [next page](/programs/auction-house/manage), we’ll see how we can use them to create and update our own Auction House.

src/pages/legacy-documentation/auction-house/trading-assets.md

@@ -0,0 +1,248 @@
+---
+title: Trading Assets
+metaTitle: Auction House - Trading Assets
+description: Explains how to manage the trading of assets on Auction House.
+---
+## Introduction
+In the previous pages, we've talked about Auction Houses and how to create & manage them. Once an Auction House is created, assets can be traded on it. A simple trade on a marketplace usually comprises of three actions:
+
+1. The seller lists an asset
+2. The buyer makes a bid on the asset
+3. Once a matching bid is found for a listing, the sale is executed
+
+On this page, we will talk about these three actions and see code examples to easily execute these actions. We will also see trade scenarios that are different from the above simple trade scenario, and go through a code example to execute each scenario. Finally, we'll also explore how listings and bids can be cancelled once they are created.
+
+Let us start with listing an asset on an Auction House.
+
+## Listing assets
+
+We went through the process of listing an asset in the [Overview page](../auction-house). This action is also referred to as creating a **Sell Order**. When a sell order is created using Auction House, the asset being listed remains in the wallet of the seller. This is a very important feature of Auction House as it allows users to list assets in an escrow-less fashion and thus users still maintain custody of assets while the assets are listed.
+
+The asset seller can create two types of listings depending on the price at which they list the asset:
+
+1. **Listing at price greater than 0**: when a user lists an asset at a price which is greater than 0 SOL (or any other SPL-token). In this case, the seller's wallet needs to be the signer and thus this wallet should be 
+
+2. **Listing at price of 0**: when a user lists an asset for 0 SOL (or any other SPL-token). In this case, the authority can sign on behalf of the seller if `canChangeSalePrice` option is set to `true` which was discussed in the [Auction House settings page](settings). When this happens, the Auction House finds a non-0 matching bid on behalf of the seller. The asset can only be listed and sold for a price of 0 if the seller acts as the signer. There must be one and only one signer; authority or seller must sign.
+
+Depending on the type of token being listed, the number of tokens to be listed can also be specified when creating a sell order:
+
+1. In case of **Non-Fungible Tokens (NFTs)**: due to the non-fungibility and uniqueness of every token, only 1 token can be listed.
+
+2. In case of **Fungible Assets**: the seller can list more than 1 tokens per listing. For example: If Alice owns 5 DUST tokens, they can list 1 or more (but less than or equal to 5) of these DUST tokens in the same sell order.
+
+{% dialect-switcher title="JS SDK" %}
+{% dialect title="JavaScript" id="js" %}
+
+Let us look at an example for making a listing or sell order on Auction House.
+
+In the following code snippet we are making a sell order for 3 DUST tokens (fungible tokens) for a total price of 5 SOL. Important to note here is that if we were creating a sell order for an NFT, we do not have to specify the number of tokens to be listed as it will default to 1 token. Specifying any other amount will result in an error.
+    
+    
+```tsx
+await metaplex
+    .auctionHouse()
+    .createListing({
+        auctionHouse,                              // A model of the Auction House related to this listing
+        seller: Keypair.generate(),                // Creator of a listing
+        authority: Keypair.generate(),             // The Auction House authority
+        mintAccount: new PublicKey("DUST...23df"), // The mint account to create a listing for, used to find the metadata
+        tokenAccount: new PublicKey("soC...87g4"), // The token account address that's associated to the asset a listing created is for 
+        price: 5,                                  // The listing price
+        tokens: 3                                  // The number of tokens to list, for an NFT listing it must be 1 token
+    });
+```
+
+{% /dialect %}
+{% /dialect-switcher %}
+
+## Bidding on assets
+
+A user looking to buy an asset can make bids, or **Buy Orders** for that asset. 
+
+There can be two types of buy orders depending on that whether the asset is listed or not:
+
+1. **Private bids**: This is the most common type of bid. A user, interested in a listed asset on an Auction House, creates a private bid on the given asset. This bid is tied to the specific auction and not the asset itself. This means that when the auction is closed (either the bid is rejected and the listing is cancelled, or the bid is accepted and the asset is sold), the bid is also closed.
+
+2. **Public bids**: A user can post a public bid on a non-listed NFT by skipping seller and tokenAccount properties. Public bids are specific to the token itself and not to any specific auction. This means that a bid can stay active beyond the end of an auction and be resolved if it meets the criteria for subsequent auctions of that token.
+
+Like in the case of sell orders, buy orders can also specifiy the number of tokens to be bid upon depending on the type of asset listed:
+
+1. **Partial Buy Order**: We discussed the case of listing more than 1 token when listing a fungible asset. When such a sell order exists, a user can make a bid to buy only a portion of the listed tokens, or make a partial buy order. For example: if Alice listed `3 DUST` tokens for `5 SOL`, Alice can make a bid to buy `2 DUST` tokens for `2 SOL`. In other words, a user can create a buy order of said assets that is less than the `token_size` of the sell order.
+
+2. **Complete Buy Order**: This is the case where the buyer creates a bid to buy all the tokens listed in the sell order. In case of non-fungible assets (NFTs) where only 1 token can be listed per sell order, a complete buy order is created. Complete buy orders can also be created in case of fungible tokens.
+
+{% dialect-switcher title="JS SDK" %}
+{% dialect title="JavaScript" id="js" %}
+
+Let us look at an example for making a bid or buy order on Auction House.
+
+In the following code snippet we are making a buy order for 3 DUST tokens (fungible tokens) for a total price of 5 SOL. Important to note here is that if we were creating a sell order for an NFT, we do not have to specify the number of tokens to be listed as it will default to 1 token. Specifying any other amount will result in an error.
+    
+This is an example of a private bid as we are specifying the seller account and the token account. If either one of them is not specified while creating the bid, the bid will be public.
+     
+```tsx
+await metaplex
+    .auctionHouse()
+    .createBid({
+        auctionHouse,                              // A model of the Auction House related to this listing
+        buyer: Keypair.generate(),                 // Creator of a bid
+        seller: Keypair,generate(),                // The account address that holds the asset a bid created is for, if this or tokenAccount isn't provided, then the bid will be public.
+        authority: Keypair.generate(),             // The Auction House authority
+        mintAccount: new PublicKey("DUST...23df"), // The mint account to create a bid for
+        tokenAccount: new PublicKey("soC...87g4"), // The token account address that's associated to the asset a bid created is for, if this or seller isn't provided, then the bid will be public.
+        price: 5,                                  // The buyer's price
+        tokens: 3                                  // The number of tokens to bid on, for an NFT bid it must be 1 token
+    });
+```
+
+{% /dialect %}
+{% /dialect-switcher %}
+
+## Executing sale of assets
+
+Now that we know how to create a listing (sell order) and a bid (buy order), we can learn how to execute sales of assets. When the sale of an asset is executed:
+
+1. The Auction House transfers the bid amount from the buyer escrow account to the seller's wallet. We will talk more about the buyer escrow account and how can the marketplace authority manage funds in that account.
+
+2. The Auction House transfers the asset from the seller's wallet to the buyer's wallet.
+
+Now that we know what the excution of a sale means, lets explore different trade scenarios in which assets can be sold using Auction House. We have already discussed them in great detail in the [overview page] but here's a brief explanation in addition to a code snippet for each scenario:
+
+1. **Direct Buy**, or *"Buying" at list price*: This is the case when the execution of the sale happens when a user bids on a listed asset. In other words, a direct buy operation creates a bid on a given asset and then executes a sale on the created bid and listing. 
+    
+    In most cases, this scenario will occur when the buyer makes a bid at the listed price of the asset. But there can be cases where marketplaces have custom order matching algorithms that work on thresholds. For example: a marketplace may have a rule to execute the sale of a given asset as soon as there is a bid which is within a range of +-20% from the listed price.
+    
+{% dialect-switcher title="JS SDK" %}
+{% dialect title="JavaScript" id="js" %}
+
+Here's an example of direct buying an asset by a user who is interested in the listed asset.
+     
+```tsx
+const listing = await metaplex
+    .auctionHouse()
+    .findListingByReceipt({...}) // we will see how to fetch listings in the coming pages
+    
+const directBuyResponse = await metaplex
+    .auctionHouse()
+    .buy({
+        auctionHouse,                   // The Auction House in which to create a Bid and execute a Sale
+        buyer: Keypair.generate(),      // Creator of a bid, should not be the same as seller who creates a Listing
+        authority: Keypair.generate(),  // The Auction House authority, if this is the Signer the
+                                        // transaction fee will be paid from the Auction House Fee Account
+        listing: listing,               // The Listing that is used in the sale, we only need a
+                                        // subset of the `Listing` model but we need enough information
+                                        // regarding its settings to know how to execute the sale.
+        price: 5,                       // The buyer's price
+    });
+```
+
+{% /dialect %}
+{% /dialect-switcher %}
+
+2. **Direct Sell**, or *"Selling" at bid price*: Counterpart to the case of direct buy, this is the case when a user, interested in an unlisted asset, places a bid on it. If the asset owner now lists the asset for the bid amount, the execution of the sale can take place, thus direct selling the asset.
+
+{% dialect-switcher title="JS SDK" %}
+{% dialect title="JavaScript" id="js" %}
+
+Here's an example of direct selling an asset by a user who is interested in a bid on the asset.
+     
+```tsx
+const bid = await metaplex
+    .auctionHouse()
+    .findBidByReceipt({...}) // we will see how to fetch bids in the coming pages
+    
+const directSellResponse = await metaplex
+    .auctionHouse()
+    .sell({
+        auctionHouse,                              // The Auction House in which to create a listing and execute a Sale
+        seller: Keypair.generate(),                // Creator of a listing, there must be one and only one signer; Authority or Seller must sign.
+        authority: Keypair.generate(),             // The Auction House authority, if this is the Signer the
+                                                   // transaction fee will be paid from the Auction House Fee Account
+        bid: bid,                                  // The Public Bid that is used in the sale, we only need a
+                                                   // subset of the `Bid` model but we need enough information
+                                                   // regarding its settings to know how to execute the sale.
+        sellerToken: new PublicKey("DUST...23df")  // The Token Account of an asset to sell, public Bid doesn't
+                                                   // contain a token, so it must be provided externally via this parameter
+    });
+```
+
+{% /dialect %}
+{% /dialect-switcher %}
+
+3. **Independant Sale Execution**, or *Lister agreeing to a bid*: This is the case when the execution of the sale takes place independantly, after a **Buy Order** (bid) and a **Sell Order** (listing) exist for a given asset.
+
+{% dialect-switcher title="JS SDK" %}
+{% dialect title="JavaScript" id="js" %}
+
+Here's an example of an independant sale execution.
+     
+```tsx
+const listing = await metaplex
+    .auctionHouse()
+    .findListingByReceipt({...}) // we will see how to fetch listings in the coming pages
+    
+const bid = await metaplex
+    .auctionHouse()
+    .findBidByReceipt({...})     // we will see how to fetch bids in the coming pages
+    
+const executeSaleResponse = await metaplex
+    .auctionHouse()
+    .executeSale({
+        auctionHouse,                   // The Auction House in which to create a Bid and execute a Sale
+        authority: Keypair.generate(),  // The Auction House authority, if this is the Signer the
+                                        // transaction fee will be paid from the Auction House Fee Account
+        listing: listing,               // The Listing that is used in the sale, we only need a
+                                        // subset of the `Listing` model but we need enough information
+                                        // regarding its settings to know how to execute the sale.
+        bid: bid,                       // The Public Bid that is used in the sale, we only need a
+                                        // subset of the `Bid` model but we need enough information
+                                        // regarding its settings to know how to execute the sale.
+    });
+```
+
+{% /dialect %}
+{% /dialect-switcher %}
+
+## Cancel Listings and Bids
+
+Till now we have seen how to create bids and listings, and also execute the sales of assets in an Auction House. Once listings and bids are created in an Auction House, they can be cancelled via the authority.
+
+{% dialect-switcher title="JS SDK" %}
+{% dialect title="JavaScript" id="js" %}
+
+Here's an example of cancelling a bid and a listing using the JS SDK.
+     
+```tsx
+const listing = await metaplex
+    .auctionHouse()
+    .findListingByReceipt({...}) // we will see how to fetch listings in the coming pages
+    
+const bid = await metaplex
+    .auctionHouse()
+    .findBidByReceipt({...})     // we will see how to fetch bids in the coming pages
+    
+// Cancel a bid
+const cancelBidResponse = await metaplex               
+    .auctionHouse()
+    .cancelBid({
+        auctionHouse,            // The Auction House in which to cancel Bid
+        bid: bid,                // The Bid to cancel
+    });
+
+// Cancel a listing
+const cancelListingResponse = await metaplex
+    .auctionHouse()
+    .cancelListing({
+        auctionHouse,            // The Auction House in which to cancel listing
+        listing: listing,        // The listing to cancel
+    });
+```
+
+{% /dialect %}
+{% /dialect-switcher %}
+
+## Conclusion
+
+In this page we covered all the components to manage trading of assets on a marketplace. 
+
+One key point which we haven't discussed is the buyer escrow account, which is needed to escrow, or temporarily hold buyer's funds when the buyer makes a bid on an asset. How are these funds managed in this account and who is responsible for keeping track of these funds? Let's find out in the [next page](buyer-escrow).

src/pages/legacy-documentation/developer-tools/beet.md

@@ -0,0 +1,16 @@
+---
+title: Beet
+metaTitle: Developer Tools - Beet
+description: Strict borsh compatible de/serializer and related extensions
+---
+
+Strict borsh compatible de/serializer and related extensions. Beet is used by [Solita](../solita) to improve type
+safety. The Solana specific extension
+package, [@metaplex-foundation/beet-solana](https://www.npmjs.com/package/@metaplex-foundation/beet), adds new features
+such as GPA builders due to Beet's knowledge of account layouts.
+
+🔗 **Helpful links:**
+
+- [GitHub Repository](https://github.com/metaplex-foundation/beet)
+- [NPM Package](https://www.npmjs.com/package/@metaplex-foundation/beet-solana)
+- [API Docs](https://metaplex-foundation.github.io/beet/docs/beet/)

src/pages/legacy-documentation/developer-tools/cusper.md

@@ -0,0 +1,15 @@
+---
+title: Cusper
+metaTitle: Developer Tools - Cusper
+description: resolves Custom Program Errors from Solana program logs or error codes
+---
+# Cusper
+
+Cusper resolves **Cus**tom **P**rogram **Er**rors from Solana program logs or error codes. It is used
+by [Solita](../solita) to make dealing with program errors significantly easier.
+
+🔗 **Helpful links:**
+
+- [GitHub Repository](https://github.com/metaplex-foundation/cusper)
+- [NPM Package](https://www.npmjs.com/package/@metaplex-foundation/cusper)
+- [API Docs](https://metaplex-foundation.github.io/cusper/docs/)

src/pages/legacy-documentation/developer-tools/rust-bin.md

@@ -0,0 +1,13 @@
+---
+title: Rust Bin
+metaTitle: Developer Tools - Rust Bin
+description: Synchronizes a Rust binary version with the related Rust crate
+---
+
+Synchronizes a Rust binary version with the related Rust crate.
+
+🔗 **Helpful links:**
+
+- [GitHub Repository](https://github.com/metaplex-foundation/rustbin)
+- [NPM Package](https://www.npmjs.com/package/@metaplex-foundation/rustbin)
+- [API Docs](https://metaplex-foundation.github.io/rustbin/docs/)

src/pages/legacy-documentation/developer-tools/shank.md

@@ -0,0 +1,14 @@
+---
+title: Solita
+metaTitle: Developer Tools - Solita
+description: extract IDLs from Rust Solana program code
+---
+
+Shank makes it possible to extract IDLs from Rust Solana program code annotated with Shank attribute macros. This IDL
+can then be fed to [Solita](../solita) in order to generate low level TypeScript SDK for that particular Rust program.
+
+🔗 **Helpful links:**
+
+- [GitHub Repository](https://github.com/metaplex-foundation/shank)
+- [Rust Crate](https://crates.io/crates/shank)
+- [CLI Rust Crate](https://crates.io/crates/shank-cli)

src/pages/legacy-documentation/developer-tools/solita.md

@@ -0,0 +1,13 @@
+---
+title: Solita
+metaTitle: Developer Tools - Solita
+description: generates a low level TypeScript SDK for your Solana Rust programs
+---
+
+Solita generates a low level TypeScript SDK for your Solana Rust programs from the IDL extracted by Anchor
+or [Shank](../shank).
+
+🔗 **Helpful links:**
+
+- [GitHub Repository](https://github.com/metaplex-foundation/solita)
+- [NPM Package](https://www.npmjs.com/package/@metaplex-foundation/solita)

src/pages/legacy-documentation/fixed-price-sale/index.md

@@ -0,0 +1,24 @@
+---
+title: Overview
+metaTitle: Fixed-Price-Sale - Overview
+description: Sell prints from Master Edition NFTs
+---
+
+{% callout type="warning" %}
+
+Please note that this program is marked as deprecated and is no longer actively maintained by the Metaplex Foundation team. New features, security fixes and backward compatibility are not guaranteed. Please use with caution.
+
+{% /callout %}
+
+# Introduction
+
+Metaplex's Fixed-Price Sale program is a Solana program for brands to create membership NFTs that they can distribute to a large audience. This NFT can be used for gating access to certain things (games, events, launches, etc.) at a future date.
+Like its name, all NFTs from the program are sold at a fixed price by minting [print editions](/token-metadata/print) from a single master edition NFT. As a result, all the NFTs will have the same metadata (apart from the edition number).
+
+The Fixed-Price Sale program also supports gating by collection. So, creators can gate sales by collection NFT, meaning that only holders of an on-chain collection are able to purchase NFTs. You can also have multiple stages of the sale: gated and not gated. For example, you can create a market with total duration of 5 hours with the first 3 being gated, so only holders can can buy an NFT.
+
+🔗 **Helpful links:**
+
+- [GitHub Repository](https://github.com/metaplex-foundation/metaplex-program-library/tree/master/fixed-price-sale)
+- [Autogenerated API](https://www.npmjs.com/package/@metaplex-foundation/mpl-fixed-price-sale)
+- [Rust Crate](https://crates.io/crates/mpl-fixed-price-sale)

src/pages/legacy-documentation/fixed-price-sale/tech-description.md

@@ -0,0 +1,281 @@
+---
+title: Technical Description
+metaTitle: Fixed-Price-Sale - Technical Description
+description: Technical Description of the Fixed Price Sale Program
+---
+
+## Creators to sell something have to:
+
+1. Create store
+
+    - It's necessary because we have to filter Markets somehow
+
+    - It will contain name, admin key, description
+
+2. Initialise Selling resource. It can be either created one or our platform will create it.
+
+    - Once user initialise selling resource we have an object with resource which we can sell
+
+3. Create a Market
+
+    - Create object with info about items selling, all apart from max supply such as we defined it in Selling resource
+
+## Users to buy tokens have to:
+
+1. Go to store. 
+
+2. Choose token and click "Buy"
+
+    - Under the hood next things will happen:
+
+        - TradeHistory account will be created where we track how many tokens this user already bought
+
+        - Debit and credit operations
+
+        - New NFT created(create mint, mint token, create Metadata, create MasterEdition)
+
+3. Token will be shown in their wallets
+
+# Accounts
+
+## Store
+
+| Field      | Type |Description|
+| ----------- | ----------- | ------ |
+| admin      | `Pubkey`       | Admin key who can create selling resources and markets in specific store       |
+|  name  |  `String`  |   |
+|  description  |  `String`  |   |
+
+## Selling resource
+
+| Field      | Type |Description|
+| ----------- | ----------- | ------ |
+|  store  |  `Pubkey`  |    |
+|  owner  |  `Pubkey`  |  Owner of resource. This account can receive back resource once sail is ended  |
+|  resource  |  `Pubkey`  |  Mint account Metadata attached to. We don’t need store Metadata key because it’s PDA and we can calculate it knowing the mint key  |
+|  vault  |  `Pubkey`  |  Token account which holds MasterEdition  |
+|  vault_owner  |  `Pubkey`  |  PDA with seeds [“mt_vault“, resource.key(), store.key()]  |
+|  supply  |  `u64`  |  Amount of tokens already sold  |
+|  max_supply  |  `Option<u64>`  |  Max amount of token can be sold  |
+|  state  |  `Enum{Uninitialised, Created, InUse, Exhausted, Stoped,}`  |  State of resource  |
+
+## Market
+
+| Field      | Type |Description|
+| ----------- | ----------- | ------ |
+|  store  |  `Pubkey`  |    |
+|  selling_resource  |  `Pubkey`  |    |
+|  treasury_mint  |  `Pubkey`  |  Mint account of tokens which market will accept as a payment  |
+|  treasury_holder  |  `Pubkey`  |  Token account buyers will send tokens to. Only market owner can withdraw assets  |
+|  treasury_owner  |  `Pubkey`  |  PDA[“holder“, treasury_mint.key(), selling_resource.key()]  |
+|  owner  |  `Pubkey`  |  Market owner  |
+|  name  |  `String`  |    |
+|  description  |  `String`  |    |
+|  mutable  |  `bool`  |    |
+|  price  |  `u64`  |    |
+|  pieces_in_one_wallet  |  `Option<u64>`  |  How many tokens we can sell to one wallet  |
+|  start_date  |  `u64`  |    |
+|  end_date  |  `Option<u64>`  |    |
+|  state  |  `Enum {Uninitialised, Created, Active, Ended,}`  |    |
+|  funds_collected  |  `u64`  |    |
+
+
+## TradeHistory
+
+### PDA [“history“, wallet.key(), market.key()]
+
+| Field      | Type |Description|
+| ----------- | ----------- | ------ |
+|  market  |  `Pubkey`  |    |
+|  wallet  |  `Pubkey`  |    |
+|  already_bought  |  `u64`  |  How many tokens user already bought from specific Market  |
+
+## PrimaryMetadataCreators
+
+### PDA [“primary_creators“, metadata.key()]
+
+| Field      | Type |Description|
+| ----------- | ----------- | ------ |
+|  creators  |  `Vec<mpl_token_metadata::state::Creator>`  |  List of creators to receive primary sales royalties  |
+
+# Instructions
+
+## CreateStore
+
+Creates new Store account.
+
+| Parameter      | Type |Description|
+| ----------- | ----------- | ------ |
+|  admin  |  Key, Signer, Writable  |    |
+|  store  |  Key, Signer, Writable  |  Uninitialized account  |
+|  name  |  `String`  |    |
+|  description  |  `String`  |    |
+
+## InitSellingResource
+
+Initialize SellingResource account which will be used by Market.
+
+| Parameter      | Type |Description|
+| ----------- | ----------- | ------ |
+|  store  |  Key  |    |
+|  store_admin  |  Key, Signer, Writable  |  Holds resource_token and pays for selling_resource account creating  |
+|  selling_resource  |  Key, Signer, Writable  |  Uninitialized account  |
+|  selling_resource_owner  |  Key  |  Key which can withdraw MasterEdition once sale is ended  |
+|  resource_mint  |  Key  |  Mint account Metadata attached to  |
+|  master_edition  |  Key  |  PDA with seeds [“metadata”, tokenMetadataProgramID, resource_mint, “edition”]  |
+|  metadata  |  Key  |  Master edition’s metadata  |
+|  vault  |  Key, Writable  |  Token account to hold resource  |
+|  vault_owner  |  PDA [“mt_vault“, resource_mint.key(), store.key()]  |  Owner of vault token account  |
+|  resource_token  |  Key, Writable  |  User’s token account which holds token from resource_mint  |
+|  max_supply  |  `Option<u64>`  |  Max amount of tokens to sell  |
+
+## CreateMarket
+
+Initialize Market account. Set state to Created, it means that owner can change some data before it will be activated, off course if Market marked as mutable.
+
+:::warning
+
+If user want sell art for native SOL as `treasury_mint` should be set `11111111111111111111111111111111` also treasury_holder and treasury_owner should be the same accounts PDA. It’s necessary for security reasons so only program will be able to spend that SOL.
+
+:::
+
+| Parameter      | Type |Description|
+| ----------- | ----------- | ------ |
+|  market  |  Key, Signer, Writable  |  Uninitialized account  |
+|  store  |  Key  |    |
+|  selling_resource_owner  |  Key, Signer, Writable  |    |
+|  selling_resource  |  Key, Writable  |    |
+|  treasury_mint  |  Key  |  Mint of assets which we will take as a payment  |
+|  treasury_holder  |  Key  |  Token account  |
+|  treasury_owner  |  PDA [“holder“, treasury_mint.key(), selling_resource.key()]  |    |
+|  name  |  `String`  |    |
+|  description  |  `String`  |    |
+|  mutable  |  `bool`  |    |
+|  price  |  `u64`  |    |
+|  pieces_in_one_wallet  |  `Option<u64>`  |    |
+|  start_date  |  `u64`  |    |
+|  end_date  |  `Option<u64>`  |    |
+|  gating_config  |  `Option<GatingConfig{collection: Pubkey, expire_on_use: bool, gating_time: Option<u64>}>`  |  Gating token. If this value set only users with NFT from pointed collection can buy new NFTs from market.  |
+
+## ChangeMarket
+
+Available only if Market::mutable == true. Can change: name, description, mutable, price, pieces_in_one_wallet.
+
+| Parameter      | Type |Description|
+| ----------- | ----------- | ------ |
+|  market  |  Key, Writable  |    |
+|  market_owner  |  Key, Signer  |    |
+|  new_name  |  `Option<String>`  |    |
+|  new_description  |  `Option<String>`  |    |
+|  mutable  |  `Option<bool>`  |    |
+|  new_price  |  `Option<u64>`  |    |
+|  new_pieces_in_one_wallet  |  `Option<u64>`  |    |
+
+## Buy
+
+User can call only if current date > Market::start_date.
+
+:::warning
+
+If user buy art for native SOL user_token_acc and user_wallet accounts should be the same.
+
+:::
+
+| Parameter      | Type |Description|
+| ----------- | ----------- | ------ |
+|  market  |  Key, Writable  |    |
+|  selling_resource  |  Key, Writable  |    |
+|  user_token_acc  |  Key, Writable  |  Token account to pay for the member token. Mint of this token acc should be == treasury_mint  |
+|  user_wallet  |  Key, Signer, Writable  |    |
+|  trade_history  |  Key, Writable  |  Account to track how many NFTs user already bought  |
+|  treasury_holder  |  Key, Writable  |    |
+|  new_metadata_acc  |  Key, Writable  |    |
+|  new_edition_acc  |  Key, Writable  |    |
+|  master_edition_acc  |  Key, Writable  |    |
+|  new_mint  |  Key, Writable  |    |
+|  edition_marker  |  Key, Writable  |  PDA, seeds can be found in token-metadata program  |
+|  vault  |  Key  |    |
+|  vault_owner  |  PDA [“mt_vault“, resource.key(), store.key()]  |    |
+|  master_edition_metadata  |  Key  |    |
+|    |  Below accounts are optional and should be passed only if gating feature is enabled ↓  |    |
+|  user_collection_token_account  |  Key, Writable  |  User’s token account from collection  |
+|  token_account_mint  |  Key, Writable  |  Token’s mint account  |
+|  metadata_account  |  Key  |  Metadata account for the mint mentioned above  |
+
+## SuspendMarket
+
+Suspend Market so nobody can buy items and market owner can change data. Instruction should be available only if Market::mutable == true because in other case there is no reason to suspend it.
+
+| Parameter      | Type |Description|
+| ----------- | ----------- | ------ |
+|  market  |  Key, Writable  |    |
+|  market_owner  |  Key, Signer  |    |
+|  clock  |  Key  |    |
+
+## ResumeMarket
+
+Instruction to resume the market after it was suspended. Can be called only if market is in suspended state.
+
+| Parameter      | Type |Description|
+| ----------- | ----------- | ------ |
+|  market  |  Key, Writable  |    |
+|  market_owner  |  Key, Signer  |    |
+|  clock  |  Key  |    |
+
+## CloseMarket
+
+This instruction can be called only if Market was created with unlimited duration.
+
+| Parameter      | Type |Description|
+| ----------- | ----------- | ------ |
+|  market  |  Key, Writable  |    |
+|  market_owner  |  Key, Signer  |    |
+|  clock  |  Key  |    |
+
+## Withdraw
+
+Called by Market owner to withdraw collected treasury funds. Available only if Market::state == Ended.
+
+| Parameter      | Type |Description|
+| ----------- | ----------- | ------ |
+|  market  |  Key  |    |
+|  selling_resource  |  Key  |    |
+|  metadata  |  Key  |    |
+|  treasury_holder  |  Key, Writable  |  Market::treasury_holder. Token account which holds all the tokens received from users during selling  |
+|  treasury_mint  |  Key  |    |
+|  funder  |  Key  |    |
+|  payer  |  Key, Signer  |    |
+|  payout_ticket  |  Key, Writable  |  PDA[“payout_ticket“, market.key(), funder.key()]  |
+|  treasury_owner  |  Key  |  PDA[“holder“, treasury_mint.key(), selling_resource.key()]  |
+|  destination  |  Key, Writable  |  Token account transfer tokens to  |
+|    |  Below account is optional and should be passed only during primary sale ↓  |    |
+|  primary_metadata_creators_data  |  Key  |  List of creators who should receive royalties from primary sale  |
+
+## ClaimResource
+
+Called by Resource owner. Available only if SellingResource::state == Exhausted of Market::state == Ended.
+
+| Parameter      | Type |Description|
+| ----------- | ----------- | ------ |
+|  market  |  Key  |    |
+|  treasury_holder  |  Key  |    |
+|  selling_resource  |  Key  |    |
+|  selling_resource_owner  |  Key, Signer  |    |
+|  source  |  Key, Writable  |  SellingResource::vault. Token account which holds master edition  |
+|  metadata  |  Key  |  Metadata for token which was sold  |
+|  vault_owner  |  Key  |  PDA with seeds [“mt_vault“, resource.key(), store.key()]  |
+|  secondary_metadata_creators  |  Key  |    |
+|  destination  |  Key, Writable  |  Token account transfer master edition to  |
+
+## SavePrimaryMetadataCreators
+
+Called before market is created. This list of creators will be used in withdraw instruction to distribute royalties. Take a note that if you are going to sell NFTs from master edition with `primary_sale_happen = true` you don't need to call this instruction.
+
+| Parameter      | Type |Description|
+| ----------- | ----------- | ------ |
+|  admin  |  Key, Signer, Writable  |  Metadata’s update authority  |
+|  metadata  |  Key, Writable  |    |
+|  primary_metadata_creators  |  Key, Writable  |  PDA with seeds [“primary_creators“, metadata.key()]  |
+|  system_program  |  Key  |    |
+|  primary_metadata_creators  |  `u8`  |  primary_metadata_creators key bump  |
+|  creators  |  `Vec<mpl_token_metadata::state::Creator>`  |  List of creators who will receive primary royalties  |

src/pages/legacy-documentation/gumdrop.md

@@ -0,0 +1,23 @@
+---
+title: Gumdrop
+metaTitle: Gumdrop
+description: Easy token airdrops and print edition airdrops, without requiring high up-front rent costs
+---
+
+{% callout type="warning" %}
+
+Please note that this program is marked as deprecated and is no longer actively maintained by the Metaplex Foundation team. New features, security fixes and backward compatibility are not guaranteed. Please use with caution.
+
+{% /callout %}
+
+The Gumdrop program enables easy token airdrops and print edition airdrops, without requiring high up-front rent costs.
+Originally pioneered for token airdrops by [Uniswap](https://github.com/Uniswap/merkle-distributor) and ported to Solana
+by [Saber](https://github.com/saber-hq/merkle-distributor), is extended to allow printing editions of a master copy.
+Moreover, Gumdrop allows creators to directly send whitelisted users a drop reclamation link by building the tree with
+off-chain handles (e.g email, discord, etc.) and allowing the user to redeem into any wallet.
+
+🔗 **Helpful links:**
+
+- [Gumdrop CLI/UI](https://github.com/metaplex-foundation/gumdrop)
+- [GitHub Repository](https://github.com/metaplex-foundation/metaplex-program-library/tree/master/gumdrop)
+- [Gumdrop Guide by Mark Sackerberg](https://www.sackerberg.dev/blog/gumdrop)

src/pages/legacy-documentation/index.md

@@ -0,0 +1,23 @@
+---
+title: Overview
+metaTitle: Legacy Documentation - Overview
+description: A collection of documentation of older Programs and Tools which might not be used anymore or deprecated. Migrated from our old docs for documentation for completeness.
+---
+
+A collection of documentation of older Programs and Tools which might not be used anymore or deprecated. Migrated from our old docs for documentation for completeness. {% .lead %}
+
+{% quick-links %}
+
+{% quick-link title="Auction House" icon="BookOpen" href="/legacy-documentation/auction-house" description="Allows users to exchange assets within the Solana blockchain." /%}
+
+{% quick-link title="Fixed Price Sale" icon="BookOpen" href="/legacy-documentation/fixed-price-sale" description="Sell NFTs at a fixed price by minting print editions from a single master edition." /%}
+
+{% quick-link title="Gumdrop" icon="BookOpen" href="/legacy-documentation/gumdrop" description="Let your community claim tokens instead of having to airdrop them and paying the fees yourself." /%}
+
+{% quick-link title="Token Entangler" icon="BookOpen" href="/legacy-documentation/token-entangler" description="Entangle NFTs with each other. E.g. to derug projects or fix ones with messed up immutable metadata." /%}
+
+{% quick-link title="Mobile SDKs" icon="CodeBracketSquare" href="/legacy-documentation/sdks" description="Probably helpful when looking into Android or iOS Development." /%}
+
+{% quick-link title="Developer Tools" icon="CodeBracketSquare" href="/legacy-documentation/developer-tools" description="Some older developer tools that might still help you along the way." /%}
+
+{% /quick-links %}

src/pages/legacy-documentation/mobile-sdks/android.md

@@ -0,0 +1,264 @@
+---
+title: Android SDK
+metaTitle: Android SDK
+description: Metaplex Android SDK
+---
+
+The Metaplex Android SDK is a library that allows you to:
+
+- Load and Deserialize Accounts
+- Create transactions
+- Run Actions (mint NFT, create an auction, and so on)
+
+It works both in Android and other platforms that support kotlin.
+
+## Stability
+
+[Stability 1 - Experimental](/stability-index)
+
+This project is in development. **All** interfaces are _very likely_ to change very frequently. Please use caution when making use of this library. Bugs or behavior changes may surprise users when Experimental API modifications occur.
+
+## References
+
+- [Source code][github]
+
+## Getting started
+
+### Installation
+#### Requirements {#requirements}
+
+- Android 21+
+
+We recommend using the GitHub recommended way to load Artifacts. First get a GitHub Token from your [account settings](https://github.com/settings/tokens).
+
+Inside settings.gradle add a maven repository:
+
+```
+repositories {
+	...
+	maven {
+       name = "GitHubPackages"
+       url = "https://github.com/metaplex-foundation/metaplex-android"
+       credentials {
+		   username = "<YOUR_GITHUB_USERNAME>"
+		   password = "<YOUR_GITHUB_TOKENS>"
+       }
+	}
+}
+ 
+```
+
+Then at your build.gradle:
+
+```
+dependencies {
+	...
+	implementation 'com.metaplex:metaplex:+' // Set version
+}
+```
+
+After that gradle sync.
+
+## JitPack Release
+
+The library is now is available through JitPack.io
+
+First, add the JitPack repository to your build:
+```
+
+repositories {
+	...
+	maven { url 'https://jitpack.io' }
+}
+
+```
+Then add the dependency to the 'build.gradle' file for your app/module:
+```
+dependencies {
+	...
+	implementation 'com.github.metaplex-foundation:metaplex-android:{version}'
+}
+```
+
+## Setup
+
+The entry point to the Android SDK is a `Metaplex` instance that will give you access to its API.
+
+Set the `SolanaConnectionDriver` and set up your environment. Provide a `StorageDriver` and `IdentityDriver`. You can also use the concrete implementations OkHttpSharedStorageDriver for OKHttp and ReadOnlyIdentityDriver for a read only Identity Driver. 
+
+You can customize who the SDK should interact on behalf of and which storage provider to use when uploading assets. We might provide a default and simple implementation in the future.
+
+```kotlin
+val ownerPublicKey = PublicKey("<Any PublicKey>")
+val solanaConnection = SolanaConnectionDriver(RPCEndpoint.mainnetBetaSolana)
+val solanaIdentityDriver = ReadOnlyIdentityDriver(ownerPublicKey, solanaConnection.solanaRPC)
+val storageDriver = OkHttpSharedStorageDriver()
+val metaplex = Metaplex(solanaConnection, solanaIdentityDriver, storageDriver)
+```
+
+# Usage
+Once properly configured, that `Metaplex` instance can be used to access modules providing different sets of features. Currently, there is only one NFT module that can be accessed via the `nft` property. From that module, you will be able to find, create and update NFTs with more features to come.
+
+## NFTs
+The NFT module can be accessed via `Metaplex.nft` and provide the following methods. Currently, we only support reading methods. Writing and creating NFTs will be supported on the future.
+
+- findByMint(mint, callback)
+- findAllByMintList(mints, callback)
+- findAllByOwner(owner, callback)
+- findAllByCreator(creator, position = 1, callback)
+- findAllByCandyMachine(candyMachine, version = 2, callback)
+
+All the methods return a callback. It's also possible to wrap them inside either RX or Async Result. We only provide this interface since is the most compatible without forcing any specific framework. 
+
+### Your first request
+
+The following code snippet is a basic one you can use to get NFTs from a publicKey. This use case maybe very common for a Wallet:
+
+```kotlin
+metaplex.nft.findByMint(mintPublicKey){
+	it.onSuccess { 
+		...
+	}.onFailure { 
+		...
+	}
+}
+```
+
+This will return an array of NFTs owned by that specific public key.
+
+### The `Nft` model
+
+All of the methods above either return or interact with an `Nft` object. The `Nft` object is a read-only data representation of your NFT that contains all the information you need at the top level.
+
+You can see its full data representation by checking the code but here is an overview of the properties that are available on the `Nft` object.
+
+```kotlin
+class NFT(
+    val metadataAccount: MetadataAccount,
+    val masterEditionAccount: MasterEditionAccount?
+) {
+
+    val updateAuthority: PublicKey = metadataAccount.update_authority
+    val mint: PublicKey = metadataAccount.mint
+    val name: String = metadataAccount.data.name
+    val symbol: String = metadataAccount.data.symbol
+    val uri: String = metadataAccount.data.uri
+    val sellerFeeBasisPoints: Int = metadataAccount.data.sellerFeeBasisPoints
+    val creators: Array<MetaplexCreator> = metadataAccount.data.creators
+    val primarySaleHappened: Boolean = metadataAccount.primarySaleHappened
+    val isMutable: Boolean = metadataAccount.isMutable
+    val editionNonce: Int? = metadataAccount.editionNonce
+    val tokenStandard: MetaplexTokenStandard? = metadataAccount.tokenStandard
+    val collection: MetaplexCollection? = metadataAccount.collection
+	...
+}
+```
+
+As you can see, some of the properties are loaded on demand. This is because they are not always needed and/or can be expensive to load.
+
+In order to load these properties, you may run the `metadata` properties of the `Nft` object.
+
+```kotlin
+nft..metadata(metaplex) { result -> 
+	it.onSuccess { 
+		...
+	}.onFailure { 
+		...
+	}
+}
+```
+
+## Auctions
+The Metaplex Auction House protocol allows anyone to implement a decentralized sales contract and accept ay SPL token they desire. 
+
+The Auctions module can be accessed via `Metaplex.auctions` and provide the following methods. Currently we only support read methods. Auction House creation, and the ability to interact with and create bids and listings will be supported in the future.
+
+- [`findAuctionHouseByAddress(address)`](#findAuctionHouseByAddress)
+- [`findAuctionHouseByCreatorAndMint(creator, treasuryMint)`](#findAllByMintList)
+- more coming soon!
+
+All methods are provided as composable [suspending functions](https://kotlinlang.org/docs/composing-suspending-functions.html) to provide more flexibility and compatibility in your application.   
+
+**Note:** These suspend functions provided by the Auctions API are an architectural change for the library. We have previously only provided async-callback methods. We highly recommend that everyone migrate to the new suspending functions, however we have also provided async-callback implementations of the available methods. Note that these methods are provided as a interim and may be deprecated in the future:
+
+- [`findAuctionHouseByAddress(address, callback)`](#findAuctionHouseByAddress)
+- [`findAuctionHouseByCreatorAndMint(creator, treasuryMint, callback)`](#findAllByMintList)
+
+### findAuctionHouseByAddress
+
+The `findAuctionHouseByAddress` method accepts a public key and returns an AuctionHouse object, or an error if no AuctionHouse was found for the given address.
+
+```kotlin
+val theAuctionHouse: AuctionHouse? = metaplex.auctions.findAuctionHouseByAddress(addressPublicKey).getOrNull()
+```
+
+### findAuctionHouseByCreatorAndMint
+
+The `findAuctionHouseByCreatorAndMint` method accepts a public key and returns an AuctionHouse object, or an error if no AuctionHouse was found for the given address.
+
+```kotlin
+val theAuctionHouse: AuctionHouse? = metaplex.auctions.findAuctionHouseByCreatorAndMint(creatorPublicKey, mintPublicKey).getOrNull()
+```
+
+The returned `AuctionHouse` model will contain details about the Auction House account on chain. In the future, this model will be used to construct an `AuctionHouseClient` instance to interact with the auction and perform trades. 
+
+## Identity
+The current identity of a `Metaplex` instance can be accessed via `metaplex.identity()` and provide information on the wallet we are acting on behalf of when interacting with the SDK.
+
+This method returns an identity object with the following interface. All the methods required a solana api instance
+
+```kotlin
+interface IdentityDriver {
+    val publicKey: PublicKey
+    fun sendTransaction(transaction: Transaction, recentBlockHash: String? = null, onComplete: ((Result<String>) -> Unit))
+    fun signTransaction(transaction: Transaction, onComplete: (Result<Transaction>) -> Unit)
+    fun signAllTransactions(transactions: List<Transaction>, onComplete: (Result<List<Transaction?>>) -> Unit)
+}
+```
+
+The implementation of these methods depends on the concrete identity driver being used. For example use a KeypairIdentity or a Guest(no publickey added)
+
+Let’s have a quick look at the concrete identity drivers available to us.
+
+### GuestIdentityDriver
+
+The `GuestIdentityDriver` driver is the simplest identity driver. It is essentially a `null` driver that can be useful when we don’t need to send any signed transactions. It will return failure if you use `signTransaction` methods.
+
+
+### KeypairIdentityDriver
+
+The `KeypairIdentityDriver` driver accepts a `Account` object as a parameter.
+
+
+### ReadOnlyIdentityDriver
+
+The `KeypairIdentityDriver` driver accepts a `PublicKey` object as a parameter. It's a read only similar to the GUestIdentity, but it has a provided `PublicKey`. It will return failure if you use `signTransaction` methods.
+
+## Storage
+
+You may access the current storage driver using `metaplex.storage()` which will give you access to the following interface.
+
+```kotlin
+interface StorageDriver {
+    fun download(url: URL, onComplete: (ResultWithCustomError<NetworkingResponse, StorageDriverError>) -> Unit)
+}
+```
+
+Currently its only used to retrieve json data off-chain. 
+
+### OkHttpSharedStorageDriver
+
+This will use OkHttp networking. Which is the most popular Android networking implementation library. This maybe the most useful implementation.
+
+### MemoryStorageDriver
+
+This will use return Empty Data object with 0 size. 
+
+## Sample app
+
+The SDK comes with a [sample app](https://github.com/metaplex-foundation/metaplex-android/tree/main/sample). Please clone it run it on your phone and take what is can help you. 
+
+[github]: https://github.com/metaplex-foundation/metaplex-android
+[sample]: https://github.com/metaplex-foundation/metaplex-android/tree/main/sample
+
+

src/pages/legacy-documentation/mobile-sdks/ios.md

@@ -0,0 +1,189 @@
+---
+title: iOS SDK
+metaTitle: iOS SDK
+description: Metaplex iOS SDK
+---
+
+The [Metaplex iOS SDK][docs] is a library that allows you to:
+
+- Load and Deserialize Accounts
+- Create transactions
+- Run Actions (mint NFT, create an auction, and so on)
+
+It works both in iOS and other Apple platforms that support Swift.
+
+## Stability
+
+[Stability 1 - Experimental](/stability-index)
+
+This project is in active development. **All** interfaces are _very likely_ to change very frequently. Please use caution when making use of this library. Bugs or behavior changes may surprise users when Experimental API modifications occur.
+
+## References
+
+- [API documentation][docs]
+- [Source code][github]
+
+## Getting started
+
+### Installation
+#### Requirements {#requirements}
+
+- iOS 11.0+ / macOS 10.13+ / tvOS 11.0+ / watchOS 3.0+
+- Swift 5.3+
+
+From Xcode 11, you can use [Swift Package Manager](https://swift.org/package-manager/) to add Solana.swift to your project.
+
+- File > Swift Packages > Add Package Dependency
+- Add `https://github.com/metaplex-foundation/metaplex-ios`
+- Select "branch" with "master"
+- Select Metaplex
+
+If you encounter any problems or have a question on adding the package to an Xcode project, I suggest reading the [Adding Package Dependencies to Your App](https://developer.apple.com/documentation/xcode/adding_package_dependencies_to_your_app) guide article from Apple.
+
+### Setup
+The entry point to the Swift SDK is a `Metaplex` instance that will give you access to its API.
+
+Set the `SolanaConnectionDriver` and set up your environment. Provide a `StorageDriver` and `IdentityDriver`. You can also use the concrete implementations URLSharedStorageDriver for URLShared and GuestIdentityDriver for a guest Identity Driver. 
+
+You can customise who the SDK should interact on behalf of and which storage provider to use when uploading assets. We might provide a default and simple implementation in the future.
+
+```swift
+let solanaDriver = SolanaConnectionDriver(endpoint: RPCEndpoint.mainnetBetaSolana)
+let identityDriver = GuestIdentityDriver(solanaRPC: solana.solanaRPC)
+let storageDriver = URLSharedStorageDriver(urlSession: URLSession.shared)
+let metaplex Metaplex(connection: solana, identityDriver: identityDriver, storageDriver: storageDriver)
+```
+
+# Usage
+Once properly configured, that `Metaplex` instance can be used to access modules providing different sets of features. Currently, there is only one NFT module that can be accessed via the `nfts()` method. From that module, you will be able to find, create and update NFTs with more features to come.
+
+## NFTs
+The NFT module can be accessed via `Metaplex.nfts()` and provide the following methods. Currently, we only support reading methods. Writing and creating NFTs will be supported in the future.
+
+- findNftByMint(mint, callback)
+- findNftByMintList(mints, callback)
+- findNftsByOwner(owner, callback)
+- findNftsByCreator(creator, position = 1, callback)
+- findNftsByCandyMachine(candyMachine, version = 2, callback)
+
+All the methods return a callback. It's also possible to wrap them inside either RX, and async Result or Combine. We only provide this interface since is the most compatible without forcing any specific framework. 
+
+### Your first request
+
+The following code snippet is a basic one you can use to get NFTs from a publicKey. This use case maybe very common for a wallet:
+
+```swift
+let ownerPublicKey = PublicKey(string: "5LeMDmNW6bQFWQjMhcTZnp6LVHTQQfUpY9jn6YH6RpyE")!
+metaplex.nft.findNftsByOwner(publicKey: ownerPublicKey) { [weak self] result in
+	switch result {
+		case .success(let nftList):
+			break
+		case .failure:
+			break
+	}
+}
+```
+
+This will return an array of NFTs owned by that specific public key.
+
+### The `Nft` model
+
+All the methods above either return or interact with an `Nft` object. The `Nft` object is a read-only data representation of your NFT that contains all the information you need at the top level.
+
+You can see its full data representation by checking the code but here is an overview of the properties that are available on the `Nft` object.
+
+```swift
+// Always loaded.
+public let metadataAccount: MetadataAccount
+    
+public let updateAuthority: PublicKey
+public let mint: PublicKey
+public let name: String
+public let symbol: String
+public let uri: String
+public let sellerFeeBasisPoints: UInt16
+public let creators: [MetaplexCreator]
+public let primarySaleHappened: Bool
+public let isMutable: Bool
+public let editionNonce: UInt8?
+
+// Sometimes loaded.
+public let masterEditionAccount: MasterEditionAccount?
+```
+
+As you can see, some properties are loaded on demand. This is because they are not always needed and/or can be expensive to load.
+
+In order to load these properties, you may run the `metadata` properties of the `Nft` object.
+
+```swift
+nft.metadata(metaplex: self.metaplex) { result in
+    switch result {
+    case .success(let metadata):
+        ...
+    case .failure:
+        ...
+    }
+}
+```
+
+## Identity
+The current identity of a `Metaplex` instance can be accessed via `metaplex.identity()` and provide information on the wallet we are acting on behalf of when interacting with the SDK.
+
+This method returns an identity object with the following interface. All the methods required a solana api instance
+
+```swift
+public protocol IdentityDriver {
+    var publicKey: PublicKey { get }
+    func sendTransaction(serializedTransaction: String, onComplete: @escaping(Result<TransactionID, IdentityDriverError>) -> Void)
+    func signTransaction(transaction: Transaction, onComplete: @escaping (Result<Transaction, IdentityDriverError>) -> Void)
+    func signAllTransactions(transactions: [Transaction], onComplete: @escaping (Result<[Transaction?], IdentityDriverError>) -> Void)
+}
+```
+
+The implementation of these methods depends on the concrete identity driver being used. For example, using a KeypairIdentity or a Guest (no publickey added).
+
+Let’s have a quick look at the concrete identity drivers available to us.
+
+### GuestIdentityDriver
+
+The `GuestIdentityDriver` driver is the simplest identity driver. It is essentially a `null` driver that can be useful when we don’t need to send any signed transactions. It will return failure if you use `signTransaction` methods.
+
+
+### KeypairIdentityDriver
+
+The `KeypairIdentityDriver` driver accepts a `Account` object as a parameter.
+
+
+### ReadOnlyIdentityDriver
+
+The `KeypairIdentityDriver` driver accepts a `PublicKey` object as a parameter. It's a read only similar to the GuestIdentity, but it has a provided `PublicKey`. It will return failure if you use `signTransaction` methods.
+
+## Storage
+
+You may access the current storage driver using `metaplex.storage()` which will give you access to the following interface.
+
+```swift
+public protocol StorageDriver {
+    func download(url: URL, onComplete: @escaping(Result<NetworkingResponse, StorageDriverError>) -> Void)
+}
+```
+
+Currently, it's only used to retrieve json data off-chain. 
+
+### URLSharedStorageDriver
+
+This will use URLShared networking. Which is the default iOS networking implementation. This maybe the most useful call.
+
+### MemoryStorageDriver
+
+This will use return Empty Data object with 0 size. 
+
+## Sample app
+
+The SDK comes with a [sample app][sample]. Please clone it run it on your phone and take what is can help you. 
+
+[github]: https://github.com/metaplex-foundation/metaplex-ios
+[docs]: https://github.com/metaplex-foundation/metaplex-ios#metaplex-ios-sdk
+[sample]: https://github.com/metaplex-foundation/metaplex-ios/tree/main/Sample
+
+

src/pages/legacy-documentation/token-entangler.md

@@ -0,0 +1,58 @@
+# Overview
+
+{% callout type="warning" %}
+
+Please note that this program is marked as deprecated and is no longer actively maintained by the Metaplex Foundation team. New features, security fixes and backward compatibility are not guaranteed. Please use with caution.
+
+{% /callout %}
+
+## Introduction
+
+Metaplex's Token Entangler program is pulled straight out of quantum mechanics! It enables you to entangle two NFTs together and make it so only one can exist in the wild at a time (and can always be exchanged with the entangled NFT). This could be useful to **'de-rug'** projects by replacing all the rugged NFTs with a new non-rug set. That's also the reason for Token Entanglers creation: To help the Exiled Apes community after the Degen Ape Academy’s erroneous mint. You can find more about the back story on the exiled apes website.
+
+The idea behind the program was that the initially minted NFTs with damaged metadata could be swapped to new NFTs containing proper metadata. It could also be used for derugging projects or more creative use cases.
+
+These swaps are possible back and forth at any given time, even if the NFT that is not in the escrow currently is sold to a different wallet the new wallet will be able to swap it back again.
+
+## Opportunities
+
+The Token Entangler Program is very simple. It takes a NFT A and returns the NFT B which has already been assigned to NFT A on token entangler creation. Nevertheless there are some opportunities which might be interesting for you:
+
+- **Swap back and Forth**: If the user swaps NFT A for NFT B he can always reverse that swap again.
+- **Swapping Fee**: You can introduce a swapping fee that is either paid every time a token is swapped or only once per NFT pair.
+- **SPL token fee**: The swapping fee can either be paid with SPL tokens or SOL.
+
+## How it works
+
+The user facing process is easy. They pay the Token Entangler with NFT A and (if configured SOL or SPL tokens) and receive the entangled mint B:
+
+![Image showing the general Token Entangler process. It shows a Wallet and the Token Entangler Program as a box. The boxes are connected with two arrows. One from Wallet to Entangler with annotation "NFT A + SOL" and another one from Entangler to Wallet with annotation "NFT B"](https://github.com/metaplex-foundation/docs/blob/main/static/assets/programs/token-entangler/Token-Entangler-Overview-Process.png?raw=true)
+
+This is a very reduced picture that just shows the user facing process. There are additional Accounts etc. that are not shown in this image.
+
+## Create your own!
+
+The start to end from a general point of view looks like this:
+
+1. Mint the new Tokens
+2. Entangle the old and new NFTs
+3. Host a customer facing website. There is a [sample UI implementation](https://github.com/metaplex-foundation/token-entangler-ui)
+4. Have your users swap their NFTs!
+
+## Further Information
+
+More general information about the Token Entangler Program can be found here in the documentation:
+
+- Getting Started
+- Accounts
+- Instructions
+- CLI
+- FAQ
+- Changelog
+
+If you want to use the Token Entangler you can e.g. use
+
+- [JS CLI](https://github.com/metaplex-foundation/deprecated-clis/blob/main/src/token-entangler-cli.ts)
+- [Token Entangler UI](https://github.com/metaplex-foundation/token-entangler-ui)
+
+Also feel free to Checkout the [GitHub Repository](https://github.com/metaplex-foundation/metaplex-program-library/tree/master/token-entangler/) if you want to look into Token Entangler code.