adding versioning

config-typedoc-core.js

@@ -74,22 +74,22 @@ const darkCodeTheme = require('prism-react-renderer/themes/dracula');
         },
         items: [
           {
-            to: "docs/next/Concepts/welcome",
+            to: "docs/2.0/Concepts/welcome",
             label: "📖 Concepts",
             position: "left",
           },
           {
-            to: "docs/next/Tutorials/welcome",
+            to: "docs/2.0/Tutorials/welcome",
             label: "📚 Tutorials",
             position: "left",
           },
           {
-            to: "docs/next/KeypomV2/welcome",
+            to: "docs/2.0/KeypomV2/welcome",
             label: "🤖 Keypom V2",
             position: "left",
           },
           {
-            to: "docs/next/keypom-sdk/welcome",
+            to: "docs/2.0/keypom-sdk/welcome",
             label: "💻 SDK TypeDocs",
             position: "left",
           },
@@ -120,15 +120,15 @@ const darkCodeTheme = require('prism-react-renderer/themes/dracula');
             items: [
               {
                 label: '📖Concepts',
-                to: 'docs/next/Concepts/welcome',
+                to: 'docs/2.0/Concepts/welcome',
               },
               {
                 label: '📚Tutorials',
-                to: 'docs/next/Tutorials/welcome',
+                to: 'docs/2.0/Tutorials/welcome',
               },
               {
                 label: "🤖Keypom V2",
-                to: "docs/next/KeypomV2/welcome",
+                to: "docs/2.0/KeypomV2/welcome",
               },
             ],
           },

config-typedoc-selector.js

@@ -74,22 +74,22 @@ const darkCodeTheme = require('prism-react-renderer/themes/dracula');
         },
         items: [
           {
-            to: "docs/next/Concepts/welcome",
+            to: "docs/2.0/Concepts/welcome",
             label: "📖 Concepts",
             position: "left",
           },
           {
-            to: "docs/next/Tutorials/welcome",
+            to: "docs/2.0/Tutorials/welcome",
             label: "📚 Tutorials",
             position: "left",
           },
           {
-            to: "docs/next/KeypomV2/welcome",
+            to: "docs/2.0/KeypomV2/welcome",
             label: "🤖 Keypom V2",
             position: "left",
           },
           {
-            to: "docs/next/keypom-sdk/welcome",
+            to: "docs/2.0/keypom-sdk/welcome",
             label: "💻 SDK TypeDocs",
             position: "left",
           },
@@ -120,15 +120,15 @@ const darkCodeTheme = require('prism-react-renderer/themes/dracula');
             items: [
               {
                 label: '📖Concepts',
-                to: 'docs/next/Concepts/welcome',
+                to: 'docs/2.0/Concepts/welcome',
               },
               {
                 label: '📚Tutorials',
-                to: 'docs/next/Tutorials/welcome',
+                to: 'docs/2.0/Tutorials/welcome',
               },
               {
                 label: "🤖Keypom V2",
-                to: "docs/next/KeypomV2/welcome",
+                to: "docs/2.0/KeypomV2/welcome",
               },
             ],
           },

docs/Concepts/KeypomProtocol/Assets/asset-types.md

