Public Sale Configurations
The public sale configuration gives the funder the ability to sell access keys in their drop with a variety of configurable behaviors such as the price, or a dedicated allowlist.
Use cases
Public sales of access keys allow for a wide range of easier to create and more interactive events. This is done by letting you:
- Set up an extremely cheap, exclusive event. This event can host an infinite amount of people and the cost of ticketing would be ~0.05 $NEAR.
- Sell access to gated function calls. For example, you can have an exclusive guest-book contract where users that signed it gained access to a VIP meet and greet with a famous artist.
- Introduce FIAT payments for your users when they purchase an access key; opening up your tickets, onboardings, and NFT drops to a whole new audience.
The sale configurations are outlined below.
- 🔑 Keypom SDK
- 📚 Protocol
loading...
loading...
Maximum Number of Keys
Default: None
The max_num_keys
parameter dictates the maximum number of keys that can be added to a drop. By default, there is no limit. Using this can help create scarcity, or abide by venue capacities.
Use case
Pretend you are hosting an exclusive talk for your dApp and want to limit the attendance 1000 people.
In this scenario, you could configure the drop to have max_num_keys = 1000
in order to ensure any keys beyond 1000 cannot be bought and added to the drop.
Price per Key
Default: None, the keys are free
This price_per_key
parameter defines the price for purchasing a key.
Use case
This parameter can be changed based on your needs. For example, if you are running a charity event and want to bring in as many attendees as possible, you would leave both price_per_key = 0
and max_num_keys
undefined. This would mean there is no limit on the number of free keys that can be added to the drop.
Alternatively, if you are looking to earn money with your event, you can choose to set price_per_key
to whatever you see fit. This value is expressed in yoctoNEAR.
Allowlist
Default: None, anyone can add keys to the drop
Allowlist
specifies a group of users that can add keys to the drop using their accountID
. For example, if allowlist = [benji.testnet, minqi.testnet]
, then only benji.testnet
and minqi.testnet
can add keys to the drop.
If left undefined, anybody can add keys to the drop.
Use case
In this example, pretend you are running a concert for only your closest friends. To do this, you would set allowlist
to be a vector of their NEAR accountID
's. This way, you can take comfort in knowing that your friends will be the only ones with tickets to the event.
Blocklist
Default: None, nobody is blocked
Contrary to the allowlist
, the blocklist
specifies those that are blocked from adding keys to the drop. This is empty by default, meaning nobody is blocked.
Note that the blocklist
takes precedent over the allowlist
. This means that if you are on both lists, you will be blocked.
Use case
Lets pretend that you are running a concert but there are known ticket scalpers in the community. To prevent keys from being scalped and ensure your true fans get tickets to your concert, you can add the NEAR accountID
's of the scalpers to the blocklist
vector.
Auto-Withdraw Funds
Default: False, revenues go to funder's Keypom Balance
The auto_withdraw_funds
parameter dictates where revenue from key sales will go. Every time a key is sold, the revenue will automatically be sent to one of two places:
- the funder's Keypom balance
- the funder's NEAR wallet
By default, the revenue will go to the funder's Keypom balance. If auto_withdraw_funds = true
, the revenue generated will be sent to the funder's NEAR wallet.
Use case
Let's say you are an event promoter who is new to NEAR. You realize that you are only going to use Keypom for a single event.
In this scenario, rather than sending revenues to your Keypom balance and then needing to manually withdraw it once the event is over, you can set auto_withdraw_funds = true
while creating the drop in order to guarantee that the revenues will go to your NEAR wallet automatically.
Start
Default: None, keys can be added immediately
The start
parameter dictates when keys can be purchased and added to the drop. Similar to time configurations, this is measured in non-leap-nanoseconds since January 1, 1970 0:00:00 UTC. A sample configuration is made available below.
Use case
Pretend you are an event coordinator for a popular event and have a limited capacity. To ensure fairness, you set a date and time for the sale to begin and let all your users know.
To do this, you can configure the start
parameter.
End
Default: None, keys can be added indefinitely
The end
parameter defines when keys can no longer be purchased and added to the drop.
Use case
For an upcoming event, you want to create a pre-sale of tickets for dedicated fans. To do this you can create a drop, separate from the main ticket sale, that begins early and ends before the general admission tickets go on sale.
To do this, you can configure the end
parameter.
Example Public Sale Configuration
const ONE_SECOND_NS = 1e9;
pub_sale: {
// Maximum of 100 Keys
max_num_key: 100,
// 1 $NEAR per key
price_per_key: parseNearAmount("1"),
// only allow benji.testnet and minqi.testnet to add keys
allowlist: ["benji.testnet", "minqi.testnet"],
// don't allow boogieman.testnet to add keys
blocklist: ["boogieman.testnet"],
// send revenue back to funder's NEAR wallet
auto_withdraw_funds: true,
// start 5 minutes from now
start: (Date.now() * 1000000) + ONE_SECOND_NS * 300,
// end 15 minutes from now
end: (Date.now() * 1000000) + ONE_SECOND_NS * 900
}