CIP - Transferring Stake Pool Ownership


This CIP proposes a way to transfer ownership of a stake pool from one pair of cold keys to another.


CIP 1853 describes how node operators should derive their stake pool cold keys according to a hierarchical deterministic (HD) standard. However, many existing stake pool operators have not derived their cold keys accordingly, and are thus unable to implement the standard without starting and marketing a new pool from scratch.

Additionally, the current protocol is such that when stake pools retire, the pool’s delegates are responsible for re-delegating to a new pool, lest they miss out on future rewards. A pool-ownership transfer mechanism could “point” the old pool’s delegation certificates at the new pool.

Furthermore, a pool-transfer mechanism would allow SPO’s who are no longer willing or able to administer their pool to sell their pool to a prospective buyer, without giving up custody of their cold keys. This is an important feature because it allows such operators to maintain custody of the history of their time as an SPO.


Pool ownership can only be transferred to unused cold keys, such that no pair of keys can ever be responsible for more than one pool. The transfer itself is initiated by specifying the new cold key-pair in the deregistration certificate of the old pool.

new deregistration-certificate flag

This certificate will act as a “pointer” for a pool’s entire history, including its current stake distribution.

Similar to how any ADA that resides at a stake address is automatically delegated to the pool that address is pointed to, any stake addresses delegating to the old pool are automatically pointed at the new pool.

Upon pool retirement, all delegation certificates from the current pool are “pointed” to the new pool. This is to ensure that the old pool is not pointed towards an existing pool, but rather a newly registered pool.

A --new-cold-verification-key-file flag is added to the cardano-cli stake-pool deregistration-certificate sub-command, requiring signatures from both cold-keys, as follows:

cardano-cli stake-pool deregistration-certificate \
--current-cold-verification-key-file current-cold.vkey \
--new-cold-verification-key-file new-cold.vkey \
--epoch <EPOCH_NUMBER>    # bound by the eMax parameter
--out-file <FILE_PATH>

The new pool must be registered on an epoch equal to or greater than the one specified by the below deregistration certificate.

Pool deposit fee of the old pool will be returned to the old reward account, as usual.


This CIP would benefit from being implemented at the same time as additional SPO-related features are implemented that require a HFC. Most notably - alongside a CIP/change that introduces group ownership of pools Conclave, and/or contingent staking mechanisms (like this one)

Other Possible methods:

registration-certificate method:

We can add a --prev-cold-verification-key-file flag to the registration certificate command, and require signatures from both cold keys:

cardano-cli stake-pool registration-certificate \
--cold-verification-key-file new-cold.vkey \
--prev-cold-verification-key-file old-cold.vkey \

However, this implementation is sub-optimal because it would require a signature from the old cold key each time the new pool is updated, which is nonsensical in the context of transferring pool ownership.

transfer-certificate method:

We can add a transfer-certificate sub-command to the cardano-cli stake-pool command, and require signatures from both cold keys.

cardano-cli stake-pool transfer-certificate \
--current-cold-verification-key-file current-cold.vkey \
--new-cold-verification-key-file new-cold.vkey \
--epoch <EPOCH_NUMBER>
--out-file <OUT_FILE>

Additionally, to incentivize careful consideration before transferring pool ownership, and/or to prevent sybil-like or malicious pool transfers, there should be a significant fee for the transfer. Considering a pool transfer should be a major event in the pool’s lifetime, the fee can be similar, if not exactly the same, as the poolDeposit fee (currently 500 ADA).

Summary of CIP Benefits:
  1. Current SPO’s have no way of implementing CIP-1853 (unless they have already done so) without creating a new pool.

  2. An SPO may become unwilling or unable to continue administering their pool. Instead of de-registering the pool, they may wish to sell the pool to a buyer.

  3. Currently, if a pool is retired, each delegator is responsible for delegating to a new pool. This CIP would allow the old pool’s delegators to be automatically delegated to the new pool.

  4. If/when shared ownership of stake pools (Conclave) is implemented, transferring one’s share of a pool will not only be useful, but necessary.

Stake Pools are endogenous entities of the Cardano Protocol, and, much like native ADA, should be transferable.

Backwards Compatibility

This CIP requires changes to the core protocol, and thus likely a HFC.

I don’t believe this necessarily creates any breaking changes in the protocol, but I may be wrong - please advise

I do the need for this and so long as it can be safely implemented it would be a nice feature to have. There should also be some talk about if the ownership (presumably management) is moved to another person should the previous management history be discarded?

