Bitmark Marking: NOSTR Relay

Technical Implementation Plan

Fee Gating Logic

Goal

Restrict access to the relay or on-chain marking features based on user payment (in BTMK).

Core Design Options

Option	Description	Tradeoffs
Token-based gating	Pre-pay for a time-limited access token (e.g., JWT)	Easy to revoke/manage
Address balance check	Require user to sign a challenge with BTMK-holding wallet	Fully decentralized
Per-use micropayments	Require NIP-57 zap or LN payment per event	Friction for users, harder to scale

Implementation Steps

1. Create User Identity Layer

Require users to register with:
- NIP-05 identity or email
- Their Bitmark wallet address
Store:
- user_id → wallet
- user_id → relay_quota (N events/day)

2. Prepay/Top-up System

Users can send BTMK to a fee wallet (fee.xmark.cc).
Once confirmed:
- Credit their quota (e.g., 1 BTMK = 100 relays)
- Store in DB: wallet → quota → expiry

3. API Protection

Before accepting a Nostr event:
- Authenticate user (JWT or NIP-98)
- Check their quota
- If valid, decrement count and allow

4. Rate Limiting Fallback

If no payment system yet:
- Add per-IP or per-pubkey rate limiter
- Example: Max 10 events/hour or 1 tx/min

5. Admin Panel / Dashboard

Show:
- Wallets with active quotas
- Daily tx volume per user
- Option to ban/flag abusers

Testing

Simulate a relay spam bot.

Enable fee gating and confirm:

Events from unpaid users are rejected
Paid users can submit and get billed properly

Future Enhancements

Integrate LNURL-pay or NIP-57 zap as access signal
Merge zap and fee logic: e.g., 1 zap = 1 relay credit
Add Nostr DMs for registration confirmation