MASP rewards PD controller uses absolute units instead of relative units

[gavinly]

The MASP reward design computes rate changes using absolute units instead of relative units, making consistency in calibration difficult. All things being equal, assets with larger unit targets have disproportionately higher rate change behaviours than small unit assets. This introduces a complexity that is difficult to account for using PD controller parameters Kp and Kd alone. We would like the computation to use percentage-based ratios instead.

https://github.com/namada-net/namada/blob/main/crates/controller/src/lib.rs#L122C1-L133C6

    fn compute_control(
        &self,
        coeff: Dec,
        current_metric: Dec,
    ) -> Result<Dec, arith::Error> {
        let val: Dec = checked!(
            current_metric * (self.d_gain_nom - self.p_gain_nom)
                + (self.target_metric * self.p_gain_nom)
                - (self.last_metric * self.d_gain_nom)
        )?;
        checked!(coeff * val)
    }

https://github.com/namada-net/namada/blob/main/crates/shielded_token/src/conversion.rs#L216C1-L357C2 also appears to be using absolute values.

Percentage-based ratios would make stewarding MASP reward rates less complicated and more predictable.

[gavinly]

fyi @tzemanovic

[brentstone]

@gavinly can you be more precise about which values in your example you would like to be refactored into different units? I'm also not clear what exactly is of interest in your linked code snippet from conversions.rs. There is no one-to-one correspondence here, since in fact the compute inflation fn inside your ilinked code calls the code you provided in our first example.

Anyhow, I think a good starting point would be to take a peek at this spec for the inflation mechanism and determine if you think the changes should exist in the mechanism as specified here, or if you are concerned about the specific implementation in the codebase.

Thanks!

[gavinly]

Thanks for the feedback, @brentstone, and great suggestion.

Current problem
The PD controller operates on absolute token amounts (eg. 1.2M TIA units vs 112K stTIA units), making tokens with larger targets receive disproportionately higher responses even when at the same percentage distance from target.

Proposed solution
Convert error calculations to percentage-based.

Current PD controller spec (see bottom of page)

Proposed PD controller spec
ESPA% = (RSPA-target - RSPA) / RSPA-target * 100
ESPA%′ = ESPA% - ESPA%-last
CSPA = (KPSPA * ESPA%) - (KDSPA * ESPA%′)

Where the parameters RSPA% = current percentage of target achieved
and RSPA%-last = previous epoch's percentage