A JSON record in a transaction, read by an index, never executed.

1.Envelope

An inscription is a transaction on Robinhood Chain (chain id 4663) whose data is the UTF-8 bytes of a JSON object, and nothing else. No prefix, no encoding, no contract: the bytes you can read on the block explorer are the record.

• Recipient. A deploy, mint or launch is sent to the sender's own address. A transfer is sent to the address the units go to.
• Value. Zero, except inside a launch window where the record carries the price (section 6).
• Sender. The account that signed the transaction is the actor for every op. There is no delegation and no operator field.
• Size. At most 4 KB of calldata. Larger records are ignored by the index.
• Ordering. Records are ordered by block, then by transaction index. A record in a reverted transaction does not exist.

// the whole transaction, as the index sees it
{
  "to":    "<sender>",          // self for deploy, mint, launch
  "value": "0",
  "data":  0x7b2270223a22726f622d3230222c226f70223a226465706c6f79222c227469636b223a22524f4249222c226d6178223a223231303030303030222c226c696d223a2231303030227d
}
// which decodes to
{"p":"rob-20","op":"deploy","tick":"ROBI","max":"21000000","lim":"1000"}

2.The four ops

Every record has p set to rob-20 and an op that is one of the following. Anything else is not a ROB-20 record.

3.Fields

All values are strings, including numbers, so that no reader has to guess at precision. Numbers are decimal integers with no sign, no separators and no leading zeros. Unknown fields are ignored; a record is never invalid for carrying one.

4.Validity

A record that fails any rule is ignored in full. It is still on the chain, and the gas is still spent; the index simply does not count it. Nothing is ever partially applied.

1. Well-formed. Valid JSON, one object, p is rob-20, every required field for the op present and typed as above.
2. First deploy wins. The first valid deploy or launch of a ticker, in chain order, creates it. Every later one for the same ticker is ignored, from anyone, including the original deployer.
3. Mint within limits. A mint is valid only for a ticker that exists, with amt at most lim, and only while minted supply plus amt is at most max. A mint that would cross max is ignored whole — it is not trimmed to fit.
4. Transfer from balance. A transfer is valid only if the sender's balance of the ticker, as of the previous record, is at least amt. Balances never go negative and a transfer never partially applies.
5. Inside the window. A mint of a launched ticker is valid only between pass (or open) and close, with the transaction value equal to price, and — before open — only from a wallet bound to a pass.
6. One actor. The signer is the sender for every op. A contract that forwards calldata does not inscribe on anyone's behalf; the contract is the sender.

5.The index

The index is a deterministic function of the chain: given every transaction on Robinhood Chain in order, it produces the same set of tickers, balances and artifacts on any machine. Robition runs one and publishes what it reads; anyone can run their own from these rules and should get the same answer. A disagreement between two indexes is a bug in one of them, or a gap in this document.

• State is per ticker: max, lim, minted supply, and a balance per address.
• Reorgs. The index follows the canonical chain. A record in a block that is later dropped is dropped with it.
• Finality. What the page shows as confirmed is what is final on Robinhood Chain; pending records are shown as pending and count for nothing until they land.

6.Launches and artifacts

A launch is how the launchpad opens a ticker. It deploys and sets a window in one record. Inside the window, each valid mint is an artifact: the index issues an NFT to the minting wallet that carries the mint record and the launch it came from. The token standard for artifacts, and the contract that holds them, is named in the launch's meta and will be published with the first launch.

• Pass window. From pass to open, only wallets bound to a Series 001 pass may mint. The bound wallet is the one a pass was issued to on this site.
• Public window. From open to close, anyone may mint, until max.
• Price. Every mint carries price as its value, to the launch's own address. A mint with the wrong value is ignored, and the ETH stays where it was sent — so wallets are expected to refuse a mint the index would ignore.
• Fee. Robition takes a fee from the creator on a launch, not from minters and never from pass holders.

{
  "p": "rob-20",
  "op": "launch",
  "tick": "ROBI",
  "max": "21000000",
  "lim": "1000",
  "price": "1000000000000000",   // 0.001 ETH per mint, in wei
  "pass": "1760000000",          // pass holders from here
  "open": "1760086400",          // everyone from here
  "close": "1760691200",
  "meta": "ipfs://…"
}

7.Examples

The three plain ops, as the calldata of a zero-value transaction.

// deploy — to self
{"p":"rob-20","op":"deploy","tick":"ROBI","max":"21000000","lim":"1000"}

// mint — to self, up to lim, while supply lasts
{"p":"rob-20","op":"mint","tick":"ROBI","amt":"1000"}

// transfer — to the recipient; amt leaves the sender's balance
{"p":"rob-20","op":"transfer","tick":"ROBI","amt":"250"}

And the mint above, hex-encoded the way it sits in the transaction:

0x7b2270223a22726f622d3230222c226f70223a226d696e74222c227469636b223a22524f4249222c22616d74223a2231303030227d

8.What may change

This is draft 0.1. The parts most likely to move before the first launch, in the order they are likely to move:

• The artifact contract and token standard named by meta, and whether an artifact is minted by the index or by the launch itself.
• Whether a transfer is one step or two — inscribe, then send the inscription — as it is on other chains.
• The ticker length and character set.
• The calldata size limit.

Changes are announced on @robitionapp before they apply, and this page carries the version they apply from. Records written under an earlier draft are read under the rules that were current when they landed.