Hi — we're deploying a Kernel v3.3 account with a session-key permission validator (Timestamp + RateLimit + Call policies) on BSC testnet (chain 97). Confirmed via eth_getCode that RateLimitPolicy (0xf63d4139B25c836334edD76641356c6b74C86873) has no bytecode deployed on BSC testnet, while TimestampPolicy and the permission ECDSA signer module both are — this causes every enable-mode validateUserOp to revert with an empty-data AA23 reverted 0x, since Kernel's own policy-install loop hits an empty-code address.
We've confirmed RateLimitPolicy was originally deployed on Ethereum mainnet via Arachnid's deterministic CREATE2 deployer (0x4e59b44847b379578588920cA78FbF26c0B4956C, which is present on BSC testnet too), through an ERC-4337-relayed transaction. Could you share the exact CREATE2 salt (and/or the raw deployment calldata) used for RateLimitPolicy, so we can redeploy the identical bytecode to the identical address on BSC testnet ourselves? Happy to also just request you deploy it if that's easier on your end.
Hi — we're deploying a Kernel v3.3 account with a session-key permission validator (Timestamp + RateLimit + Call policies) on BSC testnet (chain 97). Confirmed via
eth_getCodethatRateLimitPolicy(0xf63d4139B25c836334edD76641356c6b74C86873) has no bytecode deployed on BSC testnet, whileTimestampPolicyand the permission ECDSA signer module both are — this causes every enable-modevalidateUserOpto revert with an empty-dataAA23 reverted 0x, since Kernel's own policy-install loop hits an empty-code address.We've confirmed
RateLimitPolicywas originally deployed on Ethereum mainnet via Arachnid's deterministic CREATE2 deployer (0x4e59b44847b379578588920cA78FbF26c0B4956C, which is present on BSC testnet too), through an ERC-4337-relayed transaction. Could you share the exact CREATE2 salt (and/or the raw deployment calldata) used forRateLimitPolicy, so we can redeploy the identical bytecode to the identical address on BSC testnet ourselves? Happy to also just request you deploy it if that's easier on your end.