Missing attributes when uploading CSV to Edition Page

Manifold Support
1

In order for our team to investigate a bug/errors, please provide the following:

  • What is your wallet address?
    quietloops.eth

  • A summary of the issue:

Missing attributes when uploading Custom Reveal metadata via CSV in an Edition drop.

Sepolia testmint: strata | Manifold

example token: strata #18 by quietloops | Manifold Gallery

Only 1 (“Scene”) of about 8 attributes are getting attached to my tokens. I assume I’m making an error in the formatting of my CSV file, can someone take a look?

CSV:
https://www.dropbox.com/scl/fi/2zepzhxl24ng6cjyu9l0k/token-metadata-copy.csv?rlkey=gmbqrbhteusp91t2fed4v91xb&e=1&dl=0

Thanks in advance!

2

Quick update - I realized that from the gallery page of a token:

clicking More info > View Metadata does indeed have all attributes. It’s the fact that they are datatype number that is casing them to be hidden from the Attributes section of the token on manifold.

OpenSea is treating them as “Levels”, which can make sense for a couple of the attributes, I suppose.

Do you suggest simply treating all numbers as strings to have them surface on the manifold gallery page? Or any other protips on the CSV treatment?

Separate but related – I built my own arweave uploading pipeline in my stack (you’ll see my image and animation_urls are all pointing there; it does seems redundant/wasteful that your side is downloading and re-uploading to arweave, i wonder if there is a flag that could be set, or if there is a different workflow where I’m trusted to manage my own asset uploads. Just a thought, lmk –

3

Got another engineer on the display issue on our side skipping over that attributes. Thank you!

In the meantime to answer you OpenSea display question, they have some docs that’ll explain how they render each type of attribute according to what is provided as the type. So yes, a string would avoid this “rank” UX they use. See below for more info

For numeric traits, OpenSea currently supports three different options, number (lower right in the image below), boost_percentage (lower left in the image above), and boost_number (similar to boost_percentage but doesn’t show a percent sign). If you pass in a value that’s a number and you don’t set a display_type, the trait will appear in the Rankings section (top right in the image above).

Adding an optional max_value sets a ceiling for a numerical trait’s possible values. It defaults to the maximum that OpenSea has seen so far on the assets on your contract. If you set a max_value, make sure not to pass in a higher value.

5

Thanks @johnny, super helpful.

Ideally, I’d form my numeric traits like this:

    {
      "display_type": "number", 
      "trait_type": "Generation", 
      "value": 2
    }
  ]

Is there a trick to surfacing display_type when using the CSV upload on manifold?

Also I’m realizing that on OS2 none of this matters at all, it looks like they got rid of the ugly bar UI altogether. I’ll try everything as strings and see what happens.

Also let me know if any thoughts on this:

Separate but related – I built my own arweave uploading pipeline in my stack (you’ll see my image and animation_url s are all pointing there; it does seems redundant/wasteful that your side is downloading and re-uploading to arweave, i wonder if there is a flag that could be set, or if there is a different workflow where I’m trusted to manage my own asset uploads. Just a thought, lmk –

Thanks again for the help!

6

hey infinite_joe,

thank you for reporting the attributes issue. due to historical reasons, we were disregarding the numeric values in the attributes (previously, even if the value was numeric, it was stored as string to avoid JS overflow). it seems the standard has evolved; we’ve updated our processes to reflect that. if there are any tokens in your inventory that require updating, feel free to hit the “refresh metadata” button (usually on the “more options” page of an app).

strata #12 by quietloops | Manifold Gallery should display properly now with the previous metadata (https://z6jkdzd3adfhsmnx27ddisfjofj2qr5wxfbcxeidbdhd5ncns2bq.arweave.net/z5Kh5HsAynkxt9fGNEipcVOoR7a5QiuRAwjOPrRNloM/12)

8

thanks for the update @mani_eng!

indeed, all seems to be working as expected now with the previous version. I’m playing around with the dataType header declarations and still refining my metadata in general, will let you know if I run into anything else funny.

Thanks again for the help –