Skip to main content
Version: Next

Drop Configurations

Drop Customizations via the DropConfig object passed into create_drop can help adjust the properties and behaviors of a drop to achieve specific use-cases.

From changing the amount of times a key can be used before it's deleted to setting a public sale and making profit from keys being added to your drop, understanding the power of the DropConfig is crucial to making the most of Keypom!

tip

A configuration applies to ALL KEYS across a drop.

This means that if you want keys with different configurations, you must create multiple drops with their respective configurations.

Understanding DropConfig

src/lib/types/drops.ts
loading...

For now, the focus will be uses_per_key and root_account_id. TimeConfig, UsageConfig, and PublicSaleConfig are covered later.

Uses per Key​

Default: 1

This parameter allows you to set the number of times a user can claim a key before it is deleted.

Use cases​

This parameter is incredibly versatile and can be used in numerous ways. Some excellent examples are:

  1. Rewards that progressively increase in value. For example, you could incentivize people to show up to all your talks at a conference. A link would be given out that needed to be physically scanned at your talk to unlock rewards. If you showed up to all the events, a jackpot prize could be claimed.
  2. A set number of Recurring Payments for subscriptions or contracted/freelanced work.
  3. A method to accurately track retention, such as Event Turnout

When used with function call drops, some more complex use cases can be created, such as Customizable Multi-Phase Onboarding and Auto DAO-Registration

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

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