CIP: Stake URI scheme for pools & delegation portfolios

Staking & Delegation Stake Delegation
, , ,
1

Below is a draft Cardano Improvement Proposal (CIP) for stake pool & staking portfolio URIs. A robust forum discussion is a required step of submitting this plan as a CIP. I’m open to changes & suggestions before submitting the first draft of that CIP, and will include any corrections & consensus from the community as time goes on. I’ll include the Github CIP link in a further comment as soon as it’s produced.

Discussion is vital to keep this CIP moving forward so the necessary application support can be made in time to reverse the centralisation of stake in Cardano. This design outline would benefit the most from comments by:

  • IOHK developers working on multi-pool wallet delegation in Cardano
  • Large stake pool owners and their delegates currently using contrived means (e.g. lists of ticket symbols on Twitter) to suggest alternatives as their pools repeatedly face saturation
  • Small stake pool owners unable to find adequate delegation from the community according to their peer relationships or distinctive qualities
  • Cardano supporters & Ada holders concerned that the unabated trend of stake centralisation to only “K” (currently 150) virtually saturated pools are both a present and future vulnerability
  • Foundation members & marketers working to maintain the public perception of Cardano as the world’s most promising decentralised cryptocurrency

Assuming this is accepted as a CIP it will take time to implement… although consensus here about a stake portfolio URI scheme would provide a framework in the meantime for third parties to develop & document “stake pool portfolios” and tools to manage them, rather than waiting for these to be produced and implemented by a centralised authority.

CIP: ?
Title: Multi-Pool Stake URI Scheme
Author: Robert Phair <rphair@cosd.com>
Discussions-To:
Comments-Summary:
Comments-URI:
Status: Draft
Type: Standards
Created: 2020-09-22
License: CC-BY-4.0
Post-History: https://forum.cardano.org/t/40594

Summary

Support reading and writing weighted lists of stake pools through a URI scheme, facilitating automatic stake allocation in all Cardano wallets and other means of delegation.

Prerequisites

Support in wallets & exchanges for multi-pool delegation.

Abstract

Cardano wallets and exchange delegation mechanisms currently have no means to receive an Internet friendly reference to one or more stake pools in a way that establishes their proportion for staking: in general terms, a portfolio.

A staking URI scheme will allow such portfolios to be easily developed and shared by the community itself, with a common standard for interpreting these on Cardano wallets and compliant exchanges.

Aside from portfolios, It will also meet the simple but vital use case of individual pool web sites providing a one-click reference directly into a user’s delegation wallet.

Motivation

Centralised sources of information, particularly a Daedalus ranking mechanism currently biased to only take into account rewards from the top K (currently 150) largest stake pools, have led a growing amount of stake to be disproportionately assigned to pools pushed near & beyond the saturation point.

A growing Cardano blockchain, facing a likely sudden increase in load within the year from the introduction of Smart Contract applications, needs to more rigorously maintain its goal of decentralisation by distributing the balance of rewards, network/computing power, training, and operational knowledge among an increasingly larger group of operators. Otherwise that sudden increase may require an equally sudden rise in K to a much greater figure without having at least that number of high-quality pools.

There is also a subjective perception within and without the Cardano community that the stake pool conglomerates and Cardano foundational entities are effectively sponsoring centralisation of stake for their own benefit. Supporting a means for small stake pools and staking peer groups to be individually recognised would reverse this trend both practically and subjectively.

Specification

Example, trivial case (a single pool):
web+cardano://stake?COSD

