Omnilock signer

[sophia1ch]

I was wondering if there are any plans to add support for Ethereum-style OmniLock signing in ckb-sdk-go?

Right now, it seems like there are two limitations in the signer/omnilock package:

The AuthFlagEthereum is defined as 0x1, but newer tools like ckb-ccc use 0x12 for Ethereum-based OmniLock addresses. So the supported flags may be outdated.

Even with the correct flag, there's no implementation for signing transactions with Ethereum-style signatures (e.g., the standard MetaMask-prefixed keccak256 message format).

This functionality would be very helpful for projects using EVM wallets with OmniLock (e.g., for cross-chain swaps with MetaMask).
Just wanted to check if this is already on the roadmap — and if not, whether it’s something that might be considered?

[eval-exec]

@XuJiandong @zhangsoledad @quake What do you think about this, I’d appreciate your opinions.

[XuJiandong]

The 0x12 flag enables a message display like the following:

CKB transaction: {txhash}

This is more wallet-friendly for signing purposes. I suggest we consider adding it in SDK.

Even with the correct flag, there's no implementation for signing transactions with Ethereum-style signatures (e.g., the standard MetaMask-prefixed keccak256 message format).

I don't know what is the details. The prefix is already used.

[sophia1ch]

I don't know what is the details. The prefix is already used.

I meant to reference this part where the omnilock signer does not yet support all prefixes.

[XuJiandong]

yes. It's suggested to implement AuthFlagEthereum and AuthFlagBitcoin firstly.

[sophia1ch]

yes. It's suggested to implement AuthFlagEthereum and AuthFlagBitcoin firstly.

Do you know when or if this is planned to be implemented?
I’ll need the feature in the near future, so if it's low on the priority list, I can implement it myself.

[eval-exec]

yes. It's suggested to implement AuthFlagEthereum and AuthFlagBitcoin firstly.

Do you know when or if this is planned to be implemented? I’ll need the feature in the near future, so if it's low on the priority list, I can implement it myself.

Hi! The priority for this is quite low. If you’d like to implement it yourself, would you consider opening a PR? Otherwise, I’d be happy to work on it.

[sophia1ch]

Hi! The priority for this is quite low. If you’d like to implement it yourself, would you consider opening a PR? Otherwise, I’d be happy to work on it.

Hi, I linked the PR with my implementation.

[eval-exec]

Hi, I linked the PR with my implementation.

Thank you!