Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CIP-0126? | Multi-Stake Delegation from a Single Account #628

Open
wants to merge 5 commits into
base: master
Choose a base branch
from
Open

CIP-0126? | Multi-Stake Delegation from a Single Account #628

Changes from 2 commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
2744bb2
Initial draft
AngelCastilloB Nov 30, 2023
cdafdd4
fix: address community feedback
AngelCastilloB Jan 3, 2024
b38ef16
fix: address community feedback
AngelCastilloB Jul 22, 2024
89bff9a
fix: address community feedback
AngelCastilloB Jul 24, 2024
ae06747
remove typographically incorrect white space
rphair Aug 20, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
164 changes: 164 additions & 0 deletions CIP-XXXX/README.MD
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,164 @@
---
CIP: ????
rphair marked this conversation as resolved.
Show resolved Hide resolved
Title: Multi-Stake Delegation from a Single Account
Category: Wallets
Status: Proposed
Authors:
- Angel Castillo <angel.castillo@iohk.io>
- Fernando Moreno <fernando.moreno@iohk.io>
- Martynas Kazlauskas <martynas.kazlauskas@iohk.io>
- Mircea Hasegan <mircea.hasegan@iohk.io>
- Rhys Bartels-Waller <rhys.bartelswaller@iohk.io>
Implementors:
- Angel Castillo <angel.castillo@iohk.io>
- Mircea Hasegan <mircea.hasegan@iohk.io>
Discussions:
- https://github.com/cardano-foundation/CIPs/pull/628
Created: 2023-11-30
License: CC-BY-4.0
---

## Abstract

