SendCrypto security record

Users can transfer the `SENDC` tokens to the contract and give back staking shares by function `stake()`. The function `claim()` exchanges the full balance of the shares back to the `SENDC` token, but the contract allows users to transfer shares to each other. This allows users to arbitrage by transferring the newly deposited shares to earlier depositors, then calling the function `claim()` to delete the stake info. The cycle continues to arbitrage.

The code base contains a transparent_proxy folder, implying the potential to upgrade implementation contracts in the future. For upgradeable contracts, there must be storage gap to "allow developers to freely add new state variables in the future without compromising the storage compatibility with existing deployments". Otherwise it may be very difficult to write new implementation code. Without storage gap, the variable in child contract might be overwritten by the upgraded base contract if new variables are added to the base contract. Refer to https://docs.openzeppelin.com/upgrades-plugins/1.x/writing-upgradeable

There should always be events emitted in the sensitive functions that are controlled by centralization roles.

The contract is serving as the underlying entity to interact with third-party protocols. The scope of the audit treats third party entities as black boxes and assume their functional correctness. However, in the real world, third parties can be compromised and this may lead to lost or stolen assets. In addition, upgrades of third parties can possibly create severe impacts, such as increasing fees of third parties, migrating to new LP pools, etc. ```solidity=65 IERC1820RegistryUpgradeable internal constant _ERC1820_REGISTRY = IERC1820RegistryUpgradeable(0x1820a4B7618BdE71Dce8cdc73aAB6C95905faD24); ``` - The contract `SendCryptoStaking` interacts with third party contract with `IERC1820RegistryUpgradeable` interface via `_ERC1820_REGISTRY`.