---
# System prepended metadata

title: Untitled

---

## Example Scenarios 

*Pre-requisite Steps*
The funder that has an account and some $NEAR:

- creates a keypair locally (`pubKey1`, `privKey1`). The blockchain doesn't know of this key's existence yet since it's all local for now.
- calls send on the contract and passes in the pubKey1 as an argument as well as the desired balance for the linkdrop.
- The contract will map the `pubKey1` to the desired balance for the linkdrop.
- The contract will then add the `pubKey1` as a function call access key with the ability to call claim and create_account_and_claim. This means that anyone with the `privKey1` that was created locally, can claim this linkdrop.
- Funder will then create a link to send to someone that contains this privKey1. The link follows the following format: wallet.testnet.near.org/linkdrop/{fundingContractAccountId}/{linkdropKeyPairSecretKey}?redirectUrl={redirectUrl}
`fundingContractAccountId`: The contract accountId that was used to send the funds.
`linkdropKeyPairSecretKey`: The corresponding secret key to the public key sent to the contract.
`redirectUrl`: The url that wallet will redirect to after funds are successfully claimed to an existing account. The URL is sent the accountId used to claim the funds as a query param.


### Claiming Linkdrop without a NEAR Account

The receiver of the link that is claiming the linkdrop:

- Receives the link which redirects them to a linkdrop claiming page (such as NEAR wallet).
- The linkdrop claim page calls `get_key_information` to display information associated with the linkdrop
- The linkdrop claiming page creates a new keypair (`pubKey2`, `privKey2`) locally. (The keypair is not written to chain at this time)
- Receiver will then choose an account ID such as alice.near.
- Wallet will then use the privKey1 which has access to call `claim` and `create_account_and_claim` in order to call `create_account_and_claim` on the contract.
- It will pass in `pubKey2` which will be used to create a full access key for the new account.
- The contract will create the new account and transfer the funds to it alongside any NFT or fungible tokens included in the linkdrop.

### Claiming Linkdrop with a NEAR Account
The receiver of the link that is claiming the linkdrop:

- Receives the link which redirects them to a linkdrop claiming page (such as NEAR wallet).
- The linkdrop claim page calls `get_key_information` to display information assocaited with the linkdrop
- The linkdrop claiming page connects to an existing NEAR Account.
- Wallet will then use the `privKey1` which has access to call `claim` and `create_account_and_claim` in order to call `claim` on the contract.
- The contract will transfer the funds to the existing account alongside any NFT or fungible tokens included in the linkdrop.



## Security Implications 
1. Linkdrop Creation
Linkdrop creation involves creating keypairs associated with mapping to assets such as $NEAR, FTs, NFTs and access keys. There are security implications with the access keys associated with the keypairs. These access keys should be function call access keys and be limited to specific functionality. For example, function call access keys with permission to only call `claim` and `create_account_and_claim`. Another important security implication of linkdrop creation is to ensure that only one key is mapped to a set of assets at any given time. Linkdrop creation can happen in real-time or prior to being received. The mass creation of linkdrops involves creating multiple keypairs and mapping of assets and access keys associated with them. The security implications mentioned above are increased with the mass creation of linkdrops. 

2. Linkdrop Key Management  
Key management is a critical saftey component of linkdrops. The linkdrop creator should implement a key management strategy for linkdrop keys upon the receiver claiming the linkdrops assets. For example, one strategy may be to delete the linkdrop keypair in the same block a receiver claims the linkdrop assets so a single linkdrop cannot be used multiple times. In another example, a linkdrop creator may allow for a linkdrop to be used X number of times, where they could track the number of calls to `claim` or `create_account_and_claim` and delete after X uses of the linkdrop. It is very important to implement your key management strategy in `claim` and `create_account_and_claim` as opposed to a callback function to ensure the linkdrop keys are not improperly used. Implementing key management in a callback has a security implication of 



## Why no Linkdrop Creation Interface

A standard linkdrop creation interface. A standardized linkdrop creation interface would provide data models and functions to ensure linkdrops were created and stored in a specific format. The rationale for not choosing this design was that is was too restrictive. Standardizing linkdrop creation adds complexity and reduces flexibility by restricting linkdrop creators in the process in which linkdrops are created, and potentially limiting linkdrop functionality. The functionality of the linkdrop creation, such as refunding of assets, access keys, and batch creation, should be chosen by the linkdrop creator and live within the linkdrop creator platform. Further, linkdrop creation is often not displayed to end users and there is not an inherent value proposition for a standardized linkdrop creation interface from a client perspective. 
