Tradex Docs

What is Tradex

an inscription: the data itself, written into the chain

Tradex brings Bitcoin Ordinals-style inscriptions to Robinhood Chain. An inscription is a piece of content — an image, a text, a JSON — written directly into a transaction's calldata. The chain itself stores the bytes, forever. No file server, no IPFS, no URL that can die, no smart contract that can be upgraded or paused.

Each inscription gets a number, assigned in strict onchain order starting from #0: first inscribed, lowest number. There will only ever be one #0, ten sub-10s, a hundred sub-100s. Scarcity is not declared by a project, it is a property of time.

Ownership is derived from plain transactions by public rules (below). Anyone can re-run the rules from the first block and arrive at the same numbers and the same owners. Tradex the website is just one window into that; the artifacts live on the chain.

Inscriptions vs NFTs

None of this makes NFTs useless — but it makes inscriptions a different, harder asset: closer to a coin struck into metal than to a certificate pointing at a warehouse.

How it works, in one minute

1. 01
   Create

   Send a transaction whose calldata is the UTF-8 bytes of a data URI (data:image/webp;base64,…). Optional metadata rides in the same URI as media-type parameters — ;name=…;parent=0x… — so one transaction carries exactly what you chose to inscribe. The tx hash becomes the permanent id.

2. 02
   Own

   The recipient of the transaction is the first owner — except the mint address 0x0000000000000000000000000000000000004663: creates sent there belong to the sender (this is the default; wallets like MetaMask block dapp data-transactions to your own accounts).

3. 03
   Number

   Inscriptions are numbered from #0 in canonical order: block number, then transaction index. Final after 2 confirmations, then never changes.

4. 04
   Unique

   The SHA-256 of the calldata must never have been inscribed before. First one wins; byte-identical copies are ignored.

// the whole protocol, from the browser (viem)
await walletClient.sendTransaction({
  to: '0x0000000000000000000000000000000000004663', // mint → you own it
  data: stringToHex('data:text/plain,gm robinhood chain'),
  value: 0n,
})

Guide: inscribing

The Inscribe page walks you through five steps. You only pay Robinhood Chain gas, about a cent per KB at current prices; Tradex charges nothing.

1. 1
   Upload your assets

   Drop one or several files (PNG, SVG, GIF, WebP, text, JSON, HTML), write text/JSON, or generate deterministic SVG art from a seed. An image over the 90.00 KB calldata budget gets a one-click compress; anything that already fits is inscribed byte for byte.

2. 2
   Review & name

   Check the decoded content and the uniqueness check (byte-identical content is rejected by the protocol). Optionally give each item a name and pick a collection — or create a new one on the spot.

3. 3
   Check the fee

   The fee is pure network gas: 16 gas per byte of content plus base cost, at Robinhood Chain's gas price. A 30 KB image usually costs well under a dollar. The page warns you if your wallet doesn't hold enough ETH on chain 4663.

4. 4
   Confirm onchain

   Sign the transactions one after the other: one per item, plus one for a new collection, plus one metadata inscription if you set names or a collection. Nothing is signed or simulated on your behalf; your wallet shows every transaction before it is sent.

5. 5
   Get your numbers

   The indexer assigns numbers as soon as blocks are final — usually seconds. Your inscriptions appear on the home page, in your Portfolio, and in their collection.

Wallet notes: use a self-custody EOA (MetaMask classic account, Rabby…). Phantom cannot add custom chains. Gifting directly to someone else's address works from the "Inscribe to" field — but not to another account of your own MetaMask (MetaMask blocks dapp data-transactions to your own accounts; the mint address exists precisely to work around this).

Guide: collections

the key inscription controls the collection, like an Ordinals parent

Collections work like Bitcoin Ordinals parent-child provenance, translated to accounts:

1. 1
   The collection is a key inscription

   Creating a collection inscribes {"p":"tradex","op":"collection","name":"…"}. Its tx hash is the collection id, and the inscription itself is the collection's key.

2. 2
   Whoever owns the key controls additions

   An item joins a collection through the parent=0x… parameter written inside its own data URI at creation, honored only if the creator owns the key at that moment (the Ordinals parent rule). op: meta remains as a fallback to name or file already-minted items, same authorization. First write wins, forever.

3. 3
   Burn the key to cap the supply

   Send the key to 0x000000000000000000000000000000000000dEaD and the collection is closed forever, provably, onchain. The mint and collection pages then show a 🔒 SUPPLY LOCKED badge instead of SUPPLY OPEN.

Create

Collections page → "Create collection" (one transaction), or inline from the Inscribe flow via "+ New collection…".

Fill

Inscribe items with the collection selected — names and membership are written by one metadata inscription after your items confirm. First write wins: names and membership are immutable once set.

Hand over or close

The key is a normal inscription: send it, or sell it on the market, to transfer the whole collection's control. Burn it to freeze the supply forever.

Guide: marketplace

escrow trading: the contract holds the inscription, the indexer enforces truth

Inscriptions aren't tokens, so trading can't use approvals. The Market uses a minimal escrow contract at 0x491F215ed89F4468a11c722c4faeb2D2F5e05c78:

List (seller, 2 transactions)

