Klink Finance security record

In the contract `klinkStaking`, the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and set the interest rate and lock duration, as well as change the staking status.  In the contract `KlinkToken`, the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and burn tokens from a specified account, burn tokens from a specific account, and mint tokens to a specified address. 

In the contract `KlinkToken`, the role `owner` has the authority to update the token balance of an arbitrary account without sanity restriction through the functions `mint()` and `burnFrom()`. ```solidity=36 function mint(address to, uint256 amount) public onlyOwner { _mint(to, amount); } ``` ```solidity=57 function burnFrom(address account, uint256 amount) public override onlyOwner { super.burnFrom(account, amount); } ``` Any compromise to the owner account may allow a hacker to take advantage of this authority and mint arbitrary amount of tokens to any account.

All of the Klink tokens are sent to the contract deployer on deployment. This is a centralization risk because the deployer or the owner(s) of the EOAs can distribute tokens without obtaining the consensus of the community. Any compromise to these addresses may allow a hacker to steal and sell tokens on the market, resulting in severe damage to the project.

When transferring standard ERC20 deflationary tokens, the input amount may not be equal to the received amount due to the charged transaction fee. For example, if a user stakes 100 deflationary tokens (with a 10% transaction fee) into the staking contract, only 90 tokens actually arrive in the contract. However, the user can still withdraw 100 tokens from the contract, which causes the contract to lose 10 tokens in such a transaction.

The contract multiplies `lockDuration` by 3600 (1 hour in seconds). Yet the constructor and function docstrings suggest `lockduration_` is the number of days, which would normally be multiplied by 86400. If the intention is truly to lock for lockDuration days, then using `lockDuration.mul(3600)` is off by a factor of 24.

When a user with an existing stake calls stake(amount) again, the contract checks that the current lock has not yet expired: ```solidity require(block.timestamp < deposits[from].endTime, "Lock expired, please withdraw and stake again"); ``` If the lock is still active, the contract recalculates and accrues the user’s existing rewards up to the current time, adds those rewards to `deposits[from].rewards`, and then increases the overall deposit. Notably, this process resets the user’s `depositTime` to the new `block.timestamp` and updates the lock end to `block.timestamp + lockDurationInSeconds`. This design compounds the deposit but also means that if the user had only a short time remaining on their current lock, adding more funds starts a new lock period. Consequently, the user cannot withdraw any part of their stake until the newly established lock expires. Projects should ensure users are aware that depositing additional funds before their existing lock ends will defer their withdrawal window accordingly.