Example, simple case (a non-weighted portfolio of 3 equal favourites:
web+cardano://stake?IOG1&OCEAN&EMUR1

Example, more general case (a weighted portfolio, top 10 pools by 30-day ROA at time of writing):
web+cardano://stake?CRAB=30.14&MYTH=20.84&NINJA=20.04&HYPE=17.80&MARLN=16.92&KINGS=16.81&COSD=15.62&RAID3=15.32&ZOE=15.20&XORN=14.93

Syntax explanation (see Wikipedia: Uniform Resource Identifier):

  • this takes protocol web+cardano from the Yoroi reference implementation linked below and adds an “authority” (//stake) to differentiate the stake pool reference(s) from a payment request URIs or references to some other Cardano resource.
  • For security the hex pool ID should be usable here instead of each stake pool name, although with SMASH currently slated for Daedalus integration this may not be necessary to avoid ambiguity.

Syntax items, in order:

  • protocol: web+cardano:
  • authority: //stake
    • if authority is omitted, assumed to be a payment URI (see Reference Implementation)
    • if authority is something else, it refers to a different Cardano subsystem than staking.
  • arguments (? before first argument, & before each additional argument
    • poolTicker or poolHexID (mandatory)
    • =proportion (optional): integer or decimal, indicating relative size of stake allocation

Interpretation of proportion:

  • If only one stake pool is specified, any proportion is meaningless and ignored.
  • If all stake pools have a numerical proportion, each component of the resulting stake distribution will have the same ratio as the provided proportion to the sum of all the propotions.
  • If none of the proportions are given, all proportions are assumed to be equal.
  • If some of the proportions are missing, any missing proportions are set to the average of all those specified explicitly.
  • If a stake pool is mentioned multiple times, those proportions as determined above are added together.
  • When exporting proportions, order is not considered important but for readability should be in descending order by proportion, with the first proportion normalised to 1 (to avoid privacy risk of using actual delegation amounts).

For this specification to be fully implemented by the wallet or exchange itself, it should be possible to do at least these two things, corresponding to both import and export of stake allocation:

  • upon receiving a staking URI, invoke a UI to allocate stake in the proportion indicated by the URI (from a single wallet, if supported)
  • upon request from the user, format that user’s stake allocation as a compliant URI suitable for copying & sending.

Rationale

Since specific plans for “Stake Pool Portfolios” have not been announced (to the author’s knowledge), nor have SPOs or delegators been told they will be able to design their own portfolios (except in videos where this idea is discussed as a conjecture), without an alternative the community would have to wait for both software support and “official” portfolios to be curated and offered from a centralised source.

In the meantime, there would be little practical alternative to the current system of:

  • large pools maintaining delegation based on mainly on historical position at the top of lists ranked effectively by stake volume, or users following historically significant branding, even if a pool is saturated;
  • small pools struggling to be noticed by distinctiveness or popularity on centralised platforms like Twitter and YouTube, sometimes offering exotic or unsustainable incentives to attract delegation.

We offer this rationale how URI-based “crowdsourced” portfolios will provide better results, according to these linking scenarios:

  • Current wallet implementations allow wallets to link to pool web sites, but with a means for a browser or mobile app to follow a URI they will also be able to go in the other direction.
  • The pool web site itself is the richest source of information about a pool’s offering, and a URI ensures that information can be easily transferred to a user’s delegation preference.
  • Links sent between third parties will allow users and special interest groups to share suggested stake allocations with others by copy & pasting a link, through messaging & social networking.
  • Links generated from the wallet itself can promote staking strategies that anyone determines to be useful: practically, economically, or socially.

…with these benefits for each part of the Cardano staking ecosystem:

  • small pools : making it easier for potential delegators to find individual pools, while pool ranking sites may always favour the most heavily delegated pools (even when saturated, since many users simply follow brand recognition) and those with the greatest (now impassable) numbers of produced blocks
  • medium sized pools : supporting inclusion in third-party delegation lists, therefore helping users find delegation without the prejudice of ranking algorithms advantageous only to the K largest stake pools (see CIP: Non-Centralizing Rankings)
  • large pools : providing to superfluous delegators a simple & effective exit strategy when nearing or passing the saturation point (currently done mostly through the error-prone, easily subverted medium of social networking)
  • communities of pools : i.e. special interest, self-organising, union-formed, or democratically established peer groups, with any of these criteria and more:
    • merit-based (community or infrastructure contribution)
    • community-based (geographical, technological, or other affiliation)
    • need-based (to help the smallest pools achieve block eligibility / sustainability)
    • charity-based (with verified humanitarian distribution of rewards)
  • automation & integration : allowing portfolio links to be generated through novel means by a greater variety of new & third party web sites, scripts & software tools, and checking real and hypothetical portfolios for past results and anticipated performance
  • delegators : having an alternative to picking only the “top of the boards,” often losing rewards due to inevitable pool saturation… eventually having a rich ecosystem of alternatives beyond whatever staking portfolios may be curated & integrated into the wallet by central authorities.

Alternate designs

A developer suggested using a JSON file instead of a URI, which the author believes is not acceptable as a universal recommendation:

  • HTTP Content-Disposition: headers sent with any downloaded file, as well as file extensions & MIME types, often disrupt that file’s interpretation by the system or application: in this case creating a dead end from the user experience that wallet or exchange web site developers would not be able to prevent.
  • The generally private nature of this data would lead to issues of confidentiality and censorship, for which the *.torrent file specification eventually developed the magnet: URI protocol as an alternative: hence the similar URI based solution in this case.
  • The simplest, most common use case of pool owners and supporters being able to easily construct a single pool reference, without access to specialised knowledge or resources to post a JSON file (e.g. as one can for a YouTube link from a video ID), would be defeated by only allowing JSON data.

JSON files would be a useful portfolio format in addition to the URI as long as developers and users remain aware of the limitations above. The portfolio specification rules above could also apply to standards for building & interpreting such a JSON file… therefore I would leave it to the developer community whether JSON processing or syntax should be a part of this CIP or submitted as feature requests for the relevant wallet software.

Backwards compatibility

This proposal does not break backwards compatibility because it is an offchain change.

Reference implementation

The URI syntax above has been chosen to follow the same general scheme as the Yoroi wallet payment link URI scheme discussed here: (implement uri scheme on yoroi frontend #511). The two types of URIs will easily coexist because only the stake URI links contain an extra //stake authority component.

A simpler format was also offered here (FR: Daedalus payment URLs #883 comment (2018-04)), suggesting the need for a staking URI scheme, but only as an aside to consideration of a payment URI syntax, and without the means to accommodate multiple staking addresses.

Copyright

© 2020 Robert Phair (22 September 2020). This CIP is licensed under the CC-BY-4.0 license.

NOTE the above is the final edit of this posting; all further changes will be made on Github (see below for link).

9 Likes
2

I would rather see it as a json file you upload to the wallet that’s a dictionary of poolid mappings to weights personally where the wallet automatically rebalances the utxos needed for the weights specified in your portfolio. Something like portfolio.json:

{
"pool11234567890...": 0.5,
"pool10987654321...": 0.25,
"pool15432167890...": 0.25
}
3 Likes
4

Thanks @disasm for participating and that’s a good idea. I didn’t conceive it that way mainly based on experience of *.torrent files vs. magnet: links with the same data encoded as a URI.

Every time you download a file from an application you have to declare (or use the default) HTTP Content-Disposition: which may also involve running another application on your device… which means maybe running the wrong application as we see so often on mobile devices, or simply downloading the file somewhere instead of using it how the sender or receiver intended. The URI protocol will be unambiguously associated with our Cardano apps, while the JSON file extension & MIME type will not.

The other advantage to magnet: links (and thereby stake URIs) is anonymity and censorship resistance at a number of levels of the Internet that cannot be not provided by *.torrent files. Those same qualities will also appeal & be useful to a good percentage of cryptocurrency users. Someone somewhere at some point will try to track the download & transmission of portfolio files, while the text of portfolio URIs gives them less to hold onto.

I think the JSON file would be a great part of the overall data structure. Most of the features & advantages delineated in the CIP would apply to JSON as well. Though not part of the template, there should be a part of the CIP that includes expansions on the idea & I’ll include this as such in the submitted draft. :sunglasses:

1 Like
5

@disasm I’ve added your suggestion, along with my response, to the draft proposal above, in the section Alternate designs (that phrase itself is taken from the suggested content for the Rationale section). I’ll be forking the repo later today and officially submitting the proposal as a pull request. :sunglasses:

1 Like
6

Current draft, awaiting review (get the most current text here):

2 Likes
7

Current pull request in main repository (follow the status here):

1 Like
8

This has also been submitted as a Project Catalyst idea (note you need an Ideascale account to read the contents of this link): https://cardano.ideascale.com/a/dtd/URIs-for-Stake-Pools-and-Portfolios/324335-48088

Even if discussion proceeds on Catalyst we will still rely on Cardano Forum users to post their opinions here. There needs to be some expression of stakeholder opinions, even if not a consensus, regardless of how the idea of crowd-sourced delegation portfolios is implemented. :sunglasses: :pray:

9

I like this proposal.
It seems simple, straightforward and easy to understand.
Nice work!

4 Likes
10

@SebastienGllmt with your contributions already to the “Reference Implementation” above I’ve been hoping you would chime in about this CIP itself. Also today your name came up on the related Project Catalyst proposal (URIs for Stake Pools and Portfolios) when an idea supporter referenced your video:

The complexity of the issue & uncertainty about at what level it would be handled are why I listed that issue as a prerequisite for this CIP. Still it’s not too early to talk about how it will be possible to use multi-delegation when it finally does arrive, to avoid another long wait before the community itself can evolve its own ways of using that feature.

It’s encouraging to see the last few minutes on the whiteboard sketching out fractions & proportions for a distribution of delegation in a single wallet. Still I don’t see any sign that multi-delegation wallets will support incoming stake pool distributions by any means (URI, JSON, ???). i.e., How would that information get into the wallet in the first place?

There must have been some discussion among developers about how community-produced delegation lists will be generated & interpreted. It seems like these two issues would go hand in hand so I’m hoping you can record some of your ideas & that history here.

11

Responded on your Catalyst project page.

1 Like
12

thanks @SebastienGllmt - since there is now both developer & community feedback on the Catalyst page, I’ve added that page as a discussion link in addition to this one.

Post-History: https://forum.cardano.org/t/40594
Post-History: https://cardano.ideascale.com/a/dtd/324335-48088
13

Updates to CIP in this commit which include feedback from more developers (at the pull request link above) as well as a development timeline (for the whole readable proposal, click the /blob link above).

14

Further updates to this CIP in this commit, to supplement this new related CIP:

1 Like
15

Discussion of the CIP is progressing on this forum thread, with some interest in stake pool portfolio links as a solution for low stake allocation among the largest identified set (via @rodri) of pools affiliated through ethnicity, culture, country and/or language:

1 Like
16

I’d like to see this staking URIs implemented sooner rather than later. It would really be great if delegators can just click a link on our websites and it can automatically launch their wallet and proceed to confirming the delegation…

I’m not sure where it’s best to post this comment now. This thread seems to be the more appropriate one for furthering the discussion on this subject.

The other thread you referenced above is about a related but not exactly the same topic. It’s probably best if we just refer people into this thread.

1 Like
17

thanks @nimrod, you’ve posted it in the right place, for now & the future… any comments & affirmations should be posted here. As other discussions of this idea emerge I’ll also link them back here, so if they’re also on this forum Discourse will in turn create a back-link to this thread. Anything you think the developers need to see can also be posted at the Github link of the “pull request” above.

FYI for everyone, as I said earlier in this comment because of the live discussion there, I’ve agreed with @SebastienGllmt to split this CIP into a single-pool part to ride in with his “payment link” CIP and a multi-pool part to be added as a later edit… in the interest of getting the single pool links implemented ASAP. It is taking me a few days to do this delicately, to preserve the supporting information for the related Catalyst proposal as the voting gets under way. :sunglasses:

3 Likes
18

Single-pool links will still be a great improvement over what we currently have. Big step forward! Thanks for all your effort on this, @COSDpool…

2 Likes
19

OK, now we have a stripped down, single-pool version of this proposal to address the most vital issue: delegation links for individual pools. See this Github comment for more information about the split.

Rationale

As K continues to increase, options for convenient and informed re-delegation will become more important. Both delegators and small pools looking to survive will inevitably rely on sources of information outside the wallet to suggest pools beyond the highly contested top choices of the in-wallet ranking algorithms.

More meaningful association between a pool’s social identity and delegated stake will help ensure that pool operators are rewarded, by their own communities and other supporters, for helping maintain a number of pools sufficient to accommodate Cardano’s needs during any expected expansion period.

Cardano’s decentralisation stage will overlap with its smart contract introduction, and a sudden DeFi migration to Cardano would also mean a vast, sudden increase in transaction frequency and depth that the stake pool network will need to support with quality and diversity.

Beyond the obvious help to small pools, further increases in the K value will also make this feature important for larger pools, to provide an “exit strategy” for saturated or saturating pools, redirecting their delegators toward alternates.

The proposals for community delegation portfolios and multi-pool staking links will be added back in after these two CIPs are merged & the resulting CIP is approved. To follow and participate in this discussion directly with the developers, use the link above… otherwise keep posting your feedback & feelings here. :heart_eyes:

2 Likes
20

Good to see an update on this!

2 Likes
21

Please let me ask again for the responsible developers to accommodate the needs of the community by progressing this proposal & its dependencies, especially with this kind of news coming in:

Ada holders will need a user friendly way of breaking up their stake sooner rather than later, as soon as the protocol supports it: otherwise generous but naive delegators are likely to go on disruptively saturating small pools.

Since this problem will be a couple of standard deviations closer when K goes up to 1000 (and the saturation point halves), the community needs to be kept better informed about any progress toward multi-pool delegation, as well as its related URI standard now that I’ve done all I can in the writing & community outreach.

We are still waiting on the word of @SebastienGllmt & the CIP meetings about our green-lighted CIP merger & the beginning of a general URI standard for stake pools as well as payments. Payment links may have been declared low priority but we’re heading quickly toward the point where the stake pool link issue becomes vital. :pray:

2 Likes