TEXAN TOKEN security record

In the function `startStake()`, it is checked if `_endowmentSupply > possibleStars`. However, only the possible interest is taken from the `_endowmentSupply`. In the function `endStake()`, if a user calls `endStake()` before the `startDay`, then they are refunded the principal. However, this principal is then counted twice in the total supply as the `_endowmentSupply` is increased by the `_possibleStars` which includes the principal and also the `_StakedPrinciple` is minted to the user.

The function `stakeScrape` allows an external address to update the stake status of another user. This behavior can lead to a denial of service attack for a given time period. For example suppose that user Bob wanted to call the function `stakeScrape`. However, Alice called this function before with Bob's address in the parameter `stakerAddr` then Bob would no longer be able to call `stakeScrape` on himself as Alice has updated his respective `scrapeDay`.

The `LAUNCH_TIME` should be changed to a date in the future if the project has not already been deployed and launched.

The function `scrapeStake()` should only be called once per day and this is ensured by the if statement `if (curDay > calcDays[2])`. In this case it will not revert if a user calls the function multiple times in one day, which can cause confusion.

The `totalSupply` of a token is supposed to return the total amount of tokens in circulation, including those that are locked or in reserve. While the principle amount of tokens is burned from the user and the total possible interest is removed from the `endowmentSupply`, these can be considered as locked or reserved tokens as they are scheduled to be distributed. This can cause confusion if a user stakes or unstakes a large amount of tokens that can make a dramatic change in the `totalSupply`.

Performing integer division before multiplication truncates the low bits, losing the precision of calculation. ```solidity=726 tempInterestAmount = (((current * appliedInterestRate) / YEARPRECISION) * principle) / (PRECISION * PRECISION); //36 decimals ```

When starting a new stake the global stake id is incremented before the `newStakeId` is set equal to it. Since, `g_latestStakeId` is initialized to 1, it will cause the first `newStakeId` to be 2, which could cause confusion.

The following public functions are never called internally. Public functions cost more gas to call then external functions. ```solidity function reportGlobals() ``` --- ```solidity function calculateStakeDays(uint256 tempStartDay, uint256 tempStakedDays, uint256 tempScrapeDay) ``` --- ```solidity function calculateInterest(uint256 stakedPrinciple, uint256 stakedDays) ```

The variable `YEARDIVIDER` is defined at Line 34. The value it refers to is the same value given to the variable `day_divisor`. However the variable `day_divisor` is hardcoded. A similar pattern is also done by the variable 'YEARPRECISION' and `workingDays`. ```solidity uint256 day_divisor = 36525; ``` --- ```solidity uint256 workingDays = servedDays * 100; ```

In the function `_calculateStakeDays`, the function performs the following mathematical operations. ```solidity function _calculateStakeDays(uint256 startDay, uint256 stakedDays, uint256 scrapeDay) internal view returns (uint[6] memory) { uint256 curDay = _currentDay(); //ex. day 25 uint256 endOfStakeDay = startDay + stakedDays; //ex. Day 52 // find the higher of the two days ( startDay or a more recent scrapeDay ) uint256 targetStartDay = scrapeDay >= startDay ? scrapeDay : startDay; // the possible interest bearing days uint256 possibleDays = endOfStakeDay - targetStartDay; uint256 interestDays = 0; // if the stakedDays is less than the minimum, throw an error require(stakedDays >= MIN_STAKE_DAYS, "scrape days must be greater than 1"); ``` Then performs the following check. ```solidity require(stakedDays >= MIN_STAKE_DAYS, "scrape days must be greater than 1"); ``` If the function reverts then the operations are also reverted.