Return unsigned delegation certificate

[hasufell]

Context

When joining a stake pool, the process is as follows:

1. Check if the account has already a registered stake key.
2. Check if the requested pool can be joined (it exists and it's not retiring).
3. Select coins to cover for either the delegation, or the delegation AND the key registration.
4. Sign the delegation (provide a witness for the stake key).
5. Submit the transaction.

The user wants to be able to:

1. Stop after step 3
2. Get the unsigned delegation certificate made by the wallet
3. Do step 4 and 5 on the client side

This ticket is about 1. and 2.

Decision

Acceptance Criteria

• The endpoint POST /wallets/{walletId}/coin-selections/random should be extended to accept a new request body, either { "action": "join", "pool": <pool id> } or { "action": "quit" }.
• Request bodies providing both "payments" and "action" should fail to parse with an appropriate error.
• Request bodies providing "pool" without "action" should fail to parse with an appropriate error.
• When provided with a poolId and an action the handler must verify that the action is valid and be consistent with the existing POST /stake-pools/{poolId}/wallets/{walletId} and DELETE /stake-pools/*/wallets/{walletId}` handlers (i.e. re-use the same logic).
• If valid, the request must be processed and return a list of resolved inputs, outputs, and a list of "certificates" depending on the scenario. Inputs and outputs should be already balanced to accommodate for the certificates.
• Certificates can be either: (1) a key deregistration certificate, (2) a key registration certificate AND a stake delegation certificate, (3) a stake delegation certificate.
• Certificate must be represented as JSON objects:
  • Key registration certificates should include a tag identifying the certificate, a bech32 serialized public stake key (according to CIP-5) and the derivation path corresponding to that key. (e.g. { "type": "key_registration", "stake_public_key": { "key": "stake_xvk1____", "derivation_path": "1852H/1815H/0H/2/0" } })
  • Key de-registration certificates should include a tag identifying the certificate, a bech32 serialized public stake key and the derivation path corresponding to that key.
  • Stake Pool delegation certificates should include a tag identifying the certificate and a bech32 serialized pool id.

QA

1. for the adjustment in the yaml schema check: https://github.com/input-output-hk/cardano-wallet/pull/2213/files#diff-d9433cbec16adf8a7dad1e1440a87cbee063b9fa9ebb7c6a631ce4a3482a4ed1
2. Also on API doc edge: https://input-output-hk.github.io/cardano-wallet/api/edge/#tag/Coin-Selections

Example requestes:

{
  "delegation_action": {
    "action": "join",
    "pool": "pool1wqaz0q0zhtxlgn0ewssevn2mrtm30fgh2g7hr7z9rj5856457mm"
  }
}

{  "delegation_action": {    "action": "quit"  } }

integration test scenarios here: https://github.com/input-output-hk/cardano-wallet/pull/2213/files#diff-883f5d29ba439fce1114ee5d9fdf3acf37f84150d24429f2f2ff768de0564d99R561

[piotr-iohk]

I have two questions/remarks:

Check if the requested pool can be joined (it exists and it's not retiring).

Currently one is able to join pool that is retiring... so does this means in coin-selection there will be a check to prevent that? I guess that wouldn't be quite right...

The endpoint POST /wallets/{walletId}/coin-selections/random should be extended to accept a new request body, either { "action": "join", "pool": } or { "action": "quit" }.

Just a thought, but maybe a bit more clear would be to have something like:

• POST /wallets/{walletId}/coin-selections/stake-pools/join-certificate/{pool id}
• POST /wallets/{walletId}/coin-selections/stake-pools/quit-certificate

or maybe

• POST /wallets/{walletId}/delegation-certificates/join/{pool id}
• POST /wallets/{walletId}/delegation-certificates/quit

[hasufell]

@piotr-iohk QA section updated