How a ticket proves it was paid for without saying who paid.

Blindwoods is a private AI on Robinhood Chain. You pay from your wallet and you ask with a blind ticket, and nothing on our side can connect the two. Each ticket asks one question of a model running inside a hardware enclave, which your browser checks before it sends anything.

There is no account. The service never learns which wallet a question came from, because the ticket that carries the question was signed without the signer ever seeing it. $BLIND holders receive fresh tickets every day, paid for by the fees on $BLIND trades.

• ·Two doors, one wall: the wallet door takes payment, the ticket door takes questions, and nothing crosses between them.
• ·Blind tickets: blind RSA signatures (RFC 9474), the primitive behind Privacy Pass (RFC 9576 to 9578).
• ·Enclave-only models, checked in your browser; your question is sealed to the enclave before it leaves the page.
• ·Ownerless contracts for every split of money, and a public meter of what the fees paid for.
• ·A leak bounty that pays whoever finds a log, a tracker or a way to link a ticket to a wallet.

Door 1 is the wallet door. You pay USDG for a pack, or you prove that you hold $BLIND by signing a message. The booth behind this door checks the payment or the balance and stamps a batch of tickets your device has sealed. It writes down one line: this wallet received this many tickets today.

Door 2 is the ticket door. You hand over one ticket with your question. The gate behind it checks the stamp, crosses the ticket's serial off a spent list, and forwards the question, which your browser has already sealed to the enclave: the gate carries ciphertext it cannot open. It never learns which wallet the ticket came from, because no stamp it has ever issued can be matched to the ticket in front of it.

We see at door 1

the wallet that bought or claimed, how many tickets, the purchase tx (public anyway)

We see at door 2

a valid, unspent ticket; hourly totals for the meter

We never see

which wallet a ticket came from, your questions or answers, an account, your address at the gate once the relay ships

The wall is not a policy. It is a property of the signature scheme: the stamp the booth gives and the ticket the gate sees share no number anyone can compare.

Think of a carbon-lined envelope. You seal a ticket inside, the booth stamps the envelope from the outside, the stamp presses through onto the ticket, and you open the envelope at home. The booth stamped something it never saw.

1. 1Your device writes a random serial for each ticket and keeps it.
2. 2It seals each serial: the serial's encoding is multiplied by a random factor raised to the booth's public exponent. Only your device knows the factor.
3. 3The booth checks the payment or the holding and signs the sealed values with its private key.
4. 4Your device divides the factor back out. What remains is a valid signature on the serial itself.
5. 5Anyone can verify the ticket with the booth's public key. The serial goes on a spent list when it is used.
6. 6Because the factor was uniformly random, the sealed value the booth saw is unrelated to the ticket: every envelope the booth ever stamped fits every ticket equally well.

Scheme

RSABSSA-SHA384 (RFC 9474), RSA-2048

Keys

one per 24 h epoch; a ticket names its key id

Ticket life

72 h after its key was published, then the key is deleted

Batch size

up to 200 tickets per draw

Carried as

the Authorization: PrivateToken header (RFC 9577)

The booth on the home page runs this math for real in your browser, with a simplified full-domain-hash encoding instead of PSS. Sealing, stamping and opening are the same operations.

Packs

Anyone buys with USDG on Robinhood Chain, at $0.01 a ticket. A pack is an entitlement held against the paying wallet: your device draws blind tickets from it in batches, so nothing you bought expires. Only drawn tickets do.

Pocket

500 tickets · $5 USDG

Daily

2,500 tickets · $25 USDG

Heavy

10,000 tickets · $100 USDG

Studio

50,000 tickets · $500 USDG

Holder allowance

Wallets at or above the Sapling line claim free tickets every day by signing a message. The Compute Pool pays for them, and trading fees refill the pool.

Wanderer

holds none · buys packs

Sapling

hold 100,000 $BLIND · up to 20 tickets a day

Grove

hold 1,000,000 $BLIND · up to 250 tickets a day

Old Growth

hold 10,000,000 $BLIND · up to 3,000 tickets a day

budget     = 1/30 of the Compute Pool each UTC day, in tickets
weight     = $BLIND held × tier multiplier (1 · 1.25 · 1.5)
allowance  = min(tier cap, budget × weight / all weights)

The balance is checked at the claim and at two random blocks in the previous 24 hours. Caps rise faster than the tier lines, so one bag split across many wallets always gets fewer tickets. The pool pays the published inference payee only for tickets actually drawn, and never more than 1/30 of itself in a day; budget nobody claims stays in the pool.

Seeds

Any device with tickets can turn some into a seed link. The tickets ride after the # in the link, the part browsers never send to a server; the first device to spend them owns them, and they expire with their key like any ticket.

Standard message

1 ticket · up to 2,000 tokens in, 1,000 out

Premium model

3 tickets a message

Picture

5 tickets

