Closed bosko-m closed 2 weeks ago
@spannercode Can you also take a look at Sancho and Preview please?
@bosko-m according to the provided frontend code for creating a registration certificate, the vote delegation certificate always appears before the dRep registration certificate. If Ledger does not permit delegations to a non-existent dRep, then the order of cert in frontend should be updated accordingly. The certificate order is same when registering as a direct voter.
[
{
"VoteDelegation": {
"stake_credential": {
"Key": "1cf186c852a7e3644d84fdbe03ef221bd7647470c341bd11e9c90057"
},
"drep": {
"KeyHash": "5816cc9930591854211641ae3f732936780acf2e3754b0a760ce0b1b"
}
}
},
{
"DrepRegistration": {
"voting_credential": {
"Key": "5816cc9930591854211641ae3f732936780acf2e3754b0a760ce0b1b"
},
"coin": "500000000",
"anchor": {
"anchor_url": "https://metadata.cardanoapi.io/data/test",
"anchor_data_hash": "f186ae2a9ccb632a1e5251a824c5d46d82dabb0867ed51de548fe687f8f7b88f"
}
}
}
]
Since Node 10.X a new restriction was added to Ledger, that being "Ledger does not permit delegations to a non-existent dRep" This means the target DRep of a vote delegation MUST be registered before some can delegate
So for transactions containing both a Vote Delegation and DRep registration certificate, the DRep Registration MUST be added to transaction first to ensure it is executed first. As cert order does make a difference to the ledger.
Instances where multiple certs are in one transaction (for GovTool)
Registering as DRep/Direct Voter
Delegating to DRep - where stake key not registered
Area
Other
Domain
sanchogov.tools
Which wallet were you using?
No response
Context
Two apparently identical transactions for drep registration + vote delegation on sanchonet: one fails, the other succeeds.
Steps to reproduce
The difference between the two transactions is the order of the certificates. In the first one, the vote delegation certificate appears before the registration certificate:
{ "auxiliary scripts": null, "certificates": [ { "Stake address delegation": { "delegatee": { "DRep": "drep-keyHash-e9529fa1028dbe3388da5f26b6960d04d8e301c8a7adab6283397884", "delegatee type": "vote" }, "stake credential": { "keyHash": "1bf1e138f2f8beabc963c94cc28ee8ed4b41744601f2edaf50b21efd" } } }, { "Drep registration certificate": { "anchor": null, "certificate": { "keyHash": "e9529fa1028dbe3388da5f26b6960d04d8e301c8a7adab6283397884" }, "deposit": 500000000 } } ],....
while in the second one, the registration certificate comes first:
{ "auxiliary scripts": null, "certificates": [ { "Drep registration certificate": { "anchor": null, "certificate": { "keyHash": "e9529fa1028dbe3388da5f26b6960d04d8e301c8a7adab6283397884" }, "deposit": 500000000 } }, { "Stake address delegation": { "delegatee": { "DRep": "drep-keyHash-e9529fa1028dbe3388da5f26b6960d04d8e301c8a7adab6283397884", "delegatee type": "vote" }, "stake credential": { "keyHash": "1bf1e138f2f8beabc963c94cc28ee8ed4b41744601f2edaf50b21efd" } } } ],....
Ledger will not allow delegations to a non-existent drep, thats why I think the order matters.
Actual behavior
Certificates order is wrong, thus transaction failing
Expected behavior
Certificate order is right, thus transaction succeeds