This creates a delegation certificate which delegates funds from all stake addresses associated with key stake.vkey to the pool belonging to cold key cold.vkey. …
… that would mean that eitherpayment.addr or stake.addr could store the pledge, because in the first step (Creating keys and addresses) they’ve both been associated with stake.vkey:
Does that mean the pledge can be maintained by the sum of the amounts at payment.addr + stake.addr? Or does one of them need to be ≥ the pledge amount in order to maintain pool rewards?
If either address, or the sum of both addresses, is acceptable: what suits the semantics of the CLI, documentation, and rewards mechanism better… to use payment.addr or stake.addr to store the pledge?
If I missed a place in either the new cardano-node docs or the old pages on Zendesk where it explains exactly how “pledge” behaves and how to administer it (more than simply how to pass it as a command line argument, i.e. --pool-pledge indicates “pledge” ) please let me know where it is.
Please one more question I’d like to throw in, and a general observation in case I have missed something substantial that makes the above look like a “stupid” question, and so remaining unanswered.
[In the “olden days” there would be a “man page” written concurrently with the cardano-cli shelley address build command to answer questions like this. Even if it’s only code comments on Github I’d be happy if someone can point out to me where I’ve missed it. Honestly if it’s documented in a 96 page PDF academic paper that would be good enough for me, as long as it provides a usable foothold on this command line API and the abstractions it relies upon.]
In the first command above, payment.addr is linked to two keypairs, stake.* and payment.*. Does that mean that both private keys stake.skeyandpayment.skey need to be supplied to sign a transaction from that address, or just one of those signing keys?
If it were the latter, it would make sense for the pledge to live in stake.addr because then the person pledging to a pool would be free to withdraw their pledge at any time without having to also provide payment.skey.
I really want to nail this down because of the comment @_ilap makes here that it makes more sense for payment.addr to be associated with payment.vkeyalone (not associated with stake.vkey). Following his own reference, the keys page rigorously defines what keys are used for, but doesn’t correlate these definitions with command line examples like the ones above.
Please, if these urgent questions are not clear enough then let me know & I’ll try to rephrase them somehow. Not having 8 months of experience with the ITN (we would have joined you if we had been able to!) we are at a great disadvantage trying to reverse engineer how this command line API works from a bunch of third-party helper scripts and HOWTO articles with inconsistent nomenclature. There is no help on Telegram for questions that take more than 10 words to pose.
I have 30 years of experience as a developer and I still can’t understand some of these abstractions that are defined only in people’s habits and collective memory… please send me a documentation link with current examples that covers “pledge” and “multiple signing keys” to prove me wrong about this. We are putting our life savings on the line during a documentation blackout and we need help.
I will try to rename the title in response the broadening of the question’s scope. I don’t care it attracts flames as long as people respond with specific links and references about how pledging works, both in general and specifically with respect to the key pairs used for the other aspects of stake pool creation.
No, stake address is a separate address used for withdrawing rewards. Place your pledge in the payment address corresponding to the stake address used to register the pool owner
Pledge (and pool) rewards will be paid to the rewards (stake) address of the stake rewards address registered with the pool.
The payment.skey used to sign the transaction corresponds to the address that will be paying the transaction fee and pool registration deposit - it can be arbitrary. When the pool is retired the pool deposit is returned to the rewards account (stake address) registered to the pool.
You need to sign the transaction with some payment.addr in order to pay the fees and pool registration deposit - it need not be affiliated with the stake vkeys used in the pool reg cert.
that is a great help @ADAfrog - since there is no answer to question #3 I will assume, starting with the built-in command help for cardano-cli shelley address build :
Usage: cardano-cli shelley address build --payment-verification-key-file FILE
[--stake-verification-key-file FILE]
(--mainnet | --testnet-magic NATURAL)
[--out-file FILE]
Build a Shelley payment address, with optional delegation to a stake address.
… since payment.vkey is required, while stake.vkey is optional… that if payment.addr is created as above:
The pledge can be withdrawn from payment.addr at any time using only the private key payment.skey… which is a feature of all Cardano addresses whether or not they are associated with a stake pool (by the --stake-verification-key-file option).
(in other words) stake.skeynever needs to be supplied to withdraw funds from payment.addr.
Providing stake.skey in the creation of payment.addr associates this address with whatever stake pool eventually registers using stake.vkey, particularly in documenting the address of the pledge.
(in other words) The Cardano rewards mechanism knows that payment.addr is where the pledge is kept because the stake.vkey used to create this address matches the --pool-owner-stake-verification-key-file provided to cardano-cli shelley stake-pool registration-certificate when finally registering the pool.
… and, if stake.addr is created as above, that:
The private key stake.skey is only used to sign pool related transactions as the pool operator, but cannot be used to withdraw the pledge from payment.addr.
(in other words) Since the payment key is not associated with stake.addr, only stake.skey is required to withdraw funds that have been lodged into the rewards account.
Please someone sign off on this as correct, or amend it as necessary … I am not the only one who needs to fully understand the behaviour of this system before going ahead with it. We also need to document these issues for new SPO arrivals until we have a complete behavioural description provided along with the node software.
thanks @ADAfrog for the confirmation, which will be good enough for us to go on for now, but I still don’t understand what you mean by this last statement. If payment.skey can authorise a transaction out of payment.addr (i.e., the “pledge address”), why does it not also authorise payment of the transaction fee from that address as it would in any other transaction?
) please let me know where it is. 
