Technical documentation for Leancoin (LEAN)
- Leancoin is an SPL-Token (Solana Program Library Token) type of token.
- A total of 10,000,000,000 Leancoins will be minted in total.
- The tokens will be distributed to the wallets provided at the time of minting.
Smart contract on GitHub:
Vesting Accounts and a holding account for the tokens set up as Program Derived Addresses (PDA) in the contract to prevent unauthorized access and management of funds deposited on these accounts.
The contract has lock-ups on:
- re-execution of the token minting function,
- unauthorized execution of functions such as token minting and token withdrawal from vesting accounts,
- erroneous execution timing of the token burn function.
- anchor-lang version “0.27.0”
- anchor-spl version “0.27.0”
The contract life cycle is divided into two phases:
Phase 1 - Leancoin token initialization on the Solana network and initial tokens distribution.
Tokens are minted, burned, and transferred to strictly defined accounts based on the input parameters. The following accounts are provided in the parameters: Swap wallet - a wallet outside the contract (managed by the organization) that will be used to exchange old Lean tokens (based on Ethereum) for new Leacoin tokens (described by this document). The wallet is managed by the organization (both tokens issuer) and the exchange will be done outside the contract. Burning wallet - a wallet managed by the contract (PDA) - its tokens can be burnt and there is no way to withdraw tokens from this wallet. Community wallet - a wallet managed by the contract (PDA) - its tokens can be transferred to a wallet outside the contract but not all the tokens can be withdrawn at once due to the vesting mechanism (described as part of Phase 2). Partnership wallet - this wallet operates similarly to the Community Wallet but has distinct vesting rules that distinguish it from the Community Wallet. Marketing wallet - this wallet operates similarly to the Community Wallet but has distinct vesting rules that distinguish it from the Community Wallet. Liquidity wallet - this wallet operates similarly to the Community Wallet but has distinct vesting rules that distinguish it from the Community Wallet.
The initial balance for the last four wallets (community, partnership, marketing, liquidity) is recorded and remembered in the vesting state for vesting purposes (part of Phase 2).
This phase is initiated and completed through a single activation of import_ethereum_token_state function. To ensure the integrity of the process, the procedure is designed to be executed only once and becomes inaccessible after its initial activation.
Phase 1 flow diagram:
Phase 2 - Burning of tokens and vesting of tokens.
- Burning of tokens
Each month, a maximum of 5% of the tokens held by the contract’s burning wallet may be subject to burn. The burn process may be initiated only once per month and only within the first five days of each month.
Tokens are transferred to the burning wallet by the organization (token’s issuer) or other volunteers among token holders.
Phase 2 flow diagram for burning:
- Vesting process
Once Phase 1 is completed, the tokens are locked on the following contract accounts: Community wallet, Partnership wallet, Marketing wallet, and Liquidity wallet. The tokens are released from each of these accounts according to different algorithms, i.e.:
- Community wallet - 2.5% of the initial wallet’s balance is released every month. The first 2.5% is released immediately.
- Partnership wallet - 50% of the initial wallet’s balance is unlocked after 1 month, and the other 50% is unlocked after 2 months.
- Marketing wallet - 40% of the initial wallet’s balance is unlocked after 1 year. Afterward, 5% of the initial wallet’s balance is released every month (so it happens to start from the 13th month).
- Liquidity wallet - 50% of the initial wallet’s balance is unlocked immediately, and the other 50% is unlocked after 1 year.
There is one function defined for each of these wallets. These functions allow to the withdrawal of the tokens, i.e. to transfer them to an address provided in the function’s parameters so they can be transferred outside the contract.
Months are calculated on the basis of calendar months, not days. In other words, days are ignored when calculating the number of months elapsed. This means that if the vesting process starts on 29/04/2023, then 1 month will have passed on 01/05/2023, so the first month will only have had 2 days, but each subsequent month will have had all days, so 2 months will have passed on 01/06/2023, 3 months on 01/07/2023, and so on. If the vesting process is started on 01/04/2023, then the first month will also have all days as 1 month will still have passed on 01/05/2023.
Phase 2 flow diagram for vesting: