I was able to execute my script for rewards withdrawal a couple of weeks ago, when I execute it today, it shows the following error message when submitting the transaction via blockfrost. Please note that I didn’t delegate to drep instead I delegated for the staking pool.
data: {
error: 'Bad Request',
message: '{"contents":{"contents":{"contents":{"era":"ShelleyBasedEraConway","error":["ConwayWdrlNotDelegatedToDRep (KeyHash {unKeyHash = \\"***********************************************\\"} :| [])"],"kind":"ShelleyTxValidationError"},"tag":"TxValidationErrorInCardanoMode"},"tag":"TxCmdTxSubmitValidationError"},"tag":"TxSubmitFail"}',
status_code: 400
}
Was there a change in the protocol recently, that we do need to delegate for the Drep while delegating for the staking pool.
This is the stake address :
stake_test1uq9rp53r9hn96kv88968v66hlham9zy3suvpwd5xu3g5amsz7vzth
on preprod.
I am looking forward to your thoughts. Thanks in advance.
Yes, exactly that. As the error states.
Will also be the case on mainnet after the next protocol upgrade.
But you don’t have to be delegated before you stake. You don’t even have to be delegated to receive staking rewards on your stake address. You just have to be delegated to withdraw them from the stake address. If you want, that can wait months or years.
Having an issue when deserializing the hex value of the drep id. As it resulst in 29 bytes, but the const drepKeyHash = CardanoWasm.Ed25519KeyHash.from_bytes(Buffer.from(drepId, ‘hex’)) expects 28 bytes.
All the drep id are having the hash length of 29. Am I missing something?
Using the latest version of the @emurgo/cardano-serialization-lib-nodejs. - 13.2.0
There are actually two types of dRep IDs confusingly both starting with drep1:
The older, deprecated one according to CIP 105 should contain only the usual 28 byte key hash, the newer one according to CIP 129 additionally has a header byte that additionally specifies the type (constitutional committee member cold key, constitutional committee member hot key, or dRep) and if it is a key or script hash.
For a usual dRep with a key pair (not a script), the header byte should be hexadecimal 22.
And yes, the confusing two different dRep IDs for me (https://adastat.net/dreps/drep1yf8p623g9s0yxnlnjzealgajyxl57k7n6saeavc7azg0crcahnul9) give 28 bytes for the legacy one and the same 28 bytes plus a header of 22 for the new one:
1 Like
Thanks @HeptaSean, It helped.
I purchased a “hobby” plan on blockfrost APIs. But I am still unable to get a response Blockfrost.io - Blockfrost Open API (governance) endpoint. It always return 404 for drep ids which acre active on preprod too. Do I need to upgrade the payment plan to “developer” or “enterprise” to access governance plan?
Again, using myself as example:
Blockfrost only finds the dReps with the legacy CIP 105 dRep ID, not with the new CIP 129 dRep ID.
https://api.koios.rest/ on the other hand, finds them with both:
(…, but gives the CIP 129 ID in the response in both cases.)
