Governance Transactions Formatting
With the new RTTMmap parameter, it’s not clear to me how transactions would be submitted to update the parameter value.
For example, the way that the SupportedBlockchains parameter is updated is as follows:
pocket gov change_param a83172b67b5ffbfcb8acb95acc0fd0466a9d4bc4 mainnet pocketcore/SupportedBlockchains “[“0001”,“0003”,“0004”,“0005”,“0006”,“0009”,“000A”,“000B”,“000C”,“000F”,“0010”,“0012”,“0021”,“0022”,“0024”,“0025”,“0026”,“0027”,“0028”,“0040”,“0044”,“0046”,“0047”,“0048”,“0049”,“0050”,“0051”,“0052”,“0053”,“0054”,“0056”,“0057”,“0058”,“0059”,“0060”,“0061”,“0063”,“0065”,“0066”,“0067”,“0068”,“0069”,“0070”,“0071”,“0072”,“0074”,“0075”,“0076”,“0077”,“0078”,“0079”,“0080”,“0081”,“03DF”]”
The new RTTMmap parameter should work similarly, in that PNF only has to submit one transaction in order to modify an array of values.
Could you indicate how such a governance transaction would be formatted for the RTTMmap?
Has your local devnet testing included submitting governance transactions to update the parameter?
The per-chain RelaysToTokensMultiplier (RTTM) significantly complicates emission control policies, like the currently active ARR.
ARR operates on the assumption that there is a single RTTM that generates a given mint for a given relay count. Since we know that the same multiplier was applied to all relays, we can make weekly adjustments that will average out to the target daily minting. See this spreadsheet to see this in action.
Introducing chain-specific multipliers means that we can no longer assume that every relay will be multiplied by the same value. We can’t predict how many relays each chain will process either, since it’s an emergent product of demand. Since each chain may have different multipliers, and we can’t predict relays-per-chain, this seems to break the existing methodology for emission controls.
I’m basing this analysis on this logic outlined in the proposal:
When a node mints relay rewards, it looks up the
pos/RelaysToTokensMultiplierMap, and the relayed chain is defined there, it adopts a custom multiplier for that chain to calculate the amount of relay rewards, otherwise it adopts the default multiplier of
ARR modifies the RTTM, not the RTTMmap, and since the RTTMmap overrides the RTTM if a value is set, ARR is no longer controlling emissions for those chains.
That said, this proposal does not suggest any parameter values for the new RTTMmap, so it will not break ARR until a PUP is approved to modify the multiplier for a specific chain. We could therefore think of this PIP as a decision to grant ourselves the option to activate this feature, rather than an implicit approval of any RTTMmap values, as msa alludes to:
This PIP can proceed without answering the ARR question if we’re considering it under this framing. However, any subsequent PUP to set a RTTMmap value should be coupled with a plan to adapt or replace ARR.
The proposal authors have suggested this could be addressed by increasing the GatewayFeePerRelay for specific chains in the same proportion. However, it should be noted that GatewayFeePerRelay is not yet offsetting today’s mint rate (i.e. burn ≠ mint), so scaling the burn in proportion is not a solution by itself. This would have to be part of a broader strategy to set mint = burn, which is not viable yet at current daily relay counts.
Implementation Details and Moving to a Vote
Before moving to a vote, the Implementation section should be filled out as follows, to follow the standard for previous protocol upgrades (note: I’m assuming we’ll adopt RC-0.11.0 as the version number for this potential upgrade):
- If this proposal is approved, and after testing has taken place for BETA-0.11.0 on Testnet, RC-0.11.0 will be published for node runner adoption. Anyone can monitor node runner adoption of RC-0.11.0 using the Servicers and Validators version pie charts displayed here or the equivalent “Staked Tokens by Node Version” chart displayed here.
- Once ≥67% of validator power has updated to this version, an upgrade height will be selected by the Foundation Directors based on the preferences expressed by node runners (e.g. through Discord polls) and they will pass this height to the chain through the
pocket gov upgrade transaction.
- The upgrade height chosen by the Foundation Directors will be communicated in advance to ensure node runners are prepared to react if necessary. A time will be targeted that maximizes the availability of node runners, accounting for all time zones and working hours.
- Once the network is upgraded, each of the new features will be enabled by the Foundation submitting the
pocket gov enable txs and working with the protocol developers to ensure there are no issues.
- For avoidance of doubt, this PIP does not approve any values for the new
RelaysToTokensMultiplierMap parameter, which means the global
RelaysToTokensMultiplier will continue to apply to all chains until a subsequent PUP is approved modifying the new