This document describes the architecture for compensating volunteer peers in Lantern's unbounded network with the LANTERN token. Peers in uncensored regions contribute their IP address, CPU, memory, and bandwidth to help censored users access the open internet. In return, they earn LANTERN tokens.
LANTERN is an SPL token on Solana.
Paying peers in stablecoins would require Lantern to fund rewards from treasury. At realistic rates (~$2/month/peer), stablecoin payments would be too small to motivate participation and too expensive for Lantern to sustain at scale.
A native LANTERN token solves both problems:
-
Speculative upside is the incentive. Peers participate because they believe the network -- and thus the token -- will grow in value. This is the same dynamic that bootstrapped Helium to 500,000+ hotspots: nobody deployed a hotspot for $5/month in IoT revenue. They did it because HNT might appreciate.
-
Lantern doesn't need cash to pay peers. Token emissions come from a pre-minted supply, not from revenue. The cost to Lantern is dilution, not dollars.
-
Lantern's speculative story is stronger than Helium's. Helium had a massive supply/demand mismatch -- hundreds of thousands of hotspots but almost no IoT data demand. Lantern has real, organic demand from millions of censored users. The bet for peers is: "this network has real users who need this service, and I'm earning a stake in it."
-
Token staking creates a natural Sybil-resistance mechanism. Peers who stake LANTERN to earn higher trust tiers have skin in the game that can be slashed.
Early on, LANTERN value is purely speculative. Over time, value drivers include:
- Network growth: More censored users = more demand for peers = more useful network = token narrative strengthens
- Staking demand: Peers must stake LANTERN to reach higher trust tiers and earn more efficiently, creating persistent buy pressure
- Governance value: Token holders govern emission rates, geographic multipliers, and protocol parameters
- Future premium features: Optional paid tiers for censored users (faster speeds, dedicated peers) could require LANTERN, creating organic demand
- Lantern treasury buybacks: As Lantern generates revenue from other products, a portion could go to market buybacks, creating a value floor
- Token-native from day one. LANTERN is the compensation mechanism. No stablecoin intermediary.
- The censored user is the primary verifier. They have no incentive to lie about bandwidth received -- they want real service. Leverage this asymmetry.
- Spot-check sampling, not universal proof. Route a random fraction of traffic through the egress server for ground-truth measurement. The peer can't predict which connections are sampled.
- Progressive decentralization. Start with Lantern-operated infrastructure (oracle, egress verifiers) and decentralize over time.
- Make cheating economically irrational. Staking + slashing + graduated trust make Sybil attacks unprofitable.
┌──────────────┐
│ Freddie │
│ (Discovery/ │
│ Signaling) │
└──────┬───────┘
HTTP │ signaling
┌──────────┴──────────┐
│ │
┌──────┴──────┐ ┌──────┴──────┐
│ Censored │ │ Widget │
│ User │ │ Peer │
│ (Desktop) │ │ (Uncensored)│
└──────┬──────┘ └──────┬──────┘
│ │
│ WebRTC │ WebSocket
│ DataChannel │
└─────────────────────┘
│
┌──────┴──────┐
│ Egress │
│ Server │
└──────┬──────┘
│
│ QUIC / TCP
▼
┌─────────────┐
│ Destination │
│ Site │
└─────────────┘
Key properties of the current system:
- Freddie is a stateless signaling relay that matches censored users with volunteer peers
- All traffic flows through a Lantern-operated egress server, which already meters
ingress-bytesper session via OpenTelemetry - Peers are identified only by session UUID -- no cryptographic identity
- No incentive, reputation, or accounting system exists
- QUIC connection migration (Turbo Tunnel) maintains state across ephemeral WebSocket paths
Ship first. Works with the existing architecture, no direct-to-destination routing needed.
┌──────────────┐
│ Freddie │
│ + Wallet │
│ Registration│
└──────┬───────┘
│
┌──────────┴──────────┐
│ │
┌──────┴──────┐ ┌──────┴──────┐
│ Censored │ │ Widget │
│ User │ │ Peer │
│ │ │ + Ed25519 │
│ │ │ + Solana │
│ │ │ Wallet │
└──────┬──────┘ └──────┬──────┘
│ WebRTC │ WebSocket
└─────────────────────┘
│
┌──────┴──────┐
│ Egress │
│ Server │
│ + Per-Peer │
│ Bandwidth │
│ Accounting │
└──────┬──────┘
│
┌────────────────┤
│ │
▼ ▼
┌─────────────┐ ┌─────────────┐
│ Reward │ │ Destination │
│ Oracle │ │ Site │
└──────┬──────┘ └─────────────┘
│
▼
┌─────────────┐
│ Solana │
│ (LANTERN │
│ SPL Token) │
└─────────────┘
What changes from today:
- Peer cryptographic identity: Peers generate Ed25519 key pairs and register a Solana wallet address during Freddie signaling
- Per-peer bandwidth attribution: Egress server attributes
ingress-bytesto the forwarding peer (not just the consumer session) - Reward oracle: Reads egress telemetry, tallies bandwidth per peer per epoch, distributes LANTERN from the rewards vault
- Epoch-based settlement: Every hour (or day), the oracle submits a batch settlement transaction to the rewards program on Solana
Reward calculation:
peer_reward = base_emission_per_GB
* bytes_relayed
* uptime_multiplier (0.0 - 1.0, based on availability)
* geo_diversity_multiplier (1.0 - 3.0, higher for underserved regions)
* connection_quality_factor (0.5 - 1.0, penalizes excessive drops)
* epoch_emission_curve (decreasing over time, like Bitcoin halving)
Phase 1 is fully verifiable because all traffic flows through the egress server. No trust assumptions beyond the egress server itself, which Lantern operates.
When direct-to-destination routing is implemented in unbounded.
┌──────────────┐
│ Freddie │
│ + Routing │
│ Directives │
└──────┬───────┘
│
┌──────────┴──────────┐
│ │
┌──────┴──────┐ ┌──────┴──────┐
│ Censored │ │ Widget │
│ User │ │ Peer │
│ + Receipt │ │ + Ed25519 │
│ Signing │ │ + Staking │
└──────┬──────┘ └──────┬──────┘
│ WebRTC │
└─────────────────────┤
│
┌────────────────┼────────────────┐
│ │ │
(sampled) (direct) (direct)
│ │ │
▼ ▼ ▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Egress │ │ Destination │ │ Destination │
│ Server │ │ Site A │ │ Site B │
│ (Verifier) │ └─────────────┘ └─────────────┘
└──────┬──────┘
│
┌──────┴──────┐
│ Reward │◄─── Signed bandwidth receipts
│ Oracle │ from censored clients
└──────┬──────┘
│
┌──────┴──────┐
│ Solana │
│ LANTERN │
│ Programs │
└─────────────┘
The spot-check sampling protocol:
-
Freddie includes a routing directive with each connection assignment. The directive specifies whether this connection should be routed through the egress server (sampled) or directly (unsampled). The sampling decision is made server-side and is opaque to the peer.
-
For sampled connections, the egress server independently measures bandwidth and reports to the oracle. This provides ground truth.
-
For direct connections, the censored client sends signed bandwidth receipts to the oracle, attesting to bytes received from the peer.
-
The oracle cross-validates: if sampled traffic shows the peer relays 5 MB/hr but the peer claims 500 MB/hr of direct traffic, the discrepancy triggers investigation.
-
The peer cannot distinguish sampled from direct connections because:
- The censored client initiates all connections identically via WebRTC
- Sampled connections use end-to-end encryption to the egress server -- the peer sees opaque bytes regardless of destination
- The sampling decision is made by Freddie and communicated only to the client
Graduated trust model:
┌─────────────────────────────────────────────────────────┐
│ TRUST TIERS │
├──────────┬──────────────┬──────────────┬────────────────┤
│ Tier │ Sample Rate │ Requirement │ Stake Required │
├──────────┼──────────────┼──────────────┼────────────────┤
│ New │ 100% │ Registration │ None │
│ Bronze │ 50% │ 7+ days │ None │
│ Silver │ 20% │ 30+ days │ 100 LANTERN │
│ Gold │ 10% │ 90+ days │ 500 LANTERN │
│ Platinum│ 5% │ 180+ days │ 1000 LANTERN │
└──────────┴──────────────┴──────────────┴────────────────┘
Lower sampling = less overhead for the peer = higher effective earnings.
Staking creates persistent demand for the token.
Cheating resets trust tier to New and slashes stake.
Note: In Phase 1, all peers are effectively at "New" tier (100% egress-verified). Trust tiers unlock as direct routing becomes available in Phase 2.
Long-term architecture with multiple verifiers and on-chain governance.
┌──────────────┐
│ Freddie │
│ (Multiple │
│ Instances) │
└──────┬───────┘
│
┌──────────┴──────────┐
│ │
┌──────┴──────┐ ┌──────┴──────┐
│ Censored │ │ Widget │
│ Users │ │ Peers │
└──────┬──────┘ └──────┬──────┘
│ WebRTC │
└─────────────────────┤
│
┌─────────────────────┼─────────────────────┐
│ │ │
▼ ▼ ▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Verifier │ │ Verifier │ │ Destination │
│ Node 1 │ │ Node 2 │ │ Sites │
│ (Egress) │ │ (Egress) │ └─────────────┘
└──────┬──────┘ └──────┬──────┘
│ │
└──────────┬──────────┘
│
┌──────┴──────┐
│ On-Chain │
│ Oracle │
│ Program │
└──────┬──────┘
│
┌──────┴──────┐
│ LANTERN │
│ Governance │
│ + Rewards │
└─────────────┘
Phase 3 additions:
- Multiple independent verifier nodes (replacing single egress server) run by different operators
- On-chain oracle aggregates reports from multiple verifiers using median/threshold consensus
- LANTERN token governs: emission rates, geographic multipliers, trust tier parameters, verifier set
- Cross-peer verification: peers spot-check each other (similar to Helium's witness model but for bandwidth throughput)
| Attack | Description | Severity |
|---|---|---|
| Sybil peers | Attacker runs many fake peer identities to multiply rewards | High |
| Fake clients | Attacker creates fake "censored users" to generate fabricated bandwidth receipts | High |
| Peer-client collusion | A peer and a fake client cooperate to inflate bandwidth claims | High |
| Bandwidth inflation | Peer claims more bandwidth than actually relayed | Medium |
| Free-riding | Peer registers but provides minimal/degraded service | Medium |
| Exit scam | Peer builds trust then exploits it to claim unearned rewards | Medium |
Note on gaming pressure: A speculative token increases gaming incentive compared to stablecoin payments, because gamers are betting on token appreciation too. This makes robust verification more important, not less. The Phase 1 egress-verified model is critical: since all Phase 1 traffic flows through the egress server, gaming is nearly impossible in Phase 1. Gaming becomes a concern only in Phase 2 when direct routing is introduced.
┌─────────────────────────────────────────────────────────────┐
│ DEFENSE IN DEPTH │
├─────────────────────────────────────────────────────────────┤
│ │
│ Layer 1: IDENTITY │
│ ├── Ed25519 peer identity keys │
│ ├── Lantern account authentication for censored users │
│ ├── Geolocation verification (Freddie sees client IP) │
│ └── Residential IP scoring (MaxMind/IP2Location) │
│ │
│ Layer 2: MEASUREMENT │
│ ├── Egress server bandwidth metering (ground truth) │
│ ├── Signed client bandwidth receipts │
│ ├── Random spot-check sampling (unpredictable to peer) │
│ └── Cross-validation of sampled vs. claimed bandwidth │
│ │
│ Layer 3: ECONOMICS │
│ ├── Staking requirement for higher trust tiers │
│ ├── Slashing for detected fraud │
│ ├── Graduated trust (months to build, instant to lose) │
│ └── Per-client rate limiting on attestable bandwidth │
│ │
│ Layer 4: PLAUSIBILITY │
│ ├── Bandwidth plausibility model (connection type/region) │
│ ├── Traffic pattern analysis (real browsing is bursty) │
│ ├── Temporal consistency checks (24/7 claims from │
│ │ residential IPs are suspicious) │
│ └── Multi-client cross-referencing per peer │
│ │
└─────────────────────────────────────────────────────────────┘
For cheating to be irrational, the expected loss must exceed the expected gain:
P_detect * slash_penalty > (1 - P_detect) * reward_from_cheating
With 10% sampling rate and 20x slashing multiplier:
0.10 * 20R > 0.90 * R
2.0R > 0.9R <- cheating is clearly irrational
With 5% sampling rate and 40x slashing multiplier:
0.05 * 40R > 0.95 * R
2.0R > 0.95R <- still irrational
The sampling rate can decrease as trust increases, as long as the slashing multiplier compensates.
┌─────────────────────────────────────────────────────────────┐
│ LANTERN TOKEN │
├─────────────────────────────────────────────────────────────┤
│ │
│ Type: SPL Token on Solana │
│ Supply: 1,000,000,000 LANTERN (fixed cap) │
│ │
│ Distribution: │
│ ├── 50% Peer Rewards Pool │
│ │ └── Emitted over 10 years, halving every 2 years │
│ ├── 20% Lantern Foundation │
│ │ └── 4-year vest, 1-year cliff │
│ ├── 15% Early Contributors / Team │
│ │ └── 4-year vest, 1-year cliff │
│ ├── 10% Ecosystem Fund │
│ │ └── Grants for verifiers, tooling, integrations │
│ └── 5% Liquidity Bootstrapping │
│ └── Initial DEX liquidity (Raydium / Jupiter) │
│ │
└─────────────────────────────────────────────────────────────┘
Modeled on Bitcoin's halving approach but with 2-year cycles to front-load early adopter rewards:
Year 1-2: ~125M LANTERN emitted (25% of rewards pool)
Year 3-4: ~62.5M LANTERN emitted
Year 5-6: ~31.25M LANTERN emitted
Year 7-8: ~15.6M LANTERN emitted
Year 9-10: ~7.8M LANTERN emitted
─────────────────
Total: ~242M + tail emissions from remaining pool
Daily emission (Year 1): ~171,000 LANTERN
split across all active peers proportional to verified bandwidth
The decreasing emission schedule rewards early participants disproportionately, creating urgency to join the network early -- the same FOMO dynamic that drove Helium's growth.
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ More Peers │────►│ More Capacity│────►│ Better Service│
│ Join Network│ │ for Censored │ │ for Users │
└──────┬───────┘ │ Users │ └──────┬───────┘
│ └──────────────┘ │
│ │
│ ┌──────────────┐ │
│ │ Token Value │ │
└─────────────│ Appreciation │◄───────────┘
│ (speculative │
│ + utility) │
└──────┬───────┘
│
┌─────────────┼─────────────┐
│ │ │
▼ ▼ ▼
┌────────────┐ ┌──────────┐ ┌──────────────┐
│ Staking │ │ Trading │ │ Governance │
│ Demand │ │ Volume │ │ Participation│
│ (sink) │ │ (liquidity)│ │ │
└────────────┘ └──────────┘ └──────────────┘
Helium's token soared, attracting gamers who earned HNT without providing real coverage. The key differences in Lantern's design:
-
Phase 1 is ungameable. All traffic goes through the egress server. You can't fake bandwidth the egress server didn't see. This buys time to build robust verification before enabling direct routing.
-
Real demand exists from day one. Helium had hundreds of thousands of hotspots but almost no IoT demand. Lantern has millions of censored users who actually need bandwidth. This means honest peers earn more because there's real traffic to relay.
-
Spot-check sampling is stronger than Proof of Coverage. Helium's PoC relied on RF signals that could be spoofed with attenuators and splitters. Lantern's spot-check routes real traffic through a trusted verifier -- you either relay the bytes or you don't.
-
Graduated trust is slow to build and instant to destroy. It takes 6 months to reach Platinum tier. One fraud detection resets you to New and slashes your stake. This makes the "game for a while then cash out" strategy much less attractive.
No blockchain is cheap enough for per-megabyte payments. The system uses off-chain accounting with periodic on-chain settlement.
┌──────────────────────────────────────────────────────────┐
│ PAYMENT FLOW │
│ │
│ 1. Egress server meters bandwidth per peer │
│ (off-chain, from OTel metrics) │
│ │
│ 2. [Phase 2+] Client sends signed bandwidth receipts │
│ (off-chain, for direct-routed traffic) │
│ │
│ 3. Oracle reconciles and computes rewards per epoch │
│ (off-chain computation) │
│ │
│ 4. Oracle submits batch settlement to Solana │
│ (single on-chain tx per epoch, Merkle root │
│ of all peer rewards) │
│ │
│ 5. Peers claim LANTERN from rewards program │
│ (on-chain, Merkle proof) │
│ │
│ Settlement frequency: daily │
│ On-chain cost: ~$0.00025 per settlement tx │
│ Peer claim cost: ~$0.001 per claim │
│ │
│ 10,000 peers claiming daily = ~$3,650/year in fees │
│ (vs ~$100K-365K/year on EVM L2s) │
│ │
└──────────────────────────────────────────────────────────┘
┌─────────────────────────┐ ┌─────────────────────────┐
│ lantern_token │ │ rewards_vault │
│ (SPL Token Mint) │ │ (Anchor Program) │
│ │ │ │
│ - SPL Token standard │ │ - submit_epoch( │
│ - Fixed supply │ │ merkle_root, │
│ - Mint authority: │ │ total_reward) │
│ rewards_vault PDA │ │ - claim(proof, amount) │
│ │ │ - get_epoch(id) │
│ │ │ - emission_rate() │
└────────────┬─────────────┘ └────────────┬────────────┘
│ │
└───────────┬────────────────────┘
│
┌──────┴──────┐
│ staking │
│ (Anchor │
│ Program) │
│ │
│ - stake() │
│ - unstake()│
│ - slash() │
│ - tier_of()│
└──────┬──────┘
│
┌──────┴──────┐
│ registry │
│ (Anchor │
│ Program) │
│ │
│ - register(│
│ pubkey, │
│ wallet) │
│ - peer_info│
│ (peer) │
└─────────────┘
Solana-specific design notes:
- The LANTERN mint authority is a PDA (Program Derived Address) owned by the rewards vault program, ensuring only the vault can mint new tokens according to the emission schedule
- Peer accounts are PDAs indexed by Ed25519 public key, storing wallet address, trust tier, stake amount, and cumulative bandwidth
- Epoch data is stored in PDA accounts indexed by epoch number, containing the Merkle root and total emission for that epoch
- Solana's ZK Compression (batched Merkle trees) can be used for efficient state management as the peer set grows large
Each epoch, the oracle computes a Merkle tree of rewards:
Root Hash
/ \
H(AB) H(CD)
/ \ / \
H(A) H(B) H(C) H(D)
| | | |
Peer A Peer B Peer C Peer D
50 120 3 75
LANTERN LANTERN LANTERN LANTERN
- Oracle submits only the root hash on-chain (one tx per epoch, ~$0.00025)
- Each peer submits a Merkle proof to claim their specific reward (~$0.001 per claim)
- This scales to tens of thousands of peers per epoch with negligible on-chain cost
- Solana's ~400ms block time means claims confirm near-instantly
Used in Phase 2+ when traffic can bypass the egress server.
BandwidthReceipt {
version: uint8 // Protocol version
peer_id: [32]byte // Peer's Ed25519 public key
session_id: [16]byte // Connection session UUID
client_id: [32]byte // Client's Ed25519 public key
bytes_down: uint64 // Bytes received by client from peer
bytes_up: uint64 // Bytes sent by client through peer
timestamp: uint64 // Unix timestamp (seconds)
window: uint32 // Measurement window (seconds)
signature: [64]byte // Client's Ed25519 signature over all above fields
}
Note: Solana natively uses Ed25519 for account keys, so the peer's Solana wallet keypair doubles as their identity key. No separate key management needed.
Censored Client Widget Peer Oracle
| | |
|<------ data (N bytes) --------| |
| | |
| [every 60s or 1MB] | |
| | |
|-- sign(receipt{N bytes}) ----->| |
| |-- forward(receipt) ------->|
| | |
| ... more data transfer ... | |
| | |
|-- sign(receipt{M bytes}) ----->| |
| |-- forward(receipt) ------->|
| | |
| | ┌------+------┐
| | | Reconcile |
| | | with egress |
| | | spot-check |
| | | data |
| | +------+------┘
| | |
| | Settlement
| Requirement | How Solana Meets It |
|---|---|
| DePIN ecosystem | Solana is the dominant DePIN chain -- Helium, Grass, Render, Hivemapper all live here. LANTERN gets grouped with the DePIN narrative automatically. |
| Claim costs | ~$0.001 per claim. 10K peers claiming daily = $3,650/year. On EVM L2s this would be $100K-365K/year. |
| Speed | ~400ms block time, near-instant finality. Claims confirm in under a second. |
| DEX liquidity | Raydium, Jupiter, Meteora provide deep, easy-to-bootstrap liquidity. Raydium LaunchLab is designed specifically for new token launches. |
| Proven model | Grass (bandwidth-sharing DePIN, 3M+ users, epoch-based rewards) is the exact same pattern, already working on Solana. |
| Ed25519 native | Solana uses Ed25519 for all account keys -- the same curve used by unbounded peer identity keys. Peer wallet = peer identity, no extra key management. |
| CEX listings | All major exchanges (Binance, Coinbase, Kraken, OKX, Bybit) support SPL token deposits/withdrawals. |
| Bridges | Wormhole NTT enables native cross-chain presence on EVM chains if needed later. |
| Chain | Reason Against |
|---|---|
| Ethereum L1 | $1-50+ per tx -- far too expensive for daily reward claims |
| Base (Coinbase L2) | Viable but 10-100x more expensive per claim than Solana. No DePIN ecosystem or narrative. Would be building in isolation. |
| Arbitrum | Same issues as Base -- higher claim costs, no DePIN narrative |
| Cosmos app-chain | Go-native (great language match) but bootstrapping liquidity is extremely hard. No DePIN ecosystem. Bridges to Solana/EVM are less mature. |
| Polygon | Losing ecosystem momentum. No DePIN concentration. |
| peaq / IoTeX | DePIN-specific chains but too small, illiquid, and immature. Limited CEX support. |
Grass is the closest existing analog to what Lantern is building:
- Users share unused bandwidth via a browser extension
- Rewards distributed via epoch-based token distributions
- 3M+ users onboarded rapidly
- Built entirely on Solana
- Uses ZK proofs for session verification posted on-chain
- Token launched on Solana DEXs, quickly got CEX listings
Grass validates that the bandwidth-sharing DePIN model works on Solana specifically. Lantern's model is differentiated by its censorship-circumvention mission and the egress-server verification layer.
Launch native on Solana. If demand warrants it, expand to EVM chains later:
Native Bridged
┌─────────────┐ ┌─────────────────┐
│ Solana │ Wormhole │ Ethereum / L2s │
│ (LANTERN │────NTT─────►│ (wrapped │
│ SPL Token) │ bridge │ LANTERN) │
│ │ │ │
│ - Rewards │ │ - Additional │
│ - Staking │ │ DEX liquidity │
│ - Governance│ │ - CEX listings │
│ - Claims │ │ - DeFi access │
└─────────────┘ └─────────────────┘
Wormhole NTT (Native Token Transfers) uses a burn-and-mint model that preserves token utility across chains without creating wrapped token fragmentation. This is the same bridge infrastructure Helium and other Solana DePIN projects use.
| Project | What Worked | What Failed | Lesson for Lantern |
|---|---|---|---|
| Helium | Speculative token bootstrapped 500K+ hotspots; migrated to Solana successfully | 30-50% of rewards went to gamers; massive supply/demand mismatch | Phase 1 egress-verification eliminates gaming; Lantern has real user demand unlike Helium's phantom IoT demand |
| Grass | Bandwidth-sharing DePIN on Solana; 3M users; epoch-based rewards work | Still early; verification relies on ZK proofs that add complexity | Validates the exact model on Solana; Lantern's egress spot-check is simpler than ZK proofs |
| Filecoin | zk-SNARK proofs are unforgeable | Junk data problem; sealing too expensive for small operators | Cryptographic proofs work for static resources (storage) but bandwidth is ephemeral -- use sampling instead |
| Orchid | Probabilistic nanopayments are elegant | Cold-start problem; ERC-20 on Ethereum made micropayments impractical due to gas | Lantern avoids this: Solana's low fees make claims practical; token value comes from network growth, not from users paying peers |
| Mysterium | Payment channels + Quality Oracle is practical | Subsidy-dependent; limited scale | Subsidize via token emissions (cheap) not treasury (expensive) |
| Nym | Coconut credentials separate payment from usage identity | Network monitor is partially centralized; can be gamed | Active probing works but sophisticated operators can detect test traffic -- spot-check sampling through egress is harder to game |
| Tor | Volunteer model avoids economic attack surface | Perpetual bandwidth shortage; geographic concentration | Compensation changes who participates -- design for economically rational operators, use staking for accountability |
- Create LANTERN SPL token mint on Solana
- Build rewards vault Anchor program with emission schedule
- Build registry Anchor program for peer registration
- Add Ed25519 peer identity keys to widget/peer signaling
- Instrument per-peer bandwidth attribution in egress server
- Build reward oracle (reads OTel metrics, computes epoch rewards, submits Merkle roots)
- Add Solana wallet registration to Freddie signaling flow
- Seed initial DEX liquidity (Raydium / Jupiter)
- Build peer dashboard (earnings, bandwidth stats, tier progress)
- Security audit of Anchor programs (OtterSec, Neodyme, or similar)
- Implement direct-to-destination routing in unbounded (PathAssertion-based)
- Add signed bandwidth receipt protocol to client/peer
- Build spot-check sampling into Freddie routing directives
- Build staking Anchor program with trust tier system
- Add residential IP scoring to peer registration
- Build plausibility checking in the oracle
- Implement slashing for detected fraud
- Deploy multiple independent verifier nodes
- Build on-chain oracle with multi-verifier consensus
- Implement on-chain governance for protocol parameters (Realms or custom)
- Enable cross-peer verification
- Launch governance portal
- [Optional] Bridge to EVM chains via Wormhole NTT
-
Initial token price discovery: Should LANTERN launch with a Liquidity Bootstrapping Pool (LBP) on Meteora for fair price discovery, or a simple Raydium pool with Lantern-seeded liquidity?
-
Geographic multiplier calibration: Which regions are most underserved? How much premium should peers in those regions earn? Should this be governed by token holders?
-
Privacy of bandwidth receipts: Should receipts use blind signatures or Coconut credentials (like Nym) to prevent the oracle from linking censored user identities to their browsing patterns?
-
Regulatory classification: Is LANTERN a utility token or a security? Needs legal review before launch. The "sufficiently decentralized" argument is strengthened by the peer-operated network and on-chain governance.
-
Widget vs. desktop peer: Should browser-based widgets (ephemeral, lower bandwidth) earn at the same rate as desktop peers (persistent, higher bandwidth)? Or should there be a minimum session duration to earn?
-
Minimum claim threshold: What's the minimum accumulated LANTERN before a peer can claim? (Solana's low fees make this less critical than on EVM, but still worth considering to reduce state bloat.)
-
Anti-dump mechanism: Should there be a short vesting period on earned LANTERN (e.g., 7-day unlock) to prevent immediate dumping? This creates friction but reduces sell pressure.
-
Peer hardware requirements: Should there be minimum bandwidth/uptime requirements to earn, or should the reward formula naturally handle this via the quality multiplier?
-
Anchor vs. native Solana program: Should the programs be written in Anchor (faster development, more readable) or native Rust (more control, potentially more efficient)? Anchor is recommended for initial development with the option to optimize later.