The primary objective of the Lucky Hive protocol is the absolute preservation of user principal deposits. The secondary objective is mathematically unassailable fairness in yield distribution (prize draws).

Assumptions:

1. The underlying yield source (Stacks PoX, or the future sBTC vault) functions correctly and does not experience a total loss of principal.
2. The Stacks blockchain advances securely.
3. Admin keys (Governance) are managed via a strict multi-sig and are subject to hardcoded timelocks before parameter changes can execute.

Generating verifiable randomness on-chain is notoriously difficult. If a node operator can predict the outcome of a draw, they can manipulate transaction ordering to guarantee a win, draining the accumulated yield pool.

Currently deployed on Testnet, the MVP utilizes a commit-reveal schema leveraging Stacks block hashes.

1. Commit Phase: An automated "feeder bot" (crank) commits a hashed secret H(R) to the auction-manager contract.
2. Lock Phase: The contract locks the current draw epoch. No further deposits or TWAB updates are eligible for this specific draw. The protocol waits a predefined number of blocks N.
3. Reveal Phase: The crank reveals the raw secret R. The contract verifies H(R) == Hash(R).
4. Drawing Source of Truth: The winning number is generated by combining the revealed secret R with the block-hash of block CurrentBlock - N.

Why block hashes? The secret R is committed before the future block CurrentBlock - N is mined. Therefore, the crank operator cannot know the block hash. Conversely, a malicious miner controlling the block hash at CurrentBlock - N cannot know the secret R. The combination mathematically guarantees unpredictability.

The V1 commit-reveal model requires trust in the liveness (uptime) of the centralized crank bot to reveal the secret. While the crank cannot cheat the outcome, it could theoretically delay the draw by refusing to reveal.

The requested Stacks Foundation grant directly funds the transition to a fully decentralized Verifiable Random Function (VRF) Oracle (e.g., Pyth Network or SupraOracles, as they become mature on Stacks Mainnet).

1. The auction-manager will emit an on-chain VRF request.
2. The decentralized oracle network will respond asynchronously with a cryptographically verifiable random number and a proof.
3. The Clarity contract natively verifies this proof, directly executing the yield distribution without any localized crank intervention.

At the core of prize-pool.clar is the absolute rule: $Principal In = Principal Out$.

• Yield Segregation: User deposits (STX/sBTC) are mathematically isolated from generated yield within the contract accounting.
• Decidability Constraints: As outlined in the TECHNICAL_SPEC.md, withdrawing from the protocol is an $O(1)$ operation that simply burns the honeycomb-token receipt and returns the exact initial collateral. It is never dependent on loops or the state of other users' balances.
• Circuit Breakers: A multisig-controlled "Pause" function exists. Crucially, this pause function only halts deposits and new prize draws. Withdrawals can never be paused. Even in the event of a zero-day exploit regarding yield calculation, users retain full ability to pull their underlying collateral.

To prevent malicious upgrades or fee manipulation by the protocol founders:

• The governance.clar contract mandates a 7-day minimum timelock on changes to the ProtocolFee or TierSplit parameters.
• The protocol fee is capped mathematically in the contract logic (e.g., it can never exceed 10% of yield, currently set at 1.0%).

Prior to Mainnet launch, the entire open-source repository will undergo an independent third-party audit. Following deployment, Lucky Hive will maintain a permanent Immunefi bug bounty program targeting the core Clarity 4 suite and the TWAB logic.