Skip to main content
vibe.market is an experimental protocol. Creating a pack involves smart-contract and market risks. Read the Terms; artwork preparation and announcements do not guarantee a launch, liquidity or returns.

​
Draft and announce

Send your registered API-KEY alongside the signatures or sessions described here. Creator writes and uploads share the write budget; a key does not confer creator permissions. See authentication and limits. Use the account session with POST /account, kind: "releases", and a nested release action:
Supported release actions are mine, load, save, publish and wishlist. A standalone wallet-signed POST /releases supports the same nested action model. A release contains an ID, revision, name, symbol, cover image, color, description, artwork design, planned launch time and status. Announcements require a name, alphanumeric symbol and launch time. The time is a Unix-millisecond timestamp. Public and list responses can set cardsOmitted: true. Load the complete draft with {"kind":"load","id":"..."} before saving or publishing. Do not save a summary over the full artwork. Preserve revisions; reload and reconcile when another device has edited the draft. Publishing an announcement is offchain. It does not deploy a contract or launch a pool.

​
Prepare launch artwork

Discover the currently configured launchTarget first. POST /runtime/{version}/prepare accepts multipart form data: Odds must total 10000 basis points, multipliers must strictly increase, and the computed round-trip return after trading fees must not exceed 95%. Each file is PNG, JPEG, WebP or GIF and at most 4 MiB. The request is bounded to 12 MiB total, 512 KiB fields and nine files. Multipart overhead counts toward the request limit. The response contains baseURI, packArt, tierArt and createParams, including decimal-string ethPerPackWei. Preparation stores artwork; it does not execute the returned parameters onchain. The contract and current launch configuration can impose additional restrictions. An alternative creator workflow uses published release artwork. Do not mix its artwork format with the board-preparation format or reconstruct a metadata URL by guessing its hash.

​
Launch explicitly

Verify the current contract graph and contract-specific creation ABI. Obtain separate wallet consent for the launch transaction, verify its receipt and wait for the correct runtime to index it. Do not identify a launch solely by matching a pack name.

​
Edit an existing pack

GET /runtime/{version}/pack-preview/{id} returns a lightweight preview. GET /runtime/{version}/pack-edit/{id} returns the full edit snapshot and revision. Submit a creator-authorized edit using an account pack-edit action or the standalone signed endpoint. The edit is bound to its runtime, drop ID, launch transaction and revision.
  • Card definitions can be edited only during the seven-day card-edit window.
  • Cover-image edits are not limited to that same window.
  • Edits affect future openings; already-opened cards retain their original artwork revision.
  • At least a cover image or card definitions must be supplied. Reload after a revision conflict rather than retrying stale content blindly.
Card sets have five rarity arrays and at most 50 cards per rarity. Card metadata has bounded names, descriptions and custom attributes; protocol-owned identity, rarity, foil and wear attributes cannot be overridden.

​
Import artwork from Classic

GET /classic-import?pack={slugOrAddress} reads a Base Classic pack’s published card metadata and returns a new draft, source identity and notices. Review truncation notices, names, attributes and every rarity before saving. This imports artwork into a draft. It does not migrate existing assets, holders, contracts, balances or liquidity.