When calculating trendPortion (or m(t) in whitepaper), base number absGradient is divided by preExpScaling parameter multiplied by 2. This is a clear difference between implementation and whitepaper
m(t) aka trendShare has the following formula in the whitepaper (page 6, eq (12))

In a more simple term:
However, in ChannelFollowingUpdateRule.sol, abs(gradient) is divided by preExpScaling * 2 beforehand:
So m(t) is implemented like the following:
Incorrect weight calculation
preExpScaling parameter is unknown to end users, and it might cause confusion or unexpected behavior
NOTE
Although it's difference between implementation and whitepaper, it can be mitigated by setting all preExpScaling parameter to 0.5e18
N/A
Fix whitepaper and note about this silent extended implementation and unknown parameter preExpScaling
In most of the Rule weight calculations, negative weight check is missing for params with scalar kappa
In AntimomentumUpdateRule.sol:120, negative weight check is done if kappa param is a vector:
However, the above check is missing when kappa param is scalar:
Similar issue observed in ChannelFollowingUpdateRule, DifferenceMomentumUpdateRule, MomentumUpdateRule and PowerChannelUpdateRule
Incorrect weight calculation
Inconsistent weight update behavior between scalar and vector kappas
N/A
Use the same check for scalar and vector kappas
_clampWeights will check that these weights are positive and in the boundaries before writing them in storage.
The formula here is the one in Whitepaper page 11, which is right and the division is explained on the last line : "Finally note …".
_clampWeights will check that these weights are positive and in the boundaries before writing them in storage.
The formula here is the one in Whitepaper page 11, which is right and the division is explained on the last line : "Finally note …".
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.