CoreKit Error After Failed Transaction Signing - "Custom factor pub [object Object] not found for tssTag default"

Environment:

  • SDK: Web3Auth CoreKit [^3.5.0-0]

  • Platform: [Web]

  • Network: [Mainnet]

Issue Description:

I’m encountering a critical error with CoreKit where after a failed transaction signing attempt, the entire CoreKit instance becomes unusable with the error:

Custom factor pub [object Object] not found for tssTag default

Steps to Reproduce:

  1. Initialize CoreKit and login successfully

  2. Perform standard operations (all work fine initially)

  3. Attempt to sign a transaction

  4. Transaction signing fails with the above error

  5. After this failure, ALL subsequent CoreKit operations fail with the same error including:

    • exportPrivateKey()

    • Transaction sending

    • Any other CoreKit methods

Expected Behavior: CoreKit should either recover from the failed signing attempt or provide a way to reset the state without requiring a full re-initialization.

Actual Behavior: CoreKit becomes completely non-functional after the initial signing failure. The error persists across all operations.

Additional Context:

  • This occurs randomly/intermittently

  • I suspect there may be a state synchronization issue between local CoreKit and server metadata

  • The only recovery seems to be completely reinitializing CoreKit

Questions:

  1. Is there a recommended error handling pattern for failed transaction signing?

  2. How can I detect and recover from this desynchronized state?

  3. Are there any known issues with metadata sync that could cause this?

Any insights would be greatly appreciated!

Hi and thanks for reaching out about this. Would you mind posting this in Embedded Wallets (Web3Auth) - MetaMask Builder Hub, the developer discussion category from this community forum has migrated there. :grinning_face: :hot_beverage:

Hi @trinhchau ,

Thanks a lot for flagging this and for sharing all the details — we discussed this internally with the Web3Auth product team.

Based on what we’ve seen so far, this behavior might be related to the recent AWS infrastructure outage, which caused some temporary instability in backend services. We’re still verifying that hypothesis, and to help us narrow things down, we’d need a bit more context from your side:

  1. When the issue occurs, do you have to create a new account, or can you recover your existing one after logging back in?

  2. Did this happen to a newly registered user or to an existing one (created a week or more ago)?

  3. Did the problem first appear before, during or after the AWS outage window?

These details will help us confirm whether this stems from a temporary desync or a deeper metadata inconsistency.

Thank you!

Hi @khanti42,

Thank you for looking into this! Here are the answers:

1. When the issue occurs, do you have to create a new account, or can you recover your existing one after logging back in?

There’s a sequence of issues: First, I encounter “CoreError: Share doesn’t exist” when trying to sign a transaction. I bypass this by inputting the recovery factor key, which makes the instance work again. Then the “Custom factor pub not found” error occurs, and after that the instance becomes completely unusable.

2. Did this happen to a newly registered user or to an existing one (created a week or more ago)?

Newly created accounts. The most recent case was an account created just 15 minutes before the error occurred. However, this is not the first time - we’ve encountered the “Custom factor pub not found” issue multiple times previously.

3. Did the problem first appear before, during or after the AWS outage window?

I don’t have context about the specific AWS outage timing you mentioned. However, we’ve been experiencing this issue intermittently over the past few weeks, so it’s likely this predates any recent outage.

I suspect this is related to synchronization issues between the local CoreKit instance and server-side metadata on Web3Auth.

Thank you!

This topic was automatically closed after 26 days. New replies are no longer allowed.