The above PR is ready for production, but there is a concern about the lim value in the SRC-721 deploy.
...{
"p": "src-721",
"v": "1",
"op": "deploy",
"name": "Collection Name", // The display name of the collection
"symbol": "SYM", // the symbol for the collection
"price":"10000", // price in sats, must be paid to the owner of the collection for a mint to be valid [optional]
"description": "Description",
"unique": true, // determines if a set of traits must be unique to be valid [optional]
"wl-token":"A123456789", // a pointer to the whitelist token [optional]
"type": "data:image/png;base64",// mime type of the images used in traits t0-tx
"image-rendering":"pixelated", // css property to ensure images are displayed properly [optional]
"viewbox": "0 0 160 160", // viewbox to properly see traits t0-tx
"max": "2500", // maximum number of mints
"lim": "1", // limit per mint
"icon": "A16308540544056654000",// CP asset for a collection icon [optional]
// All t0-tx are optional if the reveal op is planned to be used
"pubkey": "a1b2...e8d9" // pubkey of the operator for future ops such as reveal [optional]
"t0": ["A12430899936789156000", "A9676658320305385000"], // up to x layers of stamp traits (references by CP asset#) containing
"t1": ["A17140023175661332000", "A6689685157378600000"], // transparency can be stacked on top of eachother to form a final image
...
"tx": ["A12240402677681132000", "A4332886198473102000"]
}
is this a problem if the issuance value is > than the "lim" and still a valid mint
Historically the indexer accepted anything with p: src-721 without any validation of the other key/value pairs. So in theory this would be up to the deployer to determine if this was actually part of the collection?
RE: https://github.com/stampchain-io/btc_stamps/pull/267
The above PR is ready for production, but there is a concern about the lim value in the SRC-721 deploy.
...{ "p": "src-721", "v": "1", "op": "deploy", "name": "Collection Name", // The display name of the collection "symbol": "SYM", // the symbol for the collection "price":"10000", // price in sats, must be paid to the owner of the collection for a mint to be valid [optional] "description": "Description", "unique": true, // determines if a set of traits must be unique to be valid [optional] "wl-token":"A123456789", // a pointer to the whitelist token [optional] "type": "data:image/png;base64",// mime type of the images used in traits t0-tx "image-rendering":"pixelated", // css property to ensure images are displayed properly [optional] "viewbox": "0 0 160 160", // viewbox to properly see traits t0-tx "max": "2500", // maximum number of mints "lim": "1", // limit per mint "icon": "A16308540544056654000",// CP asset for a collection icon [optional] // All t0-tx are optional if the reveal op is planned to be used "pubkey": "a1b2...e8d9" // pubkey of the operator for future ops such as reveal [optional] "t0": ["A12430899936789156000", "A9676658320305385000"], // up to x layers of stamp traits (references by CP asset#) containing "t1": ["A17140023175661332000", "A6689685157378600000"], // transparency can be stacked on top of eachother to form a final image ... "tx": ["A12240402677681132000", "A4332886198473102000"] }
is this a problem if the issuance value is > than the "lim" and still a valid mint
Historically the indexer accepted anything with p: src-721 without any validation of the other key/value pairs. So in theory this would be up to the deployer to determine if this was actually part of the collection?