You will have to create an intermediary contract which is owned by the address buying the NFT, and define custom logic for price. You would have to code your token to only interact with contracts of that specific type. Your logic could be rigid, and place a hard cap on price, or dynamic to allow events like discounts to take place. Since your question is vague, I'll make some points on rigid vs flexible price.
My first idea would be to start with the existing paradigm of price control via automated-market maker (AMM) contracts and expand on that. A method for this will be infinitely valuable to NFTs in general, particularly compared to a model where the price is set in stone. It requires a "P2C" or peer-to-contract setup that has certain rules in place that allow market forces or custom logic to determine ticket price.
Precedent in Fungible Tokens
Where UniSwap uses the following formula to determine market price in their liquidity pools:
x * y = k
Where x
is the amount of Token A, y
is amount of Token B, and k
is a fixed constant representing the liquidity of the pool. Unlike traditional markets, you don't need a counterparty to determine the price using this model. The price you get for an asset is determined by a formula. If I'm looking at an ETH:DAI pool, and I want to buy all of the ETH, I could not, as each ETH purchased exponentially increases the price with zero as a limit, if either x
or y
reach zero, the equation doesn't work, our k
value goes to zero, making the asset unbuyable.
Applying to NFTs
This is a very novel area of development and ripe for improvisation and unique solutions. I would encourage you to think outside the box while working on this project.
If you want a price set in stone, the controlling contract need only to limit the maximum number of ETH that can be sent to said contract in exchange for a transaction that transfers ownership of the NFT to the purchasing account. However even in current systems, ticket prices are not always set in stone. There are early bird specials, discounts for purchasing many tickets (e.g. company gatherings), and even discounts after an underwhelming sale to fill seats are all commonplace.
There's a value framework already for the value of physical items which is where I would start. It can be loosely defined as:
Value = Utility + Ownership History + Future Value + Liquidity
A ticket's has high utility, low/no ownership history impact, no future value, and liquidity varies (depending on number of sold out tickets, hype surrounding the event, number of seats).
Since ownership history and future value are not important, we can redefine in this case Utility
as Demand
and Liquidity
as Availability
. For tickets, specifically, a better equation would be:
Value = Availability / Demand
Where demand
is a variable floating point dependent on availability
. Your interacting contract would set the initial demand
value, and the availability
is determined by the number of tokens not claimed by an address in the NFT contract.
A fixed price requires less code, as you simply need to set it's value in the purchasing token. availability
is not part of any equation and serves only to see the remaining number of tickets.
In the case of a fluctuating price, demand
could be represented as a floating point variable between 0-1. When tickets first go on sale, demand
starts at 1 as zero tickets have been issued. We can approach zero, but can never reach it even if there is no demand for tickets as it creates a mathematical impossibility. It is likely that demand
will remain constant: people who want to go to something want to go to something regardless. If they can afford it, they'll go. The only thing this does is reduce the price proportionally depending on the number of requests for tickets, which is not unlike tickets to events today where promoters will give discounts just to fill the seats.
Setting the equation up like this also prevents the price from going above the sale price as you cap demand
at 1 in the controlling contract. However, you could alter this and allow for some resale within a reasonable range. If it's last minute, sometimes ticket prices do go up (scalpers or not). Perhaps setting demand
to a floating point value slightly above one would make more sense.
NOTE: The price control mechanism can also be used to lock the price by making the demand
value static or including another function that places a max value in ETH on the transfer amount.