Open questions

• What happens if artist A lists an NFT, i purchase nft, then submit that NFT to the same MKT before initial sale has completed at a higher price?
  • Suppose the answer is it depends if the frontend checks who the submitter is. That's the simple answer.
  • answer: leave it up to the frontend for now
• Can we list tokens that are not yet minted (for ex the nouns fork Shark is planning)?
  • @peri and @Jango suggest using JuiceboxProjects.sol's _takeFee method like TileDAO
  • This seems good, but will still require that contracts be written to support NFTMKT
• I would still like to find a solution that allows any contract that can direct revenues at any address to be compatible.
• Rethink auction pricing
  • shark wants to be able to list auctionable NFTs with fixed $SHARK payout
  • bc price scales, don't want to devalue nft in process
• Rethink secondary

version 1

• Juicebox deploys the NFTMKT once, specifying terminalDirectory
• Artists submit 721s and specify payout parameters
  • list fn
• Artists can withdraw NFTs
  • withdraw fn
• MKT accepts only ETH
  • purchase fn
• Fixed price listings only
• No restriction on who can submit to the contract
  • submitted NFTs are on sale immediately
  • submitter decides payout params unilaterally
  • anyone can submit any NFT, even for secondary mkt resale
• Project should be able to delist?
  • plan at present to leave all listing matters up to frontend devs
• Events emitted for all write fns

version 1, to considers

• view fns
  • getAll returns all listed nfts (contract address, tokenid, and price)
  • getCollection(contract) returns all nfts from one contract address
  • getPrice(contact, tokenId) returns tokenId and price
  • getrecipients
• prefer fns that dont require more storage
  • anything else should be thegraph
• talk to exekias about this
• spend time thinking of how to accessing these necessary properties