Sybil Resistance Enabled Built for Solana growth teams and active communities

Aroxel Documentation

Complete product and operations guide for building, running, and auditing task-based airdrop campaigns with Aroxel on Solana.

This page is structured as an implementation playbook. Follow it from top to bottom for a full operational rollout, or jump to specific sections from the sidebar.

1) Platform overview

Aroxel is a campaign operations platform that helps teams run quest-based reward programs with high confidence eligibility. It combines configurable quest logic, anti-sybil scoring, and traceable payout execution.

  • Designed for growth, community, and analytics teams.
  • Optimized for Solana-native campaigns and SPL reward flows.
  • Supports transparent auditability from submission to settlement.

2) System architecture

Campaign Service

Owns campaign definitions, versions, windows, and payout limits.

Quest Engine

Ingests proof submissions, validates rules, and computes score output.

Sybil Intelligence

Builds confidence profile from identity, behavior, and overlap signals.

Distribution Service

Converts eligible scores into recipient batches and settlement state tracking.

Analytics Layer

Provides cohort, funnel, and quality dashboards for decision-making.

Audit Store

Captures immutable logs of policy changes, moderation, and payout events.

3) Campaign lifecycle (full flow)

  1. Draft: define objective, KPI, timeline, budget, and reward token.
  2. Configure: create quests, assign weights, and define validation modes.
  3. Protect: set anti-sybil thresholds and moderation policy.
  4. Launch: publish campaign and open submission window.
  5. Validate: process proofs and monitor quality/risk dashboards.
  6. Freeze: lock eligible recipients at snapshot cutoff.
  7. Distribute: execute claim or push payout model.
  8. Close: reconcile, export reports, and archive evidence bundle.

4) Operator step-by-step guide (hyper detail)

Stage A: Workspace bootstrap

  1. Connect signer wallet and verify authority scope.
  2. Create organization profile and assign team roles.
  3. Define approval boundaries (who can publish, freeze, distribute).

Stage B: Campaign authoring

  1. Create campaign ID and set version tag (for change tracking).
  2. Set campaign windows: start_at, freeze_at, claim_open_at, claim_close_at.
  3. Set reward pool cap and optional wallet allocation ceiling.

Stage C: Quest design

  1. Create required quests (must-pass) and optional quests (bonus).
  2. Map proof schema per quest (URL, tx hash, content signature, etc).
  3. Define weight and validation type for each quest.

Stage D: Risk controls

  1. Set default confidence threshold (for pass/review/quarantine).
  2. Enable duplicate signal checks and claim-cluster heuristics.
  3. Activate manual queue with reviewer SLA target.

Stage E: Launch operations

  1. Run preflight validation of campaign config.
  2. Publish and verify event delivery.
  3. Track queue depth, completion ratio, and anomaly trend every cycle.

Stage F: Freeze and payout

  1. Execute snapshot freeze exactly at configured cutoff.
  2. Run dry-run simulation and inspect top outliers.
  3. Execute signed payout batch; monitor settlement confirmations.
  4. Export final reconciliation and audit report.

5) Quest and scoring model

Final participant score is derived from valid quest outputs, completion consistency, and risk adjustment values.

Validation modes

  • Automatic: deterministic source checks.
  • Semi-automatic: source checks + reviewer approval.
  • Manual: reviewer-only final decision.

Score formula (conceptual)

  • Total = sum(valid quest weights)
  • + consistency bonus
  • - risk penalty
  • = eligibility class

6) Anti-sybil model

Signals

  • Wallet age and transaction footprint
  • Funding source diversity
  • Submission timing entropy
  • Cross-wallet behavior overlap
  • Claim routing concentration

Decision classes

  • Pass: no intervention needed
  • Review: routed to moderation queue
  • Quarantine: excluded pending evidence

7) Distribution flow

  1. Create recipient snapshot from frozen eligibility table.
  2. Compute allocation via configured score curve and caps.
  3. Build deterministic batch manifest and run simulation.
  4. Sign and broadcast payout transactions.
  5. Track states: prepared, signed, broadcast, confirmed, reconciled.

8) Role-based operations

Operator

  • Campaign ownership, budget control, launch approvals.
  • Freeze execution and payout sign-off.

Reviewer

  • Manual queue triage and decision evidence.
  • False-positive reduction and policy feedback.

Analyst

  • Funnel and quality cohort analysis.
  • Post-campaign KPI and optimization recommendations.

Participant

  • Quest completion, proof submission, eligibility checks.
  • Claim execution in open distribution window.

9) Recommended templates

Growth launch template

  • Window: 14 days
  • Quest count: 6-10
  • Required quests: 3-4
  • Freeze cutoff: T-24h

Community engagement template

  • Window: 21 days
  • Quest count: 8-14
  • Social + on-chain blended weights
  • Manual queue target: below 12%

10) API and event reference

  • campaign.created - campaign definition persisted
  • quest.submission.received - proof payload accepted
  • quest.submission.verified - score updated with decision
  • participant.flagged - risk class changed
  • distribution.batch.ready - payout plan prepared
  • distribution.batch.settled - on-chain completion confirmed
Integration tip: store event_id and campaign_version in your data warehouse to guarantee idempotent ingestion and clean audit joins.

11) Service level targets

  • Submission intake availability: 99.9% monthly target.
  • Automatic verification p95 latency: below 2 seconds.
  • Manual review first-response SLA: below 6 hours.
  • Settlement confirmation target: below 15 minutes per batch.
  • Reconciliation export target: below 30 minutes post settlement.

12) Troubleshooting

Delayed verification

Inspect queue backlog, webhook delivery, and source API limits.

Claim mismatch

Compare snapshot hash, allocation version, and batch manifest.

False-positive risk flag

Open moderation review and attach evidence override reason.

Payout failure

Check signer authority, token account state, and retry queue outcome.

13) FAQ

Can I run social-only campaigns?

Yes, but combining social and on-chain proofs produces better eligibility quality.

Can claims be user-initiated instead of direct distribution?

Yes. Aroxel supports both push-based batches and claim-window distribution modes.

How do I prove fairness to partners?

Share score versioning logs, moderation evidence, and settlement reconciliation exports.