Intro
This article describes a component of the Immortal Lottery — a decentralized autonomous application designed to work continuously at various blockchains after deployment without any maintenance requirements.
Read more about the Immortal Lottery here.
Immortal Lottery Token ($IML)
IML will be a native Immortal Lottery Token.
The token will grant its owner the rights to claim % from each reward pool fee at each lottery round.
By participating in the lottery draws, users will contribute CLO to the lottery contract and a certain % fee will be deducted from the total reward pool and immediately sent to the “IML Lottery Reward Contract”.
In order to claim a share of the reward fees IML tokens must be staked for 13 days in the IML reward contract. The staking of tokens will work identically to how Cold Staking V1 worked with the exception that the duration of staking will be reduced to 13 days and the staking reward will be calculated in CLO.
Example:
Alice has 1000 IML tokens and Bob has 2000 IML.
Alice and Bob stake their IML tokens in the Lottery Reward Contract.
Carol and Bob are playing a lottery round. Carol deposits 100 CLO to the contract and Bob deposits 400 CLO (i.e. Carol has a 20% chance to win 450 CLO and Bob has a 80% chance to win 450 CLO).
Reward calculation: No matter who wins 50 CLO are allocated for the Lottery Rewards Contract and redistributed among the IML stakers. Alice will earn 16.6 CLO and Bob will earn 33.4 CLO for staking their IML.
Reward claiming: Alice and Bob will have two options: (1) claim reward only — in this case only CLO will be sent and the token will be re-staked for the next 13 days and (2) claim token and reward — in this case 100% of token deposit + CLO reward for the staking round will be sent to the claimer (i.e. Alice would receive 1000 IML and 16.6 CLO or Bob will receive 2000 IML and 33.4 CLO).
IML details & airdrop
IML will be a ERC223 standard token because it is nearly impossible to develop a viable ERC20 stakeable token (read more about the problems of ERC20 here).
IML will have a total supply of 100,000,000.
50% of the total supply will be allocated for the Security Department funding.
45% of the total supply will be airdropped at CLO holders.
5% of the total supply will be allocated for the Callisto Core team and Callisto Enterprise to cover the expenses of the UI implementation and other related needs.
It was originally planned to process the airdrop in early June but marketing staff recommended to re-schedule it to prevent the overlapping with CLOE airdrop as well as CSv1=>CSv2 migration.
The new date of the airdrop snapshot depends on the CSv1=>CSv2 migration process and I will post an update as soon as it will be negotiated with the marketing staff.
Security Department funding
- One of the main goals of the Immortal Lottery project is to provide the funding flow for the Callisto Security Department
https://dexaran.github.io/Immortal-Lottery/
50% of IML token supply will be allocated to fund the activity of Security Auditing department of Callisto. This means that the half of every lottery round fee will go to the special auditing fund address.
These tokens will be permanently staked at the Lottery Rewards Contract and the rewards will be manually claimed & sent to the auditing fund address monthly.
The tokens will remain staked for as long as the Security Auditing department of Callisto is operating.
Reincarnations of the Immortal Lottery
- One of the main goals of the Immortal Lottery project is to serve as a definition of sanity tests for smart-contract platforms
https://dexaran.github.io/Immortal-Lottery/
The Immortal Lottery is likely to have re-implementations across the different smart-contract platforms. In case we will be deeply investigating the capabilities of Solana smart-contracts the Immortal Lottery contract will be deployed there as a proof-of-research done.
This leaves a fully functional contract at the Solana chain but the IML token will be only available at CLO chain at this moment. As the result, it will be necessary to “re-airdrop” the IML tokens from CLO chain to the Solana chain.
Here comes the problem — Solana addresses are not the same as CLO addresses and it is not possible for a user to have the same address at two chains. As the result, a special SignUp contract was developed (you can browse the source code here).
In order to receive the airdropped IML tokens at Solana chain a user will need to explicitly define his Solana address at this special contract. In this case a special snapshot of IML tokens will be taken and compared against the signupped addresses via the SignUp contract.