[PASSED] OP-PIP-133: Abstract — Pyth Upgraded Core

Proposals
1

Abstract

Repair the Abstract mainnet deployment that did not complete during the OP-PIP-132 EVM cutover by re-issuing the three required governance actions with an Abstract-compatible implementation:

  1. UpgradeContract → deploy the Pyth Core implementation compiled with zksolc.
  2. SetDataSources → switch to the upgraded Pyth Core data source.
  3. SetWormholeAddress → switch to the Wormhole receiver carrying the Pyth Pro guardian set.

This proposal applies to Abstract mainnet only. The target chain ID is 60071.

The on-chain proposal is available here: Pyth Network

Rationale

Abstract is a ZK Stack chain and requires contracts compiled with zksolc, rather than the normal Solidity EVM compiler path. Abstract was included in the original 33-chain OP-PIP-132 cutover. However, its original UpgradeContract instruction pointed to an implementation produced through the standard EVM deployment path. That deployment produced a solc artifact of approximately 24,067 bytes, which was not valid zkEVM bytecode for Abstract. When the OP-PIP-132 governance message was executed on Abstract, the UpgradeContract action reverted. The proxy’s validation call to: this.pythUpgradableMagic() could not reach a working compatible implementation.The original governance VAA is immutable and chain-scoped. Its UpgradeContract payload hard-codes the original implementation address, so it cannot be edited to point to the corrected implementation. The relevant governance sequence also cannot be replayed with a modified payload.

The corrected implementation was deployed through: target_chains/ethereum/contracts/deploy/zkSyncDeployNewPythImpl.ts

This produced the Abstract-compatible implementation: 0x2F026C506C85c9Eb5EB3Ebc1b9939153aa996844

The new implementation reports the expected Pyth upgrade magic: 0x97a6f304 and Pyth Core version: 1.4.6

Proposed Actions

  1. UpgradeContract

Execute: GovernanceAction.UpgradeContract on Abstract mainnet, target chain ID 60071. The original OP-PIP-132 implementation target was: 0x7ea57c50b561c44965b8ed70eb686279f968dcf6

The corrected implementation target is: 0x2F026C506C85c9Eb5EB3Ebc1b9939153aa996844

The corrected implementation is compiled with the Abstract-compatible zksolc toolchain.

  1. SetDataSources

Execute: GovernanceAction.SetDataSources with one data source:

emitterChain:   26
emitterAddress: 0x507974686e6574507974686e6574507974686e6574507974686e657450797468

After execution, the Abstract Pyth Core contract will accept updates from the upgraded data source and will no longer accept the legacy data sources.

  1. SetWormholeAddress

Execute: GovernanceAction.SetWormholeAddress with the new Wormhole receiver: 0x14b9932cc9AC8Ee03301665a8644A753f46D8552

The receiver is configured for Abstract mainnet chain ID 60071 and uses guardian set index 0 with a 3-of-5 quorum.

The guardian set is:

0x41534bB176E461A3fb30479400f210549eCCE638
0x6502987B62F21Cab7eb5cCd8f0173084b60d5B41
0x44A3e8F6a382412CF6BB90A3F8106e68977476C9
0xd9D7D4529577864352c9A6539a48238fCD447052
0x1663a5A822336ece48559B1DFB1e93A017a7DAC3

Execution Order

The three instructions must execute in this order:

  • UpgradeContract
  • SetDataSources
  • SetWormholeAddress

The ordering is required because:

  1. The implementation must be upgraded before the new Wormhole receiver can be installed.
  2. SetDataSources must execute while governance is still verified through the existing receiver.
  3. SetWormholeAddress must execute last because subsequent governance messages will be verified using the Pyth Pro guardian set.

Verification

1. Decode the on-chain proposal

git clone <https://github.com/pyth-network/pyth-crosschain.git>
cd pyth-crosschain

pnpm install

cd contract_manager
pnpm tsx scripts/check_proposal.ts \
  --cluster mainnet-beta \
  --proposal 4Ge9wE18QBQZmvp6SxbcGGZ3mCghjwsKSzrcQPFDHy2p

The decoded proposal must contain exactly three Abstract-targeted governance messages:

UpgradeContract
SetDataSources
SetWormholeAddress

The target chain ID for all three messages must be: 60071

2. Reproduce the Abstract zksolc artifact

The Abstract implementation is compiled using:

Solidity:                         0.8.20
@matterlabs/hardhat-zksync-solc:  0.3.17
zksolc:                           1.4.1
Compiler source:                  binary
Optimizer:                        enabled
Artifact format:                  hh-zksolc-artifact-1

From the contract directory:

cd target_chains/ethereum/contracts

pnpm exec hardhat compile --network abstract

The relevant artifact is:

artifacts-zk/contracts/pyth/PythUpgradable.sol/PythUpgradable.json

The expected deployed bytecode is:

126,240 bytes

The expected keccak256 digest is:

0x83d645993cd3f7c062de5be98907e13bfc01a6299770a6f188efd202f816d667

The deployed implementation at: 0x2F026C506C85c9Eb5EB3Ebc1b9939153aa996844 must match the generated deployedBytecode byte-for-byte.3. Verify the live implementationThe deployed implementation must return:

pythUpgradableMagic(): 0x97a6f304
version():             1.4.6

4. Verify the Wormhole receiver

The receiver at: 0x14b9932cc9AC8Ee03301665a8644A753f46D8552 must have:

  • The expected receiver proxy bytecode.
  • The expected 3-of-5 receiver implementation.
  • Guardian set index 0.
  • The five guardian addresses listed above.
  • Wormhole chain ID 60071

References

3 Likes