SW33P protocol
documentation.

This is the deep layer. Homepage stays simple on purpose. Formulas, mechanics, and architectural details live here.

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, winners derived
PAYOUT    → USDC sent to winning wallets (auto)
PROOF     → bundle published to Proof Registry
NEXT      → sweep N+1 opens automatically

Reward sweeps

A sweep has a fixed duration (currently 33-minute, 33-seconds), a target winner count (1 jackpot + 12 runner-ups), and a published rules version.

Pool composition

Each sweep's pool is funded from a mix of $TICK3T-tied flows, partner contributions, and the carried reserve from the previous sweep. By design, ≥15% of every pool seeds the next one.

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
winners = 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 bands. Bands carry selection weight on the jackpot draw. Runner-up draws have lower band bias.

// simplified band weights
D  = 1.0×    // free-entry only, no hold
C  = 1.2×    // hold ≥ 1,000 $TICK3T
B  = 1.5×    // hold ≥ 10,000 $TICK3T
B+ = 1.8×    // hold + season activity
A  = 2.3×    // hold ≥ 100,000 $TICK3T
A+ = 3.0×    // long-term hold + high season

Exact band cutoffs are versioned in Rules. Weights are public; raw eligibility inputs are not.

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 | sweep100 | sweep500 | sweep1000
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 sweep whose number is a multiple of 33 is a Lucky 33 event with a guaranteed draw. Lucky 33 events are designed to create regular high-attention moments for boosts, burns, and competition.

• Draw still follows eligibility, score, and randomness rules.
• Boosted users are not guaranteed to win.
• "Guaranteed draw" means a draw will happen; it does not mean any wallet is guaranteed to win.

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 Sweep (~2d 8h at 33:33 cadence): standard pot boost.
• 500-Cycle Super Sweep (~11d 16h): large pot boost.
• 1000-Cycle Mega Sweep (~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    = 8 pts / sweep entered
reward_event           = 80 pts (runner-up) / 400 pts (jackpot)
qualified_referral     = 60 pts (diminishing past 10)
daily_checkin          = 4 pts (with streak multiplier)
verified_share         = 12 pts (quality-scored)
hold_bonus             = 1 pt / 1000 $TICK3T / day held

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

Each $TICK3T transaction routes a small fee into the sweep pool, creating recurring buy-pressure on the token while feeding the reward sweep. Exact rates are versioned in Rules.

Contract & audit

$TICK3T contract: TKT3...PROTC (Solana). Audit by Halborn (linked from the homepage). Always verify the contract address from this site. Never from a DM.

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. Despite audits, residual contract risk exists.
• Jurisdictional risk. Eligibility depends on local law. See Terms.
• Operational risk. Outages, network congestion, oracle delays.