u/yermakovsa

I’ve been working on a small Go library for Ethereum signature verification. The part I’m still unsure about is the policy around the main Verify function.

The narrow case is:

address + already-computed common.Hash + signature -> valid?

Repo: github.com/yermakovsa/erc6492-go

It handles:

• EOA recovery
• EIP-1271 for deployed smart contract wallets
• ERC-6492 signatures through a configured deployed verifier

I’m intentionally keeping the scope small: no message building, no EIP-712/SIWE/EIP-191 hashing, no wallet deployment, no RPC client management, and no embedded deployless verifier bytecode. Anything before the final hash exists is outside the package.

The main Verify path currently does:

ERC-6492 wrapped signature
→ WithERC6492Factory wrapping path
→ EIP-1271 if signer has code
→ EOA fallback

There are also narrower entry points: VerifyEOA, VerifyEIP1271, and VerifyERC6492.

This is v0.1.0, so I’m trying to catch bad API/policy decisions before the package hardens.

I’m unsure about a few things:

1. If the signer has code and EIP-1271 returns a clean invalid result, like wrong magic value or revert, should Verify fall back to EOA recovery? Or would you expect contract-wallet verification to be strict once code exists?
2. ERC-6492 currently requires a deployed verifier address. I avoided embedding deployless verifier bytecode because I didn’t want copied bytecode in the package without pinned source, compiler settings, and reproducible provenance. Is that too conservative, or reasonable for a small library?
3. Does this error split feel right?

​

invalid signature, including malformed/non-canonical EOA signatures
→ Result{Valid:false, Method:...}, nil

RPC / ABI failure / malformed ERC-6492 wrapper / unexpected verifier output
→ error

Also curious if the overall Go API shape feels natural: one main Verify plus narrower explicit functions.

Would appreciate blunt feedback from anyone who has dealt with EOA / contract wallet / counterfactual wallet signature verification.

I recently open-sourced a small Go library called rcpx:

https://github.com/yermakovsa/rcpx

It’s an HTTP JSON-RPC failover transport, mostly meant for Go apps using go-ethereum clients like rpc and ethclient.

The basic idea is: configure a few RPC upstreams, use rcpx as the Transport on a normal http.Client, and if one upstream starts failing, requests move to the next one in priority order.

Roughly:

rt, err := rcpx.NewRoundTripper(rcpx.Config{
    Upstreams: []string{
        "https://primary.example",
        "https://backup.example",
    },
})
if err != nil {
    // handle error
}

client := &http.Client{
    Transport: rt,
}

Right now it supports:

• sequential failover by priority
• retries on transport errors and HTTP 429, 502, 503, 504
• cooldowns for unhealthy upstreams
• replaying request bodies across attempts
• not failing over JSON-RPC write methods like eth_sendRawTransaction by default, unless explicitly enabled

I kept the scope intentionally narrow. It’s not a proxy, gateway, hosted service, quorum requester, or full RPC abstraction. It’s just a small transport-layer piece for Go apps that already use Ethereum JSON-RPC and want explicit failover behavior without running another service.

It’s still early, so API/design feedback would be especially useful from people who have dealt with RPC reliability issues in real Ethereum infra.

I’m especially curious about:

• whether the failover rules seem reasonable
• whether the write-method defaults are too conservative or not conservative enough
• whether this API fits real rpc / ethclient usage
• what edge cases I’m missing around retries, request replay, cooldowns, or provider behavior

I’d really appreciate technical feedback, especially from people who have had to handle RPC reliability issues in production.