@@ -0,0 +1,72 @@
+---
+sidebar_label: 'Asset Types'
+---
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+import Admonition from '@theme/Admonition';
+
+# Asset Types
+## Basics
+
+<Admonition type="tip" icon="💡" title="Key Concept">
+In the Keypom Protocol, an asset is something that is attached to every key in your drop. When someone obtains and uses a key, they will receive the assets - either to a new or existing account. 
+</Admonition>
+
+Assets are meant to create new experience and bring value to your users. There can be any number of mixed and matched assets for each key use. Assets can take on the following types: 
+
+* **NEAR**
+* **Fungible Tokens**
+* **Non-Fungible Tokens**
+* **Function Calls** 
+
+Each key in a drop holds the same assets, meaning a user can receive any key from the drop and be guarenteed the same set of assets. 
+
+Access Keys can have multiple uses and their assets are defined **per use**. These can be mix-and-matched to craft any experience you want. An example can be seen below:
+
+
+
+
+| **Key Use** | **Assets**                        |
+|-------------|-----------------------------------|
+| 1           | NEAR, FunctionCall, Fungible Token|
+| 2           | Non-Fungible Token                |
+| 3           | Fungible Token, NEAR              |
+
+
+This means when the user claims their key for the first time, they will receive some FTs, some NEAR and call a set of functions. On the second claim, they will receive an NFT while on the third and final claim, they will receive some NEAR and FTs. 
+
+New with Keypom V3, you can mix-and-match and add multiple different types of assets per use, for as many key uses/claims as you want! 
+
+<div class="container">
+  <div class="row">
+    <div class="col">
+      <a href="basic-assets">
+        <div class="card h-100 card-body">
+          <div class="card__body">
+            <h3 class="small-bottom-padding">NEAR, NFT, & FT Assets</h3>
+            <p class="neutraltext">Add value to your drop using tokens!</p>
+          </div>
+        </div>
+      </a>
+    </div>
+    <div class="col">
+      <a href="function-call">
+        <div class="card h-100 card-body">
+          <div class="card__body">
+            <h3 class="small-bottom-padding">Function Call Assets</h3>
+              <p class="neutraltext">Call any NEAR smart contract </p>
+          </div>
+        </div>
+      </a>
+    </div>
+  </div>
+</div>
+
+___
+
+## Defining vs Funding Assets
+An important distinction to be made is the difference between defining and funding assets. Defining an asset is similar to creating a blueprint for your drop while funding is the process of building it.
+
+:::caution
+If assets are not properly funded, your drop may not perform as expected. Proper funding is formally defined in [next section](basic-assets.md).
+:::

docs/Concepts/KeypomProtocol/Assets/basic-assets.md

