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!
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.
- 🔑 Keypom SDK
- 📚 Protocol
Uses per Key
This parameter allows you to set the number of times a user can claim a key before it is deleted.
This parameter is incredibly versatile and can be used in numerous ways. Some excellent examples are:
- 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.
- A set number of Recurring Payments for subscriptions or contracted/freelanced work.
- A method to accurately track retention, such as Event Turnout
Root Account ID
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.
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!
root_account_id = "moonpom.near" and now any account created using your linkdrops will take on the form
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