Every model answers inside a hardware enclave. Your browser checks the enclave before anything is sent, then encrypts the question to a key only that enclave holds, so the gate in between carries ciphertext. There is no fallback to a model outside an enclave: if the check fails, nothing is sent.

1. 1Your browser fetches the enclave's attestation bundle: its hardware report and the code release it claims to run.
2. 2The release is checked against its digest, its build signature and a public transparency log.
3. 3The hardware report is checked against the processor vendor's keys, and what it measured must equal what the signed release says.
4. 4Your question is encrypted to the key named inside that report (HPKE, through the Encrypted HTTP Body Protocol), so only that enclave can open it.
5. 5The enclave you reach is a router: it checks the model enclaves it forwards to in the same way before it uses them.

A failed or skipped check is a failure, never a warning: the chat sends nothing until every step passes. A badge that only checks that evidence exists is not a check.

A trade of $BLIND pays 2%: the launchpad's fee plus a creator tax. 1.7% of the volume reaches the FeeRouter, a contract with no owner that anyone can run.

• Compute Pool: buys inference for holder tickets50%
• Buyback and burn: $BLIND bought and sent to the dead address20%
• Builders: team, audits, infrastructure20%
• Leak Bounty Vault: pays whoever finds a log10%

Every ticket sale is split in the same transaction by TicketMint, which also has no owner.

• Inference and operations80%
• Compute Pool10%
• Buyback and burn10%

pool tickets per $1 traded = 1.7% × 50% / $0.01 = 0.85

$50,000 a day

$850 to the router · 42,500 pool tickets

$250,000 a day

$4,250 to the router · 212,500 pool tickets

$1,000,000 a day

$17,000 to the router · 850,000 pool tickets

Standard ticket

$0.01 · cost ≈ $0.006 (assumed)

Premium message

$0.03 · cost ≈ $0.020 (assumed)

Picture

$0.05 · cost ≈ $0.030 (assumed)

Volumes are model inputs, not forecasts. The meter on the home page shows the real numbers from launch on.

Supply

1,000,000,000 $BLIND, fixed, no mint function

Team allocation

none · no presale · no private round

Launch

Pons launchpad on Robinhood Chain, fair launch, quote token USDG

Graduation

the launchpad's setting for the USDG pair, read on chain at launch

Dev buy

at most 2%, in the creation transaction, into a 90-day vesting wallet

Snipe-tax exemptions

the dev wallet, nothing else

• sold along the bonding curve (measured on a live launch of the same launchpad)71.4%
• seeded into the pool at graduation20.4%
• locked by the launchpad at graduation8.2%

What $BLIND does

• ·Daily blind tickets, sized by tier
• ·Premium models from Grove, pictures and API tickets at Old Growth
• ·A vote on the next model added (Old Growth)

What $BLIND never does

• ·Pay holders money. It gives tickets and features, nothing else.
• ·Buy privacy. A bought ticket and a claimed ticket are the same object.
• ·Open a softer door. Every ticket passes the same stamp check.
• ·Change the fee split. The router has no owner.

Launch receipt

• ·The creation transaction, the dev wallet and the dev buy
• ·The exemption list: the dev wallet only
• ·Every buyer in the first minute, with amounts
• ·The fee recipient: the FeeRouter address
• ·The vesting wallet and its release date

TicketMint

buy(packId), buyWithPermit(…): USDG in, split 80% / 10% / 10% in the same call · event Purchased

FeeRouter

the coin's fee recipient · claim() pulls the fee, distribute() splits 50% / 20% / 20% / 10%

ComputePool

dailyBudget() public, in tickets · pays only a published inference address

BountyVault

pays only on a 2-of-3 verdict, with the report hash in the event · unspent after 12 months goes to audits, never to the team

BuybackBurner

buys $BLIND and sends it to the dead address

None of these contracts can be upgraded or paused, and none has an owner who can move money. Addresses are published here and on the receipt at launch.

• ·The chat page loads scripts, styles, fonts and images from its own origin only, enforced by its content security policy.
• ·The wallet door is the only page that talks to the chain; the chat page carries no wallet code at all.
• ·History stays in this browser. Export it or wipe it whenever you like.
• ·Tickets live in the browser's own storage; move them to another device as a text pack.
• ·Draw a batch ahead of time and ask later: a draw right before a question says more about timing.
• ·Builds are reproducible: every release hash is published, and the page shows its own (phase 3).

The chat endpoint follows the familiar chat-completions shape. Instead of an API key, each call carries tickets, and its body is encrypted to the attested enclave: the gate refuses a plain body. Any client that speaks the Encrypted HTTP Body Protocol can call it.

GET /api/keys

today's stamp key and every key still honoured

GET /.well-known/private-token-issuer-directory

the same keys, in the standard Privacy Pass directory format

POST /api/tickets/draw

door 1: a signed-in wallet's blinded batch → blind signatures

GET /api/me

door 1: tickets bought, drawn and left

POST /v1/chat/completions

door 2: tickets in the Authorization header, the body sealed to the enclave

