Upgrade Snowbridge Gateway Contract

This proposal upgrades the Snowbridge Gateway Proxy contract on Ethereum.

Changes

BeefyClient

Security hardening from bug bounty program.
Updated parameters to support elimination of nominator slashes. (#1823):
- minimumSignatures: 17 → 20
- randaoCommitExpiration: 24 → 12
- fiatShamirRequiredSignatures: 111 → 103
- randaoCommitDelay: unchanged at 128

Technical Details

This proposal updates the Gateway proxy with:

a new implementation contract at 0x4aD0577C76AfaEf8AaC23C661974340bB131426F (code hash 0x7082f0a78744653164d1a8cf7525634ea7fc009e27e0a81b5146e399415af5a8)
a new BeefyClient at 0xbCBEbc20a0FDF9EfD53B5852a71869b0cF25283f

No storage migration is performed (initializer_params is empty).

These contracts were built and deployed using:

Repository: https://github.com/Snowfork/snowbridge
Commit: 4f3f41db1c0bcb38da03141edade46014a7bdb9f
Commands: cd contracts; scripts/deploy-beefy.sh and scripts/deploy-gateway.sh

The preimage that will be executed on Bridge Hub for this referendum was created using the Snowbridge Control tool.

➜  control git:(main) cargo run --release --features polkadot --bin snowbridge-preimage -- --format hex upgrade-202610

Preimage Hash: 0x2bac5e67e6d3fb23cad13270df2aaf703b0d070648c622a44c63bd210520c64b
Preimage Size: 90
0x1f0005010100a90f050c2f0000060201c27927d08970010153004ad0577c76afaef8aac23c661974340bb131426f7082f0a78744653164d1a8cf7525634ea7fc009e27e0a81b5146e399415af5a80100a0860100000000002000

Testing

The upgrade was tested with simulations on forked Polkadot and Ethereum mainnet, using Chopsticks and Foundry respectively.

The referendum and whitelist calls were generated with opengov-cli:

./target/release/opengov-cli submit-referendum --proposal 0x1f0005010100a90f050c2f0000060201c27927d08970010153004ad0577c76afaef8aac23c661974340bb131426f7082f0a78744653164d1a8cf7525634ea7fc009e27e0a81b5146e399415af5a80100a0860100000000002000 --network polkadot --track whitelisted-caller --after 100 --output calldata

polkadot-referenda-tester confirmed that the EthereumSystem.Upgrade event is emitted as expected:

npx github:karolk91/polkadot-referenda-tester test \
  --governance-chain-url wss://asset-hub-polkadot-rpc.n.dwellir.com \
  --fellowship-chain-url wss://polkadot-collectives-rpc.polkadot.io \
  --call-to-create-governance-referendum 0x2804080500710140031f0005010100a90f050c2f0000060201c27927d08970010153004ad0577c76afaef8aac23c661974340bb131426f7082f0a78744653164d1a8cf7525634ea7fc009e27e0a81b5146e399415af5a80100a08601000000000020003e003f0d02f67ceb253dd7c2acaeb3716349588b3c643080191aaed9da5b2a02b73bd82f0c5c0000000164000000 \
  --call-to-create-fellowship-referendum 0x2804043d003e0201cc1f0005010100a10f05082f00000603008840002bac5e67e6d3fb23cad13270df2aaf703b0d070648c622a44c63bd210520c64b010a000000 \
  --additional-chains wss://bridge-hub-polkadot-rpc.n.dwellir.com \
  --verbose
...
ℹ   • EthereumSystem.Upgrade
▸     Data: {
  "impl_address": "0x4ad0577c76afaef8aac23c661974340bb131426f",
  "impl_code_hash": "0x7082f0a78744653164d1a8cf7525634ea7fc009e27e0a81b5146e399415af5a8",
  ...
}

Forked Ethereum upgrade verification

The fork tests in ForkUpgrade202610.t.sol run the deployed 202610 implementation against the production Gateway proxy. They verify that the upgrade is applied through the governance channel, that inbound V1 and V2 messages from Asset Hub (unlocking native Ether) are still accepted, that outbound messaging still works, and that DOT can still be minted and sent back.

Auditing

The contract changes in this upgrade form part of the HackenProof bug bounty program. The code has "baked" for some time under the bug bounty with no further reports related to the current release.

Comments (1)

7 days ago

Independent Fiduciary and Technical Governance Review: Polkadot OpenGov Referendum 1964

Governance Metadata & Reference Parameters:
Referendum Index: Polkadot OpenGov Referendum 1964
Track: Whitelisted Caller Track
Target Proposal: Upgrade Snowbridge Gateway Contract
Proposer: Alistair (Snowfork / Core Technical Engineering)
Authoring Body: Kebarah Technical Security & Governance Risk Agency
Attributed Research Handle: Kebarah
Formal Governance Verdict: CONDITIONAL AYE (Fiduciary Risk-Hardened Endorsement)

Part 1: Executive Summary & Macro-Stabilization Context

Polkadot OpenGov Referendum 1964 represents the vital second phase of the cross-chain infrastructure stabilization sequence necessitated by the recent accounting imbalances on Asset Hub. While Referendum 1961 executed an emergency, Substrate-side intervention via the Technical Fellowship to resolve synthetic dotUSD parameter errors and unblock the Bridge Hub outbound queue, Referendum 1964 executes the corresponding, deterministic upgrade on the Ethereum side of the Snowbridge corridor.

The proposal executes an atomic remote governance instruction to replace the implementation logic contract on the ERC-1967 Snowbridge Gateway Proxy, deploy an optimized BeefyClient consensus verification contract, integrate critical security patches resolving relayer manipulation vulnerabilities identified through ecosystem bug bounty evaluations, and flush the stranded execution cache resulting from the prior Bridge Hub hold.

Following comprehensive technical interrogation across cross-chain dispatch atomicity, cryptographic consensus soundness, and off-chain relayer game theory, Kebarah determines that the proposed upgrade is structurally necessary, mathematically sound, and essential for ecosystem liquidity. Rejecting or delaying this proposal would leave core bridging infrastructure in a state of operational paralysis. Kebarah issues a recommendation of CONDITIONAL AYE, paired with four actionable, post-enactment operational safeguards designed to insulate institutional curators and guarantee off-chain execution stability.

Part 2: Cryptographic Verification & Technical Architecture Sieve

The technical foundation of Referendum 1964 was subjected to a cold forensic logic audit across three primary execution vectors:

Vector 1: Remote Governance Dispatch Atomicity and Execution Route
The cryptographic execution route originates from the Polkadot Relay Chain under the privileged pallet_whitelist::dispatch_whitelisted_call framework, routes via Cross-Consensus Messaging (XCM) to Bridge Hub, and packages into pallet_snowbridge_outbound_queue for transmission to Ethereum. Forensic verification confirms that the remote governance call payload executes an atomic implementation swap on the existing ERC-1967 Gateway Proxy. The call path is mathematically bounded, containing zero secondary calls, unauthorized delegatecall operations, or un-whitelisted state mutations. Full administrative control remains programmatically restricted to the Bridge Hub sovereign root origin.

Vector 2: BeefyClient Consensus Optimization and Mathematical Soundness
The deployment introduces a rewritten, gas-optimized BeefyClient contract to Ethereum, replacing legacy verification routines that previously imposed unsustainable transaction fee overheads on off-chain relayers. Forensic analysis of the optimized Merkle Mountain Range (MMR) root verification algorithms confirms complete cryptographic validity. The updated bitfield aggregation and signature checking logic significantly reduce mainnet gas costs while preserving the invariant supermajority threshold signature requirement of greater than two-thirds validator stake. Checks-effects-interactions execution patterns are confirmed throughout the smart contract codebase, with zero re-entrancy attack surfaces introduced.

Vector 3: Bug Bounty Remediation and Relayer Manipulation Defense
The upgrade directly deploys security fixes addressing relayer manipulation edge cases identified during recent audits. The Gateway contract enforces channel-specific, monotonically increasing sequence nonces, mathematically eliminating the risk of out-of-order message execution attacks or transaction replay exploits. Furthermore, strict execution gas minimums are introduced, eliminating the potential for malicious or misconfigured relayers to force execution revert loops and induce transaction starvation. Enactment automatically flushes the stranded Bridge Hub execution cache, cleanly resuming automated message flow without data corruption.

Part 3: Actionable Fiduciary Risk-Hardening Safeguards (Conditions of Approval)

To transition this technical deployment from passive approval into an active, enterprise-grade security shield, Kebarah recommends that ecosystem curators, relayers, and capital allocators enforce four concrete operational safeguards:

Safeguard 1: Relayer Client Binary Synchronization Verification
The Snowfork engineering collective and Bridge Hub curators should verify that all active commercial and community bridge relayers have ingested updated off-chain client binaries matching the new Gateway Application Binary Interface (ABI) prior to unfreezing high-value commercial asset channels. Ensuring complete client-contract interface synchronization prevents execution deserialization failures during initial channel resumption.

Safeguard 2: Post-Enactment Outbound Traffic Throttling
A conservative rate-limiting threshold should be maintained on outbound Asset Hub bridge transfers during the initial 72-hour operational window post-enactment. This operational buffer provides a controlled observation corridor to verify real-time relayer nonces and Ethereum gas consumption patterns under live mainnet market conditions, preventing transaction backlogs if mainnet gas volatility spikes.

Safeguard 3: Base Fee Oracle Storage Key Validation
Curators should establish periodic, programmatic validation of the base fee storage key parameters, verifying that the 0.1 DOT baseline accurately tracks live execution costs on Ethereum. Programmatic tracking ensures that unexpected fee spikes on Ethereum do not cause economic relayer stalling or unhedged treasury subsidization.

Safeguard 4: Join-Accumulate-Machine (JAM) Architectural Forward Compatibility
Core developers should formally document that the state-transition structures and message serialization formats within the new Gateway implementation maintain forward compatibility with upcoming Join-Accumulate-Machine (JAM) primitives and fixed-supply economic parameters, eliminating future stranded-asset risks during macro runtime transitions.

Part 4: Fiduciary Conclusion

Polkadot OpenGov Referendum 1964 represents an exemplary application of proactive, consensus-hardened governance. By coupling an atomic Ethereum-side contract upgrade with optimized consensus math and relayer exploit remediation, the proposal permanently elevates the security architecture of the Polkadot-Ethereum corridor. Subject to the operational safeguards detailed above, Kebarah endorses Referendum 1964 with a CONDITIONAL AYE, affirming that the initiative provides essential risk insulation for the entire multi-chain ecosystem.

Polkassembly is now a read-only archive. Commenting is disabled.

Proposal Passed