But yes it would be a nice addition to the chain.

@zhekson I do remember when this forum thread was submitted, but I never saw a corresponding PR come up on the cardano-foundation github repo. To help answer the last person’s question, can you post why you never went on to submit it officially?

I’m not saying that it should have been submitted & personally I’d rather see a more assignable stake pool ownership established by CIP-1853 itself. From what I understand the earlier proposal also solves some issues with hardware wallets, which are much more popular for stake pool administration today than in December 2020 when CIP-1853 was drafted.

Anyway I hope that’s not the end of the discussion & that the author, other SPOs can all keep contributing here until this proposal is either officially submitted or abandoned. :sunglasses:

(p.s. also maybe the earlier CIP author @Rafael_Korbas is still on the forum & could contribute here.)

I never saw a corresponding PR come up on the cardano-foundation repo.

As per the CIP-1 specification for progressing ideas into draft CIPs, I wanted to first engage the community on this idea before proceeding with CIP formalization. I’ve already formatted the CIP to resemble a draft, and I am hoping for additional engagement. Perhaps I can submit it as a PR as is and see if there will be more engagement on Github.

Edit: Submitted as a PR: CIP - Transferring Stake Pool Ownership by nomadpool · Pull Request #276 · cardano-foundation/CIPs · GitHub


This is the right path, sorry it took so long to get any discussion on this.

I think it could prove useful in some cases and bad in others for example people buying good stake people history and running it maliciously. Do you have a preventive mechanism for this?

1 Like

I don’t see how the game theoretics here differ from what we have now. Stake is still liquid so anyone can redelegate, just as if one would have to if a pool shuts down like usual. People are still responsible for delegating to honest operators, this CIP simply makes the “Stake Pool” a transferrable entity, much like ADA or other tokens.

If a malicious actor buys a stake pool and uses it to attack the network, it is effectively the same as if an existing stake pool turns malicious - it is up to the delegators to redelegate and keep the stake in honest hands.


Its different, when DiDs come out it will be effectively impossible to determine the ID of most stake pool operators and so it would be too difficult to corrupt them in a off-chain sense, this would however enable the purchase of these pools by a collection of DiDs enabling bad actors without off-chain consideration.

Regardless of how delegators asses an operator’s reputation - whether it be via the present system or via decentralized on-chain reputation (DiDs) - it is still their (the delegators) responsibility to select honest operators.

If a pool is acquired by a new owner, they are subject to the same level of scrutiny as any other pool owner/operator. This principle holds true in both the centralized and decentralized reputation paradigms; it is foundational to PoS consensus as a whole.

I don’t see how the ability to transfer pools detracts from the system’s ability to keep stake in honest hands.

Transference is an attack vector when concerning keys.

I do not think a transfer fee is sufficient protection and would like to see significantly more details on how this process would be conducted. Retirement in the sense of ceasing to function by taking the pool down would be significantly safer. In this case transference of the the ticker/name to the new more secure variant of key custody is the primary use case?

Conclave? Never heard of her (no code = no care)
White papers, marketing, and propaganda might work in bull markets but now is the time for development :smiley:

1 Like

It is already currently possible for pool ownership and keys to be transferred privately off-chain. An on-chain solution would facilitate cross-border and trans-regional pool ownership transfers.

This type of feature could be used by adversarial corporations andor forced by nation states. This is a serious consideration.

@DinoDude Please elaborate on how “transference is an attack vector when concerning keys”

To be clear, regular pool retirement would still be an option. This CIP would give the additional option to designate a new cold key pair in the deregistration certificate, thereby transferring the pool itself (and all its current delegates, not just the ticker/name) to the new cold key pair. Signing can be conducted in an airgapped/secure fashion (as it is done now), and sequentially; without either party giving their secret keys to each other.

As you mentioned, transferring the pool to one’s own new keypair that is “more secure” or, as mentioned in the draft, CIP-1853 compliant, is one use case. I would say the primary use case is the ability to transfer a pool to a new owner while maintaing custody of your history as an owner/operator, for reputation/auditing/sentimental e.t.c. purposes.

As for your comment on (node code = no care), necessity is the mother of all invention! Before we have code, we have ideas, wants, and wishes - we have to start somewhere! :wink:

@Michael.Liesenfelt Could you please elaborate on how you see adversarial actors taking advantage of this feature, taking into account the delegator’s ability to shift stake?

My contention is that the overall security of the system has been and will continue to be in the hands of the delegators, so the integrity of public on-chain pool transfers are theirs to assess.