Prepare your metadata

Every NFT on Arkena points to a metadata JSON file on IPFS. The metadata describes what the NFT is — its name, image, traits — and the file lives on IPFS so the link can never be tampered with after mint.

You produce these files yourself, off-chain, and pin them to IPFS before opening the launch wizard. Arkena reads them as-is; we do not edit, re-host, or mirror them.

Collection metadata modes

Which mode you use depends on the supply mode you picked on the Mint configuration step. A limited collection chooses between instant and reveal-later metadata; an open edition always uses one shared file.

Instant mode (limited, revealed). Every NFT has its own JSON file. The contract appends /<tokenId>.json to the base URI you provide, so with a base of ipfs://QmFolderCid, token #1 reads from ipfs://QmFolderCid/1.json, token #2 from ipfs://QmFolderCid/2.json, and so on through your supply cap. The wizard labels the input Base metadata URI (folder) and rejects any URI with a .json suffix or trailing slash.

Reveal later mode (limited, hidden). Every NFT in the collection points to the same single JSON file — usually a placeholder image and copy that says "reveal coming soon". The wizard labels the input Placeholder metadata URI (single .json). When you're ready, the reveal action in the dashboard's danger zone flips the collection to per-token mode using the base URI you provide. Reveal is one-way: hidden → revealed.

Shared mode (open edition). An open edition has no supply cap, so per-token files are impossible — every minted token points to the same single JSON file, permanently. The wizard labels the input Shared metadata URI (single .json). There is no instant / hidden choice and no reveal flip: what you pin at launch is what every holder sees forever. Pick this only when one shared artwork is the intent of the drop.

Per-token JSON

Each <tokenId>.json follows the OpenSea metadata standard. The minimum that Arkena and most wallets recognise:

Code

{
  "name": "Cosmic Wanderer #1",
  "description": "A stargazer from the Outer Rim.",
  "image": "ipfs://QmYYY/1.png",
  "attributes": [
    { "trait_type": "Background", "value": "Nebula" },
    { "trait_type": "Eyes", "value": "Glowing" },
    { "trait_type": "Rarity", "value": "Rare" }
  ]
}

Optional fields you can add:

external_url — a link back to the collection's external page.
animation_url — for animated NFTs (MP4, WEBM, GLB, GLTF).
background_color — six-digit hex without # (e.g. "FFFFFF").

File numbering starts at 1 and runs continuously up to your supply cap. Gaps are not supported.

Hidden JSON

A single file at ipfs://QmHiddenCid/hidden.json:

Code

{
  "name": "Cosmic Wanderer (Unrevealed)",
  "description": "Reveal on May 14. Stay tuned.",
  "image": "ipfs://QmZZZ/cover.png"
}

Every NFT in the collection points to this same file until you flip the reveal switch. The placeholder image is the same for every token.

Shared JSON

An open edition uses the same structure as a hidden file — a single .json that every token resolves to — but there is no reveal afterward, so this file is the permanent metadata for the whole edition:

Code

{
  "name": "Genesis Pass",
  "description": "An open-edition commemorative pass.",
  "image": "ipfs://QmZZZ/pass.png"
}

Every token in the edition shares this name, image, and traits. Token IDs still increment per mint (#1, #2, #3, …), but the metadata behind each is identical. You point the wizard at the file directly — the shared URI must end in .json.

Folder structure

A typical revealed collection on IPFS looks like this:

Code

ipfs://QmFolderCid
  ├── 1.json
  ├── 2.json
  ├── 3.json
  ├── ...
  └── images/
      ├── 1.png
      ├── 2.png
      ├── 3.png
      └── ...

You give the launch wizard the base URI — ipfs://QmFolderCid, with no trailing slash — and the contract handles the per-token append. The image paths inside each JSON are independent; you can lay them out however you want as long as the URIs in the JSON files resolve.

For hidden mode, the structure is just two files:

Code

ipfs://QmHiddenCid
  ├── hidden.json
  └── cover.png

You point the wizard at ipfs://QmHiddenCid/hidden.json directly — the placeholder URI must end in .json. An open edition uses the same single-file shape; you just never reveal past it.

Image specs

NFT images follow the OpenSea recommendations. Arkena does not enforce these on-chain, but every wallet and aggregator reads better when you stay close to them.

Field	Recommendation
Aspect ratio	1:1 (square)
Resolution	1500×1500 px ideal; 350–4000 px range
Formats	PNG (with transparency), JPEG (photo), GIF, SVG, MP4, WEBM, GLB, GLTF
Max file size	100 MB per image
Animations	Use `animation_url` for MP4/WEBM/GLB/GLTF; `image` should still be set as a fallback

Pinning to IPFS

You're responsible for pinning the files. The most common choice is Pinata — it's the de-facto standard, has a free tier that comfortably covers a few thousand items, and resolves through every major IPFS gateway.

If you outgrow the free tier or want a backup pinning service, Filebase offers an S3-compatible API at competitive prices.

Whichever you pick, verify the URI resolves before you open the launch wizard. Open https://ipfs.io/ipfs/<your-cid> in any browser, confirm the JSON loads, and confirm the image link inside it also resolves.

What's next

You're ready to submit. Open Submit the collection and walk through the wizard.