The purpose of this article is to explain the different measures employed by the Kawakami team to ensure maximum security of the contract and peace of mind for the $KAWA investors.
Trade Fee Distribution
There are two kinds of tax in Kawatoken’s business logic — buy and sell tax. The taxes are applied on every $KAWA token transaction (buy or sell) and accumulated to the contract.
- Sell tax — the contract function is called sellTax and is constantly 9%, meaning it cannot be modified, preventing bad actors from increasing the tax to a high percentage in the event of deployer wallet hack.
- Buy tax — the contract function is called buyTax with the default value of 5%. This function can be modified, but only to lower the tax, as it was hardcoded to a maximum value of 5%. The reason this function can be edited is to lower the buy tax to 0% during promotion period.-
The collected tax is automatically swapped to ETH and distributed to KAWA Treasury and the developer address as follows:
- On buy — 4% to treasury, 1% to developer
- On sell — 8% to treasury, 1% to developer
Initial Token Distribution
The total $KAWA supply is 999,999,999,999 tokens. Initially all tokens were minted to a multi sig wallet which then added 15% of the tokens to liquidity pool in Uniswap and locked them for 100 years on Unicrypt: https://app.unicrypt.network/amm/uni-v2/pair/0x71ab4e3a48d74a66e1cd4dc5ae74836b713d7378
The rest of the tokens were subsequently airdropped to holders of the old contract (this is contract migration). This is the current token distribution: https://etherscan.io/token/0x5552e5a89a70cb2ef5adbbc45a6be442fe7160ec#balances
Centralization Risks
According to the CertiK report:
The risk describes the current project design and potentially makes iterations to improve in the security operation and level of decentralization, which in most cases cannot be resolved entirely at the present stage. We advise the client to carefully manage the privileged account’s private key to avoid any potential risks of being hacked. In general, we strongly recommend centralized privileges or roles in the protocol be improved via a decentralized mechanism or smart-contract-based accounts with enhanced security practices, e.g., multisignature wallets.
These are the security measures we have taken to mitigate the centralization issues:
- Contract owner is a multisignature Gnosis wallet — Our team uses a multisignature wallet to sign any transactions and changes on the contract via a contract owner address, requiring 3/5 signatures to complete any action. This means that no single bad actor can do anything without the approval of at least 2 other team members.
- Timelock on sensitive functions — Functions with higher sensitivity are timelocked for 48 hours to protect users and make sure they are aware if any change is made. Functions under timelock:
changeMarketingWallet(),emergencyPause(),transferOwnership()
List of team members controlling the multisignature wallet (full name, Twitter handle, wallet address):
- Andrej Kovacevic : @andrejtl : 0x0Cd34e606f1e490353aCDFadfFd855d7358CF6B5
- Richard Kayode : @Real0xRichard: 0x139eb2F8Abdd1c2809fc64cef3214943bb0d7e70
- Fahad Abdulrahman : @Fahad_abu_Tamim : 0x3dbdBb2bDeAF4D8756e2375Bb7Aa841A069283ee
- William Reynolds : @Sniperkawa : 0x9bfb0E684dEDDC637648A642EF5eFE26832c48ba
- Michael Synan : @0x_forest : 0xb11ec03332082ddfcbef1f87e464a1f28a342b41
