FOSSIL documentation

A FOSSIL is a permanent, verifiable, on-chain container for a Robinhood Chain coin's media. Once sealed, it never depends on any server, database, or offchain gateway. Verify it from any RPC.

What a fossil is

Each specimen is a struct in the FOSSIL contract keyed by the token address:

Specimen {
  address creator      // recorded by the launchpad curve
  uint64  openedAt     // block number
  uint64  sealedAt     // block number, 0 while unsealed
  uint32  size         // declared total bytes
  uint32  written      // bytes appended so far
  bytes32 digest       // sha256 of the full content
  string  mime         // e.g. image/webp
  string  meta         // JSON, up to 2048 bytes
  address[] pointers   // SSTORE2 contracts holding the raw bytes
}

Content is written as contract bytecode using SSTORE2 (data prefixed with a 0x00 stop byte). Each pointer holds up to 24,575 data bytes, the EIP-170 code limit minus one.

The two-step launch

1. Launch. Approve 2 USDG to the launchpad factory when your allowance is short, then call factory.launch(name, symbol). The curve records the caller as the creator. The token address is emitted in the Launched event.
2. FOSSIL stamp. Under 80,000 bytes fits in a single call to stamp(token, mime, meta, digest, data). Larger payloads use open → append × N → seal. The seal step reads every pointer back inside the transaction, computes SHA-256 on-chain, and reverts if it does not match the declared digest.

The on-chain SHA-256 seal

The seal step is the point of trust. It hashes the same bytes that will be returned by read(token), so a passing seal is a promise that any future read is exact. Nothing in the contract can overwrite a sealed specimen.

Reading a specimen

Every sealed specimen is readable in three ways:

• read(token) returns the raw bytes (concatenated pointer content).
• dataURI(token) returns data:<mime>;base64,… suitable for embedding directly. Intended for small and medium payloads.
• Or, without touching the FOSSIL contract, take the pointer addresses and read them raw with eth_getCode, dropping the first byte.

Verify from any RPC

The seal is verifiable from any node with an eth_call:

# 1. Read the raw bytes.
cast call 0x91Aaf9C3cC0c9faBBC3D02e3AC46A554FCc1a179 \
  "read(address)(bytes)" <TOKEN> \
  --rpc-url https://rpc.mainnet.chain.robinhood.com \
  | xxd -r -p > specimen.bin

# 2. Take the on-chain digest.
cast call 0x91Aaf9C3cC0c9faBBC3D02e3AC46A554FCc1a179 \
  "specimen(address)((address,uint64,uint64,uint32,uint32,bytes32,string,string,address[]))" \
  <TOKEN> --rpc-url https://rpc.mainnet.chain.robinhood.com

# 3. Confirm the SHA-256 matches.
sha256sum specimen.bin

Costs

• Creation fee: 2 USDG to the launchpad factory.
• UI content cap: 102,400 bytes by default (configurable per deployment).
• Contract content cap: 1,048,576 bytes.
• Per-tx calldata cap: about 95 KB on Robinhood Chain. Anything up to about 80,000 bytes fits in one stamp transaction.

Meta JSON schema

{
  "v": 1,
  "description": "optional string, up to 500 chars",
  "x": "optional https://x.com/... URL",
  "web": "optional https:// URL"
}

Addresses

• FOSSIL: 0x91Aaf9C3cC0c9faBBC3D02e3AC46A554FCc1a179
• Launchpad curve: 0x6782C15Bf5F5d5d7ca046370BF1829D5Cd4348b0
• Launchpad factory: 0x207BF73841c5bf0DA2141317dB995f4ABa014e5b

Faq

Can I fossilize a token that was launched somewhere else?

No. FOSSIL only accepts writes from the creator recorded by the launchpad curve, so the coin must be launched through the same Robinhood Chain launchpad.

What happens if the tab closes mid-stamp?

The create flow stores a resume record in localStorage right after the launch tx confirms. On the next visit to /create the same token is offered for resumption; the file must be re-picked and hashed to confirm it is the same one.

Can a specimen be replaced?

Only before it is sealed. Once sealedAt is nonzero, no function in the contract writes to the specimen. An unsealed attempt is discarded when the same creator opens a fresh one.

Where can I follow updates?

On X: @fossil_rh.