Juice NFTMKT spec

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

version 1

  • Juicebox deploys the NFTMKT once, specifying terminalDirectory
  • Artists submit 721s and specify payout parameters
    • submit 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

version 1.1

  • Lightweight JS SDK
    • get all nfts
    • get price
    • get amount remaining
    • construct submit nft tx
    • construct tx to purchase given contract & tokenId

version 2

  • buyMany (multi purchase)
  • submitAll
    • using ProxyAssert opensea style
    • recursively transfer 721s to the NFTMKT
  • ERC20 payment support
    • additional features for jb projects?
  • Access restricted purchasing
    • must hold given ERC-20/721 to purchase
  • Paused listing
    • project pause button vs artist pause button
    • default paused or unpaused param in submit
    • investigate the user requirement here
    • manual unpause button
    • allow projects to populate frontends with onchain data before sale goes live
  • Projects can optionally require greenlight before NFTs go on sale
    • whitelist or unpause per contract address
  • Variable pricing
    • jango will investigate
    • price tranches
    • dutch auctions?
    • bonding curve?

version 2.1

  • Improved JS SDK
    • aim to have Shark web devs upstream

version 3

  • 1155 support
    • better support for editions
  • Timed listings
    • purchase(){require(blockNumber > t)}
Select a repo