Platform: Code4rena
Start Date: 20/05/2021
Pot Size: $55,000 USDC
Total HM: 19
Participants: 8
Period: 7 days
Judge: cemozer
Total Solo HM: 11
Id: 11
League: ETH
Rank: 6/8
Findings: 4
Award: $1,703.76
đ Selected for report: 2
đ Solo Findings: 1
gpersoon
The function addRegistrationTributeGovernance makes a call to _addTribute, the same as addRegistrationTribute is doing However a function _addGovernanceTribute also exists and this function is never called.
It seem more logical that addRegistrationTributeGovernance should call _addGovernanceTribute
https://github.com/code-423n4/2021-05-fairside/blob/main/contracts/token/FSD.sol#L125 function addRegistrationTribute(uint256 registrationTribute) external { ... _addTribute(registrationTribute); } // https://github.com/code-423n4/2021-05-fairside/blob/main/contracts/token/FSD.sol#L133 function addRegistrationTributeGovernance(uint256 registrationTribute) ... _addTribute(registrationTribute); }
// https://github.com/code-423n4/2021-05-fairside/blob/main/contracts/dependencies/TributeAccrual.sol#L50 function _addGovernanceTribute(uint256 tribute) internal {
Editor
Check if addRegistrationTributeGovernance should indeed call _addGovernanceTribute If so, update the code accordingly.
#0 - fairside-core
2021-05-30T13:27:08Z
Duplicate of #20
đ Selected for report: gpersoon
1441.1236 USDC - $1,441.12
gpersoon
In the function purchaseMembership of FSDNetwork.sol, when the membership is extended then membership[msg.sender].creation is increased, however membership[msg.sender].gracePeriod is not increased. This might lead to a gracePeriod than is less then expected. It seems logical to also increase the gracePeriod
FSDNetwork.sol // https://github.com/code-423n4/2021-05-fairside/blob/main/contracts/network/FSDNetwork.sol#L171 function purchaseMembership(uint256 costShareBenefit) external { ... if (membership[msg.sender].creation == 0) { ... membership[msg.sender].creation = block.timestamp; membership[msg.sender].gracePeriod = membership[msg.sender].creation + MEMBERSHIP_DURATION + 60 days; } else { .... membership[msg.sender].creation += durationIncrease; }
Editor
Check if gracePeriod has to be increased also. When that is the case add the logic to do that.
#0 - fairside-core
2021-05-30T15:27:17Z
This should be bumped to a medium severity finding as it actually does not affect the membership duration at all if the gracePeriod
is not updated.
#1 - fairside-core
2021-06-01T15:02:22Z
Fixed in PR#21.
đ Selected for report: gpersoon
0 USDC - $0.00
gpersoon
The performance (gas usage) of the current arctan implementation is: arctan(ONE) ~ 5126 Gas (with solidity 0.6.8) The main cause of the gas usage is due to the library ABDKMathQuad which implements IEEE 754 quadruple-precision binary floating-point numbers However the arctan approximation has a relative low precision.
The PDF higher_order_approximations.pdf in the following article: https://www.researchgate.net/publication/258792323_Full_Quadrant_Approximations_for_the_Arctangent_Function_Tips_and_Tricks shows different formulas for the approximation for arctan, which have a higher precision than the current implementation. https://www.researchgate.net/profile/Xavier-Girones-2/publication/258792323_Full_Quadrant_Approximations_for_the_Arctangent_Function_Tips_and_Tricks/links/5fdc7f5745851553a0c8b801/Full-Quadrant-Approximations-for-the-Arctangent-Function-Tips-and-Tricks.pdf
The third order approximation is: arctan(x) âŧ Ī/2 * sgn(x)Ī(abs(x)) Ī(x) = { ax + x^2 + x^3 } / { 1 + (a+1)x + (a+1)x^2 + x^3 } a=0.6399276529
I've made an implementation (see below), which takes a lot less gas: arctan_uint(1 * precision) ~ 574 Gas (with solidity 0.6.8)
The implementation takes a different approaches to floating points: it multiples all numbers by precision. The precision factor can be adjusted as long as all temporary variables stay below 2^256 (the max value of an uint)
pragma solidity 0.6.8;
contract Test{ uint constant precision=10**30; uint constant pi=3.1415926535E30; uint constant pidiv2=pi/2; uint constant a1=0.6399276529E30; uint constant aplus1=1.6399276529E30;
function arctan_uint(uint x) public pure returns (uint) { uint xsquare = xx/precision; uint xtriple = xsquare * x/precision; uint aplus1x = aplus1 * x/precision; uint top = a1 * x/precision + xsquare + xtriple; // ax + x^2 + x^3 uint bottom = precision + aplus1x + aplus1xx/precision + xtriple; // 1 + (a+1)x + (a+1)x^2 + x^3 return pidiv2top/bottom; }
function test_arctan_uint() public pure returns (uint){
return arctan_uint(precision);
}
}
Define which resolution is required and take the necessary formula from the higher_order_approximations.pdf document. Change the math library to a simple "precision" based implementation (as shown above). This will also require adapting other code. Also set the "precision" constant to the required precision and adjust the constants to the required number of decimals.
#0 - fairside-core
2021-05-30T15:22:01Z
Although the optimization is acknowledged, it will not be applied given that we already use ABDK math across the full codebase.