A coin that can only be born where it happens.

A1Overview

A spot is one event at one place: a bar night, a booth, a rave on a ferry. On the map it is a gate with a code like G04. Each spot fixes its coin up front: name, ticker, picture, place, how many people can check in, and when the doors open and close.

A host answers for the spot. The host registers a bond and one to four device keys: a screen at the venue or the host's phone. The screen runs the beacon, which shows a check-in code that changes every 15 seconds.

Only a wallet that checked in with a live code can put SOL into the spot's pool. After the doors close, anyone can send the launch. If the pool reached the spot's minimum, the coin is born and every pass holder can claim a share of it, pro rata to what they pooled. If not, every commit goes back in full.

A2Checking in

The code is a link: /c#irl1.<spot>.<bucket>.<key>.<signature>. The site builds one transaction from it: the native Ed25519 signature check of the host's code, then check_in, which reads that check from the instructions sysvar and writes your Pass.

Two ways in

• Room code. Anyone who sees the screen can use it while it is live. Each 15 second window checks in at most ceil(capacity / 60) wallets this way, and the room code can fill at most the spot's room-code share of the passes.
• Tap. You show your wallet code, the host's beacon scans it and signs a code for your wallet only. Taps can fill the whole capacity. Use it when the room code's share is full or when a host wants every pass bound to a person.

Seeker phones

A wallet holding a Seeker Genesis Token (one per Seeker phone) can link it to its pass. That raises the wallet's pool cap from 1 to 2 SOL at this spot. One Seeker boosts one pass per spot, even if the token moves to another wallet.

A3Lifecycle

A4Trust model

• What the program enforces. The code's time window (the current or previous 15 s), one pass per wallet per spot, one Seeker per spot, the per-window and per-spot room-code caps, the capacity, and that only pass holders can pool and become the first holders.
• GPS is only a soft signal on this website. Your location only moves the map. Nothing on chain reads a location; the spot's latitude and longitude are a pin.
• A room code can be relayed live to someone who is not there (a video call, a photo sent in seconds). Rotation stops screenshots, not live streams. The damage is bounded: a code lives 15 to 30 seconds, checks in at most ceil(capacity / 60) wallets per window, and can fill only the room-code share of the spot. The rest needs a tap, which binds one wallet in front of the host.
• A host can sign for people who were not there. Its bond answers for that, but only through the admin's slash_host, a trusted arbiter power (see B4). There is no on-chain proof of absence.
• One person can hold several wallets. The per-wallet cap and the per-window room-code cap limit it; a Seeker token is one per phone.

A5The beacon

The beacon page turns any browser into the host's device. It keeps an Ed25519 key in the browser's storage, created as non-extractable where the browser supports WebCrypto Ed25519 (the page can sign with it but cannot read it). Browsers without it fall back to a key kept in the browser's storage.

1. Connect the host wallet and create the screen's key.
2. Register as a host with a bond of 1 SOL for each spot you will have open at the same time (or add the screen to an existing host: up to four keys, revoke a lost one at once).
3. Open a spot from a fixed menu: capacity, room-code share, when the doors open, how long they stay open.
4. Show the code full screen. Every 15 seconds the screen signs "irlpad:v1" || spot || bucket || 32 zero bytes; in tap mode it signs the same with the attendee's wallet instead of the zero bytes.

The bucket is floor(chain time / 15). The beacon follows the chain's clock, not the device's, and signs a second behind so a fast device clock never produces a code from the future.

A6Worked example

Mainnet defaults; this network's values are in A8.

1. Open. The Salt Lamp registers as a host with a 1 SOL bond (one bond per spot it has open at the same time) and opens "Salt Lamp Friday", $SALT, 300 passes, room-code share 225, doors 20:00 to 02:00. The bond is now locked until 7 days after the launch window.
2. Check in. 120 people check in over the night. Each one sends [Ed25519SigVerify(host key, signature, 81-byte message), check_in(bucket, key_idx, tap)]. At most 5 room-code check-ins land per 15 seconds (300 / 60).
3. Pool. 80 of them commit between 0.01 and 1 SOL (2 SOL with a Seeker). The pool reaches 30 SOL. Anyone can take SOL back until 01:50.
4. Birth. At 02:00 anyone sends birth, alone in its transaction. Budget = 30 - 0.03 rent reserve = 29.97 SOL; deployed = min(29.97, 70) = 29.97 SOL; launch fee 2.5% = 0.749 SOL booked for the pad on the spot's fee account (the treasury is not an account of birth, so no treasury can block a launch); the rest buys $SALT in one pump.fun purchase. Whatever the rents did not use comes back as SOL.
5. Claim. A wallet that pooled 0.6 SOL is owed 0.6 / 30 = 2% of the coins bought and 2% of the SOL that came back. Everyone paid the same price. claim_tokens sends the free half of those coins and the SOL; the other half stays staked in the spot's vault.
6. Fees. The coin's pump.fun creator fees flow to the spot: 40% to the attendees by what they pooled, 25% to the host, 20% to the creator, 15% to the pad. An attendee earns while its half is staked. unstake pays what it earned, sends the staked half, and ends earning for that pass for good.

Above the cap: a pool of 90 SOL deploys 70 SOL; the other 19.97 SOL comes back pro rata with the coins. Below the minimum: a pool of 1.5 SOL (minimum 2) fails and every commit is refunded.

A7Where the SOL goes

A8Parameters

Copied into every spot when it opens, so a change only affects spots opened later. "This network" is read from the program's config now.

Per spot: capacity 1 to max capacity, room-code share 0 to capacity, start from now (5 minutes of clock slack) to 30 days ahead, name 1-32 plain characters, ticker 1-10 of A-Z and 0-9, place 1-48 plain characters, picture on IPFS (ipfs:// or https://ipfs.io/ipfs/).

B1Program reference

Program id irLMgHrfRDbDjoHUc38HnwsfCFVM7zk117eHXUatCqk. Anchor 0.31. Unaudited and upgradeable.

Accounts

Instructions

The presence message

"irlpad:v1" (9) || spot (32) || bucket u64 LE (8) || wallet (32) = 81 bytes. The signature-check instruction must carry exactly one signature, read nothing from other instructions, and contain the host's key from the given slot and exactly this message.

B2Errors

Rendered from the program's interface file (irl.json), plus the shared checks.

B3Verify on chain

1. Open the spot's gate page and the program in an explorer. The Spot account shows passes, total, starts_at, ends_at and its parameters.
2. Every check-in transaction starts with a signature-check instruction whose public key equals one of the host's four device keys (Host account).
3. The vault holds exactly the pool plus its rent floor while the spot is open. /stats recounts that every pool equals the sum of its passes.
4. After birth, the pump.fun curve's creator is the spot's fees account, and the vault's token account holds exactly the coins not yet claimed.

B4Admin powers

B5Risks

• The host is trusted: it can sign for absent people. The bond and the arbiter are the answer, not a proof.
• A live room code can be relayed; bounded by its 15-30 s life, the per-window cap and the room-code share.
• Sybil wallets inside the room are limited by caps, not stopped.
• Earning needs the staked half in the spot: an attendee who wants the fee share cannot trade that half until it unstakes, and unstaking is final.
• A host needs one bond per spot it has open at the same time; the bond answers for all of them together.
• A device clock more than ~15 s off the chain makes codes fail; the beacon uses the chain's clock.
• pump.fun keeps its own admin powers over its curves. The program is unaudited and upgradeable.