GITBOOK-194: change request with no subject merged in GitBook

2026-01-12 14:33:49 +08:00 · 2023-06-21 15:37:43 +00:00
parent 8162692469
commit b16b669bbb
5 changed files with 111 additions and 13 deletions
--- a/.gitbook/assets/image
+++ b/.gitbook/assets/image
--- a/SUMMARY.md
+++ b/SUMMARY.md
@@ -23,6 +23,11 @@
 * [Understanding the Orderbook](orderbook/understanding-the-orderbook.md)
 * [Using the Orderbook](orderbook/using-the-orderbook.md)

+## 🚀 Launchpad
+
+* [What is the Launchpad](launchpad/what-is-the-launchpad.md)
+* [Using the Launchpad](launchpad/using-the-launchpad.md)
+
 ## 📚 Whitepaper

 * [Automated Market Making of Trading Pool](whitepaper/automated-market-making-of-alex/README.md)
--- a/developers/testnet.md
+++ b/developers/testnet.md
@@ -12,17 +12,5 @@ For any questions / follow-ups, please use our Discord channel ([https://discord

 ## Smart Contracts

-| Contract           | Address                                                           |
-| ------------------ | ----------------------------------------------------------------- |
-| Vault              | ST29E61D211DD0HB0S0JSKZ05X0DSAJS5G5QSTXDX.alex-vault              |
-| Reserve Pool       | ST29E61D211DD0HB0S0JSKZ05X0DSAJS5G5QSTXDX.alex-reserve-pool       |
-| Fixed Weight Pool  | ST29E61D211DD0HB0S0JSKZ05X0DSAJS5G5QSTXDX.fixed-weight-pool-v1-02 |
-| Simple Weight Pool | ST29E61D211DD0HB0S0JSKZ05X0DSAJS5G5QSTXDX.simple-weight-pool-alex |
-| Swap Helper        | ST29E61D211DD0HB0S0JSKZ05X0DSAJS5G5QSTXDX.swap-helper-v1-03       |
-| ALEX Token         | ST29E61D211DD0HB0S0JSKZ05X0DSAJS5G5QSTXDX.age000-governance-token |
-| autoALEX Token     | ST29E61D211DD0HB0S0JSKZ05X0DSAJS5G5QSTXDX.auto-alex               |
-| STX (wrapped)      | ST29E61D211DD0HB0S0JSKZ05X0DSAJS5G5QSTXDX.token-wstx              |
-| xBTC               | ST29E61D211DD0HB0S0JSKZ05X0DSAJS5G5QSTXDX.token-wbtc              |
-| xUSD               | ST29E61D211DD0HB0S0JSKZ05X0DSAJS5G5QSTXDX.token-wxusd             |
-| USDA               | ST29E61D211DD0HB0S0JSKZ05X0DSAJS5G5QSTXDX.token-wusda             |
+<table><thead><tr><th width="167">Contract</th><th>Address</th></tr></thead><tbody><tr><td>Vault</td><td>ST29E61D211DD0HB0S0JSKZ05X0DSAJS5G5QSTXDX.alex-vault</td></tr><tr><td>Reserve Pool</td><td>ST29E61D211DD0HB0S0JSKZ05X0DSAJS5G5QSTXDX.alex-reserve-pool</td></tr><tr><td>Fixed Weight Pool</td><td>ST29E61D211DD0HB0S0JSKZ05X0DSAJS5G5QSTXDX.fixed-weight-pool-v1-02</td></tr><tr><td>Simple Weight Pool</td><td>ST29E61D211DD0HB0S0JSKZ05X0DSAJS5G5QSTXDX.simple-weight-pool-alex</td></tr><tr><td>Swap Helper</td><td>ST29E61D211DD0HB0S0JSKZ05X0DSAJS5G5QSTXDX.swap-helper-v1-03</td></tr><tr><td>ALEX Token</td><td>ST29E61D211DD0HB0S0JSKZ05X0DSAJS5G5QSTXDX.age000-governance-token</td></tr><tr><td>autoALEX Token</td><td>ST29E61D211DD0HB0S0JSKZ05X0DSAJS5G5QSTXDX.auto-alex</td></tr><tr><td>STX (wrapped)</td><td>ST29E61D211DD0HB0S0JSKZ05X0DSAJS5G5QSTXDX.token-wstx</td></tr><tr><td>xBTC</td><td>ST29E61D211DD0HB0S0JSKZ05X0DSAJS5G5QSTXDX.token-wbtc</td></tr><tr><td>xUSD</td><td>ST29E61D211DD0HB0S0JSKZ05X0DSAJS5G5QSTXDX.token-wxusd</td></tr><tr><td>USDA</td><td>ST29E61D211DD0HB0S0JSKZ05X0DSAJS5G5QSTXDX.token-wusda</td></tr></tbody></table>

--- a/launchpad/using-the-launchpad.md
+++ b/launchpad/using-the-launchpad.md
@@ -0,0 +1,68 @@
+# Using the Launchpad
+
+## Contract address
+
+[https://explorer.hiro.so/txid/SP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.alex-launchpad-v1-1?chain=mainnet](https://explorer.hiro.so/txid/SP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.alex-launchpad-v1-1?chain=mainnet)
+
+## Listing
+
+`contract-owner` calls `create-pool` with the following parameters.
+
+* `launch-token-trait` : the trait reference of `project token` (e.g. ALEX)
+* `payment-token-trait` : trait reference of `payment token` (e.g. sUSDT)
+* `launch-owner` : address of the project that launches the `project token`
+* `launch-tokens-per-ticket` : number of `project token` per `ticket`&#x20;
+* `price-per-ticket-in-fixed` : `payment token` deposit required per `ticket` (in 8-digit fixed notation)
+* `activation-threshold` : number of tickets required to activate the launch
+* `registration-start-height` : start (inclusive) block-height of registration period
+* `registration-end-height` : end (inclusive) block-height of registration period
+* `claim-end-height` : end (inclusive) block-height of claim (i.e. lottery) period
+* `apower-per-ticket-in-fixed` : `apower` required for each `ticket` (can be a list, in 8-digit fixed notation)
+* `registration-max-tickets` : maximum number of `ticket` an address can register
+* `fee-per-ticket-in-fixed` : listing `fee` charged by the platform as percentage of `price-per-ticket-in-fixed` (in 8-digit fixed notation)
+
+**Launch price** of `project token` in `payment token` = `launch-tokens-per-ticket` / `price-per-ticket-in-fixed`
+
+## Project Token Transfer
+
+Once the pool is created, and before the registration period starts, `launch-owner` must call `add-to-position` with the following parameters:
+
+* `launch-id` : id of the launch
+* `tickets` : number of `tickets` `launch-owner` wants to allocate to
+* `launch-token-trait` : trait reference of `project token`
+
+**Total raise** for `project token` = `tickets` x `launch-tokens-per-ticket` x Launch price of `token`.
+
+Upon calling `add-to-position`, (`tickets` x `launch-tokens-per-ticket`) of `project token` will be transferred from `launch-owner` to the contract.
+
+## Registration
+
+Participants call `register` with the following parameters:
+
+* `launch-id` : id of the launch
+* `tickets` : number of `ticket` the participant wants to register
+* `payment-token-trait` : trait reference of `payment token`
+
+Assuming (1) registration period has started, (2) registration period has not ended and (3) the participant is not already registered, the contract will register the participant and:
+
+* burn the required number of `apower` from the participant's wallet, and
+* transfer `tickets` x `price-per-ticket-in-fixed` of `payment token` from the participant's wallet to the contract.
+
+## Lottery
+
+The lottery will be drawn one block after the registration ended. The claim/lottery period ends at `claim-end` block-height.&#x20;
+
+`contract-owner` or `launch-owner` will draw the lottery off-chain using the prescribed rule and call `claim` repeatedly with the following parameters
+
+* `launch-id` : id of the launch
+* `input` : list of participants who won the lottery (up to 200)
+* `launch-token-trait` : trait reference of `project token`
+* `payment-token-trait` : trait reference of `payment token`
+
+Upon calling `claim`, assuming (1) registration period has ended, (2) not all tickets are already won, (3) the launch is activated and (4) the claim/lottery period has not ended yet, the contract will verify the validity of `input` and&#x20;
+
+* transfer the proceeds of `payment token`, net of `fee`, to `launch-owner`,
+* transfer `fee` to the platform, and
+* transfer the appropriate number of `project token` to the winners.
+
+Refund will be processed by either `contract-owner` or `launch-owner` in a similar manner to the claim.
--- a/launchpad/what-is-the-launchpad.md
+++ b/launchpad/what-is-the-launchpad.md
@@ -0,0 +1,37 @@
+# What is the Launchpad
+
+<figure><img src="../.gitbook/assets/image (4).png" alt=""><figcaption></figcaption></figure>
+
+Every project needs a platform to launch their project tokens and our Launchpad is a lottery-based token launch platform that uses a hybrid off-chain / on-chain model.
+
+All user funds related transactions are on chain. These include the submission of the Launch ticket together with the required payment tokens, the distribution or claim of the project tokens won, and the distribution or refund of the payment tokens in the case of not winning the lottery.
+
+What is computationally expensive, i.e. the lottery drawing itself, is done off chain, but submitted to our on-chain contract for verification. The lottery drawing is also transparent and verifiable as it is based on the random seed available from the latest block height, i.e. anyone can independently verify the winners' table.
+
+## Off-chain lottery system <a href="#e255" id="e255"></a>
+
+Lottery system is based on a random number generator called “linear congruential generator”, which is [one of the oldest and best-known pseudorandom number generator algorithms](https://en.wikipedia.org/wiki/Linear\_congruential\_generator).
+
+It starts by firstly drawing a verifiable random function seed (“seed”) from the Stacks block following the registration end. The seed is then
+
+1. multiplied by a constant (_134775813_),
+2. added to another constant (_1_), and, finally,
+3. the modulus of its outcome by another constant (_4294967296_) is calculated to serve as the next random number.
+
+This random number is then scaled by `maximum step size`, the ratio of the total number of registered tickets over the total number of tickets to be won (i.e. oversubscription ratio), multiplied by 1.5 times `walk resolution`.
+
+This `maximum step size` helps ensure the fair-ness of the lottery system.
+
+If a random number drawn falls between a particular `walk resolution` within a block that corresponds to a ticket held by a user, the ticket is determined to have won the lottery.
+
+To generate the next random number, we move to the end of the `walk resolution` of the current random number, and draw another random number using the above linear congruential generator with the current random number as its seed.
+
+The process is repeated until we reach the end of the chain, with the tickets upon whose corresponding `walk resolution` random numbers fell having won the lottery.
+
+These “winners” are first determined off-chain, without the need for any on-chain events, thereby greatly increasing the overall efficiency of the lottery system.
+
+## On-chain verification <a href="#a897" id="a897"></a>
+
+In order to ensure these “winners” are not tempered with or generated in error, upon submission of the list to process claim (whereby the “winners” receive the project tokens) and refund, the contract verifies independently that the list is correct using the same process outlined above, before triggering on-chain events (i.e. processing claims and refunds).
+
+This hybrid on-chain/off-chain lottery system therefore allows ALEX to create a Launchpad that combines the efficiency/speed of off-chain processing, while maintaining verifiability/immutability of on-chain processing.