What's on the Horizon

HeartBadge today handles identity, rewards, proof, and status. The Horizon features complete the picture: a participation bus where every interaction at an event is a message on a channel. Check-ins, shout-outs, broadcasts, reward claims — they all run on the same three endpoints, the same wire format, the same identity keys.

This isn't a messaging app. It's the protocol-native event interaction layer — and messaging is just the first channel type that happened to be obvious.

MessageBox Architecture

Every badge has a messagebox identity derived from its key. Messages are authenticated via BRC-31 — cryptographically signed by the sender, verifiable by the recipient, stored in a relay you control. Three endpoints handle everything:

• sendMessage — dispatch to one or many recipients
• listMessages — pull your inbox
• acknowledgeMessage — mark as read, trigger deletion if ephemeral

That's it. Every channel type below is a different messageBox name on the same infrastructure.

Channel Types

Channels are just message categories. Each has a direction, a fee model, and an ephemeral flag. All run on the same endpoints.

Geo-Scoped Broadcast

A venue or event organizer sends a message to all checked-in members. The check-in system already knows who's present via badge scan. MessageBox already supports multi-recipient sends (the recipients array in the BRC-33 wire format). This isn't a new feature — it's a new messageBox name on existing infrastructure.

"Flash sale at the merch booth — 20% off for the next 15 minutes. Show your badge."

That's a single sendMessage call.

Ephemeral Shout-Out Line

This is the one that's electric. The artist opens a paid inbox at their own rate — say $2 per message. Fans send shout-outs during the show. The artist (or their handler) sees the queue on a dashboard. They pick one, read it on stage, the crowd goes wild.

The economics are already wired:

• Recipient fee = artist's rate (set via MemberSetPermissionRequest)
• Delivery quote = fans see the price before sending (via /getDeliveryQuote)
• Payment = MNEE reward dollars or BSV satoshis, attached to the message
• Ephemeral = artist acknowledges the message (/acknowledgeMessage), it's deleted from the relay. Gone. No archive, no screenshots-from-server. Ephemeral by protocol design.

The artist makes money. The fan gets a moment. The protocol handles the rest. No platform takes a 30% cut — just the 0.001¢ relay fee.

Anonymous Check-In with Rewards

This is exactly the anonymous membership proof in the ZK roadmap:

"I'm a HeartBadge member, I'm physically at this venue, I deserve my check-in reward — but I'm not telling you my name."

The ZK proof proves:

• The sender's key is in the HeartBadge member Merkle tree
• The sender is within geo-fence of the venue (signed location attestation)
• The sender hasn't already checked in (nullifier prevents double-claim)

...all without revealing which member. The reward gets credited to a shielded address. Nobody — not the venue, not HeartBadge, not the other attendees — knows who just checked in. But the protocol knows a valid member did, and the reward is real.

Pricing Model

MessageBox has a simple, transparent pricing model. Platform fee is $0.00001 per message (0.001¢). Network cost scales with message size at BSV's stable ~100 sat/KB rate.

Founding members (first 10,000 badges) get 10,000 free messages — cohort-aligned with the founder privilege model. Top-up rides the existing MNEE reward wallet. No new payment infrastructure.

ZK Roadmap

Zero-knowledge proofs don't encrypt messages — they prove claims without revealing data. For MessageBox, that means three concrete capabilities:

1. Anonymous Membership Proof (buildable now)

"I'm a HeartBadge member, but I'm not telling you which one." Whistleblower mode, anonymous tips, feedback without social consequences.

2. Verified Attributes Without Identity (post-launch)

"I'm a founding member with 100+ messages, but you don't know who." Prove cohort, tier, activity — without revealing identity.

3. On-Chain Delivery Proof (future/experimental)

StarkWare is building the STARK verifier for Bitcoin Script. When that lands, MessageBox delivery receipts become provable on-chain without revealing content. OP_CAT + STARK = verifiable message delivery.

Bump Interactions

Bump interactions bring the badge into the physical world. Two members tap phones (NFC) or both scan the same reader, and something happens.

Bump-to-Connect

Two badges register a connection. You now know each other's badge identifiers. Future messages between you are free.

Bump-to-Send

Send MNEE by bumping. No identifier entry, no QR scanning. Touch, confirm the amount, done.

Bump-to-Gift

Transfer a gift code or issue a sponsored membership by bumping. The recipient's badge activates on the spot.

Co-Sign Attestations

Two members bump and both sign a mutual proof-of-presence: "I was here, and so was this person, at this time." Both badges record the attestation. Both members earn heartbeats. The attestation can stay private or be published to one or both public messageboxes.

The Full Economic Loop

When MessageBox ships, the loop closes:

1. Member participates → earns MNEE and heartbeats
2. Member's public activity attracts attention
3. Attention generates paid messages → member earns more MNEE
4. Member spends MNEE on other members' content (streams, shout-outs)
5. Those members earn → cycle repeats
6. Platform takes 0.001¢ per message
7. Rewards in circulation

That's not a social network. It's not a messaging app. It's a participation bus where every interaction is a channel, attention has a price, and presence has a reward.