This post is intended to list the discrepancies between the Houston codebase and ratified RPIPs describing specifications that concern the Houston upgrade.
I’ll keep this list maintained as these are discovered and resolved. Depending on the discrepancy, possible resolutions include modifying the Houston codebase, modifying the RPIP specifications without a vote, and voting on changes to the specification RPIPs.
The overall goal is to ensure that ratified specifications are consistent with the reality of how the protocol actually works in order to prevent future grief.
I’m attempting to just list these here for tracking purposes, if I’ve made a mistake in any of these, or misrepresented their status, please leave a reply and I will update the post.
#1 RPIP-31 - Triggering RPL Reward Claims
Per RPIP-31:
As the controller of the RPL for a node, I MUST be able to trigger a claim of RPL rewards
In code, this isn’t absolute and can be prevented by the node operator (less of an issue with v10, but still exists). Should at least be highlighted under Security Considerations.
Further described by Knoshua here.
Current Status: Will likely be fixed in Houston contracts via hotfix prior to release.
Estimated Impact: Medium
#2 RPIP-31 - Triggering RPL Reward Claims Valid Sources
Per RPIP-31:
If a node’s RPL withdrawal address is set, the call MUST come from one of: the node’s primary withdrawal address, the current RPL withdrawal address, or the node’s address
Per the Houston documentation, only the current RPL withdrawal address is able to claim in the current implementation.
Further described by Knoshua here.
Current Status: Will likely be fixed in Houston contracts via hotfix prior to release.
Estimated Impact: Medium-Low
#3 RPIP-33 - Recurring Treasury Spend Interval Amount
Per RPIP-33:
Amount Per Interval: The amount of RPL to send per reward interval. Specified as a percentage of RPL rewards the pDAO received in a given interval.
Per the Houston documentation the implementation is for absolute amount of RPL per payment interval, rather than a percentage amount.
Current Status: Outstanding Discrepancy. Coded version may make more sense. Will likely try to resolve via forum sentiment vote to avoid overhead of full pDAO snapshot vote.
Estimated Impact: Medium-Low
#4 RPIP-33 - Security Council Quorum Thresholds
Per RPIP-33:
rocketDAOProtocolSettingsSecurity - security.members.quorum …
>= 51% & < 75%
Per the Houston audit, the implemented check is >= 51% and <=75%
Current Status: Coded version may make more sense. Outstanding Discrepancy.
Estimated Impact: Very Low
#5 RPIP-33 - Network Submission Frequency Guard
Per RPIP-33:
rocketDAOProtocolSettingsNetwork - network.submit.balances.frequency …
> 1 hour
Per the Houston audit, the implemented check is >= 1 hour.
Current Status: Coded version may make more sense. Outstanding Discrepancy.
Estimated Impact: Very Low
#6 RPIP-30 - 2-Step Withdrawal Process
Per RPIP-30:
The next significant smart contract upgrades SHALL update the RPL withdrawal process to be a 2-step process
This functionality is not included in Houston.
Current Status: Core team had previously communicated this would not be in Houston. RPIP-30 has been updated to clarify that this will not be in Houston. Resolved.
Estimated Impact: Low