This document presents an alternative approach for Cardano sequential wallets to support multiple stake keys by deriving them from a single account. Building
upon the foundations of [CIP-1852](https://github.com/cardano-foundation/CIPs/tree/master/CIP-1852) and [CIP-0011](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0011), this proposal introduces a simple method for managing multiple delegations within a single account.

While this proposal outlines a method for multi-delegation within the current framework of Cardano's features, it is acknowledged that more efficient strategies may exist, particularly if multi-delegation capabilities were to be integrated at the protocol level. This CIP offers a solution that operates effectively under the existing system. However, it is important to note that should the Cardano protocol evolve to natively support multi-delegation in the future, this CIP would be considered deprecated in favor of the more direct, protocol-level approach. Such an advancement would likely offer a more streamlined and potentially more robust method for managing multi-delegation, aligning with the evolving needs and capabilities of the Cardano ecosystem.

## Motivation: why is this CIP necessary?
The current philosophy of Cardano wallets, centering around a single stake key per wallet, has served well during the initial adoption phase. However, as the Cardano ecosystem expands and matures, the need for more flexible delegation options becomes evident. This proposal introduces a method for the derivation of multiple stake keys from a single account, combining the original simplicity with flexibility.

### Empowering Smaller Actors
In the current system, moderate stakeholders often find themselves constrained, unable to optimize returns due to limited delegation capabilities. This proposal empowers them to delegate across a diverse set of pools, offering a way to hedge against pool underperformance and sudden changes. It allows for a comprehensive view of their balance within a single account, thus combining convenience with enhanced delegation options. Additionally, Cardano projects are often funded via Initial Stake Pool Offering (ISPO). When multiple ISPOs happen at the same time, users might want to participate in more than one. Multi-delegation enables doing this from a single account.

### Addressing the Challenges for Large Stakeholders
Large stakeholders currently face the challenge of distributing their stake without causing pool over-saturation, which affects potential rewards. The current remedy, which involves segmenting funds into multiple distinct accounts, does not provide a good UX, requiring users to constantly switch across multiple accounts for core operations, or requiring wallet developers to add an abstraction layer on top of user accounts to overcome this issue.

### Efficient Fund Tracking with Optional Privacy
By linking all stake keys to the first payment key, this proposal introduces a transparent and simple mechanism for multi-delegation, greatly simplifying the fund tracking process. This association not only simplifies the delegation and deregistration processes but also facilitates easier tracking of funds and delegations. Besides, this method does not preclude the use of the multi-account approach for users desiring enhanced privacy. Stakeholders can still derive multiple accounts, each potentially capable of multi-delegation, granting them granular control while retaining the option for increased privacy.

### Foundation for Advanced Wallet Features and Enhanced User Experience
One of the underlying rationales of this proposal is to provide a robust foundation for more advanced wallet features. The dynamic nature of this approach offers wallets the opportunity to innovate. For example allowing users to support multiple DReps from a single account, or implementing sophisticated heuristics to maintain stake distribution to different pools. .

## Specification

### Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119).

Before delving into the specifics of the proposal, it's important to define two key terms that will be used throughout this document:

- **First Payment Key:** This refers to the external (role 0) payment key derived at index 0.

- **First Stake Key:** Similarly, this is the stake key (role 2) derived at index 0.

Throughout this proposal, the terms "first payment key" and "first stake key" will be used to refer to these specific keys.

### Overview

Under this proposal, the constraints of [CIP-0011 ](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0011)regarding the sole derivation index for the stake key are removed. While we introduce the ability to derive stake keys beyond the first , there is no strict requirement to do so in a sequential manner, although it is RECOMMENDED for logical organization. A pivotal change in this approach is that all derived stake keys MUST be associated with the first payment key. This consistent association to the first payment key serves as the foundation for the efficient discovery of these stake keys by wallet software and services.

### Multi-Delegating
- **Stake Key Derivation:** Begin by deriving the required number of stake keys needed for multi-delegation. While this derivation does not have to be sequential, it is RECOMMENDED for clarity and orderly management. Ensure that the gap between any two consecutive active stake addresses does not exceed 20, in line with the [BIP-44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) address gap limit.

- **Key Registration:** Once derived, it is REQUIRED to register these stake keys. This registration process SHALL remain consistent with current procedures, with the additional requirement that all these new stake keys MUST be associated with a common payment key.

- **Fund Distribution:** It is REQUIRED to distribute the funds across addresses formed by pairing the first payment key with each of the newly created stake keys. This distribution creates an association between all stake delegations. The specific details of how funds are distributed SHALL be determined by the user when creating the multi-delegation transaction.

Wallet software SHALL be able to easily discover all stake keys and associated delegations by sequential discovery.

External entities such as blockchain explorers or dApps SHALL be able to do the discovery by identifying addresses containing the first payment credential.

**Note that an address containing the first payment credential could be part of a mangled address and does not necessarily mean the stake credential is owned by the wallet.**

### Updating the Multi-Delegation
The dynamic nature of multi-delegation facilitates not just participation but also continuous optimization of delegations.

#### Adding Pools
To delegate to additional pools, the first step SHALL involve deriving the necessary number of new stake keys. Then, a transaction MUST be made that: registers the new stake keys, delegates, and distributes funds among addresses that pair the new stake keys with the first payment key.

#### Removing Pools
To remove a pool, the wallet MUST first identify all addresses associated with the stake key designated for removal. Then, a transaction SHALL be made that: transfers all funds from these addresses, withdraws all rewards from their associated reward accounts to one of the accounts that are still in delegation. If no other delegating accounts are left, the funds SHALL be reverted to addresses associated with the first payment key. Finally, the transaction MUST deregister the stake keys.

**Note that all rewards calculated but not distributed will be lost.**

#### Interoperability
Live delegation portfolio might drift overtime due to:
- Receiving funds to a single address
- Building transactions with software that doesn’t support multi-stake delegation (e.g. via dapp connector)

In order to maintain a record of a user’s delegation portfolio preferences, all actions related to stake delegation, including funds transfers, stake key registration, and deregistration, MUST be executed within a single atomic transaction when performing an update. This transaction SHOULD also include the delegation portfolio metadata, using the reserved metadata label 6862 (hexadecimal 0x1ace), as outlined in [CIP-0017](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0017). The metadata MUST specify only the **id** (pool id in hex) and **weight** fields, without including any of the optional fields.

Example:

``` Json
{
"pools": [
{
"ticker": "5f3833027fe8c8d63bc5e75960d9a22df52e41bdf62af5b689663c52",
"weight": 42
},
{
"id": "5f3833027fe8c8d63bc5e75960d9a22df52e41bdf62af5b689663c50",
"weight": 14
},
{
"id": "a16abb03d87b86f30bb743aad2e2504b126286fe744d3d2f6a0b4aec",
"weight": 37
},
{
"id": "9f9bdee3e053e3102815b778db5ef8d55393f7ae83b36f906f4c3a47",
"weight": 25
}
]
}
```

The inclusion of the delegation portfolio object as transaction metadata is REQUIRED, this serves to reflect any updates to the user's delegation preferences on-chain. This ensures that external applications retrieving this information are always presented with the most current data, eliminating the need to parse through multiple transactions.

External applications can retrieve the most up-to-date delegation portfolio for a given wallet by scanning the blockchain for the latest transaction with the metadata label 6862 originating from the user's wallet. This transaction will contain the metadata with the current delegation portfolio, thereby affirming the wallet owner's latest delegation preferences.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Scanning historical transactions for a specific metadatum label is rather inefficient. For wallet apps, that's a minor problem since they will typically want to present the whole transaction history to the user anyway and they only deal with one or a small set of wallets. But for dApps that are confronted with ever new wallets every moment, it might well be prohibitive.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree here, but what could be the alternative? Also for external applications that need this information, they could build any off-chain solution to make this efficient.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To be honest, if this standard were to be adopted the only way I would support it as a dApp developer is if the wallet itself either:

  1. Figured out its changing strategy for me
  2. At least provided the connected wallet's changing strategy

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for the latest transaction with the metadata label 6862 originating from the user's wallet

There's no such thing as user's wallet. There are utxos at addresses that are being consumed. Consider this: I construct an atomic swap transaction and put metadata that redefines the portfolio. I send it to the swap counterparty and they sign it. Who of us now has the delegation preferences updated?

Or even simpler, I am a malicious NFT minting dApp that wants to steal user's delegation. I put a metadata hash but do not disclose it to the user (which is normally expected)...

It is important to note that currently metadata posting never imposes any financial consequences for the users. But with this proposal adopted, it will.

This should not be accepted without a clear algorithm how to go from a chain of transactions to a mapping of payment_address -> delegation_map

Copy link
Author

@AngelCastilloB AngelCastilloB Dec 5, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the feedback @klntsky, only updating the metadata doesn't affect the users delegation, the delegation can only be altered by submitting certificates and the right signatures in the transaction, so a malicious dApp cant steal user delegation by only updating the metadata of the transaction. The portfolio metadata is only intended to be consumed by off chain clients for context, I.E to determined the users preferences vs theirs actual stake distribution

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@AngelCastilloB

delegation can only be altered by submitting certificates and the right signatures in the transaction

They do not specify the amount, so that any ADA that is on a stake pubkey is automatically delegated.

Which means a wallet or a dApp that consumes this info will find the wrongly updated metadata and prompt the user to either perform a rebalance, or will silently generate a change distribution such that ADA is moved to a SP the user didn't want to prefer more.

Right now as I understand there is no well-defined connection between user's "identity" and metadata, and what is this "identity" is also undecided.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah I see your point now @klntsky, so yes it would be possible for a malicious dApp to move the percentages, but it wouldn't be possible to make the user delegate to a different pool.

So I guess the attack vector you are suggesting here would be for an adversarial pool to create a dApp that when it detects an user that is multi-delegating and one of the pools is multi-delegating to is in his control, it would then change the percentages to make it more favorable for him.

I think we have a few options here:

  • Add a signature to the metadata
  • Place the metadata in an script output the user controls

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add a signature to the metadata

Yep. That would also make it unambiguous who is the issuer of the metadata in case of multiple user inputs. Moreover, to support this edge case, user address or pubkeyhash can be used as a key in the map.

Place the metadata in an script output the user controls

There is no way to prevent consuming an UTxO from another wallet


### Change Balancing Algorithm

Balancing change is a crucial feature designed to maintain a user’s stake distribution, using the portfolio preferences attached to the delegation transaction. As transactions occur over time, the distribution of funds across different pools will deviate from the initial portfolio percentages as the change would otherwise be concentrated onto a single address, and therefore be delegated to a single pool. This drift can be corrected while constructing transactions for a user who has defined a multi-delegation intent by reading the preferences from the delegation transaction metadata and distributing the change to best adhere

When implementing this feature, it is essential to maintain the integrity of the change outputs as produced by the input selection algorithm. The design of these algorithms, such as the Random Improve input selection, is aimed at optimizing the overall health of the wallet's UTXO (Unspent Transaction Output) set. This optimization includes avoiding the creation of dust and ensuring that the size of outputs aligns with the user's spending habits over time.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is Random Improve really a good coin selection algorithm for this? Is it – in an unmodified form – even a good coin selection algorithm for wallets with native tokens?

Shouldn't it at least be modified to select UTxOs from all stakes as proportional as possible and not leave that to the randomness of the algorithm?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Random Improve was just provided as an example. The point here would be that implementing multi-delegation shouldn't require changing the current input selection algorithm to accommodate it, the wallet could be using an input selection strategy that optimize for a given use case, ideally we dont want to disrupt that, as forcing the wallet to come up with a new input selection algorithm that satisfies his use case and multi delegation could be too problematic. Also during our internal tests, just directing the change output was sufficient to advert drift in the long run


Therefore, the following key principle will guide the balancing change process for wallets that are multi-delegating:

Every multi-delegation transaction (creation or update) MUST include the delegation portfolio metadata specifying the percentage of funds they wish to delegate to each pool. This portfolio serves as a guideline for how funds SHOULD be distributed across different stake keys.
When subsequent transactions are built, input selection is performed as usual. The resulting change from the transaction is then evaluated for rebalancing. The structure and size of change outputs determined by the input selection algorithm SHALL be preserved.
The change outputs SHALL be distributed as-is across multiple addresses associated with different stake keys, without altering the output values. Priority SHOULD be given to stake keys that are most divergent from the set preferences, thereby gradually realigning the actual distribution with the user's delegation strategy.

#### Benefits and Implementation Considerations

Consistent Delegation Strategy: Ensures that the user's delegation strategy is consistently maintained, even as funds are spent and rewards are received.

UTXO Set Optimization: Maintains the health and efficiency of the UTXO set as intended by the input selection algorithm.

Reduced Manual Adjustments: Minimizes the need for users to manually rebalance their stake across different pools, saving time and effort.

### Reference Implementation

An already working implementation can be found in Lace wallet and the Cardano-js-sdk:

- Lace: https://github.com/input-output-hk/lace
- Cardano JS SDK: https://github.com/input-output-hk/cardano-js-sdk/blob/master/packages/e2e/src/tools/multi-delegation-data-gen/index.ts

rphair marked this conversation as resolved.
Show resolved Hide resolved
## Rationale: how does this CIP achieve its goals?

This CIP details a method for delegating to multiple pools from a single account, effectively meeting the Cardano community's demand for more versatile delegation strategies. By permitting users to manage multi-pool delegations within one account, this proposal significantly enhances the user experience, offering benefits in terms of investment diversification and risk management. Furthermore, it lays the groundwork for advanced wallet functionalities, like supporting multi-DRep delegation and introducing more complex algorithms for stake distribution. It is important to note, however, that this approach is designed within the constraints of the current Cardano features. Should future protocol developments introduce native multi-delegation capabilities, this CIP would be superseded.

## Path to Active

### Acceptance Criteria

- [ ] The proposal is adopted by all major wallets and dApps in the ecosystem.
Copy link
Collaborator

@rphair rphair Jul 6, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think merging this as written would ensure that the CIP stays in Proposed status forever. Depending on the outcome of the discussion planned in my review above, this could be a sensible approach... although if other implementations are on the horizon then a more flexible acceptance threshold should be defined here.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@AngelCastilloB - continued in #628 (comment) with a reason why it may actually make sense to leave this apparently unsatisfiable criterion on the list.


### Implementation Plan

- [X] Publish open source reference implementation and instructions on how to do multi delegation from a single account using this proposal.

## Copyright

[CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode)