Issue with constructTransaction endpoint for a wallet created from xpub

[szymonmaslowski]

Just checking...

• This is a cardano-wallet bug.
• I am using the latest cardano-wallet release.
• I am using the correct cardano-node version for that release of cardano-wallet.

Version

v2024-11-18

Platform

macOS 14

Installation method

Nix

Network configuration

preview

Context

In the Daedalus, we serve HWs by restoring them in the Cardano Wallet using their account_public_key. Those wallets are having an issue calling the constructTransaction endpoint.

Description

Steps to Reproduce

1. Restore a wallet in Cardano Wallet using its account_public_key
2. Call the constructTransaction endpoint with { vote: 'abstain' } payload

Expected behavior

TX with votes delegation is correctly constructed

Actual behavior

Receiving an missing_policy_public_key error in response

[szymonmaslowski]

Unfortunately, changes from this PR do not solve the problem. Here is the change in the Daedalus repo bumping the CW to revision from the PR.

[szymonmaslowski]

There are reports from Daedalus users experiencing the same problem with wallets restored from mnemonic. In this case, the problem seems to affect only some of the wallets. Our team was not able to reproduce it.

[abailly]

@szymonmaslowski I can see this issue is referenced from a closed issue on your side, and there's been a Daedalus release, is this still relevant? Also, the description of the issue's context is pretty terse, can you elaborate on the conditions under which you observed the behaviour to be incorrect? Is this only for HW wallets? If I just restore a wallet from public key but the secret key is software, do you observe the same problem? What's the state of the wallet? How are the ADA's delegated?

It would help to have a minimal example reproducing the issue.

[abailly]

I have tried point 2. above on a wallet restored from public account key. Here is the state of the wallet:

{
  "address_pool_gap": 10000,
  "assets": {
    "available": [],
    "total": []
  },
  "balance": {
    "available": {
      "quantity": 224089650298,
      "unit": "lovelace"
    },
    "reward": {
      "quantity": 0,
      "unit": "lovelace"
    },
    "total": {
      "quantity": 224089650298,
      "unit": "lovelace"
    }
  },
  "delegation": {
    "active": {
      "status": "not_delegating"
    },
    "next": [
      {
        "changes_at": {
          "epoch_number": 187,
          "epoch_start_time": "2024-12-22T00:00:00Z"
        },
        "status": "voting",
        "voting": "no_confidence"
      }
    ]
  },
  "id": "7cc8fc38e4e4d8d74cc49512a556c47ffabea36b",
  "name": "Arnaud public wallet",
  "state": {
    "status": "ready"
  },
  "tip": {
    "absolute_slot_number": 78674007,
    "epoch_number": 185,
    "height": {
      "quantity": 2993038,
      "unit": "block"
    },
    "slot_number": 395607,
    "time": "2024-12-16T13:53:27Z"
  }
}

The transaction I submit is:

{
  "payments": [
    {
      "address": "addr_test1qppr7pnrkmksxjpx9hxu5zuquv30g92y9lzkpexe3pdl0qsd4tmh962gywl6dt4vt9c39tgqpg7ehl7f9fq7j9wzmfysp3mg2l",
      "amount": {
        "quantity": 10000000,
        "unit": "lovelace"
      }
    }
  ],
  "vote": "abstain"
}

and got the following output:

{
  "code": "missing_policy_public_key",
  "message": "It seems the wallet lacks a policy public key. Therefore it's not possible to create a minting/burning transaction or get a policy id. Please first POST to endpoint /wallets/{walletId}/policy-key to set a policy key."
}

so indeed the OP's output is confirmed. The question is: Is this is a bug or a feature?

[paweljakubas]

This PR probably will fix that error (too early we check policy key is there, we might either and also be ok) #4850

[szymonmaslowski]

@paweljakubas we tried out the changes from the PR you mentioned and unfortunately, it doesn't help.

[szymonmaslowski]

I can see this issue is referenced from a closed issue on your side, and there's been a Daedalus release, is this still relevant?

@abailly We are doing a nasty workaround so it would be much appreciated to resolve the problem.

[abailly]

@szymonmaslowski I can confirm this is a bug and @paweljakubas 's PR does not fix it.