Pigeonhole

Sorting room · twelve specimen fills

Sorting rules

  1. A drop is private to the named recipient; the site shows slot numbers and amounts, not a public classified ad.
  2. Amount must be more than 0 BOT, the recipient must be a non-zero address, and the note is optional at 120 characters or fewer.
  3. A parcel is opened or recalled at most once — whichever happens first closes the slot.
  4. Only the recipient can open, and only the sender can recall; the sender cannot open their own parcel unless they addressed it to themselves.
  5. No fee. Native BOT only.
  6. The deployer cannot redirect or collect a parcel, and there is no owner withdraw of other people's parcels.

How a parcel moves

  1. 01Drop Call drop(to, note) with more than 0 BOT and a note of at most 120 characters; the contract assigns the next slot number and seals your BOT inside.
  2. 02Wait The parcel sits in its slot, visible by number and amount, addressed to the one wallet you named and to nobody else.
  3. 03Open The recipient calls open(id); if the parcel has not been recalled, the sealed BOT pays straight to their address and the slot closes.
  4. 04Recall If it is still unopened, the sender calls recall(id) and the sealed BOT returns to them; after that the parcel can never be opened.

Who uses these boxes

Anyone who wants to hand BOT to a specific person without making it a public giveaway. A first payment to a new collaborator, a small thank-you to a friend's fresh wallet, a refund to a buyer whose address you only have as a string of characters.

It also suits people who want a short note to travel with the money: a reason, an invoice reference, a line of thanks. And it suits cautious senders — if the note goes to the wrong place or is never collected, the recall path returns the BOT instead of leaving it stranded.

Because the named recipient is the only one who can open, a pigeonhole is a poor fit for open claims and a good fit for one-to-one handoffs.

A wall of wooden pigeonhole mail slots with brass plates

Why a slot, not a transfer

A plain transfer is final the moment you send it. If the address is wrong, or the person never claims it, the BOT sits with a stranger. A pigeonhole keeps the money sealed until the named recipient acts, and keeps the sender able to take it back while the slot is still closed.

The slot is also quiet. It is not a public noticeboard and not a two-sided deal desk: there is no counter-offer, no negotiation, no listing to browse. You choose one address, write a short note, and the parcel waits. The sorting room shows slot numbers and amounts, not a classified ad for anyone to claim.

Nothing is pooled and no operator sits in the middle. The contract holds each parcel's BOT until exactly one of two things happens: the recipient opens it, or the sender recalls it.

FAQ

What exactly does a parcel hold?

Native BOT on BOT Chain plus an optional note of up to 120 characters. The amount must be greater than 0 BOT and the recipient must be a non-zero address. No other tokens are supported.

How does the recipient get the BOT?

They call open(id) from the address the parcel was addressed to. If the parcel has not been recalled, the sealed BOT pays directly to them and the slot closes for good.

How do I get my BOT back if they never open it?

Call recall(id) from the sending address while the parcel is still unopened. The sealed BOT returns to you and the parcel can no longer be opened by anyone.

Can the sender open their own parcel?

Only if they addressed it to their own wallet. Otherwise the open action belongs to the named recipient alone.

Is there a fee, and can the deployer take my parcel?

There is no fee; you send native BOT and the full amount is sealed in the slot. The deployer has no path to redirect or collect a parcel, and there is no owner withdraw of other people's parcels.

Which network is this on?

BOT Chain mainnet, chain id 677, with BOT as the native token. You can check contract activity on the explorer at https://scan.botchain.ai.

Roadmap

  1. Now The drop, open, and recall actions are specified and the contract is pending deploy; the page describes exactly those three calls and nothing more.
  2. Next Publish the deployed contract address and verify the source so anyone can read the drop, open, and recall logic before sealing BOT.
  3. Later Add a slot lookup that reads parcel state straight from the chain, so senders and recipients can see whether a slot is open, recalled, or already collected.
  4. Beyond Keep the contract limited to the three actions described here; any further work stays inside the same recall-and-open exit path rather than adding new powers over user parcels.

Leave something in a slot

Pick one address, seal some BOT with a short note, and let the parcel wait in its numbered slot. If they open it, the BOT is theirs; if they never do, recall it and the BOT returns to you.

Back to the wall