Rent the Moon for one day. Pick a calendar date, pay by card (no crypto wallet needed), and get a personalized PDF certificate plus a public dedication page. Each day is backed by a unique ERC-721 on Base — tokenId is the date, one tenant per day, forever. A novelty gift, not lunar real estate (Outer Space Treaty). Already live on Base mainnet.
No reviews yetBe the first to leave a review for MoonR
Maker
📌
Hey Product Hunt 👋 — Stan here, maker of MoonR.
The idea is stupid simple: one person can "rent" each calendar day on the Moon. You pick a date, add a dedication, pay by card, and get:
• A gold certificate (PDF in your inbox)
• A permanent public page (moonr.space/day/YYYYMMDD)
• An ERC-721 on Base mainnet — one token per day, tokenId = the date itself
First real booking is already live if you want to see the full flow:
https://moonr.space/day/20260724
Why build this? I wanted a gift that feels enormous but ships in 60 seconds. Anniversaries, proposals, birthdays, "sorry I forgot our date" recovery missions. The Moon is the most exclusive address in the solar system — even if the Outer Space Treaty politely reminds us nobody actually owns it.
Tech stack for the curious: Cloudflare Pages + D1, Paddle checkout, automated mint + email on webhook, dynamic sitemap/SEO so each rented day becomes its own indexable page.
What MoonR is NOT: lunar real estate, a property deed, or a SpaceX boarding pass. It's a novelty registry with on-chain receipts.
Would love your feedback: what date would you book, and for whom? Too cheap at $19, or just right for a meme with a receipt?
Happy to answer anything — wallet-less checkout, refunds, full moons, custody vs self-mint. 🌙
Report
how is the date actually tied to the ERC-721 if someone rents the same day later, does the new buyer just get a different tokenId or does the original certificate get invalidated somehow
Report
Maker
@ersinkeman Good question — the date IS the tokenId. July 24, 2026 mints as token 20260724, and the contract reverts with AlreadyRented if anyone tries to mint that dateId again. So there's no "new buyer gets a different tokenId" scenario: once a day is minted, checkout won't even let you pick it, and the chain enforces it even if our backend somehow tried. Nothing ever gets invalidated — the original certificate is permanent by construction. One date, one token, forever.
Report
What happens if someone tries to rent a date that's already taken mid-payment, do you hold the funds or refund automatically?
Report
Maker
@ayegl433435 Neither, because that collision can't happen: the date is locked the moment checkout opens, before any payment. Reservations are enforced by a unique constraint (one row per date), so the second person gets "this day is already taken" instead of a payment form. Abandoned checkouts auto-release the hold after 30 minutes — no funds were taken, so there's nothing to refund. The only way to complete payment for a date is to be the one holding its lock.
Report
Love that the tokenId is literally the date — such a clean way to make each day feel like its own collectible without needing a crypto wallet to get in on it.
Report
Maker
@ozkur99489 Thanks, Huriye! The date-as-tokenId thing was the moment the whole idea clicked for me — no metadata tricks, the scarcity is just the calendar itself. And yes, the wallet stays optional forever: the token waits in custody until you want it (or never). Which date would you grab?
how is the date actually tied to the ERC-721 if someone rents the same day later, does the new buyer just get a different tokenId or does the original certificate get invalidated somehow
@ersinkeman Good question — the date IS the tokenId. July 24, 2026 mints as token 20260724, and the contract reverts with AlreadyRented if anyone tries to mint that dateId again. So there's no "new buyer gets a different tokenId" scenario: once a day is minted, checkout won't even let you pick it, and the chain enforces it even if our backend somehow tried. Nothing ever gets invalidated — the original certificate is permanent by construction. One date, one token, forever.
What happens if someone tries to rent a date that's already taken mid-payment, do you hold the funds or refund automatically?
@ayegl433435 Neither, because that collision can't happen: the date is locked the moment checkout opens, before any payment. Reservations are enforced by a unique constraint (one row per date), so the second person gets "this day is already taken" instead of a payment form. Abandoned checkouts auto-release the hold after 30 minutes — no funds were taken, so there's nothing to refund. The only way to complete payment for a date is to be the one holding its lock.
Love that the tokenId is literally the date — such a clean way to make each day feel like its own collectible without needing a crypto wallet to get in on it.
@ozkur99489 Thanks, Huriye! The date-as-tokenId thing was the moment the whole idea clicked for me — no metadata tricks, the scarcity is just the calendar itself. And yes, the wallet stays optional forever: the token waits in custody until you want it (or never). Which date would you grab?