Kaan Uzdoğan
Kaan Uzdoğan
Do we need to run the full query btw? Isn't the verified_contracts id just an incremental number?
It's not really worth the effort right now to fix these 324 contracts. Moving to backlog
I've encountered this error in another VeChain verification too. Verifying `0x894Dd008137135E6ebfA9D303b9C3e8002206b71` it fails to parse the block with the following error: ` 2025-06-03T07:21:57.242Z [warn] [LibSourcify] Failed to fetch the block...
Bumping this, how would you like to proceed with this? Do you want to open an issue at ethers or create a fork and modify the related code in sourcify-monitor....
How does it reduce the bundle sizes?
Just took a look. This is a Vyper contract and an instance of #2233
This is a [ERC-5202](https://eips.ethereum.org/EIPS/eip-5202) (Blueprint) contract as pointed out, and such contracts do not fit into the standard verification process of comparing onchain vs recompiled bytecodes. From my understanding the...
Now I see the situation. To summarize the ERC-5202 lays out an EVM bytecode spec (not a language spec) to deploy factories onchain that are not meant to be interacted...
Btw thanks for reporting this @Argeric Are you aware of any contracts deployed via this blueprint? Since deployed contracts just copy the bytecode and don't call this blueprint, it's not...
We should double check if this includes the deprecated chains and the placeholder onchain bytecode for them