Receipts, review IDs, and shareable settings
Launch is review-first: the product generates deterministic review material before you sign, then stores a receipt after confirmation so you can prove what landed.
The short answer
Shareable settings encode draft form state into a URL so a teammate can open the same prep (without disclosure checkboxes that must be re-accepted). A review / receipt id changes when material launch settings change so you can tell two preps apart. A post-launch receipt stores mint or contract address, tx signature/hash, network, and related explorer links—locally first, optionally backed up when you are signed in.
Shareable settings links
Use “Copy settings link” when a second operator should fill the same name, ticker, and buy table without retyping. Switching rails drops setup encoding because Solana and Robinhood drafts are not the same schema. Never paste a settings link into a public chat if it contains private strategy notes you would not want scraped.
Local receipts vs signed-in backup
Local storage keeps receipts in the browser so offline review still works. Clearing site data deletes them. When signed in, the app can POST a backup that re-verifies against RPC before storing—so a backup failure still leaves the explorer signature as the public source of truth.
What operators should archive
- Mint or contract address (full string).
- Transaction signature / hash.
- Network id (devnet / mainnet / RH testnet / RH mainnet).
- Metadata URI (Solana) or verification package (EVM).
- Timestamp and which profile / supply split was intended.
For personal trading history rather than deploy ops, use the journal path separately.
Next