nft keys, configs, and more

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

@@ -1,14 +1,79 @@
 ---
-sidebar_label: 'Asset Configurations'
+sidebar_label: 'Key Use Configurations'
 ---
 import Admonition from '@theme/Admonition';
 
-# Asset Configurations
+# Key Use Configurations
 
-<Admonition type="tip" icon="💡" title="tip">
-For every use on an Access Key, the different types of assets can be mixed to create an infinite number of experiences! 
-</Admonition>
+> For each set of key uses in your drop, different behaviours can be defined to create unique experiences!
+
+:::info
+These configurations apply to a set of key uses, for global configurations see [drop configurations](../drop-configurations.md)
+:::
+
+# What are Key Use Configurations?
+Key use configuration defines the expected behaviour for a particular key use in the following aspects:
+
+* [**Time Configuration**](#time-configuration): Umbrella configuration for all things related to timing, such as claim periods and intervals
+* [**Claiming Permissions**](#claiming-permissions): Can/must a new account be created when claiming?
+* [**Root Account ID**](#root-account-id): Should accounts created be subaccounts of a particular account?
+* [**Account Creation Arguments**](#account-creation-arguments): Upon account creation, what information should Keypom send to the root account?
+
+The specification for key use configurations can be seen below:
 
 ```rust reference
 https://github.com/keypom/keypom/blob/8f9f8df397cb8cabbda30d1ddffdcddc4a733274/contract/src/models/config.rs#L16-L31
-```
+```
+___
+
+## Root Account ID
+*Default: `near` or `testnet`*  
+
+The `root_account_id` parameter determines which account the newly-created claiming account will be a sub-account of. For example, the default is `near` so all accounts would end in `.near` such as `benji.near`. Changing the `root_account_id` parameter will change the root of all the accounts that users create through `create_account_and_claim` when using your drop.  
+
+### Use cases
+Let's say you have an organization called Moonpom (secretly run by our beloved Pomeranian, Moon) and you want your users want to proudly represent Moonpom!
+
+You set `root_account_id = "moonpom.near"` and now any account created using your linkdrops will take on the form `${YOUR_USERNAME}.moonpom.near`
+
+:::caution Important
+the `root_account_id` **must** have a contract deployed to it that exposes a method `create_account` to create the sub-account. A sample contract can be found [here](https://github.com/near/near-linkdrop/blob/49279e529c254fa7736465b4a39d05cb8f1e5443/src/lib.rs#L130)
+:::
+
+___ 
+
+
+## Claiming Permissions
+*Default: `claim` AND `create_account_and_claim`*  
+
+The `permissions` parameter assigns which claim methods the user can call with the key you give them. They can either call both, or just one. 
+
+### Use case
+Pretend you are hosting a talk about your NEAR dApp: `Kramerly`. Your only goal is to onboard as many *new* users from the audience as possible. If the user already has a NEAR wallet, they shouldn't be able to claim assets and onboard. This is similar to free-trials in Web2 whereby only new users are able to participate.
+
+To do this, you can set the `permissions` parameter to `create_account_and_claim`.
+
+___
+
+## Account Creation Arguments
+*Default: `null`*  
+
+`account_creation_keypom_args` specifies where certain Keypom arguments should be automatically injected by Keypom upon calling `create_account_and_claim`. This should be used when specifying a custom `root_account_id`, where you have control over the exposed `create_account` method.
+
+Similar to function call [`keypom_args`](function-call.md#injecting-keypom-arguments), these arguments are immutable and can only be inserted by Keypom. This means that they can be used to validate incoming `create_account_and_claim` calls and prevent malicious attacks against your `root_account` contract.  
+### Use Case
+At NEARCON 2023, attendees used their Keypom keys as their tickets, and create4d accounts with a starting Fungible Token balance ($NCON) to participate in the on-the-ground economy. To do this, their keys called the NEARCON contract's exposed `create_account` method that instantiates a new account with a given starting $NCON balance.
+
+Say a malicious actor, EvilMoon, wishes to collect $NCON to buy delicious treats. His plan is to create a drop to fraudulently create accounts using the NEARCON contract's exposed `create_account` method without a NEARCON ticket and then sending all the $NCON to himself.
+
+In order to differentiate the official NEARCON tickets from EvilMoon's malicious drop, the NEARCON contract can leverage `account_creation_keypom_args` to receive the `dropId`, and compare it to the expected `dropId` of the official NEARCON tickets. 
+
+```rust reference
+https://github.com/keypom/nearcon-account-factory/blob/d4b0db55b02c37d574f194d91ddd4c5f2bb26576/contract/src/factory.rs#L28-L29
+```
+
+---
+
+## Time Configuration
+### What is it?
+Time configurations dictate when and how frequently a key can be claimed. A deep dive on these configurations can be found in the [Time Configurations section](./time-customization.md). 

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

@@ -7,7 +7,10 @@ import Admonition from '@theme/Admonition';
 
 # Asset Types
 ## Basics
-> In the Keypom Protocol, an asset it something you attach 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 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. They can be one of the following: 
 
@@ -65,10 +68,10 @@ ___
 An important distinction to be made is the difference between defining and funding assets. 
 
 :::caution
-If assets are not properly funded, your drop may not perform as expected. Proper funding is highlighted in each asset type's respective concepts pages and tutorials.
+If assets are not properly funded, your drop may not perform as expected. Proper funding is defined in [next section](basic-assets.md).
 :::
 
-Defining an asset is similar to creating a blueprint for your drop while funding is the process of building it. A more formal definition can be: 
+Defining an asset is similar to creating a blueprint for your drop while funding is the process of building it.
 
-* ***Defining an Asset***: This is the process you go through when creating your drop; you outline a particular asset to be available on certain set of uses. Note that the asset is not actually present in the drop after you've defined it. 
-* ***Funding an Asset***: This happens when you send Keypom the assets required as defined in your drop. This way, Keypom has ownership and can transfer it to the user when they claim their key.
+* ***Defining an Asset***: The process of creating a drop and outlining a particular asset to be available on certain set of uses.
+* ***Funding an Asset***: Transferring ownership of defined assets to Keypom so that they can be redeemed by users claiming your keys.

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

@@ -6,12 +6,26 @@ import TabItem from '@theme/TabItem';
 import Admonition from '@theme/Admonition';
 
 # NEAR, NFT, & FT Assets
-<Admonition type="tip" icon="💡" title="tip">
-For every use on an Access Key, the different types of assets can be mixed to create an infinite number of experiences! 
+<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. 
+
+:::caution
+If assets are not properly funded, your drop may not perform as expected.
+:::
+
+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 a particular asset to be available on certain set of uses.
+* ***Funding an Asset***: Transferring ownership of defined assets to Keypom so that they can be redeemed by users claiming your keys.
+
+___
+
 ## NEAR Asset
-> A NEAR Asset attaches some claimable NEAR to each use it is defined for
+> 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. 
 
@@ -43,7 +57,7 @@ In the case of NEAR assets, defining and funding are synonomous. This is because
 ___
 
 ## NFT Asset
-> A properly funded NFT Asset will allow a user to receive a Non-fungible Token
+> 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. 
 

docs/Concepts/KeypomProtocol/Assets/function-call.md

@@ -3,11 +3,18 @@ sidebar_label: 'Function Call Asset'
 ---
 import Tabs from '@theme/Tabs';
 import TabItem from '@theme/TabItem';
+import Admonition from '@theme/Admonition';
 
 # Function Call Asset
 
-The function call asset is by far Keypom's most powerful asset class. FC assets allow **any** method on **any**
-contract to be executed (with some exceptions). In addition, there are a huge variety of customizations and features you can choose from when defining the drop that come on top of the global options. The possibilities are almost endless. State of the art NFT ticketing, lazy minting NFTs, auto registration into DAOs, analytics for marketing at events and much more.
+<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>
+
+The Function Call asset allows almost **any** method on **any** contract to be executed when claiming. 
+
+These Function Calls can be used for utility, such as NFT ticketing and auto-regtration into DAOs or can carry value such as lazy minting NFTs. Combined with the ability to define function call arguments dynamically based on user input, the FC asset becomes the most versatile and expansive Keypom asset type. 
+
 
 ## How does it work?
 

docs/Concepts/KeypomProtocol/drop-configurations.md

@@ -1,3 +1,7 @@
 ---
 sidebar_label: Drop Configurations
----
+---
+
+```rust reference
+https://github.com/keypom/keypom/blob/807fea5997987cb1a97bee838c4d2312a7faab51/contract/src/models/config.rs#L59-L78
+```