# Private Offering System ## **Guaranteed Allocation Option** Since most users choose this option, and it’s easier to understand, let’s first focus on the **Guaranteed Allocation** and leave the **Lottery** mechanism for later, as it introduces additional complexity. Excessive deposits are automatically returned to the users at the end of the offering. In **Hybrid Offerings**, user allocations are determined by two factors: 1. **DAO Power** (a key metric for each user). 2. The amount of **DAO** deposited. The total allocation is split into two parts: * **Guaranteed Allocation** * **Excessive Allocation** ### **Guaranteed Allocation** Calculation The **Guaranteed Allocation** is calculated using the following formula:\ **User’s DAO Power × Total Allocation × Guaranteed Ratio / Total DAO Power registered** Where: * **DAO Power** refers to the power each user has within the system. * **Total Allocation** is the target raise amount (the maximum amount the project aims to raise). * **Guaranteed Ratio** is typically a number between 0.8 and 1, but it’s generally close to 0.98. It depends on the total **DAO Power** and deposited amounts. ### **Excessive Allocation** Calculation Once a user’s **Guaranteed Allocation** is determined, any contributions exceeding this amount are subject to an **Excessive Allocation**: **(User's Contributed Amount - Guaranteed Allocation) × Total Excessive Allocation / Total Excessive Contribution Amount** Where: * **Total Excessive Allocation** = Difference between the **Total Allocation** and the sum of all **Guaranteed Allocations**. * **Total Excessive Contribution Amount** = Difference between the **Total Contributed Amount** and the sum of all **Guaranteed Allocations**. > **Note:** The **Guaranteed Ratio** is derived from the ratio between total **DAO Power** and the total deposited amount. The exact calculation is complex but not essential for most users. *** ### **Example** For clarity, let’s walk through an example. Assume that no users have chosen the **Lottery** option, and everyone deposited at least their **Guaranteed Allocation**: * Total Allocation: 1000 DAO * **Guaranteed Ratio**: 0.98 (pre-calculated) **Users:** * Alice deposits 500 DAO and has 5000 **DAO Power**. * Bob deposits 700 DAO and has 10,000 **DAO Power**. * Carl deposits 800 DAO but has 0 **DAO Power**. **Step-by-Step Calculation:** 1. **Total DAO Power**: 15,000 (5,000 + 10,000 + 0) 2. **Total Contributions**: 2,000 DAO (500 + 700 + 800) **Guaranteed Allocations:** * Alice's Guaranteed Allocation = 5000 × 980 / 15,000 = 326.66 DAO * Bob's Guaranteed Allocation = 10,000 × 980 / 15,000 = 646.8 DAO * Carl's Guaranteed Allocation = 0 DAO (due to 0 **DAO Power**) **Excessive Contributions**: * **Total Excessive Contribution Amount** = 2,000 - (326.66 + 646.8) = 1026.54 DAO * **Total Excessive Allocation** = 1000 - (326.66 + 646.8) = 26.54 DAO **Excessive Allocations**: * Alice’s Excessive Allocation = 173.34 × 26.54 / 1026.54 = 4.48 DAO * Bob’s Excessive Allocation = 53.2 × 26.54 / 1026.54 = 1.37 DAO * Carl’s Excessive Allocation = 800 × 26.54 / 1026.54 = 20.68 DAO **Final Allocations** (Guaranteed + Excessive): * Alice: 326.66 + 4.48 = **331.14 DAO** * Bob: 646.8 + 1.37 = **648.17 DAO** * Carl: 0 + 20.68 = **20.68 DAO** **What if Bob Deposited Only 500 DAO?** If Bob had deposited just 500 DAO, his final allocation would be 500 DAO, and the remaining portion of his **Guaranteed Allocation** (146.8 DAO) would be added to the **Excessive Pool**, increasing both the **Total Excessive Contribution Amount** and the **Total Excessive Allocation**. *** ## **Lottery Option** Now, let’s dive into the **Lottery System**. Users who opt for the lottery must deposit a multiple of the **Ticket Size** (usually 100 DAO). Each user participating in the lottery receives a **Weighting**, which determines their position in the lottery. The **Weighting** calculation is similar to that used for **Guaranteed Allocations**, but with some differences that we won’t cover here. ### **User's Position in the Lottery** A user’s position in the lottery is determined by the sum of all previous users' **Weightings**. The user’s range starts from the sum of previous users’ **Weightings** and ends at the sum of previous plus their own **Weighting**. For example, if there are already 10 users in the lottery with a total **Weighting** of 1000, and the current user has a **Weighting** of 100, their position will be between 1000 and 1100. If a random number is generated within this range, they win one ticket. Users can win additional tickets if more numbers fall within their range. ### **On-Chain Transparency** The entire lottery process is fully on-chain and transparent. At the end of the offering, the lottery result is calculated off-chain, and the winners are fed into the smart contract. The smart contract then verifies that the lottery result is accurate. ### **How Does It Work?** * A sequence of user addresses (winners) is submitted to the smart contract. * The smart contract loops through the user addresses, calculating a **Random Number** (explained below) for each user and checking if it lies within their lottery range. * If the **Random Number** falls within the user’s lottery position, the smart contract assigns 1 ticket to that user. * This process repeats until the **Total Number of Tickets** is distributed. #### **How Are Random Numbers Generated?** The first **Random Number** is based on the keccak hash of the block’s timestamp and block difficulty when the lottery is executed (after the offering ends). Each subsequent **Random Number** is based on a hash of the previous hash. Every **Random Number** falls between 0 and the **Total Weighting** (sum of all users’ **Weightings**). #### **Total Number of Tickets Calculation** Rather than over-complicating the explanation with formulas, just understand that the **Total Allocation** is split into a **Guaranteed Pool** and a **Lottery Pool**, based on the ratio of the amounts deposited through the **Guaranteed** and **Lottery** options. The **Total Number of Tickets** is then determined by the size of the **Lottery Pool** and the **Ticket Size**. *** ### **Example of a Simple Lottery** Let’s assume the **Total Number of Tickets** is 5, and the **Ticket Size** is 100 DAO, making the **Lottery Pool** 500 DAO. **Users:** * Alice’s **Weighting** in the lottery is 100, placing her in the 0-100 range. * Bob’s **Weighting** in the lottery is 200, placing him in the 100-300 range. * Carl’s **Weighting** in the lottery is 400, placing him in the 300-700 range. **Generated Sequence of Winning Tickets (for example):** * Alice, Alice, Bob, Carl, Carl. **Verification by the Smart Contract:** * For Alice, the smart contract verifies that the **Random Number** is between 0 and 100. * For Bob, it verifies that the **Random Number** is between 100 and 300. * For Carl, it verifies that the **Random Number** is between 300 and 700. **Final Allocations:** * Alice wins 2 tickets (200 DAO allocation). * Bob wins 1 ticket (100 DAO allocation). * Carl wins 2 tickets (200 DAO allocation). *** The source code for our hybrid offering contract is available on [bscscan](https://bscscan.com/address/0x0530c78b8f5cf1b5e7f9c787a88e53c74197fe02#code). --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://dao-maker-1.gitbook.io/dao-maker/everything-you-need-to-know/private-offering-system.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.