How the pipeline runs

Six stages between
an idea and a mint.

Each stage names what it takes in and what it hands on. Two of them wait for you. The rest are checks, and a check that fails stops the run.

Mint gate · EIP-712 plus a counter Files · pinned on IPFS Contract ·
collection_pipeline / graph4663
input_01SubjectPrompt or reference
core_02Variation engineLock · direct · compose
gate_03ValidationSubject · traits · schema
chain_04Robinhood MainnetIPFS → sign → mint
pipeline documented
Chain
Robinhood Mainnet
Chain ID
4663
Tokens
ERC-721
Mint gate
EIP-712
Tokens per call
up to 50
Fee vibe takes
0

One project.
One record.

The same project object holds the subject rule, the trait weights, the rendered files and the token JSON. It is written once, at the first prompt, and read again at the mint receipt.

01 creative input

What you bring

Text, a reference image and any mark that has to survive.

02 generation core

What renders

The locked subject, your direction and the weights decide each batch.

03 asset data

What gets written

Files, IDs, attributes and rarity ranks tie into one JSON per token.

04 chain settlement

What lands

IPFS keeps the files, your wallet approves, the chain stores the owner.

Nothing happens
by accident.

Approve the subject before you spend a batch on it. Run the checks before you spend gas. Taste and the last signature are yours, at both ends of the run.

  1. 01subject spec
  2. 02direction
  3. 03trait graph
  4. 04generation
  5. 05validation
  6. 06onchain publish
01 subject spec

Name the thing

Silhouette, proportion, palette and any mark that has to stay come out of your text or your reference, and become the description every later prompt opens with.

Silhouette lockColor constraintsBrand elements
inputPrompt / referenceoutputSubject profile
02 direction

Agree on the look

Render a handful, look at them, then commit. A direction you approve is cheap to replace; a thousand assets are not.

Human approvalDirection versionReversible
inputSubject profileoutputApproved direction
03 trait graph

Weight the traits

Scenes, outfits, finishes, props and effects go into categories with a weight each, plus the pairs that must never appear together. Rarity falls out of those numbers.

WeightsExclusionsRarity
inputApproved directionoutputTrait manifest
04 generation

Fill the set

Batches open with the same subject text, and each candidate keeps the prompt, the seed and the traits that produced it.

Batch queueKeep or discardTraceable
inputTrait manifestoutputCandidate assets
05 validation

Run the checks

Content hashes catch repeats, exclusions catch impossible combinations, and the schema catches a blank field. Only what clears all three goes in the package.

Duplicate hashSchema checkHuman review
inputCandidate assetsoutputVerified package
06 onchain publish

Pin, sign, mint

Files go to IPFS, the service issues an authorization that expires in minutes, and your wallet sends the call on Robinhood Mainnet.

IPFSEIP-712Wallet sign
inputVerified packageoutputOnchain collection

A rendered file
is not a finished token.

At scale the work is in the bookkeeping: which renders held the subject, no impossible trait pair, no token pointing at the wrong image. Four gates run before a package exists.

Subject

One description

The approved text rides in front of every prompt, each variant renders on a seed derived from the subject seed, and you lock the candidates that hold.

Duplication

No twins

Each candidate is hashed, so the same bytes cannot be packaged twice.

Trait rules

Legal combinations

Weights and forbidden pairs are read back against what you typed.

Metadata

Complete records

IDs, image paths, attributes and required fields are read before export.

validation.reportgate
01read manifest.json
02compare each prompt to the locked subject
03hash every candidate, look for repeats
04solve the exclusion pairs
05read the token json against the standard
06point each record at its own file
package clean, export or publish from here
in: locked candidatesout: json written

One approval.
Then it is public.

The address, the file URIs and the call parameters are assembled first. Your wallet is asked once, at the end, and the receipt is what gets written down.

1 pin assets

Files get an address

Every locked piece and its JSON go up and come back as a URI.

2 authorize

The service signs once

Who pays, who receives, the file hash, the count, the price, the counter and the deadline go into one short lived signature.

3 wallet sign

You approve the call

Your wallet shows the numbers before anything is sent.

4 finality

The receipt comes back

Token IDs and an explorer link show up under your creations.

vibe Collection on Robinhood Mainnet

Read the contract controls →

Three rules the
whole thing follows.

01

You press the button

The look, the final set and every transaction wait on a click from you.

02

One row, one file

Image, attributes, ID and URI stay lined up all the way through.

03

Anyone can check

The pinned files, the signature and the transaction all stand up on their own.

Your turn

Start with one subject.
End with a minted set.

Settle the direction early. Everything before the mint can be thrown away and redone.