From your Portfolio or an inscription page: first a protocol transfer of the inscription to the escrow contract (its fallback records you as depositor and never reverts; any ETH sent along is credited back to you, not kept), then list(id, price). A piece already in the escrow lists with the second call alone. delist(id) takes it off the market and keeps it deposited.

Withdraw (seller, 1 transaction)

withdraw(id) hands the inscription back to you. It delists first if needed, so there is nothing to sequence; only a piece armed into a drop must be disarmed first. The indexer applies the Withdrawn event, like every other, only when you are the address that deposited the piece.

Buy (buyer, 1 transaction)

buy(id, seller) with the exact price; the site fills in the seller the indexer saw deposit it. The contract pays the seller (minus a 2% market fee) and emits the Sold event that hands you the inscription.

Filter & hunt

Filter by rarity buckets (Sub 100 / 500 / 1k / 10k), collection, content type and price. Low numbers are the chain's own scarcity.

Why it's safe: a listing is only shown when the indexer confirms the contract actually owns the inscription and the seller is the one who deposited it. The contract keeps one claim per (inscription, depositor), so a stranger claiming your inscription can neither block your listing nor get paid for it. There are no approvals to phish.

Payouts. A sale pushes the proceeds to the seller in the same transaction. If the seller is a contract that cannot receive ETH, the amount is parked in pendingWithdrawals instead of failing the buy, and the seller collects it with withdrawProceeds(); your Portfolio shows the pending balance. The fee is fixed at deployment and capped by the contract at 10%.

Offers. Not available yet. An off-chain offer is a free wallet signature, nothing locked, but a signature needs a relay to hold it until the owner acts, and there is none yet, so the offer form is hidden. Once a relay exists, the owner accepts by listing at your price and you complete the purchase through the same escrow.

Drops & mint pages

A drop is how a creator releases a collection to the public, with its own branded page at /mint/<collection>. It is built entirely on the escrow you already know: nothing new to trust.

1. 1
   A drop is not a market listing

   The creator deposits the collection's pieces and calls arm(collection, ids, price). Those pieces are the drop's inventory, hidden from the market until minted; a listed piece cannot be armed, and an armed piece cannot be listed or withdrawn until it is disarmed. The first armer is the drop's creator, and only they can disarm or reprice.

2. 2
   Mint is a roll

   mint(collection, qty) pays price × qty, at most 20 rolls per transaction, and receives random pieces from the remaining inventory. The randomness is derived from the previous block hash, the buyer and a nonce, so nobody, not even the creator, can pick.

3. 3
   Sold out is provable

   When the escrow inventory for the collection is empty onchain, the drop is sold out. Burn the key and the supply is locked forever.

Launching a drop, step by step

Two ways to get a collection onchain, then one page to arm it. Whoever holds the collection key sees “Launch a drop” on the collection page; the key can be handed over, so a drop can be inscribed by one wallet and run by another.

A. A handful of pieces: the Inscribe wizard

Inscribe → Collection → drop the files in, name the collection, sign one transaction per piece plus one for the collection and one for the names. Fine up to ten or twenty pieces; every transaction is a wallet popup and a page reload loses the queue.

B. A whole folder: the command line

For a 50-piece release use the repository's drop:inscribe command. It reads a folder, creates the collection, sends one transaction per file with the piece's name and parent written into the data URI (so no metadata transaction is needed), and records every hash in tradex-drop.json next to the art. Stop it, close the laptop, run it again: it continues where it left off and never sends the same bytes twice.

# in the tradex repo, with DROP_PRIVATE_KEY in .env.local
npm run drop:inscribe -- --dir ./vladpunk --collection "Vladpunk" --to 0xPartnerWallet --dry-run
npm run drop:inscribe -- --dir ./vladpunk --collection "Vladpunk" --to 0xPartnerWallet

Names default to “Collection #n” with n taken from the file name (vlad_007.png → #7); a names.json in the folder overrides any of them. Each file must fit the 90 KB calldata budget; the command refuses oversized ones before sending anything.

C. Partner drops

--to is the partner pattern: the pieces are inscribed straight into the partner's wallet, and the collection key follows them after the last piece. The wallet that ran the command pays the gas and never holds the art. The partner then opens the collection page, clicks “Launch a drop”, selects the pieces, sets the price per roll and signs two transactions: a protocol transfer into the escrow and arm. Mint proceeds go to them, minus the 2% market fee. Without --to, --arm 0.01 lets the same wallet deposit and arm from the command line.

rhc-20 tokens

tokens made of inscriptions

An rhc-20 token is not a contract you have to trust. It is an asset whose ledger is the chain itself: every balance can be recomputed from public inscriptions and events, by anyone. Same idea as BRC-20 on Bitcoin.

// deploy — first deploy of a tick wins
data:application/json,{"p":"rhc-20","op":"deploy","tick":"HOOD","max":"21000000","lim":"1000"}
// mint — up to lim per inscription, until max
data:application/json,{"p":"rhc-20","op":"mint","tick":"HOOD","amt":"1000"}
// transfer — send the inscription to the recipient
data:application/json,{"p":"rhc-20","op":"transfer","tick":"HOOD","amt":"250"}

On the Launchpad, every rhc-20 trades on a permanent bonding curve: price is a function of minted supply, p(s) = base · (1 + s/max)². No graduation event, no liquidity pool that can be pulled, no admin key.

Protocol spec (reference)