For builders

Check it yourself.

Two things on this site are claims rather than opinions: that a gift can reach an account with no history, and that the claim secret never touches a server. Both are checkable, and here is how.

Chain ID: 4663
Testnet: 46630
Accounts: ERC-4337
Contracts deployed: None

The feasibility spike

Can a stock token reach a brand-new account?

This product only exists in its intended form if the answer is yes. Robinhood Chain screens transactions at the sequencer, and the recipient of a gift has completed no verification of any kind. Those two facts might have been incompatible.

Reproduce itcurl

# The question that decides whether this product exists:
# can a stock token reach an account that has never done anything?
# Reproduce it in about ten seconds. No key, no funds, no install beyond curl.

RPC=https://rpc.testnet.chain.robinhood.com

# 1. A stock token on Robinhood testnet. TSLA, 18 decimals.
TOKEN=0xc9f9c86933092bbbfff3ccb4b105a4a94bf3bd4e

# 2. An account with no code, no nonce, no balance, no history whatsoever.
FRESH=0xd7a0977b840684881ef3fe0d5378a3d4ae38c327

# 3. Simulate a transfer into it from a real holder.
#    transfer(address,uint256) = 0xa9059cbb
HOLDER=0x6063e834928eac1ca47ac5da27838079a103e305
DATA=0xa9059cbb000000000000000000000000d7a0977b840684881ef3fe0d5378a3d4ae38c3270000000000000000000000000000000000000000000000000de0b6b3a7640000

curl -s -X POST $RPC -H 'content-type: application/json' -d "{
  \"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"eth_call\",
  \"params\":[{\"from\":\"$HOLDER\",\"to\":\"$TOKEN\",\"data\":\"$DATA\"},\"latest\"]}"

# -> {"result":"0x...0001"}   the transfer succeeds. No allowlist, no gate.

# 4. And the multiplier, which every displayed value must go through.
#    uiMultiplier() = 0xa60bf13d
curl -s -X POST $RPC -H 'content-type: application/json' -d "{
  \"jsonrpc\":\"2.0\",\"id\":2,\"method\":\"eth_call\",
  \"params\":[{\"to\":\"$TOKEN\",\"data\":\"0xa60bf13d\"},\"latest\"]}"

# -> 0x0de0b6b3a7640000 = 1e18. A WAD. Note that uiMultiplierDecimals()
#    REVERTS on the deployed contracts — do not read it to scale this.

Result

Unrestricted

Simulated transfers of TSLA, AMZN, AMD, PLTR and NFLX into accounts with no code, no nonce and no balance all succeed. So do transfers into a contract. No allowlist, no transfer hook, no compliance registry in the token itself.

Gas differential

88,247 vs 71,067

A fresh account costs about 17k more gas to receive into than a warm one — a cold storage slot being written for the first time. That is the strongest available evidence that these really are accounts that have never held anything.

What this does not prove

Sequencer admission

eth_call executes against EVM state; the compliance engine runs inside the sequencer, before sequencing. This settles the token contract question completely and the sequencer question only by inference — a fresh account has no risk signal to screen on. Broadcasting a funded transaction is the remaining step and it needs testnet funds.

uiMultiplierDecimals()

Reverts

Not implemented on the deployed contracts. The multiplier is a WAD — fixed 18 decimals. Code that reads the decimals call to scale it reverts and blanks every figure on the page.

The claim link

The secret is in the fragment, and that is the whole design.

Why a fragment

Everything after the # is never transmitted by any browser. So the claim secret never reaches our infrastructure, never lands in an access log, and cannot be replayed by anybody who compromises us. There is no server-side record that a given gift exists, let alone what is in it.

Referrer-Policy: no-referrer

Set globally. Without it, a single outbound link from the claim page would hand the full URL — fragment included on some clients — to a third party. It is one header and it is load-bearing.

Analytics never see it

assertNoSecret() in src/lib/gift.ts screens every outbound payload for a fragment-shaped string. It throws in development and drops the payload in production — deliberately not the other way around, since a thrown error would itself get reported.

The preview reveals nothing

The OG card renders from no input at all — not the id, not the amount, not the sender. A preview reading “$500 of NVIDIA, tap to claim” sitting in a group chat is a theft notice, so there is no code path that could produce one.

The gift rides in the fragment too

With no escrow to read from yet, the gift’s details sit alongside the secret. A gift is therefore fully shareable with no database and no server-side record of what anybody sent — and it exercises the fragment discipline in the one place where breaking it would be immediately, visibly broken.

The interesting problem here is onboarding, not finance.