GET /attestation

the enclave's attestation bundle, passed through for your own check

GET /api/models

models and what each costs in tickets

GET /api/meter

public hourly totals

POST /v1/images/generations

door 2: 5 tickets a picture (phase 2)

POST /v1/chat/completions
Authorization: PrivateToken token="<one ticket>"
Ehbp-Encapsulated-Key: <hex>
Content-Type: application/json

<the chat-completions body, sealed to the enclave's key>

10% of the creator fee fills a vault that pays whoever proves a privacy claim wrong.

• Link a ticket to a wallet50%
• Find a log of a question or an answer30%
• Catch the app calling a third party10%
• up to: Any other privacy defect5%

• ·A reproducible proof, encrypted to the bounty key published on the bounty page.
• ·The first valid report wins; a duplicate of a paid report gets nothing.
• ·A 2-of-3 verdict within 72 hours, posted on the meter page.
• ·The fix ships first, then the full report, with your credit or with none.

What blind tickets cannot protect

• ·What you type: a name or an address inside a question names you, ticket or not.
• ·Your device: malware, a shared browser or a wallet extension can read the page.
• ·Timing: in a small crowd, a batch drawn at 10:00 and a question at 10:01 can be guessed. Random prefetch and the relay help; a bigger crowd helps most.
• ·The network edge in phase 1 sees addresses in transit (never stored); the phase 2 relay removes them.
• ·Hardware trust: attestation is only as good as the vendors' roots and their patches.
• ·The launchpad's owner holds a timelocked power over a coin's fee recipient. We watch for it and will say so.

Attacks and defences

Borrow a bag, claim, return it

balance checked now and at two random blocks in the last 24 h

Split one bag across wallets

super-linear caps: many small wallets get fewer tickets

Hoard tickets

drawn tickets expire 72 h after their key

Spend a ticket twice

the spent set, per key epoch

Resell tickets

allowed; it hurts nobody's privacy and expiry keeps it small

Flood the gate

every request costs a ticket

Phase 1 · days 1 to 10 · building now

• ·Ownerless contracts deployed and verified
• ·Booth (blind stamps, daily keys) and gate
• ·Chat with a standard enclave model; premium with the holder tiers
• ·Attestation checked in the browser; questions sealed to the enclave
• ·Packs, holder claims, the meter, the receipt
• ·Launch on Pons

Phase 2 · weeks 2 to 6

• ·A relay run by a third party, so the gate never sees an address
• ·Pictures, seed links, the Forest
• ·The leak bounty live, with a first public review
• ·Chat-completions API paid in tickets

Phase 3 · months 2 to 4

• ·Our own enclave nodes with published measurements
• ·Reproducible builds and a transparency log
• ·Zero-knowledge holding proofs: claim without naming the wallet
• ·The stamping key split across operators

Phase 4 · months 4 to 12

• ·Partner apps on the chain accept the same tickets
• ·Private agents that pay their own way
• ·A mobile app with an on-device ticket store
• ·New enclave models by holder vote

The Forest marks the way: one tree for every 1,000 untraceable answers. At 100 trees a new model is added, at 1,000 the bounty vault gets a top-up, at 10,000 the stamping key is split across two operators.

Model

ticket $0.01 = one standard message (up to 2,000 in, 1,000 out)

Assumed

cost ≈ $0.006 a standard message

Model

premium = 3 tickets, picture = 5

Model

tier lines 100k / 1M / 10M $BLIND, caps 20 / 250 / 3,000 a day

Assumed

creator tax 1%, so 1.7% of volume to the router

Model

router split 50 / 20 / 20 / 10; ticket sale split 80 / 10 / 10

Model

key epoch 24 h, ticket life 72 h, batch 200

Model

dev buy at most 2%, 90-day vesting

Assumed

quote token USDG (an ETH pair is possible)

Measured

curve, pool and lock shares from a live launch of the same launchpad

Measured

a USDG-paired launch from a contract, its fees claimed in USDG (proven on a mainnet fork)

Model

phase 1 inference through a vetted enclave gateway, its release and hardware checked in the browser

Do I need $BLIND to use Blindwoods?

No. Anyone can buy a pack with USDG. Holding $BLIND adds free tickets every day; it never changes how private a ticket is.

Can you see my questions?

The gate passes a question to an enclave model and keeps nothing but hourly counters. It cannot tell which wallet a ticket came from. What you type is still yours to keep anonymous: a name inside a question names you.

Can the booth link my claim to my questions?

No. The booth signs sealed values it cannot read, and every envelope it stamped fits every spent ticket equally well. You can try to beat it on the home page.

What happens if I lose my tickets?

Drawn tickets live in your browser. Undrawn pack tickets stay in your entitlement, so you can draw a new batch from the wallet that paid. Lost drawn tickets expire with their key.

Is Blindwoods affiliated with Robinhood?

No. Blindwoods is a community project built on Robinhood Chain.