SW33P protocol
documentation.

This is the deep layer. Homepage stays simple on purpose. User-visible mechanics live here; exact scoring weights and anti-farm constants stay private until versioned for launch.

Overview

SW33P is a Solana-native reward protocol. It runs sweeps: time-windowed events where an eligible set is snapshotted, randomness is committed and revealed, and USDC is paid out to selected wallets. Products (currently $TICK3T) plug into the protocol; the protocol does not depend on any single product.

"Reward sweeps, not lottery." A sweep is a recurring system event with deterministic structure, transparent rules, and verifiable randomness.

Architecture

SW33P is composed of four on-chain components and a small off-chain coordination layer.

• Sweep Manager. opens, snapshots, and closes sweeps.
• VRF Oracle. verifiable randomness commit/reveal.
• Pool Vault. USDC custody and automated payouts.
• Proof Registry. publishes proof bundles per sweep.

// sweep lifecycle
OPEN      → sweep accepts entries, eligibility snapshot accumulates
COMMIT    → VRF commitment hash published (≈ 60s before close)
CLOSE     → eligibility snapshot frozen
REVEAL    → VRF reveal published, selected wallets derived
PAYOUT    → USDC sent to winning wallets (auto)
PROOF     → bundle published to Proof Registry
NEXT      → sweep N+1 opens automatically

Reward sweeps

A reward cycle has a fixed duration target (currently 33-minute, 33-seconds), an adaptive selected-wallet count (roughly 1% of eligible holders where pool size allows), and a published rules version.

Pool composition

Each cycle pool is funded by protocol fees, partner contributions, and any carried reserve from previous cycles. USDC rewards are not funded by token emissions or forced token sells.

Randomness (VRF)

SW33P uses a commit-reveal VRF. Before sweep close, a hash is published on-chain. After close, the reveal is posted. Anyone can verify the pair and re-derive the winner selection.

// commit-reveal lifecycle
commit = sha256(seed)              // published pre-close
reveal = seed                       // published post-close
verify = sha256(reveal) == commit
selected_wallets = derive(reveal, snapshot, bands, count)

The seed is generated by a multi-party process (operator + on-chain randomness beacon) so neither party can grind for a favorable outcome.

Odds bands

Eligible participants are grouped into visible score bands. Bands influence selection weight, but the full equation is private to reduce farming and wallet-splitting.

// visible score components
holding_power      // compressed balance, not raw whale dominance
time_held          // longer holds weight up
real_volume        // capped contribution from organic activity
cycle_consistency  // repeated participation compounds
burn_boost         // optional, deflationary boosts
anti_farm_hygiene  // wallet-splitting and wash-volume controls
exact_weights      = PRIVATE

Users see bands and component scores. Exact thresholds, caps, and weights are not published because they are farmable.

Burn-to-Boost

Burn-to-Boost lets users burn $TICK3T to multiply their odds for eligible sweeps and special events. The dashboard shows the selected multiplier, required burn, estimated odds improvement, and whether insurance is active before the user confirms.

// boost mechanics
multiplier_range   = 1.1x → 20x
burn_required      = curve(multiplier, target_event)   // versioned, partly private
target_event       = current | lucky33 | cycle100 | cycle500 | cycle1000
weighted_entries   = base_entries * boost_curve(multiplier)
boost_band         = band(base_band, multiplier)
burn               = IRREVERSIBLE

• Multiplier range is published. Exact cost curve is versioned and may change between rules releases.
• A boost applies to one selected eligible sweep or event.
• Burns are irreversible. The dashboard always previews before confirming.
• Boost effects may be capped per event type.

Insurance

Insurance guarantees the boost receives a draw. It does not guarantee the user wins.

// insurance lifecycle
OFF · boost attached to event N
  → event N has draw → boost used
  → event N has no-draw → boost LOST
ON  · boost attached to event N
  → event N has draw → boost used
  → event N has no-draw → boost rolls to N+1 (or next targeted event)

Insurance state is committed in the proof record. Aggregate rollover counts are public; individual boost owners are not.

Lucky 33

Every cycle whose number is a multiple of 33 is a Lucky 33 event with a scheduled draw event. Carry-forward pools can also create larger, more newsworthy moments when earlier cycles roll forward.

• Draw still follows eligibility, score, and randomness rules.
• Boosted users are not guaranteed to win.
• "Scheduled draw" means a draw event runs; it does not mean any wallet is guaranteed to receive a reward.

Milestone boosts

Scheduled events where the pot receives an extra boost. They create larger predictable reward moments and natural windows for burn activity.

• 100-Cycle Event (~2d 8h at 33:33 cadence): standard pool boost.
• 500-Cycle Event (~11d 16h): larger pool boost.
• 1000-Cycle Event (~23d 7h): largest scheduled boost.
• Pot boost source: reserve allocation, fee routing, milestone allocation. Exact sizes are versioned.

Score model

Your score is composed of visible components. Exact weights are private to reduce farming.

// visible components
holding            // $TICK3T balance at snapshot
loyalty            // time-held streak
volume             // $TICK3T volume contribution
burn_boost         // 1.1x → 20x multiplier from burns
insurance          // active rollovers
season_activity    // sweep participation & consistency
referral_quality   // qualified, non-sybil referrals
eligibility_hygiene// anti-farm checks passed

// private
exact_weights      = HIDDEN
antifarm_rules     = HIDDEN
boost_curve        = HIDDEN
sybil_thresholds   = HIDDEN

Season points

Sweeps roll up into seasons. Each season is ~90 days. Points come from sweep participation, qualified referrals, daily activity, social actions, and a small hold bonus.

cycle_participation    // consistency score
selected_event         // reward event history
qualified_referral     // diminishing after quality caps
verified_share         // quality-scored, anti-spam
hold_bonus             // balance + time held, compressed

Referrals

Referrals give entries, season points, and a small future-rewards smell. Boost diminishes past 10 quality referrals to discourage farming.

$TICK3T · Token overview

$TICK3T is the eligibility/utility token for SW33P's flagship reward sweep. It's the first product on the protocol. Not the protocol itself.

Supply & allocation

Sweep flow

Protocol fees fund the USDC reward pool and reward real activity. Volume can help the system, but score contribution is capped and filtered so wash volume does not dominate.

Contract & audit

$TICK3T contract, audit report, and official token links are pending launch. Until they are published here, treat any claimed address or audit link as unofficial.

Proof model

SW33P publishes a proof bundle per sweep. See Proof for the full structure.

Public/private boundary

We publish everything needed to verify outcomes. We do not publish the full eligible-wallet list or raw inputs that would (a) expose users to phishing, or (b) let bad actors farm the system.

API (planned)

A public read-only API is planned for Q3. Sweep state, proof bundles, and aggregate stats will be queryable; per-wallet detail will be gated by wallet-signed requests.

Risk disclosures

• No guaranteed rewards. Sweeps are random within their eligible set.
• Token volatility. $TICK3T is volatile. Holding is not investment advice.
• Smart-contract risk. Audits are pending; residual contract risk will still exist after review.
• Jurisdictional risk. Eligibility depends on local law. See Terms.
• Operational risk. Outages, network congestion, oracle delays.