Abstract
DegenBox is a multi-tenant, Solana-based, on-chain gaming protocol that enables SPL token projects to deploy verifiable, non-custodial lootbox mechanics for their communities.
The system leverages cryptographic randomness via Switchboard VRF, Program Derived Addresses (PDAs) for asset custody, and a commit–reveal–settle architecture to ensure transparency, fairness, and resistance to manipulation.
Outcomes are computed deterministically from public on-chain configuration + VRF output, enabling independent recomputation by any observer.
This document describes the architecture underpinning DegenBox, its smart contract design, randomness model, economic mechanisms, and security assumptions. It further outlines the incentive alignment between project creators, protocol participants, and $3EYES token holders within the broader DegenBox ecosystem.
1. Threat Model and Design Constraints
1.1Adversarial Risks in Current Lootbox Systems
On-chain and off-chain gaming systems are subject to a common set of adversarial risks that undermine user trust and economic integrity:
Randomness Manipulation
In centralised systems, outcome generation is opaque and controlled by the operator, allowing probabilities to be modified or selectively applied without external verification or participant knowledge.
Custodial Asset Risk
User funds are typically held in operator-controlled wallets, creating exposure to mismanagement, insolvency, or unilateral withdrawal by platform administrators.
State Manipulation and Timing Attacks
Systems that generate randomness or outcomes prior to user commitment enable adversaries to condition participation on favourable outcomes.
Regulatory and Jurisdictional Ambiguity
Centralised platforms frequently operate across legal boundaries without formal accountability structures, limiting recourse in the event of disputes or losses.
1.2Operational Constraints for SPL Token Communities
Projects issuing SPL tokens face structural challenges when attempting to deploy interactive economic systems:
Security Standards
Smart contract development introduces significant risk without access to secure randomness sources, formal audits, and hardened custody mechanisms.
Infrastructure Overhead
Operating frontends, backend services, and token custody systems imposes ongoing maintenance and operational complexity.
Standardisation and Transparency
The absence of commonly adopted, auditable gaming primitives limits the ability of communities to independently verify system behaviour.
2. System Architecture and Trust Model
2.1System Components
The DegenBox protocol is composed of the following core components:
On-Chain Components
DegenBox Program (Solana Smart Contract)
Anchor-based program responsible for project creation, box issuance, commit–reveal logic, outcome calculation, vault custody, and reward distribution.
Project Vault PDAs
Program Derived Addresses that hold SPL tokens used for participant payouts. Each vault is deterministically derived per project and token mint.
Box State Accounts
On-chain accounts representing individual box instances, including ownership, frozen luck score, commit status, randomness reference, and settlement or refund state.
Platform Treasury PDA
Program-controlled account that accumulates platform fees and project initialisation fees.
Randomness Accounts (Switchboard VRF)
On-chain accounts generated by Switchboard oracles containing signed verifiable randomness and associated metadata.
Off-Chain Components
Web Application (Next.js / React)
User interface for project creation, box interaction, and account state visualisation. Serves as a transaction relay but does not custody assets.
Backend Services (Node.js)
Handles metadata indexing, subdomain routing, analytics aggregation, and treasury automation. Does not possess signing authority over on-chain assets.
Oracle Network (Switchboard VRF)
Distributed oracle network responsible for generating and signing cryptographically verifiable randomness.
2.2Trust Boundaries and Security Assumptions
The protocol enforces the following trust model:
Non-Custodial Asset Model
All user and project funds are held in PDAs controlled exclusively by the on-chain program. Neither the frontend nor backend services possess private keys capable of moving funds.
Oracle Trust Assumption
Randomness integrity relies on the security of the Switchboard oracle network and its cryptographic signature scheme. The protocol assumes a threshold of honest oracles.
Client Integrity
The frontend is treated as untrusted. All state transitions and validations occur on-chain.
Administrator Authority
Platform administrators are restricted to configuration updates and emergency pause controls. They do not have withdrawal authority over project vaults.
2.3Protocol Lifecycle
Project Initialisation
A creator submits a project creation transaction and pays a launch fee denominated in $3EYES. The protocol deploys a project configuration account and derives a vault PDA for the specified SPL token mint.
Liquidity Provisioning
The creator deposits SPL tokens into the project vault PDA to fund potential participant rewards. Prior to activation, each project must satisfy a minimum vault funding requirement calculated using a statistically derived model.
Box Issuance and Commitment
A participant purchases a box using the project's SPL token. The protocol creates a box state account and records ownership and timestamped luck accumulation parameters.
Commit Phase
The participant submits an "open" instruction, freezing the box's luck score and creating a randomness request account.
Reveal Phase
Switchboard oracles fulfil the randomness request and publish a signed randomness value. The participant submits a "reveal" instruction, upon which the protocol deterministically computes the outcome on-chain.
Settlement
Upon successful outcome computation, the protocol consumes the randomness value, closes the associated oracle account, and transfers the calculated payout from the project vault to the participant.
3. Protocol Incentive and Fee Model
3.1Role of the $3EYES Token
The $3EYES token functions as the platform utility asset within the DegenBox protocol. It is used to gate access to protocol-level functionality and to coordinate economic incentives between project creators, participants, and the platform treasury.
3.2Fee Collection and Treasury Operations
The protocol collects fees from two primary sources:
Project Initialisation Fee
A one-time payment denominated in $3EYES submitted during project creation.
Transaction Commission
A percentage-based fee applied to each box purchase, denominated in the project's SPL token.
All commission fees are routed on-chain to the Platform Treasury PDA. The treasury holds collected assets until processed according to protocol-defined treasury operations.
3.3Treasury Processing and Buyback Mechanism
At defined intervals, treasury-held SPL tokens are programmatically exchanged for SOL through an on-chain liquidity aggregator.
The resulting SOL is allocated according to the following policy:
| Allocation | Percentage | Purpose |
|---|
| Buyback Allocation | 90% | Used to acquire $3EYES from public liquidity venues |
| Operational Allocation | 10% | Routed to operations wallet for development and maintenance |
Acquired $3EYES tokens are transferred to a designated protocol-controlled account. The protocol may apply holding, redistribution, or future governance mechanisms to these tokens as defined by subsequent upgrades.
3.4Incentive Alignment and Risk Considerations
The incentive model is designed to align economic interests across protocol participants:
Project Creators
Are incentivised to increase platform usage through community engagement, as protocol activity directly contributes to platform-level fee generation.
Participants
Benefit from transparent fee structures and verifiable on-chain execution.
Token Holders
Are economically exposed to protocol activity through the treasury's buyback mechanism.
Technical Note
This model assumes: Sustained platform usage and liquidity availability for token exchange operations; Adequate market depth to support treasury conversions without excessive slippage; Stable operation of on-chain liquidity aggregators.
4. Outcome Model and Probabilistic Framework
4.1State Variables and Parameters
Each box instance is governed by a set of on-chain state variables:
Box Price (P)
The SPL token amount required to purchase a box.
Luck Score (L)
A non-negative integer that increases as a function of box holding duration prior to commitment.
Tier Thresholds (T₁, T₂, T₃)
Configurable boundaries that map luck scores to discrete probability tiers.
Payout Multipliers (Mᵣ, Mₑ, Mₚ, Mⱼ)
Deterministic multipliers applied to the box price for each outcome class: rebate, break-even, profit, and jackpot.
Randomness Value (R)
A uniformly distributed integer derived from verifiable randomness, bounded within a fixed range (e.g. 0–99).
All variables are publicly readable on-chain and fixed at the moment of commitment.
4.2Luck Accumulation Function
The protocol defines a monotonic accumulation function:
L(t) = L₀ + floor((t - t₀) / Δt)
Where:
- +L(t) = luck score at time t
- +L₀ = base luck value at box creation
- +t₀ = box issuance timestamp
- +Δt = project-defined luck interval
At the moment of commitment, the current luck score is frozen and used for tier classification.
4.3Outcome Space and Payout Multipliers
The protocol defines a finite outcome space:
| Outcome Class | Multiplier | Description |
|---|
| Rebate | Mᵣ | Partial return of box price |
| Break-even | Mₑ | Full return of box price |
| Profit | Mₚ | Positive expected gain |
| Jackpot | Mⱼ | High-magnitude payout |
The realised payout W is computed as:
W = P × Mₓ
Where Mₓ is selected based on the outcome class determined by the tier-specific probability distribution.
4.4Tier-Based Probability Distributions
Luck scores map deterministically to a tier classification:
Tier(L) =
T1 if L ≤ τ₁
T2 if τ₁ < L ≤ τ₂
T3 if L > τ₂
Each tier defines a discrete probability distribution over the outcome space. The randomness value R is used to select an outcome via interval mapping.
Technical Note
Example (Tier 3):
R ∈ [0, 43] → Rebate
R ∈ [44, 77] → Break-even
R ∈ [78, 97] → Profit
R ∈ [98, 99] → Jackpot
Tier parameters, probability ranges, and multipliers are stored on-chain in the platform configuration account and are publicly verifiable.
4.5Expected Value and RTP Characteristics
The expected value (EV) of a box opening under a given tier is defined as:
EV = Σ(i ∈ O) [ pᵢ × (P × Mᵢ) ]
Where:
- +O = set of outcome classes
- +pᵢ = probability of outcome i
- +Mᵢ = payout multiplier for outcome i
- +P = box price
The Return-to-Participant (RTP) ratio is expressed as:
RTP = EV / P
Tier parameters are selected to produce RTP values that increase monotonically with luck score, subject to the constraint:
RTP_T1 ≤ RTP_T2 ≤ RTP_T3 < 1
This ensures that all tiers maintain a non-negative platform edge while providing improved expected outcomes for higher-tier participation.
4.6Reveal Expiry, Oracle Failure, and Settlement Conditions
The protocol enforces a bounded reveal window following the commitment phase. If a participant fails to complete the reveal instruction within this interval, the box instance is marked as expired and deterministically settles to a null payout state.
In the event of a verified oracle or network failure that prevents the randomness request from being fulfilled within the reveal window, the protocol enters a refund state for the affected box instance. Under this condition, the participant is permitted to reclaim the original box price from the project vault.
Security Property
This fallback mechanism is designed to preserve liveness and participant fairness under external service disruptions while maintaining the integrity of the protocol's probabilistic model.
5. Security Model and Verifiability Framework
5.1Threat Assumptions
The protocol is designed under the following adversarial assumptions:
Untrusted Clients
Frontend and backend services are assumed to be potentially compromised. All critical state transitions and validations occur exclusively on-chain.
Rational and Adversarial Participants
Participants and project creators may attempt to exploit timing, arithmetic, or authorisation flaws to gain economic advantage.
Partially Trusted Oracles
The protocol assumes a threshold of honest behaviour within the Switchboard oracle network and relies on cryptographic verification of oracle signatures.
Privileged Administrator Risk
Platform administrators are assumed to have access to configuration and pause controls, but are not trusted with direct asset custody.
5.2Randomness Integrity Model
Randomness is provided through Switchboard's Verifiable Random Function (VRF), which generates cryptographically signed entropy that is both unpredictable prior to fulfilment and mathematically verifiable post-settlement.
The protocol enforces the following properties:
- +Unpredictability — Randomness cannot be known before oracle commitment
- +Determinism — Given inputs produce identical outputs
- +Authenticity — Oracle signatures prove origin
- +Single-Use Entropy — Each randomness value is consumed once
5.3State Transition and Authorisation Model
All protocol operations are implemented as explicit state transitions governed by on-chain constraints.
Each instruction validates:
- +Ownership — Caller identity verification
- +Project Authority — Creator-level permissions
- +Administrative Scope — Platform-level restrictions
- +State Validity — Correct transition sequencing
Unauthorised or out-of-sequence transitions result in deterministic transaction failure.
5.4Asset Custody and Withdrawal Controls
All SPL tokens associated with participant rewards and creator funds are held in Program Derived Addresses (PDAs) controlled exclusively by the protocol.
The only permitted vault egress paths are:
- +Settlement Transfer — Payout to winning participant
- +Creator Withdrawal — Authorised vault access by project owner
- +Project Closure — Return of remaining funds to creator
5.5Emergency Controls and Failure Domains
The protocol includes bounded administrative controls intended to mitigate systemic risk:
- +Global Pause Mechanism — Halt all operations in emergencies
- +Non-Retroactivity — Pausing does not affect committed boxes
- +Scoped Authority — Admins cannot extract vault funds
These controls define a limited failure domain in which liveness may be temporarily reduced without compromising asset safety or outcome integrity.
5.6Independent Verification Procedures
All protocol state is publicly accessible on the Solana blockchain and can be independently verified without reliance on platform-operated infrastructure.
Verification procedures include:
- +Platform Configuration Audit — Read probability distributions and multipliers
- +Box Outcome Audit — Verify luck score, randomness, and payout
- +Randomness Authenticity Audit — Check oracle signatures
- +Vault Solvency Audit — Confirm funds are present for payouts
Security Property
The protocol is designed to be fully verifiable using only publicly available on-chain data and open-source client tools, without reliance on trusted intermediaries.
6. Project Deployment and Integration Guide
6.1Eligibility and Prerequisites
To deploy a project instance on the DegenBox protocol, a creator must satisfy the following conditions:
- +Control of a valid SPL token mint
- +Ability to provision initial liquidity for participant payouts
- +Payment of the protocol-defined project initialisation fee denominated in $3EYES
- +Access to a Solana-compatible wallet capable of signing program instructions
6.2Project Initialisation Workflow
Project deployment follows a deterministic on-chain workflow:
1
Creator submits project creation transaction and remits initialisation fee in $3EYES
2
Protocol creates project configuration account and derives vault PDA
3
Creator supplies initial liquidity by transferring SPL tokens into project vault
4
Upon satisfying minimum vault balance, project transitions to active state
6.3Economic Parameters and Vault Management
Each project instance operates under protocol-level economic constraints:
Vault Funding Requirement
Project vault must maintain balance ≥ protocol-defined minimum threshold prior to activation.
Revenue Retention
A fixed commission of 1% is applied to each box purchase. Remaining revenue accrues to project vault.
Withdrawal Authorisation
Only the project authority may invoke vault withdrawal instructions.
6.4Operational Responsibilities
Project creators assume responsibility for:
- +Communicating platform mechanics and risks to their community
- +Monitoring protocol announcements related to upgrades or parameter changes
- +Complying with applicable legal and regulatory requirements in relevant jurisdictions
Technical Note
The protocol does not assume responsibility for project-level representations, token economics, or regulatory compliance.
7. Protocol Development and Upgrade Framework
The DegenBox protocol is designed as an extensible on-chain system whose functionality may evolve through controlled upgrades to the program logic and platform configuration parameters.
Protocol development is guided by the following principles:
- +Backward Compatibility — New versions maintain existing project functionality
- +Deterministic State Migration — Upgrades follow predictable patterns
- +Parameterisation Over Hardcoding — Configuration changes via accounts, not redeployment
- +Security-First Deployment — Thorough testing before mainnet updates
7.1Planned Capability Extensions
The following areas represent active research and development targets rather than binding delivery commitments:
- +Tier and outcome model extensions
- +Creator analytics and performance reporting
- +Referral and attribution mechanisms
- +Governance tooling for protocol parameter updates
- +Cross-project reputation and verification systems
8. Protocol Outlook and Governance Considerations
The long-term objective of the DegenBox protocol is to operate as a transparent, verifiable on-chain system whose behaviour can be independently inspected, simulated, and integrated by external developers and auditors.
Governance of protocol-level parameters may be extended to token-based or multi-signature control mechanisms in future iterations, subject to formalisation of voting thresholds, upgrade paths, and emergency intervention procedures.
Security Property
The protocol does not rely on discretionary off-chain processes for outcome determination, asset custody, or settlement. All critical operations are enforced through deterministic on-chain logic and publicly auditable state.
Conclusion
DegenBox represents an application of cryptographic randomness, non-custodial asset control, and probabilistic mechanism design to the deployment of community-driven on-chain gaming systems.
By formalising outcome generation, settlement, and economic flows at the protocol level, the system seeks to reduce reliance on trusted intermediaries and enable independent verification of fairness, solvency, and operational integrity.
This document describes the current reference implementation and protocol design as deployed on the Solana blockchain. Behaviour is governed exclusively by on-chain program logic and configuration accounts. This document is non-authoritative in the event of discrepancies between described behaviour and deployed code.