Post-Mortem: Sky Proposal Submission — Value Parameter Error
Summary
On June 9th, StableLab submitted an onchain governance proposal on behalf of the Sky team to deploy their custom gateway contract on Arbitrum. After submission and prior to the voting phase beginning, the Sky team identified a critical mistake in one of the transaction parameters: specifically, the value field was incorrectly set to 820,000,000,000,000 ETH instead of 0.00082 ETH as intended.
Fortunately, this error was caught before voting commenced and no funds or contracts were impacted.
This post-mortem is intended to transparently explain the cause, contributing factors, and propose improvements to avoid similar issues in future governance submissions.
Timeline
-
Preparation Phase:
The Sky team finalized the execution payload and provided all parameters to StableLab in a HackMD document, including calldata and execution details. -
Submission:
StableLab copied the parameters as provided into Tally’s proposal submission interface. At this point, no validation errors were triggered. -
Final confirmation:
The Sky team conducted a final review of the proposal payload to verify that the calldata and parameters matched the intended execution details prior to sponsorship. -
Karpatkey sponsoring:
Karpatkey submitted the proposal onchain as proposal sponsor to enter the governance voting pipeline. -
Error Discovery:
During the delay period prior to voting, the Sky team performed a final review and identified that the value parameter was misrepresented by several orders of magnitude:-
Submitted: 820000000000000 ETH
-
Intended: 0.00082 ETH
-
-
Root Issue Identified:
The confusion arose due to unit mismatches between ETH and wei units.
Root Cause
- Unit Mismatch:
The governance platform (Tally) requests the value field in ETH units (Image), while the proposal value was provided in wei units (820000000000000 wei = 0.00082 ETH). This unit specification can only be seen by the proposal author.
View of the execution payload edition by the proposal author.
- Missed verification:
The Proposal Draft raw data shows the wei value of the proposal payload. This incorrect value was missed upon onchain submission of the Proposal Draft.
View of the Proposal Draft raw data by Proposal author and external reviewers.
- Failed onchain simulation incorrectly displayed:
While Tenderly can successfully spot the difference between the correct and incorrect payload ETH value (Image), Tally UI shows in both cases a “Passed” simulation, preventing the author from noticing the failed simulation unless specifically checked.
View of the proposal draft including the incorrect payload ETH value.
View of the Proposal Draft Simulation pop-up including the incorrect payload value.
View of the Proposal Draft Simulation pop-up including the correct payload value.
Impact
-
The proposal contained an invalid execution payload that would have, if executed, resulted in an unrealistic value transfer.
-
The error was detected before voting started; no contract interaction or fund movement occurred.
-
The proposal will be voted against upon delegate coordination and re-submitted with corrected parameters.
Lessons Learned
1. Unit Clarity Is Critical:
The discrepancy between wei and ETH units remains a high-risk area in manual governance proposal submissions. While engineers and protocol teams may commonly work with wei, many governance platforms request ETH input, creating easy avenues for human error. It is essential that both proposal authors and reviewers apply extra caution when inputting and verifying value parameters.
2. Proactively verify Proposal onchain simulations:
Even when platform UI indicates simulations have passed, teams should manually check transaction simulations like Tenderly whenever available. These external verifications often provide deeper transparency into the transaction payload and can catch issues that UI layers may overlook. Establishing this manual verification step as a mandatory part of pre-submission workflows can help ensure that critical execution payloads receive full scrutiny, regardless of front-end simulation results.
3. Strengthen Simulation and Validation Workflows for Critical Parameters:
While external tools like Tenderly correctly flagged the excessive value transfer, Tally’s UI displays a “Passed” status despite the incorrect ETH transfer amount. Importantly, these simulations and validations should not be passively displayed and flagged issues must be clearly surfaced in the user interface when anomalies are detected.
Next Steps
-
StableLab will collaborate with the Sky team to resubmit the proposal with the corrected value parameter.
-
The governance community will be kept informed to ensure full transparency.
Closing Thoughts
As StableLab continues to assist teams in navigating governance submission processes, we recognize the importance of continuously improving internal controls and cross-team coordination to make Arbitrum governance stronger. We take full responsibility for the oversight and are committed to strengthening our validation procedures to prevent such incidents in the future.
We appreciate the Sky team’s diligence in catching the issue early, the Tally team for timely addressing the incident, preventing further confusion, and thank the Arbitrum community for its understanding.
Post-submission update
We submitted the corrected proposal onchain. Following the advice of Arbitrum Foundation, we switched to using manual ticket redemption in the calldata as outlined here. For this reason, the msg.value field in the tally proposal was set to 0.