# Houston Specification Discrepancies **URL:** \ **Category:** Governance\ **Created:** [3 May 2024 17:25 UTC](https://dao.rocketpool.net/t/houston-specification-discrepancies/2958 "2024-05-03T17:25:13Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![LongForWisdom](https://dao.rocketpool.net/user_avatar/dao.rocketpool.net/longforwisdom/32/743_2.png) [@LongForWisdom](https://dao.rocketpool.net/u/LongForWisdom)\ **Post date:** [3 May 2024 17:25 UTC](https://dao.rocketpool.net/t/houston-specification-discrepancies/2958/1 "2024-05-03T17:25:14Z")
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](https://rpips.rocketpool.net/RPIPs/RPIP-31#claiming-rpl-rewards): > 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](https://dao.rocketpool.net/t/rewards-tree-spec-v10/2937/22). **Current Status:** Will likely be fixed in Houston contracts via [hotfix](https://github.com/rocket-pool/rocketpool/tree/houston-hotfix) prior to release. **Estimated Impact:** Medium * * * ### #2 RPIP-31 - Triggering RPL Reward Claims Valid Sources Per [RPIP-31](https://rpips.rocketpool.net/RPIPs/RPIP-31#claiming-rpl-rewards): > 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](https://docs.rocketpool.net/guides/houston/whats-new#rpl-withdrawal-address), only the current RPL withdrawal address is able to claim in the current implementation. Further described by Knoshua [here](https://dao.rocketpool.net/t/rewards-tree-spec-v10/2937/22). **Current Status:** Will likely be fixed in Houston contracts via [hotfix](https://github.com/rocket-pool/rocketpool/tree/houston-hotfix) prior to release. **Estimated Impact:** Medium-Low * * * ### #3 RPIP-33 - Recurring Treasury Spend Interval Amount Per [RPIP-33](https://rpips.rocketpool.net/RPIPs/RPIP-33#treasury-contract-change): > 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](https://docs.rocketpool.net/guides/houston/participate#creating-a-recurring-treasury-spend) 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](https://rpips.rocketpool.net/RPIPs/RPIP-33#parameter-table): > 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](https://rpips.rocketpool.net/RPIPs/RPIP-33#parameter-table): > 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](https://rpips.rocketpool.net/RPIPs/RPIP-30#final-states): > 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 * * * ---
**Author:** ![Valdorff](https://dao.rocketpool.net/user_avatar/dao.rocketpool.net/valdorff/32/319_2.png) [@Valdorff](https://dao.rocketpool.net/u/Valdorff)\ **Post date:** [4 May 2024 02:11 UTC](https://dao.rocketpool.net/t/houston-specification-discrepancies/2958/2 "2024-05-04T02:11:15Z")
Could we add impacts to these? To me it’s roughly: #1: medium #2: medium-low #3: medium-low #4, #5: negligible (I think an RPIP editor can fix these) ---
**Author:** ![knoshua](https://dao.rocketpool.net/user_avatar/dao.rocketpool.net/knoshua/32/128_2.png) [@knoshua](https://dao.rocketpool.net/u/knoshua)\ **Post date:** [4 May 2024 07:08 UTC](https://dao.rocketpool.net/t/houston-specification-discrepancies/2958/3 "2024-05-04T07:08:51Z")
So I don’t forget, v10 would create a new discrepancy: Per [RPIP-31](https://rpips.rocketpool.net/RPIPs/RPIP-31#claiming-rpl-rewards): > If a node operator is in the smoothing pool a claim of RPL will also distribute ETH rewards With [Reward Tree Spec v10](https://dao.rocketpool.net/t/rewards-tree-spec-v10/2937) a claim of RPL will no longer distribute ETH rewards if the RPL withdrawal is set and different from the primary withdrawal address. ---
**Author:** ![LongForWisdom](https://dao.rocketpool.net/user_avatar/dao.rocketpool.net/longforwisdom/32/743_2.png) [@LongForWisdom](https://dao.rocketpool.net/u/LongForWisdom)\ **Post date:** [7 May 2024 13:16 UTC](https://dao.rocketpool.net/t/houston-specification-discrepancies/2958/4 "2024-05-07T13:16:16Z")
I’ve added Val’s impact estimations and made the post a wiki-post. This means that almost anyone can edit it. Use power responsibly, etc. ---
**Author:** ![LongForWisdom](https://dao.rocketpool.net/user_avatar/dao.rocketpool.net/longforwisdom/32/743_2.png) [@LongForWisdom](https://dao.rocketpool.net/u/LongForWisdom)\ **Post date:** [8 May 2024 09:27 UTC](https://dao.rocketpool.net/t/houston-specification-discrepancies/2958/5 "2024-05-08T09:27:21Z")
For completeness and future reference. Message from @langers in discord: > [@](#): > > We acknowledge the discrepancies documented ([Houston Specification Discrepancies](https://dao.rocketpool.net/t/houston-specification-discrepancies/2958)) and will be revising our QA going forward so we identify these issues in our internal testing. Obviously we would prefer to rectify the issues but we have been conscious of delivering Houston asap. > > Rectifying RPIP-31, is a very small change that could be developed, tested, and audited quickly. Depending on auditor availability - it may even be comparable to a pDAO vote timeline. As we would have to delay for the pDAO vote anyway, we might as well fix the issue. It would also not affect Saturn in the least. > > We will confirm scope and auditor availability asap. > > For completeness, we could also rectify the small guard issues with RPIP-33 but to be honest, as coded they make more sense than the spec. Although rectifying the spend interval amount will not be possible, while keeping the scope small and quick. [https://discord.com/channels/405159462932971535/774497904559783947/1237575258500759614](https://discord.com/channels/405159462932971535/774497904559783947/1237575258500759614) Further messages came after that, the output of which should be captured in the initial post.