# 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)}`