Unable to revoke Kraken (KRAKEN) token approval on Ink mainnet (approve(spender, 0) always fails)

Summary

I am unable to revoke a token approval on Ink mainnet for the Kraken (KRAKEN) token. Calling approve(spender, 0) consistently fails with an "internal error" in multiple wallets and UIs, so the allowance for this spender remains a very large uint256 value (effectively unlimited).

I’m reporting this here in case it is related to Ink infra / RPC / explorer integration and not only a third‑party wallet issue.

Network

• Network: Ink mainnet

Addresses / Contracts

• Owner (my EOA): 0x521D78818f6F96D8AcbAD527fB18D8a01319c9b7
• Token (Kraken / KRAKEN): 0xCa5f2cCBD9C40b32657dF57c716De44237f80F05
• Spender (DYORSwap router / contract): 0x9b17690dE96FcFA80a3acaEFE11d936629cd7a77

What I see

1. On the Ink explorer (Blockscout UI) under Contract → Read/Write contract for KRAKEN, calling:

   • allowance(owner, spender) with the above addresses returns a very large uint256 value (unlimited approval).

2. When I try to revoke by calling approve(spender, 0):

   • Via Revoke.cash on Ink
   • Via Ink explorer Write UI for the KRAKEN contract
   • Using several different wallets (Rabby, OKX, etc.)
   • Using the official Ink RPC endpoints

   the wallet shows an "internal error" and the transaction is not broadcast (no tx hash is created). The allowance value does not change.

3. Other transactions on Ink from this address work fine, so it doesn’t look like a general network or nonce issue for my account.

Why this matters

Because the allowance is still unlimited, if I ever receive KRAKEN on this address again, the spender contract theoretically can move those tokens. Right now my KRAKEN balance is 0, so there is no immediate loss, but it is impossible to properly revoke this approval and clean up wallet permissions.

What I expected

• approve(spender, 0) on the KRAKEN contract should succeed and set the allowance for this spender back to 0, like a normal ERC‑20 approval revoke.

Questions

1. Is there any known issue on Ink mainnet (RPC, gas configuration, or explorer integration) that could cause approve(spender, 0) on this token/contract to consistently fail with "internal error" in multiple wallets?
2. Is this behaviour expected for this token (e.g. non‑standard ERC‑20 implementation) or something that should be investigated as an infra issue?
3. Is there any recommended workaround to safely revoke this approval on Ink, short of abandoning this EOA for KRAKEN?

Happy to provide additional logs, screenshots or to test specific RPC endpoints if that helps. Thanks!

Start with the KRAKEN contract's allowance and approve calls through Ink explorer's Contract → Read/Write UI, Revoke.cash, and the official Ink RPC endpoints. Compare whether the call fails before broadcast across these entry points and determine whether the cause is token behavior, RPC or gas handling, or explorer integration. Done means documenting the confirmed cause and a safe revocation path, if one exists.