@@ -0,0 +1,150 @@
+---
+sidebar_label: 'NEAR, NFT, & FT Assets'
+---
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+import Admonition from '@theme/Admonition';
+
+# NEAR, NFT, & FT Assets
+<Admonition type="tip" icon="💡" title="Key Concept">
+For every use on a Key, the different types of assets can be mixed to create an infinite number of experiences! 
+</Admonition>
+
+## Defining vs Funding Assets
+An important distinction to be made is the difference between defining and funding assets. Defining an asset is similar to creating a blueprint for your drop while funding is the process of building it.
+
+* ***Defining an Asset***: The process of creating a drop and outlining the behaviour expected for your keys. At this point, you've created a blueprint of your drop's expected assets but have not built it out. 
+
+* ***Funding an Asset***: Transferring ownership of defined assets to Keypom so that they can be redeemed by users claiming your keys.
+
+Once a drop's assets have been defined and funded, keys can be used properly. 
+
+:::caution
+If assets are not properly funded, users of your drop will not receive the assets promised to them. 
+:::
+___
+
+## NEAR Asset
+> A NEAR Asset attaches some NEAR that will be deposited in the user's account when claiming
+
+Whenever a NEAR asset is present in a key use, the user will receive some NEAR for that particular key use. For example, if a key has 2 uses, and a NEAR asset is defined in the first use but not the second, then the user will only receive NEAR the first time they claim their key. 
+
+### Structure
+The structure of a NEAR asset is relatively simple. All that needs to be defined is the amount. Note that if multiple NEAR assets are defined in the same use, the claiming user will receive the sum of `yoctonear` contained in all the NEAR assets.
+<Tabs>
+<TabItem value="KP" label="📚 Protocol">
+
+```rust reference
+https://github.com/keypom/keypom/blob/8f9f8df397cb8cabbda30d1ddffdcddc4a733274/contract/src/models/external/models.rs#L30-L33
+```
+
+</TabItem>
+<TabItem value="KPJS" label="🔑 Keypom SDK">
+
+```ts reference
+https://github.com/keypom/keypom-js/blob/e8c43f4219a79afb3c367296cc90b8d5de977945/src/lib/types/fc.ts#L68-L74
+```
+
+</TabItem>
+</Tabs>
+
+### Funding
+In the case of NEAR assets, defining and funding are synonomous. This is because the drop creation will fail if insufficient NEAR is provided. This NEAR can come from:
+
+* Your [Keypom Balance](../balances.md).
+* An [attached deposit](https://docs.near.org/develop/contracts/environment/#environment-variables) when creating the drop.
+
+___
+
+## NFT Asset
+> A properly funded NFT Asset will allow a user to receive a Non-fungible Token when claiming
+
+Whenever an NFT asset is present and properly funded in a key use, the user will receive an NFT for that particular key use. For example, if a key has 2 uses, and an NFT asset is defined in the first use but not the second, then the user will only receive an NFT the first time they claim their key. 
+
+Note that multiple different tokens can be sent at once by defining additional NFT Assets following the structure below.
+### Structure
+When defining an NFT Asset, only one item needs to be specified:
+* `nft_contract_id`: the contract that the NFT lives on.
+
+<Tabs>
+<TabItem value="KP" label="📚 Protocol">
+
+```rust reference
+https://github.com/keypom/keypom/blob/8f9f8df397cb8cabbda30d1ddffdcddc4a733274/contract/src/models/external/models.rs#L50-L53
+```
+
+</TabItem>
+<TabItem value="KPJS" label="🔑 Keypom SDK">
+
+```ts reference
+https://github.com/keypom/keypom-js/blob/e8c43f4219a79afb3c367296cc90b8d5de977945/src/lib/types/fc.ts#L68-L74
+```
+
+</TabItem>
+</Tabs>
+
+### Funding
+:::caution
+An improperly loaded NFT Asset will result in **no NFT being sent to the user**
+:::
+
+In order to fund an NFT asset, you must transfer it to the Keypom contract: `v3.keypom.near` or `v3.keypom.testnet`. By doing this, you give the Keypom contract the ability to transfer it to the end user when they claim. 
+
+It is important that when transferring, you are transferring from the contract that you defined above. It is also important to include the `dropId` as a `msg`. This tells Keypom to associate the incoming NFT with your drop.
+```js reference
+https://github.com/keypom/keypom/blob/b5ee9ddde16cc604fea2da83c6368e2ea3461b81/__tests__/creation/nft-creation.ava.ts#L189-L199
+```
+In the case where you have multiple NFT Assets, you will need to transfer the appropriate number of NFTs. For example, if you have 5 keys with 2 NFT Assets each, you will need to transfer 10 NFTs to Keypom. 
+
+When claiming, the user will receive the lastest NFT that was transferred to Keypom. 
+
+:::note
+Only a drop's creator can fund its NFT Assets
+:::
+___
+
+## FT Asset
+> A properly funded FT Asset will send the claiming user a predetermined amount of Fungible Tokens
+
+Whenever an FT asset is present and properly funded in a key use, the user will receive a set amount of FTs for that particular key use. For example, if a key has 2 uses, and an FT asset is defined in the first use but not the second, then the user will only receive an the predefined amount of FTs the first time they claim their key. 
+
+Note that multiple different tokens can be sent at once by defining additional NFT Assets following the structure below.
+### Structure
+When defining an FT Asset, a few things need to be defined:
+* *ft_contract_id*: The Fungible Token contract.  
+* *ft_amount*: The amout of Fungible Tokens to be sent. Defined in the smallest divisible unit. For more, see the token's definition of the [decimal value](https://docs.openzeppelin.com/contracts/3.x/erc20#a-note-on-decimals). 
+* *registration_cost*: Specific to each FT contract, this is the cost to register the user on the FT contract. 
+
+<Tabs>
+<TabItem value="KP" label="📚 Protocol">
+
+```rust reference
+https://github.com/keypom/keypom/blob/8a4009be98f263e93d718779983efcdac1b1a9f8/contract/src/models/external/models.rs#L38-L45
+```
+
+</TabItem>
+<TabItem value="KPJS" label="🔑 Keypom SDK">
+
+```ts reference
+https://github.com/keypom/keypom-js/blob/e8c43f4219a79afb3c367296cc90b8d5de977945/src/lib/types/fc.ts#L68-L74
+```
+
+</TabItem>
+</Tabs>
+
+
+### Funding
+:::caution
+An improperly loaded FT Asset will result in **no FTs being sent to the user**
+:::
+
+In order to fund a Fungible Token asset, you must transfer it to the Keypom contract: `v3.keypom.near` or `v3.keypom.testnet`. By doing this, you give the Keypom contract the FT balance necessary to transfer it to the end user when they claim. 
+
+It is important that when transferring, you are transferring from the contract that you defined above. It is also important to include the `dropId` as a `msg`. This tells Keypom to associate the incoming NFT with your drop.
+```js reference
+https://github.com/keypom/keypom/blob/b5ee9ddde16cc604fea2da83c6368e2ea3461b81/__tests__/utils/ft-utils.ts#L17-L28
+```
+:::note
+Anybody can fund a drop's FT Assets
+:::
+___