Skip to content

SCP Event Monitoring: createEventMonitor returns 175303 for implementation events on EIP-1967 proxy contracts #154

Description

@superbigroach

Summary

createEventMonitor (SCP Event Monitoring) returns 175303 "The specified event signature does not exist" for any implementation-defined event when the contractAddress is an EIP-1967 proxy (the standard OpenZeppelin UUPS/Transparent upgradeable pattern). SCP validates the eventSignature against the proxy's verified ABI — which only contains the proxy's own events (e.g. Upgraded) — instead of the implementation's ABI where the real events are defined. This makes SCP Event Monitoring unusable for the very common upgradeable-proxy contract pattern.

Environment

  • Network: Base Mainnet (chainId 8453)
  • Contract pattern: OpenZeppelin ERC1967Proxy (UUPS), implementation verified on Basescan
  • API: POST /v1/w3s/contracts/import + POST /v1/w3s/contracts/monitors

Reproduction

  1. Deploy a UUPS upgradeable contract (proxy + implementation) — implementation emits e.g. MatchCompleted(bytes32,address,uint256,uint256).
  2. Verify the implementation on the block explorer, and link proxy→implementation (Etherscan verifyproxycontract).
  3. importContract({ address: <PROXY>, blockchain: "BASE" }) → succeeds.
  4. createEventMonitor({ blockchain: "BASE", contractAddress: <PROXY>, eventSignature: "MatchCompleted(bytes32,address,uint256,uint256)" })

Real example (public, Base mainnet):

  • Proxy: 0xC2d9C772C7Fd8bdb735d597e1D724fE1cD605344
  • Implementation (verified): 0x1144f3094fE87784FBe307d16D1a66F43cA18099

Expected

A monitor is created for MatchCompleted — the event the implementation actually emits (and which is emitted from the proxy address at runtime via delegatecall).

Actual

{ "code": 175303, "message": "The specified event signature does not exist" }

Root cause

SCP appears to validate the event signature against eth_getabi(<proxy>), which for an EIP-1967 proxy returns only the proxy ABI:

  • getabi(proxy) → events: ["Upgraded"]
  • getabi(implementation) → events: ["MatchCompleted", "MatchCreated", "MatchRefunded", ...]

Events emit from the proxy address at runtime, but their definitions live in the implementation ABI. SCP only looks at the proxy ABI, so every real event is rejected.

What I tried (none resolve it)

  1. Verified the implementation contract on the explorer — getabi(proxy) still proxy-only.
  2. Linked proxy→implementation via verifyproxycontract (so the explorer's "Read as Proxy" resolves) — getabi(proxy) unchanged; still 175303.
  3. Re-imported the contract into SCP with a fresh idempotency key — still 175303.
  4. PATCH /v1/w3s/contracts/{id} with abiJson set to the implementation ABI — rejected with { "code": 2, "message": "API parameter invalid" }.

Note: monitoring the implementation address instead is not a workaround, because events are emitted from the proxy address (delegatecall), not the implementation address.

Feature request (any one of these would fix it)

  1. Resolve EIP-1967 proxies automatically — when an imported contract is detected as a proxy, validate event signatures against the implementation ABI (this is what Basescan's "Read as Proxy" already exposes once linked).
  2. Allow supplying the implementation ABI — accept an optional abiJson on POST /contracts/import (or make PATCH /contracts/{id} accept abiJson) so developers can register the implementation ABI for a proxy address.
  3. Allow a raw topic / eventSignatureHash on createEventMonitor — skip ABI validation and monitor by keccak256(eventSignature) directly, which is all that's needed to match logs.

Today, the documented "unverified contracts skip validation" behavior is the only way these monitors get created — which forces developers to set up monitors before verifying their contracts. That's backwards for production.

Thanks — happy to provide more repro detail. The upgradeable-proxy pattern is extremely common, so supporting it in Event Monitoring would be a big unlock.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions