CIP: Stake URI scheme for pools & delegation portfolios

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).

5 Likes

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
}
2 Likes

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

@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

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

2 Likes

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

1 Like

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:

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

3 Likes

@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.

Responded on your Catalyst project page.

1 Like

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

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).

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