search

metaplex-foundation / metaplex-program-library

Smart contracts maintained by the Metaplex team
Other
580 stars 511 forks source link

Add more Information to Trade States #62

Closed austbot closed 2 years ago

austbot commented 2 years ago

Problem

TradeStates have no data inside of them. This is great for cost but makes it harder to build marketplaces and products that can aggregate AuctionHouses. It also makes it very hard for a product that notifies users of bids on their NFTs to be made. In the current design one would need to follow the ledger and watch all AuctionHouse program transactions to pick this up. While watching the ledger may always be necessary for some applications marketplaces may benefit from more data in the tradestate.

Proposed Solution

Buyer Trade States Add more information in the Trade state such as the

By adding this information, marketplaces need to only store tradestates and token accounts. Aggregation tools can now just use GPA filters to find all the trade states on specific NFTs in the background.

Pros/Cons

CON: Expense, this makes the trades more expensive, this cost is recouperated later. CON: Lowers the barrier to entry for sale bots to try to execute more sales, could be bad for buyers, but still good for sellers. PRO: Wallets could somewhat easily show notifications and price of offers on an NFT PRO: Auction House UIS could be built so trade across many auction houses with stats and price data PRO: No need to follow the ledger, just a long call to GPA

aaronlinsky commented 2 years ago

Seems like pros outweigh cons (to me at least). Two questions:

  1. Would this be an optional feature configurable on a per auction house basis?
  2. What would be the approximate increase in cost per bid (or whatever cost metric makes sense)?
ohaddahan commented 2 years ago
  1. What would be the approximate increase in cost per bid (or whatever cost metric makes sense)?

Cost difference isn't too high from what I remember. https://solanacookbook.com/references/accounts.html#calculating-rent-exemption

> solana rent 1
Rent per byte-year: 0.00000348 SOL 
Rent per epoch: 0.000002458 SOL    
Rent-exempt minimum: 0.00089784 SOL

> solana rent 100
Rent per byte-year: 0.00000348 SOL 
Rent per epoch: 0.000004344 SOL    
Rent-exempt minimum: 0.00158688 SOL

Probably due to overhead in the account creation, difference between 1 and 100 bytes storage is less than 2X.

kespinola commented 2 years ago

The idea I've been toying with (and will be opening up a proof of concept PR this week) is to add "receipt" instructions that accept more or less the same data as the buy, offer, and deposit instructions but create a pda designed for reading relevant information in the seed as fields on the data account. The instruction should assert that the receipt being saved computes to the address of the trade state its attempting to document.

These instructions should be executed in the same transaction as the buy, offer, or deposit instruction. Having another instruction doesn't alter the API or functionality of the current actions while allowing for teams looking to read the chain more affectively the option create extra accounts.

ohaddahan commented 2 years ago

The idea I've been toying with (and will be opening up a proof of concept PR this week) is to add "receipt" instructions that accept more or less the same data as the buy, offer, and deposit instructions but create a pda designed for reading relevant information in the seed as fields on the data account. The instruction should assert that the receipt being saved computes to the address of the trade state its attempting to document.

These instructions should be executed in the same transaction as the buy, offer, or deposit instruction. Having another instruction doesn't alter the API or functionality of the current actions while allowing for teams looking to read the chain more affectively the option create extra accounts.

Two modes of operation can exist at the same time as you said, buy / buy-v2 , etc.

I personally think that the trade state should hold more data such as: auction-house-key / type (buy/sell) / mint / token-account / price / wallet (seller/buyer).

Also the seeds should be: auction-house-key / type / mint / wallet.

This way you get:

  1. Unique trade state , easy to handle, no need to cancel old ones, and it doesn't make much sense to have the same wallet bidding different prices through the same auction-house on the same mint.
  2. Easy to search via getProgramAccounts since the trade state will hold all data needed to query (I would even add the new collection pointer if we want to really make this 100% web3).
  3. Much safer since can double check inside the contract that all data match for the two trade states, unlike now that it's open to some unpleasant cases.

I think that changes wise, pretty straight forward shouldn't be hard to change.

kespinola commented 2 years ago

addressed by https://github.com/metaplex-foundation/metaplex-program-library/pull/268