HoneyJar

Unified Incentives for the Financial OS 🍯

HoneyJar is a soulbound (non-transferable) NFT, one per user, that serves as the canonical incentives ledger across HoneyPlay’s Financial OS. It aggregates points from:

  • Marketplace activity (listings, bids) — continuous, index-based accrual

  • Marketplace trading (completed NFT sales) — 7-epoch cycles

  • AMM trading (per-pool, fee-weighted) — pool cycles

Points convert into claimable HONEY at a rate set by the HoneyOracle. Claims are tax-aware (via HoneyTaxConfig), so every reward redemption reinforces the economy (burn, creator rewards, treasury, protocol).

💡 Hint — Why a soulbound NFT? Tying incentives to a non-transferable identity prevents farming via transfers and makes reward history portable across all apps plugged into the OS.


Key attributes:

  • Soulbound Design: Cannot be transferred; represents lifetime engagement.

  • Multi-Stream Tracking: Separates points by source (AMM, Marketplace activities, NFT trades) for granular incentives.

  • Claim Mechanism: Users claim all rewards in one transaction, with HONEY taxes applied via TokenRules.

  • Minting: Only one per user is allowed


🎮 Incentive Streams

HoneyJar supports three streams, each tailored to protocol areas:

1) Marketplace Activity (Listings & Bids)

  • Type: Continuous, index-based distribution

  • Awarding: Listing and bid actions can be price/duration/amount-weighted, with collection multipliers

  • Formula: user_reward = user_points × (global_index − user_last_index) / PRECISION

  • Purpose: Reward liquidity creation (inventory and intent)

2) Marketplace Trading (Completed Sales)

  • Type: 7-epoch cycles (weekly cadence)

  • Awarding: Both buyer & seller earn points based on commission paid

  • Formula : user_reward = (user_cycle_points / cycle_total_points) × cycle_honey

  • Purpose: Reward value creation (volume that produces fees)

3) AMM Trading (Per-Pool)

  • Type: Per-pool cycles, fee-weighted (SUI/ggSUI fees paid)

  • Formula: user_reward = (user_pool_points / pool_total_points) × pool_honey_allocation

  • Purpose: Incentivize trades that actually pay into the system; deter spam.

🔒 Parallel-safe design Per-pool accounting keeps swaps parallelizable and avoids a global lock on trading.

All streams feed into one claim, with points reset post-claim to prevent double-dipping.

Last updated